¿Qué es realmente el happy path testing?

Cuando decimos “Probemos el happy path”, ¿realmente sabemos que debemos probar?

Advertisements

Dependiendo de nuestra posición y entendimiento del proyecto y/o del negocio, el “Happy path” requiere de distintos elementos:

“Happy path”, para el usuario…

  • Entiende perfectamente la funcionalidad
  • Está familiarizado perfectamente con la interfaz
  • Trabaja de la manera en que la aplicación fue diseñada
  • Recuerda perfectamente todo
  • Entiende perfectamente los mensajes enviados por la aplicación (aún y cuando no haya ninguno)
  • Nunca comete errores
  • Nunca se distrae
  • Sólo ingresa información que probó estar correcta

…además “Happy path” del producto…

  • Es usado en una infraestructura y equipo en particular, donde está garantizado que funcionaría de un modo particular (Probado que funcionaría)
  • No tiene ninguna variación o fluctuación
  • Puede entenderse de un sólo modo, un modo perfecto

…creado por equipo “happy path”…

  • Entiende perfectamente el requerimiento de negocio y su propósito
  • Diseñado e implementado de una sola manera, la manera correcta

…Todo eso equivale a un caso sobresaliente
El punto es, hasta que no hayamos aprendido lo suficiente sobre los usuarios, el producto y el ambiente en que se le trabajara, no tendremos idea de cuál será el patrón principal de su uso y cuales serán las funcionalidades o características más importantes a probar. Veamos unos ejemplos

Historia #1
El instructor apunta al botón Guardar y dice “Den clic en Guardar”, veinte usuarios dan clic en el botón salvar desde sus laptops. Veinte usuarios reciben un error de timeout y se bloquean sus sesiones. El ambiente en el entrenamiento de pre-venta se vuelve pesado.

Unas pruebas de carga que incluyeran llamadas simultaneas de HTTP de veinte usuarios a la vez hubiera sido un buen escenario de happy path en este contexto, aún y cuando producto pudiera soportar más de cien usuarios trabajando a la vez(pero no simultaneamente).

 

Historia #2
En un sistema que graba documentos legales -Decisiones legales- cada letra, caracter, signo de puntuación y espacios extra debe ser grabado como en el original, o si no el documento puede ser modificado en la corte. Para horror del dueño del producto, descubieron que en algunos registros electrónicos, algunos datos no se guardaban. Después de una extensa y costosa investigación, algunos casos fueron aislados, lo que resultó fue lo siguiente: Algunas veces “menos que” se abreviava como “<“, desafortunadamente el código interpretaba el “<” como tags de xml abiertos pero no cerrados, truncando de inmediato toda esa sección.

Testing para caracteres especiales e inyecciones de html hubieran sido un escenario para este happy path, aún y cuando los usuarios de este producto(no accesible a todo público) fueran agentes empleados legales experimentados que nunca se esperaría que hicieran mal uso del producto.

 

Historia #3
Un esposo y una esposa ordenan una chequera. Sus nombres deberían aparecer impresos en los cheques como: “Mr. & Mrs. Smith”, sin embargo reciben sus cheques viéndose así:

image1

Pruebas de, por lo menos, algunos caracteres especiales en HTML y PDF hubieran sido un escenario de pruebas en este contexto de “Happy Path”, porque el uso de “&” es común hoy en día, pero es automáticamente reemplazado por un “&amp” a menos que sea manejado correctamente.

 

Historia #4
Una conversión de datos de un coma flotante de 64 bits a valor entero de 16 bits causa un overflow y una excepción de hardware; el resultado es un cohete espacial que se desestabiliza y explota.

El problema había surgido al convertir un número almacenado en algo que los programadores llaman ‘coma flotante de 64 bits’ en ‘entero de 16 bits’.

Los números de ‘coma flotante’ son otra forma de decir ‘números decimales’. Y lo que sucedió fue algo así como si al convertir el valor ‘32790,789’ en un número entero en vez de ‘32790’ el resultado fuera ‘0’, ‘-500’ o un error similar (en los números enteros de 16 bits el valor máximo es 32767).

