Tranquilidad Paz Relax ¿verdad?

No puedo empezar este artículo sin antes agradecer a Víctor y a QALovers la oportunidad de contar a través de ellos, cómo el movimiento DevOps está ayudando a conseguir entregar software de mayor calidad en menos tiempo.

En un entorno donde cada vez contamos con más recursos y herramientas tecnológicas, y en el que el software no se limita únicamente a ordenadores personales y teléfonos móviles, sino que se amplía a un buen número de elementos que fomentan los hogares y ciudades “inteligentes”, los métodos clásicos de desarrollo y validación de calidad, se quedan obsoletos.

Se quedan obsoletos, en primer lugar, y como decía antes, por el elevado número de elementos que dependen del software en comparación a años atrás. En segundo lugar, porque, el avance tecnológico no recae únicamente en las empresas del sector IT. Y, además, en tercer lugar, se quedan obsoletos por la cada vez mayor necesidad de las organizaciones de hacer llegar sus productos al usuario antes que lo haga la competencia, cumpliendo siempre un mínimo de calidad.

Es por eso, que no es suficiente con entregar software rápido, ni es suficiente entregar software de calidad,  es necesario entregar software rápido y de calidad.

Y si algo está destacando en estos últimos años, y que cada vez ayuda a más corporaciones a al cumplimiento del anterior objetivo, es la implantación de la cultura DevOps.

Así que en esta serie de artículos vamos los componentes y claves que aporta DevOps a conseguir software que hace lo que queremos que haga, que al fin y al fin y al cabo es lo que buscamos en calidad.

Si hablamos de calidad, tenemos que empezar por el principio, y el principio del software en las máquinas es… el código. Por eso, la primera clave es enfocarnos en la calidad del código, ya que es el elemento en el que como programadores o QA’s vamos a participar en mayor medida.

Y para ello debemos seguir un modelo de inspección continua que permita validar, o en el peor de los casos, detectar defectos, en el mejor momento posible, al principio, pues como veremos a continuación, aporta una serie de ventajas.
 
1.    Qué es la inspección continua
La inspección continua, es el proceso de integrar el análisis de la calidad del código como parte del ciclo completo del desarrollo de software.

De esta forma, y al hilo de que el movimiento DevOps fomenta la cultura de la colaboración, el trabajo en equipo, mejorando los procesos y eliminando de barreras y silos que causan retrasos y defectos, la inspección continua es responsabilidad de todo el equipo que participa en el desarrollo del producto. Por eso, debe contar con el apoyo y el seguimiento de especialistas tanto del desarrollo de software, como de sistemas y de testing.

¿Y qué se debe corregir? Para responder a esta pregunta, una buena aproximación es la que ofrece SonarQube (sobre el que luego te contaré algo más) y su modelo de calidad enfocado en unos tipos concretos de evidencias.

Lo principal es encontrar dos tipos de defectos: bugs y vulnerabilidades. Si no tienes claro en qué se diferencian, debes saber que los bugs son aquellos elementos del código que causan que la aplicación falle (y seguramente lo hará en el peor momento posible), mientras que las vulnerabilidades son defectos que ofrecen a un posible atacante un agujero de seguridad que le permitiría realizar operaciones que no deseamos.

Estos dos elementos, bugs y vulnerabilidades, son los dos principales elementos que deben centrar nuestros en la inspección, pues ayudan a mantener un elevado nivel de fiabilidad y seguridad respectivamente, lo que se traduce en una mayor calidad.

Y el tercer tipo de defecto, menos prioritario, aunque nunca debe olvidarse, es el code smell, que son elementos del software que, no producen errores directamente, pero dificultan que el software sea mantenible y escalable, y que, por consiguiente, afecta directamente al nivel de mantenibilidad del software.

Así que, la inspección continua nos permite mantener a raya esos tres tipos de defectos inmediatamente tras escribir el código, por lo que habremos evitado la gran mayoría de defectos que aparecen en un software en producción.
 
2.    Ventajas de la inspección continua
Los objetivos de la inspección continua, como decía antes, se deben centrar en la detección temprana de los defectos, al principio del desarrollo, pero ¿qué ventajas te trae esto?

