Control de la Calidad

Uno de los problemas que se afrontan actualmente en la esfera de la informática es el proceso de la calidad del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de software.

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. 

En términos generales la calidad de software puede definirse como el grado en que un conjunto de características inherentes al software cumple con unos requisitos explícitos e implícitos.

La implantación de un sistema de calidad en una organización ayuda a mejorar la gestión del desarrollo de software, y esto traerá como consecuencia una disminución de los problemas y errores, favoreciendo las relaciones y comunicación entre las personas y grupos de organización, y de éstos con los clientes. 

La gestión de la calidad va tomando cada día mayor importancia en el ámbito del desarrollo de software. De esta forma, los esfuerzos encaminados a integrar la gestión de la calidad dentro de la gestión de los proyectos deben generar también un aumento de la productividad.

La obtención de un software con calidad implica la utilización de metodologías o procedimientos, estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

Gestión de la calidad de software: Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como:

1. Planificación de la Calidad del Software.
2. Control de la Calidad del Software.
3. Aseguramiento de la Calidad del Software.
4. Mejora de la Calidad del Software.

1. La Planificación de la Calidad del Software

Es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del mercado. El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para producir un desarrollo y utilidades satisfactorias.

Los aspectos a considerar en la Planificación de la Calidad de Software son: Modelos/Estándares de Calidad de Software a utilizar, Costos de la Calidad de Software, Recursos humanos y materiales necesarios, entre otras.  El plan de calidad define los atributos de calidad más importantes del producto a ser desarrollado y define el proceso de evaluación de la calidad.

En la Planificación de la Calidad de Software se debe determinar:

• Rol de la Planificación.
• Requerimientos de la Calidad de Software.
• Preparación de un Plan de Calidad de Software.
• Implementación de un Plan de Calidad de Software
• Preparar un Manual de Calidad.

2. El Control de la Calidad del Software

Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad. Son las inspecciones, revisiones y pruebas para asegurar la calidad del producto centradas en 2 objetivos fundamentales:

1. Mantener bajo control un proceso.
2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de calidad del software se ha convertido, por tanto en una parte esencial de los programas de control de calidad. La atención de los requisitos específicos de la calidad del software es una actividad que está integrada a través del programa de procesamientos de información de la calidad. Está formado por actividades que permiten evaluar la calidad de los productos de software desarrollados. El aspecto a considerar en el Control de la Calidad de Software es la “Prueba del Software”.

Las pruebas son elementos críticos para determinar la calidad del software. Es el proceso de ejecutar un programa con intención de encontrar defectos. Es un proceso destructivo que determina el diseño de los casos de prueba y la asignación de responsabilidades.

Objetivos de las pruebas:

• Encontrar defectos en el software.
• Una prueba tiene éxito si descubre un defecto.
• Una prueba fracasa si hay defectos pero no los descubre.
• Ejecución de un programa con la intención de descubrir un error.
• Técnica experimental para la búsqueda de errores en los programas.

Algunos principios de las pruebas recogen lo siguiente:

• Las pruebas deberían planificarse mucho antes de que comiencen.
• No son posibles las pruebas exhaustivas: El número de permutaciones de camino para incluso programas pequeños es excepcionalmente grande. Por ese motivo es imposible ejecutar todas las combinaciones de caminos durante las pruebas.
• Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente: El ingeniero de software que creo el sistema no es el más adecuado para realizar las pruebas del software, ya que consciente o inconscientemente tiende a probar lo que sabe que funciona.

Existen varios tipos de pruebas que pueden realizarse durante el proceso de desarrollo de software como son:

• Unitarias: Pretenden probar cada función en un archivo de programa simple (una clase en terminología de objetos).
• Integración: Pretenden comprobar la integración de los componentes, es decir, la comunicación a través de interfaces, acceso incoherente a estructuras de datos globales.

Las pruebas de integración pueden realizarse de forma ascendente o descendente

• Validación: Pretende comprobar que se satisfacen los requisitos.
• Sistema: Se centran en comprobar la recuperación, seguridad, resistencia, rendimiento.

Asociado a los tipos de pruebas existen también técnicas de pruebas que ayudan a definir conjuntos de casos de pruebas aplicando ciertos criterios, como son:

• Pruebas de caja blanca: Se centra en comprobar la interacción interna de los componentes del sistema.
• Pruebas de caja negra: “Se centran en los requisitos funcionales del software. O sea, la prueba de de caja negra permite al ingeniero del software obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos”.

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 confiabilidad del software e 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.

3. El Aseguramiento de Calidad del Software

Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Se trata de una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software. Se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la calidad del software engloba:

• Un enfoque de gestión de calidad.
• Métodos y herramientas de Ingeniería del Software.
• Revisiones técnicas formales aplicables en el proceso de software.
• Una estrategia de prueba multiescala.
• El control de la documentación del software y de los cambios realizados.
• Procedimientos para ajustarse a los estándares de desarrollo del software.
• Mecanismos de medición y de generación de informes.
  

Todo el que este involucrado en el proceso de desarrollo del software es responsable de la calidad desarrolladores, analistas, arquitectos, jefes de proyectos, clientes y aquellas personas que en los proyectos llamamos grupo de aseguramiento de la calidad.

Las actividades del grupo de aseguramiento de la calidad son:

• Establecimiento del plan de aseguramiento de la calidad para un proyecto.
• Participación en el desarrollo de la descripción del proceso de software.
• Revisión de las actividades de ingeniería del software.
• Auditorías de los procesos de software designados para verificar el ajuste con los definidos como parte del proceso de software.
• Registrar lo que no se ajuste a los requisitos e informar a los superiores.
• Coordinar el control de cambio.

CMMI v1.2 en el área de proceso de aseguramiento de la calidad propone:

• Elaborar objetivamente los procesos.
• Evaluar objetivamente los artefactos y servicios.
• Comunicar y asegurar la resolución de las no conformidades.
• Establecer registros.

Además de estas actividades, el grupo de aseguramiento de la calidad coordina el control y la gestión de cambios y; ayuda a recopilar y analizar las métricas del software. Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se habla de software nos referimos a la disciplina de recopilar y analizar datos basándonos en mediciones reales de software, así como a las escalas de medición.

Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los requisitos del cliente o de los usuarios y, por lo tanto, actúan como restricciones dentro del proyecto. Las medidas de Calidad del Software deben comenzar desde la especificación y terminar con la implementación, implantación y mantenimiento o post-implantación. Debe aplicarse a lo largo de todo el proceso de Ingeniería de Software. Básicamente, la medición es una fase normal de cualquier actividad industrial Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.

4. La Mejora de la Calidad del Software

Es la parte de la Gestión de la Calidad que contribuye, por medio de las mediciones, a los análisis de los datos y auditorías, a efectuar mejoras en la calidad del software.

Las auditorías según el estándar ISO 19011:2002 se define como: proceso sistemático, independiente y documentado para evaluar el estado actual (evidencias de la auditoría) y evaluarlas de manera objetiva con el fin de determinar la extensión en que se cumplen los criterios de auditoría.

Una Auditoría de Calidad tiene como objetivo:

• Mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza.
• Suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.

Los resultados de la auditoría son documentados y remitidos al director de la organización auditada, a la entidad auditora, y cualquier organización externa identificada en el plan de auditoria. El informe incluye la lista de elementos no conformes u otros aspectos para las posteriores revisiones y acciones. Cuando se realiza el plan de auditoría, las recomendaciones son informadas e incluidas en los resultados de la auditoría.

Para implementar un programa de mejoras es necesario definir procesos, decidir qué se quiere mejorar, definir qué medidas serán necesarias recoger, cómo y dónde tomarlas, gestionarlas mediante herramientas, utilizarlas para la toma de decisiones y reconocer las mejoras. Cuando el proceso a mejorar es el de desarrollo del software, es importante definir qué objetivos se quieren alcanzar, para reducir el número de medidas y, en consecuencia, el coste de recopilarlas y el impacto sobre la actividad de producción de software.

Modelo de Toma de Decisiones

Las pruebas de software no son solo una fase del ciclo de vida; ellas abarcan una gran cantidad de actividades orientadas a detectar, corregir y prevenir errores en los sistemas software. Estas actividades en su totalidad de carácter técnico se apoyan en un conjunto de activos y generan un gran volumen de flujo de información, debido a factores tales como: el elevado número de requisitos a probar; la generación de diferentes casos de prueba; la necesidad de disponer de un número adecuado de datos de prueba que cubra suficientemente un rango amplio de posibles valores de entrada; la generación de múltiples resultados y de un registro de las actividades de prueba, las cuales siempre son crecientes. 

