QALovers

José A. Esteban - CEO Ironia Fintech

Actualmente hablamos mucho de trasformación digital y parece que a base de repetirlo muchas veces va a suceder, a veces nos parecemos a esos niños de 4 años que repiten muy rápido y muchas veces lo que desean pensando que eso lo hace realidad. El problema es que ya no tenemos 4 años, y el mundo de la tecnología ha cambiado tanto y tan rápido que ojalá bastara solo con repetir las cosas para que se hiciesen realidad.

Si la tecnología y el mundo ha cambiado tanto. ¿Qué ha pasado con los procesos de calidad del software? Pues que han cambiado de igual forma por eso cuando conocí esta iniciativa de QAlovers me pareció que encajaba muy bien con la forma de enfocar la calidad en IronIA Fintech.

En estos tiempos modernos cuando desarrollas un producto tienes que asumir que no lo puedes probar 100%, si lo habéis leído bien; no se puede probar 100%, si es un producto web como nuestra plataforma de fondos de inversión tienes un conjunto de navegadores pongamos 50 solo teniendo en cuenta las distintas versiones de Google Chrome que corren sobre distintos sistemas operativos unos 5 IOS, Android, Windows, Mac y Linux y sobre unos 100.000 dispositivos diferentes tantos como móviles, tablets, ordenadores o incluso televisores existen en el mercado. Pensar que podéis abarcar toda es cantidad de pruebas solo demostraría vuestra ingenuidad.

Entonces debemos probar solo lo importante.

Estas frases que yo denomino “frase de concurso de mister/miss” son frases tan indiscutibles como inútiles, evidente que debemos probar lo importante, pero ¿Qué es lo importante? Y peor aun ¿Quién sabe lo que es importante? Sí yo le pido a un programado que me indique lo importante de nuestra plataforma casi estoy convencido que coincidirá con las funcionalidades que ha creado ella o el. Sí le pregunto al de marketing, lo mismo descubro que la plataforma no tiene nada importante y que las landing page son lo que hay que probar.

En IronIA Fintech decidimos preguntarle a nuestros clientes, ya que estábamos haciendo una plataforma para ellos lo mismo tenían algo que decir. Esta idea no es nueva se lleva utilizando mucho tiempo por eso como casi siempre la idea en si misma carece de valor, el valor esta en el como hacerlo. Ese “como” no es solo un trabajo técnico. Nosotros llamamos a esta iniciativa “Early Adopters” y para ella creamos un conjunto de elementos:

- Elemento Comercial: Creamos una suscripción de 3 meses por 9,99 lo que permitía a los clientes tener un 66% de descuento para probar la plataforma en real.

- Elemento de Reporte: Los clientes no son profesionales de calidad por lo que debemos proporcionar una forma sencilla de contarnos que les a pasado, o sea reportar un bug. Esto lo hicimos utilizando Microsoft Test & feedback (todavía podéis acceder a la página, aunque la iniciativa ya esta terminada: https://www.ironia.tech/test-feedback). Esta solución nos permitía que los clientes grabasen los pasos que daban y los errores que se encontraban sin necesidad de escribir más texto, además nos informaba de todo el entorno de ejecución por lo que nos resultaba mucho más fácil localizar los errores. Aquí tenéis un ejemplo de un error reportado por un Early Adopter.
- Elemento de Objetivo: Nuestro objetivo era detectar problemas sin tener un equipo de calidad especifico, es decir sin tener recursos asignados. Como podemos ver en la grafica adjunta el acumulado de errores detectado ha ido creciendo desde las primeras pruebas en abril; teniedo una fuerte subida desde mediados de junio hasta mediados de septiembre, cuando lanzamos el programa de Early Adopters y en la actualidad donde ya casí no encontramos errores y la curva se aplana (uff, creo que estoy viendo demasiado segumiento del COVID en tv) .

Ahora tenemos un conjunto de pruebas que señalan lo importante según nuestros clientes y podemos dotar de recursos para hacer esas pruebas antes de desplegar nuevas versiones, de hecho, la primera versión con este conjunto de pruebas ha sido la IronIA Fintech 1.5 que desplegamos el pasado 7 de septiembre.

Sin este enfoque todavía podríamos estar discutiendo cuales son los casos de uso importante, en que dispositivos debemos probar, etc. La única forma que conozco de eliminar incertidumbre es con información y en el mundo de la calidad hay que desarrollar formas que nos permitan medir; tan importante es tener las herramientas que miden, como la forma y objetivos de medición.

Si queréis que vuestros clientes aporten algo más que los ingresos de la compañía debéis generar dinámicas donde esa participación sea sencilla de verdad y donde a demás reciban algo a cambio. No es aprovecharte del cliente para hacer las pruebas se trata de escucharle para que sean ellos los que te indiquen que utilizan y que debemos probar.

En resumen, para saber lo que debes probar pregúntale a tus clientes, pero no seas torpe haciendo la pregunta mediante una encuesta o un grupo de control, la monitorización de tus aplicaciones web te permite saber como se comportan tus clientes y ese comportamiento te proporciona las pruebas que debes hacer, sí además empleas una herramienta que les permite probar mientras navegan, pruebas exploratorias, tendrás una metodología eficiente de obtener un conjunto de pruebas de tu producto.

Si quieres saber más, no puede perderte el webinar que impartirán el próximo jueves 17 de septiembre a las 18:00 h. y que te puede registrar desde el siguiente enlace: https://bit.ly/3lXc2JP

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

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.

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:

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.

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:

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.

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.

¿Qué te sugiere esta imagen?

Tranquilidad Paz Relax ¿verdad?

Las reglas...

Integridad

Ética

Sostenibilidad

Somos

Qalovers

Es hora de hablar de Calidad.

Nuestro Ecosistema 360º

QALovers

QALovers Xpress

QALovers Academy

QALovers Jobs

El Blog

¿Confías en tus clientes? Que te ayuden a probar

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

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

Pautas para realizar agile testing con garantia

Cinco técnicas para estimar nuestras pruebas de software

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

Buscar

Post populares

¿Con quien trabajamos?

¿Hablamos?

Móvil :

Email :

Dirección :