Cuando se trabaja como parte de un equipo de ingenieros de control de calidad la misión es simple: ¡encontrar y reportar bugs!
¿Quién de ellos querría que se le escape algún defecto o que después de reportar alguno el equipo del proyecto determine que dicho defecto es inválido? ¡Ninguno!
Al hablar de “bugs”, es necesario explicar su significado pues tiene muchísima importancia en el día a día del trabajo que realizan.
¿Qué es un bug o pulga?
Cuando hablamos de bugs o pulgas, podemos referirnos a tres términos según la ISTQB:
Defecto: Un desperfecto que puede causar que el componente o el sistema falle al realizar su función requerida, por ejemplo: una sentencia incorrecta o una definición incorrecta de los datos. Si se encuentra un defecto durante la ejecución, puede causar una falla del componente o sistema.
Falla: Una acción humana que produce un resultado incorrecto.
Error: Desviación del componente o el sistema de su entrega prevista.
Bug o Pulga, es el término general que se utiliza para incorporar los términos revisados anteriormente.
Entonces, podemos decir en pocas palabras que un bug es todo lo que cause algún tipo de inconformidad o insatisfacción en nosotros o en el cliente. Incluso en muchas ocasiones, el deseo del ingeniero por reportar tantos bugs como le sea posible encontrar puede llevar al reporte inválido del mismo
Experiencia que marca la diferencia
Presentamos algunos consejos -basados en la experiencia- para evitar el reporte de bugs o pulgas inválidas. Dichos consejos aplicados a las actividades de ejecución de casos de prueba y reporte de defectos pueden ayudar a reducir estos reportes al mínimo.
Revisando requerimientos
La información contenida en los requerimientos es sumamente importante, ya que contienen información relevante que va más allá de los criterios de aceptación del mismo, por lo tanto, se debe comprender todo el requerimiento para no dejar ningún escenario por fuera.
Al momento de encontrar un bug se deberá comparar el comportamiento actual del sistema versus el esperado según el requerimiento respectivo y determinar si hay o no una inconsistencia. Esto en gran manera reducirá la posibilidad de reportar pulgas que en alguna parte del requerimiento se mencionó que se podrían encontrar.
¿Es el ambiente correcto?
Al iniciar pruebas en el producto, se debe revisar que el ambiente en el que se realizarán las pruebas es el que está destinado para este fin. Si no se realiza una revisión en este aspecto, se corre un riesgo enorme de reportar bugs inválidos, ya que en el ambiente correcto las funcionalidades podrían estar operando correctamente.
Borrando caché
Cuando se trabaja en plataformas o ambientes web y no se borra la memoria caché del browser, la página suele cargar lo que ya se tiene en memoria local, privando al ingeniero de calidad de ver los nuevos cambios hechos a la aplicación; haciendo fácil caer en el error de reportar bugs inexistentes. Para evitar esto, se puede navegar en modo incógnito o bien limpiar estos archivos temporales del navegador periódicamente o cada vez que se va a iniciar un ciclo de pruebas, para aplicar los cambios y de esta manera, se puedan reportar bugs cuya validez es indiscutible.
Probando un Filtro
Si se cuenta con una herramienta para el reporte y seguimiento de bugs, por ejemplo con el caso de JIRA, se tiene la posibilidad de crear un filtro para saber cuáles bugs han sido marcados como inválidos y de esta forma saber qué casos se consideran como tales para compararlos al caso a reportar como bug.
Existen muchas formas de llevar este control, incluso existen herramientas poco convencionales en las que se puede llevar un control de este tipo, por ejemplo: Google Drive.
Además realizar una búsqueda en la herramienta de administración de defectos respecto al error a reportar, constituye una buena práctica para evitar el reporte de bugs duplicados.
¿No hay filtros? Siempre puede haber comunicación
La comunicación es sumamente importante en un equipo, no solo para saber qué está haciendo cada miembro, sino para que cada ingeniero de calidad tenga conocimiento sobre los reportes hechos previamente; de ésta forma evitaremos reportar bugs que han sido ya reportados por otros miembros del equipo de control de calidad y que ya fueron -en algún momento- marcados como inválidos por existir reportes previos al actual. Entonces, es importante hacer una revisión sobre los bugs que ya han sido reportados.
Todos los consejos anteriores pueden ayudar a evitar el reporte de bugs inválidos, por lo que aplicarlos en actividades diarias de control y aseguramiento de la calidad ayudará a evitar exceso de trabajo tanto del equipo de QA como del equipo de desarrollo para así optimizar el tiempo utilizado para el reporte y corrección de defectos.
.png)
