PRUEBAS DE SOFTWARE Las pruebas de software ( testing en ingls) son los procesos que permiten verificar y revelar la calidad

de un producto software antes de su puesta en marcha. Bsicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniera de software. En este sentido, se ejecuta el aplicativo a probar y mediante tcnicas experimentales se trata de descubrir qu errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema. Existen muchas definiciones de pruebas de software. A continuacin, se hace referencia a la definicin citada por IEEE y SWEBOK. Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo condiciones especificadas, los resultados son observados o registrados, y una evaluacin es realizada de un aspecto del sistema o componente. [IEEE Std.610.12-1990] Una prueba es una actividad ejecutada para evaluar y mejorar la calidad del producto a travs de la identificacin de defectos y problemas. [SWEBOK] Otros especialistas de pruebas manifiestan que las pruebas de software son actividades claves para que los procesos de validacin y verificacin tengan xito, ya que ayudan a entregar el producto con la calidad suficiente para satisfacer las necesidades del cliente y con la certeza de que el producto cumple las especificaciones definidas. En este sentido, las pruebas pueden considerarse como un proceso que intenta proporcionar confianza en el software y cuyo objetivo fundamental es demostrar al desarrollador y al cliente que el software satisface sus requisitos. Algo que los especialistas de pruebas deben considerar es que las pruebas de software nunca se deben realizar en un entorno de produccin. Es necesario probar los nuevos sistemas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin, es necesario crear las mismas condiciones que existe en la de produccin. Como parte del proceso de validacin y verificacin, se debera tomar decisiones sobre quin debera ser responsable de las diferentes etapas de las pruebas. Dichas etapas de pruebas se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniera de Software. En la figura 1.1 se observa un modelo de cmo las etapas de pruebas se integran en el ciclo de vida de desarrollo de software genrico. Durante la etapa de planificacin es importante establecer una buena estrategia de pruebas y seleccionar las tcnicas

adecuadas de estimacin en funcin de los factores que afecten a las pruebas del proyecto. La siguiente fase de desarrollo es el diseo del producto, que trae consigo el diseo de casos de prueba. Durante las siguientes fases de codificacin y pruebas del producto, se ejecutan las pruebas unitarias, de sistemas, de integracin, etc., de las que se explicar en apartados siguientes.

De lo anterior, el proceso de pruebas puede considerarse como un subproyecto dentro del proyecto sobre el cual se estn ejecutando las pruebas, y como tal requiere la definicin de un plan a seguir. Cuando el proceso de pruebas existe dentro del contexto del proyecto, debera prestarse atencin a la efectividad y eficiencia de las pruebas desde la perspectiva del proyecto y no desde la perspectiva del propio subproyecto de pruebas. La eficiencia consiste en conseguir el efecto deseado de la manera correcta, es decir, sin desaprovechamiento de recursos, ni de tiempo ni de dinero. Por consiguiente, la eficiencia est relacionada con dos conceptos: productividad y ausencia de prdidas. Para conseguir esta eficiencia deseada durante el proceso de pruebas, se pueden considerar los siguientes aspectos: Evitar redundancias: Las redundancias traen consigo una prdida o desaprovechamiento de tiempo por lo que hay que intentar ejecutar las pruebas ms adecuadas a cada situacin y lo ms rpido posible. Es importante encontrar los errores que ms impacto puedan tener sobre el producto lo ms rpido posible. Aunque sea aconsejable no desaprovechar el tiempo, no hay que olvidarse de la planificacin, preparacin de las pruebas, y de prestar atencin a todos los detalles. No abandonar las estrategias previamente establecidas ante la primera seal de problemas o retrasos. Es decir, en un intento de ahorrar tiempo, se debe tener cuidado de no cometer errores que tendrn como consecuencias invertir ms tiempo del que se intenta ahorrar.

 Reducir costes: Para reducir costes se debera prestar especial atencin a la adquisicin de elementos que puedan ayudar a la ejecucin de pruebas, del tipo de herramientas para la ejecucin de pruebas o entornos de pruebas. Habra que cerciorarse de que realmente fueran necesarias y de que existe el tiempo y las habilidades suficientes para emplearlas de manera ventajosa. Tambin, es aconsejable evaluar las herramientas antes de comprarlas y ser capaz de justificar estos gastos frente al anlisis de costos-beneficios. Un posible flujo del proceso de pruebas, identificando distintas actividades y entregables se muestra en la figura 1.2.

1.1.1. Validacin y Verificacin en el desarrollo de software Los procesos de validacin y verificacin determinan si un producto software satisface las necesidades del negocio y si se est construyendo acorde a las especificaciones. Con respecto a las tareas asociadas a estos procesos, las pruebas estn ms relacionadas con el proceso de validacin, mientras que las revisiones son tareas ms orientadas al proceso de verificacin. El objetivo principal de la validacin y verificacin es comprobar que el sistema est hecho para un propsito, es decir, que el sistema debe ser lo suficientemente bueno para su uso previsto. El nivel de confianza requerido depende de tres factores: El propsito o funcin del sistema. El nivel de confianza necesario depende de lo crtico que sea el software para una organizacin. Las expectativas del usuario. Actualmente, es menos aceptable entregar sistemas no fiables, por lo que las compaas deben invertir ms esfuerzo en llevar a cabo las actividades de verificacin y validacin. Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema deben tener en cuenta los sistemas competidores, el precio que sus

clientes estn dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema. Cuando una compaa tiene pocos competidores, puede decidir entregar un programa antes de que haya sido completamente probado y depurado, debido a que quiere ser el primero en el mercado. Cuando los clientes no estn dispuestos a pagar precios altos por el software, pueden estar dispuestos a tolerar ms defectos en l. Todos estos factores pueden considerarse a fin de decidir cunto esfuerzo debera invertirse en el proceso de validacin y verificacin. 1.1.1.1. Validacin. El propsito de la Validacin en CMMI es demostrar que un producto o componente del mismo satisface el uso para el que se cre al situarlo sobre el entorno previsto. Segn Boehm, la validacin responde la siguiente pregunta: Se est construyendo el producto correcto? 1.1.1.2. Verificacin. El propsito de la Verificacin en CMMI es asegurar que los productos seleccionados cumplen los requisitos especificados. Para diferenciar esta tarea con la validacin, Boehm indica que debe responderse a la siguiente pregunta: Se est construyendo el producto de la manera correcta? 1.1.2. Tipos de pruebas La disciplina de pruebas es una de las ms costosas del ciclo de vida software. En sentido estricto, deben realizarse las pruebas de todos los artefactos generados durante la construccin de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el cdigo fuente y el resto de productos que forman parte de la aplicacin (por ejemplo, la base de datos), e infraestructura. Obviamente, se aplican diferentes tcnicas de prueba a cada tipo de producto software. A continuacin, se describir los tipos de pruebas en funcin de qu conocemos, segn el grado de automatizacin y en funcin de qu se prueba. 1.1.2.1. En funcin de qu conocemos. a. Pruebas de caja negra En este tipo de prueba, tan slo, podemos probar dando distintos valores a las entradas. Los datos de prueba se escogern atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los flujos de una funcionalidad (casos de uso).

Con este tipo de pruebas se intenta encontrar: Funcionalidades incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y finalizacin.

b. Pruebas de caja blanca Consiste en realizar pruebas para verificar que lneas especficas de cdigo funcionan tal como est definido. Tambin se le conoce como prueba de caja-transparente. La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para derivar los casos de prueba.

Las pruebas de caja blanca intentan garantizar que: Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas. Para esta prueba, se consideran tres importantes puntos.

1.1.2.2. Segn el grado de automatizacin a. Pruebas manuales Una prueba manual es una descripcin de los pasos de prueba que realiza un evaluador (usuario experto). Las pruebas manuales se utilizan en aquellas situaciones donde otros tipos de prueba, como las pruebas unitarias o las pruebas Web, seran demasiado difciles de realizar o su creacin y ejecucin sera demasiado laboriosa. Tambin, podra utilizar una prueba manual en situaciones donde no sea posible automatizar los pasos, por ejemplo, para averiguar el comportamiento de un componente cuando se pierde la conexin de red; esta prueba podra realizarse de forma manual, desenchufando el cable de red. Otro ejemplo, sera en caso de comprobar cmo se visualiza el contenido de una pgina web en dos navegadores diferentes. Las pruebas manuales ayudarn a descubrir cualquier problema relacionado con la funcionalidad de su producto, especialmente defectos relacionados con facilidad de uso y requisitos de interfaces. b. Pruebas automticas A diferencia de las pruebas manuales, para este tipo de pruebas, se usa un determinado software para sistematizarlas y obtener los resultados de las mismas. Por ejemplo, verificar un mtodo de ordenacin. La suite de IBM Rational nos provee varias herramientas que permiten automatizar las pruebas de un sistema.