Las 39 Preguntas Principales de La Entrevista Sobre Pruebas de Automatización
Las 39 Preguntas Principales de La Entrevista Sobre Pruebas de Automatización
Las 39 Preguntas Principales de La Entrevista Sobre Pruebas de Automatización
automatización
Hemos cubierto preguntas básicas de automatización de pruebas, así como algunas
preguntas avanzadas para candidatos de nivel intermedio a experto de hasta 2 a 5 años de
experiencia.
P # 1) ¿Qué es la automatización?
Responder: La automatización es cualquier acción que pueda reducir los esfuerzos humanos.
P # 2) ¿Qué son las pruebas de automatización?
Responder: El proceso de utilizar herramientas de software especiales o scripts para realizar tareas de
prueba, como ingresar datos, ejecutar los pasos de prueba y comparar los resultados, etc., se conoce como
prueba de automatización.
P # 3) ¿Qué cosas puedes automatizar?
Responder:
Conjunto de pruebas de regresión
Conjunto de pruebas de humo / cordura
Desarrollar implementación
Creación de datos de Prueba
Automatización detrás de la GUI como pruebas de API y métodos.
P # 4) ¿Cuándo son útiles las pruebas de automatización?
Responder: Las pruebas de automatización son útiles en los siguientes escenarios:
a) Prueba de regresión: En caso de que se solucione un error o se implemente un nuevo módulo, debemos
asegurarnos de que la funcionalidad ya implementada o sin cambios no se vea afectada. En este caso,
terminamos ejecutando el caso de prueba de regresión varias veces.
Por ejemplo: Después de cada solicitud de cambio o corrección de errores, después de cada iteración en
caso de enfoque de desarrollo incremental, etc.
b) Pruebas no funcionales: Prueba de los aspectos no funcionales de una aplicación.
Por ejemplo, Las pruebas de carga o de rendimiento, etc., son muy difíciles de rastrear y analizar para los
humanos.
c) Cálculo complejo controles o escenarios de prueba que son propensos a errores humanos.
d) Ejecución repetida de las mismas pruebas: A veces, tenemos que ejecutar el mismo conjunto de casos
de prueba para un conjunto diferente de datos o después de cada versión de compilación o en varios
hardware, software o una combinación de ambos.
La automatización de los casos de prueba en los escenarios anteriores ayuda a lograr la velocidad de las
pruebas y a minimizar los errores humanos.
P # 5) ¿Cómo identifica los casos de prueba que son adecuados para la automatización?
Responder: Identificar los casos de prueba adecuados para la automatización es el paso más importante
hacia la automatización.
P # 6) ¿Puede lograr el 100% de automatización?
Responder: Sería difícil lograr una automatización del 100% porque habría muchos casos de prueba de
borde y algunos casos que se ejecutan raras veces. Automatizar estos casos que no se ejecutan a menudo no
agregará valor a la suite automatizada.
P # 7) ¿Cómo decidir la herramienta que se debe utilizar para las pruebas de automatización en sus
proyectos?
Respuesta: Para identificar la herramienta para las pruebas de automatización en su proyecto:
a) Comprenda los requisitos de su proyecto a fondo e identifique los escenarios de prueba que desea
automatizar.
b) Busque la lista de herramientas que se adaptan a los requisitos de su proyecto.
c) Identifique su presupuesto para la herramienta de automatización. Seleccione las herramientas dentro de
su presupuesto.
D) Identifique si ya cuenta con recursos capacitados para las herramientas. Si no tiene los recursos calificados
necesarios, identifique el costo de capacitar los recursos existentes o contratar nuevos recursos.
es) Ahora compare cada herramienta para criterios clave como:
¿Qué tan fácil es desarrollar y mantener los scripts para la herramienta?
¿Puede una persona no técnica también ejecutar los casos de prueba con poca formación?
¿La herramienta es compatible con diferentes tipos de plataformas como web, móvil, escritorio, etc.,
según los requisitos de su proyecto?
¿Tiene la herramienta una función de informes de prueba? Si no es así, ¿se puede configurar
fácilmente para la herramienta?
¿Cómo es la herramienta para compatibilidad entre navegadores para aplicaciones basadas en web?
¿Cuántos tipos de pruebas diferentes puede admitir esta herramienta?
¿Cuántos idiomas admite la herramienta?
F) Una vez que haya comparado las herramientas, seleccione la herramienta que esté dentro de su
presupuesto y sea compatible con los requisitos de su proyecto, y le brinde más ventajas basadas en los
criterios clave mencionados anteriormente.
P # 8) Actualmente no tengo ninguna automatización en mi proyecto, pero ahora quiero implementar la
automatización, ¿cuáles serían mis pasos?
Responder:
Primero, identifique qué tipo de pruebas / casos de prueba desea automatizar.
Identificar la herramienta
Diseñar el marco
Cree archivos de utilidad y archivos de entorno.
Empezar a escribir
Identificar y trabajar en la elaboración de informes.
Asignar tiempo para mejorar y mantener los guiones.
Los pasos necesarios para implementar las pruebas de automatización en un proyecto incluyen:
Comprender las ventajas y desventajas de las pruebas de automatización e identificar los
escenarios de prueba que son adecuados para la automatización.
Seleccione la herramienta de automatización que sea más adecuada para automatizar los
escenarios identificados.
Busque al experto en herramientas para que le ayude a configurar la herramienta y el entorno
necesario para ejecutar los casos de prueba con la herramienta.
Capacite al equipo para que pueda escribir scripts en el lenguaje de programación que admite
la herramienta.
Cree el marco de prueba o identifique el ya existente que cumpla con sus requisitos.
Escriba un plan de ejecución para SO, navegadores, dispositivos móviles, etc.
Escriba scripts de programación para casos de prueba manuales para convertirlos en casos de
prueba automatizados.
Informe el estado del caso de prueba mediante la función de informes de la herramienta.
Mantenga los scripts para cambios continuos o nuevas funciones.
P # 9) ¿Cómo decides qué herramienta tienes que usar?
Responder: Concluyendo que herramienta es la más adecuada para el proyecto se requiere mucha lluvia de
ideas y discusiones.
P # 10) Una vez que identifique la herramienta, ¿cuáles serían sus próximos pasos?
Responder: Una vez que finalicemos la herramienta, nuestro siguiente paso sería diseñar el marco.
P # 11) ¿Qué es un marco?
Responder: Un marco es un conjunto de la estructura de toda la suite de automatización. También es una
pauta, que si se sigue puede dar como resultado una estructura que es fácil de mantener y mejorar.
Estas pautas incluyen:
Estándares de codificación
Manejo de los datos de prueba
Mantenimiento y manejo de los elementos (repositorio de objetos en QTP)
Manejo de archivos de entorno y archivo de propiedades
Notificación de datos
Manejo de registros
P # 12) ¿Cuáles son los atributos de un buen marco?
Respuesta: Las características incluyen:
Modular: El marco debería poder adaptarse al cambio. Los evaluadores deben poder modificar los
scripts según el entorno o el cambio de información de inicio de sesión.
Reutilizable: Los métodos o utilidades comúnmente utilizados deben escribirse en un archivo común
que sea accesible para todos los scripts.
Consistente: La suite debe escribirse en un formato coherente siguiendo todas las prácticas de
codificación aceptadas.
Independiente: Los guiones deben estar escritos de tal manera que sean independientes entre sí. En
caso de que una prueba falle, no debe retener los casos de prueba restantes (a menos que sea una
página de inicio de sesión)
Registros: Es bueno haber implementado la función de registro en el marco. Esto ayudaría en caso de
que nuestros scripts se ejecuten durante más horas (digamos en modo nocturno), si el script falla en
algún momento, tener el archivo de registro nos ayudará a detectar la ubicación junto con el tipo de
error.
Informes: Es bueno tener la función de informes incorporada automáticamente en el marco. Una vez
finalizada la secuencia de comandos, podemos hacer que los resultados y los informes se envíen por
correo electrónico.
Integración: Automation Framework debe ser tal que sea fácil de integrar con otras aplicaciones como
la integración continua o la activación del script automatizado tan pronto como se implemente la
compilación.
P # 13) ¿Puedes prescindir de un marco?
Responder: Los marcos son pautas y no reglas obligatorias, por lo que podemos prescindir de un marco,
pero si lo creamos y lo seguimos, mejorar y mantener sería fácil de implementar.
P # 14) ¿Cuáles son los diferentes tipos de herramientas de automatización que conoce?
Responder: Herramienta de código abierto como Selenium, JMeter, etc.
Herramientas pagas como QTP, Load Runner, Ranorex, RFT y Rational Robot.
P # 22) ¿Cómo selecciona qué herramienta de automatización es la más adecuada para usted?
Responder: La selección de la herramienta de automatización depende de varios factores como:
El alcance de la aplicación que queremos automatizar.
Gastos generales de gestión como costes y presupuesto.
Es hora de aprender e implementar la herramienta.
Tipo de soporte disponible para la herramienta.
Limitación de la herramienta
Q #23) ¿Qué crees que detiene a los probadores para hacer la automatización? ¿Hay alguna forma de
superarlo?
Responder: El principal obstáculo para los probadores es aprender a programar / codificar cuando quieren
automatizar. Dado que los probadores no codifican, adaptarse a la codificación es un poco desafiante para los
probadores.
Podemos superarlo mediante:
Colaborar con los desarrolladores al automatizar.
Considerando que la automatización es responsabilidad de todo el equipo y no solo de los testers.
Dando un tiempo dedicado y enfoque en la automatización.
Obtener el apoyo administrativo adecuado.
Puede guardar estas preguntas de la entrevista de pruebas de automatización en formato pdf e imprimirlas
para leer más.
Crea una capa de abstracción entre los módulos, por lo que cualquier modificación en los scripts de prueba
para un módulo no afecta a ningún otro módulo.
Las pruebas basadas en palabras clave son un incremento de las pruebas basadas en datos.
Ventajas:
Se puede usar menos codificación y el mismo script para múltiples conjuntos de datos.
No se requiere experiencia en automatización para crear un caso de prueba utilizando las palabras
clave ya existentes para acciones.
Se pueden utilizar las mismas palabras clave en varios casos de prueba.
Desventajas:
Este marco es más complicado ya que debe ocuparse de las acciones de palabras clave y también de
la entrada de datos.
Los casos de prueba se vuelven más largos y complejos, lo que afecta la Mantenibilidad de los
mismos.
(iv) Marco de pruebas híbridas:
Este marco es una combinación de todos los marcos de prueba mencionados anteriormente (modular, basado
en datos y basado en palabras clave).
En este marco, los casos de prueba se desarrollan a partir de scripts modulares combinándolos en el marco
de prueba modular. Cada uno de los casos de prueba utiliza un script de controlador que usa un archivo de
datos como en el marco basado en datos y un archivo de acción basado en palabras clave.
Ventajas:
Modular y de fácil mantenimiento.
Menos codificación puede encargarse de más casos de prueba.
Se puede ejecutar un caso de prueba con varios conjuntos de datos.
Desventajas:
Complejo de leer, mantener y mejorar.
P # 28) ¿Cuándo prefiere las pruebas manuales a las pruebas de automatización?
Responder: Preferimos las pruebas manuales sobre las pruebas de automatización en los siguientes
casos:
El proyecto es a corto plazo y la redacción de guiones llevará mucho tiempo y será costosa en
comparación con las pruebas manuales.
Se requiere flexibilidad. Los casos de prueba automatizados se programan y ejecutan en una forma
específica de configuraciones.
Es necesario realizar pruebas de usabilidad.
Aplicaciones / módulo se ha desarrollado recientemente y no tiene casos de prueba anteriores.
Es necesario realizar pruebas exploratorias o ad-hoc.
P # 29) ¿Son útiles o no las pruebas de automatización en la metodología ágil?
Responder: Las pruebas de automatización son útiles para pruebas de regresión, humo o cordura. Todos
estos tipos de pruebas en el modelo de cascada tradicional ocurren al final del ciclo y, a veces, si no hay
muchas mejoras en la aplicación, es posible que ni siquiera tengamos que hacer pruebas de regresión .
Mientras en metodología ágil , cada iteración requiere ejecutar el caso de prueba de regresión a medida que
se agregan algunas funcionalidades nuevas.
Además, la suite de regresión en sí sigue creciendo después de cada sprint, ya que los casos de prueba
funcional del módulo de sprint actual deben agregarse a la suite de regresión para el siguiente sprint.
Por lo tanto, las pruebas de automatización en metodología ágil son muy útiles y ayudan a lograr la máxima
cobertura de pruebas en menos tiempo del sprint.
Se requiere un marco para brindar un conjunto de pautas que todos deben seguir para mantener la legibilidad,
la reutilización y la coherencia en los scripts de prueba. Un marco también proporciona un terreno común para
la funcionalidad de generación de informes y registro.
P # 33) ¿Cómo automatizará los casos de prueba de funcionalidad básica de 'inicio de sesión' para una
aplicación?
Responder: Suponiendo que la herramienta y el marco de automatización ya están en lugar del entorno de
prueba.
Para probar la funcionalidad básica de 'Inicio de sesión':
Comprender los requisitos del proyecto : La funcionalidad de inicio de sesión tendrá un cuadro de
texto de nombre de usuario, un cuadro de texto de contraseña y un botón de inicio de sesión.
Identifique los escenarios de prueba: Para la funcionalidad de inicio de sesión, los posibles
escenarios de prueba son:
Nombre de usuario y contraseña en blanco
nombre de usuario y contraseña inválidos
Un nombre de usuario y una contraseña válidos
Nombre de usuario y contraseña válidos
Prepara un Archivo de entrada de datos con los datos correspondientes a cada escenario.
Lanzar la herramienta del programa.
Identifique el campo de nombre de usuario, el campo de contraseña y el botón de inicio de sesión.
Para cada escenario de prueba, obtenga los datos del archivo de datos e ingrese en los campos
correspondientes. Programa haga clic en el botón de inicio de sesión después de ingresar los datos.
Validar el mensaje de error para escenarios negativos y el mensaje de éxito para escenarios positivos
en el script de prueba con la ayuda de afirmaciones.
Correr la suite de pruebas y generar el informe.
P # 34) ¿Automatización está probando una prueba de caja negra o una prueba de caja blanca?
Responder: Las pruebas de automatización son principalmente prueba de caja negra ya que simplemente
programamos los pasos que realiza un probador manual para la aplicación bajo prueba sin conocer el diseño
de bajo nivel o el código de la aplicación.
A veces, los scripts de prueba automatizados necesitan acceso a los detalles de la base de datos que se
utilizan en la aplicación bajo prueba o algunos detalles de codificación más y, por lo tanto, pueden ser un tipo
de prueba de caja blanca.
Por lo tanto, las pruebas automatizadas pueden ser del tipo de caja blanca o negra, según los escenarios en
los que se realiza la automatización.
(iii) Casos de prueba de cálculos complejos: Los casos de prueba que implican algunos cálculos complejos
para verificar un campo para una aplicación entran en esta categoría. Los resultados de cálculos complejos
son más propensos a errores humanos, por lo tanto, cuando se automatizan, dan resultados precisos.
(iv) Casos de prueba basados en datos: Los casos de prueba que tienen el mismo conjunto de pasos y se
ejecutan varias veces con el cambio de datos se conocen como casos de prueba basados en datos. Las
pruebas automatizadas para este tipo de casos de prueba son rápidas y rentables.
(v) Casos de prueba no funcionales: Los casos de prueba como las pruebas de carga y las pruebas de
rendimiento requieren un entorno simulado con múltiples usuarios y múltiples combinaciones de hardware o
software.
La configuración manual de varios entornos es imposible para cada combinación o número de usuarios. Las
herramientas automatizadas pueden crear fácilmente este entorno para realizar pruebas no funcionales
fácilmente.
P # 38) ¿Cuáles son las fases del ciclo de vida de las pruebas de automatización?
Respuesta: Las fases del ciclo de vida de las pruebas de automatización incluyen:
1. La decisión de realizar pruebas de automatización.
2. Identifica y aprende sobre la herramienta de automatización.
3. Determine el alcance de las pruebas de automatización.
4. Diseñe y desarrolle una suite de pruebas.
5. Ejecución de pruebas
6. Mantenimiento de scripts de
prueba.
P # 39) ¿Qué es un script de prueba automatizado?
Responder: Un script de prueba automatizado es un programa corto que está escrito en un lenguaje de
programación para realizar un conjunto de instrucciones en una aplicación bajo prueba para verificar si la
aplicación cumple con los requisitos.
Este programa cuando se ejecuta, da los resultados de la prueba como aprobados o no, dependiendo de si la
aplicación cumple con las expectativas.
Conclusión
Estas son las principales preguntas que son independientes de la herramienta de automatización o del
lenguaje de programación. Las entrevistas de pruebas de automatización también incluyen preguntas
específicas sobre herramientas y lenguajes de programación, según la herramienta con la que haya trabajado.
La mayoría de las preguntas de la entrevista de automatización de pruebas se centran en el marco que
desarrolle, por lo que se recomienda que cree y comprenda su marco de prueba a fondo. Cuando estoy
entrevistando, y el candidato ha respondido mi pregunta sobre el marco, también prefiero hacer una pregunta
específica del idioma (core java en mi caso).
Las preguntas parten de los conceptos básicos de Java para escribir la lógica de algún escenario
básico como:
¿Cómo extraerías un conjunto de texto de una línea determinada?
¿Cómo extraerías la URL?
En cualquier página web, en cualquier marco, la cantidad de enlaces y su contenido cambian
dinámicamente, ¿cómo lo manejarías?
¿Cómo maneja las imágenes y los objetos flash?
¿Cómo encuentras una palabra en una línea?
Respuestas a todas estas preguntas de la entrevista de automatización de pruebas son muy específicos
de la herramienta / lenguaje que está utilizando para automatizar. Así que, antes de ir a la entrevista, repase
sus habilidades de programación.
En caso de que no haya tenido la oportunidad de crear su marco y alguien más lo haya creado, tómese un
tiempo para comprenderlo a fondo antes de sentarse para la entrevista.
¿Qué diferencia hay entre Selenium y Appium y cuándo usar cada uno?
¿Cuáles son los lineamientos básicos a seguir para reportar un bug eficientemente?
Los puntos básicos que tiene que tener un bug son:
Reporter: Tester que lo reportó. Esto facilitará la comunicación entre el que lo reportó y el que
lo va a solucionar.
Versión: Indica la versión de la aplicación en que se detectó la falla.
Ambiente: Indica sobre que ambiente de pruebas ocurrió la falla.
Componente: Indica sobre que componente/módulo/submódulo/pantalla se detectó la falla.
Plataforma y Sistema Operativo: Indica sobre las características de hard y sistema operativo
de la maquina en donde se detectó la falla.
Navegador: Indica el navegador que se estaba utilizando cuando se detectó la falla.
Prioridad: Se indica “cuando” debe arreglarse la falla. Este parámetro nos ayuda a indicarle al
desarrollador con que urgencia necesitamos la corrección del bug.
Severidad: Indica el impacto de la falla sobre la aplicación.
Resumen: Descripción corta que describe la falla en forma simple y concreta.
Descripción: Detalle de los pasos realizados para poder reproducir la falla, junto con los datos
utilizados y la generación del escenario para que ocurra el bug.
Falla: Descripción que indica cual es el error exactamente.
Esperado: Descripción de que debería ocurrir en lugar de la falla.
Adjuntos: Cualquier material complementario que sirva para ayudar al desarrollador a
solucionar la falla (screenshots, logs, documentos, etc…)
Estado: En que situación se encuentra la falla para indicar si ya puede ser tomada por el
desarrollador, si ya fue solucionada o si todavía no puede revisarla.
¿Qué es Cucumber?
Cucumber es una herramienta para implementar metodologías como el Behaviour Driven
Development (BDD) o desarrollo basado en comportamiento, que permite ejecutar descripciones funcionales
en texto plano como pruebas de software automatizadas.
Estas descripciones funcionales se escriben en un lenguaje específico de dominio, legible por el área de
negocio, denominado Gherkin, que soporta más de 60 idiomas. Gherkin sirve simultáneamente como
documentación de apoyo al desarrollo y a las pruebas automatizadas.
¿Qué es JUnit?
JUnit se trata de un framework open source para la automatización de las pruebas (tanto unitarias como
de integración) en los proyectos software. El framework le provee al usuario herramientas, clases y métodos
que le facilitan la tarea de realizar pruebas en su sistema y así asegurar su consistencia y funcionalidad. JUnit
también sirve como herramienta para realizar las pruebas de regresión, que se ejecutan cuando una parte
del código ha sido modificada y sea necesario comprobar que se sigue cumpliendo con todos los requisitos.
Diferencias entre JUnit y Cucumber
Teniendo en cuenta lo anterior, sabemos que Cucumber es una herramienta basada en el modelo BDD y la
colaboración con personas no técnicas. Tiene una orientación hacía el negocio, y su finalidad es desarrollar
pruebas funcionales y de integración. Por tanto, personas que no tengan conocimientos técnicos o de
programación pueden comprenderlas, como un product owner (cliente o dueño del producto) o cualquier otro
individuo que esté involucrado en el desarrollo de un proyecto.Por otro lado, JUnit es una herramienta basada
en el modelo TDD (Test Driven Development), la cual fue creada con el propósito de desarrollar pruebas
unitarias. Esto no quiere decir que JUnit no nos permita realizar pruebas funcionales; simplemente no es su
objetivo principal. A continuación vamos a resolver 3 preguntas claves para entender mejor la diferencia entre
JUnit y Cucumber, dos herramientas de automatización de pruebas:
La diferencia consiste en que, mientras JUnit apunta a las pruebas, Cucumber apunta a la colaboración con
personas no técnicas. Las personas no técnicas no entenderán lo que hace una prueba unitaria; sin
embargo, podrán comprender y validar un ejemplo escrito en Gherkin.
Hay más gastos generales cuando usas Cucumber. Tendrás que implementar cada paso como un método y
no solo un método de prueba, como se haría con JUnit. La legibilidad que obtienes al expresar ejemplos
usando texto plano en Cucumber a veces es una ventaja frente a JUnit.
Los objetos de página son una abstracción para la página web que se está verificando. Los objetos de página
pueden ser utilizados tanto por JUnit como por Cucumber. De hecho, no hay diferencia entre estas dos
herramientas de automatización de pruebas desde esa perspectiva.
Cucumber, por otro lado, funciona en un nivel mucho más alto de abstracción. Empiezas escribiendo
"descripciones de prueba" en texto puro. Probablemente la diferencia clave está en que no es necesario
conocer programación Java para escribir una prueba de Cucumber. Lo único que se necesita de un
programador de Java es el código que le permite a Cucumber convertir su entrada de texto en un código
ejecutable.