Aseguramiento de Calidad

Agosto de 2008

Temario
Control y Aseguramiento de la Calidad
Nmeros y ejemplos
Definicin de calidad
Aseguramiento y control de calidad
La calidad en el ciclo de vida del software
El plan de calidad
Mtricas

Temario
Testing
Definiciones
Tipos de test
El proceso
Tcnicas de derivacin de casos de test
Tips
Documentacin
Estimaciones
Inspecciones de cdigo y revisiones
Conclusiones

Control y Aseguramiento de la Calidad

Motivacin
Preguntas
Cul es el impacto de un error detectado por un usuario, en la operacin
de la aplicacin?
Cul es el costo para el negocio?
Cul es el costo de solucionar el problema en el software?

El costo de los errores

Error en proceso de facturacin, descubierto por un cliente de la compaa
Un milln y medio de facturas reimpresas (costos de impresin 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 cada de un website de inversiones durante dos das
Prdida 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 calidad

Algunos nmeros sobre los defectos

50 % de los defectos se introducen durante la programacin.
Hoy, no ms 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 lneas
de cdigo (no comentadas).
80% de los defectos de prog. se encuentran en el 20% de los mdulos de
programacin. Muchos se ven durante la integracin.
El costo de reparacin crece con el tiempo (1000 en test de unidad a 12500
durante operacin).

Calidad de Software
Supongamos que recibimos un producto de software en tiempo, acorde con el
presupuesto, y que desempea sus funciones correcta y eficientemente
Podemos decir que estaremos satisfechos con l?

Calidad de Software
La respuesta puede ser No
El producto de software puede ser
difcil de entender y modificar
difcil de utilizar
innecesariamente dependiente de un hardware o difcil de integrar
con otros programas

Definiciones de Calidad
Aptitud para el uso
Ausencia de defectos
Satisfaccin de los requerimientos
Triste conclusin:
En general, los sistemas de software no cumplen con ninguna definicin
de calidad!

Atributos de calidad

Correccin
Confiabilidad
Integridad
Usabilidad
Eficiencia
Mantenibilidad
Flexibilidad
Testeabilidad

Interoperabilidad
Reusabilidad
Portabilidad

Calidad externa
La calidad externa es aqulla que puede ser vista por los usuarios y que
tradicionalmente es testeada
Se observa
cadas del sistema
corrupcin de datos
problemas de performance
comportamientos inesperados
Es un sntoma
El problema se halla en la calidad interna

Calidad interna
La calidad interna es la parte oculta del iceberg
estructura del programa
prcticas de programacin
esfuerzo de mantenimiento
experiencia en el dominio
Consecuencias
prdida 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 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 introduccin de esos
defectos
Los defectos no se propagan a otras etapas
Entonces mejora la calidad

Aseguramiento de la Calidad
Patrn de acciones planeado y sistemtico, necesario para proveer un nivel de
confianza adecuado en que el tem o producto est acorde a los requerimientos
tcnicos establecidos
Software Quality Assurance (SQA): evaluacin de la calidad y adherencia a
los estndares del producto, procesos y procedimientos. Incluye el proceso de
asegurar que los estndares y procedimientos son definidos y cumplidos a lo
largo del ciclo de software
http://satc.gsfc.nasa.gov/assure/agbsec3.txt

SQA
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 Calidad
Conjunto de procedimientos cuyo objeto es medir el producto a fin de
asegurar que satisface los requerimientos y especificaciones sobre el mismo
Ej: testing

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 QA

Dar visibilidad al Management sobre la ejecucin del proceso de desarrollo

Asegurar el cumplimiento del proceso definido
A travs de las revisiones, ayudar a poner la calidad en los productos
Reducir riesgos

La calidad a lo largo del ciclo de vida de un

sistema
Una de las mayores dificultades que enfrentan las organizaciones despus 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 Requerimientos
Requerimiento
ambiguo: Las pginas
deben cargar rpido

Requerimiento no ambiguo:
El tiempo de carga de las
pginas no debe ser mayor
a 10 segundos

Los requerimientos no
tienen prioridad

Se identifica la prioridad
de cada requerimiento

Calidad 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 Requerimientos

Una etapa de requerimientos, tambin debe identificar restricciones

Al agregar un requerimiento, se debe pensar cmo 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 requerimientos

Distintas organizaciones toman distintos atributos
Trazabilidad
Consistencia
Correctitud
Completitud
Verificabilidad
Comprensin
No ambigedad
Volatilidad
Modificabilidad
Testeabilidad

Calidad en el Diseo
Disee para cambiar maana (design for change, D. Parnas)
Disee para que nadie mire lo que hay adentro (information hiding, D. Parnas)
Permite que los cambios se realicen en forma confiable con esfuerzo
limitado
Disee para que (el producto) sea coherente y asimilable
Haga un diseo simple
Utilizar la abstraccin (descripcin simplificada que permite enfatizar
ciertos detalles respecto de otros, y se independiza de la implementacin)

Calidad en el diseo - Ejemplo

Principios de calidad de diseo en OO (Coad and Yourdon)
Bajo acoplamiento
Alta cohesin
Claridad del diseo
Las especializaciones deben ser tales
Mantener los objetos y las clases simples

Calidad en la Programacin
Las variables no se
inicializan
Las variables se designan
con un carcter
No existen comentarios en
el cdigo

Toda variable est

inicializada
Las variables se designan
con nombres alusivos a su
propsito
Cada procedimiento tiene
una pequea descripcin
de su funcionalidad.
Existen comentarios para
cada modificacin realizada
luego de la implementacin
inicial

Calidad en la Programacin
Use herramientas
Ej: chequeadores de sintaxis HTML
Use estndares
Nomenclatura (variables, funciones, procedimientos, etc)
Informacin obligatoria en los comentarios de modificaciones del cdigo
Declaracin e inicializacin de variables
Escritura de condicionales
Use esqueletos de programas
Capacite a los programadores
Evale a los programadores que contrata

Calidad en el Testing
En la siguiente parte de la charla..

Calidad en las Implementaciones

Los cortes de servicio son
frecuentes e inesperados,
dado que las
implementaciones no son
planificadas
Al momento de instalar la
aplicacin en produccin,
se detecta que el servidor
no tiene la configuracin
necesaria

Los cortes de servicio se

realizan una vez a la
semana, en el horario de
menos uso de la aplicacin,
el cual es conocido por
todos los usuarios
Se establece la lista de
requerimientos para el
ambiente donde se instala
la aplicacin, y se planifica
la configuracin del mismo
con tiempo suficiente para
poder realizar pruebas
previo a la implementacin

Calidad en las Implementaciones

Planifique la instalacin
Cules son los requerimientos tcnicos?
Cules son los grupos afectados?
Cunto tiempo es necesario detener el sistema?
Cules son los procedimientos de la organizacin para las instalaciones en
ambientes productivos?
Obtenga el acuerdo formal de los afectados
Prevea la vuelta atrs
Backup
Prueba de restauracin de backups

Calidad en las Implementaciones

Defina tareas de seguimiento
Defina adecuadamente los mecanismos de soporte
Otras tareas relacionadas con las implementaciones
Configuracin inicial
Capacitacin de usuarios
Comunicacin

Calidad en la Planificacin
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
asignacin de los recursos
y se administran los
tiempos para maximizar la
ocupacin de los mismos y
minimizar los plazos de
entrega
dem anterior

Se establecen fechas de
compromiso que nunca se
cumplen

Calidad en la Planificacin
Algunos de sus puntos
Tareas
Recursos afectados
Responsabilidades
Necesidades de capacitacin
Entregables
Estimaciones
Procedimientos
Datos histricos
Administrar riesgos
Administrar configuraciones
Seguimiento

Paradigma del SEI de la

Administracin de Riesgos

Calidad en la Planificacin
El plan debe ser acorde con los requerimientos
Tener control del proyecto
Las tareas y actividades se revisan peridicamente
Se replanifica cuando es necesario
Se conocen las responsabilidades

Paradigma del SEI

Identificar
Antes de que se conviertan en problemas
Existen cuestionarios para facilitar esta tarea
Analizar
Convertir la informacin de riesgos en informacin para la toma de
decisiones
Planificar
Transformar la informacin de riesgos en decisiones y acciones

Paradigma del SEI

Distintas formas
Mitigar el impacto
Evitar el riesgo
Aceptar el riesgo
Estudiar el riesgo
Seguir
Chequear estado de riesgos y acciones
Mtricas
Controlar
Corregir desviaciones sobre las acciones planificadas
Comunicar
A niveles y entidades apropiados

Administracin de Configuraciones
Se pierden modificaciones
realizadas en el cdigo

Se administran versiones y
se tiene control de las
mismas

Existen ambientes de
desarrollo, pruebas y
produccin, sin embargo,
no se sabe qu diferencias
existe entre el cdigo de
cada uno de ellos

Se documentan las
versiones que se impactan
en cada ambiente. El
ambiente de produccin
slo contiene versiones de
software debidamente
probadas, el ambiente de
test slo contiene
versiones cuyo desarrollo
se ha finalizado y se
solicita su prueba

Administracin de las Configuraciones

Definir tems de configuracin y la granularidad del manejo

Establecer el versionado de los tems
Permitir el manejo de versiones, apoyado con herramientas
Auditar la configuracin

Plan de QA
Propsito: especificar y documentar las actividades de QA para un proyecto
especfico
No puede evolucionar en forma independiente al proyecto
Importante: Realizar el seguimiento del plan
Elementos que no deben faltar:
Capacitacin y Planificacin
Auditorias, Inspecciones y Revisiones
Estndares y Procedimientos
Mtricas

Plan de QA - Guidelines
Realizarlo junto con el plan del proyecto
Establecer el momento adecuado para las actividades (ej: el estndar de diseo
debe estar listo antes de la etapa de diseo del proyecto)
Asegurar la disponibilidad de las herramientas antes que las mismas sean
requeridas en el proyecto

Plan de QA Ejemplo
(IEEE 730-1998)
Debe

contener al menos las siguientes secciones

Propsito
Documentos de referencia
Management
Documentacin
Estndares, prcticas, convenciones y mtricas
Revisiones y auditoras
Tests
Reporte de problemas y acciones correctivas

Plan de QA Ejemplo
(IEEE 730-1998)

Herramientas, tcnicas y metodologas

Control de cdigo
Control de medios
Control de proveedores
Registros, mantenimiento y resguardo
Capacitacin
Administracin de riesgos

Por dnde empezar?

Todo programa de calidad en un rea de sistemas debe empezar poniendo orden
en la entrada de requerimientos
Es difcil hablar de calidad en una organizacin en la que la gente trabaja en 20
cosas distintas a la vez
El prximo paso es establecer una organizacin para QA, aunque sea informal
Los tems a controlar se deben ir agregando gradualmente

Por dnde empezar?

El proceso es simple:
1 - Definir
2 - Capacitar
3 - Implementar control (segunda parte de
la capacitacin)
4 - Revisar y mejorar definiciones
5 - Goto 1

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 ms 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 mediciones

Qu prefiere que le digan:
Hace un poco de fro,
La sensacin trmica es de 5 grados bajo cero?
La calidad se enfoca en el grado de correccin con que se implementan las
necesidades del usuario
La calidad de esa implementacin debe ser cuantificable, de acuerdo a criterios
que puedan medirse
Las mtricas intervienen en cuanto a que se aplican para evaluar determinados
atributos o factores de calidad

La importancia de las mediciones

Permiten
Tomar acciones que determinan una mejor calidad de los productos
Evitar potenciales riesgos
Tener informacin histrica para mejorar los proyectos futuros
Aprender
Tomar mejores decisiones
Determinar si se cumplen los objetivos

Consideraciones

Permiten obtener datos objetivos sobre el proyecto, el proceso y la organizacin

Desastrosas si se usan con motivos polticos o de evaluacin
Lamentablemente, cada mtrica ofrece una nica dimensin
Deben combinarse para cobrar sentido

Ejemplos de mtricas
Conviene definir mtricas bsicas antes de comenzar una iniciativa de calidad
Mostrar el caos (otros ejemplos):
Cantidad de requerimientos por canal de entrada
Cantidad de fallas en produccin y su tiempo de resolucin
Cantidad de fallas de un sistema instalado

Calidad - 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 acompaan al ciclo de vida del software
Prevenir los problemas
Detectar en etapas tempranas
La labor de calidad es en conjunto y en colaboracin con las dems personas y
actividades involucradas en el proyecto

Testing y Revisiones

Temario
Testing
Definiciones
Tipos de test
El proceso
Tcnicas de derivacin de casos de test
Tips
Documentacin
Estimaciones
Inspecciones de cdigo y revisiones
Conclusiones

Definiciones

Definiciones - Testing
Segn 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 caractersticas no
funcionales del software
Testear es ejecutar el software

Por qu hay que testear?

Mejorar la calidad del producto final
Encontrar los errores antes que el usuario
Cuanto antes se inicie mejor
El slo hecho de definir los casos de prueba ayuda a encontrar problemas

El Proceso del Testing

Toda actividad de testing debe finalizar con una comparacin cuidadosa

Orculo
Orculo
Datos de Test
Componente
Componente
aaTestear
Testear

Estrategia
Estrategia

Comportamiento
Esperado

Comparacin
Comparacin

Datos de Test
Test
Test

Resultado

Comportamiento
Real

El gran axioma del testing

Axioma: El Testing slo puede mostrar la
presencia de defectos, no su ausencia (Dijkstra)
Corolario: Un test slo es exitoso si encuentra errores

Conceptos: Casos vs datos de test

Casos de test: descripciones de condiciones o situaciones a testear.
Segn IEEE standards 1999: Es un conjunto de condiciones de ejecucin
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.

Cul es cul?
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 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 pequeo para poder ejecutar el proceso de testing con
cada elemento del conjunto y minimizar el costo del testing

Pregunta
Se puede probar un programa ingresando todos los valores posibles?
Campo de 9 dgitos decimales
387420489 posibilidades
Si tardo 2 segundos en la ejecucin, tomara 2242 das ejecutar el
test

Los datos de test

Los datos de test deben ser representativos de lo que voy a probar
Si la aplicacin es para registrar costos en Chile, un valor de 15.000.000
es una situacin 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 ejercitacin de toda la funcionalidad
Si estoy probando la emisin de una consulta que genera una tabla 6
columnas y 12 filas y slo utilizo datos que reflejen valores en 1 celda, no
es suficiente

Tipos de Test

Tipos (o niveles) de test

De
De
De
De
De
De

Unidad
Integracin
Sistema
Aceptacin del Usuario
Regresin
Cualidades de Calidad

Test de unidad
Su objetivo es asegurar que funcione correctamente una unidad de cdigo
pequea, claramente definida.
Segn de la tecnologa puede
aplicarse programas, rutinas,
o lo que sea la unidad natural
En general lo hace el
desarrollador
Ejercitar los caminos lgicos
Ejecutar segn las variaciones de datos
Manejo de errores

Test de integracin
Testing en el cual los componentes de software, hardware o ambos se
combinan y prueban para evaluar la interaccin entre ellos [IEEE 90].
Su objetivo es asegurar que cuando las partes funcionan bien, tambin lo hace
el conjunto
El foco est en la integracin 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 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
pequea, sino que est formada por otras unidades ya integradas.

Test de aceptacin
del 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 estn basados en los requerimientos.
Lo disean y ejecutan los usuarios.
Involucrar a los usuarios es clave en el proceso de testing.

Test de regresin
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 deban cambiar
Tambin llamado de no impacto
Necesito condiciones y datos de test reusables
Retestear todo, o seleccionar casos de regresin?

(sus ltimas palabras fueron)

Por cambiar un par de lneas no va a pasar nada...
Yo me juego y catalogo sin probarlo...

Test de regresin Seleccin 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 mtodos que
invoquen a los mtodos modificados, o que usen las estructuras de datos
modificadas

Testeando Cualidades de Calidad Test de

Usabilidad
Tiene por objetivo asegurar la usabilidad de la aplicacin
Los tiempos de respuesta son los esperados?
Se entiende cmo realizar cada operatoria en la aplicacin?
Es sencillo aprender a utilizar la aplicacin?
Para ello es necesario conocer lo que los usuarios consideran usable

Testeando Cualidades de Calidad

Confiabilidad
Seguir un camino operativo con apropiada carga en funcionalidades, para
cubrir lo mximo 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 Calidad

Extensibilidad
Construir casos de test para requerimientos que no formen parte de los
requerimientos actuales
Evaluar la respuesta a las situaciones hipotticas
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 Proceso

Proceso cannico

Preparacin
de datos

Estrategia

Definicin
de casos

Ejecucin

Seguimiento
de
incidentes

reas crticas

Cubrimiento

Alcance

Incidentes

Estados

Completitud

Tipos de test

Priorizacin

Reuso

Ambientes

Clasificacin

Repriorizacin

Priorizacin

Comunicacin

Reclasificacin

Los casos de test - Validacin

Con usuarios o expertos en el dominio
Para identificar errores y omisiones
Con los desarrolladores
Clarifica la comprensin de los requerimientos por parte de los
desarrolladores
Asegura que el diseo y el cdigo se ajustan a los requerimientos

Ejecucin del testing

Manual
Funcional
Usabilidad
Compatibilidad (entre
browsers) - WEB
Contenidos - WEB

Automtico
Stress y volumen
De estructura (links,
imgenes) - 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 ms de 8
regresiones)

