¿Que hace un QA?
Destapando la caja negra
Desde que entré en el mundo del desarrollo web escuchaba muy poco el término QA (Quality Assurance), y cuando se mencionaba me preguntaba, ¿qué rayos es eso?, ¿qué hace? y ¿cómo se come?.
Las respuestas que obtenía siempre eran un poco confusas: “un QA es calidad”, “es un super villano que saca errores y deprime al desarrollador”, “una persona que revisa el trabajo final de un desarrollador y califica si está o no bien hecho”. Okey, todo eso suena muy fácil, pero, al buscar en nuestro querido amigo google te encuentras que todo es mucho más complejo, ya que hay diversas ramas, especializaciones, y cada una de ellas se dedica especialmente a algo, que te llena de información valiosa. Al ver esto me emocioné y dije, ¡quiero ser uno de esos!
Pero, en ninguna parte me dicen por dónde empezar, cómo hacerlo o qué herramientas necesito. NADIE revela el proceso de lo que hace un QA, ni en qué momento entra al ruedo en un equipo para asegurar que el proyecto tenga calidad. Este artículo tiene ese fin, ya que te comentaré el proceso básico de un QA basado en mi experiencia, después de tantas pruebas, algunas fallidas y muchas otras exitosas en este mundo.
Ser un QA es mucho más que revisar y sacar bugs, es asegurar que el producto se haga bien desde su inicio, según los requerimientos levantados con el product owner, hasta la entrega final del proyecto. La forma más sencilla y efectiva, que hasta ahora, yo he encontrado de ver cuándo y cómo interfiere un QA y lo que hace en un equipo de desarrollo es usando la metodología scrum.
Sin embargo, a continuación les dejo los puntos más básico que debes cumplir para ser exitoso en este mundo:
LEVANTAR REQUERIMIENTOS
Esto se hace en las reuniones de refinamiento con el cliente, todas las ideas que él tiene se plasman en historias de usuario, y si ya las tiene redactadas se revisan o depuran a ver si son entendibles para los desarrolladores. En este momento se empiezan a detectar los casos bordes y se dan recomendaciones para una buena experiencia del usuario final que usará la web o aplicación.
Casos de pruebas
No sabes lo importante que son hasta que los usas, es como tratar de visualizar el futuro con un sprint de anticipación. La idea de los casos de prueba es poder tener un orden de cómo y qué revisar en tu proyecto.
Aquí debes plasmar todos tus casos bordes (si es por criterios de aceptación, mucho mejor) y los detalles paso a paso. Colocas la pre condición que hay que tener para realizar esa prueba, especificas cual es el resultado esperado de ese caso, los datos de prueba a utilizar y un plus, que yo hago, es distinguir cada caso con un nombre, aquí ya entra tu creatividad para ver de qué forma diferenciar un caso del otro.
Esto te ayudará a ganar tiempo a la hora de probar.
Reportar los temidos bugs
Si al terminar de ejecutar tu caso de prueba el resultado no es el esperado, se levantan los temidos bugs, en mi caso, me apoyo con capturas de pantallas o vídeos de ejecución para que los desarrolladores no se pierdan en qué lugar sucedió y vean lo que vi yo. Muchas veces para asegurarme repito dicha prueba varias veces, esto con la finalidad de ver si el comportamiento se repite o no, o si en cada caso el resultado es distinto.
¡Usa tu criterio e instinto!
Documentación
Esto es muy importante, y muchas veces no le damos la atención que se merece. Te daré las razones de porqué documentar tu proyecto:
- Ayuda a el equipo a entender los procesos y proyecto, lo que llaman modelo de negocio.
- Te permite desplazarte por el proyecto, así te das una idea de lo que es o no usual.
- Visualizas qué parte del proyecto está realizada, cuál está en construcción y lo que viene a futuro. Te proyectas.
- Si un nuevo integrante se suma al equipo puede empaparse rápido del proyecto.
- Podrás realizar manuales de uso, de ser necesitados o solicitados por el cliente para el uso del sistema.
Aquí también fluye tu creatividad en cómo documentarlo, puedes usar flujos, imágenes, mockup, vídeos o documentos, con lo que te sientas más cómodo. Solo por experiencia te aconsejo “no lo dejes para última hora” .
Y esto nos lleva al último punto
HAZLO TUYO
El QA debe conocer el flujo del sistema como si fuese suyo, siempre tiene que estar al día de lo que pasa y lo que no en su proyecto y constantemente debe apoyarse en su equipo.
Para resumir un QA no es una máquina maligna que saca o crea errores, es un soporte de apoyo en el equipo que tiene información valiosa del proyecto.
