Quiero ser QA ¿Por dónde empiezo?

Siguiendo con los posts orientados a aquellos que quieran iniciarse como QAs, quiero responder a esta pregunta que suelen hacerme bastante seguido.
 
¿Por dónde empiezo?

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 (supongo que todos saben lo que es), en dicho 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, de hecho hasta 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 numero muy grande, numero negativo, numero con decimales, letras, etc
Precio: Ingresar letras, numeros 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.
 
Bien… Ya se lo que es un BUG.. ¿Y ahora que 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 este comenzando junto con nuestro testing, entonces se comienza creando un plan de pruebas (test plan) con casos de pruebas (test cases). Esto tiene como ventaja generar una documentación de que alcance tiene el testing y sobre que cosas se prueban y que no.

En caso de que el proyecto ya esté desarrollado y necesitan 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 como documentar lo que hemos probado y lo que no.

En otro post comentaré más en detalle que son los test plan y como 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 que nosotros encontremos.

Siempre que reportemos un error, debemos ser lo más claros posibles a la hora de reportarlo, es decir, debemos documentar bien que 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 únuco de cada bug. Los issue tracker los colocan de forma automática
Título: Título descriptivo. Suelo poner entre corchetes el nombre del módulo que posee el error
Descripción: Una breve descripción sobre el error encontrado
Precondiciones: Si necesito tener ciertos accesos o permisos para poder reproducir el bug
Pasos para reproducirlo: Detalle paso por paso de que acciones debo realizar para reproducir el bug
Resultado Actual: Explicar que está pasando actualmente
Resultado Esperado: Explicar como debería funcionar
Screenshot/Video: Alguna captura de pantalla o video mostrando el error
Prioridad: Que tipo de prioridad tiene este issue (Los explicaré más adelante en otro post)
Asignación: Asignarle el issue al desarrollador que hizo esa funcionalidad
 
Ejemplo con Redmine:


Esto es todo lo que necesitan saber por ahora sobre bugs y como reportarlos. Pronto subiré otra entrada sobre más metodologías o estrategias de testing y poco a poco iremos encadenando los conceptos.

Cualquier duda que tengan o sugerencias para un futuro post, pueden dejarlo en la caja de comentarios