Equipo de trabajo
Lder de proyecto
Definicin de la estrategia de testing
Elaboracin del plan
Control del proyecto
Interaccin con el cliente
Tester Diseador
Definicin de los casos de prueba
Poblado de las condiciones de prueba
Tester ejecutor
Ejecucin de los casos de prueba
Deteccin y registro de incidentes

Testing manual - Tiempo

Segn nuestra experiencia
Otros
15%

Testing
30%

Estrategia
5%
Ejecucin
50%

Desarrollo
70%

Definicin
30%

Tips

Algunas responsabilidades frente a un

proyecto de testing
Conocer y entender lo que hay que probar
Entender qu es importante para el usuario de la aplicacin
En un sistema referente a instrumentos mdicos, lo ms importante ser
que se ajuste exactamente a la definicin, y la seguridad de que los datos
mostrados son correctos
En un software de impresin, lo importante ser la usabilidad y la
compatibilidad hacia atrs

Algunas 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 correccin de incidentes

Claves 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 vlidos, Y los invlidos
Combinar tcnicas
Cuestionar

Algunas 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 concentracin
Nadie est motivado para encontrar sus propios errores

Documentacin

Testing manual - Documentacin

Beneficios de documentar las pruebas
Mejora nuestras estimaciones futuras
Mejora la curva de aprendizaje de los testers juniors
Mejores decisiones
Salida a produccin
Eleccin de proveedores
Interno o tercerizacin?
Permite identificar problemas comunes
Reso de casos

