2.6 Pruebas Funcionales.pdf

Modulo 6
Metodologías prácticas en pruebas de software

Los 3 pilares de la calidad
Funcionalidad
Seguridad
Rendimiento

Pilar Nº1
Pruebas Funcionales de software

Planeación
del Proyecto
Análisis y
Diseño
Desarrollo Pruebas
integración
Concepción Elaboración Construcción Transición
Procesos del cliente Procesos de Calidad Procesos de Soporte Fases del Desarrollo
Levantamiento
de requisitos
Despliegue
Planeación de
Pruebas
Diseño de Casos de Prueba
Pruebas del Sistema Pruebas de
Aceptación
Control y Seguimiento de Cambios y Defectos
Evaluación
Pruebas funcionales

WorkFlow del Proceso
Solicitud de pruebas nuevo proyecto
Planeación de pruebas y estimación
Aprobado?
Si
No
Plan de pruebas rechazado
Si el plan es rechazado, se negocian tiempos
y alcance con el Coordinador de Pruebas de
Q-Vision S.A.
Entrega del aplicativo
Ejecutar Ciclo de pruebas
Reportar defectos
Corrección de defectos
Diseñar nuevos casos de prueba
Se repite de 1 a N veces (siendo N la cantidad de ciclos)
Generar resumen de pruebas
Generar carta de certificación
Puesta en producción
Control y seguimiento
En caso de problemas en
producción el aplicativo será
devuelto a pruebas dependiendo
de los criterios de devolución.
Diseñar casos de prueba
Documentación
completa?
No
Si
Paso
SmokeTest?
Solución de problemas antes de pruebas
No
Gestión
del
proceso

Concepción inicial del
proyecto
Planeación de
pruebas
Plan de
pruebas
Cronograma del
proyecto
Cronograma de
pruebas
Documento de
requisitos
Modelo de
casos de uso
Diagramas de
actividad
(Opcional)
Diagrama de
clases
Diagrama de
distribución
Modelo y diccionario
de datos
Diagramas de
secuencia (Opcional)
Informe de
avance
Planeación de pruebas

ENTRADAS REQUERIDAS
„ Documento de Definición. (*)
„ Requerimientos del Usuario. (*)
„ Casos de Uso:
… Detalle. (*)
… Diagramas. (*)
„ Modelo Entidad Relación. (*)
„ Diagramas de Secuencia.
„ Diccionario de Datos. (*)
„ Prototipos. (*)
„ Diagramas de Flujo del proceso de
negocio.
„ Diagramas de Estados.
„ Reportes Pendientes de Versiones
Anteriores.
„ Reuniones Aclaratorias y
Capacitaciones.
DOCUMENTACIÓN RESULTANTE
„ Repositorio de Documentos:
… Documentación del proceso en blanco.
„ Plan de Pruebas.
… Retroalimentación y Revisión realizada
por el Comité de Cambios.
„ Cronograma de Actividades.
Los elementos marcados con asterisco
(*) son obligatorios

Actividades en la planeación
1. Definir el alcance de la prueba.
2. Definir la estrategia de pruebas.
3. Identificar Recursos de software y Hardware.
4. Identificar Recursos Humanos (responsabilidades).
5. Definir entregables.
6. Organizar el comité de cambios.
7. Definir actividades y tiempos.

Estimar la complejidad del proyecto
Desde el inicio

Definir el alcance
Características que serán probadas: Se debe identificar las
características (funciones, módulos ó subprocesos) del software a
probar, que se planean cubrir con el proceso de pruebas, hasta este
punto solo es necesario conocer y describir los procesos de alto nivel
únicamente.
Características que no serán probadas: Es importante aclarar en el
alcance, las características de la aplicación que no se probaran y
explicar porque no serán tenidas en cuenta en el proceso de pruebas.
Aplicación
Módulos a probar Módulos no a probar

APLICATIVO X
Módulo 1 Módulo 2 Módulo 3
Funcionalidad 1
Funcionalidad 2
20%
30%
40%
30%
30% 10% 60%
Se avanza cuando está
construido y probado
Importancia de
cada módulo -
Impacto
20% 30% 40% 10%
Funcionalidad 3
Funcionalidad 4 10%
100%
Producto
Módulos
Función
Avance del 6%
Avance

Definir la estrategia de pruebas
La estrategia de prueba, es la forma como se va a probar el
software.
En esta actividad se definen y describen las técnicas y
herramientas que se va a implementar en el proceso de pruebas
funcionales
La estrategia define criterios de calidad y criterios de éxito que
determinaran cuando terminar de probar.

Criterios de Finalización. Ej:
1. Cuando el 100% los casos de prueba pasan satisfactoriamente durante los ciclos finales
de prueba.
2. Ningún defecto abierto con nivel de severidad alto o medio.
3. Cuando se ha cubierto con los casos de prueba el 99% de los requisitos definidos.
4. Cuando el 98% de los defectos identificados han sido tratados y su solución ha sido
implementada en el producto.
5. Toda la documentación está libre de comentarios y revisiones.
6. Cuando los reportes generados se encuentren en un estado Terminal.
7. ...

Identificar Recursos
El identificar recursos permite conocer con anticipación cuales
aspectos técnicos y humanos deben estar disponibles antes de
la prueba, se debe identificar los siguientes tipos:
1. Recursos de humanos
2. Recursos de hardware
3. Recursos de software
4. Entregables de pruebas

Coordinador
de pruebas
Responsable por:
Plan de
pruebas
Resumen de
pruebas
Seguimiento
al proyecto
Coordinador de pruebas
Analista de
calidad
Responsable por:
Test Maestros Casos de
prueba
Set de datos
Analista de calidad
Matriz de
trazabilidad
Tester
Responsable por:
Reporte de
defectos
Registro de
pruebas
Tester
Informe de
avance
Lecciones
aprendidas
Matriz de
Ejecución

• Planeación del proceso de pruebas.
• Administración de los recursos dispuesto para las pruebas (software y
Hardware).
• Evaluación del progreso y efectividad de las pruebas.
• Asignación de recursos (analistas y testers) a los diferentes proyectos
que se presenten.
• Mantenimiento del dialogo primario, con los involucrados en el
desarrollo.
• Elaboración periódica de informes de avance y seguimiento.
• Supervisión (directa o indirecta) de los analistas de calidad y Testers.
• Validar el cumplimiento de estándares en manuales y entrega de los
mismos.
Administrador de pruebas

