El ciclo de vida del desarrollo de software (en inglés: SDLC – Software Development Life Cycle) podría definirse como conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es liberado.

Según el modelo en el que te encuentres tu ciclo de vida varía en cuanto a fases, procesos, duración, etc., pero existen fases que no están escritas en ningún lado y que considero que son de vital importancia que el QA se involucre desde el minuto cero en ellas, yo definiría estas sub-fases como:

• Kickoff
• Test analysis
• Coding + Testing
• Review Testing
• Getting ready for release
• Done

Si bien, lo ideal es que el QA participe en cada una de ellas, a veces no es posible (falta de recursos, mala planeación, no hay tiempo suficiente, involucramiento tardío, etc., etc., etc.) al menos el QA debería de participar en 3 (Kickoff, Test strategy, review testing) de ellas para asegurar que el producto salga con los mejores estándares de Calidad.

Kickoff

Aunque muchos lo asocian con el análisis del requerimiento yo lo veo como un after, es decir, una vez que llega el PO/PM/etc con el requerimiento tu deber como QA es entenderlo al 100% para que tu QA strategy sea lo más exacto posible, entonces ¿Que pasa cuando tienes dudas en un requerimiento, criterio de aceptación, DoD?, probablemente lo reportes como riesgo y esperes a que se aclaré, sin embargo con un kickoff puedes ahorrarle tiempo a todo equipo (incluyéndote), te propongo lo siguiente:

1. Reúne a las personas requeridas – evita reunir mucha gente, equipos completos o personas cuyo aporte no era necesario para revisarlo.
2. Se claro con tus observaciones – a nadie le gusta ir a una reunion que pudo ser un email, se claro con tus dudas, preocupaciones o riesgos, trasmitelos de manera que todos en la reunion estén alineados contigo.
3. Establece una agenda previa – mientras los invitados tengan más tiempo para prepararse para la reunión esta será más productiva, envía un pequeño listado de tus observaciones, documentos señalados, etc.
4. No te olvides de los action items – en todas las reuniones exitosas salen owners de actividades para mitigar todas esas observaciones, por ejemplo: cambiar los criterios de aceptación, actualizar los mockups, refactorizar algún módulo, etc. etc. etc., coloca todos esos action items en donde todos los involucrados no se olviden de ellos, puede ser un email al final de la junta o un mensaje en Slack, lo importante es no perderlos.

Test analysis

Para cuando la fase de análisis ha terminado, seguramente tu como QA ya tienes toda la QA strategy que ese producto debe de llevar acabo y luego ¿esperas hasta que pase a pruebas? la respuesta es no, yo te recomiendo que hagas una presentación de ella al equipo de desarrollo… sí, leíste bien, al desarrollador.

Cuando tú le presentas todos los escenarios por los que va a pasar su trabajo y los riesgos que has identificado pasan muchas cosas buenas:

• El desarrollador encuentra escenarios que no sabía que podrían existir, por lo que se asegurara de que funcionen y algunas veces de incluirlos en las pruebas unitarias.
• El desarrollador encuentra escenarios que no funcionan como “deberían”, porque quizá el había interpretado de manera diferente el requerimiento.
• El desarrollador nutre tus escenarios, a veces a nosotros se nos escapan ciertos comportamientos que técnicamente son posibles y que deberíamos de validar.
• Los riesgos se mitigan antes de que sucedan, suele pasar que cuando nosotros vemos un riesgo super complicado/peligroso nos alertamos, pero si el desarrollador conoce de ellos puede que no sea tan complicado de mitigar incluso antes de que suceda o pudiera suceder.

Al final lo resumiría como, evitamos reportar/corregir bugs desde antes de entrar a la fase de testing lo cual es muy importante porque se traduce como ahorro de tiempo y/o recursos.

Review testing

Esta ultima yo lo colocaría como opcional, casi no me sucede, pero cuando sucede hemos evitado problemas en producción, en fin, el review testing lo defino como un pre-informe final después de que la fase de pruebas ha concluido y esta fue caótica y no me refiero a que salieron muchos bugs, me refiero a cuando las cosas tomaron un camino diferente al que se planeaba.

Durante la fase de testing nosotros vemos el resultado final del producto antes que el cliente, que el stakeholder, el PM, etc, entonces a veces vemos que se hizo alguna dependencia con un módulo que no estaba contemplado, algún diseño no se ve tan fancy como se planeaba porque los estilos al final no funcionaron, etc. bueno en este informe nosotros enlistamos todas esas cosas que salieron diferente a lo que todo el equipo pensaba, lo comunicas a las personas correctas y le das tiempo suficiente al PO/PM de decidir si vamos a modificarlos en esta versión, si debemos de crear mejorar para futuros sprints, si van a ser “known issues”, etc y por lo tanto el desarrollador puede estimar cuando tiempo tomará hacer las adecuaciones necesarias (en caso de optar por hacerlas) y al final todos estamos alineados con los siguientes pasos y con la calidad del entregable.

Quiero pero no puedo…

Si todo lo que te digo te hace sentido y quisieras comenzar a implementarlo en tus equipos pero no puedes por la razón que quieras, te recomiendo seguirlas de manera extraoficial, cada una de estas fases tienen como objetivo elevar la calidad del entregable y ahorrar tiempo de desarrollo, cada que armes alguna de estas reuniones hazlas cortas, claras y efectivas, cuando todo el equipo comience a ver los beneficios que obtienen se iran incluyendo en tu proceso casi sin que te des cuenta.

Recuerda que como QAs velamos por la calidad de los procesos, cuida la forma en la que te comunicas, saca a relucir tus soft skills junto con tu dominio del sistema, modificalas a tu comodidad y siempre busca como mejorar tus procesos.