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: pmo@helpnet.cl

Santiago de Chile

Torres Boonen, 805. Providencia.Fono: (56-2) 658 14 40 Fax: (56-2) 658 14 43

Email: pmo@helpnet.cl