¿Qué te sugiere esta imagen?

Tranquilidad Paz Relax ¿verdad?

Comunidad de QALovers Solicita una reunión

Las reglas...

Integridad
Ética
Sostenibilidad
Somos

Qalovers

Es hora de hablar de Calidad.

¿En algún momento has recibido una llamada de un cliente quejándose de que tu Software no funciona?


Una situación tan drástica puede llevarte a perder un cliente por un pequeño fallo en tu producto. ¿Puedes permitirte algo así?


Aquí, es donde puede ayudarte QALovers, permitiéndote cerrar el ordenador al acabar tu jornada y desconectar con la misma Tranquilidad, Paz y Relax. Sin miedo a recibir una llamada de ese tipo y ahorrándote sustos y sorpresas inesperadas.

¿En qué podemos ayudarte?

QALovers

Somos expertos en procesos y metodologías de QA, te ayudamos a crear tu Oficina de Calidad y a implantar una estrategia de pruebas adecuada para tu organización.

QALovers Xpress

La primera plataforma online que acerca las pruebas de software y los diagnósticos de procesos a todas las empresas de manera sencilla, asequible y transparente.

QALovers Academy

El primer ecosistema educativo online del mundo enfocado en la Calidad del Software. Formación de personas para personas: sencilla, eficaz y transparente y sobre todo asequible.

QALovers Jobs

Diagnosticamos el perfil profesional de forma gratuita para mejorarlo ofreciendo líneas de formación personalizadas para potenciar la carrera y crear una marca personal.

El Blog

Inspección continua - Empieza por analizar el código

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:
  • Agilizar el tiempo de desarrollo: Si eliminas los defectos en el momento de escribir el código, piensa por un lado en los procesos posteriores que se agilizarán: pruebas, validación, despliegues, etc… mientras que, por otro lado, es más fácil corregir errores si escribiste el código ayer, que si es un código heredado que ya tiene unos años.
  • Reducir los costes: Si, como decía antes, entregas el producto a antes gracias a la reducción de tiempo de posteriores procesos, los costes se reducen de forma directamente proporcional al no requerir de tanto esfuerzos ni personas implicadas.
  • Aumentar la calidad del producto: gracias a la automatización y que la inspección se realiza de forma continua, revisarás el código en más ocasiones, con lo que estás poniendo un mayor número de barreras a la aparición de defectos, y junto a la mayor facilidad en resolver errores, como mencionábamos en el punto anterior, se obtiene mejor software.

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

Mejorando la eficiencia del proceso de pruebas en una aplicación para personas con discapacidad visual

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:

  • Técnicas y mejoras de casos de prueba
  • Reutilización de pasos y casos, con una serie de herramientas
    personalizadas para la corporación.
  • Buenas prácticas, tanto a nivel general como personalizadas para el
    proyecto.
  • Criterios únicos, unificando todo el trabajo de equipo y donde se
    pudiesen realizar mediciones.

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.

Pautas para realizar agile testing con garantia

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.

agile testing

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:

  • Mentalidad: las pruebas tempranas tienen muchos beneficios, pero deben de tener un modelo de comunicación muy consensuado y potente, sobre todo para que todas las personas tengan en mente que el cambio en la manera de realizar las pruebas tiene que ser global. Las pruebas son responsabilidad de todo el equipo, sin distinción y que se comiencen desde el primer día, ya sea en su definición, estudio o elaboración temprana.

  • Flexibilidad: esto es algo que debemos de solventar desde el principio, ya que va a ser uno de los principales obstáculos a vencer. En los modelos tradicionales, cada persona tenía una función estipulada y la realizaba, pero ahora, esto cambia ligeramente. No existe un rol especifico como tal y se pude que cualquiera pueda ayudar en cualquier momento sobre las necesidades. Esto puede hacer que exista cierta resistencia que hay que vencer.
 
  • Documentación: en modelos ágiles, las pruebas automatizadas son necesarias y con ellas suele venir la predisposición a abandonar la documentación o a realizarla más ligera. Esto es uno de los peores errores que podemos cometer y hay que realizar revisiones periódicas para comprobar que se está realizando todo, de la manera adecuada. Con esto, hay una serie de herramientas, especialmente sonarqube, que permite realizar auditorias y validar el nivel de documentación técnica que se está realizando.

  • Colaboración: los equipos multidisciplinares que se requieren en enfoques ágiles deben de ser colaborativos al 100%. Si esto no existe, se puede caer en el error de trabajar en silos, lo que nos hará por llevar a romper el método ágil desde la raíz. Si no existe un trabajo conjunto entre desarrolladores y tester, la calidad y la entrega sufrirán.

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:

  • Desplazamiento a la izquierda: en los modelos tradicionales, las pruebas comenzaban después del desarrollo, pero actualmente la técnica del desplazamiento a la izquierda, nos dice que debemos de comenzar las pruebas antes de nada. Esto hará que identifiquemos defectos de manera temprana, solucionarlos y acelerar el ciclo de vida del desarrollo.

  • Integración de pruebas manuales con automáticas: es bien sabido que en entornos de este tipo, no podemos sobrevivir con pruebas manuales, pero no podemos dejar de hacerlas. Para ello, tenemos que realizar una estrategia mixta que nos lleve a garantizar el software con ambos tipos. 

  • Automatización: la validación rápida en métodos ágiles, además de las plataformas omnicanal, nos lleva a tener que introducir técnicas de automatización para validar las pruebas repetitivas como la regresión. Lo esencial es seleccionar las herramientas adecuadas y aprender a escribir los script sobre máximos de mantenibilidad. 
 
  • Pruebas continuas: la base principal de la introducción métodos ágiles es esta. Al existir una serie de ciclos de entrega más cortos, podemos llegar a decidir no invertir más tiempo en pruebas. Para ello, debemos de definir y poner en marcha un proceso continuo de validación que se ejecute en paralelo al desarrollo, creando una colaboración total entre desarrollo y testing para que se cumplan los requisitos al 100%, sin problemas. 

  • Virtualización: la necesidad de dinamizar los entornos de pruebas con diferentes cáusticas, nos lleva a tener que utilizar sistemas virtualizados, donde se han de simular variables de prueba para detectar defectos sin necesidad de utilizar la aplicación real.

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.

Cinco técnicas para estimar nuestras pruebas de software

Cuando vamos a entregar un producto de software, se suele luchar entre un equilibrio entre la calidad y la fecha de lanzamiento previstaTodos 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.

Estimaciones de pruebas

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:

  • Plan de pruebas 
  • Casos de prueba 
  • Ejecución de pruebas
  • Gestión del defecto
  • Verificación completa
  • Regresión
  • Pruebas exploratorias
  • Informe y resultado

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:

  • Optimista (A)
  • Pesimista (B)
  • Realista (R)

Tras ello, se puede saber el tiempo estimado (E) con la siguiente fórmula:

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.

Como la inteligencia artificial nos ayuda en la realización de pruebas más eficientes.

En la mayoría de equipos existen, aún, tiempos muertos o de espera que crea mucha frustración y desesperación. Esto es a causa de la ineficiencia en los procesos de entrega, complejidad, burocracia o incluso cuellos de botella.


Ni siendo puristas, ni utilizando elementos de integración continua, podemos evitar que existan atascos que vengan desde cualquier persona o equipo, aunque, habitualmente, el atasco y la problemática general suele tener un único culpable: el equipo o área de testing.

Hace ya bastante tiempo, si hablamos de pruebas puras y duras, nos convertimos en una pieza más dentro del ciclo de vida del desarrollo, pudiendo aportar, más o menos en el proyecto y empujando para que las cosas se hagan de la mejor manera. Desde ese momento, nuestro trabajo no ha cambiado demasiado, tenemos que preocuparnos en garantizar la calidad de las entregas, realizar pruebas (ya sean automáticas o no) y enfocarnos en que la caja negra que tenemos encima de la mesa esté funcionando lo mejor posible.

Realizamos planes de prueba que detectan defectos, confiando en que nuestra pericia y conocimiento del negocio en concreto pueda ayudarnos a detectar el mayor número de cosas y que todo salga perfecto. Tras ello, introducimos la automatización donde ahorramos tiempo, podemos mejorar el realizar tareas repetitivas con un solo Click, pero, en un punto, diría yo, de no retorno, esto se vuelve ineficiente y empieza a no existir un beneficio como tal. Este punto, que  invierte el coste y el esfuerzo, se da cuando la mantenibilidad que hay que dedicar a las pruebas es tal que no nos supone ningún tipo de beneficio el tener una enorme batería de pruebas automatizada que garantice nuestra puesta en producción. Si eso ocurre, hemos sobrepasado el punto de no retorno y estaremos invirtiendo demasiado sin beneficio alguno.

