spinner

Los 10 errores más comunes del QA

Los seres humanos cometemos errores, forma parte de la vida y de nuestro aprendizaje y crecimiento como personas. En un equipo además se cometen errores colectivos de muchos tipos. En este artículo expondremos los 10 más comunes del QA (es decir, de todo el equipo). Recuerda que QA somos todxs.

“Ser o no ser, hé ahí la cuestión” es un monólogo que unimos siempre a Hamlet de William Shakespeare ya que siempre está en el imaginario colectivo la imagen de Hamlet sosteniendo la calavera y recitando el famoso monólogo. El problema es que en la obra Hamlet nunca recita el monólogo con una calavera en la mano, la calavera aparece en otro acto diferente. Este es un error colectivo, como tantos otros, que se ha ido pasando de generación en generación y se ha perpetuado.

El problema número 2 es que, aunque sabemos que es un error, continuamos uniendo el “to be or not to be” a un Hamlet sosteniendo una calavera y no lo corregimos. QA trata, entre otras cosas, de asegurar la calidad del software previniendo los errores, pero hay errores que hacen que el proceso de calidad sea menos preciso. En este post trataremos de identificar los 10 más comunes dándoles una solución para que no se perpetúen y el proceso de calidad fluya mejor.

1.- Falta de comunicación

La comunicación es la clave de cualquier trabajo en equipo y especialmente cuando hablamos de desarrollo software. En ocasiones la falta de comunicación en el equipo, la distancia que se marca con la persona enfocada en QA o la separación del equipo de desarrollo del resto de componentes del proyecto hacen que la calidad del mismo se resienta.

La falta de comunicación es una clara indicación del resultado de la puesta en producción de un producto y de la calidad con la que va a salir, no sólo hablamos de calidad del producto final, si no de la calidad de trabajo del día a día, un proyecto con un equipo en el que haya mal ambiente o falta de comunicación dará como resultado un producto fallido.

Igual que decimos que todos somos responsables del producto y de su calidad, también lo somos de la comunicación con todos los integrantes del proyecto y por eso se deben de atajar cuanto antes todos los problemas que hagan que falle esa comunicación.

Otra clave para que nuestro producto sea exitoso es la estabilidad del equipo: cuando el equipo esté formado y rodado (todo lleva su tiempo) se debe de intentar que éste permanezca todo lo estable posible, ya que una alta rotación podría dar resultados negativos.

2.- Formación insuficiente

Es bastante significativo que muchas veces se tenga una falsa percepción de los conocimientos de los conceptos de calidad y se confundan términos como QA y testing, no saber qué engloba la calidad, cómo medirla, cómo gestionarla o simplemente cómo implantarla.

En algunos proyectos la calidad se considera un trámite para poder subir a producción el producto y no se tienen en cuenta los beneficios tanto a corto como largo plazo que puede tener aplicar una estrategia de calidad, un plan de pruebas, una gestión de errores o un plan de automatización.

Los equipos deben de estar correctamente formados e idealmente contar con una persona que esté enfocada a la calidad dentro del proyecto para que ayude, forme, recicle, aclare conceptos y haga que la calidad sea un proceso al mismo nivel del desarrollo del producto. Si esto no fuera posible, los equipos deberían de buscar aquellas formaciones necesarias para poder llevar a cabo el proceso de calidad dentro del proyecto con éxito.

3.- Falso ahorro de costes

De todos los errores que se cometen al tratar de implementar la calidad dentro de un proyecto, el de la percepción de un falso ahorro de costes por ahorrar en personas especializadas en calidad, herramientas o formaciones quizá sea el más grave. O peor aún: no incluir un plan de calidad cuando se vende el proyecto, lo que hace que se incrementen los costes del mismo paulatinamente, que se creen cuellos de botella como resultado de introducir la calidad (mucho) después de haber iniciado el desarrollo o que se detecten los errores encima de hora y se tenga que retrasar la puesta en producción; en este caso el coste es doble: monetario porque el equipo tiene que hacer horas extras y moral, porque el equipo al tener que hacer al final el doble de trabajo se desmotivará y correremos el riesgo de crear burn-out entre sus miembros.

4.- Falta de planificación y tardanza

La falta de planificación de un plan de calidad o la tardanza en el mismo va unido al punto 3 de falso ahorro de costes. Cuando ideamos o vendemos un proyecto debería de incluirse el plan de calidad del mismo: equipo necesario, pruebas, cómo se desarrollará, herramientas…

