Maquillaje de Noche

En una primera implementación posible, los scripts de prueba automatizados dentro de una suite localizan e interactúan con elementos de una interfaz web indirectamente a través de los navegadores usando controladores y APIs específicos del navegador, proporcionados por una herramienta de prueba automatizada utilizada como parte del TAS. En una implementación alternativa, estos scripts de prueba localizan e interactúan directamente con elementos de la misma interfaz web a nivel HTML accediendo al DOM (Document Object Model) y al código JavaScript interno. La primera implementación posible: Opciones: Tiene un nivel de intrusión menor que la implementación alternativa, por lo que sus scripts de prueba son menos propensos a producir falsos positivos. Tiene un nivel de intrusión más alto que la implementación alternativa, por lo que sus scripts de prueba son menos propensos a producir falsos positivos. Tiene un nivel de intrusión menor que la implementación alternativa, por lo que sus scripts de prueba tienen más probabilidades de producir falsos positivos. Tiene el mismo nivel de intrusión que la implementación alternativa, por lo que el riesgo de que los scripts de prueba produzcan falsos positivos es el mismo en ambos casos.

¿Cuál de las siguientes recomendaciones puede ayudar a mejorar la mantenibilidad del código de automatización de pruebas? Opciones: Utiliza códigos de error en el código de automatización de pruebas en lugar de excepciones (si el lenguaje de programación soporta excepciones) para el manejo de errores. Evita producir código de automatización de pruebas que contenga métodos con demasiados niveles de anidamiento, ya que el código profundamente anidado es más difícil de entender. Evita adoptar patrones de diseño que introduzcan altos niveles de abstracción en el código de automatización de pruebas, como el patrón del modelo de flujo. Evita usar analizadores estáticos en código de automatización de pruebas y otras herramientas de desarrollo, ya que están diseñadas para mejorar la mantenibilidad del código SUT.

Considera un TAS destinado a implementar y ejecutar scripts de prueba automatizados a nivel de interfaz en aplicaciones web. El TAS debe soportar compatibilidad entre navegadores para una variedad de navegadores compatibles, asegurando que el mismo script de prueba se ejecute en dichos navegadores de la misma manera sin realizar ningún cambio. Esto se consigue introduciendo abstracciones adecuadas en el TAA para la conexión e interacción con diferentes navegadores. Por ello, el TAS podrá realizar llamadas directas a los navegadores compatibles utilizando el soporte nativo de automatización de cada uno de los distintos. ¿Cuál de los siguientes principios de SOLID se adoptó? Opciones: Principio de inversión de dependencias. Principio abierto-cerrado. Principio de sustitución de Liskov. Principio de segregación de interfaces.

Actualmente, estás realizando una Prueba de Concepto (PoC) destinada a seleccionar una herramienta que se utilizará para el desarrollo de un TAS. Este TAS será utilizado exclusivamente por un equipo dentro de tu organización para implementar scripts de prueba automatizados a nivel de interfaz de usuario para dos aplicaciones web. Las dos herramientas seleccionadas para el PoC utilizan JavaScript/TypeScript para implementar los scripts de prueba automatizados y ofrecer capacidades de captura y reproducción. Se seleccionaron tres casos de prueba para cada una de las dos aplicaciones web para ser automatizados durante el PoC. El punto de concepto comparará estas dos herramientas en cuanto a su efectividad para reconocer e interactuar con los widgets de interfaz de usuario ejercidos por los casos de prueba, para determinar rápidamente si la automatización de pruebas es posible y cuál herramienta es mejor. ¿Cuál de los siguientes TAF es MÁS adecuado para dirigir a las personas de color? Opciones: Un TAF de una sola capa (scripts de prueba). Un TAF de dos capas (scripts de prueba, librerías de prueba). Un TAF de tres capas (scripts de prueba, lógica de negocio, bibliotecas centrales). Un TAF en capas con más de tres capas.

Un SUT (SUT1) es un sistema cliente-servidor basado en un cliente ligero. El cliente es principalmente una interfaz de visualización y entrada, mientras que el servidor proporciona casi todos los recursos y funcionalidades del sistema. Otro SUT (SUT2) es un sistema cliente-servidor basado en un cliente fat que depende poco del servidor y proporciona la mayoría de los recursos y funcionalidades del sistema. Un TAS dado se utiliza para implementar pruebas automatizadas tanto en SUT1 como en SUT2. El objetivo principal del TAS es cubrir la mayor cantidad posible de funcionalidades del sistema mediante pruebas automatizadas ejecutadas lo más rápido posible. ¿Cuál de las siguientes afirmaciones sobre la solución de automatización es MEJOR en este escenario? Opciones: El TAS debería soportar principalmente automatización del lado del cliente, tanto para SUT1 como para SUT2. El TAS debería soportar principalmente automatización del lado del cliente para SUT1 y automatización del lado del servidor para SUT2. El TAS debería soportar principalmente automatización del lado del servidor tanto para SUT1 como para SUT2. El TAS debería soportar principalmente automatización del lado del servidor para SUT1 y automatización del lado del cliente para SUT2.

