Preguntas y Respuestas de la Entrevista de Pruebas Manuales 2023

Para Profesionales de Nivel Principiante, Intermedio y Avanzado

A medida que el mundo avanza cada vez más hacia la automatización, las pruebas manuales siguen teniendo un espacio en el mundo de las pruebas de software.De hecho, a menudo son consideradas un complemento de las pruebas automatizadas. Como resultado, existe una alta demanda de especialistas en QA manual.

Si planeas seguir una carrera de pruebas manuales, ¡has llegado al lugar correcto! En este artículo, revisaremos algunas preguntas y respuestas de una entrevista para pruebas manuales. Ya sea que tu nivel de experiencia como tester manual sea principiante, intermedio o avanzado, este artículo tiene algo para ti.

Principales Preguntas y Respuestas de la Entrevista de Pruebas Manuales de QA de 2022 

Preguntas de Entrevista para Principiantes

1. ¿Qué son las pruebas de software?

Las pruebas de software son un proceso que garantiza que el software desarrollado cumpla todos los requisitos especificados. Las pruebas evalúan a un sistema en términos de usabilidad, precisión, integridad, eficiencia, entre otros.

2. ¿Puedes definir la terminología clave que se usa en el proceso de pruebas?

• La ejecución de un caso de prueba significa que se concluyó exitosamente un ciclo completo de pruebas tras la corrección final de un bug.
• Una fecha límite de prueba es la fecha en que la fase de validación termina y, si no quedan defectos críticos o de alta prioridad, la validación se declara completa.
• El índice de cobertura de código (CC, por sus siglas en inglés) es el porcentaje de código cubierto por las pruebas automatizadas. El equipo puede terminar la validación tras alcanzar el índice de cobertura de código (CC) deseado.

3. ¿Cuáles son los diferentes niveles de pruebas?

Los cuatro niveles de pruebas son los siguientes:

• Las pruebas de unidad/componente/programa/módulo examinan cada unidad o componente de una aplicación software.
• Las pruebas de integración validan el flujo de datos de un módulo o componente a otro.
• Las pruebas de sistema verifican los requisitos funcionales y no funcionales del software y evalúan la aplicación como un sistema completo.
• Las pruebas de aceptación condensan todos los procesos de pruebas anteriores para determinar si se cumplió una especificación o requisito.

4. ¿Qué es un plan de pruebas y qué incluye?

Un plan de pruebas documenta todas las posibles actividades de prueba para garantizar la calidad de un producto. Recopila información de la descripción del producto, los requisitos y documentos de casos de uso como:

• Objetivos de las pruebas
• Alcance de las pruebas
• Calendario de pruebas
• Entorno
• Motivo de la prueba
• Criterios de entrada y salida
• Entregables
• Factores de riesgo

5. ¿Qué es la cobertura de las pruebas?

La cobertura de las pruebas es una métrica de calidad que muestra las pruebas completadas como un porcentaje. Se usa para identificar casos de prueba faltantes tanto en pruebas funcionales como no funcionales.

6. ¿Cuáles son los diferentes tipos de pruebas de software?

Los especialistas en QA usan una gran variedad de enfoques al probar el software, entre ellos:

• Pruebas unitarias
• Pruebas de integración
• Pruebas de regresión
• Pruebas de shakeout 
• Pruebas de humo
• Pruebas funcionales
• Pruebas de desempeño: 
  • Pruebas de carga
  • Pruebas de estrés
  • Pruebas de resistencia
• Pruebas alfa y beta
• Pruebas de sistema

7. ¿Se pueden realizar pruebas durante cualquier fase?

Las pruebas de sistema deben comenzar una vez que todos los módulos estén implementados y funcionando correctamente. Sin embargo, deben completarse antes de las pruebas de aceptación del usuario (UAT, por sus siglas en inglés).

8. ¿Qué es STLC?

El ciclo de vida de las pruebas de software (STLC, por sus siglas en inglés) es una infraestructura para organizar y gestionar el proceso de pruebas que facilita la ejecución de pruebas de manera planificada y sistemática para garantizar la calidad del producto.

Los componentes clave del STLC incluyen:

• Análisis de requisitos
• Planificación de pruebas
• Desarrollo de casos de prueba
• Configuración del entorno
• Ejecución de pruebas
• Cierre del ciclo de pruebas

9. ¿Qué significan los términos verificación y validación en las pruebas de software?

En las pruebas de software, la verificación se realiza durante el proceso de desarrollo para confirmar que un producto sigue las especificaciones y usa procedimientos estándar de desarrollo. Incluye las siguientes actividades:

