Flujo de trabajo de un extremo a otro, integración CI/CD, ética y seguridad: uso responsable de la IA — Inteligencia artificial en pruebas de software y control de calidad

Ganancias:

Capacidad para diseñar el papel de la inteligencia artificial y los puntos de aprobación humana en el flujo de control de calidad de un extremo a otro, desde la idea hasta el lanzamiento en el contexto de CI/CD.
En CI/CD, no se autoriza a la IA a "pasar" automáticamente la prueba, sino que se aplican límites para proteger los datos y las claves confidenciales.
Capacidad para realizar pruebas de seguridad dentro de la autoridad y con fines defensivos, y para adoptar principios de divulgación responsable y transparencia ética.

En las diez unidades anteriores, utilizamos IA en tareas individuales: generación de escenarios, código de automatización, informes de errores, análisis de cobertura, pruebas de mutaciones. Esta unidad final los combina todos en un flujo de trabajo responsable. El control de calidad moderno no es un trabajo que termina en el escritorio de una sola persona; Es un proceso que reside dentro de CI/CD (Integración continua/Entrega continua: el proceso donde el código se combina constantemente, se prueba automáticamente y se prepara para su publicación con frecuencia y seguridad). La IA puede abarcar todas las etapas de este proceso. Pero a medida que crece el poder de la IA, también crece la importancia de usarla de manera responsable: privacidad, autoridad en las pruebas de seguridad, ética y, lo más importante, dejar la decisión de calidad en manos del ser humano. En esta unidad, aprenderá el flujo y los límites de un extremo a otro.

Flujo de control de calidad de extremo a extremo impulsado por IA

El papel de la IA en el recorrido de una función desde la idea hasta el lanzamiento:

1. Análisis de requisitos. AI señala ambigüedades en el requisito y falta de criterios de aceptación ("esta regla no dice cuántos caracteres es mínimo la contraseña").

2. Diseño de pruebas. Los borradores de escenarios y casos (unidad 2), y los casos extremos (unidad 3) se encuentran entre los criterios de aceptación.

3. Automatización. Borradores de código de prueba de unidad (6), API (5) y UI (4); cada uno se confirma mediante mutación (10).

4. Integración CI/CD. Las pruebas se ejecutan automáticamente con cada combinación de código. AI redacta la configuración de canalización (YAML), resume los registros de pruebas fallidas y sugiere una posible causa raíz.

5. Decisión de liberación. Se recopilan los resultados del análisis de riesgos (8) y de la regresión (9), pero el experto decide si puede tener éxito.

6. Seguimiento y retroalimentación de la producción. Los errores en la vida se convierten en pruebas futuras; La IA propone un caso de regresión a partir de un defecto de fabricación.

Consejo: configure la IA como una capa en CI/CD que "acelere los borradores revisados por humanos" en lugar de "escribir pruebas y tomar decisiones". Ninguna prueba generada automáticamente debe ingresar al proceso sin que un humano la revise y apruebe.

IA en CI/CD: donde sí, donde no

etapa

Ajuste de IA

lo humano es esencial

Borrador del código de prueba

Revisión + mutación

Borrador YAML de canalización

Autenticación + verificación de clave secreta

Resumen de registro fallido

Confirmación de causa raíz

Diagnóstico de prueba frágil

Decisión de solución permanente

"¿Puede haber una versión?"

Juicio experto y responsabilidad.

"Pasar" automáticamente la prueba

nunca

—

Precaución: Nunca le dé a la IA un mandato como "arreglarlo para pasar la prueba fallida" en CI/CD. Esto anula el propósito de las pruebas y automáticamente oculta los errores. La IA puede explicar el error, sugerir una corrección; pero "pintar la prueba de verde" debe ser una decisión consciente y razonada de una persona.

Privacidad, datos y seguridad: fronteras inmutables

Privacidad. En el entorno de prueba, los datos reales del cliente, las copias de la base de datos de producción, las claves API y la información interna del sistema son confidenciales. No los entregues a herramientas públicas de IA. Los datos personales están sujetos a la KVKK y regulaciones similares; Enmascarar registros y capturas de pantalla. Utilice datos de prueba sintéticos (ficticios) siempre que sea posible.

Pruebas de seguridad: defensivas y autorizadas. Las pruebas de seguridad aprendidas en este módulo (pruebas de autorización/IDOR, límites de carga de archivos, validación de entradas) son solo para probar su propio producto dentro de la autorización escrita y el alcance definido. Usar IA para acceder al sistema de otra persona sin permiso, convertir vulnerabilidades reales en armas o realizar pruebas fuera de alcance es poco ético e ilegal. Cuando encuentre una vulnerabilidad de seguridad, cumpla con el principio de divulgación responsable: mantener la vulnerabilidad confidencial e informarla a la parte correspondiente para que pueda solucionarse.

Ética y transparencia. No presente las pruebas producidas por la IA como su propio trabajo; Declarar que estás utilizando IA dentro del equipo es transparencia. Usted es responsable de la inexactitud de un resultado producido por IA: "La IA lo escribió" no es una excusa.

Aviso débil / Aviso fuerte

Débil: "Configurar canal de prueba para CI".

Fuerte: "Elabore un flujo de trabajo de CI YAML para acciones de GitHub: ejecute pruebas unitarias + API en cada PR, genere un informe de cobertura, ejecute pruebas de mutación (Stryker) semanalmente. No incruste secretos en el código; use solo referencias de secretos. Bloquee la combinación si las pruebas están en rojo. Este es un BORRADOR; revisaré y editaré los pasos de validación y administración de claves secretas. NO AGREGUE un paso de 'corrección' o 'migración' de pruebas automatizadas".

Aviso potente; Impone límites a la confidencialidad, la revisión humana y "no pruebas automatizadas".

Cuatro plantillas copiables

1) Plan de pruebas de un extremo a otro:

Su función: líder senior de control de calidad. Redacte un plan de pruebas de extremo a extremo desde la idea hasta el lanzamiento para la siguiente característica: [característica + criterios de aceptación]. Fases: análisis de requisitos (incertidumbres), diseño de pruebas, capas de automatización (unidad/API/UI), integración CI/CD, criterios de decisión de lanzamiento, seguimiento de producción. Especifique el papel de los puntos de aprobación de IA y HUMANOS en cada etapa por separado.

2) Esquema del proceso de CI/CD:

Borrador de CI YAML para [GitHub Actions/GitLab CI/Azure Pipelines]:- Unidad + prueba API + alcance en PR- Evitar fusión en prueba roja- Valores secretos solo con secretos; incrustar en códigoEste es un borrador; Revisaré los pasos clave de administración y aprobación. Agregar un paso de autocorrección/prueba de aprobación.

3) Análisis de registro de prueba fallido:

En esa impresión de CI, las pruebas están en rojo. Examinar el registro; agrupe las fallas, distinga la posible causa raíz y CUÁL puede ser la falla real y cuál puede ser un problema frágil de prueba/entorno. Si hay datos personales, enmascararlos. La decisión y corrección serán mías. Registro: [pegar]

4) Verificación previa de seguridad/privacidad:

Antes de enviar estos datos/registro de prueba a la herramienta de IA, verifique: ¿contiene datos personales, clave API, dirección interna del sistema, datos de producción? Enumere qué áreas, si corresponde, deben enmascararse/eliminarse. Procesamiento tal como está. Contenido: [pegar]

tres mini casos

Caso 1: Velocidad del flujo de un extremo a otro. Un equipo abordó una nueva función de “renovación de suscripción” con un flujo de extremo a extremo impulsado por IA: incertidumbres de requisitos marcadas desde el principio, pruebas de tres capas redactadas y validadas por mutaciones, vinculadas a la CI. La característica redujo el ciclo de prueba, que tomaba 5 días en el proceso tradicional, a 2 días; pero la aprobación humana se mantuvo en cada etapa y la incertidumbre sobre los requisitos (qué sucede si falla la actualización) se cerró antes de la puesta en marcha.

Caso 2: Regreso de una fuga de claves. Un desarrollador hizo que la IA generara CI YAML, y la IA integró una clave API de aspecto real en el YAML como ejemplo. El paso de “verificación previa de seguridad/privacidad” captó esto; clave convertida en referencia secreta. Sin el paso de auditoría, la clave se filtraría al control de versiones (historial de git).

Caso 3 — Límite de autoridad. Un miembro del equipo quería aplicar la prueba IDOR que aprendió al sistema en vivo de un socio comercial porque "tenía curiosidad". El líder de control de calidad se detuvo: es ilegal realizar pruebas de seguridad en otro sistema sin autorización escrita y sin un alcance definido. Las pruebas se realizaron únicamente en el entorno de prueba de sus propios productos, con autoridad; El responsable abierto fue notificado al equipo correspondiente.

Errores comunes

Hacer que la IA tome decisiones de lanzamiento. Hacer la pregunta "¿Se puede publicar?" a la IA y poniendo la respuesta en lugar de la firma.
"Pasar" la prueba automatizada. En CI, hacer que la IA pinte la prueba de verde; encubriendo errores.
Entregar datos confidenciales/llave del vehículo. Compartir datos de producción, datos personales o claves API sin supervisión.
Pruebas de seguridad no autorizadas. El atacante prueba en otro sistema sin alcance ni permiso.
Introducir pruebas en el proceso sin revisión. Ejecute automáticamente el boceto de IA sin aprobación humana.
Echarle la culpa a la IA. Defender el resultado incorrecto diciendo "AI lo escribió".

En resumen

El control de calidad de extremo a extremo es un proceso que se extiende desde los requisitos hasta el seguimiento de la producción y se desarrolla dentro de CI/CD; En cada etapa, la IA produce borradores, resume el registro y sugiere las causas fundamentales. Pero los límites son inmutables: los humanos toman decisiones de prueba y obtienen su aprobación; A la IA nunca se le da la autoridad para “pasar” automáticamente la prueba; datos confidenciales y llaves no ingresan al vehículo; Las pruebas de seguridad se realizan únicamente en su propio producto, dentro de la autorización escrita y el alcance definido, con fines defensivos, y los hallazgos se informan con divulgación responsable. Sea transparente cuando utilice la IA; Usted es responsable de la precisión de la salida. La IA se acelera; Usted responde por la calidad y la ética.

Tarea de aplicación

Redacte un plan desde la idea hasta el lanzamiento con una plantilla de "plan de prueba de un extremo a otro" para una característica de su propio proyecto; Marque el papel de la IA y los puntos de aprobación humana por separado en cada etapa. Luego genere un YAML con un “esquema de canalización de CI/CD” y aplique una “verificación previa de seguridad/privacidad” a este YAML para verificar si hay claves/datos secretos incrustados. Finalmente, enumere todos los puntos de “decisión humana” en su plan y justifique en una oración por qué estas decisiones no se pueden delegar a la IA.

lista de verificación

[ ] Atribuyo las decisiones de lanzamiento y prueba a la aprobación humana; No se lo entregué a AI.
[] En CI/CD no le di permiso a la IA para "pasar/corregir" automáticamente la prueba.
[ ] Verifiqué y oculté datos confidenciales, datos personales y claves antes de enviarlos al vehículo.
[ ] Solo he considerado realizar pruebas de seguridad en mi propio producto, dentro de la autorización y el alcance por escrito.
[ ] Abordé las vulnerabilidades encontradas con el principio de divulgación responsable.
[] Declaré de forma transparente que utilicé IA y me hice responsable de la precisión del resultado.

Examen del módulo

1. ¿Cómo se define con mayor precisión el "falso pase" en el contexto de la garantía de calidad?

A) Aunque la prueba se vuelve verde, en realidad no confirma ningún comportamiento; ✔ No se pone rojo incluso si el código está dañado
B) La prueba se ejecuta muy lentamente y se agota el tiempo de espera.
C) El test detecta un error real y se pone rojo
D) La prueba se ejecuta solo en el entorno de producción.

Explicación: Un pseudo-aprobado es cuando una prueba dice "aprobado" pero en realidad no confirma nada significativo; La prueba es verde, pero incluso si el software está defectuoso, no lo detectará. Este es el riesgo número uno de la IA en el control de calidad porque la IA tiende a producir pruebas que parecen claras pero que son vacías.

2. ¿Cuál es el posicionamiento más preciso de la inteligencia artificial en el proceso de pruebas y control de calidad?

A) La inteligencia artificial puede decidir si la versión se puede lanzar sin la aprobación humana
B) La inteligencia artificial es un asistente que genera borradores e ideas; La decisión y responsabilidad de '¿está listo para su publicación' pertenece al experto ✔
C) La inteligencia artificial solo escribe texto y no puede manejar ningún código de prueba
D) La inteligencia artificial siempre escribe pruebas más correctas que las humanas, por lo que la revisión es innecesaria

Descripción: La inteligencia artificial es un asistente de pruebas, generador de borradores y multiplicador de ideas; produce escenarios de prueba, código de automatización y borradores de informes. Sin embargo, la responsabilidad y la aprobación final de decisiones de calidad como "está este software listo para su publicación" o "ha pasado esta prueba" pertenecen al experto competente.

3. Con base en el hecho de que los errores ocurren principalmente en los valores umbral, ¿qué técnica de diseño de prueba es probar a los 17, 18 y 19 años por separado para el límite de edad de 18 años?

