 Proceso de desarrollo de la prueba.

 Casos de Prueba
 Convención de nombres.
 Casos de Prueba Vs Corridas
 Diseño de Casos de pruebas

Módulo 2: “Verificación, Validación e Inspección”2 2

Módulo 1: Aseguramiento de la calidad del software 3
• Documentación es analizada para determinar “QUE”
se va a testear .

 Es definida como un ítem o evento que puede ser

verificada por uno o mas casos de prueba.
Ej: Función, una transacción, una característica , etc.

4
 Se establece la trazabilidad de las condiciones de
test con los Reqs o especificaciones para permitir :
◦ Un buen análisis de impacto cuando un requerimiento
cambia
◦ Un análisis de cobertura cuando se ejecutan las pruebas
dentro de set de pruebas

 Los riesgos identificados, y el enfoque del detalle

de las pruebas ayudan a seleccionar la técnica de
diseño a usar para los casos de pruebas.

5
• Los test cases ( casos de prueba) y set de datos son
creados y especificados
IEEE829:
Especificaciones del diseño de la prueba ( test design
specifications)
Especificaciones del caso de prueba ( test case
specifications).

6
 Son los que contiene un conjunto de datos de
entradas, condiciones de ejecución y resultados
esperados de las pruebas, identificados para hacer
una evaluación de los aspectos específicos de un
elemento objeto de prueba.

Un caso de prueba consiste en valores de entrada,

precondiciones de ejecución, resultado esperado y
post ejecución desarrollado para cubrir cierta
“Condición de testing”.
Cada caso de prueba esta asociado a un
escenario de un caso de uso en particular.

Los casos de pruebas deben ser escritos con el

detalle suficiente para que el tester pueda
empezar rápidamente a ejecutar pruebas y a
encontrar defectos.
Además, estos reflejan trazabilidad con:
 Los casos de uso,
 Las especificaciones suplementarias de
requerimientos
 Diseño del sistema

Un Caso de Prueba no es igual a un Caso de

Uso.
El Caso de Prueba extiende o amplía la información
contenida en un Caso de Uso.
 Es el proceso de transformación de los objetivos
generales de testing en condiciones de prueba y
casos de prueba.
 Es distinto que las técnicas de diseño que son
procedimientos usados para derivar o seleccionar
casos de pruebas

10
 Documentar especificando casos de pruebas
(objetivos, entradas, acciones, resultado esperado
y precondición) para un objeto a probar

11
 Son parte de las especificaciones de los casos de
prueba e incluye salidas, cambio de datos y
estados, y cualquier otra consecuencia de la
prueba.
 Si no se define un resultado esperado, cualquier
salida erronea puede ser confundida como
correcta.

12
 Datos de prueba: Datos que existen (por ejemplo,
en la base de datos) antes que la prueba sea
ejecutada, y que afecta o es afectada por el
componente o sistema dentro de la prueba.
 Herramienta para la preparación de los datos de
prueba:
◦ Un tipo de herramienta que habilita datos para ser
seleccionados en un prueba
 Obtiene datos de una base de datos existente.
 Crea, genera, manipula, modifica para la prueba.

13
Define una lista de variables y sus posibles
valores a introducir para la ejecución de las
pruebas, así como también los resultados
esperados de la ejecución para propósitos
comparativos.
Se pueden tomar en cuenta valores
específicos o describir rangos de valores.
Los Datos de Pruebas se utilizan como fuente
de engaño al objeto de prueba y así encontrar
errores.
Cabe destacar que cada caso de prueba
deberá ser ejecutado una vez por cada
combinación de valores.
Los casos de prueba son desarrollados, implementados,
priorizados o categorizados y organizados dentro de
especificación del procedimiento del test.

16
 Especificación del procedimiento de la prueba:
“Documentar especificando la secuencia de acciones
para la ejecución de una prueba.( Documento de caso
de prueba, test script (manual o automático))”

 No confundir con -Proceso de prueba: es el proceso

fundamental que comprende, planeación y control de la
prueba, análisis de la prueba, diseño de la prueba,
implementación de la prueba, ejecución de la prueba,
evaluación de las salidas, reporte y cierre de actividad.

