PoC - Cómo ganar siempre con una Prueba de Concepto

¿Cómo ganar siempre haciendo una Prueba de Concepto con AAT?

¿De qué sirve hacer una Prueba de Concepto? ¿Qué tengo que tener en cuenta? ¿Qué conclusiones espero obtener?

Todos los que estamos en proyectos Appian, vemos como la dedicación de los testers se tiene que ir ajustando en aspectos concretos: picos en las entregas, incremento progresivo para hacer las pruebas de regresión…

Y cuando tenemos que empezar un proyecto, honestamente, la calidad no suele ser el tema más prioritario, ni el testing manual, ni el automático (mira nuestros artículos en este blog), pero…

Pero sabemos que va a ser algo fundamental y que va a requerir una carga de recursos concreta, que tenemos que dimensionar, y sabemos lo que ocurre si no acertamos el dimensionamiento!

Si tienes mucha experiencia en proyectos Appian, podrás dimensionar bien tu equipo de QA. Generalmente, si el equipo de desarrollo tiene experiencia, los requisitos están más o menos bien, y no automatizas, necesitas aproximadamente 0.4 testers por designer.

Y si automatizas… ¿Tienes suficiente experiencia en el producto que vas a utilizar para dimensionar el equipo de QA? Generalmente, la respuesta es que no, ya sea porque tienes experiencia en el producto pero no en proyectos Appian - donde el ritmos de cambios es más alto que en otras tecnologías - o al revés, por que tienes experiencia en Appian pero no en el producto.

Este es precisamente el objetivo de una PoC (Proof Of Concept, o Prueba de Concepto).

Con una PoC debes confirmar la ruta que estás tomando, lo ágil que te hace, lo rápido que progresas, cómo se adapta a tu metodología, cómo participa todo el equipo y el retorno que te va a dar.

ETAPAS:

Una PoC no deja de ser un pequeño proyecto, y si quieres sacarlo todo el jugo y que sea realmente representativa, hay que prepararla bien.

Vas a tener que ir progresando por un conjunto de etapas que te comento un poco en detalle.

Análisis previo general

Debes pensar en las características del proyecto.

Por ejemplo, no tiene nada que ver una nueva fase de un proyecto existente, que el empezar un proyecto desde cero. Hay mucha diferencia en heredar un proyecto de otro proveedor que no ha renovado, a un proyecto para cambiar de infraestructura de una aplicación.

Tienes que identificar la calidad de los requisitos, el volumen de cambios, la experiencia del equipo, los objetivos de negocio, las restricciones de calendario y presupuesto… todo!

Con esta información podrás diseñar el marco en el que ejecutar la PoC y un primer conjunto de exigencias que le vas a hacer a tu herramienta.

Selección del caso típico

Si en el punto anterior tocábamos aspectos más de arquitectura, aquí bajaremos a los aspectos prácticos del diseño: tenemos que escoger el caso típico que va a representar el porcentaje de uso más alto.

No es efectivo, cuando buscamos herramientas de automatización, pensar en casos especialmente complejos si representan una situación excepcional en el proyecto; siempre hay el que sugiere poner una funcionalidad muy difícil de automatizar para ver si la herramienta es suficientemente potente.

Esto, en general, es una pérdida de tiempo. Si algo es muy difícil de automatizar, no se automatiza y punto.

El objetivo de la automatización es poder cubrir una cantidad muy alta de funcionalidad de manera muy rápida y que sea muy fácil de mantener y adaptar a los cambios que surjan. Aquí es donde voy a tener un impacto realmente importante en el retorno de la inversión.

Los casos excepcionales impactan 0 en el total.

La preparación y tus requisitos a la PoC