Gracias la inspección continua se consigue:

3.    Herramientas disponibles para realizar inspección continua
Las herramientas necesarias para poder integrar la inspección continua en tu ciclo de desarrollo, se dividen en tres tipos.

En primer lugar, una herramienta tipo “linter”, que ayude a los desarrolladores a encontrar defectos en el código en el momento de escribirlo (y que no llegue ni siquiera al repositorio), y que pueda servir, además, como elemento formativo que instruya sobre las buenas prácticas que se deben seguir.

En este caso, recomiendo usar Sonarlint, disponible para los IDE’s más utilizados y gratuitos. Aunque también la mayoría de IDE’s y lenguaje cuentan con el suyo propio.

Por otro lado, debes contar con servidores de automatización, que te permitan realizar los análisis de forma: continua (siempre que haya un cambio en el código), rápida (para que muestre los resultados lo antes posible) y desatendida (que no requiera la presencia de ningún miembro del equipo durante la ejecución, más que para validar el resultado al final).

Sobre este tipo de herramientas, las más destacables que podemos ver en estos momentos son: Jenkins (Open Source, gratuito y muy extendido), Azure DevOps (una herramienta cada vez más utilizada por las organizaciones de considerable tamaño) y Gitlab (que además de automatizar, te permite disponer de otras herramientas como repositorio, wiki, etc…).

Por último, y en este caso, quizá la más importante, es necesario contar con una herramienta de análisis de código, que te permita detectar los defectos que hemos nombrado anteriormente y muestre la información de la forma más clara posible.

En este caso, mi recomendación también es clara, SonarQube, pues cuenta tanto con ediciones gratuitas para los lenguajes más habituales, como con ediciones que cumplen las necesidades de las corporaciones más grandes, aunque utilicen lenguajes menos habituales. Pero la oferta de herramientas de análisis estático no acaba aquí, también te invito a que busques información sobre otras como Kiuwan

--
Y hasta aquí, el primer artículo de esta serie de DevOps Lovers.
Si tuviera que elegir el concepto más importante que quiero que te lleves de este artículo es:
Empieza por analizar el código de forma continua, tus usuarios te lo agradecerán 😉

AUTOR: Oscar Moreno

Hace unos meses, desde el tándem itegGO-QALovers, finalizamos una primera etapa de proceso de eficiencia de pruebas de software en una empresa líder del sector consultoría. Solicitaban un estudio completo de la situación actual y tras ello, una serie de pautas para que pudieran ser más eficientes y mejorasen el día a día de las personas involucradas en un proyecto para una corporación de derecho público de carácter social sin ánimo de lucro que tiene el propósito fundamental de mejorar la calidad de vida de las personas ciegas, personas con resto visual y personas con discapacidad de toda España.

También, esta solicitud venía dada por la necesidad de eficientar el proceso de pruebas actual y de este modo, aportar mucho más valor a la corporación sin ánimo de lucro en las entregas. Además, contaban con la intención de mejorar el acoplamiento de las pruebas de cara al trabajo con desarrollo y conseguir estar más cerca de las necesidades reales del negocio, aumentando los altos estándares de calidad que ya estaban realizando.

Este proyecto liderado desde la consultora especializada, tenía el objetivo de mejorar la percepción de la calidad del software entregado a la corporación, optimizar las inversiones de personas y tiempos en las pruebas requeridas para conseguir la calidad deseada, un menor esfuerzo en la estimación y planificación de las pruebas y la posibilidad de detectar defectos en etapas tempranas, además de una optimización y unificación de las técnicas de diseño y operativa de ejecución de pruebas.
Fue un proyecto realmente bonito ya que contábamos con un tiempo ajustado y de nuestra pericia y conocimiento dependía el poder ofrecer un diagnóstico unido a una serie de herramientas que pudieran ser realmente útiles y eficientes para todas las personas.

Durante las primeras jornadas, se estudio la situación y se trabajó en conocer a grandes rasgos el negocio. Esto sería indispensable para saber el tipo de pruebas y esfuerzos que se realizan en el proyecto. Además, se realizó un estudio exhaustivo del proceso de trabajo actual, realizando una serie de reuniones con los principales actores de él. Esto, nos dio una base muy potente para comenzar a trabajar.

