Cuando tenemos que probar un desarrollo, hay un porcentaje de defectos que resultan rechazados o acaban siendo eliminados por algún motivo. Habitualmente, estos motivos, suelen ser los siguientes:
- - Defectos que no pueden reproducirse de nuevo
- - Defectos duplicados, que han sido abiertos anteriormente
- - Defectos incorrectos o que no se deberían de haber abierto
Con estos tipos de defectos, podemos sacar una serie de métricas que medirán la efectividad de nuestro equipo y así poder tomar las decisiones oportunas para aprovechar mejor el tiempo y que la detección sea lo más adecuada y certera posible.
En relación a los defectos que no pueden reproducirse, podemos dividirlos en dos:
1. Los que son extremadamente complicados de reproducir porque son casuísticas muy particulares y complejas o que necesitan una serie de datos adecuados para que la interacción sea completa.
Este tipo de defectos, suelen suceder cuando estamos realizando pruebas exploratorias o varias pruebas continuadas y de repente, nos encontramos el error, pero no tenemos claro cual es la situación que lo ha generado. Por lo tanto, tenemos que retroceder y volver a ejecutar los pasos o entablar una relación con los parámetros o datos que hemos utilizado (ya sea lógica o no).
2. Otros defectos de este tipo son los que no se reproducen una segunda vez porque no existen. Esto, suele ocurrir cuando hay inestabilidad en el entorno, por un error humano o una malinterpretación de los requisitos, generando un caso de prueba inadecuado o que, simplemente, hay que eliminar porque no aplica.
Con este tipo de defectos, simplemente, lo que hay que hacer, es cerrarlos aportando la razón adecuada, ya sea como “rechazado” o “falso positivo”.
En el caso de los defectos duplicados, son aquellos que ya se dieron de alta anteriormente y ya no aplicarían, tomándose en cuenta el primero y aportando o enlazando el duplicado a este mismo.
También, tenemos que tener en cuenta que a veces, los problemas detectados son diferentes y no se deben de tomar como duplicados, aunque los pasos para reproducirlos sean exactamente los mismos. En este caso, se puede optar por unificar todos los criterios o tratarlos por separado.
Por último, si hablamos de defectos que no deberían de haberse abierto, suelen ocurrir cuando el comportamiento del producto no cumple con las expectativas que nos habíamos marcado o, incluso, que el entendimiento de la persona que prueba ha sido diferentes de lo que realiza la aplicación o no se entendieron correctamente los requisitos. Por lo tanto, este tipo de defectos no aplicarán y podrán cerrarse o tomarse en cuenta como posibles mejoras, si se determina más adelante.
Una vez que hemos puesto en contexto todos los tipos de defectos, debemos de saber como estos errores afectan a las personas que forman al equipo y como se invierte un tiempo muy valioso en darlo de alta, estudiarlo, informarlo y reproducirlo por la persona que quiera solucionarlo. Uno de los principales problemas que suelen ocurrir, independientemente del resto, es que estos defectos suelen causar “encontronazos” con las personas que trabajan en el proyecto por la posible “pérdida de tiempo” que causa el darlos de alta y verificarlos.
El total de este tipo de defectos, se puede contabilizar como una medida de ineficiencia del equipo y también puede dar “señales” del tipo de perfil que tienen las personas que prueban, detectando un mayor o menor grado de madurez y de experiencia y aportándonos datos sobre donde reforzar las zonas más “débiles”.
Una de las métricas más claras que pueden aportar este tipo de defectos, que son complicados de reproducir, es la meticulosidad de las personas y de como se añade toda la información adecuada para su correcta reproducción. Ya sean datos de acceso, de selección de formularios, usuarios, contraseñas o cualquier tipo de aporte factible para que las personas que solucionarán el error, puedan hacerlo de una manera eficaz y rápida.
Cuando se abren defectos incorrectos o que no aplican, podemos sacar la conclusión de que no se han comprendido o no se dominan los requisitos adecuadamente, ya sea por falta de tiempo o porque no se han realizado las preguntas adecuadas a las personas encargadas del producto y nos hemos quedado con dudas que hubieran solventado este tipo de situaciones. Otro tipo de problemáticas, pueden venir dadas al abrir un defecto sin haber realizado una búsqueda adecuada por si ya estaba dado de alta.
Hablando con diferentes personas que se dedican a probar, la sensación suele ser la misma, cuando nos rechazan un defecto, nos sentimos mal, incluso algunas de estas personas me comentan que se sienten dolidas o “insultadas”, como si se menospreciase su trabajo, pero muchas veces esto no es así, simplemente nos hemos equivocado y hay que reconocer nuestro error.
Unos pasos que se pueden realizar cuando nos ocurre esto, pueden ser los siguientes:
- - Volver a reprobar el defecto en el entorno de pruebas, por si hay algún problema anterior y ya está solucionado (quizá nos equivocamos al ejecutar algo).
- - Si el defecto está basado en los requisitos porque los hemos entendido mal, podemos tratar de que estos sean mejorados e intentar no cerrarlo hasta que no se modifique este o la frase para que no le vuelva a ocurrir a ninguna persona.
- - Si el defecto se rechaza por duplicado, debemos de relacionarlo con el que se queda abierto y cerrar el duplicado adecuadamente aportando una explicación coherente.
- - Si el defecto es del producto, pero viene a través de los requisitos, ya sea porque se considera un funcionamiento correcto algo que va a causar confusión a los clientes, habría que intentar cambiarlo porque se van a tener problemas posteriores, seguro.
Además de todo esto, tenemos que recapacitar y tener mucho más cuidado, invertir más tiempo en darlo de alta, explicarlo bien y dar todo detalle a los desarrolladores.
A nivel global, dentro de un equipo de pruebas, debemos de tratar de reducir los defectos rechazados, pero marcándose unos niveles adecuados y que no generen stress.
Un porcentaje bajo de defectos de este tipo, nos permitirá analizar que salió mal, que problemas se han tenido y en grandes rasgos, invertir un tiempo en mejorar nuestro trabajo. Esto hará que las personas que prueban, solo reporten defectos que tengan total seguridad.
De esta manera, perderemos el reporte de defectos en las que la usabilidad del producto no esté clara y no podremos mejorar el desarrollo ni reforzar esa virtud de una buena batería de pruebas. Al final, nos podríamos hacer la siguiente pregunta: ¿porqué reportar algo que va a ser rechazado?, ¿merece la pena buscar ese enfrentamiento? Dos preguntas que son erróneas y que debilitan las pruebas realizadas.
Las personas que nos dedicamos a realizar pruebas, debemos de ser contundentes, claras y el intentar reportar (con todo tipo de detalles, siempre que sea posible) cualquier comportamiento que nos parezca extraño o sospechoso, sin más. Salirnos de ese camino, bajo mi punto de vista, es un error. Prefiero que me digan que el defecto ha sido rechazado y me den una explicación razonable que no reportarlo y quedarme con la duda de si será un problema que luego genere un defecto en producción.
Para mi, un porcentaje de defectos rechazados de un 10% a un 15%, es más que adecuado dentro de un ciclo de pruebas y permitirá ajustarnos e ir bajando este porcentaje todo lo que podamos cuando todas las personas que engloban al equipo tengan la suficiente confianza, ya sea para reportar defectos seguros como para perder el miedo a tener alguno rechazado.
0 Comentarios