Skip to main content

Las entrevistas de trabajo son difíciles. Es como si cada pregunta de la entrevista estuviera diseñada para dejarte fuera de la carrera.

Pasas tiempo leyendo sobre la empresa antes de la entrevista, ensayas tus respuestas a todas las preguntas que crees que te harán y, luego, el día de la entrevista, llegas una hora antes y bebes demasiado café.

Mira, las entrevistas provocan ansiedad en el mejor de los casos, pero estamos aquí para ayudarte a reducir parte de esa ansiedad previa a la entrevista.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Esta guía descubre todos los detalles de las entrevistas de control de calidad, enumera algunas de las preguntas más difíciles de las entrevistas sobre pruebas de software y explora algunas preguntas y respuestas de entrevistas de control de calidad para ayudarte a prepararte para el gran día.

Cómo prepararse para una entrevista de control de calidad

La mejor manera de prepararte es evaluar honestamente tus capacidades y concentrarte en tus fortalezas, al tiempo que reconoces tus debilidades.

Repasa tus definiciones, comprende el mercado laboral de control de calidad leyendo guías relevantes sobre empleos de probador de control de calidad, revisa las preguntas y respuestas que aparecen a continuación, consulta la descripción del puesto de probador de control de calidad y recuerda que el proceso de contratación consiste tanto en encontrar a la persona adecuada para la cultura de la empresa como en encontrar al candidato más cualificado. 

Para destacar en tu entrevista de control de calidad, es fundamental estar familiarizado con el software de gestión de pruebas líder del sector. Estas herramientas suelen ser la base de cualquier proyecto de control de calidad exitoso. Leer artículos interesantes sobre pruebas de software también puede ser útil.

¿Cuánto dura una entrevista de control de calidad típica?

Depende del entrevistador y del entrevistado, así como de la rapidez con la que respondas las preguntas.

Las entrevistas de control de calidad pueden llevar mucho tiempo, ya sea una entrevista para un puesto de pruebas de bases de datos de aseguramiento de la calidad o para un puesto de ingeniero, analista, gerente o líder. A menudo, habrá varias rondas de entrevistas y entrevistas técnicas más adelante.

Por lo general, la mayoría de las entrevistas de control de calidad duran entre una y dos horas, aunque puede haber varias entrevistas a lo largo del proceso de contratación. 

Lista de preguntas y respuestas de entrevistas de control de calidad

Mi objetivo con este artículo es ayudarte a prepararte para el tipo de preguntas de entrevista de control de calidad que te harán, ya sea sobre automatización, tu proceso de pruebas o tu personalidad.

A menudo, al entrevistador le interesarán tus capacidades como ingeniero de control de calidad y tu enfoque de las pruebas.

Algunas preguntas de entrevistas de control de calidad serán abiertas o parecerán vagas. Esto se debe a que el entrevistador quiere escuchar tu enfoque. Intenta hacerse una idea del tipo de trabajador que eres y, lo que es más importante, si eres el tipo de trabajador que encajará en su equipo de pruebas.

Sin más preámbulos, aquí tienes una lista de posibles preguntas y respuestas de entrevistas de control de calidad para que te hagas una idea de tus respuestas. ¡Buena suerte!

1. ¿Por qué debería contratarte?

Esta es una pregunta favorita de los entrevistadores de todo el mundo. No es una pregunta capciosa: es una forma de romper el hielo.

Aprovecha esta oportunidad para mostrar tu mejor versión. Habla de lo que te apasiona del control de calidad y de por qué harás el trabajo mejor que cualquier otra persona del equipo de control de calidad, gracias a la combinación única de talento y rasgos de personalidad que solo tú puedes aportar al puesto. No te preocupes por ser autocrítico ni excesivamente humilde en este caso. La pregunta está diseñada para hablar de las fortalezas del candidato. 

2. ¿Qué es un error?

Un error es cualquier fallo, equivocación o defecto en el código de software que impide que la función del software se ejecute correctamente. 

3. ¿Cuál es la diferencia entre gravedad y prioridad?

Comprender estas diferencias es esencial para gestionar el tiempo de manera eficaz. La gravedad se refiere a la complejidad de solucionar un problema, mientras que la prioridad indica la urgencia de abordarlo.

El hecho de que un problema tenga una gravedad alta no significa necesariamente que tenga una prioridad alta, y viceversa.

Este es un ejemplo de un problema de gravedad alta y prioridad baja:

  • La aplicación se bloquea cuando se ejecuta una función que se utiliza rara vez en un software heredado al que la mayoría de los usuarios no puede acceder.

Este es un ejemplo de un problema de gravedad baja y prioridad alta:

  • El logotipo incorrecto de la empresa aparece durante el inicio. 

4. ¿Cuál es la diferencia entre los comandos assert y verify en la automatización de pruebas?

Existen muchas similitudes entre ambos comandos. Los dos comprueban si las condiciones del código son verdaderas. La diferencia está en lo que sucede después.

  • Cuando un comando assert falla, deja de ejecutar el código y la prueba se pausa.
  • Cuando un comando verify falla, continúa ejecutando el resto del código.

5. ¿Cuál es la diferencia entre el aseguramiento de la calidad, el control de calidad y las pruebas de calidad?

El aseguramiento de la calidad planifica cómo un equipo y una organización supervisarán el proceso de pruebas. El control de calidad encuentra defectos y sugiere formas de mejorar el software. Las pruebas son el proceso mediante el cual el aseguramiento de la calidad y el control de calidad encuentran errores.

Aquí tienes una guía relacionada sobre la diferencia entre el aseguramiento de la calidad y la ingeniería de calidad, así como sobre la diferencia entre el control de calidad y el aseguramiento de la calidad.

6. ¿Cuándo debería comenzar el aseguramiento de la calidad?

El aseguramiento de la calidad debería comenzar lo antes posible. Cuanto antes se involucren en el proceso los analistas de QA, los probadores de QA y el líder del equipo de QA, más problemas se evitarán posteriormente en el ciclo de desarrollo de software. Las pruebas estáticas pueden realizarse antes de que el software sea completamente funcional. 

7. ¿Cuál es el ciclo de vida de las pruebas de QA?

Puedes hablar sobre el proceso de pruebas con el que estés más familiarizado, pero aquí tienes una versión estándar:

  1. Requisitos
  2. Planificación 
  3. Análisis 
  4. Diseño 
  5. Implementación 
  6. Ejecución 
  7. Conclusión 
  8. Cierre 

Mejora tu bandeja de entrada con más sabiduría sobre liderazgo tecnológico para ofrecer mejores programas y sistemas.

 8. ¿Qué es un plan de pruebas? 

Un plan de pruebas es un documento que describe los detalles de la prueba prevista. Antes de comenzar las pruebas, establece los roles necesarios, los posibles riesgos y las soluciones, así como los recursos que utilizará.

9. ¿Qué incluye un plan de pruebas?

Los planes de pruebas deberían incluir:

  • Alcance
  • Enfoque
  • Recursos necesarios
  • Calendario previsto de las pruebas 

10. ¿Cuáles son las principales ventajas de las pruebas automatizadas en el desarrollo de software?

Las pruebas automatizadas mejoran la eficiencia al ejecutar los casos de prueba con mayor rapidez y reducir los errores humanos. Mejoran la cobertura de las pruebas al ejecutar escenarios de prueba exhaustivos y repetitivos en distintos entornos.

Además, las pruebas automatizadas son compatibles con la integración y la entrega continuas (CI/CD), lo que permite lanzamientos más rápidos y una mayor calidad del software.

11. ¿Qué incluirías en un plan de pruebas automatizadas?

Como elaborar un plan para las pruebas automatizadas es una tarea importante, no tienes que entrar en todos los detalles.

En su lugar, menciona algunos aspectos esenciales de un plan de pruebas; por ejemplo, cómo debería describir el diseño de las pruebas, cómo se ejecutarán, cómo se gestionarán los defectos y cómo serán los informes de automatización de pruebas.

12. ¿Qué es un caso de uso?

Los casos de uso describen la causa y el efecto de una función. Garantizan que la acción del usuario y la respuesta del sistema se comuniquen correctamente. 

13. ¿Qué es una estrategia de pruebas?

La estrategia de pruebas describe el plan para la etapa de pruebas del desarrollo de software.

A diferencia del plan de pruebas, que describe una prueba específica, la estrategia de pruebas abarca toda la fase de pruebas del desarrollo e incluye una descripción de las herramientas de pruebas, los grupos de pruebas, las prioridades de las pruebas, el mantenimiento de los registros de pruebas y el resumen de las pruebas. 

