Definición de casos de prueba y prioridades

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

Ramona Schwering

En la publicación 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 ganar la mayor confianza en los resultados, teniendo en cuenta tus recursos. Sin embargo, esto solo nos da una idea de cuánto debemos probar. Aún debes determinar exactamente qué probar. Los siguientes tres criterios pueden ser útiles para comprender qué esperar en una prueba y ver qué tipo de prueba y nivel de detalle podrían ser más adecuados:

1. Cuida tu camino 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ápidamente.
2. Decide con cuidado el nivel de detalle. Proporciona más detalles si tu caso de uso es vulnerable o si un error podría causar un daño significativo.
3. Prioriza las pruebas de nivel inferior, como las de integración y unidades, por 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 la hora de definir 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 diseñan para confirmar la efectividad 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 planeado y que todas sus características y funciones se ejecuten correctamente. Los verificadores o desarrolladores de software suelen crear estos casos de prueba para garantizar que el software cumpla con las especificaciones y los requisitos especificados.

Cuando se ejecuta un caso de prueba, el software realiza una serie de verificaciones para garantizar que produce los resultados deseados. Mientras haces eso, una prueba cumple con las siguientes tareas:

• Verificación. El proceso de verificar minuciosamente el software para garantizar que funcione sin errores. Es crucial 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 correctamente?”
• Validación. El proceso de garantizar que el producto de software cumpla con los estándares o requisitos de alto nivel necesarios. Implica verificar si el producto real se alinea con el esperado. Básicamente, respondemos la pregunta: "¿Estamos creando el producto correcto para los requisitos del usuario?".

Supongamos que el programa no entrega el resultado esperado. En ese caso, el caso de prueba será el sistema de mensajería, por lo que se informará un resultado fallido, y el desarrollador o verificador deberá investigar el problema y encontrar una solución. Piensa en las verificaciones y acciones como rutas que sigue la computadora, independientemente del tipo de prueba. Los grupos de datos de entrada o las condiciones que se usan para la verificación se denominan "clases de equivalencia". Deberían obtener un comportamiento o resultados similares del sistema a prueba. Las rutas de acceso específicas ejecutadas dentro de una prueba pueden variar, pero deben coincidir con las actividades y aserciones realizadas 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 determinado comportamiento. Por lo general, hay tres situaciones a partir de las cuales crear casos de prueba.

El primero es el más conocido, que probablemente ya estés usando. Es el camino ideal, también conocido como "situación de día feliz" o "ruta de éxito". 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.

La segunda ruta de prueba más importante que debes cubrir en tus casos de prueba suele omitirse porque resulta incómoda, como podría implicar su nombre. Es el “camino aterrador” o, en otras palabras, la prueba negativa. Esta ruta se orienta a situaciones que provocan que el código se comporte de manera incorrecta o ingrese un estado de error. Probar estas situaciones es especialmente importante si tienes casos de uso muy vulnerables que impongan un alto riesgo para las partes interesadas o los usuarios.

Hay otras rutas que quizás desees conocer y considerar usar, pero, por lo general, son menos comunes. En la siguiente tabla, se resumen estos elementos:

Hay varios métodos para categorizar esas rutas. Los dos enfoques más comunes son los siguientes:

• 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, otros casos de prueba en la misma partición probablemente revelarán defectos similares. Como todas las entradas dentro de una clase de equivalencia específica deben tener un comportamiento idéntico, puedes disminuir la cantidad de casos de prueba. Obtén más información sobre la partición de equivalencia.
• Limita el análisis. Es un método de prueba, también conocido como análisis del valor de los límites, que examina los límites o extremos de los valores de entrada para encontrar cualquier problema o error potencial que pueda surgir dentro de los límites de capacidades o restricciones del sistema.

Práctica recomendada: Escribe casos de prueba

Un caso de prueba clásico escrito por un verificador contendrá datos específicos que te ayudarán a captar el contenido de la prueba que quieras realizar y, por supuesto, ejecutarla. Un verificador típico documentaría sus esfuerzos 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, a nuestras propias pruebas:

• Patrón Arrange, act, assert. El patrón de prueba "organizar, actuar, asertar" (también conocido como "AAA" o "Triple A") es una forma de organizar las pruebas en tres pasos distintos: organizar la prueba, luego realizarla y, por último, pero no menos importante, sacar conclusiones.
• Dado, cuándo, luego. Este patrón es similar al de AAA, pero tiene algunas raíces en el desarrollo impulsado por el comportamiento.

En los próximos artículos, se detallarán estos patrones en cuanto se aborde la estructura de una prueba en sí. Si quieres profundizar más en estos patrones en esta etapa, consulta estos dos artículos: Arrange-Act-Assert: Un patrón para escribir pruebas eficaces y Given-When-then.

Según toda la información obtenida en este artículo, la siguiente tabla resume un ejemplo clásico:

En las pruebas automatizadas, no es necesario documentar todos estos casos de prueba como lo necesita un verificador, aunque sin duda hacerlo es útil. Si prestas atención, puedes encontrar toda esta información en la prueba. Ahora, traduzcamos este caso de prueba clásico a una prueba automatizada.