Guía de inglés técnico
Vocabulario de QA en inglés: test plans, severity vs. priority y el sign-off del release
21 de octubre de 2026
Las palabras que necesitan QA y test engineers más allá de los reportes de bugs: test plans, test cases, acceptance criteria, severity vs. priority y el lenguaje del sign-off del release.
Nuestra guía sobre cómo explicar un bug en inglés cubre el vocabulario que necesita cualquier developer para standups, tickets y Slack. Esta es diferente: es para los documentos y decisiones específicas del rol de QA, los que aparecen antes y después de un reporte de bug, no dentro de uno. How to Explain a Bug in English.
Puntos clave
- Un test plan establece el objetivo y el alcance de las pruebas antes de escribir un solo test case: qué vas a probar y, tan importante como eso, qué no vas a probar.
- Un test case siempre tiene cuatro partes: precondition, steps, expected result y actual result.
- Severity y priority son ejes distintos. 'This is high severity but low priority' es una oración normal, no una contradicción.
- 'Sign-off' significa una aprobación formal y explícita, no solo silencio. Si nadie dice 'QA has signed off', asume que todavía no pasó.
- Un smoke test verifica que el build esté lo suficientemente estable como para probarlo. Un regression test verifica que las funciones que ya andaban sigan andando después de un cambio.
Writing a test plan
Cómo escribir un test plan
Un test plan es el documento que establece qué vas a probar y por qué, antes de escribir un solo test case. En inglés, la clave es declarar el alcance de forma explícita, incluyendo lo que queda fuera.
“The objective of this test plan is to verify the new checkout flow before the release.”
Declara el objetivo en una sola oración, al principio del documento.
“In scope: payment methods, discount codes, and order confirmation emails.”
Enumera exactamente qué se va a probar.
“Out of scope: performance testing and third-party integrations, which are covered in a separate plan.”
Declarar qué no vas a probar evita malentendidos más adelante.
“Entry criteria: the build must be deployed to staging and the smoke test must pass.”
Establece qué tiene que ser cierto antes de empezar a probar.
“Exit criteria: all P0 and P1 test cases pass, with no open blockers.”
Establece qué tiene que ser cierto para considerar las pruebas terminadas.
Writing a test case
Cómo escribir un test case
Un test case es más estructurado que un reporte de bug. En inglés, sigue siempre la misma forma de cuatro partes, para que cualquiera del equipo pueda ejecutarlo igual que tú.
“Precondition: the user is logged in and has at least one item in the cart.”
Declara qué tiene que ser cierto antes de empezar la prueba.
“Steps: 1) Go to the cart page. 2) Click 'Apply discount code'. 3) Enter 'SAVE10'. 4) Click 'Apply'.”
Numerado, una acción por paso, sin ambigüedad.
“Expected result: the total updates to reflect a 10% discount.”
Qué debería pasar si la funcionalidad funciona.
“Actual result: the total does not change and no error message appears.”
Qué pasó en realidad. Aquí es donde reportas la prueba como fallida.
“This test case is blocked because the discount code field is not rendering.”
Usa 'blocked' cuando ni siquiera puedes ejecutar los pasos.
Acceptance criteria
Criterios de aceptación
Los acceptance criteria definen cuándo una funcionalidad se considera 'terminada'. El formato Given/When/Then es común en equipos angloparlantes, pero una oración simple también funciona.
“Given a logged-in user with items in the cart, when they apply a valid discount code, then the total updates immediately.”
La estructura clásica Given/When/Then.
“Given an expired discount code, when the user applies it, then an error message explains that the code has expired.”
Escribe siempre un criterio también para el caso de fallo, no solo para el camino feliz.
“This is done when a user can complete checkout with a saved card in under three clicks.”
Una alternativa en inglés simple a Given/When/Then. Igual de válida.
“Acceptance criteria met. Moving this to 'Ready for QA'.”
Lo que dices cuando el desarrollo terminó y está listo para probar.
Severity vs. priority, and release language
Severity vs. priority y el lenguaje del release
Severity describe qué tan grave es el bug. Priority describe qué tan pronto hay que arreglarlo. Confundir las dos es uno de los errores más comunes para quienes hablan inglés como segunda lengua en QA.
“This is high severity but low priority: it crashes the app, but only for an internal admin tool nobody uses yet.”
Severity (daño técnico) y priority (urgencia de negocio) no tienen por qué coincidir.
“This bug is low severity but high priority: it is just a typo, but it is on the homepage right before a big launch.”
Un bug pequeño igual puede ser urgente por razones de negocio.
“We ran a smoke test on the new build and it passed, so QA can start.”
Un smoke test es rápido: solo confirma que el build no se rompió por completo.
“Before sign-off, we need a full regression pass on the payment module.”
Un regression test vuelve a revisar funciones que ya andaban, después de un cambio.
“QA has signed off on this release.”
La frase explícita que significa que las pruebas terminaron y fueron aprobadas. El silencio no cuenta como sign-off.
“This build is not release-ready: there are two open blockers in the payment flow.”
La frase para decir que un release todavía no puede salir, con el motivo.
QA vocabulary table
Vocabulario de QA
Términos que vas a usar constantemente una vez que pasas de 'hay un bug' al lenguaje del test planning y el release readiness.
| Término | Traducción | Definición | Ejemplo |
|---|---|---|---|
| test plan | plan de pruebas | The document stating the objective, scope, and schedule of testing for a feature or release. | The test plan for the new onboarding flow is ready for review. |
| test case | caso de prueba | A single, specific scenario to test, with a precondition, steps, and an expected result. | I wrote 12 test cases for the new discount code feature. |
| precondition | precondición | What must be true before a test case can be executed. | The precondition for this test is that the user has an active subscription. |
| expected / actual result | resultado esperado / resultado real | What should happen if the feature works correctly, versus what actually happened when you ran the test. | Expected result: a success message. Actual result: the page just reloads with no message. |
| acceptance criteria | criterios de aceptación | The specific conditions a feature must meet to be considered complete and correct. | This story has three acceptance criteria, and the last one is not implemented yet. |
| smoke test | prueba de humo / smoke test | A quick test that checks whether a build is stable enough to test further, not a full test pass. | The smoke test failed, so QA cannot start testing this build yet. |
| test coverage | cobertura de pruebas | How much of the feature or codebase is actually being tested. | Test coverage for the checkout flow is still low; we are missing cases for failed payments. |
| blocker | bloqueante | An issue serious enough that testing, or the release, cannot continue until it is fixed. | This is a blocker: I cannot test the rest of the flow until login works. |
| sign-off | aprobación formal / sign-off | A formal, explicit approval that a release or feature is ready, stated out loud or in writing, never assumed. | We are waiting on sign-off from QA before we deploy to production. |
| release-ready | listo para release | The state of a build that has passed all required testing and has no open blockers. | This build is release-ready as of this morning. |
| pass / fail | aprobado / fallido | The final verdict of a test case: whether the actual result matched the expected result. | Of the 40 test cases in this run, 38 passed and 2 failed. |
| test run | ronda de pruebas | One full execution of a set of test cases, usually against a specific build. | This is the second test run against the release candidate build. |
Preguntas frecuentes
¿Cuál es la diferencia entre severity y priority en QA?
Severity mide cuánto daño técnico causa un bug: si rompe la app, corrompe datos o solo se ve mal. Priority mide qué tan urgente es arreglarlo, según el impacto de negocio. Un bug puede ser high severity y low priority, o al revés. Un buen reporte declara los dos ejes por separado.
¿Qué significa 'sign-off' en un release de software?
Es la declaración formal y explícita de que las pruebas terminaron y el release está aprobado para salir, normalmente escrita como 'QA has signed off on this release'. Nunca se asume por silencio: si nadie lo dijo, asume que todavía no pasó.
¿Cuál es la diferencia entre un smoke test y un regression test?
Un smoke test es una verificación rápida de que el build está lo suficientemente estable como para probarlo. Un regression test es una pasada más amplia que vuelve a revisar funciones que ya andaban, para asegurarse de que un cambio reciente no las rompió. Primero el smoke test, después la pasada completa de regression.
¿Cómo escribo acceptance criteria en inglés?
El formato más común es Given/When/Then. Una oración simple también funciona: 'This is done when a user can complete checkout in under three clicks.' Escribe siempre al menos un criterio para el caso de fallo, no solo para el camino feliz.
Artículos relacionados
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.