Estrategias de validación de código entre desarrollo y QA

En los últimos años, las pruebas son muchísimo más complejas de lo que venían siendo. Ahora hay test unitarios, pruebas de integración, pruebas de humo, pruebas automatizadas tanto con Selenium, por ejemplo, o ahora involucrando RPAs y, por supuesto, Testing manual, una pieza clave que no se tiene que perder jamás (aunque muchos piensen que ya está muerto, aunque ya escribiré un artículo tratando el tema).

Todas estas pruebas son muy diferentes entre si, pero tienen algo en común: el tiempo. 

A lo largo de toda mi vida laboral, os puedo asegurar, que en ningún momento he vivido un proyecto en el que, poniendo en una balanza los tiempos y entregas de otras áreas de trabajo, han sido comparables a lo que hemos tenido en QA. Habitualmente se le da poco peso, prisas, somos el último eslabón y se nos recorta este maravilloso elemento tan escaso en nuestra sociedad actual: tiempo.

¿Cuál es la solución para ello? Si te dedicas a QA, pensaras lo mismo que pensamos el 99% de nosotr@s: aprietas el culo y sacas el trabajo con sudor y sangre. Pero, evidentemente, esta no es la solución ni lo que debemos hacer. En estos tiempos en los que está tan de moda la integración continua, el DevOps y la entrega constante, nuestras estrategias deben de cambiar y adaptarnos al futuro y a un tipo de revisión algo diferente de lo habitual, manteniendo la esencia.

Una de las ventajas de las nuevas tendencias en el desarrollo de software, es la entrada en valor de los microservicios, que nos aportan un aislamiento y podemos tratar paso por paso y en etapas, los diferentes servicios del software, sin que se vean afectados el resto ni pongamos en peligro todo el proceso completo.

Otra de las ventajas de estas nuevas tendencias, es que, si se realiza una estrategia adecuada, el código y la cobertura puede llegar a ser muy alta, y tener una batería de pruebas muy completa y con resultados muy buenos. Involucrando esta estrategia en el plan de integración continua, podemos obtener unos resultados óptimos y la calidad del proyecto aumentará.

Lo más importante, ahora mismo, es que, dentro del marco de la integración continua, entrega continua o DevOps, como lo queráis llamar, aunque sean términos diferentes, es tener muy clara esta estrategia, y sobre todo definir ciertas pautas antes de comenzar el proyecto, tanto a nivel de cobertura de código, como de que herramienta se va a usar para la realización de los test. Esto, lo que hará, es que la funcionalidad en concreto, llegará mucho más estable y libre de códigos a las personas de QA que realizarán las pruebas posteriormente.

De cara a realizar la estrategia, nos tenemos que centrar en el estado de las pruebas que se van entregando en cada sprint o release, cosa que podemos mejorar con una evaluación sobre puntuación en las funcionalidades (o historias de usuario entregadas).

Esta evaluación se puede hacer en una pizarra con post-it, poniendo las funcionalidades del proyecto y una numeración del 1 al 5 (siendo 1 muy mala y 5 excelente) en base a la batería de pruebas realizada y el estado de las mismas.

Cuando se hace la entrega, se cogen las funcionalidades entregadas y vemos el estado. Si este es bajo, lo que haremos es priorizar las pruebas para ese sprint o entrega siguiente y aumentar la nota de la misma si se ha cumplido el resultado. La fiabilidad de estas notas las podemos comprobar con herramientas como SonarQube, donde mantendremos un porcentaje de cobertura de código y observaremos si este se eleva o no. Esta pizarra se actualiza a diario y se van poniendo riesgos o posibles pruebas que se puedan realizar y esto se le asigna a alguien del equipo, que cubrirá la prueba con un test unitario o de integración, aumentando así, la nota de la funcionalidad a lo largo del sprint.

Es muy importante el mantener unos estándares de calidad adecuados y una cobertura de test por funcionalidad lo más alta posible, tanto a nivel de porcentaje (que nos proporcionará cuando código no está probado), como a nivel de que la funcionalidad y el código que la genera realice, justamente, lo que tenga que hacer. 

Este trabajo, se debe de hacer entre desarrollo y QA, que son los que pueden aportar casuísticas de pruebas para que la funcionalidad se cubra de manera total a nivel de validación y garantizar la calidad.