Definición de casos de prueba y prioridades

Determina qué probar, define tus casos de prueba y establece prioridades.

Ramona Schwering

En la entrada anterior, aprendiste sobre las estrategias de prueba, la cantidad de pruebas necesarias para probar una aplicación y cómo encontrar la mejor opción para obtener la mayor confianza en los resultados teniendo en cuenta tus recursos. Sin embargo, esto solo nos da una idea de cuánto probar. Aún debes determinar exactamente qué probar. Los siguientes tres criterios pueden ser útiles para comprender qué esperar de una prueba y ver qué tipo de prueba y qué nivel de detalle podrían ser más adecuados:

1. Cuida tu ruta ideal. Esta es la historia de usuario más genérica o principal de tu aplicación, en la que el usuario notará un error muy rápido.
2. Decide cuidadosamente el nivel de detalle. Entra en más detalles si tu caso de uso es vulnerable o si un error causaría un daño importante.
3. Prioriza las pruebas de nivel inferior, como las pruebas de unidades y de integración, sobre las pruebas de extremo a extremo de nivel superior siempre que sea posible.

En el resto de este artículo, se exploran estos criterios y cómo se aplican a medida que defines los casos de prueba.

¿Qué es un caso de prueba?

En el desarrollo de software, un caso de prueba es una secuencia de acciones o circunstancias que se idean para confirmar la eficacia de un programa o una aplicación de software. El objetivo de un caso de prueba es garantizar que el software funcione según lo planificado y que todas sus funciones y características funcionen correctamente. Los verificadores o desarrolladores de software suelen crear estos casos de prueba para garantizar que el software cumpla con los requisitos y especificaciones especificados.

Cuando se ejecuta un caso de prueba, el software realiza una serie de verificaciones para garantizar que produzca los resultados deseados. Mientras lo hace, una prueba realiza las siguientes tareas:

• Verificación: Es el proceso de verificar el software en detalle para garantizar que funcione sin errores. Es fundamental determinar si el producto creado cumple con todos los requisitos no funcionales necesarios y logra con éxito su propósito previsto. La pregunta que responde es: “¿Estamos creando el producto de la manera correcta?”.
• Validación: Es el proceso de garantizar que el producto de software cumpla con los estándares necesarios o los requisitos de alto nivel. Implica verificar si el producto real se alinea con el producto esperado. En esencia, respondemos la pregunta: “¿Estamos creando el producto adecuado para los requisitos del usuario?”.

Supongamos que el programa no genera el resultado esperado. En ese caso, el caso de prueba será el mensajero, por lo que se informará un resultado incorrecto, y el desarrollador o verificador deberá investigar el problema y encontrar una solución. Piensa en las verificaciones y acciones como las rutas que sigue la computadora, independientemente del tipo de prueba. Los grupos de datos de entrada o condiciones que se usan para la verificación se denominan "clases de equivalencia". Deberían obtener un comportamiento o resultados similares del sistema en prueba. Las instrucciones específicas que se ejecutan dentro de una prueba pueden variar, pero deben coincidir con las actividades y aserciones que se realizan en la prueba.

Rutas de prueba: tipos típicos de casos de prueba

En el desarrollo de software, un caso de prueba es una situación de ejecución de código a partir de la cual se espera y prueba un comportamiento determinado. Por lo general, hay tres situaciones a partir de las cuales se pueden crear casos de prueba.

El primero es el más conocido, que probablemente ya estés usando. Es la ruta viable, también conocida como “escenario ideal” o “ruta de oro”. Define el caso de uso más común de tu función, aplicación o cambio, la forma en que debería funcionar para el cliente.

A menudo, se omite la segunda ruta de prueba más importante que debes cubrir en tus casos de prueba porque es incómoda, como su nombre puede implicar. Es la “ruta aterradora” o, en otras palabras, la prueba negativa. Esta ruta de acceso se orienta a situaciones que hacen que el código se comporte de manera incorrecta o entre en un estado de error. Probar estas situaciones es especialmente importante si tienes casos de uso muy vulnerables que imponen un alto riesgo a las partes interesadas o a los usuarios.

Hay otras rutas que te recomendamos conocer y considerar usar, pero que, por lo general, no son tan comunes. En la siguiente tabla, se resumen:

Existen varios métodos para categorizar esas rutas. Estos son dos enfoques comunes:

• Partición de equivalencia: Un método de prueba que clasifica los casos de prueba en grupos o particiones y, como resultado, ayuda a crear clases de equivalencia. Esto se basa en la idea de que, si un caso de prueba en una partición descubre un defecto, es probable que otros casos de prueba en la misma partición revelen defectos similares. Como todas las entradas de una clase de equivalencia específica deben mostrar un comportamiento idéntico, puedes disminuir la cantidad de casos de prueba. Obtén más información sobre la partición de equivalencia.
• Análisis de límites. Un método de prueba, también conocido como análisis de valores límite, que examina los límites o extremos de los valores de entrada para encontrar posibles problemas o errores que puedan surgir en los límites de las capacidades o restricciones del sistema.

Práctica recomendada: Cómo escribir casos de prueba

Un caso de prueba clásico escrito por un verificador contendrá datos específicos para ayudarte a comprender el contenido de la prueba que deseas realizar y, por supuesto, ejecutarla. Un verificador típico documentaría sus esfuerzos de prueba en una tabla. Hay dos patrones que podemos usar en esta etapa, que nos ayudan a estructurar nuestros casos de prueba y, más adelante, nuestras pruebas:

• Patrón organizar, actuar, afirmar. El patrón de prueba “organizar, actuar, afirmar” (también conocido como “AAA” o “Triple A”) es una forma de organizar las pruebas en tres pasos distintos: organizar la prueba, realizarla y, por último, sacar conclusiones.
• Patrón qué, cuándo, luego. Este patrón es similar al patrón AAA, pero tiene algunas raíces en el desarrollo orientado a la conducta.

En artículos futuros, analizaremos estos patrones con más detalle, en cuanto abordemos la estructura de una prueba. Si quieres profundizar en estos patrones en esta etapa, consulta estos dos artículos: Arrange-Act-Assert: Un patrón para escribir buenas pruebas y Given-When-Then.

Según todo lo que aprendiste en este artículo, la siguiente tabla resume un ejemplo clásico:

En las pruebas automatizadas, no es necesario que documentes todos estos casos de prueba de la manera en que lo hace un verificador, aunque sin duda es útil hacerlo. Puedes encontrar toda esta información en la prueba si prestas atención. Entonces, traduzcamos este caso de prueba clásico en una prueba automatizada.