• Inspecciones
• Revisiones
• Recorridos
• Demostraciones

La validación se usa en un producto desarrollado para confirmar que está libre de bugs y que funciona como se espera. La validación implica lo siguiente:

• Pruebas funcionales
• Pruebas no funcionales

10. ¿Qué son las pruebas de caja negra? y ¿cuáles son los diferentes tipos de pruebas de caja negra?

Las pruebas de caja negra son un enfoque de pruebas de software donde los testers evalúan la funcionalidad del software de acuerdo con los requisitos del negocio. Los  testers simulan la perspectiva del usuario final evaluando un programa sin usar su código ni su estructura interna.

Las diferentes técnicas de pruebas de caja negra son:

• Partición de equivalencia
• Análisis de valores límite
• Gráfico de causa y efecto

11. ¿Qué son las pruebas de caja blanca? y ¿cuáles son los diferentes tipos de pruebas de caja blanca?

Las pruebas de caja blanca consisten en seleccionar casos de prueba con base en el análisis de un componente o de la estructura interna de un sistema, como la cobertura de código, cobertura de rama, cobertura de ruta, cobertura de condición, etc. También se les conoce como pruebas basadas en código o pruebas estructurales. 

Entre los tipos pruebas de caja blanca, están:

• Coberturas de sentencias
• Cobertura de decisiones

12. ¿Cuáles son los pasos de las pruebas de caja blanca?

Las pruebas de caja blanca verifican los siguientes atributos del software:

• Defectos de seguridad del código
• Rutas de código incompletas o inservibles
• Flujo de la estructura según se especificó en el documento
• Resultados previstos
• Bucles condicionales en el código
• Pruebas al 100% y codificación línea por línea

13. ¿Qué son las pruebas de flujo de datos?

Las pruebas de flujo de datos son un tipo de pruebas de caja blanca que evalúan el flujo de datos en relación con las variables del código. Examina la inicialización de variables y verifica los valores en cada instancia.

Requiere los siguientes atributos:

• Datos de entrada del módulo
• La ruta del flujo de control de pruebas
• Un par de definiciones de variables apropiadas y sus aplicaciones
• El resultado previsto del caso de prueba

14. ¿Qué es una matriz de trazabilidad?

Una matriz de trazabilidad es un documento, generalmente en forma de tabla, que se usa en el desarrollo de software para determinar la integridad de una relación entre los casos de prueba y los requisitos.

15. ¿Cuál es la diferencia entre pruebas unitarias y pruebas de integración?

Las pruebas unitarias son un tipo de pruebas de software que se usan para verificar si un pequeño pedazo de código está funcionando apropiadamente. 

Como su nombre lo indica, las pruebas de integración son un tipo de pruebas de software que verifican la funcionalidad de la interfaz entre dos unidades o módulos de software. En algunos casos, pueden abarcar toda la aplicación.

16. ¿Qué son las pruebas ágiles?

Las pruebas ágiles son un enfoque de pruebas de software que toma la perspectiva del usuario final. El equipo de QA puede empezar a probar antes sin esperar a que el equipo de desarrollo termine de escribir el código. Como resultado, los procesos de desarrollo y pruebas pueden ocurrir simultáneamente. 

17. ¿Cuál es el objetivo de las pruebas de extremo a extremo?

La estrategia de pruebas de extremo a extremo abarca todos los posibles flujos de una aplicación. El objetivo de las pruebas de extremo a extremo es identificar las dependencias de software y verificar que los datos de entrada correctos se pasen entre los diferentes módulos y subsistemas del software.

Preguntas de Entrevista para Testers Manuales de Nivel Intermedio

1. ¿Cómo alcanzarías una cobertura de pruebas del 100%? ¿Es posible?

Se considera imposible probar todos los aspectos de un producto. Estas son las dos razones principales por las que nunca se puede probar un software en su totalidad:

• Las especificaciones de software pueden ser subjetivas, lo que conduce a una amplia gama de interpretaciones.
• Un programa de software puede requerir una cantidad excesiva de datos de entrada, resultados y combinaciones de rutas.

Sin embargo, si se siguen estos pasos, podemos acercarnos a una cobertura del 100%:

• Establecer límites estrictos en las siguientes variables:
  • Porcentaje de casos de prueba exitosos
  • Cantidad de bugs identificados
• Establecer una bandera roja si se cumple alguna de las siguientes condiciones:
  • Presupuesto de pruebas gastado
  • Plazos no cumplidos
• Establecer una bandera verde si se cumple alguna de las siguientes condiciones:
  • Los casos de prueba cubren toda la funcionalidad
  • Los errores importantes tienen estatus de CLOSED

