Dev Box Testing: ¿cómo reducir el costo de corrección de un bug?

Antes de todo, ¿usted ya pensó en cuánto cuesta un bug?

Según un artículo en el sitio web de FEMAMA, los costos para el tratamiento del cáncer aumentan conforme la etapa de la enfermedad, o sea, tratar el cáncer en una etapa avanzada es mucho más caro que en la fase inicial. El artículo presenta la información de que el tratamiento de cáncer de colon, en la primera etapa, cuesta poco más de R$ 4,1 mil. En la tercera etapa pasa para R$ 77 mil. El de cáncer de mama, que cuesta R$ 11,3 en la primera etapa, pasa para R$ 55 mil en la tercera etapa. Pero calma, usted no tuvo un delirio (ni yo), y también estamos hablando sobre Dev Box Testing. El punto es que acabamos de concluir que en la medicina curar es mucho más caro y traumático que prevenir, y mientras más alta sea la etapa de la enfermedad, más caro y menos oportunidades de cura existen. Siguiendo el mismo concepto, podemos reducir el costo de corrección de un bug.

El trabajo que tendríamos para corregir un posible bug por entendimiento incorrecto en la planning, sería muy pequeño, cerca de lo que tendríamos al corregir ese bug después que la funcionalidad ya haya sido entregada al cliente. Como el bug ya estaría en el cliente, él podría tener pérdida financiera, pérdida de la confianza en nuestro producto, entre otros problemas.

Para la corrección, sería necesario parar un equipo de desarrollo que ya está involucrado con otra actividad. Los desarrolladores tendrían que entrar nuevamente en el contexto, entender la funcionalidad hasta encontrar la raíz del problema. Este bug tendría que pasar por todas las etapas del proceso de desarrollo, como, por ejemplo, la revisión del código y pruebas. Una nueva versión sería liberada para el cliente que tendría que programarse para hacer a instalación en su ambiente. Mucho trabajo, ¿no es verdad? Ahora, ¿imagina si ese bug hubiese sido encontrado en la planning, con una pregunta? En algunos minutos de conversación entre el equipo, lo que generaría un gran problema en el futuro estaría resuelto. Entonces, como en la medicina, mientras más rápido es encontrado un bug, más fácil y menos impactante es su corrección.

‍

¿Pero qué ese tal de Dev Box Testing tiene que ver con esto?

Dev Box Testing es la ronda inicial de pruebas hechas en la máquina de desarrollo, antes que el código sea enviado al repositorio para la revisión. Es una técnica de agilidad que tiene como principal objetivo reducir el costo de corrección de un bug.

Ciclo de desarrollo SIN Dev Box Testing:

‍

Ciclo de desarrollo CON Dev Box Testing:

‍

La teoría es fácil, pero ¿cómo se hace en la práctica?

1. En su máquina después de la conclusión de la codificación, el desarrollador invita al Analista de Calidad para juntos hacer el Dev Box Testing.

2. Con ambos en la misma máquina, el desarrollador demuestra la funcionalidad implementada.

3. El Analista de la Calidad asume el control de la máquina y realiza algunos escenarios.

4. En el caso que sean apuntados bugs, el desarrollador que supervisa la prueba lo anota.

5. Después del término, el Analista de la Calidad deja la máquina para que el Desarrollador haga las correcciones.

En el caso que uno de los dos o ambos estén actuando de forma remota y no presencial, puede ser utilizada una herramienta para acceso remoto o el desarrollador puede ejecutar los escenarios conforme el pedido del responsable de las pruebas.

Puntos importantes:

- Para bugs complejos encontrados durante el dev box, el Analista de la Calidad puede ser llamado para una nueva validación después de la corrección.

- Dev Box Testing es una prueba básica, rápida y directa, y no tiene como objetivo sustituir la prueba completa realizada en el ambiente de QA después del envío al repositorio y revisión del código. La prueba completa debe ser realizada normalmente dentro del proceso, principalmente porque pueden haber tenido modificaciones solicitadas en la etapa de revisión del código o pueden tener problemas que aparecerán solamente en el ambiente de pruebas.

- El tiempo gastado para esto debe variar de 10 a 15 minutos, con base en la complejidad de la historia o defecto implementado.

¿Y qué ganamos con esto?

- Reducción del ciclo de feedback;

- Reducción de retrabajo;

- Más agilidad en el proceso de desarrollo;

- Mejor cobertura de pruebas automáticas;

- Mejor comunicación e integración entre desarrollador y Analista de la Calidad.

¿Imagine tener que volver una actividad para realizar nuevamente todo el proceso por culpa de un bug que sería fácilmente identificado por el analista de la calidad, en la primera prueba que hiciese? Si este bug es impeditivo, el responsable de las pruebas también tendrá que esperar para proseguir, incluso después de que la actividad haya sido liberada para él. Con la práctica de Dev Box, tenemos un feedback más rápido de los problemas. Este bug sería corregido aún en tiempo de desarrollo, cuando el responsable de la codificación aún está con el ambiente preparado, y con la “mano en la masa”, lo que reduce el retrabajo ya que él no necesitaría volver para corregirlo después de haber entregado la actividad de desarrollo.

Claro que la mayoría de las veces no será posible eliminar todos los bugs en dev box, incluso porque este no es el objetivo y las pruebas son básicas. Sin embargo, eliminar el máximo posible en esta etapa es fundamental para que la prueba más completa, hecha después del proceso de revisión del código, pueda ser hecha con más tiempo y enfoque.

