¿Cómo enfoco el testing de forma ágil?

Implantaciones de Scrum, formaciones, cursos, congresos, empresas a las que vamos desde 233 Grados de TI… En la mayoría de las ocasiones o veo o alguien saca a la luz un problema recurrente: “estamos implantando Scrum, agilidad, pero al final…nos quedamos a medias. Seguimos haciendo el testing al final, no tenemos tiempo. QA siempre retrasa al equipo de desarrollo.”
Y efectivamente, en forma de pensar, creo que esta frase, se encuentra a medio camino entre un pensamiento tradicional y la agilidad, por ejemplo tipo Scrum.
En mi opinión, en un enfoque tradicional, QA y desarrollo son dos mundos separados.
Desarrollo va por una parte, y QA es el departamento que verifica, que da el visto bueno o no, tras el desarrollo. Son dos mundos: cuando desarrollo termina, lo que pase después no es problema suyo, a no ser que se encuentren errores.
Y viceversa. A QA no le tiene por qué importar el desarrollo, solo verifican que esté todo ok.
Pero cuando vamos a un proyecto ágil, la cosa cambia. Uno de los principales objetivos de la agilidad es mejorar la calidad del software, que tu empresa pueda moverse rápido: desarrollar poco a poco y contrastar ese desarrollo con el cliente (subiendo a producción en ciclos más cortos, p.e al final de un sprint de 2 semanas, cada semana, cada vez que hacemos un cambio etc.), para saber que vamos en buen camino y si no rectificar.
Para responder rápido, necesitamos un entorno altamente colaborativo. Equipos multidisciplinares, capaces de producir incrementos y mejoras en el software con la calidad esperada. En un equipo hay gente de distinto tipo:
– Una parte técnica (distintos perfiles de desarrollo, sistemas etc.).
– Una parte de negocio (Product Owner).
– Los testers, están entre la parte técnica y la de negocio. Ayudan por un lado a la parte de negocio a traducir lo que el cliente quiere en pruebas, que será lo que debe cumplir el software, lo que en definitiva tienen que implementar los desarrolladores.
Un tester ágil aporta una visión intermedia entre desarrollo y negocio: entiende el punto de vista del usuario, pero a la vez, tiene conocimientos a alto nivel de la complejidad que conlleva desarrollar software.
El éxito del equipo es conseguir aportar lo que el cliente quiere. Y para ello tenemos que colaborar entre todos y cumplir todas las actividades necesarias para terminar una funcionalidad.
– Si desarrollo termina de implementar algo, pero el Product Owner no da el visto bueno, realmente la funcionalidad no está terminada.
– Lo mismo, si QA no da el ok a la tarea.
– Si desarrollo espera feedback por parte de QA y no se lo da, tampoco es agilidad.
Etc.
Testers, desarrollo, Product Owner…Son un equipo con un objetivo común. Si una parte no termina, el trabajo de todos no ha terminado.
Por eso una historia de usuario no implica solo actividades de desarrollo, sino que el testing y las pruebas de aceptación (QA, Product Owner) deben estar incluidas en la definición de terminado de dicha historia.

La frase de “QA retrasa al equipo de desarrollo, la culpa es de QA,” no es un pensamiento ágil.

Si QA no llega, no termina a tiempo, también es problema de todo el equipo en general, igual que ocurre si desarrollo por algún motivo no termina a tiempo.
Aunque esto puede ocurrir por multitud de causas, si que es cierto que el enfoque del testing en el mundo ágil es un poco distinto al tradicional. No solo debemos probar al final del proceso.
El objetivo del testing no solo es detectar fallos, sino en la medida de lo posible, prevenir dichos fallos.
Por eso, la calidad, y el testing empiezan en fases tempranas de desarrollo, a distinto nivel (recuerda que existen distintos tipos de pruebas, no solo funcionales ¿Pruebas de integración, funcionales, de carga…? ¡Qué jaleo! ¿Qué diferencias hay?):
– Nivel más cercano al usuario: Verificar que se cumplen los criterios de aceptación de la historia de usuario (puede ser testing manual, o tenemos prácticas como BDD o ATDD).
– Nivel de desarrollador: Pruebas unitarias para prevenir que no haya errores a nivel del componente, de método, clase desarrollado.
– Por otra parte, dividimos el trabajo en pequeñas tareas, pequeños incrementos de código, que después se integran para que sea todo más sencillo que dejar la integración para el final. Hay que comprobar que esa integración no rompa nada del resto del software.
– Además, deberíamos buscar nuevas casuísticas. No quedarnos solo en verificaciones sencillas, sino en qué puntos podría fallar la plataforma (utilizando para ello el conocimiento de negocio y el técnico de los testers)
– Y no hagamos solo pruebas funcionales. Si las necesitamos, ejecutemos pruebas de sistema, de carga etc.
Los miembros del equipo deben considerar el trabajo del otro, trabajar en conjunto y estar informados.
En ciertas empresas ágiles incluso, fomento la regla de que cuando un desarrollador tiene alguna duda, no solo hable con el Product Owner, sino que un Product Owner y un tester estén presentes en la conversación. Y lo mismo ante una duda de un tester.

