Download - GPS Para MoProSoftv1.0

5/14/2018 GPS Para MoProSoftv1.0 - slidepdf.com

http://slidepdf.com/reader/full/gps-para-moprosoftv10 1/66

Guía de Pruebas de Software (GPS)

GPS - Guardati & Ponce 1

GUÍA DE PRUEBAS DE SOFTWARE(GPS) PARA MOPROSOFT

Silvia Guardati1

Alain Ponce2

1 Profesora del Departamento Académico de Computación – División Académica de Ingeniería - ITAM

2 Maestría en Tecnologías de Información y Administración - División Académica de Ingeniería - ITAM





I. INTRODUCCIÓN................................................................................ 3

I.1 Implantar un lineamiento base ................................................................................................... 4 I.2 Incrementar la eficiencia ............................................................................................................ 5 I.3 Organización del documento...................................................................................................... 7

II. GUÍA DE PRUEBAS DE SOFTWARE (GPS)................................ 9

II.1 Alta Dirección (DIR)................................................................................................................... 10

II.2 Gerencia (GER).......................................................................................................................... 13

II.3 Operación (OPE)........................................................................................................................ 16 II.3.1 Administración de Proyectos Específicos [OPE.1] .............................................................. 17

II.3.2 Desarrollo y Mantenimiento de Software [OPE.2] ............................................................... 23

III. PRUEBA DE SOFTWARE: CONCEPTOS BÁSICOS................56

III.1 Pruebas estáticas y dinámicas............................................................................................... 56 III.2 Requerimientos ...................................................................................................................... 59 III.3 Planeación de pruebas........................................................................................................... 61 III.4 Actividades comunes de pruebas .......................................................................................... 62 III.5 Ciclos de pruebas................................................................................................................... 64

REFERENCIAS .....................................................................................66





I. INTRODUCCIÓNEn un mercado tan competitivo como el actual, una PyME no puede permitirse entregar productos

de mala calidad o fabricar software que no realice las actividades para las que fue diseñado. Unerror cometido por una PyME dentro de sus primeros meses e incluso años de vida puede ser un

factor determinante para su permanencia o no en el mercado.

Esta guía está enfocada a las PyME-TIC que aplican MoProSoft [1]. El negocio principal de

estas organizaciones es crear o mejorar software para otras áreas de la misma organización o para

terceros. Con el seguimiento de la guía, las empresas podrán lograr:

Disminución de los tiempos de entrega.

Reducción de codificación incorrecta o innecesaria.

Reducción de defectos en el producto final.

Entrega de productos alineados a los requerimientos de las empresas cliente.

Definición cuantitativa del programa de calidad.

Mayor tiempo de permanencia en el mercado de los productos.

Creación de una memoria institucional con los proyectos concluidos, constituyendo una

referencia para los nuevos proyectos.

Mayor claridad entre empresas con respecto a niveles de calidad del software desarrollado.

Soporte de pruebas al modelo MoProSoft en sus 3 categorías.

Estrategia de la Empresa

T e o r í a d e P r u e b a s

G e s t i ó n d e R e c u r s o s

G e s t i ó n d e D e f e c t o s

Gestión de procesos

G e s t i ó n d e P r o y e c t o s

Desarrollo yMantenimiento de

Software

Administración deproyectos específicos

V a l o r a c i ó n y M e j o r a C o n t i n u

a

Figura 1- Integración de actividades de pruebas al ciclo de desarrollo del proyecto.





Se toma como base MoProSoft para aplicar la guía de pruebas en las distintas etapas del modelo

(figura 1), y tratando de cumplir con dos objetivos:

1. Implantar un lineamiento base: fomentar el desarrollo de las pruebas en cualquier proyecto de

la empresa mediante una integración de esta teoría con la estrategia, planeación y procesos de

la organización.

2. Incrementar la eficiencia: para cada una de las tareas del modelo MoProSoft es posible

ejecutar pruebas adecuadas a la PYME, enfatizando en aquellas donde se pueden observar

mejoras a largo plazo.

I.1 Implantar un lineamiento basePara lograr el primer objetivo se aplica la guía de pruebas dentro de las categorías de Alta Dirección

y Gerencia de MoProSoft.

I.1.1 Alta Dirección

En la tabla 1 se presentan las tareas que se desarrollan en la guía dentro de la categoría Altadirección, incluyendo sus beneficios. En la misma se muestra la actividad de pruebas a desarrollar

dentro de cada tarea específica de las actividades de Planificación Estratégica y Valoración y

Mejora Continua de MoProSoft, así como los beneficios que se obtienen al desarrollarla. Por

ejemplo, desarrollar el plan estratégico de la empresa y su validación son actividades de pruebas a

ejecutar dentro de la tarea A1.11, en la actividad de Planificación Estratégica, obteniendo como

beneficios:

La reducción de malentendidos, documentación incompleta y huecos en el plan.

Mayor conocimiento y entendimiento de éste dentro de la organización.

Proceso Actividad MoProSoft Tarea Actividad de Pruebas Beneficios

A1. Planificación Estratégica (O1) A1.2.

Obtener una imagen real de la calidad delos servicios de la empresa.

Conocimiento de las fortalezas ydebilidades de la empresa enfocaaquellas actividades que las pruepueden mejorar.


Desarrollar objetivos para el área depruebas, enfocados a incrementar lacalidad de los productos finales.

Desarrollar las estrategias del área, conlas que se pretenderá cubrir dichosobjetivos.

Formación de una base estratégicpruebas que está enfocada en redebilidades que se requiere desa

dentro de la organización.


Desarrollar el plan estratégico de laempresa, incluyendo la estrategia a tomar

en todo lo relacionado a las pruebas.Validar el plan estratégico de la empresa

mediante el uso de herramientas depruebas estáticas.

Evitar defectos en el plan estratégcomo: malentendidos, documenta

incompleta y huecos en el plan.Reducción de tiempos para el

entendimiento total del plan estra

A3. Valoración y Mejora Continua

(O3) A3.1.

Contar con una base de criterios quepermitan recibir información acerca deprocesos y actividades que necesitan sermejoradas.

Facilidad de mejora mediante laactualización de los procesos de de la organización.

Alta dirección

D I R

. 1 G e s t i ó n d e N e g o c i o

Tabla 1 - Beneficios en la aplicación de pruebas en la categoría Alta Dirección.





I.1.2 Gerencia

La guía incluye actividades de pruebas dentro de dos de los procesos de la categoría de Gerencia:

Gestión de Procesos y Gestión de Recursos. La elección de los mismos obedece a los beneficios

esperados (ver tabla 2).


G E S . 1

G e s t i ó n

d e

P r o c e s o s

A1. Planificación (O1) A1.1.

Implementar una nomenclatura y librería

de procesos enfocados en las pruebas.

Control completo de las diferentes

actividades y procesos de pruebas u

por la empresa.

A1. Planificación de Recursos

(O1, O2) A1.3.

Determinar criterios para la adquisición de

bienes enfocados a realizar pruebas.

Determinar los planes de capacitación

necesarios para incrementar la eficienciaen la realización de las pruebas.

Planeación de gastos en las pruebas

determinación de Costo/Beneficio de

gastos.

Determinación de un calendario de

utilización de los recursos de prueba

empresa.

A3. Investigación de

Tendencias Tecnológicas

(O3) A3.1.

Determinar el impacto de las nuevastecnologías en la eficiencia de la ejecución

de pruebas de la empresa.

Visibilidad de las nuevas tendenciasmercado, así como probable evaluac

éstas antes de su implementación. G E S . 3

G e s t i ó n

d e R e c u r s o s

Gerencia

Tabla 2 - Beneficios en la aplicación de pruebas en la categoría Gerencia.

Para Gestión de Procesos es necesario implementar una nomenclatura dentro de los

procesos de las pruebas, obteniendo un control único de las diferentes actividades y procesos de

pruebas usados por la empresa.

Para la Gestión de Recursos básicamente se integran los criterios de pruebas para planificar

los recursos necesarios para llevar a cabo las actividades de la guía, además de facilitar la mejora de

estas actividades mediante la retroalimentación proveniente de la operación.

I.2 Incrementar la eficienciaPara lograr este objetivo, la guía ofrece elementos para incluir las pruebas en la categoría Operación

dentro de sus dos procesos: Administración de proyectos específicos y Desarrollo y Mantenimiento

de Software.

I.2.1 Administración de proyectos específicos

En este proceso se integra el conocimiento general de pruebas dentro de la planificación del

esfuerzo requerido en las distintas etapas de la creación de software.

Una actividad de pruebas importante aquí es la determinación del número de ciclos yactividades adecuados para cada tipo de pruebas, haciendo posible planear de una manera real el

esfuerzo requerido para lograr un objetivo de cobertura deseada por la empresa. Esta actividad de

pruebas también permite realizar un plan de ejecución detallado y enfocado a maximizar los

recursos disponibles dentro de la organización. Otra de las actividades importantes dentro de este

proceso es formalizar las condiciones de cierre para cada fase del proyecto. Esta actividad permite

establecer los criterios a cumplir dentro de cada etapa con el fin de tomar decisiones de

continuación o paro de la fase (o del proyecto), de acuerdo a la calidad alcanzada (que podrá ser





medida). Los beneficios obtenidos por aplicar la guía en esta categoría se pueden observar en la

tabla 3.



Determinar el número de ciclos y

actividades adecuados para cada tipo de

pruebas.

Defininir las actividades necesarias par

obtener la cobertura de pruebas desea

en cada proyecto.

A1. Planificación (O1) A1.6.Determinar el tiempo esperado para cadaactividad de pruebas.

Disminuir la variación en la planeación recursos de pruebas.


Conformar un equipo de trabajo depruebas.

Determinar la mejor manera de obtenerrecursos de pruebas, de acuerdo a lascaracterísticas específicas de la empre


Generar calendarios de trabajo de las

pruebas.

Obtener una línea base real para el

desarrollo de las actividades de pruebasoportando el enfoque de estas hacia l

mejora del producto final.

A4. Cierre (O1) A4.1.

Formalizar las condiciones de cierre en lasdiferentes fases de programación y delproyecto total.

Entregar bases cuantitativas acerca decalidad esperada en cada una de lasdiferentes etapas del desarrollo del

software.Estas bases se pueden utilizar como pa

de un contrato de calidad del proyecto. O

P E 1 . A d m i n i s t r a c i ó n d e P r o y e c t o s E s p e c í f i c

o s

Operación

Tabla 3 - Beneficios en la aplicación de pruebas en el proceso OPE1, de la categoría Operación.

I.2.2 Desarrollo y mantenimiento de software

Para el proceso de Desarrollo y Mantenimiento de Software la guía presenta diferentes actividades,

técnicas y fases de pruebas que se deben de considerar dentro de la etapa de desarrollo (o

mantenimiento) del proyecto.

Dentro de estas actividades destaca la revisión de requerimientos, donde se especifican las

funcionalidades que debe tener el sistema una vez terminado. Una validación aquí es tan crítica quede ella puede depender que el sistema, como un todo, cumpla o no el objetivo para el que fue

desarrollado.

En la fase de pruebas unitarias, de integración de componentes y de sistema, se desarrollan

procedimientos que brindan como beneficio la disminución de los defectos típicos de cada una y el

aprovechamiento de recursos. Un ejemplo de eficiencia de recursos es evitar gastar demasiado

tiempo en el registro de errores en la fase de pruebas unitarias, debido a que por su naturaleza es

muy difícil mantener un control exacto de éstos.

Así mismo, GPS agrega la fase de pruebas de Aceptación de Usuario, donde se valida el

software desde una perspectiva de negocio, obteniendo beneficios como: ganar confianza del

usuario final y reducir los riesgos al implantar el sistema en condiciones de operación reales.

Finalmente, el registro de métricas de pruebas se encuentra inmerso en cada fase del

modelo MoProSoft, con lo que es posible conocer en todo momento el estado actual de éstas y la

calidad del proyecto en general.






A2. Realización de lafase deRequerimientos(O1,

O3)

A2.2. Asegurar que los requerimientosse encuentran alineados a lo queel cliente requiere.

Software alineado a los requerimientos del cliente.Software aplicable en los procesos de negocio del Software fácil de usar.

Software enfocado al cliente.

A2. Realización de la

fase deRequerimientos(O1,O3)

A2.3. Identif icación y val idación

estática de los requerimientos delproyecto.

Requerimientos claros para todos los niveles de la

organización, así como para el cliente, permitiendodisminuir el esfuerzo empleado en la creación de mno importantes ó fuera del alcance.

A2. Realización de la

fase deRequerimientos(O1,O3)

A2.7. Bases para la elaboración

correcta de un plan de la fase depruebas de sistema y aceptación.

Eliminación de tiempos insuficientes u holgados de

la creación del plan.Conforme se obtiene experiencia los datos son mápara cada empresa.

A3. Realización de lafase de Análisis yDiseño (O1,O3)

A3.2. Validación de la estructura internadel sistema.

Reducción de malentendidos técnicos que pudieraocasionar retrasos y mayores costos debido a falladiseño básicas de los diferentes módulos del proye

A3. Realización de lafase de Análisis yDiseño (O1,O3)

A3.7. Bases para la elaboracióncorrecta de un plan de la fase depruebas de integración.

Reducción en los tiempos de planeación.Consideración total de las actividades necesarias ppruebas de integración.

A4. Realización de lafase de Construcción(O1, O3)

A4.2. Aplicar pruebas unitarias decomponentes.

Reducción de fallos en el código desde etapas temproporcionando calidad con menor esfuerzo.Registro de métricas de defectos en la etapa de

codificación.

N/A N/A Definir casos de prueba yescenarios.

Creación de una guía parametrizable de ejecuciónpruebas con la que será posible delegar esta activmiembros del equipo con menor conocimiento delfuncionamiento del negocio.

N/A N/A Definir datos de pruebas. Reducción en el tiempo de ejecución de pruebas.

Facilidad en el descubrimiento de defectos causaddatos no comunes en la operación normal.

A5. Realización de lafase de Integración yPruebas (O1, O3)

A5.2. Realizar fase de integración. Reducción de defectos en el nivel de comunicaciócomponentes, lo que ocasiona reducción de defecetapas posteriores del proyecto.

A5. Realización de lafase de Integración yPruebas (O1, O3)

A5.6. Realizar pruebas de sistema y deaceptación.

Con las pruebas de sistema se puede determinar uconfiabilidad de la operación del software desde unde vista más real hacia el usuario.Con las pruebas de aceptación se permite entrega

confianza al usuario final acerca de la operación tosoftware, tal como se utilizará en las condicionesnormales del día a día.

A6. Realización de lafase de Cierre(O2)

N/A Cierre del proyecto, en base amétricas de pruebas.

Fase de entrega o rechazo del proyecto de acuerdparámetros definidos al inicio de éste. Lo que permidentificar con claridad los cumplimientos del contrefectuados en la firma del proyecto.

A6. Realización de lafase de Cierre(O2)

A6.1 Soporte en el manual demantenimiento (ambientes de

pruebas).

Adición al manual de mantenimiento de las diferencaracterísticas necesarias para la operación correc

sistema bajo los ambientes requeridos.

O P E 2 . D e s a r r o l l o y M a n t e n i m i e n t o d e S o f t w a r e

Operación

Tabla 4 - Beneficios en la aplicación de pruebas en el proceso OPE2, de la categoría Operación.

I.3 Organización del documentoEste documento consta de tres capítulos. En el primero se presentaron las actividades de

MoProSoft cubiertas por GPS y los beneficios esperados.

El capítulo dos está dedicado a la guía, en él se presenta para cada una de las categorías de

MoProSoft las actividades sugeridas por GPS, así como material requerido para ejecutar dichas

actividades.





En el capítulo tres se presentan algunos de los conceptos más importantes de la teoría de

pruebas. Este capítulo pretende servir como auxiliar en la capacitación de los miembros de una

organización que realizará actividades de pruebas. Este capítulo puede ser omitido por aquellos

lectores que ya poseen los conocimientos del área y que sólo requieren de una guía para la

implementación de las pruebas en el marco de MoProSoft. Por último, se presentan las referencias

bibliográficas.





II. GUÍA DE PRUEBAS DE SOFTWARE (GPS)A continuación se presenta la Guía de Pruebas de Software (GPS), adecuada a la PyME y

relacionada directamente a cada una de las actividades de MoProSoft en las cuales se considera quelas pruebas son más eficientes y/o necesarias.

La guía está estructurada de acuerdo al modelo MoProSoft, con objeto de simplificar la

localización de las diferentes actividades de prueba que componen a cada una de las categorías del

modelo. En la figura 2, de cada categoría, se colorean (sombreadas) las actividades cubiertas por la

guía.

Gestión de Negocio Gerencia

Operación

Administración de proyectos

específicos

Valoración y mejora

continua

Preparación para la

realización

Gestión de

procesos

Gestión derecursos

Gestión deproyectos

Planeación

Realización

Desarrollo y mantenimiento de software

Inicio

Cierre

Planeación estratégica

Fase de Requerimientos

Fase de Análisis y

Diseño

Fase de Construcción

Fase de Integración y

Pruebas

Figura 2 - Actividades del modelo MoProSoft cubiertas por la guía.





Al inicio de cada sección de la guía (ver figura 3), se encuentra una descripción y un

esquema de las actividades que contiene la categoría del proceso, relacionándolas con las

actividades de pruebas. La expresión Oi, junto al nombre de la actividad Aj de MoProSoft, hace

referencia al objetivo i del proceso alcanzado por medio de la actividad Aj.

II.1 Alta Dirección (DIR)La teoría de pruebas enfocada a la categoría Alta Dirección (DIR) es un pilar fundamental del

proyecto de pruebas, ya que es indispensable que la cabeza de la organización conozca los

beneficios de la implantación de éstas dentro de un enfoque de negocios.

Dentro del modelo MoProSoft, en la categoría Alta Dirección se encuentran las diferentes

actividades relacionadas al proceso de Gestión de Negocio.

Planificación estratégica

Valoración y mejora

continua

Preparación para la

realización

Gestión de Negocio

MoProSoftActividades Tareas Actividades GPS

A1.2 1. Entender la situación actual

A1.3 2. Desarrollar o actualizar objetivos y estrategiasA1. PlanificaciónEstratégica (O1) A1.11 3. Verificar el Plan Estratégico

A3. Valoración y MejoraContinua (O3)

A3.1 Análisis de la información y evaluación del desempeño

Figura 3 - Cobertura de la guía en la categoría Gestión de Negocio de MoProSoft.

II.1.1 Gestión de Negocio [DIR.1]

GPS se enfoca en dos estrategias dentro del proceso de Gestión de Negocio:a. Planificación Estratégica (O1).

b. Valoración y Mejora Continua (O3).

a. Planificación E stratégica

Las siguientes tareas están relacionadas a la actividad de Planeación Estratégica: 1) Entender la

