Puesto
Pruebas y QA
¿Qué dejáis caer primero cuando una entrega llega más rápido que las pruebas? Normalmente la regresión, y ahí suele estar el fallo que vuelve como aviso de un usuario.
Conversación inicial
Cuatro preguntas por las que empezaríamos
¿Qué dejáis caer primero cuando una fecha de entrega aprieta?
La respuesta describe dónde surge la deuda de calidad de vuestro proceso.
¿Cómo sabéis que el área cambiada en esta entrega se ha probado?
Si es porque el tester lo cree, la cobertura es una convicción y no un hecho.
¿Cuántas veces vuelve el mismo fallo tras una corrección?
Si pasa con regularidad, lo que falta es una prueba que lo impida, no la atención de un desarrollador.
¿Qué es lo que no hacéis aunque sabéis que deberíais?
Normalmente: no probáis los casos límite ni los escenarios raros. Siempre por falta de tiempo, nunca por falta de conciencia.
Nos quedamos con la preparación y la repetición, vosotros con diseñar las pruebas
Preparar datos de prueba, ejecutar la regresión, informar de los resultados y mantener la documentación de pruebas se pueden quitar del escritorio. Qué hay que probar y por qué lo diseña el tester.
- La regresión no compite con las pruebas nuevas. - Si los escenarios repetibles se ejecutan solos, el tiempo del tester se va en lo que nadie ha comprobado antes.
- Los datos de prueba no bloquean el arranque. - Preparar un juego de datos para un escenario deja de ser una tarea de media jornada antes de cada ronda de pruebas.
- La cobertura es un hecho, no una impresión. - Se ve qué áreas cambiadas en una entrega tienen pruebas y cuáles no, y esa es la base de una decisión de publicar.
Alcance
Qué se puede quitar de un tester
Diecinueve tareas de ejemplo. Cada una tiene un punto de aprobación humana. Abajo una selección, y el alcance lo ajustamos a vuestro proceso de desarrollo.
Diseño de pruebas
- Un borrador de casos de prueba a partir de un requisito (valoración: el tester)
- Señalar los casos límite que considerar
- Enlazar un caso con un requisito y un área del sistema
- Una señal cuando un requisito no tiene prueba asignada
Datos de prueba
- Generar juegos de datos para un escenario
- Datos que cubran distintos estados y configuraciones
- Restaurar el estado del entorno antes de una ronda de pruebas
- Anonimizar los datos tomados de producción
Ejecución e informes
- Ejecutar los escenarios repetibles sin el tester
- Registrar el resultado con los pasos para reproducirlo
- Un borrador de informe de fallo con el contexto (contenido: el tester)
- Un resumen de los resultados de una ronda de pruebas
Pruebas de regresión
- Señalar las áreas afectadas por un cambio de la entrega
- Un conjunto de regresión ajustado al alcance del cambio (decisión: el tester)
- Una señal sobre un área cambiada y no cubierta por una prueba
- Comparar el resultado con la ronda anterior
Calidad tras la entrega
- Enlazar los avisos de los usuarios con áreas del sistema
- Señalar los fallos que una prueba existente debería haber detectado
- Fallos resumidos por área y causa
Un día de trabajo
Hoy
- Preparáis los datos de prueba a mano antes de cada ronda
- Ejecutáis la regresión pasando a clics por los mismos escenarios
- Con una fecha apretada probáis lo que da tiempo
- No sabéis si el área cambiada en la entrega tiene alguna prueba
- Escribís un informe de fallo desde cero, con los pasos
- Tras la entrega no sabéis qué fallo podía haberse detectado antes
Con asistencia de IA
- Un juego de datos para un escenario se genera sin media jornada de preparación
- Los escenarios repetibles se ejecutan solos
- El tiempo se va en casos que nadie ha comprobado antes
- Un área cambiada y no cubierta por una prueba está señalada
- Un informe de fallo tiene borrador con los pasos para reproducirlo
- Los fallos posteriores a la entrega se enlazan con carencias de las pruebas
- Cobertura de pruebas
se ve qué está comprobado y qué solo lo parece
los casos están enlazados con requisitos y áreas
- Tiempo de regresión
la regresión cabe antes de la entrega y no después
los escenarios repetibles se ejecutan solos
- Fallos detectados tras la entrega
menos asuntos que llegan a los usuarios
el tiempo del tester se va en casos nuevos
- Pruebas repetibles
la misma prueba da el mismo resultado la ejecute quien la ejecute
los datos y el estado del entorno se pueden reproducir
Empezamos por los datos de prueba, porque son lo que más a menudo retrasa el arranque de las pruebas.
- Paso 1
Datos y un entorno reproducible
Juegos de datos para los escenarios y un estado inicial repetible.
- Paso 2
Escenarios repetibles
Ejecutar la regresión sin el tester en cada pasada.
- Paso 3
Cobertura frente a los cambios
Señalar las áreas cambiadas y no cubiertas por una prueba.
- Paso 4
Calidad tras la entrega
Enlazar los avisos con áreas y con carencias de las pruebas. Al final, porque requiere datos de producción.
Preguntas frecuentes
Preguntas que surgen en la primera reunión
¿No rebajará esto la posición del tester en el equipo?
Normalmente al contrario, porque el tester deja de ser quien pasa a clics por la regresión y pasa a ser quien diseña qué merece la pena comprobar siquiera. Esa es la parte más difícil de este trabajo y la más visible para el equipo.
¿Seguirán haciendo falta testers?
Las pruebas generadas no encuentran lo que importa, y lo decimos abiertamente unos párrafos más abajo. Un tester hace falta para diseñar qué merece la pena comprobar siquiera, y esa es la parte más difícil de este trabajo que pasar a clics por la regresión. Cuando la regresión se ejecuta sola, hay tiempo para ello. Los equipos que pasan por esto suelen acabar con un QA más fuerte, no más pequeño.
¿Esto entra en el ámbito del Reglamento de IA?
Probar software no es un uso de alto riesgo. El único punto que requiere cuidado es usar datos de producción como datos de prueba: ahí se aplican las reglas de protección de datos y la anonimización es parte del alcance y no un añadido.
¿Os queda alguna pregunta que no esté aquí? Reservad una llamada
Siguiente paso
¿Cuánto tiempo se fue antes de la última entrega en preparar datos de prueba?
Os enseñaremos cómo son las pruebas cuando la regresión no compite con los casos nuevos y la cobertura se ve antes de la decisión de publicar.