En testing ágil también entran las pruebas automáticas, para ser más rápidos.

Puede parecer que es invertir mucho en testing. Que es inviable en tiempo y en recursos. Que no puedes poner a un tester a verificar todas estas cosas, que no tienes personal.
Sí, es inviable tener a un equipo de testing manual ejecutando pruebas de regresión toda la plataforma cada vez que se hace una integración de código: es muy lento y muy pesado. Y ciertamente, creo que en esto desaprovechamos las cualidades de los testers.
Ahí es donde entra tener un balance entre pruebas automáticas y manuales.
Tener una batería de pruebas automáticas me va a permitir lanzar ciertas verificaciones muy a menudo y con resultados muy rápidos (por ejemplo, una batería de pruebas de regresión cuando el desarrollador integre su código en el control de versiones, gracias a una plataforma de Integración Continua).
Pero automatizar pruebas no significa que se elimine el testing manual.
Las pruebas que se suelen automatizar podríamos considerarlas verificaciones: una máquina no piensa. Los errores que podamos detectar con esas pruebas son errores que ya hemos detectado antes. O son lo que llamamos “happy paths”, las rutas más simples en las que una aplicación podría fallar.
Por eso, un tester manual es imprescindible. Automatizar esas pruebas va a facilitarle el trabajo a los testers, en el sentido de que pueden dedicarse al testing de verdad, nuevo, que vaya aportando valor en cada iteración: testeo de nuevas funcionalidades, búsqueda de errores más difíciles de encontrar, probar nuevas casuísticas. En definitiva, actividades que requieran más de su experiencia.
Por último, esas pruebas automáticas también ayudan a los desarrolladores.
Tener una batería de pruebas automáticas que se ejecuten y me den un informe de que “no he roto nada”, me proporciona más seguridad en lo que hago. Y esto es imprescindible para realizar refactorizaciones, mejora de calidad de código: tener algo que me garantice que los cambios que he hecho no han modificado el comportamiento del código con respecto a lo que había antes.

Esta es mi visión del testing ágil, donde la automatización de pruebas da para un próximo post.
¿Cuál es tu experiencia a la hora de integrar el testing en fases más tempranas del desarrollo, junto con la agilidad?

