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.
0 Comentarios