situación actual, 2) Desarrollar o actualizar objetivos y estrategias y 3) Verificar el plan estratégico.





1) Entender la situación actual

Dentro de la tarea A1.2 de MoProSoft, la guía se enfoca directamente a la ejecución del Análisis de

la situación interna, donde es indispensable determinar la calidad de los productos que actualmente

se están entregando al usuario final. Para realizar este análisis lo más recomendable es aplicar una

entrevista o encuesta tanto al equipo de ventas como al usuario final, enfocándose en aspectos

como:

Confiabilidad del sistema (robustez, disponibilidad, portabilidad).

Cumplimiento de lo esperado (% de satisfacción).

Facilidad de uso y aspecto (look & feel).

Tiempo de entrega (días).

Tiempo de retraso estimado (días).

Calidad de la documentación.

Costo.

Tiempos de resolución de problemas.

Aunque el usuario final no lo perciba, el enfoque de la encuesta debe ser tal que sea posible

observar las diferentes desviaciones de costo y tiempo en la entrega de los resultados, respecto al

plan original.

Este tipo de ejercicios permite obtener datos reales y concretos en cuanto a la percepción final

del producto que está desarrollando la empresa, las áreas de mejora existentes y las fortalezas ya

desarrolladas que hay que mantener. El siguiente paso en el Análisis de la situación interna es el de

determinar si las oportunidades existentes se pueden cubrir implementando la teoría de pruebas en

los diferentes niveles del ciclo de vida del proyecto.

2) Desarrollar o actualizar objetivos y estrategiasUna vez que se ha concluido con el Análisis de la situación interna, entonces es posible determinar

los objetivos del área de pruebas que se desee así como las estrategias para lograrlos a corto,

mediano y largo plazo.

Los objetivos del área de pruebas tienen que estar relacionados de manera general con

indicadores estratégicos, tales como: la percepción de la calidad de los productos finales, la

“usabilidad” de los productos, el análisis de los beneficios a obtener al invertir en el área de pruebas

y los recursos de la empresa que puede disponer para efectuar estos esfuerzos. Algunos objetivos

típicos en el área de pruebas son:

A corto plazo

Contar con una agrupación de pruebas en un periodo no mayor a 3 meses con un

proyecto piloto que comience dentro de ese tiempo.

Realizar pruebas en todas las fases de los 5 proyectos más importantes.

Aumentar la utilización de las pruebas de aceptación de usuario a un 50% de los

proyectos.

A mediano plazo





Ejecutar las pruebas de sistema en un 100% de los proyectos y las pruebas de

aceptación de usuario en un 80%.

Capacitar a todo el personal de pruebas en el uso de herramientas estándares de pruebas

en un periodo de 1 año.

Integrar un área especializada únicamente en pruebas, incluyendo metodología,

herramientas y capacitación estándar. Realizar la compra de una herramienta especial de administración de casos de prueba.

A largo plazo

Utilizar herramientas de administración de pruebas dentro de todos los ciclos y

proyectos de la empresa.

Ofrecer al mercado proyectos de pruebas, y que esto represente el 10% de la

facturación anual de la empresa.

Estos ejemplos son sólo algunas ideas que pueden aplicarse en cualquier organización

PyME. Sin embargo, la única manera de aplicarlo es entendiendo las necesidades específicas de la

empresa, así como las bondades que llegarán a ésta al realizar pruebas de manera formal.

Es importante recalcar que para una PyME es muy difícil cubrir varios objetivos al mismo

tiempo, por lo que es muy recomendable asignar prioridades a éstos, con la idea de enfocarse

primero en aquellos que beneficien más a la empresa en su situación actual.

La estrategia del área de pruebas, desde el punto de vista de las pruebas, es la de determinar

las diferentes actividades que se realizarán dentro de la empresa, así como los diferentes criterios de

utilización de ellas en los proyectos, con el fin de lograr los objetivos planteados. A continuación se

muestran 5 ejemplos de estrategias de pruebas que se pueden aplicar en cualquier organización:

Formalizar el proceso de pruebas. Los beneficios que puede brindar formalizar estasactividades son poco tangibles; sin embargo, es un hecho que es el primer paso para lograr una

ejecución correcta de las pruebas, sirviendo de base para la implementación de otras estrategias

más elaboradas.

Utilización de herramientas estándares de pruebas. En esta estrategia se determinan las

diferentes herramientas que se utilizarán dentro de cada una de las actividades de pruebas, tales

como: el análisis de ambigüedades (pruebas estáticas), formatos de casos de prueba o las

herramientas de administración de defectos (pruebas dinámicas).

Determinar el nivel de involucramiento del área de pruebas. Esta estrategia indica los

criterios de participación del área de pruebas en los diferentes proyectos de la empresa. Por

ejemplo, “Las pruebas en los proyectos menores a $XXX serán realizadas en su totalidad por el

grupo de pruebas de la empresa, mientras que en los proyectos de más de $XXX serán

ejecutadas por un grupo externo y validadas por miembros de nuestra empresa”. El beneficio

inmediato que se puede ver con esta estrategia es el de dosificar los esfuerzos del personal de

pruebas sin descuidar la calidad del producto.

Determinar la cobertura de las pruebas con relación al ciclo de vida total del proyecto.

Para que todos los involucrados manejen la misma información, se debe establecer claramente

las actividades del proyecto donde se aplicarán actividades de pruebas. Lo más recomendable es





ejecutar dichas actividades desde el arranque del proyecto, debido a que un requerimiento mal

definido desde el principio será una funcionalidad no deseada del sistema, en otras palabras: un

defecto. Uno de los beneficios inmediatos que se pueden obtener con esta estrategia, es apoyar

de manera inmediata aquellas áreas de oportunidad detectadas en el análisis de la situación

interna.

Entregar información relacionada a las pruebas en todos los proyectos. Es una estrategia

enfocada a ganar confianza en el nivel de calidad de los productos de la empresa, mediante la

entrega de información de la ejecución exitosa de las pruebas de los productos. Al mismo

tiempo, esta información ayudará a contar con una base de datos de proyectos exitosos que

permitirá adoptar las mejores prácticas de los programadores para reducir defectos.

Para poder aplicar alguna de estas estrategias (o cualquier otra) en el área de pruebas, es

necesario que esté completamente alineada a la estrategia global de la organización.

3) Verificar el plan estratégico

Un análisis de ambigüedades (prueba estática) es ideal durante la creación del plan estratégico para

eliminar cualquier mal entendido dentro de los diferentes documentos que lo integran, y paraasegurar documentación completa.

b. Valoración y Mejora Continua (O3)

Para la actividad de Valoración y Mejora Continua se considera tarea: Análisis de la informacióny evaluación del desempeño.

Durante la adopción de pruebas por parte de una empresa, es también necesario definir un

proceso de recolección de métricas en todos los proyectos involucrados. Algunos de los indicadores

más importantes son:

Número de defectos encontrados en cada fase, por tipo de proyecto.

Tiempo utilizado en la resolución de los defectos.

Número de ciclos ejecutados en cada fase de los proyectos.

Cantidad de recursos utilizados.

Fallas en producción.

II.2 Gerencia (GER)El objetivo de MoProSoft para esta categoría consiste en establecer los procesos de la organización,

así como definir, planear e implantar las actividades que ayuden a realizar las mejoras necesarias en

ellos.El objetivo específico para la guía en esta categoría es únicamente definir los procesos de

pruebas establecidos dentro del plan estratégico. Por lo tanto, contiene actividades para los procesos

de Gestión de Procesos y Gestión de Recursos.





Gestión de

Procesos

Gestión deRecursos

Gestión deProyectos

Gerencia

MoProSoft

Actividades TareasActividades GPS

A1. Planificación (O1) A1.1 Establecer o actualizar la definición de

elementos de procesosA1. Planificación de Recursos (O1,O2)

A1.1 Generar o actualizar el Plan deAdquisiciones y Capacitación

A3. Investigación de TendenciasTecnológicas (O3)

A3.1 Generar Propuestas Tecnológicas

Figura 4 - Cobertura de la guía en la categoría Gerencia de MoProSoft.

II.2.1 Gestión de Procesos [GES.1]Para este proceso, la guía se enfoca en la actividad de Planificación (O1).

Planificación (O1)La teoría de pruebas se puede aplicar en la tarea Establecer o actualizar la definición deelementos de procesos, relacionada a la actividad de Planificación de MoProSoft. Es necesario

implementar una nomenclatura y una librería de procesos enfocados a pruebas donde se pueda

documentar la información referente a cada uno y las relaciones entre ellos.

II.2.2 Gestión de Recursos [GES.3]El enfoque de la guía en este proceso se presenta en las siguientes actividades de MoProSoft:

a. Planificación de Recursos (O1, O2)b. Investigación de Tendencias Tecnológicas (O3)

a. Planificación de Recursos (O1, O2)

Dentro de esta actividad, la teoría de pruebas se puede aplicar en el Plan de adquisiciones y

capacitación.





Adquisiciones. Dependiendo del grado en que la empresa realice las pruebas, requerirá o no de

insumos especiales para llevarlas a cabo. Por ejemplo, para validar los requerimientos de la

ejecución del sistema en un servidor específico, para hacerlo en condiciones reales, es necesario

contar con dicho servidor. Esto no implica necesariamente que la empresa deba comprarlo, podría

conseguirlo por arrendamiento o préstamo. Independientemente de la forma de conseguir los

insumos, es necesario considerar todos los casos que puedan presentarse y su mejor solución. Esimportante tener en cuenta los posibles insumos, clasificados por categorías:

Hardware

Equipos Servidores.

Almacenamiento de datos.

Computadoras personales (incluye PDA’s, teléfonos inteligentes, etc.).

Equipo de interconexión.

Dispositivos especiales.

Software

Sistemas operativos (PC, Servidores, Teléfonos, etc.).

Bases de datos.

Software para la administración de pruebas.

Contratos externos (outsourcing)

Personal temporal para ejecutar las pruebas (Testers).

Equipos de profesionales de pruebas externos.

Capacitación. En esta sección es necesario crear un plan específico de entrenamiento en el área de

pruebas que ayude a disminuir el tiempo necesario para adoptar todo el conocimiento que la

empresa requiera, según sus objetivos y estrategias. Para establecer un plan de capacitación se

pueden considerar los siguientes temas: Contenidos en esta guía

Creación de requerimientos.

Revisión de ambigüedades.

Creación de casos de prueba.

Administración de ejecuciones de pruebas.

Creación de datos para pruebas.

Administración de defectos.

Recolección e interpretación de métricas.

Cursos avanzados

Herramientas comerciales para la administración de pruebas.

Herramientas comerciales para ejecución automática de pruebas.

Técnicas avanzadas de diseño de pruebas.

Administración de ambientes de prueba.

Pruebas sin requerimientos.





Si los requerimientos de capacitación de la empresa son muy demandantes en términos de

tiempo y contenido, se puede delegar la capacitación a empresas externas. Sin embargo, en estos

casos el conocimiento será básicamente teórico y será necesario realizar al menos uno o dos

proyectos para alcanzar el nivel de capacitación deseado.

b. Investigación de Tendencias Tecnológicas (O3)Dentro de esta actividad se trabaja con la tarea Generar propuestas tecnológicas. La teoría de

pruebas no puede estar ajena a las tendencias tecnológicas, ya que las mismas pueden determinar el

nivel del éxito alcanzado. Las tecnologías más conocidas en el área de pruebas son:

Las herramientas automáticas de pruebas.

Técnicas de pruebas enfocadas a validar tecnologías emergentes.

Outsourcing global de pruebas.

A pesar de que existen muchas propuestas de tecnología aplicada a las pruebas es importante

determinar el costo/beneficio de cada una de ellas. De cualquier manera, éste es un punto que las

organizaciones con experiencia en pruebas deben de considerar, ya que el dominio de una

tecnología emergente por parte de una PyME le daría una ventaja competitiva que sería un

detonante inmediato en su crecimiento dentro del mercado.

II.3 Operación (OPE)Dentro de la categoría Operación, se establecen y ejecutan las actividades enfocadas a lograr los

objetivos de un proyecto específico, de forma sistemática.

Al analizar la categoría desde un enfoque de pruebas, se determinan las actividades a

realizar para asegurar el funcionamiento correcto del producto entregado en cada una de las fases de

desarrollo. Así mismo, aquí se implementa el registro y control de métricas en las ejecuciones con

el fin de tener los datos reales de cada uno de los proyectos. Esto proporciona a la gerencia y a la

alta dirección material sobre cada una de las etapas del desarrollo que le permite la toma de

decisiones correctamente informadas.

Las pruebas a realizar dentro de la categoría Operación se enfocan en los procesos: 1)

Administración de proyectos específicos y 2) Desarrollo y Mantenimiento de Software (figura 5).





Operación

Administración de proyectos

específicos

Planeación

Realización

Desarrollo y mantenimiento de software

Inicio

Cierre

Fase de Requerimientos

Fase de Análisis y

Diseño

Fase de Construcción

Fase de Integración y

Pruebas

Figura 5 - Cobertura de la guía en la categoría de Operación del modelo MoProSoft.

II.3.1 Administración de Proyectos Específicos [OPE.1]Dentro de la Administración de proyectos específicos se encuentra la actividad de Planificación en

la cual se elabora el Plan del proyecto. Además se encuentra la actividad de Cierre que tiene como

objetivo formalizar los acuerdos para poder completar cada fase del proyecto, así como los

indicadores para aprobar la terminación total de éste (ver figura 6).





Planificación

Administración de Proyectos

Específicos

Realización

Evaluación y

Control

Cierre

MoProSoft Actividades Tareas Actividades GPS

A1.4 1. Identificar ciclos y actividades

A1.6 2. Determinar el tiempo estimado para cada actividad

A1.8 3. Conformar el equipo de trabajo

A1. Planificación (O1)

A1.9 4. Generar el calendario de trabajo

A4. Cierre (O1) A4.1 Formalizar la terminación del ciclo y del proyectoFigura 6 - Cobertura de la guía en el proceso de Administración de Proyectos Específicos.

a. Planificación (O1)

La teoría de pruebas dentro del proceso de Administración de proyectos específicos se aplica en lassiguientes tareas: 1) Identificar ciclos y actividades, 2) Determinar el tiempo estimado, 3)

Conformar el equipo de trabajo, y 4) Generar el calendario de trabajo.

1) Identificar ciclos y actividades

Ciclos. El número de ciclos de pruebas se define de acuerdo a los objetivos de la organización y de

las actividades de pruebas que se realicen dentro del proyecto. En la tabla 5 se proponen los ciclos

de prueba, de acuerdo al tipo de prueba.

Tipo de Prueba < de 3 Ciclos 3 a 10 Ciclos Más de 10 Ciclos

Revisión de Documentos Pruebas de Integración de Componentes

Pruebas de Humo

Pruebas de Sistema

Pruebas de Regresión

Pruebas de Aceptación de Usuario

Tabla 5 - Cantidad de ciclos de prueba para los tipos de prueba.





Actividades generales. Son las actividades de pruebas mínimas que deben de ejecutarse en todos

los proyectos con el fin de asegurar que la calidad de los entregables cumple con los estándares de

la organización. Se sugieren las siguientes:

Creación y revisión de documentos de pruebas.

Pruebas de Integración de Componentes.

Pruebas de Aceptación de Usuario. Administración de las actividades de pruebas.

Criterios de aceptación y/o detención.

Estas actividades generales se aplican de acuerdo a las políticas del área de pruebas de la

organización.

Actividades específicas. Son las actividades de pruebas especiales que se requiere ejecutar sólo en

ciertos proyectos, con el objetivo de determinar: los diferentes tipos de pruebas a realizar en el

proyecto, el nivel de revisión/aprobación de documentos, controles de entrada y salida para cada

etapa del proyecto, criterios de aceptación y detención, etc. Algunos ejemplos de este tipo de

actividades son:

Ejecutar una fase de pruebas con los usuarios finales en proyectos de gobierno.

Ejecutar actividades de control de esfuerzos dentro del proyecto.

Realizar una fase de pruebas de conectividad con dispositivos o sistemas externos.

Realizar pruebas de estrés.

Realizar pruebas en los procesos de recuperación de desastres.

Pruebas de hacking ético.

Conforme la empresa adquiera experiencia, es posible mantener la información referente a

todas estas actividades en una base de datos, así como la aportación y las lecciones que se hubiesen

aprendido.

2) Determinar el tiempo estimadoEl tiempo estimado para cada actividad varía de acuerdo a la experiencia de la empresa, el tamaño

del proyecto y los requerimientos específicos de éste. Por lo tanto es muy difícil determinar este

tiempo sin contar con una base de información de proyectos previos.

Es necesario consolidar la información adecuada de los proyectos registrados, de tal manera

que la misma resulte confiable. A medida que la organización gane experiencia, contará con los

datos requeridos para realizar estimaciones acertadas.

3) Conformar el equipo de trabajoEquipo de trabajo. Un equipo de trabajo debe estar organizado con el objeto de cubrir los

objetivos y estrategias de la organización. Puede estar integrado por una o varias personas,

dependiendo del proyecto y de la organización, y puede incluir personal externo. En general, las

PyME no cuentan con personal dedicado exclusivamente a las pruebas. Por lo tanto se deben

asignar los roles dedicados a las mismas entre miembros de la organización, siendo especialmente

importante la participación del responsable del proyecto.





Roles involucrados y capacitación. MoProSoft indica solamente 2 roles para realizar las

actividades de pruebas:

Responsable de pruebas: persona que tiene el conocimiento y/o la experiencia en la

planificación y realización de Pruebas de Integración y de Sistema.

Revisor: persona que tiene el conocimiento en las técnicas de revisión y experiencia en el

desarrollo y mantenimiento del software.

Estos roles son fundamentales, sin embargo dentro de la industria podemos encontrar una

especialización de los mismos, en:

Administrador de pruebas: persona encargada de administrar las pruebas desde un nivel

gerencial. Es decir, valida los planes generales, controla el presupuesto y mantiene la

comunicación entre pruebas y las otras áreas que conforman la empresa.

Analista de pruebas: es un experto en pruebas que conoce y aplica la teoría general de pruebas

en los diferentes proyectos con el objetivo de cumplir con la estrategia de pruebas definida por

la organización.

Diseñador de pruebas: esta persona se encarga de diseñar los diferentes casos de prueba, de

acuerdo a la cobertura que se dará a cada requerimiento. No requiere dominar toda la teoría de

pruebas, ya que se encargará de desarrollar los casos de prueba en los formatos pre-establecidos

y de revisar los casos de prueba creados por otros miembros del equipo. Sin embargo, sí es

recomendable que conozca del negocio y que domine los requerimientos del proyecto.

Tester: es el encargado de ejecutar las pruebas, no necesita conocer el proyecto ni el sistema a

evaluar; simplemente tomará cada caso de prueba y lo ejecutará de manera imparcial, validando