0 comentarios en “¿Cómo enfoco el testing de forma ágil?”

  1. Buenas tardes,
    Muy interesante el punto de vista dado.
    Pero con todo este tema me surge una duda a la hora de implementar el desarrollo ágil en una organización, cuando el proceso de calidad comienza con el descubrimiento y evaluación de requisitos.
    Esta parte del ciclo, a veces, no es precisamente ‘ágil’, se superpone con sucesivas etapas del ciclo de vida del proyecto, etc; pero sin embargo, un consistente repositorio de requisitos es imprescindible en una empresa para el buen conocimiento del negocio.
    ¿Cómo se podría agilizar la gestión de dichos requerimientos de los proyectos (a veces inexistentes…)?
    ¿Qué herramientas serían recomendables en este sentido dentro del desarrollo ágil?
    Gracias.

  2. Muy interesante el artículo. Creo que este es un de los mayores problemas que existe en sistemas.
    Por empezar, hace 10 años que trabajo en sistemas haciendo testing, y en todas las empresas se quiso implementar testing automático, y fue un fracaso, lo empiezan a usar y despuès queda en desuso.
    Por otro lado, cuando se estiman las tareas en el sprint, falta un líder que oriente a todo el equipo, generalmente se deja que los desarrolladores estimen su tiempo, y después se quedan cortos con el mismo, y atrasa todo el proyecto.
    En mi caso, cuando realizo testing con scrum, por el momento solo hago testing manual, con mucha comunicación con los desarrolladores, el owner y a veces el cliente para saber todo el funcionamiento del negocio.
    Con respecto a mi trabajo, documento todos los casos de prueba, y realizo un orden por sprint, y eso me va marcando en qué sprint se encontró un error y en cual se arregló, y también me marca durante cuántos sprint existe un error y todavía no se arregló, y esto me permite tener visibilidad para saber qué parte de la funcionalidad tiene más error y cuál no.
    Saludos!!!!

  3. Excelente post, tal cual lo mencionas en este artículo los comentarios dentro del equipo de desarrollo sobran para culpar al equipo de testing por la No entrega a tiempo de un producto, pero la idea en general es guiar a todos los integrantes del equipo y hacerles entender en que el equipo lo conforman todos, es decir, desarrolladores, product owner y testers.
    Tal como lo veo yo, meter un ciclo de pruebas manteniendo una metodología ágil, es solo cambiar los tiempos del proceso de testing, pero a su vez este proceso si no es controlado por el product owner, puede impactar en el desarrollo del siguiente sprint, debido a que testing no aprueba la ultima versión liberada y no permite avanzar con el siguiente sprint, con lo cual deberá ser un proceso bien controlado.
    Bueno desde ya muchas gracias por este post.
    Saludos Cordiales

  4. Es muy interesante el articulo. Creo que es muy importante mantener una comunicacion constante entre Cliente-Desarrollador-Product Owner y Testers; esto ayuda mucho a mejorias continuas, agiliza las pruebas y al final ganamos todos.

  5. Muy interesante el post, desde mi punto de vista conocer bien el negocio base (core), es lo fundamental para equipos como QA y Desarrollo, para empatizar como primera fase.
    Ya que si decimos que el cliente siempre tiene que estar involucrado desde un inicio, no obviar que el cliente o stakeholdes vienen con una mirada mucho mas amplia que muchas veces es desconocida por areas de desarrollo y equipos de calidad, lo que ya empieza a traer dificultades en entregables.
    Ahora el otro punto, que no se, si no se habla mucho o no aplica para metodologías ágiles, es el control de calidad al final de cada entregable. ¿ Ó el simple hecho de que el cliente este satisfecho, es suficiente para una puesta a producción de dicha pila de producto (o requisitos)?
    GRacias…

  6. Hola Javier
    Me gustaría que en algún momento nos pudieras hablar sobre la calidad para las PYMES. Normalmente leo sobre «equipos» de QA para test manuales y automatizados, pero ¿Cómo hacer cuando hay poco personal? ¿Que hacer cuando no se cuenta con el software adecuado para implementar testing? o ¿Qué camino se debe tomar cuando el testing no es de departamentos, sino de todo el equipo de desarrolladores?
    Gracias
    saludos

  7. Me gustó mucho el post y algunos comentarios. Me gustaría leer algo más del tema. Me recomiendan algún libro y/o artículo.
    Gracias

  8. Hola, muy buen blog estoy empezando en este mundo de Tester y QA me gustaría poder obtener más información sobre esta área, como crecer en este mundo.

    1. Que tal Pamela soy Test Manager, si estas iniciando y estas interesada en el Testing de aplicaciones te recomiendo la Certificación Foundation Level de ISTQB. De donde nos escribes?.
      Te recomiendo leer el libro: Agile Testing: A Practical Guide for Testers and Agile Teams
      Saludos!

      1. Hola Christopher, Gracias por la recomendación ya me han recomendado mucho la certificación, manos a la obra con eso!. Soy de Venezuela.
        Muchas Gracias
        Saludos. Si sabes o tienes algo más que compartir por compartir te lo agradecería!

  9. Gracias por la recomendación, ya he leído algo sobre la certificación.
    Gracias y si tienes algo más que compartir te lo agradecería. Soy de Venezuela.
    Saludos

  10. Que tal Pamela, una consulta muchas veces necesitamos realizar las pruebas de manera mas rapida, cual seria tu recomendación para probar mas rapido y mejor, con el minimo porcentaje de error.
    Muy agradecido de tu comentario.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba