Respuesta: Continuous Delivery significa que el software está técnicamente listo para producción en cualquier momento, pero requiere una liberación manual. Continuous Deployment va más allá y automatiza todo el proceso hasta la puesta en producción cuando se cumplen todos los Quality Gates. En resumen: Delivery es “listo para desplegar”, Deployment es “desplegado automáticamente”.

Respuesta: Una lista de verificación completa debe contener: conformidad arquitectónica (decisiones, patrones), verificación de seguridad (validación de entrada, autenticación), manejo de errores (Exception Handling, Logging), cobertura de pruebas (Unit Tests, tests de integración), convenciones de nombres, complejidad del código (Cyclomatic Complexity), aspectos de rendimiento y documentación (comentarios, API Doc).

Respuesta: La preparación de auditoría incluye: definir el alcance (procesos, sistemas, períodos), recopilar evidencia (documentación, resultados de pruebas, registros), proporcionar políticas y ADRs, crear un plan de muestreo, capacitar al personal, desarrollar un plan de acciones para deficiencias identificadas y asegurar el Audit Trail.

Respuesta: El análisis estático de código permite la detección automatizada de violaciones estilísticas, estructurales y relacionadas con seguridad sin ejecutar el código. Establece Quality Gates, monitorea Technical Debt, verifica reglas de cumplimiento y proporciona métricas como Cyclomatic Complexity. Herramientas como SonarQube se integran en pipelines CI/CD y previenen la integración de código de baja calidad.

Respuesta: La efectividad de las pruebas se mide a través de varias métricas: Mutation Score (qué tan bien las pruebas detectan mutaciones de código), Flaky Rate (estabilidad de las pruebas), detección de defectos antes del lanzamiento, Test Coverage como tendencia (no como número absoluto), tiempo de ejecución de pruebas y tasa de éxito de pruebas de regresión. Alta efectividad se demuestra con detección temprana de errores y pocos defectos en producción.

Respuesta: Los Quality Gates son puntos de decisión automatizados en pipelines CI/CD que permiten o bloquean el avance basándose en criterios de calidad definidos. La implementación ocurre a través de umbrales para métricas (Coverage < 80% = bloqueo), escaneos de seguridad, pruebas de rendimiento y estado de Code Review. Los gates se configuran en herramientas de pipeline como Jenkins, GitLab CI o GitHub Actions.

Respuesta: La pirámide de pruebas describe la distribución ideal de tipos de pruebas: Unit Tests (70%) rápidos, aislados y numerosos; Tests de integración (20%) moderados, verifican interacción de componentes; E2E Tests (10%) lentos, prueban todo el sistema. Su importancia radica en: retroalimentación rápida con muchos Unit Tests, eficiencia de costos al usar menos E2E Tests costosos, mejor aislamiento de fallos y suite de pruebas estable.

Respuesta: Mutation Testing es una técnica para evaluar la calidad de las pruebas. Realiza pequeños cambios (mutaciones) en el código y verifica si las pruebas los detectan. Se utiliza en sistemas críticos, para optimizar pruebas y en Quality Gates. Un alto Mutation Score (mayor que 80%) indica buena cobertura de pruebas. Herramientas como PIT (Java) o Stryker (JavaScript) automatizan este proceso.

Respuesta: Pair Programming proporciona revisión en tiempo real (los errores se detectan inmediatamente), transferencia de conocimiento (intercambio de experiencias entre compañeros), tasa de defectos más baja (dos pares de ojos ven más), mejores decisiones arquitectónicas (discusión en equipo) y aprendizaje continuo. Es especialmente valioso para problemas complejos, integración de nuevos empleados y áreas críticas del código.

Respuesta: Un proceso efectivo de seguimiento de errores incluye: captura estructurada (pasos de reproducción, entorno, logs), priorización según severidad e importancia, asignación a desarrolladores responsables, seguimiento de estado (Nuevo → En progreso → Corregido → Probado → Cerrado), vinculación con commits y lanzamientos, análisis de causa raíz y métricas como MTTR y densidad de defectos.

Respuesta: Definition of Ready (DoR) define criterios que una User Story debe cumplir antes de ser incluida en un sprint (requisitos claros, criterios de aceptación, técnicamente factible). Definition of Done (DoD) describe criterios de conclusión para una tarea (Code Review aprobado, pruebas en verde, documentación actualizada, listo para desplegar). Ambos actúan como mecanismos de aseguración de calidad en el proceso ágil.

Respuesta: Git Flow (ramas feature, develop, release, master) es apropiado para lanzamientos estructurados con pruebas extensas. GitHub Flow (rama feature → master → deploy) funciona bien para ciclos rápidos de despliegue. Trunk-Based Development favorece una integración continua extrema con ramas mínimas. La elección depende de frecuencia de lanzamiento, tamaño del equipo, requisitos de cumplimiento y tolerancia al riesgo.

Respuesta: La integración de seguridad se realiza mediante: SAST (Static Application Security Testing) durante la compilación, escaneo de dependencias para vulnerabilidades conocidas, DAST (Dynamic Application Security Testing) en staging, escaneo de contenedores, gestión de secretos, comprobaciones de cumplimiento y Quality Gates de seguridad. Herramientas como OWASP ZAP, SonarQube Security o Trivy se integran en fases de la pipeline.

Respuesta: Feature Flags son interruptores de configuración que habilitan o deshabilitan funcionalidades en tiempo de ejecución. Apoyan la aseguración de calidad mediante liberación gradual (Canary Releases), A/B Testing, desactivación rápida en caso de problemas, desarrollo paralelo y despliegues con riesgo minimizado. Se implementan a través de servidores de configuración, herramientas de Feature Toggle o archivos de configuración simples.

Respuesta: El despliegue Canary lanza la nueva versión gradualmente a pequeños grupos de usuarios y monitorea métricas. El despliegue Blue-Green mantiene dos entornos de producción idénticos y cambia todo el tráfico al nuevo entorno (Green). Ambos minimizan riesgos de despliegue, permiten rollback rápido y proporcionan retroalimentación temprana. La elección depende de la infraestructura y la estrategia de riesgo.

Respuesta: Las métricas DORA incluyen: Deployment Frequency (con qué frecuencia se despliega), Lead Time for Changes (tiempo desde commit hasta despliegue), Mean Time To Recovery (MTTR) (tiempo para recuperarse tras un incidente) y Change Failure Rate (porcentaje de despliegues fallidos). Los de alto rendimiento muestran despliegues frecuentes, Lead Times cortos, recuperación rápida y baja tasa de fallos.

Respuesta: Technical Debt describe los costos futuros de decisiones técnicas subóptimas. Se gestiona mediante identificación (análisis de código, retroalimentación del equipo), priorización (impacto vs. esfuerzo), seguimiento (Technical Debt Ratio, SonarQube), estrategia de reembolso (sprints regulares de refactoring) y prevención (Code Reviews, decisiones arquitectónicas). El objetivo es tomar decisiones conscientes en lugar de permitir deterioro descontrolado.

Respuesta: Las pruebas no funcionales incluyen: pruebas de rendimiento (carga, estrés, picos), pruebas de seguridad (penetración, vulnerabilidades), pruebas de usabilidad (experiencia de usuario, accesibilidad), pruebas de disponibilidad (alta disponibilidad, failover), pruebas de escalabilidad (escalado horizontal/vertical) y pruebas de cumplimiento (GDPR, normas ISO). Estas pruebas se ejecutan frecuentemente en entornos especializados con herramientas dedicadas.

Respuesta: Los ADRs documentan decisiones arquitectónicas importantes con contexto, decisión, justificación y consecuencias. Son importantes para la trazabilidad, transferencia de conocimiento, consistencia e incorporación de nuevos miembros. Los ADRs se versionan, típicamente en formato Markdown, y se tratan como parte de la documentación del proyecto. Apoyan la gobernanza arquitectónica y la toma de decisiones.

Respuesta: La separación de entornos se logra mediante separación física (diferentes servidores/clusters), separación lógica (esquemas de base de datos, configuraciones), separación de red (firewalls, VPNs), separación de datos (datos de prueba anonimizados) y control de acceso (RBAC). El objetivo es proteger la seguridad de datos de producción, mantener pruebas estables y facilitar el desarrollo paralelo. Las tecnologías de contenedores (Docker, Kubernetes) simplifican esta separación.

Respuesta: Contract Testing verifica la compatibilidad entre Microservicios a través de “contratos” definidos (especificaciones de API). Se utiliza en arquitecturas de Microservicios para acelerar pruebas de integración, detectar cambios que rompan la compatibilidad tempranamente y permitir desarrollo paralelo. Herramientas como Pact o Spring Cloud Contract automatizan este proceso e integran la verificación en pipelines CI/CD.

Respuesta: La calidad de la documentación se asegura mediante versionado (en el repositorio), automatización (generación de documentación a partir del código), procesos de revisión (revisión por Technical Writer), plantillas (estructuras estandarizadas), vinculación con código (API Doc), actualizaciones regulares (como parte de DoD) y retroalimentación de usuarios. Herramientas como Swagger/OpenAPI, Javadoc o MkDocs apoyan este proceso.

Respuesta: Los Smoke Tests son pruebas simples que verifican la funcionalidad básica de una aplicación tras el despliegue. Se ejecutan después de cada despliegue para detectar errores críticos tempranamente. Ejemplos típicos: función de login, conexión a base de datos, endpoints de API, servicios externos. Son rápidos (pocos minutos) y proporcionan una señal clara de éxito o fallo para continuar con pruebas adicionales.

Respuesta: La gestión de datos de prueba abarca Test Data Factories (generación programática), containerización (Docker con datos de prueba), migraciones de base de datos (Flyway, Liquibase), mocking para dependencias externas, limpieza de datos entre pruebas y versionado de datos de prueba. El objetivo es lograr pruebas reproducibles, rendimiento e aislamiento de entornos de prueba.

Respuesta: Pregunta: “Describa un proceso de aseguración de calidad completo para un nuevo proyecto web.” Estructura de respuesta: 1. Medidas preventivas (Coding Standards, Architecture Guidelines), 2. Pipeline CI/CD (Build → Test → Analyze → Deploy), 3. Code Reviews (lista de verificación, principio de cuatro ojos), 4. Estrategia de pruebas (Unit, Integration, E2E), 5. Quality Gates (métricas, seguridad), 6. Monitoreo (métricas de producción), 7. Mejora continua (retrospectivas, métricas). Esta estructura demuestra enfoque sistemático y competencia en QS.