Uno de los objetivos de nuestros productos es que sean estables, que sean fiables. Intentamos que cada cambio realizado en el producto, en el código fuente, no rompa, no estropea nada. Es vital para todos nosotros que cada usuario disfrute de mejoras y no de disgustos.
En este post voy a intentar explicar como en la última versión velneo 22 un hábil bug ha podido escaparse de todas las barreras de defensa que tenemos.
Barrera 1 - El programador
Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Aunque en algunos casos se ve como el "culpable" de introducir el bug, también es el "culpable" de crear el producto. Si no se toca código es difícil añadir bugs.
Barrera 2 - En la integración continua
Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs ( Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc )Es muy útil tener todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.En Velneo contamos con la herramienta interna "vEst" que es una aplicación que ejecuta la mayoría de las funciones de Velneo cada vez que un programador toca una línea de código. Vienen a ser unos 2.000 test que prueban base de datos, objetos, procesos, javascript, etc.Cada día intentamos añadir más tests para poder comprobar el mayor porcentaje de funcionalidades de la plataforma en todos los sistemas operativos (Win, Lin, Mac, iOS, Android)
Barrera 3 - En el equipo de desarrollo
Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.Actualmente todos los programadores invierten un valioso tiempo en revisar y compartir los cambios de los compañeros. Es vital poner toda la atención posible para descubrir si algún bug paso las dos primeras barreras. En este caso el bug de la versión 22 paso delante de mis ojos y no fui capaz de verlo :-(
Barrera 4 - En el departamento de pruebas
Todos las incidencias, tienen que ser "cerradas" por el equipo de pruebas o la persona que ha introducido la necesidad/incidencia. Al mismo tiempo se prueban las novedades sobre aplicaciones estándar para ver si funciona correctamente. Un buen tiempo dedicado a probar que todo funciona bien y sin cambios, puede detectar bugs que han llegado a esta barrera.
Barrera 5 - Los betatesters
Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester. Es importante que el betatesters invierta tiempo en probar las novedades y cambios y que actúe casi como un usuario final. En algunos casos intentamos poner esta versión en producción, para poder darle una garantía de prueba real.Si el bug ha pasado todas estas barreras, ha llegado al cliente, posiblemente el coste es ya muy alto. Comunicaciones, revisiones, emails, disculpas, mala imagen, inestabilidad, etc.Cada vez que un bug salta todas las barreras, intentamos analizar como pudo pasar por cada barrera, para dar un punto de mejora y evitar que pasen más en el futuro.
