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.

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

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.

¿Sabes que usos son los más adecuados para Gherkin y BDD?

A quien no conozca Gherkin, le podemos decir que es uno de los estándar para realizar pruebas escritas con un lenguaje muy sencillo y fácil de entender. Está basado en técnicas de BDD y se agrupa en:

•    Estado inicial: Nos preguntamos ¿Dónde?
•    Acción: Nos preguntamos ¿Cuándo?
•    Resultado esperado: Nos preguntamos ¿Entonces?

Toda esta información está agrupada en Escenarios. Este es un paso muy rápido sobre de que trata este lenguaje, de cara a hacerse una idea de lo que podemos llegar a hacer con él.

Cucumber, como herramienta, que está basada en Gherkin, tiene una muy buena perspectiva en una serie de situaciones, donde su utilización está más que recomendada:

•    Al dar de alta nuevas historias de usuario y sus criterios de aceptación, si utilizamos este tipo de lenguaje, podemos acordar con producto y desarrollo una serie de escenarios que sean válidos, completos y automatizables en un siguiente paso.

•    En algunas ocasiones, este tipo de lenguaje nos hará entender los motivos comerciales por los cuales se va a realizar o se ha realizado una funcionalidad en concreto. Es algo muy sencillo de entender, de llevar a la práctica y de trabajar para todos los perfiles que estén involucrados en el proyecto.

•    Es una manera muy sencilla de trazar los requisitos al código y a su vez a las pruebas realizadas, por lo tanto, podemos decir que estamos trabajando bajo una documentación viva que está actualizada en todo momento.

En ocasiones, tenemos que enfocar nuestras pruebas en el API y si ya tenemos Cucumber o alguna herramienta basada en Gherkin funcionando, que mejor que utilizarla para ello, algo que no es del todo recomendable.

Al realizar una prueba en el API, habitualmente llamamos a una URL y bajo una serie de parámetros, esperamos un resultado esperado positivo o negativo. En gran medida, no es de vital importancia como lleguemos a llamar a esa URL con esos parámetros, para ello hay herramientas como Postman que nos pueden ayudar a ello, pero en este caso, nos enfocamos en Gherkin.

En el caso de este tipo de pruebas, no es necesaria la filosofía de Gherkin con ese lenguaje natural ya que no aplica en la llamada a una URL que nos aporta un resultado. Si lo pensamos fríamente, no es relevante el manejar las preguntas expuestas más arriba para saber el resultado de una prueba de este tipo.

Cuando realizamos pruebas en un API, podemos tener dos objetivos principales, uno es la cobertura y otro es la funcionalidad (cosa que no debería de ser una prueba en un API).

Si por ejemplo, mandamos un dato vacio a un campo obligatorio, esperaremos un error que nos diga que hay que rellenar el campo, por lo tanto, no es necesario la realización de las preguntas: donde, cuando y entonces que usaremos en Gherkin.

Si estamos utilizando BDD para realizar nuestras pruebas, no solemos enfocarnos en una tecnología en concreto, si no más bien en la funcionalidad. Veamos algunos problemas típicos que podemos encontrarnos:

•    Si nos enfocamos en tecnología, esta puede cambiar a menudo, cosa que nos romperá las pruebas. Pero si nos enfocamos en la funcionalidad, las pruebas, seguramente no cambien con tanta frecuencia y el mantenimiento será menor.

•    Al escribir pruebas con Gherkin, solemos tratar el lenguaje de una manera demasiado prosaica, cosa que hace que sea accesible para todos, pero pierde el punto técnico, por lo tanto, debemos de enfocarnos a crear un tipo de lenguaje que ayude a que los desarrolladores entiendan las razones comerciales o de negocio de la funcionalidad que van a desarrollar.

•    En relación a las pruebas unitarias, las pruebas basadas en Gherkin, son más complejas de cerrar, ya que suelen llevar el estado entre métodos con variables, los IDE tienen una capacidad menor de depuración y en algunas ocasiones el trasladar ese lenguaje sencillo a código, es un poco complicado (a veces, juega en contra el como se entiende la frase en concreto).

Por último, diremos que Gherkin es un marco BDD integral, por lo que se debe de utilizar siempre en entornos de este tipo. En el caso de las pruebas API que hablábamos anteriormente, no tiene sentido que se realicen con este lenguaje, ya que se deben de orientar más a la solución técnica, en comparación con que al realizar BDD de este modo, nos enfocaremos más en funcionalidades de negocio.

Esperamos que os hayamos ayudado a tener una idea más clara de donde utilizar Gherkin y donde no para que sea realmente eficiente y su uso sea el adecuado, sin complicaros la vida en traducciones de lenguaje complejas a código y no invertir más tiempo de lo habitual.

Vuelve el Tester Funcional ¿o es que nunca se ha marchado?

Vuelve el tester funcional.

Efectivamente, has leído bien. En la época de la automatización, de los RPA, del DevOps, lo digo y lo reafirmo: el testing funcional ha vuelto con fuerza.

Puedo deciros, sin miedo a equivocarme, que jamás se fue. Éramos pocos los que seguíamos haciendo ese tipo de trabajo, pero ahora, es mas necesario que nunca.

Llevo meses viéndolo una y otras veces, empresas con unos procesos automáticos brutales, elaborados minuciosamente y con unas baterías dignas de los grandes, pero...con agujeros en producción. Errores graves y críticos que se cuelan y hacen que todo el esfuerzo invertido se quede en nada, además de que el cliente tenga una percepción negativa.

Os cuento lo que sucede.

Ahora todo es automatizar, hacer TDD, testing integrado en DevOps, incluso procesos completos con RPAs que se olvidan de las personas y manejan complejos proyectos de una manera ágil y especialmente rápida.

Viendo lo que se ha avanzado y lo que tienen algunas empresas montado, es digno de estudio y de, en algunos casos, hacerlos estándares y exportables de una empresa a otra.

Ahora bien, ¿que está sucediendo si estos procesos automáticos dejan estos agujeros en los productos que se elevan hasta el entorno de producción?

Pues, es tan sencillo como que la capa experta funcional se ha olvidado y no se cubren todos los caminos y se escapan. Mi experiencia, durante todo este tiempo, es que antes de hacer estos proyectos automáticos es que hay que hacer un análisis o un diagnóstico inicial, unido a un proyecto que realice una primera capa funcional en la que basarse todo.

Con este primer análisis, se realiza una batería completa, una documentación funcional y se crea la base total de lo que se tiene que automatizar con total garantía.

Además, aunque queramos realizar automatización de primeras en un proyecto, siempre, en la primera etapa, hay que apoyarse en, al menos, unas sesiones de pruebas exploratorias manuales que permitan cubrir, bajo el punto de vista de una persona, que todo está funcionando como debe de funcionar.

La realidad está ahí presente y no es la primera ni la segunda vez que encontramos esta situación y nos piden ayuda para averiguar que sucede con sus productos.

Volviendo a los orígenes.

La época de la automatización está presente y os digo que una persona dedicada a la calidad debe de saberla, casi por encima de cualquier otra cosa, pero también debe de aplicarse en formación procedimental, funcional y metodológica, ya que, si no, toda la fuerza que podamos aportar, acaba diluyéndose con estas situaciones inoportunas y engorrosas.

Ahora bien, nuestra intención no es decir que se tienen que hacer proyectos manuales, que la automatización es el demonio, ni nada por el estilo, si no que, es tan sencillo como que no se debe de olvidar el origen del testing y el conocimiento funcional o documental que hay que realizar, antes de nada.

El tester, debe de ser una persona metódica y concienzuda y muy enfocada a documentar todo, sobre todo, los casos de prueba (ya sea a nivel de código o en un documento). Estos casos de prueba deben de ser estudiados y extraídos de un documento funcional o requisitos que han sido entregados previamente.

Aquí, es donde se suele cojear, ya que en muchas ocasiones ni siquiera las personas que hacen esta batería de pruebas son tester, si no que son desarrolladores preocupados de la calidad o involucrados en equipos multidisciplinares.

Estos equipos, funcionan realmente bien en muchas ocasiones, pero como siempre se dice, no todo el mundo puede saber de todo y ser experto de ello, por lo tanto, una persona dedicada a una sola pata del amplio abanico del mundo tecnológico o informático, siempre aportará mucho más valor que una persona enfocada en varias cosas, que no puede llegar a ser experto de todo.

Desde aquí, hacemos un llamamiento a no olvidar ese conocimiento y labor funcional que puede salvarnos de más de un disgusto en nuestros proyectos.