A) Prueba de transición de estado
B) Tabla de decisiones
C) Análisis de valores en la frontera ✔
D) Pruebas exploratorias

Explicación: El análisis del valor límite se basa en la observación de que los errores ocurren con mayor frecuencia en los límites y prueba los valores umbral (justo por debajo, justo por encima y justo por encima del límite) por separado. Es una técnica poderosa que complementa las clases de equivalencia.

4. ¿Qué enfoque debería preferirse en la selección de elementos para reducir la fragilidad en el código de automatización de pruebas de UI producido con inteligencia artificial?

A) Utilizar la ruta XPath más larga posible
B) Seleccionar el elemento según su posición de píxel en la pantalla
C) Usar selectores basados en nombres de clases CSS
D) Uso de atributos estables (data-testid) agregados para pruebas ✔

Explicación: Las rutas XPath largas y los nombres de clases CSS dependen en gran medida de la estructura y el diseño de la página; Se rompe al menor cambio de interfaz. Los atributos estables agregados específicamente para las pruebas (por ejemplo, data-testid) no se ven afectados por los cambios de diseño y hacen que las pruebas sean sólidas.

5. ¿Por qué no es suficiente que una prueba de API verifique simplemente el código de estado HTTP (por ejemplo, 200)?

A) Porque los datos del cuerpo con el código de estado correcto pueden estar dañados y la verificación de estado por sí sola no detectará esto (pseudoconfianza) ✔
B) Porque los códigos de estado no son nada confiables en las pruebas de API
C) Porque la verificación del código de estado ralentiza mucho la prueba.
D) Porque el código de estado nunca se devuelve en las pruebas de API

Explicación: Si bien el servidor devuelve el código de estado correcto, es posible que devuelva datos corruptos en el cuerpo (tipo incorrecto, campo faltante, valor calculado incorrectamente). La prueba que sólo observa la situación no puede ver esto y da una confianza falsa. Por lo tanto, también se debe agregar la validación de esquema/contrato y reglas comerciales.

6. ¿Por qué es fundamental decirle a AI que "calcule manualmente el valor esperado de acuerdo con la regla de aceptación, no haga referencia a la salida actual de la función" cuando imprima las pruebas unitarias?

A) Porque el cálculo manual ejecuta las pruebas más rápido
B) Porque de lo contrario la prueba acepta el comportamiento actual (quizás con errores) del código como "correcto" y confirma el error ✔
C) Porque la inteligencia artificial no puede calcular números decimales en absoluto
D) Porque las reglas de aceptación nunca se utilizan en las pruebas.

Explicación: Si la IA deriva el valor esperado de la salida de la función bajo prueba, hará que la prueba 'pase' incluso si la función es defectuosa; Es decir, cualquier cosa que produzca el código, la prueba cuenta como verdadera. Calcular el valor esperado independientemente de la regla de aceptación garantiza que la prueba sea un guardián de la regla, no un espejo del código.

7. ¿Cuál de las siguientes es la característica más distintiva de un buen informe de error?

A) Ser lo más largo y técnico posible
B) Escrito por inteligencia artificial
C) Contiene pasos de reproducción deterministas que el desarrollador puede seguir de forma independiente y producir el error ✔
D) Es solo una captura de pantalla.

Explicación: El valor real de un informe de error es que el desarrollador puede reproducir el error sin su ayuda. Esto lo garantizan pasos de reproducción deterministas y rastreables desde cero; Si faltan estos pasos, el informe a menudo se cierra como "no se pudo producir".

8. ¿Cuál es la expresión más precisa para la relación entre gravedad y prioridad en el error de ortografía del nombre de la empresa en la página de inicio?

A) Intensidad y prioridad siempre deben tener el mismo valor
B) Tanto la gravedad como la prioridad de este error son definitivamente bajas.
C) Severidad y prioridad son el mismo concepto, una etiqueta es suficiente
D) La intensidad técnica puede ser baja pero la prioridad empresarial (reputación) puede ser alta; Los dos se evalúan de manera diferente ✔

Explicación: La gravedad es el impacto técnico del error (error tipográfico técnicamente bajo), la prioridad es la urgencia con la que se debe solucionar (alta porque es un elemento de reputación que todos los visitantes ven). Los dos no siempre van en la misma dirección; Este ejemplo es una situación de baja gravedad y alta prioridad.

9. ¿Cuál es la interpretación más precisa de un conjunto de pruebas con una cobertura de línea del 90 %?

