La calidad es una puerta. No una fase.
Si probar es algo que pasa después de construir, es lo primero que se corta cuando la fecha se corre. Nosotros la volvemos la condición para hacer merge.
El problema
La forma tradicional pone el QA al final, lo que garantiza dos cosas. Los defectos se encuentran en su momento más caro, y toda la actividad se vuelve negociable en el instante en que una fecha se acerca.
Nosotros lo invertimos. Las pruebas salen de la especificación, y se escriben antes de construir y no después. Una prueba escrita desde la especificación pregunta si la implementación hace lo que se pidió. Una prueba escrita desde la implementación terminada solo pregunta si la implementación hace lo que hace. Esas pruebas corren como puerta en cada merge, así que el trabajo que no pasa no entra, lo que le saca la decisión de las manos a cualquiera un viernes a las 6 de la tarde.
El resultado no es cero defectos, porque nada produce cero defectos. Es que los defectos que te llegan son de los interesantes, encontrados temprano, y no una regresión en una funcionalidad que servía el mes pasado.
- Pruebas escritas desde la especificación, antes de construir, no desde el código terminado
- Una segunda verificación independiente de que el código corresponde a la especificación, no solo a sí mismo
- Revisión automática y puertas de calidad en cada merge
- Suites de regresión que crecen con el producto en vez de podrirse
El modo de falla que sí tiene la entrega AI-First
Esta es la parte que la mayoría de los discursos sobre desarrollo con IA deja afuera, y es la razón por la que nuestra disciplina de QA se ve distinta de una tradicional.
Cuando alguien de ingeniería le pide a un agente construir una funcionalidad, el agente va a producir con gusto la implementación y las pruebas en la misma pasada, desde la misma lectura de la especificación. Si esa lectura estaba equivocada, la implementación está equivocada y las pruebas pasan igual. Nada en el pipeline objeta. El código está confiada y verificablemente equivocado contra un estándar que él mismo escribió.
Eso no es un defecto del modelo. Es una propiedad estructural de cualquier sistema que genera el trabajo y la verificación juntos. La velocidad lo empeora, porque se construye encima de la cosa equivocada antes de que alguien vuelva a leer el requisito.
Así que rompemos el ciclo a propósito. Los escenarios se definen desde la especificación antes de que empiece la implementación, y los define alguien distinto de quien conduce la construcción. Después de construir, un conjunto aparte de verificaciones comprueba los requisitos de la especificación que las pruebas de la construcción no cubrieron, escritas por otra persona con otra intención. Dos autores, dos intenciones, y una posibilidad real de atrapar la mala lectura.
- Escenarios definidos desde la especificación antes de construir, no derivados del código terminado
- Una pasada de cumplimiento aparte, escrita por alguien distinto de quien construyó
- Atención particular donde un agente se desvía de forma plausible: alcance de los datos, autorización, estado por defecto, caminos negativos
- Autorización verificada en la capa de API y de datos, no solo donde la interfaz esconde el botón
Quién responde por qué, y cuándo
El criterio que no se puede automatizar es decidir qué hay que comprobar y dónde es probable que un agente se equivoque. Ese es un trabajo distinto de escribir las pruebas, así que le corresponde a otra persona.
| Dimension | Definido antes de construir | Construido y verificado después |
|---|---|---|
| Qué hay que comprobar | El contrato de comportamiento: camino feliz, reglas de validación, casos borde, accesibilidad | Implementado como pruebas en la capa que lo compruebe más barato |
| Qué tan grave es una falla | Una severidad por escenario, acordada por adelantado | Qué se corrige primero cuando algo se pone en rojo |
| Cuándo corre | Humo, completa o regresión, decidido por escenario | Conectado al pipeline como puerta de calidad |
| Dónde podría desviarse un agente | Anotado por escenario, con anticipación | Atacado por una verificación de cumplimiento independiente después de construir |
| Qué capa del stack | Deliberadamente no se decide aquí | Decisión de ingeniería en tiempo de construcción: unitaria, de componente, de integración, de punta a punta, o visual |
La automatización ya no es la parte cara, así que un plan que se detiene en "vamos a escribir pruebas" no es un plan. Decidir qué comprobar es el trabajo.
Qué cubre esto
Regresión automatizada
Una suite que corre en cada cambio y que se mantiene como parte del trabajo.
Desempeño y carga
Pruebas de estrés y validación de escalabilidad contra expectativas reales.
QA de dispositivos y hardware
Bluetooth, IoT, terminales de pago y NFC sobre hardware real.
Pruebas de seguridad
Evaluación de vulnerabilidades y pruebas de penetración por especialistas.
Accesibilidad
Verificación WCAG tratada como requisito, no como remiendo.
Reportes de calidad
Qué está cubierto, qué no, y qué cambió en este ciclo.
La pirámide, y qué controla sobre ella
La estrategia de pruebas aquí tiene forma de pirámide, lo cual no está de moda decir y sigue siendo correcto. Muchas pruebas unitarias rápidas, menos pruebas de integración donde los componentes se encuentran, y una capa delgada de pruebas de punta a punta que cubre los recorridos que te costarían dinero si se rompieran.
La inversión es lo que sale mal en otras partes. Una suite que es casi toda de punta a punta es lenta, inestable, y termina ignorada, y una suite ignorada es peor que ninguna suite porque produce confianza falsa. Así que mantenemos delgada la capa cara a propósito.
Todo corre como puerta de calidad. El linter, las pruebas unitarias, las de integración y las de punta a punta corren en el pipeline, y el trabajo que no pasa no entra. En la aceptación de fase los umbrales de cobertura son números explícitos y no una promesa: al menos 70% unitaria y al menos 50% de integración sobre el código que escribimos, medido contra nuestro código y no inflado con librerías de terceros.
- Unitarias, de integración, y después una capa de punta a punta deliberadamente delgada
- El linter y cada nivel de prueba corriendo como puerta de merge, no como reporte nocturno
- Al menos 70% de cobertura unitaria y 50% de integración sobre el código escrito por Koombea en la aceptación de fase
- Cobertura medida sobre nuestro código, nunca rellenada con librerías de terceros
- Una barra más alta en los caminos que cargan riesgo: autenticación, autorización, pagos
- Ningún defecto P1 o P2 abierto en la entrega, que es una puerta dura y no una meta
Una puerta que no puede tumbar la construcción es decoración
Cada pipeline que corremos exige la misma línea base antes de cualquier merge: linter en cero errores y no en cero errores bloqueantes, verificación de tipos sin supresiones, la suite unitaria pasando, un piso de cobertura, análisis estático, y un escaneo de dependencias por vulnerabilidades conocidas.
La regla que importa es que la puerta tiene que poder fallar. Una verificación instalada pero no exigida no dice nada y entrena a todo el mundo a ignorar el rojo. Si alguna vez desactivamos una, la razón y la fecha en que vuelve a activarse quedan escritas.
También verificamos el artefacto y no el código de salida. Un comando de pruebas que corre cero pruebas termina con éxito, y un pipeline que reporta verde sin haber ejecutado nada es peor que ningún pipeline, porque fabrica confianza. Así que las puertas afirman que la salida existe y tiene la forma que debería, no solo que un comando devolvió cero.
- Linter, tipos, suite unitaria, piso de cobertura, análisis estático, escaneo de dependencias
- Cada puerta bloquea el merge, o no es una puerta
- Las corridas de prueba afirman una cantidad plausible de pruebas, así un cero silencioso no puede pasar por verde
- Una puerta desactivada carga una razón escrita y una fecha para restaurarla
Las herramientas, con nombre
Automatización de navegador y móvil
Selenium y Appium para cobertura entre navegadores y sobre dispositivos reales.
Punta a punta
Cypress para los recorridos cuya falla te costaría dinero.
Carga y desempeño
JMeter contra el volumen y el patrón de picos que esperas, no contra un número redondo.
Trazabilidad
BDD con Cucumber y Gherkin donde un requisito tiene que quedar demostrablemente probado.
Diseño de pruebas AI-First
Pruebas generadas desde la misma especificación que guía la implementación, y después revisadas.
Nuestra propia gestión de pruebas
Construida y operada en casa en vez de alquilada, y es la razón por la que los reportes son específicos.
Qué mueve la estimación
Aquí la calidad no es una línea aparte, porque las pruebas se generan desde la misma especificación que guía la construcción. Así que la pregunta no es cuánto cuesta el QA. Es qué sube la barra de cobertura, y eso vale la pena saberlo antes de escoger un alcance.
- Datos regulados o movimiento de dinero, que suben la cobertura requerida en vez de la cantidad de funcionalidades
- La matriz de dispositivos y navegadores que de verdad tienes que soportar, que normalmente es más pequeña que la solicitada
- Hardware físico dentro del alcance: Bluetooth, NFC, terminales de pago e IoT necesitan dispositivos reales, no simuladores
- Si hay que verificar y evidenciar un nivel de conformidad de accesibilidad
- Combinaciones de roles y permisos, que multiplican la superficie de prueba más rápido que cualquier otra cosa
Preguntas que vale la pena hacer
¿Podemos simplemente saltarnos las pruebas para alcanzar una fecha?
No tenemos ninguna prueba. ¿Por dónde empiezan?
¿Se acabaron las pruebas manuales?
¿70% de cobertura significa que se atrapan 70% de los defectos?
¿Quién corre las pruebas de penetración?
Credenciales detrás de los controles de calidad
Nuestros equipos tienen credenciales ISTQB y Certified Agile Tester, y la unidad de diseño y desarrollo de software de Koombea tiene evaluación CMMI-DEV/3.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.