Ganancias:
- Ser capaz de distinguir dónde la inteligencia artificial ahorra tiempo real en el proceso de control de calidad y dónde las decisiones de calidad, como "listo para publicación", se dejan en manos de los humanos, según el nivel de riesgo de la tarea.
- Capacidad para reconocer el riesgo de pases falsos e implementar una disciplina de verificación que pruebe cada prueba de IA rompiendo deliberadamente el código.
- Capacidad para proteger datos de prueba, datos personales y claves, y adquirir el hábito de realizar pruebas de seguridad sólo dentro de la autorización y con fines defensivos.
Considere una noche de lanzamiento. Se realizaron cientos de pruebas, todas obtuvieron luz verde, el equipo se sintió aliviado y el software se puso en funcionamiento. A la mañana siguiente, el cliente informó que la pantalla de pago se había bloqueado. Las pruebas estaban en verde pero no vio el error. Esta es la pesadilla más insidiosa de la profesión de control de calidad (QA), es decir, la disciplina que garantiza sistemáticamente que el software tenga la calidad deseada: la prueba que se ilumina en verde pero que en realidad no confirma nada. Cuando la inteligencia artificial (IA, software que extrae patrones de datos históricos y genera texto y código) ingresa a esta profesión, se produce a la vez una enorme aceleración y una magnificación de exactamente esta pesadilla. La promesa inicial de este módulo es clara: la IA es un asistente de pruebas, un generador de planos y un multiplicador de ideas; Usted es el evaluador que aprueba la decisión de "¿está este software listo para su lanzamiento?".
En esta primera unidad nos centraremos en la disciplina, no en la herramienta. Aprenderá dónde la IA ahorra tiempo real en el proceso de control de calidad, dónde es peligrosa, por qué el engañoso verde llamado "paso falso" es el mayor riesgo, cómo verificar cada resultado y qué datos puede proporcionar a cada herramienta. Sin sentar estas bases, las unidades posteriores quedarán en el aire.
¿Dónde resulta útil la IA en el proceso de prueba?
Dividamos los trabajos de prueba en dos grandes grupos. Primer grupo: trabajos preliminares, repetitivos y producibles. Redactar un caso de prueba a partir de un requisito, enumerar puntos de interrupción, escribir un esqueleto de código de automatización para una pantalla, traducir un caso de error complejo en un informe de error ordenado, resumir cientos de líneas de archivos de registro y extraer un esquema de una respuesta API. En estas tareas, la IA reduce los minutos a segundos y no se cansa.
Segundo grupo: decisiones cuyo resultado es calidad, confianza y responsabilidad. Decisiones como "¿puede esta versión entrar en funcionamiento?", "¿este error es crítico o puede posponerse?", "esta cobertura de prueba es suficiente", "este escenario captura el riesgo real del usuario", etc., requieren contexto, conocimiento del producto y responsabilidad. Aquí la IA genera opciones, borradores, pero usted decide “aprobar/reprobar” y “aprobar/no aprobar”.
Aclaremos la distinción en una frase: la IA es fuerte en "qué situaciones se pueden probar y cómo escribir código que las pruebe"; La decisión es suya cuando se trata de la pregunta "¿Este software realmente funciona y quién lo avala?"
Consejo: antes de entregar un trabajo a la IA, pregunte: "¿Qué sucede si este resultado es incorrecto y no me doy cuenta?" Si la respuesta es "Perderé unos minutos", delega fácilmente. Si la respuesta es "el software defectuoso se activa", deje que la IA produzca el borrador y usted tome la decisión y la verificación.
Falso pase: el riesgo número uno de la IA en el control de calidad
Cuando una prueba se ilumina en verde, puede significar dos cosas: o el software realmente está funcionando correctamente o no detecta el error porque la prueba se escribió incorrectamente. El segundo se llama falso aprobado: la prueba dice "aprobado" pero en realidad no confirma nada. Este riesgo aumenta significativamente en las pruebas producidas con IA, porque la IA tiene mucho éxito a la hora de redactar pruebas fluidas y de apariencia fluida pero vacías.
Las tres formas más comunes de pseudoaprobación son: (1) Pruebas sin aserción: el código se ejecuta, no contiene aserciones y siempre pasa. (2) Prueba de autoverificación: el valor esperado de la prueba se calcula a partir del resultado del código bajo prueba; Es decir, cualquier cosa que produzca el código, la prueba lo acepta como "correcto". (3) Prueba que verifica algo incorrecto: la afirmación existe, pero verifica algo trivial (por ejemplo, "la respuesta no es nula"), no la regla comercial real.
Precaución: Un panel de prueba verde no es prueba de calidad; En el mejor de los casos, dice "los controles que escribimos no están rotos en este momento". No se sienta reconfortado al ver un "aprobado" en la prueba que produce la IA; la verdadera pregunta es: ¿esta prueba se pondrá roja si rompo deliberadamente el código? Si no gira, esa prueba es una decoración.
La regla de oro que se repite a lo largo de este módulo: probar cada prueba de IA rompiendo deliberadamente el código. Si la prueba aún está verde, esa prueba no está funcionando. (Profundizaremos en esta idea como prueba de mutación en la unidad 10).
Disciplina de verificación: tres pasos
La IA habla con confianza; Eso no significa que sea verdad. Desarrolle un reflejo de tres pasos para aplicar a cada resultado:
- Átelo al requisito. Cada caso de prueba y afirmación que produce la IA debe basarse en un requisito o criterio de aceptación real (condiciones que debe cumplir un trabajo para que se considere "terminado"). “¿Qué regla confirma este escenario?” preguntar.
- Encolerizarse. Ejecute la prueba generada una vez, descifrando el código. Si no se pone rojo, la prueba no es válida. Este es el paso no negociable en las pruebas de IA.
- Pásalo por el filtro de contexto. ¿El resultado coincide con lo que usted sabe que es el comportamiento del producto, la arquitectura y el flujo de usuarios real? El conocimiento de su dominio es el filtro final.
Privacidad y seguridad de los datos: ¿qué va y dónde?
Los datos con los que trabaja en el entorno de prueba suelen ser confidenciales: registros de clientes reales, copias de bases de datos de producción, claves API, direcciones internas del sistema y funciones aún por anunciar. Haga una clasificación sencilla: Los datos abiertos (documentados, disponibles públicamente) pueden ingresar a cualquier vehículo. Datos internos (fragmentos de código fuente, documentación interna) solo a herramientas aprobadas por la agencia. Los datos confidenciales (datos reales del cliente, información de identidad, detalles de vulnerabilidad, claves) solo ingresan a las herramientas contratadas por la institución, cuyos datos no van a la capacitación del modelo, preferiblemente enmascarados.
Existe un límite adicional en el contexto de las pruebas de seguridad: todo lo aprendido en este módulo tiene fines defensivos: probar con autoridad la seguridad de su propio producto. Usar IA para infiltrarse en el sistema de otra persona sin permiso, convertir en armas vulnerabilidades reales o probar un sistema para el cual no se tiene autoridad es poco ético y criminal. No se realizarán pruebas ofensivas sin autorización (alcance y permiso).
Consejo: utilice datos de prueba sintéticos (producidos artificialmente) en lugar de datos reales de los clientes. Pedirle a la IA que “genere datos de prueba realistas pero completamente ficticios” preserva la privacidad y diversifica los casos extremos.
tres mini casos
Caso 1: Ahorro de tiempo en el lugar correcto. El evaluador de un equipo de Ekomerce pasó 6 horas creando manualmente un escenario de prueba a partir del documento de requisitos de 30 páginas para cada versión. Le entregó el documento (la parte que no contenía secretos comerciales) a YZ y pidió un borrador de escenario estructurado; El tiempo se redujo a 90 minutos. Dedicó el tiempo ahorrado a verificar por sí mismo agregando casos extremos de reglas comerciales que la IA había pasado por alto. La IA eliminó el trabajo repetitivo y dejó el juicio al ser humano.
Caso 2: Atrapado en un pase falso. Un desarrollador hizo que la IA escribiera 12 pruebas unitarias para una función de cálculo; todos eran verdes. El evaluador implementó el paso "ver rojo": cambiar deliberadamente el signo de suma dentro de la función a multiplicación. Sólo 3 de 12 pruebas arrojaron resultados rojos. Las otras nueve pruebas no proporcionaron ninguna confirmación real; Simplemente decía "no arrojó ningún error". Se eliminaron 9 pruebas decorativas y en su lugar se escribieron 5 pruebas reales.
Caso 3: Regreso por violación de la privacidad. Un pasante pegó un registro de errores que contenía correos electrónicos de clientes reales y los últimos cuatro dígitos de la tarjeta de la base de datos de producción en una herramienta pública y dijo "explica este error". El responsable de control de calidad intervino: se trataba de datos personales fuera de control y una violación de la KVKK (Ley de Protección de Datos Personales). El mismo trabajo se realizó en un vehículo aprobado por la institución, enmascarando las áreas personales y dejando solo un rastro de la pila.
Cuatro plantillas copiables
1) Evaluación de idoneidad laboral:
Su función: líder senior de control de calidad. Te describiré un trabajo de prueba. Dígame (1) si este trabajo es un trabajo de redacción/análisis que se puede delegar de manera segura a la IA o una decisión de calidad que el ser humano debe tomar, (2) el costo potencial de una producción incorrecta, (3) la verificación que debo hacer antes de delegar. Trabajo: [insertar trabajo aquí]
2) Control de pseudopaso:
Mira la prueba a continuación. Dime:- ¿Qué comportamiento confirma esta prueba? (una oración) - ¿Cómo puedo descifrar el código bajo prueba para que la prueba se vuelva ROJA? - ¿Existe alguna debilidad que pueda hacer que esta prueba pase siempre (falta afirmación, autovalidación, verificación trivial)? Prueba: [pegue la prueba aquí]
3) Control de enmascaramiento de datos de prueba:
El registro/los datos que le proporcionaré pueden contener campos personales o confidenciales (correo electrónico, nombre, tarjeta, clave, dirección interna). Primero, enumere los campos que deben enmascararse; Lo enmascararé y lo enviaré de nuevo. No lo analices tal como es.
4) Generación de datos de prueba sintéticos:
Genere 20 filas de datos de prueba realistas y completamente ficticios para [la siguiente estructura de campo]. No utilice datos reales de personas/organizaciones. Incluya también casos extremos: espacios vacíos, texto demasiado largo, valores límite, formato no válido.
Aviso débil / Aviso fuerte
Débil: "Escribe pruebas en este código".
Fuerte: "Calcule esto Escriba pruebas unitarias para la función de descuento. Criterios de aceptación para la función: 10% de descuento sobre 1000 TL, 20% de descuento sobre 5000 TL; la cantidad negativa debería arrojar un error. Especifique con una línea de comentario qué regla está validando para cada prueba. Pruebe los valores límite (999, 1000, 1001, 5000, 0, -1) por separado. Utilice afirmaciones reales que se volverán rojas si Rompo el código; lo vacío o no escribo una afirmación trivial".
Aviso potente; Proporciona criterios de aceptación, valores límite, expectativas de validación e instrucciones explícitas contra la suplantación de identidad. El mensaje débil invita a la IA a escribir una prueba decorativa.
Errores comunes
- Confiando en el verde. Pensar que pasar la prueba es una prueba. La verdadera pregunta es: ¿se pone rojo cuando descifras el código?
- Solicitar una prueba sin dar ningún motivo. La IA produce pruebas genéricas, a menudo inútiles, sin saber qué es lo que hay que verificar.
- Saltarse la verificación. Decir "La IA lo escribió, probablemente sea cierto". La responsabilidad recae en la persona que utiliza la salida.
- Pegar datos reales/sensibles en la herramienta. Trabajar con datos de producción, claves o datos personales.
- Pruebas de seguridad no autorizadas. Intentar realizar pruebas ofensivas sin alcance ni permiso.
- Usar IA para delegar la toma de decisiones. Hacer la pregunta "¿Se puede lanzar esta versión?" a la IA y poniendo la respuesta en la firma.
En resumen
La IA es un poderoso asistente en el proceso de control de calidad que acelera el trabajo repetitivo y producible; Pero la responsabilidad de la decisión de calidad recae en el ser humano. El riesgo número uno de la IA en esta profesión es el pseudo-aprobado: pruebas ecológicas que parecen interesantes pero no confirman nada. Pruebe cada prueba de IA descifrando deliberadamente el código; Si no se pone rojo, esa prueba es una decoración. Vincúlelo al requisito, vea el rojo, páselo por el filtro de contexto. Enmascare datos confidenciales, realice pruebas de seguridad solo con fines autorizados y defensivos.
Tarea de aplicación
Realice 5 pruebas unitarias generadas por IA (o generadas por IA) de su propio proyecto. Para cada uno: (1) escriba en una oración qué comportamiento verifica, (2) rompa y ejecute deliberadamente el código bajo prueba y observe cuántos se vuelven rojos, (3) marque los que no se vuelven rojos como "pruebas de decoración" y reescríbalos con la afirmación real. Coloque el resultado en una tabla: nombre de la prueba / regla verificada / se rompió cuando se rompió / acción.
lista de verificación
- [ ] Antes de entregar el trabajo, hice la pregunta "¿qué perderé si sale mal?"
- [] Probé todas las pruebas de IA descifrando el código; Reemplacé el que no se puso rojo con la prueba real.
- [] Vinculé los casos de prueba con los criterios de aceptación/requisito reales.
- [] Enmascaré datos confidenciales/reales sin entregárselos a la herramienta; Utilicé datos sintéticos si era posible.
- [] Consideré las pruebas de seguridad solo dentro de la autoridad y con fines defensivos.
- [] Dejé la decisión de "si se lanzará la versión" a mí mismo, no a la IA.