Las 39 preguntas principales de la entrevista sobre pruebas de

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 # 15) ¿Cuál es generalmente la estructura de un marco?

Responder: Normalmente, la estructura debería tener - (Sería diferente de un proyecto a otro)
 Una carpeta 'src' (fuente) que contiene los scripts de prueba reales.
 Una carpeta ”lib” (biblioteca) que tiene todas las bibliotecas y métodos comunes.
 Una carpeta de 'clase' que tiene todo el archivo de clase (en caso de que use java).
 Una carpeta de 'registro' que contiene los archivos de registro.
 Un archivo / carpeta que tiene todos los ID de elementos web.
 Un archivo que contiene la URL, el entorno y la información de inicio de sesión.
Q #16) ¿Dónde mantendrá información como URL, inicio de sesión, contraseña?
Responder: Esta información siempre debe mantenerse en un archivo separado.
P # 17) ¿Por qué desea mantener este tipo de información en un archivo separado y no directamente
en el código?
Responder: URL, inicio de sesión y contraseñas son el tipo de campos que se utilizan con mucha frecuencia
y estos cambian según el entorno y la autorización. En caso de que lo codifiquemos en nuestro código,
tenemos que cambiarlo en cada archivo que tenga su referencia.
En caso de que haya más de 100 archivos, entonces será muy difícil cambiar los 100 archivos y esto, a su
vez, puede dar lugar a errores. Entonces, este tipo de información se mantiene en un archivo separado para
que la actualización sea fácil.

P # 18) ¿Cuáles son los diferentes tipos de marcos?

Responder: Los diferentes tipos de marcos incluyen:
 Marco basado en palabras clave
 Marco basado en datos
 Marco híbrido
 Scripting lineal
Q #19) ¿Puede contarnos algunas buenas prácticas de codificación durante la automatización?
Responder: Algunas de las buenas prácticas de codificación incluyen:
 Agregue los comentarios apropiados.
 Identifique los métodos reutilizables y escríbalos en un archivo separado.
 Siga las convenciones de codificación específicas del idioma.
 Mantenga los datos de la prueba en un archivo separado.
 Ejecute sus scripts con regularidad.

P # 20) ¿Algún tipo de prueba que crea que no debería automatizarse?

Responder:
 Pruebas que rara vez se ejecutan.
 Prueba exploratoria
 Pruebas de usabilidad
 Prueba que se ejecuta rápidamente cuando se hace manualmente.
Q #21) ¿Crees que las pruebas solo se pueden realizar en el nivel de la interfaz de usuario?
Responder: Hoy en día, al pasar al modo ágil, las pruebas no se limitan a la capa de interfaz de usuario. La
retroalimentación temprana es imperial para un proyecto ágil. Si nos concentramos solo en la capa de la
interfaz de usuario, en realidad estamos esperando hasta que la interfaz de usuario se desarrolle y esté
disponible para probar.
Más bien, podemos probar incluso antes de que se desarrolle realmente la interfaz de usuario. Podemos
probar directamente las API o los métodos utilizando herramientas como Cucumber y FitNesse .
De esta manera, estamos dando la retroalimentación mucho antes y estamos probando incluso antes de que
se desarrolle la interfaz de usuario. Seguir este enfoque nos ayudará a probar solo el aspecto de la GUI de
pequeños cambios cosméticos o algunas validaciones en la interfaz de usuario y ayudará a los
desarrolladores al dar más tiempo para corregir los errores.

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.

P # 24) ¿Qué es un marco de prueba de automatización?

Responder: Un marco, en general, es un conjunto de pautas. Un conjunto de pautas, suposiciones,
conceptos y prácticas de codificación para crear un entorno de ejecución en el que se automatizarán las
pruebas, se conoce como marco de pruebas de automatización.
Un marco de pruebas de automatización es responsable de crear un arnés de prueba con un mecanismo para
conectarse con la aplicación bajo prueba, tomar la entrada de un archivo, ejecutar los casos de prueba y
generar los informes para la ejecución de la prueba. Un marco de pruebas de automatización debe ser
independiente de la aplicación y debe ser fácil de usar, modificar o ampliar.

