La mala calidad del software lleva a los usuarios a la frustración, al enfado, a la decepción. A desinstalar la aplicación o cambiar de proveedor. También desespera a los desarrolladores que pierden interés en el producto o les enfurece tocar ciertas partes del código poco probables o directamente nunca probadas.
La industria del desarrollo de software ha debatido hasta la extenuación sobre los ciclos de desarrollo, el modelo a seguir, los procesos, etc. Sin embargo, pese a todo este debate aún se ven muchas situaciones en las que la calidad se deja de lado. Especialmente en startups midiendo con cuidado si su producto será viable o si es mejor dedicarse a otra cosa.
1.- No tener ingenieros dedicados a la calidad
Si nadie se dedica expresamente a la calidad del software, comprobar la calidad se convierte en una responsabilidad compartida, reducida e ignorada.
La idea es, los desarrolladores programan sin arnés de seguridad, son responsables de su código y por tanto producen código de más calidad. Entiendo que detrás de esta afirmación se incluye que los desarrolladores añadan pruebas automáticas que comprueben su código. Convirtiéndoles en automatizadores de pruebas a tiempo parcial.
Sin embargo, un desarrollador es responsable de su código haya ingenieros de calidad o no. Tenerlos sólo le ayudarían a mejorar su trabajo.
Los desarrolladores no prueban su código como lo haría un ingeniero de pruebas. Como todas las actividades, probar mejora con la experiencia. Sus pruebas no tendrían tanta maldad, tendrían miedo a romper su trabajo. Lo mismo sucede con la automatización de las pruebas más complejas.
Automatizar lleva tiempo y requiere preparación. Más allá de las pruebas unitarias, un desarrollador tendría que invertir mucho tiempo en hacerlas. Tiempo que no estaría dedicando a mejorar sus habilidades de desarrollo o a mejorar el producto.
2.- Posponer la contratación de ingenieros de calidad porque el proyecto está empezando
Al no tener QAs en las primeras fases, puede que desarrollen productos difícilmente automatizables, o que caigan en errores de arquitectura que lastren el producto indefinidamente. Precisamente en el comienzo de los proyectos es donde un ingeniero de calidad puede prevenir problemas venideros. Tratando de minimizar la «matriz del dolor», persiguiendo que cada parte del sistema sea automatizable y en general mejorando los procesos de desarrollo.
¿Es necesario crear productos mínimamente viables con una inmensa deuda técnica?
3.- No preparar pruebas automáticas
Si no se automatizan las pruebas, se tendrán que hacer manualmente o asumir que se publicará un producto lleno de bugs. Esto se puede conseguir contratando a un ejército de probadores manuales para que verifiquen cada parte del sistema en cada nueva release. Por supuesto este ejército se frustrará al pasar tantos regresivos.
Preparar tests automáticos es una inversión en el proyecto. Suponen un mecanismo de monitorización del sistema, pudiendo tener todo lo probado bajo control. También suponen una fuente de documentación del proyecto, ya que describen escenarios de uso del producto.
La automatización de pruebas es la clave para conseguir la entrega continua, si quisiéramos seguir ese proceso.
Tener una suite de pruebas automatizadas es el mejor regresivo para un producto. Permitiendo la refactorización del código sin miedo a romper nada, lo que contribuye a reducir la deuda técnica de los proyectos.
4.- Eliminar las pruebas manuales
En el lado contrario de la balanza nos encontramos con el crimen de eliminar las pruebas manuales esperando que la automatización sea suficiente. La automatización tiene muchísimos beneficios, pero nunca tendrá sentido común. Nadie como un humano puede comprender a los usuarios. La experiencia de usuario es algo que las máquinas difícilmente podrán probar (al menos en los próximos años).
Las pruebas manuales deben ser test exploratorios en los que se analice la aplicación y se tengan en cuenta los casos de uso de los clientes del producto.
Estas pruebas permiten tener un conocimiento exhaustivo del producto. Son las que dan lugar a ideas de mejora y para las que se necesita más creatividad. Cuanto más completa sea la suite de pruebas automatizadas, más creatividad se podrá usar en este tipo de pruebas, «rompiendo» el producto de diversas formas, investigando y analizando mejor los resultados.
Una corriente en empresas con alto número de usuarios es utilizar un cierto porcentaje de usuarios para conseguir feedback real sobre el funcionamiento de la nueva versión o funcionalidad. Esto es dejar este tipo de pruebas en manos de los usuarios finales, que verán la aplicación sin finalizar antes de tiempo, siendo conejillos de indias. Este modelo sólo puede funcionar si tienes muchos usuarios y si no te importa que algunos encuentren bugs de usabilidad. Pero en cualquier caso alguien deberá gestionar esos bugs, ese feedback de los usuarios finales. ¿Qué mejor que un ingeniero de calidad para esa tarea?
5.- No tener tests unitarios
Esta es una tarea normalmente en exclusiva de los desarrolladores. Pero sin ella los bugs se propagan como una plaga.
Los tests unitarios son la primera barrera de control contra posibles bugs. Son la base del test driven development, si se quisiera seguir ese proceso. Agilizan el trabajo al poder cambiar partes del código y comprobar los fallos rápidamente. Son ejemplos para los nuevos desarrolladores que se añadan al proyecto.
Algunas ideas contrarias a los tests unitarios se basan en que un buen diseño o una buena planificación arregla muchos más problemas que los detectados por este tipo de tests. Aunque el diseño sea fantástico no puedes asegurar que el código funciona sin estos tests y dependerías de otras pruebas a más alto nivel.
6.- No tener tests de integración
Los tests de integración son los que verdaderamente comprueban que el sistema está funcionando. Unen partes del sistema y comprueban que encajan sin problemas. Son la base del behaviour driven development, junto con los tests funcionales. Los tests unitarios no tienen en cuenta elementos tan importantes como los accesos a base de datos o peticiones de red. No son suficiente para comprobar que el comportamiento es correcto.
Gracias a este tipo de tests podemos encontrar bugs directamente en los pull requests sin necesidad de pasar regresivos relacionados con esa parte del producto. Hacen que el sistema sea fiable, pudiendo confiar en las partes protegidas por estos tests, ya que tendrán el comportamiento deseado al ser llamados por otros componentes. Protegen a los grupos de desarrolladores para que el código de otros componentes no les sorprenda de formas desagradables.
Al utilizar un lenguaje como gherkin para escribir este tipo de pruebas se consigue además una documentación extra sobre el funcionamiento del sistema. Pudiendo saber rápidamente qué está cubierto por los tests y qué no.
7.- No tener tests funcionales
Es un paso más allá de los tests de integración y tratan de probar el sistema como lo haría un usuario. Aquí entra especialmente la automatización de interfaces gráficas. Son las pruebas funcionales que más mantenimiento necesitan y las más lentas.
Sin embargo los beneficios son similares a los anteriores tipos de pruebas. Protegen contra interfaces fallidas, quitan trabajo a la hora de hacer pruebas manuales. Son especialmente útiles al configurarlos y prepararlos para ser ejecutados en todos los entornos en los que se distribuye o se ejecuta la aplicación. Por ejemplo en los diferentes navegadores soportados, si el interfaz a probar fuera un entorno web.
Sin este tipo de tests estamos condenados a probar manualmente las interfaces, pudiendo dejarnos en el tintero posibles combinaciones. Suelen ser los mejores para las pequeñas suites de sanity tests.
8.- No tener QA managers
El QA manager o cómo lo denominan en Google, el testing engineering manager, es alguien que domina el producto en profundidad. Conociendo sus mayores riesgos, sus debilidades y sus posibilidades de mejora. Es el que mejor puede saber dónde se deberían hacer los mayores esfuerzos de automatización o pruebas manuales.
El motivo más habitual para obviar este rol es el uso de las metodologías ágiles o post-ágiles, asumiendo que mantener una alta calidad del producto es una responsabilidad compartida de todo el equipo. Aún así alguien tiene que tomar las decisiones y en estos casos son los líderes de desarrollo.
Eliminar los QA managers recordando los procesos de desarrollo en cascada es un error. Debe ser un rol diferente, alguien que tiene una visión de pájaro sobre el producto, siendo el líder de un departamento de calidad virtual mejorando el producto en su conjunto.
En un entorno ágil hace falta ser flexible, preparados para el cambio y ser capaces de introducir mejoras en los procesos. Precisamente es donde este rol destaca. Descargando a los desarrolladores de tomar decisiones relacionadas con las pruebas (no unitarias) y pudiendo interactuar con ellos para tomar las decisiones apropiadas.
Alguien tiene que escoger las herramientas principales usadas para automatizar, preparar entornos de pruebas, seguimiento de los bugs etc. Si en cada parte de un producto se usan unas herramientas diferentes será más difícil cambiar de rol a los ingenieros. Además dominar unas herramientas concretas centra los esfuerzos de preparación.
Sin un QA manager, no habrá nadie con poder suficiente para rebatir a los líderes de desarrollo desde el punto de vista de la calidad. Los ingenieros de calidad quedarán a merced de los desarrolladores, enfocándose en los problemas inmediatos en lugar de afrontar los mayores riesgos. Dándose la situación de desarrolladores con arnés de seguridad que mencionaba al principio.
Dicen que Leonardo Da Vinci en su lecho de muerte dijo: «He ofendido a Dios y a la humanidad porque mi trabajo no tuvo la calidad que debía haber tenido». Podéis evitar sentiros como él.
Posts relacionados:
