- Hay muchos puntos de vista para definir una caso de prueba, esto depende del contexto y de la experiencia del analista de pruebas Las práticas que se mostraran a continuacion no son una camisa de fuerza pero si que son una manera de construir buenos casos de prueba, entendibles para los desarroladores y los involucrados en el proyecto.
Entre mas atomico sea el caso de prueba, mejor sera su legibilidad y la correcion del error si este llega a detectarse.
El caso de prueba deber ser preciso, y debe testear algo exacto.
En el mundo de la automatización de pruebas de software, existe una lenguaje llamado Gherkin. Es un lenguaje comprensible por humanos y por ordenadores, con el que vamos a describir las funcionalidades, definiendo el comportamiento del software, sin entrar en su implementación. Se trata de un lenguaje fácil de leer, fácil de entender y fácil de escribir. Es un lenguaje de los que Martin Fowler llama 'Business Readable DSL', es decir, 'Lenguaje Específico de Dominio legible por Negocio'.
Como el dicho, "el que mucho abarca poco aprieta", asi pues es indispensable que el caso de prueba sea relativamente pequeño y que sus pasos sean atomicos. Si te encuentras escribiendo un caso de prueba largo, entonces es probable que estés tratando de probar demasiado. En ese caso, debe dividirlo en múltiples casos de prueba. Los casos de prueba largos se vuelven demasiado complicados y eso a su vez conduce a errores en la definición, implementación o ejecución.
Los casos de prueba deben ser independientes de los demas, cada caso debe ser autosuficiente y parametrizar todo lo que necesita para ejecutarse. El hecho de que sea independiente tmbién le permite al probador o desarrollador usar el caso de prueba para volver a realizar la prueba según sea necesario y probar un subconjunto de pruebas mientras espera que algún componente se complete o repare
Al leerse una caso de prueba no deben generarse confusiones, es por este motivo que debe tener las palabras necesarias y precisas.
Esto permite ejecutar pruebas de regresión, repeticiones de correcciones e integración continua donde las pruebas se ejecutan cada vez que el código modificado se integra en el producto.
Esta regla va junto con una definición clara. Al nombrar o identificar una característica, funcionalidad o widget, debe haber la misma terminología coherente dentro del caso de prueba y en todos los casos de prueba. Entonces, por ejemplo, si los casos de prueba describen las pruebas para la página de inicio de sesión para una clase universitaria, no deberían tener "usuario", "persona" y "estudiante" para referirse a la misma identidad. Uno de estos debe seleccionarse y usarse de manera consistente.