Desde Paradigmarecuerdan que son muchos los proyectos y clientes en los que, por falta de tiempo, se recortan tiempos y calidad en sus distintos procesos. Existen casos sonados de errores cometidos por no haber probado correctamente la calidad o la usabilidad del software desarrollado, como el fallo de software en la máquina de radiación terapéutica Therac-25 que suministró dosis de rayos X indebidas; la inexistencia de un punto en una línea de código que hizo que el dominio ‘.se’ de Suecia desapareciese; el fallo en una actualización de T-Mobile y Microsoft por la que un millón de usuarios del teléfono Sidekick perdieron sus agendas de contactos, notas, calendarios y fotos; y hace no mucho, cientos de miles de clientes de una conocida operadora móvil perdieron el servicio durante casi un día completo en España.
Según Tricentis, los errores de software provocaron 1,7 billones de dólares en pérdidas a la economía en 2017. Conscientes de la importancia de incorporar al equipo de calidad de software desde el inicio de la conceptualización de productos y servicios, Paradigma desvela las seis claves por las que los errores en la calidad del software acaban afectando tanto a la reputación de la marca como a las cuentas financieras de la empresa:
1. Definir los requisitos. Este es el primer paso a cualquier desarrollo. Es el momento en el que se define qué es lo que queremos tener y por qué. Frecuentemente, se suele caer en tener definiciones generales que van tomando forma durante el desarrollo. Esto lleva a equívocos y acaban provocando fallos tanto a nivel de código, como a nivel funcional. Se debe trabajar en tener requisitos lo mejor definidos posibles y sin definiciones abiertas que den lugar a dudas. Para ello, existen técnicas como BDD que se basa en definir la aplicación a base de ejemplos y de cómo debería comportarse, haciendo que todo el mundo lo entienda.
2. Automatizar las pruebas. En las pruebas manuales es habitual centrarse en probar los nuevos cambios, ya que es prácticamente imposible probar toda una aplicación con cada uno ellos. Esto suele provocar graves errores ya que un simple cambio puede afectar a muchas partes del código. Las pruebas manuales ayudan y, a veces son necesarias, pero es mucho más importante tener una buena cobertura de pruebas automatizadas que nos garanticen, de una forma rápida, que tanto el nuevo desarrollo como los anteriores funcionan perfectamente.
3. Desarrollar flujos automáticos. Durante el desarrollo de nuestros productos se debe tener automatizado el mayor número de flujos posibles como la ejecución de tests, revisión y entrega de código… Con esto no solo se gana tiempo, sino que se evitan pasos manuales que siempre pueden provocar errores. Por otro lado, si los flujos se automatizan, garantizamos que se lleven a cabo siempre los mismos pasos y configuraciones, algo que más difícil de cumplir si se hace manualmente.
4. Velar por la calidad del código. Se suele decir que existen dos tipos de código, el que funciona y el que no, pero esto no es cierto. Existe el bueno y el malo. El código no solo tiene que funcionar correctamente. Además de ello, tiene que tener calidad que evite futuros bugs. Para ello, hay que trabajar en puntos como: el código duplicado, nivel y calidad de comentarios, complejidad ciclomática o estándares de codificación entre muchos otros.
5. Respetar los tiempos. Los puntos anteriores son muy importantes y todos ellos tienen algo en común: todos requieren de una dedicación que debe ser respetada desde el primer hasta el último minuto. Las prisas no son buenas consejeras y nos podemos acabar arrepintiendo y mucho de recortar tiempos de cualquiera de las fases.
6. Concienciar a todos los departamentos. Seguramente, cuando repasamos los puntos anteriores, a muchas personas le viene a la mente el rol QA, pero esto es un error conceptual. Es cierto que el QA es la cabeza visible si hablamos de la calidad de un proyecto, pero la realidad es que la calidad es responsabilidad de todos y cada uno de los miembros del equipo. En algunas empresas se trabaja con un equipo externo al de desarrollo. Este equipo entra en una fase posterior, lo cual va en contra de lo nombrado anteriormente. Lo más aconsejable es que todo el equipo se sienta responsable de la calidad durante todo el proceso de desarrollo y se centre en tratar de prevenir y evitar los errores en lugar de buscarlos.