14. ¿Son el mismo documento las estrategias de pruebas y los planes de pruebas?

No. Los planes de pruebas recopilan y organizan los casos de prueba.

Las estrategias de pruebas describen el enfoque hacia las pruebas. En general, las estrategias de pruebas son gestionadas por el responsable o líder de QA, mientras que los probadores de QA gestionan los planes de pruebas.

15. ¿Cuáles son algunos tipos diferentes de pruebas?

Pruebas de regresión, pruebas exploratorias, pruebas funcionales, pruebas de carga, pruebas de integración, pruebas unitarias, pruebas entre navegadores, pruebas de caja blanca y pruebas de caja negra, pruebas de volumen, pruebas alfa, pruebas beta y muchas más.

Consulta nuestra publicación sobre los tipos de pruebas de software para obtener más información sobre las técnicas de prueba.

16. ¿Cuáles crees que son algunas ventajas de las pruebas manuales?

Estas son algunas ventajas de las pruebas manuales de las que puedes hablar:

  • Pueden ser menos costosas en comparación con las pruebas automatizadas.
  • Puede ser más fácil para los equipos nuevos o las personas que son nuevas en QA aprender a realizar una prueba manual, de modo que pueda implementarse más rápidamente.
  • Del mismo modo, las pruebas manuales pueden ser importantes en proyectos a corto plazo cuando los scripts de prueba no se reutilizan con frecuencia.
  • Puedes analizar el producto desde el punto de vista del usuario final al realizar pruebas manuales.
  • Probar la interfaz gráfica de usuario puede resultar más intuitivo y generar resultados más precisos al realizar una prueba manual; la accesibilidad visual y las preferencias pueden ser difíciles de automatizar.

Aquí tienes un artículo donde puedes leer más sobre las ventajas y desventajas de las pruebas manuales y automatizadas.

17. ¿Qué es un buen caso de prueba?

Un buen caso de prueba indica claramente los parámetros de la prueba y los errores que espera encontrar. 

18. ¿Cuál es la diferencia entre las pruebas funcionales y no funcionales?

Las pruebas funcionales prueban las partes clave del software para garantizar que cumpla con los requisitos y las especificaciones. Las pruebas no funcionales evalúan aspectos esenciales, aunque no cruciales, del software, como los tiempos de carga, la resistencia y el rendimiento general. 

19. ¿Debería QA resolver los problemas de producción?

Es posible que tengas opiniones diferentes al respecto, pero te aconsejaría responder «Sí».

A menudo es positivo que QA participe en la resolución de problemas de producción. Cuando sea posible, debería redactar casos de prueba, revisar los datos de prueba e intentar encontrar los problemas. Al involucrarse, QA minimiza el número de problemas en el producto final.

20. Cuando encuentras un error en producción, ¿cómo te aseguras de que se resuelva?

La mejor medida es redactar inmediatamente un caso de prueba para el error y realizar una prueba de regresión; de ese modo, cualquier prueba futura que se realice en el software debería comprobar específicamente ese error. 

21. ¿Qué hiciste en tu último proyecto?

No hay respuestas claras, solo pautas, para esta pregunta. Es habitual que los entrevistadores pregunten sobre tu trayectoria profesional y tus proyectos anteriores, así que prepara de antemano una lista breve de puntos para que puedas hablar de los proyectos que, en tu opinión, representan mejor tu trabajo.

Mi consejo más importante es que respondas con la mayor honestidad posible. No exageres ni subestimes tu contribución a equipos anteriores. Destaca los momentos en los que asumiste tareas de gestión de proyectos de QA fuera de tus responsabilidades para demostrar iniciativa y responsabilidad. Cuéntales cuál era tu función diaria, qué herramientas utilizabas y cómo se desarrollaron las pruebas de QA. 

22. ¿Cómo priorizas cuando tienes tantas tareas?

Piensa en cómo has afrontado los momentos de mucho trabajo en el pasado. ¿Eres estricto con la planificación? ¿O prefieres distribuir tu tiempo de forma más flexible, dejando margen para adaptarte a problemas repentinos? De nuevo, estas preguntas de entrevista sobre pruebas se centran más en determinar si encajas bien por tu personalidad en su equipo. 

