Prueba del software: más que una fase en el ciclo de vida

Abstract

5HFLELGRRGHHDJRVWRRGHHPRGLLFDGRRGHHHQHURRGHHDSUREDGRRGHHHQHURRGHH Palabras claves Caminos de ejecución, capacidad de prueba, escenario de SUXHEDXMRRGHHGDWRVSUXHEDDGHOOVRIWZDUHYHULLFDFL³Q Resumen La prueba de software es probablemente la parte menos comprendida del ciclo de vida del desarrollo de software. En este trabajo, mediante una propuesta metodológica de cuatro fases, se muestra por qué es difícil detectar y eli-minar errores, por qué es complejo el proceso de realizar pruebas y por qué es necesario prestarle más atención. Abstract Software testing probably is the least understood part of the software testing life cycle. In this work, by means of a methodological proposal of four stages, is showed why is complex the process of carrying out the testing software, why is necessary to pay it more attention and why is so GLIIFXOWWWRRGHWHFWWDQGGGHOHWHHWKHHPLVWDNHV INTRODUCCIÓN Toda empresa que desarrolla software prueba sus productos pero, aun así, antes de entregarlos siempre contienen ano-malías residuales de diversa gravedad. A veces, es difícil imaginar cómo es que los probadores no detectan algunos errores evidentes. En muchas empresas, los probadores están mal preparados para ejecutar la difícil tarea de ensayar los productos software, cada vez más complejos. Los resultados en muchas encuestas informales, hechas a los asistentes a se-minarios, sugieren que algunos de los que realizan pruebas, como profesión o como un complemento al desarrollo, tienen un adecuado entrenamiento en pruebas o tienen acceso a bue-nos libros de pruebas de software. James Whittaker [1] brinda algunas luces acerca de por qué el proceso de probar el software actual es tan retador e LGHQWLLFDDYDULRVVHQIRTXHVVFRQFUHWRVVTXHHWRGRVVORVVSUREDGR-res deberían ser capaces de aplicar fácilmente: el probador HHFLHQWHHWLHQHHDDVXXGLVSRVLFL³QQXQQDPSOLRRFRQMXQWRRGHHW©FQL-cas de prueba, entiende cómo se utilizará el producto en su entorno operativo, tiene buen olfato para encontrar errores sutiles y tiene a la mano una bolsa de trucos que sabe utilizar. Los métodos que se describen en este trabajo pueden ayudar a los probadores para dar una respuesta sensata a la cuestión de lo que realmente quieren expresar cuando dicen: "estamos ejecutando pruebas a un sistema software". Los desarrolladores conocen la frustración cuando se reci-ben reportes de errores de parte de los usuarios. Cuando esto sucede inevitablemente se preguntan: ¿cómo escaparon esos errores a las pruebas? Sin duda que invirtieron incontables horas en el examen cuidadoso de cientos o miles de variables y sentencias de código, así que ¿cómo puede un error eludir esta vigilancia? La respuesta requiere, en primer lugar, una mirada más atenta a las pruebas de software en el contexto de desarrollo y, en segundo lugar, es necesario comprender el papel que juegan los probadores y los desarrolladores en dicho contexto dos funciones parecidas pero muy diferentes. Suponiendo que las anomalías que reportan los usuarios realmente son errores, la respuesta a la anterior pregunta po-dría ser cualquiera de las siguientes: (OOXVXDULRRHMHFXWDDXQQF³GLJRRQRRSUREDGR3RUUIDOWDDGHHWLHP-po, no es raro que los desarrolladores liberen código sin probar, en el que los usuarios pueden encontrar anomalías. El orden en que se ejecutan las declaraciones en el am-ELHQWHHGHHXVRRGLLHUHHGHOOTXHHVHHXWLOL]³³GXUDQWHHODDSUXHED Este orden puede determinar si el software funciona bien o no. (OOXVXDULRRDSOLFDDXQDDFRPELQDFL³QQGHHYDORUHVVGHHHQWUDGDDQRR probados. Las posibles combinaciones de valores de entra-da, que miles de usuarios pueden hacer a través de una in-terfaz de software, simplemente son demasiado numerosas para que los probadores las apliquen todas y, como deben #35 Revista de Ingeniería. Universidad de los Andes. Bogotá D.C., Colombia. rev.ing. ISSN. 0121-4993. Julio-diciembre de 2011, pp. 34-40.