que el resultado obtenido corresponde al resultado esperado.

Adicionalmente existen otros roles con actividades más específicas, aunque son empleados

únicamente cuando los proyectos son muy grandes:

Administrador de datos de pruebas: persona que tiene acceso a las bases de datos de cada

uno de los proyectos de pruebas. Las siguientes actividades son responsabilidad de este rol:

Entregar los insumos (datos) a utilizar en la ejecución.

Configurar las bases de datos para que estén listas para comenzar la ejecución.

Reiniciar los datos a un estado inicial o ejecutar procesos para obtener una

modificación deseada en ellos.

Validar la modificación de los datos de prueba durante la ejecución (si el proyecto lo

requiere).

Administrador de ambientes: es el encargado de administrar el ambiente de pruebas(software) con el objetivo de usar estos recursos de manera eficiente. Entre las actividades que

realiza se encuentran:

Determinar fechas y horarios de ejecución para cada proyecto.

Administrar el acceso a los diferentes ambientes.

Realizar copias de seguridad.

Configurar los ambientes de acuerdo a requerimientos específicos.

Monitorear las interfaces entre ambientes y sistemas.





Administrador de equipos de prueba: encargado de controlar y administrar los diferentes

recursos de pruebas que tiene la empresa. Esto incluye hardware, software, licencias de uso,

tiempos de utilización, etc. Esta persona también es experta en la configuración y puesta a

punto de los equipos, por lo tanto puede brindar un servicio integral asegurándose de dar el

mejor uso a estos recursos. Administrador de requerimientos y cambios: encargado de crear y actualizar la tabla de

requerimientos, utilizando al menos un proceso de control de cambios para realizar cada

movimiento. También entrega reportes de cobertura de requerimientos con las pruebas

ejecutadas.

Administrador de grupos de pruebas: Este rol está enfocado a empresas que tienen distintos

equipos de pruebas trabajando con diferentes proyectos al mismo tiempo, ya sean locales,

nacionales o internacionales. El rol principal es el de asegurarse que los recursos humanos están

asignados de manera eficiente, pudiendo rotar al personal de un proyecto a otro de acuerdo a

sus necesidades.

4) Generar el calendario de trabajo

Calendario. Una vez que se tiene conformado el listado de actividades a desarrollar y el grupo de

personas que participarán en ellas es posible determinar los tiempos aproximados para completar la

fase de pruebas. Conforme el grupo de pruebas de la organización gane experiencia, se podrá

determinar con más precisión el tiempo requerido para cada actividad. Es importante tener presente

algunos factores del mundo de los negocios que pueden influir:

Rotación de personal.

Ventas con tiempos estrechos.

Requerimientos específicos del proyecto.

A pesar de todo, es necesario tener en mente que el calendario de trabajo de pruebas se debe

realizar manteniendo un tiempo suficiente para resolver los posibles problemas que ocurran dentro

del desarrollo de las mismas. Este tiempo debe de ser el justo (no holgado) y puede estar soportado

de un análisis de los riesgos para completar cada actividad. Para asignar los tiempos es necesario

crear una “línea base” para cada actividad, de acuerdo a:

La complejidad.

La cantidad de recursos que se encargarán de realizarla.

Referencias propias o de la industria para desarrollar la actividad.

Determinar variación de la duración de cada actividad, con base en:

La experiencia que cada recurso tiene en esa tarea en específico. La cantidad de veces que se realizará la actividad (a mayor número de ejecuciones,

menor el tiempo destinado a cada ejecución nueva).

Factores externos.

Si no se cuenta con una referencia concreta previa, estos valores pueden estimarse en

conjunto con los encargados de desarrollar las actividades. Es importante registrar los tiempos

utilizados para cada actividad del proyecto con el objeto de generar información que posteriormente





permitirá realizar las estimaciones de una manera rápida y exacta. Para las actividades que

requieren de la ejecución de tareas que no son responsabilidad del grupo de pruebas es necesario

tener acuerdos de tiempos de servicio con las áreas externas involucradas.

En la tabla 6 se presentan algunas estimaciones de tiempos límites requeridos para resolver

problemas, según la importancia de los mismos y la dificultad de la actividad. Por ejemplo, para

una actividad de dificultad “media” y un defecto de importancia “alta” se tendrán como máximo 4horas. Considerando esta información será posible establecer un tiempo base de respuesta.

Baja Media Alta Crítica

Fácil 12 Hrs 4 Hrs 2 Hrs 1 Hr

Medio 24 Hrs 10 Hrs 4 Hrs 2 Hrs

Díficil 36 Hrs 16 Hrs 8 Hrs 6 Hrs

DíficultadImportancia del defecto encontrado

Tabla 6 - Acuerdo de servicio para resolución de defectos.

Una vez determinadas las actividades, será necesario asignar fechas de inicio y fin a cada unacon el fin de generar el Calendario de Trabajo tomando en cuenta los recursos, la secuencia y la

dependencia de las actividades. Es necesario identificar las actividades que se pueden ejecutar de

manera independiente a la fase en la que se encuentren, de tal manera de minimizar los tiempos

muertos. El calendario global del proyecto debe contemplar el tiempo necesario para realizar las

actividades de pruebas, considerando:

Revisión de documentos de las pruebas.

Creación de datos de pruebas.

Resolución de defectos (a cargo del grupo de desarrollo).

Re-ejecuciones de pruebas.

Revisión de la evidencia de las pruebas.

Solicitud de cambios. Cada modificación en las actividades, requerimientos o tiempos del plan

original ocasionan un impacto en las pruebas. Dentro del calendario del proyecto es muy difícil

determinar el impacto ocasionado por un cambio en las actividades. Sin embargo, si todas las

actividades se encuentran correctamente documentadas, cuando ocurra un cambio es posible

administrarlo y planearlo de manera más fácil.

b. Cierre (O1)

La teoría de pruebas apoya en Formalizar la terminación del ciclo y del proyecto dentro de la

actividad de Cierre. Al tener identificados los requerimientos del proyecto es posible implantar

criterios para aprobar el cierre de ciclos y del proyecto. Un criterio muy simple es establecer unporcentaje de requerimientos ejecutados exitosamente (por ejemplo el 90%), o bien la validación

total de ciertos requerimientos críticos para cada ciclo o para el proyecto total.





II.3.2 Desarrollo y Mantenimiento de Software [OPE.2]Las seis actividades MoProSoft de esta categoría se muestran en la figura 7. Las mismas soportan el

ciclo de vida de un proyecto de software. Asimismo, en la figura 7 se presenta un esquema de las

actividades cubiertas por esta guía.

Desarrollo y mantenimiento de Software

Cierre

Análisis y Diseño

Construcción

Integración y Pruebas

Inicio

Requerimientos

MoProSoft

Actividades Tareas Actividades GPS

A2.2 1. Documentar o modificar la Especificación deRequerimientos

A2.3 2. Verificar la Especificación de Requerimientos

A2.7 3. Elaborar o modificar Plan de Pruebas de Sistema

A2. Realización de la fasede Requerimientos (O1,O3)

NI 4. Pruebas de Aceptación A3.2 1. Generar la descripción de la estructura interna del

sistema y del registro de rastreoA3. Realización de la fasede Análisis y Diseño (O1,O3) A3.7 2. Elaborar o modificar Plan de Pruebas de Integración

A4. Realización de la fasede Construcción (O1, O3)

A4.2 Definir y aplicar pruebas unitarias a los componentes

NI 1. Definir y crear Casos y Escenarios de PruebasCreación de los casos de

prueba ( NI) NI 2. Crear datos de pruebasA5.2 1. Realizar integración y pruebas

A5.6 2. Realizar las Pruebas de Sistema

A5. Realización de la fasede Integración y Pruebas(O1, O3) NI 3. Realizar las Pruebas de Aceptación

NI 1. Decisión de finalización del proyectoA6. Realización de la fasede Cierre (O2) A6.1 2. Manual de mantenimiento

Figura 7 - Cobertura de la guía en el proceso de Desarrollo y Mantenimiento de software.





a. Realización de la fase de Requerimientos

La teoría de pruebas apoya las siguientes tareas de la actividad Realización de la fase de

Requerimientos en el proceso de Desarrollo y Mantenimiento de Software: 1) Documentar o

modificar la especificación de requerimientos, 2) Verificar la especificación de requerimientos y 3)Elaborar o modificar plan de pruebas de sistema.

1) Documentar o modificar la especificación de requerimientos

La especificación de requerimientos es un documento formal donde se listan todas las

funcionalidades que debe contar el sistema una vez liberado. Este documento debe ser realizado por

el analista, el cliente, el usuario y el diseñador de las interfaces. MoProSoft señala que los

requerimientos se dividen en las siguientes categorías:

Funcionales

Interfaz de Usuario

Interfaces externas Confiabilidad

Eficiencia

Mantenimiento

Existen otras categorizaciones por lo que se recomienda que el grupo de pruebas y los

responsables de los requerimientos sigan una misma tipificación.

2) Verificar la especificación de requerimientos

Una vez que se tiene la especificación de requerimientos, podemos realizar la verificación de la

misma mediante las siguientes actividades:

Identificación única de todos los requerimientos del proyecto.

Realizar una revisión de los requerimientos (pruebas estáticas).

Identificación única de todos los requerimientos del proyecto. Debido a que se pretende realizar

revisiones de todos los requerimientos, es importante contar con un identificador único para:

Mantener un panorama completo del total de los requerimientos del proyecto, así como de su

severidad y de los datos relevantes de cada uno de ellos.

Facilitar la administración de las actividades relacionadas a los tipos de pruebas aplicados a

cada uno.

Soportar la tarea de asegurarse de que todos los requerimientos contienen alguna validación

asociada (cobertura total).

Tener una base de requerimientos única y administrada para facilitar las tareas de fases

posteriores del proyecto.

Para lograr una identificación eficiente se pueden seguir los siguientes pasos:





1. Agrupar los requerimientos a alto nivel, de acuerdo al área del negocio a la que pertenecen o al

módulo del sistema en caso de que sólo aplique a un área. A cada grupo se le asigna un

identificador que represente el nombre del grupo, el cual se recomienda que se componga de 2 o

3 letras, por ejemplo: “CM ” (Compras), “VT ” (Ventas),”GG” (Gerencia General), etc.

2. Asignar un número único a cada requerimiento, dentro de cada grupo. La forma más usada es

utilizando una numeración secuencial, este número debe ser precedido del identificador delgrupo, por ejemplo: “VT.0030”. Es importante asegurarse de tener una cantidad adecuada de

dígitos para cubrir todos los posibles requerimientos que se encuentran dentro del módulo. En la

tabla 7 se presenta un ejemplo.

Realizar una revisión de los requerimientos (pruebas estáticas). El objetivo de esta revisión es

validar que 1) El requerimiento cumple con lo que la organización requiere y 2) Los requerimientos

están redactados claramente.

#

Negocio

Descripción

Negocio

#

Consecutivo

#

RequerimientoDescripción Requerimiento Comentarios

GN General 0001 GN.0001

Usar la imagen de la empresa en todas laspantallas.

Todas las pantallas deben contener el logo y loscolores de la empresa


El sistema debe mostrar una pantalla de arranqueindicando versión, fecha de creación y nombreslegales del sistema y de la empresa.

Los nombres se pueden obtener del area de Legaen el documento "Nombre y Marcas Legales.doc"


Se deben de manejar 3 níveles de usuario, cadanivel contiene un determinado número de módulos

que se mostrarán.

Nivel 1: Administrador: Se muestran todos losmenús del sistema.Nivel 2: Ventas: Se muestran los módulos de veny los de consulta del sistema.

Nivel 3: Compras: Se muestran los módulos deCompras y los de consulta del sistema.


El sistema debe de soportar los siguientes sistemas

operativos: Windows 98, Windows 2000, WindowsXP, Windows Vista.

No se creará el sistema para soporte a sistemasoperativos Mac ni Linux.

VT Ventas 001 VT.001

Cada venta debe contener la siguiente información:

Empleado, Cliente, RFC Cliente, Monto total, Tipode pago, Referencia de pago, Fecha de pedido,

Fecha de entrega, Lista de productos y Número defactura.

El número de factura electrónico debe ser similarnúmero de factura impreso en el papel.

Tabla 7 – Ejemplo de listado de requerimientos

1) El requerimiento cumple con lo que la organización requiere. Consiste en validar que los

requerimientos representan todo lo que la organización desea para el proyecto. Elementos a tener en

cuenta:

Contenido

Los requerimientos cumplen con los objetivos del proyecto.

Se encuentran documentados todos los requerimientos requeridos para cumplir con

estos objetivos (diseño completo).

Los requerimientos no se repiten, son independientes y únicos.

La definición de pantallas está documentada.

Si existen, los dispositivos especiales se encuentran documentados.

Capacidad

Los tiempos definidos para las actividades son suficientes.

Se tiene la capacidad tecnológica para cumplir con los requerimientos.

Son costeables.

Los requerimientos son factibles (por ejemplo, incrementar la capacidad de tomar

órdenes en un 20% con la misma base de personal).





Negocio

Se encuentran alineados con los objetivos de la organización.

Se están aplicando todas las actividades definidas en el plan de pruebas.

Las características del proyecto no entran en conflicto con otros productos del mercado.

Cualquier asunto legal involucrado se encuentra definido. El producto final expresa lo que el cliente desea.

Debido a que las revisiones son requeridas por varios niveles de la organización, es difícil

reunir a todas las personas involucradas, para esto existen técnicas que apoyan estas tareas, entre las

que se encuentran:

Pares: es una revisión informal donde el autor del documento lo entrega a un compañero para

que realice observaciones y sugerencias antes de pasarlo a una revisión o a una entrega formal.

Grupales: como su nombre lo indica, es una revisión de las personas involucradas en el

desarrollo de los requerimientos, generalmente se enfocan sólo a la parte del negocio. Estas

pruebas se realizan en una reunión en tiempo real, ya sea presencial o soportada por alguna delas tecnologías actuales de telecomunicación.

Guiadas: el autor envía el documento (o secciones de éste) a varias personas que pueden

realizar la evaluación. Así, el autor puede guiar de manera directa el criterio que tomará cada

persona para realizar la revisión. La retroalimentación se da de manera escrita pero informal. El

propio autor es el encargado de actualizar el documento con base en los comentarios recibidos.

Reuniones formales: es una reunión donde se exponen todos los temas relacionados con el

área de dominio del personal que asiste a ella. Se crea una minuta de cada reunión, con firma de

acuerdo de cada asistente, con el fin de dejar en evidencia lo acordado y que al final de todas las

reuniones se pueda integrar un documento global aprobado por las áreas. Se pueden realizar

diferentes reuniones formales de revisión, de acuerdo a los temas, el enfoque general del

proyecto, con el cliente, etc.

Documentos guía: se envían los requerimientos a un grupo de revisores con el objeto de que

cada uno registre sus observaciones y correcciones dentro de un documento de control formal

que contiene reglas específicas para su llenado. Este documento es el más difícil de completar

pero es también aquel que nos proporciona la mayor cantidad de información relacionada a las

pruebas estáticas.

Técnicas: realizadas por personal con buenas habilidades técnicas. Sirve para determinar la

factibilidad del proyecto, los requerimientos técnicos de cada uno de los objetivos, las

especificaciones de diseño y las herramientas a utilizar, entre otros.

Gerenciales: el objetivo es reunir a los diferentes encargados de las áreas del proyecto

(incluyendo al cliente como encargado final), con el fin de llegar a un entendimiento en losasuntos que relacionen a 2 o más áreas. Por ejemplo, el área legal con la de diseño gráfico o

contabilidad con programación. Para estas reuniones se recomienda tener una agenda con temas

puntuales donde se requiera llegar a un acuerdo de ambas partes, con el objeto de no alargar las

revisiones y poder finalizar las negociaciones de una manera eficaz.





Con todas estas validaciones se pretende llegar a un acuerdo para aprobar la especificación de

requerimientos obteniendo un documento robusto que incluye la conjunción de los puntos de vista

de todas las áreas involucradas.

2) Los requerimientos están redactados claramente. La segunda parte de la revisión de

requerimientos se centra en la redacción de los mismos, mediante la aplicación de las técnicas de

revisión grupales. Esta validación intenta asegurar que los requerimientos cumplen con las

siguientes características:

Requerimientos escritos en un lenguaje entendible por todos los involucrados de la

organización.

Todos los términos están claramente definidos.

Todas las sentencias tienen inicio y fin.

Los requerimientos son cuantificables.

No existen elementos inconclusos o ambiguos dentro de los requerimientos.

Al finalizar con estas 2 actividades, se debe de tener como producto final:

El listado de requerimientos completo, donde se tiene identificado de manera única el área a la

que pertenece cada requerimiento.

Los documentos que muestran los defectos de las revisiones formales de los requerimientos.

3) Elaborar o modificar plan de pruebas de sistema

Plan de Pruebas. Un plan de pruebas de sistema es un documento formal que incluye un listado de

las actividades de pruebas a ejecutarse posterior a la entrega del software por parte del área de

desarrollo. Es recomendable que desde el inicio se asignen tiempos aproximados para dimensionar

la duración total de las pruebas y aunque este tiempo se irá modificando conforme se realicen las

revisiones y se avance en el proyecto, la primer estimación es útil porque servirá de base para

realizar los cálculos y planeación inicial.

Dentro de la planeación de la PyME, suele verse a la fase de Pruebas de sistema como un

gran bloque con fechas de inicio y fin, sin embargo, este plan debe de desglosarse al menos en las

actividades complementarias, con el fin de determinar el alcance y cobertura y por tanto el grado de

confiabilidad de las pruebas. Algunas actividades a considerar dentro de un plan de pruebas de

sistema son las siguientes:

Pruebas estáticas. Estas pruebas se pueden desarrollar en conjunto con la revisión de los

requerimientos, dejando los puntos pendientes como una actividad de cierre de pruebas estáticas

dentro del plan general.

Administración de las pruebas. Es una actividad que abarca todas las fases de las pruebas, es

importante debido a los recursos que ésta consume, así como los tiempos destinados a revisiones,

reuniones y toma de decisiones.

Condiciones y escenarios de prueba. La identificación de estas actividades se realiza para soportar

el diseño de los casos de prueba.

Las condiciones determinan todas aquellas funciones que el sistema necesita realizar para poder

considerarlo completo.





Los escenarios identifican la cobertura que es necesario alcanzar de acuerdo a la estrategia de

pruebas definida en la estrategia general de la empresa para el tipo de proyecto a realizar.

Creación de casos de prueba. Es el periodo determinado para analizar, diseñar y construir los casos

de prueba que serán ejecutados dentro de esta fase de pruebas. Es posible incluirlo como una

actividad macro o dividirlo por módulos, tipo de prueba o funcionalidad del sistema.

Revisión de los casos de prueba. Esta es una actividad que va a la par con la creación de los casos

