CURSO
SOFTWARE
TESTING
UNIDAD 3
Diseño de Casos de Prueba (TC)
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
En esta unidad vamos aprender cómo se diseñan
PRESENTACIÓN los casos de prueba (Test Cases)
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
1. – Principios del Testing
2. – Características de un Test Case
TEMARIO
3. – Diseño de Test Cases.
4. – Ejemplos.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 1: La prueba muestra la presencia de defectos.
● La prueba puede mostrar que los defectos están presentes, pero no puede probar que
no hay defectos.
● La prueba reduce la probabilidad de los defectos no descubiertos restantes en el
software pero, incluso si no se encuentran defectos, no es una prueba de corrección.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 2 - La prueba exhaustiva es imposible.
● Probar todo (todas las combinaciones de entradas y de precondiciones) no es factible
a excepción de casos triviales.
● En vez de la prueba exhaustiva, usa el riesgo y prioridades para enfocar los
esfuerzos de prueba.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 3 - La prueba temprana.
● Las actividades de prueba deben comenzar tan pronto como sea posible en el ciclo de
vida del desarrollo del software o del sistema y deben enfocarse en los objetivos
definidos.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 4 - El agrupamiento de defectos
● Un número pequeño de módulos contiene la mayoría de los defectos.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 5 - La paradoja del pesticida (eficacia de las pruebas).
● Las mismas pruebas se repiten una y otra vez, eventualmente el mismo conjunto de
casos de prueba no encontrará más cualquier nuevo bug.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Principios del Testing
Principio 6 - La prueba es dependiente del contexto.
● La prueba se hace diferentemente en diversos contextos.
Principio 7 - Falacia de la ausencia de errores.
● Encontrar y arreglar defectos no ayuda si el sistema construido es inutilizable y no
cumple las necesidades y expectativas de los usuarios.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Test Cases de un sistema de facturación
● Que permita identificar al cliente
● Que permita cargar artículos, cantidad y precio
● Que permita ver el importe total de la operación con sus impuestos
● Que permita guardar el comprobante
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Características de los TC
● Testeable: Independiente del autor y del ejecutor, debe ser claro.
● Completo: No debe asumir cosas que debe hacer el ejecutor del caso de prueba,
tampoco debe tener información innecesaria.
● Reutilizable: Los casos de prueba deberían poder ser reutilizables para la prueba de otra
funcionalidad
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Características de los TC
Formalmente los casos de prueba escritos consisten principalmente en tres partes con
subdivisiones:
A. Visión general: contiene información general acerca de los Casos de Prueba.
B. Actividades (de los casos de prueba).
C. Resultados.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Visión General
1. Identificador (ID): es un identificador único para futuras referencias.
2. Caso de prueba dueño/creador es el nombre del analista o diseñador de pruebas.
3. Versión la actual definición del caso de prueba (ya que podría modificarse en el futuro).
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Visión General
4. Nombre:
● Debe tener un título entendible por cualquier persona
● Debe contener las palabras clave que faciliten su búsqueda
● No deben existir dos casos de prueba con la misma descripción
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Visión General
5. Identificador de requerimientos: Incluido por el caso de prueba. Puede ser
identificador de casos de uso o especificación funcional. (REQUISITOS)
6. Propósito: Contiene una breve descripción del propósito de la prueba, y la
funcionalidad que chequea.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Visión General
Ejemplo: Permitir login de usuario.
● Funcionalidad a chequear: De un usuario existente pedir ingreso de password.
● Validar la coincidencia de la password ingresada y la asignada al usuario.
7. Dependencias: si el caso de test depende de la ejecución anterior de otro
caso de prueba o proceso, aquí se indica el mismo.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Visión General
8. Prioridad: indica qué tan importante es la realización del caso de prueba. La clasificación
se realiza luego del análisis de riesgo.
● Alta: Son los que nos aseguran que la aplicación se puede usar. Generalmente
imposibilitan realizar otras pruebas.
● Media: Condiciones alternativas.
● Baja: Agregan calidad al producto. No son bloqueantes.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Resultados
1. Resultados esperados contiene una descripción de lo que el analista debería ver tras
haber completado todos los pasos de la prueba.
Ejemplo: El sistema presenta un mensaje de bienvenida y lleva a otra pantalla que posee
un menú para el usuario
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Resultados
2. Resultados reales: Contienen una breve descripción de lo que el analista encuentra
después de que los pasos de prueba se hayan completado.
Esto se sustituye a menudo con un Correcto/Fallido.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Diseño de los TC – Resultados
Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se debe
enumerar en esta columna.
Ejemplo:
● OK: El sistema se comporta según lo esperado.
● NO OK: El sistema arroja un error luego de presionar ‘ingresar’. Ver defecto 1122.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas
● Cadenas.
● Números.
● Fechas.
● Listas desplegables.
● Radio Button.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas
● Check Button.
● Importar Archivos.
● Desde Base de Datos.
● Desde Web.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas - Cadenas
● Cadena vacía.
● Cadena consistente únicamente de un espacio en blanco.
● Cadena que empieza o termina con un espacio en blanco.
● Cadena con carácter especiales como escape, numeral, mayor
y menor, etc.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas - Cadenas
● Cadena con valores en mayúsculas y minúsculas.
● Cadena con pocos caracteres.
● Cadena con el máximo de caracteres permitidos.
● Cadena con inyección de código SQL (por ej. “ or 1=1 ”).
● Cadena con caracteres extranjeros (tilde, ñ, etc).
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas - Números
● Campo vacío.
● Cero.
● Números fuera del rango.
● Números negativos.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas - Números
● Comienzo con cero.
● Valores decimales.
● Sintácticamente inválidos
(incluir letras).
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas - Fechas
● Campo vacío
● Formato incorrecto
● Fechas inválidas
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas -
Listas Desplegables
● Sin seleccionar
● Selección un elemento
● Selección varios elementos
● Tipeo de elemento existente
● Tipeo de elemento inexistente
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas -
Radio Button
● Sin seleccionar
● Un objeto seleccionado
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas -
Check Button
● Sin seleccionar
● Seleccionar varios
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas
Importar archivo
● En blanco
● De 0 bytes
● Archivo grande
● Archivo con nombre largo
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Tipos de Entradas
Importar archivo
● Archivo con nombre con espacios
● Archivo con nombre con caracteres
no convencionales
● Archivo con datos inválidos
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Reporte de Fallos
● ID de Fallo: Un identificador único
● Test Case Asociado: Numero de TC
● Reporter: Tester que lo reportó. Esto facilitará la comunicación
entre el que lo reportó y el que lo va a solucionar.
● Software y Release: Modulo en donde se detecto la falla
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Reporte de Fallos
● Ambiente: Indica sobre que ambiente de pruebas ocurrió la falla.
● Plataforma y Sistema Operativo: Indica sobre las características
de hard y sistema operativo de la máquina en donde se detectó la
falla.
● Navegador: Indica el navegador que se estaba utilizando cuando se
detectó la falla.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Reporte de Fallos
● Prioridad: Indica la urgencia.
● Severidad: Indica el impacto de la falla sobre la aplicación (Bloqueante)
● Resumen: Describe el error exacto.
● Esperado: Descripción de que debería ocurrir en lugar de la falla.
UNIDAD 3
DISEÑO DE CASOS
DE PRUEBA (TC)
Reporte de Fallos
● Pasos: Detalle de los pasos realizados para poder reproducir la falla,
junto con los datos utilizados y la generación del escenario para que
ocurra el bug.
● Adjuntos: Cualquier material complementario que sirva para ayudar al
desarrollador a solucionar la falla.
¡¡Muchas gracias!