Curiosamente esa parte del código sólo se usaba durante la preparación para el despegue; una vez en marcha no tenía utilidad. Sin embargo, como otro de esos encadenamientos de causas que suelen provocar estos catastróficos fallos ese código continuaba funcionando durante 40 segundos tras el despegue.

¿Por qué? El código provenía de los anteriores cohetes Ariane 4 donde sí se usaba, así que se mantuvo tal cual. Pero nadie pudo imaginar que ese código pudiera nunca contener otros valores tan diferentes, que fueran a provocar un ‘error de excepción de software’ ni que eso en combinación con otros sistemas de la nave provocara que los datos de vuelo fueran incorrectos y se convirtieran en órdenes capaces de modificar la trayectoria del cohete, llegando a destrozarlo en pleno vuelo.

El resultado del incidente fueron muchas lecciones aprendidas, unos 500 millones de dólares en carga perdidos y meses de desarrollo desaprovechados… a cambio de unos curiosos y carísimos ‘fuegos artificiales’.

Con esto volvemos a redefinir que es un testing de happy path y mejor pensemos en readecuar el proceso de pruebas en pos de descubrir los problemas antes que ocurran tan catastróficamente en producción.

 

¿Conclusiones?
Las metáforas pueden ser útiles, pero también podrían conducir a la confusión, falta de comunicación, o a una falacia de reificación. Muchas personas podrían, y usarán distintas terminologías, y no es trabajo de los testers hacer de policía del idioma.

Cuando se trata del “Happy path”, es labor del tester averiguar y explorar que es lo que el happy path significa en el contexto del producto y sus usuarios.

Los verdaderos usuarios tendrán un concepto distinto al tuyo de happy path.

Por Albert Gareev

Mob testing: Una introducción

Mob testing se trata de que todo el equipo de testing trabaje en una sola computadora, y que cada uno colabore en un esfuerzo conjunto.

Mob testing se trata de que todo el equipo de testing trabaje en una sola computadora, y que cada uno colabore en un esfuerzo conjunto.
Mobbing (Mob Programming o Mob Testing) inicia con la idea de un grupo de personas trabajando en una sola computadora, forzando a que haya un solo flujo. Por turnos, cada miembro del equipo se sienta frente a la computadora y sigue el flujo hasta que la tarea sea terminada, esta técnica hace que cada miembro trabaje en conjunto sobre un sólo estilo de navegación dentro de la aplicación.

Esto significa que quien sea que esté en el teclado(el timonel) no tendrá permitido decidir que hará con el teclado, las instrucciones vendrán del resto del equipo(los navegantes), quienes guiarán con el nivel más alto posible de abstracción. El objetivo no es que cada uno de su mejor opinión, sino entender mejor como el equipo está avanzando.

 

Nivel de abstracción, ¿Qué es eso?

Para hablar de manera eficaz mientras se navega, resulta provechoso pensar en los tres niveles abstracción:

 

  • Intención – Es el primer paso, donde explicamos lo que queremos
  • Locación – Se usa si la intención no fue suficiente como para llevar a que la acción realizada no resultara como deseamos. Por ejemplo, “Usa la búsqueda mediante un atajo desde el teclado, en vez del menú”
  • Detalles – Para explicaciones de bajo nivel de lo que queremos cuando hemos fallado en guiar las acciones en la dirección que queremos. Por ejemplo: “Teclea Ctrl + F”

 

Ejemplos de los tres niveles de abstracción

En conjunto, el grupo está intentando llevar a cabo una tarea, por ejemplo, probar la funcionalidad de búsqueda. Imagina que estás sentado frente al teclado y te han pedido que abras la aplicación para que el grupo pueda probar la funcionalidad; si eres experto en esta aplicación, probablemente podras iniciar sin mayores detalles. Este es un ejemplo de “Intención”, pero si no es suficiente, entonces habrá que recurrir a otros niveles de abstracción.

Usar el atajo del teclado en vez del menú para llegar a la funcionalidad de búsqueda es un ejemplo de “Locación”, de donde iniciar. El navegante está en control y se asegura que el trabajo se realice de la manera en que ha tenido intención, eso gracias a la información adicional que brindó al timonel.

