METODOLOGA PARA LA REALIZACIN DE PRUEBAS DE SOFTWARE

Juan David Rodrguez Jaramillo

Paula Andrea Lpez Gutirrez



Trabajo de grado para optar al ttulo de
Ingeniero de Sistemas




Asesor
RAFAEL RINCN BERMDEZ
Magster en Matemticas Aplicadas
Magster en Sistemas de Calidad





DEPARTAMENTO DE INFORMATICA Y SISTEMAS
ESCUELA DE INGENIERA
UNIVERSIDAD EAFIT
MEDELLN
2004
TABLA DE CONTENIDO
INTRODUCCIN ............................................................................................................. 6
1. QU ES CALIDAD................................................................................................... 9
2. QU SON LAS PRUEBAS................................................................................... 12
3. IMPORTANCIA DE LAS PRUEBAS DE SOFTWARE..................................... 13
4. FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE.................................. 16
5. TCNICAS DE DISEO DE CASOS DE PRUEBAS ...................................... 18
6. ESTRATEGIAS DE PRUEBA DEL SOFTWARE.............................................. 32
6.1 Pruebas de unidad ............................................................................................. 32
6.2 Pruebas de integracin...................................................................................... 33
7. LOS MODELOS INTERNACIONALES Y LAS PRUEBAS.............................. 34
8. METODOLOGA DE PRUEBAS DE SOFTWARE ........................................... 38
FASE 1: PLANEAR....................................................................................................... 39
1. RECOLECCIN DE INFORMACIN................................................................. 40
1.1 Preparacin de la entrevista .............................................................................. 40
1.1.1 Identificar los participantes....................................................................... 40
1.1.2 Definir la Agenda...................................................................................... 41
1.2 Desarrollo de la entrevista ................................................................................ 41
1.2.1 Entender el proyecto ................................................................................. 42
1.2.2 Entender los objetivos del proyecto.......................................................... 43
1.2.3 Entender la planeacin del proyecto......................................................... 43
1.2.4 Conocer la metodologa de desarrollo ...................................................... 44
1.2.5 Conocer las reglas de negocio................................................................... 45
1.2.6 Anlisis de riesgos .................................................................................... 46
1.3 Reporte de resultados........................................................................................ 46
1.3.1 Resumen de la entrevista .......................................................................... 46
1.3.2 Resultados de la entrevista........................................................................ 47
2. PLANEACIN DE LAS PRUEBAS..................................................................... 48
2.1 Definir el identificador del plan........................................................................ 48
2.2 Preparar la introduccin.................................................................................... 49
2.3 Identificar los requerimientos ........................................................................... 49
2.4 Identificar los tipos de prueba........................................................................... 50
2.5 Identificar cundo terminar las pruebas............................................................ 51
2.6 Establecer la estrategia de pruebas de regresin............................................... 52
2.7 Definir los entregables ...................................................................................... 52
2.8 Organizar el equipo de pruebas......................................................................... 54
2.9 Establecer el ambiente de pruebas .................................................................... 55
2.10 Seleccionar las herramientas de pruebas........................................................... 56
2.11 Programar las pruebas....................................................................................... 56
2.12 Establecer los procedimientos para el registro de errores................................. 56
2.13 Definicin de los objetivos de las mtricas....................................................... 58
2.14 Revisar y aprobar el diseo............................................................................... 60
2.14.1 Programar y preparar la revisin............................................................... 60
2.14.2 Aprobacin................................................................................................ 61
FASE 2: HACER ........................................................................................................... 62
3. DISEO DE CASOS DE PRUEBA. .................................................................... 63
2
3.1 Disear las pruebas de funcin. ........................................................................ 63
3.1.1 Refinar los requerimientos de pruebas funcionales. ................................. 63
3.1.2 Construir una matriz de funcin/prueba ................................................... 66
3.2 Disear pruebas de GUI. (Interfaz grfica de usuario) ..................................... 67
3.2.1 Definir componentes GUI de la aplicacin............................................... 68
3.2.2 Disear pruebas de GUI............................................................................ 70
3.3 Definir las pruebas de sistema y de aceptacin. ............................................... 71
3.3.1 Identificar las pruebas potenciales del sistema ......................................... 71
3.3.2 Disear pruebas de fragmentos del sistema. ............................................. 73
3.3.3 Identificar pruebas potenciales de Aceptacin ......................................... 73
3.4 Revisar y aprobar el diseo............................................................................... 74
3.4.1 Programar y preparar la revisin............................................................... 74
3.4.2 Aprobacin................................................................................................ 74
4. DESARROLLO DE LAS PRUEBAS.................................................................... 75
4.1 Desarrollar formatos de pruebas ....................................................................... 75
4.1.1 Desarrollar formatos de pruebas de GUI .................................................. 75
4.1.2 Desarrollar formatos de las pruebas de fragmentos del sistema............... 76
4.2 Revisar y aprobar el desarrollo de las pruebas.................................................. 77
4.2.1 Programar y preparar la revisin............................................................... 77
4.2.2 Aprobacin................................................................................................ 77
FASES 2 y 3: HACER Y VERIFICAR......................................................................... 78
5. EVALUACIN Y EJECUCIN DE LAS PRUEBAS. ........................................ 79
5.1 Ejecucin y Documentacin de las pruebas. (HACER) .................................. 79
5.1.1 Ejecucin de las pruebas de regresin. ..................................................... 79
5.1.2 Ejecutar una nueva sesin de pruebas....................................................... 80
5.1.3 Documentar los defectos arrojados por las pruebas.................................. 80
5.2 Evaluacin de las pruebas. (VERIFICAR) ...................................................... 81
5.2.1 Analizar las mtricas................................................................................. 81
5.2.2 Refinar el cronograma de pruebas. ........................................................... 82
5.2.3 Identificar los cambios en requerimientos. ............................................... 83
FASE 4: ACTUAR.......................................................................................................... 84
6. PREPARAR LAS SIGUIENTES PRUEBAS...................................................... 85
6.1 Refinar las pruebas............................................................................................ 85
6.1.1 Actualizar la matriz funcin / prueba....................................................... 85
6.1.2 Actualizar las pruebas de fragmentos del sistema. ................................... 85
6.1.3 Actualizar las pruebas de aceptacin. ....................................................... 85
6.2 Examinar el equipo y el ambiente de pruebas .................................................. 86
6.2.1 Evaluar el equipo de prueba...................................................................... 86
6.2.2 Evaluar el ambiente de pruebas ................................................................ 86
6.3 Publicar reportes intermedios ........................................................................... 87
FASES 1,2,3 y 4: PLANEAR, HACER, VERIFICAR Y ACTUAR........................... 90
7. DIRIGIR LAS PRUEBAS DEL SISTEMA........................................................... 91
7.1 Completar el plan de pruebas del sistema......................................................... 91
7.1.1 Finalizar los tipos de prueba del sistema .................................................. 91
7.1.2 Programar pruebas del sistema ................................................................. 92
7.1.3 Equipo para las pruebas del sistema ......................................................... 92
3
7.1.4 Estabilizar el ambiente de pruebas:........................................................... 93
7.2 Tipos de pruebas del sistema ............................................................................ 94
7.2.1 Pruebas de rendimiento............................................................................. 94
7.2.2 Pruebas de seguridad................................................................................. 96
7.2.3 Pruebas de volumen.................................................................................. 97
7.2.4 Pruebas de estrs....................................................................................... 97
7.2.5 Pruebas de compatibilidad........................................................................ 97
7.2.6 Pruebas de Documentacin....................................................................... 98
7.2.7 Pruebas de Backup y Recuperacin.......................................................... 99
7.2.8 Pruebas de instalacin............................................................................... 99
7.3 Revisar y aprobar las pruebas del sistema. ....................................................... 99
7.3.1 Programar y preparar la revisin............................................................... 99
7.3.2 Aprobacin.............................................................................................. 100
7.4 Ejecutar las pruebas del sistema ..................................................................... 100
7.4.1 Volver a probar fallos anteriores del sistema.......................................... 100
7.4.2 Ejecutar las pruebas del sistema. ............................................................ 101
7.4.3 Documentar los defectos arrojados por las pruebas................................ 101
8. DIRIGIR LAS PRUEBAS DE ACEPTACIN................................................... 102
8.1 Completar la planeacin de las pruebas de aceptacin. .................................. 102
8.1.1 Identificar los tipos de pruebas de aceptacin. ....................................... 102
8.1.2 Finalizar el cronograma de las pruebas de aceptacin............................ 102
8.1.3 Organizar el equipo de pruebas de aceptacin........................................ 104
8.1.4 Establecer el ambiente de pruebas de aceptacin. .................................. 104
8.1.5 Instalar las herramientas para las pruebas de aceptacin........................ 105
8.2 Completar los casos de pruebas de aceptacin. .............................................. 106
8.2.1 Identificar el subconjunto de pruebas del sistema que se utilizarn para
pruebas de aceptacin. ............................................................................................ 106
8.2.2 Disear y escribir pruebas de aceptacin adicionales............................. 107
8.3 Revisar el plan de pruebas de aceptacin. ...................................................... 107
8.3.1 Programar y llevar a cabo la revisin. .................................................... 107
8.3.2 Aprobar el plan de pruebas de aceptacin. ............................................. 108
8.4 Ejecutar las pruebas de aceptacin. ................................................................ 108
8.4.1 Ejecutar las pruebas de aceptacin de los errores encontrados en las
pruebas anteriores. .................................................................................................. 108
8.4.2 Ejecutar las actuales pruebas de aceptacin............................................ 109
8.4.3 Documentar los defectos de aceptacin. ................................................. 110
9. RESUMEN DE PRUEBAS Y REPORTE FINAL............................................. 111
9.1 Resumen y consolidacin de la informacin de pruebas. ............................... 111
9.1.1 Pruebas ejecutadas y terminadas............................................................. 111
9.1.2 Consolidar los errores por casos de prueba y funciones. ........................ 111
9.1.3 Documentar errores no corregidos.......................................................... 111
9.2 Reporte final.................................................................................................... 112
9.2.1 Resumir las actividades y eventos durante el desarrollo de las pruebas. 112
9.3 Crear y analizar grficos de mtricas.............................................................. 112
9.4 Conclusiones y Recomendaciones.................................................................. 120
9.4.1 Programar y preparar la revisin............................................................. 120
4
9.4.2 Aprobacin.............................................................................................. 120
CONCLUSIONES......................................................................................................... 122
BIBLIOGRAFA........................................................................................................... 125










































5


INTRODUCCIN

Actualmente en la mayora de empresas desarrolladoras de software se est
elaborando y entregando software que presenta una gran cantidad de errores, si
bien es un problema que se puede presentar por diversas razones como las
malas prcticas de programacin o un proceso a veces desorganizado que se
lleva en la construccin del software, entre otros, es un problema que crece cada
vez ms, en la medida en que no se aplica un completo y efectivo proceso de
pruebas en ninguna de las fases del desarrollo, permitiendo as que los
productos tengan errores y no satisfagan completamente los requerimientos del
usuario. Esto afecta en gran medida los procesos que se llevan a cabo tanto en
la empresa desarrolladora como en el cliente y finalmente la imagen proyectada
a ste.

Los procesos de ambas empresas (desarrolladora y cliente) se ven afectados ya
que frecuentemente se ve la necesidad de devolver los productos que
supuestamente han sido terminados exitosamente, debido a que presentan
varios tipos de errores, estos pueden ser tan pequeos que simplemente se
tienen en cuenta para futuras entregas, o pueden ser tan graves que afecten la
funcionalidad del sistema e impliquen hacer un reproceso del desarrollo que
haba sido llevado a cabo con anterioridad, lo que hace que no se entregue el
trabajo a tiempo y que se acumulen otros y por ende que aumenten los costos,
no slo para el cliente sino tambin para la empresa.

Finalmente, se observa que los problemas que se generan durante todas las
fases del desarrollo y que generan los errores y el no cumplimiento de los
requerimientos iniciales, se ven aumentados con la falta de una metodologa
clara para la realizacin de pruebas del software. Esto hace que los productos
no sean correctos ni confiables.

6
Por tanto, es indispensable implementar una metodologa clara y que se pueda
integrar con la diferentes metodologas de desarrollo para lograr detectar y
corregir las fallas y problemas durante las distintas fases del ciclo de vida del
software, y lograr as cumplir con los requerimientos especificados para los
productos.

En este proyecto, se contemplan varios aspectos relacionados con la realizacin
de pruebas antes del desarrollo de la metodologa.

En los primeros captulos, se hablar del concepto de calidad de software y la
importancia que tiene sta en los proyectos y productos desarrollados. Se habla
tambin acerca de qu son las pruebas de software, los principios y los objetivos
de las pruebas y las tcnicas de diseo de los casos de prueba como son:
pruebas de caja blanca, caja negra, etc.

En el capitulo 6, trataremos acerca de los modelos internacionales y las pruebas,
y cmo las caractersticas mencionadas se relacionan con la metodologa
propuesta.

Por ltimo, se explican cada uno de los pasos de la metodologa desarrollada,
basada en el ciclo PHVA, Planear, Hacer, Verificar y Actuar.

La fase Planear, comienza con la definicin de los objetivos de las pruebas o
lo que se espera como resultado del proceso de pruebas. Se describen los
elementos de la estrategia de pruebas y el plan de pruebas.

La fase Hacer, describe como disear y ejecutar los casos de pruebas
incluidos en el plan de pruebas.

7
La fase Verificar, comprende la importancia de la evaluacin, las mtricas y los
reportes. En este punto se analizan los resultados que han arrojado los casos
de prueba ejecutados.

La fase Actuar, provee la gua para la actualizacin o realizacin de los casos
de prueba. Tambin sobre mejoras en los procesos o preparacin para un
nuevo ciclo de pruebas.


























8
1. QU ES CALIDAD


La calidad es un aspecto especialmente importante en el desarrollo de software.
El inters por la calidad es cada vez mayor, ya que los clientes se vuelven ms
selectivos y comienzan a rechazar los productos poco fiables o que realmente
no dan respuesta a sus necesidades.

A la hora de definir la calidad del software se pueden adoptar diferentes
conceptos.

La calidad del software es el grado con el que un sistema, componente o
proceso cumple los requerimientos especificados y las necesidades o
expectativas del cliente o usuario
1


Concordancia con los requerimientos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo
software desarrollado profesionalmente.
2


El estndar de la IEEE para la calidad de software define el trmino calidad del
software como:
3


La totalidad de rasgos y caractersticas de un producto de software que se
refieren a su habilidad para satisfacer necesidades especficas.

El grado en el cual el software posee una combinacin deseada de atributos.


1
IEEE, Std. 610-1990.
2
Pressman, Roger S. Ingeniera del software Un enfoque prctico. Quinta Edicin. 2002.
3
IEEE Std 729 1983. Glossary of Software Engineering Terminology
9
El grado en el cual un usuario o cliente percibe que el software cumple con sus
expectativas.

Las caractersticas del software que determinan el grado en el cual dicho
software en uso cumple con las expectativas del cliente.

Capacidad del producto software para satisfacer los requisitos establecidos
4


Lo que est claro a partir de estas definiciones es que la calidad es algo relativo.
Siempre va a depender de los requisitos o necesidades que se desee satisfacer.
Por eso, la evaluacin de la calidad de un producto siempre va a implicar una
comparacin entre unos requisitos preestablecidos y el producto realmente
desarrollado.

Tambin es importante diferenciar entre la calidad del producto de software y la
calidad del proceso de desarrollo. Las metas que se establezcan para la calidad
del producto van a determinar las metas a establecer para la calidad del proceso
de desarrollo, ya que la calidad del producto va a estar en funcin de la calidad
del proceso implementado. Sin un buen proceso de desarrollo es casi imposible
obtener un buen producto.

Es importante destacar que la calidad de un producto software debe ser
considerada en todos sus estados de evolucin (especificaciones,
requerimientos, anlisis, diseo, cdigo, ...). La meta es por consiguiente
prevenir defectos o inconsistencias desde los primeros pasos o etapas del
desarrollo. Para esto se deben seguir procesos asociados en alguna
metodologa de desarrollo. La Calidad de un producto de software no se
consigue evaluando ste cuando ya est terminado completamente, cuando los
problemas de calidad ya no tienen solucin o la solucin es muy costosa.


4
DoD 2168
10
El aseguramiento de la calidad rebaja los costos del desarrollo debido a que los
defectos se encuentran ms rpido y pueden ser corregidos. Aunque al principio
requiere mayor inversin, a largo plazo va a generar productos con mayor
calidad y menos costos de soporte y mantenimiento

El costo total del aseguramiento de la calidad se puede ver como la suma de
cuatro componentes, el primero es el costo de la prevencin, es decir, de las
acciones que se realizan para prevenir defectos en las etapas del desarrollo; el
segundo, es el costo de inspeccin, son aquellas acciones en que se mide, se
evala y se auditan los productos para que cumplan con los estndares y
especificaciones; el tercer componente es el costo que generan las fallas y los
errores encontrados antes de liberar el producto; y por ltimo el costo de los
errores que se detectan despus de liberado el producto. stos pueden ser los
ms graves, ya que deterioran la imagen de la compaa.

















11
2. QU SON LAS PRUEBAS

Los procesos de prueba o testing son una herramienta que asegura que un
sistema hace lo que tiene que hacer. Probar es una prctica habitual de todo
proceso productivo, que bsicamente consiste en comprobar que un producto
tiene las caractersticas deseadas. Prcticamente todos los productos que
llegan al mercado son probados: se "prueban" los materiales que van a forma
parte de un producto, se "prueba" que las partes a ensamblar tienen las
dimensiones adecuadas y se "prueba", por ejemplo, que el producto final tiene la
resistencia adecuada. Es decir, a lo largo del proceso productivo de cualquier
producto se hacen comprobaciones que hacen que el producto final sea el
adecuado.

En el caso del software ocurre lo mismo. El proceso de desarrollo de software
consta de una serie de etapas. En cada etapa se van desarrollando y
ensamblando partes que al final van a conformar el producto final. Al igual que
ocurre en un proceso productivo normal, cada una de estas partes debe ser
"probada". Al igual que ocurre en un proceso productivo, la naturaleza y el tipo
de pruebas a realizar con el software vara a media que el desarrollo avanza.












12
3. IMPORTANCIA DE LAS PRUEBAS DE SOFTWARE

El software se ha convertido en la base de los negocios modernos y de la
interconexin entre los miembros de una sociedad, pues se encuentra
estrechamente unido a todos los aparatos de nuestra vida cotidiana, por esta
razn, es necesario desarrollar software con calidad que se adapte a los
requerimientos de los usuarios para ser ms competitivos en el medio en que se
desenvuelven.