¿Cuál de las siguientes respuestas NO se refiere a un ejemplo de elemento de configuración que debería especificarse en las pipelines de desarrollo para identificar un entorno de prueba (y sus datos específicos de prueba) asociado a una aplicación web bajo prueba sobre la que ejecutar pruebas automatizadas? Opciones: El número y tipo de pruebas automatizadas a ejecutar en el entorno de pruebas donde se despliega la aplicación web. La URL base del entorno de prueba donde se despliega la aplicación web (es decir, la dirección raíz para acceder a la aplicación web). La(s) cadena(s) de conexión para conectarse a la(s) base(s) de datos de prueba dentro del entorno de prueba donde se despliega la aplicación web. La(s) cadena(s) de conexión para conectarse a la(s) base(s) de datos de prueba dentro del entorno de prueba donde se despliega la aplicación web.

¿Cuál de las siguientes afirmaciones sobre la relación entre TAA, TAS y TAF es cierta? Opciones: Un TAF puede usarse para implementar un TAS, que es una implementación de un TAA. Un TAS puede usarse para implementar un TAF, que es una implementación de un TAA. Un TAS puede usarse para implementar un TAA, que es una implementación de un TAF. Un TAF puede usarse para implementar un TAA, que es una implementación de un TAS.

Las pruebas automatizadas ejecutadas por un TAS (Sistema de Automatización de Pruebas) en un SUT (Sistema Bajo Prueba) pueden estar sujetas a ráfagas repentinas de mensajes (sudden bursts of messages) para registrar en la bitácora durante su ejecución. Todos los mensajes de la bitácora que ocurren durante la ejecución deben almacenarse de forma permanente en los registros de ejecución de pruebas correspondientes por el TAS para su análisis posterior. Si el registro no se realiza correctamente, estas ráfagas pueden reducir la velocidad de ejecución de estas pruebas automatizadas, haciendo que produzcan resultados poco confiables. ¿Cuál de las siguientes soluciones esperaría que fuera la MÁS útil para abordar este problema en el registro del TAS?. Utilizar un servidor de Protocolo de Tiempo de Red (NTP) para asegurar que los relojes de las máquinas que ejecutan el TAS y el SUT estén sincronizados con una fuente de tiempo común. Registrar todos los mensajes en memoria utilizando un búfer circular y vaciar periódicamente el búfer (flush the buffer) hacia los archivos de registro correspondientes asociados con la ejecución específica. Evitar registrar los mensajes que ocurren durante las ráfagas especificadas para minimizar cualquier posible sobrecarga de rendimiento en la ejecución de la prueba. Registrar todos los mensajes directamente en los archivos de registro correspondientes asociados con la ejecución específica para garantizar el almacenamiento permanente de los registros de ejecución de la prueba.

¿Cuál de las siguientes afirmaciones sobre un informe de progreso de pruebas producido para una suite de pruebas automatizadas es VERDADERA? Opciones: El informe de progreso de la prueba debe indicar, para cada prueba del conjunto, las marcas de tiempo relacionadas con los pasos de la prueba. El contenido del informe de progreso de la prueba no debe verse afectado por las partes interesadas a las que está dirigido el informe. El informe de progreso de las pruebas debe indicar el entorno en el que se realizaron las pruebas. El informe de progreso de la prueba debe indicar, para cada prueba de la suite, las marcas de tiempo de inicio y fin de la prueba.

Estás evaluando el mejor enfoque para implementar pruebas automatizadas a nivel de UI para una aplicación web. Específicamente, tu objetivo es permitir que los analistas de pruebas escriban pruebas automatizadas en formato tabular, dentro de archivos que encapsulen pasos lógicos de prueba relacionados con la forma en la que un usuario interactúa con la interfaz web, junto con los datos de prueba correspondientes. Estos pasos deben expresarse utilizando palabras en lenguaje natural que representen las acciones realizadas por el usuario en la interfaz web. Estos archivos luego serán interpretados y ejecutados por una herramienta de ejecución de pruebas. ¿Cuál de los siguientes enfoques de automatización de pruebas es el MÁS adecuado para lograr este objetivo?. Desarrollo guiado por pruebas (Test-Driven Development). Pruebas dirigidas por palabras clave (Keyword-Driven Testing). Pruebas dirigidas por datos (Data-Driven Testing). Script lineal (Linear Scripting).

