Concrete Logo
Hamburger button

Cómo hacer (o tratar de hacer) atomatización de pruebas en sprint

  • Blog
  • 18 de Junho de 2019
Share



Frecuentando Meetups y conversando con profesionales de QA de otras empresas, siempre surge el tema sobre la dificultad de implementar la automatización de pruebas dentro de Sprint. Por eso tuve la idea de contar cómo fue (y está siendo) mi experiencia con automatización aquí en el Concrete. En el caso de que se trate de una persona que no sea de su familia,

Para que el método funcione, sin embargo, son necesarios algunos prerrequisitos, que basé en conversaciones y lecturas sobre el asunto y en mi experiencia en el Concrete. Son ellos:

EMPRESA

En los casos con más éxito citados en las conversaciones la empresa (o al menos algunos cargos de dirección) compra la pelea para girar agilidad, independiente del framework (si Scrum, Kanban u otro). En estos casos, si el equipo equivocado es estimulado a intentar de nuevo, y no castigado por los errores.

Esta pelea también va para la empresa cliente que quiere “cascatear” el proceso. Si su empresa acata las decisiones de la empresa cliente de cómo el equipo debe trabajar sólo para no perder la venta, la probabilidad de fracaso es alta.

TIEMPO

Aquí, vamos a considerar al equipo como un grupo de personas trabajando con el objetivo de agregar valor al producto, todas juntas con el mismo objetivo.

El equipo debe compartir información, ideas, dolores, éxito y fracaso, trabajando como una entidad única.
Un equipo es diferente de un grupo de trabajo de acuerdo con la forma en que las personas se comportan. En un grupo de trabajo, cada uno hace el suyo sin pensar en lo que puede afectar al otro. ¿Sprint falló? “Yo entregué mi trabajo en el plazo, no tengo nada con eso”. O peor: “quien no hizo y perjudicó al equipo fue esa persona ahí”, apuntando el dedo.

Y en el caso de que no sea así. El timito sabe trabajar en unión, pero sólo hace lo que es mandado. Puede incluso pensar en mejoras, pero si el objetivo está siendo atendido, por qué mover?

Si usted está en un grupo de trabajo, difícilmente podrá automatizar durante Sprint. En los otros casos, la probabilidad es grande. Y si está en un timito, ¿por qué no tratar de convertirlo en un equipo? Exponga sus ideas de integración en las retros o llame al equipo para conversar después de una diaria, ya que estarán juntos.

IMAGINACIÓN

Para automatizar una funcionalidad que no existe también se necesita un poco de imaginación. Si usted ya tiene el diseño de las pantallas se hace más fácil, pero si no lo tiene, imagine el flujo. Su código, en principio, va a automatizar funciones como el relleno de un campo o el click de un botón independiente de su posición en la pantalla, el color o la forma.

“Pero no sé los IDs !!!”, usted dice. Dos soluciones que utilizo:

Deje el campo en blanco o con alguna indicación para completar después, o
Cree una variable que permita la construcción clave-valor (hash, hashmap o dict, por ejemplo). Rellene el campo con el nombre de la variable [none_la clave]. Después es sólo completar el segundo miembro de la igualdad con los valores que usted está descubriendo.
Con este método ya he podido terminar mi código de funcionalidad junto con el Dev! En ese entonces, sólo mapear los ID y hacer pequeños ajustes que la funcionalidad ya estaba automatizada.

MI FLUJO

Todo comienza en la reunión de planificación (planning), en la que decidimos el backlog del sprint. Supongamos que el objetivo del sprint es la realización del login (siempre el login como ejemplo …).

Escriba todos los escenarios posibles para la realización de un inicio de sesión. Antes de salir automatizando todo, defina cuáles serán unarios / instrumentados, cuáles serán de servicios / API, y cuáles serán del front.

Divididas las responsabilidades y automatiza primero todos los “caminos felices”, aquellos en que todo va a ser hecho y llenado con perfección. De nada sirve una funcionalidad que no realiza su función si el usuario hace todo bien.

Volviendo, escriba todos los escenarios posibles de inicio de sesión con éxito, por ejemplo:

Funcionalidad: Iniciar sesión con éxito

Escriba todos los que su sistema va a soportar.

IMPLEMENTAR LOS ESCENARIOS

Aquí viene la imaginación. Los escenarios se implementarán sólo con el diseño de la pantalla de inicio de sesión.

Mi archivo de pasos, sin la implementación, queda así:

Se ve que aunque mi archivo de características ha quedado grande, sólo tengo tres pasos para implementar. A la hora de escribir cualquier cosa en su código es muy importante pensar en la reutilización. Después de implementar “con mi imaginación”, los pasos van a quedar así:

Y los archivos de page objects, variables y métodos, utilizando SitePrism y Capybara:

Ahora sólo esperar a que la pantalla de inicio de sesión esté lista y completar el código que la funcionalidad ya está automatizada! Solo que no…

Incluso si usted reemplaza todo derecho, la probabilidad de que dé algún error en la primera (segunda, tercera …) la ronda es enorme. El ejemplo anterior es sólo para servir como base. Es legal arreglar los errores según el registro de ejecución apuntando. Incluso con los errores iniciales, seguramente es más fácil y rápido hacer ajustes que esperar a que la funcionalidad esté totalmente lista para escribir el código. Los errores van a disminuir al paso del tiempo.

Además, no es sólo porque usted ha terminado una característica que se quedará sentado esperando. En un equipo ágil, siempre tiene algo que hacer. Siente con la persona responsable de DevOps y vea cómo anda la pipeline del CI / CD, busque saber cómo va el desarrollo de la aplicación con quien desarrolla, converse sobre el backlog y la usabilidad. Interactúa con el equipo, da sugerencias para mejoras, apunta problemas (si es posible ya con soluciones). Usted es responsable de la calidad del producto, y no sólo por automatizar las pruebas.

No olvide la prueba manual exploratoria

Siempre separe un tiempo para usar su producto, sólo así usted tendrá el completo conocimiento de cómo está funcionando. No se asegure a automatizar solamente los requisitos descritos en las historias, pues muchas cuestiones e incluso nuevas automáticas van a surgir con el uso de la aplicación. Las pruebas automatizadas y manuales son complementarias, no excluyentes.

Hasta me arriesgaría a decir que, actualmente, con la gran exigencia de automatización, profesionales de QAs también deben “retroceder” un poco y hacer pruebas manuales. Espero que pueda tomar la idea general de este texto y aplicar en el contexto de su empresa. Y no se olvide de comentar aquí cómo está la experiencia! ¿Tienes alguna pregunta o quisiera compartir tu experiencia? ¡Deja un comentario abajo!

Y si quieres saber más aquí tienes algunos consejos.

  • Podcasts de Samanta Cicília y de Federico Moreira (lo recomiendo mucho!)
  • Libro Scrum: El arte de hacer el doble del trabajo en la mitad del tiempo.
  • Libro Agile Testing: La Guía Práctica para los Testers y Agile Teams.
  • Libro More Agile Testing: Learning Journeys para el equipo completo.

¡Hasta la próxima!