de prueba. Sin embargo, dependiendo de los requerimientos, es posible definirla como una actividad

individual. Un ejemplo claro de esto es cuando se desarrollan casos de prueba que tienen que ser

autorizados por un área ajena a la ejecución de éstos, tal como contabilidad o finanzas.

Creación y carga de datos de prueba. Es el tiempo destinado para comprobar, migrar o agregar datos

en el sistema, tales como: configuración de cuentas, accesos, pedidos previos, cargas de datos

reales, etc. También se debe contemplar el tiempo adecuado para realizar una revisión de los

mismos.

Plan de ejecución de las pruebas. Dentro de esta actividad se diseñan una o varias secuencias de laejecución de las pruebas planeadas. Cada secuencia debe de tener por objetivo dar prioridad a un

tipo de cobertura. Consecuentemente, se pueden crear varios caminos alternos para el caso de tener

problemas con la entrega del sistema final.

Ejecución de las pruebas. Es el tiempo determinado para llevar a cabo la ejecución de todos los

casos de prueba dentro de cada una de las fases del sistema, incluyendo el porcentaje de re-

ejecuciones esperadas y el número de ciclos que realizarán dentro de cada fase. El tiempo de re-

ejecuciones generalmente se determina por experiencia, aunque una cifra usada de manera estándar

en la industria es el 30% del tiempo normal.

Resolución de defectos. Para determinar el tiempo adecuado para la resolución de defectos se debeconsultar con el área de sistemas. Una forma sencilla de determinar este tiempo para el caso de que

no se tenga experiencia previa es el siguiente: considere un proyecto de 100 requerimientos, donde

aproximadamente se tiene un 30% de defectos (re-ejecuciones). Se puede determinar el tiempo

usando una curva exponencial de acuerdo a la severidad de resolución de cada defecto, como se

muestra en la tabla 8.

Baja Media Alta

Cantidad de Defectos 18 9 3Tiempo de Resolución 4 10 24

Tiempo Total (Hrs) 72 90 72

234Horas requeridas para resolver los defectos

100 Requerimientos Defectos por Severidad

Tabla 8 - Tiempo aproximado para resolución de defectos en un proyecto de 100 requerimientos.

De acuerdo a las características del proyecto y la capacidad del área de desarrollo es posible

prescindir de un tiempo exclusivo para la resolución de defectos, pero esto ocurre sólo en el caso de





que se pueda realizar la actividad a la par de la ejecución de otros casos de prueba. Entonces esta

actividad sería complementaria a la ejecución total.

En el caso de que el tamaño del proyecto, o la duración de los ciclos de pruebas sean cortos

(menor a 2 semanas), es sumamente recomendable agregar el tiempo de resolución de defectos

como una actividad crítica dentro del plan del proyecto. Esto con el fin de dar tiempo al equipo de

desarrollo para la resolución de alguna contingencia.

Revisión de resultados y aprobación de las pruebas. También es importante agregar un tiempo

determinado para realizar una revisión detallada de los resultados de la ejecución de las pruebas,

para que de esta manera se pueda garantizar que los resultados obtenidos son correctos y se

encuentran correctamente documentadas. Aquí se puede tomar la decisión de realizar una reunión

de revisión de cierre de fase de pruebas, donde se acepte que los criterios de salida de la fase se han

cubierto de manera satisfactoria.

Otras actividades. Adicionalmente a cada actividad se puede agregar un listado de recursos a

utilizar, así como los responsables por el cumplimiento de cada una de ellas.

Pruebas de aceptación. Si el sistema lo amerita, será necesario obtener una acreditación del

usuario mediante las pruebas de aceptación de usuario. Estas pruebas no se encuentran en el modelo

MoProSoft, sin embargo son útiles porque se enfocan en validar el sistema desde el punto de vista

del negocio (o del usuario final), ejecutando todas las transacciones necesarias para simular un día

normal de operación. Generalmente, las pruebas de aceptación se basan en las pruebas de sistema,

siendo una simplificación de éstas, debido a que se valida la misma funcionalidad pero desde la

perspectiva del negocio.

Al momento de asignar tiempos a las actividades de esta fase, se debe recordar que serán

ejecutadas por los usuarios finales, quienes no tienen un contexto específico de las pruebas y las

realizarán desde el punto de vista operacional. Existen otras tareas que se pueden realizar dentro de

esta fase, tales como:

Comprensión y modificación de casos de prueba de sistema. Se pueden modificar casos de

prueba para ajustarlos al enfoque de las pruebas de aceptación de usuario.

Actividades de acondicionamiento del ambiente. Existen algunas actividades requeridas para

acercar el ambiente de las pruebas a la realidad de producción, tales como: carga de archivos

externos, encriptación y carga de datos de producción, modificación de fechas de sistema

durante las ejecuciones, etc.

Administración de datos de prueba macro. De acuerdo al sistema, es probable que requiera de

un tiempo determinado para administrar datos que son afectados dentro de los diferentes

escenarios de prueba ejecutados, tales como: archivos contables, reportes finales, consultas

mensuales, etc.

b. Realización de la fase de Análisis y Diseño

Dentro de la actividad Realización de la fase de análisis y diseño, las pruebas se aplican en las

siguientes tareas: 1) Generar la descripción de la estructura interna del sistema y del registro de

rastreo y 2) Elaborar o modificar el plan de pruebas de integración.

1) Generar la descripción de la estructura interna del sistema y del registro de rastreo





Descripción de la estructura interna del sistema. Las pruebas pueden ayudar a alcanzar 2

objetivos: 1) Identificación única del desglose de requerimientos del proyecto y 2) Realizar una

revisión del desglose de requerimientos.

1. Identificación única del desglose de requerimientos del proyecto. Es necesario asegurarse en

continuar con la nomenclatura anterior, agregando un sub-número en cada nuevo requerimiento

desglosado. En la tabla 9 se presentan algunos ejemplos.

# Requerimiento Descripción Requerimiento

#

Sub-

Requerimiento

Desglose del requerimiento

(Estructura interna)

GN.0001.001

Existirá un objeto "Layout" que contendrá los logos y los

colores de la empresa.

GN.0001.002

Todas las pantallas podrán utilizar el objeto "Layout

Empresa" para heredar sus características.

GN.0002

El sistema debe mostrar una pantalla de

arranque indicando versión, fecha de creación y

nombres legales del sistema y de la empresa. GN.0002.001

Creación de un objeto "Pantalla" que desaparezca

después de cierto tiempo, además contenga la facilidad

de parametrizar sus componentes.

GN.0003.001

Crear un menú de nivel 1 que corresponda al de

Administrador.

GN.0003.002 Crear un menú de nivel 2 para Ventas.

GN.0003.003 Crear un menú de nivel 3 para Compras.

GN.0003.004Crear una pantalla de firma digital para seleccionar el

menú a aplicar.

GN.0001

GN.0003

Se deben de manejar 3 níveles de usuario, cada

nivel contiene un determinado número de

módulos que se mostrarán.

Usar la imagen de la empresa en todas las

pantallas.

Tabla 9 - Desglose de requerimientos del proyecto.

2. Realizar una revisión del desglose de requerimientos. Es una tarea sencilla si se mantiene la

nomenclatura original en la especificación de requerimientos, bastando con agregar una marca de

“desglosado” en cada renglón en el que se encuentra realizada la descripción de la funcionalidad

interna.

Registro de rastreo. El registro de rastreo es una herramienta que contiene todos los

requerimientos y todos los casos de prueba indicando una relación “1 a 1” o “1 a varios”, y será

muy útil tanto para la administración de la ejecución de las pruebas como para determinar la

cobertura que tiene cada caso o escenario de pruebas. El insumo principal del registro de rastreo es

la especificación de requerimientos en el nivel desglosado. Posteriormente será necesario agregar

los tipos de pruebas que se realizarán según las siguientes fases del proyecto. En esta fase del

proyecto no será posible indicar la relación entre casos de prueba y requerimientos, pero se podrá

actualizar conforme se desarrollen las siguientes etapas. En la tabla 10 se presenta un ejemplo.





Matriz de Rastreo V. 002 Actualizado: 04-ene-08

# Requerimiento#

Sub-RequerimientoCaso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6

GN.0001.001

GN.0001.002

GN.0002 GN.0002.001

GN.0003.001

GN.0003.002

GN.0003.003

GN.0003.004

GN.0004.001

GN.0004.002

GN.0004.003

Casos de prueba

GN.0004

Listado de Requerimientos

GN.0001

GN.0003

Tabla 10 - Ejemplo de registro de rastreo.

2) Elaborar o modificar plan de pruebas de integración

Plan de pruebas de integración. El plan de pruebas de integración contiene un desglose detallado

de todas las actividades de pruebas a realizar durante la construcción del código nuevo (o

modificado), enfocándose en los requerimientos desde un punto de vista técnico. Se debe de validar

principalmente:

La interacción entre los diferentes módulos que componen al sistema.

La interacción con sistemas externos que soportan o reciben la información que es procesada en

el software evaluado.

El adecuado uso de las interfaces externas del sistema, incluyendo impresoras, lectoras,

terminales portátiles, pantallas, etc.

El manejo de errores en todas las transacciones validadas.

Las actividades incluidas en esta fase deben de soportar la ejecución de las pruebas en un bajo

nivel. Es decir, se deben incluir (entre otras) las siguientes:

Entendimiento del diseño interno del sistema, ya que será la base del diseño de los escenarios.

La validación de los ambientes donde se realizarán las pruebas.

La administración de las versiones de cada pieza mediante un control estricto de cambios.

La creación de escenarios de prueba donde se muestren las relaciones entre los componentes y

su prioridad hacia los requerimientos más críticos del sistema, incluyendo el diseño de los casos

para el manejo de errores.

El desarrollo de componentes adicionales que simulen las interfaces entre el sistema

desarrollado o modificado y otros sistemas.

La implantación de controles de seguridad para ejecutar las pruebas, esto debido a que el tester

tendrá a disposición código que puede ser modificado accidentalmente.

Configuración de equipos externos, incluyendo tiempos de entrega, cotizaciones, etc.





Resolución de defectos.

De ser posible, crear un plan de entrega de módulos programados (o modificados), con el fin de

hacer eficiente la ejecución de las pruebas.

Validación de resultados y aceptación del cumplimiento de la fase.

De acuerdo al perfil que tengan los testers, esta fase puede ser responsabilidad del grupo deprogramadores. Sin embargo, es necesaria la validación de las evidencias de la realización exitosa

de las pruebas y por tanto del cumplimiento de los criterios de salida de la fase.

Para determinar los tiempos y la importancia que se dará a cada requerimiento será necesario

asignar prioridades a cada actividad, de acuerdo a los criterios establecidos en la estrategia de

pruebas y a factores como:

El riesgo potencial considerando el área del negocio a la que pertenece.

Su importancia.

El costo de permitir la aparición de defectos en producción.

Tamaño del requerimiento.

Requerimientos regulatorios gubernamentales.

La funcionalidad.

Uso de tecnologías especiales y su grado de dominio (WiMax, GPS, triple play, etc.)

Especificaciones de rendimiento del software (disponibilidad, capacidad de carga, etc.).

Conocimiento de la industria a la que se destinará el software.

Una vez que se han asignado las prioridades, los requerimientos deben ser agrupados de

acuerdo a las categorías pactadas en la especificación de requerimientos. De esta manera, se forman

grupos de ejecuciones que permitirán tener flexibilidad en la ejecución de las pruebas y poder

cambiar el enfoque de éstas de acuerdo a los resultados obtenidos día a día.

c. Realización de la fase de Construcción

Durante la fase de construcción se deben de desarrollar las pruebas unitarias de los componentes.

Definir y aplicar pruebas unitarias de los componentesEl objetivo de estas pruebas es que el programador valide la funcionalidad de cada componente o

módulo programado de manera individual, tanto para casos correctos como para casos de error, con

el objeto de validar la capacidad de los componentes para soportar las fallas. Debido a la naturaleza

de estas pruebas, es difícil lograr evidencia concreta de cada ejecución, sin embargo es posible usar

alguna de las siguientes técnicas para administrar el trabajo de una manera adecuada:

1. Control de versionesComo se ha mencionado anteriormente, una administración adecuada de las versiones permite

mejorar el código de manera incremental, evitando duplicar errores que ya se habían corregido con

anterioridad o programar con versiones defectuosas. Un control de versiones se puede administrar

de forma sencilla, por ejemplo como en la tabla 11.





Fecha Versión actual Nombre de componente Dueño de versión

01/12/2007 0.00023 Manejador de impresora Matriz de Puntos Carmen Jímenez

02/12/2007 0.00003 Manejador de impresora ticket Carmen Jímenez

01/12/2007 0.00001 Conectividad con Sistema "e-Gobierno" Erasmo Torres

04/12/2007 0.00008 Exportador de Consultas SQL a txt William Whiteriver

01/12/2007 0.00002 Registro de Logs de transacciones William Whiteriver

30/11/2007 0.00001 Validador de Login de Usuario William Whiteriver

Tabla 11 – Ejemplo de control de versiones.

Si la madurez de los procesos y del grupo de pruebas es avanzada, a esta tabla se le puede

agregar información adicional, tal como: comentarios, estado actual de la pieza, localización física,

complejidad, etc.

2. Registros de pruebas exploratorias

Es un documento donde se guardan los resultados de las pruebas realizadas, así como la versión del

componente que se está validando. Ayuda a tener un registro de los defectos encontrados durante lafase de programación de una manera rápida y fácil de usar. Un ejemplo de un registro de pruebas

exploratorias se muestra en la tabla 12.

Ejecución Versión Fecha Pieza Resultado obtenido

1 0.00001 21/11/2007

Exportador de consultas SQL a archivo de

Texto.

1. No se ha logrado parametrizar la ruta de manera

adecuada.

2 0.00002 23/11/2007

Exportador de consultas SQL a archivo de

Texto.

1. Ya se logró parametrizar la ruta.

2. El archivo está convirtiendo la consulta esperada.

3 0.00001 23/11/2007 Administrador de impresora laser tipo ticket.

1. La impresión se realiza de manera correcta.

2. Se requiere enviar el control de corte de página al

impresor.

4 0.00002 25/11/2007 Administrador de impresora laser tipo ticket.

1. El corte de página del impresor se realiza de la

manera adecuada.

5 0.00003 25/11/2007 Administrador de impresora laser tipo ticket. 1. La impresora no se reestablece después de que elsistema entra en hibernación.

Tabla 12 – Ejemplo de registro de pruebas exploratorias.

d. Creación de los casos de prueba

Esta es una tarea que no está contemplada dentro del modelo MoProSoft, sin embargo en la teoría

de pruebas es esencial que se realice de manera previa a la ejecución de cualquiera de los tipos de

pruebas. Las tareas que conforman esta actividad son las siguientes: 1) Definir y crear casos y

escenarios de prueba y 2) Crear los datos para pruebas.

1) Definir y crear casos y escenarios de prueba

El objetivo de crear los casos y escenarios de pruebas es documentar las acciones que se realizan alejecutar cada prueba. Los casos de prueba se deben ejecutar de acuerdo al nivel de pruebas que se

necesite; es decir: integración, sistemas y aceptación de usuario. Adicionalmente, actualizando el

registro de rastreo se puede mantener un control de pruebas para documentar el avance de éstas, así

como guardar evidencia de la realización de las mismas.

Casos de pruebas de integración. Los casos de prueba en esta fase se diseñan de una manera no

abstracta (pruebas de caja blanca). Se enfocan en la funcionalidad interna esperada de las distintas





piezas del software operando de manera conjunta pero desde la perspectiva del programador. La

funcionalidad se debe encontrar previamente documentada en la Realización de la fase de Análisis y

Diseño, donde se desglosó cada requerimiento en específico.

Debido a que las pruebas de integración son realizadas por los desarrolladores, es difícil crear

un caso de prueba dentro de un documento adicional, sin embargo en la ejecución será

indispensable actualizar el registro de rastreo con las diversas pruebas ejecutadas dentro de estafase.

Casos de pruebas de sistema. Los casos de pruebas de sistema validan que la operación de los

diferentes componentes del mismo cumplan con las condiciones y los requerimientos funcionales

del sistema, sin entrar en el detalle de la operación individual de cada uno de ellos (pruebas de caja

negra). El desarrollo de estos casos de prueba se realiza desde el punto de vista de la funcionalidad

técnica del sistema. Algunas validaciones comunes son:

Botones

El botón realiza las acciones señaladas en el diseño funcional como cerrar la pantalla, abrir un

reporte, etc.

El botón cumple con el comportamiento especificado para cada uno de sus estados, por

ejemplo: en reposo, al presionarlo, cuando el cursor se encuentra sobre el botón, al

arrastrarlo, etc.

El tamaño, color y fuente del texto de los botones es el indicado.

El ícono o figura para cada estado del botón son los definidos.

Campos de texto

El campo acepta un número mínimo y máximo de caracteres.

El campo contiene una máscara predeterminada para el ingreso de datos.

El campo sólo acepta cierto tipo de caracteres.

El campo se llena automáticamente cuando cierta condición sucede. El tamaño, color y fuente del campo son los indicados.

Funcionalidad al poner el cursor sobre el campo de texto (por ejemplo, globos de texto de

ayuda).

Iconos e imágenes

El tamaño de la figura varía de acuerdo al tamaño de la pantalla.

Al dar clic sobre la figura ocurre una acción esperada.

El tamaño, color y posición de la figura son los adecuados.

La figura cambia de acuerdo al contenido de un archivo.

Filtros

El filtro actúa sobre una lista adyacente o en un reporte solamente con las condiciones

seleccionadas.

El filtro contiene las opciones de filtrado obtenidas de una tabla en la base de datos.

El filtro muestra las opciones de acuerdo a un orden especificado o a otro pre-filtrado.

Menús





Se despliegan los menús tal como lo indica el diseño funcional.

Cada opción del menú realiza la acción especificada.

Se despliega el menú adecuado al perfil de usuario que ha ingresado al sistema.

El color, tamaño y tipo de fuente de los menús son los indicados.

Pantallas

El tamaño, color, fuente y atributos estéticos de la pantalla son los adecuados.

La pantalla se muestra siempre en primer plano.

Al cambiar de tamaño, los objetos de la pantalla se ajustan.

Al no estar activa (o al minimizar) se realiza una acción determinada.

Reportes

El reporte impreso contiene la misma información que el mostrado en pantalla.

El reporte está correctamente configurado, en cuanto a colores, tipo de letra y espacio

disponible para la información contenida en éste.

El tamaño del reporte satisface los requerimientos físicos del papel a emplear en su

impresión.

Los objetos requeridos por los reportes son automáticamente cargados por el sistema, de

acuerdo a los requerimientos.

Funcionalidad

Aquí las pruebas se enfocan en que la funcionalidad individual de cada módulo entregue el