Módulo 1: Aseguramiento de la calidad del software 17

 Están antes de ejecutar la prueba

Están antes de crear el set de ejecución

En la ejecución se actualiza la
planilla de defectos
“Debe estar documentado en algún lugar”
19
La convención de nombre debe establecerse en
el plan de testing,y tiene que tener una
coherencia tanto con la convención de
nombres empleadas para los Casos de Usos,
para los Requerimientos.
Es necesario establecer una similitud de
nombres en todos los niveles de testing.
Para los unitario, para los de sistemas, etc.
 Tener en cuenta lo siguiente:
◦ Relacionado al proyecto:
 El alcance abarca mas de un proyecto
 Proyecto esta dividido en módulos
 Proyecto esta dividido en funcionalidades
 Proyecto esta dividido en interfaces
◦ Relacionado al testing:
 Que tipo de testing se va a realizar
 Que niveles se va abarcar
 Se abarcará test automáticos y Manuales, o
Automáticos o Manuales.
 Ejemplo1:
Projecto_Funcionalidad_DescripcionsCU_Anro.
Projecto: Tango. (TAN)
Funcionalidad: Gestion de Ventas (Gvtas)
Subfuncionalidad: IVA ventas (IvaVentas)
Descripcion significativa Test : Reporte de Iva
Automatico o Manual.

Test Cases :
TAN_Gvtas_IvaVentas_A01.

Ejemplo2:
Nombre relacionado al requerimiento.
Req1: ReporteMensualIvaVentas.
Test_ReporteMensualIvaVentas_M01.
 Interfaces de usuarios
 Funciones de negocios
 Performance / Rendimiento
 Seguridad
 Estress
 Volumen
 Configuración
 Instalación.
 Usabilidad.
 Regresión.
Verifica que el software provea los servicios esperados

Lewis lo define como lo que el test demuestra que la

aplicación conocen los requerimientos del usuario.

La motivación del diseño de estos test es demostrar

que puede destruirse al probarse con datos validos
e inválidos.
A) Conocer los distintos escenarios tanto positivos
como negativos
1) Conocer las datos permitidos.
2) Conocer el flujo de la información permitida, lo que
debe ejecutarse primero
3) Conocer las excepciones.
4) Conocer los diferentes perfiles.
5) Conocer la tecnología de la aplicación.
6) Conocer el nivel de la aplicación.
A)Crear test considerando
1. Rehusó
2. Rapidez de ejecución.
3. Fácil mantenimiento
4. Integridad.
5. Claridad de los tipos de test que se están abarcando.
Tipo GUI test o Test de interfaces de usuario.

El objetivo de un buen diseño de GUI deberia consistir

en “look and feel” mira y siente, para el usuario de la
aplicación.

Un buen diseño tiene dos componentes, interacción y

apariencia.

Iteración relacionada como el usuario va a interactuar

con la aplicación y apariencia relacionada a como la
interfaz luce para el usuario.
A) Identificar los componentes de la aplicación:
1. Ventana principal y ventanas emergentes.
2. Menu
3. Caja de texto
4. Rotulos
5. Iconos
6. Controles ( check boxes, radio button, combo o lista
desplegable, lista desplegada, grilla).
A) Identificar lo permitido:
1. La ubicación de las ventana principal
2. Tamaño modificable
3. Lo habilitado y deshabilitado de controles, caja de texto y
menú.
4. EL orden de navegación
5. El uso de shorcut key or de teclas de rápido acceso.
6. El uso del botón derecho del mouse.
7. El color y el tamaño de la letra de los label.
8. Acceso a el menú (ctrl menú)
9. El uso de doble click.
10.La información precargada de los controles de listas
desplegables y desplegadas.
B) Que transacciones están permitidas:
1. Agregar
2. Consultar/ Buscar
3. Eliminar
4. Modificar
5. Ordenar
A)Crear test considerando
1. Rehusó
2. Rapidez de ejecución.
3. Fácil mantenimiento
4. Integridad.
5. Claridad de los tipos de test que se están abarcando.
 Crear el test verificando y validando que los