A medida que los equipos de desarrollo de software crecen y los proyectos se
vuelven ms complejos, las pruebas de calidad en aplicaciones evolucionan
mucho ms all de simplemente depurar la aplicacin para posteriormente
migrarla a produccin.

Los sistemas actuales han crecido en tamao, complejidad e importancia, cada
vez se hacen menos frecuentes los proyectos donde una sola persona es la
encargada de crear todo un sistema. Ahora se necesita todo un equipo de
personas que siguen alguna metodologa. En resumen, cada vez se hace ms
difcil crear y dar mantenimiento a un sistema, y an es ms difcil crear un
sistema con la calidad que requiere el ambiente altamente competitivo de las
organizaciones.

Para cualquier metodologa, la fase de Pruebas de Software es la actividad ms
visible en el proceso de Aseguramiento de la Calidad en Software, la cual quiz
sea la parte ms crtica en un proyecto de desarrollo. No se trata de
inspeccionar rpidamente los mens de una aplicacin, no se trata de detectar
algn defecto, se trata de asegurarse que el producto satisface las necesidades
del cliente anticipndose a la aparicin de algn error.

Este es el objetivo principal de un proceso de pruebas de software: documentar
el error, localizarlo, buscar sus causas, repararlo y generar acciones para
13
prevenirlos. Las pruebas a un programa pueden revelar la presencia de algn
defecto, pero nunca su ausencia, una prueba con xito ser la que encuentre
algn error antes de que lo haga el usuario final.

En muchas de las empresas de software, el proceso de pruebas se realiza
mientras se est construyendo la aplicacin, pocas tienen definida una
metodologa propia para esta fase, pues requiere de una considerable cantidad
de tiempo, esfuerzo y recursos.

En el mundo de la computacin tan cambiante de hoy, y sobre todo de gran
evolucin tecnolgica, y en vista de las exigencias que ha trado la globalizacin,
se ha hecho necesario desarrollar metodologas para asegurar la calidad de los
productos de software y obtener un mejoramiento continuo de todos los
procesos relacionados con el desarrollo de software.

El desarrollo de software tiene slo algunas dcadas; mientras los constructores
tienen procedimientos bien establecidos, la industria del software est an
definiendo sus caminos, buscando la manera adecuada de desarrollarse.
Considerar las propuestas basadas en la experiencia de los dems nos permitir
desarrollarnos con mayor velocidad; por ello hablaremos de las ltimas
tendencias de las pruebas de software.

Anteriormente, las pruebas de software se consideraban slo una actividad que
realizaba el programador para encontrar fallas en sus productos; con el paso de
los aos se ha determinado la importancia que tienen para garantizar el tiempo,
el costo y la calidad del producto, de tal forma que actualmente comprende un
proceso cuyo propsito principal es evaluar la funcionalidad del software
respecto de los requerimientos establecidos al inicio.

El proceso de realizacin de pruebas se percibe con frecuencia como un
proceso problemtico e incontrolable. Realizar pruebas conlleva mucho ms
14
tiempo, cuesta mucho ms de lo planeado y ofrece insuficiente informacin
sobre la calidad del proceso de pruebas y, por lo tanto, de la calidad del sistema
de informacin que est siendo probado, as como de los riesgos para el
proceso de negocio en s mismo. Pero, qu se puede hacer al respecto?

Muchas organizaciones se dan cuenta de que mejorar el proceso de pruebas
puede resolver estos problemas. Sin embargo, en la prctica, resulta difcil
definir qu pasos se deben realizar para mejorar y controlar dicho proceso, y en
qu orden deben ser realizados.

La prueba es un elemento crtico para la calidad del software. La importancia de
los costos asociados con los errores promueve la definicin y aplicacin de un
proceso de pruebas minuciosas y bien planificadas. Las pruebas permiten
validar y verificar el software, entendiendo como validacin del software el
proceso que determina si el software satisface los requisitos, y verificacin como
el proceso que determina si los productos de una fase satisfacen las condiciones
de dicha fase.

En este proyecto se pretende aclarar cmo debe ser el proceso de realizacin
de pruebas de software con el fin de lograr productos de alta calidad en las
empresas.









15
4. FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE

OBJETIVOS DE LAS PRUEBAS.

1. La prueba es el proceso de ejecucin de un programa con la intencin de
descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de
mostrar un error no descubierto hasta entonces.
3. Una prueba tiene xito si descubre un error no detectado hasta entonces.

Los objetivos anteriores quitan la idea que normalmente se tiene de que una
prueba tiene xito si no descubre errores.

Si la prueba se lleva a cabo con xito (de acuerdo a lo establecido
anteriormente), descubrir errores en el software. Adicionalmente, la prueba
demuestra hasta qu punto las funciones del software parecen funcionar de
acuerdo con las especificaciones y parecen alcanzar los requisitos de
rendimiento. Adems, los datos que se van recogiendo a medida que se lleva a
cabo la prueba proporcionan una buena indicacin de la fiabilidad del software.


PRINCIPIOS DE LAS PRUEBAS

Antes de comenzar el proceso de pruebas, se deben entender los principios
bsicos que guan las pruebas del software, a continuacin se presenta un
conjunto til de principios de prueba:

A todas las pruebas se les debera poder hacer un seguimiento hasta los
requisitos del cliente. Como se ha visto hasta ahora, el objetivo de las
pruebas del software es descubrir errores. Se entiende que los defectos
16
ms graves (desde el punto de vista del cliente) son aquellos que impiden
al programa cumplir sus requisitos.
Las pruebas deberan planificarse mucho antes de que empiecen. La
planificacin de las pruebas puede empezar cuando este completo el
modelo de requisitos. La definicin detallada de los casos de prueba
puede empezar cuando el modelo de diseo se haya terminado. Por
tanto, se pueden planificar y disear las pruebas antes de generar ningn
cdigo.
El principio de Pareto es aplicable a la prueba del software. El principio
de Pareto implica que al 80% de todos de todos los errores descubiertos
durante las pruebas se les puede hacer un seguimiento hasta un 20% de
todos los mdulos del programa. El problema es aislar los mdulos
defectuosos y probarlos concienzudamente.
Las pruebas deberan empezar por lo pequeo y progresar hacia lo
grande. Las primeras planeadas y ejecutadas se centran generalmente
en mdulos individuales del programa. A medida que avanzan las
pruebas, el objetivo se centra en encontrar errores en grupos integrados
de mdulos y finalmente en el sistema entero.
No son posibles las pruebas exhaustivas. El nmero de permutaciones
de caminos para incluso un programa de tamao moderado es
excepcionalmente grande. Por este motivo, es imposible ejecutar todas
las combinaciones de caminos durante las pruebas. Sin embargo, es
posible cubrir adecuadamente la lgica del programa y asegurarse de que
se han aplicado todas las condiciones en el diseo a nivel de
componente.
Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo
independiente. Al decir eficaces se refiere a realizar pruebas con la ms
alta probabilidad de encontrar errores, las cuales no son buenas si son
ejecutadas por los creadores del programa.

17
5. TCNICAS DE DISEO DE CASOS DE PRUEBAS

El diseo de casos de prueba est totalmente influenciado por la imposibilidad
de probar exhaustivamente el software, por lo que las tcnicas de diseo de
casos de prueba tienen como objetivo conseguir una confianza aceptable en que
se detectarn los defectos o errores existentes (ya que la seguridad total slo
puede obtenerse de la prueba exhaustiva, que no es practicable) sin necesidad
de consumir una cantidad excesiva de recursos. Toda la disciplina de pruebas
debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y
la confianza que aportan los casos para descubrir los defectos existentes.

Ya que no se puede probar todas las posibilidades de funcionamiento del
software, la idea fundamental para el diseo de casos de prueba consiste en
elegir algunas de ellas que, por sus caractersticas, se consideren
representativas del resto. As, se asume que si no se detectan defectos en el
software al ejecutar dichos casos, podemos tener un cierto nivel de confianza en
que el programa no tiene defectos. La dificultad de esta idea es saber elegir los
casos que se deben ejecutar, por lo que es necesario recurrir a ciertos criterios
de eleccin, conociendo la funcin especfica para la que fue diseado el
producto (pruebas de caja negra), o conociendo el funcionamiento del producto
(pruebas de caja blanca).










18
Pruebas de caja blanca


Figura 1. Pruebas de Caja Blanca

Se llaman tambin pruebas estructurales, en este tipo, las condiciones de las
pruebas son diseadas examinando el cdigo. El encargado de disear las
pruebas se gua por la estructura del programa o sistema, examinando la lgica
y sin tener en cuenta los requerimientos especficos. Luego de analizar el
cdigo, se usa toda esta informacin sobre su estructura para derivar los datos
de prueba.

El objetivo de este tipo de pruebas es elegir y recorrer una serie de importantes
caminos lgicos y probar las estructuras de datos ms importantes.

En resumen, las pruebas de caja blanca usan la estructura de control del diseo
procedimental para obtener los casos de prueba. Estos casos deben garantizar:

Que se ejercita por lo menos una vez todos los caminos independientes
de cada mdulo.
Que se ejerciten todas las decisiones lgicas en sus vertientes verdadera
y falsa.
Que se ejecuten todos los bucles en sus lmites operacionales.
19
Que se ejerciten las estructuras internas de datos para asegurar su
validez.

El enfoque del diseo de casos debe basarse en la eleccin de caminos (se
define camino como la secuencia de sentencias encadenadas desde la
sentencia inicial del programa hasta su sentencia final) importantes que ofrezcan
una seguridad aceptable en descubrir los defectos, y para ello se utilizan los
diferentes criterios de cobertura lgica.

Una posible clasificacin de criterios de cobertura lgica es la siguiente:

Cobertura de sentencias:
Se trata de generar los casos de prueba necesarios para que cada sentencia o
instruccin del programa se ejecute al menos una vez.

Cobertura de decisiones:
Consiste en escribir casos suficientes para que cada decisin tenga, por lo
menos una vez, un resultado verdadero y, al menos una vez, uno falso. En
general, una ejecucin de pruebas que cumple la cobertura de decisiones
cumple tambin la cobertura de sentencias.

Cobertura de condiciones:
Se trata de disear tantos casos como sea necesario para que cada condicin
de cada decisin adopte el valor verdadero al menos una vez y el falso al menos
una vez. No podemos asegurar que si se cumple la cobertura de condiciones se
cumple necesariamente la de decisiones.

Criterios de decisin/condicin:
Consiste en exigir el criterio de cobertura de condiciones obligando a que se
cumpla tambin el criterio de decisiones.

20
Criterio de condicin mltiple:
En el caso de que se considere que la evaluacin de las condiciones de cada
decisin no se realiza de forma simultnea, se podra considerar que cada
decisin multicondicional se descompone en varias decisiones unicondicionales.
En este caso se debe conseguir que todas las combinaciones posibles de
resultado (verdadero/ falso) de cada condicin en cada decisin se ejecuten al
menos una vez.

La cobertura de caminos (secuencia de sentencias) es el criterio ms elevado
que se puede plantear, es decir que cada uno de los posibles caminos del
programa se debe ejecutar al menos una vez. Sin embargo el nmero de
caminos en un programa pequeo puede ser impracticable para las pruebas, por
lo que para reducir el nmero de caminos a probar, se habla del concepto de
camino de prueba, que es un camino del programa que atraviesa, como mximo,
una vez el interior de cada bucle que encuentra.

La idea en que se basa consiste en que ejecutar un bucle ms de una vez no
supone una mayor seguridad de detectar defectos en l. Sin embargo, algunos
especialistas recomiendan que se pruebe cada bucle tres veces, una sin entrar
en su interior, otra ejecutndolo una vez y otra ms ejecutndolo dos veces.
Esto ltimo es interesante para comprobar cmo se comporta a partir de los
valores de datos procedentes, no del exterior del bucle (como en la primera
iteracin), sino de las operaciones de su interior.

Si se trabaja con los caminos de pruebas, existe la posibilidad de cuantificar el
nmero total de caminos utilizando algoritmos basados en matrices que
representan el grafo de flujo del programa. As, existen diversos mtodos
basados en ecuaciones, expresiones regulares y matrices que permiten tanto
calcular el nmero de caminos como enumerar dichos caminos expresados
como series de arcos del grafo de flujo. Saber cul es el nmero de caminos del
grafo de un programa ayuda a planificar las pruebas y a asignar recursos a las
21
mismas, ya que indica el nmero de ejecuciones necesarias. Tambin sirve de
comprobacin a la hora de enumerar los caminos.

Se destacan las siguientes variantes de pruebas de caja blanca:

Prueba del camino bsico:
Es una tcnica para obtener casos de prueba. Permite obtener una medida de
la complejidad lgica del diseo procedimental y usarla para definir un conjunto
bsico de caminos de ejecucin que garanticen que cada sentencia del
programa se recorre al menos una vez (cobertura de sentencias). Esta medida
puede ser usada como gua a la hora de definir un conjunto bsico de caminos
de ejecucin (diseo de casos de prueba).

Prueba de condicin:
Tcnica de prueba de caja blanca que se centra en la prueba de cada una de las
condiciones del programa. Las estrategias de prueba de condiciones tienen
generalmente, dos ventajas. La primera, que la cobertura de la prueba de una
condicin es sencilla. La segunda, que la cobertura de la prueba de las
condiciones de un programa da una orientacin para generar pruebas
adicionales del programa. El propsito de la prueba de condiciones es detectar,
no slo los errores en las condiciones de un programa, sino tambin otros
errores en dicho programa.

Prueba de flujo de datos:
Tcnica de prueba de caja blanca que selecciona caminos de prueba de un
programa de acuerdo con la ubicacin de las definiciones y los usos de las
variables del programa. Dado que las sentencias de un programa estn
relacionadas entre s de acuerdo con las definiciones de las variables, el
enfoque de prueba de flujo de datos es efectivo para la proteccin contra
errores.

22
Prueba de bucles:
Tcnica de prueba de caja blanca que se centra exclusivamente en la validez de
las construcciones de bucles, para lo cual distingue tratamientos para los
diferentes bucles: bucles simples, bucles concatenados, bucles anidados y
bucles no estructurados.


Pruebas de caja negra


Figura 2. Pruebas de Caja Negra

Tambin denominadas pruebas de comportamiento. Considera el sistema como
una caja negra, cuyo comportamiento es determinado nicamente a partir de sus
entradas y salidas. Estn diseadas basadas en la funcionalidad del producto,
para qu fue creado y qu hace.

El encargado de realizar las pruebas de caja negra debe tener informacin de
los datos de entrada y observar qu pasa con la respuesta o salidas del sistema,
sin tener en cuenta cmo trabaja ste en su interior.

Una prueba de Caja Negra examina algunos aspectos del modelo fundamental
del sistema sin tener mucho en cuenta la estructura lgica interna del software.

23
Tipos de errores que detecta:

Funciones incorrectas o ausentes.
Errores de la interfaz.
Errores en estructuras de datos o accesos a bases de datos.
Errores de rendimiento.
Errores de inicializacin y terminacin.

Las ventajas que presentan este tipo de mtodos de prueba son dos:

Reducen el nmero de casos de prueba que se deben disear.
Detectan clases de errores en vez de errores simples.

Mtodo de la particin equivalente

Consiste en dividir el dominio de entrada de un programa en clases de datos, de
los que se pueden generar casos de prueba. Los datos de entrada y los
resultados de salida se pueden agrupar en clases diferentes, en las que todos
los miembros de dicha clase estn relacionados.

Cada una de estas clases es una particin de equivalencia en la que el
programa se comporta de la misma forma para cada miembro de la clase. Las
clases de equivalencia pueden ser vlidas y no vlidas.

Se debe intentar dividir el dominio de entrada en un nmero finito de clases de
equivalencia, tal que probar un valor representativo de cada clase es equivalente
a probar cualquier otro valor, es decir: Si un caso de prueba es tal que en una
clase de equivalencia detecta un error, todos los dems posibles casos de
prueba en la misma clase detectarn el mismo error.

24
Si un caso de prueba no detecta error, podemos pensar que ningn otro caso de
prueba en esa clase encontrar el error.

Identificacin de las clases de equivalencia.

Se identifican dividiendo en dos o ms grupos cada condicin de entrada,
pueden ser:

Un valor numrico especfico.
Un rango de valores.
Nmero de valores.
Un conjunto de valores relacionados:
Una condicin booleana.

Mtodo basado en grafos
El primer paso en la prueba de caja negra es entender los objetos que se
modelan en el software (entendiendo por objeto a los objetos de datos y a los
objetos de programa tales como subsistemas,.). Una vez que se ha llevado a
cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que
todos los objetos tienen entre ellos las relaciones esperadas. Dicho de otra
manera, la prueba del software empieza creando un grafo de objetos
importantes y sus relaciones, y despus diseando una serie de pruebas que
cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones
para descubrir los errores.

Anlisis de valores lmite

Mediante la experiencia se ha podido constatar que los errores tienden a darse
ms en los lmites del campo de entrada que en el centro. Por ello se ha
desarrollado el anlisis de valores lmite como tcnica de prueba de caja negra,
la cual lleva a una eleccin de casos de prueba que ejerciten los valores lmite, y
25
que complementa de esta manera la tcnica de particin equivalente. As en
lugar de seleccionar cualquier elemento de una clase de equivalencia, esta
tcnica lleva a la eleccin de casos de prueba en los extremos de la clase, y
adems de centrarse solamente en las condiciones de entrada, se obtienen
casos de prueba tambin para el campo de salida.

Prueba de comparacin

Hay situaciones en las que la fiabilidad del software es algo absolutamente
crtica. En ese tipo de aplicaciones, a menudo se utiliza hardware y software
redundante para minimizar la posibilidad de error. Cuando se desarrolla
software redundante, varios equipos separados desarrollan versiones
independientes de una aplicacin, usando las mismas especificaciones. En
esas situaciones, se deben probar todas las versiones con los mismos datos de
prueba, para asegurar que todas proporcionan una salida idntica. Luego, se
ejecutan todas las versiones en paralelo y se hace una comparacin en tiempo
real de los resultados, para garantizar la consistencia.

Con las lecciones aprendidas de los sistemas redundantes, los investigadores
han sugerido que, para las aplicaciones crticas, se deben desarrollar versiones
de software independientes, incluso aunque slo se vaya a distribuir una de las
versiones en el sistema final basado en computadora. Esas versiones
independientes son la base de esta tcnica de prueba de caja negra. Si las
salidas producidas por las distintas versiones son idnticas, se asume que todas
las implementaciones son correctas. Si la salida es diferente, se investigan
todas las aplicaciones en una o ms versiones.

