Hay algo curioso sobre las fallas en producción que ocurren en la mayoría de las empresas  y es que casi nunca aparecen cuando la organización está preparada para enfrentarlas. 

Por lo general estas aparecen en el peor momento posible; mientras está activa una campaña comercial, en el lanzamiento de un nuevo producto, en una fecha de alta demanda o justo después de una actualización que parecía completa. 

Lo verdaderamente interesante es que la mayoría de las organizaciones no descubren la importancia de una estrategia de pruebas después de una capacitación, una auditoría o una reunión de planeación, sino que lo descubren cuando enfrentan las consecuencias de no haberla tenido. 

Y aunque sabemos que cada incidente es diferente, las lecciones que dejan suelen ser bastante similares. Por eso en SQA te contamos 3 lecciones que toda empresa aprende después de una falla en producción: 

• Probar no es lo mismo que tener una estrategia de pruebas 

Después de una falla importante, muchas compañías descubren algo que inicialmente parece contradictorio y es que, aunque sí se realizaron pruebas, hubo casos ejecutados, validaciones documentadas e incluso aprobaciones formales antes de salir a producción, el incidente ocurrió de todas formas. 

La razón es sencilla, ejecutar pruebas no garantiza que se estén validando los escenarios correctos. 

En muchas organizaciones, las actividades de QA siguen enfocándose en comprobar que una funcionalidad cumpla con los requisitos definidos. El problema es que los usuarios no interactúan con funcionalidades aisladas. Interactúan con procesos completos que involucran múltiples sistemas, integraciones, reglas de negocio y condiciones que cambian constantemente. 

Cuando las pruebas se diseñan únicamente alrededor de requisitos, la organización valida que el sistema haga lo que debería hacer. Cuando existe una estrategia de pruebas, la organización valida también lo que podría salir mal. 

• Las fallas técnicas casi siempre terminan convirtiéndose en problemas de negocio 

Uno de los mayores errores que cometen las organizaciones es pensar que la calidad es una preocupación exclusiva del área de tecnología, pero la realidad demuestra exactamente lo contrario. 

Cuando una aplicación presenta errores en producción, el impacto rara vez permanece dentro del equipo de desarrollo. Lo que comienza como un incidente técnico suele afectar rápidamente otras áreas de la organización. 

Cuando un fallo ocurre por lo general el área de servicio al cliente recibe reclamos, el equipo comercial enfrenta clientes insatisfechos, operaciones debe gestionar excepciones y marketing ve afectadas las campañas que están en ejecución. Es ahí donde la dirección comienza a evaluar las consecuencias económicas del problema. 

En ese momento queda en evidencia algo que muchas empresas entienden demasiado tarde; la calidad nunca fue un asunto técnico, siempre ha sido un asunto de negocio. 

Por esta razón, las estrategias de pruebas más efectivas no se construyen únicamente alrededor de aplicaciones, plataformas o funcionalidades. Se construyen alrededor de procesos críticos, objetivos comerciales y riesgos operativos. 

Cuando una empresa entiende el impacto real de una falla, deja de preguntarse cuánto cuesta hacer QA y empieza a preguntarse cuánto cuesta no hacerlo. 

• Mientras más tarde se detecta un fallo, más difícil es corregirlo 

Existe una frase muy ampliamente conocida en la industria del software; los defectos son más baratos cuando se encuentran temprano. Aunque parece una afirmación sencilla, comprender todo lo que realmente implica sigue siendo un desafío para muchas organizaciones. 

Cuando un riesgo se identifica durante la definición de requisitos, normalmente basta con ajustar una decisión de negocio o replantear un flujo funcional. Cuando ese mismo problema aparece durante el desarrollo, ya existe un esfuerzo técnico involucrado. Si llega a la fase de pruebas, el costo continúa creciendo porque ahora también impacta cronogramas, recursos y prioridades. 

Pero cuando alcanza la etapa producción, la situación cambia por completo. En ese momento ya no se trata únicamente de corregir código. Se trata de tener que gestionar clientes afectados, atender incidentes, coordinar múltiples equipos, analizar impactos reputacionales y en muchos casos, responder ante consecuencias financieras directas, todo al mismo tiempo. 

Por eso una de las lecciones más importantes que deja cualquier incidente, es que la calidad no puede ser una actividad que ocurre al final del proyecto. 

Cuando el QA participa desde el inicio, las conversaciones cambian. Ya no se habla únicamente de funcionalidades, también se analizan riesgos, dependencias, escenarios críticos y posibles puntos de falla. Muchas veces esas conversaciones evitan problemas que jamás llegarán a convertirse en defectos. 

La verdadera lección detrás de todas las demás para las empresas

Las tres lecciones tienen algo en común, ninguna habla exclusivamente de tecnología, todas hablan de decisiones. Hablan de cómo las organizaciones gestionan el riesgo, protegen la experiencia de sus clientes y construyen confianza en cada cambio que llevan a producción. 

Por eso las empresas más maduras no esperan a experimentar una crisis para preguntarse si sus pruebas son suficientes. Entienden que cada liberación representa una oportunidad para fortalecer o debilitar la percepción que los usuarios tienen de la marca. 

Las fallas en producción seguirán ocurriendo ya que ninguna organización está completamente exenta de ellas. Lo que sí puede marcar la diferencia es qué tan preparada está para evitar que un pequeño fallo se convierta en un gran problema. 

Y esa es precisamente, la lección que las empresas más exitosas prefieren aprender antes de que ocurra el próximo incidente. Si quieres conocer más haz clic aquí.