Dónde se encuentran los errores
No solo cuántos llegan a producción: cuántos se encuentran antes y cuántos se escapan. Ejemplo ilustrativo: de 5 de cada 10 a 8 de cada 10. Ese cambio habla directo de QA, porque QA es quien los encuentra antes.
Recurso gratuito · Video · El QA invisible
Un número que mezcla todo no tiene dueño.
Una tabla que dice qué cambió en QA, sí.
Una amiga me contó que en su empresa los errores que llegaban a producción bajaron un montón. Cuando los jefes miraron los números, nadie supo decir si la mejora venía de QA o de desarrollo. Y en esa duda, su trabajo se volvió invisible. Esta hoja es la tabla del video: tres datos, cómo estaban antes, cómo están después y qué cambió en QA.
Descargar la tabla (PDF)
Gratis · Sin registro · Una página A4.
Cuánto se tarda en encontrarlos
Cuántos días pasan, en promedio, hasta detectar un problema. Ejemplo ilustrativo: de 9 días a 2 días. Es el valor de probar temprano, y se puede medir.
Qué flujos importantes están probados
Flujos del negocio, no porcentaje de código: pagar, registrarse, cancelar una suscripción. Cuántos tienen pruebas hoy que antes no tenían. Ejemplo ilustrativo: de 4 de 12 a 10 de 12.
// Cómo se usa
Elige, mide, cuenta, lleva
- 1
Elige un dato
No tienes que reportar todo, todo el tiempo. Empieza por el dato que mejor muestra lo que cambió en tu equipo.
- 2
Saca el antes y el después
Los números salen de tu herramienta de seguimiento de errores, por ejemplo Jira: dónde se encontró cada error y cuándo se reportó. Compara un periodo antes de la mejora con uno después.
- 3
Llena «qué cambió en QA»
Escribe lo que se hizo y cuándo. No escribas «gracias a QA»: la conclusión la saca quien lee.
- 4
Llévala a una reunión, no por correo
Suma la línea de tiempo: en un gráfico simple, marca cuándo entró cada mejora de QA al lado de la curva de errores. Y cuenta la historia una vez.
El prompt que la llena contigo
Te paso un export en CSV de los errores de mi equipo.
La fecha de corte es [fecha]: lo anterior es «antes», lo posterior es «después».
Con esos datos, calcula para cada periodo:
1. Dónde se encuentran los errores: de cada 10, cuántos se encontraron
antes de producción y cuántos se escaparon a producción.
2. Cuánto se tarda en encontrarlos: días en promedio hasta detectar un error.
3. Qué flujos importantes están probados: de esta lista de flujos
[pagar, registrarse, ...], cuántos tienen pruebas.
Arma una tabla con tres filas y estas columnas:
| | Antes | Después | Qué cambió en QA |
Deja vacía la columna «Qué cambió en QA», o llénala solo con lo que yo te
cuente aquí: [mejoras de QA y fecha de cada una].
Si algún dato no se puede calcular con el CSV, escribe [Por confirmar]
en lugar de inventarlo.
No afirmes que QA causó la mejora: muestra los números y lo que cambió.
Al final, dime qué columnas del CSV usaste para cada dato.La tabla en Markdown, para pegar
# La tabla que hace visible a QA
| | Antes | Después | Qué cambió en QA |
|---|---|---|---|
| Errores encontrados antes de producción | | | |
| Tiempo hasta detectar un error | | | |
| Flujos importantes con pruebas | | | |
| Opcional · Lo que costaría cada error evitado (horas o ventas), si se puede calcular | | | |
## Línea de tiempo
Un renglón por mes. Si ese mes entró una mejora de QA, anótala en la última columna (por ejemplo: automatizar el login). Después pásalo a un gráfico simple y marca esos meses con una bandera.
| Mes | Errores en producción | Mejora de QA que entró ese mes |
|---|---|---|
| Mes 1 | | |
| Mes 2 | | |
| Mes 3 | | |
| Mes 4 | | |
| Mes 5 | | |
| Mes 6 | | |
**Los errores que no pasan no se demuestran solos.**El límite
Que la curva baje justo después de una mejora es una pista, no una prueba: pudo cambiar otra cosa al mismo tiempo. Por eso la línea de tiempo va junto al dato 1, el de dónde se encuentran los errores. La línea de tiempo dice cuándo. El dato dice quién los encontró.
Descargar tabla-que-hace-visible-a-qa.pdf