Preguntas en una entrevista de trabajo: 10 respuestas prácticas sobre pruebas manuales

Empieza con estas diez preguntas y adapta las respuestas de ejemplo a un trabajo que puedas explicar con honestidad. Para responder a preguntas sobre pruebas de software en entrevistas, relaciona el requisito, los datos de entrada, el resultado esperado y el motivo de tu elección.

1. ¿Cómo probarías un campo de cantidad?

Respuesta de ejemplo: «Confirmaría los valores permitidos y el comportamiento al enviar el formulario; después probaría cantidades aceptadas, rechazadas y los valores límite. Para un rango de enteros de 1 a 10, incluiría 0, 1, 10 y 11, con resultados esperados explícitos».

2. ¿En qué se diferencian la partición de equivalencia y el análisis de valores límite?

«La partición de equivalencia agrupa entradas que deberían recibir un tratamiento similar; el análisis de valores límite se centra en los extremos de las particiones ordenadas. Para la cantidad, elegiría 5 como valor válido habitual y luego comprobaría dónde cambia la aceptación alrededor de 1 y 10».

3. ¿Qué debe incluir un caso de prueba?

«Necesito suficiente detalle para que otra persona encargada de las pruebas pueda repetir la comprobación. Para el proceso de pago, especificaría el carrito inicial, el estado de la cuenta, la cantidad, la acción y el total del pedido esperado; después registraría el resultado observado en la versión probada».

4. ¿Cómo probarías reglas de negocio que interactúan entre sí?

«Anotaría las condiciones y las acciones esperadas antes de elegir las combinaciones. Si el proceso de pago requiere que haya existencias y que el pago sea aprobado, cubriría ambas condiciones a la vez, incluido el caso de un artículo disponible con un pago rechazado».

5. ¿Cuándo importa el estado?

«Probaría la misma acción desde distintos estados iniciales. Enviar un pedido desde un carrito listo puede ser válido; volver a enviarlo mientras el pago está pendiente debería seguir una regla acordada para los envíos duplicados».

6. ¿Qué pruebas realizas después de corregir un defecto?

«Las pruebas de confirmación vuelven a comprobar la corrección; las pruebas de regresión buscan efectos adversos en otras partes. Tras corregir el rechazo de la cantidad 10, repetiría esa prueba fallida y elegiría comprobaciones cercanas de cantidad y del proceso de pago según el cambio».

7. ¿Cómo informarías de un fallo intermitente?

«Registraría las condiciones, los intentos, las marcas de tiempo y las evidencias. Si el proceso de pago fallara dos veces en diez intentos, informaría de esa observación, conservaría las secuencias que funcionaron y las que fallaron, y evitaría presentar como confirmada una causa que solo sospecho».

8. ¿En qué se diferencian la gravedad y la prioridad?

«La gravedad se refiere al impacto; la prioridad, a cuándo debe corregirse. Describiría el flujo de compra afectado y la solución provisional disponible; después hablaría con el equipo sobre la planificación, en lugar de dar por definitiva mi valoración inicial».

9. ¿Qué harías si el requisito no está claro?

«Haría una pregunta concreta: ¿introducir 2.0 cuenta como una cantidad entera? Anotaría la interpretación acordada y la usaría en los resultados esperados de la prueba, en vez de elegir discretamente el comportamiento que prefiero».

10. ¿Qué harías si queda muy poco tiempo?

«Empezaría por los fallos que podrían impedir las compras o generar cobros incorrectos y después explicaría qué queda sin probar. En mi actualización indicaría la versión probada, los resultados, las lagunas y mi recomendación para que la persona responsable de la versión pueda decidir».

Convierte el rango en un comportamiento observable antes de nombrar las técnicas. Requisito de ejemplo: un campo de cantidad obligatorio acepta números enteros desde 1 hasta 10, ambos incluidos. Un envío válido añade al carrito exactamente esa cantidad. Un envío no válido muestra un mensaje de validación de cantidad y no modifica el carrito. Supón que hay existencias suficientes y que el carrito empieza vacío en cada caso.

