Download - Curso Aseguramiento de Calidad
Aseguramiento de Calidad
Agosto de 2008
TemarioTemario
• Control y Aseguramiento de la Calidad– Números y ejemplos– Definición de calidad– Aseguramiento y control de calidad– La calidad en el ciclo de vida del software– El plan de calidad– Métricas
TemarioTemario
• Testing– Definiciones– Tipos de test– El proceso– Técnicas de derivación de casos de test– Tips– Documentación– Estimaciones
• Inspecciones de código y revisiones• Conclusiones
Control y Aseguramiento de la CalidadControl y Aseguramiento de la Calidad
MotivaciónMotivación
• Preguntas– ¿Cuál es el impacto de un error detectado por un usuario, en la operación
de la aplicación? – ¿Cuál es el costo para el negocio?– ¿Cuál es el costo de solucionar el problema en el software?
El costo de los errores El costo de los errores
• Error en proceso de facturación, descubierto por un cliente de la compañía– Un millón y medio de facturas reimpresas (costos de impresión de facturas
y del área de sistemas para subsanar el problema)• Error en el costeo de llamadas en empresa de telecomunicaciones
– No se cobran las llamadas de larga distancia de 400.000 clientes durante un mes
• Error causa la caída de un website de inversiones durante dos días– Pérdida de transacciones y posibles clientes
• Error en el formato de las direcciones reconocidas por un sistema de despacho de ambulancias
– Provoca una demora de 30min en llegar al domicilio de un hombre con riesgo de muerte
Efectos de una baja calidadEfectos de una baja calidad
Algunos números sobre los defectosAlgunos números sobre los defectos
• 50 % de los defectos se introducen durante la programación.• Hoy, no más del 15% de los defectos iniciales son detectados antes del testing.• Al comienzo del test de unidad la densidad es de 20 defectos x cada 1000 líneas
de código (no comentadas).• 80% de los defectos de prog. se encuentran en el 20% de los módulos de
programación. Muchos se ven durante la integración.• El costo de reparación crece con el tiempo (1000 en test de unidad a 12500
durante operación).
Calidad de SoftwareCalidad de Software
• Supongamos que recibimos un producto de software en tiempo, acorde con el presupuesto, y que desempeña sus funciones correcta y eficientemente
– ¿Podemos decir que estaremos satisfechos con él?
Calidad de SoftwareCalidad de Software
• La respuesta puede ser No– El producto de software puede ser
• difícil de entender y modificar• difícil de utilizar• innecesariamente dependiente de un hardware o difícil de integrar
con otros programas
Definiciones de CalidadDefiniciones de Calidad
• Aptitud para el uso• Ausencia de defectos• Satisfacción de los requerimientos
• Triste conclusión: – ¡En general, los sistemas de software no cumplen con ninguna definición
de calidad!
Atributos de calidadAtributos de calidad
• Corrección• Confiabilidad• Integridad• Usabilidad• Eficiencia• Mantenibilidad• Flexibilidad• Testeabilidad
• Interoperabilidad• Reusabilidad• Portabilidad
Calidad externaCalidad externa
• La calidad externa es aquélla que puede ser vista por los usuarios y que tradicionalmente es testeada
• Se observa – caídas del sistema – corrupción de datos– problemas de performance– comportamientos inesperados
• Es un síntoma– El problema se halla en la calidad interna
Calidad internaCalidad interna
• La calidad interna es la parte oculta del iceberg– estructura del programa– prácticas de programación– esfuerzo de mantenimiento– experiencia en el dominio
• Consecuencias– pérdida de tiempo en el desarrollo– arreglos que suelen introducir nuevos problemas– necesidad de un lento retesteo
• Las deficiencias en calidad interna resultan en altos costos de mantenimiento
Calidad de proceso vs calidad de productoCalidad de proceso vs calidad de producto
• En la industria manufacturera, hay evidencia de que la madurez del proceso está positivamente asociada con la calidad del producto
• Y en el software?– Los defectos se generan en el ciclo de vida del software
• La madurez en el proceso ayuda a disminuir la introducción de esos defectos
• Los defectos no se propagan a otras etapas• Entonces mejora la calidad
Aseguramiento de la CalidadAseguramiento de la Calidad
• Patrón de acciones planeado y sistemático, necesario para proveer un nivel de confianza adecuado en que el ítem o producto está acorde a los requerimientos técnicos establecidos
• Software Quality Assurance (SQA): evaluación de la calidad y adherencia a los estándares del producto, procesos y procedimientos. Incluye el proceso de asegurar que los estándares y procedimientos son definidos y cumplidos a lo largo del ciclo de software
– http://satc.gsfc.nasa.gov/assure/agbsec3.txt
SQASQA
• SQA no es responsable de la calidad• La responsabilidad de la calidad recae en el proyecto• El rol de SQA es monitorear la forma en que se cumplen las responsabilidades de
calidad en el proyecto
Control de la CalidadControl de la Calidad
• Conjunto de procedimientos cuyo objeto es procedimientos cuyo objeto es medir el productomedir el producto a fin de asegurar que satisface los requerimientos y especificaciones sobre el mismo
• Ej: testing
Para tener en cuenta...Para tener en cuenta...
Una vez definidos los requerimientos de calidad, tengo que tener en cuenta que:– Las calidad no puede “inyectarse” al final.– La calidad del producto depende de tareas realizadas durante todo el
proceso.– Detectar errores en forma temprana ahorra esfuerzos, tiempo, recursos.
Objetivos de QAObjetivos de QA
• Dar visibilidad al Management sobre la ejecución del proceso de desarrollo• Asegurar el cumplimiento del proceso definido• A través de las revisiones, ayudar a “poner la calidad” en los productos• Reducir riesgos
La calidad a lo largo del ciclo de vida de un sistemaLa calidad a lo largo del ciclo de vida de un sistema
• Una de las mayores dificultades que enfrentan las organizaciones después de completar un proyecto es que el sistema no cumple con las especificaciones del usuario
• En cada etapa del ciclo de vida del sistema deben incorporarse chequeos de calidad
Calidad en RequerimientosCalidad en Requerimientos
Requerimiento ambiguo: Las páginas deben cargar rápido
Se identifica la prioridad de cada requerimiento
Los requerimientos no tienen prioridad
Requerimiento no ambiguo: El tiempo de carga de las páginas no debe ser mayor a 10 segundos
Calidad en RequerimientosCalidad en Requerimientos
• Entender lo solicitado– Expresarlo adecuadamente– Cuantificar
• Administrar los requerimientos• Administrar los cambios en los requerimientos• Definir un alcance razonable • Documentar• Obtener un acuerdo• Validar
Calidad en RequerimientosCalidad en Requerimientos
• Una etapa de requerimientos, también debe identificar restricciones• Al agregar un requerimiento, se debe pensar cómo se lo va a testear• Se debe definir el impacto en sistemas• Identificar contactos y responsables de los grupos involucrados
Atributos de calidad de los requerimientosAtributos de calidad de los requerimientos
• Distintas organizaciones toman distintos atributos– Trazabilidad– Consistencia– Correctitud– Completitud– Verificabilidad– Comprensión– No ambigüedad– Volatilidad– Modificabilidad– Testeabilidad
Calidad en el DiseñoCalidad en el Diseño
• Diseñe para cambiar mañana (design for change, D. Parnas)• Diseñe para que nadie mire lo que hay adentro (information hiding, D. Parnas)
– Permite que los cambios se realicen en forma confiable con esfuerzo limitado
• Diseñe para que (el producto) sea coherente y asimilable• Haga un diseño simple
– Utilizar la abstracción (descripción simplificada que permite enfatizar ciertos detalles respecto de otros, y se independiza de la implementación)
Calidad en el diseño - EjemploCalidad en el diseño - Ejemplo
• Principios de calidad de diseño en OO (Coad and Yourdon)– Bajo acoplamiento– Alta cohesión– Claridad del diseño– Las especializaciones deben ser tales– Mantener los objetos y las clases simples
Calidad en la ProgramaciónCalidad en la Programación
Las variables no se inicializan
Toda variable está inicializada
No existen comentarios en el código
Cada procedimiento tiene una pequeña descripción de su funcionalidad. Existen comentarios para cada modificación realizada luego de la implementación inicial
Las variables se designan con un carácter
Las variables se designan con nombres alusivos a su propósito
Calidad en la ProgramaciónCalidad en la Programación
• Use herramientas– Ej: chequeadores de sintaxis HTML
• Use estándares– Nomenclatura (variables, funciones, procedimientos, etc)– Información obligatoria en los comentarios de modificaciones del código– Declaración e inicialización de variables– Escritura de condicionales
• Use esqueletos de programas• Capacite a los programadores• Evalúe a los programadores que contrata
Calidad en el TestingCalidad en el Testing
• En la siguiente parte de la charla..
Calidad en las ImplementacionesCalidad en las Implementaciones
Los cortes de servicio son frecuentes e inesperados, dado que las implementaciones no son planificadas
Los cortes de servicio se realizan una vez a la semana, en el horario de menos uso de la aplicación, el cual es conocido por todos los usuarios
Al momento de instalar la aplicación en producción, se detecta que el servidor no tiene la configuración necesaria
Se establece la lista de requerimientos para el ambiente donde se instala la aplicación, y se planifica la configuración del mismo con tiempo suficiente para poder realizar pruebas previo a la implementación
Calidad en las ImplementacionesCalidad en las Implementaciones
• Planifique la instalación– Cuáles son los requerimientos técnicos?– Cuáles son los grupos afectados?– Cuánto tiempo es necesario detener el sistema?– Cuáles son los procedimientos de la organización para las instalaciones en
ambientes productivos?• Obtenga el acuerdo formal de los afectados• Prevea la vuelta atrás
– Backup– Prueba de restauración de backups
Calidad en las ImplementacionesCalidad en las Implementaciones
• Defina tareas de seguimiento• Defina adecuadamente los mecanismos de soporte• Otras tareas relacionadas con las implementaciones
– Configuración inicial– Capacitación de usuarios– Comunicación
Calidad en la PlanificaciónCalidad en la Planificación
Los problemas se suceden de forma inesperada. Se insume mucho tiempo “apagando incendios”
Se analizan los riesgos del proyecto, se establecen estrategias para evitarlos o mitigarlos. En general no hay sorpresas
Las tareas se realizan a demanda, con los recursos disponibles en el momento
Se estiman los tiempos de cada tarea, se determina la asignación de los recursos y se administran los tiempos para maximizar la ocupación de los mismos y minimizar los plazos de entrega Se establecen fechas de
compromiso que nunca se cumplen
Ídem anterior
Calidad en la PlanificaciónCalidad en la Planificación
• Algunos de sus puntos– Tareas– Recursos afectados– Responsabilidades– Necesidades de capacitación– Entregables– Estimaciones
• Procedimientos• Datos históricos
– Administrar riesgos– Administrar configuraciones– Seguimiento
Paradigma del SEI de la Administración de Riesgos
Calidad en la PlanificaciónCalidad en la Planificación
• El plan debe ser acorde con los requerimientos• Tener control del proyecto
– Las tareas y actividades se revisan periódicamente– Se replanifica cuando es necesario– Se conocen las responsabilidades
Paradigma del SEIParadigma del SEI
• Identificar– Antes de que se conviertan en problemas– Existen cuestionarios para facilitar esta tarea
• Analizar– Convertir la información de riesgos en información para la toma de
decisiones• Planificar
– Transformar la información de riesgos en decisiones y acciones
Paradigma del SEIParadigma del SEI
• Distintas formas– Mitigar el impacto– Evitar el riesgo– Aceptar el riesgo– Estudiar el riesgo
• Seguir– Chequear estado de riesgos y acciones– Métricas
• Controlar– Corregir desviaciones sobre las acciones planificadas
• Comunicar– A niveles y entidades apropiados
Administración de ConfiguracionesAdministración de Configuraciones
Se administran versiones y se tiene control de las mismas
Existen ambientes de desarrollo, pruebas y producción, sin embargo, no se sabe qué diferencias existe entre el código de cada uno de ellos
Se documentan las versiones que se impactan en cada ambiente. El ambiente de producción sólo contiene versiones de software debidamente probadas, el ambiente de test sólo contiene versiones cuyo desarrollo se ha finalizado y se solicita su prueba
Se pierden modificaciones realizadas en el código
Administración de las ConfiguracionesAdministración de las Configuraciones
• Definir ítems de configuración y la granularidad del manejo• Establecer el versionado de los ítems• Permitir el manejo de versiones, apoyado con herramientas• Auditar la configuración
Plan de QAPlan de QA
• Propósito: especificar y documentar las actividades de QA para un proyecto específico
• No puede evolucionar en forma independiente al proyecto• Importante: Realizar el seguimiento del plan • Elementos que no deben faltar:
– Capacitación y Planificación– Auditorias, Inspecciones y Revisiones– Estándares y Procedimientos– Métricas
Plan de QA - GuidelinesPlan de QA - Guidelines
• Realizarlo junto con el plan del proyecto• Establecer el momento adecuado para las actividades (ej: el estándar de diseño
debe estar listo antes de la etapa de diseño del proyecto)• Asegurar la disponibilidad de las herramientas antes que las mismas sean
requeridas en el proyecto
Plan de QA – Ejemplo (IEEE 730-1998)Plan de QA – Ejemplo (IEEE 730-1998)
• Debe contener al menos las siguientes secciones– Propósito– Documentos de referencia– Management– Documentación– Estándares, prácticas, convenciones y métricas– Revisiones y auditorías– Tests– Reporte de problemas y acciones correctivas
Plan de QA – Ejemplo (IEEE 730-1998)Plan de QA – Ejemplo (IEEE 730-1998)
– Herramientas, técnicas y metodologías– Control de código– Control de medios– Control de proveedores– Registros, mantenimiento y resguardo– Capacitación– Administración de riesgos
Por dónde empezar?Por dónde empezar?
• Todo programa de calidad en un área de sistemas debe empezar poniendo orden en la entrada de requerimientos
• Es difícil hablar de calidad en una organización en la que la gente trabaja en 20 cosas distintas a la vez
• El próximo paso es establecer una organización para QA, aunque sea informal• Los ítems a controlar se deben ir agregando gradualmente
Por dónde empezar?Por dónde empezar?
• El proceso es simple:– 1 - Definir– 2 - Capacitar– 3 - Implementar “control” (segunda parte dela capacitación)– 4 - Revisar y mejorar definiciones– 5 - Goto 1
Para tener en cuenta...Para tener en cuenta...
• Las tareas de control de calidad deben realizarse durante todo el desarrollo del proyecto
• El Administrador de Calidad debe trabajar para prevenir defectos más que detectar defectos
• Las actividades de QA de un proyecto deben ser llevadas a cabo por personal independiente del proyecto.
• La importancia de las personas en cualquier programa de calidad, y en el software en particular, es fundamental. Ninguna herramienta o control pueden garantizar o mejorar la calidad por sí solas
La importancia de las medicionesLa importancia de las mediciones
• ¿Qué prefiere que le digan:– Hace un poco de frío, ó– La sensación térmica es de 5 grados bajo cero?
• La calidad se enfoca en el grado de corrección con que se implementan las necesidades del usuario
• La calidad de esa implementación debe ser cuantificable, de acuerdo a criterios que puedan medirse
• Las métricas intervienen en cuanto a que se aplican para evaluar determinados atributos o factores de calidad
La importancia de las medicionesLa importancia de las mediciones
• Permiten – Tomar acciones que determinan una mejor calidad de los productos– Evitar potenciales riesgos– Tener información histórica para mejorar los proyectos futuros
• Aprender– Tomar mejores decisiones– Determinar si se cumplen los objetivos
ConsideracionesConsideraciones
• Permiten obtener datos objetivos sobre el proyecto, el proceso y la organización• Desastrosas si se usan con motivos políticos o de evaluación• Lamentablemente, cada métrica ofrece una única dimensión• Deben combinarse para cobrar sentido
Ejemplos de métricasEjemplos de métricas
• Conviene definir métricas básicas antes de comenzar una iniciativa de calidad• Mostrar el caos (otros ejemplos):
– Cantidad de requerimientos por canal de entrada– Cantidad de fallas en producción y su tiempo de resolución– Cantidad de fallas de un sistema instalado
Calidad - ConclusionesCalidad - Conclusiones
• Existen distintas definiciones de calidad – Encontrar la propia
• Es importante definir un plan de calidad adecuado– Empezar por los requerimientos
• Las actividades de calidad acompañan al ciclo de vida del software• Prevenir los problemas• Detectar en etapas tempranas• La labor de calidad es “en conjunto” y en colaboración con las demás personas y
actividades involucradas en el proyecto
Testing y RevisionesTesting y Revisiones
TemarioTemario
• Testing– Definiciones– Tipos de test– El proceso– Técnicas de derivación de casos de test– Tips– Documentación– Estimaciones
• Inspecciones de código y revisiones• Conclusiones
DefinicionesDefiniciones
Definiciones - TestingDefiniciones - Testing
• Según IEEE standards 1999. “El testing de software es el proceso de analizar un producto de software para detectar las diferencias entre el comportamiento real con el pedido, y para evaluar las funcionalidades y características no funcionales del software”
• Testear es ejecutar el software
Por qué hay que testear?Por qué hay que testear?
• Mejorar la calidad del producto final• Encontrar los errores antes que el usuario
• Cuanto antes se inicie mejor– El sólo hecho de definir los casos de prueba ayuda a encontrar problemas
El Proceso del TestingEl Proceso del Testing
• Toda actividad de testing debe finalizar con una comparación cuidadosa
Componentea Testear
Componentea Testear
Datos de Test
Datos de Test
ComportamientoReal
ComportamientoEsperado
ResultadoEstrategiaEstrategia ComparaciónComparación
OráculoOráculo
TestTest
El gran axioma del testingEl gran axioma del testing
• Axioma: “El Testing sólo puede mostrar la presencia de defectos, no su ausencia” (Dijkstra)
• Corolario: Un test sólo es exitoso si encuentra errores
Conceptos: Casos vs datos de testConceptos: Casos vs datos de test
• Casos de test: descripciones de condiciones o situaciones a testear.– Según IEEE standards 1999: “Es un conjunto de condiciones de ejecución
sobre los valores de entrada y resultados esperados generadas para satisfacer un objetivo particular”
– Crear casos de test es un proceso creativo.• Datos de test: lotes de datos necesarios para ejecutar un caso de test.
– Crear datos de test es muy laborioso... Y poco creativo.
¿Cuál es cuál?¿Cuál es cuál?
• Cuenta origen = Cuenta destino monto transferencia > 0 monto transferencia < saldo
• Cuenta origen: 6055-81434-015 • Cuenta destino: 6055-81434-019• Monto transferencia: $125.000
Casos de testCasos de test
• Una de las mayores dificultades es encontrar un conjunto de tests adecuado: – suficientemente grande para abarcar el dominio y maximizar la
probabilidad de encontrar errores– suficientemente pequeño para poder ejecutar el proceso de testing con
cada elemento del conjunto y minimizar el costo del testing
PreguntaPregunta
• ¿Se puede probar un programa ingresando todos los valores posibles?
Campo de 9 dígitos decimales 387420489 posibilidades Si tardo 2 segundos en la ejecución, tomaría 2242 días ejecutar el test
Los datos de testLos datos de test
• Los datos de test deben ser representativos de lo que voy a probar– Si la aplicación es para registrar costos en Chile, un valor de 15.000.000
es una situación normal– Si un proceso tiene que recorrer un archivo que puede tener cientos de
registros, mi prueba siempre es con un archivo de 1 registro, no voy a asegurar el procesamiento normal
• Deber permitir la ejercitación de toda la funcionalidad– Si estoy probando la emisión de una consulta que genera una tabla 6
columnas y 12 filas y sólo utilizo datos que reflejen valores en 1 celda, no es suficiente
Tipos de TestTipos de Test
Tipos (o niveles) de testTipos (o niveles) de test
• De Unidad• De Integración• De Sistema• De Aceptación del Usuario• De Regresión• De Cualidades de Calidad
Test de unidadTest de unidad
• Su objetivo es asegurar que funcione correctamente una unidad de códigopequeña, claramente definida.
• Según de la tecnología puedeaplicarse programas, rutinas,o lo que sea la unidad “natural”
• En general lo hace eldesarrollador
– Ejercitar los caminos lógicos– Ejecutar según las variaciones de datos– Manejo de errores
Test de integraciónTest de integración
• “Testing en el cual los componentes de software, hardware o ambos se combinan y prueban para evaluar la interacción entre ellos” [IEEE 90].
• Su objetivo es asegurar que cuando las partes funcionan bien, también lo hace el conjunto
– El foco está en la integración de las unidades• Dicho de otro modo, que el todo no funciona peor que las partes• No hay que confundirlo con el test de sistema (testear un sistema
integrado)
Test de sistemaTest de sistema
• Su objetivo es asegurar que el sistema, como un todo, opera de acuerdo a lo esperado.
• Es un test del sistema completo, o de partes ya integradas del sistema.• Es en realidad como un test de unidad, pero la una unidad que ya no es
pequeña, sino que está formada por otras unidades ya integradas.
Test de aceptacióndel usuario (UAT)Test de aceptacióndel usuario (UAT)
• Tiene por objetivo asegurar que el sistema implementa adecuadamente los requerimientos definidos y aprobados por el usuario.
• Es una forma particular del testing del sistema.• Los casos de test están basados en los requerimientos.• Lo diseñan y ejecutan los usuarios.• Involucrar a los usuarios es clave en el proceso de testing.
Por cambiar un par de líneas no va a pasar nada...Yo me juego y catalogo sin probarlo...
(sus últimas palabras fueron)
Test de regresiónTest de regresión
• “Retesteo selectivo de un sistema o componente, para verificar que las modificaciones no causaron efectos inesperados y que el sistema o componente sigue cumpliendo con los requerimientos especificados” [IEEE 90].
• Tiene como objetivo asegurar que luego de un cambio no se han introducido errores en funcionalidades que no debían cambiar
• También llamado “de no impacto”• Necesito condiciones y datos de test “reusables”• Retestear todo, o seleccionar casos de regresión?
Test de regresión – Selección de casosTest de regresión – Selección de casos
• Incluir los casos que fallaron en el test anterior• Incluir casos que cubran la funcionalidad modificada• Incluir casos que correspondan a la parte no modificada, como métodos que
invoquen a los métodos modificados, o que usen las estructuras de datos modificadas
Testeando Cualidades de Calidad – Test de UsabilidadTesteando Cualidades de Calidad – Test de Usabilidad
• Tiene por objetivo asegurar la usabilidad de la aplicación– Los tiempos de respuesta son los esperados?– Se entiende cómo realizar cada operatoria en la aplicación?– Es sencillo aprender a utilizar la aplicación?
• Para ello es necesario conocer lo que los usuarios consideran “usable”
Testeando Cualidades de CalidadTesteando Cualidades de Calidad
• Confiabilidad– Seguir un camino operativo con apropiada carga en funcionalidades, para
cubrir lo máximo posible– El % de fallas se usa para computar la confiabilidad
• Performance– Construir escenarios de test que provean una certera medida del tiempo
requerido para dicho escenario
Testeando Cualidades de CalidadTesteando Cualidades de Calidad
• Extensibilidad– Construir casos de test para requerimientos que no formen parte de los
requerimientos actuales– Evaluar la respuesta a las situaciones hipotéticas
• Seguridad– Construir casos de test para acceder a las secciones del sistema que se
suponen seguras– En cada posible escenario utilizar privilegios apropiados e inapropiados
El ProcesoEl Proceso
Proceso canónicoProceso canónico
Estrategia Definición de casos
Ejecución Seguimiento
de incidentes
Áreas críticas
Alcance
Tipos de test
Ambientes
Comunicación
Cubrimiento
Completitud
Reuso
Priorización
Incidentes
Priorización
Clasificación
Estados
Re-priorización
Re-clasificación
Preparación de datos
Los casos de test - ValidaciónLos casos de test - Validación
• Con usuarios o expertos en el dominio– Para identificar errores y omisiones
• Con los desarrolladores– Clarifica la comprensión de los requerimientos por parte de los
desarrolladores– Asegura que el diseño y el código se ajustan a los requerimientos
Ejecución del testingEjecución del testing
• Manual– Funcional– Usabilidad– Compatibilidad (entre
browsers) - WEB– Contenidos - WEB
• Automático– Stress y volumen– De estructura (links, imágenes)
- WEB
• Tener en cuenta que el esfuerzo de automatizar los tests funcionales debe compensarse con la cantidad de veces que utilizaremos los scripts (se calculan necesarias más de 8 regresiones)
Equipo de trabajoEquipo de trabajo
• Líder de proyecto– Definición de la estrategia de testing– Elaboración del plan– Control del proyecto– Interacción con el cliente
• Tester Diseñador– Definición de los casos de prueba– Poblado de las condiciones de prueba
• Tester ejecutor– Ejecución de los casos de prueba– Detección y registro de incidentes
Desarrollo70%
Testing30%
Testing manual - TiempoTesting manual - Tiempo
• Según nuestra experiencia
Otros15%
Estrategia5%
Definición30%
Ejecución50%
TipsTips
Algunas responsabilidades frente a un proyecto de testingAlgunas responsabilidades frente a un proyecto de testing
• Conocer y entender lo que hay que probar• Entender qué es importante para el usuario de la aplicación
– En un sistema referente a instrumentos médicos, lo más importante será que se ajuste exactamente a la definición, y la seguridad de que los datos mostrados son correctos
– En un software de impresión, lo importante será la usabilidad y la compatibilidad hacia atrás
Algunas responsabilidades frente a un proyecto de testingAlgunas responsabilidades frente a un proyecto de testing
• Conocer las prioridades• Conocer las fechas requeridas• Conocer el alcance de la prueba
– Lo requerido– Lo real (completitud)
• Conocer el estado de avance del test• Ordenar la corrección de incidentes
Claves para definir los casos de testClaves para definir los casos de test
• Entender la funcionalidad• Escribir el resultado esperado• No asumir que lo que se va a probar está libre de errores• Identificar todos los datos de inputs y de output• Identificar particularidades o comportamientos especiales• Probar los casos válidos, Y los inválidos• Combinar técnicas• Cuestionar
Algunas claves para el testing funcionalAlgunas claves para el testing funcional
• Testing independiente• El que desarrolla no prueba
– Si el requerimiento no fue entendido, no voy a descubrirlo yo mismo• Mayor experiencia y concentración• Nadie está motivado para encontrar sus propios errores
DocumentaciónDocumentación
Testing manual - DocumentaciónTesting manual - Documentación
• Beneficios de documentar las pruebas– Mejora nuestras estimaciones futuras– Mejora la curva de aprendizaje de los testers juniors– Mejores decisiones
• Salida a producción• Elección de proveedores• Interno o tercerización?
– Permite identificar problemas comunes– Reúso de casos
Testing manual - DocumentaciónTesting manual - Documentación
• Qué documentar– Estrategia de prueba– Casos de prueba
• Estoy cubriendo toda la funcionalidad?
• Estoy contemplando las situaciones más comunes de la funcionalidad?
• Cuánto llevo probado?• Manejar estados• Manejar prioridades
– Problemas• Manejar estados• Manejar prioridades• Detallar los datos de
prueba y los pasos para poder reproducirlo
– Ejecución: Tablero de control• #casos ejecutados por
criticidad• #incidentes por estado y
criticidad
Documentación – Plan de TestDocumentación – Plan de Test
– ¿Qué se prueba y qué no?– Estrategia
• Herramientas• Métricas• Configuraciones a testear• Regresión
– ¿Cuándo termina el test?– ¿Cuáles serán los Entregables?– Requerimientos de entorno
• Características de hardware, datos de test, versiones de software, seguridad, comunicaciones
– Responsabilidades
Documentación - Casos de testDocumentación - Casos de test
• Documentación especificando inputs, condiciones de ejecución y resultados esperados para un item de test
• Componentes– Identificador– Funcionalidad a testear– Descripción– Pasos– Datos– Resultado esperado– Prioridad– Tipo– Estado
Documentación - IncidentesDocumentación - Incidentes
• El reporte de un incidente debe proveer suficiente información para permitir que otras personas entiendan cómo se descubrió y cómo reproducirlo
• Componentes • Procedimiento utilizado para descubrir el incidente• Información sobre el caso de test (que permita reproducirlo)• Registro de la ejecución del caso de test (logs, pantallas, etc)• Severidad• Prioridad
Documentación - ChecklistsDocumentación - Checklists
• Checklists– Pueden ser utilizados por testers, desarrolladores y usuarios– Ahorran tiempo de testing– Fáciles de entender y mantener– Se crean a partir de problemas encontrados
• Ejemplos– Instalación– Verificación inicial de la versión a probar– Validación de página– Verificación de las puesta en producción– Estándares
Checklist - EjemploChecklist - Ejemplo
Para definir casos de test Identificarlos inputs
Válidos Inválidos Bordes
Identificar los mensajes de error Identificar los outputs
Válidos Errores
Chequear generación duplicados Chequear eliminaciones de datos Chequear actualizaciones de datos Identificar situaciones comunes de error (basándose en los encontrados en
otras situaciones) Identificar valores default Utilizar escenarios
EstimacionesEstimaciones
Estimaciones – Una formaEstimaciones – Una forma
• Registrar las experiencias y estimar luego en base a ellas– Dividir el test en módulos– Clasificar los módulos según su complejidad– Estimar la cantidad de casos por módulo– Multiplicar por el tiempo que se insume según las propias métricas
Ejemplo de información a registarEjemplo de información a registar
Gesta 2004Indicadores del Proyecto Multimoneda (America)Cantidad de Funcionalidades 27Promedio de Casos definidos por Funcionalidad 10.11Promedio de Horas insumidas por Funcionalidad 10.78Entidades reportadas por Funcionalidad 10.44Entidades reportadas por Caso ejecutado 1.09% de completitud en la definición 74.07%% de completitud en la ejecución 94.51%
Cantidad de Casos Alta Media Baja TotalCantidad de Casos de prueba definidos 207 63 3 273Cantidad de Casos de prueba ejecutados 204 51 3 258% de Casos de prueba ejecutados 98% 80% 100% 95%
Cantidad de Entidades Alta Media Baja Invalidante TotalCantidad de Entidades reportadas 100 81 94 7 282Cantidad de Entidades abiertas 11 2 2 0 15% de Entidades abiertos 11% 2% 2% 0% 5%
Distribución de Dedicaciones Total %Definición de casos 53.00 18.21Ejecución de casos 188.00 64.60Seguimiento de Incidentes 50.00 17.18TOTAL DE HORAS 291.00 100.00
Estimaciones – Otras técnicasEstimaciones – Otras técnicas
• Identificar tareas• Estimar la duración de cada tarea en equipo
– Oráculo de Delphi– Three Point– Wideband
• Ordenar las tareas en el tiempo, identificando las dependencias
Revisiones de documentaciónRevisiones de documentación
• Permiten detectar problemas antes de la codificación• Tipos de problemas que se encuentran
– Indefiniciones– Inconsistencias
• Qué revisar– Requerimientos– Diseños– Casos de pruebas– Planes de proyecto
Revisiones de documentaciónRevisiones de documentación
• Participantes– Depende del documento a analizar– Analistas, desarrolladores, gente de QA, usuarios
• Mecánica– Sesiones individuales de revisión del documento, luego reuniones para
discutir las observaciones• Ej: revisión de contenidos antes de cargarse en el site
ConclusionesConclusiones
Testing y revisiones - ConclusionesTesting y revisiones - Conclusiones
• Testeamos para mejorar la calidad del producto final• Testeamos para encontrar los errores antes que el usuario• No podemos asegurar la ausencia de errores• Existen distintas técnicas y herramientas tanto para definir la prueba, como para
llevar adelante su ejecución• La documentación es fundamental, desde el plan de pruebas, hasta los
incidentes• También existen otras formas de contribuir a la calidad del software: revisiones
de código y de documentación
Para mayor informaciónPara mayor información
Visite nuestro web site:
www.helpnet.cl
Viña del Mar
9 Norte, ½ Oriente Oficina 302. Viña del Mar.Fono: (56-32) 288 17 43
Email: [email protected]
Santiago de Chile
Torres Boonen, 805. Providencia.Fono: (56-2) 658 14 40 Fax: (56-2) 658 14 43
Email: [email protected]