Testing manual - Documentacin

Qu documentar
Estrategia de prueba
Casos de prueba
Estoy cubriendo toda la
funcionalidad?
Estoy contemplando las
situaciones ms comunes
de la funcionalidad?
Cunto llevo probado?
Manejar estados
Manejar prioridades

Problemas
Manejar estados
Manejar prioridades
Detallar los datos de
prueba y los pasos para
poder reproducirlo
Ejecucin: Tablero de control
#casos ejecutados por
criticidad
#incidentes por estado y
criticidad

Documentacin Plan de Test

Qu se prueba y qu no?
Estrategia
Herramientas
Mtricas
Configuraciones a testear
Regresin
Cundo termina el test?
Cules sern los Entregables?
Requerimientos de entorno
Caractersticas de hardware, datos de test, versiones de software,
seguridad, comunicaciones
Responsabilidades

Documentacin - Casos de test

Documentacin especificando inputs, condiciones de ejecucin y resultados
esperados para un item de test
Componentes
Identificador
Funcionalidad a testear
Descripcin
Pasos
Datos
Resultado esperado
Prioridad
Tipo
Estado

Documentacin - Incidentes
El reporte de un incidente debe proveer suficiente informacin para
permitir que otras personas entiendan cmo se descubri y cmo
reproducirlo
Componentes
Procedimiento utilizado para descubrir el incidente
Informacin sobre el caso de test (que permita reproducirlo)
Registro de la ejecucin del caso de test (logs, pantallas, etc)
Severidad
Prioridad