Las pruebas automatizadas a nivel de UI para una aplicación web adoptan un mecanismo de espera asíncrona que les permite sincronizar los pasos de prueba con la aplicación, de modo que se ejecuten correctamente y en el momento adecuado, únicamente cuando la aplicación está lista y ha procesado el paso anterior; esto se realiza cuando no existen timeouts ni solicitudes asíncronas pendientes. De esta manera, las pruebas se sincronizan automáticamente con las páginas web de la aplicación. Las mismas tareas de inicialización para establecer las precondiciones de prueba se implementan como pasos de prueba en todos los casos de prueba. Con respecto a las funcionalidades de preprocesamiento (Setup) definidas a nivel de suite de pruebas, el TAS proporciona tanto un Suite Setup (que se ejecuta exactamente una vez cuando inicia la suite) como un Test Setup (que se ejecuta al inicio de cada caso de prueba en la suite). ¿Cuál de las siguientes recomendaciones proporcionarías para mejorar el TAS (asumiendo que es posible implementar todas)?. Adoptar una sincronización manual con las páginas web usando esperas fijas (hard-coded waits) en lugar de la sincronización automática actual. Implementar las tareas de inicialización destinadas a establecer las precondiciones de las pruebas dentro de la funcionalidad Test Setup a nivel de la suite de pruebas. Adoptar una sincronización manual con las páginas web usando esperas dinámicas mediante polling en lugar de la sincronización automática actual. Implementar las tareas de inicialización destinadas a establecer las precondiciones de las pruebas dentro de la funcionalidad Suite Setup a nivel de la suite de pruebas.

¿Qué capa del TAA contiene implementaciones tecnológicas específicas que permiten que las acciones lógicas del test interactúen realmente con el SUT?. Test generation layer. Test definition layer. Test execution layer. Test adaptation layer.

¿Cuál de los siguientes enunciados se refiere a una ventaja típica de la automatización de pruebas?. Las pruebas automatizadas pueden determinar si los resultados reales coinciden con los esperados, incluso para resultados que no son interpretables por una máquina. En promedio, es probable que las pruebas automatizadas escritas a nivel de API se ejecuten más rápido que las pruebas automatizadas escritas a nivel de UI. La inteligencia artificial se puede utilizar para ayudar a identificar pruebas redundantes dentro de suites de pruebas de regresión automatizadas grandes y de larga duración. Las pruebas automatizadas pueden permitir que los defectos se detecten antes que las pruebas manuales porque sus tiempos de ejecución pueden ser más cortos.

Para mejorar la mantenibilidad del código de automatización de pruebas, se recomienda adoptar principios y patrones de diseño que permitan estructurar el código en: Módulos altamente acoplados y débilmente cohesivos. Módulos altamente acoplados y altamente cohesivos. Módulos débilmente acoplados y altamente cohesivos. Módulos débilmente acoplados y débilmente cohesivos.

Un TAS que realiza pruebas automatizadas en un único entorno de prueba fue instalado y configurado manualmente desde un repositorio central, con todos sus componentes en las versiones correctas. Se verificó que todos los componentes del TAS en este entorno son capaces de proporcionar un rendimiento confiable y repetible. El TAS se usará para ejecutar varias suites de pruebas de regresión automatizadas en distintos SUTs en el entorno de prueba. Tu objetivo actual es completar todas las verificaciones preliminares para asegurar que el TAS funciona correctamente. ¿Cuál de las siguientes actividades realizarías PRIMERO?. Crear scripts para instalar y configurar automáticamente el TAS en el entorno de prueba desde el repositorio central. Verificar si la conectividad del TAS hacia todos los sistemas internos, externos e interfaces requeridas está disponible. Ejecutar una suite varias veces usando el TAS para determinar si todos los scripts de regresión siempre proporcionan el mismo resultado. Verificar si todos los scripts de regresión en una suite determinada tienen los resultados esperados.

