18 preguntas de entrevista para manual testers

Los ingenieros de control de calidad (QA) y los ingenieros de pruebas/testeo entienden cual es el valor de la evaluación. Afortunadamente, tu entrevista no será diferente. Cuando se trata de cubrir puestos de trabajo de testeo manual remoto, los gerentes a cargo de contratación querrán evaluar tus habilidades como candidato, por lo que te harán una serie de preguntas de control de calidad manual en la entrevista, para garantizar que tu candidatura sea la apropiada.

Para ayudarte a superar la prueba, hemos recopilado las preguntas y respuestas más comunes en entrevistas técnicas de testeo manual. Vamos a llevarte paso a paso por el proceso.

En la mayoría de los casos, la entrevista comenzará con varias preguntas de programación para principiantes. Estas preguntas básicas al inicio de la entrevista de pruebas manuales, son una forma sencilla de iniciar un intercambio de puntos de vista acerca de temas fundamentales sobre el testeo de pruebas y plataformas, antes de profundizar en conceptos más avanzados.

Aprovecha las siguientes preguntas y respuestas para demostrar tus técnicas personales en el manejo de pruebas manuales.

El control de calidad debe comenzar lo antes posible. Esto no sólo te da tiempo para definir las funciones específicas dentro del departamento de pruebas, sino que ayuda a mitigar la necesidad de rehacer cualquier trabajo que contenga errores, en una etapa más tardía del proceso.

El ciclo de vida de las pruebas de software (STLC) es un conjunto de actividades de verificación y validación, utilizadas para comprobar un producto metodológicamente. El ciclo de vida completo confirmará todos los criterios de entrada y salida previstos, para garantizar la calidad de cualquier software testeado.

El ciclo de vida típico de las pruebas de software consta de seis etapas:

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

Sin embargo, estas etapas pueden variar. Por ejemplo, la lista de ISTQB incluye las siguientes etapas:

1. Planificación y control de pruebas
2. Análisis y diseño
3. Aplicación y ejecución
4. Evaluación de criterios de salida y presentación de informes
5. Actividades de cierre de pruebas

Es importante tener en cuenta que no tienes que recordar todas las etapas de memoria. Tu respuesta tiene mayor valor cuando puedes demostrar tus conocimientos explicando los puntos clave y su orden general.

Un caso de prueba describe la entrada, la acción y la respuesta esperada para una función de la aplicación sometida a prueba. Considéralo como un conjunto de instrucciones o comandos, que describen el modo en que tratarías de validar una actividad de prueba concreta.

Cuando escribas tu caso de prueba, es importante que incluyas datos específicos en las descripciones, como por ejemplo:

• ID de la prueba
• Unidad a testear
• Prioridad
• Prerrequisitos
• Pasos de la prueba
• Resultado previsto
• Estado/Estatus

Como tester manual, tendrás que redactar informes de defectos para que un proyecto se desarrolle a tiempo y cubriendo las funciones apropiadas. Describe la importancia de los informes de defectos al entrevistador, y asegúrate de nombrar los datos que se necesita recolectar para ello:

• Resumen o título
• Prioridad
• Ambiente
• Pasos a reproducir
• Resultado previsto
• Resultado obtenido

A lo largo del ciclo de vida de las pruebas, es posible que tengas que hacer cambios en el código. Las pruebas de regresión son una práctica que consiste en detectar cualquier posible impedimento, asunto o problema de funcionalidad que se introduzca tras cada cambio en el código. Idealmente, puedes realizar pruebas de regresión después de cualquier modificación de la rama de código, y con la mayor frecuencia posible.

En la entrevista, mantén tu respuesta centrada en las pruebas manuales, no en las automatizadas. Por ejemplo, puedes explayarte sobre un proyecto anterior en el que hiciste pruebas de regresión manuales con JIRA para el seguimiento y solución de errores.

Las pruebas de desarrollo de software se dividen, a grandes rasgos, en dos modelos o categorías: pruebas funcionales y no funcionales.

Las pruebas funcionales comprueban la calidad del comportamiento de una aplicación, donde el software se prueba en un ambiente real (por ejemplo, pruebas de humo, pruebas de regresión).

Las pruebas no funcionales abordan la preparación de un sistema para el rendimiento de aplicaciones no funcionales, probando atributos que no están relacionados con la funcionalidad, como la usabilidad, la fiabilidad y la escalabilidad. Por ejemplo, es fundamental realizar pruebas de acuerdo con las expectativas del usuario (por ejemplo, pruebas de carga, pruebas de estrés y pruebas de volumen).