Uno de los beneficios de esta práctica, además de feedback más rápido, reducción del retrabajo y más agilidad en el proceso de desarrollo, es la mejoría en la cobertura de las pruebas automáticas hechas por el desarrollador. Con este cambio de conocimiento en el momento del dev box, el desarrollador gana insumos para implementar sus pruebas de forma que puedan cubrir una cantidad mayor de escenarios.

Sabemos que el trabajo en equipo es muy importante en la agilidad, e incluso con equipos formados por personas con especialidades diferentes, la comunicación entre ellos también sufre modificación. El analista de la calidad y el desarrollador se sientan juntos para aplicar el Dev Box, lo que establece aún más una buena relación, comunicación y un vínculo de colaboración entre ellos, ya que ambos están enfocados en aquel momento y contribuyendo a dejar el proceso más ágil y entregar la tarea al cliente con más calidad en un menor tiempo.

El objetivo de este procedimiento es agilizar el proceso de desarrollo, anticipando los problemas para que el costo de corrección sea menor, dejando el ciclo de vida del bug más corto, ganando tiempo para enfocarse en los escenarios que son más críticos para el sistema.

La forma de trabajar presentada aquí es una sugerencia. Usted puede y debe adaptarla para su equipo y proyecto que tienen características específicas y sus particularidades, siempre pensando en la reducción del re-trabajo, agilidad, calidad e interacción entre las personas del equipo. Con esta práctica simple, y que presenta un impacto positivo, es fácil incluirla en el flujo del equipo. Entonces, ¿qué usted está esperando para aplicar y ver los resultados?

‍

¿Qué decir del Dev Box Testing que conozco hace poco tiempo y ya considero mucho?

“¡La idea de aplicar dev box testing fue simplemente genial! Durante la actuación de las pruebas locales, no solo impidieron el paso de bugs para los demás ambientes, sino también es pasada la perspectiva del QA y la visión de diversos escenarios. De esta manera, tuvimos este análisis profundo ya durante el tiempo de desarrollo. ¡Es una práctica de extrema importancia para cualquier sistema! – Gian Raphael Martins da Costa – Software Developer“

“Dev Box Testing está ayudando en la Prevalidación en el ciclo de desarrollo, estamos logrando anticipar problemas y entregar flujos para que el QA siga sin diversas interrupciones ocasionadas por problemas. Con esto estamos reduciendo problemas que podrían traer riesgo para Sprint y estamos aumentando la calidad de entrega del producto. – Matheus Bongiorno – Software Developer”

“Dev Box Testing proporcionó una reducción de tiempo en el flujo de desarrollo, bugs pueden ser identificados con más velocidad y menos burocracia, además de esto, esta dinámica estimula a los involucrados a identificar flujos alternativos antes no vistos, permitiendo una cobertura mayor en el tratamiento de posibles errores. – Daniel Elvis Quevedo – Software Developer”

“Al inicio del Dev Box en el equipo, fue difícil asimilar que después de hacer el deploy de la aplicación para ser probada se obtiene la respuesta: “TODO BIEN”, la cabeza se traba, ¿cómo que todo bien? ¿no hay bug? NO. Eso está ocurriendo debido a la convivencia con el QA proporcionado por la práctica del Dev Box. La programación pasó a ser de cierto modo preventiva, pues los puntos de fallas están quedando cada vez más claros. – Edson Pereira do Nascimento Junior – Software Developer”

“Devbox testing nos ayudó a mejorar la calidad de la entrega entre las fases de desarrollo y pruebas, reduciendo el número de errores básicos encontrados por el equipo de QA. – Eduardo Marinho David – Software Architect”

“El proceso de dev box testing ayudó mucho en las entregas, garantizando aún más calidad para el cliente, que se ha mostrado realmente satisfecho con el resultado. – Alan Marcel da Costa – Product Owner”

“Dev Box Testing fue una práctica adoptada en nuestras sprints que trajo muchos beneficios. Lo que inicialmente surgió como un piloto en nuestros proyectos acabó convirtiéndose en una actividad presente en prácticamente todas nuestras tareas. Aplicamos esta buena práctica por aproximadamente 6 meses y verificamos que el número de bugs reportados en la etapa de prueba disminuyó significativamente, consecuentemente hubo una disminución en el retrabajo, tanto en la etapa de desarrollo como en la etapa de prueba, y proporcionó aún más calidad en las entregas y un mejor aprovechamiento del tiempo en las sprints. A pesar de que nuestro equipo siempre haya actuado de forma unida y colaborativa, esta actividad conjunta promovió aproximación del equipo y permitió que los desarrolladores pudiesen conocer y entender un poco más del trabajo ejecutado por el especialista de prueba. Feedbacks positivos surgieron por todos los lados: Cliente feliz con la calidad de las entregas y bajo número de bugs en el ambiente de producción, equipo técnico unido, comprometido y motivado. – “Renata Gumerato Aguiar – Team Leader “

“Dev Box Testing trajo aún más agilidad para un equipo ya habituado a utilizar buenas prácticas de desarrollo y procesos ágiles. Percibimos que hubo una mejoría en la integración entre desarrolladores y analistas de la calidad, además de un mayor cuidado con la calidad del código fuente y comprensión sobre la importancia de las pruebas. – Natalia Bortoletto Cruz – Manager”

‍