Para este ejercicio, acuerda que se rechazan los campos vacíos, los decimales como 1.5 y el texto como «dos». La aceptación de formatos como 2.0, los ceros iniciales o los espacios al principio o al final requiere una regla de formato aparte. No des por sentado que esas opciones forman parte del requisito sobre el rango de números enteros.

Usa tres particiones numéricas: enteros menores que 1, enteros del 1 al 10 y enteros mayores que 10. Elige valores representativos y luego céntrate en los límites de aceptación. La tabla combina un valor interior, comprobaciones de los límites y comprobaciones del formato de entrada.

Respuesta oral de ejemplo: «Vaciaría el carrito, introduciría 10, enviaría el formulario una vez y comprobaría que el carrito contiene 10 artículos. Después volvería a vaciarlo e intentaría introducir 11; esperaría un mensaje de validación y que el carrito no cambiara. Así compruebo el límite superior de aceptación sin confundir un valor mostrado con una actualización correcta».

Si la interfaz impide escribir letras, registra ese comportamiento y prueba las vías de interacción admitidas; no afirmes haber enviado una entrada que no pudiste introducir. Si la persona entrevistadora cambia las existencias a ocho artículos, detente y aclara cómo interactúa la regla de existencias con el límite de cantidad.

La terminología sigue el programa de estudios ISTQB CTFL v4.0.1, elaborado por el equipo del programa de nivel Foundation, cuya fuente y titulares de derechos de autor, ISTQB y los autores del programa, se reconocen aquí. Los requisitos desarrollados y las respuestas de esta guía son ejemplos de entrevista.

Separa las condiciones que determinan un resultado de la secuencia que conduce a él. Suposiciones de ejemplo: el carrito contiene un artículo válido; las existencias se comprueban antes del pago; solo se solicita el pago si hay existencias; el pedido solo se confirma después de aprobarse el pago. Si se rechaza el pago, el carrito queda disponible para otro intento.

Para una tabla de decisión compacta, indica «no solicitado» cuando el pago no pueda realizarse. Así evitas fingir que una combinación imposible necesita un resultado de prueba.

A continuación, describe los estados: Listo, Pago pendiente, Pago fallido y Confirmado. Recorre la secuencia Listo → Pago pendiente → Pago fallido → Pago pendiente → Confirmado. En cada paso, comprueba el estado visible y si existe un pedido.

Un segundo clic mientras el pago está pendiente necesita su propia regla. Supón que el comportamiento acordado consiste en ignorar los envíos duplicados mientras se muestra el progreso. El resultado esperado es un intento de pago y un único pedido final, no dos. Explica qué evidencias necesitarías para comprobarlo en el entorno de pruebas proporcionado; que un botón esté desactivado no demuestra por sí solo qué ocurrió después, en los sistemas posteriores.

Al responder a preguntas sobre pruebas de software en entrevistas, deja clara la dependencia: una tabla de condiciones organiza las opciones, mientras que la secuencia de estados muestra el comportamiento que depende de eventos anteriores. Pide a la persona entrevistadora que confirme las expectativas sobre los reintentos y los envíos duplicados antes de calificar un resultado como defectuoso.

Primero menciona el fallo original y luego describe el posible alcance del cambio. Ejemplo: la versión Q-17 rechaza la cantidad 10, aunque el requisito la permite. La versión Q-18 incluye la corrección. Empieza por repetir en Q-18 los pasos registrados con las mismas condiciones iniciales y comprobar el resultado en el carrito, no solo la ausencia de un mensaje de error.

Después, selecciona un conjunto de pruebas de regresión específico:

• Comprueba 1 y 10 como extremos aceptados, y 0 y 11 como valores vecinos rechazados.
• Comprueba 5 para detectar una corrección que, por accidente, solo acepte un valor extremo.
• Cambia de 9 a 10 la cantidad de una línea ya existente en el carrito y verifica la cantidad y el total.
• Elimina la línea y vuelve a añadirla para comprobar una ruta relacionada del carrito.
• Completa la ruta de pago acordada con una cantidad de 10 y verifica la cantidad del pedido.

