Es innegable que la era digital cuyas raíces datan del último cuarto del siglo XX y que, en estas primeras dos décadas del siglo XXI se ha manifestado de forma exponencial en nuestra vida cotidiana, en nuestro trabajo y en nuestra forma de entender el mundo, ha supuesto desde su inicio un conjunto de desafíos técnicos y metodológicos para la cada vez más grande industria del software, en particular en el área de la calidad.
La necesidad de diseñar software de calidad y testearlo mediante algún proceso formal con el fin de comprobar su operatividad (aunque sea mínima), inició en conjunto con el desarrollo de los primeros programas que ofrecían funcionalidades complejas, por allá a finales de los años 70. Una pequeña muestra de ello –y para no abrumarnos con la historia-; es que el software completo para la misión Apollo 11 (1969) requirió unas 145.000 líneas de código, diez años después, tan solo el software que daba pie a la preparación del lanzamiento requería ya 400.000 líneas de código con un testeo aproximado en términos de tiempo de un 60% total del proyecto. Esta creciente complejización del software impuso (e impone aún) un desafío de ingeniería sobre las formas y técnicas para testear los desarrollos, validar la operatividad, funciones, mantenibilidad de las pruebas, etc. En un sentido más amplio; asegurar la calidad del mismo.
Con el tiempo, diferentes y ampliamente difundidos frameworks como el “Modelo de cascada” y el “Modelo V” plantearon soluciones acotadas, y por qué no decirlo; acordes a su época, para el problema del testing, estableciendo en todos los casos una significancia directa entre calidad = pruebas = etapa. Esta visión de la calidad como una etapa dentro de un proceso de desarrollo y tan difundida como la “parte del Quality Assurance (QA)” se halla aún arraigada hasta el día de hoy en organizaciones que han debido –por los avatares del tiempo y la época– crear o al menos intentar formar sus propios equipos internos de desarrollo de software, aunque aún más llamativo es que esta idea se encuentre también en empresas que ofrecen servicios de QA (o Testers, Ingenieros de calidad, Ingenieros de automatización de pruebas, etc…). Esto es fácilmente comprobable con un experimento casero, preguntando a cualquier persona que tenga nociones sobre desarrollo de software que describa el flujo de la creación y liberación de un programa informático (por ejemplo), es altamente probable que describa a grandes rasgos algo como:
Desarrollo -> QA -> Deploy… y si se interroga sobre ¿Qué es el QA?, probablemente responda; Pruebas.
Para entrar un poco en detalle de lo recién comentado, la visión “clásica” establece al Quality Assurance, que para estos fines comprendemos en la forma de: “la ejecución de pruebas”, como un hito en el flujo de desarrollo de software, una etapa donde el producto entra en una etapa de pruebas, por ende, se entendiente como la etapa de “pruebas/calidad”, esto incluso en equipos que trabajan bajo alguna metodología ágil y no es difícil entender el porqué de esto; uno de los argumentos que podemos encontrar es que la definición del concepto de la calidad y pruebas, así como del Quality Assurance, no ha sido casi tocada en 30 años y las metodologías ágiles (por nombrar lo más común actualmente) no se preocupan como tal de los pormenores metodológicos del “Cómo”, al menos en lo que respecta a los conceptos heredados de calidad. Es decir, el aseguramiento de calidad tiende a asociarse a una etapa donde se realizan pruebas, cualquiera sea el índole de estas, pero con las cuales, se asume que, aseguramos la calidad del producto. El aseguramiento de la calidad entonces, equivale a realizar pruebas.
La historia no termina acá, pero en un próximo post te seguiremos contando…