Muchas veces, por desgracia, el proyecto que no ha tenido en cuenta la calidad desde el minuto cero se da cuenta (tarde) de que debería de hacer algo y se inyecta calidad en un estadio muy avanzado del desarrollo, al personal enfocado en la calidad se le demanda que en un corto espacio de tiempo entienda el producto, haga una estrategia de calidad, un plan de test, proponga las herramientas necesarias, automatice y se integre en el equipo, spoiler: suele salir mal.

5.- Poca o nula implicación del equipo

Otro de los puntos flacos en cuanto a la calidad suele ser una falta de implicación de los equipos, es decir, no se entiende el concepto de desarrollo sin testing, cuando el testing debería de formar parte del desarrollo de las funcionalidades del producto, por lo que la frase “la calidad es cosa de todos” se queda en eso, una frase, que no se aplica a la realidad del día a día del desarrollo del producto, en el que o no se hacen test o los test que se hacen los hace una sola persona, en general especializada en calidad (conocida como tester) y corremos el peligro de crear cuellos de botella además de ser señalado como el responsable de la tardanza de entrega de código.

6.- Separar desarrollo y testing

¿Cuántas veces desarrollo acaba una funcionalidad y se la pasa a testing para probar? ¿Cuántas de esas veces salen errores básicos que se habrían podido evitar si desarrollo hubiera hecho unas pruebas básicas? Es una práctica común que dentro de un mismo equipo se separen desarrollo y testing como si fueran dos cosas completamente distintas.

Es necesario entender que cada paso que se da a la hora de desarrollar un producto sirve para algo, que todo suma y no debemos dejar de ver el trabajo de los otros como algo ajeno a nuestras tareas diarias, tenemos que tratar de entender y aprender lo que hacen los demás. En ocasiones sentarnos con una compañera o un compañero y que nos explique su campo de expertise o realizar reuniones para compartir conocimientos entre todo el equipo afianzará no sólo las relaciones si no que repercutirá positivamente en el producto final.

7.- Dejar las pruebas para el final

¿Vamos para bingo? 😀 ¿cuántas veces se han dejado las pruebas para el final? ¿Cuántas veces se ha dado a entender que las pruebas eran el cuello de botella?

Dejar las pruebas para el final sólo traerá más problemas a lo largo del tiempo y alargará el tiempo de desarrollo, no hay mucho más que decir, ¿no?

8.- Falta definición de calidad por el Product Owner

El Product Owner es el dueño del producto, si traducimos las siglas del inglés. El producto debería de cumplir con las expectativas que los Stakeholders y el equipo hayan pactado y con unos estándares de calidad. ¿Cuántas veces el Product Owner da por hecho esto?

El Product Owner, como el resto del equipo, pero en su caso en mayor grado, debería trabajar codo con codo con la persona orientada a la calidad dentro del equipo y debería de tener claro cómo quiere que salga su producto, qué es la calidad, qué pruebas debería de pasar su producto y cómo se va a llevar a cabo. Debería de tener esto tan claro como la definición funcional y pactada con los Stakeholders.

9.- DevOps separado de QA (tender al CI + QA + Sec)

Volvemos a la separación, falta de comunicación y la no cooperación entre equipos, entendiendo que DevOps es un ente separado de QA cuando QA debería de formar parte de todo el proceso de trabajo de un producto y debería de trabajar codo a codo también con DevOps.

10.- Olvidarse del Post-Desarrollo (Soporte usuario, documentación, operaciones, alertas, etc)

Una vez entregamos nuestro producto nos desentendemos de él. Los productos software están vivos siempre que un usuario los utilice y aunque no evolucionen pueden tener muchos problemas desde errores que no se hayan solucionado previamente hasta malinterpretaciones del usuario final que no entiende su uso.

Mucha gente confunde agilismo con falta de documentación. Esto es un error, la documentación debe de tenerse en cuenta durante todo el proceso y debe de formar parte de la entrega del producto, esa piedra angular debe de incluir algún tipo de soporte al usuario que le permita entender el propósito de todo o partes de la funcionalidad. Sin eso, nuestro producto, carece de calidad.

En resumen y para no caer en las mismas trampas una y otra vez podríamos concluir que el 90% del peso en los errores que cometemos al hacer el proceso de calidad está en la falta de comunicación. Escuchar a todo el equipo, tener en cuenta las opiniones y colaborar para remar en la misma dirección nos hará mucho más fácil el trabajo. Parece evidente, pero como en el monólogo archiconocido de Hamlet: “Olvidamos que la calavera nunca estuvo allí”.

Fuente foto principal: Unsplash

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?