Vamos a empezar explicando lo que es un bug, que, de ahora en más, será nuestro aliado o enemigo.
Un bug, es básicamente un error (comportamiento no esperado, error visual, entre otros).
¿Por qué digo que es un enemigo o un aliado?
Una de las formas de saber si estamos haciendo bien nuestro trabajo, es porque estamos encontrando errores en una plataforma. Y se puede decir que es un enemigo, porque mientras más errores tenga una plataforma, más tiempo tardaremos en salir a producción.
Para entender mejor el tema, vamos a poner el siguiente ejemplo: tenemos un sistema de stock y en este sistema tenemos un CRUD de productos, en donde podemos crear, editar, eliminar y ver los items cargados.
Nuestra tarea como QAs es probar cada campo, cada función, e incluso todo lo visual que podamos llegar a notar en la pantalla que estamos testeando.
Supongamos que estamos dando de alta un producto y que los campos son:
Título
Cantidad
Precio
Podemos probar cosas como:
Título: caracteres especiales, colocar más de 500 caracteres, dejarlo vacío, etc.
Cantidad: colocar un número muy grande, número negativo, número con decimales, letras, etc
Precio: ingresar letras, números negativos, caracteres especiales, etc.
La idea de esto es intentar romper la aplicación como sea, si el campo es de cantidad, no tiene sentido que se ingresen letras. Parece un poco obvio, pero no se dan idea de la cantidad de errores así que se encuentran en las aplicaciones. Muchas veces por apurarse, los desarrolladores olvidan poner validaciones en los campos.
Ya sé lo que es un bug .. ¿Y ahora qué hago?
Esto varía mucho dependiendo del proyecto en el que estemos trabajando, los tiempos que tengamos y demás. Pero suponiendo que es un mundo feliz, en donde el testing inicia junto con el proyecto, es decir, que el desarrollo está comenzando junto con nuestro testing, entonces crearemos un plan de pruebas (test plan) con casos de pruebas (test cases). Esto tiene como ventaja generar una documentación que muestra el alcance del testing y qué cosas se prueban y cuáles no.
En caso de que el proyecto ya esté desarrollado y se necesite un test en un corto lapso de tiempo, se puede optar por otras estrategias de testing, como por ejemplo un testing exploratorio que consiste en navegar la aplicación en busca de errores. Lo malo de esto es que no tenemos cómo documentar lo que hemos probado y lo que no.
En otro post comentaré más en detalle qué son los test plan y cómo armarlos, lo mismo que los test cases y las diferentes estrategias de testing.
¡Encontré un bug! ¿Con qué se come?
En todo proceso de desarrollo de software, es muy necesario contar con un issue tracker (Redmine, Jira, etc).
Los issues trackers no solo sirven para documentar las funcionalidades de la aplicación, sino también para reportar cada bug encontrado.
Siempre que reportemos un error, debemos ser lo más claros posibles a la hora de reportarlo, es decir, debemos documentar bien qué tipo de bug es, pasos para reproducirlo, etc.
A continuación, les voy a compartir una plantilla que suelo utilizar yo a la hora de reportar un bug.
ID #: ID único de cada bug. Los issue tracker los colocan de forma automática.
Título: suelo poner entre corchetes el nombre del módulo que posee el error.
Descripción: una breve descripción sobre el error encontrado.
Precondiciones: ¿necesito tener ciertos accesos o permisos para poder reproducir el bug?
Pasos para reproducirlo: detalle paso por paso de las acciones que debo realizar para reproducir el bug.
Resultado actual: explicar qué está pasando actualmente.
Resultado esperado: explicar cómo debería funcionar.
Screenshot/video: alguna captura de pantalla o video mostrando el error.
Prioridad: ¿qué tan grave es este error para el negocio?
Asignación: asignarle el issue al desarrollador que hizo esa funcionalidad.
Por lo general, solemos utilizar la siguiente plantilla para reportar bugs, en donde se puede ver de forma completa como reportar bugs y un ejemplo.
¡Espero que estas indicaciones les sean útiles!
