Si eres desarrollador y haz trabajado con áreas de aseguramiento de la calidad del software (SQA), seguramente en más de una ocasión te han asignado bugs que no lo son. Recordemos que no todos los defectos que levanta el equipo de SQA aplican, también tenemos errores y una buena justificación de esto nos puede ayudar a aclarar la confusión. En este artículo te presento cinco razones justificables que puedes utilizar para rechazar defectos de manera correcta.

Colegas que aseguran la calidad del software, este artículo también les puede servir para evitar este tipo de errores, recuerden que un bug rechazado es un esfuerzo mal invertido (¿Cuánto tiempo te llevó documentarlo?), antes de levantar un defecto debes de estar muy seguro de que este en realidad aplica.

Razón 1: El bug debe ser 100% reproducible

Para que un desarrollador logre depurar un defecto, se debe conocer la secuencia de pasos con los cuales se origina. Si un defecto ocurre en “ocasiones triviales“, el desarrollador no podrá ir a la raíz del problema y atacarlo. Ejemplo: pasó un avión de la NASA sobre el edificio generando interferencia electromagnética y dañó la transmisión de paquetes de datos en la aplicación, ¿Le pedimos a la NASA que vuelva a enviar otro avión por la misma ruta? Además, ¿Cada cuando nos afectan los aviones de la NASA?

Tester: “Tengo un vídeo en donde la aplicación falló“.
Desarrollador: “No dudo que el defecto se haya presentado, sólo quiero saber cómo lo reproduzco en mi ambiente para iniciar su depuración“.
Tester: “Es que ya no sucede, pero sucedió, aquí puedes volver a ver la grabación“.
Desarrollador: “Lo siento, si no puedes reproducirlo en vivo nuevamente, no puedo hacer nada.”

Razón 2: El detalle del reporte sobre el bug es incompleto

Si un tester reporta un defecto de manera incompleta o poco clara, puede ser rechazado con justa razón (ojo: no abusar); recuerda que un bug debe de tener los datos necesarios para que puedas iniciar su depuración.

Descripción del bug: “El botón ACEPTAR no funciona, se da click y no se realiza ninguna acción”.
¿Qué botón? ¿Dónde se encuentra ese botón? ¿Es el botón de la pantalla A o el de la pantalla B? ¿Con que perfil de usuario lo intentaron?

Razón 3: Lo reportado no está dentro del alcance

En ocasiones se levantan “defectos” de funcionalidades que aún no se agregaron a la aplicación de manera intencional (se agregará en una siguiente entrega o versión), no está dentro de los requerimientos que realizó el cliente, esto debe de ser RECHAZADO al no haberse pactado dentro del alcance.

Tester: “No existe funcionalidad para dar de baja el registro de usuario que acabo de realizar“.
Desarrollador: “Ese es un cambio que requiere un control de cambios, afecta al alcance del proyecto o entregable, no es un defecto, por lo tanto el bug se rechaza“.

Razón 4: El sistema no funciona bajo ciertas modificaciones “externas“

Las aplicaciones están desarrolladas para funcionar bajo ciertas condiciones de hardware/software. Para que una aplicación funcione correctamente en diferentes plataformas se requiere realizar adaptaciones propias de esta.

Tester: “La aplicación Web se aprecia correctamente en Chrome, pero en Edge no se visualiza correctamente“.
Desarrollador: “La aplicación sólo esta diseñada para el uso en Chrome, por lo tanto, para que funcione óptimamente el equipo del usuario deberá tenerlo instalado. Es un requisito para su uso.”

Razón 5: Corregir el defecto genera mayor impacto al sistema

Existen muchos bugs muy pequeños y de poco impacto para la aplicación, pero su depuración requiere implementar grandes cambios internos. Para este tipo de casos, lo mejor es no resolverlos, dejar la funcionalidad intacta, de lo contrario se requeriría mayor esfuerzo tanto en desarrollo como en pruebas.

Tester: “Se detectó que en la tabla usuarios de la base de datos, el campo de la llave primaria se llama ‘idusers’ y en la documentación indica que debe denominarse ”idusuario“.
Desarrollador: “Todas las columnas de las bases de datos mantienen nombres en inglés, por lo tanto se cambió para respetar esta propiedad. El cambio implica 23 modificaciones en la misma base de datos, por lo tanto, considerando el esfuerzo se rechaza el bug pero se actualizará la documentación“.

Conclusión

El equipo de SQA no siempre tiene la razón, en ocasiones tenemos que aceptar que nuestros bugs sean rechazados debido a que estos no aplican y una buena justificación del motivo de rechazo es más que suficiente para aceptarlo. Esta actividad (levantar bugs que no son bugs) tampoco es intencional (considerar que documentar un bug tiene su nivel de dificultad) y mucho menos se realiza con la intención de molestar al equipo de desarrollo. Recuerda que nuestro trabajo es asegurar que el software haga lo que tiene que hacer y debemos hacer lo necesario para lograrlo.

Muchas veces esto se debe a que no todos los involucrados en el desarrollo mantienen el mismo canal de comunicación y no están bajo el mismo entendido (¿Cambió la funcionalidad? ¡Avísenme!). Es importante que todo el equipo de desarrollo trabaje como equipo, no como enemigos, viendo quién es el que gana y desde luego, compartir todo el conocimiento es una buena práctica para evitar este tipo de errores generados a partir de una confusión (“yo creí”, “imaginé que”, “la documentación decía”, etc.)

¿Alguna otra razón para rechazar bugs? Regálame tu aporte.