Precondiciones
- Datos de Prueba: Datos que deben existir antes de que una prueba pueda ser ejecutada y que afectan o son afectados por el componente o sistema bajo prueba. – Ej. Una base de datos conteniendo instancias específicas de una entidad.
- Entorno de prueba: Elementos diferentes del objeto de prueba que son necesarios para conducir la prueba – Ej. Hardware, Herramienta de Testing, etc.
- Entrada de Prueba: El dato recibido por un objeto a prueba, durante la ejecución de la prueba desde una fuente externa la cual puede ser HW, SW o una acción humana.
- Resultado Esperado: El comportamiento predicho por la especificación u otra fuente, del objeto de prueba, bajo condiciones específicas. Se debe también especificar cómo se obtiene el resultado esperado.
- Oráculo: Es una fuente para determinar resultados esperados de un caso de prueba. Un oráculo puede ser un sistema existente, un usuario manual, o el conocimiento especializado de un individuo. Nunca debería ser el código. Ej. Simulación, experto en el dominio.
- Criterio para el Veredicto Pasa/Falla: Reglas de decisión usadas para determinar si un ítem de prueba ha pasado o fallado una prueba.
- Postcondición: Condiciones del entorno y estado que se deben cumplimentar después de la ejecución de una prueba o un caso de prueba, o un procedimiento de prueba.
- Caso de Prueba a Alto Nivel: Un caso de prueba que no tiene una implementación concreta, o valores concretos para la entrada de datos y el resultado esperado. Se usa Caso de Prueba Lógico como sinónimo.
- Caso de Prueba a Bajo Nivel: Es un caso de Prueba con valores concretos, que existen a nivel de implementación, para dato de entrada y resultado esperado. Los operadores lógicos de los casos de prueba a alto nivel son reemplazados por valores reales que corresponden al objetivo de los operadores lógicos.
- Conjunto de Pruebas Ideal: Es el menor subconjunto de todos los casos de prueba posibles que encuentra todos los defectos sobre un componente o sistema.
Prueba Exitosa
- Aquella que detecta un defecto aún no descubierto.
- Es aquella que encuentra muchos defectos, no lo opuesto.
- Un producto sin defectos daría como resultado que el testing no produzca pruebas exitosas y el consiguiente fracaso del testing.
Características de un Buen Caso de Prueba
- Fácil de repetir.
- Teniendo un fijo y preciso punto de inicio. El estado del sistema cuando se introdujo la entrada es conocido.
- Conociendo exactamente qué datos de entrada fueron introducidos y en qué secuencia.
- Representativo: el testing exhaustivo no es factible, con lo cual el caso de prueba debería ser representativo de un conjunto posible de casos de prueba.
- Ayuda a identificar fácilmente cuál es el defecto.
- Fácil de usar, entender o de realizar.
- Fácil de mantener.
- Trazable.
Derivación de Casos de Prueba
a) En Base a Documentos del Cliente
- Útil para el diseño de casos de prueba de funciones de negocio.
- Aconsejable para las pruebas de aceptación de usuario.
- Puede ser muy pobre para un testing funcional.
b) En Base a Documentos de Relevamiento
- Si se detectan omisiones o supuestos equivocados en el relevamiento, se debe informar para corregir.
- El diseño de casos de pruebas generado de estos documentos tiene que servir al testing y no hay que confundirlo con el diseño del desarrollo.
c) En Base a Especificaciones de Programación
- En el área de Testing se reciben las mismas especificaciones que se le envían al programador.
- Si un programador puede codificar en base a estas especificaciones, Testing debe poder diseñar casos de prueba y testear.
- Más completo que el diseño que se logra en base a documentos del cliente y de relevamiento.
- Más detalle.
d) En Base a Código
- En Testing se recibe el CÓDIGO.
- Adquiere las mismas ventajas y desventajas que esta técnica tiene.
- Es complementario al diseño de casos de prueba en base a documentación.
- Amplia cobertura del código y por supuesto del diseño.
- Se usa para el diseño de pruebas unitarias o de componentes.