En la mayoría de los casos, la ineficiencia de las pruebas, viene dada por que existen áreas de código que no se han probado adecuadamente, no se han visualizado o no tienen una cobertura de pruebas adecuada que permita garantizar todas las casuísticas que se quieren probar o se deben de controlar.

En este caso, si introducimos procesos de IA, la cosa cambia y podemos aportar un cierto punto de inteligencia que nos haga detectar casuísticas extrañas y que no se escape ningún camino sin probar adecuadamente.

La inteligencia artificial funciona mejor cuando tiene una gran cantidad de puntos que analizar, ya sean datos o elementos recurrentes. De esta manera, encontrará tendencias, realizará predicciones e identificará casuísticas que puedan probar lo necesario o solucionar agujeros que, hasta ese momento, eran muy complicados de detectar.

El cambio de paradigma con este tipo de sistemas y herramientas es más que satisfactorio y se están convirtiendo en un potencial amigo de los tester que las apliquen en sus proyectos.

El principal foco, es que esta IA aprende constantemente y puede llegar a comprender como se está ejecutando el código, como interactúan aplicaciones o como se relacionan terceros entre si para que una funcionalidad en concreto funcione como debe. A esto, hay que sumar la gran rapidez de lectura y procesamiento de información que permite bajar el tiempo de realización de pruebas de una manera más que considerable, pasando de minutos a segundos en un abrir y cerrar de ojos.

En este caso, si nos ponemos puristas, al introducir algún tipo de IA en nuestro proceso de pruebas, en el que, mínimamente deberían de existir tres controles de calidad con ejecución de diferentes pruebas (ya sea el análisis de código, las pruebas unitarias y las pruebas funcionales), con este tipo de sistemas, se permite comprender diferentes interactuaciones, procesar todo tipo de datos en segundos y permitir que se valoren y traten que zonas de la aplicación tienen mayor riesgo de fallo o una tasa más alta de mal funcionamiento a lo largo de todo el código. Esto, detectará que zonas no tienen una cobertura adecuada y nos permitirá poner el foco en solucionarlo y ampliarla para que no tengamos un agujero en nuestro software.

Desde el punto de vista del tiempo invertido, si introducimos procesos de ejecución de pruebas con IA e incluso, con RPA, se reducirá de manera exponencial y podemos invertir el tiempo extra en ampliar o consolidar baterías de pruebas ya realizadas.

La visibilidad que podemos ganar con la introducción de sistemas de inteligencia artificial es enorme, pudiendo utilizar diferentes datos recopilados para identificar código modificado o cambiado, definir de manera automática las ejecuciones de pruebas que han de lanzarse o que conjuntos de prueba son más factibles de utilizar en base al despliegue o zonas modificadas del código.

Este nuevo enfoque nos cambiará la visión de manera total, siendo, más bien, una manera de encontrar defectos más rápido, permitiendo ciclos de retroalimentación más robustos y haciendo que podamos garantizar la entrega de una manera mucho más sencilla y con una inversión de tiempo, considerablemente menor. El futuro de la inteligencia artificial es aún turbio y no podemos saber cual será el próximo paso, pero si sabemos que puede ir dirigido a los micro servicios y a revisiones de informaciones mucho más complejas y detalladas.

Sobre todo, si que podemos saber que cuando más demanda exista de puestas en producción más rápidas, tiempos de ciclos más cortos y velocidades de crucero mucho más rápidas, el introducir sistemas de IA en nuestros proyectos será la única manera de poder mantener todas estas casuísticas y que no vuelvan a aparecer cuellos de botella o ralentizaciones incómodas en los ciclos de vida de los desarrollos que tenemos que probar.

El futuro ya está aquí y debemos de ser capaces de adoptarlo y ponerlo en práctica en cada proyecto donde nos involucremos.

¿Como solventar un agujero funcional en nuestro software?

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.

¿Hablamos?

Pulsando el check estas aceptando la Política de Privacidad: