Buscar diferentes enfoques en los procesos de calidad y pruebas

Durante muchos años, la industria del software ha pasado por diferentes cambios, evoluciones e innovaciones sobre procesos, metodologías, modelos o formas de trabajo, además de bastantes intentos por estandarizar las pruebas y la adecuación de certificaciones, aunando en la unificación de criterios. 

Esto, no ha sido siempre lo más acertado y existen bastantes detractores sobre estos estándares y del porque no debe de existir algo así. Una de las líneas más defendidas es que depende del perfil que realice las pruebas o las pautas, estas se realizarán de una manera o de otra y tendrás más o menos profundidad.

Aún teniendo diferentes prácticas o formas de realizar las pruebas, estas evolucionan y hay conceptos que hay que remarcar, mejorar o profundizar y que la costumbre que tenemos en la realización de alguna pauta ya no aplica como lo hacía hace varios años. Para ello, es importante hacer una revisión progresiva de la estrategia de pruebas que se están realizando y comprobar que aplican adecuadamente, son válidas o hay que darles una vuelta para poder adaptarlas a los nuevos tiempos.

Dentro de estas pautas o prácticas que ya no deberíamos de volver a hacer o al menos, intentar no aplicarlas más, son estas:

1. Conteo de errores y el desempeño de la persona.
Hace unos años, los tester se dedicaban, única y exclusivamente en abrir defectos, gestionar su ciclo de vida y comprobar que las pantallas eran adecuadas y correctas en base a que no se encontraran estos problemas.

Actualmente, el perfil ha ido evolucionando hacía otros terrenos que son más de acompañante de un proceso de calidad adecuado que a verificar estas pantallas, por lo tanto, no debemos seguir juzgando la calidad del perfil o la experiencia del mismo por la cantidad de defectos que abre o encuentra en una entrega concreta.

Esto también ha cambiado con la introducción de estrategias de automatización, ya sean funcionales o en entornos de desarrollo y la detección temprana de defectos que se capturan de manera automática, evita que lleguen entregas a la persona de una manera catastrófica.

Actualmente, los tester tienen un abanico de habilidades mayor, pudiendo abarcar desde el arranque inicial del proyecto, verificando que los requisitos se están realizando adecuadamente o como cerciorarse de que la puesta en producción se hace adecuadamente y se pasan todos los baremos o métricas de calidad dentro de una herramienta de gestión de la calidad del código, son tantas las posibilidades, que seguir viendo el rendimiento de estos perfiles con tan solo la apertura de defectos es un gran error.

2. Verificación de los porcentajes de aprobación y error del plan de pruebas.
Si te dedicas a probar, tienes que saber que la mayoría de los errores se encuentran fuera de los caminos felices habituales. El caso, es que los equipos de pruebas, se dedican en gran medida a realizar grandes cantidades de casos de prueba antes de tan siquiera acceder a una versión determinada y que, tras ello, habrá bastantes condiciones no documentadas que tendrán defectos y que, aunque, la tasa de “verdes” o de OKs sea muy alta, en un porcentaje muy pequeño de funcionalidad pueden existir cientos de defectos que han de ser solucionados.

Ahora mismo, no es una de las mejores tácticas el tener un caso de prueba por cada defecto encontrado, si no que debemos de ser capaces de elevar la tasa de confianza de los equipos de trabajo. Si realizamos unos paneles de control donde marquemos la cobertura, confianza, análisis y estado actual y lo comenzamos a compartir, cada persona se hará responsable de su trabajo y elevará la tasa de código correcto y adecuado.

La confianza de las personas está por encima de cualquier tipo de cobertura o de prueba que queramos realizar, siempre y cuando, la funcionalidad crítica esté cubierta del todo y si que pueda ser puesta en producción con total garantía.

3. Verificación final del equipo de pruebas
Como se suele decir, aunque no aplicar, en la mayoría de los casos, la calidad es responsabilidad de todos y los tester dan fe de los resultados que les llegan, pero no son los responsables directos de la calidad global de un producto, si no que ayudan a que la calidad se eleve.

En un porcentaje extremadamente grande, el equipo de proyecto espera a que las personas de QA den su visto bueno, pero esto solo debe de ser una parte del mismo y no el OK definitivo. La calidad se puede asegurar de manera global y enfocándose desde todo el equipo, por ejemplo:

•    Se define una línea base de calidad con controles medibles que verifican que todo se esté cumpliendo.
•    Cada equipo es responsable de la calidad de su entrega y toma las medidas necesarias para cumplirla y entregar con total garantía. Además de verificar ciertos estándares de calidad predefinidos en el proyecto.
•    Romper las barreras entre roles de cada a trabajar colaborativamente y ayudándose mutuamente.
•    Se implementa una cultura de calidad para cada equipo y se transfiere entre personas que deben de aplicarla y cumplirla.

Un proceso de pruebas y de calidad es siempre la mejor garantía para que algo salga como debe de salir, siempre y cuando todas las personas del proyecto trabajen unificadamente y mano a mano, si no, posiblemente, el resultado no será el que esperamos, en tu caso, 

¿Qué experiencias has tenido? Puedes dejarnos tu comentario en la comunidad o aquí, en el propio artículo.

QATalks 06 - Nadia Soledad Cavalleri, CEO de Argentesting

Nadia Soledad Cavalleri, es una de las personas dedicadas a Testing más reconocidas de Argentina. 

La apasionan las pruebas de software y compartir sus conocimientos con toda la comunidad. Tiene blogs, publica vídeos en Youtube relacionados con la Calidad de manera asidua y es una de las creadoras de Argentesting, el evento de Calidad de Argentina por excelencia. 

Desde aquí, la damos las gracias por haber participado en las QATalks y habernos aportado tanto conocimiento.

