Qué es QA (y qué no es)

Testing, QC y QA no son lo mismo

Se usan como sinónimos, pero describen cosas distintas — y confundirlas es lo primero que te delata en una entrevista:

• Testing es la actividad: ejecutar el software para encontrar diferencias entre lo que hace y lo que debería hacer.
• QC (Quality Control) es verificar el producto: ¿este build cumple los criterios de aceptación? Es una foto del resultado.
• QA (Quality Assurance) es el proceso completo: prevenir defectos, no solo encontrarlos. Un buen QA influye en los requisitos antes de que se escriba una línea de código.

En la industria, el cargo "QA" abarca las tres cosas. Pero entender la diferencia cambia cómo trabajas.

El QA que solo ejecuta casos que le pasaron es reemplazable. El que previene defectos en el diseño —haciendo la pregunta incómoda en la reunión de refinamiento— es invaluable. Ese es el salto que este curso te ayuda a dar.

Los 7 principios del testing (ISTQB)

Vale la pena entenderlos, no memorizarlos como loro: aparecen en cada entrevista y son verdad en el trabajo real.

1. El testing muestra la presencia de defectos, nunca su ausencia. Que no encuentres bugs no prueba que no existan.
2. El testing exhaustivo es imposible. No puedes probar todas las combinaciones — por eso existe el criterio de riesgo (lección 5).
3. Probar temprano ahorra dinero. Un bug en requisitos cuesta ~100x menos que en producción.
4. Los defectos se agrupan. El 80% de los bugs vive en el 20% de los módulos. Ahí concentras el esfuerzo.
5. La paradoja del pesticida. Los mismos casos dejan de encontrar bugs nuevos; hay que renovarlos.
6. El testing depende del contexto. No pruebas igual un e-commerce que un marcapasos… ni que un proceso ETL bancario que mueve millones de registros de noche.
7. La ausencia de errores es una falacia. Un software sin bugs que no resuelve el problema del usuario sigue siendo un fracaso.

Un día real de QA

Olvida la caricatura del "probador de botones". Un día típico incluye:

• Revisar historias de usuario nuevas y hacer preguntas incómodas ("¿qué pasa si el usuario se queda sin internet a mitad del pago?").
• Diseñar y ejecutar casos de prueba para lo que salió del sprint.
• Una sesión de testing exploratorio sobre la funcionalidad nueva.
• Reportar bugs reproducibles y re-testear los corregidos.
• Revisar que la automatización siga verde (aunque todavía no la escribas tú).

La mitad del valor de un QA ocurre antes de que exista algo que probar: en las preguntas que hace.

La herramienta más barata: un buen reporte de bug

Un bug mal reportado rebota entre QA y desarrollo días enteros. Uno bien escrito se arregla en una tarde. Esta es la plantilla mínima que usarás desde la lección 4 — cópiala con el botón de arriba a la derecha del bloque y guárdala:

Título: [Pantalla] Qué falla, en una línea

Pasos para reproducir:
1.
2.
3.

Resultado actual:
Resultado esperado:

Entorno: (navegador / SO / versión / usuario de prueba)
Severidad: (bloqueante / alta / media / baja)
Evidencia: (captura, video, logs)

Con esa estructura, cualquier desarrollador puede reproducir el bug sin escribirte de vuelta. Abajo tienes un mini-quiz para fijar los conceptos y un reto para aplicarlos.

En la próxima lección pasamos de las preguntas a la técnica: cómo convertir una historia de usuario en una matriz de casos de prueba que no deje huecos.