Un nuevo TAS permite la implementación de scripts de prueba automatizados basados en datos. Todas las tareas planificadas para la implementación inicial de este TAS, destinadas a instalar y configurar los componentes del TAS y aprovisionar la infraestructura, serán realizadas manualmente por un equipo especializado. Se espera que este TAS se despliegue en el futuro en otros entornos similares. Como TAE, ves un riesgo de que no se pueda garantizar un despliegue correcto y reproducible del TAS. ¿Cuál de las siguientes opciones es la MEJOR para mitigar este riesgo?. No es necesario hacer nada, porque el equipo que realizará manualmente las tareas especificadas, al ser especializado, no cometerá errores y podrá garantizar un despliegue correcto y reproducible. Particionar las tablas de datos que contienen datos de prueba usados por los scripts basados en datos en tablas más pequeñas, usando un criterio lógico apropiado, para hacerlas más manejables. Revisar los scripts basados en datos para organizar mejor las bibliotecas de prueba, añadiendo funciones que contengan secuencias idénticas de acciones comúnmente implementadas en varios scripts. Intentar automatizar la mayoría de las tareas relacionadas con la instalación y configuración de los componentes del TAS y las relacionadas con el aprovisionamiento de la infraestructura.

¿Cuál de las siguientes respuestas describe la preocupación MENOS relevante al seleccionar herramientas de automatización de pruebas adecuadas para un proyecto de automatización de pruebas?. ¿Cuál es el grado de conocimiento técnico y habilidades dentro del equipo de pruebas para implementar automatización basada en código para el proyecto (por ejemplo, en términos de programación y patrones de diseño)?. En el caso de herramientas de automatización de pruebas de código abierto, ¿estas herramientas se publican bajo licencias permisivas o restrictivas y, si corresponde, está especificado si pueden ser modificadas y por quién?. ¿Se ha formado el equipo de pruebas teniendo en cuenta las diferentes personalidades de sus miembros, para asegurar que la interacción entre ellos sea efectiva en el logro de los objetivos del proyecto de automatización de pruebas?. En el caso de herramientas de automatización de pruebas comerciales, ¿qué factores determinan los costos de licencia de estas herramientas (por ejemplo, en términos del número máximo de usuarios soportados y si el tipo de licencia es fija o flotante)?.

Un caso de prueba automatizado que siempre debería pasar a veces pasa y a veces falla de forma intermitente (comportamiento no determinista) cuando se ejecuta en el mismo entorno de prueba, incluso si no se ha modificado ningún código (es decir, código SUT o código de automatización de prueba). ¿Cuál de las siguientes afirmaciones sobre la causa raíz de este comportamiento no determinista es VERDADERA?. La causa raíz especificada es una condición de carrera que puede identificarse analizando también los archivos de registro del caso de prueba, el SUT y el TAF. Determinar la causa raíz especificada puede requerir, además del TAE, el apoyo de otros como desarrolladores e ingenieros de sistemas. La causa raíz especificada debe estar en la inestabilidad del entorno de prueba, ya que no se ha modificado ningún código. Determinar la causa raíz especificada es ciertamente más fácil que si la prueba automatizada siempre falla (comportamiento determinista).

La respuesta de una API a una solicitud realizada al punto final correspondiente debe devolver datos específicos sobre una transacción de pago en formato JSON. En particular, tu objetivo es escribir el código de automatización de pruebas, manteniéndolo lo más breve posible, con el objetivo de determinar si esa respuesta incluye ciertas propiedades (transaction_id, cantidad, estado, marca de tiempo) con los tipos de datos y formatos esperados. Suponiendo que el TAF proporcione todo el soporte necesario para validar la respuesta especificada de la API, ¿cómo lograrías mejor tu objetivo?. Especifica el esquema para los datos de respuesta esperada (propiedades, tipos de datos y formatos) y valida los datos reales de respuesta frente a este esquema. Escribe una única afirmación para cada propiedad para comprobar si los tipos de datos y formatos de esa propiedad son los esperados en la respuesta real. Utiliza un algoritmo de inteligencia artificial basado en aprendizaje automático y reconocimiento de imágenes para implementar una capacidad de autorreparación. Escribe código personalizado que analice los datos reales de respuesta y compruebe si las propiedades, tipos de datos y formatos extraídos son los esperados.

¿Cuál de las siguientes prácticas puede utilizarse para especificar las características activas (es decir, realmente disponibles) para cada versión del SUT y determinar las pruebas automatizadas correspondientes que deben ejecutarse para una versión determinada?. Desarrollo impulsado por funciones. El uso de archivos de características. Desarrollo guiado por pruebas. El uso de interruptores de funciones.

¿Cuál de las siguientes NO es una consideración técnica de diseño para un TAA? Opciones: El número de usuarios para el SUT. Disponibilidad de interfaces para que el SUT sea probable. Normas y requisitos legales, por ejemplo, privacidad de datos. Datos utilizados por el SUT, por ejemplo, configuración, usuarios2.