A) Demuestra que las líneas están ejecutadas pero no prueba que se comporten correctamente; ✔ una cobertura alta puede dar una confianza falsa
B) Demuestra de manera concluyente que el 90% del software está libre de errores
C) Es una medida definitiva de excelente calidad de prueba.
D) Indica que ya no es necesario escribir pruebas adicionales

Explicación: La cobertura de filas indica que solo se ejecutaron filas; No prueba que produzca resultados correctos. Incluso con pruebas ineficaces, se puede lograr una cobertura del 90%. El alcance es un mapa de "nunca miré dónde", no una garantía de "todo ha sido probado"; la protección real se mide mediante pruebas de mutación.

10. En las pruebas basadas en riesgos, ¿cómo se calcula el riesgo de una característica para dirigir el esfuerzo de prueba limitado?

A) Sólo por número de líneas de código.
B) Multiplicando la probabilidad de falla y el efecto que se producirá cuando se estropee ✔
C) Solo en el orden en que se desarrolló la función.
D) Priorizar solo la característica para la que es más fácil escribir pruebas

Explicación: En las pruebas basadas en riesgos, el riesgo se evalúa como probabilidad = probabilidad (probabilidad de avería) × impacto (daño si se rompe). Los dominios de alta probabilidad y alto impacto (pago, autenticación) merecen las pruebas más intensas, mientras que los dominios de baja × baja reciben pruebas ligeras.

11. ¿Cuál es el principal riesgo de agregar un reintento a una prueba que a veces pasa y a veces falla (frágil/inconsistente) aunque el código no haya cambiado?

A) Acortar el tiempo de ejecución de la prueba.
B) Disminuye el porcentaje de cobertura
C) Encubrir un verdadero error de concurrencia o causa raíz y suprimir el síntoma ✔
D) Cambiar el nombre de la prueba

Explicación: El reintento es una herramienta de diagnóstico, no un tratamiento. La indecisión a menudo proviene de una condición racial o adicción real; Hacer que la prueba 'pase' mediante un reintento encubre este error real y puede causar serios problemas en la vida. Primero se debe encontrar la causa raíz.

12. ¿Cómo funcionan las pruebas de mutación, el método más honesto para medir si un conjunto de pruebas realmente protege?

A) Midiendo la velocidad de carrera de las pruebas.
B) Contando cuántas líneas de código se escribieron
C) Ejecutando las pruebas en diferentes órdenes.
D) Creando deliberadamente pequeñas rupturas en el código y midiendo si las pruebas las detectan ✔

Descripción: Las pruebas de mutación producen pequeñas distorsiones (mutaciones) intencionales en el código fuente; Un buen conjunto de pruebas debería detectar estas distorsiones y volverse rojo. Las mutaciones que no se detectan (sobreviven) indican que las pruebas no preservan ese comportamiento. La puntuación de mutación es una medida de calidad mucho más honesta que el porcentaje de cobertura.

13. ¿Cuál es el límite principal que se debe seguir al realizar pruebas de seguridad (por ejemplo, pruebas de autorización/IDOR)?

A) Sólo debe realizarse sobre producto propio, dentro de autorización escrita y alcance definido, con fines defensivos ✔
B) Puede aplicarse libremente a cualquier sistema de interés
C) Se puede probar en sistemas activos de socios comerciales sin permiso
D) Cualquier vulnerabilidad encontrada debe publicarse públicamente de inmediato.

Descripción: Las pruebas de seguridad aprendidas en este módulo son solo para probar su propio producto con fines defensivos, dentro de una autorización escrita y un alcance definido. Acceder al sistema de otra persona sin permiso o realizar pruebas fuera de alcance es poco ético e ilegal; Cualquier vulnerabilidad encontrada se informa mediante divulgación responsable.

14. ¿Qué autoridad nunca se debería otorgar a la IA en el proceso de CI/CD?

A) Resumir los registros de pruebas fallidas
B) La autoridad para 'pasar' automáticamente una prueba fallida (roja) o pintarla de verde ✔
C) Sugerir un borrador de código de prueba
D) Redacción de archivos YAML de canalización

Descripción: la IA puede producir un esquema de código de prueba, canalización YAML y resumen de registros en CI/CD; sin embargo, nunca se debe ofrecer la capacidad de "aprobar/arreglar" automáticamente una prueba fallida. Esto anula el propósito de las pruebas y automáticamente oculta los errores. Pintar la prueba de verde debe ser una decisión consciente y razonada de una persona.