Somos desarrolladores de software y nos fascina esa sensación de crear un producto nuevo, es casi como la sensación de tener un hijo o más aún, crear un universo nuevo. Sin embargo, algo que usualmente resulta frustrante, especialmente cuando se cuenta con un equipo de testers o probadores dedicados tiempo completo a romper el código, es que encuentran demasiados, pero demasiados, errores.
Puede estar seguro de que todo desarrollador quiere ser el primero en conocer cualquier bug o error que resulte inconveniente para los usuarios, pero una pregunta esencial es ¿cómo distinguir entre los errores que los usuarios siempre encontrarán y los que probablemente nunca verán?
El primer paso es tomar la lista de errores de los testers o probadores y tener una reunión de triaje (triage en inglés) :
“El término "triaje" se tomó prestado del triaje médico donde un médico o enfermera tiene que priorizar la atención para un gran grupo de personas heridas. El trabajo principal de un equipo de triaje de bugs o errores de software es decidir qué errores deben corregirse (o, a la inversa, qué errores estamos dispuestos a liberar).
[Hay] cuatro preguntas que deben responderse durante el triage para decidir si un error se debe corregir o no:
- Gravedad : cuando ocurre este error, ¿qué tan negativo es el impacto?
- Frecuencia : ¿con qué frecuencia ocurre este error o bug?
- Costo : ¿cuánto esfuerzo se requeriría para solucionar este bug?
- Riesgo : ¿Cuál es el riesgo de corregir este error?”
En Pensemos S.A. hemos adicionado un paso cero que precede a cualquier evaluación, pues hay ocasiones en que se clasifica algo como error cuando en realidad es el comportamiento esperado:
- Validez: ¿Es realmente un error?
El triaje no es exactamente una actividad que nos haga sentir cómodos o que sea el mejor momento de nuestra vida. Pero es necesario hacerlo, porque siempre se tienen más bugs o errores que tiempo y capacidad para desarrollar. Nadie, y tomamos el riesgo de generalizar, tiene el lujo de arreglar todos los errores en su software.
Como lo menciona Jeff Atwood, uno de los fundadores de StackOverflow y StackExchange, Los testers o probadores producen dos tipos de errores:
- Un pequeño subconjunto de errores muy serios sobre los cuáles todo el equipo puede acordar de inmediato si se deben resolver. Estos son la fascinación de cualquier desarrollador de software.
- Todo lo demás. Una extensa y gris llanura de pseudo-bugs en la que nadie puede estar realmente de acuerdo. ¿Es un inconveniente para el usuario? ¿Los usuarios realmente harían las cosas de esta manera? ¿Alguna vez un usuario se encontraría con esto? ¿Nos importa?
Los errores sobre los cuáles todo el equipo está de acuerdo constituyen una clara victoria. Este conjunto de errores constituyen entre el 10% y el 20%. Los demás presentan un problema grave: los probadores no son usuarios reales. No sería descabellado darle un peso diez veces mayor a un error de un cliente que a un bug informado por un probador o tester.
La fuente del error es solo un factor a considerar. El triaje de errores no es una ciencia. Es algo altamente subjetivo y totalmente dependiente de la manera en que se aplique. En el libro Bugs Are a Business Decision, Jan Goyvaerts describe cómo puede diferenciarse el triaje para productos en cada extremo del espectro:
“En julio pasado volé a Denver para asistir a la Conferencia de la industria de Shareware. Volé de Taipei a Los Ángeles en un Boeing 747 operado por China Airlines. Este avión tiene dos sistemas principales de software a bordo: el software de aviónica (computadora de vuelo) y el sistema de entretenimiento en vuelo. Estos dos sistemas son completamente independientes unos de otros, desarrollados por diferentes compañías, con diferentes estándares.
El software de aviónica es el software que vuela el avión. No, los pilotos no vuelan el avión, la computadora de vuelo sí. ¿Cuántos errores tolerarías en el software de aviónica? ¿Cuántos crees que Boeing dejó sin arreglar? ¿Cuántas personas han muerto por errores de software en aviones modernos? Cero. Una computadora de vuelo defectuosa haría fallar inmediatamente a todos los 747 en todo el mundo. Boeing no sería capaz de recuperarse.
El sistema de entretenimiento a bordo es una historia completamente diferente. No es esencial para el avión. Solo sirve para que los pasajeros olviden cuán incómodos son en realidad esos asientos económicos. Si el sistema de entretenimiento se descompone, el costo es mínimo. Los pasajeros ya se han quedado sin dinero, y la mayoría elegirá su próximo vuelo según el precio y el calendario, en lugar de las películas que se muestran en esas pantallas diminutas, si las hay. En realidad, estaba bastante satisfecho con el sistema de China Airlines, que ofrecía a los pasajeros económicos pantallas individuales y una selección de una docena de películas a pedido (es decir, cada pasajero puede comenzar a ver cualquier película en cualquier momento, e incluso pausar y rebobinar). Solamente, hasta que el sistema comenzó a funcionar mal. Se bloqueó algunas veces y la película de todos se detuvo durante varios minutos. En una ocasión, la tripulación tuvo que reiniciar todo. Ese cómico pingüino Linux se burló de mí durante varios minutos mientras pasaban los mensajes de arranque. X11 mostró su cursor en forma de X justo en el medio de la pantalla, incluso más. A juzgar por la actitud de la tripulación al respecto, el reinicio parecía algo que forma parte de su entrenamiento.”
Los errores también tienen un impacto económico para solucionarlos. En el libro My Life as a Code Economist, Eric Sink describe todas las decisiones que se toman para determinar si un error se soluciona o no en su empresa:
“¿Acaso no es cierto que todos comenzamos con la creencia de que el software siempre mejora a medida que trabajamos en él? El solo hecho de que necesitemos pruebas de regresión es de alguna manera una evidencia de que algo está mal en el mundo. Después de todo, no es como si alguien en nuestro equipo estuviera creando nuevos errores intencionalmente. Estamos tratando de asegurarnos de que nuestro producto mejore cada día, y aún así, en algún lugar entre 3.1.2 y 3.1.3, lo empeoramos."
Pero así son las cosas. Cada cambio de código es un riesgo. Un ciclo de desarrollo que no reconoce esto se mantendrá indefinidamente y nunca creará un producto entregable. En algún momento, si el producto realmente va a converger hacia un lanzamiento, debe comenzar a decidirse qué errores no serán resueltos.
Para decirlo de otra manera, piense en lo que quiere decirse a sí mismo cuando se vea en el espejo justo después de que se haya lanzado su producto. Las personas del grupo 2 quieren mirarse en el espejo y decir esto:
"Nuestra base de datos de errores tiene cero elementos abiertos. No diferimos un solo error. Los solucionamos todos. Después de cada corrección de error, volvimos a probar el producto completo, con una cobertura de código del 100%. Nuestro producto es perfecto, absolutamente perfecto y superará cualquier crítica que sea ".
La persona del grupo 1 quiere mirar al espejo y decir esto:
"Nuestra base de datos de errores tiene muchos elementos abiertos. Hemos revisado cuidadosamente cada uno de ellos y consideramos que cada uno es aceptable. En otras palabras, la mayoría de ellos probablemente ni siquiera deberían llamarse errores. No nos avergüenza esta lista de bugs abiertos. Por el contrario, obtenemos confianza de esta lista porque estamos liberando un producto con un nivel de calidad que es bien conocido. No habrá sorpresas, ni errores sorpresa. Admitimos que nuestro producto sería mucho mejor si todos estos errores fueran "arreglados", pero corregirlos implicaría el riesgo de introducir nuevos errores. En esencia, estaríamos intercambiando estos errores que consideramos aceptables por la posibilidad de errores recién introducidos que podrían ser peores".
No estoy hablando de enviar productos de dudosa procedencia. No estoy sugiriendo que nadie libere productos de baja calidad. Estoy sugiriendo que las decisiones sobre la calidad del software pueden ser difíciles y sutiles, y debemos ser realmente inteligentes sobre cómo tomar esas decisiones. Algunas veces un "error" no debería ser reparado.”
Cómo concluye Atwood, la priorización de errores se trata de una sola una cosa: mejorar la vida de los usuarios. Y la mejor manera de hacerlo es basar las decisiones de clasificación en los datos del uso real, a través de trazas de excepción, comentarios de los usuarios y pruebas beta. De lo contrario, el triaje es solo un grupo de desarrolladores y probadores en una sala, tratando de adivinar lo que los usuarios podrían hacer.
Pensemos S.A. es una empresa Colombiana creadora del software Balanced Scorecard, para seguimiento de la gestión y ejecución estratégica, Suite Visión Empresarial. En Pensemos tenemos claro que nuestra capacidad para exceder las expectativas de nuestros clientes es directamente proporcional con nuestra capacidad para atraer y retener personas excepcionalmente talentosas, por ello nos tomamos en serio la labor de seleccionar cada persona de nuestro equipo. Si desea tener más información sobre nuestros productos, no dude en contactarnos y si está interesado en trabajar con nosotros puede enviarnos su hoja de vida.