Por ejemplo, si tu proceso está analizando operaciones que se tienen que validar

  • Escoge una operación de alta, que suelen ser como se inician los flujos de este tipo

    • Mide lo rápido que un tester sin conocimiento de programación lo pueda automatizar. Una pantalla normal no debería tardar más de 5 minutos

    • Mira lo sencillo que va a ser para un Product Owner entender el test generado. Debería poder reconocer las acciones y las validaciones que hay

    • Asegura que puedes crear el test sin tener que esperar a que el designer haya creado su contenido, que te puedas adherir a una metodología BDD sin problemas.

    • Valida cómo se enlaza con tus historias de usuario. Deberías tener una visión funcional.

    • Prueba cómo te genera las evidencias: ficheros word con capturas, videos de la navegación, integración con suites de test tipo ALM, etc.

    • Y ahora, haz que cada miembro del equipo pruebe a ejecutar el test: designers, analistas, el Product Owner y los testers. Todos deben poder ejecutar un test.

  • Simula un cambio de requisitos

    • Cuenta qué rápido cualquiera del proyecto, empezando por los analistas, encuentran los test que estén impactados por el cambio (análisis de impacto).

    • Haz que cualquiera del equipo mida el grado de impacto. No quieres especialistas, quieres que la calidad esté en todo el equipo!

    • Mide el tiempo que se tarda en hacer el cambio; por supuesto siempre tiene que ser mucho menor que en el lado Appian, menor que el impacto de crearlo por primera vez.

    • Y evalúa si en el lado Appian el cambio ha sido sobre un componente reutilizable, si ese mismo nivel de reutilización lo has tenido en el test.

  • Ahora simula un cambio de versión Appian.

    • Las herramientas generalistas de test, no entienden de Appian y no saben lo que es que todos los componentes cambien su estructura interna de un día para el otro. Cada vez que hay un cambio de versión, puede que el rendering de un objeto Appian sea distinto

    • Si la herramienta que estás evaluando no entiende de Appian, todo lo automatizado puede dejar de funcionar.

    • AAT tiene un parámetro de configuración donde indicas en qué versión de Appian estás, soportando desde la 18.3 hasta las más nueva. El cambio de versiones es transparente para ti.

  • Ahora evalúa la “industrialización”

    • Presupuesta delegar la creación de un test en un profesional externo

    • Mide la curva de aprendizaje de los distintos perfiles que tienes disponibles, en tu empresa o en el mercado, con y sin experiencia en programación

    • Evalúa que comporta añadir nuevos entornos, migrar a un entorno local sin conexión a Internet, si necesitas de bases de datos u otras infraestructuras, etc.

    • Considera cómo se va a integrar con un pipeline DevOps, si se puede ejecutar en kubernetes (o similar) para escalar indefinidamente,

    • Presupuesta las licencias calculando la participación de todo el equipo y sin límites de ejecuciones en paralelo

    • Asegúrate que cada equipo puede lanzar sus pruebas completas cada noche para discutir en las daily cómo está todo

  • Y finalmente, prepara tus números:

    • Prepara KPIs para calcular el tiempo de creación y actualización del test

    • Crea el modelo de costes de formación, licencias y ejecución

    • Asegúrate de estar alineado con las metodologías BDD y otras que te puedan exigir

    • Mide las incidencias que tienes antes y después de automatizar, y su ratio de mejora

    • ...

Recomendaciones

  • Ten un experto que te guie y te ayude a empezar con buen pié: quien automatiza los test en Appian tiene que conocer plataforma y las características de los proyectos Appian.

  • La herramienta tiene que reconocer objetos de la plataforma Appian.

  • Los cambios de versiones (hay como mínimo 4 al año) son críticos para tu test y tu solución de automatización tiene que garantizarte un impacto casi nulo. Las herramientas generalistas suelen fallar en este punto.

Conclusiones y toma de Decisiones

Como has visto, una PoC no es algo trivial.

Una vez la tienes definida y la has ejecutado, debes recibir por parte del proveedor un resumen de la PoC y preparar las conclusiones y enfocar la toma de decisiones.

Nosotros siempre preparamos un informe con los detalles que hemos comentado. Nuestro equipo conoce Appian y entiende los proyectos que se nos exigen, y por eso ayudamos a nuestros clientes a evaluar sus conclusiones enfatizando los riesgos que productos de ámbito general desconocen completamente.

En cualquier caso, con nuestra PoC, adquirirás una visión innovadora, llevada a cabo por un equipo de profesionales que se dedica en exclusiva a proyectos Appian.

Cuando lo necesites, con AAT tendrás una herramienta especializada lista para ayudarte, que te permitirá mantener una dedicación a la calidad proporcional al equipo de desarrollo, no al historial del proyecto.

Y recuerda,

no tiene por que automatizarse todo. Hay tantos modelos de adopción de una herramienta como proyectos exista. Lo que es importante es que en cada modelo, el retorno de la inversión sea substancial.

Debes buscar la flexibilidad en su máximo exponente, y no estar atado a que si no automatizas cierta cantidad, no valga la pena automatizar.

Related Articles

Image
Follow Us on...
CEITA LinkedIn
London, Barcelona, Madrid, Jaipur
© 2023 CEITA SL. All rights reserved
Save
Cookies user preferences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Session Management
Adobe Experience Cloud
Used for debugging purposes in the Adobe Experience Cloud and contains information about debugging sessions.
Accept
Decline
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Accept
Decline