Prueba de la tabla ortogonal

Hay muchas aplicaciones en que el dominio de entrada es relativamente
limitado. Es decir, el nmero de parmetros de entrada es pequeo y los
26
valores de cada uno de los parmetros estn claramente delimitados. Cuando
estos nmeros son muy pequeos, es posible considerar cada permutacin de
entrada y comprobar exhaustivamente el proceso del dominio de entrada. En
cualquier caso, cuando el nmero de valores de entrada crece y el nmero de
valores diferentes para cada elemento de dato se incrementa, la prueba
exhaustiva se hace impracticable o imposible.

La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio
de entrada es relativamente pequeo pero demasiado grande para posibilitar
pruebas exhaustivas, siendo particularmente til al encontrar errores asociados
con fallos localizados, como por ejemplo una categora de error asociada con
defectos de la lgica dentro de un componente software. De manera que esta
tcnica proporciona una buena cobertura de prueba con bastantes menos casos
de prueba que en la estrategia exhaustiva.

Conjetura de errores

Tcnica de prueba de caja negra que consiste en enumerar una lista de
equivocaciones que pueden cometer los desarrolladores y de las situaciones
propensas a ciertos errores. Despus se generan casos de prueba con base en
dicha lista, que se suelen corresponder con defectos que aparecen comnmente
y no con aspectos funcionales.

Esta tcnica tambin se ha denominado generacin de casos (o valores)
especiales, ya que no se obtienen con base en otros mtodos sino mediante la
intuicin o la experiencia.


Utilizacin de casos de uso del sistema para la realizacin de pruebas de
caja negra.

27
Una buena prctica para la realizacin de pruebas de caja negra, es disear los
casos de prueba basndose en los casos de uso de las funcionalidades que
sern probadas. La utilizacin de los casos de uso para el diseo de los casos
de prueba, le facilitar al tester la realizacin de las pruebas ya que ste puede
tener mas conocimiento acerca de las funcionalidades a probar, acercar de
cmo debe responder el sistema ante determinadas acciones, pues en un caso
de uso se encuentran indicados los posibles escenarios de xito y/o fallo
permitindole al tester tener una idea mas acertada de las entradas que debe
generarle al sistema con el fin de validar que la funcionalidad se encuentre
correcta.

A continuacin se presenta un ejemplo de un caso de uso de la funcionalidad
Procesar venta de un punto de venta, seguidamente se presenta un ejemplo de
cmo usar el caso de uso como un caso de prueba.

CASO DE USO UC1: Procesar Venta.
Actor principal: Cajero.
Precondiciones: El cajero se identifica y se autentica.
Garantas de xito (Postcondiciones): Se registra la venta. El impuesto se
calcula de manera correcta. Se actualizan la contabilidad y el inventario. Se
registran las comisiones. Se genera el recibo. Se registran las autorizaciones
de pago aprobadas.
Escenario principal de xito (o flujo bsico):
1. El cliente llega a un terminal PDV con artculos que comprar.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artculo.
4. El sistema registra la lnea de venta y presenta la descripcin del artculo,
precio y suma parcial. El precio se calcula a partir de un conjunto de reglas de
precios.
El cajero repite los pasos 3 4 hasta que se indique.
5. El sistema presenta el total con los impuestos calculados.
28
6. El cajero le dice al cliente el total y pide que le pague.
7. El cliente paga y el sistema gestiona el pago.
8. El sistema registra la venta completa y enva la informacin de la venta y el
pago al sistema de contabilidad externo y al sistema de inventario.
9. el sistema presenta el recibo.
10. El cliente se va con el recibo y la mercanca.
Extensiones (o flujos alternos):
3a. Identificador no vlido:
1. El sistema seala el error y rechaza la entrada.
3b. Hay muchos artculos de la misma categora y tener en cuenta una nica
identidad del artculo no es importante:
1. El cajero puede introducir el identificador de la categora del artculo y la
cantidad.
3-6a. El cliente le pide al cajero que elimine un artculo de la compra.
1. El cajero introduce el identificador del artculo para eliminarlo de la
compra.
2. El sistema muestra la suma parcial actualizada.
3-6b. El cliente le pide al cajero que cancele la venta.
1. El cajero cancela la venta en el sistema.
4a. El sistema genera el precio de un artculo que no es el deseado. (ej: el
cliente se queja por algo y se le ofrece un precio mas bajo).
1. El cajero introduce el precio alternativo.
2. El sistema presenta el nuevo precio.
Lista de tecnologa y variaciones de datos:
3a. El identificador del artculo se introduce mediante un escner lser de cdigo
de barras o a travs del teclado.

En el caso de uso anterior se observan diferentes secciones que indican cmo
es el proceso y qu se debe tener en cuenta para su correcto funcionamiento,
adems presenta la seccin de flujos alternos, que le da al tester una idea
acerca de otras condiciones adicionales que deben ser probadas. A continuacin
29
se presenta el ejemplo de un formato para la realizacin de pruebas usando el
caso de uso anterior:


Caso de PruebaProcesar Venta.
TesterJohn
Fecha10/12/2004
Actor principalCajero.
PrecondicionesEl cajero se identifica y se autentica.
Garantas de xito
(Postcondiciones)
Se registra la venta. El impuesto se calcula de manera
correcta. Se actualizan la contabilidad y el inventario. Se
registran las comisiones. Se genera el recibo. Se
registran las autorizaciones de pago aprobadas.
Curso Normal de Eventos
Accin del usuario Respuesta del sistema Fall / Pas
1. El cliente llega a un
terminal PDV con artculos
que comprar.

2. El cajero comienza una
nueva venta.

3. El cajero introduce el
identificador del artculo.
4. El sistema registra la lnea de
venta y presenta la descripcin del
artculo, precio y suma parcial. El
precio se calcula a partir de un
conjunto de reglas de precios.

El cajero repite los pasos 3 4 hasta que se indique.
5. El sistema presenta el total con
los impuestos calculados.

6. El cajero le dice al cliente
el total y pide que le pague.

7. El cliente paga y el cajero
introduce el pago
8. El sistema gestiona el pago:
registra la venta completa y enva la
informacin de la venta y el pago al
sistema de contabilidad externo y al
sistema de inventario.

9. el sistema presenta el recibo.
Flujos alternos
3a. Identificador no vlido:
El sistema seala el error y rechaza la entrada.

3b. Hay muchos artculos de la misma categora y tener en cuenta
una nica identidad del artculo no es importante:
El cajero puede introducir el identificador de la categora del
artculo y la cantidad.

30
3-6a. El cliente le pide al cajero que elimine un artculo de la
compra:
El cajero introduce el identificador del artculo para eliminarlo de
la compra y el sistema muestra la suma parcial actualizada.

3-6b. El cliente le pide al cajero que cancele la venta.
El cajero puede cancelar la venta en el sistema.

4a. El sistema genera el precio de un artculo que no es el
deseado. (ej: el cliente se queja por algo y se le ofrece un precio
mas bajo):
El cajero introduce el precio alternativo y el sistema presenta el
nuevo precio.

Lista de tecnologa y variaciones de datos:
3a. El identificador del artculo se introduce mediante un escner
lser de cdigo de barras o a travs del teclado.



En este formato se puede indicar mediante una entrada de Pas o Fall en la
columna de la derecha si los pasos de la funcionalidad probada se encontraron
correctos o no. En los pasos que no generan respuesta del sistema se puede
ingresar N.A (No Aplica).















31
6. ESTRATEGIAS DE PRUEBA DEL SOFTWARE

Una estrategia de casos de prueba del software integra las tcnicas de diseo
de casos de prueba en una serie de pasos bien planificados que dan como
resultado una correcta construccin del software. Cualquier estrategia de
prueba debe incorporar la planificacin de la prueba, el diseo de casos de
prueba, la ejecucin de las pruebas y la agrupacin y evaluacin de los datos
resultantes.

6.1 Pruebas de unidad

La prueba de unidad centra el proceso de verificacin en la menor unidad del
diseo del software: mdulos. Se trata de las pruebas formales que permiten
declarar que un mdulo est listo y terminado (no las informales que se realizan
mientras se desarrollan los mdulos)

Hablamos de una unidad de prueba para referirnos a uno o ms mdulos que
cumplen las siguientes condiciones [IEEE, 1986a]:

Todos son del mismo programa.
Al menos uno de ellos no ha sido probado.
El conjunto de mdulos es el objeto de un proceso de prueba.

La prueba de unidad puede abarcar desde un mdulo hasta un grupo de
mdulos.

Algunas pruebas que pueden hacerse como pruebas de unidad son:

Pruebas de interfaz.
Pruebas de estructuras de datos.
Pruebas de condiciones lmite.
32
Pruebas de caminos independientes,
Pruebas de caminos de manejo de errores.

6.2 Pruebas de integracin

Implican una progresin ordenada de pruebas que van desde los componentes o
mdulos y que culminan en el sistema completo.

El orden de integracin elegido afecta a diversos factores, como lo siguientes:

La forma de preparar casos.
Las herramientas necesarias.
El orden de codificar y probar los mdulos.
El coste de la depuracin.
El coste de preparacin de casos.

Tipos fundamentales de integracin

Integracin incremental: Se combina el siguiente mdulo que se debe probar
con el conjunto de mdulos que ya han sido probados

Ascendente: Se comienza por los mdulos hoja.
Descendente: Se comienza por el mdulo raz.

Integracin no incremental: Se prueba cada mdulo por separado y luego se
integran todos de una vez y se prueba el programa completo



33
7. LOS MODELOS INTERNACIONALES Y LAS PRUEBAS

CMMI ha sido concebido por el SEI (Software Engineering Institute) como
modelo para determinar y mejorar la capacidad de los procesos en las
organizaciones, con el objetivo de desarrollar productos de calidad de manera
consistente y predecible. CMMI integra las disciplinas de ingeniera de software
e ingeniera de sistemas en un nico marco de referencia.
CMMI incorpora material de las ltimas versiones de estndares y modelos
como los relacionados con ingeniera de software: ISO/IEC TR 15504, ISO/IEC
12207, CMMI-SW, entre otros.
CMMI es un modelo descriptivo que detalla los atributos esenciales que
deberan caracterizar a una organizacin en un determinado nivel de
maduracin.
Es un modelo normativo donde las prcticas detalladas caracterizan los tipos
normales de comportamiento esperables en una organizacin que ejecuta
proyectos a gran escala.
La mejora continua de los procesos se basa en muchos pasos pequeos y
evolutivos en vez de innovaciones revolucionarias.
CMMI proporciona un marco para organizar estos pasos evolutivos dentro de
cinco niveles de maduracin que sientan fundamentos sucesivos para la mejora
continua del proceso, cada uno de ellos queda caracterizado por la presencia (o
ausencia) de determinadas prcticas.
Cada nivel comprende un conjunto de objetivos que, una vez alcanzados,
estabilizan un componente importante del proceso de software. Al alcanzar cada
nivel del marco de madurez se establece un componente diferente en el proceso
de software, resultando en un incremento en la capacidad de proceso de la
organizacin.
Los niveles se observan a continuacin:
34

Figura 3. Niveles de Madurez de CMMI

Realizado: En este nivel hay pocos procesos definidos o ninguno.
Administrado: En este nivel las organizaciones tienen procesos bsicos
para administrar sus proyectos; se monitorean costos, planes y
funcionalidad.
Definido: Hay un proceso estndar que integra prcticas de gestin e
ingeniera.
Cuantitativamente Administrado: El proceso facilita la obtencin de
mediciones detalladas del desempeo del proceso y de la calidad de los
productos desarrollados.
Optimizado: El proceso est bajo control estadstico y en un ciclo de
mejora continua.
35
CMMI cuenta con 23 PAs (process areas) clasificadas en los siguientes grupos:

Procesos administrativos: Los procesos administrativos se utilizan para
establecer la visin, metas, estrategia y la direccin de la empresa. Los
procesos administrativos iniciados, planean y realizan las actividades que
conllevarn al logro de los objetivos de la empresa, de la organizacin, o
del proyecto. Supervisan la ejecucin de los otros procesos en el modelo.
Procesos del ciclo de vida: Estos procesos son usados para desarrollar,
mantener y operar un servicio o producto con el fin de proveer y sostener
los servicios y las necesidades del cliente.
Procesos de soporte: estos procesos son usados por otras PAs cuando
estas los necesitan y contribuyen al xito y la calidad de los dems
procesos.

Dentro de los procesos del ciclo de vida se encuentra la PA 08: Pruebas del
sistema y evaluacin; que permite confirmar que los servicios y los productos
adquiridos y/o desarrollados satisfacen los requerimientos y necesidades
operacionales, e identifican y documentan el estado actual y potencial de los
defectos que puede presentar un producto o servicio.

Los objetivos de la PA 08 son:

Establecer los requerimientos, mtodos y el ambiente para la evaluacin
del sistema para proporcionar una base objetiva para determinar si los
productos y los servicios cumplen con los requerimientos y pueden ser
aceptados.
Realizar las evaluaciones como fue planeado.
Transmitir los anlisis de las evaluaciones mediante los resultados de
stas para soportar la aceptacin o las acciones correctivas del sistema.

36
A continuacin se presentan las prcticas llevadas a cabo en esta PA y cmo
estn relacionadas con la metodologa propuesta:

BP 08.01 Estrategia de Evaluacin.
Prctica relacionada con el paso de Planeacin de las pruebas.
BP 08.02 Procedimientos de Evaluacin.
Prctica relacionada con el paso Evaluacin y ejecucin de las pruebas.
BP 08.03 Establecer y mantener el ambiente de evaluacin.
Prctica relacionada con los pasos: Planeacin de las pruebas y
Preparar las siguientes pruebas.
BP 08.04 Evaluar el crecimiento del producto.
Esta prctica est relacionada con toda la base de la metodologa, la cual
es cclica y est basada en el mejoramiento continuo del producto.
BP 08.05 Verificar productos finales.
Esta prctica est relacionada con el paso Dirigir las pruebas del
sistema.
BP 08.06 Validar productos finales.
Esta prctica est relacionada con el paso Dirigir las pruebas de
aceptacin
BP 08.07 Analizar resultados de la evaluacin.
Esta prctica est relacionada con los pasos Preparar las siguientes
pruebas y Resumen de pruebas y reporte final.










37
8. METODOLOGA DE PRUEBAS DE SOFTWARE

En un ambiente de desarrollo de software es importante realizar pruebas durante
todo el ciclo de vida de los proyectos. La metodologa de pruebas que se
presenta a continuacin se puede ver como un proceso de mejoramiento
continuo que debe ser integrado con la metodologa de desarrollo. La
integracin de estos procesos conlleva a prevenir y detectar defectos durante las
diferentes fases del desarrollo y a prevenir avances sin haber realizados las
pruebas necesarias para el aseguramiento de la calidad.

El siguiente modelo presenta las distintas etapas de la metodologa de pruebas
de software. Dichas etapas se encuentran inmersas dentro del ciclo PHVA
(Planear, Hacer, Verificar y Actuar).


Figura 4. Pasos Metodologa de Pruebas

38
FASE 1: PLANEAR


Figura 5. Fase: Planear (PHVA)

La etapa uno (Recoleccin de la informacin) y la etapa dos (Planeacin de las
pruebas) se encuentran en la fase Planear.

A continuacin se detallan las actividades que se llevan a cabo en cada una de
estas etapas:






















39
1. RECOLECCIN DE INFORMACIN


El propsito de la fase de recoleccin de informacin es obtener informacin
relevante del proyecto de desarrollo de software, para entender qu se quiere
realizar, cules son los objetivos y qu alcance tiene el proyecto. Toda esta
informacin ser utilizada para empezar la elaboracin o construccin del plan
de pruebas.

1.1 Preparacin de la entrevista

Para la realizacin de la entrevista a los participantes (que sern identificados en
el siguiente punto), es importante definir los objetivos y el alcance que va a tener
sta. Antes de su realizacin debe asegurarse que los participantes tengan
claro el motivo y los objetivos de la entrevista.

1.1.1 Identificar los participantes

Para realizar una buena entrevista y que sta abarque los temas necesarios, se
deben definir bien sus participantes. De ah la importancia de que estn
involucradas personas de las diferentes reas, como el rea de calidad,
desarrollo y lderes de proyectos.

En el rea de calidad se deben elegir mximo dos personas, una que tenga el
papel de dirigir la entrevista y otro que lleve registro o nota de la informacin que
se vaya generando. Esto con el fin de que el entrevistador tenga un mayor
enfoque en la obtencin de informacin. Es recomendable que el encargado de
dirigir la entrevista, sea la persona lder y responsable de las actividades de
pruebas de todo el proyecto.

40
El responsable de tomar nota durante la entrevista se debe encargar de que
queden registrados los temas, supuestos y preguntas que se lleven a cabo
durante toda la entrevista. Adems esta persona servir de soporte al
entrevistador.

Tambin el encargado de tomar nota debe ser uno de los ingenieros de pruebas
o lder de pruebas que se asignen al proyecto.

Por parte del rea de desarrollo, deben estar en la entrevista, el lder del
proyecto y uno de los miembros del grupo de programadores. Esto con el fin de
tener los diferentes puntos de vista de los involucrados en el proyecto.

1.1.2 Definir la Agenda

Uno de los factores importantes para el xito de la entrevista, es definir la
agenda. Esta agenda debe ser construida previamente por el entrevistador y
debe ser aceptada por los dems participantes.

La agenda debe contener los puntos necesarios para que la entrevista cumpla
con el objetivo de recopilar la informacin suficiente para el aseguramiento de la
calidad del proyecto y la elaboracin de un plan de pruebas. La agenda debe
contener una introduccin, los temas a tratar y por ltimo, el resumen y las
conclusiones de la entrevista.

1.2 Desarrollo de la entrevista

El desarrollo de la entrevista est a cargo del entrevistador, quien debe ser la
persona que presente la agenda que se va a seguir y lleve el control durante
todo su desarrollo. Durante la entrevista se deben tratar todos los temas
41
propuestos y se debe llevar el control del tiempo que se tiene programado para
cada actividad o tema que se va a realizar.

Tambin el entrevistador debe presentarse ante los participantes, comunicar sus
funciones como lder, los objetivos de la entrevista y pedir a cada uno de los
asistentes que hablen acerca de sus funciones en el proyecto y de las
responsabilidades que tienen asignadas.

1.2.1 Entender el proyecto

Luego de presentar la agenda y los objetivos de la entrevista, sta se debe
centrar en entender el proyecto. Para ello, se deben realizar una serie de
preguntas de informacin general y bsica del proyecto como:

Cul es el proyecto del que se va a hablar?
Cules son los objetivos generales del proyecto?
Es un proyecto nuevo, en desarrollo o de mantenimiento?
Cundo empieza el proyecto? (nuevos proyectos)
Qu tiempo se tiene estimado para el proyecto?
Quines son los participantes en el proyecto?
Qu recursos estn asignados a cada participante?
Cules son las responsabilidades de cada participante?
Quines son los usuarios del proyecto?
Cules son los principales problemas o riesgos del proyecto?
Cul es el presupuesto del proyecto?




42
1.2.2 Entender los objetivos del proyecto

Entender los objetivos del proyecto es una tarea necesaria para construir un
buen plan de pruebas. El propsito de esta tarea es entender el alcance, las
necesidades y los requerimientos del proyecto.

Algunas preguntas que se pueden realizar para tal propsito son:

Qu tipo de proyecto se est realizando, o se va a realizar?
Por qu se va a realizar?
Qu anlisis o qu modelos se han hecho del sistema?
Qu tipo de usuarios lo van a utilizar?
Cules van a ser las funciones del sistema?
Qu se va a hacer y qu no?
Qu funciones se van a implementar?
Qu beneficios tiene el proyecto para los usuarios?
Entregas programadas?

1.2.3 Entender la planeacin del proyecto

El propsito es entender en qu estado est el proyecto y qu planes se han
hecho para su desarrollo, esto ayudar a planear los esfuerzos que se tienen
que realizar para las pruebas. Tambin es necesario conocer las actividades y
tareas que se realizarn y los recursos que se emplearn para el proyecto.

Para obtener esta informacin se pueden realizar preguntas como:

En qu estado se encuentra el proyecto?
Hay algn plan de trabajo para el proyecto?
Qu actividades o tareas hay programadas?
43
Cules son las actividades principales planeadas?
Horas estimadas?
El tiempo estimado para el desarrollo es apropiado?
Qu tan detallado es el plan de trabajo?
Estn asignados los recursos para cada actividad del plan de trabajo?
El plan de trabajo es actualizado peridicamente?
Cules son los mayores riesgos estimados?

1.2.4 Conocer la metodologa de desarrollo

En todo proyecto de desarrollo de software, la planeacin y ejecucin de las
pruebas debe estar integrada con el ciclo de vida y con la metodologa que se
utilice para el desarrollo del proyecto.

Considerar las pruebas como una funcin aparte del desarrollo puede llevar a un
mayor riesgo de pasar por alto errores y aumentar el costo para resolverlos.
Integrando las pruebas a la metodologa de desarrollo, se asignarn los recursos
apropiadamente y se evitar que algunas actividades continen sin haber
realizado las pruebas necesarias.

Adems, las actividades de pruebas necesariamente tendrn que afectar la
metodologa de desarrollo, agregando o modificando algunas tareas. Debe
conocerse tambin, cundo se pueden comenzar las pruebas y cules sern las
actividades planeadas para corregir los errores detectados.

Algunas preguntas que se pueden realizar son:

Qu metodologa de desarrollo es usada usualmente por la
organizacin?
Cul metodologa va a ser utilizada para el proyecto?
44
Cules son los pasos o actividades principales de la metodologa?
Qu tanto se sigue esta metodologa?
Qu estndares se siguen?
Qu documentacin se lleva?

1.2.5 Conocer las reglas de negocio

Cada organizacin, dependiendo de la metodologa que utilice en el desarrollo
de los productos de software, tiene diferentes formas de hacer la toma de
requerimientos de un proyecto. La especificacin de los requerimientos define
las funciones del producto en un ambiente especfico.

El entrevistador o lder de pruebas, debe evaluar los requerimientos del proyecto
de desarrollo de software, y estos deben quedar lo suficientemente claros para
as, conocer qu se supone que debe realizar la aplicacin, planear el diseo de
las pruebas y estimar los requisitos que requieren la implementacin de estas.

Las preguntas que se deben realizar para obtener informacin sobre los
requerimientos y reglas del negocio son:

Qu tipo de aplicacin es? ( Financiera, control de inventarios, ventas,
etc.)
Cules son las principales funciones que debe realizar el sistema? (Se
deben pedir detalles de cada funcin.)
Para qu sistema operativo se va a desarrollar?
Qu interfaces sern utilizadas?
Qu plataforma ser utilizada?
Requerimientos mnimos del sistema? ( Espacio en disco, memoria
RAM, otros requerimientos.)
Cul es el rendimiento esperado?
45
Qu reglas o polticas de seguridad se deben cumplir?
Qu polticas o qu restricciones se deben cumplir?
Qu otros aspectos se deben probar?

1.2.6 Anlisis de riesgos

El propsito de esta tarea es analizar qu tipo de riesgos tiene la aplicacin y
qu tipo criticidad tiene cada mdulo del proyecto. Esto puede ayudar a
identificar y realizar pruebas ms exhaustivas en estas aplicaciones.

Para obtener esta informacin se pueden realizar estas preguntas:

Cules son los mdulos principales del proyecto?
Cul es el tamao del proyecto?
Qu impacto tiene el proyecto en el cliente?
Qu tipo de cliente es?
Nmero de usuarios del sistema?
Qu prediccin hay de costos para el usuario por fallos de la aplicacin?

1.3 Reporte de resultados

Al terminar la entrevista se deben llevar a cabo 2 actividades, la primera hacer el
resumen de lo hablado y luego elaborar los reportes apropiados con la
informacin obtenida.

1.3.1 Resumen de la entrevista

Luego de terminar las preguntas elaboradas durante la entrevista, se deben
revisar los puntos de la agenda que se tena prevista. Si todos no han sido
cumplidos, y se requiere una prxima reunin, sta se debe programar en ese
46
momento, ya que todos lo miembros estn presentes y se pueden poner de
acuerdo. En caso de que la agenda se haya cumplido, los participantes pueden
hacer los comentarios adicionales que tengan.

El encargado de llevar nota de los temas tratados en la entrevista se debe
encargar de elaborar un reporte claro y organizado, con el orden en que se
realiz la entrevista y hacerlo llegar a las reas de la empresa que lo requieran.

1.3.2 Resultados de la entrevista

En este paso, el objetivo es que los participantes de la entrevista estn de
acuerdo, tengan claro y entiendan el proyecto. Luego de ser distribuido el
reporte, los participantes pueden hacer sus comentarios o sugerencias para
modificar el reporte. Una vez que todos aprueben el documento, este ser
distribuido de nuevo a las reas de la organizacin que lo requieran.
















47
2. PLANEACIN DE LAS PRUEBAS

La planeacin de las pruebas es una de las etapas ms importantes de un
proceso de pruebas y por lo tanto de la metodologa, ya que puede proveer la
forma ms organizada de probar el software. En esta fase se elabora el plan de
pruebas, que es el documento que ayuda a manejar todo el proceso de pruebas.

El plan de pruebas debe ser simple, completo, actualizado y debe estar al
alcance de todos los participantes del desarrollo para poder hacer su aprobacin
y utilizarlo como retroalimentacin. Un buen plan de pruebas minimiza la
redundancia de pruebas, provee procedimientos de trabajo para el monitoreo y
rastreo del comportamiento o estado de las pruebas. Contiene tambin una
definicin clara de los roles y responsabilidades de las partes involucradas en el
proceso de pruebas.

Siguiendo un buen plan de pruebas hay buenas oportunidades de encontrar la
mayora de los defectos y cubrir la mayor parte del cdigo.

CONSTRUIR EL PLAN DE PRUEBAS

El propsito del plan de pruebas es explicitar el alcance, el enfoque, los recursos
requeridos, el calendario, los responsables y el manejo de los riesgos de un
proceso de pruebas. Este plan de pruebas debe ser realizado y / o actualizado
en cada una de las etapas del ciclo de desarrollo para que se realicen pruebas
de acuerdo a la fase o estado en que se encuentra el proyecto.


2.1 Definir el identificador del plan

Todo plan de pruebas debe llevar un identificador nico, ste debe
preferiblemente tener alguna forma mnemnica que permita relacionarlo con su
48
alcance. Adems deber llevar a fecha y la versin del plan, ya que puede ser
modificado durante la ejecucin de las pruebas.

2.2 Preparar la introduccin

La primera parte del plan de pruebas debe ser la introduccin, en donde
describe por qu el plan va a ser desarrollado y cules son sus objetivos.
Tambin se da una descripcin del proyecto o del problema que se va a tratar y
del entorno en que va a ser desarrollado, y explica los eventos que llevaron a
desarrollar el plan. Estos pueden incluir implementacin de procesos de
mejoramiento, o la adicin de nuevas funcionalidades.

Adems, los riesgos de la aplicacin, el alcance, los objetivos, el propsito y los
factores de xito deben ser documentados en la introduccin.

Cualquier otra documentacin, como la especificacin de requerimientos,
especificaciones funcionales, especificaciones de diseo, planes de trabajo,
modelos de datos deben ser listados y se debe describir su estado.

Adicionalmente en la introduccin se deben mencionar los riesgos que pueden
tener las pruebas.

2.3 Identificar los requerimientos


Esta seccin del plan de pruebas lista los requerimientos que deben ser
probados. Cualquier requerimiento que no sea nombrado est fuera del alcance
del plan de pruebas.

49
Se deben identificar todas las funciones que deben ser probadas, como crear,
editar o borrar registros. Ac se puede hacer referencia a otro documento donde
sean nombrados todos los requerimientos del sistema.

Tambin, comprende las pruebas de la interfaz de usuario, la descomposicin
jerrquica de las funciones ( estructura de los mens, el flujo que siguen, etc.), el
diseo de las ventanas y el estndar que sigue su diseo.

2.4 Identificar los tipos de prueba

En este paso, se describe cmo los objetivos de cada tipo de prueba que va a
ser parte del plan de pruebas van a ser cumplidos. Los tipos de pruebas pueden
ser entre otros:

Pruebas de unidad.
Pruebas funcionales.
Pruebas de integracin.
Pruebas de volumen.
Pruebas de estrs.
Pruebas de rendimiento.
Pruebas globales del sistema.

Para cada tipo de prueba se debe detallar lo siguiente:

Objetivo: EL objetivo principal de la prueba.
Tcnica: Documentar cmo los casos de prueba van a ser desarrollados,
las herramientas que se van a utilizar, cmo se van a ejecutar, y los datos
que van a ser usados.
Consideraciones especiales: Configuraciones o detalles nicos o
especiales que se deben tener en cuenta como, datos, ambiente fsico o
50
de software, o cualquier otro que deba tenerse en cuenta para el xito de
las pruebas.
Criterio de terminacin: Documentar cundo se dan por terminadas las
pruebas.
Definir cundo y cmo se deben realizar nuevamente las pruebas: Luego
de cambios, mejoras o correcciones.
Herramientas: Documentar las herramientas que se van a utilizar.

El tipo de pruebas que se van a disear depende totalmente de los objetivos de
las aplicaciones que van a ser desarrolladas y la fase en que sta se encuentre.
Sin embargo, se deben realizar pruebas funcionales de la aplicacin, que
asegure que se cumple los objetivos para lo que fue desarrollada, pruebas de la
interfaz de usuario y pruebas luego de encontrar y corregir cada error, o luego
de implementar alguna nueva mejora.

2.5 Identificar cundo terminar las pruebas

Uno de los principales problemas que se encuentra al realizar pruebas es
identificar cundo terminarlas ya que por ejemplo es imposible determinar
cundo un programa o una aplicacin est libre de defectos.

Existen algunos criterios para terminar las pruebas:

Termina el tiempo estimado para realizar las pruebas
Se encuentra un nmero especificado de errores.
Todas las pruebas programadas han terminado.
Combinacin de las anteriores.

La mayora de los proyectos deberan utilizar una combinacin de los criterios
anteriores.
51
2.6 Establecer la estrategia de pruebas de regresin.

Probar la aplicacin cada que se realice un cambio, cada que se haga la
correccin de un error, o cada que se haga una mejora en una nueva versin es
una de las estrategias que se debe adoptar. Estas pruebas se deben realizar
para confirmar que los cambios que se le han hecho a la aplicacin no afectaron
los dems mdulos o no tuvieron efectos no esperados en el comportamiento
del programa. Correcciones de errores que tengan relacin con el flujo de
control o con la lgica y errores de interfaces son un ejemplo de cundo se debe
volver a probar.

Debido a que realizar de nuevo todas las pruebas cada que haya un cambio no
es posible, se pueden establecer polticas para poder hacer una buena eleccin
de qu pruebas o tipos de pruebas se van a repetir.

A tener en cuenta:

Pruebas que puedan ser automatizadas son buenas candidatas para
repetirse luego de cada cambio a la aplicacin.
Se deben repetir pruebas que fueron diseadas antes de hacerse el o los
cambios.
Se deben hacer pruebas que sean diseadas luego de los cambios.

2.7 Definir los entregables

Como resultado de los diferentes pasos del ciclo de pruebas se generan algunos
documentos que se deben entregar. Algunos entregables pueden ser:

Plan de pruebas: Define los objetivos, el alcance, la estrategia y los tipos
de pruebas que se van a desarrollar.
52
Mtricas: Documento con los aspectos que se van a medir durante el
desarrollo de las pruebas.
Casos de pruebas: Formato con informacin de los casos de prueba.
(Figura 6)
Reportes intermedios: Reporte que se hace luego de ejecutar las
pruebas en cada fase del proceso de pruebas. ( Seccin: 6.3 )
Reporte Final: Reporte del resultado final de las pruebas. Este reporte se
elabora luego de terminar todo el proceso de pruebas. ( Seccin: 9 )
Reporte de errores: Formatos con la informacin de los errores
descubiertos durante el proceso de pruebas. ( Seccin: 2.11 )


Figura 6. Formato de Casos de prueba
53
2.8 Organizar el equipo de pruebas

El grupo de trabajo que haga parte del equipo de pruebas debe ser escogido
entre las personas de la empresa que tengan un buen grado de experiencia y de
talento. Idealmente, estos individuos deben ser profesionales del rea de
aseguramiento de calidad, pero pueden tambin representar el grupo de
usuarios, tcnicos, administradores de bases de datos, externos, etc. Estos
ltimos son particularmente buenos en la fase final de aceptamiento del sistema.

Durante el desarrollo de las pruebas se definen dos responsabilidades
principales: probar las aplicaciones, esto hace parte de las tareas del equipo de
pruebas, y ocuparse de las actividades globales concernientes con las pruebas,
de esto se encarga el lder del grupo.

El lder debe encargarse tambin de dirigir el equipo de pruebas, ser el
intermediario entre los desarrolladores y los ingenieros de pruebas. Adems
entre otras responsabilidades estn:

Definir los objetivos de las pruebas.
Definir los recursos que se van a utilizar para las pruebas.
Crear los procedimientos de pruebas.
Desarrollar y mantener el plan de pruebas.
Disear los casos de pruebas.
Realizar reportes.
Definir los roles de los integrantes del equipo de pruebas.
Asegurarse de la calidad del proceso de pruebas.

Entre las principales responsabilidades del equipo de pruebas estn:

Ejecutar los casos de pruebas de acuerdo con el plan de pruebas.
Evaluar los resultados de las pruebas.
54
Reportar los errores.
Documentar los errores.

Luego de encontrar errores en las aplicaciones y documentarlos junto con el
camino que llev a que estos aparecieran, se deben reportar al rea de
desarrollo para que sean corregidos. Una vez el grupo de desarrolladores haya
corregido estos errores, el equipo de probadores debe volver a ejecutar las
pruebas que llevaron a la aparicin de los errores en un principio.

2.9 Establecer el ambiente de pruebas

El propsito de un buen ambiente de pruebas es dotar a los encargados del
aseguramiento de calidad de la infraestructura necesaria para las actividades de
pruebas. Para esto se debe estabilizar y revisar el ambiente antes de su
implementacin.

Es importante dentro del ambiente de pruebas contar con la tecnologa
adecuada y las herramientas de pruebas adecuadas. Esta tecnologa incluye la
plataforma de hardware, la infraestructura de red con todos sus componentes, el
sistema operativo, y cualquier otra herramienta de software que se requiera.

El espacio fsico donde sea ubicado el equipo de pruebas debe ser definido, es
recomendable que ste quede cerca del equipo de desarrollo, para que se
facilite la comunicacin y puedan interactuar fcilmente para llegar a fines
comunes.

El hardware y el software necesarios, debern ser configurados adecuadamente
para llevar a cabo las pruebas exitosamente.

55
2.10 Seleccionar las herramientas de pruebas

Para la seleccin de las herramientas, se debe tener en cuenta que las
escogidas deben ser las que ms se adapten al ambiente de pruebas, y al tipo
de aplicacin que se vaya a probar. Estas herramientas son un factor
importante en el xito de las pruebas.

En el plan de pruebas se debe especificar qu herramientas se van a utilizar y
quien es el proveedor de dicha herramienta. Igualmente los encargados de
utilizarlas debern revisar y aprobar el uso de ellas ya que la seleccin y el uso
deben ir de acuerdo con el plan de pruebas.

La seleccin de estas herramientas puede ser por la experiencia que se tenga
en su utilizacin o en la experiencia del equipo de pruebas.

2.11 Programar las pruebas

En este punto se especifica cundo cada mdulo de la aplicacin va a estar listo
para ser probado, el tiempo estimado para realizar dichas pruebas, fecha de
inicio y fecha estimada de finalizacin. Tambin se especifica el flujo de
actividades de pruebas y el responsable de realizar dichas actividades.

Se deben tener en cuenta todas las fases de la metodologa de desarrollo para
que los procesos se realicen en paralelo.

2.12 Establecer los procedimientos para el registro de errores

Durante toda la fase de pruebas se descubren defectos. De estos defectos debe
almacenarse o guardarse toda su informacin, como dnde fue encontrado y el
estado en que se encuentra:

56
Abierto: An no se ha asignado para correccin.
En revisin: Se encuentra siendo revisado por el equipo de desarrollo.
Listo para prueba: Se debe probar de nuevo.
Cerrado: El error ha sido corregido y probado nuevamente.

La informacin acerca de los defectos debe estar al alcance de los
desarrolladores y es til para tener las estadsticas de errores o el estado
general de una aplicacin. Como por ejemplo cuntos errores se han
encontrado y cuntos se encuentran sin corregir en el sistema.

Bsicamente la informacin que se debe suministrar es:

Identificador del error.
Nombre del error.
Descripcin del error.
Fecha en que fue descubierto.
Tipo de error. ( funcional, interfaz, lgico...)
Severidad del error.
Circunstancias en las que se encontr el error.
Datos ingresados.
Ambiente donde ocurri.
Diagnstico del error (cdigo).
Efecto que tiene el error en el programa.
Comentarios adicionales.