Si la persona desarrolladora cambió un validador compartido con la edición del carrito, esa ruta merece atención. Si el cambio está aislado, hablad de una selección menor sin dejar de considerar el impacto del fallo. Pregunta qué componentes cambiaron en lugar de adivinarlo por el título del ticket.

Registra el resultado de cada comprobación y vincúlalo con la corrección y la versión. Si ahora funciona la cantidad 10, pero también se acepta la 11, informa del nuevo fallo; que haya desaparecido el síntoma original no basta para cerrar todas las pruebas. Termina tu respuesta indicando el alcance restante y las comprobaciones bloqueadas.

Ofrece a la persona entrevistadora un informe que podría entregar a un miembro del equipo. Informe de defectos de ejemplo: el requisito de cantidad sigue siendo de 1 a 10, ambos inclusive, pero el entorno de pruebas rechaza el límite superior. Los identificadores y las observaciones siguientes pertenecen a este ejemplo.

ID: QTY-24
Título: Se rechaza la cantidad 10 al añadir un artículo con existencias
Observado: 2026-11-05
Reportado por: Alex, tester manual
Estado: Abierto
Versión: Q-17
Entorno: Tienda de QA, navegador de escritorio; se adjunta la versión exacta
Referencia: Requisito QTY-01; caso de prueba QTY-BOUNDARY-10
Precondiciones: Carrito vacío; cuenta de prueba con sesión iniciada; hay 20 unidades del artículo
Datos: Cantidad 10; artículo TEST-MUG

Pasos:
1. Abre la página del producto TEST-MUG.
2. Introduce 10 en Cantidad.
3. Selecciona Añadir al carrito una vez.
4. Revisa el mensaje de validación y el carrito.

Esperado: Sin error de validación de cantidad; el carrito contiene 10 unidades de TEST-MUG.
Real: Aparece un error de validación de cantidad; el carrito sigue vacío.
Reproducción: 3 fallos en 3 intentos, vaciando el carrito cada vez.
Impacto: Los clientes no pueden añadir de una sola vez la cantidad máxima permitida.
Solución provisional observada: Añadir 5 dos veces da como resultado una cantidad de 10 en el carrito.
Gravedad propuesta: Media según la escala de impacto de este equipo.
Prioridad propuesta: Revisar durante la clasificación antes de la promoción de compras al por mayor.
Evidencias: Captura de pantalla del mensaje; grabación de la sesión; se adjuntan las marcas de tiempo.

En un informe real, sustituye el marcador de posición del entorno y adjunta las evidencias mencionadas. Gestiona los datos de la cuenta y las grabaciones conforme a las normas del equipo. Indica por separado cualquier causa sospechada: «Posible problema en la comparación del límite superior» es una pista, no un resultado observado.

Habla del impacto y la planificación con contexto. La solución provisional puede reducir la interrupción inmediata, mientras que una próxima promoción puede hacer más urgente la corrección. Otro equipo podría usar etiquetas de valoración distintas. Explica primero las consecuencias para el cliente y el momento; después relaciónalos con la escala local. Si la persona desarrolladora no puede reproducir el problema, compara conjuntamente la versión, los datos, la cuenta y la secuencia antes de cambiar el estado del ticket.

Convierte la incertidumbre en una solicitud concreta de decisión. Ejemplo: «El ticket dice que los clientes pueden volver a intentar el pago, pero no aclara si la reserva del carrito se mantiene tras un rechazo. ¿El reintento debería volver a comprobar las existencias?». Anota la respuesta junto al requisito y actualiza los resultados esperados. Hasta entonces, marca la expectativa como no resuelta en vez de contar la comprobación como aprobada.

Con una fecha límite, propone un orden relacionado con los daños probables y la función afectada. En el ejemplo del proceso de pago, empieza por la creación del pedido, el fallo del pago, los envíos duplicados y los totales de cantidad. Después, si queda tiempo, cubre los detalles de presentación de menor impacto. Si una dependencia de configuración bloquea una comprobación de alto riesgo, comunica el bloqueo mientras ejecutas pruebas independientes que sí sean útiles.