• Verificar requisitos y Casos de uso, que servirán como base para
extraer casos de prueba.
• Diseñar y refinar casos de prueba.
• Registrar la no conformidad de los estándares y procedimientos, si no
fueron cumplidos razonablemente.
• Recolectar y mantener el Set de datos.
• Obtener métricas y estadísticas de calidad en el proyecto.
• Control y seguimiento de defectos.
• Realizar ERT (Error Replication Test) Prueba de replicación de error,
ejecución de escenarios para replicar errores aleatorios o difíciles de
detectar.
• Evaluación del resultado de cada ciclo de pruebas.
Analista de calidad

• Ejecutar cada uno de los casos de prueba en cada ciclo.
• Identificar la forma mas práctica de ejecutar las pruebas para ahorrar
tiempo y esfuerzo.
• Reportar cualquier defecto encontrado en el producto.
• Dar sugerencias a los analistas de calidad sobre casos de prueba
adicionales que puede diseñarse basados en la ejecución de los casos
existentes.
• Reportar cualquier consideración o sugerencia en cuanto a diseño y
funcionalidad del aplicativo.
• Acompañar al equipo de desarrollo en la solución de defectos,
resolviendo dudas e inquietudes.
• Generación de informes de avance.
Analista de pruebas (tester)

Organizar el comité de cambios
El comité de cambio es un grupo de personas responsables de la
evaluación y aprobación de entregables. Análisis de defectos,
cambios y mejoras en la aplicación y aprobación o desaprobación
de los mismos.
El comité estará constituido por el analista de calidad, una persona
representante del equipo de desarrollo, el director o coordinador del
proyecto, en algunos casos especiales también podrá participar un
representante de los usuarios finales.

Organizar el comité de cambios
1. Analizar, dar sugerencias y aprobar el plan de pruebas del proyecto.
2. Analizar, dar sugerencias y aprobar los casos de prueba.
3. Analizar los reportes de defectos con el fin de:
a. Definir estado para algunos.
b. Clasificar en la categoría correspondiente.
c. Hacer análisis de impacto y severidad de cada defecto.
d. Decidir si será corregido o no un defecto en una versión del
producto determinada.
4. Hacer seguimiento al avance del proceso de pruebas.
5. Levantar alertas en caso de desviaciones, desfases o
incumplimientos.
6. Evaluar las actividades del proceso de pruebas.
7. Aprobar o desaprobar los entregables durante el proceso de pruebas.

Entregables de pruebas IEEE-829
Plan de
pruebas
Especificaciones
de diseño
de pruebas
Modulo A
Especificaciones
de diseño
de pruebas
Modulo B
Especificaciones
de diseño
de pruebas
Modulo C
Casos
de pruebas Casos
de pruebas Casos
de pruebas
Registro de
pruebas
Ciclo N+1
Reporte de
Incidentes
Resumen
de pruebas

Planeación
Diseño
Ejecución
Evaluación
Gestión
Plan de
Pruebas
Cronograma
del Proyecto
Plantilla de
estimación
Casos de
prueba
Lista de
GUI
Informe
Avance
Registro
Actividades
Incidentes
de proyecto
Informe Fin
Mes Actas
PROYECTO X
Estructura
Documentos
Reporte de
defectos
Registro de
pruebas
Indicadores
Resumen de
Pruebas
Test
Maestros
Matriz de
Trazabilidad

Estimar tiempos y actividades
El cronograma identifica:
9 Recursos humanos necesarios para pruebas
9 Cuando intervendrán dichos recursos en las actividades
9 Como se van a distribuir los recursos
9 Que actividades se realizaran
9 Tiempo de cada actividad

Distribución porcentual de tiempo
Estimación de Tiempos de pruebas
12%
32%
28%
2%
4%
8%
4% 2%
8%
Validación de requisitos
Revisiones de diseño
Levantamiento de casos de prueba
Ejecución de pruebas funcionales (de sistema), por
ciclos
Ejecución de pruebas de aceptación
Control y seguimiento de defectos
Seguimiento del proyecto
Reportes de calidad durante todo el cIclo del desarrollo
Informe final de calidad

Creación del resumen de pruebas
Certificación de la aplicación
Análisis de defectos
Evaluación de la cobertura de requerimientos
Análisis de resultados
Evaluación de pruebas
Revisar cambios a la aplicación
Investigar los resultados inesperados
Reporte de defectos
Evaluación de la ejecución de las pruebas
Ejecución de procedimientos de prueba
Ejecución de pruebas
Revisar y controlar la cobertura de requisitos
Identificar y estructurar procedimientos de prueba
Identificar y describir caso de prueba
Diseño de pruebas
Generar plan de pruebas
Identificar recursos
Análisis e identificación de requisitos de prueba
Responsable
Horas
Fecha
Actividad

Plan de
pruebas
Diseño de casos
de prueba
Documento de
requisitos refinado
Modelo de casos de
uso refinado
Descripción de
casos de prueba
Informe de
avance
Matriz de
trazabilidad
Cronograma de
pruebas ACT.
Plan de
pruebas
ACT.
Diseño de pruebas
de datos

ENTRADAS REQUERIDAS
„ Plan de Pruebas.
„ Documentación Actualizada.
… Modelos.
… Casos de Uso.
… Procedimientos.
… Reglas de Negocio.
„ Reuniones Aclaratorias y
Capacitaciones.
„ Casos de Prueba.
… Entregas totales, evolutivas o
iterativas; de acuerdo a la naturaleza
del proyecto.
… Matriz de Trazabilidad.
… Retroalimentación y Revisión realizada
por el Comité de Cambios.
„ Como consecuencia de una
modificación en el alcance:
… Plan de Pruebas Actualizado y
Aprobado.
… Cronograma de Actividades
Actualizado.
„ Como consecuencia de una
modificación en los tiempos de
ejecución:
… Cronograma de Actividades
Actualizado.
Diseño de pruebas

Actividades en el diseño
1. Derivar casos de prueba de las especificaciones.
2. Identificar casos de prueba excepcionales.
3. Detallar casos de prueba.
4. Definir lo que se va probar en cuanto a interfaz de usuarios se refiere.
5. Trazar casos de prueba a casos de uso.
6. Definir el conjunto de datos para probar.
Diseño de pruebas

Considere el siguiente requisito: Identificar tipo triangulo
La aplicación lee tres valores enteros, que representan las
longitudes de los lados de un triangulo, e imprime un mensaje
que establece si el triangulo es escaleno, isósceles o
equilátero.
Que tanto sabemos de testing?
Diseño de pruebas
Genere todas la posibles opciones que
permitan validar el programa

Un caso de prueba es la representación de un flujo, evento o
escenario del sistema, el cual determinará si un requisito
particular es parcial o completamente satisfactorio.
Casos de prueba
Diseño de pruebas