P # 25) ¿Cuáles son los módulos importantes de un marco de pruebas de automatización?

Responder: Los módulos importantes de un marco de pruebas de automatización son:
1. Herramienta de afirmación de prueba: Esta herramienta proporcionará declaraciones de aserción
para probar los valores esperados en la aplicación bajo prueba. Por ejemplo. TestNG, Junit, etc.
2. Configuración de datos: Cada caso de prueba debe tomar los datos del usuario de la base de datos
o de un archivo o incrustados en el script de prueba. El módulo de datos de Frameworks debe
encargarse de la entrada de datos para los scripts de prueba y las variables globales.
3. Herramienta de gestión de compilación: El marco debe construirse e implementarse para el uso de
la creación de scripts de prueba.
4. Herramienta de integración continua: Con CICD (Continuous Integration and Continuous
Development) en su lugar, se requiere una herramienta de integración continua para integrar y
desplegar los cambios realizados en el marco en cada iteración.
 5. Herramienta de informes: Se requiere una herramienta de informes para generar un informe legible
después de que se ejecuten los casos de prueba para una mejor vista de los pasos, resultados y fallas.
6. Herramienta de registro: La herramienta de registro en el marco ayuda a depurar mejor los errores y
errores.
P # 26) Explique algunas herramientas de prueba de automatización.
Responder: Algunas de las famosas herramientas de prueba de automatización se explican a
continuación:
(i) Selenio : Selenium es un marco de prueba para pruebas de automatización de aplicaciones web. Es
compatible con varios navegadores y es independiente del sistema operativo. Selenium también admite varios
lenguajes de programación como Java, C #, PHP, Ruby y Perl, etc.
Selenio es un conjunto de bibliotecas de código abierto que se puede utilizar para desarrollar marcos de
prueba adicionales o scripts de prueba para probar aplicaciones basadas en web.
(ii) UFT : Unified Functional Testing es una herramienta con licencia para pruebas funcionales. Proporciona
una amplia gama de características como API, servicios web, etc. y también es compatible con múltiples
plataformas como computadoras de escritorio, web y dispositivos móviles. Las secuencias de comandos de
UFT están escritas en lenguaje de secuencias de comandos básico visual.
(Ii) épocas : Appium es una herramienta de prueba de aplicaciones móviles de código abierto. Se utiliza para
automatizar las pruebas en aplicaciones móviles multiplataforma, nativas, híbridas y basadas en la web.
Appium automatiza cualquier aplicación móvil desde cualquier idioma con acceso completo a API y DB desde
el código de prueba.
Appium se basa en la arquitectura cliente-servidor y ha evolucionado a partir del selenio.
(iv) Pepino : Cucumber es una herramienta de desarrollo basada en el comportamiento de código abierto. Se
utiliza para pruebas de automatización de aplicaciones basadas en web y admite lenguajes como ruby, java,
scala, groovy, etc. Cucumber lee las especificaciones ejecutables escritas en texto plano y prueba la
aplicación bajo prueba para esas especificaciones.
Para que pepino entienda los escenarios en texto plano, tenemos que seguir algunas reglas de sintaxis
básicas que se conocen como Gherkin.
(v) Prueba completa : TestComplete es una herramienta de prueba de IU automatizada con licencia para
probar la aplicación en diferentes plataformas como computadoras de escritorio, web, dispositivos móviles,
etc. Proporciona flexibilidad para registrar un caso de prueba en un navegador y ejecutarlo en varios
navegadores y, por lo tanto, admite pruebas entre navegadores.
TestComplete tiene un algoritmo de reconocimiento de objetos incorporado que identifica de forma única un
objeto y lo almacena en el repositorio.

P # 27) ¿Cuáles son los diferentes tipos de técnicas de marco de prueba?