Si el timonel nunca ha usado la aplicación pero los navegantes sí, entonces son ellos los que guiarán el curso de la sesión dando todos los detalles necesarios. Así tendríamos el tercer nivel de abstracción, “Detalles”.

El detalle de estos niveles son para tener un control del trabajo hecho con los navegantes, mientras apoyan las acciones del timonel. Cuando las palabras dichas por los navegantes hacen que las pruebas avancen de la manera en que ellos quieren, los niveles más bajos de abstracción no son necesarios.

 

Usa las palabras y no toques el teclado

Estamos acostumbrados a trasladar nuestras ideas a las acciones a través de nuestras manos, usando el teclado por ejemplo. Bajo esta practica, se remueve la conexión física y nos enfocamos en las palabras.

Cuando estas sesiones inician, es complicado encontrar las palabras adecuadas para decir. Algunos podrán no saber como decirle a las cosas que tienen en su IDE, así que buscamos las palabras que indiquen claramente que es los que queremos lograr; de igual manera, hay algunos que no están acostumbrados a escuchar pacientemente las instrucciones que alguien le intenta comunicar. Durante las sesiones de mobbing, el timonel podrá responder y sugerir nuevos métodos para avanzar, pero serán los navegantes los que tendrán el poder de decidir.

Si el timonel empieza a trabajar por su cuenta, se creará una brecha de entendimiento para varias personas en el grupo, y los navegantes se volverán revisores que intentarán interpretar las acciones tomadas por el timonel. Es importante que todos se mantengan conectados, y compartan la misma idea sobre la tarea; así mismo, la rotación de roles en lapsos de algunos minutos, promueve que todos compartan la misma idea.

 

Manos a la obra.

El grupo debe iniciar la sesión con una tarea clara. Cualquier actividad que esta sea, el primer desafío casi siempre será la comunicación.

 

Dos reglas para la comunicación en las sesiones Mob

¿Qué sucede si el grupo no está de acuerdo en como hacer algo? ¿Qué sucede si cada uno tiene una idea distinta de como realizar una tarea en particular?

 

  1. La regla “Si, y…”: El grupo trabaja en una tarea en conjunto. Cuando algo inicia, tiene que ser terminado, pero podemos agregarle acciones.

 

  1. La regla “Haz ambas…”: Si hay dos maneras de hacer algo, escuchalas, y haz ambas; empieza con la que menos te agrade, o escogela al azar; la meta es que cada opinión sea escuchada.

Cada una de estas reglas, crea acciones a realizar. ¡Dejate llevar! A medida que el grupo avanza, las cosas empezarán a trabajar de maneras que nadie pudo prever. Las acciones planeadas todavía no ocurren. Entrega el primer incremento, y hazlo lo suficientemente pequeño para que los fallos sean una opción y una oportunidad para aprender.

 

Re-examina para aprender

Independientemente de como te sientas durante y después de una sesión de mobbing, ésta deberá terminar con una retrospectiva. Habla con los miembros del grupo acerca de las observaciones sobre como trabajo el grupo, acerca de las diferentes cosas en que trabajaron y de las cosas que aprendió cada participante. No debes proyectar tus percepciones hacia las demás, sino asegurarte que cada experiencia sea escuchada, aprende de ellas y usa esa experiencia para tus futuras sesiones.

 

Obten lo mejor de cada uno en el trabajo realizado

El mecanismo de mobbing es interesante, a fin de obtener las ideas de las personas en el momento correcto, se puede sentir que otras personas no están participando mientras que otras contribuyen en la dinámica. En lugar de pensar que los miembros no vocales no están contribuyendo, deberíamos pensar en que en esos momentos están aprendiendo. Un miembro debe continuar en la sesión  siempre que esté aprendiendo o contribuyendo.

Sin embargo, siempre será necesario tener en cuenta la amabilidad, consideración y respeto. Todos los miembros de la sesión deben poder escuchar las contribuciones de todos los demás. Todas las contribuciones hechas por los miembros deben ser respetadas, sin importar si no fue provechosa en el momento en que fue hecha.

Todo lo que necesitas es un grupo de personas que compartan una computadora, todos viendo a la pantalla a la vez que trabajan en una tarea compartida. Las posibilidades de aprender de manera fortuita son interminables.

Por Maaret Pyhäjärvi

 