requerimientos de performance han sido
considerados.
 Para diseñar test de performance hay que
considerar la combinacion de caja blanca y caja
negra. Porque se necesita conocer como esta
trabajando internamente el sistema.
A)Debe analizar si se desea medir:
1. Uso del cpu.
2. USO de IO ( Entradas y Salidas)
3. Numero de IO por instrucción.
4. Uso de la memoria principal de almacenamiento.
5. Uso de la memoria secundaria de
almacenamiento.
6. Porcentaje de tiempo de ejecución por modulo.
7. Porcentaje de tiempo de espera entre operaciones
8. Tiempo de respuestas del sistema.
9. Numeros de transacciones por unidad de tiempo.
 El objetivo de este diseño debe ser evaluar la
presencia y apropiada funcionalidad de la
seguridad de la aplicación asegurando la
integridad y confidencialidad de los datos.
 La seguridad debe diseñarse demostrando
que los recursos son protegidos.
A)Considerar:
 Los permisos de acceso.
 La autorización.
 La autenticación.
 La encriptación.
 El tipo de las sesiones.
 La conectividad ( protocolos y sus relaciones).
 La auditoria
 B) Preguntas tipicas:
1. Los errores son registrados y capturados?
2. Es posible loguearse sin contraseña.
3. Hay usuarios que tiene superpoderes?
4. Se validan los password y estan encriptados?
5. Cual es el comportamiento del sistema al loguearse
repetidad veces mal?
6. Cual es el comportamiento del sistema al acceder de
forma remota?
El objetivo de un test de volumen es evaluar el
volumen de dato que va a ser manejado por el
sistema.
Este tipo de test suele confundirse con el de stress
Stress tiene como objeto carga pero en términos
de rangos, a través de cortos periodos de
tiempo.
En cambio el de volumen esta orientado a mostrar
que el sistema puede manejar el volumen de
dato especifico para el que fue creado.
A) Conocer los datos que van a ser ingresados en
cada transacción.
El objetivo es investigar el comportamiento que
tiene el sistema dentro de condiciones de
sobrecarga.
Es de particular interes conocer el impacto que
tiene en los tiempos de procesamiento.
A) Preguntarse si se conoce el numero máximo de
terminales que utilizaran el sistema o si están
especificadas dentro de un requerimiento.
B) Sobrecargar un test midiendo lo siguiente:
A) Buffer
B) Memoria
C) La conexión en red
D) Las impresoras
E) El uso del sistema
F) El almacenamiento en disco
C) Ejecutar multiples tareas de un simple requerimiento.
D) Conocer cuales son los defectos correctos o esperados
al ejecutar un simple test de stress.
E) Tratar de ejecutar repetidamente los test de estress.
 El objetivo es determinar cuan bien el usuario
puede usar y entender la aplicación.
A) Verificar si existen funciones o instrucciones
excesivamente complejas.
B) El grado de dificultad del procedimiento para la
installacion.
C) Los mensajes de error, el grado de complejidad de
los mismos.
D) La no estandarizacion de las GUI.
E) Dificultad en el procedimiento de logueo-
F) Ayuda no sensible al contexto o sin el detalle
suficiente.
G) Poca claridad en los default.
 El objetivo de este diseño es verificar la habilidad
de instalar el sistema correctamente.

 El procedimiento de instalación siempre es la

ultima actividad de desarrollo por lo cual recibe
menos prioridad en la actividad de desarrollo. Y
es la primera actividad que el cliente hace cuando
usa el sistema. Sin embargo la claridad y
consistencia del procedimiento de instalación es
sumamente importante como parte de la
documentación del sistema.
A)Considerar:
 Quien es el usuario? ( un técnico, un usuario
aficionado, un inexperto).
 Cuales son los ambientes que el procedimiento de
instalación soporta. ( ejemplo: plataformas,
software, hardware, redes, versiones)
 La instalación va a cambiar el ambiente actual del
usuario ( config.sys)
 La instalación es automática o requiere interacción
con el usuario?