Diseñar mejores pruebas de software usando taxonomía de bugs

La taxonomía de bugs ayuda a los testers novatos a tomar puntos de referencia en sus pruebas y a los experimentados a evaluar el alcance total de sus pruebas.

Advertisements

Sumario: En testing, la taxonomía de bugs tiene que ver con definir categorías de funcionalidades y listar todos los posibles bugs en cada categoría. Esas listas pueden ser usadas por testers inexpertos como puntos de referencia, y para ayudar a testers experimentados para iniciar una lluvia de ideas y evaluar la totalidad de un caso de prueba. Usar una taxonomía de bugs existente puede ser provechoso, pero crear una por tu cuenta es aún mejor.

 

Como parte del equipo de investigación y desarrollo, mi equipo desarrolla nuevos productos. R&D tiene un halo de innovación y descubrimiento, pero como estoy seguro que cualquiera que trabaje en R&D sabe que, parte del trabajo donde hacemos cosas nuevas, es bastante escaso. Aún y cuando desarrollamos algo nuevo, una vez que el trabajo inicia, la mayoría de las veces es rehacer cosas que ya estaban hechas.

Algunos ejemplos: Desarrollas una nueva maravilla embebida que resuelve el hambre en el mundo. El producto final debe ser actualizable para que en su versión 2.0 pueda resolver el problema de la disminución de la capa de ozono, así que también se necesitaría una funcionalidad para actualizar el firmware; ¿Qué no habíamos hecho esto antes? ¡Por supuesto que lo hicimos! Cualquier sistema embebido lo tiene, así que nuevamente nos enfrentamos a los mismos retos y, por añadidura, a los mismos bugs. Es la misma situación que instalar un programa, un módulo de base de datos, etc. Si no fue nuestro equipo el desarrollo algo así antes, entonces fue otro equipo haciendo algo similar y hecho sus respectivos casos de prueba. Así que llegamos al mismo punto, reinventando la rueda una vez más.

Es redundante e ineficiente. Debe haber una manera de converger el conocimiento acumulado entre proyectos, entre ingenieros veteranos y novatos, entre los equipos que hay dentro de tu organización, aún entre distintas empresas.

 

Iniciando con la taxonomía de bugs

Una manera de compartir conocimiento sobre testing, es a través de la taxonomía de bugs. Como el término sugiere, la idea general es definir las funcionalidades por categoría y enlistar los posibles bugs en cada categoría.

Estas listas pueden ser usadas para ayudar a los testers experimentados dandoles ideas sobre que probar, y para darle a los inexpertos una lista de las cosas que deben ser probadas y darles a conocer aspectos del producto que tal vez no habían visto que debían de probar, como aspectos específicos de desempeño o usabilidad, y evaluar la totalidad de un caso de prueba seleccionando los ítems de la lista de taxonomía y revisando si ese aspecto ya fue cubierto.

 

Por ejemplo, usando un extracto del libro “Testing computer software” de Cem Kaner, Hung Q. Nguyen y Jack Falk; aquí una lista de aspectos a probar:

 

Desempeño:

  • Baja optimización
  • Pobre respuesta de echo
  • Pobre respuesta de comunicación
  • Ausencia de funcionalidad de Tecleo Anticipado
  • Falta de alertas si una operación tomará mucho tiempo en ejecutarse
  • Falta de reportes de progreso
  • Problemas de tiempo excedido

 

Algunos de esos ítems son funcionalidades más o menos obvias a probar, y otras deberían detonar ideas para pruebas que quizá estén faltando.

 

Por ejemplo, el bug “Falta de alertas si una operación tomará mucho tiempo en ejecutarse”, debería traer a discusión varias validaciones: ¿Hay funciones en el producto que tomen mucho tiempo en ejecutarse?, ¿Bajo qué condiciones?, ¿Habrá registro de avance?, ¿Ese registro es preciso?; Además que debería plantear preguntas sobre funcionalidades redundantes: ¿Daremos soporte al registro de progreso para cosas que tomen poco tiempo?, si lo hacemos ¿Saltará una ventana de avance en la pantalla y desaparecerá en segundos?, de ser así, el usuario podría confundirse por lo que acaba de pasar.

 