Llevas muchos años relacionada con la calidad del software en Argentina, ¿cómo ves el panorama actual en tu país? ¿Cómo ha cambiado la forma de hacer pruebas desde los últimos años en Argentina?
A la situación actual del país la veo complicada jaja pero no entremos a hablar de política. Afortunadamente, a pesar de nuestra crisis las empresas siguen invirtiendo en desarrollo de software y, por lo tanto, en testing. Es cierto que al ser un año electoral muchos proyectos están en stand by, pero en términos genérales nuestra industria no se vio tan afectada como muchas otras.
Particularmente en relación a cómo cambiaron las pruebas en Argentina, lo que te puedo decir es que se fueron profesionalizando. Por supuesto, cada empresa a su ritmo, pero la mayoría han evolucionado en ese sentido. Aquellas que no hacían testing ahora empezaron a hacerlo, las que lo hacían de manera intuitiva han capacitado a su personal, los que lo hacían manualmente han empezado a automatizar y así sucesivamente. Sin duda, la mayoría ha introducido mejoras al respecto.

Actualmente eres la fundadora de uno de los congresos más importantes que se hacen allí, Argentesting, ¿Qué temas están más candentes este año y de que se quiere hablar en él?
Actualmente tenemos abierto el llamado a ponencias así que aprovecho para invitarlos a todos los que quieran exponer a visitar nuestro sitio y hacernos llegar su propuesta. Pueden dictar charlas, talleres o lightning talks.
Lo cierto es que aún no hemos empezado a evaluarlas, lo haremos recién a fines de junio. Sin embargo, teniendo en cuenta las ponencias recibidas el año anterior y los webinars que dictamos recurrentemente te puedo decir que todo lo que es agilidad, devops y automatización en todas sus formas son los temas más candentes y RPA, testing de machine learning y blockchain son los más innovadores.


Hay un cambio de paradigma con la entrada de los RPA en el mundo del testing, ¿cómo se ve en las empresas argentinas la implantación de esta herramienta? 
Estamos muy receptivos y abiertos a trabajar con RPA, sin embargo, he visto pocas implementaciones exitosas aún. Lo que sí noto es que las áreas de negocio que, por supuesto no son tan técnicas como la nuestra, están muy predispuestos a empezar a usarlas. Y eso es fabuloso porque significa que trasciende al testing y que nuestros usuarios finales también van a utilizarlas. Creo que hay interés y muchas ganas, solo falta invertir algo de tiempo para investigarlas e implementarlas en los proyectos.


¿Hacía donde crees que va el mundo de las pruebas? ¿Cuál crees que será el futuro?
No quiero caer en un cliché, pero la tecnología avanza a ritmos agigantados, y el testing va a ir acompañando este avance. Si pregunto ¿Cuántas de las personas que está leyendo esta nota participó en un proyecto de blockchain, realidad aumentada, realidad virtual, impresoras 3D, RPA o sistemas biométricos? Probablemente la respuesta sea "muy pocos o ninguno". Yo creo que el futuro más cercano nos va a encontrar probando esto.


¿Las empresas con las que trabajas están comenzando a implantar metodologías diferenciales o que faciliten la integración de pruebas?
Definitivamente. Cada vez más empresas están implementando metodologías o prácticas ágiles. El rol de los scrum masters y agile coaches está cobrando cada vez más relevancia. Y esto es muy positivo para testing porque más allá de incluir prácticas o ceremonias ágiles, estos roles nos ayudan a que se adopte el mindset ágil. Esa es la base para tener una visión integral de las pruebas. Después sobre eso se puede construir devops, testing continuo y el resto de las técnicas, prácticas o herramientas.


Dentro de la perspectiva que tomará tu carrera profesional, ¿cómo te ves dentro de unos años?
Es una pregunta difícil porque tengo múltiples roles y me cuesta pensar cuál se va a desarrollar más que otro. Hoy en día: lidero proyectos, gestiono una empresa, doy clases, dicto conferencias, escribo artículos, genero contenidos en video, hago coaching a testers, entre otras cosas. De todo esto, lo que más disfruto es lo que tiene que ver con la generación de contenidos, ya sean escritos o en video. Asi que voy a contestar la pregunta más desde lo que deseo que desde lo que puedo proyectar. Me gustaría seguir viajando por el mundo dando más charlas de testing y con el canal de Youtube un poco más desarrollado.


La semana pasada estuviste exponiendo en el Bolchi Testing Day en Chile ¿Sobre qué tema expusiste?
Hace poco me tocó probar una aplicación para niños y me di cuenta que en el testing de aplicaciones para este público hay que tener en cuenta un montón de cuestiones que no solemos considerar. Así que en mi charla conté esa experiencia y compartí el aprendizaje adquirido.  La estrategia de testing en estos proyectos es un poco diferente. Yo lo fui aprendiendo sobre la marcha, a medida que transcurría el proyecto, pero me hubiese venido muy bien que alguien me cuente todo esto, antes de empezar el proyecto.

Mi experiencia realizando pruebas en un sistema de alquiler de coches Full-Digital

Para algun@s de vosotr@s, os será muy familiar este tipo de aplicación, para otros no os sonará de nada, así que voy a dar un poco de contexto a que es la aplicación que probé hace unas semanas: Click’n Go.

Pero, antes de nada, quisiera dar las gracias a BSD Enterprise, compañía que me ha dado la oportunidad de colaborar en la realización y ejecución de este proyecto, siendo BSD Enterprise actualmente un partner que apoya al equipo interno de Calidad de Goldcar.

BSD Enterprise es una empresa internacional de Tecnología de la Información con distintas verticales de servicio, mismos que conjuntan conocimiento de mercado y métodos de trabajo innovadores, destacando su experiencia en el área de Aseguramiento de la Calidad y Pruebas de Software. 

A continuación, os voy hablar de la App, Click'n Go es un sistema de alquiler de coches full-digital de Goldcar, en el que se usa un dispositivo móvil (Smartphone) para recoger, abrir y cerrar tu vehículo con la ayuda de la aplicación móvil del mismo nombre. Cuando llegues al aeropuerto (o al sitio específico), tu vehículo estará aparcado y listo en la plaza de parking asignada a la hora de recogida exacta que has indicado en tu reserva.

El funcionamiento de reserva de Click’n’Go es tan sencillo como, hacer la reserva en la web, www.goldcar.com y descargar la App. Tras ello, te mandan todos los datos necesarios para acceder a tu llave digital que necesitarás para recoger el vehículo.

