Cada día los negocios y sus procesos críticos dependen más de la tecnología; los usuarios finales o clientes esperan que ésta les asegure rapidez y confiabilidad en los procesos. Por otro lado, la competencia y el mercado imponen plazos más perentorios a la puesta en producción de nuevos sistemas y aplicaciones, realidad que plantea un enorme desafío al área de Quality Assurance.
En nuestro país recién empieza a tomar relevancia el Quality Assurance (QA), es decir, aquellos procedimientos y herramientas que buscan asegurar determinados niveles de calidad a los sistemas. Es en este contexto que el Testeo de Calidad -Quality Testing- juega un rol muy importante, orientándose a probar que una aplicación funciona bien o que no se encontró errores.
Una nueva definición
Sin embargo, más que tratar de probar que algo funciona, debemos probar que no lo hace. Proponemos así una definición de Testing que difiere de la generalizada y que lo describe como el proceso de ejecución de un programa o sistema con la intención de encontrar fallas.
El software sin defectos es por esencia inalcanzable, porque es uno de los productos más complejos producidos por la mente humana. Pensar que es posible implementar soluciones libres de errores en un 100% es exponernos directamente a tener problemas. Debemos establecer procesos que nos permitan encontrar problemas, que sabemos están ahí. También estamos al tanto de que introduciremos código defectuoso en ambientes de producción, lo que perseguimos es minimizar el impacto de esos defectos.
Plazos reales
Uno de los errores más significativos en relación al Testing, es que tradicionalmente se piensa que en el proceso de desarrollo hay una etapa específicamente destinada al testeo. Esto se grafica en el siguiente ejemplo: “esperamos que el código esté listo para el 1º de este mes, la fecha de paso a producción es el Lunes siguiente al 18, así es que tenemos todo el próximo mes para el Testing”.
Hay dos problemas en esta forma de pensar. Primero, el Testing nunca empezará en la fecha predefinida, con suerte comenzará 15 días después. Por otro lado, el día de puesta en producción es inamovible, por lo tanto, habrá sólo 15 días para el Testing en vez de los 30 originalmente programados.
El otro inconveniente es que nunca habrá el tiempo necesario y aún los 30 días originalmente considerados no son suficientes. Por lo tanto, hay que iniciar el testeo el primer día en que se empezó a trabajar en el sistema, ya que “éste no es una fase del proceso de desarrollo, es parte de todas las fases”.
Desde el primer día
Será necesario hacer Testing a lo largo de todo el proceso de desarrollo, lo que permitirá una gran mejora en la calidad del testeo y del producto, y ayudará a obtener considerables ahorros de tiempo y dinero.
Por eso, el contar con herramientas que automaticen el proceso, dismi-nuyan los errores humanos y, a la vez, los tiempos y costos asociados, es una inapreciable ayuda para alcanzar la definición propuesta: “Testing es el proceso de ejecución de un programa o sistema con la intención de encontrar errores”.
En este contexto, suites de soluciones integrales de QA que consideran el testeo como algo continuo que acompaña al proceso de desarrollo desde el primer día, son las mejores respuestas a esta búsqueda y a la erradicación de errores en los sistemas.
Octubre de 2003
