El mundo de la calidad ha evolucionado notablemente y ha empezado a tener más notoriedad dentro de los productos de software. Y esta es una de las razones por las que cada día hay una mayor demanda de profesionales de calidad para diferentes proyectos de desarrollo.
Sin embargo, dada esta misma evolución, en internet podemos encontrar mucha documentación sobre los temas que están en boca de todos, y esto puede ser abrumador, e incluso puede llegar a volverse un problema cuando quieres empezar en el mundo de la calidad. Así que hoy quiero dejarte cinco consejos de lo que debes hacer como analista de calidad y la misma cantidad de los que no debes hacer. Sin más introducción vamos a comenzar con lo que debes hacer:
SI: Colabora con las historias de usuario
Una de las formas de asegurar que todos están alineados y entienden una funcionalidad de la misma manera es trabajar en las historias de usuario y los criterios de aceptación, así que uno de mis consejos es que aprendas a hacerlas. En mi instagram tengo un reel donde te enseño rápidamente cómo hacer una historia, si lo quieres ver, sólo haz clic acá y aprovecha de seguirme.
SI: Haz tanta preguntas como necesites para entender
Muchas veces asumimos información y nos da temor preguntar por no quedar como tontos y además creemos entender aunque aún existan algunos espacios grises, pero ese es el inicio del desastre. No tener muy clara una funcionalidad, lo que se va programar y lo que no, va a hacer que no tengas claridad acerca de los casos de pruebas que vas a ejecutar y que incluso el mismo desarrollador no sepa cuáles escenarios debe probar. Así que tomate en serio las preguntas y no tengas miedo a lucir como tonto.
SI: Participa en las sesiones de creación de tarjetas
Tu visión sobre lo que espera el usuario y la visión que pueda tener el dueño del producto y el analista de negocio son la tripleta ganadora. Así que cuando se crea una tarjeta para una nueva funcionalidad, asegúrate de participar.
SI: Entabla amistad con los desarrolladores
Recuerda que según scrum tu no perteneces al “Equipo de QA”, sino al equipo de desarrollo de un producto, así que aprende a trabajar en equipo con ellos. Escuchalos y brindale tu asesoría en materia de calidad. Influye positivamente en el trabajo que ellos están haciendo.
SI: Determina los riesgos de tu producto
Para poder hacer un trabajo más planificado, debes conocer los riesgos de tu producto y cómo puedes mitigarlos, que planes puedes ejecutar en caso que se convirtieran en una realidad y te ayuda a estar preparado para cualquier contingencia. Así que asegúrate de trabajar con el dueño del producto para determinarlos.
Todos estos consejos te ayudarán a comenzar con buen pie con tu equipo y con tu producto y fijate que la mayoría de estas cosas ni siquiera están relacionadas directamente con conocimientos de pruebas, sino de trabajo en equipo, y decidí nombrarlas primero porque algo que debes fomentar es que la calidad es responsabilidad de todos. Y con esto en mente te diré lo que tienes que evitar cuando quieres ser un buen analista de calidad.
NO: Convertirse en el que aprueba los lanzamientos
Como te dije anteriormente, esto sólo conseguirá que el resto del equipo se desentienda de los factores que garantizan un producto de calidad y dejar la decisión sólo en tus manos, y tu siempre tendrás miedo que el producto pueda tener fallos. Al contrario, busca colaboración y comparte esta decisión con más miembros del equipo.
NO: Probar sólo al final del proceso de desarrollo
Cuando esperas a que una funcionalidad esté desarrollada y pase a tus manos para probar, el efecto que tendrás es que a último minuto vas a encontrar muchas cosas, vas a regresar en muchos momentos las tarjetas y vas a convertirte en el cuello de botella del equipo. Para evitar esto, involúcrate desde el inicio, usa tu sentido común para decir dónde crees que pueden haber problemas por la manera en que se piensa una funcionalidad y donde se pueden introducir errores. Allí comenzarás a probar incluso sin que se haya hecho una sóla línea de código.
NO: Hacer suposiciones
Como te dije en el punto dos de la primera parte, es mejor preguntar cuando es necesario y cuando hay dudas. Suponer nunca es bueno y en materia de calidad menos. Una vez que hayas leído la descripción de una funcionalidad, si tienes dudas y te las responden, recuerda documentar la información que hayas encontrado para que otros también manejen la misma información.
NO: Aprender solo sobre pruebas del producto
Probar el producto es tu tarea principal, pero no la única, debes ser intencional con tu trabajo y ser un referente en cuanto al funcionamiento del producto, pero el producto existe en un negocio bajo una tecnología y en un determinado ambiente con interacciones de datos. Recuerda recolectar esa información en tu dia a dia para mejorar los procesos que pudiera afectar directamente esas pruebas del producto. Eso también hace parte del trabajo de calidad
NO: Aislarte del resto del equipo
Los equipos ya no trabajan bajo metodologías de cascadas y se esperan resultados más prontos en cada interacción que pueden ser de dos a cuatro semanas. Incluso puedes estar recibiendo nuevas funcionalidades a diario de las que el equipo espera retroalimentación. Así que asegúrate de trabajar con el equipo en la estrategia y de mantenerte agregando valor en cada interacción sobre los errores y funcionamiento de tu producto de software.
Espero que estos consejos te puedan servir para tener un horizonte claro sobre lo que pueden ser las primeras habilidades a desarrollar para ser un analista de calidad de exito.
Si te ha gustado este material recuerda compartirlo con amigos para que sigamos haciendo crecer esta comunidad de #genteDeCalidad
