Por qué el código sin errores es el objetivo equivocado
Todo sistema tiene defectos con los que nadie ha tropezado todavía, y el costo de encontrar el siguiente sube con fuerza a medida que se eliminan los evidentes. Pasado cierto punto, la hora marginal dedicada a cazar defectos vale menos que esa misma hora dedicada a que los fallos sean baratos de detectar y corregir.
El segundo problema es cultural. Cuando el objetivo declarado es no tener errores, un error pasa a ser un fracaso que hay que explicar en lugar de información sobre la que actuar, y la gente empieza a hablar menos de ellos.
Tres objetivos que sí funcionan
Sin repeticiones
Un mismo error ocurre una sola vez. Cada corrección deja una comprobación detrás.
Alcanzable, y su efecto se acumula.
Detectado antes que los usuarios
Mueve la detección de producción al pull request.
Medible: qué proporción se detectó internamente.
Barato de corregir
El tiempo entre el fallo y la corrección, que depende sobre todo de la calidad del informe del fallo.
Por qué el primero es el que más importa
Un equipo que nunca publica el mismo error dos veces mejora cada mes por construcción. Requiere exactamente un hábito: cuando arregles algo, deja una comprobación detrás. La mayoría de los equipos corrige el error, cierra el ticket y no deja constancia de que ese comportamiento alguna vez necesitó protección.
La medición
Haz seguimiento de la proporción de defectos encontrados antes del lanzamiento y del tiempo entre el fallo y la corrección. Ambos se mueven cuando algo real mejora y ninguno se puede manipular escribiendo más pruebas, que es la propiedad útil. El número de pruebas y el porcentaje de cobertura suben cuando uno quiere y no te dicen casi nada.
Por qué los equipos lo siguen persiguiendo de todos modos
Saber que el objetivo está equivocado no impide que la gente apunte a él, y vale la pena entender el motivo porque es estructural, no ingenuo.
Los errores son visibles y la prevención no. Un defecto que llegó a un cliente tiene un ticket, un nombre y un responsable. Los doce que se detectaron antes del lanzamiento no tienen nada, porque no pasó nada. Así que el registro visible de un trimestre es una lista de fallos, y la respuesta natural ante una lista de fallos es exigir que haya menos.
La contrapartida es hacer que la prevención también sea visible. Informa de cuántos defectos se detectaron antes del lanzamiento junto a cuántos se escaparon. El primer número suele ser mucho mayor, y verlo cambia la conversación de por qué seguimos teniendo errores a si la proporción se está moviendo, que es la pregunta que tiene una respuesta útil.
Cómo se ve esto en la práctica
Cada error deja una comprobación. Las comprobaciones se ejecutan en cada cambio, no antes de los lanzamientos. Los fallos llegan en un formato sobre el que quien los corrige puede actuar sin tener que reconstruir la historia.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre el mismo terreno para quien no quiera una instalación local, y el conjunto completo de comandos vive en el repositorio de la CLI.
El disparador importa más que el mecanismo. Apuntarlo a tu evento de despliegue hace que cada cambio se compruebe sin que nadie tenga que decidirlo; la GitHub App lo hace desde el panel, y un paso de GitHub Actions lo hace desde dentro de tu flujo de trabajo.
Cómo TestSprite apoya los tres objetivos
Sin repeticiones es el que atiende de forma más directa. El caso que reprodujo un error se queda en el proyecto y se ejecuta en cada cambio, así que la corrección deja una comprobación detrás sin que nadie tenga que acordarse de escribirla.
Detectado antes que los usuarios es cuestión de cadencia. La cobertura se genera a partir de tu producto y se ejecuta en el pull request, lo que traslada la detección desde producción al cambio que lo provocó.
Barato de corregir depende del informe del fallo. Una ejecución devuelve qué se intentó, qué hizo la aplicación y dónde divergieron ambas cosas, de modo que quien lo corrige, cada vez más un agente de programación, parte de evidencia en lugar de reconstruir la historia.
¿Es alcanzable alguna vez el código sin errores?
En sistemas pequeños y formalmente especificados, casi, a un costo que casi nadie puede justificar. En un producto corriente, no.
¿Cuál es una tasa de defectos razonable?
Compárate con tu propia tendencia en lugar de con una cifra del sector. Importa más la dirección que el nivel.
¿Más pruebas significan menos errores?
Hasta cierto punto. Pasado ese punto, las pruebas adicionales añaden mantenimiento sin añadir señal, sobre todo si duplican lo que ya cubres.
¿Deberíamos hacer seguimiento del número de errores?
Haz seguimiento de los defectos que se escapan y del tiempo hasta la corrección. Los recuentos brutos suben cuando mejora el reporte, lo que los convierte en una señal pobre.
¿Cuál es el hábito con más impacto?
Deja una comprobación detrás cada vez que corrijas algo. Es el único hábito cuyo efecto se acumula.
Apunta a que nada se repita, no a cero.
El código sin errores no es alcanzable y distorsiona las prioridades. Apunta a que nada se repita, a detectarlo antes que los usuarios y a que corregirlo sea barato. Deja una comprobación detrás después de cada corrección y mide los defectos que se escapan en lugar del número de pruebas.