Actividad de Afianzamiento: Test de Criterio Técnico en QA

1. ¿Cuál es el objetivo principal del enfoque Shift-Left en la ingeniería de calidad?. Automatizar únicamente las pruebas de integración en el pipeline de CI/CD. Trasladar las pruebas al final del ciclo para no interferir con el desarrollo. Prevenir defectos identificando ambigüedades en la definición de requerimientos desde las fases tempranas.

2. Al clasificar una falla, ¿Cómo se define la Severidad de un bug?. El nivel de urgencia del negocio para lanzar la corrección a producción. El impacto técnico y estructural que causa el fallo dentro del sistema. El grado de molestia visual percibido por el Product Owner.

3. En la sintaxis Gherkin, ¿Cuál es la función de la palabra clave Given (Dado)?. Describir la acción principal que ejecuta el usuario. Establecer el estado previo, contexto o precondiciones del sistema. Validar el resultado final y la respuesta de la aplicación.

4. ¿Qué caracteriza al estilo Declarativo en la redacción de escenarios de prueba?. Detalla cada clic, coordenadas de pantalla e IDs de los componentes visuales. Se enfoca en la intención y el valor de negocio, abstraído de la interfaz gráfica. Utiliza código ejecutable de automatización dentro del archivo .feature.

5. ¿Cuál es una ventaja clave de las pruebas exploratorias frente a las automatizadas?. Garantizan el 100% de cobertura de código sin intervención humana. Son altamente efectivas para descubrir comportamientos inesperados e intuir edge cases en flujos nuevos o inestables. Ejecutan la suite de regresión a la mayor velocidad posible en cada despliegue.

6. Al documentar un bug de API, ¿por qué es crucial adjuntar el Payload, los Headers y el Status Code?. Porque la herramienta de seguimiento cancela el reporte si faltan esos campos. Para aislar la falla en el backend y reducir el Time to Resolution (TTR) al evitar rodeos. Para demostrar que la falla es responsabilidad del desarrollador y no de QA.

7. Un bug visual leve en la página pública no bloquea la compra, pero daña la imagen de marca en un evento masivo. ¿Cómo se clasifica?. Alta Severidad y Alta Prioridad. Baja Severidad y Alta Prioridad. Alta Severidad y Baja Prioridad.

8. ¿Qué busca evitar el estándar de pruebas centrado en la reducción del Time to Resolution (TTR)?. La creación de escenarios de prueba en formato Gherkin. Las iteraciones innecesarias de aclaración entre Dev y QA por falta de contexto o datos de prueba. La automatización de pruebas unitarias durante el sprint.

9. En el análisis de causa raíz (Root Cause Analysis), ¿Cuál es el propósito de inspeccionar los logs de consola y red?. Verificar si los estilos CSS se cargaron correctamente en la pantalla. Identificar la respuesta del servidor o excepciones no controladas antes de que lleguen a la UI. Reescribir las historias de usuario que fueron mal especificadas.

¿Por qué los escenarios de prueba en formato Imperativo son considerados frágiles o costosos de mantener?. Porque están redactados en un lenguaje técnico que el negocio no comprende. Porque cualquier cambio menor en la UI (como renombrar o mover un botón) rompe el escenario. Porque requieren el uso obligatorio de herramientas de inteligencia artificial.

11. ¿Qué prácticas forman parte de una estrategia efectiva de Shift-Left Testing? (Selecciona las opciones correctas). Revisar y desafiar criterios de aceptación durante el refinamiento de US. Definir escenarios de prueba y casos límite antes de que inicie la codificación. Esperar a que el desarrollador pase la tarea a "Listo para QA" para iniciar el diseño de pruebas. Probar únicamente la interfaz gráfica final en el entorno de Staging.

12. ¿Cuáles de los siguientes elementos son indispensables en un reporte de bug técnico y de alta calidad? (Selecciona las opciones correctas). Pasos claros, ordenados y secuenciales para reproducir el fallo. Comportamiento esperado frente al resultado real obtenido. Evidencia técnica (logs de consola, llamadas de red, captura/video con contexto). Opiniones personales sobre el desempeño del desarrollador a cargo.

13. Al diseñar una suite de pruebas para un formulario de registro, ¿cuáles representan validaciones de Edge Cases o casos límite? (Selecciona las opciones correctas). Envío de un correo electrónico con una longitud de 256 caracteres (límite de BD). Intento de registro simulando una pérdida de conexión de red justo al hacer clic en "Enviar". Iniciar sesión con un usuario que ya fue creado previamente. Registro exitoso con datos válidos en todos los campos obligatorios.

14. ¿Cuáles son características propias de las Pruebas de Regresión? (Selecciona las opciones correctas). Aseguran que los cambios o correcciones recientes no hayan roto funcionalidades existentes. Son las candidatas principales para ser automatizadas en el pipeline de CI/CD. Se ejecutan de forma puramente manual y exploratoria en cada sprint. Se enfocan únicamente en evaluar la usabilidad y experiencia de usuario (UX).

15. Al comparar la Automatización de Pruebas con las Pruebas Manuales, ¿cuáles afirmaciones son correctas? (Selecciona las opciones correctas). La automatización ofrece un ROI alto en tareas repetitivas, como la regresión y pruebas de API. Las pruebas manuales son ideales para evaluar la usabilidad y validar flujos en etapas tempranas e inestables. La automatización reemplaza por completo la necesidad de pruebas exploratorias humanas. Es recomendable automatizar interfaces de usuario que cambian de diseño todos los días.