Pruebas Automatizadas de Calidad de Software

Business_Software“Es necesario contar con modelos maduros de gestión integral de pruebas, que permitan principalmente, validar la calidad de los productos de estos dispositivos.”

¿Qué significa “probar bien”?
Cada vez es más común encontrar, tanto en México como en el resto del mundo, empresas y profesionales de la industria de TI convencidos de la importancia que tiene garantizar la calidad de los productos de Software y Hardware (dispositivos) antes de su puesta en producción y antes de incurrir en altos costos operativos. Esto implica arreglar errores en producción: de trabajo de toda el área de TI, del usuario quien deberá validar una vez más la nueva versión, penalizaciones de entidades gubernamentales por incumplimiento de normas, etcétera; pero principalmente, antes de pagar el costo que implica la imagen y confianza hacia sus clientes, quien tiene el poder y la libertad de decidir ir con la competencia en cualquier momento.A pesar de que las empresas están invirtiendo cada vez más en tecnología de desarrollo, en mejorar su infraestructura, e incluso en la implementación de procesos de mejora continua (por ejemplo:CMMi/TMM), los resultados en cuanto a Calidad de Software no mejoran, por lo menos no en la misma proporción de la inversión de tiempo y costos que han realizado.
Casos de prueba
Una de las razones que explican esto, sin duda, es que la mayoría de estas empresas mantienen la práctica de realizar pruebas manuales para tratar de encontrar el mayor número posible de defectos en los sistemas, lo que deja abierta una serie de situaciones que aumentan la posibilidad de no detectar defectos a tiempo, como errores en la ejecución de los Casos de Prueba (captura incorrecta del “especialista en pruebas”), baja cobertura de pruebas (probar sólo lo que se definió y no lo que se debería), falta de tiempo para probar (probar lo que el tiempo permita y no lo que se debería), etc.Además, esta práctica explica por sí misma, porqué las empresas por lo regular sólo prueban “los defectos encontrados en el ciclo anterior”. Es simple entender que si un proceso de pruebas manuales requiere, por ejemplo dos o tres semanas de pruebas y se detectaron cierto número de defectos en este primer ciclo, cuando estos defectos son arreglados y se tiene la nueva versión, por lo regular no se cuenta ya con otras dos o tres semanas para volver a probar todo, por lo que en el segundo ciclo de pruebas se ejecutará sólo una parte de todos los Casos de Prueba (CP) del primer ciclo. Esto se repite para el tercer ciclo y así sucesivamente. Claro está, que en cada nuevo ciclo de prueba se están dejando sin probar una cantidad enorme de casos que “ya estaban bien”, pero que nadie garantizará “que sigan bien”, dado que en el proceso de corrección de defectos que hace el área de desarrollo es muy probable que el código modificado afecte
funcionalidad antes correcta.Para no incurrir en esta práctica, las empresas deberían de contar, además del tiempo para probar de nueva cuenta todo, con el presupuesto que significa volver a contratar a la empresa de pruebas manuales para ejecutar dos, tres o cuatro veces el mismo número de Casos de Prueba (CP); es decir, multiplicar por “n” el costo actual del servicio de pruebas, por lo que en la mayoría de los casos, lo hace inviable.

 

Por: David Ballesteros G.
Si desea conocer el texto completo busque nuestra edición de Diciembre en todos los Sanborns del país.

ARTÍCULOS RELACIONADOS

El Big Data, sin duda alguna, se ha convertido en una constancia día a...
Entre los posibles riesgos, la seguridad de la información es el más peligroso y...
Negocios como hoteles, restaurantes, bares, centros de entretenimiento como cines, tiendas de mochilas y...