Si sientes que priorizar varios proyectos es uno de tus puntos débiles, Harvard Business Review tiene una guía sobre cómo priorizar correctamente en el trabajo. 

23. Háblame de tu proyecto más desafiante.

Respira profundamente. Deja que todo vuelva a tu mente: las emociones, las noches interminables intentando encontrar el problema y la cantidad desmesurada de cajas de comida para llevar acumuladas durante tu prueba.

Esta es una excelente oportunidad para dejar que se manifieste tu pasión por el control de calidad. Explícales qué fue lo que más dificultades te causó, por qué fue tan difícil encontrar la solución y cuánto te esforzaste para resolverlo. 

 24. Háblame de una ocasión en la que no detectaste un error.

En la primera pregunta, te dije que mostraras tu mejor faceta de manera natural. Por eso no todas las preguntas estarán formuladas de una manera que te presente bajo la mejor luz.

En una entrevista de control de calidad, la persona encargada de las necesidades de contratación debe saber que los posibles miembros del equipo reconocen abiertamente sus errores.

Lo peor que puede hacer un evaluador de control de calidad es actuar como si nunca hubiera cometido un error. Sé abierto y sincero. Para cuando estés sentado en una entrevista, es seguro que no hayas detectado algún error o que hayas cometido una equivocación. Háblales de tus errores, de cómo resolviste el problema y de lo que aprendiste. 

25. ¿Cómo probarías una tostadora averiada?

Esta es una pregunta adicional porque a algunas organizaciones les gustan este tipo de preguntas y a otras no. Por un lado, coloca al entrevistador en una situación difícil que casi con toda seguridad no esperaba afrontar. Sin embargo, la ventaja es que exige pensar con rapidez y de manera innovadora, y permite a los entrevistados demostrar su creatividad. 

Debido al espíritu de la pregunta, no voy a decirte cómo probar una tostadora averiada. Eso depende de ti. 

26. ¿Cuáles son las características esenciales de los líderes en control de calidad?

Una pregunta como esta probablemente aparecerá entre las preguntas de una entrevista para ingenieros de control de calidad o puestos similares orientados al liderazgo. También podrían hacerte esta pregunta porque tu futuro gerente querrá saber qué cualidades buscas en tus líderes.

En cualquier caso, la mejor respuesta es una respuesta sincera. Reflexiona sobre esto y prepárate para hablar de los tipos de entornos en los que trabajas mejor y de cómo los líderes pueden ayudar a crear ese entorno.

Algunas ideas que puedes mencionar son la comunicación sólida, la escucha activa, la honestidad, la seguridad psicológica, el empoderamiento, la autonomía, la visión y otras más.

27. ¿Cuál es la métrica de pruebas más importante y por qué?

No existe una respuesta correcta para esta pregunta, principalmente porque la métrica que elijas dependerá de tus objetivos y del tipo de prueba que estés ejecutando; por ejemplo, las pruebas de aceptación medirán métricas muy diferentes de las pruebas exploratorias.

Para responder a esta pregunta, prepárate para hablar de métricas estándar de control de calidad, como «errores por prueba», que pueden aplicarse a muchos tipos distintos de pruebas, y de la información que te proporciona esta métrica.

También prepárate para hablar de los motivos por los que elegirías una métrica específica según los objetivos de tu prueba, los objetivos de la organización en general, el entorno de prueba y cómo podrías hacerlo.

Para obtener puntos adicionales, deberías consultar el artículo de Niall Lynch sobre una métrica de control de calidad que desarrolló, llamada T2Q o Tiempo hasta la calidad; puede aplicarse de manera bastante universal a cualquier prueba, medirse fácilmente y proporcionarte información significativa sobre tus esfuerzos de prueba.

28. ¿Cuáles son algunos de los objetivos que tienes para tu carrera?

Deberás encontrar estas respuestas por tu cuenta, pero para obtener algunas ideas, aquí tienes un artículo sobre cómo gestionar tu carrera en control de calidad.

29. ¿Qué son las pruebas basadas en datos?