Un TAS se utiliza para ejecutar en un entorno de prueba un conjunto de pruebas de regresión automatizadas, escritas a nivel de interfaz de usuario, en diferentes versiones de una aplicación web: todas las ejecuciones se completan con éxito, proporcionando siempre resultados correctos (es decir, sin producir ni falsos positivos ni falsos negativos). Las pruebas, todas independientes entre sí, consisten en scripts de prueba ejecutables basados en el patrón del modelo de flujo que se ha implementado en un TAF de tres capas (scripts de prueba, lógica de negocio, bibliotecas centrales), expandiendo el modelo de objeto de página mediante el patrón de fachada. Actualmente, la suite tarda demasiado en ejecutarse, y los scripts de prueba se consideran demasiado largos en términos de LOC (Líneas de Código). ¿Cuál de las siguientes recomendaciones proporcionarías para mejorar el TAS (suponiendo que sea posible realizarlas todas)? Opciones: Modificar el TAF para que los scripts de prueba se basen en el modelo de objeto de página, en lugar del patrón del modelo de flujo. Implementa un mecanismo para reiniciar automáticamente toda la aplicación web en caso de fallo. Divide la suite en subsuites y ejecuta cada una simultáneamente en diferentes entornos de prueba. Modificar la arquitectura de la SUT para mejorar su testabilidad y, si es necesario, la TAA en consecuencia.

Tu objetivo es verificar la integridad, consistencia y el comportamiento correcto de una suite de pruebas automatizada. Se ha demostrado que el TAS se instala con éxito en el entorno SUT. Todas las comprobaciones preliminares para verificar el correcto funcionamiento del entorno de pruebas automatizado y la configuración, instalación y configuración de la herramienta de prueba se han completado con éxito. ¿Cuál de las siguientes NO es una comprobación relevante para alcanzar tu objetivo en este escenario? Opciones: Comprobar si todos los casos de prueba contienen los resultados esperados. Comprobar si se han cumplido las condiciones de la publicación para todos los casos de prueba. Comprobar si la carga del TAS es repetible en el entorno SUT. Comprobar si todos los casos de prueba producen resultados repetibles.

¿Cuál de las siguientes afirmaciones sobre las pruebas por contrato es VERDADERA? Opciones: Las pruebas por contrato, independientemente del enfoque elegido (impulsado por el proveedor o por el consumidor), no necesitan depender de la creación de stubs/mocks, ya que se utilizan para implementar pruebas de integración, no para pruebas unitarias/componentes. Las pruebas por contrato pueden considerarse una forma especializada de pruebas de API que puede aplicarse para probar de forma eficaz y eficiente la integración entre microservicios, pero solo si interactúan con APIs REST. Las diferencias entre ambos enfoques para las pruebas por contrato provienen principalmente de qué parte crea el contrato: esta creación la realiza el proveedor para el enfoque impulsado por el proveedor y por el/los consumidor(es) para el enfoque impulsado por el consumidor. Las pruebas por contrato pueden considerarse una forma especializada de pruebas de API que puede aplicarse para probar la integración entre sistemas de forma eficaz y eficiente, pero solo si interactúan de forma síncrona.

¿Cuál de las siguientes descripciones de lo que algunas herramientas de automatización de pruebas pueden usar es VERDADERA? Opciones: Diseña y evalúa de forma autónoma interfaces intuitivas, así como la experiencia de usuario (UX) general de una aplicación. Analizar resultados de pruebas, cambios en el código y métricas para predecir posibles defectos y áreas de alto riesgo dentro de una aplicación. Realizar de forma autónoma sesiones de pruebas exploratorias basadas en cartas de prueba para encontrar defectos dentro de una aplicación. Haz grabaciones de vídeo de las sesiones de pruebas de la interfaz para compartirlas con los interesados y así mostrar la funcionalidad y apariencia de una aplicación.

Has acordado con los gerentes de tu organización llevar a cabo un proyecto piloto para introducir la automatización de pruebas. Las expectativas de los gerentes sobre los beneficios de la automatización son demasiado optimistas. ¿Cuál de las siguientes opciones es la MENOS relevante al decidir el alcance de los objetivos del proyecto piloto? Opciones: Evaluar la idoneidad de diferentes herramientas de automatización de pruebas en función de la pila tecnológica utilizada por las aplicaciones para las cuales se desarrollarán las pruebas automatizadas. Evaluar los posibles ahorros de costos y beneficios (por ejemplo, una ejecución de pruebas más rápida, una mejor cobertura de pruebas) del uso de pruebas automatizadas en comparación con las pruebas manuales. Evaluar los conocimientos y habilidades de las personas que participarán en la automatización de casos de prueba para los frameworks y tecnologías de automatización de pruebas aplicables. Evaluar el rendimiento de la infraestructura de red de una organización en términos de factores como la disponibilidad, el ancho de banda, la latencia, la pérdida de paquetes y el jitter.

