-
Dirección original: Por qué los errores no se solucionan
Autor: Alan Page, Director de Excelencia en Ingeniería de Pruebas de Microsoft, coautor del libro Cómo probamos el software en Microsoft (traducido en chino como "La forma de prueba de software de Microsoft").
Traducción: Lu Yueli, Lu Mengyan, Wang Hong
Últimamente me he encontrado con más y más personas que se sorprenden de que lancemos un producto con errores. Lo que me sorprendió fue que muchas de estas personas eran probadores de software y pensé que ya lo sabrían. Le sugiero que lea primero el artículo anterior (pero excelente) de Eric Sink. No estoy seguro de cuánto más puedo contribuir a este tema, pero quiero intentarlo.
No vale la pena corregir muchos errores. "¿Eres un tester?", me gritarás, "Los testers son los guardianes de la calidad del producto". Puedo repetirlo otra vez (si es necesario), no vale la pena corregir muchos errores. "Déjame decirte por qué. En la mayoría de los casos, corregir un error requiere cambiar el código. Y cambiar el código requiere una inversión de recursos (tiempo) e introduce riesgos. Eso apesta, pero es cierto. A veces, si el riesgo y la inversión son muy superan el valor de corregir los errores, por lo que no los corregiremos.
Nuestra decisión sobre si corregir un error no se basa, ni debería basarse, en "sensaciones". Me gusta utilizar el concepto de "dolor del usuario" para ayudarme a tomar decisiones. Utilizo tres factores clave para considerar e identificar el "dolor del usuario":
1. Gravedad: ¿Qué impacto tendrá este error? ¿Hará que todo el programa se bloquee? ¿Hará que se pierda la información del usuario? ¿O no es tan grave? ¿Existe una solución más sencilla? ¿O es simplemente una cuestión irrelevante?
2. Frecuencia: ¿los usuarios encuentran este problema con frecuencia? ¿Es parte del flujo de trabajo principal del programa? ¿O está oculto en una función que no se utiliza habitualmente? Probablemente será necesario solucionar los pequeños problemas que existen en las partes más utilizadas del programa, mientras que es posible que se dejen de lado algunos problemas importantes que existen en las partes menos utilizadas del programa.
3. Impacto en los clientes: si ha hecho bien su tarea, ya debería saber quiénes son sus clientes y cuántos (o cuántos espera tener) usuarios habrá en cada uno de sus grupos de clientes. Luego hay que juzgar si este problema afectará a todos los usuarios o sólo a algunas personas. Si puede realizar un seguimiento de cómo los clientes utilizan su producto, podrá obtener datos más precisos.
Los tres factores anteriores constituyen una fórmula. Asigne un rango de valores a cada uno de los factores anteriores y haga algunos cálculos; puede sumar, multiplicar o sumar pesos directamente según su aplicación y los factores del mercado. Por ejemplo, solo necesitamos realizar una suma y asignar un rango numérico de 10 puntos a cada error.
Error #1: Por ejemplo, es un error que bloquea el programa (10 puntos), existe en la mayor parte del programa (10 puntos) y afecta al 80% de los clientes (8 puntos), por lo que este error causa "dolor del usuario" "El volumen es de 28 puntos y apostamos a que lo vamos a solucionar.
Error #2: Es solo un error de arreglo (2 puntos), aparece en la ventana secundaria (2 puntos), y la parte del programa donde se encuentra el error solo se usará en versiones anteriores (2 puntos). Por lo tanto, el valor de "dolor del usuario" de este error es de 6 puntos y probablemente no lo solucionaremos.
Desafortunadamente, muchas situaciones no son tan simples como las anteriores. El error n.º 3 es un problema de pérdida de datos (10 puntos) que existe en la mayor parte de una aplicación pero que solo falla en determinadas circunstancias (5 puntos) (los datos son subjetivos, por cierto). La investigación de clientes demuestra que rara vez se utiliza (2 puntos). Por tanto, su valor de "dolor del usuario" es de 17 puntos. Este es un dato ambiguo, que puede modificarse o no. Por un lado, la inversión necesaria para solucionarlo puede no valer la pena, pero siempre que se comprenda el problema y no tenga puntos ciegos, ignorar el error probablemente sea el enfoque correcto.
Por otro lado, hay que compararlo con otros errores del sistema. Aquí aplicamos el efecto "Ventana rota": si hay demasiados errores de umbral medio en la aplicación, la calidad del producto (o al menos, la percepción de la calidad) se verá muy afectada. Cuando considere cada error en el sistema, también debe considerar otros errores (conocidos) en el sistema y usarlos para analizar y decidir qué errores deben corregirse y cuáles no vale la pena corregir.
De hecho, es muy malo tener errores en el software lanzado oficialmente, pero basándonos en nuestras herramientas y lenguajes de desarrollo existentes, todavía no hemos encontrado una solución más razonable.
Reponer:
Mientras escribo esto, creo que me falta un cuarto factor en la fórmula: la fecha de lanzamiento. Este factor también juega un papel clave en la decisión de corregir o no corregir un error a medida que se acerca la fecha de lanzamiento. Sin embargo, no estoy seguro de si es el cuarto factor, ni cuál es el umbral para la cantidad de "dolor del usuario" necesaria para corregir un error cuando se acerca el lanzamiento.