Una vez que nos hemos puesto en contexto, ya podemos hablar de las pruebas realizadas y de mi experiencia hace unas semanas, en la sede central de Goldcar en España.

Allí, coincidí con Juan Antonio Ruzafa, QA Lead y habitual de eventos como VLCTesting, donde hace un par de años dio una ponencia muy interesante. Además, conocí a Garry Dale, que es el Project Manager y trabajé, mano a mano, con Guillermo Rodenas para garantizar la calidad del evolutivo de la app.

Toma de contacto

La toma de contacto fue realmente sencilla, la aplicación se da a conocer por si misma y es altamente intuitiva. Esto me ayudó mucho, ya que tenía algo en contra y del que no podía escapar, el tiempo. Teníamos los días contados y había que dejar probado un evolutivo completo de una aplicación que no conocía totalmente, así que, punto muy a favor para Goldcar, tanto para este tipo de acciones, como si me pongo en la piel de un usuario que no tiene grandes conocimientos tecnológicos.

Todo el equipo dedicado, y en particular, Guillermo, me puso al día rápidamente y me pasó bastante documentación donde poder leer y empaparme bien de las tripas de la aplicación, que conexiones con terceros tiene y como se gestionaba internamente.

Tras ello y una vez capturada toda la información, fui haciéndome un mapa mental de todo e iba dando forma a todas las interconexiones para comprender cada engranaje y que no se escapara ninguna casuística. 

El paso siguiente, como es lógico, fue la toma de contacto y lectura de los casos de prueba que existían para la aplicación. Estos casos me ayudaron a definir algunas pautas que no conocía y comprender del todo, la complejidad interna del sistema digital de alquiler de vehículos de Goldcar. Como ya os digo, la app a nivel visual y utilización es muy sencilla, pero el entramado a bajo nivel es complejo y tiene muchas casuísticas que hay que tener en cuenta para que las reservas funcionen como deben, tanto a nivel de vehículo como a nivel de contrato con el cliente en concreto.

Esta fase la realicé en paralelo al montaje de toda la plataforma de pruebas y que se quedara todo listo para probar en un entorno estanco y seguro. Esto me permitió, paralelizar tareas y ganar un tiempo muy valioso.

Además, tuve tiempo para montar todo lo necesario para conectarme a sus herramientas y preparar mi portátil y los dispositivos con TestFlight y el paquete .apk de pruebas, para garantizar la calidad de lo solicitado.

Realizando una fase exploratoria

Una vez que capturé toda esa información en mi cerebro y como el tiempo nos iba ganando terreno, pensé que lo ideal era realizar una fase exploratoria en la app que comprobase que la funcionalidad crítica estuviera funcionando correctamente.

Evidentemente, el paso más crítico para Goldcar es, básicamente, abrir un contrato, que se utilice el vehículo y cerrar el contrato. Así que me puse a ello. Guillermo me habilitó un contrato desde su herramienta interna, cogí los dispositivos de pruebas (que eran Android y iOS para comprobar ambos sistemas operativos) y me fui el vehículo asignado.

En un primer momento me sorprendió la velocidad y capacidad de la aplicación. Me esperaba algo un poco más “pesado”, pero, al contrario de mi pensamiento, es super ligera, rápida y sencilla. En el momento que activé el usuario de pruebas, ya tenía las llaves descargadas en la app y con un simple movimiento de dedo pude abrir el coche. El retardo es casi nulo desde que haces el gesto hasta que se abre el vehículo. Diría que casi, prácticamente, el mismo tiempo que se tarda en girar la llave en el bombín.

Una vez que el vehículo está abierto, hay que realizar una serie de gestiones para habilitar el contrato y dar información sobre el vehículo y su estado actual. Tras ello, puedes arrancar el coche con el sistema Start&Stop o el que esté disponible.

Como la aplicación es bastante intuitiva, pude realizar una fase exploratoria bastante completa y empaparme aún más del producto. Sin entretenerme mucho, acabé realizando el fin del ciclo, cerrando el contrato y el vehículo y comprobando que todo se quedó perfecto.

Ampliando la batería de pruebas

Tras esta fase exploratoria, iba revisando y cerrando diferentes casos de prueba que ya estaban definidos y así, realicé ciclos completos, por diferentes caminos, durante prácticamente una jornada completa. 

En este punto, pensareis, vaya…si hace un momento nos decía que iba con el tiempo justo y se pasa un día entero realizando fases exploratorias en la aplicación. Realmente, así fue y la explicación es muy sencilla, esto me permitió hacer, en paralelo una revisión completa de los casos de prueba existentes e ir descubriendo casuísticas, cambios, mejoras y mientras tanto, validando todo y levantando defectos por el camino. Este tipo de “técnicas”, te permiten aprender como funciona una aplicación en un periodo corto de tiempo y con la garantía de que no se escape ninguna casuística (al menos, que sea grave o crítica).

En muchas ocasiones, nos ceñimos a un guión estipulado que es el que se realiza habitualmente, pero, en casos como el de estas jornadas de validación, hay que cambiar las técnicas, innovar y paralelizar mucho, aunando y simplificando esfuerzos para poder aportar el máximo valor.

Durante estas sesiones, detecté varias problemáticas y mientras las investigaban, decidí aportar, como valor extra, todo el conocimiento adquirido. Así que me puse a refactorizar y ampliar la batería de pruebas que tenían en la herramienta de test management que utilizan en Goldcar.

Primero reordené los casos de prueba y los coloqué de tal manera que formaran un camino lógico como si de un cliente se tratase. Una vez que tuve esa ordenación, Guillermo y Juan, me aportaron más información de la herramienta interna de control de contratos. Con toda esa información, fui dando forma a nuevos casos de prueba que iban conformando una batería compleja que unía el camino lógico de un cliente con el camino lógico interno de Goldcar, comprobando todas las casuísticas y los diferentes puntos críticos que hay que pasar para que todo funcione y se registre de la manera idónea.

Ejecutando la nueva batería de Pruebas

Una vez que contábamos con esta nueva batería de pruebas, nos pusimos manos a la obra para ejecutarla en los dispositivos y hacer unas buenas pruebas de compatibilidad.