Se te ha encomendado la tarea de añadir la ejecución de pruebas de verificación de la compilación (build verification tests) al pipeline de CI/CD actual utilizado en un proyecto Ágil. El objetivo de estas pruebas es verificar la estabilidad de las compilaciones diarias y asegurar que los cambios más recientes no hayan alterado la funcionalidad principal (es decir, realizar pruebas de humo o smoke tests). Actualmente, la primera actividad que se realiza como parte de este pipeline es el análisis estático del código fuente. ¿En cuál de las siguientes etapas del pipeline añadirías la ejecución de estas pruebas de humo?. Como primera actividad, antes de realizar el análisis estático del código fuente y antes de generar la nueva compilación. Después de realizar el análisis estático sobre el código fuente y antes de generar la nueva compilación. Después de desplegar la nueva compilación en el entorno de pruebas y antes de realizar pruebas más exhaustivas. Como actividad final, inmediatamente antes de liberar la nueva compilación a producción.

¿Cuál de las siguientes opciones es el MEJOR ejemplo de cómo las herramientas de análisis estático pueden ayudar a mejorar la calidad del código de automatización de pruebas en términos de seguridad?. Las herramientas de análisis estático no generan falsos positivos cuando intentan detectar vulnerabilidades de seguridad dentro del código de automatización de pruebas. Las herramientas de análisis estático pueden ayudar a detectar la presencia de instancias repetidas de código (código duplicado) dentro del código de automatización de pruebas. Las herramientas de análisis estático pueden ayudar a detectar credenciales escritas de forma fija (hard-coded credentials) que exponen información confidencial dentro del código de automatización de pruebas. Las herramientas de análisis estático pueden garantizar que no existan vulnerabilidades de seguridad dentro del código de automatización de pruebas.

En las Pruebas de Aceptación de Usuario (UAT) para un nuevo SUT, además de las pruebas manuales realizadas por los usuarios finales, se ejecutan pruebas automatizadas que se centran en la ejecución de escenarios de prueba repetitivos y rutinarios. ¿En cuál de los siguientes entornos se realizan típicamente todas estas pruebas?. Entorno de construcción (Build environment). Entorno de integración (Integration environment). Entorno de preproducción (Preproduction environment). Entorno de producción (Production environment).

Una suite de casos de prueba automatizados se ejecutó múltiples veces en la misma versión (release) del SUT en el mismo entorno de pruebas. Considera el análisis de un histograma de pruebas que muestra la distribución de los resultados de las pruebas (aprobado, fallido, etc.) para cada caso de prueba a lo largo de estas ejecuciones. ¿Cuál de los siguientes problemas potenciales es MÁS probable que se identifique como resultado de dicho análisis?. Valores atípicos (outliers) en los tiempos de ejecución de las pruebas. Vulnerabilidades de seguridad en los casos de prueba automatizados. Casos de prueba automatizados inestables. Problemas de mantenibilidad en los casos de prueba automatizados.

¿Cuál de los siguientes aspectos del "diseño para la testabilidad" (design for testability) está MÁS directamente asociado con la necesidad de definir con precisión qué interfaces están disponibles en el SUT para la automatización de pruebas en los diferentes niveles de prueba?. Autonomía (Autonomy). Transparencia de la arquitectura (Architecture transparency). Controlabilidad (Controllability). Observabilidad (Observability).

Considera un TAS (Sistema de Automatización de Pruebas) implementado para realizar pruebas automatizadas en aplicaciones móviles nativas a nivel de interfaz de usuario (UI), donde el TAF (Framework de Automatización de Pruebas) implementa una arquitectura cliente-servidor. El cliente se ejecuta de forma local (on-premise) y permite la creación de scripts de prueba automatizados utilizando las librerías del TAF para reconocer e interactuar con los objetos de la UI de la aplicación. El servidor se ejecuta en la nube como parte de un servicio PaaS (Plataforma como Servicio), recibiendo comandos del cliente, traduciéndolos en acciones para el dispositivo móvil y enviando los resultados de vuelta al cliente. La plataforma en la nube aloja varios dispositivos móviles dedicados para el uso de este TAS. El dispositivo en el que se ejecutarán los scripts/suites de prueba se especifica en tiempo de ejecución (run time). Actualmente, estás verificando si el entorno de automatización de pruebas y todos los demás componentes del TAS/TAF funcionan correctamente. ¿Cuál de las siguientes actividades realizarías para lograr tu objetivo?. Administrar la infraestructura que aloja al servidor, incluyendo el hardware, las actualizaciones de software y los parches de seguridad. Verificar si las referencias al dispositivo en el que se ejecutarán los scripts/suites de prueba están correctamente codificadas de forma fija (hard-coded) dentro de dichos scripts/suites de prueba. Verificar si las librerías del TAF que utilizarán los scripts de prueba para reconocer e interactuar con los objetos de la UI de la aplicación (widgets) funcionan como se espera. Verificar si todos los scripts de prueba que serán ejecutados por el TAS como parte de una suite de pruebas determinada tienen resultados esperados.

