Todo el mundo habla de velocidad, de aceleración, de agilidad, de ir a la carrera para llegar más rápido y más tecnificado. Pero, ¿cuál es el costo de pretender ser el cowboy digital más veloz?

En una reciente encuesta que realizamos a más de 600 líderes de Ti y de QA de Latinoamérica acerca del principal problema o desafío asociado a las pruebas de software, encontramos que la gran mayoría alude el hecho de tener que trabajar con planes improvisados o deficientes de pruebas, donde muchas veces los desarrolladores o los dueños de producto interfieren para lograr un time to market que atenta brutalmente con un plan de calidad coherente y objetivo para el negocio.

Citamos a modo de ejemplo la respuesta de una líder de QA en Latinoamérica “La principal frustración que me he visto enfrentada es que los equipos de desarrollo hablan de pruebas de software y no de calidad de software, por lo tanto, se preocupan más de las pruebas de poco alcance y funcionales, que de entregar un software que cumpla con los atributos de calidad. Se preocupan más de la fecha de entrega, que de verificar lo necesario para que un software funcione correctamente, a veces generando re trabajo”

Como este testimonio, hay varios que refieren a lagunas en la documentación y en criterios de aceptación alineados con el logro de mejores resultados para el negocio.

Sucede que, se presupone que la calidad del software es inherente a los desarrollos, pero ha resultado ser la variable más débil cuando una organización emprende aceleradamente numerosos proyectos. 

Y es que muchas veces el paradigma de cumplir la fecha de entrega a toda costa y el de no sobrepasar presupuestos es una paradoja, ya que el costo en el que se incurre cuando los equipos de desarrollo aceleran la entrega de un proyecto mal probado, o que después necesita ser recodificado, es el Harakiri de cualquier iniciativa de transformación digital.

Las causas de este círculo improductivo se deben a las malas prácticas y metas corporativas equivocadas, que hacen que los equipos adopten una dinámica poco crítica, no colaborativa, que elige saltarse pasos y tomar atajos que lo pueden llevar a un precipicio.

Usualmente los hechos se suceden de la siguiente forma:

El equipo manifiesta haber terminado una funcionalidad que se transfiere a QA para ser probada, pero hay una definición carente de pautas de calidad, con vacíos en los criterios de aceptación, en los que muchas veces no se cubren acertadamente los requerimientos del negocio. Así que en esa relación débil entre el área del negocio, desarrolladores y testers, en conjunción con la comunicación poco efectiva acerca de los objetivos del proyecto,  se genera gran deficiencia en la estrategia de pruebas.

De modo que al probar de forma parcial, se continúan agregando deficiencias cada vez que se desarrolla y se aceptan avances en estas condiciones. Es aquí que comienza una espiral para tratar de mejorar las fallas incorporadas, pero la bola de nieve va creciendo, hasta el punto que es insostenible mantener el error y el equipo de QA se convierte en el enemigo de los desarrolladores. Entonces hay que dar marcha atrás corregir, retestear y hacer pruebas más exhaustivas. Luego QA pide presupuesto para diagnosticar la causa del problema de forma más eficiente, pero en esta instancia los humos están calientes y tecnologías que podrían acelerar la cadena como las pruebas automatizadas se perciben aún como una ralentización del desarrollo. Muchas empresas (incluso las que practican la agilidad) creen que las pruebas automatizadas son más engorrosas y costosas que las manuales y prefieren seguir consumiendo tiempo y esfuerzos haciendo que las pruebas de regresión sean poco consistentes y muy largas, disminuyendo aún más la entrega del software. 

Según nuestra experiencia aún existen paradigmas y tabús acerca de la automatización, pero hay evidentes beneficios que las empresas deben aprovechar.

Para resolver este círculo vicioso se deben tener en cuenta aspectos como:

• Mejorar las instancias de comunicación de los equipos
• Integrar al equipo, a todas las áreas involucradas en el proyecto. 
• Dar participación activa y temprana a los Testers, ya que deben compartir el mismo objetivo que el resto del equipo.
• Considerar la automatización para aportar rentable y ágilmente al desarrollo.
• Tener iteraciones frecuentes con el dueño del proyecto PMO o cliente final, para ir viendo avances y oportunidades de mejora de forma anticipada.
• Alinear expectativas a medida que avanza el proyecto.

Si te identificas con esta situación y no quieres repetirla o si quieres evitarla en tus proyectos, no dudes en incluir la automatización como parte de tu estrategia de pruebas y liberación de software.

Emplea herramientas de automatización que aceleren resultados y que no impacten en los tiempos de creación y ejecución de pruebas, considera soluciones robustas, fáciles de usar, que proporcionen evidencia con reportes de fallas accionables y que se integren con metodologías ágiles de forma sencilla.