Propiciar la calidad en el software es una actividad que ha surgido como consecuencia de la fuerte demanda de sistemas de software en todos los procesos que se desarrollan en la actualidad; desde programas elementales de contabilidad hasta programas complejos como los económicos y espaciales. De allí el esfuerzo que se ha desplegado para obtener software de alta calidad. El aseguramiento de la calidad toma en cuenta todas aquellas acciones planificadas y sistemáticas necesarias para proporcionar la confianza de que un producto o servicio satisfaga los requisitos de calidad establecidos. Para que sea efectivo, se requiere una evaluación permanente de aquellos factores que influyen en la adecuación del diseño y de las especificaciones según las aplicaciones previstas. Roger Pressman, por su parte, asegura que la garantía de calidad del software es una “actividad de protección” que se aplica a lo largo de todo el proceso de ingeniería del software, la cual engloba: métodos y herramientas de análisis, diseño, codificación y prueba; revisión de técnicas formales que se aplican durante cada paso; estrategia de prueba multiescalada; control de la documentación del software y de los cambios realizados; procedimientos que aseguren un ajuste a los estándares de desarrollo del software; y mecanismos de medida y de información.
Las pruebas de software, en inglés testing, son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de computadora. Básicamente es una fase en el desarrollo del software consistente en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que 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.
La prueba del software es la fase del ciclo de vida de un desarrollo software cuyo objetivo es descubrir los fallos que se han producido en el resto de fases, de tal forma que puedan ser solucionados, mejorando así la calidad del producto y disminuyendo el costo derivado de dichos de fallos. Sin embargo esta fase es muy costosa y se estima que suele consumir entre un treinta por ciento y un cincuenta por ciento como mínimo del costo total de un desarrollo software. Una parte de esta fase que conlleva una labor intensiva es la generación de los datos de prueba utilizados en la construcción de los casos de prueba del producto software. Esta tarea es crucial para el éxito de la prueba, debido a que es imposible obtener un programa software completamente probado, debido a que el número de casos de prueba necesarios para probar un programa software es infinito, y un diseño adecuado de los casos de prueba podrá detectar un elevado número de fallos. Además la creación de los datos de prueba, al ser principalmente manual, es tal vez la tarea más costosa de la prueba del software, ya que puede suponer aproximadamente el cuarenta por ciento de su costo total. Por estas razones, los diversos métodos desarrollados para la generación automática de los datos de prueba tratan de encontrar de forma eficiente un conjunto pequeño de dichos datos que permitan satisfacer un determinado criterio de suficiencia. De esta forma se reduce el costo de la prueba del software, por lo que los productos software pueden ser probados eficientemente.
Según Edsger Dijkstra, uno de los grandes gurus de la computación, la prueba puede examinar la presencia de errores pero no la ausencia de ellos. Existen muchos planteamientos a la hora de abordar el proceso de pruebas del software, pero para verificar productos complejos de forma efectiva se requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra. Una definición de "prueba” es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "probador" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Por supuesto, nunca se debe probar el software en un entorno de producción. Es necesario probar los nuevos programas en un entorno de pruebas separado físicamente del entorno de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producción es necesario crear las mismas condiciones que en la máquina de producción. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware: IBM, Sun, HP, etc. Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.
En general, los informáticos distinguen entre errores de programación y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa computacional. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo. Una práctica común es que el proceso de pruebas de un programa sea realizado por un “grupo independiente de prueba" al finalizar su desarrollo y antes de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versión del producto en pruebas y que es anterior a la versión final se denomina beta, y a dicha fase de pruebas, “prueba beta”. Puede además existir una versión anterior en el proceso de desarrollo llamada alfa, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser probado. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de “prueba de liberación al mercado”, dónde se comprueba cada funcionalidad del programa completo en entornos de producción. La práctica común en la ingeniería del software es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y continúe hasta que finaliza.
La fase de pruebas es una de las más costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de productos que forman parte de la aplicación. Obviamente, se aplican diferentes técnicas de prueba a cada tipo de producto software. El estándar ISO/IEC 12207 liberado el año 1995, identifica tres grupos de procesos en el ciclo de vida software: (1) Procesos principales, grupo en el que incluye los procesos de adquisición, suministro, desarrollo, operación y mantenimiento. (2) Procesos de la organización, en donde se encuentran los procesos de gestión, mejora, infraestructura y formación. (3) Procesos de soporte o auxiliares, en donde están los procesos de documentación, gestión de la configuración, auditoría, resolución de problemas, revisión conjunta, aseguramiento de la calidad, verificación y validación. No define, como se observa, un proceso de pruebas como tal, sino que aconseja, durante la ejecución de los procesos principales o de la organización, utilizar los procesos de soporte. Entre éstos se encuentran los procesos de “validación y de verificación.”
El proceso de validación tiene como objetivo determinar si los requisitos y el sistema final cumplen los objetivos para los que se construyó el producto, respondiendo así a la pregunta ¿el producto es correcto?. Por su parte el proceso de verificación intenta determinar si los productos software de una actividad se ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este modo, la pregunta a la que responde este proceso es ¿se está construyendo el producto correctamente?
Del proceso de verificación se observa la importancia de verificar cada uno de los productos que se van construyendo, bajo la suposición de que si lo que se va construyendo es del todo correcto, también lo será el producto final. Igualmente, se observa que el proceso de validación resalta la importancia de comprobar el cumplimiento de los objetivos de los requisitos y del sistema final, de suerte que podría construirse un plan de pruebas de aceptación desde el momento mismo de tener los requisitos, que sería comprobado al finalizar el proyecto. Si tras la fase de requisitos viniese una segunda de diseño a alto nivel del sistema, también podría prepararse un plan de pruebas de integración, que sería comprobado tras tener codificados los diferentes módulos del sistema. Esta correspondencia entre fases del desarrollo y tipos de prueba produce el llamado “modelo en V”.
Las pruebas de software, en inglés testing, son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de computadora. Básicamente es una fase en el desarrollo del software consistente en probar las aplicaciones construidas. Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que 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.
La prueba del software es la fase del ciclo de vida de un desarrollo software cuyo objetivo es descubrir los fallos que se han producido en el resto de fases, de tal forma que puedan ser solucionados, mejorando así la calidad del producto y disminuyendo el costo derivado de dichos de fallos. Sin embargo esta fase es muy costosa y se estima que suele consumir entre un treinta por ciento y un cincuenta por ciento como mínimo del costo total de un desarrollo software. Una parte de esta fase que conlleva una labor intensiva es la generación de los datos de prueba utilizados en la construcción de los casos de prueba del producto software. Esta tarea es crucial para el éxito de la prueba, debido a que es imposible obtener un programa software completamente probado, debido a que el número de casos de prueba necesarios para probar un programa software es infinito, y un diseño adecuado de los casos de prueba podrá detectar un elevado número de fallos. Además la creación de los datos de prueba, al ser principalmente manual, es tal vez la tarea más costosa de la prueba del software, ya que puede suponer aproximadamente el cuarenta por ciento de su costo total. Por estas razones, los diversos métodos desarrollados para la generación automática de los datos de prueba tratan de encontrar de forma eficiente un conjunto pequeño de dichos datos que permitan satisfacer un determinado criterio de suficiencia. De esta forma se reduce el costo de la prueba del software, por lo que los productos software pueden ser probados eficientemente.
Según Edsger Dijkstra, uno de los grandes gurus de la computación, la prueba puede examinar la presencia de errores pero no la ausencia de ellos. Existen muchos planteamientos a la hora de abordar el proceso de pruebas del software, pero para verificar productos complejos de forma efectiva se requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra. Una definición de "prueba” es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "probador" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Por supuesto, nunca se debe probar el software en un entorno de producción. Es necesario probar los nuevos programas en un entorno de pruebas separado físicamente del entorno de producción. Para crear un entorno de pruebas en una máquina independiente de la máquina de producción es necesario crear las mismas condiciones que en la máquina de producción. Existen a tal efecto varias herramientas vendidas por los mismos fabricantes de hardware: IBM, Sun, HP, etc. Esas utilidades reproducen automáticamente las bases de datos para simular un entorno de producción.
En general, los informáticos distinguen entre errores de programación y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa computacional. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo. Una práctica común es que el proceso de pruebas de un programa sea realizado por un “grupo independiente de prueba" al finalizar su desarrollo y antes de sacarlo al mercado. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versión del producto en pruebas y que es anterior a la versión final se denomina beta, y a dicha fase de pruebas, “prueba beta”. Puede además existir una versión anterior en el proceso de desarrollo llamada alfa, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser probado. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de “prueba de liberación al mercado”, dónde se comprueba cada funcionalidad del programa completo en entornos de producción. La práctica común en la ingeniería del software es que el proceso de pruebas se realice desde el mismo momento en que empieza el desarrollo y continúe hasta que finaliza.
La fase de pruebas es una de las más costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construcción de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el código fuente y el resto de productos que forman parte de la aplicación. Obviamente, se aplican diferentes técnicas de prueba a cada tipo de producto software. El estándar ISO/IEC 12207 liberado el año 1995, identifica tres grupos de procesos en el ciclo de vida software: (1) Procesos principales, grupo en el que incluye los procesos de adquisición, suministro, desarrollo, operación y mantenimiento. (2) Procesos de la organización, en donde se encuentran los procesos de gestión, mejora, infraestructura y formación. (3) Procesos de soporte o auxiliares, en donde están los procesos de documentación, gestión de la configuración, auditoría, resolución de problemas, revisión conjunta, aseguramiento de la calidad, verificación y validación. No define, como se observa, un proceso de pruebas como tal, sino que aconseja, durante la ejecución de los procesos principales o de la organización, utilizar los procesos de soporte. Entre éstos se encuentran los procesos de “validación y de verificación.”
El proceso de validación tiene como objetivo determinar si los requisitos y el sistema final cumplen los objetivos para los que se construyó el producto, respondiendo así a la pregunta ¿el producto es correcto?. Por su parte el proceso de verificación intenta determinar si los productos software de una actividad se ajustan a los requisitos o a las condiciones impuestas en actividades anteriores. De este modo, la pregunta a la que responde este proceso es ¿se está construyendo el producto correctamente?
Del proceso de verificación se observa la importancia de verificar cada uno de los productos que se van construyendo, bajo la suposición de que si lo que se va construyendo es del todo correcto, también lo será el producto final. Igualmente, se observa que el proceso de validación resalta la importancia de comprobar el cumplimiento de los objetivos de los requisitos y del sistema final, de suerte que podría construirse un plan de pruebas de aceptación desde el momento mismo de tener los requisitos, que sería comprobado al finalizar el proyecto. Si tras la fase de requisitos viniese una segunda de diseño a alto nivel del sistema, también podría prepararse un plan de pruebas de integración, que sería comprobado tras tener codificados los diferentes módulos del sistema. Esta correspondencia entre fases del desarrollo y tipos de prueba produce el llamado “modelo en V”.
Para conocer más acerca del Doctor Choque y sus publicaciones, haz clic en el siguiente vínculo:
No hay comentarios:
Publicar un comentario