Mejora de procesos

El objetivo es poder disponer de una versión de nuestro proyecto lista para ser instalada en cualquier entorno con la máxima seguridad de que será completamente funcional.

Disponer de un proceso de integración continua nos evita la pesadilla de tener que realizar grandes integraciones de diversas fuentes manualmente, reduce la probabilidad de aparición de defectos por la propia integración y permite tener código fresco cada día, propagado en todas las ramas. Disponer de una buena configuración permitirá que el proceso sea sencillo y eficiente.

Los entornos de calidad y preproducción han de ser lo más similares posible a producción. Esto nos permite corregir errores de despliegue al ser detectados en entornos no productivos, minimizando la probabilidad de fallo en los entornos productivos. También nos permite tener el producto rápidamente listo para una demo, una UAT o pruebas de testing funcional o automático. Si este punto no está logrado o lo está en parte, debemos identificar y priorizar qué partes deben ser implementadas o reforzadas.

Estas herramientas pueden ser desde un básico gestor de defectos hasta una completa herramienta de que permita manejar un equipo scrum, con post-it virtuales, cálculo de burn-downs, control de kanban, etc. Generalmente lo más eficaz no es ni uno ni otro extremo, sino conseguir adaptar la herramienta al proceso del equipo.

El perfil de QA en un equipo ágil no se centra únicamente en hacer el testing funcional sino que tiene un espectro mucho más amplio, comenzando con el contacto con el Product Owner para entender bien sus necesidades y transmitirlas al equipo de desarrollo y a las propias pruebas, gestión de las incidencias, liderar las retrospectivas, velar por la mejora continua, etc. Este perfil en los equipos del cliente puede ser permanente en una persona o rotativo, pero en cualquier caso ha de ejercer sus responsabilidades y éstas han de ser conocidas por todo el departamento.

Tanto para realizar las pruebas manuales como para las pruebas automáticas funcionales o de rendimiento, el sistema bajo prueba ha de contener unos datos iniciales. Estos datos pueden dividirse en datos de configuración, necesarios para que el sistema pueda funcionar y datos de negocio, que son aquellos que se van añadiendo a la base de datos durante el uso natural de la aplicación.

Gestionarlos correctamente reforzará la calidad de nuestros entornos no productivos, permitiendo resultados más completos de las pruebas funcionales (manuales y automáticas), de rendimiento, UAT, demos, etc.

Los test automáticos nos ayudarán no solo a reducir el tiempo de las pruebas, sino a detectar problemas que de otro modo serían imposibles de encontrar antes de llegar al entorno productivo. Estas pruebas automáticas pueden dividirse en:

1. calidad estática de código fuente
2. test unitarios
3. test funcionales
4. test de rendimiento

Durante la vida del proyecto, el cliente final debe poder tener feedback rápido y claro del estado de su proyecto, idealmente sin ponerse en contacto el equipo de desarrollo. Para ello se le deben ofrecer indicadores claros, sencillos y disponibles las 24 horas. Estos información, junto con las reuniones diarias han de permitir detectar rápidamente cuellos de botella en el proceso que deben solucionarse. Por ejemplo, tickets que están demasiado tiempo esperando ser validados o código en espera de revisión técnica para ser integrado.

El usuario final ha de tener canales sencillos y efectivos para poner en conocimiento el cliente incidencias con su producto una vez esté en producción.

1. ¿La comunicación principal será telefónica?
2. ¿Dispone de una herramienta de ticketing para abrir incidencias?
3. Cómo se gestionan estas dentro del equipo de desarrollo y se devuelve feedback al cliente?
4. ¿Qué efectividad tenemos resolviendo incidencias?

Todas estas preguntas y muchas otras han de estar claras y se debe disponer de un procedimiento establecido para abordarlas de igual manera en todos los proyectos.