Documentacin - Checklists
Checklists
Pueden ser utilizados por testers, desarrolladores y usuarios
Ahorran tiempo de testing
Fciles de entender y mantener
Se crean a partir de problemas encontrados
Ejemplos
Instalacin
Verificacin inicial de la versin a probar
Validacin de pgina
Verificacin de las puesta en produccin
Estndares

Checklist - Ejemplo
Para definir casos de test
Identificarlos inputs
Vlidos
Invlidos
Bordes
Identificar los mensajes de error
Identificar los outputs
Vlidos
Errores
Chequear generacin duplicados
Chequear eliminaciones de datos
Chequear actualizaciones de datos
Identificar situaciones comunes de error (basndose en los encontrados
en otras situaciones)
Identificar valores default
Utilizar escenarios

Estimaciones

Estimaciones Una forma

Registrar las experiencias y estimar luego en base a ellas
Dividir el test en mdulos
Clasificar los mdulos segn su complejidad
Estimar la cantidad de casos por mdulo
Multiplicar por el tiempo que se insume segn las propias mtricas

Ejemplo de informacin a registar

Gesta 2004
Indicadores del Proyecto Multimoneda (America)
Cantidad de Funcionalidades
Promedio de Casos definidos por Funcionalidad
Promedio de Horas insumidas por Funcionalidad
Entidades reportadas por Funcionalidad
Entidades reportadas por Caso ejecutado
% de completitud en la definicin
% de completitud en la ejecucin

