19 de diciembre de 2012

Estrategias de Prueba del Software

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.

Las características generales son:
  • La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
  • En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
  • La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
  • La prueba y la depuración son actividades diferentes.
  • Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
  • Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
  • Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
  • Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
  • Planificación de las pruebas.
  • Diseño de las pruebas.
  • Implementación de las pruebas.
  • Ejecución de las pruebas.
  • Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
  •  Plan de Pruebas.
  •  Casos de Prueba.
  •  Informe de evaluación de Pruebas.
  •  Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:
  • Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.
  • Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.
Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.

Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:
  • La eliminación de casos de prueba obsoletos.
  • El refinamiento de algunos casos de prueba en casos de prueba de regresión.
  • La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.
La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.

Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores".

Pruebas del Software

Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.

Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. 

Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.

Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.


OBJETIVOS DE LAS PRUEBAS

  • La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
  • Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
  • Una prueba tiene éxito si descubre un error no detectado hasta entonces.
  • Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.
Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores


PRINCIPIOS DE LAS PRUEBAS

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.
Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.

El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.

Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.

No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.

Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.


FACILIDAD DE PRUEBA

En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.

Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.


Operatividad

«Cuanto mejor funcione, más eficientemente se puede probar.»
  • El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
  • Ningún error bloquea la ejecución de las pruebas.
  • El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).

Observabilidad

«Lo que ves es lo que pruebas.».
  • Se genera una salida distinta para cada entrada.
  • Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
  • Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
  • Todos los factores que afectan a los resultados están visibles.
  • Un resultado incorrecto se identifica fácilmente.
  • Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
  • Se informa automáticamente de los errores internos.
  • El código fuente es accesible.

Controlabilidad

«Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»
  • Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.
  • Todo el código es ejecutable a través de alguna combinación de entrada.
  • El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.
  • Los formatos de las entradas y los resultados son consistentes y estructurados.
  • Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

Capacidad de Descomposición

«Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »
  • El sistema software está construido con módulos independientes.
  • Los módulos del software se pueden probar independientemente.

Simplicidad

«Cuanto menos haya que probar, más rápidamente podremos probarlo.»
  • Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
  • Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
  • Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).

Estabilidad

«Cuanto menos cambios, menos interrupciones a las pruebas.»
  • Los cambios del software son infrecuentes.
  • Los cambios del software están controlados.
  • Los cambios del software no invalidan las pruebas existentes.
  • El software se recupera bien de los fallos.

4 de diciembre de 2012

Gestión de la Configuración del Software

El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.

La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.

El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.

A medida que progresa el proceso del software, el número de elementos de configuración del software
(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:

Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;
Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;
Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;
Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.

La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.

La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.

Cuando se construye software los cambios son inevitables

• Los cambios aumentan el nivel de confusión en el equipo de desarrollo
• Confusión debida a:
                                  - No se han analizado los cambios antes de realizarlos.
                                  - No se han registrado antes de implementarlos.
                                  - No se les ha comunicado a aquellas personas que necesitan saberlo.
                                  - No se han controlado de manera que mejoren la calidad y reduzcan los errores.
• La Gestión de la Configuración Software (GCS) es una actividad de protección que  gestiona el cambio a lo largo del ciclo de vida del software
• El cambio se puede producir en cualquier momento
• Por tanto, las actividades de GCS son:
                                                             - Identificar el cambio.
                                                             - Controlar el cambio.
                                                             - Garantizar la correcta implementación del cambio.
                                                             - Informar del cambio a todos aquellos que lo necesiten.


Elementos de Configuración

• El software es el resultado del proceso de IS:
                                                                       - Programas.
                                                                       - Datos.
                                                                       - Documentos.
• Los elementos que componen toda la información generada como parte del proceso de IS se denominan colectivamente configuración del software
• A medida que progresa el proceso de IS el número de Elementos de Configuración Software (ECS) crece rápidamente
• e.g. la SRS produce un plan del proyecto y un diseño que a su vez produce código.
• Los ECS producen otros ECSs para crear una jerarquía de información
• Si simplemente tuviéramos esta jerarquía no habría confusión
• La confusión surge cuando entra en juego el cambio
• Éste puede producirse en cualquier momento y por cualquier razón
• Las fuentes fundamentales del cambio son:
      - Fallos.
      - Nuevos negocios o condiciones comerciales que dictan cambios en los requisitos del producto.
      - Nuevas necesidades del cliente que demandan la modificación de los datos, funciones o servicios.
      - Reorganización y/o reducción del volumen comercial que provoca cambios en el proyecto.
      - Restricciones presupuestarias o de planificación que provocan una redefinición del producto.


Línea Base

Es una configuración de referencia en el proceso de desarrollo del software a partir de la cual las revisiones se han de realizar de manera formal, con el objetivo de controlar los cambios en el software, sin impedir llevar a cabo aquellos que sean justificados, Se definen al comienzo del proyecto, coincidiendo con los hitos marcados y generalmente se corresponden con los resultados de las fases.

• Los cambios por tanto pueden ser necesarios y están justificados
• Una línea base es un concepto de GCS que nos ayuda a controlar los cambios sin perjuicio de aquellos que sean necesarios
• El IEEE define una línea base como una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios
• Antes de que un ECS se convierta en línea base el cambio puede llevarse a cabo de manera rápida e informal
• Sin embargo, una vez que se ha establecido una línea base solo se pueden efectuar los cambios si se aplica un procedimiento  formal para evaluarlos y verificarlos
• El concepto de línea base es similar al de una boda...
• Durante la preparación del evento se pueden cambiar fechas, horas y lugares...... pero una vez mandadas las invitaciones los cambios no son tan sencillos.
• El el contexto de IS definimos una línea base como un punto de referencia en el  desarrollo del software que queda marcado  por el envío de uno o más elementos de  configuración del software y la aprobación  del ECS obtenido mediante una RTF.

Proceso de Generación de Línea Base


• ECSs que forman un conjunto de líneas base:
                                                                       - Plan del proyecto del software.
                                                                       - SRS.
                                                                       - Diseño.
                                                                       - Código.
                                                                       - Casos de prueba.
                                                                       - Manual preliminar de usuario.

                                                                       - Manuales de operación e instalación.
                                                                       - Manual de usuario.
                                                                       - Documentos de mantenimiento.
                                                                       - Estándares y procedimientos de IS.
• Además de estos ECSs pueden inmovilizarse las herramientas de software (e.g., editores, compiladores, herramientas CASE, etc.)


Actividades de GCS

• La GCS es una actividad de protección que  puede considerarse dentro de la SQA
• Aunque su actividad fundamental es el control del cambio también se encarga de otras actividades
• Cualquier GCS debe tener claro:
              - Cómo identificar y gestionar las versiones de un programa para permitir modificaciones.
              - Cómo controlar los cambios antes y después de distribuir el software al cliente.
              - Quién es el responsable de aprobar y de asignar prioridades a los cambios.
              - Como podemos garantizar que los cambios se han llevado a cabo adecuadamente.
              - Qué mecanismos se usan para avisar a otros de los cambios realizados.

• Actividades de GCS:
              - Identificación de ECSs.
              - Control de versiones.
              - Control de cambios.
              - Auditoria de la configuración.
              - Informes de estado.