Cómo escribir un caso de prueba
Qué contiene un caso de prueba en Qably, qué lo hace bueno, cómo elegir su prioridad y cómo llegan los casos que propone Aeris.
Un caso de prueba describe un comportamiento de su producto: qué debe cumplirse antes, qué hacer y qué debe ocurrir. El código de la prueba decide si ese comportamiento sigue funcionando; el caso explica para qué sirve la prueba, de modo que una persona que no la escribió pueda entender un fallo.
Qué contiene un caso
Estos campos se completan al agregar o editar un caso en una suite. Aeris propone todos menos el estado.
| Campo | Qué escribir |
|---|---|
| Título | El comportamiento, con un verbo en presente y la condición esperada: "rechaza un token vencido". |
| Objetivo | Qué verifica el caso, en una frase. |
| Precondiciones | Lo que ya debe ser cierto antes del primer paso: la cuenta, los datos, la configuración. |
| Pasos | Las acciones en orden, una por línea. |
| Resultado esperado | Lo que muestra el usuario o el sistema cuando los pasos tienen éxito. |
| Prioridad | Crítico, Alto, Medio o Bajo. |
| Estado | Activo, Borrador o Deprecado. |
Un caso es manual o automatizado. Una persona ejecuta el caso manual y registra su resultado en una ejecución manual. El caso automatizado está vinculado a una prueba de su repositorio y sus resultados provienen de los reportes que envía su CI. Qably considera un caso completamente documentado cuando tiene título, objetivo, pasos y resultado esperado; las precondiciones son opcionales.
Qué hace bueno a un caso
Cinco hábitos separan un caso útil de uno que solo existe:
- Un comportamiento por caso. Si el título necesita una "y", divídalo en dos. Es la misma regla de nombrar las pruebas.
- Independiente. El caso prepara sus propios datos y no depende de que otro se haya ejecutado antes.
- Datos y precondiciones explícitos. Escriba el tipo de cuenta, el monto o la fecha. "Un usuario válido" obliga al lector a adivinar.
- Un resultado verificable. Indique qué aparece, cambia o se devuelve: "el total muestra 90.00", no "funciona".
- Un título con verbo en presente. "Rechaza un token vencido", "aplica un código de descuento". En una prueba automatizada, el título parte del nombre de la prueba, que además forma parte de la identidad del caso.
Un caso débil y uno bueno
Ambos casos cubren la misma funcionalidad. El débil solo puede ejecutarlo su autor.
| Campo | Caso débil | Caso bueno |
|---|---|---|
| Título | Login funciona | Inicia sesión con credenciales válidas y abre el panel |
| Objetivo | Probar el login | Verificar que un usuario registrado llega al panel al ingresar su correo y su contraseña correctos |
| Precondiciones | Existe un usuario | La cuenta [email protected] existe y está activa |
| Pasos | Iniciar sesión | Abrir la página de acceso; ingresar el correo y la contraseña correcta; seleccionar Iniciar sesión |
| Resultado esperado | Funciona | Se abre el panel y muestra el nombre de la cuenta |
La versión buena nombra sus datos, enumera pasos que cualquiera puede repetir y tiene un resultado que puede fallar de forma visible.
Cómo elegir la prioridad
La prioridad indica al equipo qué mirar primero cuando fallan varios casos. Estos niveles son una práctica general de QA, así que ajústelos a su producto:
- Crítico: el producto queda inutilizable o hay dinero, datos o accesos en riesgo. Por ejemplo, iniciar sesión, pagar, guardar un pedido.
- Alto: falla una funcionalidad principal, pero existe una alternativa.
- Medio: una funcionalidad secundaria o un camino poco frecuente.
- Bajo: detalles cosméticos y combinaciones poco probables.
Una prueba rápida: si este caso fallara el día de un lanzamiento, ¿detendría usted el lanzamiento? Si la respuesta es sí, es Crítico o Alto. Si todo es Crítico, nada destaca.
Cómo llegan los casos a Qably
Un caso llega a Qably de tres maneras:
- Escrito a mano. Agregue un caso a una suite y complete los campos anteriores. Es un caso manual.
- Reportado por su CI. La primera vez que un reporte incluye una prueba que Qably no conocía, crea un caso en estado Borrador, con el título tomado del nombre de la prueba y sin pasos. La suite lo muestra como Sin documentar hasta que se documente.
- Propuesto por Aeris. Cuando un push modifica un archivo de prueba, Aeris, el asistente de IA de Qably, lo lee en el repositorio conectado y propone casos documentados. Las propuestas esperan en la Bandeja de revisión y nada pasa a ser oficial hasta que una persona lo aprueba.
Tras un push, Aeris solo lee los archivos que coinciden con los patrones de archivos de prueba del proyecto. Por defecto son *.spec.ts y *.test.ts; edítelos en la vista Repositorio si sus pruebas se llaman de otra forma.
La Bandeja de revisión muestra cada propuesta con el código fuente del que salió. Si la propuesta coincide con un caso existente, aprobarla publica una nueva versión de ese caso en lugar de crear un segundo caso. Una propuesta sin pasos no puede publicarse, y Rechazar descarta la que no desee.
Para un caso automatizado que ya existe, Documentar este caso pide a Aeris que proponga su documentación, y la propuesta llega a la misma bandeja. Cuando una persona cambia el título, los pasos o el resultado esperado de un caso, Aeris lo deja intacto al documentar una suite.
Importante: Revise una propuesta contra el requisito, no solo contra el código de la prueba. Aeris describe lo que hace una prueba; si la prueba es incorrecta, una propuesta aprobada publica ese error como caso oficial.
Cuando ya tenga casos, qué tipos de errores buscar ayuda a encontrar los que faltan, y las señales de un caso indican cuáles necesitan trabajo.