Una versión candidata (release candidate) de un SUT, después de haber sido completamente integrada con todos los demás sistemas necesarios, ha superado con éxito todas las pruebas funcionales requeridas (el 90% fueron pruebas automatizadas y el 10% fueron pruebas manuales). Ahora, es necesario realizar pruebas de confiabilidad (reliability tests) destinadas a evaluar si, bajo ciertas condiciones, esa versión será capaz de garantizar un MTBF (Tiempo Medio Entre Fallos) en el entorno de producción superior a un determinado umbral (expresado en tiempo de CPU). ¿Cuál de los siguientes entornos de prueba es el MÁS adecuado para realizar estas pruebas de confiabilidad?. Entorno de desarrollo local (Local development environment). Entorno de construcción (Build environment). Entorno de integración (Integration environment). Entorno de preproducción (Preproduction environment).

Un pipeline de CI/CD consta de dos fases: construcción (build) y despliegue (deployment). La fase de build, entre otras actividades, ejecuta casos de prueba automatizados en los siguientes niveles de prueba: Pruebas de Componentes (CT) y Pruebas de Integración de Componentes (CIT). Si la fase de build tiene éxito, se inicia la fase de deployment. La fase de deployment primero aprovisiona la infraestructura del entorno de pruebas necesaria para desplegar el SUT, luego despliega el SUT en este entorno y, finalmente, activa otro pipeline independiente que ejecuta casos de prueba automatizados en los siguientes niveles de prueba: Pruebas de Sistema (ST) y Pruebas de Aceptación (AT). ¿Cuál de los siguientes enunciados es VERDADERO?. Tanto los casos de prueba automatizados para CT-CIT como para ST-AT pueden actuar como compuertas de calidad (quality gates). Los casos de prueba automatizados para CT-CIT pueden actuar como compuertas de calidad, mientras que los casos de prueba automatizados para ST-AT no pueden actuar como compuertas de calidad. Los casos de prueba automatizados para CT-CIT no pueden actuar como compuertas de calidad, mientras que los casos de prueba automatizados para ST-AT pueden actuar como compuertas de calidad. Ni los casos de prueba automatizados para CT-CIT ni los casos de prueba automatizados para ST-AT pueden actuar como compuertas de calidad.

Un script de prueba automatizado realiza una solicitud bien formada a una API REST en el backend de una aplicación web para agregar un solo artículo de un producto (con ID=710) al carrito, y espera una respuesta que confirme que el producto se agregó con éxito. La línea de estado de la respuesta de la API es HTTP/1.1 200 OK, mientras que el cuerpo de la respuesta indica que el producto está agotado (out of stock). La respuesta de la API es correcta, el script de prueba falla, pero se completa, y el mensaje que se registrará en la bitácora es: "El producto con ID=710 está agotado. Carito no actualizado". Cuando esto ocurre, ya eres consciente de que tanto la prueba fallida como la API se están comportando correctamente y que el problema radica en los datos de prueba. El TAS admite los siguientes niveles de registro de pruebas: FATAL, ERROR, WARN, INFO, DEBUG. ¿Cuál de las siguientes opciones es el nivel de registro de pruebas MÁS adecuado para registrar el mensaje especificado?. FATAL. INFO. DEBUG. WARN.

¿Cuál de las siguientes descripciones sobre lo que algunas herramientas de automatización de pruebas pueden utilizarse para hacer es VERDADERA?. Diseñar de forma autónoma interfaces de usuario (UI) intuitivas y evaluarlas, así como evaluar la experiencia de usuario (UX) general de una aplicación. Analizar resultados de pruebas, cambios en el código y métricas para predecir posibles defectos y áreas de alto riesgo dentro de una aplicación. Realizar de forma autónoma sesiones de pruebas exploratorias basadas en cartas de prueba (test charters) para encontrar defectos dentro de una aplicación. Realizar grabaciones de video de las sesiones de prueba de la interfaz de usuario para compartirlas con las partes interesadas (stakeholders) para mostrar la funcionalidad y apariencia de una aplicación.