2. ¿Cuáles son las diferencias entre pruebas basadas en datos y repetición de pruebas?

La repetición de pruebas o retesting se refiere a volver a verificar los bugs recién corregidos una vez que el equipo de desarrollo ha realizado los cambios. La repetición de pruebas es un proceso manual que consiste en probar una aplicación con un solo conjunto de datos. Durante las pruebas basadas en datos, se evalúa la aplicación usando múltiples conjuntos de datos de prueba y diversos valores.

3. ¿Cuáles son las diferencias entre la repetición de pruebas y las pruebas de regresión?

Las siguientes son algunas diferencias entre la repetición de pruebas y las pruebas de regresión:

• La repetición de pruebas garantiza la corrección de los defectos, mientras que las pruebas de regresión verifican que la corrección de un bug no haya afectado negativamente a otras partes de la aplicación.
• Las pruebas de regresión garantizan la reejecución de los casos de prueba aprobados, mientras que la repetición de pruebas implica la ejecución de los casos de prueba fallidos.
• La repetición de pruebas tiene mayor prioridad que las pruebas de regresión, pero en ocasiones ambas se pueden ejecutar simultáneamente.

4. ¿Cuál es la diferencia entre los drivers y los stubs de pruebas?

Un driver de pruebas es el pedazo de código responsable de llamar al sistema o programa que se está probando. Suele usarse en las pruebas ascendentes. Un stub de pruebas es un programa simulado que funciona junto a una aplicación para completar su funcionalidad y se aplica en las pruebas que emplean un enfoque descendente.

5. ¿Cuál es la diferencia entre UAT y pruebas del sistema?

Las pruebas del sistema, también conocidas como pruebas de extremo a extremo, identifican defectos cuando el sistema se prueba como un todo. En este tipo de pruebas, toda la aplicación tiene fallos.

Las pruebas de aceptación del usuario (UAT) someten un producto a una serie de pruebas específicas para garantizar que cumple las especificaciones.

6. ¿Qué pasos se deben seguir al descubrir un bug? 

Cuando ocurra un bug, se deben seguir estos pasos:

• Ejecutar pruebas adicionales para asegurarse de que el problema está bien definido.
• Realiza algunas pruebas más para asegurarse de que no ocurra el mismo problema con diferentes datos de entrada.
• Una vez que se haya determinado el alcance total del error, especificarlo y reportarlo.

7. ¿Cómo se prueba un producto cuando aún se están terminando los requisitos?

Cuando a un producto le faltan las especificaciones necesarias, es posible crear un plan de pruebas con base en suposiciones acerca del producto. Sin embargo, estas suposiciones deben documentarse meticulosamente en el plan de pruebas.

8. ¿Qué haría sin la documentación de pruebas apropiada?

Cuando los documentos oficiales como la especificación de los requisitos del sistema o la descripción de características no están disponibles, es posible que los especialistas de control de calidad tengan que recurrir a las siguientes alternativas:

• Capturas de pantalla
• Versiones anteriores de la aplicación
• Wireframes
• Emails o cualquier otro tipo de comunicación entre los miembros del equipo

Hablar con los desarrolladores o analistas del negocio también puede ayudarte a aclarar o mejorar tu comprensión. 

Si ninguna de estas alternativas te ayuda, piensa en la aplicación con base en tu experiencia y realiza un conjunto básico de scripts de pruebas. Al llegar a la fase de pruebas, puedes realizar la gestión de casos de prueba para afinar los scripts existentes y crear documentación para las siguientes fases.

 9. ¿Puede mencionar los desafíos principales de las pruebas de software?

• La ausencia de documentación estándar
• Cantidad insuficiente de testers calificados
• Limitaciones de tiempo y plazos estrictos
• Pruebas insuficientes y cantidad inadecuada de casos de prueba

10. ¿Cuáles son los tipos de pruebas funcionales?

• Pruebas unitarias
• Pruebas de humo
• Pruebas de aceptación del usuario
• Pruebas de sanidad
• Pruebas de interfaz
• Pruebas de integración 
• Pruebas del sistema
• Pruebas de regresión

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

El objetivo de las pruebas funcionales es determinar qué tan bien funciona el software o la aplicación, en otras palabras, lo que hace el producto. Las pruebas funcionales se realizan de acuerdo con los requisitos del negocio, y los resultados reales de las pruebas se comparan con los resultados esperados.

Las pruebas no funcionales garantizan que una app siempre trabaje de manera eficiente y sin problemas, como el usuario espera. Todos los casos de prueba se construyen en torno a las expectativas del usuario y las necesidades de desempeño. Este tipo de pruebas evalúan el tiempo de respuesta y la velocidad del software bajo condiciones específicas.

