REF 1 KNOL, a unit of knowledge. Coronel, Fabiana Patricia. 17 de Mayo de 2009. Disponible en Internet: KNOL
He aquí los últimos cinco principios de un tester ágil.
Mejora continua. Responde al cambio
· Se auto organiza Foco en la gente
· Se divierte
Mejora continua |
El tester ágil y el equipo que integra están siempre en la búsqueda de herramientas, skills o prácticas que puedan ayudarlos a agregar valor o conseguir un mejor retorno de la inversión del cliente. Las iteraciones cortas de la metodología ágil hacen mas fácil probar elementos nuevos por unas pocas iteraciones y ver si es bueno adoptarlo a largo plazo.
Adquirir nuevos conocimientos y crecer profesionalmente es importante para un tester ágil. Toman ventaja de los muchos recursos libres disponibles para mejorar sus conocimientos especiales, tales como el testing exploratorio. Van a reuniones y conferencias, se unen a listas de correo, leen artículos, blogs y libros para conseguir nuevas ideas. Buscan formas para automatizar tareas repetitivas así tienen más tiempo para contribuir con su valuada experiencia.
Las retrospectivas son una práctica ágil clave que permite al equipo usar la experiencia de ayer para hacer un mejor trabajo mañana.
Responde al cambio |
En una iteración ágil de dos semanas, nosotros podemos decir:"OK, escriba una tarea para ello y lo haremos en la próxima iteración o la próxima release". El cliente ahora sabe que puede conseguir su cambio cuando lo desea porque él controla la prioridad.
Responder al cambio es un valor clave para la práctica de la metodología ágil, pero es uno de los conceptos más difíciles para el tester. La estabilidad es lo que más clama, entonces puede decir: "Lo he testeado, está listo". Los cambios de requerimientos en forma continua son una pesadilla para el tester. Sin embargo, tenemos que darle la bienvenida al cambio. El miércoles, podríamos esperar testear las historias A y B y luego la C el viernes. Para el viernes, el cliente podría haber repriorizado y ahora quiere las historias A, X e Y. Cuanto más nos mantenemos en contacto con el cliente, mejor se pueden llevar los cambios porque estamos trabajando al mismo paso que el resto del equipo, seguimos el flujo de trabajo y trabajamos con el equipo para adaptarnos al cambio.
El testing automatizado es una clave para la solución. Una cosa sabemos seguro: ningún equipo ágil será exitoso haciendo solamente testing manual. Se necesita una automatización robusta para entregar un negocio de valor en un marco de tiempo que lo haga valuable.
Se auto organiza |
La automatización del test es difícil, pero es mucho más fácil cuando el equipo entero trabaja en conjunto para ello.
Cuando el equipo se enfrenta a un gran problema, tal vez un showstopper en producción o un build que esta roto, es un problema de todos. Los errores de más alta prioridad son problemas para resolver por todo el equipo. Los miembros del equipo discuten el mismo y deciden cómo y quién lo resolverá.
El equipo en sí mismo desarrolla el plan mas útil para la situación.
Foco en la gente |
Los equipos que verdaderamente adhieren a la filosofía ágil le dan a todos los miembros del equipo el mismo peso.
El tester ágil sabe que contribuye con un valor único al equipo, y el equipo de desarrollo encuentra que es más exitoso cuando se incluye una persona con skills específicos de testing. Alguien con una amplia experiencia en testing puede formular preguntas importantes que no se le ocurrieron a los miembros del equipo. El conocimiento de testing es un componente de habilidad de cualquier equipo para obtener un producto con valor agregado.
Se divierte |
La metodología ágil recompensa al tester por su pasión en el trabajo.
Nuestro trabajo como testers es particularmente satisfactorio porque nuestro punto de vista y conocimientos nos permite agregarle valor real al equipo.
Importante para tener en cuenta cuando tenemos que migrar a una metodología ágil en nuestro trabajo como testers.
Desde mi experiencia personal, les puedo decir que testear con este tipo de metodología al comienzo no es fácil. Estamos acostumbrados a casos de uso que describen en detalle la funcionalidad y de repente nos encontramos con user stories que sólo dicen que es lo que un usuario en un determinado rol espera poder hacer con el desarrollo de la nueva funcionalidad. Pasamos de largas fases de desarrollo a cortas etapas en las cuales escribimos los casos de prueba y nos encontramos testeando a la vez.
Todo cambia y lo mas importante es adaptarnos a ese cambio continuo sin resistirnos a él. Es la clave para estas nuevas metodologías de desarrollo que estan en auge y continuo crecimiento
No hay comentarios:
Publicar un comentario