Por otra parte cuando se detecta un fallo por un caso de prueba, se genera una incidencia, lo cual obliga a una posterior validación, esto también ocurre cuando se introducen nuevos requisitos y cambios en el código; en consecuencia se generan cambios en los elementos del sistema de prueba. Estas características típicas de un entorno de pruebas, requieren de una organización y un control adecuado para manejar su complejidad y garantizar el logro de los objetivos de la prueba con un uso eficiente de los recursos. Para realizar este control e implementar la gestión de pruebas se debe basar en la toma de decisiones. Por ello se propone un modelo de toma de decisiones para soportar la gestión del proceso de prueba. Este modelo está formado por niveles, conformando una estructura que soporta la toma de decisiones para un proyecto de prueba.

En la figura, muestra un modelo de toma de decisiones de un proceso de prueba. Este incluye tres niveles, que enlazan las actividades técnicas de prueba (estas son el sujeto de la gestión) con las de gestión. El primer nivel está compuesto por los procedimientos de gestión que son los encargados de extraer la información de los activos técnicos del proceso; el segundo nivel analiza la información obtenida del proceso y la distribuye a los procesos de gestión, que es donde se toman las decisiones. 

Estas decisiones impactan el proyecto de prueba. De esta manera la información técnica que se extrae de la actividad del proyecto de prueba se transforma en información de gestión, para controlar dicha actividad. 

Con este modelo se intenta mostrar como fluye la información dentro de la gestión de prueba, por otra parte también guía la definición detallada de cada uno de sus componentes. Por lo tanto para describir el modelo de gestión a partir de sus componentes, primero se presenta una vista muy detallada del flujo de información generado por las actividades técnicas del proceso de prueba, el cual constituye la base del modelo; luego se continuara con la definición de los procesos de gestión, que son los usuarios de la información generada en la base del modelo; y finalmente describiré los procedimientos técnicos de gestión que son los que extraen y analizan la información, que consumen los procesos de gestión.

Meta-Modelo de Gestión de Pruebas

El meta-modelo de gestión del proceso de pruebas se compone de un paquete de procesos y de cinco componentes que corresponden con las áreas de gestión. El núcleo se agrupa los cinco procesos fundamentales definidos: inicio, planificación de la prueba, ejecución, seguimiento & control y cierre o finalización; para los cuales se define brevemente su función.

Con el paquete de procesos de inicio se cubre las actividades necesarias para establecer y lanzar el proyecto de pruebas, además proporciona una puerta de entrada al proceso de pruebas, para permitir la comunicación de las actividades de desarrollo con las de prueba en la parte inicial del proyecto. 

El paquete de procesos de planificación tiene como objetivo planificar las actividades del proyecto, asignar los recursos, definir los mecanismos para controlar el proceso de prueba y facilitar la ejecución tanto de los demás procesos de gestión así como de los procesos técnicos de prueba. 

El paquete de procesos de ejecución tiene como objetivo garantizar la correcta ejecución del plan, es decir la ejecución de las actividades técnicas de prueba. Este paquete de procesos se apoya en el paquete de seguimiento & control para realizar sus actividades. 

El paquete de procesos de seguimiento & control tiene como objetivo coordinar las actividades del proceso de ejecución, controlar el flujo de información, evaluar en cada momento la ejecución del proceso de pruebas. 

El paquete de procesos de cierre tiene como objetivo evaluar de manera global el proyecto de prueba, se convierte en el último punto de verificación para determinar que todas las actividades se han ejecutado según lo planificado y que se han obtenido los resultados de acuerdo con los parámetros establecidos; adicionalmente, determinar aquellas prácticas que pueden ser aplicadas en otros procesos. También se representa en el meta-modelo las áreas de gestión: definición y lanzamiento del proyecto, entorno de prueba, actividades técnicas de prueba, activos de prueba y resultados de prueba. Estas corresponden  a aquellos aspectos fundamentales del proyecto de prueba que deben ser gestionados, estas áreas son transversales a las actividades concretas de los procesos que forman parte del núcleo. A través de las áreas se pretende facilitar la definición de los procesos de gestión, dado que acotan los activos junto con las actividades que son sujetos de la gestión. 