4 estrategias para crear un proceso de QA estructurado

El rol de tester está evolucionando junto con la industria de la tecnología y su adhesión a las metodologías agil. Esta transición abre oportunidades inexploradas, emocionantes y desafiantes para todo tester.

El rol de tester está evolucionando junto con la industria de la tecnología y su adhesión a las metodologías agil. Esta transición abre oportunidades inexploradas, emocionantes y desafiantes para todo tester.

 

Las viejas formas: Sólo encontrar defectos

En mis primeros años como tester poco me preocupaba por el pensamiento crítico. Cada mañana el equipo de testing nos daba una lista de aplicaciones a revisar, el recurso asignado instalaba las aplicaciones e intentaba romper su funcionalidad.

Nuestros análisis de desempeño eran simples: ¡Entre más bugs encontráramos, más inteligentes eramos! Sin análisis, sin estrategia, sin motivación. En nuestros descansos las discusiones giraban en torno al número de bugs encontrados, en lugar de discutir la calidad de estos bugs.

Eso me puso a pensar, ¿Qué valor estamos agregando? ¿Deberíamos probar sólo para encontrar defectos? Tenía muchas preguntas sin respuesta.

 

Desarrollando un proceso de QA

Mi siguiente empleo lo cambió todo. Como parte de las pruebas de una funcionalidad, el equipo de QA también debuggeaba, analizaba el track trace, y proveía la causa raíz del error cuando reportaba a los desarrolladores. Fue vigorizante ver a cada uno de los miembros colaborar como un equipo con un sólo propósito.

Me di cuenta que las tareas de un tester no eran actividades individuales para romper la aplicación, pero más las de un miembro de un equipo contribuyendo al esfuerzo común. A medida que los testers iban cambiando de equipos, empezamos a priorizar la mejora continua de la automatización y el conocimiento profundo de cada componente. Desarrollé una perspectiva totalmente diferente sobre QA, además de un gran respeto por todo el valor que proporcionaba este rol.

Cuando cambié de posición, me emparejaron con un arquitecto de QA. Nunca imaginé que esa mentoría tendría un impacto tan grande y duradero en mi. Me di cuenta de la importancia dar un seguimiento estructurado a QA; con la ayuda de este arquitecto, afiné y perfeccioné cuatro estrategias para mejorar el proceso de QA.

 

  1. Revisa los documentos de diseño y arquitectura

Siempre será una buena idea tener tanto conocimiento como se pueda sobre el producto que está siendo probado, si los documentos de arquitectura y diseño están disponibles para revisarse, dales una leída. Te sorprenderás de cuanto puedes entender del producto sabiendo su arquitectura, los componentes integrados, y del flujo de información que del solo hecho de probar. Toma notas y traza diagramas de como funcionan tus pruebas en paralelo y de cómo interactúa el sistema.

 

  1. Investiga defectos pasados

El pasado informa al presente. Es importante conocer las áreas riesgosas y las funcionalidades más susceptibles a fallar en cada modificación. Ese tipo de información puede provenir de la historia de los defectos.

Lleva a cabo una investigación en tu gestor de defectos y analiza los defectos que han sido reportados anteriormente. Cualquier patrón predecible que provenga de este análisis ayudará a automatizar esas áreas, también incluye los defectos que son reportados por los usuarios o clientes. Este ejercicio te ayudará a tomar decisiones sobre la estrategia a seguir en la mayoría de los releases.

 

  1. Triangula los defectos

QA encuentra un defecto y se reporta, pero el trabajo no termina ahí, hay que ir más allá y hacer algunas otras preguntas importantes. ¿Hay algo más que pudiste haber hecho?, ¿Sabes porqué ocurrió ese defecto?, ¿Qué lo causó?, y ¿Qué cambio en el código pudo haber causado el problema?

Ésto no es trabajo exclusivo de los desarrolladores. Tienes acceso al log, a los releases y al código, así que se puede excavar por información que ayude a resolver esos problemas. Dependiendo en que tan técnico seas, puedes profundizar tanto como puedas. Pero si estás en un alto nivel, mira en las excepciones en el log. ¿Hay un null pointer?, ¿Tiene que ver especificamente con tus datos o con alguna secuencia de pasos?

