Testing en cascada

En Abstracta trabajamos en diversidad de proyectos, clientes de todo tipo y en diferentes ubicaciones, con distintos contextos. Gracias a esto es que tenemos variedad de situaciones, hay proyectos muy ágiles que siguen Scrum o Kanban, y otros muy en cascada con etapas bien marcadas. En este post te quiero compartir la historia de Bárbara Salinas, de Abstracta, que nos cuenta sobre su experiencia haciendo testing en cascada en el proyecto que ha estado trabajando en los últimos dos años. Lo que quiero resaltar es que no porque sea en cascada significa que es malo o no colaborativo, todo lo contrario.

Desde hace dos años aproximadamente estoy trabajando en un proyecto muy desafiante. Es desafiante por varios motivos, desde el impacto que tiene para la sociedad, la cantidad de empresas y personas involucradas en el desarrollo, así como las metodologías con las que se trabaja. Una de las cosas que siempre decimos en Abstracta es que el agilismo es adaptarse al contexto, y si el contexto implica trabajar en un formato más parecido al tradicional o cascada, quizá agilismo en este caso sea adaptarse a eso, sin perder de vista los valores y viendo qué prácticas incorporar.

Como en este caso hay empresas de desarrollo tercerizadas y yo formo parte del equipo de testing que verifica en un entorno más cercano al de producción, ya que somos directamente contratados por el cliente que pone el sistema en funcionamiento, nuestro enfoque de pruebas es externo, independiente. Como tal, ha sido un proceso de testing en cascada y no por ello menos valioso o menos colaborativo. Quiero compartir aquí la experiencia de este proyecto, cómo han sido las tareas que fuimos realizando y aspectos clave para que hoy todos podamos decir que es un proyecto que se viene desenvolviendo de forma muy exitosa.

El trabajo que realizamos ha sido por etapas, las cuales describo a continuación. Veremos en cada etapa las tareas realizadas por testing en esa etapa.

Análisis de requerimientos

Esta primera etapa consistió en el estudio de la documentación del proyecto y las necesidades del cliente. Cuando empecé a trabajar en el proyecto me explicaron cuál era el objetivo y el alcance del proyecto y nos entregaron las reglas de negocio y toda la documentación. Era muy importante el estudio minucioso de la documentación no sólo para entender el negocio, sino también para verificar que las reglas de negocio estuvieran completas y claras y no dieran lugar a que se generaran dudas o formas de hacer diferentes para los desarrolladores. Esto era especialmente importante ya que habían proveedores de desarrollo diferentes.

Del estudio de la documentación surgieron un montón de preguntas que ayudaron que hubiese un mejor entendimiento del negocio y a que se hicieran cambios en la documentación para que esta quedara más completa y más acercada a la realidad del negocio. En este aspecto estamos viendo cómo en un proyecto de testing en cascada también se aplican enfoques ágiles de “shift left testing”, que en realidad se trata del clásico modelo en V.

En esta etapa realizamos flujos o árboles de decisión (si querés conocer esta técnica de pruebas podés revisar el capítulo de técnicas en el libro) que luego sirvieron como insumos en la realización de los casos de prueba y se agregaron a la documentación del proyecto.

Planificación de las pruebas

Después de conocer las necesidades del cliente y tener un acercamiento inicial al negocio, el equipo ya estaba en condiciones de planificar las pruebas.

Para realizar la planificación se tuvieron en cuenta los siguientes aspectos:

Identificar las funcionalidades a probar: Se correspondía con la migración de un proyecto que se encontraba operativo, pero la mayoría de las funcionalidades eran nuevas. Además había que validar los datos que se centralizaban en un sistema único (recordar que habían diferentes empresas involucradas). Conocer las funcionalidades a probar ayuda a clarificar el scope del proyecto y a su vez entender cuál es “el todo”, que permite tener una noción más clara de cuál es la cobertura para el negocio.
Definir la estrategia de prueba: Un aspecto a resaltar es que se consideraron solo pruebas funcionales por diferentes motivos, de scope, aspectos tecnológicos, etc.
Definir los criterios de aceptación de las pruebas: Se identificaron los criterios de aceptación de todos los requisitos funcionales.
Definir herramientas y su modo de uso: En el cliente se utilizaba la herramienta Jira para gestionar los incidentes. Se estableció la severidad del incidente en función de qué tanto afectaba al usuario final. Contábamos con un Trello donde quedaban planificadas las tareas de todo el equipo.
Definir infraestructura de pruebas: Se documentaron los procesos de instalación del software y manejo de las tres plataformas sobre las que se iba a realizar el testing.
Determinar las necesidades de capacitación del equipo de testing: Fue necesario capacitar a algunos miembros del equipo de testing en el uso de las plataformas y la metodología de trabajo del cliente.
Establecer el procedimiento de prueba: Se realizaba el siguiente flujo de trabajo:
- Una vez que el proveedor entregaba una nueva versión de software, se seleccionaban los datos con los que se iba a probar.
- Se instalaba en la plataforma correspondiente.
- En función de lo que entregaba el proveedor se seleccionaban los casos de prueba a ejecutar teniendo en cuenta la prioridad establecida por el cliente.

Diseño de casos de prueba

Luego de realizar la planificación de las pruebas, comenzamos a diseñar los casos de prueba, tomando como insumo, como mencionaba antes, los flujos o árboles de decisión.

El negocio tenía gran complejidad, además de un montón de variables que en función del valor que tomaran, podían cambiar el resultado esperado del caso. Debido a esto se comenzó trabajando con casos de prueba de abstractos, que a la hora de la ejecución y de acuerdo con los datos con los que se fueran a probar se convertirían en casos de prueba concretos.