El objetivo fundamental del proceso de gestión es coordinar los esfuerzos de todos los participantes, controlar y hacer seguimiento de los activos técnicos de prueba, sus relaciones y sus dependencias; adicionalmente facilitar la re utilización de estos activos durante el progreso de las actividades en los diferentes niveles de prueba, en la fase de mantenimiento del sistema desarrollado y en otros proyectos similares. Para lograrlo este se basa en los activos técnicos que participan en este proceso, entre los cuales se destaca: 

• El plan de prueba 
• Escenario de prueba 
• Componentes de la plataforma (hardware y software) 
• Datos de prueba 
• Sistema bajo prueba 
• Los requisitos del sistema 
• Los casos de prueba 
• Los resultados de prueba 
• Los scripts de prueba 

Como resultado de los procesos de gestión se generan otro tipo de activos, los activos de gestión. Estos activos se clasifican en tres tipos, activos de inicio del proyecto, activos de operación y activos de cierre y/o evaluación. Esta clasificación se realiza teniendo en cuenta el impacto que tienen en las etapas del proyecto. Por lo tanto los activos de inicio se constituyen con la definición del alcance del proyecto y el plan de pruebas; los activos de operación por las métricas del proceso de prueba y las novedades de control; y los activos de cierre por el informe de cierre.

Áreas de Gestión de Pruebas y Actividades de Gestión

Consiste en relacionar las actividades de prueba con las áreas de gestión para así definir las tareas que se van a realizar en cada área. Ver ejemplo:

Así un proceso de gestión se implementa por diferentes actividades; y las actividades se aplican en áreas concretas para gestionarlas. De esta manera se facilita la aplicación y la adaptación del proceso de gestión a un proyecto de prueba en concreto, de acuerdo con sus necesidades específicas. Por ejemplo, un primer paso sería tomar la tabla como una herramienta para analizar cuales actividades de gestión están cubiertas y cuáles no; como resultado obtendríamos un listado de actividades que deberíamos implementar para gestionar un área de gestión de pruebas en concreto. 
A través de las áreas se define el objetivo de la gestión de pruebas, por lo tanto una manera de evaluar el proceso de gestión es medir la cobertura o el grado del logro de estos objetivos. Así la gestión de pruebas debería satisfacer los siguientes cinco objetivos: 

• Definir y coordinar la iniciación del proyecto de pruebas.
• Definir los recursos necesarios para crear e instalar el entorno de prueba.
• Facilitar la ejecución de las actividades técnicas del ciclo de prueba.
• Apoyar la toma de decisiones a partir de los resultados y las métricas obtenidas durante la ejecución del proceso de prueba.
• Definir, mantener y verificar la calidad de los artefactos de prueba durante y después del proceso.

Otro aspecto importante de las actividades es que se podrían usar como una plantilla para evaluar el nivel de esfuerzo de aplicar cada actividad y se podría obtener un indicador del esfuerzo requerido para implantar el proceso de gestión de pruebas, o el nivel de esfuerzo requerido por cada proceso (columna). 

Descripcion de los Procesos de Gestion de Pruebas

Como mencioné previamente la gestión del proceso de prueba se basa en cinco procesos fundamentales, y cada uno de ellos está compuesto por actividades (definidas en la sección anterior) que definen lo que debe hacerse. En esta sección presento una descripción de alto nivel de los procesos de gestión; esta se hace de manera lineal, sin embargo estos funcionan de manera iterativa y sus actividades se superponen constantemente durante la ejecución del proyecto, por lo tanto este tipo descripción tiene el objetivo de servir como guía para implementarlos, pero su operación y funcionamiento está condicionado por la operación de las actividades técnicas que gestionan, las cuales se ejecutan de manera iterativa (cíclica). 

• Proceso de Inicio del Proyecto de Prueba

Propongo un proceso de inicio de prueba formado por tres actividades principales, la definición del alcance, definición de los participantes de la prueba (“stakeholders”) y comunicar el alcance. 

Planteo la definición del alcance de prueba como una tarea conjunta entre el líder del proyecto de desarrollo y el líder de prueba, la realización de esta actividad desencadena la ejecución de las otras dos. Esta actividad se integra dentro de la formulación del plan del proyecto de desarrollo (el cuál no se contempla dentro del alcance de esta investigación). A partir de allí se define el proyecto de prueba. Para definir el alcance del proyecto de prueba se toma como entrada el plan del proyecto de desarrollo, a partir de él se define brevemente el o los niveles de prueba a aplicar, las técnicas a usar y la dimensión del sistema; con esta información se definen los participantes en el proceso de prueba, se comunica el alcance del proyecto y se da paso a la elaboración del plan de prueba. 

