El ciclo de vida de un sistema software empieza en el momento en que nace la idea de desarrollar el sistema y acaba cuando el software por alguna u otra razón deja de ser usado.
Entre estos dos momentos el producto software pasa por varias fases: el diseño de alto nivel, el diseño técnico o detallado, el diseño de programa, el diseño de módulo, la codificación, la ejecución de las pruebas finales, la implantación, la explotación y el mantenimiento, y por último su sustitución por otro sistema.
El desarrollo (igual que la compra) y el mantenimiento de un sistema software implican costes muy altos. Un sistema es rentable si estos costes se justifican por las ventajas que ofrece el sistema durante su fase de explotación. Esta rentabilidad será mayor si los gastos de desarrollo o compra y de mantenimiento se disminuyen y si la duración de la fase de explotación es más larga.
La gestión de la calidad es el único instrumento adecuado para evitar un exceso de los gastos por falta de calidad del producto y de los procesos de desarrollo y de mantenimiento, y para poder decidir de forma responsable si un sistema es apto para su uso o no. La gestión, y como parte de ella el control de la calidad, no es exclusivamente la responsabilidad de los que desarrollan un sistema software. Sus clientes, es decir, los usuarios finales, tienen un papel incluso más importante en este proceso. En la situación óptima el equipo de calidad está compuesto por representantes de ambos partidos. Desde el punto de vista de los usuarios la cima de la gestión de la calidad está en la llamada prueba de aceptación.
Las pruebas de software
El único instrumento adecuado para determinar el status de la calidad de un producto software es el proceso de pruebas. En este proceso se ejecutan pruebas dirigidas a componentes del software o al sistema de software en su totalidad, con el objetivo de medir el grado en que el software cumple con los requerimientos. En las pruebas se usan casos de prueba, especificados de forma estructurada mediante Técnicas de prueba. El proceso de pruebas, sus objetivos y los métodos y técnicas usados se describen en el plan de prueba.
¿Quién se encarga de las pruebas de software?
Se distinguen pruebas técnicas y pruebas funcionales. Las pruebas técnicas son la responsabilidad de los ingenieros de software que han desarrollado el producto, pero estos ingenieros nunca deben hacerse cargo de las pruebas funcionales, por varias razones. El responsable para las pruebas funcionales es el técnico de pruebas, que dispone de los conocimientos y aptitudes necesarios para esta tarea tan importante y específica.
En proyectos a gran escala las pruebas funcionales son la responsabilidad de un equipo de pruebas, que consiste de uno o varios técnicos, un coordinador de pruebas y un gestor de pruebas o de calidad.
Objetivos de las pruebas de software.
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están:
Detectar defectos en el software.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.
Principios de las pruebas de software.
Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan:
La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.
La principal dificultad del proceso de prueba es decidir cuándo parar.
Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.
Una parte necesaria de un caso de prueba es la definición del resultado esperado.
Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.
El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.
Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.
Etapas involucradas en las pruebas de software.
Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.
Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.
Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.
Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.
Ejecutar los casos de prueba.
La prueba de aceptación
El uso de cualquier producto de software tiene que estar justificado por las ventajas que ofrece. Sin embargo, antes de empezar a usarlo es muy difícil determinar si sus ventajas realmente justifican su uso. El mejor instrumento para esta determinación es la llamada 'prueba de aceptación'. En esta prueba se evalúa el grado de calidad del software con relación a todos los aspectos relevantes para que el uso del producto se justifique.
Para eliminar la influencia de conflictos de intereses, y para que sea lo más objetiva posible, la prueba de aceptación nunca debería ser responsabilidad de los ingenieros de software que han desarrollado el producto.
Para la preparación, la ejecución y la evaluación de la prueba de aceptación ni siquiera hacen falta conocimientos informáticos. Sin embargo, un conocimiento amplio de métodos y técnicas de prueba y de la gestión de la calidad en general facilitan esta labor.
La persona adecuada (o el equipo adecuado) para llevar a cabo la prueba de aceptación dispone de estos conocimientos y además es capaz de interpretar los requerimientos especificados por los futuros usuarios del sistema de software en cuestión.
No hay comentarios:
Publicar un comentario
Todos los comentarios son bien recibidos...