A grandes rasgos, podemos dividir las pruebas en dos categorías: de caja negra y de caja blanca. Las pruebas de caja negra se basan en requisitos funcionales y de negocio, sin que los ingenieros de pruebas conozcan la estructura interna del software ni el código fuente del programa. Las pruebas de caja blanca analizan la construcción del programa, donde los ingenieros de pruebas utilizan su conocimiento del código fuente y acceden a él para desarrollar y ejecutar casos de prueba. Este método está destinado a poner a prueba la arquitectura del sistema.

Los nombres proceden de términos de ingeniería y corresponden a la función de cada prueba. En una caja negra cerrada, sólo se pueden medir entradas y salidas, mientras que una caja blanca o transparente te permite observar y medir el funcionamiento interno del sistema.

Las pruebas únicas se clasifican en cuatro grupos principales. Cada nivel de prueba permite llevar a cabo etapas como el análisis sistemático, el diseño, la ejecución y la publicación final.

En la entrevista: explica los cuatro niveles de prueba más comunes:

• Las pruebas unitarias revisan los componentes de la aplicación.
• Las pruebas de integración revisan el flujo de datos entre componentes.
• Las pruebas de sistema comprueban el rendimiento, tanto funcional como no funcional, de la aplicación.
• Las pruebas de aceptación revisan que la aplicación funcione de acuerdo con las especificaciones del cliente.

Una vez que las preguntas básicas de la entrevista han sido completadas, el entrevistador pondrá a prueba tus capacidades con preguntas de pruebas manuales en una entrevista para profesionales con más experiencia.

Debido a la amplia gama de condiciones de prueba que existen, los distintos diseños de prueba pueden aumentar la cobertura de la prueba y su ejecución en general, en instancias emparejadas específicamente. Siendo una pregunta de entrevista para ingenieros de pruebas manuales con experiencia, el propósito es comprender el alcance y la amplitud de tus habilidades en cada técnica del diseño de pruebas. Asegúrate de incluir cuándo y por qué elegirías un diseño de prueba específica, y de dar ejemplos de tus proyectos anteriores.

Entre las técnicas habituales de diseño de pruebas, se incluyen:

• Análisis de valores límite (BVA)
• Partición en clases de equivalencia
• Cuadro de decisiones
• Transición de estado/estatus
• Estimación de errores
• Caso de uso para pruebas

Su objetivo como tester manual es medir valores de rendimiento de salida, de acuerdo con las expectativas del cliente y del proyecto. Para definir con eficacia las condiciones de aprobado/fallido (pass/fail) y establecer posibles mejoras de la aplicación, es necesario disponer de métricas de prueba.

Dado que las pruebas manuales tienen casos de uso fuera del alcance de las pruebas automatizadas, éstas vienen con métricas únicas de pruebas que deberás describir en detalle al entrevistador.

Algunos ejemplos de métricas de pruebas manuales son:

• Cobertura de pruebas
• Frecuencia de ejecución de pruebas
• Estado de la prueba
• Métricas de defectos
• Eficacia de pruebas

El Protocolo de Transferencia de Hipertexto (HTTP) intercambia o recupera recursos y datos web por medio de peticiones, permitiendo la interacción entre clientes y servidores. Se utilizan métodos HTTP específicos para realizar acciones en la web, o acceder a información:

• GET
• POST
• PATCH
• PUT
• DELETE
• CONNECT
• HEAD

Al realizar peticiones a través de métodos HTTP, los evaluadores manuales pueden examinar el rendimiento de las aplicaciones web. En la entrevista, enumera y comenta escenarios de pruebas habituales, así como el modo en que implementarías cada método HTTP.

Tu objetivo es entregar un software sin errores ni fallos. Desgraciadamente, las limitaciones de tiempo, presupuesto y recursos dificultan completar una cobertura total de las pruebas, sobre todo si se tienen en cuenta los casos de uso específicos relacionados con las pruebas manuales.

Para apoyar un proyecto basado en la web, puedes disponer de una serie de herramientas de prueba:

• SOAP UI
• Poster para Firefox
• Postman
• Rest Assured
• Swagger

Como pregunta de entrevista de tester manual para ingenieros con experiencia, ésta es tu oportunidad de explicar tu enfoque específico a la hora de realizar pruebas. Utiliza cada herramienta de pruebas para demostrar cómo mantienes un plan de pruebas eficaz y exhaustivo a lo largo de toda la extensión de un proyecto.