57
2.13 Definicin de los objetivos de las mtricas

Definir las mtricas

Michael [99] define las mtricas de software como La aplicacin continua de
mediciones basadas en tcnicas para el proceso de desarrollo del software y sus
productos para suministrar informacin relevante a tiempo, as el administrador
junto con el empleo de estas tcnicas mejorar el proceso y sus productos.
Las mtricas de software proveen la informacin necesaria para la toma de
decisiones tcnicas.

Se puede decir que una mtrica tiene las siguientes caractersticas:

Medible.
Independiente.
Contable.
Precisa

El objetivo de recolectar mtricas es hacer el proceso de pruebas ms eficiente.
Esto se consigue analizando los datos arrojados por el proceso de pruebas y
aplicando las acciones necesarias que se tomen a partir de estos resultados
para resolver los errores.

Algunas mtricas que se pueden utilizar son:

Anlisis de defectos: Cada defecto debe ser analizado para identificar
su causa, cmo fue detectado, en dnde, y por quin.
Efectividad de las pruebas: Que tan bien se estn realizando las
pruebas.
Correccin de errores: Cuantos errores se han corregido
completamente y cuantos no.
58
Estimacin de costo y esfuerzo.
Estado de las pruebas.

El siguiente es un ejemplo del contenido de un plan de pruebas:

1. Introduccin
1.1 Propsito
1.2 Resumen del proyecto
1.3 Documentacin del proyecto
1.4 Riesgos
2. Alcance
2.1 Alcance de las pruebas
2.2 Requerimientos del sistema
2.2.1 Requerimientos funcionales
2.2.2 Requerimientos no funcionales
2.3 Pruebas de interfaz
2.4 Pruebas de sistema y aceptacin
2.4.1 Pruebas de rendimiento
2.4.2 Pruebas de seguridad
2.4.3 Pruebas de volumen
2.4.4 Pruebas de estrs
2.4.5 Pruebas de compatibilidad
2.4.6 Pruebas de usabilidad
2.4.7 Pruebas de documentacin
2.4.8 Pruebas de backup y recuperacin
2.4.9 Pruebas de instalacin
2.5 Pruebas de regresin
2.6 Pruebas fuera del alcance
3. Pruebas
3.1 Estructura de las pruebas
3.2 Datos
59
3.3 Interfaz
3.4 Ambiente de pruebas
3.5 Dependencias
3.6 Estrategia de regresin
3.7 Seguimiento de errores
3.8 Solucin de errores
3.9 Recursos
3.9.1 Personal de pruebas
3.9.2 Ambiente de pruebas
3.9.3 Herramientas
3.10 Programacin de las pruebas
3.11 Administracin de la configuracin
3.12 Entregables
3.13 Mtricas
3.14 Criterio de terminacin de las pruebas
3.15 Reportes
3.16 Aprobacin

2.14 Revisar y aprobar el diseo

2.14.1 Programar y preparar la revisin

La revisin del plan de pruebas debe ser programada de tal manera que se logre
tener un avance entre ellas. Es importante que los participantes tengan la ltima
copia del plan de pruebas.

En la reunin que se lleve a cabo para la revisin, se debe primero hacer la
introduccin sobre los temas que se van a tratar. Luego de esto, deben
centrarse en cada uno puntos y discutir sus detalles.

60
La agenda realizada para la revisin debe contemplar el tiempo estimado para
terminar todos los puntos. En caso de no terminarse se debe programar una
siguiente reunin.

El propsito de esta revisin es lograr que se apruebe el plan de pruebas tanto
por el gerente del proyecto como por los desarrolladores. Cualquier sugerencia
o cambio debe ser realizado e incorporado al plan de pruebas.


2.14.2 Aprobacin

El plan de pruebas debe ser revisado por todos los responsables de su
ejecucin, y debe ser aprobado por el equipo de pruebas, lderes del proyecto y
lderes de desarrollo.

Es recomendable hacer una reunin donde se apruebe entre todos el plan de
pruebas.














61
FASE 2: HACER


Figura 7: Fase: Hacer (PHVA)

La etapa tres (Diseo de casos de prueba) y la etapa cuatro (Planeacin de las
pruebas) se encuentran en la fase Hacer.

A continuacin se detallan las actividades que se llevan a cabo en cada una de
estas etapas:














62
3. DISEO DE CASOS DE PRUEBA.

El principal objetivo del diseo de casos de prueba es obtener un conjunto de
pruebas que tengan la mayor probabilidad de descubrir los defectos del
software.

3.1 Disear las pruebas de funcin.

Para realizar esta actividad, se deben realizar las siguientes tareas:

3.1.1 Refinar los requerimientos de pruebas funcionales.

En este punto las especificaciones funcionales deben estar terminadas. Una
especificacin funcional es una lista detallada de las funciones del negocio, la
cual adems contiene la estructura y los estndares de las ventanas, los
mnimos requisitos del sistema para soportar la aplicacin, los tipos de
actividades que se realizan y perfiles de usuario, definiendo as con este
conjunto de datos las funciones bsicas del sistema y la forma en que el usuario
interacta con ste.

Una funcin de negocio es un aspecto controlable del negocio y es un pequeo
componente del sistema, cada uno de estos debe ser nombrado y descrito
utilizando el verbo objeto que indique la funcin que se quiere especificar del
sistema (Ej. cerrar caja). El criterio a usar para determinar la ejecucin exitosa
de cada funcin debe ser indicado.

Una especificacin funcional es usada para ilustrar los procesos (funciones del
negocio) en una estructura jerrquica con sucesivos niveles de detalle. Los
procesos elementales no son descompuestos en la especificacin (Ver tabla 1).
La especificacin funcional sirve como base para las pruebas funcionales, las
63
cuales tendrn mnimo un caso de prueba por cada nivel en la jerarqua.
Algunos ejemplos de funciones son: listar clientes, listar cuentas de un cliente,
pagar cuenta, generar factura, etc.

Las funciones de negocio constituyen el total de la aplicacin en varias
interfaces; una buena manera de recolectar esta informacin (las diferentes
funciones) es mediante la descomposicin detallada de los procesos y/o la
elaboracin de un flujo de datos del negocio.



Requerimientos de Prueba Funcionales (Administracin)

Procesamiento de Ordenes
Crear Orden
Llenar Orden
Editar Orden
Borrar Orden
Ver Detalle

Administracin de Clientes
Crear Cliente
Editar Cliente
Borrar Cliente

Administracin Financiera
Recibir Pago de Cliente
Depositar Pago
Pagar Nmina
Tabla 1. Especificacin Funcional

64
La estructura funcional de una ventana describe cmo sern implementadas las
funciones en este ambiente, qu informacin se presenta al usuario, las
restricciones, las posibles acciones en la ventana. Un ejemplo de una estructura
funcional puede ser:

Estructura Funcional de las ventanas de procesamiento de Ordenes.

Ventana principal de procesamiento de ordenes.

a. Esta ventana presenta el listado de las ordenes existentes en el sistema.
b. El listado de ordenes se presenta ordenado ascendentemente por nmero
de orden.
c. La informacin presentada es de solo lectura.
d. Por cada orden en el listado, se presentan los siguientes datos:
1. Nmero de Orden.
2. Nombre del Cliente.
3. Identificacin del Cliente.
4. Fecha de creacin de la Orden.
5. Nmero de factura.
6. Valor total
7. Icono que permite ver detalle de la Orden haciendo un click.
e. Al hacer doble click sobre un nmero de orden, se desplegar la ventana
de edicin de orden, en la cual es posible modificar la informacin.
f. No se genera scroll horizontal.
g. En la parte inferior del listado, a la izquierda aparece botn Regresar
para ubicarse nuevamente en el men principal, y a la derecha botn
Nuevo para crear nueva orden.




65
3.1.2 Construir una matriz de funcin/prueba

En este punto, se debe construir una matriz que relacione cada funcionalidad de
la aplicacin con el caso de prueba correspondiente, ilustrando de esta forma,
cul caso de prueba debe ser usado para cada funcionalidad. (Ver tabla 2).

La matriz es utilizada para llevar el control de los casos de prueba que deben ser
usados durante la ejecucin de las pruebas y adicionalmente puede ser utilizada
durante el mantenimiento de la aplicacin, por ejemplo, si una funcin es
cambiada, el equipo de mantenimiento puede utilizar la matriz para determinar
cul caso de prueba debe ser ejecutado o modificado. En la matriz, las
funcionalidades son listadas verticalmente y los casos de prueba
horizontalmente por cada funcionalidad, los casos de prueba son registrados en
la matriz con su nmero.

















66

CASO DE PRUEBA

FUNCIONALIDAD

1

2

3
Procesamiento de ordenes
Crear Orden CO01 CO02
Llenar Orden ALO01
Editar Orden EO01 EO02 EO03
Borrar Orden BO01 BO02
Ver Detalle VD01
Administracin de Clientes
Crear Cliente ACC01 ACC02
Editar Cliente EC01 EC02
Borrar Cliente BC01
Administracin Financiera
Recibir Pago de Cliente RPC01 RPC02 RPC03
Depositar Pago ADP01 ADP02
Pagar Nmina PN01
Tabla 2. Matriz de funcin/prueba

Es importante diferenciar cules casos de prueba se ejecutan manualmente y
cules automticamente; para esto se puede definir un estndar en la
asignacin del cdigo del caso de prueba, como en el ejemplo, los casos de
prueba que son automticos comienzan por la letra A y van seguidos por las
iniciales del nombre de la funcionalidad.

3.2 Disear pruebas de GUI. (Interfaz grfica de usuario)

El objetivo de un buen diseo de GUI debe ser consecuente con la amigabilidad
(apariencia y facilidad de uso) de la aplicacin para los usuarios. Un buen
67
diseo de GUI tiene dos componentes clave: interaccin y apariencia. La
interaccin esta asociada a la manera como el usuario interacta con la
aplicacin, y la apariencia a cmo luce la interfase para el usuario.

Las pruebas de GUI conciernen a la confirmacin de una correcta navegacin
por la aplicacin, las siguientes son algunos aspectos del diseo de GUI que el
encargado de realizar las pruebas debe tener en cuenta mientras prueba la
aplicacin:

Nueve directivas para un buen diseo de GUI:

1. Involucrar a los usuarios.
2. Comprender la cultura y experiencia de los usuarios.
3. Realizar prototipos continuamente para validar los requerimientos.
4. Permitir que el diseo sea conducido por el flujo de trabajo del
negocio de los usuarios.
5. Crear la GUI y las ayudas concurrentemente.
6. No contar con que los usuarios recuerden comandos secretos o
funciones.
7. Anticipar errores y no culpar al usuario.
8. Recordarle al usuario continuamente el estado de la aplicacin.
9. Hacerlo fcil.

3.2.1 Definir componentes GUI de la aplicacin.

La interfaz grfica de usuario (GUI) provee mltiples canales de comunicacin
usando palabras, grficos, animacin, sonido y video. Cinco componentes base
de la interfaz de usuario son: ventanas, mens, formas, conos y controles.


68
Ventanas: En un ambiente de ventanas, todas las interacciones del
usuario con la aplicacin ocurren a travs de ventanas. Esto incluye una
ventana principal, junto con un nmero de ventanas secundarias
generadas de la principal.
Mens: los mens se presentan en una variedad de estilos y formas, por
ejemplo: mens de accin (radio botones), listas desplegables, mens de
opciones, mens en cascada.
Formas: Las formas son ventanas en las cuales el usuario puede
adicionar informacin.
Iconos: Los conos son valiosos por su fcil reconocimiento, aprendizaje
y facilidad de navegacin a travs de la aplicacin.
Controles: un componente de control aparece en una ventana que
permite al usuario interactuar con la aplicacin y se identifica por medio
de su correspondiente accin. Los controles incluyen barras de mens,
listas desplegables, radio botones, cajas de chequeo, entre otros.

Un acercamiento para el diseo de pruebas de GUI incluye definir y nombrar
cada componente de GUI por su nombre, como es presentado en la tabla 3. En
el siguiente paso es desarrollada una lista de chequeo de componentes de GUI,
la cual puede ser usada para verificar cada componente.

Tabla 3. Matriz de Prueba de Componentes GUI
69
3.2.2 Disear pruebas de GUI

En la tarea anterior, los componentes de aplicacin GUI fueron definidos,
nombrados y categorizados en la matriz de prueba de componentes GUI. En la
presente tarea es elaborada una lista de chequeo para verificar cada
componente GUI. La lista debe cubrir todas las posibles interacciones y puede o
no aplicar a un componente particular.

Lista de chequeo:

Los siguientes son algunos tems para verificar en la GUI:

Acceso con doble click.
Acceso con un click.
Acceso por medio de un men.
Acceso mediante la barra de herramientas.
Opciones del click derecho del mouse.
Vnculos de ayuda.
Barra de botones.
Iconos de acceso.
Posibilidad de mltiples ventanas abiertas.
Cambiar la medida de las ventanas.
Aceptacin de valores vlidos en formularios.
Manejo de valores invlidos en los formularios.
Minimizacin y maximizacin de las ventanas.
Color.
Tabulacin de secuencias.
Cajas de chequeo.
Fuentes.
Arrastrar y soltar.
Cancelar.
70
Salir.
Aceptar.
Teclas rpidas.
Desplegar y plegar rboles.

Adicionalmente a los chequeos de componentes de GUI, se tiene un estndar de
diseo de GUI, el cual es esencial para asegurar que se siguen unas reglas de
construccin con el fin de lograr los niveles de consistencia deseados. Los
siguientes son algunos de los estndares GUI:

Usar colores llamativos.
Alineamiento de ventanas y tablas.
Funciones y teclas rpidas.
Consistencia en la ubicacin de los elementos en las ventanas.
Consistencia en los colores y grficos usados.
Presentacin de mensajes de error y caractersticas de las ayudas.
Secuencia lgica de objetos.
Consistencia en el tipo de letra.

3.3 Definir las pruebas de sistema y de aceptacin.

3.3.1 Identificar las pruebas potenciales del sistema

Las pruebas de sistema se encuentran en el nivel ms alto de la fase de pruebas
ya que estas evalan la funcionalidad del sistema como un todo, su rendimiento
y su adaptabilidad. Estas pruebas normalmente son ejecutadas internamente y
son orientadas a las caractersticas tcnicas, por el contrario, las pruebas de
aceptacin son pruebas orientadas a los usuarios.

71
Las pruebas de sistema consisten en una o ms pruebas que se basan en los
objetivos iniciales de la aplicacin y que fueron definidos en la entrevista que fue
realizada en la fase de recoleccin de la informacin. El propsito de esta tarea
es identificar y seleccionar las pruebas del sistema que van a ser realizadas y no
como estas se van a implementar.

Pruebas de rendimiento: La finalidad de estas pruebas es verificar y
validar que los requerimientos de rendimiento que fueron establecidos
sean cumplidos. Como por ejemplo tiempos de respuesta, la tasa de
transacciones y otros requerimientos de tiempo.

Pruebas de seguridad: Estas se realizan para probar la seguridad que
sea implementada en la aplicacin para garantizar la integridad y al
confidencialidad de la informacin.

Pruebas de volumen: Probar la aplicacin con volmenes grandes de
datos para verificar que sea capaz de manejarlos.

Pruebas de estrs: Probar la aplicacin en condiciones que
sobrecarguen los recursos. Se debe observar principalmente el tiempo
de respuesta.

Pruebas de compatibilidad: Probar la compatibilidad de la aplicacin
con otras aplicaciones o con otros sistemas.

Pruebas de usabilidad: Determinar que tan bien los usuarios van a
entender y a usar la aplicacin.

Pruebas de la documentacin: Asegurarse que la documentacin es
apropiada y gue correctamente por la aplicacin a los usuarios.

72
Pruebas de Backup: Verificar la capacidad del sistema para tener
respaldo de los datos en caso de un fallo de software o hardware.

Pruebas de recuperacin: Verificar la viabilidad del sistema para
recuperarse luego de una falla de software o hardware.

Pruebas de instalacin: Probar la instalacin y que esta sea exitosa.

3.3.2 Disear pruebas de fragmentos del sistema.

Una Prueba de fragmentos del sistema es la divisin de una prueba del sistema
que puede realizarse durante el desarrollo de la aplicacin. El objetivo de estas
pruebas es identificar tempranamente problemas o defectos que se pueden ver
reflejados en las pruebas del sistema.

Algunas pruebas de sistema que pueden ser fragmentadas son: pruebas de
seguridad, de rendimiento, usabilidad, documentacin y procedimientos. Por el
contrario, no pueden ser fragmentadas pruebas de instalacin, recuperacin,
etc.

3.3.3 Identificar pruebas potenciales de Aceptacin

Las Pruebas de aceptacin son pruebas que corren los usuarios para verificar
que la aplicacin cumple con los requerimientos especificados. El objetivo de
estas pruebas es demostrar que el sistema funciona. En ellas se hace menos
nfasis en las caractersticas tcnicas y se centra en si la aplicacin es til para
el usuario final.


73
3.4 Revisar y aprobar el diseo

3.4.1 Programar y preparar la revisin

La revisin del diseo de pruebas debe ser programada de tal manera que se
logre tener un avance entre ellas. Es importante que los participantes tengan la
ltima copia del documento con el diseo de las pruebas.

En la reunin que se lleve a cabo para la revisin, se debe primero hacer la
introduccin sobre los temas que se van a tratar. Luego de esto, deben
centrarse en cada uno de los puntos y discutir sus detalles.

La agenda realizada para la revisin debe contemplar el tiempo estimado para
terminar todos los puntos. En caso de no terminarse, se debe programar una
siguiente reunin.

El propsito de esta revisin es lograr que se apruebe el diseo de las pruebas
tanto por el gerente del proyecto como por los desarrolladores. Cualquier
sugerencia o cambio debe ser realizado e incorporado al diseo de las pruebas.

3.4.2 Aprobacin

El objetivo de la aprobacin es lograr que los participantes del proyecto estn de
acuerdo con el diseo de las pruebas. Esta aprobacin se debe realizar por
escrito y debe estar firmada por el gerente del proyecto, el lder de pruebas y el
lder de los desarrolladores. Se debe tambin elaborar y entregar un
documento donde encuentre la ultima copia del diseo de las pruebas con las
sugerencias y los cambios que se llevaron a cabo. Finalmente se debe indicar
que durante el ciclo de vida del proyecto el documento podr ser modificado.


74
4. DESARROLLO DE LAS PRUEBAS