• Proceso de Planificación del Proyecto de Prueba

Este proceso usa como entradas el plan de del proyecto de desarrollo y el documento que define el alcance de prueba junto con los participantes, el cual pasa a formar parte del plan. El plan de pruebas contiene los siguientes elementos: asignación de recursos, definición de hitos, identificación del  sistema a probar, identificación de la especificación de requisitos, definición del escenario de prueba y la definición del nivel de prueba defino las actividades y pasos para construir el plan, las cuales describo a continuación.

• Identificar el sistema bajo prueba. En esta actividad se dimensiona el sistema y se establecen los tipos de técnica de prueba a aplicar, es decir se define el enfoque de prueba. También se analiza cuales son las partes más críticas del sistema (establecer riesgos), que luego serán probadas. 
• Definir los niveles de prueba. Respecto de los niveles el plan debe definir al menos un nivel. Sin embargo podrían definirse varios niveles de prueba, en cuyo caso podría definirse un plan para cada nivel. 
• Identificar la especificación de requisitos. Una especificación puede contener variados y diversos tipos de requisitos, a partir de los cuales deberán identificarse aquellos de mayor prioridad o criticidad para la aplicación y para el cliente.
• Definir o estimar las métricas y los casos de prueba necesarios para probar el sistema.
• Con el fin de apoyar la asignación de esfuerzo y recursos sugiero que se haga una primera estimación de los casos de prueba necesarios para probar el sistema; la cual será depurada en la fase de diseño de pruebas, descrita en el capítulo anterior. Durante esta actividad también debe definirse algunas de las reglas más importantes para guiar la ejecución del  proceso (criterios de control). Así por ejemplo se definiría el grado de cobertura de prueba, los criterios de fallo, las métricas o indicadores para determinar sise avanza o no al siguiente nivel de prueba, o si debe repetirse de nuevo la prueba. 
• Definir y secuenciar las actividades. Consisteen definir detalladamente cada fase de prueba (“Work Breakdown Structure”), los productos, los hitos, asignar el responsable, las características del artefacto que debe generar cada fase como resultado y el orden de ejecución.
•  Asignación de los recursos (personal, infraestructura, técnicos, etc.). Se asignan los recursos necesarios para construir el entorno de prueba, se determinan los elementos de la plataforma de despliegue y se definen las habilidades técnicas del personal requerido, es decir se caracterizan los roles. 
• Descripción inicial del escenario(s) deprueba, que consiste en indicar la especificación de requisitos, el sistema bajo prueba y el entorno en el que serán probados.
• Adicionalmente determinar las áreas geográficas de aplicación si fuese necesario, por ejemplo en modelos distribuidos es necesario especificar las responsabilidades de cada lugar y el orden en que estos deberían realizar las pruebas. 
• Este proceso está estrechamente relacionado con la fase de requisitos de prueba que es parte del ciclo de vida de actividades técnicas de prueba definido en el capítulo cinco; la cual tiene un mayor énfasis en las actividades de gestión más que en las técnicas.

• Ejecución de los Procesos Técnicos de Prueba

La Figura 72, muestro los flujos y las actividades que conforman el proceso de ejecución de los procesos técnicos de prueba. Este proceso tiene como objetivo elegir y dirigir el equipo del proyecto de pruebas, comunicar la información (dirigir los flujos de información) y, dirigir la ejecución de las fases del ciclo de vidade pruebas. Este proceso es transversal a las áreas de: actividades técnicas de prueba, resultados de prueba y activos de prueba; adicionalmente se apoya en los procesos de seguimiento & control y finalización de las pruebas, que describo en el siguiente apartado. 

Elegir equipo del proyecto de prueba.Esta actividad usa como entrada la información suministrada por el plan de pruebas respecto de los roles asignados, las actividades y los  responsables de cada una de ellas. Esta debe ser una de las primeras actividades en realizarse durante el proyecto, debería ejecutarse antes de finalizar el proceso de planificación. Para elegir el equipo se tienen en cuenta las habilidades requeridas por los roles definidos en el plan de prueba.