12. ¿Cuál es la diferencia entre STLC (ciclo de vida de las pruebas de software) y SDLC (ciclo de vida del desarrollo de software)?

El ciclo de vida de las pruebas de software (STLC, por sus siglas en inglés) es una serie de actividades que tienen lugar durante el proceso de pruebas de software. El ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés) es una serie de actividades que se llevan a cabo durante el proceso de desarrollo del software. 

Por lo tanto, el SDLC se relaciona principalmente con el desarrollo de software, mientras que el STLC se relaciona con el proceso de las pruebas del software.

13. ¿Qué significa una falla en las pruebas de software?

Una falla es una condición donde la ejecución del software fracasa al realizar la función especificada o la función en cuestión.

14. ¿Cuál es la diferencia entre bug, defecto, error y falla?

• Un error es una equivocación cometida por un programador al codificar. 
• Un defecto es un fallo encontrado por el tester durante la fase de desarrollo. 
• Un bug es un error encontrado durante las pruebas y confirmado por el equipo de desarrollo. 
• Una falla se define como un error descubierto por el usuario final.

15. ¿Cómo se relacionan la gravedad y la prioridad entre sí?

La gravedad de un bug indica su importancia y efecto sobre el software. La prioridad es un parámetro que especifica el orden en que se atienden los bugs. De esta manera, la gravedad se relaciona con los estándares de calidad, mientras que la prioridad se relaciona con la planificación de los defectos del software que necesitan solucionarse.

16. ¿Cuáles son los distintos tipos de gravedad?

Dependiendo del contexto, la gravedad de un bug puede ser baja, moderada o alta. Algunos ejemplos son:

• Defectos de la interfaz de usuario – Baja
• Defectos relacionados con los límites – Media
• Defectos de manejo de errores – Media
• Defectos de cálculo – Alta
• Datos mal interpretados – Alta
• Fallos de hardware – Alta
• Problemas de compatibilidad – Alta
• Defectos de flujo de control – Alta
• Condiciones de carga – Alta

Preguntas de Entrevista para Testers Manuales con Experiencia

1. ¿Qué habilidades debe tener un líder de pruebas experimentado o un profesional de control de calidad?

• Conocimientos de metodologías de pruebas de software
• Capacidad para aumentar la productividad y la cooperación en equipo
• Capacidad para mejorar la colaboración entre los ingenieros de QA y los de Desarrollo 
• Capacidad para ofrecer sugerencias para mejorar los procesos de QA
• Capacidad para dirigir reuniones de RCA y alcanzar conclusiones
• Excepcionales habilidades interpersonales y de comunicación escrita
• Capacidad para aprender rápidamente y orientar a los miembros del equipo

2. ¿Cuál es el proceso de creación de un script de pruebas?

El proceso de escritura de un script de pruebas puede dividirse en tres pasos principales:

• Paso 1: Conseguir una comprensión total de la aplicación. Leer atentamente los documentos requeridos. En ausencia de documentación, se pueden usar otras referencias disponibles, como versiones anteriores de la aplicación, wireframes o capturas de pantalla.
• Paso 2: Identificar los requisitos de las pruebas. En esta fase, se debe identificar lo que se va a probar creando una lista de las áreas de la aplicación que requieren pruebas. 
• Paso 3: Realizar un plan de pruebas y determinar los datos de las pruebas. Una vez que se cuenta con los requisitos de las pruebas, pueden enfocarse en cómo probarlos. Esta etapa implica escribir instrucciones detalladas sobre cómo probar una función específica, qué datos introducir y el resultado esperado. 

Una vez que estos tres pasos estén completos, se puede empezar a probar la aplicación.

3. ¿Cuál es el porcentaje de detección de defectos en las pruebas de software? y ¿cómo se calcula?

La proporción de bugs detectados antes de la liberación en relación con los bugs detectados después de la liberación se conoce como porcentaje de detección de defectos (DDP, por sus siglas en inglés). Su objetivo es evaluar la eficiencia del proceso de pruebas.

Supongamos que el equipo de QA encontró 52 problemas durante las pruebas y el cliente encontró otros 20 tras la liberación. En este caso, el DDP sería 52 / (52 + 20) = 72%.

4. ¿Cuál es la definición de eficacia de eliminación de defectos en las pruebas de software? y ¿cómo se calcula?

La eficacia de eliminación de defectos (DRE, por sus siglas en inglés) mide la capacidad del equipo de desarrollo para resolver problemas antes de la liberación. Se calcula como la proporción entre los defectos corregidos y la cantidad total de problemas encontrados.