El riesgo de proyecto se refiere a variables que amenazan el objetivo final de un proyecto (por ejemplo, cuestiones organizativas y políticas). Por otro lado, el riesgo de producto pone en duda la calidad del producto final (es decir, la funcionalidad o fiabilidad del software). Como jefe de equipo, a menudo tendrás que equilibrar ambas formas de riesgo. Usa esta pregunta para demostrar tus habilidades de liderazgo, y utiliza ejemplos de tus proyectos anteriores para demostrar tu capacidad de gestión.

Muchas aplicaciones se instalan en servidores UNIX, lo que significa que los ingenieros de pruebas deben conocer los conceptos básicos de UNIX. Puedes utilizar comandos UNIX para invocar a/interactuar con el terminal UNIX. Demuestra tus conocimientos de UNIX, enumerando y explicando los comandos UNIX que podrías utilizar como tester manual.

Los comandos Unix más comunes son:

• less: ver y abrir archivos
• cp, rm: eliminar o copiar un solo dígito files (archivos)
• chmod: obtener archivopermissions (permisos)
• ls: entrega una lista con el contenido de los archivos

El concepto de cobertura de pruebas es controvertido entre los ingenieros de software. Algunos sostienen que es innecesario, porque la cobertura de las pruebas no es una prueba fehaciente de calidad (¿por qué obtener un 100% en una prueba inútil?). Además, muchos consideran que es imposible conseguir una cobertura completa, ya que la completitud es una certeza que nunca está garantizada.

En la entrevista, explica cómo influyen estas perspectivas en tu planteamiento de pruebas, y explica cómo harías para acercarte lo más posible al 100% (por ejemplo, fijando límites estrictos para los factores presupuestarios o sobre el número de errores corregidos).

Los recursos son los contenidos fundamentales de la arquitectura REST. Un servidor accede al contenido mientras el cliente lo modifica. Sion embargo, una vez que un recurso ha sido identificado, necesita representación.

TEXT, JSON y XML son los formatos más populares para comprender los recursos. Dado que las pruebas manuales suelen llamar a un recurso REST para validar su respuesta, una pregunta de este tipo en una entrevista es el momento perfecto para demostrar tus habilidades con las pruebas funcionales de REST.

Los cambios realizados en una iteración durante un sprint Scrum, inducen mucha confusión entre los equipos Scrum. Algunos creen que cualquier cambio debe ser considerado como un sprint completamente nuevo, mientras que otros consideran que todos los cambios que acarrean valor para el cliente, son una inclusión que vale la pena.

Lo ideal es llegar a un equilibrio, pero no hay una respuesta correcta. El entrevistador formula esa pregunta abierta para determinar qué valores de prueba estás siguiendo. Compara los pros y los contras de ambas posturas.

Las estimaciones de pruebas son fundamentales para que los proyectos se entreguen a tiempo y dentro del presupuesto. Técnicas de estimación de pruebas distintas dan resultados diferentes (punto de función, tres puntos, etc.). El tipo de estimaciones de pruebas que diseñes, dependerá de variables como la destreza del equipo, la complejidad de la aplicación y los recursos que tengas disponibles.

La forma en que estimas tu productividad y tu esfuerzo demostrará al entrevistador tus habilidades y tu competencia como líder, así que prepárate para defender tu técnica de estimación de pruebas preferida.

Al final de la entrevista, habrás explicado la mayoría de los conceptos fundamentales de las pruebas. Y si te has preparado con antelación, habrás entregado una explicación precisa de tus habilidades y capacidades como tester manual.

Aun así, las pruebas manuales requieren pensar mucho "fuera de la caja". El objetivo de cada pregunta no es reanudar explicaciones previas o dar las mismas respuestas cada vez, sino demostrar tu modo de afrontar el desarrollo de pruebas. Cuando eres capaz de deliberar sobre conceptos de pruebas de software, entonces tu entrevistador podrá evaluar mejor cómo encajarías en la estructura de la empresa.

Asegúrate de practicar y prepararte de acuerdo con los requisitos específicos de pruebas, que figuran en la descripción de la oferta de trabajo, yprepárate para explicar tu estilo personal de manejo de pruebas manuales.

¿Quieres avanzar en tu carrera como tester manual? Explora nuestras ofertas de trabajo de tester manual en EPAM Anywhere y presenta tu candidatura.