¿Cuál de las siguientes informaciones en la documentación de una API es la MENOS relevante para implementar pruebas automatizadas en esa API?. Notas de lanzamiento / registros de cambios sobre cambios basados en la API. Detalles sobre los parámetros aceptados por cada punto de acceso (endpoint) de la API. Mecanismos de autenticación requeridos para acceder a la API. Detalles sobre el formato de las respuestas de la API.

Como TAE (Ingeniero de Automatización de Pruebas), estás evaluando una herramienta de automatización de pruebas para automatizar algunas pruebas de interfaz de usuario (UI) para una aplicación web. Las pruebas automatizadas primero localizarán los elementos HTML requeridos en la página web utilizando sus identificadores correspondientes (locators), luego realizarán acciones sobre esos elementos y, finalmente, verificarán la presencia de cualquier texto esperado para un elemento HTML. Estas pruebas son independientes entre sí y están organizadas en una suite de pruebas que debe ejecutarse todas las noches contra la versión más reciente (build) de la aplicación web. Existe un alto riesgo de que la aplicación web se caiga (crash) mientras se ejecutan algunas pruebas automatizadas. Basándote únicamente en la información proporcionada, ¿cuál de las siguientes es tu preocupación MÁS importante relacionada con la evaluación de la herramienta de automatización de pruebas?. ¿Proporciona la herramienta de automatización de pruebas una función para especificar pruebas automatizadas en un descriptivo que no sea directamente ejecutable en la aplicación web?. ¿Ofrece la herramienta de automatización de pruebas una función para restaurar la aplicación web, recuperarse de la prueba fallida, saltarse dichas pruebas y reanudar la siguiente en la suite?. ¿Ofrece la herramienta de automatización de pruebas una función para crear un servidor simulado (mock server) que simule el comportamiento de una API real aceptando solicitudes y devolviendo respuestas?. ¿Soporta la herramienta de automatización de pruebas un esquema de licenciamiento que permita acceder a diferentes conjuntos de características?.

¿Cuál de los siguientes enunciados sobre cómo se aplica la automatización de pruebas a través de los diferentes modelos de ciclo de vida del desarrollo de software es VERDADERO?. En el desarrollo de software Ágil, las suites de pruebas de regresión automatizadas a veces crecen tanto que pueden volverse difíciles de mantener, y por lo tanto, se vuelve crucial invertir en la automatización de pruebas en múltiples niveles de prueba (it becomes crucial to invest in test automation at multiple test levels). En un modelo en Cascada (Waterfall), las pruebas automatizadas generalmente se ejecutan solo durante la última fase del ciclo de vida del desarrollo, pero su implementación ocurre en las etapas tempranas. En el desarrollo de software Ágil, independientemente del contexto (por ejemplo, tipo de aplicación a desarrollar, herramientas disponibles), la automatización de pruebas debe basarse en la distribución de automatización conocida como el modelo de la pirámide de pruebas. A diferencia del desarrollo de software Ágil, donde las pruebas unitarias automatizadas son escritas por los desarrolladores (a menudo con un enfoque de desarrollo guiado por pruebas o test-first), en un modelo en V las pruebas.

Algunos scripts de pruebas de regresión automatizadas ejecutados por un TAS en un entorno de pruebas determinado realizan llamadas a APIs privadas que requieren autenticación para todas las solicitudes (el método de autenticación es el mismo para todas las APIs). El SUT es un sistema crítico para el negocio. Se planean los dos siguientes cambios: un cambio en el método de autenticación de todas las APIs y una actualización menor del sistema operativo (OS) en el entorno de pruebas. Ya has actualizado los scripts de prueba para hacer frente al cambio en el método de autenticación de las APIs. ¿Cuál de las siguientes secuencias de actividades es la MEJOR para garantizar que los scripts de prueba no se vean afectados negativamente por estos cambios?. Primero, actualizar el sistema operativo; luego, implementar el cambio en el método de autenticación de las APIs; y, finalmente, ejecutar todos los scripts de prueba actualizados. Implementar un cambio a la vez y ejecutar un subconjunto de los scripts de prueba actualizados después de cada cambio, y finalmente ejecutar todos los scripts de prueba actualizados. Primero, implementar el cambio en el método de autenticación de las APIs, luego actualizar el sistema operativo y, finalmente, ejecutar todos los scripts de pruebas actualizadas. Implementar un cambio a la vez y ejecutar un subconjunto de los scripts de prueba actualizados después de cada cambio.