27
10.11
10.78
10.44
1.09
74.07%
94.51%

Cantidad de Casos
Cantidad de Casos de prueba definidos
Cantidad de Casos de prueba ejecutados
% de Casos de prueba ejecutados

Alta Media Baja

207
63
3
204
51
3
98%
80% 100%

Cantidad de Entidades
Cantidad de Entidades reportadas
Cantidad de Entidades abiertas
% de Entidades abiertos

Alta Media Baja Invalidante Total

100
81
94
7 282
11
2
2
0
15
11%
2%
2%
0%
5%

Distribucin de Dedicaciones
Definicin de casos
Ejecucin de casos
Seguimiento de Incidentes
TOTAL DE HORAS

Total
%
53.00 18.21
188.00 64.60
50.00 17.18
291.00 100.00

Total
273
258
95%

Estimaciones Otras tcnicas

Identificar tareas
Estimar la duracin de cada tarea en equipo
Orculo de Delphi
Three Point
Wideband
Ordenar las tareas en el tiempo, identificando las dependencias

Revisiones de documentacin
Permiten detectar problemas antes de la codificacin
Tipos de problemas que se encuentran
Indefiniciones
Inconsistencias
Qu revisar
Requerimientos
Diseos
Casos de pruebas
Planes de proyecto

Revisiones de documentacin
Participantes
Depende del documento a analizar
Analistas, desarrolladores, gente de QA, usuarios
Mecnica
Sesiones individuales de revisin del documento, luego reuniones para
discutir las observaciones
Ej: revisin de contenidos antes de cargarse en el site

Conclusiones

Testing 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 tcnicas y herramientas tanto para definir la prueba, como para
llevar adelante su ejecucin
La documentacin es fundamental, desde el plan de pruebas, hasta los
incidentes
Tambin existen otras formas de contribuir a la calidad del software: revisiones
de cdigo y de documentacin

Para mayor informacin

Visite nuestro web site:

www.helpnet.cl

Santiago de Chile

Via del Mar

Torres Boonen, 805. Providencia.

Fono: (56-2) 658 14 40
Fax: (56-2) 658 14 43
Email: pmo@helpnet.cl

9 Norte, Oriente Oficina 302. Via del Mar.

Fono: (56-32) 288 17 43
Email: pmo@helpnet.cl