Las pruebas basadas en datos son una técnica de pruebas de software que almacena los datos de prueba en formato de tabla o de hoja de cálculo. Esto permite a los evaluadores ejecutar varios casos de prueba utilizando un único script de prueba, al recuperar dinámicamente las entradas de datos de fuentes externas como bases de datos, hojas de cálculo o archivos XML. Los resultados de las pruebas se registran después en el mismo formato estructurado, lo que facilita el análisis del rendimiento en distintos conjuntos de datos.

30. ¿Cómo se implementan las pruebas basadas en datos?

En las pruebas tradicionales, las entradas de prueba están codificadas de forma fija, lo que limita la flexibilidad y la escalabilidad. Las pruebas basadas en datos eliminan esta restricción mediante la parametrización de los casos de prueba y el uso de variables globales que leen directamente de fuentes de datos externas. Este enfoque garantiza la cobertura de pruebas para diversos escenarios de entrada sin modificar el script de prueba. Por ejemplo, en un marco de automatización como Selenium, los evaluadores pueden utilizar archivos CSV o Excel externos para introducir valores dinámicos en los casos de prueba, lo que permite una validación exhaustiva con un mantenimiento mínimo del script.

31. ¿Qué es una matriz de trazabilidad y por qué es importante en las pruebas de software?

Una matriz de trazabilidad es un documento utilizado en las pruebas de software para garantizar que todos los requisitos estén vinculados a los casos de prueba correspondientes. Ayuda a realizar un seguimiento de la cobertura de las pruebas, garantizando que ningún requisito quede sin probar y evitando lagunas en la validación. Esto resulta especialmente útil en el análisis de impacto cuando se producen cambios, ya que permite a los equipos identificar qué casos de prueba deben actualizarse o volver a ejecutarse.

32. ¿Cómo verificas que las restricciones de la base de datos (como las claves foráneas o la unicidad) funcionan según lo previsto?

Intentaré insertar o actualizar registros que deberían infringir cada restricción; por ejemplo, intentaré insertar una fila con una clave foránea inexistente o crear entradas duplicadas donde exista un índice único, y confirmaré que la base de datos las rechace. Revisar los registros de errores y confirmar que la base de datos devuelve los códigos de error correctos ayuda a garantizar que las restricciones se apliquen.

33. ¿Cuáles son los tres tipos de matrices de trazabilidad y cuál es el papel de la matriz de trazabilidad para garantizar unas pruebas exhaustivas?

Matriz de trazabilidad hacia adelante (FTM), que garantiza que cada requisito tenga casos de prueba asignados para lograr una cobertura completa; matriz de trazabilidad hacia atrás (BTM), que garantiza que cada caso de prueba se vincule a un requisito para evitar redundancias; y matriz de trazabilidad bidireccional (BTM), que combina la trazabilidad hacia adelante y hacia atrás para verificar la cobertura completa de las pruebas y eliminar los casos de prueba innecesarios. La matriz de trazabilidad ayuda a garantizar una cobertura completa de las pruebas al asignar casos de prueba a los requisitos del proyecto y verificar que se prueben todas las funcionalidades. Permite a los equipos realizar un seguimiento de los cambios en los requisitos y de su impacto en los casos de prueba, reduciendo el riesgo de omitir funcionalidades críticas. Además, respalda la garantía de calidad al identificar lagunas, evitar pruebas redundantes y garantizar que todos los requisitos se validen antes de la implementación.

34. ¿En qué se diferencian las pruebas exploratorias de las pruebas basadas en guiones y cuáles son sus principales ventajas?

Las pruebas exploratorias son un enfoque de pruebas no basado en guiones, en el que los evaluadores exploran activamente la aplicación para identificar defectos, a diferencia de las pruebas basadas en guiones, que siguen casos de prueba predefinidos. Permiten una mayor flexibilidad y descubren problemas inesperados que las pruebas estructuradas podrían pasar por alto. Este enfoque ayuda a detectar problemas de usabilidad, casos límite y nuevos defectos introducidos por cambios recientes.

35. ¿Cuáles son las principales diferencias entre las pruebas de caja negra y las de caja blanca?

Las pruebas de caja negra se centran en verificar la funcionalidad del software sin conocer la estructura interna del código, basándose en las entradas y las salidas esperadas. En cambio, las pruebas de caja blanca requieren comprender el código, la lógica y la estructura internos para diseñar casos de prueba. Mientras que las pruebas de caja negra se utilizan habitualmente para las pruebas funcionales y a nivel de usuario, las pruebas de caja blanca son más adecuadas para las pruebas unitarias, el análisis de cobertura del código y las pruebas de seguridad.

