QA The Other WayGarantía de calidad para la era de las pruebas escritas por IA. QA The Other Way.
QA práctica

Una comprobación flexible también necesita una parada firme.

Recoge fallos independientes sin dejar que un requisito incumplido autorice la siguiente acción.

5 min de lecturaQA The Other Way
Diagrama original de observaciones y una barrera firme antes de la acción dependiente.
Ilustración editorial original.
Vídeo ilustrativo de este artículo. Texto en pantalla en inglés; seleccione subtítulos para este idioma.

Edición traducida. Los identificadores técnicos permanecen en su forma original.

Recoge fallos independientes sin dejar que un requisito incumplido autorice la siguiente acción.
Ejemplo local del ejecutor con datos inventados, no una interfaz de cliente o proveedor.

Una página de revisión tiene el título y el estado del borrador equivocados. Una aserción normal se detiene en el primer error; una flexible puede recoger ambos. Es información útil, pero la prueba sigue fallida. Continuar la ejecución no autoriza continuar el flujo del producto.

Esta guía usa la documentación de aserciones de Playwright con una página local inventada. No hay aprobación real, envío ni cuenta. Buscamos varias observaciones independientes y una barrera antes del botón que representa el siguiente paso.

Recoge observaciones que sigan teniendo sentido

Playwright documenta que las aserciones flexibles fallidas no terminan la ejecución, pero hacen fallar la prueba. Funcionan con su ejecutor de pruebas. Un script de navegador con otra biblioteca no obtiene ese comportamiento automáticamente.

Usa estas comprobaciones si la observación posterior sigue siendo válida tras la anterior. Un título incorrecto no impide inspeccionar un estado independiente. Un registro previo ausente es distinto: leer sus campos puede producir errores secundarios confusos.

await expect.soft(page.getByRole('heading')).toHaveText('Review demo draft');
await expect.soft(page.getByRole('status')).toHaveText('Ready for review');
expect(test.info().errors).toHaveLength(0);
await page.getByRole('button', { name: 'Continue demo' }).click();

El ejemplo requiere la página controlada e importar test y expect del ejecutor. La aserción firme sobre los errores es intencionada. Si falla alguna observación, no se pulsa Continue. El botón pertenece al ejemplo local, no es una recomendación para una aprobación real.

Coloca la barrera antes de las acciones dependientes

Detente antes de una acción cuyo significado depende del estado comprobado. Al final sería demasiado tarde: podrías haber actuado sobre otro registro. Define la barrera por las dependencias reales, no para obtener la lista de errores más larga.

Los fallos registrados están en test.info().errors. No vacíes el array ni cambies el estado para aparentar éxito. Los fallos son el resultado; una captura posterior no los elimina.

Continúa con observaciones de solo lectura únicamente si siguen siendo útiles y autorizadas. En pruebas autenticadas, incluso leer puede exponer datos privados en las trazas. Usa registros de pruebas autorizados y revisa los archivos antes de compartirlos.

Verifica el caso negativo

La muestra local tiene título y estado incorrectos. El ejecutor registra ambos errores y la barrera detiene la ejecución. Una comprobación posterior verifica que el estado del botón Continue nunca cambió. La ejecución fallida se inspecciona como fallo, no se convierte en un aprobado de producción.

Otro caso proporciona título y estado correctos, cruza la barrera y cambia un marcador local. Ambos demuestran el flujo de control, no que un servidor impidiera una operación no autorizada ni que todo test generado tenga la misma protección.

Para un requisito de seguridad, una aserción normal puede ser más sencilla. La flexibilidad es una herramienta de informe, no una obligación de posponer todos los fallos. Una suite clara usa ambas donde corresponden.

Deja una regla de revisión

Anota las comprobaciones independientes, la acción que depende de ellas y el punto de parada. Así se detecta un recorrido que recoge errores pero todavía avanza.

AnyTest describe exploración y pruebas de extremo a extremo para revisión humana. Pregunta si el test conserva el fallo y protege las acciones dependientes. No se afirma una implementación concreta de aserciones flexibles de AnyTest. Más diagnóstico solo ayuda si no debilita la barrera.

Preguntas comunes

¿Una aserción flexible fallida mantiene la prueba en verde?

No. Permite continuar la ejecución, pero marca la prueba como fallida.

¿Dónde debe estar la barrera firme?

Antes de la acción dependiente, no solo al final del recorrido.

Fuentes