Nos acompañó, durante todo el tiempo un experto en todo lo relacionado con el proyecto que queríamos acometer. Él, nos proporcionó todo el conocimiento suficiente, tanto a nivel de proceso actual como de conocimiento funcional.

Lo que se realizó en jornadas posteriores fue ir implantando diferentes pautas y controles de calidad que pudieran controlar todos los pasos que se iban dando, aportando información de valor que se usara con el cliente. Todo ello, se fue materializando en diferentes herramientas que y técnicas de uso inmediato y a corto plazo tras una formación.

El proyecto se dividió en dos ciclos, con las siguientes pautas:

Tras la realización de estos tres puntos, se acordaron una serie de direcciones relacionadas con las nuevas prácticas, unificando los criterios, adecuando una serie de ejemplos o plantillas y dando las pautas suficientes en la herramienta de trabajo, para que cada persona, pudiera utilizar cada tipología y sus pasos acordados.

 Tras ello, se definió un proceso completo de trabajo que fuera único para todas las personas del proyecto y extrapolable a cualquier área de la compañía.

Además, se realizó una herramienta creada a medida, permite detectar de manera temprana y tras el estudio realizado en los requisitos, que casuísticas ya están cubiertas y detectando automáticamente que porcentaje de cobertura tiene ese requisito, aportando a cliente final toda la información, por si hubiera que hacer un despliegue temprano por alguna problemática, asumiendo los riesgos bajo un determinado control y con coberturas adecuadas y detectadas precozmente. Junto con la herramienta, se aportó una plantilla personalizada para ellos y la herramienta de trabajo que permitía realizar un trabajo de realización de casos de prueba mucho más sencillo y eficaz, trabajando de manera unificada.

Tras ello, y de cara a poder tener baterías de regresión independientes basadas en despliegues tempranos, cubriendo zonas críticas, o de mayor valor para el negocio, se definió una matriz de criticidad y prioridad, enfocada a que se pudieran ejecutar los casos de prueba determinados por ella. Esto vino de la mano de una personalización en la herramienta de trabajo enfocada a estos nuevos campos que se dieron de alta y, por lo tanto, a añadir la información oportuna para poder trabajarla con este nuevo formato.

Para finalizar, se realizó una propuesta completamente nueva de informes y entregables que permitían englobar toda la información, aportando todos los datos de interés y valiosos para cliente y poder trabajar conjuntamente con métricas, estados y determinada información contrastada del resultado de cada entrega o evolutivo en concreto.

Pasadas unas semanas, se realizó un piloto con esta nueva forma de trabajo y se obtuvo un éxito rotundo en la eficiencia y eficacia de todas las técnicas y herramientas expuestas, mejorando los tiempos, la detección temprana y la ejecución de las pruebas de una manera unificada y adecuada. Además, acompañamos este proyecto con una POC, enfocada a automatizar los casos de prueba de regresión que se detectarían a lo largo del tiempo, con este nuevo formato de trabajo más eficiente y unificado.

Únicamente, nos queda dar las gracias a itegGO por confiar en QALovers como colaborador de procesos y metodologías de QA y a la consultora especializada por la acogida, la recepción de todas las pautas y la atención de cada una de las personas con las que tuvimos el placer de trabajar durante todo el tiempo que duró el proyecto.

Con el nuevo paradigma de utilización de dispositivos móviles frente a los ordenadores y portátiles, tenemos que hacer que nuestras aplicaciones funcionen en muchos dispositivos, navegadores o sistemas operativos. Realizar todo esto en modelos en cascada, es posible pero empieza a ser bastante tedioso.

En este punto, es donde entra en juego el modelo ágil y donde tienen que confluir las líneas del desarrollo y las de la calidad por el mismo camino y en estrecha coordinación. Para ello realizamos el trabajo en sprints que no es más que separar las entregas en pequeños trozos.

Este modelo trata de responder a los cambios tanto tecnológicos como a nivel de personas y se enfoca en un trabajo multifuncional y totalmente colaborativo. La rapidez se premia, pero siempre con calidad.

Una vez escuché a un gerente de tecnología que para diferenciarse de la competencia había que hacer las cosas mucho más rápido que la competencia. Ahora bien, sin una base perfecta de calidad, esto no llegó más que a hacer aguas, cuando se quiere entregar a los clientes rápidamente sin ningún control ni garantía de calidad…no existe otro camino que el fracaso absoluto. Este argumento es el que se suele utilizar para que las empresas se suban al carro de la agilidad, pero antes de ello, sobre todo bajo el punto de vista de calidad, deben de hacerse una serie de cosas antes.

Pautas previas a la adquisición de modelos ágiles

En primer lugar, para que se puedan realizar entregas de producto con una velocidad de crucero, la estrategia de pruebas debe de comenzar mucho antes. Para ello hay que poner énfasis en lo siguiente:

Prácticas posteriores a la implantación ágil

Las pautas previas, nos harán el realizar una transición exitosa entre métodos tradicionales y a los ágiles, pero hay que llevar a cabo una serie de buenas prácticas para que todo encaje y que todo el proyecto colabore con el fin de garantizar la calidad.

Estas prácticas  son las siguientes:

Todas estas pautas y prácticas requieren una participación activa y comprometida de todos los miembros del equipo y sobre todo una coordinación total para no dejar ningún cabo suelto. Para que todo ello se cumpla hay que hacer frente a los silos, acabando con ellos de raíz y forzándonos a salir de ellos, posibilitando un diálogo continuo, global y de confianza entre todos.

Cuando vamos a entregar un producto de software, se suele luchar entre un equilibrio entre la calidad y la fecha de lanzamiento prevista. Todos sabemos, y lo comentamos, prácticamente a diario, que probar el software es un paso crucial para garantizar que todo funcione tal y como fue diseñado.

Si no se siguen una serie de técnicas de estimación del tiempo de prueba, nos podemos encontrar con que los plazos previstos se incumplan y no se realicen todas las pruebas que quisiéramos para garantizar nuestro software.

Si esto ocurre, el presupuesto se dispara y comienza la tensión, ya sabemos que cuando el dinero está por medio, no puede pasar nada bueno. El presupuesto viene de un cliente, y si este, no recibe lo que a pagado en los plazos y fechas que se han estipulado, lo más seguro es que los nervios afloren y se pidan explicaciones. Aunque esto suceda, jamás podemos dejar atrás el proceso esencial de probar y garantizar la calidad del producto que queremos poner en producción.

Vamos a revisar como poder planificar el proceso de pruebas de manera adecuada.

En primer lugar, tenemos que leer y analizar la documentación del proyecto como tal, realizando reuniones, discusiones o debates con directores, gerentes o jefes de proyecto. Debemos de pasar varios días en esta situación para aclarar detalles, dudas, responder a cualquier tipo de pregunta y, sobre todo, no dejarnos nada en el tintero.

En este caso debemos de tener claras las pruebas que se van a realizar, que tipos de perfiles se van a necesitar, si son más enfocados en la automatización o no y, sobre todo, cuantas personas serán necesarias para poder garantizar la calidad con la mejor garantía.

Una vez que ya tenemos clara la planificación, los perfiles y hemos podido detectar y resolver todas las preguntas y cuestiones con todos los actores del proyecto, podemos hablar sobre las pruebas como tal y sus tareas.

Uno de los principales errores que se comenten a la hora de planificar y estimar proyectos de pruebas es el de solo pensar en la ejecución. Esto suele ocurrir con perfiles más enfocados en la dirección, que no saben exactamente que es lo que hay que hacer y no tienen mucho contexto del trabajo que realizamos. Pero, en una lista rápida, las tareas habituales que deben de tenerse en cuenta para estimar:

Estas tareas básicas son las que se deben de tener en cuenta, aunque pueden cambiar según el proyecto y la organización. Para ello, es muy importante estimar el tiempo de pruebas e incluir todas las tareas que pensemos de manera integral, esto nos dará un tiempo adecuado para cubrir todas las tareas o labores que se deben de hacer y no pillarnos los dedos.

Para realizar estas estimaciones, podemos utilizar 4 o 5 técnicas habituales que nos ayudarán a acercarnos lo mejor posible a la realidad y no llevarnos sustos de última hora.

