¿Puedes predecir si el software fallará antes de probarlo?
Más allá aún: ser capaz de predecir la cantidad de defectos y fallas que tendrá el software antes de iniciar testing
En este artículo:
Una historia de gestión de la calidad
Cómo predecir si el software fallará
Plan de acción
Recursos para ti
Fui coach de calidad y procesos para un proyecto, en el que trabajaron dos equipos. Un equipo estaba encargado del diseño de especificación y pruebas del software; el otro, de escribir el código y hacer la integración del mismo. La separación de estas responsabilidades era así por regulaciones propias del tipo de software en desarrollo.
El proyecto estaba dividido en tres ciclos, cada uno con sus respectivas actividades de especificación, implementación y pruebas funcionales. En el primer ciclo, el equipo de desarrollo entregó siete componentes para pruebas y yo hice una recomendación al otro equipo: “no inicies las pruebas todavía, estos componentes van a presentar varias fallas y causarán un retraso importante”. Yo no había probado los componentes ni leído su código antes de afirmar esto.
El líder técnico del equipo de diseño y pruebas no me tomó en serio, y dijo que empezarían a probar inmediatamente para seguir con el plan. Le insistí que postergara el inicio de pruebas un par de días, para que revisaran los componentes y eliminaran los fallos antes de probar. Frunció el ceño y le escribí en la pizarra de la oficina:
Fallas pronosticadas: 14
Retraso estimado: 1.5 semanas
Las pruebas debían hacerse en tres días, pero el líder técnico me llamó al segundo día con las temidas palabras “tenemos un problema”. No habían podido completar las primeras pruebas porque los componentes fallaban y detenían todo el proceso; hasta el momento, habían encontrado siete fallas graves y solo en un componente; los otros ni siquiera los habían tocado. Nos sentamos, revisamos la situación, le dije mi pronóstico: 7 defectos en componente A, 3 en componente C, 2 en componente D y 2 en componente E (los otros tres no deberían presentar problemas). Siguió con su proceso anterior y terminaron las pruebas en dos semanas, luego de que el otro equipo estuvo arreglando y regresando los componentes.
Las fallas totales en el ciclo fueron 14 y el retraso de dos semanas (un poco mayor al pronosticado). El líder técnico estaba atónito con lo certero de la predicción.
Para el siguiente ciclo, el líder técnico se acercó a mí antes de la fecha de entrega a preguntarme cómo había adivinado lo que pasaría en la primera iteración y que estaba preocupado de que el tiempo se les viniera encima. Le dije que me acompañara a leer los datos del proceso y allí lo comprenderíamos juntos.
En el segundo ciclo, detuvimos la prueba de dos componentes para que los revisaran y probamos los restantes. Se pronosticaron 7 fallos y encontraron 5, que repararon fácilmente. En el último ciclo, con el aprendizaje anterior, acordamos una estrategia conjunta para prevenir los defectos; en pruebas solo aparecieron dos defectos menores.
El proyecto concluyó satisfactoriamente y sobró tiempo para agregar una función extra (que al cliente le encantó). La buena calidad paga, y paga bien.
¿Cómo predecir la calidad del software antes de probarlo?
No soy un mago o un adivino con bola de cristal, que consulta fuerzas sobrenaturales para predecir el futuro. Solamente leo e interpreto números.
Watts Humphrey me enseño que la calidad del producto de software depende de la calidad del proceso que se usó para construirlo. Si tu proceso es cuidadoso con la calidad, el producto será de alta calidad; lo opuesto, si tu proceso no contempla la calidad como componente principal.
Me basta dar un vistazo a la forma de trabajo para saber si el testing será fácil y corto o largo y tortuoso. Si agregamos mediciones (los números), podemos predecirlo con precisión.
¿Qué medir y en qué poner atención?
Verás, todos los desarrolladores y gente involucrada en el desarrollo de software comete errores (eso ya te lo había dicho anteriormente). Lo interesante es que sabemos las razones y proporciones de sus errores y entender su impacto en el producto. Esto es lo que sabemos hasta hoy:
Un analista / PO comete entre 2 y 4 errores por hora de trabajo en documentos de requerimientos.
Un Líder Técnico comete entre 4 y 8 errores por hora de trabajo en las decisiones de diseño de la solución.
Un desarrollador comete entre 10 y 20 errores por hora de trabajo en el código del producto.
Si haces las multiplicaciones, tendrás una estimación de la cantidad de errores en el producto, 80% de los cuales causarán fallas en testing y producción.
Otros datos que conocemos bien hasta hoy son:
En procesos que no son minuciosos con la calidad, el 90% de los errores llegan a testing.
Las actividades de testing, por más minuciosas que sean, solo encuentran el 50% de todos los errores.
Es decir, que por cada 10 errores, 9 llegarán a pruebas, 5 serán encontrados por QA y 4 llegarán a producción, con costos de arreglo altísimos.
¿Empiezas a ver cómo hice las predicciones del proyecto con el que inicié el artículo?
¿Cómo predecir para hacer planes?
Con base en las métricas anteriores, puedes planificar para la buena calidad con estas acciones:
Estima la cantidad de horas que trabajarás en documentación, diseño y código.
Multiplica el tiempo de cada trabajo por las tasas de error que te compartí en la sección anterior, por ejemplo:
10 horas en documentación: 20 errores
5 horas en diseño de solución: 20 errores
20 horas en código: 200 erroresEstablece el siguiente objetivo: cambiar mi forma de trabajo para que encuentre el 70% de los errores antes de enviar el producto a Testing.
Hay muchas maneras de lograr el paso tres. De eso quiero hablarte en el siguiente artículo.
Por lo pronto, ¡gracias por leer! Déjame tus comentarios y con gusto dialogamos
¿Quieres implementar estas mejoras, pero no sabes cómo? Te presento dos alternativas:
Una consulta profesional de 1 hora, para discutir problemas individuales y encontrar respuestas.
¡Únete al grupo de facebook para compartir ideas con otros profesionales de Élite!