Guillermo, creó varios contratos y yo fui ejecutando, caso por caso, en los dispositivos de pruebas. La verdad, tengo que decir, que el funcionamiento fue realmente bueno. Nos pegamos dos sustos, pero que resultaron ser problemas del entorno de pruebas que se solventaron después y se apuntaron para que no volvieran a suceder. 

Estas ejecuciones, permitieron detectar mejoras en los entornos de pruebas, detectó varios defectos que se solventaron muy ágilmente por las personas de desarrollo y conseguimos averiguar algunas casuísticas extrañas, que no se habían tenido en cuenta, hasta ese momento y que completaron la batería de pruebas bastante bien.

El resultado de las últimas ejecuciones fue muy bueno y no se encontró nada crítico o grave para el funcionamiento de la nueva release de la app, por lo tanto, la satisfacción por el trabajo bien hecho, estuvo presente durante todas las jornadas de trabajo.

Sensaciones y conclusiones

Escribiendo este artículo y recordando aquellos días, puedo decir que me lo pasé tremendamente bien. 

Hacía mucho tiempo que no realizaba este tipo de proyectos (con aparatos físicos de grandes dimensiones) y puedo decir, que nunca lo había hecho con un vehículo y una aplicación así. Es un aprendizaje que me llevo y que me ayudará con otros proyectos.

También, me llevo el haber conocido y trabajado con enormes profesionales y seguir creando sinergias y ampliando horizontes. Conocer internamente una compañía como Goldcar es algo muy enriquecedor y, además, compartir con Juan algunas conversaciones y poder ver en vivo y en directo el pedazo de ecosistema de pruebas automáticas que han realizado es bestial. Ya os digo, que es digno de ver y como le dije, de contar (no te olvides, Juan, que hay una ponencia en algún evento para contar aquello, si o si).

Se que much@s de vosotr@s (si habéis llegado hasta aquí) se os estarán poniendo los pelos como escarpias leyendo que se realizaron pruebas manuales, si, has leído bien: manuales. Independientemente de que, personalmente, piense que las pruebas manuales se tienen que seguir realizando, existan o no las pruebas automáticas, he de decir, que este proyecto hay que hacerlo de manera manual obligatoriamente. Es completamente imposible el automatizar pruebas con un vehículo, abrirlo, arrancarlo, incluso conducirlo y aparcarlo en la plaza asignada en la reserva. Por lo tanto, si, las pruebas manuales son necesarias y más, en estos casos.

Para finalizar, solo me queda dar las gracias a David de la Cruz Viana, Key Account Manager en BSD Enterprise, por confiar en mi persona para realizar el proyecto, a Juan, Guillermo y Garry de Goldcar por su acogida, su amabilidad y su tiempo para darme toda la información y ayudarme con las herramientas internas a las que no podía tener acceso. También, a Sergio Gómez Moreno, QA Engineer de BSD Enterprise en Goldcar, por ser tan sumamente amable y cercano, acogiéndome cada día para comer y darme diferentes puntos de interés que visitar (aunque tengo pendiente ese famoso arroz).

Ha sido un placer ayudaros con esta aplicación, ser parte de ella y de como vamos a alquilar y utilizar los coches en muy poco tiempo. Estamos construyendo el futuro y las pruebas están más vivas que nunca, encontrar empresas, como BSD Enterprise y Goldcar, donde se apuesta tanto por la calidad, es un verdadero placer y un honor, 

¡Gracias!

¿Coordinar proyectos con personas o coordinar personas en proyectos?

Cuando trabajamos con diferentes áreas o equipos, debemos de tener la visión transversal suficiente para entender que la colaboración es la base principal de que un proyecto funcione como debe.

Muy frecuentemente, tendemos a trabajar de manera individual, empezando y finalizando nuestras tareas sin ni siquiera fijarnos en los demás o preocuparnos si su día a día será más sencillo gracias a nosotros. Esto es un error, por el que muchas empresas, no se preocupan y donde debemos de incidir más en el día a día.

En este sentido, podemos hablar del pecado capital de todo proyecto, la falta de comunicación y la individualización de las tareas. 

Uno de los puntos más a favor a la hora de tener un contacto directo con las personas, es realizar planificaciones grupales, reuniones conjuntas y dinámicas, hacer que fluya la comunicación y trabajar para los demás. Más de una vez, veo como desde las capas más altas, se trabaja para uno mismo, con objetivos más que individuales en ves de grupales y sobre todo, para proteger a las personas de nuestra empresa.

¿En cuantas ocasiones os habéis quedado vendid@s delante de un cliente porque vuestro responsable directo o el responsable del proyecto no ha dado la cara por vosotr@s? Yo ya os digo, que unas cuantas.

Si llevamos a la práctica alguna de estas pautas grupales, permitiremos que el proyecto sea más fácil de coordinar, de seguir y fluirá el trabajo de manera más ágil, creando entregas con mucha más calidad y garantizando a los clientes las fechas acordadas. Un equipo motivado y que circula en la misma dirección es 20 veces superior que un equipo desecho y que sale bien en las fotos, pero que en el día a día, crea grupos cerrados de crítica y negatividad.

La  idea de los eslabones de la cadena (que tanto utilizo allí donde voy) tiene que quedar patente en todo lo que hacemos, reforzando lo que existe a nuestro alrededor y concienciando a los demás para ello. Personalmente, no me vale el quiero cambiar si luego no hago nada para cambiar. 

El primer paso para que un proyecto funcione, sea ágil y acorde con las necesidades del cliente es que las personas que trabajen en él estén amarradas una a una haciendo una cadena perfecta e irrompible y que sean consecuentes con que si su trabajo es de calidad, la persona que venga despues encontrará algo digno y facil para continuar, si no, la rotura será inmediata, tanto a nivel profesional, porque se seguirá trabajando sobre algo ya inadecuado, como a nivel personal porque pensaremos que vaya regalo nos han dejado y empezarán las tensiones.

Como ya hemos visto en otras ocasiones, podemos fortalecer esto con planificaciones, reuniones de cierre del mapa de proyecto, toma de contacto y sobre todo, teniendo en la cabeza una fase de definición donde el resultado final sea una documentación ferra y consecuente, donde escribamos toda la información y la elaboremos entre tod@s, estando alineados y listos para comenzar a trabajar en la misma dirección.

