Sistema de departamento de aseguramiento de la calidad (QA)

Antes de cada lanzamiento se construye una tarjeta de «Plan» que define el ámbito de la prueba: las funciones nuevas, las zonas de mayor riesgo y los dispositivos y navegadores de la cobertura. Cuando la versión candidata está lista, pasa a «Ejecución», donde los probadores recorren los escenarios y registran el resultado de cada caso. Cada defecto descubierto genera una tarjeta de «Incidencia» con los pasos para reproducirlo, el resultado esperado y el real y el grado de gravedad; un desarrollador lo asume y lo corrige. La incidencia corregida vuelve a «Verificación» para que la pruebe un probador distinto de su autor y se asegure de que la corrección no rompió otra cosa. Cuando las incidencias críticas llegan a cero, la tarjeta madre pasa a «Publicación» con una recomendación formal, y las cifras se trasladan a «Informe»: cuántos casos se ejecutaron, cuántas incidencias se encontraron y en qué zonas se concentran los defectos.

El chat es la sala de operaciones durante la prueba: una incidencia crítica que detiene el lanzamiento se anuncia en él de inmediato, y una duda sobre si un comportamiento es intencionado o un error se resuelve con el desarrollador en un minuto, en lugar de una tarjeta rechazada. Pero la regla es estricta: lo que se resuelva en el chat se registra en la propia tarjeta de la incidencia, porque el tablero es el registro, no la memoria.

El director de calidad escribe el «Plan», reparte la ejecución y es dueño de la decisión de recomendar la publicación; y es quien detiene el lanzamiento si quedan incidencias críticas. Los probadores ejecutan y escriben las incidencias con un estándar unificado, y los desarrolladores reciben las incidencias, las corrigen y las devuelven a «Verificación». El principio del sistema: el probador no verifica la corrección de una incidencia que él mismo escribió, y la publicación es una decisión documentada con cifras, no una sensación general de que el panorama parece bueno.