Algo más que es interesante de resaltar es que algunas de estas ideas ya son obsoletas. Por ejemplo, la funcionalidad de tecleo anticipado era un requerimiento para aplicaciones de la primer generación de computadoras, cuando una persona podía teclear tan rápido que sobrepasaba la capacidad del sistema para mostrar caracteres en pantalla. Con el tiempo, y el aumento en las capacidades de nuestros sistemas y equipos, ésto dejó de ser un problema.

 

Crear tu propia taxonomía de bugs

Aún y cuando estoy familiarizado con cierto número de listas de taxonomías, realmente nunca he usado ninguna. Lo he intentado, pero debo admitir que no lo he intentado mucho. Por un lado, estoy seguro que las listas de taxonomía de bugs funcionan, pero por otro, usarlas puede ser un inconveniente.

La forma de pensar y el proceso de análisis que siguió la persona que haya escrito la lista, no necesariamente puede coincidir con los tuyos. De esta manera, muchos ítems que esperas encontrar en cierta categoría, terminan en otra que no te hace sentido. Tomemos por ejemplo la lista pasada, en esa lista pusieron “Falta de reportes de progreso” dentro la categoría de “Desempeño”, yo la habría listado dentro “Experiencia de usuario”; otro punto a resaltar es el lenguaje, que en estas listas debería ser breve y conciso, a veces puede ser complicado de entender.

Para poder beneficiarse de una lista de taxonomía de bugs, para un aspecto específico del producto, es necesario leer muchas partes de la lista, filtrar resultados que puedan ser irrelevantes al producto que estás por probar, además que habrá que aceptar que hay muchas cosas que pudieras no entender debido a tu experiencia.

Así que, tenemos una buena idea, pero fue implementada de una manera que resulta ser muy complicada de usar; ¿deberíamos descartarla?

Claro que no, una opción que he aprendido por experiencia, es crear tus propias listas con cosas que he encontrado en repetidas ocasiones; gracias a que tu escribiste esa lista, su organización te hará sentido y el lenguaje te será claro; de esta manera te familiarizaras con su uso en los proyectos en que trabajes.

 

Tengo una lista similar, creada hace mucho tiempo y que enlista aspectos de testing de APIs; la reviso continuamente, y en cada ocasión que descubro una manera de aproximárme a las pruebas de APIs, lo agrego a esa lista. No compartiré esta lista por lo descrito anteriormente: Está escrita de una manera que yo entiendo, pero no sería sencillo de entender para otras personas; cuando la he compartido, lo he hecho estando a lado de las personas que la usarán, explicando cada aspecto descrito y resolviendo sus dudas para asegurarme que la entienden. Para mi, esta lista es muy valiosa y la he usado en innumerables ocasiones; también sé que hay otras listas creadas por colegas de mi empresa, que cubren sus propias necesidades.

Toda esta evidencia anecdótica no califica, de ninguna manera, como un estudio riguroso; sin embargo todo se enfoca en ejemplificar que una lista de taxonomía de defectos funciona en las actividades del día a día, y funciona mucho mejor si esa lista la creaste tú.

Puedes crear una de estas listas recolectando detalles con el paso del tiempo; puedes crearla para ti o para un grupo, si decides hacerla para un grupo, te recomiendo no sólo invitar a participar a los testers, sino también a los desarrolladores y gerentes a que contribuyan con ideas; también puedes respirar profundamente, buscar en listas publicadas y encontrar ideas que estén relacionadas con tu situación, aún y cuando no encuentres información directamente relacionada, es muy probable que te inspiren de distintas maneras.

 

Eso es un punto de inicio, también puedes apoyarte en el uso de herramientas de mapeos mentales para crear tus listas.

 

Michael Stahl

https://www.stickyminds.com/article/using-bug-taxonomy-design-better-software-tests