Delimita el problema y empieza una conversación con el equipo de desarrollo, sabrán apreciar la información detallada y la investigación.

 

  1. Ve más allá del defecto reportado

No te enfoques sólo en las pruebas de funcionalidad. Piensa también en como el back-end y el front-end interactúan con tu aplicación.

Por ejemplo, mientras revisas el log de pruebas, podrás darte cuenta que tal vez la aplicación esté funcionando correctamente, algunos errores están ocurriendo en el back-end. Aquí podrás preguntarte, ¿Son los logs lo suficientemente detallados?, ¿Se están manejando correctamente las excepciones?. Cuando pruebas aplicaciones web, abre las herramientas de desarrollador en el navegador y monitorea los componentes de red, ¿las respuestas están tomando más tiempo del debido? ¿Hay algún request que no está siendo llamado cuando se accede a la aplicación?

Todas esas preguntas permitirán al tester a ir más allá de lo que tiene asignado. También motivará discusiones con el dueño del producto y los desarrolladores al encontrar escenarios que no habían sido pensados.

Es vital tener una mentalidad ágil al momento de buscar y reparar discrepancias en el producto. Una enseñanza clave en testing es ser proactivo. Los bugs que descubres de esta manera pueden volverse historias técnicas, que de no haberse prevenido hubieran pasado desapercibidas y volverse en un error muy serio mucho más adelante.

 

Vuélvete el propietario de la calidad

Ser un tester de software ya no se trata sólo de encontrar defectos y de romper la aplicación; ahora se trata de la mejora continua, de definir una estrategia de pruebas, y de ir un paso más allá para mejorar la calidad.  Seguir un proceso estructurado y consistente de QA te ayudará a adquirir más conocimiento del producto que estás probando, a hacer las preguntas que de otra forma no te hubieras hecho, y al final, volverte en el propietario verdadero de calidad.

 

Por Praveena Ramakrishnan

 

 

 

En metodologías Ágil, ¿Quiénes son los tres amigos?

En metodologías ágil, esta técnica ayuda a encausar el incremento de producto desde 3 perspectivas distintas.

Los tres amigos se refieren a las tres perspectivas principales al examinar el incremento de producto antes, durante y después del desarrollo. Estas perspectivas son:

 

  • Línea de negocio – ¿Qué problema intentamos resolver?
  • Desarrollo – ¿Cómo vamos a crear la solución que resuelva ese problema?
  • Testing – Si hacemos ésto, ¿Qué es lo que pueda ocurrir?

 

Las personas responsables de tener estas perspectivas deben de colaborar en definir las acciones a realizar, y acordar cuando es que estas acciones estarán hechas correctamente. El resultado final de esta colaboración es una descripción clara del incremento de producto, generalmente en forma de ejemplos, y termina siendo un entendimiento compartido con el resto del equipo.

 

También resulta una buena práctica que estas personas también revisen los incrementos del producto que ya haya sido implementado, para asegurar que es lo correcto desde estas perspectivas distintas.

 

El concepto de los tres amigos busca balancear la colaboración entre personas con distintas perspectivas e involucrar al equipo entero a la discusión de los detalles en cada incremento de trabajo.

 

Beneficios esperados:

  • Construir un entendimiento compartido sobre los incrementos de producto
  • Identifica confusiones pronto y permite que las lecciones aprendidas ocurran en una etapa temprana del incremento de producto
  • Limita el número de personas que deberían de involucrarse en las discusiones de cualquier incremento de producto

 

Obstaculos comunes:

  • Limitar estas reuniones a sólo tres personas; si hay cualquier otro tomador de decisiones que pueda enriquecer la visión de un incremento de producto específico, es necesario incluirlo en la conversación
  • Terminar de incluir a todo el equipo en estas reuniones; la idea de esta practica es incluir sólo las perspectivas necesarias y mantener el grupo lo más reducido posible
  • Las reuniones de los tres amigos se vuelven juntas programadas y empiezan a manejarse como cualquier otra ceremonia, en lugar de servir de guía basada en las perspectivas que deberían ser incluidas en la conversación de un incremento de producto en particular

 

Kent McDonald

 

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.

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