36. ¿Qué son las pruebas de carga, estrés y volumen?

Las pruebas de carga, estrés y volumen son técnicas de rendimiento que evalúan el comportamiento de un sistema en diferentes condiciones.

  • Las pruebas de carga miden el rendimiento del sistema con las cargas de usuarios previstas para garantizar que pueda gestionar el tráfico habitual sin problemas.
  • Las pruebas de estrés llevan el sistema más allá de sus límites al aplicar cargas de trabajo extremas para identificar los puntos de ruptura y las capacidades de recuperación ante fallos.
  • Las pruebas de volumen evalúan la capacidad del sistema para procesar grandes cantidades de datos, garantizando su estabilidad y eficiencia al gestionar volúmenes elevados de datos.

Cada prueba ayuda a evaluar la fiabilidad, la escalabilidad y la solidez del sistema en condiciones variables.

37. ¿Cómo aplicas BVA para garantizar una cobertura exhaustiva de los rangos de entrada?

El análisis de valores límite se centra en probar los extremos de los rangos de entrada, como los puntos mínimo, máximo, inmediatamente inferior, inmediatamente superior y los límites válidos. Si un campo de formulario acepta valores del 1 al 100, por ejemplo, normalmente probaría 0, 1, 2, 99, 100 y 101 (si corresponde) para garantizar que el sistema gestione correctamente todos los límites críticos.

38. ¿Puedes explicar cómo la partición de equivalencias ayuda a optimizar el diseño de casos de prueba?

La partición de equivalencias agrupa las entradas en conjuntos que deberían comportarse de manera similar, lo que evita pruebas redundantes. Por ejemplo, si las entradas válidas para un campo de contraseña tienen entre 8 y 16 caracteres, puedes probar una longitud válida y una longitud no válida a cada lado de ese rango, en lugar de comprobar todos los números del 1 al 20. Permite ahorrar tiempo sin dejar de garantizar una cobertura amplia.

39. ¿Cuándo utilizarías un enfoque de tabla de decisiones y cómo estructurarías tus casos de prueba en consecuencia?


Las tablas de decisiones son ideales para escenarios con múltiples condiciones y resultados, como las reglas empresariales complejas. Primero identifico todas las condiciones posibles y, después, tabulo las acciones o los resultados que se activan con cada combinación. Este método ofrece una visión clara y sistemática de cada posible ruta, lo que garantiza que no se pase por alto ninguna ramificación lógica.

40. ¿Qué experiencia tienes probando distintos tipos de API y con qué desafíos te encuentras normalmente al trabajar con SOAP frente a REST?

REST suele ser más ligero, a menudo utiliza JSON y se adapta bien a las integraciones basadas en la web. SOAP es más rígido, utiliza XML y depende de las definiciones WSDL. Entre los desafíos se incluyen gestionar esquemas de autenticación complejos, analizar XML frente a JSON y trabajar con estándares más estrictos en los servicios basados en SOAP. He comprobado que las pruebas automatizadas para REST suelen necesitar una cobertura exhaustiva de los distintos métodos HTTP, mientras que las pruebas de SOAP pueden requerir una validación minuciosa de los esquemas XML.

¿Qué sigue?

Al fin y al cabo, la mayoría de las entrevistas de QA consisten tanto en mostrar quién eres como en demostrar lo que sabes. Sí, tendrás que dominar conceptos clave como las pruebas automatizadas frente a las manuales o la gravedad frente a la prioridad, pero no subestimes el valor del autoconocimiento y de contar tu experiencia con honestidad.

Los equipos de contratación buscan a alguien que pueda colaborar eficazmente, asumir sus errores y mantener los proyectos encaminados bajo presión.

Ten presentes estas preguntas, pero recuerda también que toda entrevista es una vía de doble sentido: aprovecha la oportunidad para comprobar si la empresa es adecuada para ti. Si llegas preparado, con curiosidad y dispuesto a adaptarte, tendrás las mejores posibilidades de conseguir tu nuevo puesto de QA y de prosperar en él.

Suscríbete al boletín de The CTO Club para recibir más preguntas de entrevista y perspectivas sobre QA.