Existen diversas técnicas que, habitualmente, siguen los mismos pasos y que nos hacen tener una guía sencilla y unificada de lograr un método para hacer las cosas fáciles y para todo el equipo. 

Las pautas en las que debemos de fijarnos, a modo de ejemplo, son los siguientes:

• Hay que observar que pasos vamos a dar dentro del proyecto, para ello hay que tener claro que nos han pedido y que esperan de nosotros. Esto se puede realizar con reuniones conjuntas entre cliente y nosotros y elaborar un mapa de proyecto. Sobre todo, no hay que comprometerse a nada sin dar los siguientes pasos.

• Buscar equipo. Determina de manera clara, una vez que hemos visto que hay que hacer, quien lo va a hacer. Esto es una de las cosas más importantes, debemos de planificar y buscar a las personas que van a realizar el proyecto, responsabilizándolos de las tareas y haciéndolas suyas. Deben de salir líderes que se encarguen de que suceda cada acción. Un error típico de malos gestores es el de no saber dimensionar correctamente un proyecto e ir añadiendo personas en el tiempo, eso hará que no se tenga tiempo de formar ni de capturar toda la información funcional de los proyectos.

• Elabora un plan B. Las cosas pueden ir mal, esto es así. No te creas a nadie que te diga que por trabajar con una metodología o haciendo las cosas de una manera, todo irá perfecto. Nunca es así y, por línea general, suelen existir problemas. Elabora un plan de contingencia, valora riesgos, cúbrete las espaldas a ti y a tu equipo (importante, no solo a ti, por favor). Si algo puede ir mal, lo irá, se precavid@.

• Se realista. Una de las máximas. No hagas florituras, intentes introducir esa tecnología tan moderna y nueva o esa filosofía DevSuperChulaGuayVops si no eres un experto. Quizá, tu equipo sea experto en proyectos en cascada y con un lenguaje de programación más antiguo. El resultado será el mismo, todos contentos y satisfacción integral. Se realista, las cosas molan, pero mola más llegar a fechas con garantía y que el cliente esté contento.

Hay muchas pautas, maneras y formas de coordinar proyectos, pero siempre hay que llevar por delante la ética y la integridad. No vendas lo que no sabes hacer, se realista con lo que haces y con los tiempos que proporcionas y sobre todo no te dejes embaucar por personas que, seguramente, sepan más bien poco de esto. tu eres el verdadero experto y quien debe de poner la cara delante de cliente, si no puedes hacerlo y tu integridad profesional está en juego, no lo dudes, ese no es el sitio donde debes de trabajar.

Valencia AfterTest '19 - Resumen del evento

Hace unas semanas, tres de nuestros colaboradores, fueron a Valencia al After Test celebrado allí.

Los afortunados fueron Belén Montes, Jorge León y Estefanía Fernández Muñoz. Estuvieron repartidos por varias sesiones y nos traen un magnífico resumen de lo que allí se habló y de, lo que son, las nuevas tendencias de testing que hay en este momento.

Los damos las gracias por la colaboración, por el pedazo de resumen que han realizado y por el entusiasmo que le ponen a todo, ¡¡sois unos grandes #QALovers!!

Por un lado, Estefanía estuvo en las siguientes sesiones:

Isabel Evans - Track 2 - 11:45 - 13:15 | UX y testing de usabilidad. 'Shift left' para UX

La master class de Isabel fue bastante inspiradora en cuanto a cosas a tener en cuenta a la hora de probar un producto basándonos en el UX y en lo que va a pensar en usuario final sobre ella.

Isabel nos habló de varios puntos importantes: 
Conceptos:

• ¿Qué significa para nosotros la calidad? Debíamos pensar qué es calidad para nosotros y compartir lo que pensábamos en grupo. ¿Cómo definimos calidad?, ¿Podemos dar algún ejemplo?, ¿Está el grupo de personas con las que has hablado de acuerdo contigo?
• ¿Qué es la experiencia de usuario?, ¿Que pensamos que es? Cómo la pregunta anterior la comentamos en voz alta. Tenemos que tener en cuenta que UX no es solo la interfaz y la usabilidad, que hay muchas cosas más.
• Calidad al usar un producto: ¿Cómo medimos eso?, ¿Cómo probamos eso? Debemos tener en cuenta que para probar algo tenemos que verlo no sólo con la cabeza, sino con el corazón y el alma.
  

Introducción a los procesos de UX:

• ¿Cómo sabemos qué personas van a usar el producto y cuál es su contexto? Tenemos que identificar QUIÉN lo va a usar, POR QUÉ, PARA QUÉ lo va a utilizar e identificar sus emociones.
• ¿Cómo identificamos atributos de calidad? Tenemos varias capas: las capas de UX, la de calidad en el uso y la de calidad del producto.
• ¿Cómo definimos las US y los criterios de aceptación para el UX? Tenemos que escribir historias ricas (Rich Stories) con detalles, específicas, contractuales, simples...
• ¿Cómo hacemos unas buenas iteraciones en el diseño? Mediante la empatía y experimentando. Nos preguntaremos: ¿quién? ¿Por qué? ¿Dónde? ¿Cuándo? ¿Cómo? Para dar respuesta a estas preguntas.
• ¿Cómo hacemos una review de UX y tomamos en cuenta las observaciones? Mediante prototipos y test de usabilidad.
  

Fue una clase muy inspiradora y más filosófica de lo que esperaba, pero me sirvió mucho para mejorar los conceptos que tenía sobre UX y aplicarlos en mi día a día en pruebas.

Seretta Gamba - Track 2 - 14:30-16:00 | Automatización de prueba. Lecciones para los automatizadores de pruebas

Para mi la master class de Seretta fue una de las más interesantes de todo el evento. La clase que impartió se centró en lecciones y buenas prácticas para las personas que se dedican (o nos dedicamos) a automatizar pruebas, sobre todo centrándonos en dos partes:

•    Problemas más habituales que se tienen a la hora de automatizar pruebas.
•    Formas o enfoques para solucionar estos problemas.

