Vocabulario de control de calidad (QA) y testing de software en inglés

El vocabulario de QA en inglés distingue conceptos que en español a veces se mezclan bajo una sola palabra: "bug" vs "defect" vs "issue", "test case" vs "test scenario", "regression" vs "smoke testing". Usar el término preciso en reportes y comunicación con el equipo evita ambigüedad sobre severidad, alcance y tipo de prueba realizada.

Términos que distinguen severidad y tipo de problema

• "Bug" / "defect": un error de comportamiento del software respecto a lo esperado; se usan casi indistintamente aunque algunos equipos reservan "defect" para procesos formales de QA.
• "Issue": término más general que puede ser un bug, una tarea o una pregunta — no asumir que "issue" siempre significa error.
• "Blocker": un bug que impide continuar probando o usar una funcionalidad crítica — comunicar esto correctamente cambia la prioridad que le da el equipo.
• "Regression": un bug que reaparece en una funcionalidad que ya había sido corregida antes — señal de que algo se rompió en un cambio reciente.
• "Edge case": un escenario poco común en los límites de lo esperado (valores extremos, condiciones inusuales) que puede no estar cubierto por pruebas estándar.

Tipos de pruebas: el vocabulario que hay que dominar sin confundir

"Unit testing" prueba componentes individuales de código de forma aislada; "integration testing" prueba cómo interactúan varios componentes juntos; "smoke testing" es una verificación rápida y superficial de que las funciones básicas funcionan antes de una prueba más profunda; "regression testing" verifica que un cambio nuevo no rompió funcionalidad existente; y "user acceptance testing" (UAT) es la prueba final desde la perspectiva del usuario antes de lanzar. Confundir estos términos en un reporte o en una reunión genera expectativas equivocadas sobre qué tan exhaustiva fue realmente una prueba.

Cómo escribir un test case claro en inglés

Un test case bien escrito en inglés sigue un formato predecible: precondiciones ("Given the user is logged in"), pasos de acción ("When the user clicks Submit"), y resultado esperado ("Then the confirmation message should appear"). Este formato Given-When-Then, común en QA moderno, reduce ambigüedad porque separa claramente el estado inicial, la acción y el resultado esperado — escribirlo en frases largas y narrativas en vez de esta estructura dificulta que otro miembro del equipo lo ejecute exactamente igual.

Vocabulario de severidad y prioridad que cambia decisiones reales

La distinción entre "severity" (qué tan grave es el impacto técnico del bug) y "priority" (qué tan urgente es arreglarlo para el negocio) es una de las más importantes y más frecuentemente confundidas. Un bug puede tener severidad alta (rompe una función central) pero prioridad baja (afecta a muy pocos usuarios en un caso raro), o al revés. Comunicar estos dos conceptos como si fueran uno solo genera decisiones de priorización equivocadas en el equipo, un error que trasciende el idioma pero que se agrava cuando el vocabulario en sí ya genera confusión adicional.

Frases estándar para reportar y hacer seguimiento de bugs

"Steps to reproduce", "expected behavior" y "actual behavior" son los tres encabezados estándar de cualquier reporte de bug en inglés, reconocidos en cualquier equipo o herramienta de tracking (Jira, GitHub Issues, Linear). Usar exactamente esta estructura, en vez de una descripción narrativa libre, hace que el reporte sea inmediatamente legible para cualquier miembro del equipo sin necesidad de traducir mentalmente qué se quiso decir — es una de las inversiones de vocabulario técnico que más tiempo ahorra en equipos internacionales de desarrollo.