Los casos de prueba están basados en:
Escenarios de casos de uso
Reglas de negocio
Áreas funcionales
Aspectos Heurísticos
Casos de prueba
Diseño de pruebas

Están divididos en tres categorías:
Casos de prueba de funciones y reglas de negocio
Casos de prueba de Excepción
Casos de prueba de GUI
Casos de prueba
Diseño de pruebas

Casos de prueba de funciones y reglas de negocio: (validar
que al generar un pedido se actualiza el stock)
Casos de prueba de Excepción: (validar un campo numérico)
Casos de prueba de GUI: (validar el orden del tabulador en los
campos de un formulario)
Casos de prueba (Ejemplo)
Diseño de pruebas

1. Identificar los escenarios de cada caso de uso (básicos y
alternos)
2. Identificar variables que puede tener en el caso de uso.
3. Identificar diferentes opciones que puede presentar cada
escenario.
4. Identificar la entrada o salida de información de cada
escenario.
Pasos en obtener de casos de prueba a partir de
casos de uso
Diseño de pruebas

Antes de diseñar casos de prueba, es necesario identificar
todos los escenarios de los casos de uso.
Un escenario es una instancia de un caso de uso, el cual
describe un camino a través del flujo de eventos.
¿Que es un escenario?
Diseño de pruebas

Escenarios de casos de uso
Diseño de pruebas

Flujos normales o básicos: entradas validas (happy path)
Flujos alternos: otras entradas validas o invalidas
Flujos de eventos
Diseño de pruebas

Identificando Escenarios
Flujo básico
Flujo alterno 1
Flujo alterno 3
Flujo alterno 4 Flujo alterno 2
Diseño de pruebas

Identificando Escenarios
Diseño de pruebas
Flujo básico
Flujo alterno 1
Flujo básico
Flujo alterno 2
Flujo alterno 3
Flujo básico
Flujo básico
Flujo alterno 3
Flujo básico
Flujo alterno 1
Flujo básico
Flujo alterno 4
Flujo alterno 3
Flujo básico
Flujo alterno 1
Flujo alterno 4
Flujo alterno 3
Flujo básico
Flujo alterno 2

Identificando escenarios
Flujo alterno 4
Flujo alterno 3
Flujo básico
Escenario 8
Flujo alterno 4
Flujo básico
Escenario 7
Flujo alterno 2
Flujo alterno 1
Flujo alterno 3
Flujo básico
Escenario 6
Flujo alterno 1
Flujo alterno 3
Flujo básico
Escenario 5
Flujo alterno 3
Flujo básico
Escenario 4
Flujo alterno 2
Flujo alterno 1
Flujo básico
Escenario 3
Flujo alterno 1
Flujo básico
Escenario 2
Flujo básico
Escenario 1
Flujo básico
Flujo alterno 1
Flujo alterno 3
Flujo alterno 4 Flujo alterno 2
Diseño de pruebas

Identificar Escenarios - Ejemplo
1. Inicio del retiro. El cliente inserta la tarjeta del banco para que sea leída por la
maquina
2. Verificar tarjeta del banco. El cajero lee el código de la cuenta de la cinta
magnética de la tarjeta y verifica si esta es una tarjeta valida.
3. Ingresar clave. El cajero solicita el número de clave (4 dígitos).
4. Verificar número de cuenta y clave. El número de la cuenta y la clave son
verificados para determinar si la cuenta es valida y si la clave ingresada es
correcta para esa cuenta.
5. Opciones del cajero. El cajero despliega las diferentes opciones disponibles (en
este flujo el cliente del banco siempre selecciona “retiro de fondos”).
Flujo básico
Diseño de pruebas