1. Análisis de puntos funcionales: Cuando trabajamos con esta medida, lo que realizamos es el de añadir una serie de tallas o clasificaciones basadas en la dificultad de probar. Por ejemplo, del 1 al 5, siendo 1 lo más sencillo y 5 lo más complicado. Una vez que hemos “puntuado” las funcionalidades, tenemos que realizar la siguiente ecuación: (persona-horas)*puntos función.

2. Desglose de trabajo: si utilizamos este método, lo que realizamos es la deconstrucción del proyecto en elementos muy básicos (o elementales) y realizaremos una estimación de cada uno de ellos, que hará que esta labor sea mucho más sencilla.

3. Planificación Póker: es un método gamificado para estimar el tiempo de nuestro trabajo. Lo que haremos es dividir el proyecto en tareas muy individuales y una vez que se realiza esto, se sacan las cartas y se estiman con la numeración de cada una entre todas las personas del equipo sin revelar su resultado hasta después de la discusión.

4. Método Delphi: esta técnica se centra en realizar encuestas de especialistas en control de calidad para determinar una estimación “promedio” por cada una de las tareas.

5. Tres puntos: Dividimos el proyecto en tareas pequeñas, más en concreto en componentes básicos o lo más atómicos posibles. Una vez se realiza esto, se asignan los datos según estas tres propuestas:

E = (A + 4xR + B) / 6.

Estas técnicas de planificación, son una parte muy importante de la estimación que queremos hacer para nuestros tiempos de pruebas.

Sobre todo, tenemos que tener muy claro, que existen muchas labores o tareas alrededor de lo que son la ejecución de pruebas y que tenemos que contabilizarlas y hacerlas ver a todas las personas que forman el proyecto o incluso la organización. En mi trayectoria en el mundo de la calidad, me he encontrado con tijeretazos y cortes sustanciales al proceso de pruebas, dejando únicamente un tiempo acotado para probar sin, ni siquiera, el poder permitir la realización de un plan de pruebas adecuado o que se pueda entregar a cliente o incluso, el ver como cualquier tipo de problema es achacado al equipo de pruebas tras haber recortado de manera sustancial su tiempo y dedicación y no permitiendo hacer su trabajo de manera correcta.

Es realmente importante hacer ver este tipo de situaciones, ya que, son más habituales de lo que pensamos y pueden hacer que se demonice nuestra situación y que toda la responsabilidad y problemáticas encontradas nos lleguen directamente sin tan siquiera permitirnos ni defendernos.

Este panorama está cambiando y solo ocurre en “des-organizaciones” (como me gusta llamarlas) que no trabajan de una manera adecuada, ordenada y entregan a cliente proyectos inacabados, fuera de tiempo o con fueras de alcance que intentan repercutir a cliente sin que ni siquiera se den cuenta de ello. Nosotros, con nuestro conocimiento y experiencia, tenemos que cambiar las cosas, luchando contra viento y marea para que la calidad esté por encima de cualquier otra cosa y que nuestra satisfacción sea el trabajo bien hecho.

A lo largo de los años, he trabajado con mucha documentación de la que extraer información para realizar las baterías de pruebas y cada caso con un detalle, más o menos, completo.

En ellos , se suele detallar, a nivel funcional, como debe de funcionar el software que queremos construir, pero en muchas ocasiones, están cojos de información técnica o de posibles casuísticas. Hay empresas que solventan estas situaciones con mapas y modelos de cobertura completos, pero no es algo que siempre se vea.

Estos agujeros no contemplados o que son difíciles de detectar a nivel de requisitos, se llaman puntos ciegos.

Puntos ciegos en automatización
Ahora mismo, con los RPA, quedan cubiertos muchos puntos ciegos que antes no eramos capaces de solventar, como inspeccionar un pdf y comprobar que los datos son correctos o se ven bien, esto puede ayudarnos a cubrir esos puntos ciegos y detectarlos, pero no en todos los sitios existe implantación de RPA y herramientas como Selenium no pueden detectarlos.