El objetivo de esta etapa es documentar y transformar en formatos cada uno de
los casos de prueba para su posterior utilizacin en la ejecucin de las pruebas.

4.1 Desarrollar formatos de pruebas

4.1.1 Desarrollar formatos de pruebas de GUI

En un paso previo fue construida la matriz funcin/prueba que referencia los
casos de prueba con las funciones de la aplicacin. Las funciones son listadas
verticalmente y los casos de pruebas son listados horizontalmente.

En este paso los casos de prueba son documentados y transformados en
formatos de pruebas que puedan ser reutilizados y que contengan los datos de
las pruebas.

El formato de los casos de pruebas debe contener la siguiente informacin:

El nombre del caso de prueba
Nmero del caso.
La funcin que se va a probar.
El objetivo del caso de prueba.
Los pasos del caso de prueba.
Los resultados esperados.
Estado del caso ( pas / fall )
Nombre de quin realiza la prueba
Fecha de realizacin de la prueba.


75
El siguiente formato se puede tomar como muestra de recoleccin de
informacin de los casos de prueba


Tabla 4. Formato de casos de prueba


4.1.2 Desarrollar formatos de las pruebas de fragmentos del sistema

En un paso previo se disearon las pruebas de fragmentos del sistema. Estas
son pruebas de partes ms pequeas de la aplicacin o prueban funcionalidades
especificas del sistema.

En este paso los casos de prueba son documentados y transformados en
formatos de pruebas que puedan reutilizados. Un formato similar al visto en
pruebas GUI puede ser utilizado para documentar estos casos.

Es importante resaltar que debido a que en las pruebas de fragmentos del
sistema se involucran aspectos como rendimiento y seguridad, los objetivos y los
pasos podrn ser ms amplios y dicientes que los objetivos de pruebas de GUI.




76
4.2 Revisar y aprobar el desarrollo de las pruebas

4.2.1 Programar y preparar la revisin

La revisin del desarrollo de pruebas debe ser programada de tal manera que se
logre tener un avance entre ellas. Es importante que los participantes tengan la
ltima copia del documento del desarrollo de las pruebas.

La agenda realizada para la revisin debe contemplar el tiempo estimado para la
revisin de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunin.

El propsito de esta revisin es lograr que se apruebe el desarrollo de las
pruebas tanto por el gerente del proyecto como por los desarrolladores.
Cualquier sugerencia o cambio debe ser realizado e incorporado al desarrollo de
las pruebas.

4.2.2 Aprobacin

El objetivo de la aprobacin es lograr que los participantes del proyecto estn de
acuerdo con el desarrollo de las pruebas. Esta aprobacin se debe realizar por
escrito y debe estar firmada por el gerente del proyecto, el lder de pruebas y el
lder de los desarrolladores. Se debe tambin elaborar y entregar un
documento donde se encuentre la ltima copia del diseo y desarrollo de las
pruebas con las sugerencias y los cambios que se llevaron a cabo. Finalmente
se debe indicar que durante el ciclo de vida del proyecto el documento podr ser
modificado.




77
FASES 2 y 3: HACER Y VERIFICAR


Figura 8: Fases: Hacer y Verificar (PHVA)

La etapa cinco de la metodologa de pruebas (Evaluacin y ejecucin de las
pruebas) hace parte de las fases 2 y 3 (Hacer y verificar) del ciclo PHVA.

A continuacin se detallan las actividades que se llevan a cabo en esta etapa:















78
5. EVALUACIN Y EJECUCIN DE LAS PRUEBAS.

El objetivo de esta etapa es ejecutar los casos de pruebas y evaluar los
resultados obtenidos.

5.1 Ejecucin y Documentacin de las pruebas. (HACER)

5.1.1 Ejecucin de las pruebas de regresin.

El objetivo de esta actividad es ejecutar nuevamente las pruebas que arrojaron
errores anteriormente o las pruebas de funcionalidades que han sufrido
modificaciones. De esta manera se verifican las correcciones y se pueden
detectar errores en la aplicacin ocasionados por correcciones o modificaciones
al cdigo.

A lo largo de la vida del software, debe ser mantenido y dispuesto para su
utilizacin un conjunto de casos de prueba. Estos casos de prueba deben ser lo
suficientemente completos de tal modo que las funcionalidades de la aplicacin
puedan ser probadas a fondo. Mediante una matriz de reexaminacin (retest) se
pueden ubicar fcilmente los casos de prueba que sern utilizados para probar
los defectos encontrados en pruebas pasadas.

Una matriz de reexaminacin relaciona los casos de prueba con las funciones de
la aplicacin. Una entrada de chequeo en la matriz indica que el caso de prueba
es ejecutado nuevamente cuando la funcin (unidad del programa) sea
modificada debido a mejoras o correcciones. La matriz de reexaminacin puede
ser construida al inicio de las pruebas y debe ser mantenida durante las
siguientes pruebas, debido a que las funciones de la aplicacin pueden ser
modificadas durante el ciclo de desarrollo; pueden existir nuevos casos de
79
prueba que deben ser creados y chequeados en la matriz para la realizacin de
las pruebas.

Si al ejecutar un caso de prueba (realizar la prueba) de la matriz se obtienen los
resultados esperados, el estado del defecto en el reporte de defectos debe ser
cambiado a Cerrado.

5.1.2 Ejecutar una nueva sesin de pruebas.

El objetivo de esta actividad es ejecutar las pruebas (casos de prueba) que
fueron creadas desde la ltima ejecucin de pruebas realizada, pues en este
lapso de tiempo el equipo de pruebas ha actualizado el plan de pruebas, la
matriz de pruebas de GUI, los scripts (pruebas automticas), las pruebas de
fragmentos del sistema y las pruebas de aceptacin, en preparacin para las
siguientes pruebas. En este punto todas estas pruebas son ejecutadas.

5.1.3 Documentar los defectos arrojados por las pruebas.

Durante la ejecucin de las pruebas, los resultados deben ser reportados en la
base de datos de defectos. Los defectos generalmente estn relacionados con
casos de prueba individuales que ya han sido ejecutados. El objetivo de esta
tarea es elaborar un registro completo de los defectos encontrados, se debe
tener en cuenta que algunos defectos ya pueden estar registrados, por lo que se
debe concentrar, recolectar y consolidar toda la informacin relacionada con el
defecto. Es recomendable realizar el registro de los defectos digitalmente ya
que de esta forma es ms fcil hacerles seguimiento y localizar los defectos
duplicados.



80
5.2 Evaluacin de las pruebas. (VERIFICAR)

5.2.1 Analizar las mtricas.

El uso de mtricas nos ayuda a soportar el proceso de desarrollo y a tomar
decisiones con mas efectividad. El objetivo de esta tarea es aplicar los
principios de las mtricas para tener un buen control sobre el proceso de
pruebas.

En una actividad anterior se identificaron las mtricas que van a ser utilizadas, y
durante las pruebas se ha recogido informacin que permite realizar un anlisis
de los resultados obtenidos, esto incluye la cuantificacin de las mtricas y la
elaboracin de grficos con estos datos.

La siguiente es la informacin clave que un lder de pruebas necesita para saber
que las pruebas han sido finalizadas:

Estado de la ejecucin de los casos de prueba.

Cuntos casos de prueba fueron ejecutados, cuntos no fueron ejecutados y
cuntos descubrieron defectos. Estas preguntas proveen informacin acerca
de la productividad de las pruebas. Si los casos de prueba no han sido
ejecutados oportunamente, esto puede indicar la necesidad de asignar ms
personal al proyecto.

Anlisis de la diferencia de defectos.

Cul es la diferencia entre el nmero de defectos que han sido descubiertos
y los que han sido corregidos. Esto provee informacin acerca de la habilidad
de los desarrolladores para la correccin de defectos oportunamente. Si
81
existe una diferencia relativamente alta, esto puede indicar que quiz ms
desarrolladores deban ser asignados al proyecto.

Estado de la severidad de los defectos.

En este punto se debe evaluar cmo es la distribucin de la severidad de los
defectos (Ej. : severidad crtica, mayor y menor). Cuntos defectos con
severidad crtica, mayor y menor se encuentran abiertos, cuntos se han
resuelto. Si por ejemplo se encuentra un alto porcentaje de defectos con
severidad crtica abiertos, probablemente exista un nmero considerable de
caractersticas de la arquitectura y del diseo con debilidades.

Anlisis de la curva ingreso de defectos.

Graficar el nmero de defectos descubiertos peridicamente con el fin de
conocer los defectos que ingresan en cada lapso de tiempo y tomar medidas
segn la inclinacin de la curva, si sta se aproxima a cero indica que los
defectos estn disminuyendo, de lo contrario se concluye que el
descubrimiento de defectos es aun muy robusto y que muchos ms defectos
pueden ser descubiertos en las siguientes pruebas.

5.2.2 Refinar el cronograma de pruebas.

Con anterioridad fue elaborado un cronograma de pruebas que incluye los pasos
de las pruebas, las fechas de inicio y de finalizacin y las responsabilidades.
Durante el transcurso del desarrollo, el cronograma de las pruebas debe ser
continuamente monitoreado. El objetivo de esta actividad es actualizar el
cronograma con el fin de reflejar el estado actual; estas actividades son
responsabilidad del lder de pruebas:

Comparar el progreso actual contra el progreso planeado.
82
Evaluar los resultados para determinar el resultado de las pruebas.
Tomar las acciones apropiadas basado en la evaluacin.

Si el progreso de las pruebas no est segn lo planeado, el lder de pruebas
debe determinar los factores que ocasionaron el retrazo; generalmente una
causa de esto es la subestimacin del esfuerzo a invertir en las pruebas. Otro
factor puede ser el descubrimiento desmedido de defectos, causando que gran
parte del esfuerzo sea invertido en probar nuevamente la correccin de stos.

5.2.3 Identificar los cambios en requerimientos.

Con anterioridad los requerimientos funcionales fueron analizados mediante una
descomposicin jerrquica funcional, la estructura funcional y los estndares de
las ventanas y los requerimientos mnimos del sistema.

Durante el proceso de desarrollo, nuevos requerimientos pueden ser
introducidos, tales como:

Nuevas interfaces o componentes GUI
Modificacin de funciones.
Nuevas funciones.
Eliminacin de funciones.
Nuevos requerimientos de sistema, Ej. hardware.

Cada nuevo requerimiento debe ser identificado, registrado, analizado y
actualizado en el plan, el diseo y los scripts de pruebas.




83
FASE 4: ACTUAR


Figura 9: Fase: Actuar (PHVA)


La etapa seis de la metodologa de pruebas (Preparar las siguientes pruebas)
hace parte de las fases 4 (Actuar) del ciclo PHVA.

A continuacin se detallan las actividades que se llevan a cabo en esta etapa:














84
6. PREPARAR LAS SIGUIENTES PRUEBAS

El objetivo de esta actividad es preparar un nuevo ciclo de pruebas segn los
nuevos requerimientos y los resultados de las pruebas anteriores.
6.1 Refinar las pruebas.

6.1.1 Actualizar la matriz funcin / prueba.

El propsito de esta tarea es actualizar el diseo de las pruebas y la matriz de
funcin / prueba con los nuevos requerimientos. En el caso de la matriz las
nuevas funciones se aaden verticalmente y los nuevos casos de prueba
horizontalmente.

Para las pruebas de GUI, se deben actualizar los formatos aadiendo los nuevos
casos de prueba que resulten de los nuevos requerimientos.

6.1.2 Actualizar las pruebas de fragmentos del sistema.

En un paso anterior fueron definidas las pruebas de fragmentos del sistema. El
objetivo de estas pruebas es encontrar posibles problemas que pueda tener el
sistema.

El objetivo de esta tarea, es entonces, actualizar las pruebas de fragmentos del
sistema de acuerdo con los nuevos requerimientos.

6.1.3 Actualizar las pruebas de aceptacin.

En un punto anterior se definieron las posibles pruebas de aceptacin. Estas
pruebas son posibles pruebas orientadas al usuario que lo llevan a comprobar
que la aplicacin cumple con los requerimientos especificados.
85
El objetivo de este paso es actualizar las pruebas de aceptacin de acuerdo con
los nuevos requerimientos.

6.2 Examinar el equipo y el ambiente de pruebas

6.2.1 Evaluar el equipo de prueba

Antes de comenzar un nuevo ciclo de pruebas, se debe evaluar el equipo de
pruebas en cuanto a productividad, cumplimiento y calidad. El lder del equipo
de pruebas debe mirar que casos de prueba se llevaron a cabo de acuerdo con
el plan de pruebas. Debe tambin evaluar el cumplimiento de las tareas que se
haban programado y sacar conclusiones de cmo ha sido el comportamiento
del equipo. Si es necesario, el lder de pruebas debe integrar nuevos
participante en el equipo o cambiar a alguno para mejorar el rendimiento y la
productividad del grupo.

6.2.2 Evaluar el ambiente de pruebas

En un paso anterior se defini el ambiente de pruebas. Este ambiente provee la
infraestructura necesaria para llevar a cabo las pruebas durante toda las fases
del desarrollo.

El objetivo de este paso es revisar el adecuado funcionamiento de este ambiente
y realizar los cambios que sean necesarios de acuerdo con los nuevos
requerimientos.

Los principales componentes de un ambiente de pruebas incluyen las
herramientas de software, la tecnologa y el hardware. Tambin es necesario
revisar la configuracin tanto de las herramientas como del sistema operativo y
el hardware.
86

Algunos posibles cambios al ambiente de pruebas pueden ser:

Extender el laboratorio de pruebas.
Nuevas herramientas de pruebas.
Nuevo hardware requerido.
Cambios en las configuraciones de red.
Nuevo software.

6.3 Publicar reportes intermedios

Luego de realizar un ciclo de pruebas se deben realizar reportes que indiquen el
estado de las pruebas. Estos reportes deben ser realizados por el equipo de
pruebas, el lder de pruebas y el representante del grupo de desarrolladores. El
objetivo es identificar mejoras que se puedan realizar para el siguiente ciclo.

El reporte del estado de ejecucin de los casos de prueba puede ayudar a
identificar el estado de la aplicacin y a hacer predicciones de cundo puede
estar lista la liberacin de una nueva versin. (Figura 10.)

Se puede tambin con este reporte observar si hay muchos casos de pruebas
que no han sido ejecutados, y esto llevara a incrementar la productividad del
equipo de pruebas o de los recursos del ambiente de pruebas. Otro punto que
puede revelar el informe es el nmero de casos de pruebas que no se han
corregido o que corren con errores.

Otro reporte que puede ser til, es la distribucin de los errores encontrados
divididos en tres categoras: crtica, media, baja. ( Figura 11. )

87
Estado de los casos de pruebas
0
10
20
30
40
50
60
casos
completados
casos con
errores
casos no
ejecutados
Porcentaje

Figura 10: Estado casos de prueba

En esta figura se observa que el 50 % de los casos de prueba se han
completado sin errores, el 21 % han arrojado errores y el 29 % no se han
ejecutado todava. Esto puede significar que son necesarios ms recursos para
evacuar un mayor nmero de casos de prueba y poder liberar una nueva versin
mas rpidamente.



88
Severidad de los errores
0
5
10
15
20
25
30
35
40
45
Critica Media Baja
Porcentaje

Figura 11: Severidad de los errores

En este grfico se observa que el 33% de los errores encontrados son crticos,
esto puede indicar errores en las fases de diseo o en la arquitectura del
sistema.















89
FASES 1,2,3 y 4: PLANEAR, HACER, VERIFICAR Y ACTUAR



Figura 12: Fases: Planear, Hacer, Verificar y Actuar (PHVA)

La etapa siete de la metodologa de pruebas (Dirigir las pruebas del sistema) y la
etapa 8 (Dirigir las pruebas de aceptacin) hacen parte de las fases 1,2,3 y 4
(Planear, hacer, verificar y actuar) del ciclo PHVA.

A continuacin se detallan las actividades que se llevan a cabo en estas etapas:













90
7. DIRIGIR LAS PRUEBAS DEL SISTEMA

Las pruebas del sistema evalan el comportamiento, la funcionalidad y el
rendimiento de la aplicacin vindola como un todo. Estas pruebas consisten en
pruebas de estrs, volumen, rendimiento, seguridad, recuperacin, etc. El
objetivo de esta tarea es discutir cmo se deben preparar las pruebas, cmo
disearlas, ejecutarlas y reportar los errores encontrados.

7.1 Completar el plan de pruebas del sistema

7.1.1 Finalizar los tipos de prueba del sistema

En los pasos anteriores se ejecutaron las pruebas de fragmentos del sistema.
Cada una de ellas se elabor durante las distintas fases del proyecto. Ahora, el
objetivo de esta tarea es seleccionar las pruebas globales del sistema que van a
ser desarrolladas. Estas pruebas se basan o se plantean segn los objetivos
originales del proyecto que fueron definidos durante la fase de recoleccin de la
informacin.

Durante esta fase se debe definir el orden en que se van a ejecutar estas
pruebas. Un ejemplo de esto puede ser

Pruebas del rendimiento del sistema.
Pruebas que manejen un nivel alto de volumen de datos.
Pruebas de estrs.

Luego:

Pruebas de seguridad del sistema.
Pruebas de Backup y recuperacin.
91
Y por ltimo:

Pruebas de compatibilidad con otros mdulos o sistemas.
Pruebas a la documentacin.
Pruebas de instalacin.

Tambin, en esta fase se define qu pruebas se pueden realizar con
herramientas automticas. La ventaja de estas pruebas es que pueden ser
repetitivas y con ellas se pueden realizar ms exhaustivamente pruebas de
estrs por ejemplo.

7.1.2 Programar pruebas del sistema

En este paso lo que se debe hacer es programar cada una de las tareas que se
deben realizar para la ejecucin de las pruebas del sistema. Se debe
especificar la fecha de inicio y la fecha en la que se deben terminar, as como
tambin se debe nombrar el responsable de cada prueba.

7.1.3 Equipo para las pruebas del sistema

El equipo de pruebas del sistema es el encargado de disear, ejecutar y evaluar
los resultados de las pruebas. Est encargado tambin de reportar los errores y
las anomalas al grupo de desarrollo siguiendo, los procedimientos
anteriormente mencionados. Luego de que los errores sean corregidos el
equipo de pruebas de volver a ejecutar las pruebas para comprobar que no
hayan afectado otras funcionalidades de la aplicacin o para corroborar que las
fallas se han corregido.



92
En el equipo de pruebas debe haber un lder encargado de:

Organizar el equipo de trabajo.
Estabilizar y adecuar el ambiente de trabajo.
Organizar las polticas y estndares a utilizar.
Trabajar de acuerdo con el plan de pruebas.
Coordinar la documentacin.