resultado de acuerdo al proceso documentado en el diseño funcional del proyecto. Por

ejemplo, la generación de reportes de acuerdo a la opción seleccionada en la pantalla, la

impresión de recibos de acuerdo a una venta realizada, etc.

Una vez que se ha determinado las diferentes validaciones del caso de prueba, éste sedocumenta en un archivo individual y consta al menos de los siguientes datos:

Nombre único. Objetivo. Acciones a ejecutar. Acciones esperadas que realice el sistema. Número de requerimiento al que está direccionado. Versión del caso de prueba.

Desarrollo del caso de acuerdo al grado de madurez del área.

Como punto inicial un caso de prueba puede contener únicamente la descripción de la validación

para la que está creado, así como (de forma genérica) las acciones a realizar y los resultadosesperados para dichas acciones. Los siguientes ejemplos muestran casos de prueba simples donde se

valida la funcionalidad de una pantalla, de un menú y de un botón respectivamente.





Id Req:

GN.0002 CP.0001.func.: Verificar pantalla de arranque Fecha de Creación: 01/12/2007

Versión:

0001

Paso Accion Resultado Esperado

1 Abra el sistema, capture una imagen a la pantallaflash para validar la imagen y textos de la pantalla,

así como el tiempo que tarda la pantalla en

desaparecer.

La pantalla contiene el logo y el nombre de la empresa, el

nombre del módulo abierto y el usuario registrado en lalicencia.

Cuando la pantalla flash desaparece, se muestra la pantalla

de acceso al sistema, solicitando usuario y password.

Objetivo:

Verificar que al arrancar el sistema se muestre la pantalla de "flash", donde muestre el logo, y nombre de la empresa,

así como el módulo y los datos del usuario registrado.

Tabla 13 - Caso de prueba para validar una “Pantalla”.

Id Req:

GN.0003

CP.0002.func.: Verificar menú de administrador alingresar al sistema. Fecha de Creación: 01/12/2007

Versión:

0001


1 Ingrese al sistema con un usuario del tipo

Administrador.

La pantalla muestra después del logín correcto el menú

general, con todas las opciones habilitadas, así como elsubmenú "Administrador" también con todas las opciones

habilitadas.

Objetivo:Verificar que al ingresar al sistema con un usuario de tipo "administrador" se muestra el menú del "administrador".

Tabla 14 - Caso de prueba para validar un “Menú” de acuerdo al tipo de acceso.

Id Req: GN.0003

CP.0030.func.: Verificar botón de exportar una

cotización. Fecha de Creación: 04/12/2007

Versión:

0001


1

Ingrese al sistema con un usuario del tipo Operador

de Ventas, realice el alta de una cotización y valide

las acciones del botón "Exportar".

Dentro de la pantalla "Alta de Cotizacion", el botón "Exportar"

presenta las siguientes características:

1. El botón es color blanco, contiene el ícono "Exportar.ico", y

el texto "Exportar", así como el tooltip "Realiza una

exportación de la cotización actual a otro sistema".

2. Al presionar el botón, el sistema envía una pantalla con las

opciones "Microsoft Excel" y "Texto".

Objetivo:

Validar que el botón "Exportar" funciona adecuadamente dentro de la pantalla "Cotización".

Tabla 15 - Caso de prueba para validar un “Botón”.

El formato de casos de prueba usado en los ejemplos se puede adaptar a cualquier tipo de

validación que la empresa desee realizar, y una de las ventajas de aplicarlo es que en cualquiera de

los casos es posible identificar los elementos más importantes: objetivo, acción y resultado

esperado. En la figura 8 se presentan y explican estos elementos para el ejemplo de la tabla 13.



GP S

- G u ar d a t i &

P on c e

3 7

F i g ur a 8 - C om p on e

n t e s d e un c a s o d e pr u e b a .

S i l a e m pr e s a c u e n t a c on un gr u p o d e pr u e b a s c on e x p e r i e n c i a , e n t on c e s d e b e d e c r e a r l o s

c a s o s e s p e c i f i c a n d ol a s a c c i on e s d e m a n e r a m

á s a m pl i a y d o c um e n t a r e l r e s ul t a d o e s p e r a d o p a r a

c a d a un a d e

e l l a s . Un c a s o d e pr u e b a “ a v a nz a d o” d e b e c on t e n e r l a i nf or m a c i ó n s uf i c i e n t e p a r a q u e

p u e d a s e r e j e c u t a d o p or un a p e r s on a q u e n o c on o c e e l s i s t e m a , p or e j e m pl o e l

d e l a t a b l a 1 5 .E l

ni v e l d e d e t a l l e e s p e c i f i c a d o d e n t r o d e un c a s o

d e pr u e b a t a m b i é n v a r í a e nr e l a c i ó n a o t r o s f a c t or e s ,

t a l e s c om o :

L a i m

p or t a n c i a d e l r e q u e r i mi e n t o y c on d

i c i on e s a v a l i d a r .

E l t i e m p o e s p e c i f i c a d o p a r a d e s a r r ol l a r l o s c a s o s d e pr u e b a .

Id Req: GN.0002 CP.0001.func.: Verificar pantalla de arranque

Versión:

0001

Paso Accion

1Abra el sistema, capture una imagen a la pantalla flash para validar la

imagen y textos de la pantalla, así como el tiempo que tarda la pantalla

en desaparecer.

La

m

C

a

Objetivo:

Verificar que al arrancar el sistema se muestre la pantalla de "flash", dond

datos del usuario registrado.

Número de requerimiento al que pertenece el caso

Nombre único que servirá como identificador del caso

Número y descripción de las acciones del caso de prueba

Versión del caso que fue aprobada como final





Casos de pruebas de aceptación. Estas pruebas generalmente son realizadas por el usuario final

del sistema y se llaman de “aceptación” porque es éste quien da el visto bueno de que el sistema

funciona de la manera esperada. Las pruebas de aceptación tienen como objetivo demostrar que el

sistema funciona como “un todo”, de la manera esperada una vez puesto en producción. Por lo

tanto, estas pruebas se desarrollan validando toda la funcionalidad de un ciclo de operación normal

sin detenerse en cada pieza del software (pruebas de caja negra). Estos casos de prueba pueden serrealizados por los expertos de negocio o por la gente que ha estado encargada de las fases previas de

prueba.

Algunas de las pruebas de sistemas se pueden modificar para convertirse en pruebas de

aceptación, especialmente aquellas usadas para validar alguna funcionalidad del software

importante para el negocio. Por ejemplo: ingresar tarjetas de crédito, capturar números de cliente,

realizar búsquedas especializadas, etc. Estas pruebas tienen que estar completamente ligadas a los

requerimientos funcionales del sistema aunque sin excluir otro tipo de validaciones adicionales

como las basadas en experiencia y cualquier otra que el usuario final desee realizar.

Para desarrollar casos de prueba de aceptación, los pasos a realizar tienen que describirse en

el lenguaje de la operación real, no es necesario ingresar cuestiones técnicas, como número y tipos

de caracteres, tiempos de espera, etc. Hay que recordar que el usuario final no revisa el tiempo

exacto en que tarda una ventana en desplegarse, sólo se limita a realizar una apreciación personal de

dichos tiempos. De la misma manera, un usuario final no validará la comunicación correcta con la

impresora, pero sí validará el diseño de los reportes, los permisos requeridos para obtenerlos y la

facilidad de configuración de estos.

Crear escenarios de prueba

Un escenario puede validar una o más condiciones de prueba, sin embargo esto se permite o se

niega de acuerdo a las características e importancia de cada condición en particular. Para definir un

escenario se requiere tener la especificación de requerimientos completa, además del conocimiento

acerca del funcionamiento del sistema.

Así mismo, debido a que las pruebas de aceptación generalmente se enfocan a un grupo de

componentes, que a su vez conforman una operación completa del día a día es necesario crear

escenarios de prueba que documenten las operaciones dentro de cada caso, incluyendo los datos que

fluyen dentro de los escenarios y las autorizaciones necesarias. Por ejemplo: la compra de equipo

nuevo (cotización, aprobación, pedido, recepción, pago), un día de venta (ventas, cancelaciones,

cambio de turnos, cambio de usuarios, reportes finales), etc. Para crear escenarios de prueba se

sugiere realizar los 5 pasos siguientes:

1. A partir del registro de rastreo realizar una matriz donde se liste las operaciones del negocio que

involucran a cada requerimiento en específico (tabla 16).

# Requerimiento DescripciónRequerimiento

Crear una venta Crear unacompra

Crear unaCancelación

Cambiar deTurno

Realizar Devolución

GN.0001 Requer imiento 1



GN… .

GN… .

GN… .

GN.00NN Requer imiento N

Tabla 16 - Ejemplo de matriz de requerimientos versus operaciones de negocio.





2. Relacionar los requerimientos del sistema con las diferentes operaciones del negocio que hacen

uso o proveen información a cada requerimiento en específico. Al final, todos los

requerimientos de pruebas deben haber sido cubiertos al menos 1 vez, tal como se muestra en la

tabla 17.

# RequerimientoDescripción

RequerimientoCrear una Venta

Crear una

Compra

Crear una

Cancelación

Cambiar de

TurnoRealizar Devolución

Requerimiento 1 X

GN.0002 Requerimiento 2 X X

GN.0003 Requerimiento 3 X X

GN… . X X X X

GN… . X X X

GN… . X X X X X

GN.00NN Requerimiento N X X

Requerimientos cubiertos por cada operación de negocio

Tabla 17- Identificación de requerimientos para cada operación de negocio.

3. Es posible diversificar las operaciones de negocio en los diferentes escenarios; estos escenarios

serán la guía de los casos de prueba de esta fase. Es necesario asegurarse una vez más que todos

los requerimientos indicados para cada operación de negocio se cubren completamente en losescenarios previstos. Así mismo, a cada escenario se le debe añadir el resultado que se espera

obtener al ejecutarlo; por ejemplo, una venta realizada, una cotización aprobada, un alta de

cuenta satisfactoria, etc.

Crear una ventaVenta al

publico

Venta a

Crédito

Cancelación

de Venta

Requerimiento 1 X X X

Requerimiento 32 X X X

Requerimiento 33 X

Requerimiento 39 X X

Requerimiento N X

Resultado esperado 1 SI

Resultado esperado 2 SIResultado esperado 3 SI

Tabla 18 - Escenarios de prueba para una operación de negocio.

4. Incluir varias ejecuciones por escenario. Por ejemplo, realizar varios días de ventas (un único

escenario, pero con datos para 2 o 3 días), varias cancelaciones de compras, varias cotizaciones,

etc.

5. Asignar a cada caso de prueba un número único de acuerdo al orden de ejecución de los

escenarios según la importancia de las operaciones, la cantidad de requerimientos cubiertos, etc.

Ver tabla 19.





Operación de Negocio Escenarios de Prueba

Crear una Venta VEN.0010.USR.Venta al publico

Crear una Venta VEN.0020.USR.Venta a Crédito

Crear una Venta VEN.0030.USR.Cancelación de Venta

Cambiar de Turno COM.0010.USR.Apertura de Turno Matutino

Cambiar de Turno COM.0050.USR.Cierre de Turno Matutino

Cambiar de Turno COM.0060.USR.Cierre de Turno Vespertino

. .

. .

Realizar Devolución DEV.0860.USR.Devolución autorizada por gerente

Tabla 19 – Ejemplo de listado de escenarios de prueba para la fase de aceptación.

Una vez desarrollados los escenarios entonces es posible crear los casos de prueba. Al igual

que en las pruebas de sistema, el nivel de detalle se determinará por los diversos factores

involucrados en el proyecto. Sin embargo, siempre es necesario utilizar una plantilla estándar para

desarrollarlos, la cual puede ser la misma que la ya usada para los casos de sistema.

Desarrollo del caso de acuerdo al grado de madurez del área.

Al igual que en la creación de casos de prueba de sistema es posible manejar dos niveles dedesarrollo para la fase de aceptación, simple y avanzado.

En la tabla 20 se presenta un ejemplo de un caso de prueba “simple” a utilizarse en grupos de

pruebas sin experiencia.

Crear una Venta VEN.0010.USR.Venta al publico Fecha de Creación: 21/12/2007

Versión:

0001


1Abra el sistema, capture una venta y registre el

pago.

Se almacena un registro de la venta, sin datos de cliente relacionados

y del tipo "venta al público". La venta genera un ticket que contiene los

datos especificados en los requerimientos, así como el desglose de la

venta de acuerdo al tipo "Nota de venta".

Objetivo:

Realizar una venta al publico de un grupo de artículos sin cotización previa ni descuentos aplicados.

Tabla 20 - Caso de prueba “simple” para validar una venta al público.

En la tabla 21 se presenta un ejemplo de un caso de prueba “avanzado” a utilizarse en

grupos más experimentados.

Los casos de prueba de aceptación se realizarán a razón de un caso por escenario. Sin

embargo, en ocasiones será necesario crear casos de prueba que únicamente validen la

funcionalidad de un cierto módulo en particular, con el objeto de hacer revisiones puntuales. Así

mismo, también habrá casos de prueba definidos por el usuario, donde se utilizará su experiencia

personal para determinar posibles fallas del sistema que serían difíciles de identificar dentro de un

escenario completo. Un caso de prueba avanzado también puede integrar la identificación de los

datos de entrada y salida que se usarán dentro de cada paso. Se presenta un ejemplo en la tabla 22.Identificar los datos desde la creación del caso de prueba ahorra tiempo en la administración

posterior, y a la vez permite crear casos de prueba “parametrizables” que son fáciles de mantener.





Id Req:

GN.0002 CP.0001.func.: Verificar pantalla de arranque Fecha de Creación: 01/12/2007

Versión:

0001


1 Ejecute el sistema. Una pantalla de inicio se muestra.

2Valide visualmente que la pantalla de iniciocontiene el logo de la empresa.

La pantalla muestra el logo de la empresa de manera

centrada y en un cuadro que abarca la mayor parte dela pantalla.

3Valide visualmente que la pantalla de inicio

contiene el "nombre del Módulo" ejecutado.

La pantalla muestra el nombre del módulo a manerade título, colocado en un cuadro blanco con bordesnegros y centrado, justamente encima del logo de la

empresa.

4Valide visualmente que la pantalla de iniciocontiene La "versión" del sistema.

La pantalla muestra la "versión" correcta, colocada enun cuadro blanco sin marcos, siendo el primer renglóncon texto.

5

Valide visualmente que la pantalla de iniciocontiene la "leyenda de autorización" del uso del

producto.

La pantalla muestra la "Leyenda de autorización"correcta, colocada debajo del cuadro de la versión,

en un cuadro del mismo tamaño sin espacios entreambos, sin marco y con el mismo tamaño y tipo de

letra.

6

Valide visualmente que la pantalla de inicio

contiene la "leyenda de CopyRight" y el "año" decreación del software.

La pantalla muestra la "leyenda de CopyRight"correcta, debajo de la "leyenda de autorización", de

manera centrada sin cuadros y sin marcos, con un

tamaño de letra menor a la de la leyenda deautorización".

7Valide que la pantalla se cierra después de 3segundos de haberse abierto.

La pantalla se cierra y se muestra la pantalla principaldel módulo abierto.

8 N/A

Todas las validaciones realizadas en este caso deprueba se han realizado de manera satisfactoria.

Objetivo:Verificar que al arrancar el sistema se muestre la pantalla de "flash", donde muestre el logo, y nombre dela empresa, así como el módulo y los datos del usuario registrado.

Tabla 21 - Ejemplo de caso de prueba “avanzado” para validar una venta al público.

2) Creación de datos de prueba

Una parte importante en el diseño de las pruebas, tanto de usuario como de aceptación, es el diseño

y creación de los datos para la ejecución de las mismas. Estos indican las entradas y salidas, y son

un componente crítico para mantener una imparcialidad al momento de interpretar el resultado de

las pruebas. Es responsabilidad del experto de negocio crear los datos de prueba, pudiendo en

algunas ocasiones entregar un grupo grande de datos válidos, tal como una base de datos o un grupo

de facturas de periodos anteriores. En ese caso será necesario seleccionar algunos datos para cada

caso de prueba, así como administrarlos durante la ejecución. Los datos de prueba se pueden

administrar en una tabla adicional que contenga el número del caso de prueba al que corresponden

los datos y un listado de los datos de entrada y los datos de salida para cada ejecución.





Crear una Venta VEN.0010.USR.Venta al publico Fecha de Creación: 21/12/2007

Versión:

0005Paso Accion Resultado Esperado

1Datos: Ninguno

Ejecute el sistema Una pantalla de inicio se muestra

2

Datos: "Usuario", "Password", "Menú de Ventas"

Ingrese al sistema con un el "Usuario" y

"Password".

El sistema permite el ingreso a la pantalla principal, y el menú de

"Ventas" se despliega.

3

Datos: Ninguno

Seleccione el menú: Ventas-> Realizar una

Venta. El sistema despliega la pantalla "Ventas diarias".

4

Datos: Ninguno

Seleccione la pestaña "Ventas al público

general" dentro de la pantalla "Ventas Diarias".

El sistema permite seleccionar la pestaña y muestra los campos y

botones que permiten realizar una venta al publico general.

5

Datos: "Listado de la Venta"

Ingrese uno por uno los códigos del "Listado de

la Venta" de los artículos a vender

manualmente.

Cada vez que se ingresa un "código" de producto, el sistema muestra

el "nombre completo" de este, así como el "precio" y permite ingresar

la cantidad de artículos que se marcarán (por default muestra el

número "1"). Así mismo, el último artículo marcado es agregado dentro

del "listado de la venta" y se muestra un total de la lista en todo

momento.

6Datos: "Total", "Listado de Opciones"

Presione el botón "Finalizar Venta".

El sistema muestra una nueva ventana, indicando el "Total" de la

cuenta, así como un "listado de opciones" para efectuar el pago.

7

Datos: "Tipo de Pago", "Monto", "Listado de laVenta"

Seleccione el "Tipo de Pago", ingrese el

"Monto" y finalice la venta.

El sistema imprime un ticket en la impresora especializada quecontiene los datos especificados en el diseño funcional del ticket, así

como el listado de los artículos vendidos (cantidades y nombres

cortos), y el total final incluyendo Impuestos.

8 N/A

Todas las validaciones realizadas en este caso de prueba se han

realizado de manera satisfactoria.

Objetivo:

Realizar una venta al publico de un grupo de artículos sin cotización previa ni descuentos aplicados.

Tabla 22 - Ejemplo de caso de prueba “avanzado” incluyendo la identificación de los datos de prueba.

En casos de prueba de sistema bastará con ingresar el dato de entrada a usarse dentro del caso

de acuerdo al nivel de detalle de éste:

1. En los casos simples sólo se ingresará un listado de datos a utilizar. Ver tabla 23.

2. En casos de prueba más desarrollados (avanzados), será necesario separar los datos de acuerdo

