Guía Esencial

Navegue en las secciones

BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Lo básico Póngase al día con nuestro contenido introductorio.

Amamos odiar las métricas de pruebas de calidad, pero aún las necesitamos

Necesitamos métricas de pruebas de calidad, pero solo hasta cierto punto. La experta Yvette Francino explica por qué tenemos que elegir las métricas y el proceso con cuidado.

Tengo una relación de amor-odio con las métricas de calidad. Por un lado, las encuentro muy valiosas para ayudarnos a analizar, reflexionar y mejorar. Por otra parte, las métricas de prueba pueden ser muy engañosas o dar lugar a comportamientos que no siempre son saludables.

Cuotas de recuento de defectos

Cuando se trata de medir la calidad, "contar defectos" son las métricas de prueba comunes. Esto ha sido un problema para mí desde mis primeros días como una desarrolladora de software de IBM en los años 80. En ese momento, estábamos usando el enfoque clásico de cascada para el desarrollo de software, y el proceso que se siguió fue que el código no podía moverse a lo largo de la siguiente fase hasta que se hubiera encontrado un cierto número de "defectos". La cuota de defectos era determinada por el número de líneas de código que había en el sistema en desarrollo. Así, por ejemplo, se requirió que los desarrolladores encontraran tantos defectos durante la prueba unitaria, y luego también se requirió que los probadores, que llevaron a cabo las pruebas de funcionamiento, encontraran un cierto número de errores antes de que el código pudiera ser desplegado.

Un problema con este enfoque es que no había "ponderación" para los defectos. El recuento de defectos no se basaba en su gravedad, por lo que, básicamente, un error tipográfico contaba igual que algo que podría provocar un corte de misión crítica. Como resultado, una gran cantidad de errores bastante triviales eran abiertos con el fin de alcanzar la cuota requerida.

Otro inconveniente era que el equipo de pruebas informaría de errores en escenarios "ridículos" –por lo menos en las mentes de nosotros, los desarrolladores– que cualquier cliente "sano" nunca haría. Esto dio lugar a una gran cantidad de errores cerrados como "errores de usuario". También estaba la clásica respuesta, un tanto condescendiente, "funciona en mi máquina", que daban los desarrolladores a los informes de errores. No hace falta decir que la relación entre los desarrolladores y los probadores no era tan buena.

¿Qué pasa cuando hay una falta de pruebas unitarias?

Avance rápido unos 15 años más o menos, a la década del 2000, cuando yo era gerente de control de calidad en Sun Microsystems. Al haber llegado desde el mundo del desarrollo, estaba concentrada en una relación de colaboración entre el área de desarrollo y la de control de calidad y, en su mayor parte, desarrollo y control de calidad eran amigos. Como gerente de control de calidad, todavía tenía que hacer una gran cantidad de informes sobre defectos, pero por suerte, control de calidad no estaba obligado a encontrar un cierto número de errores en función del número de líneas de código en el sistema que estaba bajo prueba. Sin embargo, no solo no había reglas estrictas para el control de calidad, sino que a los desarrolladores ni siquiera se les pedía hacer pruebas unitarias.

A pesar de que desarrollo y control de calidad eran "amigos", los equipos aún seguían separados organizativamente con los desarrolladores de código, y luego pasaban el código al equipo de control de calidad para probarlo. Había una aplicación que mi equipo de control de calidad estaba probando que era claramente de mala calidad. Mi pista principal era que el equipo encontró errores evidentes fácilmente. A pesar de mi recomendación en contra de ella, la aplicación fue desplegada a producción "en la fecha prevista". Esta era una aplicación interna de bajo riesgo, por lo que, a pesar de que tenía mis reparos, entendí la decisión de seguir adelante.

Cero defectos puede no significar alta calidad

Imagine mi sorpresa cuando, un mes más tarde, ese equipo de aplicación ganó un premio por la calidad porque había cero defectos reportados. Me encantan los premios, así que estaba contenta y orgullosa del equipo, pero no podía dejar de pensar: "¡De ninguna manera!". Hice un poco de investigación detrás de la escena, ¿y adivine cuántas personas habían utilizado esa aplicación? Cero. Así es. Ni una sola persona había incluso iniciado sesión en la aplicación. No recuerdo ahora por qué nadie la había utilizado. Podría haber sido que en realidad no la necesitaban, o tal vez su disponibilidad no había sido bien comunicada. Pero una lección importante que esto me enseñó: La calidad no puede medirse únicamente por el número de defectos encontrados. El uso del cliente y la retroalimentación son factores imprescindibles.

Un avance rápido de otros 15 años hasta el mundo actual del desarrollo ágil. Los desarrolladores y probadores trabajan juntos para proporcionar calidad. Tenemos integración continua y desarrollo impulsado por pruebas y otras técnicas para ayudar a hornear la calidad de forma temprano. Tenemos demos y nos reportamos con las partes interesadas después de cada carrera corta, para que podamos obtener retroalimentación temprana.

No hay respuestas fáciles sobre la mejor manera de medir la calidad. Tanto los procesos de calidad disciplinados utilizados en IBM, como los procesos más informales que experimenté en Sun eran apropiados en el momento y para las aplicaciones que estábamos probando. Los procesos ágiles tampoco garantizan la calidad. Lo importante es aprender y perfeccionar, ya sea que estemos hablando de aplicaciones de software, procesos o métricas de pruebas de calidad. Tanto si usted utiliza recuentos de defectos o alguna otra métrica, las prácticas ágiles nos dicen que obtengamos retroalimentación y que actuemos sobre esa retroalimentación.

Este artículo se actualizó por última vez en marzo 2016

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close