Responder: Hay cuatro tipos de técnicas de marco de pruebas de automatización.
Son:
(i) Marco de prueba modular:
Este marco se basa en el concepto de abstracción. En este marco, el evaluador crea scripts para cada módulo
de la aplicación bajo prueba individualmente y luego estos scripts se combinan en orden jerárquico para crear
grandes casos de prueba.

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.

Ventajas de este marco:

 Mantenimiento y escalabilidad más fáciles de casos de prueba.
 La creación de casos de prueba mediante el uso de módulos ya programados es más fácil y rápida.
Desventajas:
 Los casos de prueba tienen datos incrustados en ellos. Por lo tanto, ejecutar el mismo script de prueba
con diferentes datos es un gran cambio a nivel del script.
(ii) Marco de prueba basado en datos:
En el marco de prueba basado en datos, los datos de entrada y los datos de salida esperados
correspondientes a los datos de entrada se almacenan en un archivo o base de datos y el script automatizado
ejecuta el mismo conjunto de pasos de prueba para múltiples conjuntos de datos. Con este marco, podemos
ejecutar múltiples casos de prueba donde solo los datos de entrada difieren y los pasos de ejecución son los
mismos.
Ventajas:
 Reduce el número de scripts de prueba que deben ejecutarse. Ejecutamos el mismo script varias
veces con diferentes datos.
 Menos codificación para pruebas de automatización.
 Mayor flexibilidad para mantener y corregir los errores o mejorar la funcionalidad.
 Los datos de prueba se pueden crear incluso antes de que el sistema automatizado de prueba esté
listo.
Desventajas:
 Solo se pueden combinar casos de prueba similares con el mismo conjunto de pasos de ejecución
para varios conjuntos de datos. Los diferentes conjuntos de pasos de ejecución requieren un caso de
prueba diferente.
(iii) Marco de prueba basado en palabras clave:
Es un marco de prueba independiente de la aplicación que utiliza tablas de datos y palabras clave auto
explicativas. Las palabras clave explican las acciones a realizar en la aplicación bajo prueba y la tabla de
datos proporciona los datos de entrada y salida esperados.

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.

P # 30) Enumere algunas ventajas y desventajas de las pruebas de automatización.

Responder:
Ventajas:
 Menos recursos humanos
 Reutilización
  Más cobertura de prueba en menos tiempo
 Fiabilidad
 Ejecución paralela de casos de prueba
 Rápido
Desventajas:
 El tiempo de desarrollo y mantenimiento es mayor.
 Costo de la herramienta
 Se requieren recursos calificados.
 Configuración del entorno
 La depuración del script de prueba es un problema.
P # 31) Enumere algunas ventajas y desventajas de las pruebas manuales.
Responder:
Ventajas:
 No se necesita configuración de entorno.
 No se requieren conocimientos de programación.
 Recomendado para requisitos que cambian dinámicamente.
 Permita que el poder de observación humano detecte más errores.
 El costo es menor para proyectos a corto plazo.
 Flexibilidad
Desventajas:
 Difícil de realizar cálculos complejos.
 Reutilización
 Tomando tiempo
 Alto riesgo de errores humanos o errores.
 Se requieren más recursos humanos.
P # 32) ¿Podemos realizar pruebas de automatización sin un marco? Si es así, ¿por qué necesitamos
un marco?
Responder: Sí, podemos realizar pruebas de automatización incluso sin utilizar un marco. Simplemente
podemos entender la herramienta que estamos usando para la automatización y programar los pasos en el
lenguaje de programación que admiten las herramientas.
Si automatizamos los casos de prueba sin un marco, no habrá coherencia en los scripts de programación para
los casos de prueba.

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.

P # 35) ¿Cuántos casos de prueba ha automatizado por día?