Fórmula del DRE: DRE= (Cantidad de defectos encontrados internamente/ Cantidad de defectos encontrados internamente + Cantidad de defectos encontrados externamente) × 100.

Por ejemplo, si se descubrieron 89 defectos durante el ciclo de pruebas y se corrigieron 75, entonces el DRE sería 64/89 = 83%.

5. ¿Cómo se maximizan los resultados de un equipo offshore?

La clave es involucrar a todos en la revisión de los scripts de pruebas, asistir a reuniones sobre los defectos y participar en sesiones de transferencia de conocimientos de manera que todo el equipo entienda la aplicación a profundidad.

Promover el trabajo en equipo y la cooperación puede mejorar la unidad del equipo, y las reuniones de seguimiento regulares ayudan a mantener los proyectos funcionando sin problemas.

6. ¿Cuáles son los roles y responsabilidades de un coordinador in situ?

El coordinador in situ sirve como punto de contacto entre el equipo offshore y el cliente respecto a la participación en las pruebas. Sus responsabilidades suelen incluir:

• Transferencia de Conocimientos (KT, por sus siglas en inglés) entre clientes offshore 
• Preparar el entorno de pruebas
• Pruebas de humo y de sanidad
• Pruebas
• Revisión de los bugs descubiertos por el equipo offshore
• Asignar bugs al desarrollador correspondiente
• Proporcionar métricas
• Cierre

7. ¿Cómo lidiar con los bugs inconsistentes? 

Cada bug, ya sea que se haya encontrado in situ u offshore y sea repetible o no, debe ser documentado y analizado. En lugar de simplemente reportar problemas, los testers pueden agregar valor real participando en la determinación de la causa de los bugs.

Estas son algunas estrategias para lidiar con los bugs inconsistentes:

• Los equipos in situ y offshore deben seguir la política de tomar capturas de pantalla para cualquier error encontrado, sea repetible o no.
• Los equipos deben buscar cualquier log, archivo del sistema o posible fuente del problema.
• Sí después de implementar estas medidas, los equipos no pueden determinar la causa del error ni cuándo ocurre, deberán notificar al desarrollador de la manera más detallada posible.

8. ¿Cómo se prueba una aplicación que contiene video o audio?

Al probar una aplicación que contiene audio o video, se deben considerar los siguientes elementos clave:

• Niveles de acceso (con o sin restricciones mediante contraseñas)
• Diversos tipos de entornos
• Compatibilidad con los navegadores
• Resoluciones de pantalla
• Velocidades de conexión a Internet
• Las opciones específicas de un video, como play, stop y mute
• Tamaño del video 
• Comentarios en los videos (límites en la longitud de los comentarios y la cantidad de comentarios permitidos)
• Reacciones al video
• Interoperabilidad con sitios de redes sociales
• Velocidad de almacenamiento en buffer

 9. ¿Qué factores harían que prefirieras las pruebas automatizadas sobre las manuales?

La pruebas automatizadas se eligen sobre pruebas manuales si:

• Las pruebas deben realizarse regularmente.
• Las pruebas involucran procedimientos repetitivos.
• Las pruebas se llevan a cabo en un entorno de ejecución estándar.
• Automatizar las tareas acelera el proceso.
• La automatización aumenta la reutilización.
• Los reportes automatizados están disponibles para cada ejecución.
• Versiones menores (como los service packs) contienen correcciones de bugs menores. 

10. ¿Cuál es el proceso para probar una aplicación móvil?

• Verificar si la app es compatible con múltiples operadores y dispositivos.
• Examinar la usabilidad de las funciones en diversos dispositivos móviles.
• Probar la app en diferentes plataformas móviles, incluyendo Android e iOS.
• Examinar los procesos de instalación y desinstalación, y asegurarse de que la app se ejecute con y sin red.
• Examinar el rendimiento de la app con diversas conexiones de red, como WiFi, 2G y 5G.
• Depurar la aplicación con la utilidad de configuración de iOS para iPhone y los logs de Android Device Monitor. 

Conclusión

Las pruebas manuales son una gran forma de mantenerse a la vanguardia en el siempre cambiante mundo del desarrollo de software. Esperamos que nuestra lista de preguntas y respuestas de pruebas manuales te ayuden a sobresalir en tu carrera de tester manual del año 2023 en adelante. 

¡También tenemos algo para aquellos que están pensando en elegir esta carrera! Con la formación adecuada, puedes empezar a ganar un salario de más de 70,000 dólares después de solo dos meses de capacitación. ¡Checa nuestra Formación para Tester Manual y empieza a aprender hoy!