Como profesional en proyectos Appian sabrás que unos de las constantes es encontrarse en continuos cambios de requerimientos y pequeñas mejoras.
Sabes que Appian es una plataforma amplia, unificada, repleta de soluciones y muy ágil.
A medida que el proyecto entra en mantenimiento correctivo, la cantidad de pequeños cambios se incrementa, impactando en cualquier parte de la aplicación:
TODO ES SUSCEPTIBLE DE CAMBIAR, incluso en aquellas partes que eran estables.
Ahora, las pruebas de regresión abarcan toda la aplicación! siendo más amplias que cuando el proyecto se está creando, que solo se centran en la parte nueva.
Consecuentemente, si las pruebas no están automatizadas, habrás visto que las pruebas son el nuevo cuello de botella de las entregas.
Todos los ojos están en el equipo de QA, al que tenemos que esperar que acabe, para subir la nueva versión.
En otras tecnologías, el equipo técnico no es tan rápido haciendo el evolutivo, y se compagina mejor con el de QA, pero en Appian, los cambios son muy rápidos y las pruebas ... depende!
La clave radica en cómo abordar y solucionar la regresión.
La gestión de la regresión impacta sin duda en la eficiencia, en la rentabilidad, y también en el éxito del proyecto, y por ende, en la fidelización del cliente.
¿Cuales son las medidas que tomamos más comunes?
En el caso que estés automatizando los tests, necesitarás implicar perfiles muy altos como un QA engeneering para que realice los cambios en los automatismos relacionados. Generalmente este perfil tiene un enfoque muy técnico y menos funcional. Su implicación constante suele ser costosa y no siempre tan reactiva o resolutiva. Suele ser habitual que el QA engenering esté llevando otros proyectos no Appian paralelamente.
En el caso de que no estés automatizando, implicarás testers manuales, pero como ahora hay que hacer regresión de toda la aplicación, o bien necesitarás más testers para tener las pruebas hechas a tiempo, o la regresión va a tardar significativamente más.
Para tener una gestión satisfactoria de QA hay que implementar un buen grado de automatización de test.
Entonces surgen siempre estas preguntas:
Si frente a la mayoría de los cambios, me supone casi más esfuerzo arreglar los test automáticos que realizar los mismos cambios... ¿porque debería seguir automatizando test?
¿Cómo puedo gestionar el impacto de los cambios en mis tests automáticos?
Deberíamos buscar un modelo en el que un pequeño cambio corresponda a un pequeño impacto en la automatización de los test….
Estoy seguro que estas son preguntas que nos hemos hecho todos los profesionales Appian.
Nos gustaría compartir nuestra experiencia adquirida al haber tenido la oportunidad de participar en proyectos destacados junto a excelentes profesionales en todos los niveles.
De entrada, por nuestra experiencia en el campo, podemos decir que hemos visto que todo proyecto Appian que supera los 6 meses necesita implementar test automático para minimizar desviaciones.
Entonces ¿cuales serían los puntos más importantes a considerar para implementar los automatismos de Test?
Especialmente si estás involucrado en proyecto de gran alcance, te recomendamos:
- Escoge cuidadosamente la herramienta de test.
- Entiende bien en que momento está tu proyecto.
- Evalúa el nivel de cambios que estás recibiendo y la excelencia del resultado
1. Herramientas
Herramientas Generalistas
Sabrás que existen multitud de aplicaciones y herramientas generalistas, cada vez más potentes, que permiten realizar una buena automatización de la regresión.
Para más información sobre las alternativas del mercado, te recomendamos este artículo
No obstante, la potencia (especialmente de las más caras) desde una perspectiva de proyecto BPM o de una experiencia en proyectos Appian, podemos evidenciar las siguiente ventajas y inconvenientes:
- Son herramientas dirigidas a facilitar la vida a QA engeenering, especialmente en proyectos con tecnología tradicional. Por lo tanto su grado de colaboración no es alto.
- Tienen una gran potencia técnica en problemas generales (reconocimiento de imágenes, procesamiento de texto, ...)
- Están pensadas para proyectos estables, con poco mantenimiento
- No siguen la filosofía Appian en cuanto a uso de componentes reutilizables.
- Suelen no estar orientadas a la construcción
Vamos a aportar unos ejemplos significativos siempre basados en nuestra experiencia real ya que nos hemos encontrado en varias situaciones en las que este tipo de automatizaciones han sido más un dolor de cabeza que una solución.
Mantenibilidad orientación Appian
En más de una situación, hemos visto como QA managers provenientes de proyectos fuera del mundo Appian, han implantado su solución de automatización centrándose en la regresión.
Tras hacer un gran esfuerzo técnico en la automatización, los constantes cambios en el desarrollo han hecho que ese esfuerzo no sirviera y se tiró la toalla, ya que no era viable seguir manteniendo el coste de licencia más el coste del QA Engeneering.
Cambio de versiones Appian
Como sabes Appian evoluciona la plataforma con 4 versiones cada año.
El cambio de versión de la plataforma puede tener impacto en el rendering de los objetos
Hay que considerar que la mayoría de las soluciones generalistas se basan precisamente en el rendering, en las posiciones de pantallas o en interntar buscarlas (más que entender los objetos de Appian)
Nos hemos encontrado recientemente como en un proyecto grande, automatiado con una herramienta generalista, potente y costosa, después de un cambio de versión de Appian que tenía impacto en el rendering, dejaron de funcionar todos los test de regresión!
¡Se tuvo que hacer un esfuerzo de testing descomunal para readaptar los test ya hechos, ya que quedaron todos inservibles y se replanteó la utilidad real de esta herramienta en el proyecto!
Especialista QA engeenering
Los QA engeenering, como seguramente sabes, son perfiles muy buscados en el mercado y muy caros.
Es muy complicado que podamos tener un beneficio de esta dedicación en un escenario de pequeños cambios constantes, pero dependemos de ellos si la herramienta es compleja.
Como más compleja sea la herramienta, más caro será el perfil y más nos costará mantener el proyecto en costes.
Herramienta especialistas
¡Aquí entramos en juego nosotros!
La experiencia que hemos acumulado en proyectos significativos de Appian, bien en el área de desarrollo, o bien en la automatización de testing, nos ha llevado a crear una solución que auna designers de Appian, QA y testers, manager, product owners y especialistas funcionales.
De hecho, nuestra solución AAT (Appian Automated Testing) puede resultar útil para cada participante del proyecto, ya que no requiere conocimientos técnicos ni implica la escritura de líneas de código o gestión tipo script. Está orientada a usuarios finales y presenta una visión funcional.
Frente a las herramientas genéricas que a menudo se implementan en los proyectos Appian, que después de algunos meses se abandonan debido a su falta de adaptabilidad a los cambios y la rotación de especialistas, nuestra solución ha sido altamente valorada por nuestros clientes ya que cualquier miembro del equipo puede entender y mantener los tests.
La evolución de nuestra solución tiene estas características principales:
- AAT es una herramienta específica, centrada en Appian.
- No es necesario tener conocimientos de programación, cualquier usuario, como por ejemplo un tester manual, puede usarla y llegar a crear test automáticos en poco tiempo.
- Está basada en el comportamiento y no en otros sistemas de reconocimiento (en este link hablamos de ello), es capaz de ser altamente reactiva a cambios.
- Gracias a sus componentes reutilizables, en cuestión de minutos se pueden cambiar componentes que afectan a decenas de test cases.
- Es colaborativa, es decir, todos los perfiles pueden aportar en el cliclo de testing. Es más, permite que cualquier usuario, desde el tester, al desarrollador, pasando por el Product Owner, sea capaz de ejecutar o incluso modificar cualquier prueba de una forma súper rápida y sencilla.
2. Momento o fase del proyecto
¿Estás seguro que tu estrategia de testing automático esta alineada con el momento en el que se encuentra tu proyecto?
Tener la visión de las etapas del proyecto hace que puedas adaptar la estrategia de testing dinámicamente.
Proyecto nuevo
La regresión en estos casos es mínima, aunque irá creciendo con el paso de los sprints.
Te recomendamos que sientes las bases del proyecto escogiendo una metodología BDD y una herramienta que lo soporte plenamente, como AAT.
Proyecto en cambio de fase
El cambio de fase es un momento excelente para entender que necesitas implementar una solución importante de cara evitar problemas de regresión en la nueva fase en la que estás entrando.
Ten presente que, a menos que hayas utilizado desde el principio BDD y tengas casi todo automatizado, es necesario que pienses seriamente como atacar la regresión. Con toda seguridad, no prevenir el esfuerzo de la regresión, te supondrá importantes desviaciones.
Proyecto en curso
Si tienes síntomas de que algo va mal, especialmente si se tarda en detectar incidencias o las UAT se van alargando cada vez más, sugerimos que no lo subestimes.
Aquí es donde las pruebas de regresión son más importantes y tienen más peso. Hay varia maneras de reorientar la gestión de QA. Pregúntanos para que te expliquemos cómo.
Proyecto en estado crítico
Si el equipo es nuevo en el proyecto y aún no lo ha hecho suyo, o si el proyecto empezó mal y ha ido siempre desviado, a la que coge volumen, se hace muy difícil de gestionar.
Es el momento de pedir consejo y ayuda.
Estamos a tu disposición para segundas opiniones, ayudar con las estrategias para reorientar el proyecto y estar a tu lado para encarrilar la situación, de manera que entre en una regresión controlada.
3. Evalúa el nivel de cambios que estás recibiendo y la excelencia del resultado
Si el proyecto está muy estable, no hay nada que decir... Pero si lo hay, piensa en las claves de la excelencia:
- BDD: crea el test automático durante el desarrollo, no esperes a que el desarrollo acabe, para que los designers puedan usarlo.
- Shift-left: el test debe ejecutarse constantemente. Como mínimo, cada noche, de manera que el equipo vea el resultado en la daily.
- Mantén el alineamiento Appian: 1 componente Appian = 1 componente de test. Mejorará la mantenibilidad del test.
- Ejecuta los tests en todos los entornos no productivos.
- Mantén auditorías periódicas en la calidad de tu código.
Si siques estos puntos, tu proyecto estará alineado con la excelencia y tendrás al cliente totalmente fidelizado.
Conclusión
Podríamos seguir hablando extensamente sobre nuestra experiencia con la regresión, abordando los aspectos clave de adaptación al cambio, pero para resumir:
En la mayoría de los proyectos Appian es conveniente automatizar la regresión, pero siempre contando con una buena estrategia y herramienta alineada con esta.
El QA debe estar siempre alineado con el enfoque Agile que proporciona Appian como plataforma. Perderlo es una de las principales causas por las que se deja de automatizar.
Los beneficios de la automatización de la regresión son múltiples: ayuda a aumentar la confianza en el proyecto tanto internamente en el equipo como de cara al cliente final, reduce los problemas de impacto debido a la rotación de personal, dinamiza y acelera los sprints y refuerza el valor de los entregables.
Para nosotros es importante confrontarnos con nuevas situaciones y animamos a que puedas plantearnos el marco de tu proyecto.
Ten en cuenta que generalmente una POC sin compromiso de una semana, es suficiente para encontrar elementos importantes y ver la viabilidad de soluciones.
Te esperamos!