Para ilustrar todo esto utilizamos una wiki que ha desarrollado Seretta junto a Dorothy Graham y donde se recogen todos estos patrones y enfoques. La URL de la wiki es: https://testautomationpatterns.org/wiki/index.php/Main_Page.

En la master class, Seretta nos hizo hacer algunos ejercicios para entender cómo utilizar esta wiki:

Ejercicio 1:

Vimos el ejemplo de Nancy Naive: https://testautomationpatterns.org/wiki/index.php/Nancy_Naive

El caso que se expone es el siguiente:

•    Nancy es una persona que no ha realizado automatización anteriormente.
•    Su empresa compra una herramienta para la automatización de pruebas (de la que tiene una demo) y que principalmente se basa en grabar acciones y auto-genera test automáticos.
•    Mediante esta herramienta, Nancy tiene que automatizar toda la suite manual de regresión que tiene actualmente.
•    Después de la demo comienza a grabar test y la primera ejecución funcionan perfectamente.
•    En las siguientes ejecuciones se da cuenta de que, al introducir nuevos desarrollos, los test que ya tenía grabados no le funcionan y tarda más en volver a grabar de nuevo los casos de prueba para pasarlos de forma automática que hacerlo manualmente.
•    Para analizar el problema de Nancy, debemos ir al Test Automatizo Issues Mind Map: (https://testautomationpatterns.org/wiki/index.php/Test_Automation_Issues_Mind_Map) y enumerar los que encontramos y que se puedan ajustar a este caso.

Algunos de los problemas que podemos encontrar son:

•    Execution issues: flaky test, inefficient execution.
•    Design issues: brittle scripts.
•    Management issues: inadequate support, inadequate team, limited experience, no previous test automation. 

Ejercicio 2:

Vimos el ejemplo de Ursula Unfocused: https://testautomationpatterns.org/wiki/index.php/Ursula_Unfocused

El caso que se expone es el siguiente:

• Úrsula ha empezado a automatizar recientemente.
• Tiene background de desarrollador a con lo cual está muy contenta de empezar.
• Está utilizando buenos principios de automatización para crear la base del proyecto de pruebas automatizadas.
• Tiene problemas en decidir qué test debe automatizar.
• Empezó automatizando aquellos que se ejecutaban más, y algunos smokes.
• Después comenzó a hacer test que le resultaban fáciles y le hacían avanzar de forma rápida.
• Después de pasar un tiempo automatizando y mejorando la suite automática, ha tenido quejas de que hay partes importantes de la aplicación sin test automáticos y deben seguir ejecutando muchas pruebas manuales.
• Para analizar el problema de Ursula tenemos que ir al Test Automation Patterns Mind Map (https://testautomationpatterns.org/wiki/index.php/Test_Automation_Patterns_Mind_Map) y enumerar los que encontramos y que se pueden ajustar a este caso.
  

Algunos de los patrones que podemos encontrar son:

•    Design: Abstraction levels, automate good test.
•    Process: ask for help, automate what’s needed, good programming practices, lazy automator, learn from mistakes.
•    Management: mix approaches, prefer familiar solutions, set clear goals.

Ejercicio 3:

Vimos el ejemplo de Iván Indispensible: https://testautomationpatterns.org/wiki/index.php/Ivan_Indispensible

El caso que se expone es el siguiente:

•    Iván es un arquitecto de test que ha creado el proyecto de automatización de pruebas de su empresa actual.
•    El proyecto está bien estructurado (ya que Iván tiene background de desarrollador) y no tiene casi duplicación.
•    Los scripts están bien estructurados y diseñados para ejecutar las pruebas de la forma más eficiente.
•    La automatización de pruebas es un éxito en la empresa y cada día hay más automatización.
•    La empresa de Iván se ha unificado con otra y ésta quiere aplicar el mismo principio de automatización que ha hecho Iván en su organización.
•    La nueva compañía ha asignado a Ramesh a realizar este proceso.
•    El problema es que Iván no ha documentado nada de todo el proceso que ha seguido y Ramesh está teniendo problemas para arrancar y comprender todo lo que hay montado.
•    Iván considera que documentar todo este proceso era una pérdida de tiempo porque él era la única persona que automatiza, pero ahora que Ramesh se ha unido piensa que quizás debería haber hecho las cosas de una forma diferente.
•    Para analizar el problema de Iván iremos a Diagnostic (https://testautomationpatterns.org/wiki/index.php/Diagnostic) y veremos qué diagnóstico le daremos al problema de Iván.

Alguno de los diagnósticos que pensamos para Iván son:

•    ¿Está Iván poco satisfecho con su automatización actual? En la parte de funcionalidad no porque él lo ha estructurado bien, pero a la hora de explicarlo a alguien nuevo está bastante descontento con cómo lo ha gestionado.
•    ¿Ha empezado hace poco el proceso de automatización? No, y ahora tienen que volver atrás y documentar el proceso para ayudar a Ramesh a entenderlo y aplicarlo.
•    ¿Te has unido a un equipo de automatización sin experiencia? En este caso Ramesh se ha unido a un equipo con experiencia, pero él no la tiene.
•    ¿Conoces ya cuáles son tus problemas? No, Iván los empezó a conocer cuando llegó Ramesh, hasta entonces pensaba que su solución era inmejorable.

Después de estos ejercicios Seretta siguió explicando las técnicas que están en la wiki más detalladamente y para terminar hizo un sorteo de su libro: “A Journey throught Test Automation Patterns” (https://www.amazon.com/Journey-through-Test-Automation-Patterns/dp/1727504887)

Fue una de las master class que más me gustó y de la que más disfruté, de hecho al final de la clase me quedé hablando con Seretta haciéndole varias preguntas sobre todo lo que había hablado. Sin duda, repetiré en alguna de las que dé.

Por otro lado, Jorge, estuvo en las siguientes sesiones:

Track 3_ES-Testing en el siglo XXI
Ponente: Alex Soto
 
De las Master Class más interesantes de la Test Academy de Valencia.
Alex Soto nos desmitificó un tema tabú en el testing, las pruebas en producción.
Todos sabemos que lo ideal en el mundo QA, es probar en un entorno lo más parecido al que van a utilizar los usuarios finales y que mejor que hacer dichas pruebas en el propio entorno productivo.

Nos explicó la metodología de trabajo para poder probar en este entorno, ir liberando releases para que sean testadas solo por ciertos usuarios en nodos concretos.
Esta redirección del tráfico se realizaría con la herramienta ISTIO:
https://istio.io/

Esta sería una pirámide tipo



Nos explicó terminología muy de modo actualmente como Canary release, chaos testing, Blue/Green Deployment o Shadowing Traffic.

Esta metodología de trabajo la usan grandes empresas como Facebook, Google o Netflix

Track 4_ES-API REST testing – Automatización e integración continua
Ponente: Rodrigo Jiménez

Master Class muy interesante en la que Rodrigo nos explicó su metodología de trabajo y herramientas utilizadas para realizar pruebas sobre Apis.
Lo mejor de todo, con un alto de porcentaje de herramienta open source y conocidas por tod@s:

•    Jenkins
•    Jmeter
•    Testlink
•    Jira

Si, si, habéis leído bien Jmeter para realizar pruebas funcionales de API.
Gracias a unos scripts de integración realizados en Python consigue relacionar todas estas herramientas en el proceso de integración continua de su empresa.

El flujo sería:

•    Definición de pruebas en Testlink con campos personalizados.
•    Desarrollo de los test en Jmeter con una nomenclatura especial para poder enlazarlos con los casos de prueba de Testlink.
•    En Jenkins se ejecutan las pruebas.
•    Con scripts desarrollados por el mismo en Python consigue que los resultados de las pruebas de Jmeter se generen en formato Tap. Esto hace que los resultados se vean de forma más claro que los que se obtienen por defecto en Jmeter
•    Gracias a los plugin de Jenkins y a otros scripts en Python consigue:

• Obtener unos resultados muy limpios y claros de las pruebas
• Que dichos resultados se vuelquen a Testlink.
• Y que si existen pruebas falladas automáticamente se creen defectos en Jira.

Y para finalizar, Belén estuvo en las siguientes:

Albert Tort - Track 1 - 09:50 - 11:20 | Inteligencia artificial. Bots, spiders y modelos cognitivos: Las claves de la automatización en el testing con inteligencia artificial

Con esta Master Class, dio comienzo el Track en español del Test Academy de Valencia.

Durante este Track, se trataron conceptos como “Narrow AI”, donde se busca que la máquina sea buena en una tarea concreta, y “General AI”, que engloba aquella que pretende emular la gran mayoría de las capacidades humanas.

Respecto a Bots, spiders y modelos cognitivos, Albert Tort mostró por qué era necesario incluir estas herramientas en nuestro día a día.
Uno de los ejemplos fue hacer buscar a los asistentes un enlace roto en una página web. Estos, tardaron una media de un minuto o minuto y medio en encontrar alguno tras haber revisado 12-14 enlaces mientras que un spider, en ese mismo tiempo, fue capaz de analizar decenas de enlaces y reportar todos aquellos que no se encontraban operativos.

Albert Tort presentó un tema a la orden del día, haciendo partícipes a los testers reunidos del avance de la tecnología y el testing en este sector, a la vez que captó la atención de todos los asistentes con encuestas que mostraban resultados en vivo y lo difícil que puede ser tomar una decisión para una IA y también para las personas.

Tanja Vos - Track 2 - 11:45 - 13:15 | Pruebas visuales. TESTAR, ¡deja que la herramienta aprenda cómo probarlo!

Tanja Vos, profesora asociada en la Universidad Politécnica de Valencia, centró su Master Class en el testing de la Interfaz Gráfica de Usuario (GUI).

Comenzó poniendo en valor el GUI testing. Mostró la importancia de comprobar desde la Interfaz de un programa de ofimática hasta la Interfaz de máquinas tan delicadas como un monitor de constantes vitales en un hospital.

Tras esto, mostró la cantidad de casuísticas a tener en cuenta a la hora de realizar GUI testing y formuló la pregunta “¿Por qué no enseño a una máquina a hacerlo?”
Con esta premisa, presentó la herramienta TESTAR (https://testar.org/) que permite realizar GUI testing en aplicaciones de escritorio, web y móvil.
Es una herramienta de interfaz sencilla y bastante intuitiva que tiene unas cuantas acciones configuradas pero que, al ser de código abierto, permite adaptarla a las necesidades que se tenga en cada proyecto.

Actualmente, la versión de escritorio está más desarrollada, debido a las necesidades que tienen por parte de uno de los clientes, y buscan crear una comunidad que vaya alimentando esta herramienta.
Además, Tanja comentó que estaría encantada de ayudar a cualquiera que quisiese colaborar en el desarrollo de la herramienta facilitando su número de teléfono (690 917 971) para cualquier consulta.

Personalmente, esta Master Class me fascinó por el abanico de posibilidades que puede ofrecer la herramienta con una pequeña inversión de tiempo en la parte de aplicaciones móviles.

Estrategia de pruebas exploratorias estructuradas

En entornos de DevOps, se están adoptando, con el tiempo, pruebas exploratorias. Estas pruebas, se adaptan muy bien a esta filosofía y al trabajar de manera tan flexible, nos permite tener cierta garantía en despliegues muy rápidos.

El problema que tenemos con este tipo de pruebas, es que, a veces no sabemos como realizarlas correctamente o de manera eficiente.

El primer paso es estructurarlas, si nos centramos únicamente en caminos felices, el resultado será muy pobre y si, por el contrario, nos enfocamos en ampliar la cobertura, el tiempo, nos puede ganar la batalla y nos ser óptimas.

Una estructura lógica para realizar pruebas exploratorias es la de utilizar la criticidad de los módulos para la compañía, comenzando a probar lo más crítico, ya que, de esto, dependerá el negocio y los ingresos de la misma.

Si la funcionalidad crítica y más “económica”, funciona correctamente, al menos, salvamos los ingresos empresariales y los usuarios seguirán utilizando la herramienta en su capacidad “inicial”, por lo tanto, podría ser una buena estrategia.

En el caso de entornos puramente de desarrollo, este tipo de pruebas se llevan la palma, ya que son las más sencillas de realizar y son las que pueden decidir que un evolutivo está listo para desplegar. Lo malo, es que se suelen hacer sin estrategias ni técnicas de diseño de pruebas o cobertura y esto genera que aparezcan puntos ciegos y regresiones inesperadas en producción que pueden ser demoledoras. También, tenemos el ejemplo de las pruebas de integración, en las que, se suele tender a probar el camino feliz y el resultado, vuelve a ser muy pobre si no se estructura correctamente. 

También, tenemos diferentes problemas a la hora de realizar pruebas de UAT o de aceptación en la que los clientes realizan una caza de defectos, pero no se estructuran las pruebas adecuadamente y son muy poco eficientes. Esto, por ejemplo, nos pasó en un proyecto no hace mucho tiempo, los tiempos de pruebas eran escasos, no había una buena estructura de desarrollo y los directores del proyecto no habían decidido ni gestionado ningún tipo de estrategia, solo estaban centrados en facturar y facturar, por lo tanto, el proyecto fue un completo desastre. Evidentemente, la culpa de todo el desastre era de las personas de desarrollo y de testing, cosa muy lejana de la realidad, pero es lo que suele suceder. Al final, el jefe de proyecto, hizo una labor espectacular y mano a mano, decidimos crear una estrategia de pruebas de UAT y se hizo una batida de pruebas muy completa que permitió poner el software en producción con bastante garantía y el proyecto dio la vuelta completamente, tras ello, lo que suele suceder, los directores del proyecto se colgaron la medalla y lo celebraron por todo lo alto (qué tire la primera piedra a quien no le haya pasado esto en algún momento).

Con este tipo de situaciones, debemos de mantener unas estrategias de pruebas exploratorias estructuradas, para que, al menos, podamos mantener cierta integridad y garantía a la hora de poner algo en producción.

El primer paso, evidentemente, es ayudar a realizar mejores requisitos. Desde QA, debemos de dar las pautas y formar a las personas para que los requisitos cubran las necesidades de todo el mundo. Que sirvan para realizar unos buenos casos de prueba y para que el cliente, pueda comprobar y verificar lo que se le va a entregar, teniendo toda la información de la mano.

El segundo paso es hacer una evaluación o un análisis de posibles riesgos en el producto, tratando con todas las personas del equipo y que pusieran encima de la mesa los diferentes puntos ciegos que viesen para cubrirlos con anexos a los requisitos o a la documentación que se utilice.

Otro punto que debe de realizarse es hacer pequeños listados de cosas críticas o importantes que deben de probarse, incluyendo caminos felices y posibles casuísticas no contempladas a simple vista. Un extra en este punto, es el realizar guionesdetallados en módulos complejos del producto, esto le da a todo el equipo, una seguridad enorme.
Estos documentos e información, se pueden utilizar como mapas mentales, ahorrando tiempo y esfuerzo a todas las personas.

En estos casos, las pruebas, las suele hacer el tester, pero con esta documentación, se pueden realizar por cualquier persona. Esto, genera una serie de informes con datos y resultados que se pueden utilizar para saber que probamos y que no probamos en los siguientes evolutivos, tratando de eficientar cada segundo de las personas dedicadas a estas labores.

Como podéis observar, esta estrategia está definida, según habíamos hablado antes, sobre la criticidad de los módulos y no es algo cerrado ni fijo, pero nos ayuda con un guión que puede ser todo lo flexible que queramos y se puede adaptar a cualquier momento o situación.

Una vez tenemos estas partes definidas y funcionando, ya podemos ir introduciendo otras etapas, como la automatización en dispositivos móviles, por ejemplo.

Con todo lo realizado anteriormente, se van captando las pruebas que hemos lanzado, capturando las más críticas, ya que, si no, el tiempo de realización, mantenibilidad y ejecución puede ser demasiado alto y costoso, y el retorno de inversión bajaría considerablemente, no mereciéndonos la pena.

La idea, es capturar un pequeño número de pruebas, con una cobertura amplia basándonos en la criticidad y adaptándonos a un “presupuesto” que hayamos estudiado anteriormente. La ventaja de automatizar esta pequeña lista, es que los evolutivos o despliegues, se pueden garantizar bajo diferentes situaciones y la confianza que genera a todas las personas irá en aumento.

Si conseguimos que esto sea factible, el presupuesto se irá ampliando y evidentemente, la garantía será mayor y conseguiremos automatizar, prácticamente todo.
Una vez que realicemos este tipo de pruebas estructuradas, vamos a aprender una serie de cosas, como, por ejemplo:

·      Aprender a que la estrategia de pruebas debe de ser flexible, preguntándonos que hay que probar, que es más crítico y actuar en consecuencia.

·      Utilizar técnicas de diseño y cobertura adecuadas. Cada proyecto, es un mundo y en base a la utilización y los módulos que sean más críticos y que nos generen ingresos directamente, nos deberán de dar el punto de partida para realizar toda la estrategia en torno a ellos.

·      Otro punto, que, aunque yo sea un loco de la documentación, en este caso, es muy factible, es no dedicar mucho tiempo a ella, si no que se deben de realizar mapas mentales que generen una documentación más liviana.

·      Y otro punto, aunque ahora no estará del todo bien visto, es que la automatización no es la respuesta a todos los problemas. En ocasiones, nos puede generar más de los que resuelve. Hay que seguir haciendo estrategias híbridas ya que muchas herramientas no cubren todas las casuísticas ni pueden probar todos los sistemas.

·      Y como punto final, podríamos decir que las pruebas son un oficio independiente y acotado. Una cosa es que desarrolladores y otras personas ayuden y apoyen a realizar pruebas, pero una persona de QA aportará una garantía y una excelencia, que lamentablemente, nadie más puede aportar (al igual que las otras personas de los otros oficios). Organizaciones que piensan que QA somos todos y que cualquier puede hacer pruebas, a corto plazo, se la acaban pegando.

Con esta serie de pautas, ideas y organización estructurada de pruebas exploratorias, podemos comenzar a implantar una muy buena estrategia en nuestra empresa y así, garantizar mucho más cualquier puesta en producción.