al número de paso donde se emplean y en ocasiones se requerirá administrar la transformación

de un dato a través de los diferentes pasos del caso de prueba (por ejemplo: crédito disponible

del cliente en una venta). Ver tabla 24.

Caso de Prueba Entradas Salidas

CP.0002.func.: Verificar menú de administrador al

ingresar al sistema.Usuario: Admin1

Password: Admin1 Ninguno

CP.0003.func.: Verificar menú de Operador de

Ventas al ingresar al sistema.Usuario: OpeVtas1

Password: OpeVtas1 Ninguno

Tabla 23 - Ejemplo de datos para casos de pruebas de sistema "simple".

Esta forma de administrar los datos también aplica para los casos de prueba de aceptación

que se generan para realizar validaciones puntuales, es decir, aquellos que no validan un escenario

completo de pruebas.

Para los casos de prueba de aceptación que provienen de un escenario completo de prueba,

es necesario mantener un control por tiempos que permita administrar las modificaciones de un dato

de prueba desde el momento en que entra al sistema hasta el momento que sale o se almacena en un





repositorio. Esto es particularmente crítico para validar requerimientos contables, financieros y

estadísticos.

Caso de Prueba Paso Entradas Salidas

CP.0001.func.: Verificar

pantalla de arranque3

Ninguno Módulo: "Sistema de Administración de Ventas"



Ninguno Versión: "1.0000"



Ninguno

Leyenda: "Se autoriza la utilización de este producto a :"Operaciones y

Transferencias S.C.""



Ninguno

CopyRight: "Este programa está protegido bajo las leyes de Derechos de Autor

Internacionales"

Año: "2008"

Tabla 24 - Ejemplo de datos para casos de pruebas de sistema "avanzado".

Como se muestra en el ejemplo de la figura 9, el valor de cada variable se determina

dependiendo del momento en que se encuentre dentro de la ejecución total del sistema. Por ejemplo,

el “Crédito Cliente” es igual a su monto antes de la operación (120,000) menos el monto de la

operación (-20,000), y da como resultado el monto final (100,000).

Estado del Caso de Prueba >

Caso de Prueba

# Cliente Crédito Cliente

Cuentas x Cobrar Cliente

Autorización Venta Crédito

Fecha de Pago

Total de Venta

Crédito Cliente

Cuentas x

Cobrar Cliente

CP.0120.func.: Crear una

venta a crédito 00234 120,000 40,000 JUX983L1 02-ene-08 20,000 100,000 60,000CP.0121.func.: Cancelar una

venta a crédito 00235 10,000 0 JUX983L1 02-ene-08 3,850 6,150 3,850

Antes de la Operación Después de la OperaciónDurante la Operación

Datos de prueba que cambian de valor en la ejecución

Figura 9 – Selección de casos de prueba de aceptación creados a partir de un escenario.

e. Realización de la fase de Integración y Pruebas

Dentro de la realización de la fase de integración y pruebas se encuentran las tareas: 1) Realizar

integración y pruebas y 2) Realizar las pruebas de sistema.

1) Realizar integración y pruebas

Crear el plan de ejecución de las pruebas de integración . Este plan contiene el detalle de las

actividades y los procedimientos a seguir durante la ejecución de las pruebas. Así mismo

proporciona un registro guía para el avance de cada fase de pruebas, permitiendo controlar aquellos

casos de prueba que se han ejecutado con éxito, así como los que han descubierto un defecto del

sistema. El plan de ejecución muestra los casos de prueba a ejecutar dentro de cada día de la fase depruebas, así como el responsable de cada una de ellas, el tiempo destinado y todas aquellas

actividades que forman parte de un pre-requisito para realizar las ejecuciones, por ejemplo, la

captura de datos de prueba, la ejecución de un proceso alterno, etc.

Dentro del plan, los casos de prueba se encuentran ordenados de acuerdo a una secuencia

predefinida, que se determina al agrupar los casos de prueba que tienen objetivo similar o que

pertenecen a una misma funcionalidad, con esto se generan “bloques de ejecución” que permiten





mostrar el estado de cada módulo o funcionalidad del sistema. En la figura 10 se muestra un

ejemplo de un plan de pruebas de integración.

A

B

C

D

Plan de Ejecución Pruebas de Sistema

Modulo /

Funcionalidad Caso de Prueba

Ambiente Actividad - Instalar el ambiente de ejecución.

Ambiente Actividad - Carga de Datos de Configuración

Instalación Instalación de sistema en equipo de pruebas.

CP.0001.func.: Verificar pantalla de arranque

CP.0002.func.: Verificar menú de administrador al ingresar al

sistema.

CP.0003.func.: Verificar menú de Operador de Ventas al ingresar

al sistema.

CP.004.func.: …

CP.005.func.: …

CP.0120.func.: Crear una venta a crédito

CP.0121.func.: Cancelar una venta a crédito

CP.0130.func.: …

CP.0140.func.: ...

Ambiente Ejecución de Cierre de día Laboral

Ambiente Ejecución de Inicio de día Laboral

CP.0030.func.: Verificar botón de exportar una cotización.

CP.0035.func.: ...

CP.0040.func.: ...

CP.0045.func.: ...

CP.0050.func.: ...

Compras (CM)

General (GN)

Ventas (VT)

Figura 10- Bloques de ejecución de las pruebas.

Los bloques de ejecuciones facilitan la modificación del plan, en caso de requerirlo. Por

ejemplo, un módulo que contiene muchos errores se mueve hacia un tiempo posterior de ejecución,

lo que permite disponer de más tiempo para la corrección de defectos mientras se valida otra

funcionalidad.

Para realizar el plan de pruebas de integración, es posible indicar solamente en forma global

los módulos de las piezas que serán validadas en cada día, con el objetivo de enfocar el esfuerzo

hacia la funcionalidad específica del sistema y no “validar todo a la vez”. En el caso de los

requerimientos generales, se recomienda que se coloquen al final de las pruebas, debido a que

pueden pertenecer a diferentes pantallas o funcionalidades, lo que podría ocasionar confusiones.

La tabla 25 contiene un plan de pruebas de integración con los datos mínimos requeridos

para formalizar la ejecución de las actividades de pruebas.

Ejecutar pruebas de humo. El objetivo de las pruebas de humo es el de asegurarse que el

requerimiento, funcionalidad o módulo específico trabaja de la manera esperada antes de iniciar con

la ejecución de los casos de prueba formales de sistema. Estos casos de prueba no son creados

dentro de un formato pre-establecido, por lo tanto no se encontrarán documentados. Sin embargo es

la primera validación que se realizará antes de comenzar con los ciclos de las pruebas de sistema y

aceptación.





Plan de Ejecución Pruebas de Integración Versión 001

Modulo Funcionalidad Fecha Planeada

Ventas

VT.001 - Cada venta debe contener la siguiente información:

Empleado, Cliente, RFC Cliente, Monto total, Tipo de pago,

Referencia de pago, Fecha de pedido, Fecha de entrega, Lista de

productos y Número de factura. 10/12/2007

CM.001 - Cada compra debe contener la siguiente información:

Empleado, proveedor, RFC proveedor, Monto total, Tipo de

pago, Referencia de pago, Fecha de pedido, Fecha de entrega,

Lista de productos y Número de factura. 12/12/2007

CM.002 - Cada compra debe de ser autorizada por un supervisor

antes de cerrar el pedido. 12/12/2007

CM.003 - Cada compra debe contener una cotización de compra

con almenos 3 proveedores, para validar una compra justa. 14/12/2007

GN.0004 - El sistema debe de soportar los siguientes sistemasoperativos: Windows 98, Windows 2000, Windows XP, Windows

Vista. 14/12/2007

GN.0003 - Se deben de manejar 3 níveles de usuario, cada nivel

contiene un determinado número de módulos que se mostrarán.

17/12/2007

GN.0002 - Usar la imagen de la empresa en todas las pantallas 19/12/2007

GN.0001 - El sistema debe mostrar una pantalla de arranque

indicando versión, fecha de creación y nombres legales del

sistema y de la empresa 21/12/2007

Compras

General

Tabla 25 - Formato para plan de pruebas de integración.

Realizar pruebas de integración. Esta es una actividad que efectúan los programadores en

paralelo con el avance de la integración de los componentes del software. Para estas pruebas, es

recomendable mantener un registro donde se evidencien todos los incidentes que ocurran dentro de

la ejecución, tales como:

Cantidad y tiempo de resolución de defectos ocurridos.

Tiempo de configuración del ambiente.

Cantidad de ejecuciones por caso de prueba.

Tiempo de ejecución por caso de prueba.

Los registros se realizan de acuerdo al plan de ejecución de las pruebas, asegurándose de

almacenar cada ejecución, y defecto encontrado y solucionado dentro de esta fase. Debido a que

estas pruebas son realizadas por el programador, la administración de la ejecución se reduce al

registro de defectos. Esta actividad se realiza mediante un control simple donde se registran todos

los defectos encontrados, indicando la fecha de solución y, en lo posible, otros datos tales como:

estado, criticidad del defecto, tiempo de resolución, piezas afectadas por el defecto, número de





aparición (defectos repetidos), etc. En la tabla 26 se presenta un ejemplo de un formato para la

administración de defectos.

# Defecto Fecha

Creación

Fecha

Cierre Estado Criticidad

Esfuerzo

(hrs) Piezas afectadas

#

Aparición

1

Campo "Teléfono", es "Integer" debería de

ser "String". 17-dic-07 17-dic-07 Cerrado Baja 1

Captura de Cliente,

Modificación de Cliente, Baja

de Cliente. 1

2

La conexión con la Base de Datos no

trabaja (Error 2231). 17-dic-07 17-dic-07 Cerrado Alta 3 Captura de Cliente. 1

3

Los datos mostrados en el formulario están

mal mapeados. 17-dic-07 18-dic-07 Cerrado Media 2 Modificación de Cliente. 1

4

El campo "Teléfono" se guarda

erroneamente. 17-dic-07 17-dic-07 Cerrado Media 4 Modificación de Cliente. 1

5

El número de Folio de la factura no

aparece 18-dic-07 18-dic-07 Cerrado Alta 1 Venta al publico. 1

6

Campo "Teléfono", es de tipo "Integer"

debería de ser "String". 18-dic-07 18-dic-07 Cerrado Baja 0.5 Venta al público. 2

7

Falta el mensaje "Desconexión por sesión

inactiva". 18-dic-07 18-dic-07 Cerrado Baja 1.5 General. 1

8

La pantalla de "Screensaver" no muestra el

mensaje de la Base de Datos. 19-dic-07 Abierto Baja General. 1

9

La pantalla de "Screensaver" no aparece

en el tiempo almacenado. 19-dic-07 Abierto Baja General. 1

Tabla 26 - Administración de defectos.

Reporte de ejecución de pruebas de integración

Al finalizar la ejecución de las pruebas de integración se crea un reporte que incluye la cantidad de

veces que se ha probado una pieza (re-ejecuciones), así como los tiempos que el grupo de desarrollo

tardó en resolver un defecto. De esta manera, se pueden realizar proyecciones de entrega del

proyecto en base a los defectos esperados y así poder manejar los riesgos de una mejor manera. Este

reporte entrega también los datos requeridos por la alta gerencia para tomar decisiones de negocio y

así validar si es posible o no aceptar el software después de las pruebas de integración, actuando

como soporte de la firma de aceptación o del rechazo de esta fase.

2) Realizar las pruebas de sistema

Crear plan de ejecución de pruebas de sistema. Antes de realizar las pruebas de sistema y de

aceptación de usuario es necesario que, al igual que en las pruebas de integración, se cree un plan de

ejecución. Este plan debe mostrar todas las actividades que se realizarán en esta fase de pruebas.

Ver el formato propuesto en la tabla 27.

Dentro del plan se pueden observar, además de los casos de prueba (CP), todas las

actividades complementarias, tales como la configuración de datos y ambiente, la instalación del

sistema y los cambios de fecha de operación, así como el número de ciclos a ejecutar dentro de las

pruebas de sistema. Una consideración importante al desarrollar el plan de pruebas es la de dar

tiempo suficiente para la resolución de los defectos encontrados en las pruebas ( Actividad A5.7 del

modelo MoProSoft ). Para determinar el tiempo de resolución de defectos, es posible llegar a un

acuerdo con los encargados de la programación, para esto se puede utilizar la tabla 8.





Plan de Ejecución Pruebas de Sistema

Modulo /

Funcionalidad Caso de Prueba Responsable Fecha Planeada

Ambiente Actividad - Instalar el ambiente de ejecución. Cliente 01/01/2008

Ambiente Actividad - Carga de Datos de Configuración Desarrollo 02/01/2008

Instalación Instalación de sistema en equipo de pruebas. Desarrollo 03/01/2008

CP.0001.func.: Verificar pantalla de arranque Tester A 04/01/2008

CP.0002.func.: Verificar menú de administrador al ingresar al

sistema. Tester B 04/01/2008

CP.0003.func.: Verificar menú de Operador de Ventas al ingresar

al sistema. Tester C 04/01/2008

CP.004.func.: … Tester A 04/01/2008

CP.005.func.: … Tester B 04/01/2008

CP.0120.func.: Crear una venta a crédito Tester A 05/01/2008

CP.0121.func.: Cancelar una venta a crédito Tester B 05/01/2008

CP.0130.func.: … Tester C 05/01/2008

CP.0140.func.: ... Tester A 05/01/2008

Ambiente Ejecución de Cierre de día Laboral Cliente 05/01/2008

Ambiente Ejecución de Inicio de día Laboral Cliente 06/01/2008

CP.0030.func.: Verificar botón de exportar una cotización. Tester C 07/01/2008

CP.0035.func.: ... Tester A 07/01/2008

CP.0040.func.: ... Tester B 07/01/2008

CP.0045.func.: ... Tester C 07/01/2008

CP.0050.func.: ... Tester B 07/01/2008

Compras (CM)

Versión 001

General (GN)

Ventas (VT)

Tabla 27 - Formato para plan de pruebas de sistema y aceptación de usuario.

Con el plan realizado es muy útil para el administrador y para el equipo de ejecución contar

con un diagrama de ejecución. El esquema de la figura 11 ofrece una visión general de lo descrito

más arriba. El número de ciclos corresponde al número de ciclos que se hayan determinado en el

plan inicial. Las actividades complementarias son únicas de acuerdo a cada proyecto y se deben

revisar y coordinar con el líder del mismo.

Pruebas de Sistema

Pruebas

de HumoInicio

Ciclo 2 de

Pruebas

Ciclo n de

Pruebas

Pruebas de

Aceptación de

Usuario

Ciclo 1 de

Pruebas

Figura 11 – Diagrama de Ejecución de Pruebas de Sistema y Aceptación de Usuario.





Realizar las pruebas de sistema. La administración de una fase de realización de las pruebas no es

muy diferente a la administración de cualquier proyecto de sistemas en general: existen actividades

que realizar y recursos limitados para completarlas. Debido a que ya se cuenta con el plan de

ejecución, sólo es necesario validar la disponibilidad de los recursos a emplear. Durante la

ejecución es muy importante enfocarse en las siguientes actividades de pruebas:

1. Realizar pruebas de humo.2. Administrar el esfuerzo realizado por cada integrante.

3. Ejecutar casos de prueba.

4. Documentar los defectos.

5. Reporte de mando.

6. Administrar los defectos durante todo su ciclo de vida.

7. Registrar y administrar métricas.

8. Reportar ejecución de pruebas.

1. Realizar pruebas de humo

Para las pruebas de aceptación es necesario ejecutar varios ciclos, el primero de ellos será el de

“pruebas de humo”. Este ciclo se ejecuta inmediatamente al recibir una pieza nueva o una

actualización del software bajo validación. El objetivo es validar de manera rápida los casos de

prueba más importantes, bajo la premisa de que si no funcionan estos, no son necesarias todas las

validaciones y el producto se rechaza para ser reparado.

2. Administrar el esfuerzo realizado por cada integrante

Asignar a los testers los casos de prueba que indica el plan de pruebas, considerando las situaciones

extraordinarias tales como los defectos aún no resueltos. Es decir, si existe un defecto que se

presentará en los casos de prueba del día, es posible asignar otro “bloque” de casos. El objetivo es

tener a su disposición casos de prueba a ejecutar que le permitan detectar defectos aún no

encontrados. De acuerdo a las características de los casos de prueba, es posible asignarlos a uno o

más ejecutores diferentes, así como uno o más días de realización, esto sucede en casos de prueba

muy grandes o en las ocasiones en que por razones especiales sea necesario interrumpir un caso de

prueba para reanudarlo en otro día o después de la ejecución de un proceso específico.

3. Ejecutar casos de prueba

Consiste en realizar las acciones que indica el caso de prueba en cada uno de sus pasos y determinar

si se obtiene un resultado satisfactorio, tanto en cada paso, como el caso de prueba total. Al realizar

la ejecución, se debe almacenar la evidencia de todo lo que se está realizando. Para esto, se sugiere

usar un documento electrónico y también para guardar la imagen de la pantalla que muestre la

operación y/o el resultado.

Existen casos especiales donde las pruebas requerirán de un proceso adicional para seralmacenadas, tales como fotografías externas del comportamiento de equipos o componentes,

grabaciones de audio e impresiones en documentos predefinidos, por mencionar algunas. En el

mercado existen herramientas de software muy completas, creadas específicamente para administrar

la ejecución de las pruebas. Sin embargo no sería recomendable tener una herramienta tan poderosa

mientras no se tengan proyectos de magnitud importante.





4. Documentar los defectos

Existen diferentes criterios para realizar una documentación completa de un defecto, los cuales

dependen del tipo de ejecución, de la herramienta e inclusive del propio sistema. Sin embargo es

altamente recomendable que todos los defectos se entreguen con la misma estructura en cuanto a la

información contenida, permitiendo así obtener las ventajas de la estandarización de procesos, tales

como:

Disminución en el tiempo de entrenamiento.

Facilidad para entender el problema.

Detección de la duplicidad.

Facilidad en el mantenimiento.

Capacidad para observar errores que aparecen con ciertos patrones.

En la tabla 28 se propone un formato para documentar un defecto.

# Defecto F. Alta Caso de Prueba Tester Severidad Paso F. Cierre

Def.0001 26-dic-07 CP.0001.func Alain Ponce 2 - Alta 06 -

Defecto:

Error en la carga de un nuevo usuario.

Descripción:

Al momento de realizar una alta de cliente nueva, el sistema envía el error "Necesita

ingresar al menos 1 teléfono", sin embargo el registro ya tiene 2 números telefónicos

cargados en los campos correspondientes.

Consideraciones Generales:

Los 2 teléfonos cargados son número celular, sin embargo no existe ninguna

restricción con respecto al tipo de teléfono a almacenar forzosamente.

Tabla 28 - Ejemplo de registro de defecto de sistema.

Los campos empleados en esta documentación son:

