1. Datos de pruebas
1.1. Especificos
1.1.1. "Caso de pruebas con datos". Se define en concreto los datos para cada variable
1.2. Abstractos
1.2.1. No se define los datos a usarse, solo restricciones o consideraciones.
2. Estructura
2.1. ID
2.1.1. Código único, identifica el caso de prueba
2.2. Titulo
2.2.1. Objetivo del caso de prueba, tiene que ser breve
2.3. Pre-condiciones
2.3.1. Acciones previas a la ejecución del caso de prueba
2.4. Pasos a seguir
2.4.1. Secuencia de pasos a seguir al ejecutar el caso de prueba
2.5. Datos de prueba
2.5.1. Datos específicos o abstractos, que se utilizan para ejecutar en el caso de prueba
2.6. Resultados esperados
2.6.1. Directamente relacionado con el Titulo o sea el Objetivo. Debe corresponder con él
2.7. Estado
2.7.1. Puede ser
2.7.1.1. No ejecutado
2.7.1.1.1. Cuando se diseña el CP
2.7.1.2. Paso
2.7.1.2.1. Cumple con el objetivo
2.7.1.3. Fallo
2.7.1.3.1. No cumple con el objetivo
2.7.1.4. Bloqueado
2.7.1.4.1. Algo que impide la ejecución del CP
3. Recomendaciones para su ejecución
3.1. Prestar atención en que sector del sistema se deben ejecutar las pruebas. Generalmente esta información esta indicada en la descripción o titulo del caso de prueba
3.2. No olvidar las pre condiciones, si no lo hacemos el caso de prueba podría fallar debido a una omisión nuestra
3.3. Seguir paso a paso lo especificado en el caso de prueba validando si aplica cada uno de los resultados intermedios
3.4. En caso de ser necesario recuerda tomar evidencia de la ejecución
3.5. Si se detecta un incidente, además de cambiar el estado del caso de prueba "falló", incluir en las notas de ejecución el ID del defecto reportado en la herramienta de gestion de incidentes
4. Ejemplos
4.1. Abstracto
4.1.1. 1 - Ingresar a la aplicación con un usuario válido 2 - Crear un nuevo producto con stock positivo y un precio entre $1 y $100
4.2. Especifico
4.2.1. 1 - Ingresar a la aplicación con el usuario "admin" 2 - Crear un producto "Producto 1" con stock "10" y precio "$150"
5. Buenos Casos de pruebas
5.1. Objetivos
5.1.1. Llevar un proceso para detectar bugs relevantes y que se resuelvan dichos bugs
5.1.2. Crear documentación precisa
5.1.3. Ayudan a aprender del error y predecir su impacto
5.2. ¿Qué lo hace un buen caso de prueba?
5.2.1. Mas poderoso
5.2.1.1. Mayor probabilidad de encontrar un bug si esta allí
5.2.2. Mayor probabilidad de mostrar resultados significativos
5.2.3. Mas confiable
5.2.3.1. Alta probabilidad de lo que describa el caso ocurra
5.2.4. Refleja el uso real de la aplicación
5.2.5. Complejidad apropiada
5.2.5.1. En las primeras etapas es preferible casos de prueba mas simples ya que hay incidentes bloqueantes
5.2.6. Mas facil de evaluar
5.2.6.1. Determina de forma sencilla si "paso" o "fallo"