6. Ingresar la cantidad. Ingresar la cantidad a retirar (para este flujo el cliente
selecciona cantidad de (10.000$, 20.000$, 50.000, 100.000$ o 200.000$).
7. Autorización. El cajero inicia el proceso de verificación con el sistema bancario
enviando la información de código de la cuenta, de la clave, de la cantidad, y de la
identificación de la tarjeta. La envía como transacción. (para este flujo el sistema
bancario esta en línea y responde autorizando el retiro de fondos y actualizando el
saldo de la cuenta).
8. Dispensar. El dinero es dispensado
9. Retornar tarjeta. La tarjeta es retornada.
10. Recibo. El recibo es impreso y dispensado
Flujo básico
Diseño de pruebas

4. Clave incorrecta: En el paso 4 del flujo básico. Verificar cuenta y clave, el cliente
tiene tres intentos para ingresar la clave correcta.
Si ingresa una clave incorrecta, el cajero despliega el mensaje apropiado, si
todavía hay intentos restantes, este flujo envía al paso 3 del flujo básico.
Si en el intento final la clave ingresada es incorrecta, la tarjeta es retenida
3. Fondos insuficientes en cajero: En el paso 6 del flujo básico. Ingresar cantidad,
si el cajero tiene fondos insuficientes para dispensar la cantidad requerida, se
debe desplegar un mensaje apropiado para volver a ingresar otra cantidad menor
a la solicitada
2. Cajero sin dinero: En el flujo básico paso 5. opciones del cajero, si el cajero no
tiene dinero, la opción “retiro de fondos” debe estar desahabilitada
1. Tarjeta no valida: En el flujo básico paso 2. Verificar tarjeta del banco, si la tarjeta
no es valida se debe desplegar un mensaje apropiado indicando al cliente.
Flujos alternos
Diseño de pruebas

5. Cuenta incorrecta: En el paso 4 del flujo básico. Verificar cuenta y clave, Si el
sistema bancario retorna un código indicando que la cuenta no se pudo encontrar
ni es una cuenta que permita hacer retiros, el cajero despliega el mensaje
adecuado y reenvía al cliente para volver a ingresar la tarjeta.
8. Cancelar transacción: El cliente puede en cualquier momento terminar con la
transacción (cancelar) la transacción es detenida y la tarjeta es devuelta
7. Cantidad de retiro diario alcanzado: En el paso 6 del flujo básico Autorización, el
sistema bancario retorna un código indicando que, incluyendo esta solicitud de
retiro, el cliente excede o excederá la cantidad máxima permitida en un periodo de
24 horas
6. Insuficientes fondos en la cuenta: En el paso 7 del flujo básico. Autorización, si
el sistema bancario retorna un código indicando que el saldo es menor que la
cantidad ingresada en el paso 6 del flujo básico – ingresar cantidad, el cajero
despliega un mensaje apropiado y reenvía al cliente al paso 6 del flujo
Flujos alternos
Diseño de pruebas

Diseño de pruebas
Tarjeta valida?
Ingresar clave
Clave valida?
Cuenta valida?
Se despliegan las opciones del cajero
Seleccionar retiro de fondos
Seleccionar
cantidad a retirar
Fondos suficientes
en cajero?
Fondos suficientes
en la cuenta?
Verificar que el sistema retorna
tarjeta, entrega dinero y recibo
Si
No
Si
No
Tiene intentos
Restantes?
Si
Retener tarjeta
No
Si
No
Si
No
Si

Diseño de pruebas
1. Inicio de retiro
2. Verificar tarjeta del banco
3. Ingresar clave
4. Verificar número de cuenta y clave
5. Opciones del cajero
6. Ingresar la cantidad
7. Autorización
8. Dispensar
9. Retornar tarjeta
10. Recibo

Identificar Escenarios (ejemplo)
ESCENARIO 8....
FLUJO ALTERNO 6º
FLUJO BÁSICO
ESCENARIO 7 INSUFICIENTES FONDOS EN LA CUENTA
FLUJO ALTERNO 5
FLUJO BÁSICO
ESCENARIO 6 CUENTA INCORRECTA
FLUJO ALTERNO 4
FLUJO BÁSICO
ESCENARIO 5 CLAVE INCORRECTA (TRES INTENTOS)
FLUJO ALTERNO 4
FLUJO BÁSICO
ESCENARIO 4 CLAVE INCORRECTA
FLUJO ALTERNO 3
FLUJO BÁSICO
ESCENARIO 3 FONDOS INSUFICIENTES EN CAJERO
FLUJO ALTERNO 2
FLUJO BÁSICO
ESCENARIO 2 CAJERO SIN DINERO
FLUJO BÁSICO
ESCENARIO 1 RETIRO DE FONDOS
Diseño de pruebas

1. Paso 4: Verificar número de cuenta y clave.
• Password (Number)
• Cuenta (Number)
2. Paso 6: Ingresar cantidad
• Saldo en cajero (Number)
3. Paso 7: Autorización
• Valor a retirar (Number - list)
• Saldo en cuenta (Number)
• Cantidad de retiro diario (Number)
Identificar variables que puede tener en el caso de
uso en cada paso (ejemplo)
Diseño de pruebas

1. Strings regular john_smith@aol.com
2. Vacío
3. Mínimo a@b.com
4. Máximo 12345678910@verylongdomainname.com
5. Max + 1 012345678910@verylongdomainname.com
6. Muy Largo aaaaaaaaaaaaaaaaaaaaaaaaaaaa...
7. Lógica/ invalido john_smith@aol.xyz
Identificar diferentes opciones que puede presentar
cada escenario – Clases de equivalencia
Diseño de pruebas

-
-
-
I
I
V
MENSAJE DE ALERTA, LA TARJETA ES RETENIDA POR EL
CAJERO
-
-
-
V
I
ESCENARIO 5 / CLAVE
INCORRECTA (0 INTENTOS
INTENTO RESTANTES)
CP04
MENSAJE DE ALERTA, RETORNA AL PASO 4 DEL FLUJO
BÁSICO – INGRESAR CLAVE
-
-
-
V
I
ESCENARIO 4 / CLAVE
INCORRECTA (1 INTENTOS
INTENTO RESTANTE)
CP04
BÁSICO – INGRESAR CLAVE
-
-
-
V
I
ESCENARIO 4 / CLAVE
INCORRECTA (MAS DE UN
INTENTO RESTANTE)
CP04
BÁSICO – INGRESAR CANTIDAD
-
V
V
V
V
ESCENARIO 3 / FONDOS
INSUFICIENTES EN CAJERO
CP03
OPCIÓN RETIRO DE FONDO DESHABILITADA
-
V
V
V
V
ESCENARIO 2 / CAJERO SIN
DINERO
CP02
RETIRO DE FONDOS EXITOSO
V
V
V
V
V
ESCENARIO 1/ RETIRO DE
FONDOS
CP01
RESULTADO ESPERADO
ESCENARIO/CONDICIÓN
ID
Clave
#
cuenta
Cantidad
Saldo
Saldo
cajero
Identificar la entrada o salida de información de
cada escenario.
Diseño de pruebas
Retiro
Diario

Nombre del Caso de uso
Elaborar Pedido
Descripción del Caso de Uso
El caso de uso describe la manera como se elabora un pedido
para un cliente que ya existe en el sistema, el pedido puede
quedar en estado de elaboración o enviado a almacén
Identificar Casos de prueba basados en casos de uso
(ejemplo2)
Diseño de pruebas

Flujo Básico
1. Inicio: El caso de uso inicia cuando se ha consultado un cliente para realizar un pedido y se selecciona la opción de nuevo pedido en
la ventana de información del cliente.
2. Despliegue de opciones: El sistema despliega una nueva ventana en la que aparece un campo con la fecha actual del sistema, la
referencia del pedido (estas son generadas automáticamente por el sistema), la dirección de envío del pedido y un listado de las
líneas de pedido, en las que se reflejan el código de artículo, la descripción del mismo, la cantidad solicitada, el precio, y por último el
precio total del pedido, con los datos de las líneas de pedido que contuviera el mismo.
3. Datos de la dirección de envío: El operador debe introducir la dirección de envío del pedido especificando dirección, Apto, código
postal, país, Departamento o provincia y ciudad.
3.1. Por defecto el sistema trae la dirección del cliente para el cual se va a elaborar el pedido.
4. Ingresar línea de pedido: El operador introduce una nueva línea de pedido mediante el botón añadir línea, habiendo introducido la
referencia del producto y la cantidad deseada por el cliente. Conforme se introducen las cantidades se muestra el IVA y el costo total
del pedido.
4.1. En caso de querer introducir una nueva línea de pedido, volver al punto 4
5. Seleccionar modalidad de pago: Se selecciona la modalidad de pago, que aparecerá como a crédito y al contado o bien sólo una
de éstas opciones según sea el perfil del cliente.
Nota: en este paso el sistema debe traer por defecto una de las opciones o ambas, dependiendo del perfil del cliente.
6. Guardar Información del pedido: Una vez introducidas todas las líneas de pedido, el actor puede guardar el pedido seleccionando
el botón “guardar”, en cuyo caso se almacenará con los datos actuales en estado de elaboración, o pueden pasar el pedido a
almacén seleccionando la opción “enviar a almacén”, en cuyo caso el pedido deja de estar en elaboración y aparece en el listado de
pedidos no atendidos del almacén.
Continuación
Diseño de pruebas

Flujos Alternos
1. Validar datos numéricos positivos
Si en el punto 3 al introducir alguno de los campos apartamento o código postal se ha ingresado un número no estrictamente
positivo, el sistema generará un mensaje de alerta.
2. Campos obligatorios
Si en el punto 3 al dejar alguno de los campos de la dirección vacíos (excepto apartamento), y seleccionar alguna de la opciones
“guardar” o “enviar a almacén”, el sistema generará un mensaje de alerta.
3. Referencia no existente
Si en el paso 4 se introduce una referencia errónea o inexistente, el sistema generará un aviso de producto no existente.
4. Cantidad de productos menores o iguales a O
Si en el paso 4 se introduce una cantidad no mayor que cero el sistema generará un aviso de cantidad errónea.
5. Cantidad máxima de productos
Si en el paso 4 se introduce una cantidad por encima del rango máximo razonable de pedido, el sistema generará un aviso, de
haber excedido esta cantidad.
6. Eliminar Línea
Si en el paso 4 a medida que se van ingresando líneas, también es factible ir eliminando líneas, se selecciona la línea que se desea
eliminar y luego se seleccionar la opción eliminar línea, el sistema no solicita confirmación para eliminar la línea
7. Eliminar sin seleccionar línea
En caso de seleccionar la opción eliminar línea y no haber seleccionado una línea para eliminarla del pedido, el sistema despliega
un mensaje alertando al actor sobre que no es posible eliminar un línea que si no se ha seleccionado.
Continuación
Diseño de pruebas

1. Paso 3: Datos de la dirección de envío
• Dirección de envió (String - 100)
• Apartamento (Numérico - 2)
• Código postal (Numérico - 4)
• País (String - 50)
• Departamento (String - 50)
• Ciudad (String - 50)
2. Paso 4: Ingresar línea de pedido
• Referencia (Numérico - 4)
• Cantidad (Numérico - 3)
• Cantidad en inventario (Numérico)
• Cantidad máxima permitida (Numérico)
Identificar Variables (ejemplo2)
Diseño de pruebas

Paso 5: Seleccionar modalidad de pago
• Modalidad de pago (Lista)
Identificar Variables (ejemplo2) - cont
Diseño de pruebas

1. Paso 3: Datos de la dirección de envío
• Dirección de envió: Vació, >=100 Car
• Apartamento: Vacio, df, 23, >=2 car
• Código postal: Vacio, dfer, 2382, >=4 car
• País: Vació, >=50 Car
• Departamento: Vació, >=50 Car
• Ciudad: Vació, >=50 Car
2. Paso 4: Ingresar línea de pedido
• Referencia: Vacio, derf, 2334, >=4 car
• Cantidad: Vacio, derf, 2334, >=4 car
• Cantidad en inventario (Viene por defecto)
• Cantidad máxima permitida (Es parametrizado)
3. Paso 5: Seleccionar modalidad de pago
• Modalidad de pago (Viene por defecto)
Clases de equivalencia (ejemplo2)
Diseño de pruebas

Identificar la entrada o salida de información de
cada escenario (ejemplo2).
Diseño de pruebas

Casos de prueba GUI
Diseño de pruebas

Ejemplos de defectos conocidos, que es conveniente evaluar
en cada caso de uso:
• Demasiados caracteres
• Campos requeridos nulos
• Fechas inválidas (el 30 de febrero ó 31 de septiembre)
• Ingresar fechas incompletas
• Combinaciones imposibles (fecha _ inicio después de fecha _ final)
• El código realiza el procedimiento correcto si el usuario presiona Detener.
• Concurrencia (¿Que pasa si dos usuarios tratan de reservar el mismo cuarto al mismo
tiempo?).
• Consistencia en la redacción, lugar de los botones, funcionalidad.
• Confirmación antes de hacer algo mayor (ej., una eliminación en cascada).
• Eliminar elementos relacionados y ver como se comportan
Entre muchos otros....
Identificar posibles excepciones no tenidas en
cuenta en la documentación del caso de uso.
Diseño de pruebas

En la práctica
Ejercicio Nº 3 – 20 min
Ir al libro de trabajo. Basados en el caso de uso “Registrar
Curso en Linea”. Identificar todos los escenarios con las
respectivas variables y opciones que se puedan presentar
en el caso de uso.

• Código de caso de prueba: Este código es una nomenclatura de
casos de prueba establecida por la organización como estándar.
• Nombre del caso de prueba: Es el nombre que identifica cada caso
de prueba.
• Descripción del caso: Es la descripción del caso de prueba.
• Configuración: Describe en forma detallada el ambiente (tanto de
software como de hardware) en el cual se ejecutara el caso de prueba
(esto puede ser opcional).
• Entradas de prueba: Especifica cada uno de los requisitos, casos de
uso o regla de negocio que serán validados por dicho caso de prueba.
Partes de un caso de prueba
Diseño de pruebas

• Condiciones de inicio: Son los requisitos previos que se deben dar
para poder ejecutar el caso de prueba.
• Resultado esperado: Es el criterio de éxito que se debe cumplir
para definir si un caso de prueba fue completado exitosamente o no.
• Procedimientos de prueba: Es la descripción de todos lo pasos y
puntos de verificación que se deben seguir al ejecutar un caso de
prueba.
Partes de un caso de prueba
Diseño de pruebas

Partes de un caso de prueba (ejemplo)
Mensaje de alerta “No tiene
fondos suficientes”
Retorna al usuario al paso anterior
Resultado
esperado
Deben haber fondos insuficientes
para realizar un retiro
Condiciones de
inicio
AS400
Procesador XX
…..
Config.
Caso de uso
Retirar fondos
Entradas
Verificar que se despliega
mensaje de alerta sin la cantidad
de retiro es superior a los fondos
existentes en el cajero
Descripción
CP03
Código
Fondos insuficientes en cajero
Nombre
Diseño de pruebas

El procedimiento de prueba es la forma estructural de ejecutar
un caso de prueba, el procedimiento de prueba se compone
básicamente de dos aspectos:
Paso: Es un procedimiento que se debe implementar
utilizando una función de la aplicación.
Punto de verificación: Es una comprobación que se realiza
para asegurase que un paso o varios están siendo
completados satisfactoriamente o no.
Procedimientos de prueba
Diseño de pruebas

Ingresar la tarjeta bancaria para que sea leída, debe ser una tarjeta valida.
Ingresar la clave (4 dígitos, debe ser una clave valida).
Verificar que se desplieguen las opciones de operación del cajero.
Seleccionar la opción retiro de fondos.
Verificar que se despliegan las cantidades de dinero posibles para el retiro (10.000,
20.000, 50.000 y 100.000).
Ingresar una cantidad de retiro superior a la cantidad existente en el cajero.
Verificar que se despliega un mensaje de alerta indicando que la cantidad ingresada,
es superior a la cantidad existente en el cajero.
Procedimientos de prueba (ejemplo)
El siguiente es el ejemplo para el caso de prueba, fondos
insuficientes en cajero:
;
;
Validación
;

UU
Nomenclatura de casos de prueba - Ej
FF CC nn
Id Caso de uso
Flujo de caso de uso
Tipo de Caso
Numero de secuencia
Diseño de pruebas

Crear y generar Querys
Realizar los querys necesarios para el proceso de ejecución de las
pruebas.
SELECT *
FROM tblVendedores
WHERE (strNumDocumento = 43903672)
Diseño de pruebas

En la práctica
Ir al libro de trabajo. Basados en la definición del producto de
software “Administrar Sistema de pedidos”.
Describir todos los casos de prueba (Negocio, excepcionales
y de GUI) con sus repectiva descripción y procedimientos de
prueba.

Trazar casos de prueba hacia requisitos
Diseño de pruebas

Es una técnica que permite relacionar a los requisitos, diseño
e implementación y hacer un seguimiento efectivo a los
cambios que ocurran de manera continua y como se ven
afectados uno a otros.
Permite determinar el origen y destino de cada elemento.
¿Qué es trazabilidad o Rastreabilidad?
Diseño de pruebas

Validar que un requisito esta implementado en el producto.
Hacer seguimiento a los cambios que ocurren en el sistema.
Tener un mecanismo de análisis de impacto.
Tener un mecanismo para identificar los elementos necesarios
o innecesarios.
¿Para que se usa?
Diseño de pruebas

¿cómo funciona la rastreabilidad?
Diseño de pruebas
Característica B
Característica A
Caso de uso 1
Caso de uso 2
Caso de uso 3
Caso de uso 4
Caso de prueba 1
Caso de prueba 2
Caso de prueba 3
Caso de prueba 4
Caso de prueba 5
Caso de prueba 6
Caso de prueba 7
Caso de prueba 8
Caso de prueba 9
Caso de prueba 10

x
CP10
x
CP08
x
x
CP08
x
CP07
x
CP06
CP05
x
x
CP04
x
CP03
x
CP02
x
CP01
UC 5
UC 4
UC 3
UC 2
UC 1
UC
CP
Matriz de rastreabilidad
Diseño de pruebas

En la práctica
Generar la matriz de trazabilidad de casos de uso Vs Casos
de prueba.

Los datos de prueba (Set de datos) permiten simular datos
reales de un caso de prueba con el fin de ejemplarizar el
escenario del caso de uso, estos datos deben tener varias
características:
• Amplitud
• Alcance
• Profundidad
Datos de prueba
Diseño de pruebas

Amplitud: cantidad de datos que serán utilizados
1 registro
10 registros
Datos de prueba
Diseño de pruebas

1.000.000
Ant
Girardot
Circ 6 # 135-29
Juan
Llano
250.000
Cal
Manizalez
Cra 128 # 10-00 ap 4
Mauricio
Jimenez
10.000
Cun
Chia
Calle 10 sur · 45-29
Rodrigo
100.000
Ant
Cualquier parte
Calle 123
Navajas
Pedro
100.000
Ant
Cualquier parte
Calle 123
Mickey
Mouse
Alcance: Variación en los datos de pruebas, valores similares
no proporcionan resultados objetivos
Datos de prueba
Diseño de pruebas

Profundidad: Relevancia en los datos de prueba, variación de
extremo a extremos para garantizar un cobertura optima:
999.999.999
Ant
Girardota
Circ 6 # 135-29
Juan
Llano
-10.000
Cal
Manizalez
Cra 128 # 10-00 ap 4
Mauricio
Jimenez
0
Cun
Chia
Calle 10 sur · 45-29
Rodrigo
100.000
Ant
Cualquier parte
Calle 123
Navajas
Pedro
100.000
Ant
Cualquier parte
Calle 123
Mickey
Mouse
Datos de prueba
Diseño de pruebas

En la práctica
Generar datos con todas las caracteristicas que ayudaran a
validar los requisitos.

Descripción de
casos de prueba
Registro de
pruebas
Pruebas del
sistema
Informe de
avance
Software a probar
Reporte de defectos
(bugtracker)
Matriz de
trazabilidad
Set de datos
Comité
Cambios
de datos
Matriz de
Ejecución

ENTRADAS REQUERIDAS
„ Casos de Prueba.
„ Cronograma de Actividades.
„ Plantillas de Proceso QA.
… Actas.
… Informes.
… Reportes.
„ Documentación Actualizada.
„ Documentación Pruebas de Desarrollo.
… Test Ejecutados.
… Certificación Escrita.
„ Planeación de Comités de Cambio.
… Fechas Estimadas.
„ Documentación QA del Proceso.
… Actas.
… Informes.
… Reportes.
… Casos de Prueba
… Matriz de ejecución
„ Informe de Avance.
… Diario.
… Semanal.
„ Informe de Horas Invertidas.
„ Lecciones Aprendidas y Sugerencias.
„ Reportes de la Solución (Bug’s).
… Errores.
… Consideraciones.
… Sugerencias.
„ Métricas
„ Análisis de Impactos.

Actividades en la ejecución
1. Ejecutar casos de prueba y registrar los resultados.
2. Reportar cambios y defectos en el producto.
3. Evaluar la ejecución de cada ciclo de pruebas.
4. Realizar ciclos de regresión cuando hayan cambios o soluciones.

¿Como se ejecutan las pruebas?
Se ejecutan los casos de
prueba previstos
Se reportan los defectos
existentes
Nuevos escenarios que
surjan, son diseñados
Se ejecutan N ciclos,
hasta que se alcancen los
criterios de éxito definidos.
BugTracker
Ciclos de Ejecución
Se libera el producto ya
certificado.

Cada caso de prueba que se ejecute debe ser registrado en un
documento con el fin de tener un historial del resultado de
cada caso de prueba en un ciclo determinado.
Registrar los resultados de pruebas

Log o registro de pruebas: documento donde se registran cada
uno de los casos de prueba que se han ejecutado, en el se
identifican:
1. Código del caso de prueba ejecutado
2. Nombre del caso de prueba ejecutado
3. Resultado esperado
4. Resultado obtenido
5. Estado de ejecución (Paso, Fallo, No se pudo ejecutar)
6. Ciclo correspondiente
7. Defectos asociados durante ese ciclo al caso de prueba
8. Fecha de ejecución
9. Analista de calidad
Registrar los resultados de pruebas

Registrar los resultados de pruebas - Ej

Es un documento que permite hacer un seguimiento a la
ejecución de cada caso de prueba en cada ciclo.
Matriz de Ejecución
X
Ok
CP05
X
X
CP04
Ok
Ok
Ok
CP03
Ok
X
Ok
Ok
CP02
Ok
Ok
Ok
X
CP01
Ciclo4
Ciclo3
Ciclo2
Ciclo1
Ciclos
CP

El proceso de seguimiento de defectos (bugs) es una parte de
la disciplina de control de cambios, de esta disciplina también
hace parte el control de cambios en los requerimientos, el
control de mejoras y adiciones.
Control y seguimiento de defectos

Bugtracker
Aplicación o base de datos, donde se registran, siguen y
controlan todos los defectos que se detectan en un producto.

Informe o reporte de defectos
Titulo o resumen
Es un pequeño enunciado que permite recrear rápidamente cual es el
defecto que se presenta.
Descripción
Es una explicación detallada del defecto, de cómo se presento y que se
estaba realizando cuando se presento el defecto.

Tipo
Es la clasificación según el origen:
Defecto: Indica que es un comportamiento incorrecto del software.
Consideración: Es una duda que se pueda presentar sobre un posible
comportamiento anormal.
Sugerencia: Es una propuesta para mejorar alguna funcionalidad o parte
del producto.

Severidad
La severidad es el impacto que tiene o tendrá el defecto sobre la aplicación.
Menor: el defecto no afecta ninguna regla de negocio es simplemente un
problema cosmético.
Promedio: se ven afectadas algunas funcionalidades, pero sin embargo no
afecta las reglas de negocio.
Mayor: son problemas graves y que requieren sean tratados rápido, ya que
se ven afectadas las reglas de negocio.
Critica: un estado de severidad critica es aquel donde no hay funcionalidad
de las reglas del negocio y/o la aplicación

Prioridad
Es el nivel de atención o servicio deseado, el cual indica la rapidez con la cual
debe ser tratado un defecto.
Baja: el defecto es algo superficial y se puede proyectar su solución para mas
adelante.
Normal: no hay sobrecarga de esfuerzo, se pueden realizar otras labores mas
importantes, antes de la solución del defecto.
Alta: el defecto merece atención pero no es necesario actuar en el momento.
Urgente: Se necesita una atención extrema, debe ser atendido cuanto antes.
Hasta que no se solucione el problema no se debe continuar (defecto stopper).

Ambiente
Cuando se refiere al ambiente, se refiere a la configuración de software (y
hardware) en la cual ocurrió el error, en el ambiente se debe especificar:
El entorno: es decir que tipo de ambiente es (pruebas, desarrollo o
producción)
Sistema operativo: es el sistema operativo del servidor y del cliente
Servidor: se deben especificar las características de maquina en la cual esta
instalada la aplicación.

Datos de la aplicación
Estos datos ayudaran a analizar mejor en donde se esta presentado el
defecto en caso de haber control de versiones.
Versión: es la versión de la aplicación donde esta ocurriendo el defecto
Build: es la versión compilada de la aplicación

Otros posibles datos que puede contener un reporte
Módulo: Es el área funcional donde se presento el defecto.
ID de caso de prueba: Se puede hacer una referencia del caso de prueba
que origino el defecto.
Pasos para reproducir el defecto: Serie de acciones que se deben llevar a
cabo para replicar el defecto en el aplicativo

1. Funcional
2. Interfaz
3. Datos
4. Parametrización
5. Documentación o definición
6. Seguridad
7. ...
Clasificación de defectos (naturaleza)

El estado es el momento por el cual pasa un diferente defecto
durante un ciclo, los estados son:
• Abierto
• Asignado
• Aceptado
• Resuelto
• Feedback
• Confirmado
• Cerrado
Nota: los estados pueden ser definidos según se requiera para la organización
Estados de un defecto

El bug es abierto
El bug es asignado
Por SQA
El desarrollador
Confirma el bug
El desarrollador
Solicita retroalimentación
El bug es resuelto
El bug es revisado
por SQA
El bug es reabierto
El bug es cerrado
Estados de un defecto

La evaluación de la ejecución de pruebas permite determinar
si los criterios de completitud de los casos de prueba han
alcanzados satisfactoriamente en cada ciclo de ejecución y si
este tuvo:
a. Terminación normal
b. Terminación anormal
Evaluar la ejecución de pruebas

Terminación normal
- Todos los casos de prueba previstos han sido ejecutados
- Todos los resultados actuales son validos o inválidos
Terminación anormal
- Se presentaron errores fatales (defectos stopper)
- Se presentaron problemas de sistema
Evaluar la ejecución de pruebas

Una vez implementada la solución de un defecto, se deben
realizar la evaluación y la ejecución de los casos de prueba
respectivos, esto es conocido como regresión, se verifica lo
siguiente en las pruebas de regresión:
a. Que la solución del defecto ha sido incorporada
correctamente.
b. Que no se generaron defectos adicionales después de
implementar la solución.
Pruebas de regresión

Peticiones de cambio VS pruebas
PRD
Test
Code
SRS
CR
Nueva Característica
Nuevo Requerimiento
Defecto
Solicitud de cambio
Único canal
de aprobación
Proceso
de aprobar
decisiones
( CCB )
Entradas de Usuarios Finales
y Clientes
Marketing
Entradas de codificadores
Entradas de Testers
Entradas de Usuarios Finales
Help Desk
Las solicitudes de clientes llegan de muchas fuentes a través del ciclo de vida

Registro de
pruebas
Reporte de
defectos
Evaluación de
pruebas
Resumen de
pruebas
Carta de
certificación
Matriz de
Ejecución
Descripción de
casos de prueba

ENTRADAS REQUERIDAS
„ Casos de Prueba Diligenciados.
„ Cronograma Completado.
„ Documentación QA Diligenciada.
… Informe de Avance.
… Actas.
… Reportes.
„ Reportes en Estado Terminal.
„ Lecciones Aprendidas.
„ Resumen de Pruebas.
„ Estadísticas y Métricas de Pruebas.
„ Lecciones aprendidas.

Actividades en la Evaluación
1. Analizar los resultados recolectados durante el diseño y ejecución.
2. Analizar la métricas claves del proceso.
3. Documentar lecciones aprendidas del proceso.
4. Generar el resumen de pruebas

Una medida proporciona una indicación cuantitativa de la
extensión, cantidad, dimensiones, capacidad o tamaño de
algunos atributos de un proceso o producto.
Ej: Un programa tiene 10.000 LDC (líneas de código).
Ej: Se diseñaron 400 casos de prueba.
Conceptos de Métricas

La medición es el acto de determinar una medida
Ej: Ana será la encargada de medir las LDC de cada módulo
del sistema.

Una métrica es una medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo dado.
Ej: la productividad de este proyecto fue de 500(LDC/Persona
-mes).
Ej: La capacidad del equipo de análisis es documentar 3 casos
de uso/1 hora.

Las medidas no sirven para comparar, necesitamos
métricas.
Ejercicio: en el país A ganan 1000 ($US/pm), y en el país B
ganan 1500 ($US/pm).
Una hamburguesa cuesta 3 $US en el país A, y en el país B
cuesta 5 $US.
¿viven mejor en el país B que en el país A?
Echemos cuentas…
Medidas VS métricas

País A: 1000(€/pm)/3(€/BM) = 333,33 (Hamb/pm)
País B: 1500(€/pm)/5(€/BM) = 250 (Hamb/pm)
Conclusión: no sabemos donde se vive mejor, pero en el país
A una persona durante un mes puede comer un 33% más
hamburguesas que en el país B.
Medidas VS métricas

Las métricas en el proceso de pruebas ayudan a tomar
decisiones y responden preguntas criticas en el proceso
como:
¿Encontramos muchos defectos?
¿Qué severidad tienen los defectos?
¿Estamos solucionando los defectos?
¿Tienen suficientemente cobertura nuestras pruebas?
¿Las pruebas avanzan según el calendario?
¿Tenemos que ajustar los recursos?
¿El código es estable?
¿Qué calidad tiene el código?
Métricas de pruebas

Métricas de Defectos
Métricas de Calidad
Métricas de Cobertura
Métricas de Progreso
¿cuáles son las métricas claves?

Métricas de Defectos: es la medida de la eficiencia en la
identificación, tratamiento y remoción de defectos, esta basada
en en el análisis de defectos detectados durante las pruebas.
Métricas de Calidad: la calidad es la medida de la
confiabilidad, estabilidad y rendimiento de la aplicación que se
esta probando, la calidad esta basa en el análisis de
resultados de casos de prueba durante la ejecución
Métricas claves

Métricas de Cobertura: la cobertura es la medida de la
completitud de las pruebas y se basa en la cantidad de
requisitos, cubiertos por los casos de prueba.
Métricas de Progreso: el progreso es la medida del avance
en el diseño y ejecución de pruebas, se basa en registros
históricos de avance durante el proceso de pruebas.
Métricas claves

¿Dónde están los defectos?
¿Qué severidad tienen?
¿De que tipo son?
Métricas Defectos
0
10
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
Clientes Pedidos Facturación Reportes
#
defectos
¿Qué esfuerzo nos cuesta arreglar
defectos en función de su origen?
0
5
10
15
2 0
2 5
3 0
3 5
Funcional GUI DB Documenta/ Arquitectura
Tie mp o s o luc ió n
Tie mp o ab ie rt o
0
10
20
30
40
1a sem 2da sem 3ra sem 4ta sem
Abiertos
Pendientes
Solucionados
Cerrados
¿Qué tipo de defectos se quedan
abiertos mucho tiempo?

¿Se solucionan lo suficientemente
rápido los defectos?
Métricas Defectos
¿cuál es la eficacia de los testers
para identificar defectos?
0
5
10
15
2 0
2 5
3 0
3 5
Juan Pedro Maria Julian
#
defectos

¿Cuántos defectos se reportaron
por ciclo de pruebas?
Métricas Calidad
0 2 0 4 0 6 0 8 0 10 0 12 0
Ciclo1
Ciclo2
Ciclo3
¿Cuál es el estado de ejecución de
los casos de prueba por cada ciclo?
0
2 0
4 0
6 0
8 0
C i c l o 1 C i c l o 2 C i c l o 3
P a s a r o n
f a l l a r o n
N o E j e c u t a d o
¿Cuántos casos de prueba fueron
diseñados para cada módulo?
0
10
2 0
3 0
4 0
5 0
6 0
7 0
Clientes Pedidos Facturación Reportes
Casos
de
prueba

Métricas Progreso
¿cuál es la eficiencia de los testers?
0
20
40
60
80
100
Juan Pedro Maria
CP-Previstos
CP-Ejecutados
¿cómo están avanzando las
pruebas?
0
2 0
4 0
6 0
8 0
10 0
S e mana 1 S e mana 2 S e mana 3 S e mana 4 S e man 5
C P- Plane ad o s
C P- Eje c ut ad o s
¿cuál es la eficiencia de los
desarrolladores? 0
2 0
4 0
6 0
8 0
P a b l o R i c a r d o C a r l o s S a n d r a
A s i g n a d o s
S o l u c i o n a d o s
V e r i f i c a d o s

Métricas Cobertura
¿Cuántos casos de prueba hay por
reléase? 0
5 0
1 0 0
1 5 0
2 0 0
2 5 0
V 1 . 0 V 1 . 1 V 2 . 0
C a s o s p r u e b a
R e q u i s i t o s
¿Cuántos requisitos se están
cubriendo con casos de prueba?
33%
67%
Requisitos no cubiertos
Requisito Cubiertos

¿Cuán completa es la implementación funcional?
CF = A / B * 100
A = Número de casos de uso (o requisitos) implementadas
B = Número de casos de uso (o requisitos) descriptas en el
Alcance del sistema final.
Otras métricas utiles

¿Qué tan completas son las prueba?
CReq = A / B * 100
A = Número de requisitos cubiertos por casos de prueba.
B = Número de requisitos total.

¿Qué tan efectiva es la solución de defectos?
SD = A / B * 100
A = Número total de defectos en estado solucionado/cerrado
B = Número total de defectos reportados

¿qué tanto ha avanzado la ejecución de prueba?
%Ejecución = A / B * 100
A = Número de casos de prueba ejecutados
B = Número total de casos de prueba

Que son lecciones aprendidas?:
Son las soluciones a problemas y/o malas practicas basados
en la experiencia y aprendizaje tácito en un proceso y que se
convierten en buenas prácticas.
Documentar lecciones aprendidas

1. Lecciones sobre las relaciones con personal de
Desarrollo
2. Lecciones sobre la metodología de pruebas.
3. Lecciones referentes al proceso de desarrollo
4. Lecciones de estimación de tiempos
5. Lecciones sobre métricas e indicadores
6. Lecciones referentes al desempeño del personal
Documentar lecciones aprendidas

2.6 Pruebas Funcionales.pdf

Más contenido relacionado

La actualidad más candente (20)

Similar a 2.6 Pruebas Funcionales.pdf (20)

Último (20)

2.6 Pruebas Funcionales.pdf