En la elaboración de casos de prueba es muy importante que el tester sepa combinar conocimientos sobre el negocio, habilidades técnicas y personales (comunicación, atención al detalle). Así es como lograremos identificar los valores límites y lo casos bordes de acuerdo a las reglas del negocio.

Ejecución de las pruebas

Ya diseñados los casos y teniendo en el ambiente de pruebas la versión de software instalada, es momento de ejecutar los casos de prueba para verificar cuáles de estos pasan o fallan.

Al ejecutar las pruebas el equipo tenía en cuenta los siguientes aspectos:

Lo casos de prueba a ejecutar.
Los datos de prueba.
La versión del software y la plataforma sobre la que se van a ejecutar las pruebas.
La documentación a generar con los resultados de la ejecución para tener claridad los casos que pasan y fallan.

La comunicación con el cliente siempre fue fluida, pero la transparencia dada en los reportes también se volvió fundamental y de mucho valor para el contexto complejo en el que se trabajaba.

Reporte de incidentes

Al ejecutar los casos de prueba se encuentran incidentes (registrando estos casos como fallidos). Estos incidentes deben ser reportados en la herramienta definida para darle seguimiento y que en la próxima versión del software se pueda evaluar si fueron corregidos o no. En nuestro caso como los desarrolladores no formaban parte del equipo, teníamos que, además de reportar en la herramienta, enviar un informe con los incidentes encontrados en cada iteración de pruebas.

Al reportar un incidente teníamos en cuenta los siguientes aspectos:

En qué funcionalidad fue detectado.
Pasos para poder reproducirlo.
Resultado esperado y resultado obtenido.
Sobre qué versión del software se identificó y con qué datos fue probado.
La severidad del incidente.
La prioridad que tiene su solución.
El estado en el que se encuentra.
A qué proveedor había que asignarlo.

El incidente debe de ser redactado de forma tal que la persona que lo está leyendo le sea fácil identificar dónde está ocurriendo y porqué. Toda información extra que contribuya a facilitar la tarea del desarrollador para resolverlo será bienvenida (capturas, logs, descripciones más detalladas, etc.).

Regresión de las pruebas

Durante la ejecución de pruebas encontramos varios incidentes bloqueantes, lo que no nos permitió en algunos casos terminar todas la pruebas que teníamos planificadas para cada iteración. Por tanto, ante una nueva entrega hubo que volver a ejecutar aquellos casos de pruebas que fallaron y el resto de los casos que se vieron afectados por ese fallo. A estas nueva ejecución le llamamos pruebas de regresión.

En el proyecto teníamos que realizar las pruebas de regresión de forma manual y con el mayor cubrimiento de pruebas posibles debido al impacto que tiene el sistema en el usuario final.

Entrega de informes de avances

En el proyecto teníamos que realizar informes de incidentes por iteración para todos los involucrados y además teníamos que mantener al tanto al cliente del estado de software para que le permitiera tomar decisiones, replanificar y buscar nuevas estrategias. En el informe se dejaba constancia de los incidentes encontrados, las pruebas que se habían realizado y cuáles no se habían podido realizar.

Para leer más sobre buenas prácticas de reportes de pruebas te recomiendo leer acá.

Pruebas de campo

Además de todas estas tareas realizadas durante el desarrollo del proyecto, se vio necesario realizar pruebas de campo para disminuir los riesgos en la puesta en producción. Esto fue principalmente porque se quería mitigar riesgos debidos a las diferencias entre las pruebas de laboratorio y lo que luego sería el ambiente de producción (el cual cuenta con una gran complejidad técnica y de dispositivos involucrados). Por esta razón se realizaron pruebas de campo donde se pudo verificar el comportamiento del software en un entorno real.

¿Certificado de calidad?

¿Podemos decir que con las tareas que realizamos podemos garantizar la calidad del software? A veces parece que el testing en cascada está pensado para dar el sello final, para “aprobar la salida a producción”. Para garantizar la calidad del software.

En realidad por más pruebas y regresiones que hayamos realizados no podemos decir que podamos garantizar la calidad. No nos olvidemos de nuestro amigo Dijkstra que nos enunció hace años que nunca vamos a poder demostrar la ausencia de errores. Es imposible simular totalmente todos los casos tal cual se dan en producción. Una vez que el software es liberado y puesto en manos de los usuarios debemos seguir dándole seguimiento al software para verificar que el comportamiento que tiene es el esperado y no entorpece el funcionamiento del negocio.

Estas pruebas de campo sirvieron para identificar incidentes que no se hubiesen podido detectar con las pruebas que realizamos en el ambiente de testing.

La combinación para el éxito en las pruebas

A modo de conclusión quiero resumir, más allá si se trata de testing en cascada o ágil, lo que yo considero es la ecuación para obtener buenos resultado realizando testing:

conocimiento + habilidades + experiencia

Los conocimientos, las habilidades y la experiencia que tengamos nos van a permitir realizar una correcta estrategia de testing y por tanto que obtengamos los resultados que se esperan de nosotros. Lo que significa que vamos a tener usuarios y clientes satisfechos.

Cada uno de los elementos de la ecuación se mejora con el tiempo y en dependencia de las ganas y el empeño que le pongamos. En el mundo de la tecnología y en específico del testing, siempre hay cosas nuevas para aprender, herramientas para utilizar que nos ayudan a mejorar las formas de hacer, así como habilidades para desarrollar. En la medida que desarrollemos cada una de ellas, sin duda, va a crecer nuestra experiencia.

Testing en cascada