Capacitar el equipo del proyecto, asignar actividades. Una vez elegido el equipo, este debe recibir capacitación respecto del proceso y la metodología a usar; adicionalmente como parte de las actividades de dirección se le comunican las metas y el plan de trabajo; se asignan las actividades a realizar y se evalúa su cumplimiento. 

Definir esquema de acceso a la información y Distribuir información. Estas dos actividades están estrechamente relacionadas; la primera define la forma como se debe distribuir la información; y la segunda (Distribuir información) tiene la responsabilidad de dirigir los flujos de información (técnicos y de gestión) a los participantes del proyecto. Para ello se basa en el modelo de flujos de información que se muestra en la Figura 68, la cual define como fluye la información entre los diferentes artefactos, actividades y roles que forman parte del proyecto de pruebas.Esta actividad se basa en un esquema de acceso que permite entregar la información que necesita cada participante y por nivel y la distribución de la información de acuerdo con ese esquema.  Para dirigir la ejecución de las fases del ciclo de vida de pruebas propongo cinco actividades: verificar la instalación y configuración de los elementos del entorno de prueba, ejecutar el plan de prueba, calcular métricas, verificar final de la fase y el producto y actualizar el plan de prueba; las cuales se basan en la información suministrada por el plan de pruebas y el plan detallado de las actividades técnicas de prueba contenido en él. Verificar la instalación y configuración de los elementos del entorno de prueba, esta consiste en verificar y garantizar que todos los elementos técnicos de apoyo a las actividades de prueba, estén instalados y configurados de acuerdo con las especificaciones del plan y con los requisitos técnicos para ejercitar el sistema. Esta actividad es clave en las pruebas funcionales de sistema, dado que dentro el entorno de prueba se deberá incluir todos los elementos de la plataforma de despliegue necesarios para ejercitar el sistema, con lo cual a través de él se podrá probar el despliegue y tomar decisiones sobre la fase de implantación. Esta actividad se basa en dos elementos el plan de prueba y el escenario de prueba. 

•  El plan de prueba proporciona la información sobre los recursos de que se dispone para configurar el entorno, adicionalmente sirve como información base para establecer una lista de verificación. 
• El escenario define las características que debe tener el entorno en cuanto a infraestructura, tales como: las herramientas que deben instalarse, la estructura de directorios que se debe crear, la definición de la estructura del repositorio para guardar los diferentes artefactos, y define exactamente dónde encontrar los elementos necesarios durante el despliegue dela prueba. El objetivo es obtener la  plataforma de despliegue de las pruebas. Propongo usar secuencias de comandos (“scripts”) para configurar y ejecutarlos elementos del entorno durante el despliegue de la prueba. 
• En concreto el entorno de prueba usa los recursos de infraestructura asignados por el plan de prueba; respecto de los elementos necesarios y sus características, en cuanto a configuración las define el escenario de pruebas, estas se implementan por las secuencias de comandos de prueba que actúan sobre los elementos de la plataforma de despliegue.
• Ejecutar el plan de pruebas. Se usa la planificación detalladade las actividades técnicas contenidas en el plan de pruebas con el propósito de garantizar que cada actividad cuente con los recursos necesarios para realizarse y que se inicie de acuerdo con la programación indicada por el plan, es decir ejecutar el plan de prueba. 
• Calcular las métricas. Esta es una actividad clave, que tiene como objetivo  proporcionar la información para apoyar la toma de decisiones y soportar la ejecución del plan. 
• Verificar final de la fase y producto. Esta actividad es responsable de garantizar que se hayan obtenido los productos al final de cada fase, de informar el momento exacto de terminación de la fase. Es una actividad que complementa a la actividad “ejecutar el plan de pruebas”. 
• Actualizar el plan. Propongo esta actividad con el fin de introducir los cambios en la planificación, cuando fuese necesario. Por ejemplo esto podría ocurrir como resultado de un evento en la ejecución de la prueba, el cual puede estar relacionado con la asignación adicional de recursos, o con lanecesidad de efectuar más pruebas a un elemento, o con el cambio en la configuración del entorno de pruebas entre otras.
• Los elementos que participan en las anteriores actividades, son aquellos que forman parte del modelo de ejecución de actividades técnicas (definido en el capítulo cuatro, ver Figura 51); para los cuales indico su nivel de participación así: 
• El plan de prueba. Aporta la información sobre la duración de las fases, los hitos, las características de los productos y las métricas que deberían calcularse.
• Escenario de prueba.Establece la información sobre los elementos mínimos para la ejecución de la prueba, junto con el plan y el caso de prueba constituyen los elementos directores de esta actividad. 
•  El plan de ejecución. Es un elemento implementado por secuencias de comandos, tal como lo defino previamente en este trabajo (ver capítulo cuatro), a partir de él se pueden establecer puntos de observación en cualquier momento del proceso, extraer métricas para apoyar actividades como la toma de decisiones durante la ejecución de acuerdo con las métricas establecidas, incluso variar el orden de ejecución o suspender la ejecución.
• El caso de prueba. Es un elemento esencial para la ejecución del proceso. La actividad de ejecución de las actividades técnicas se centra en verificar que todos los casos de prueba relacionados con el escenario que se desplegará, estén listos para ser ejecutados. Para verificar esta regla básica del proceso de pruebas, se establece un punto de observación, que extrae la información y la compara con la información contenida en el plan y con la descrita por el escenario. Con base en ello se decide respecto de las fases de diseño, especificación e implementación de los casos de prueba.
• La especificación y los datos de prueba. Estos dos elementos están estrechamente relacionados con el caso de prueba, a partir de ellos se establecen métricas (indicadores) para evaluar aspectos como la cobertura y que tan suficientemente se ha probado el sistema.
• El registro de prueba. Este elemento aporta todala información registrada durante el proceso de ejecución de la prueba. La cual es útil para determinar el progreso del proceso, en términos de ejecución, de validez y cobertura entre otros.
• El proceso de Control y Seguimiento de las Pruebas

Este proceso está estrechamente relacionado con el proceso de ejecución de los procesos técnicos de prueba, descrito en la sección anterior; de quien recibe como entrada los valores y métricas con el fin de tomar decisiones sobre la ejecución, de acuerdo con lo establecido en el plan de prueba respecto de la programación, la calidad y los riesgos.

Es transversal a las áreas de ejecución de actividades de prueba, de resultados y de activos. Propongo cinco actividades de gestión para implementar este proceso tal como lo muestro en la Figura 69, las cuales defino a continuación. 

• El seguimiento de la ejecución de las actividades del proceso de prueba. Para llevar a cabo esta actividad defino dos entradas: la programación detallada de las actividades contenida en el plan (hitos) y las medidas de progreso del proceso de prueba emitido por los procesos de ejecución. A partir de ellos se establece si la actividad o fase de prueba se ha realizado en el tiempo previsto y si se han obtenido los resultados planificados. En el caso de existir alguna diferencia se comunica una novedad o directiva de control a los procesos de ejecución, para tratar con ella, es decir iniciar acciones correctivas.
• Control de calidad. En el proceso de pruebas defino la calidad como el logro de los niveles de cobertura establecidos en el plan, la detección de un rango de fallos (mínimo - máximo) y la verificación de que los fallos previamente detectados hayan sido corregidos en una iteración posterior. Para lograrlo propongo como mecanismo de control de calidad el cálculo y la extracción de la información relevante de los resultados (cobertura de código, de requisitos, fallos, e incidencias) durante el progreso del proceso de prueba, para ello me baso en la actividad definir puntos de observación. La información obtenida se compara con los umbrales de calidad establecidos y se toman las decisiones respecto de validar el proceso de prueba, repetir o no una prueba, parar el proceso, o determinar el cierre del mismo. Para ello el proceso se apoya en la actividad enviar novedad de control al proceso de ejecución. 
• Informar del avance del proyecto. Esta actividad tiene por objetivo presentar el informe detallado de los resultados del proceso de prueba por cada prueba realizada y/o por iteración. Para ello toma como entrada los resultados generados por la ejecución de los casos de prueba, junto con los indicadores (métricas) generados durante el proceso. Con esta información se elaboran informes tales como: total de fallos detectados, número de casos de prueba ejecutados, número de requisitos probados, cobertura de código, cobertura de requisitos, incidencias abiertas y/o cerradas, grado de cumplimiento del plan, etc.
• El proceso de Cierre del Proyecto de Prueba

El objetivo de este proceso es evaluar el proceso de prueba en general, es decir realizar un balance general, con el fin de establecerla efectividad real del proceso, obtener  mejoras en futuras campañas de prueba y de analizar la información de las pruebas de manera global, para entregar información útil y recomendaciones, que ayuden a mejorar el trabajo del equipo de desarrollo y a disminuir el esfuerzo en la fase de implantación del sistema. Como muestro en la Figura 74, el flujo de este proceso está dirigido por una serie de decisiones que se toman de acuerdo con la información generada durante la ejecución de las pruebas. 

El proceso de cierre del proyecto de prueba se inicia como resultado de una novedad de control, la cual establece a través del seguimiento que hace de la ejecución, que la totalidad de actividades planificadas se hayan realizado a través de todas las iteraciones de prueba previstas. Este proceso se basa en la trazabilidad de los activos generados, de los cuales toman la información del proceso y le aplica los criterios de aceptación de las pruebas. Estos criterios son los valores respecto de cobertura, porcentaje de errores, densidad de fallos, número de casos de prueba ejecutados, etc., los cuales son establecidos por el líder del equipo de desarrollo, el líder de prueba y el cliente. Para su implementación defino siete actividades: 

• Verificar entrega de producto. Esta actividad verifica principalmente dos aspectos: que todos los casos de prueba programados se hayan ejecutado y que se hayan enviado los informes respectivos a los participantes. En caso contrario informar al líder de prueba y suspender el cierre. 
• Verificar el cierre de incidencias. Establecer el número total de incidencias abiertas como resultado del proceso, cuáles de ellas fueron aceptadas y cuáles no y de las aceptadas verificar que se hayan cerrado todas, en caso contrario informar y suspender el cierre.
• Verificar el nivel de cobertura alcanzado. Validar queel nivel de cobertura alcanzado sea al menos igual al nivel establecido en el plan de prueba. En caso negativo informar y se suspende el cierre.
• Calcular la densidad de fallos. Elaborar un informe con el número de fallos totales, fallos por componentes y porcentajes de estos respecto del total, con ello se determina la densidad de fallos. 
• Preparar recomendaciones. Respecto del informe de recomendaciones para el grupo de desarrollo este debería contener valores sobre indicadores como: casos de prueba ejecutados, partes del sistema probadas, cobertura de requisitos, cobertura de código, fallos descubiertos, incidencias abiertas, incidencias cerradas, densidad de fallos, recomendaciones de pruebas de regresión para aquellos componentes con más fallos detectados, incluso recomendaciones sobre capacitación al personal de desarrollo para prevenir fallos en la estructura y estilo del código. Respecto del sistema enviar restricciones de operación relacionadas con aspectos no funcionales, o informar sobre las condiciones reales operación entre otras.
• Establecer elementos reutilizables. El objetivo es evaluar cuales de los activos del proceso (datos de prueba, casos de prueba, ficheros de secuencias de comandos, el registro de prueba, etc.) podrían usarse en pruebas de regresión o en otros proyectos similares. 
• Evaluar el proceso. Esta actividad tiene como objetivo establecer el grado de eficiencia del proceso, considerar las buenas prácticas que pasarán a formar parte de los procesos organizativos, establecer que aspectos deben mejorarse para futuros proyectos de prueba y garantizar la permanencia y accesibilidad de la información contenida en los activos de prueba para uso posterior tanto del cliente del sistema como de la organización.

Procedimientos de Gestión de Prueba

En la sección anterior definí los procesos de gestión, los cuales involucran un conjunto de actividades; que para su realización requieren de la ejecución de uno o varios procedimientos; los cuales describo en esta sección. Estos procedimientos son el motor del modelo de toma de decisiones propuesto anteriormente (ver sección 6.2), cuya función es extraer y analizar la información de los activos técnicos de prueba, y proporcionarla a los procesos de gestión para apoyar su operación. De acuerdo con la naturaleza de estos procesos no es posible definir procedimientos detallados para algunos de ellos, por lo tanto clasifico las actividades en dos grupos. El primero involucra a las actividades tales como: la definición del alcance de pruebas, la identificación de los participantes y la planificación de las pruebas; estas se realizan de forma manual y para su ejecución dependen de la habilidad de quien las realiza, con el apoyo de algunas herramientas de automatización de oficina. En el segundo grupo incluyo actividades tales como: el control y dirección de la ejecución, el análisis de las métricas y de los resultados; para las cualesdefino procedimientos concretos que actúan sobre los activos técnicos de prueba. Estos procedimientos los denomino procedimientos de gestión de pruebas, los cuales defino en las siguientes sub-secciones.