# Defecto: es el número único del defecto durante todo el proyecto y se compone del

identificador de defecto (Def.) y un número asignado de manera secuencial (0001).

F. Alta: es la fecha en que se detectó y registró el defecto.

Caso de prueba: es el número del caso de prueba ejecutado sobre el cual se detectó el defecto.

En caso de un defecto genérico o que no provenga de un caso de prueba, se puede indicar con

las leyendas “General” ó “N/A” respectivamente.

Tester: es el nombre o identificador del tester que descubrió el defecto, por ejemplo: número de

acceso a la red, número de empleado, etc.

Severidad: representa el grado de importancia del defecto, con respecto al daño que puede

causar si se llegara a presentar en producción. Las severidades deben definirse antes del inicio

de la ejecución, y van de la mano con los tiempos de respuesta acordados con los encargados de

la programación.

Paso: es el número de paso del caso de prueba donde se detectó el defecto. Se puede colocar la

leyenda “N/A” en caso de ser un defecto general o que éste no provenga de un caso de prueba.





F. cierre: es la fecha en la que se cerró el defecto. Al momento de crearlo se puede dejar con el

símbolo “-“. Sin embargo, es importante actualizarla al momento de cerrar el defecto, ya que

será fundamental para obtener métricas al respecto.

Defecto: es un nombre representativo de la falla. Debe describir de manera muy abstracta su

contenido, por ejemplo: “Error en la captura del nombre”, “El sistema no permite consultar”,

“Mensaje de error al arrancar”, etc. Descripción: es la descripción detallada del defecto, la forma en que se detectó y, de ser posible,

se debe indicar una segmentación. Es importante que al redactar, se ponga énfasis en las

acciones realizadas para detectar el error y en las posibles causas (si se conocen).

Consideraciones generales: en este espacio se pueden agregar comentarios acerca del defecto,

que no necesariamente se relacionan directamente al sistema. Por ejemplo: “el defecto se ha

reportado 3 veces”, “la forma correcta de operar se encuentra en el requerimiento XXX”, “El

defecto es intermitente y no se ha detectado una forma constante de reproducirlo”, etc.

5. Reporte de mando

El reporte muestra el estado del proyecto en tiempo real, así como la cantidad de casos exitosos,

fallados y faltantes por ejecutar. Puede agregar las métricas que considere representativas para elgrupo al que se entregará el reporte, tales como: el porcentaje de variación de lo real versus lo

planeado, la proyección de la fecha de cierre, en caso de continuar con el ritmo actual de trabajo o

la cantidad de defectos de severidad alta documentados. Este reporte se diseña principalmente para

los mandos gerenciales, sin embargo se puede crear un resumen adicional para el equipo de

ejecución. Un reporte simple podría mostrar lo siguiente:

Número de casos de prueba ejecutados durante el día.

Porcentaje de avance de casos de prueba ejecutados completamente, casos de prueba fallados y

casos de prueba bloqueados.

Número de defectos documentados durante el día, incluyendo severidad y re-aperturas.

Número de defectos críticos aún abiertos.

Número de re-ejecuciones realizadas.

Para realizar esta actividad puede re-utilizar el formato del plan de pruebas, con esto es posible

registrar la ejecución sin perder la vista global del proyecto. Entre la información relevante a

registrar en la ejecución se encuentra la fecha real de ejecución, el estado en el que se encuentra

cada actividad, el número de defectos detectados y el responsable encargado de realizar la tarea. En

la tabla 29 se presenta un ejemplo de reporte de mando de pruebas de sistema.





Reporte de Mando Pruebas de Sistema

Modulo/

Funcionalidad Caso de Prueba Responsable

Fecha

Planeada

Fecha

Ejecución

Estado

Ejecución

#

Defectos

Ambiente

Actividad - Instalar el ambiente de

ejecución. Cliente 01/01/2008 02/01/2008 Ejecutado 0

Ambiente

Actividad - Carga de Datos de

Configuración Desarrollo 02/01/2008 02/01/2008 Ejecutado 0

Instalación

Instalación de sistema en equipo de

pruebas. Desarrollo 03/01/2008 04/01/2008 Ejecutado 0

CP.0001.func.: Verificar pantalla de

arranque Tester A 04/01/2008 07/01/2008 Ejecutado 1

CP.0002.func.: Verificar menú de

administrador al ingresar al sistema. Tester B 04/01/2008 07/01/2008 Defectos 3

CP.0003.func.: Verificar menú de Operador

de Ventas al ingresar al sistema. Tester C 04/01/2008 07/01/2008 En ejecución 0

CP.004.func.: … Tester A 04/01/2008 07/01/2008 Defectos 2

CP.005.func.: … Tester B 04/01/2008 08/01/2008 En ejecución 1

CP.0120.func.: Crear una venta a crédito Tester A 05/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0121.func.: Cancelar una venta a

crédito Tester B 05/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0130.func.: … Tester C 05/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0140.func.: ... Tester A 05/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

Ambiente Ejecución de Cierre de día Laboral Cliente 05/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

Ambiente Ejecución de Inicio de día Laboral Cliente 06/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0030.func.: Verificar botón de exportaruna cotización. Tester C 07/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0035.func.: ... Tester A 07/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0040.func.: ... Tester B 07/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0045.func.: ... Tester C 07/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

CP.0050.func.: ... Tester B 07/01/2008 Sin ejecutar Sin ejecutar Sin ejecutar

General (GN)

Ventas (VT)

Compras (CM)

F. Actualización: 04/01/2008 Total Defectos Encontrados: 7

Tabla 29 - Formato de control de ejecución de pruebas integrales.

6. Administrar los defectos durante todo su ciclo de vida

Si durante la ejecución se detecta una diferencia entre el resultado esperado y el obtenido, entonces

será necesario documentar y administrar un defecto. La administración de los defectos se realiza

desde que se detecta una falla en el sistema hasta que se ha corregido completamente. Para

administrar esta información puede utilizar la plantilla presentada en la tabla 30.

Defecto Estado Fecha AltaFecha

ResoluciónComentarios

Tabla 30 - Formato para administración de defectos.

Lo que sucede con un defecto a partir de que fue descubierto hasta que es resuelto se

conoce como “ciclo de vida del defecto”. El ciclo de vida se puede representar por medio de un

diagrama como el de la figura 12. El defecto puede estar en distintos estados según la etapa del

ciclo de vida en la que se encuentre:

Nuevo: se utiliza cuando se detecta y documenta el defecto.

Aceptado: se utiliza cuando el defecto es tomado por el equipo de desarrollo y éste se encuentra

trabajando en su resolución. Dentro de una administración avanzada es posible asignar la

revisión del defecto a una persona específica.

Validación: es cuando el defecto se ha resuelto por el equipo de desarrollo y se ha liberado para

que el tester realice su revisión. Esta validación se realiza a través de una re-ejecución de un





caso de prueba. Al igual que en los otros estados, dentro de una administración avanzada es

posible asignar a una persona específica la validación de este defecto.

Cerrado: cuando la resolución del defecto se ha validado completamente, se asigna este estado y

se almacena en las métricas.

Re-Abierto: cuando la resolución del defecto no se ha podido validar, debido a que continúa

apareciendo al realizar una re-ejecución de un caso de prueba. Cancelado: se asigna si se presenta una de las siguientes condiciones:

El defecto ya se ha reportado en otro documento;

El error reportado no es un defecto; y

Por razones de negocio, el defecto ya no se resolverá.

Nuevo

Defecto

Def. 0001

Defecto

Def. 0001

Aceptado

Defecto

Def. 0001

Cerrado

Defecto

Def. 0001

Re-Abierto

Defecto

Def. 0001

Validación

Tester Administrador Desarrollador

Revisa y

Asigna

Concentra

y Asigna

Concentra

y Asigna

Defecto

Def. 0001

Cancelado

Figura 12 - Ciclo de vida de los defectos.

7. Registro y administración de métricas de ejecución

Las métricas obtenidas durante cada jornada de la ejecución de las pruebas son almacenadas dentro

de uno o más repositorios, en un formato predefinido, pudiendo contener, entre otros datos: fecha,





recursos utilizados y avance ejecutado, defectos encontrados y re-abiertos cada día, así como la

actualización de las fechas de resolución de defectos anteriores. Un ejemplo de un formato para

almacenar las métricas se muestra en la tabla 31.

05-ene-08

Proyecto

High Medium Low Total

Casos totales del proyecto 25 50 100 175

Casos ejecutados hoy 3 3 6 12

Casos fallados hoy 0 0 1 1

Casos exitosos hoy 3 3 5 11

Casos ejecutados total 13 21 50 84

Casos fallados total 1 3 5 9

Casos exitosos total 12 18 45 75

Defectos encontrados 2 5 3 10

Defectos cerrados 1 5 3 9

Defectos cancelados 0 0 0 0

Casos detenidos 5 0 0 5

Crear sistema SIO 1.0

Fecha de Métricas

Tabla 31 - Plantilla para almacenar métricas de pruebas.

Dentro de una administración básica, el formato de métricas puede servir para entregar

reportes de avance a los mandos superiores. En una administración avanzada es necesario mantener

un estándar en los formatos de los reportes de métricas, incluyendo gráficas, imagen corporativa,

etc., así como administrar los permisos de acceso, mantener estándares en la frecuencia de los

respaldos, y llevar un seguimiento detallado del esfuerzo por recurso, defectos por estado, defectos

por módulo y tiempos estimados para la resolución de estos.

El registro de las métricas de ejecución es la única manera de obtener datos reales de los

proyectos de la empresa. Así mismo, las métricas deben mostrar valores como: cantidad de

ejecuciones y re-ejecuciones, tiempo de no disponibilidad del sistema, número de defectos

reportados previamente detectados, número de defectos que realmente no lo son, número de casos

de prueba bloqueados por alguna razón, casos de prueba exitosos hasta la “n-ésima” ejecución, etc.

8. Reportar pruebas de sistema

Existen dos reportes de pruebas de sistema:

a) El primero se crea conforme se avanza con la ejecución de las pruebas Es posible administrar

varias “etapas” dentro de la ejecución de éstas, para representar la validación de la funcionalidad del

sistema de una manera real. Es indispensable señalar la desviación de la fecha en la que se ejecutacon respecto a la línea base marcada por la fecha planeada.

b) El segundo se crea al final de la ejecución, mediante la entrega de un resumen general que

quedará como primer evidencia de la ejecución total. El reporte debe contener las métricas del

sistema, problemas encontrados, las lecciones aprendidas y documentos finales de costos, tiempos y

cantidad de recursos utilizados en esta fase. Así mismo, si es posible, se puede incluir un listado de

la funcionalidad validada durante las pruebas y en caso de que así suceda, la funcionalidad aún





pendiente por revisar en etapas posteriores (un ejemplo típico son las pruebas de desempeño, tales

como los tiempos de respuesta en bases de datos de producción, o el uso distribuido de bases de

datos).

Pruebas de aceptación. Las pruebas de aceptación pueden considerarse como una réplica de las

actividades de las pruebas de sistema. Sin embargo, como ya se ha visto antes, se enfocan en validarciclos completos de operación del negocio. Al igual que las pruebas de sistema, las pruebas de

aceptación deben de seguir un plan de ejecución de pruebas, así como registrar los defectos

encontrados y administrarlos dentro del ciclo de resolución de defectos. De la misma manera, al

contar con el plan de ejecución no es necesario preocuparse por tener que decidir cuales grupos de

casos de prueba son los más indicados a realizar en cada momento. Durante la ejecución también es

necesario realizar las siguientes actividades de pruebas:

1. Realizar pruebas de humo.

2. Administrar el esfuerzo realizado por cada integrante.

3. Ejecutar casos de prueba.

4. Documentar los defectos.

5. Reporte de mando.

6. Administrar los defectos durante todo su ciclo de vida.

7. Registrar y administrar métricas.

8. Reportar ejecución de pruebas.

Hay que considerar que para administrar el esfuerzo realizado por cada integrante se deben

contemplar casos de prueba más grandes y con requerimientos de conocimiento del sistema

mayores.

f. Realización de la fase de Cierre

Esta guía también apoya la fase de cierre del proyecto, mediante las siguientes tareas: 1) Decisiónde cierre del proyecto y 2) Manual de mantenimiento.

1) Decisión de finalización del proyectoEsta tarea no está incluida en el modelo MoProSoft, sin embargo es una actividad fundamental

dentro de cualquier proyecto de una PyME.

Las métricas obtenidas de las diferentes etapas de pruebas son un indicador cuantificable

para las decisiones de aceptación o rechazo del proyecto. Se puede definir un límite máximo de

defectos en el software durante cada etapa. Si no se cuenta con información histórica para tomar

esta decisión, en la tabla 32 se presentan valores que a consideración del autor son adecuados para

cada etapa de pruebas. Estos valores fueron obtenidos con base a la experiencia en proyectos de

pruebas de gran magnitud y fueron corroborados con datos estadísticos de la industria del software.





Secundaria Importante Fundamental

Ventaja

competitiva

Pruebas Unitarias N/A N/A 30% 30%

Pruebas de Integración 35% 25% 10-15% 30%

Pruebas de Sistema 30% 20% 5-10% 10%Pruebas de Aceptación 30% 20% 2-5% 1%

Tipo de aplicación para el negocio.

Fase de pruebas

Tabla 32 - Número de pruebas fallidas permitidas.

2) Manual de mantenimiento

Un manual de mantenimiento de pruebas incluye un documento de rastreo de todos los módulos del

sistema con las pruebas que fueron ejecutadas para cubrir cada módulo. Este documento describe la

configuración de software y los ambientes usados para el desarrollo y para las pruebas, brindando

así información básica para realizar el mantenimiento de cada módulo y funcionalidad del sistema.

Además de la lista de ambientes para cada tipo de pruebas es necesario agregar los

documentos usados para crear y ejecutar los casos de prueba, (incluyendo los datos de prueba), así como el registro de rastreo para validar la cantidad de casos de prueba que es necesario ejecutar

para actualizar o crear un módulo similar en proyectos posteriores.





III. PRUEBA DE SOFTWARE: CONCEPTOSBÁSICOSLa teoría de pruebas se refiere a la base conceptual de las actividades a realizar dentro de un

proceso de ejecución de pruebas a un proyecto de software. Dentro del mercado existen 2 institutos

que proporcionan mejores prácticas para realizar las actividades de pruebas de software:

El Comité Internacional de Certificación de Pruebas de Software ( International Software

Testing Qualifications Board - ISTQB), y

La Organización Internacional para la Estandarización (International Organization for

Standarization - ISO).

El ISTQB define 3 objetivos [2] generales a perseguir con la realización de las pruebas:

Descubrir defectos

Ganar confianza en el nivel de calidad, y al proveer información

Prevenir defectos

Glenford J. Myers define el proceso de pruebas como: “ El proceso de ejecutar un programa

con la intención de encontrar errores” [3].

Los términos error (error), falta (fault) y falla (failure) algunas veces se usan como sinónimos y

otras no. Siguiendo las definiciones de IEEE [4] se pueden definir de la siguiente manera:

a. Error: tiene dos acepciones. Una de ellas hace referencia a la diferencia entre el valor obtenido

y el valor esperado (correcto) de un producto de software. La otra hace referencia a la acción de

una persona que se refleja en una falta o defecto en el producto de software, en cualquiera delas fases del desarrollo.

b. Falta (fault): es una condición que origina que un sistema falle en la ejecución de sus funciones.

Es la razón básica para que el mal funcionamiento del software. Es sinónimo de bug. Puede

verse como una variación de la segunda definición de error.

c. Falla (failure): es la incapacidad de un producto de software para ejecutar una función requerida

de acuerdo a las especificaciones. Una falla ocurre cuando el comportamiento es diferente del

esperado. Las fallas pueden tener causas funcionales o de desempeño. Una falla se produce sólo

si hay una falta en el sistema. La presencia de faltas no garantiza una falla. Es posible que unafalla ocurra y no sea detectada.

III.1 Pruebas estáticas y dinámicasDentro de la teoría de pruebas estos dos tipos difieren en gran medida una de la otra, debido al

momento en que se realizan:





III.1.1 Pruebas estáticas

El ISTQB indica que las pruebas estáticas son validaciones que se realizan sin necesidad de

ejecución del software y pueden ser manuales o automatizadas. En esta categoría se encuentran las

revisiones de documentos, la revisión del diseño estructural del sistema, la validación del diseño

funcional y las inspecciones de código.

Para realizar las pruebas estáticas de manera manual existen técnicas de validaciones talescomo: la revisión de ambigüedades y las revisiones grupales.

Un caso específico de una validación automática es la ejecución de un compilador, sistema

que verifica la sintaxis y las diferentes operaciones inmersas en el código entregando mensajes de

error si descubre un defecto, aquí el software que se está creando no es ejecutado.

II.1.2 Pruebas dinámicas:

Estas pruebas se realizan solamente cuando se está ejecutando el software, y se basan en el

comportamiento de éste conforme a las condiciones de entrada y resultados esperados, aquí se

encuentran las pruebas de caja blanca y las pruebas de caja negra.

Pruebas de caja blanca

Estas pruebas se basan en la comprobación de la forma en que el sistema realiza las operaciones

para obtener los resultados deseados. Las pruebas de caja blanca se distinguen en la visibilidad

interna del sistema para quien las realiza, por lo tanto la misma persona tiene el conocimiento del

software y tiene acceso al código fuente para desarrollar los casos de pruebas (ver figura 13).

Figura 13. Pruebas de Caja Blanca.

Un ejemplo de pruebas de caja blanca es en la etapa de codificación, en la cual el

programador escribe una porción del código y posteriormente lo ejecuta para validar su operación.





Con las pruebas de caja blanca se “prueba” la implementación del programa. Es decir, se

ejecutan todas las estructuras algorítmicas y todas las estructuras de datos del programa. Por esta

característica, a estas pruebas también se las conoce como pruebas de estructuras.

Para probar la estructura de un programa se requieren casos de pruebas que cubran todas las

estructuras. Los criterios propuestos en general son precisos, debido a la naturaleza misma de las

estructuras que es formal y precisa. Algunos criterios para pruebas estructurales son [6]:a. Pruebas basadas en el flujo de control

b. Pruebas basadas en el flujo de datos

c. Pruebas de mutación

Algunas de las ventajas de estas pruebas son:

Pruebas enfocadas. El programador puede probar el sistema por piezas, él puede escribir

código especial que ingrese valores específicos en un módulo aislado y puede reportar

resultados inmediatos obtenidos en cada módulo.

Cobertura de pruebas. Se puede determinar cuáles partes del programa son verificadas por

cada prueba y así le es más fácil entender cuales líneas de código, bloques o rutas del sistemano han sido probadas.

Control de ejecución. Se conoce exactamente el siguiente paso que debe de ejecutar el

programa de acuerdo a su estado actual. Se puede ejecutar el programa para recibir informes

