Trabajar con los analistas de sistemas y los desarrolladores para identificar qué escenarios y requerimientos necesitan casos de prueba nuevos o adicionales. Revisar los planes para asegurarse de comprender el alcance del desarrollo para la iteración actual y determinar los casos de prueba necesarios.

Para cada requerimiento es importante revisar los criterios de aceptación (si corresponde), los cuales guiarán el diseño de las pruebas.

Identificar diversos escenarios de ejecución del software y las condiciones que permiten la ejecución de los mismos como condiciones de prueba únicas. Considerar caminos alternativos o excepcionales desde una perspectiva positiva (casos felices) y negativa (casos de error).

Discutir el requerimiento o funcionalidad a probar con los analistas de sistema y otras partes interesadas para identificar otros criterios de aceptación para el requerimiento a probar que no se encuentren documentadas.

Enumerar o identificar los casos de prueba de forma única e identifique los resultados esperados del mismo.

Para cada caso de prueba, documentar una breve descripción con el resultado esperado. Asegurarse de que un lector casual pueda comprender claramente la diferencia entre los casos de prueba. Tener en cuenta las pre-condiciones y post-condiciones que se aplican a cada caso de prueba. Opcionalmente, describir la serie de pasos que permiten la ejecución del caso de prueba.

Verificar que los casos de prueba cumplan con las Pautas para la especificación de casos de prueba.

Dependiendo de la forma en el cual está especificado el requerimiento a probar, algunas de las siguientes técnicas de generación de casos de prueba pueden resultar de ayuda:

• Guia para la generación de casos de prueba a partir de casos de uso.
• Guía para la generación de casos de prueba a partir de historias de usuario.
  

Revise los casos de prueba con los analistas de sistemas y desarrolladores responsables del requerimiento / funcionalidad relacionada. Otras partes interesadas, así como expertos del negocio ​​también pueden participar.

Preguntar a los participantes si están de acuerdo en que si ese caso de prueba "pasa", éste evalúa de forma correcta la implementación del requerimiento / funcionalidad. Relevar e identificar ideas de prueba adicionales de analistas y partes interesadas para asegurarse de que se comprende adecuadamente el comportamiento esperado del requerimiento.

Durante la revisión, asegúrese de que:

• Los requerimientos planificados para la iteración actual tienen casos de prueba.
• Todos los participantes están de acuerdo con los resultados esperados de los casos de prueba.
• No hay otras condiciones de satisfacción para el requerimiento que se está probando, que indiquen un caso de prueba faltante o un requerimiento faltante.