Estrategia de QA:

Qué decisiones tomar al tener proyectos Appian.

En este articulo queremos resumir a nivel conceptual soluciones, necesidades y decisiones que a menudo deben tomar nuestros clientes

 

Preguntas del tipo:

Tengo que automatizar, o puedo seguir con el testing manual?

¿Qué le debo pedir a una herramienta de testing automático?

¿Cómo nos ayudan las herramientas recomendadas por Appian y hasta dónde llegan?

¿Cómo puedo combinar distintas tecnologías y salir ganando?

Si cambio de herramienta de test, ¿voy a perder todo lo que ya tengo hecho?

 

Bienvenido,

espero que puedas llegar a leer este breve articulo hasta el final,

lo que te voy a contar te ayudará en tus decisiones y puede tener un impacto significativo en la gestión de tus proyectos y en la eficiencia del servicio QA.

Empecemos!

 

Cualquier responsable de control de calidad, en los proyectos Appian, ha experimentado que intentar realizar pruebas manuales es cada vez menos eficiente:

Appian es tan productivo que, en pocos sprints, el contenido entregado aumenta rápidamente.

 

Si no queremos lastrar las fechas de entrega, nos encontramos pronto en tener que tomar decisiones como:

• Aumentamos los recursos dedicados al control de calidad. Es decir, aumentamos los costes.

• Optamos por tener que reducir la profundidad de las pruebas. Es decir, bajamos algo de calidad del delivery.

 

La opción más acertada y aceptada por los responsables de QA es:

• Vamos a automatizar los test.

 

Entonces, es cuando surge la gran pregunta:

Automatizar sí, pero ¿cómo?

 

La tecnología y los expertos siempre nos ayudan:

 

Los “Tecky” del equipo a veces tienen la tendencia de solucionarlo todo programando, por ejemplo usando los drivers de Selenium en una aplicación Java o Python para automatizar una navegación.

¿Por qué no? Somos desarrolladores, ¿verdad? y desarrollando a medida nada es imposible!

 

Bueno, definitivamente es un enfoque posible, teniendo bien presente que Selenium trabaja a un nivel muy bajo.

Por supuesto, permite un enorme nivel de control - para nuestros amigos desarrolladores – por otro lado, significa también que se necesitaran más expertos, que estamos viendo en el mercado laboral son cada vez más costoso.

 

¡Ok vale!, asumamos los costes siempre cuando haya resultados, ¿Verdad?

 

Lo que estamos viendo frecuentemente es que los resultados con este enfoque no llegan a cumplir con las expectativas. ¿Porque?

Los motivos son evidentes:

• La baja productividad, que provoca un alto coste.

• El escaso nivel de colaboración entre perfiles técnicos y el resto, incluso los desarrolladores Appian!

• La lejanía del enfoque de negocio que inevitablemente tienen desarrolladores de Selenium.

 

En definitiva, el enfoque “Tecky” es una opción, pero se está quedando pobre en comparación con otros enfoques.

 

Veamos a entenderlo con un un Ejemplo

Ponemos el caso que en nuestro equipo de proyecto tenemos expertos en Selenium.

Si usamos solo Selenium, podemos tardar fácilmente un día en automatizar una página Appian.

Sabemos que no se trata solo de que haga click en un enlace o que rellene un campo, nos encontramos fácilmente en casos como:

• Gestionar las sesiones.

• Obtener los datos de alguna fuente,

• Controlar que el contenido que vemos es el esperado.

• Guardar las evidencias adecuadamente…

• Puede haber un largo etc. de necesidades.

 

¡Todo ello no es tan fácil e intuitivo incluso si estamos empleando a un experto!

Por contra, hay herramientas que nos permiten la misma automatización en mucho menos tiempo.

Concluiremos que el uso de Selenium, como solución transversal para automatizar cualquier aplicación es poco eficiente, menos aún en proyectos Appian.

En cambio, puede ser muy útil en escenarios muy puntuales, donde no hay otra manera de automatizar una funcionalidad y se necesita todo el control de Selenium para conseguirlo.

Nosotros lo sabemos, porque entre otras cosas lo hacemos, siéntete libre de preguntarnos.

 

¿Podemos dar un salto, ganar más velocidad y ser más eficientes?

Herramientas de mercado genéricas

Por supuesto, se puede ir al mercado y buscar una herramienta. Hay una gran variedad de herramientas, desde herramientas de código abierto hasta herramientas realmente caras.

 

Cada herramienta tiene sus pros y sus contras.

Las herramientas baratas suelen ser herramientas de bajo nivel (cercanas a Selenium) con una funcionalidad limitada, poca colaboración entre el equipo y curvas de aprendizaje abruptas, con escasa documentación, si existe.

 

Por otro lado, las herramientas más caras tienen una gran versatilidad, pero pueden requerir un análisis profundo para averiguar si vale la pena invertir en ellas, por el coste de las licencias y la inversión en certificaciones.

 

El mundo QA está en continua evolución, existen herramientas de todo tipo:

• Basadas en RPAs

• Herramientas basadas en reconocimiento de imagen,

• Herramientas basadas en IA,

• Herramientas de registro de la navegación del usuario,…

 

Las herramientas genéricas están pensadas para solucionar cualquier escenario, luego son complejas, muy amplias y requieren perfiles especializados tipo ingenieros QA.

Hemos visto clientes comprando productos muy potentes, con la idea tener una herramienta válida para automatizar todo tipo de escenarios en múltiples tecnologías.

Naturalmente el objetivo inicial era el de ganar sinergias para amortizar costes. Pero la realidad de cada proyecto, especialmente en los proyectos Appian, es muy diferente.

 

La experiencia nos enseña:

• Hay que valorar donde es más conveniente automatizar y con qué urgencia.

• Evaluar si es conveniente la exigencia de automatizarlo absolutamente todo. Cada aplicación es distinta.
  

• Se puede tener un mix de acciones y herramientas que realizan una gestión de QA excelente y apreciada por los interesados en el delivery a costes razonables.

• Todo lo que se automatiza, es susceptible a cambios y mantenimientos, un coste que no siempre está previsto.

 

Hay que analizar muy bien cuál es el ámbito real de la automatización y el coste que va a tener. Solo entonces vamos a entender cómo amortizar nuestra inversión.

 

Por ejemplo, automatizar una aplicación en Appian es muy conveniente, porque se extiende muy rápidamente.

Pero mantener dicha automatización con un producto genérico que no entienda el comportamiento de Appian es muy costoso.

 

Si eres profesional de Appian, conocerás bien que el fabricante distribuye cuatro actualizaciones al año.

Cada cambio de versión puede romper todos los tests automáticos que se hayan creado con herramientas.

 

¿Qué pasa. si al cambiar de versión, Appian cambia la presentación de un componente? Ahora te lo cuento...

Vamos a ver qué enfoque tiene Appian

Appian tiene dos particularidades: primero - no nos cansaremos en repetirlo - es altamente productivo y segundo, como seguramente ya sabes ¡se actualiza al menos cada trimestre!

 

El fabricante realiza todos su esfuerzo para corregir y mejorar la Plataforma: Appian puede cambiar – para mejor – la forma en que representa las interfaces de una versión a otra.

 

Esto puede romper fácilmente todos los esfuerzos que realices en automatizar pruebas con herramientas genéricas.

 

Hemos visto con nuestros propios ojos un proyecto Appian, donde con una aplicación genérica de test automático muy conocida ... se han automatizado tests.

• ¡Los scripts de prueba no duraron ni un solo trimestre!

• ¡La primera actualización de Appian aplicada rompió todas las navegaciones que habían automatizado!

• En esa actualización, se cambió cómo se presentaban los calendarios para seleccionar una fecha, NO hubo nada que hacer aparte de rehacer la automatización de testing.

 

Estos tipos de cambios del fabricante, son continuos, ¡no se pueden evitar ya que generalmente proporcionan mejoras … el producto evoluciona!

Por ello evolucionan también las herramientas y las empresas de servicios especializadas como la nuestra…

Ahora te voy a contar que encontrarás en el Appian Market en cuanto a automatización de testing.

Appian Market

Encontrarás 2 herramientas ofrecidas de forma gratuita: FitNesse para Appian y Cucumber para Appian, las dos ofrecidas por el fabricante.

Un nota: Tenemos que tener claro que estas dos soluciones están en el marco “Tecky” es decir son para ingenieros desarrolladores de QA:

 

FitNesse for Appian (FFA) te obliga a escribir los comandos de test en un fichero de texto, con una sintaxis muy delicada, llena de símbolos “|” y sin un compilador que te avise de los errores.

El desarrollador va un poco a ciegas y hasta que no lo prueba, no sabe si lo que ha escrito está bien o no. No dispone ni de integraciones ni de extensiones de por sí, hay que montarlo "a mano" en FitNesse.

 

Por otro lado, Cucumber for Appian (CfA) es realmente un enfoque mucho mejor que desarrollar en Selenium, y es mejor que FFA, ya que tienes el compilador de Java, pero aún así sigue siendo un entorno exclusivo para desarrolladores.

 

Es algo paradójico que creemos una aplicación low-code en Appian y para probarla necesitemos un experto en Java.

 

Lo que vemos es que el fabricante ofrece una ayuda para que los desarrolladores tengan más “armas” y tengan un poco más fácil su tarea de desarrollo de automatismos de testing,

 

Si estas pensando adoptar estas soluciones ten en cuenta:

• Trabajan a un nivel bastante bajo.

• Necesitamos desarrolladores, para entendernos de los que trabajan en una consola negra para ejecutar las pruebas,

• Generando ficheros de log como resultado, a interpretar. Nadie de negocio lo va a revisar.
  

• El entorno es bastante sensible a fallos.

• Sin apenas capacidad de colaboración.

 

 

¡En el market de Appian encontrarás también nuestra solución!

¿Porque nace AAT?

 

En los últimos cinco años hemos visto como nuestros proyectos Appian se hacen más multi-disciplinares:

• Hay más “gente” y más variada involucrada en los proyectos,

• Cada vez el tamaño de las aplicaciones es mayor.

• La expectativa de entrega es más rápida.

 

Bajo este marco de evolución, necesitamos herramientas de alto nivel para que todo el equipo esté alineado en algo tan crítico como la calidad.

Necesitamos que las curvas de aprendizaje sean sencillas y que el equipo sabiendo Appian, tenga bastante.

 

Creamos AAT precisamente por huir de las pantallas negras y priorizar la colaboración resolviendo multitud de necesidades vividas en los proyectos.

 

Como partner de servicio de Appian hemos tenido la visión de reunir todo nuestro conocimiento y experiencia anteriormente mencionada en AAT.

 

Hemos creado una herramienta potente, low-code y colaborativa para todos los participantes en el delivery.

Hemos sido capaces – sobre todo por nuestra especialización – de satisfacer la metodología BDD y permite tener el test preparado antes del Desarrollo.

 

AAT surge del trabajo que representa cada día satisfacer proyectos complejos en clientes exigentes:

• Los retos que encuentran nuestros arquitectos en situaciones dispares.

• De las auditorías que hacemos a los clientes.

• De los imprevistos, cambios, errores que todo el mundo puede hacer incluido nosotros.

 

Así ha nacido AAT, aprovechando la experiencia y las facetas de todos los perfiles que trabajan en Appian y aprovechando lo mejor de las tecnologías del mundo Agile;

Es decir: de entender que el cambio es constante y no podemos depender de la localización, de la forma o de la posición que hoy tiene un componente porque seguro que mañana tendrá otra.

 

Nos hemos dado cuenta que:

• Que da lo mismo de si puedo o no grabar una navegación, porque mañana su forma será distinta,

• Que lo más constante es el comportamiento, y que el comportamiento y no la forma, es la clave.

 

Puedes encontrar más información en la web, en Appian Market pero sobre todo, siéntete libre de contactar con nosotros.

Nuestro equipo está especializado técnicamente, pero lo más valioso diría que es nuestra cercanía, la ganas de comprender, la disponibilidad y la orientación a solucionar.

 

Entonces no te cortes! Haznos preguntas como:

• Cómo puede un usuario sin ningún conocimiento de programación automatizar tests en Appian

• Cómo puedes construir un test antes de que esté acabado el Desarrollo.

• Lo robusto que es mi test, soportando cambios de las versiones de Appian y cambios en la forma de las pantallas sin que nos impacte.

• Cómo puede colaborar todo el equipo en la preparación y el mantenimiento de los tests

• Cómo puedes integrar tests que hayas hecho anteriormente por ejemplo con Selenium

• Y mucho más!

 

Seas técnico, seas director, analista, o developer, si te apasiona Appian siempre serás bienvenido