El trabajo de los testers en Agile

El rol actual de los testers es más versátil que nunca, y requiere un amplio rango de habilidades. Los testers tienen tareas dentro del sprint, y también se encargan de programar. No necesitan especializarse en un solo lenguaje: mientras más conozcan, mejores soluciones podrán encontrar. Un buen ingeniero especializado en testing debe poder adaptar su conocimiento de acuerdo a las necesidades del desarrollo.

Teniendo esto en cuenta, y apoyándonos en la imagen inferior, podemos examinar en más detalle el trabajo de los testers y su distribución de tareas dentro del sprint. En métodos Agile, podemos considerar un sprint previo presente y futuro: el tester deberá encargarse de tareas de estas iteraciones.

• Ser parte de la reunión de planificación para el sprint actual. El tester debe encargarse de proveer estimaciones sobre la creación de datos, casos de testing positivos y negativos, ejecución de pruebas, diseño de frameworks y sus mejoras, configuración de entornos y más.
• Ser parte de la reunión de planificación para el sprint futuro. Antes de comenzar la nueva etapa, el tester debe informar sobre la creación de entornos de trabajo complejos, y sobre cualquier modificación o mejora al framework de automatización.
• Redactar criterios de aceptación para cada ítem del sprint futuro. Los testers deben crear criterios de aceptación para las historias de usuario, ayudando al Business Analyst mediante sugerencias sobre estándares, user experience, problemas de performance y posibles bugs. Dependiendo de qué tan Agile es el equipo, tendremos criterios de aceptación y/o casos de prueba (esto también depende de la compañía). Redactar estos criterios es una tarea realmente creativa, pero debe validarse con el equipo para que se adapte a los procesos.
• Actualizar los criterios de acuerdo a comentarios, y crear casos de prueba para el sprint futuro. Una vez que el tester recibe el feedback sobre los criterios, debe amoldarlos a los comentarios y críticas que haya recibido.
• Automatizar APIs (sprint actual). Si la aplicación está dividida en niveles, tendremos APIs, o servicios. El tester puede comenzar con el scripting antes de que los programadores terminen con su código en el sprint actual. En un primer momento, las pruebas fallarán, pero la situación cambiará gradualmente en tanto avance el proyecto (ATDD). Esta automatización puede lograrse mediante herramientas como SoapUI y Jmeter.
• Ejecutar criterios manualmente (sprint actual). Los casos de prueba deben ser ejecutados manualmente al menos una vez cuando cada historia de usuario se completa. La verificación manual nos provee una serie de bugs, una idea sobre las limitaciones del proyecto y sobre la importancia del caso de prueba. Además, esta práctica puede determinar los candidatos de automatización para el sprint futuro.
• Automatizar pruebas de interfaz (sprint anterior). Automatizar la interfaz de usuario una vez que la aplicación es estable puede ayudarnos a evitar muchos dolores de cabeza. En esta etapa, el tester debe encargarse de la smoke test para las funciones del desarrollo, y de las regresiones para los módulos complejos. Hacia adelante, esta prueba puede ser actualizada, agregando nuevas características.
• Pruebas exploratorias. Este tipo de testing puede encontrar bugs y errores que ninguna prueba automatizada detecta. No hay nada que pueda compararse con la creatividad del tester, y es por ello que debe aplicarse una vez por sprint.
• Ejecutar testing de Seguridad: El testing de seguridad es una validación clave para entregar un buen producto de calidad.  Validaremos desde encriptación de datos hasta XSS y demás técnicas avanzadas tratando de corromper la aplicación basados en  “Etical Hacking”.
• Ejecutar testing de Performance: Las pruebas de performance tienen que ser ejecutados en dos instancias al menos a lo largo de un proyecto. Una en una etapa intermedia del mismo, y otra previa a salir a producción en un ambiente lo mas parecido posible a la infraestructura del servidor real. En la primera instancia detectaremos grandes problemas de recurrencia entre usuarios y manejo de recursos.
• Ser parte de la reunión de review para el sprint actual. Los testers pueden encargarse de las demostraciones internas o externas. El objetivo es mostrar el compromiso del sprint actual, e idealmente no debemos mostrar ningún problema en vivo! En este sentido, el tester debe elegir el camino seguro e indicar los conflictos ya identificados anteriormente.
• Ser parte de la reunión retrospectiva para el sprint actual. En esta reunión participan todos los integrantes del sprint, identificando tareas bien logradas, cuestiones por mejorar y acciones para aplicar.