7.1.4 Estabilizar el ambiente de pruebas:

El propsito de un buen ambiente de pruebas es dotar a los encargados del
aseguramiento de calidad de la infraestructura necesaria para las actividades de
pruebas.

Es importante dentro del ambiente de pruebas contar con la tecnologa
adecuada y las herramientas de pruebas adecuadas. Esta tecnologa incluye la
plataforma de hardware, la infraestructura de red con todos sus componentes, el
sistema operativo, y cualquier otra herramienta de software que se requiera.

El espacio fsico donde sea ubicado el equipo de pruebas debe ser definido, es
recomendable que ste quede cerca del equipo de desarrollo, para que se
facilite la comunicacin y puedan interactuar fcilmente para llegar a fines
comunes.

El hardware y el software necesarios, debern ser configurados adecuadamente
para llevar a cabo las pruebas exitosamente.




93
7.2 Tipos de pruebas del sistema

Durante esta fase los tipos de pruebas del sistema son diseados y
documentados.

7.2.1 Pruebas de rendimiento

El objetivo de las pruebas de rendimiento es medir el comportamiento del
sistema en cuanto al cumplimiento de objetivos tales como tiempos de respuesta
esperados. Los resultados obtenidos deben ser comparados con los resultados
esperados y documentar las diferencias que haya.

Las pruebas de rendimiento pueden ser una combinacin de pruebas de caja
negra y pruebas de caja blanca. En el primero de los casos se pueden realizar
cargas masivas de datos o realizar operaciones globales en la aplicacin. Para
las pruebas de caja blanca es necesario definir qu mdulos, instrucciones o
tareas especficas se quieren probar.

Algunas medidas que se pueden tomar en cuenta para la evaluacin de pruebas
de rendimiento son:

Uso del procesador.
Lectura / Escritura en discos.
Nmero de Lecturas / Escrituras por instruccin.
Velocidad de respuesta en red.
Utilizacin de memoria.
Tiempo medio de ejecucin por mdulo.
Porcentaje de tiempos de espera.
Espera entre mdulos.
Tiempo de inicio de la aplicacin o mdulos.
Tiempo de respuesta del sistema a las instrucciones.
94
Nmero de transacciones por minuto.

Las pruebas de rendimiento asumen que la aplicacin funciona, es estable y
slida. Por tanto, es importante eliminar tantas variables como sea posible de
las pruebas. Por ejemplo, los errores en el cdigo pueden crear la apariencia de
un problema de rendimiento o incluso enmascarar un problema de rendimiento.
Para comparar con precisin los resultados de diferentes pasadas de las
pruebas de rendimiento, la aplicacin debe funcionar correctamente. Es
especialmente importante restablecer la funcionalidad de la aplicacin si el
proceso de ajuste ha modificado la implementacin de un componente. La
aplicacin debe pasar las pruebas de funcionalidad para poder probar su
rendimiento. Adems de los cambios de la aplicacin, puede haber cambios
inesperados en el hardware, el trfico de la red, la configuracin del software, los
dispositivos del sistema, etc.

Para ajustar correctamente el rendimiento, deben mantenerse registros precisos
y completos de cada ejecucin de las pruebas. Los registros deben incluir:
La configuracin exacta del sistema, especialmente los cambios de
pasadas anteriores de las pruebas.
Los datos sin formato y los resultados calculados de las herramientas de
supervisin del rendimiento.
Estos registros no indican slo si la aplicacin cumple los objetivos de
rendimiento, sino que ayudan a identificar las posibles causas de problemas
futuros de rendimiento.

Durante cada ejecucin de las pruebas, se deben ejecutar exactamente el
mismo conjunto de pruebas de rendimiento; de lo contrario, no es posible
discernir si los resultados diferentes se deben a cambios en las pruebas o a
cambios en la aplicacin. Automatizar el conjunto de pruebas de rendimiento en
la medida de lo posible ayuda a eliminar diferencias de operador.
95
Otros factores aparentemente benignos causan impacto en los resultados de las
pruebas de rendimiento, como el tiempo que se ejecuta la aplicacin antes de
comenzar la prueba.

7.2.2 Pruebas de seguridad

El objetivo de las pruebas de seguridad es evaluar que la aplicacin tenga las
funciones adecuadas para asegurar la integridad y confidencialidad de la
informacin.

Uno de los puntos que debe probarse es el acceso a los recursos de la
aplicacin. Analizar diferentes caminos de usar un recurso con fines ilcitos o
dainos. Tambin es importante probar que la informacin slo pueda ser
cambiada o manipulada segn el tipo de usuarios o segn el mdulo de la
aplicacin.

Otros aspectos que se deben tener en cuenta son:

Acceso de usuarios al sistema.
Polticas de vencimiento o bloqueo de passwords de usuarios.
Roles de los usuarios.
Accesos remotos.
Las acciones maliciosas que puedan causar perdidas o daos..
Que daos pueden ocurrir a la informacin en caso de acciones
maliciosas.
Funciones o controles que se deben tener en cuenta para prevenir
acciones que puedan causar daos o perdidas en la informacin.
Funciones de seguridad para resguardar la informacin en caso de
errores humanos
Funciones de auditoria.
96
7.2.3 Pruebas de volumen

El objetivo de las pruebas de volumen es exponer el sistema a grandes
volmenes de datos y comprobar que sea capaz de manejarlo y comportarse de
la manera esperada.

Las pruebas de volumen extienden el sistema a sus lmites de diseo con
grandes volmenes de transacciones, datos, etc. Examina el funcionamiento del
sistema cuando est trabajando con grandes volmenes de datos y con
cantidades de datos no permitidas.

7.2.4 Pruebas de estrs

El objetivo de las pruebas de estrs es comprobar el comportamiento del
sistema aumentando la carga de procesamiento y de los recursos.
Principalmente se pueden observar los tiempos de respuesta y el cumplimiento
de los objetivos de la aplicacin.

Las pruebas de estrs ayudan a descubrir errores sutiles que, de otro modo, no
se detectaran hasta que se hubiese implementado la aplicacin. Estas pruebas
son pruebas del lmite del sistema, por ejemplo la mxima cantidad de usuarios
concurrentes.

7.2.5 Pruebas de compatibilidad

El objetivo de estas pruebas es chequear la compatibilidad de la aplicacin con
otros mdulos de la aplicacin, otras aplicaciones u otros sistemas. Estos tipos
de pruebas se deben realizar antes de salir a produccin, en ellos se
encontraran defectos que pueden no encontrarse en el ambiente de pruebas.

97
Un ejemplo de este tipo de pruebas es cuando la aplicacin comparte datos con
otras aplicaciones o est instalada en el mismo servidor con otros sistemas
compartiendo recursos como memoria.

7.2.6 Pruebas de Documentacin

El objetivo de las pruebas de documentacin es verificar que la documentacin
del usuario sea correcta y que los procedimientos que se indican en ella
funcionen adecuadamente.

Una buena documentacin ayuda a rebajar los costos de post venta ya que los
usuarios pueden resolver preguntas fcilmente sin tener que llamar a soporte.

Durante estas pruebas se debe seguir paso a paso las funciones que indica el
manual y pueden ser realizadas por usuarios finales, ya que para ellos es
realizada y es necesario comprobar su comprensin.

Algunas recomendaciones pueden ser:

Usar la documentacin como fuente para la elaboracin de casos de
pruebas.
Usar el sistema exactamente como dice la documentacin.
Probar todos los puntos y recomendaciones del manual.
Documentar los errores encontrados.
Asegurarse que la documentacin contemple todas las funcionalidades
del sistema.
Asegurarse que no se hable en terminologa muy tcnica.


98
7.2.7 Pruebas de Backup y Recuperacin

El objetivo de estas pruebas es ver la facilidad del sistema para realizar respaldo
y recuperacin de los datos y de la aplicacin en caso de un desastre o fallo de
hardware o software.

Algunas recomendaciones para estas pruebas son:

Hacer backup de todos los archivos.
Realizar respaldos de las bases de datos.
Realizar backup automticos si estos estn contemplados.
Verificar procedimientos de seguridad durante el backup.
Realizar el procedimiento completo de backup.
Restaurar parcialmente backups anteriores.
Restaurar completamente backups anteriores.
Realizar restauraciones automticas.

7.2.8 Pruebas de instalacin

El objetivo de estas pruebas es comprobar que la aplicacin se instale
correctamente. Tambin se deben incluir pruebas de desinstalacin y
reinstalacin y comprobar su funcionamiento.

7.3 Revisar y aprobar las pruebas del sistema.

7.3.1 Programar y preparar la revisin

La revisin de la planeacin de pruebas del sistema debe ser programada. Es
importante que los participantes de la reunin para la revisin tengan la ltima
copia del documento del plan de pruebas del sistema.
99

La agenda realizada para la revisin debe contemplar el tiempo estimado para la
revisin de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunin.

El propsito de esta revisin es lograr que se apruebe el plan de pruebas del
sistema tanto por el gerente del proyecto como por los desarrolladores.
Cualquier sugerencia o cambio debe ser realizado e incorporado al documento.

7.3.2 Aprobacin

El objetivo de esta actividad es que sea aprobado el diseo de las pruebas del
sistema por el equipo de calidad y el equipo de desarrollo. Esta aprobacin se
debe realizar por escrito y debe estar firmada por el gerente del proyecto, el lder
de pruebas y el lder de los desarrolladores. Se debe tambin elaborar y
entregar un documento donde se encuentre la ltima copia del diseo de las
pruebas con las sugerencias y los cambios que se llevaron a cabo. Finalmente
se debe indicar que durante el ciclo de vida del proyecto el documento podr ser
modificado.

7.4 Ejecutar las pruebas del sistema

7.4.1 Volver a probar fallos anteriores del sistema

El objetivo de esta tarea es realizar nuevamente las pruebas donde se
descubrieron errores. Algunos casos de pruebas son mantenidos durante todo
el ciclo de vida del proyecto. Estos casos se deben realizar para comprobar que
se cumplen todas las funcionalidades del sistema, enfocndose en las funciones
que se han modificado o que han sido objeto de correcciones.

100
Mediante una matriz de reexaminacin (retest) se pueden ubicar fcilmente los
casos de prueba que sern utilizados para probar los defectos encontrados en
pruebas pasadas.

7.4.2 Ejecutar las pruebas del sistema.

El objetivo de esta actividad es ejecutar las pruebas (casos de prueba) que
fueron creadas desde la ltima ejecucin de pruebas realizada, pues en este
lapso de tiempo, el equipo de pruebas ha actualizado el plan de pruebas, la
matriz de pruebas de GUI, los scripts (pruebas automticas), las pruebas de
fragmentos del sistema y las pruebas de aceptacin, en preparacin para las
siguientes pruebas. En este punto todas estas pruebas son ejecutadas.

7.4.3 Documentar los defectos arrojados por las pruebas.

Durante la ejecucin de las pruebas, los resultados deben ser reportados en la
base de datos de defectos. Los defectos generalmente estn relacionados con
casos de prueba individuales que ya han sido ejecutados. El objetivo de esta
tarea es elaborar un registro completo de los defectos encontrados, se debe
tener en cuenta que algunos defectos ya pueden estar registrados, por lo que se
debe concentrar en recolectar y consolidar toda la informacin relacionada con
el defecto. Es recomendable realizar el registro de los defectos digitalmente ya
que de esta forma es ms fcil hacerles seguimiento y localizar los defectos
duplicados.






101
8. DIRIGIR LAS PRUEBAS DE ACEPTACIN

Las pruebas de aceptacin son pruebas ejecutadas por un usuario para
demostrar que la aplicacin cumple con los objetivos del negocio y
requerimientos del sistema. Usualmente estn compuestas por subconjuntos de
pruebas del sistema. A continuacin se indica cmo preparar, disear y ejecutar
las pruebas de aceptacin y adicionalmente cmo reportar los defectos
descubiertos durante las pruebas.

8.1 Completar la planeacin de las pruebas de aceptacin.

8.1.1 Identificar los tipos de pruebas de aceptacin.

En esta actividad, la lista de la clasificacin de las pruebas iniciales de
aceptacin es refinada y son seleccionadas las pruebas que sern ejecutadas.

Las pruebas de aceptacin demuestran la habilidad de la aplicacin para reunir
todos los requerimientos del usuario. El objetivo de estas pruebas es demostrar
que la aplicacin funciona, en este punto se hace menos nfasis en las
caractersticas tcnicas y ms en verificar que el sistema es adecuado para el
usuario final. Las pruebas generalmente son ejecutadas por usuarios, quienes
en ocasiones definen pruebas especiales como pruebas de carga o de estrs
con el fin de sobrepasar los lmites del sistema.

8.1.2 Finalizar el cronograma de las pruebas de aceptacin.

En esta actividad el cronograma de las pruebas de aceptacin debe ser
finalizado incluyendo los pasos de las pruebas, fechas de inicio, finalizacin y
responsables. El cronograma adicionalmente debe describir cmo ser
revisado, cmo se le har seguimiento y cmo ser aprobado.
102

Para las pruebas de aceptacin, el equipo de pruebas usualmente est
conformado por usuarios delegados. Sin embargo el mbito del equipo de
pruebas y las herramientas para las pruebas son probablemente los usados
durante las pruebas del sistema. A continuacin se presenta un ejemplo de un
cronograma de pruebas de aceptacin:


Paso de la prueba
Fecha de
inicio
Fecha de
finalizacin
Responsable
Organizacin general
Organizar el equipo de pruebas
de aceptacin.
08/01/2004 08/07/2004
John, Director
de pruebas
Establecer el ambiente para las
pruebas de aceptacin
08/08/2004 08/09/2004
John, Director
de pruebas
Establecer las herramientas para
las pruebas de aceptacin
08/10/2004 08/10/2004 Juan, Tester
Pruebas de Aceptacin
Diseo / Escritura de las
pruebas
12/11/2004 12/15/2004
Juan (usuario),
Testers
Revisin de las pruebas 12/16/2004 12/16/2004
Jhon, Director
de pruebas
Ejecucin de las pruebas 12/17/2004 12/22/2004
Juan (usuario),
Testers
Probar nuevamente los defectos
de aceptacin
12/23/2004 12/25/2004
Juan (usuario),
Testers
Tabla 5: Cronograma de pruebas



103
8.1.3 Organizar el equipo de pruebas de aceptacin.

El equipo de pruebas de aceptacin es responsable de disear y ejecutar las
pruebas, evaluar los resultados de las pruebas y reportar cualquier defecto
usando el sistema de seguimiento de defectos. Cuando los desarrolladores
corrigen los defectos, el equipo de pruebas prueba nuevamente los puntos en
los que se encontraron, para asegurar la correccin. El equipo de pruebas de
aceptacin usualmente cuenta con un representante de los usuarios de la
aplicacin que finalmente es quien acepta el sistema.

El equipo de pruebas de aceptacin es liderado por un director de pruebas, que
tiene las siguientes responsabilidades:

Organizar el equipo de pruebas.
Establecer el ambiente para las pruebas.
Definir las polticas de pruebas, procedimientos y estndares.
Asegurar la preparacin de las pruebas.
Trabajar en el plan de pruebas y controlar el proyecto.
Hacer seguimiento de costos de las pruebas.
Asegurar que la documentacin de las pruebas es exacta y oportuna.
Coordinar el equipo.

8.1.4 Establecer el ambiente de pruebas de aceptacin.

Durante esta actividad se finaliza el ambiente para las pruebas de aceptacin, el
cual generalmente es el mismo que se us para las pruebas del sistema. El
propsito del ambiente de pruebas es proveer la infraestructura necesaria para
las actividades de prueba. Para esta tarea las necesidades del ambiente de
pruebas se establecen y se repasan antes de su implementacin.

104
Los componentes principales del ambiente de pruebas incluyen la facilidad, la
tecnologa, y las herramientas de las pruebas. El componente facilidad de las
pruebas se refiere a la disposicin y configuracin fsica. La tecnologa se
refiere al hardware, redes y sus componentes, sistema operativo, entre otros. El
componente herramientas se refiere a cualquier software de pruebas
especializado, herramientas de pruebas automatizadas, libreras de pruebas y
software de soporte.

La facilidad de las pruebas y el lugar de trabajo deben ser establecidos. Este
puede extenderse de una configuracin individual del lugar de trabajo a un
laboratorio de pruebas formal; de cualquier forma, es importante que los
probadores estn juntos y cerca del equipo de desarrollo. Esto facilita la
comunicacin y la tenencia del sentido de una meta comn.

El hardware y el software de pruebas deben ser instalados. Esto en
coordinacin con los vendedores, los usuarios y el personal de tecnologa de
informacin. Puede ser necesario probar el hardware y coordinar con los
vendedores de hardware, adicionalmente las redes de comunicaciones
necesitan ser instaladas y ser probadas.

8.1.5 Instalar las herramientas para las pruebas de aceptacin.

Durante esta actividad, las herramientas para las pruebas de aceptacin son
instaladas y verificadas. Se debe realizar una ejecucin de los casos de prueba
y de los scripts de las pruebas para verificar que las herramientas estn listas
para las pruebas de aceptacin. Algunas otras consideraciones para tener en
cuenta en la preparacin de las herramientas son:

Capacitar al equipo de pruebas en el uso de las herramientas.
Verificar compatibilidad de las herramientas con el ambiente de
operacin.
105
Asegurar espacio en disco para las herramientas.
Garantizar comunicacin directa con el proveedor de las herramientas.
Verificar si es necesario modificar los procedimientos de las pruebas para
acomodarse a las herramientas.
Instalar la ltima versin de las herramientas.

8.2 Completar los casos de pruebas de aceptacin.

En esta actividad, los casos de prueba de aceptacin se disean y se escriben.
Los casos de prueba funcionales, se transforman en casos reutilizables para
pruebas de aceptacin con los datos de prueba creados.

8.2.1 Identificar el subconjunto de pruebas del sistema que se
utilizarn para pruebas de aceptacin.

Los casos de prueba de aceptacin generalmente (no siempre) son
desarrollados por el usuario final y normalmente no son responsabilidad de la
empresa desarrolladora, porque las pruebas de aceptacin comparan los
requisitos originales del sistema y las necesidades de los usuarios. Es la prueba
final para que los usuarios acepten o rechacen el sistema. Los usuarios finales
proveen los recursos de las pruebas y realizan sus propias pruebas. Pueden o
no utilizar el mismo ambiente de pruebas que fue utilizado durante las pruebas
del sistema, depende de s las pruebas sern ejecutadas en el ambiente de
trabajo del usuario final o no.