Responder: Bueno, el número depende de la complejidad de los casos de prueba. Cuando la complejidad era
limitada, pude automatizar de 5 a 6 casos de prueba por día. A veces, pude automatizar solo un caso de
prueba para escenarios complejos.
También he desglosado mis casos de prueba en diferentes componentes como, tomar entrada, hacer el
cálculo, verificar la salida, etc. en caso de escenarios muy complejos y tomar 2 o más días.

P # 36) ¿Qué factores determinan la efectividad de las pruebas de automatización?

Respuesta: Algunos de los factores que determinan la efectividad de las pruebas de automatización
son:
 Ahorro de tiempo al ejecutar scripts sobre la ejecución manual de casos de prueba.
 Defectos encontrados
 Cobertura de prueba o cobertura de código
 Tiempo de mantenimiento o tiempo de desarrollo
 Estabilidad de los guiones
 Prueba de reutilización
 Calidad del software bajo prueba
P # 37) ¿Qué casos de prueba se pueden automatizar?
Responder: Los tipos de casos de prueba que pueden automatizarse son:
(i) Casos de prueba de humo: Las pruebas de humo también se conocen como pruebas de verificación de
construcción. Los casos de prueba de humo se ejecutan cada vez que se lanza una nueva compilación para
comprobar el estado de la compilación y su aceptación para realizar las pruebas.
(ii) Casos de prueba de regresión: La prueba de regresión es la prueba para garantizar que los módulos
desarrollados previamente funcionen como se esperaba después de que se agrega un nuevo módulo o se
corrige un error.
Los casos de prueba de regresión son muy cruciales en el enfoque de software incremental donde se agrega
una nueva funcionalidad en cada fase de incremento. En este caso, la prueba de regresión se realiza en cada
fase incremental.

(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.

Algunos consejos para las entrevistas de pruebas de automatización serían:

 Conozca su herramienta a fondo.
 Aprenda las técnicas de localización que utiliza su herramienta.
 Practique la programación utilizando el lenguaje que utiliza para las pruebas de automatización.
 Conozca su marco y sus componentes.
 Siempre es ventajoso que haya participado en el desarrollo de su marco. Por lo tanto, sea minucioso
con los módulos del marco en el que ha trabajado.

¿Qué diferencia hay entre Selenium y Appium y cuándo usar cada uno?

¿Qué es Appium y para que nos sirve?

Appium es una herramienta open-source para la automatización de aplicaciones web nativas e híbridas en
las plataformas móviles iOS y Android, y en la plataforma de escritorio Windows. Es cross-platform por lo que
es posible crear pruebas en diversas plataformas utilizando la misma API. Esto permite la reutilización de
código entre conjuntos de casos de prueba definidos para una aplicación desarrollada para varias
plataformas. Appium emplea el WebDriver de Selenium, que es un entorno de pruebas para
aplicaciones web y que especifica un protocolo cliente-servidor conocido como JSON Wire Protocol.
Esto permite al cliente el uso de marcos de pruebas escritos en cualquier lenguaje, enviando las
solicitudes HTTP apropiadas al servidor.

¿Cuándo usar selenium?

Selenium es un conjunto de utilidades que facilita la labor de obtener juegos de pruebas para aplicaciones
web. Para ello nos permite grabar, editar y depurar casos de prueba, que podrán ser ejecutados de forma
automática e iterativa posteriormente.

¿Cómo funciona la integración continua?

La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores
combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan
versiones y pruebas automáticas.

¿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:

1. ¿Hay algo que Cucumber no pueda hacer frente a JUnit?

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.

2. ¿Cuál es más fácil de usar?

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.

3. ¿Ambos trabajan con objetos de página?

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.

En conclusión, ambas trabajan en niveles de abstracción completamente diferentes. 

JUnit es principalmente un marco de automatización. Tiene la capacidad de escribir rápidamente casos de

prueba usando el lenguaje de programación Java. Además, proporciona anotaciones que facilitan declarar el
método. Por tanto, fue pensado como marco para pruebas unitarias; pero muchas personas también lo
usan para conducir pruebas de integración o función a gran escala.

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.