No soy yo muy de “check list”, hasta el nombre en inglés me parece feo, pero como todo, algun checklist de vez en cuando no viene mal. Así pasó hace un tiempo con aquel Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software, que hasta ha habido gente que me ha dicho que le ha sido de gran ayuda.
Así que, de nuevo, al igual que han hecho muchos otros antes de mi (por ejemplo aquí, aquí en testing o aquí), de nuevo arriesgándome a ello sin tener ni nombre ni apellido en inglés, quiero dejar mi aportación al mundo, en este caso, sobre cómo, en 3 min., de manera muy simple, saber si cuando dices, o te dicen, que -Hacemos Testing Ági – hasta que punto es así o de qué estamos hablando .
Las preguntas del Test podrían ser centenares, pero las he dejado en 7, y esas 7 son las que son. Cada pregunta se responde con un “sí” o un “no”, cada “sí” suma un punto. El orden de las preguntas y su numeración es indiferente en este test, lo que importa es la suma de “si” o “no”.
Haz el Test, que son 3 min., y cuéntame en los comentarios que puntuación (número de “si”) has sacado. ¡Suerte!
1) En tu equipo o empresa… ¿Testing dejó de ser, o nunca fue, una FASE para convertirse en una TAREA de uso común?
Recordarás, o si no, te aconsejo que lo leas, que no se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints), pero es más, es que el Testing no debería ni ser una fase, con un principio y un final, inamovible, al final del desarrollo, con mucha gente dedicada solo a ello, no, no… testing debería ser una, unas, tarea que se haga reiterativamente en cada sprint, es más una “manera de trabajar”.
Así que en este primer punto… ¿haces testing como una tarea dentro de cada Sprint o tienes una fase de Testing? Si contestas que sí a la primera parte de la pregunta… ¡apúntate un punto! Vamos, ánimo, al siguiente.
2) ¿Empiezas a hacer las pruebas ANTES de desarrollar (y no después de haber desarrollado algo), empezando el mismo momento que se están haciendo los requisitos (o historias)?
Lo que más finamente se viene a llamar el Test-Last vs Test-Driven. Tradicionalmente, en la antigüedad, las pruebas se hacían, se empezaban a hacer, después de tener aquello que debía ser probado, la aplicación (bueno, lo de empezar a probar antes de desarrollar es casi más antiguo, recuerda eso de “Utilizamos la novedosa técnica de TDD”… ¿Cómo? ¿Novedosa? ¿Seguro?). También se empezaba a trabajar en los antiguos casos de prueba una vez se habían cerrado los requisitos, cerrados estos, los tester hacían casos de prueba que lanzarán después de tener el desarrollo.
Dejar las pruebas para después trae un montón de problemas que ya te he contado muchas veces. En Testing Ágil las pruebas empiezan con los requisitos, historias, o incluso antes, haciendo escenarios desde los requisitos, y la automatización de pruebas se hace antes de desarrollar. No me extiendo más aquí, leete ¿Qué es eso de ATDD? o Entendiendo qué es BDD (Behavior-Driven Development) (I)
¿Otro punto más? ¡Ánimo!
3) ¿Todo el mundo Prueba o solo prueba el que tiene el “gorro” de Tester?
En proyectos muy tradicionales, los tester eran los únicos responsables de las actividades de prueba. En Testing Ágil, las pruebas es la responsabilidad de todo el equipo (muy al estilo de enfoques “sin ego” y que si en tu equipo existe la cultura de otro vea el trabajo que has hecho). Y hay coordinación entre perfiles más de Testing y el resto, siendo el resto la parte Product Owner y el resto del equipo.
Todo ello para ir más rápido, recuerda la teoría de los “cuellos de botella”, el equipo irá tan rápido como su parte más lenta, eso hace que no tenga sentido tener un único tester para n desarrolladores, lo que nos lleva a que no sólo el de testing prueba.
¿Sumas un punto más?
4) ¿Está la persona de Testing dentro del equipo?
Ya sabes de qué te voy a hablar, de equipos multifuncionales, aquellos que poseen todas las competencias necesarias para lograr completar el trabajo, sin depender de otros equipos, áreas, o roles fuera del mismo. Que no significa que todo el mundo dentro del equipo sepa hacer de todo, significa que el equipo en su conjunto es autosuficiente, si eso te dejo para ampliar aquel de los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad.
En el caso en el que estamos, y muy relacionado con el punto 3, si estamos en Testin Ágil, o testing con sentido común, las personas más centradas en Testing son parte del equipo, están dentro, se sientan juntos, etc. Esto excluye al Tester en una empresa separada de Testing, al Tester en un departamento lejano, etc.
Otro, aquí ya deberías llevar 4 puntos.
5) ¿Usas el “Definition of Done” y este incluye por naturaleza al Testing?
Cuando desarrollo y testing va cada uno por su lado, y no estamos entonces hablando de Testing ágil, suele suceder que el “Definition of Done” para desarrollo es haber desarrollado algo… pero no cuenta con que terminado es, además de desarrollado… probado.
Como siempre, te dejo más información del tema en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)
¿Sumas? Vamos al siguiente.
6) Además de Testing ¿haces uso de código limpio?
Ya sabes, calidad de código, revisión estática, aquello de Yo que tú vigilaría la deuda técnica (y sus intereses) que puedes estar pagando durante mucho tiempo o, si lo quieres simple, Sólo necesitas dos métricas para hacerte una idea de la calidad del producto software (y del dinero que puedes estar tirando) o, si usas Sonar, Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (2/3)
Recuerda, que el ciclo de vida ágil es incremental (añadir valor) e iterativo, limpiar, calidad.
Venga, que estamos en el penúltimo.
7) ¿Haces la documentación justa, útil, imprescindible y necesaria?
Algo típico del mundo clásico es el papeleo. Papeles por aquí papeles por allí. Aplicado al Testing, papeles, pdfs, con laboriosos planes de pruebas, Gantts, decenas de páginas con casos de pruebas, etc. La agilidad no dice que no se documente, pero, como bien dice Lean, cualquier documento que no aporte valor es desperdicio. En Testing ágil la documentación es muy controlada, recuerda aquello de Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos).
Ya sabes, menos papel y más Gherkin y Cucumber.
.
.
¿Qué tal? ¿Cuántos SI te salen?
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Hola Javier; el hecho de no hacer pruebas automatizadas no quiere decir que no esté haciendo testing ágil?
Eso implicaría no tener, por ejemplo, pruebas unitarias… difícil es un testing ágil sin pruebas unitarias…
7 de 7, ¡muy bueno!
4/7 mucho por mejorar todavía! 🙂
Hola, en nuestro caso las pruebas unitarias se hacen, pero son tarea/responsabilidad de los desarrolladores. El del gorro de «tester» no entra en ellas. Sí que ha revisado el documento que define el marco de estas pruebas (cómo deben ser, cual porcentage de cobertura exigimos .. etc) pero obviamente siendo unitarias las escribe los desarrolladores a la vez (o idealmente antes) de que escriben su código.
Que pinta el QA realmente en lo que se refiere a pruebas unitarias concretamente.
A parte de esto.. tendríamos un 7
Se me escapó el «?» al final de «Que pinta el QA realmente en lo que se refiere a pruebas unitarias concretamente.» 🙂
5 de 7… seguimos trabajando para logar el 7 de 7.
Gracias Javier por acompañarnos en este largo camino de la mejora continua en TI.