Generalmente, las pruebas de aceptacin consisten en un subconjunto de las
pruebas del sistema que se han diseado ya durante las pruebas del sistema.
Por tanto, la tarea actual consiste en identificar cules de las pruebas del
sistema sern utilizadas para las pruebas de aceptacin.

106
8.2.2 Disear y escribir pruebas de aceptacin adicionales

Las pruebas de sistema que se ejecutarn nuevamente durante las pruebas de
aceptacin, pueden ser complementadas con condiciones especiales para
maximizar la aceptabilidad del sistema. Por ejemplo, una prueba de aceptacin
pudo requerir que un cierto rendimiento de procesamiento est sostenido por un
perodo de tiempo con lmites de tolerancia aceptables del tiempo de respuesta.

Otras pruebas no diseadas durante las pruebas del sistema pueden ser
previstas por el usuario, pues ste tiene mas conocimiento acerca de los
requisitos y las operaciones del negocio, puede que el usuario descubra
defectos que solamente un usuario final ve. Esto tambin ayuda al usuario a
estar listo para lo que se va a instalar y a poner en produccin realmente de
manera que no se creen falsas expectativas.

El diseo de las pruebas de aceptacin puede incluir el uso de datos coherentes,
porque probablemente se dar ms fcilmente la aceptacin de los resultados
de las pruebas si se parecen a los datos reales del usuario.

8.3 Revisar el plan de pruebas de aceptacin.

8.3.1 Programar y llevar a cabo la revisin.

La revisin del plan de pruebas de aceptacin se debe programar antes de la
revisin real y los participantes deben tener la ltima versin del plan de
pruebas.

Como con cualquier entrevista o revisin, se deben tener en cuenta cuatro
elementos. El primero define qu ser discutido; el segundo presenta los
detalles; el tercero resume y el cuarto se refiere a la puntualidad.

107
El revisor debe indicar la duracin estimada para la revisin y aclarar que si el
tiempo expira antes de terminar todos los puntos de la agenda deber ser
programada otra revisin para continuar.

El propsito de esta actividad es que los desarrolladores y el gerente del
proyecto convengan y acepten el plan de pruebas. Si hay algunos cambios
sugeridos al plan de pruebas durante la revisin, estos deben ser incorporados
en el plan.

8.3.2 Aprobar el plan de pruebas de aceptacin.

La aprobacin del plan de pruebas es crtica ya que ayuda a proporcionar los
acuerdos necesarios entre las pruebas, los desarrolladores, y el gerente del
proyecto. Esta aprobacin se debe realizar por escrito y debe estar firmada por
el gerente del proyecto, el lder de pruebas y el lder de los desarrolladores. Se
debe adjuntar al documento el ltimo plan de pruebas e indicar que se han
incorporado todos los comentarios al respecto y que si no se habla nada al
respecto se asume que todos estn de acuerdo con el plan.

8.4 Ejecutar las pruebas de aceptacin.

8.4.1 Ejecutar las pruebas de aceptacin de los errores encontrados en
las pruebas anteriores.

El propsito de esta tarea es ejecutar nuevamente las pruebas que descubrieron
defectos en las anteriores pruebas de aceptacin. Estas pruebas detectan los
errores causados por modificaciones o correcciones realizadas al software.

Los casos de prueba deben ser bastante completos de manera que se cubran
todas las funcionalidades de la aplicacin a fondo. El problema se enfoca en
108
cmo localizar esos casos de prueba para probar los defectos descubiertos
durante las pruebas anteriores, un buen mecanismo es la matriz de
reexaminacin.

Como se mencion anteriormente, una matriz de reexaminacin relaciona los
casos de prueba con las funciones (o las unidades del programa). Un chequeo
en la matriz indica que el caso de prueba debe ser reexaminado cada vez que la
funcin (o la unidad del programa) sea modificada debido a una mejora o a una
correccin. Ninguna entrada significa que la prueba no necesita ser ejecutada
nuevamente. La matriz de reexaminacin puede ser construida antes de las
primeras pruebas y debe ser actualizada y usada durante las siguientes
pruebas. Mientras que las funciones (o las unidades del programa) se modifican
durante el desarrollo, los casos existentes o nuevos de prueba necesitan ser
creados e ingresados en la matriz de reexaminacin en la preparacin para las
siguientes pruebas.

Si se observa que algunas funciones estn estables y no han tenido
modificaciones recientes, se puede retirar (s existe) su chequeo de la matriz de
reexaminacin.

8.4.2 Ejecutar las actuales pruebas de aceptacin.

El propsito de esta tarea es ejecutar las pruebas de aceptacin creadas desde
la ltima ejecucin de pruebas. Durante este lapso de tiempo, el equipo de
pruebas debe haber puesto al da las funciones/GUI, los fragmentos del sistema,
y las pruebas de aceptacin en la preparacin para estas pruebas.




109
8.4.3 Documentar los defectos de aceptacin.

Durante la ejecucin de las pruebas de aceptacin, los resultados de las
pruebas deben ser reportados en la base de datos de defectos. Estos defectos
generalmente estn relacionados con casos de prueba individuales que han sido
ejecutados, sin embargo, variaciones a los casos de prueba formales a menudo
descubren otros defectos. El objetivo de esta actividad es producir un
expediente completo de los defectos descubiertos. Si el paso de la ejecucin se
ha registrado correctamente, los defectos ya se deben encontrar registrados en
la base de datos, si este es el caso, el objetivo se convierte en recoger y
consolidar la informacin del defecto.

Existen herramientas que se pueden utilizar para consolidar y registrar defectos
dependiendo de los mtodos de la ejecucin de la prueba. Si los defectos se
registran en papel, la consolidacin implica recoger y organizar todos los
papeles. Si los defectos se registran electrnicamente, las caractersticas de
bsqueda pueden localizar fcilmente los defectos duplicados.














110
9. RESUMEN DE PRUEBAS Y REPORTE FINAL

9.1 Resumen y consolidacin de la informacin de pruebas.

9.1.1 Pruebas ejecutadas y terminadas

El objetivo de esta tarea es que el equipo de pruebas, con base en el plan de
pruebas, verifique que todas los casos y todas las pruebas hayan sido
ejecutadas y que todos los errores hayan sido resueltos. Para esto, se deben
basar en los documentos que se han generado durante todo el desarrollo de las
pruebas y el estado en que se encuentran los errores. Si hay algn error que no
ha sido resuelto se debe dar mayor nfasis a l y se debe disponer de los
recursos necesarios para estabilizar la aplicacin.

9.1.2 Consolidar los errores por casos de prueba y funciones.

En esta fase, el equipo de pruebas debe consolidar la informacin que se
encuentra en la documentacin de los errores, donde se especifica en qu
estado se encuentra el error. Se debe especificar el caso de prueba exacto en
que ocurri el error y el nmero de errores para dicho caso.

9.1.3 Documentar errores no corregidos

Para los errores que no han sido corregidos, se debe especificar tambin el caso
de prueba y la funcin en donde ocurri. Esto se debe documentar en la matriz
de prueba / funcin.


111
9.2 Reporte final

En esta etapa se prepara y se construye el reporte donde se sumariza el
resultado de todo el ciclo de pruebas. Este reporte servir como un punto base
para conocer la estabilidad de la aplicacin.

9.2.1 Resumir las actividades y eventos durante el desarrollo de las
pruebas.

Se debe resumir informacin sobre:

El equipo de pruebas: Especificar quines conforman el equipo de
pruebas, qu papel desempea cada uno dentro del equipo y qu cargo
tienen. ( ej. Diseador de pruebas, ejecutor, etc. )
El ambiente de pruebas: Describir el ambiente de hardware y software en
que se ejecutaron las pruebas, como tecnologas utilizadas, herramientas,
redes, etc.
Tipos de pruebas: Especificar qu tipos de pruebas se utilizaron y cuntas
por cada tipo ( pruebas de sistema, pruebas de aceptacin, etc. )
Eventos: Indicar qu eventos externos e internos afectaron el desarrollo
de las pruebas y qu impacto tuvieron sobre la aplicacin.

9.3 Crear y analizar grficos de mtricas.

El objetivo de esta tarea es analizar las mtricas que se midieron durante el ciclo
de pruebas del proyecto. Para ello se deben crear grficos que ayuden a un
mejor anlisis y comprensin de los resultados de las pruebas. Este anlisis
sirve como instrumento para determinar la calidad y la aceptabilidad del sistema
as como para futuros proyectos.

Algunas mtricas y grficos sugeridos son:
112
Seguimiento de errores

En este grfico se puede hacer un seguimiento de los errores en el tiempo.
Analizando el comportamiento de los errores que entran, los abiertos y los
corregidos . Por ejemplo si la cantidad de errores abierto debe tender a bajar,
de lo contrario la efectividad del equipo de pruebas puede estar fallando.


Figura 13: Seguimiento de errores

Defectos por funcin:

Analizar el nmero de defectos encontrados por cada una de las funciones o
grupos de funciones de la aplicacin. Con esta medida se puede identificar
cuales funciones presentaron ms problemas y encontrar as posibles causas de
esto; por ejemplo un mal diseo de los requerimientos. ( tabla 6 )


113


FUNCIONALIDAD

Nmero de defectos

Porcentaje
Procesamiento de ordenes
Crear Orden 10 20
Llenar Orden 8 16
Editar Orden 3 6
Borrar Orden 4 8
Ver Detalle 7 14
Administracin de Clientes
Crear Cliente 4 8
Editar Cliente 4 8
Borrar Cliente 3 6
Administracin Financiera
Recibir Pago de Cliente 0 0
Depositar Pago 3 6
Pagar Nmina 4 8
Total 50 100
Tabla 6: Defectos por funcin


Severidad de los errores encontrados

El objetivo de esta mtrica es mostrar los errores encontrados divididos segn
su severidad y el efecto en la aplicacin. En este reporte se observa que los
errores crticos en las pruebas finales fueron pocos y que la aplicacin en
general present errores de severidad baja. ( Figura 13 )

114
Severidad de los errores
0
10
20
30
40
50
60
70
80
90
Critica Media Baja
Porcentaje

Figura 14: Severidad de errores


Diferencia entre errores encontrados y errores corregidos

Este grfico debe mostrar la mayor similitud posible entre la lnea de errores
encontrados y errores corregidos. Al final del desarrollo, la diferencia que haya
entre las dos ser una buena medida de la calidad de la aplicacin.

Causas del error

El objetivo es mostrar el porcentaje de las causas de los defectos, como por
ejemplo: conectividad, arquitectura, base de datos, etc.

En el siguiente grfico se puede observar que un gran porcentaje de los errores
est relacionado con la funcionalidad del sistema. Esto puede indicar problemas
en la toma de requerimientos o en el diseo de las funcionalidades. ( Figura 14)
115

Figura 15: Causas del error

Quin encontr los errores

El objetivo es mostrar quin encontr los errores de la aplicacin, como por
ejemplo clientes externos, el equipo de calidad, etc. La mayora de los errores
deben ser encontrados por el equipo de calidad. En caso de que terceros o
usuarios internos sean los que descubren los errores, se debe revisar el papel
del equipo de calidad y pruebas.


116
Estado final de la ejecucin de los casos de prueba

El reporte del estado final de la ejecucin de los casos de prueba muestra qu
casos han sido resueltos y nos indican si la aplicacin esta lista para su
liberacin a produccin. Al final, en este reporte se debe indicar que todos las
funcionalidades han sido probadas y estn correctas; si se encuentra alguna
excepcin esta debe estar completamente documentada. (Figura 15)

Estado de los casos de pruebas
0
20
40
60
80
100
casos
completados
casos con
errores
casos no
ejecutados
Porcentaje

Figura 16: Estado Final de los casos de prueba



Reporte de defectos en las pruebas globales del sistema.

En este reporte se ilustran en que tipo de pruebas se encontraron los errores en
la etapa de pruebas globales del sistema. (Figura 16)


117

Figura 17: Defectos en pruebas del sistema.

En este reporte se puede observar que el 25% de los errores se encontraron en
las pruebas de rendimiento. Esto puede indicar que la infraestructura en donde
corre la aplicacin no es la adecuada o requiere una mejora.




118
Reporte de defectos en las pruebas de aceptacin

El objetivo de este reporte es demostrar que la aplicacin cumple con los
objetivos del negocio y requerimientos del sistema y que la aplicacin funciona.
Este reporte puede estar compuesto por los tipos de prueba del sistema. Al final
la mayor parte de los requerimientos deben quedar segn las exigencias de los
usuarios.


Figura 18: Defectos en pruebas de aceptacin

119
9.4 Conclusiones y Recomendaciones

En esta seccin del reporte final, el equipo de pruebas y el grupo de calidad
deben concluir en qu aspectos se fall y deben hacer las recomendaciones
para futuras mejoras.

Las conclusiones y recomendaciones deben ser ledas por los participantes del
proceso para comprobar que sean correctas y que se puedan realizar. Cada
conclusin y recomendacin debe ser documentada.

9.4.1 Programar y preparar la revisin

La revisin del reporte final debe ser programada. Es importante que los
participantes de la reunin para la revisin tengan la ltima copia del reporte
final.

La agenda realizada para la revisin debe contemplar el tiempo estimado para la
revisin de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunin.

El propsito de esta revisin es lograr que se apruebe el reporte final, tanto por
el gerente del proyecto como por los desarrolladores. Cualquier sugerencia o
cambio deber ser revisado y anexado al documento.

9.4.2 Aprobacin

El objetivo de la aprobacin es lograr que los participantes del proyecto estn de
acuerdo con el reporte. Esta aprobacin se debe realizar por escrito y debe
estar firmada por el gerente del proyecto, el lder de pruebas y el lder de los
desarrolladores. Se debe tambin elaborar y entregar un documento donde se
120
encuentre la ltima copia del reporte final con las sugerencias y los cambios que
se llevaron a cabo.





























121
CONCLUSIONES

La mejora del proceso de pruebas requiere un alto grado de conocimiento
y experiencia por parte del personal involucrado, al menos en las reas
de pruebas, organizacin y administracin de cambios.

El diseo de pruebas es uno de los mecanismos ms efectivos de
prevencin de errores ya que el objetivo de esta actividad es crear
pruebas tiles que puedan descubrir y eliminar problemas en cada etapa
del desarrollo.

Muchas organizaciones no realizan actividades de verificacin tales como
inspecciones del software, planeacin y diseo temprano de las pruebas.
Estas actividades proporcionan informacin oportuna para reducir
defectos cuando es menos costoso fijar y mejorar los mtodos, tcnicas y
procesos en el desarrollo. Adicionalmente, brindan la informacin
necesaria para preparar la siguiente fase de las pruebas hacindolas ms
completas y enfocndose siempre en el mejoramiento continuo.

Menos defectos en software conducen a menos esfuerzo en la ejecucin
de las pruebas, cuantas menos pruebas encuentren defectos, menos
pruebas necesitan ser realizadas de nuevo debido a que se corrigen
menos defectos.

La realizacin de pruebas ineficazmente, o peor aun, la ausencia de un
proceso claro para la ejecucin de stas puede ser perjudicial para las
empresas, ya que se invierte tiempo y dinero que finalmente se pierde en
esfuerzos que no dan resultados y no mejoran el proceso. La
implementacin de la metodologa para la realizacin de pruebas
contribuye al mejoramiento continuo del proceso y asegura que el tiempo
y dinero invertido en las pruebas es consumido eficaz y eficientemente.
122

La realizacin de pruebas de software es una parte importante del
proceso de desarrollo de software. No es una simple actividad que se
lleva a cabo despus de la implementacin del cdigo pues es parte de
cada etapa del ciclo de vida. Una estrategia de pruebas exitosa debe
comenzar desde la especificacin de los requerimientos. Los detalles de
las pruebas sern especificados a travs de los diseos de alto y bajo
nivel del sistema y las pruebas sern llevadas a cabo por un grupo de
pruebas y por los desarrolladores durante el ciclo de vida del desarrollo.
Como con las otras actividades en el ciclo de vida del software, las
pruebas tienen sus propios objetivos. Mientras los sistemas de software
son ms complejos, la importancia y la efectividad de los esfuerzos
invertidos en las pruebas deben incrementarse.

Las empresas dedicadas al desarrollo de software intentan aumentar la
calidad de sus productos para evitar los problemas inherentes a sus
procesos: plazos y presupuestos incumplidos, insatisfaccin del usuario,
escasa productividad y la baja calidad en el software producido. Las
empresas son conscientes de que el mercado valora, cada da ms, la
calidad. Por tanto, las compaas exigen la disminucin de errores y
penalizan los retrasos en entregas y las cancelaciones de proyectos. El
problema esta en que a menudo los profesionales no saben cmo
aumentar la calidad de sus desarrollos de software de una forma eficaz.
Una herramienta clave para conseguir una aplicacin de alta calidad y
libre de errores es contar con un proceso de pruebas efectivo.
Lamentablemente, y aunque es una de las tcnicas fundamentales de
aseguramiento de calidad, al proceso de pruebas no se le suele dar la
importancia que merece, lo que significa que las empresas no cuentan
con una buena metodologa y/o con las herramientas adecuadas para
disear e implementar un proceso de pruebas adecuado a sus
necesidades.
123

Debido a la complejidad de probar una aplicacin, la etapa de pruebas
puede llegar a ser de las ms lentas del proceso de desarrollo de
software. Sin embargo, si un proceso de pruebas se desarrolla siguiendo
una planificacin, una metodologa y unas herramientas adecuadas se
pueden conseguir importantes disminuciones en los costos de desarrollo
y mantenimiento del software, as como una reduccin en el nmero de
errores.























124
BIBLIOGRAFA


Pressman, Roger S. (2002). Ingeniera del Software: Un enfoque prctico;
Quinta edicin. Mc Graw-Hill, Madrid.

Putnam, Lawrence H. & Myers, Ware (1996). Executive Briefing: Controlling
Software Development. IEEE Computer Society Press. Los Alamitos, CA.

Raynus, Joseph (1999). Software Process Improvement with CMM. Artech
House, Inc. Norwood, MA.

Sanders, Joc & Curran, Eugene (1994). Software Quality. A Framework for
Success in Software Development and Support. ACM Press, Dublin, Ireland.

Sommerville, Ian (2002). Ingeniera de Software; Sexta edicin. Pearson
Educacin, Mxico, D. F.


Sitios en Internet

http://www.avantare.com/anteriores/ElModeloCMM.pdf
http://www.sogeti.nl/images/ios/upload/tpi_spaans.PDF
http://siul02.si.ehu.es/~alfredo/iso/programaISO2002.htm
http://mailweb.udlap.mx/~tesis/lis/garcia_r_ci/capitulo6.pdf




125