Este grupo de puntos ciegos que nos encontramos en herramientas de automatización, también pueden solventarse con pruebas manuales (si, lees bien). Las pruebas manuales que a todo el mundo le resultan de la edad de piedra, efectivamente.

El encontrarnos con muchas herramientas de automatización y tener una implantación bastante amplia no quita que sigamos necesitando este tipo de pruebas, ya que lo que detecta el ojo humano, disculpadme, no lo hace ni dios.

Si al realizar una batería “completa”, no tenemos en cuenta estos puntos ciegos, hay casuísticas que se escapan y por lo tanto, tendremos defectos en producción que vienen dados por la falta de cobertura que nos brindan estas herramientas automáticas. Con esto, no digo que no se usen, si no que se hagan como apoyo y en su justa medida y que sean totalmente complementarias, unas con otras.

Puntos ciegos en pruebas funcionales
Al hablar de este tipo de pruebas, nos viene a la mente el nivel de cobertura que hemos conseguido con nuestro plan de pruebas. Habitualmente, tenemos defectos comunes, que suceden una y otra vez y que hay que cubrir con un caso de regresión y posteriormente automático y los tipos de fallos habituales en la plataforma, que suelen suceder al tocar componentes core o críticos.

En estos casos, solemos comprobar cambios en pestaña haciendo click, girar el dispositivo para ver como se adapta la aplicación o realizar inicios de sesión inyectando datos en la propia URL.

Aquí nos encontramos com problemas de apertura de casuísticas y que, en equipos jóvenes son más frecuentes, ya que se dedican a seguir los pasos, unos tras otro, pero no ha ver que hay a su alrededor y a “perder el foco”, con la realización de unas pruebas exploratorias controladas.

Esto, se solventa con herramientas de Test Management, como ALM Octane y deben de cubrir ese tipo de pruebas a las que las herramientas automáticas no llegan, como ese posicionamiento de la aplicación según se gire el dispositivo.

Si unimos las pruebas manuales con las automáticas, nos encontramos con una cobertura mucho mayor, solventando las casuísticas comentadas anteriormente y una serie de baterías de pruebas (ya sean de regresión o no) que se automatizarán para no dedicar el tiempo a tareas repetitivas o que nos hagan invertir demasiado en ellas.

Si esto, a su vez, lo unimos a una estrategia adecuada de cobertura de casuísticas, ya sea mediante un diagnóstico completo o un trabajo de heurística, no tendremos problemas de agujeros donde se nos escapen defectos.

Estrategias de mejora
En este punto, una vez repasado, a nivel general, diferentes puntos ciegos, vamos a comprobar y verificar ciertas estrategias para que esto no nos suceda, aunque es algo que ya hemos podido ver en párrafos anteriores.

Una tarea que suele ser bastante socorrida es la de sacar listados de 3,4 o 6 meses con defectos que se han escapado, centrándonos en que se rompio, no en la causa raiz de los mismos.

Despues, verificamos y comprobamos cuales son nuestros mecanismos (anteriores y posteriores) para reducir estos defectos o agujeros, ya sea desde la revisión estática de código, procesos humanos o automáticos y con herramientas o no. Si comparamos, lo ideal es hacernos la siguiente pregunta: ¿el proceso de control debería de haber encontrado el problema?

Tras ello, realizaremos una serie de acciones:

•     Trabaja mano a mano con las personas implicadas en ese defecto, ya sea el tester, el desarrollador y la persona que diseñó el requisito, encontrando que falló y que no se hizo adecuadamente para que se escapara el problema.
•     Una vez tenemos detectado que pasó, hay que revisar todo el proceso de calidad implantado y ajustarlo para que no vuelva a suceder.
•     Esto, nos dará que pruebas, controles, inspecciones y kpis hay que reestructurar para cubrir todo adecuadamente, implementando una nueva versión del modelo.

Al final, en algún momento nos encontraremos con un punto ciego, con un agujero en el software o con algún problema que ha escapado de todos los controles, pero si actuamos rápido, hacemos los cambios oportunos y sobre todo, cubrimos los problemas de manera adecuada, veremos como este tipo de “fallos” serán un aprendizaje continuo que nos hará no repetir estas acciones o adelantarnos a que sucedan.