Usa una breve actualización sobre la versión con cuatro partes: qué se probó, qué ocurrió, qué se desconoce y qué decisión hace falta.

Ejemplo: «En Q-18, se aprobaron las comprobaciones de cantidades aceptadas y rechazadas, y un pago aprobado creó el pedido esperado. El reintento tras el rechazo del pago está bloqueado porque la configuración de pago de pruebas no está disponible. Recomiendo restablecer esa configuración y completar la comprobación del reintento antes de publicar. Si se publica ahora, la ruta del reintento seguirá siendo un riesgo explícito que deberá aceptar la persona responsable de la versión».

No conviertas «no hubo fallos en las comprobaciones ejecutadas» en «el sistema no tiene defectos». Distingue las comprobaciones aprobadas, fallidas, bloqueadas y no ejecutadas. Al responder a preguntas de entrevista sobre desacuerdos en las pruebas, explica cómo compararías las evidencias con una persona desarrolladora y trasladarías el comportamiento de negocio aún no resuelto a quien deba tomar la decisión. Termina con una próxima acción práctica, como organizar la configuración que falta o aclarar la regla del reintento.

Usa SayNow AI para practicar cómo explicar con claridad tus decisiones sobre las pruebas. Su simulador de entrevista con IA ofrece una conversación por voz con preguntas y repreguntas, seguida de una puntuación y sugerencias sobre fluidez, estructura del contenido, adecuación a la situación y consecución de objetivos.

Prepara un ejemplo de esta guía cuya corrección técnica hayas comprobado antes de abrir el escenario de entrevista de trabajo. En tus respuestas orales, empieza por la decisión, explica el requisito pertinente e indica el resultado esperado. Usa STAR para contar una experiencia pasada, como investigar un defecto controvertido. Si la conversación profundiza en un punto impreciso, responde directamente en vez de volver a empezar toda la historia.

Después, elige un cambio a partir de los comentarios: adelanta el resultado esperado, acorta los antecedentes o aclara tu acción individual. Vuelve a practicar teniendo presente ese cambio. SayNow AI no comprueba la corrección técnica; revisa por separado tu razonamiento sobre las pruebas comparándolo con el requisito y consultando a una persona con experiencia en testing. Considera la puntuación oral como lo que es: comentarios para ensayar.

Practica cómo explicar tu entrevista en el escenario de entrevista de trabajo.

Haz un último ensayo con una condición modificada en lugar de memorizar cada frase. Pide a una persona que practique contigo que cambie el límite de cantidad, elimine la solución provisional o pregunte qué evidencias respaldan un fallo comunicado. Tu tarea consiste en ajustar el resultado esperado de la prueba y explicar las consecuencias.

Usa esta lista para revisar la respuesta:

• ¿Puede quien te escucha identificar el requisito y las suposiciones?
• ¿Has dado datos de prueba concretos y un resultado esperado observable?
• ¿Podría alguien repetir el informe de defectos partiendo de las condiciones iniciales indicadas?
• ¿Has explicado por qué importan las pruebas seleccionadas después del cambio?
• ¿Has distinguido los resultados observados, las causas sospechadas y las preguntas sin resolver?
• ¿Has indicado la próxima acción y quién necesita esa información?

Para las preguntas de entrevistas de puestos de pruebas de software, prepara una historia de un proyecto junto con los ejemplos técnicos. Describe tu propia contribución y el resultado que observaste realmente. Usa las guías relacionadas sobre entrevistas conductuales y STAR para mantener la historia centrada.

Las respuestas sólidas a las preguntas en una entrevista de trabajo sobre pruebas manuales vinculan un requisito claro con entradas deliberadas, resultados esperados y una próxima decisión justificable. Ensaya el ejemplo de cantidad, adapta el informe de defectos a una experiencia que puedas contar con honestidad y explica el riesgo que sigue existiendo después de las comprobaciones que elegiste.