Algo que comentó al pasar Derk-Jan en su curso luego de TestingUY, que me resultó muy interesante, es que la mayoría de los testers jóvenes (los más nuevos) no pasaron por waterfall, y quizá dentro de algunos años, ya ninguno vaya a pasar por waterfall y van a comenzar todos directamente trabajando en entornos ágiles.
Nosotros (los que tenemos más de 30) seguramente pasamos la transición, trabajamos primero con algo tradicional y ahora estamos en ágil.
Esto implica que los testers más jóvenes tal vez:
- no se formaron en técnicas de diseño de casos de prueba
- no han trabajado con documentación
- no han trabajado con un proceso definido
Y como consecuencia, me imagino que no se verá de igual manera el valor que agregan las metodologías ágiles, que al menos a mí me pasa que les veo el beneficio de eliminar desperdicios… ¡porque he visto esos desperdicios!
De todos modos, algo que decía Derk-Jan y que apoyo, aún necesitamos entrenar a los testers con técnicas (sí, máquinas de estado, tablas de decisión, este tipo de cosas pueden ser usados en el testing exploratorio, no necesariamente son solo para usar con casos de prueba). Deberíamos formarlos para que tengan un panorama amplio y que así puedan definir buenas estrategias de prueba (y ojo, no me refiero a hacer un documento de 40 páginas).
La pregunta es, ¿cómo reinventamos el old stuff para hacer que sea nuevamente eficiente?
Es muy interesante lo que comentas, pero esto ya sucedía desde antes. En muchas empresas los testers junior entran y se dan cuenta que ahi no se hace documentación (ni desarrollo ni testing), hacen casos de prueba en planillas de excel, nunca fueron capacitados para ver maquinas de estado, tablas de decision, etc, el testing en esas empresas es como una tarea que alguien tiene que hacer para probar mas o menos lo que desarrollaron, y se le da poca importancia a la capacitación del personal. Este es el caso de gran parte de las empresas chicas en Uruguay, o por lo menos lo era hasta hace unos años.
Igualmente te digo… que hoy en dia la moda sea agile no significa tampoco que todas las empresas lo apliquen, es mas, hay muuuchas empresas que siguen trabajando en cascada. Todo lo que es bancos por ejemplo que tienen procesos muy estrictos (a ustedes seguramente les pase con Santander) por lo general trabajan en metodologias en cascada.
Yo creo que el tema de la documentación es complejo, a nosotros nos ha costado un poco, pero llegamos a la conclusion de que hay que hacerla pero que no sea tan especifica. Nosotros documentamos casos de prueba pero de forma mas simple, sin pasos. Esto es debido a que tenemos muchos cambios de flujo en un periodo relativamente corto de tiempo, lo que genera que tengamos que actualizar toda la documentación todo el tiempo. Como los objetivos de las features siguen siendo los mismos y lo que cambia es el flujo unicamente, no ingresando los pasos nos ahorramos el mantenimiento. Lo que si hacemos es usar diagramas de flujo (imagenes jpg generadas en el DIA por ejemplo) y entonces mirando los diagramas y los casos de prueba (practicamente en forma de checklist) podemos saber que probar.
Con respecto a la tecnica para generar casos de prueba eso me parece que te lo da un poco mas la experiencia por los proyectos que hayas pasado y la comunicación constante con compañeros de tu rubro, ayuda muchisimo las testinguy, las meetups, reuniones informales, etc.
Muy buen tema sacaste Fede!
Maxi! muchas gracias por el comentario!
Sí, creo que a lo que hay que apuntar es a un balance. Combinar testing exploratorio con algo al estilo casos de prueba, o guiones de alto nivel, checklists, algo que sea más fácil de mantener y a su vez útil para dejar claro qué quiero probar… pero seguro que es poco el contexto en el cual sirve tener todo súper documentado, ya que terminaría uno más tiempo en mantener eso que en mantener el código
Abrazo!
Che, quiero ver más posts en tu blog 🙂
Con esto de la Testinguy no he tenido tiempo para escribir, pero este finde vuelvo! abrazo grande!
Es justamente en algo que pienso todo el tiempo. Sí se encuentran algún plan de capitación, si lo debo proponer yo. En mí caso, soy de la vieja escuela. Y además un standard de ISTQB me da también esos conocimientos. Pero y el resto? Muy buen artículo!!
Hola Fabricio, gracias por el comentario.
Sí, ISTQB, o cualquier otra capacitación, es la base. El tema es la formación en el trabajo, en la práctica también. Cómo lograr ser ordenado en la agilidad, metódico, aprender técnicas y buenas prácticas para saber documentar lo justo!
Me ha pasado discusión con tester de la vieja escuela que reclaman los casos de uso para ejecutar las pruebas.
Que ven como negativo las metodologías ágiles porque dicen que no genera documentación. Desde mi punto de vista es todo lo contrario porque la narrativa de la historia va generando la documentación necesaria (la realmente necesaria).
No lo veo como cosas disjuntas, al contrario es parte del proceso para generar la historia.
Gabylán, cómo va?
Si, tal cual, apuntar a generar la documentación justa, ya sea en una conversación, en un documento, mindmap o lo que más le guste al equipo, pero no tiene que ser una cosa sí o sí porque eso dice el proceso…
Abrazo!
Pregunta, eso lo ves solo en los de la vieja escuela, qué ves en los de la nueva escuela? 🙂
Me pareció muy interesante el post y quiero compartir algunas cosas desde mi experiencia.
En el curso que hice de Testing nos enseñaban las técnicas tradicionales como maquinas de estado, tablas y arboles de decisión, clases de equivalencia, etc, y también en los proyectos que nos mandaban, nos pedían que documentaramos todo:
desde el plan de pruebas hasta el reporte final.
También en la UTU, en el bachillerato tecnológico especificamente, durante el proyecto que teníamos que hacer para egresar, los profesores nos inclinaban al desarrollo en cascada, con documentación super extensiva (500 páginas de documentación) y no nos mencionaban nada de Agile. Entonces me lleve una sorpresa cuando entré a Abstracta y empecé a conocer que todo eso que tanto me agotaba y molestaba un poco también, en realidad en el mercado laboral no se utiliza.
Es como que en el sistema educativo nos enseñan algo bastante atrasado comparado a cómo se trabaja hoy. Yo lo veía como algo negativo, pero ahora al leer el post me hizo reflexionar que está bueno que sea así porque nos da la oportunidad de conocer ambos mundos.
Qué bien! una tester joven 😀
Gracias Fer por el comentario, lo valoro muchísimo!
Ojo, no es que en el mercado laboral no se utilice, depende el proyecto (supongo que en algún cliente te podrá llegar a tocar algún día).
Yo me refería más que nada a los aprendizajes en la vida profesional, que como contás, arrancas trabajando en proyectos ágiles. En la formación supongo que aún están (estamos) los testers que pasamos por la vieja escuela, entonces los programas se van adaptando de a poco. El punto para mí es, cómo adaptarlos? Yo creo que las técnicas hay que estudiarlas, hay que tenerlas presentes. Lo de la documentación, ahí hay matices… deberíamos apuntar a ser críticos y analizar qué conviene en cada caso, y no solo documentar y documentar solo porque hay un proceso que dice que eso es así.
Saludos!!