El mito de cubrir todo desde el principio
Existe la creencia de que mientras más casos de prueba se creen al inicio del proyecto, mejor protegido estará el sistema. En la práctica, esto genera cientos de casos que nadie mantiene, que quedan desactualizados en semanas y que consumen tiempo de revisión sin aportar valor real. Un equipo que trabaja con 40 casos bien definidos detecta más defectos que otro con 300 casos redundantes.
Documentar sin criterio de salida claro
Muchos equipos escriben casos de prueba sin definir previamente qué resultado específico indica que la prueba pasó. Cuando el criterio de aceptación es ambiguo, la ejecución se convierte en una interpretación subjetiva, y eso obliga a repetir ciclos completos. Redactar un criterio concreto, como que el sistema devuelva el código 200 con el campo usuario_id poblado, elimina discusiones costosas después.
Reutilizar casos sin revisar su vigencia
Copiar casos de prueba de proyectos anteriores parece eficiente, pero si la lógica de negocio cambió aunque sea parcialmente, esos casos validan comportamientos que ya no existen o pasan por alto los nuevos. Antes de reutilizar, conviene hacer una revisión de cobertura de 30 minutos contra los requisitos actuales para identificar qué sigue siendo válido.
Ejecutar manualmente lo que se puede automatizar con poco esfuerzo
Hay pruebas de regresión que se repiten en cada ciclo sin variación alguna, como verificar que el formulario de inicio de sesión acepta credenciales válidas. Automatizarlas con herramientas como Cypress o Playwright requiere una inversión inicial de horas, pero elimina el costo recurrente de ejecución manual en cada release.