Caso de prueba: ¿qué es un caso de prueba y cómo escribirlo?

Las pruebas de software y aplicaciones incluyen la verificación de sus requisitos funcionales y no funcionales. Para validar estos requisitos, los probadores de software deben crear casos de prueba eficaces utilizando diversas técnicas de diseño de pruebas de caja blanca/pruebas de caja negra.

En este texto hablaremos en detalle de los casos de prueba, sus distintos atributos y tipos.

Índice

1. ¿Qué es un caso de prueba?
2. Atributos de los casos de prueba
3. ¿Cómo escribir buenos casos de prueba?

¿Qué es un caso de prueba?

Un caso de prueba es un conjunto de condiciones para evaluar una característica concreta de un producto de software con el fin de determinar su conformidad con los requisitos de la empresa.

El caso de prueba contiene supuestos, valores de entrada y resultados esperados en una forma documentada que abarca diferentes escenarios de prueba.

Una vez creados los casos de prueba a partir de los requisitos, el trabajo de los probadores consiste en ejecutarlos. Los probadores leen todos los detalles del caso de prueba, realizan los pasos de la prueba y luego marcan el caso de prueba como aprobado o suspenso en función del resultado esperado y real.

Atributos del caso de prueba

Veamos los distintos atributos de un caso de prueba que lo componen y lo hacen más fiable, claro y conciso, evitando o reduciendo así cualquier tipo de redundancia.

1. TestCaseId – identificador único del caso de prueba. Se trata de un campo obligatorio que identifica de forma única el caso de prueba, por ejemplo TC_01.
2. Resumen de la prueba – Un resumen inequívoco del caso de prueba. Este campo es opcional. Normalmente, los casos de prueba tienen un campo «Resumen de la prueba» o un campo «Descripción».
3. Descripción – Descripción detallada del caso de prueba. Este campo define la finalidad del caso de prueba, por ejemplo verifica que el usuario puede conectarse con un nombre de usuario y una contraseña válidos.
4. Prerrequisito o condición previa – Conjunto de requisitos previos que deben cumplirse antes de poder realizar los pasos de la prueba. Por ejemplo, al probar la funcionalidad de una aplicación tras el inicio de sesión, podemos tener un campo de precondición que diga «El usuario debe haber iniciado sesión en la aplicación».
5. Pasos de la prueba – Pasos detallados para ejecutar un caso de prueba. Este es el campo más importante del caso de prueba. El probador debe esforzarse por que los pasos de la prueba sean claros e inequívocos, de modo que otra persona pueda seguirlos mientras se realiza la prueba.
6. Datos de prueba – el valor de los datos de prueba utilizados en el caso de prueba. Por ejemplo, al probar la función de inicio de sesión, el campo de datos de prueba puede contener el valor real del nombre de usuario y la contraseña que se utilizarán durante la ejecución de la prueba.
7. Resultado esperado – El resultado esperado en el que marcamos la prueba como superada. Según los pasos de prueba realizados y los datos de prueba utilizados, llegamos al resultado esperado, por ejemplo el usuario debe conectarse correctamente y navegar hasta la página de inicio.
8. Resultado real: el resultado real después de realizar los pasos de la prueba. Este campo sólo se rellena durante la ejecución de la prueba. En este campo escribimos el resultado real observado durante la ejecución del caso de prueba.
9. Resultado de la prueba: el estado de aprobado/no aprobado de la prueba. En función del resultado esperado y del resultado real, el caso de prueba se marca como satisfactorio o no satisfactorio.
   Además del valor pasa/no pasa, también podemos tener otros valores, como Aplazado, cuando un caso de prueba se marca para una ejecución posterior por algún motivo. Bloqueado cuando la ejecución del caso de prueba está bloqueada por algún otro motivo en la aplicación.
10. Estado de automatización – Identificador de automatización: si la aplicación está automatizada o no. Se trata de un campo opcional que sólo se utiliza cuando tenemos automatización en el proyecto.
11. Fecha – La fecha en que se realizó la prueba. Este campo ayuda a realizar el seguimiento de diferentes iteraciones a lo largo de múltiples ciclos de ejecución de pruebas.
12. Ejecutado por: nombre de la persona que ejecuta el caso de prueba. Este campo ayuda cuando varios miembros del equipo están trabajando en una actividad de ejecución de pruebas.

¿Cómo escribir buenos casos de prueba?

1. Técnica de diseño de pruebas

Sigue la técnica de diseño de pruebas que sea más adecuada para tu organización o las necesidades específicas de tu proyecto, como – el análisis de umbrales, la distribución de clases de equivalencia, las pruebas de tablas de decisión, etc. Esto garantizará que se apliquen normas y prácticas bien documentadas en el desarrollo de los casos de prueba.

2. Pruebas claras y concisas

Resumen del caso de prueba, descripción, pasos de la prueba, resultados esperados, etc. debe redactarse de forma clara y concisa. Deben ser fácilmente comprensibles para las distintas partes implicadas en las pruebas.

3. Nomenclatura uniforme

Para mantener la coherencia entre los casos de prueba, debemos seguir una nomenclatura uniforme y un conjunto de normas al escribir los casos de prueba.

4. Casos de prueba básicos/atómicos

Haz que los casos de prueba sean lo más básicos posible. Por tanto, un caso de prueba debe probar sólo una unidad de funcionalidad, sin combinar ni solapar varias partes comprobables.

5. No dejes lugar a la ambigüedad

Escribe casos de prueba con un conjunto claro de instrucciones. {homepageURL}Por ejemplo – en lugar de «Abrir página de inicio», escribe – «Abre la página de inicio – http://www. .com en tu navegador y pulsa intro».

6. Sin requisitos previos

Cuando escribas casos de prueba, no asumas ninguna funcionalidad, requisito previo o estado de la aplicación. En su lugar, asigna casos de prueba a los documentos necesarios, como – SRS, documentos de casos de uso, etc.

7. Evita la redundancia

No repitas los casos de prueba, pues supone una pérdida de tiempo y recursos. Esto puede lograrse con casos de prueba bien planificados y categorizados.

8. Pruebas trazables

Utiliza una matriz de trazabilidad para asegurarte de que el 100% de la funcionalidad de la aplicación en el ámbito de las pruebas está cubierta en los casos de prueba.

9. Garantizar la cobertura de los diferentes aspectos del software

Asegúrate de que en los casos de prueba se cubren, además de la funcionalidad, distintos aspectos del software sometido a prueba, como el rendimiento, la usabilidad, la robustez, etc. creando casos de pruebas de rendimiento y puntos de referencia, casos de pruebas de usabilidad, casos de pruebas negativas, etc.

10. Datos de la prueba

Los datos de prueba utilizados en las pruebas deben ser tan diversos y tan próximos al uso en tiempo real como sea posible. Si tienes datos de prueba diversos, podrás elaborar casos de prueba más fiables.