constantes de lo que está haciendo en cada momento, para esto existen herramientas tales como

los debuggers y la ejecución manual del código (corridas de escritorio).

Integridad de datos. El programador conoce qué partes del sistema deberían de modificar un

objeto o un dato específico, además puede rastrear cada dato dentro de cada paso del sistema

con el fin de determinar si existe una manipulación inadecuada de éstos.

Límites internos. Gracias a las pruebas de caja blanca, el programador puede conocer los

límites internos del código que no son visibles a un ejecutor de pruebas (tester) de caja negra,

tales como capacidad de manejo de datos por los objetos, número de valores almacenados en

buffers, etc.

Pruebas de caja negra

Son pruebas que se centran en validar los resultados del sistema en base a los datos de entrada, sin

importar lo que sucede dentro del sistema (figura 14). Este tipo de pruebas intenta encontrar errores

tipo:

1. Detectar funciones incorrectas o faltantes.

2. Errores en interfaces.

3. Errores en accesos a bases de datos externas.4. Errores de desempeño.

5. Errores de inicialización o terminación.





Sistema

Figura 14. Pruebas de Caja Negra.

Las pruebas de caja negra se ejecutan después de que el sistema es programado, mediante

un proceso de entrega de versiones, validación de éstas y registro de errores. Es de esperarse que

existan varias versiones, debido a que dentro de cada una puede haber errores que no se habían

detectado, debido a 2 diferentes causas:

1. Errores colaterales creados al resolver los de la versión previa.

2. Errores que aparecen al ejecutar una parte que sólo es accesible después de corregir una parte

del sistema

Es necesario repetir los ciclos de validación de versiones hasta que el sistema sea lo

suficientemente confiable como para salir a producción. Dentro de estas pruebas se encuentran las

pruebas de Sistema y las pruebas de Aceptación de usuario.

Algunas de las técnicas de caja negra más usadas son [6]:

a) Clases de equivalencias

b) Análisis de valores límites

c) Gráfica de causa-efecto

d) Casos especiales

III.2 RequerimientosEn esta sección se presentan algunos conceptos relacionados a los requerimientos que deben tenerse

en cuenta para la realizar las pruebas en la etapa de análisis. Existen dos tipos diferentes de

especificación de requerimientos:

III.2.1 Requerimientos a alto nivel

Integra el listado de todos los requerimientos que el sistema tiene que cumplir dentro de un

documento formal llamado “Especificación de requerimientos”. Aquí cada petición es ordenada por

módulo cubriendo las diferentes categorías definidas en [5].

a) Funcionales

Grupo de requerimientos que se enfocan en describir lo que se supone que el producto deba derealizar, estos requerimientos se pueden especificar a nivel de sistema o a nivel de usuario. Dentro

de un nivel más alto de descripción, estos requerimientos deben de contener el alcance específico de

las funciones que el producto debe de realizar.

b) InterfacesDescriben las entradas desde sistemas externos y las salidas también a sistemas externos, se pueden

incluir constantes en los datos, formatos o medios que apliquen a estas interfaces.





c) DatosHace referencia a los datos de entrada y salida válidos, que el sistema permite y puede administrar,

los formatos que se necesitan y los datos que se requiere almacenar, así como la exactitud deseada

para los cálculos realizados dentro de las operaciones a ejecutar.

d) RendimientoEstos requerimientos describen los tiempos y escalamientos que el sistema debe de cumplir, tales

como: qué tan bien debe de comportarse el sistema en términos de número de usuarios simultáneos,

cantidad de transacciones por unidad de tiempo y el tiempo máximo que un usuario debe de esperar

una respuesta a una petición. Se debe de prestar especial atención al cuantificar estos

requerimientos para que puedan ser evaluados.

e) Usuarios y el Factor HumanoDeterminan al tipo de persona que usará el sistema, en términos de sus habilidades y

entrenamiento, así como la facilidad de uso de las diferentes funciones del sistema. Por ejemplo,

cuantas acciones discretas son requeridas para ejecutar una operación común, y qué tan clara es la

respuesta del sistema a cada acción.

f) SeguridadDescribe como será controlado el acceso al sistema y a sus datos, también puede incluir como se

realizarán las copias de seguridad del sistema (respaldos), así como la frecuencia y los medios en

los que se almacenarán.

g) DocumentaciónDefine los documentos que se requerirán, tanto impresos como electrónicos, así como la audiencia

objetivo de cada uno de ellos. Aquí se incluyen los formatos que se generan en el sistema y aquellosque se entregan de manera estática en la instalación de éste.

h) Tolerancia a FallosEstos requerimientos describen el comportamiento que el sistema debe mostrar para responder a las

fallas. Puede indicar si el sistema debe detectar fallas y emitir alarmas cuando se presente un

problema, así mismo el sistema puede reaccionar a un tiempo máximo entre fallas y/o un límite en

el tiempo en que se puede estar fuera de línea.

i) MantenimientoRequerimientos que se relacionan a la manera en que serán resueltos los problemas encontrados en

el sistema, la forma en que se entregarán las actualizaciones del software al cliente final y cómo es

que los usuarios ejecutarán dichas actualizaciones.

j) Calendarios de entregaEn caso de que los requerimientos puedan ser priorizados, una herramienta muy útil es definir un

calendario de entregas que muestre cuáles requerimientos serán finalizados en cada una de las

versiones planeadas.





III.2.2 Requerimientos detallados

La especificación de requerimientos por categoría se re-escribe desde la perspectiva del diseñador

de sistemas y en un lenguaje o notación que se enfoca y beneficia al equipo de desarrollo,

almacenando el resultado en un nuevo documento llamado “especificación funcional del sistema”.La especificación no es una re-escritura, sino una actualización completa, agregando el

detalle suficiente mediante el desglose de cada requerimiento original en uno o varios más técnicos.

Por ejemplo, relacionado con las interfaces de usuario, la especificación se centra en el determinar a

nivel técnico los detalles de operación de las pantallas del sistema incluyendo elementos como:

tiempo de respuesta, descripción detallada de cada pantalla, funcionamiento explícito de cada

pantalla, etc.

III.3 Planeación de pruebasDentro de la planeación de pruebas se encuentran varios elementos que sirven de soporte tanto a la

administración de la empresa, como al líder del proyecto.

III.3.1 Condiciones de pruebas

Se define como un objeto o evento que debe verificarse por uno o más casos de prueba. Durante la

planeación de las pruebas se analiza la documentación base para determinar todas las condiciones

que serán validadas. Un ejemplo de condiciones de pruebas es: validar que el sistema puede

responder a las transacciones de 1000 usuarios simultáneos en menos de 0.01 segundo.

III.3.2 Cobertura de las pruebas

La cobertura de pruebas es un documento formal donde se indica el porcentaje de pruebas que se

realizarán dentro de cada una de las fases. Esta definición es muy útil debido a que nunca es

posible validar cada uno de los diferentes comportamientos que debe cumplir el sistema, por

ejemplo, no es posible validar cada uno de los valores flotantes comprendidos entre 0 y 100.

La cobertura de pruebas ayuda a determinar los costos, tiempos y recursos que se

requerirán dentro del proyecto.

II.3.3 Criterios de entrada y salida

Desde la planeación de pruebas es indispensable determinar aquellas condiciones de entrada y

salida para cada fase de pruebas.

Los criterios de entrada generalmente se componen de la ejecución exitosa de alguna etapa

previa o de la entrega de una serie de documentos que permitan comenzar con cada fase.

Los criterios de salida definen cuándo deben de detenerse las pruebas, ya sea porque se ha

llegado al final del proceso determinado, o cuando el software ha cubierto una meta específica.

Algunos de los criterios de salida comunes son:

Métricas robustas en cuanto a cobertura de código, funcionalidad o riesgo.

Estimaciones confiables en la densidad de defectos.

Costos.

Riesgos residuales, como defectos no resueltos o falta de cobertura de pruebas en ciertas áreas.





Agendas apretadas para la puesta en producción del sistema.

III.4 Actividades comunes de pruebasExisten diferentes actividades de pruebas que se ejecutan en varias partes del ciclo de vida del

proyecto.

III.4.1 Registro de rastreo

Desde el punto de vista de pruebas, un Registro de rastreo es un documento que contiene una lista

enlazada de requerimientos que el sistema debe cumplir contra los tipos de prueba y concretamente

los casos de prueba que se ejecutarán en la fase de pruebas del proyecto. El objetivo fundamental de

este registro de rastreo es el de mostrar de manera visual la cobertura de pruebas para el software,

con este documento es muy sencillo determinar aquellos requerimientos que no han sido cubiertos

de manera adecuada, y en caso de requerirlo se puede tomar una decisión informada del impacto

que se tendrá en la validación de la funcionalidad en caso de que se decida acortar el ciclo de

pruebas.

Con este registro de rastreo también es posible obtener datos a nivel gerencial (producirmétricas reales del avance de las pruebas en el proyecto, llevar a decisiones para asignar

prioridades de manera informada, etc.), gracias a esto el gerente del proyecto puede elaborar

escenarios de cobertura de pruebas, incluyendo riesgos y beneficios de modificar el alcance original

de la fase, una decisión muy importante para no perder el control de la calidad del software final.

Existen varias maneras de administrar un Registro de rastreo, desde la más simple en papel

hasta algunas un tanto complejas que se incluyen dentro de herramientas comerciales de pruebas.

III.4.2 Casos de prueba

Un caso de prueba es un documento u objeto donde se detallan los pasos a seguir para lograr la

validación de una funcionalidad trabajando de manera correcta. Existen diferentes tipos y nivelesde casos de prueba, según el detalle de los pasos a realizar. Es decir, pueden existir casos de prueba

que muestren paso por paso las acciones a realizar para validar un objeto y pueden existir otro tipo

de casos de prueba donde las acciones a realizar se muestran como un listado dentro de una tabla

adicional.

Un caso de prueba debe de cubrir una o varias condiciones de prueba, por lo que es

necesario tenerlas listadas para desarrollar adecuadamente el caso.

III.4.3 Definición de escenarios

Un escenario es un caso de pruebas enfocadas a validar varias condiciones por más de una ocasión

y enfocándose en un ciclo completo de negocio, estos casos son utilizados generalmente en las

pruebas de aceptación de usuario ya que brindan las condiciones de operación reales del sistema.

III.4.4 Datos de prueba

Los datos son un recurso fundamental en el desarrollo de cada fase de pruebas, si se puede mantener

una administración completa de ellos es más fácil determinar si se están obteniendo los resultados

adecuados durante la fase de ejecución, además ayudará a que el tiempo perdido por falta de datos,

o por tener datos erróneos sea el mínimo.





III.4.5 Elaboración de documentos de pruebas

Existen diferentes documentos que se entregan durante las etapas de las que constan las pruebas de

un software, tales como:

Administración de defectos.

Administración de versiones. Herramientas de cobertura de pruebas.

Plan de adquisiciones y capacitación de pruebas.

Equipo de trabajo.

Costos.

Descripción de requerimientos.

Plan de pruebas de sistema.

Reporte de pruebas de sistema.

Plan de pruebas de integración.

Reporte de pruebas de integración.

Manual de mantenimiento.

III.4.6 Herramientas de software de pruebas

Son programas de software especializados en la teoría de pruebas que se encargan de realizar de

manera automática algunas de las actividades que pueden llevar la mayor parte del tiempo para una

organización de pruebas, se encuentran divididos en los siguientes:

Administrador de ejecuciones de pruebas: sistemas que mantienen un control total de un

proyecto de pruebas, incluyendo captura automática de métricas, administración de defectos,

cobertura de pruebas, etc.

Realización de pruebas automáticas: como su nombre lo indica, este software se encarga de

realizar la validación completa de las pruebas de nuevos sistemas, existen 2 tipos diferentes: los

que se encargan de grabar y reproducir las acciones del usuario, y los que ejecutan la

automatización en base a tablas de acciones pre-definidas.

Soporte en la toma de decisiones en la cobertura de pruebas: herramientas que en base a análisis

estadísticos y decisiones de inteligencia artificial permiten determinar el tamaño de las pruebas

que se necesitan realizar para llegar al porcentaje indicado de cobertura del software.

Creación de datos aleatorios para pruebas: sistemas que tienen 2 funciones en específico:

Crear una base de datos que cumplan con las características de negocio indicadas por el

usuario, con el fin de disminuir el tiempo requerido para obtener información confiable de

entrada de acuerdo a la prueba que se desee realizar

Conversión de datos reales a datos de pruebas: realizan una modificación carácter porcarácter de la información de un ambiente real de ejecución para obtener datos codificados,

estos programas son muy útiles cuando el manejo de la información es restringida y se

requiere también la creación de un número grande de datos para realizar la actividad de

pruebas.

Validación de código: es el software más común para realizar las pruebas, comúnmente

llamados compiladores, se encargan de realizar validaciones a nivel sintáctico y semántico del

código creado por el programador en base a un lenguaje determinado.





Existe una cantidad muy grande de programas que cumplen alguna de las características arriba

mencionadas, generalmente son costosos, aunque es muy probable que se pueda encontrar

herramientas de software libre que cubran con las necesidades de pruebas.

III.5 Ciclos de pruebasLos diferentes ciclos de pruebas que forman parte de la teoría general se enfocan cada uno en lograr

un objetivo concreto dentro de la validación total del proyecto.

III.5.1 Pruebas unitarias

El objetivo de las pruebas unitarias es el de disminuir errores de programación en los niveles más

básicos del proyecto, evitando reproducir defectos en los componentes superiores y por lo tanto se

disminuyen errores en las fases posteriores. Estas pruebas se realizan dentro de cada uno de los

componentes del sistema e incluyen pruebas estáticas y dinámicas.

Debido a su naturaleza, es la fase más rápida de pruebas en cuanto al tiempo que pasa entre

que se descubre un defecto y que se resuelve, por lo mismo es difícil mantener un registro detallado

de las acciones tomadas para validar cada parte del sistema.

III.5.2 Pruebas de integración

Las pruebas de integración validan el funcionamiento en conjunto de varios objetos del sistema o de

alguna parte del sistema con otros sistemas, tales como: sistema operativo, sistemas de archivos,

hardware o interfaces entre sistemas.

Para esta fase es necesario conocer el detalle del comportamiento que tendrá cada objeto al

integrarse a algún otro. Estas pruebas son realizadas por los programadores y debido a esto, al igual

que en las pruebas unitarias, las de integración tienen un tiempo corto entre la detección del defecto

y la resolución de éste.

Existe más de un nivel de pruebas de integración que pueden ser ejecutados en objetos detamaños diversos, por ejemplo:

Las pruebas de integración que validan las interacciones entre los diferentes componentes de

software creados en la fase de codificación

Las pruebas de integración que validan las interacciones entre sistemas diferentes y pueden ser

realizadas después de las pruebas de sistema. En este caso, la organización que desarrolla debe

tomar control de un lado de las interfaces para garantizar la validación del funcionamiento

independiente y total de éstas. Los procesos de negocio implementados pueden contener

diversas series de sistemas y diversas plataformas de software.

En cada etapa de este proceso, los testers se deben de concentrar únicamente en la integraciónen sí, por ejemplo, si ellos se encuentran integrando el módulo A con el módulo B, deben de estar

interesados en validar la comunicación entre ambos, no en la funcionalidad de cada uno.

Idealmente los testers deberían de entender la arquitectura del sistema para poder ejecutar las

pruebas, con esto se logra una fase más eficiente.





III.5.3 Pruebas de sistema

Las pruebas de sistema se centran en el comportamiento de un sistema o producto completo tal

como se define en el alcance del desarrollo del proyecto o programa. En estas pruebas, los

ambientes de prueba deben corresponder al ambiente final de producción tanto como sea posible,

para poder minimizar el riesgo de fallas específicas de ambientes no encontradas en una ejecución

simple.También pueden validar requerimientos funcionales y no funcionales del sistema. Todo

requerimiento debe existir como texto y/o modelos. El tester también necesita lidiar con

requerimientos incompletos o poco documentados.

Las pruebas de sistemas empiezan usando una especificación basada en técnicas de caja

negra para validar cada aspecto del sistema, por ejemplo: podrían partir de una tabla de decisiones

que contiene combinaciones de los efectos requeridos por las reglas del negocio. Así mismo, esta

fase de pruebas debería ser desarrollada por un equipo ajeno a la programación del sistema, con el

objeto de fortalecer la imparcialidad de las mismas.

III.5.4 Pruebas de aceptación de usuario

Estas pruebas son comúnmente responsabilidad de los clientes o usuarios del sistema, así mismo,

cualquier persona interesada en el sistema debería de estar involucrada, tales como: inversionistas,

directores de la empresa, etc.

El objetivo de las pruebas de aceptación es la de establecer confianza en el sistema, partes

del sistema o características específicas de éste. Buscar defectos no es el principal foco de atención

de estas pruebas, sino el validar el desenvolvimiento del sistema y su uso final, al mismo tiempo

que no es necesario un nivel final de pruebas, por ejemplo, una integración masiva de los diferentes

elementos del sistema deberían de realizarse después de las pruebas de aceptación. Estas pruebas

deben de abarcar más de un sólo nivel de pruebas, por ejemplo:

Un software debe validarse con pruebas de aceptación cuando es integrado o instalado en sulugar final.

Las pruebas de aceptación enfocadas en la usabilidad de los componentes deben de ejecutarse

durante las pruebas de componentes

Las pruebas de aceptación de adaptaciones en la funcionalidad actual deberían de venir después

de las pruebas de sistema.

Pruebas comunes dentro de esta fase son:

Pruebas de restablecimiento y recuperación.

Pruebas de desastres.

Administración de usuarios. Tareas de mantenimiento.

Validaciones periódicas de vulnerabilidades de seguridad.





REFERENCIAS

[1] Modelo de Procesos para la Industria de Software (MoProSoft). Comunidad MoProSoft.

Disponible en: http://comunidadmoprosoft.org.mx/

[2] Müller, Thomas, Black, Rex, Eldh, Sigrid, Graham Dorothy, Olsen, Klaus, Pyhäjärvi Maaret,Thompson Geoff y van Veendendal Erik (2005), Certified Tester Foundation Level SyllabusV2007, Actualizado el 12 de abril de 2007, ISTQB, pp. 12-28. Disponible en World Wide Web:http://www.istqb.org/downloads/syllabi/SyllabusFoundation.pdf

[3] MYERS, Glenford J. (2004), The art of Software Testing, 2da Ed. John Wiley & Sons, Inc,

New Jersey, USA, pp. 6.

[4] IEEE Software Engineering Standards. Technical Report, 1987.

[5] Culbertson, Robert, Brown, Chris y Cobb, Gary (2002), Rapid Testing 1era Edición, USA:Prentice-Hall, pp. 32 y 33.

[6] Jalote, Pankaj. An Integrated Approach to Software Engineering. Springer. Third Edition, 2005.