Los 5 Mandamientos del Testing Agile
Para construir un producto de calidad, las actividades de prueba deben integrarse completamente con el ciclo de desarrollo. El mismo equipo que crea el producto debe realizar las pruebas. Esto asegura que todo el equipo de desarrollo posea la calidad del producto, en lugar de un individuo. La propiedad colaborativa debe de primar sobre la objetividad separada.
Los testers en lugar de ser observadores críticos, deben de participar activamente en la prevención de los defectos del producto. Esto es más fácil si los testers están familiarizados con la funcionalidad, el dominio empresarial del producto y participan en actividades de desarrollo trabajando con analistas de negocios y clientes.
Combinar pruebas automatizadas y pruebas con personas asegura una cobertura de prueba completa en situaciones de la vida real. Los seres humanos pueden no ser tan precisos, pero superan las computadoras de muchas otras maneras: la creatividad, la conciencia del contexto y el pensamiento fuera de la caja.
En estos esfuerzos por construir un software de alta calidad, el Testing Agile define las claves para entregar un producto donde el trabajo conjunto del equipo prime antes del individual, estos criterios quedan definidos mediante el Testing Manifesto:
Testing durante VS testing al final: Priorizar la realización de tareas de testing desde el inicio hasta que se da por acabada en vez de realizar el testing como una etapa al finalizar el sprint.
Prevenir bugs VS encontrar bugs: Incentivar la discusión y revisión grupal de las tareas, tener claro que hay que hacer, como y porque. Evitar todo tipo de suposiciones y trabajar realmente en equipo con el desarrollador para que los bugs se puedan evitar de antemano, en vez de esperar a que el desarrollo este completo para revisar, así como evitar discutir con el desarrollador sobre que se va a testear.
Entender lo que se está testeando VS verificar funcionalidad: Entender que es lo que quiere el usuario, para que lo quiere y como lo va a usar, para realizar pruebas que den valor agregado en vez de ver que las especificaciones se cumplen. Ver que 1+1 sea igual a 2, en una tarea más de checklist que de testing.
Construir el mejor sistema VS romper el sistema: Promover un ambiente de trabajo necesario para poder mejorar lo que se está haciendo en vez solo intentar romper el sistema.
El equipo es responsable de la calidad VS el tester es responsable de la calidad: Primar la responsabilidad de la calidad del producto sea del equipo en vez de que la calidad recaiga sobre un solo rol, el tester.
Las pruebas continuas utilizan esta visión integrando las pruebas al principio, manteniéndolas involucradas a lo largo del proceso de desarrollo. Lo que está claro es que cuanto más temprano se encuentra un error, menos daño puede hacer y menos costos generan al proyecto.
Estas propuestas de mejora, hacen que los testers estén buscando errores al mismo tiempo que pueden proporcionar información crucial sobre la usabilidad y las características del producto, si conjuntamente es complementando con la investigación del mercado y pruebas beta públicas, se garantiza que el producto entregado sea de alta calidad.
“Ninguno de nosotros es tan bueno como todos nosotros juntos” - Ray Kroc.
