La inclusión de pruebas de calidad en un desarrollo de software

No es un secreto que en muchos libros de desarrollo de software se reflexiona siempre sobre la inclusión de las pruebas de calidad en este proceso. Si no prestamos atención a la calidad, los costes de mantener el producto y la capacidad de entrega se verán afectados al tener que estar constantemente corrigiendo la aplicación o resolviendo incidencias encontradas por el propio cliente final. A todo esto, tenemos que sumar que nuestra aplicación dará un mal servicio al estar llena de fallos.

Muchas veces recibimos un código que inevitablemente tiene algunos errores y tenemos que arreglarlo, pero ¡sin romper nada!, porque si se rompe “algo” habría que arreglar todo completo. Para que este no falle, sería como mantener un código sabiendo que la persona que lo va a usar, fuera un psicópata violento que sabe dónde vives. De hecho, cuando el código es caro de sostener, se decide empezar de nuevo la aplicación.

Ahora bien, no podemos esperar en cualquiera de los dos casos una calidad total ya que es muy costosa. Sin embargo, sin un nivel elevado de calidad, es difícil sostener los costes y la tan esperada entrega de valor.

Existen tres frases que van matando la calidad en el desarrollo software históricamente, vamos a repasarlas:

La primera frase es “Siempre va a haber incidencias”. No podemos aspirar a una calidad total con cero incidencias, eso es cierto. Los equipos con altos niveles de calidad tienen un número bajo de incidencias.
La segunda es “Si al final tenemos tiempo hacemos test”. Con esta frase, tratamos de explicar que nos centraremos en el alcance, que es lo que ha pedido el cliente, y una vez finalizado, prestaremos atención a la calidad de nuestro producto. Sin embargo, la experiencia nos demuestra que nunca hay tiempo para la calidad. El cliente acaba por solicitar cambios al recibir las primeras funcionalidades, y esto es debido a que las necesidades cambian o aparecen nuevas. El resultado es que llegamos a una fecha sin test de ningún tipo, que acaba por generar incidencias y un mal servicio a los usuarios.
Por último, la tercera frase más utilizada es “En la siguiente fase lo arreglamos”. En muchos equipos, corremos para acabar un primer entregable en fecha, y dejamos la calidad para la siguiente fase o contrato con el cliente. Sin embargo, cuando la fase 1 ha ido mal, y hemos tenido que echar horas extra para “llegar”, nos costará cambiar de estrategia en la fase 2. El problema de fondo es la cultura de relacionar el éxito con la entrega en fecha, y no con la calidad del servicio que se presta. De hecho, si nos quejamos por el número de incidencias que generamos, alguien nos recordará la primera frase “Siempre va a haber incidencias”.

Si McDonald’s funcionara como una compañía de software, uno de cada cien Big Mac’s te envenenarían, y la respuesta sería ‘‘lo sentimos, aquí tiene un cupón para dos más” Mark Minasi.

¿Cuál de estas habéis escuchado en BABEL o en vuestro equipo?

Por ello, si se incluye en el equipo de desarrollo desde el principio a una persona de QA, que se dedique a asegurar la calidad del producto mientras se está en fase de desarrollo, entonces: