Prueba s Desist Em At
125
METODOLOGÍA PARA LA REALIZACIÓN DE PRUEBAS DE SOFTWARE Juan David Rodríguez Jaramillo Paula Andrea López Gutiérrez Trabajo de grado para optar al título de Ingeniero de Sistemas Asesor RAFAEL RINCÓN BERMÚDEZ Magíster en Matemáticas Aplicadas Magíster en Sistemas de Calidad DEPARTAMENTO DE INFORMATICA Y SISTEMAS ESCUELA DE INGENIERÍA UNIVERSIDAD EAFIT MEDELLÍN 2004
-
Upload
geovanny-elias-montiel-francisco -
Category
Documents
-
view
26 -
download
0
Transcript of Prueba s Desist Em At
METODOLOGÍA PARA LA REALIZACIÓN DE PRUEBAS DE SOFTWARE
Juan David Rodríguez Jaramillo
Paula Andrea López Gutiérrez
Trabajo de grado para optar al título de
Ingeniero de Sistemas
Asesor
RAFAEL RINCÓN BERMÚDEZ
Magíster en Matemáticas Aplicadas
Magíster en Sistemas de Calidad
DEPARTAMENTO DE INFORMATICA Y SISTEMAS ESCUELA DE INGENIERÍA
UNIVERSIDAD EAFIT MEDELLÍN
2004
TABLA DE CONTENIDO INTRODUCCIÓN ............................................................................................................. 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. TÉCNICAS DE DISEÑO DE CASOS DE PRUEBAS ...................................... 18 6. ESTRATEGIAS DE PRUEBA DEL SOFTWARE.............................................. 32
6.1 Pruebas de unidad ............................................................................................. 32 6.2 Pruebas de integración ...................................................................................... 33
7. LOS MODELOS INTERNACIONALES Y LAS PRUEBAS .............................. 34 8. METODOLOGÍA DE PRUEBAS DE SOFTWARE ........................................... 38 FASE 1: PLANEAR....................................................................................................... 39 1. RECOLECCIÓN DE INFORMACIÓN ................................................................. 40
1.1 Preparación 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 planeación del proyecto ......................................................... 43 1.2.4 Conocer la metodología de desarrollo ...................................................... 44 1.2.5 Conocer las reglas de negocio................................................................... 45 1.2.6 Análisis 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. PLANEACIÓN DE LAS PRUEBAS ..................................................................... 48 2.1 Definir el identificador del plan........................................................................ 48 2.2 Preparar la introducción.................................................................................... 49 2.3 Identificar los requerimientos ........................................................................... 49 2.4 Identificar los tipos de prueba........................................................................... 50 2.5 Identificar cuándo terminar las pruebas............................................................ 51 2.6 Establecer la estrategia de pruebas de regresión............................................... 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 Definición de los objetivos de las métricas....................................................... 58 2.14 Revisar y aprobar el diseño............................................................................... 60
2.14.1 Programar y preparar la revisión............................................................... 60 2.14.2 Aprobación................................................................................................ 61
FASE 2: HACER ........................................................................................................... 62 3. DISEÑO DE CASOS DE PRUEBA. .................................................................... 63
2
3.1 Diseñar las pruebas de función. ........................................................................ 63 3.1.1 Refinar los requerimientos de pruebas funcionales. ................................. 63 3.1.2 Construir una matriz de función/prueba ................................................... 66
3.2 Diseñar pruebas de GUI. (Interfaz gráfica de usuario) ..................................... 67 3.2.1 Definir componentes GUI de la aplicación............................................... 68 3.2.2 Diseñar pruebas de GUI............................................................................ 70
3.3 Definir las pruebas de sistema y de aceptación. ............................................... 71 3.3.1 Identificar las pruebas potenciales del sistema ......................................... 71 3.3.2 Diseñar pruebas de fragmentos del sistema. ............................................. 73 3.3.3 Identificar pruebas potenciales de Aceptación ......................................... 73
3.4 Revisar y aprobar el diseño............................................................................... 74 3.4.1 Programar y preparar la revisión............................................................... 74 3.4.2 Aprobación................................................................................................ 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 revisión............................................................... 77 4.2.2 Aprobación................................................................................................ 77
FASES 2 y 3: HACER Y VERIFICAR ......................................................................... 78 5. EVALUACIÓN Y EJECUCIÓN DE LAS PRUEBAS. ........................................ 79
5.1 Ejecución y Documentación de las pruebas. (HACER) .................................. 79 5.1.1 Ejecución de las pruebas de regresión. ..................................................... 79 5.1.2 Ejecutar una nueva sesión de pruebas....................................................... 80 5.1.3 Documentar los defectos arrojados por las pruebas.................................. 80
5.2 Evaluación de las pruebas. (VERIFICAR) ...................................................... 81 5.2.1 Analizar las métricas................................................................................. 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 función / prueba....................................................... 85 6.1.2 Actualizar las pruebas de fragmentos del sistema. ................................... 85 6.1.3 Actualizar las pruebas de aceptación. ....................................................... 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 estrés ....................................................................................... 97 7.2.5 Pruebas de compatibilidad ........................................................................ 97 7.2.6 Pruebas de Documentación....................................................................... 98 7.2.7 Pruebas de Backup y Recuperación.......................................................... 99 7.2.8 Pruebas de instalación............................................................................... 99
7.3 Revisar y aprobar las pruebas del sistema. ....................................................... 99 7.3.1 Programar y preparar la revisión............................................................... 99 7.3.2 Aprobación.............................................................................................. 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 ACEPTACIÓN................................................... 102 8.1 Completar la planeación de las pruebas de aceptación................................... 102
8.1.1 Identificar los tipos de pruebas de aceptación. ....................................... 102 8.1.2 Finalizar el cronograma de las pruebas de aceptación............................ 102 8.1.3 Organizar el equipo de pruebas de aceptación........................................ 104 8.1.4 Establecer el ambiente de pruebas de aceptación. .................................. 104 8.1.5 Instalar las herramientas para las pruebas de aceptación........................ 105
8.2 Completar los casos de pruebas de aceptación. .............................................. 106 8.2.1 Identificar el subconjunto de pruebas del sistema que se utilizarán para pruebas de aceptación. ............................................................................................ 106 8.2.2 Diseñar y escribir pruebas de aceptación adicionales............................. 107
8.3 Revisar el plan de pruebas de aceptación. ...................................................... 107 8.3.1 Programar y llevar a cabo la revisión. .................................................... 107 8.3.2 Aprobar el plan de pruebas de aceptación. ............................................. 108
8.4 Ejecutar las pruebas de aceptación. ................................................................ 108 8.4.1 Ejecutar las pruebas de aceptación de los errores encontrados en las pruebas anteriores. .................................................................................................. 108 8.4.2 Ejecutar las actuales pruebas de aceptación............................................ 109 8.4.3 Documentar los defectos de aceptación.................................................. 110
9. RESUMEN DE PRUEBAS Y REPORTE FINAL ............................................. 111 9.1 Resumen y consolidación de la información 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 gráficos de métricas.............................................................. 112 9.4 Conclusiones y Recomendaciones.................................................................. 120
9.4.1 Programar y preparar la revisión............................................................. 120
4
9.4.2 Aprobación.............................................................................................. 120 CONCLUSIONES......................................................................................................... 122 BIBLIOGRAFÍA ........................................................................................................... 125
5
INTRODUCCIÓN Actualmente en la mayoría 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 prácticas de programación o un proceso a veces desorganizado que se
lleva en la construcción del software, entre otros, es un problema que crece cada
vez más, 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 pequeños 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
había 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 sólo para el cliente sino también 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 metodología
clara para la realización de pruebas del software. Esto hace que los productos
no sean correctos ni confiables.
6
Por tanto, es indispensable implementar una metodología clara y que se pueda
integrar con la diferentes metodologías 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 realización
de pruebas antes del desarrollo de la metodología.
En los primeros capítulos, se hablará del concepto de calidad de software y la
importancia que tiene ésta en los proyectos y productos desarrollados. Se habla
también acerca de qué son las pruebas de software, los principios y los objetivos
de las pruebas y las técnicas de diseño 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 cómo las características mencionadas se relacionan con la metodología
propuesta.
Por último, se explican cada uno de los pasos de la metodología desarrollada,
basada en el ciclo PHVA, Planear, Hacer, Verificar y Actuar.
La fase “Planear”, comienza con la definición 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 diseñar y ejecutar los casos de pruebas
incluidos en el plan de pruebas.
7
La fase “Verificar”, comprende la importancia de la evaluación, las métricas y los
reportes. En este punto se analizan los resultados que han arrojado los casos
de prueba ejecutados.
La fase “Actuar”, provee la guía para la actualización o realización de los casos
de prueba. También sobre mejoras en los procesos o preparación para un
nuevo ciclo de pruebas.
8
1. QUÉ ES CALIDAD
La calidad es un aspecto especialmente importante en el desarrollo de software.
El interés por la calidad es cada vez mayor, ya que los clientes se vuelven más
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
explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente”.2
El estándar de la IEEE para la calidad de software define el término calidad del
software como:3
“La totalidad de rasgos y características de un producto de software que se
refieren a su habilidad para satisfacer necesidades específicas.
El grado en el cual el software posee una combinación deseada de atributos.
1 IEEE, Std. 610-1990. 2 Pressman, Roger S. Ingeniería del software Un enfoque práctico. Quinta Edición. 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 características 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 evaluación de la calidad de un producto siempre va a implicar una
comparación entre unos requisitos preestablecidos y el producto realmente
desarrollado.
También 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 función 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 evolución (especificaciones,
requerimientos, análisis, diseño, código, ...). 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
metodología 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 solución o la solución es muy costosa.
4 DoD 2168
10
El aseguramiento de la calidad rebaja los costos del desarrollo debido a que los
defectos se encuentran más rápido y pueden ser corregidos. Aunque al principio
requiere mayor inversión, 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 prevención, es decir, de las
acciones que se realizan para prevenir defectos en las etapas del desarrollo; el
segundo, es el costo de inspección, son aquellas acciones en que se mide, se
evalúa y se auditan los productos para que cumplan con los estándares 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 después de liberado el producto. Éstos pueden ser los
más graves, ya que deterioran la imagen de la compañía.
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 práctica habitual de todo
proceso productivo, que básicamente consiste en comprobar que un producto
tiene las características deseadas. Prácticamente 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 varía 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
interconexión entre los miembros de una sociedad, pues se encuentra
estrechamente unido a todos los aparatos de nuestra vida cotidiana, por esta
razón, es necesario desarrollar software con calidad que se adapte a los
requerimientos de los usuarios para ser más competitivos en el medio en que se
desenvuelven.
A medida que los equipos de desarrollo de software crecen y los proyectos se
vuelven más complejos, las pruebas de calidad en aplicaciones evolucionan
mucho más allá de simplemente depurar la aplicación para posteriormente
migrarla a producción.
Los sistemas actuales han crecido en tamaño, 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 metodología. En resumen, cada vez se hace más
difícil crear y dar mantenimiento a un sistema, y aún es más difícil crear un
sistema con la calidad que requiere el ambiente altamente competitivo de las
organizaciones.
Para cualquier metodología, la fase de Pruebas de Software es la actividad más
visible en el proceso de Aseguramiento de la Calidad en Software, la cual quizá
sea la parte más crítica en un proyecto de desarrollo. No se trata de
inspeccionar rápidamente los menús de una aplicación, no se trata de detectar
algún defecto, se trata de asegurarse que el producto satisface las necesidades
del cliente anticipándose a la aparición de algún 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 algún
defecto, pero nunca su ausencia, una prueba con éxito será la que encuentre
algún 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 aplicación, pocas tienen definida una
metodología propia para esta fase, pues requiere de una considerable cantidad
de tiempo, esfuerzo y recursos.
En el mundo de la computación tan cambiante de hoy, y sobre todo de gran
evolución tecnológica, y en vista de las exigencias que ha traído la globalización,
se ha hecho necesario desarrollar metodologías 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 sólo algunas décadas; mientras los constructores
tienen procedimientos bien establecidos, la industria del software está aún
definiendo sus caminos, buscando la manera adecuada de desarrollarse.
Considerar las propuestas basadas en la experiencia de los demás 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 sólo una actividad que
realizaba el programador para encontrar fallas en sus productos; con el paso de
los años 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 propósito principal es evaluar la funcionalidad del software
respecto de los requerimientos establecidos al inicio.
El proceso de realización de pruebas se percibe con frecuencia como un
proceso problemático e incontrolable. Realizar pruebas conlleva mucho más
14
tiempo, cuesta mucho más de lo planeado y ofrece insuficiente información
sobre la calidad del proceso de pruebas y, por lo tanto, de la calidad del sistema
de información 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 práctica, resulta difícil
definir qué pasos se deben realizar para mejorar y controlar dicho proceso, y en
qué orden deben ser realizados.
La prueba es un elemento crítico para la calidad del software. La importancia de
los costos asociados con los errores promueve la definición y aplicación de un
proceso de pruebas minuciosas y bien planificadas. Las pruebas permiten
validar y verificar el software, entendiendo como validación del software el
proceso que determina si el software satisface los requisitos, y verificación como
el proceso que determina si los productos de una fase satisfacen las condiciones
de dicha fase.
En este proyecto se pretende aclarar cómo debe ser el proceso de realización
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 ejecución de un programa con la intención 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. Además, los datos que se van recogiendo a medida que se lleva a
cabo la prueba proporcionan una buena indicación de la fiabilidad del software.
PRINCIPIOS DE LAS PRUEBAS
Antes de comenzar el proceso de pruebas, se deben entender los principios
básicos que guían las pruebas del software, a continuación se presenta un
conjunto útil de principios de prueba:
• A todas las pruebas se les debería 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
más graves (desde el punto de vista del cliente) son aquellos que impiden
al programa cumplir sus requisitos.
• Las pruebas deberían planificarse mucho antes de que empiecen. La
planificación de las pruebas puede empezar cuando este completo el
modelo de requisitos. La definición detallada de los casos de prueba
puede empezar cuando el modelo de diseño se haya terminado. Por
tanto, se pueden planificar y diseñar las pruebas antes de generar ningún
código.
• 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 módulos del programa. El problema es aislar los módulos
defectuosos y probarlos concienzudamente.
• Las pruebas deberían empezar por lo pequeño y progresar hacia lo
grande. Las primeras planeadas y ejecutadas se centran generalmente
en módulos individuales del programa. A medida que avanzan las
pruebas, el objetivo se centra en encontrar errores en grupos integrados
de módulos y finalmente en el sistema entero.
• No son posibles las pruebas exhaustivas. El número de permutaciones
de caminos para incluso un programa de tamaño moderado es
excepcionalmente grande. Por este motivo, es imposible ejecutar todas
las combinaciones de caminos durante las pruebas. Sin embargo, es
posible cubrir adecuadamente la lógica del programa y asegurarse de que
se han aplicado todas las condiciones en el diseño a nivel de
componente.
• Para ser más eficaces, las pruebas deberían ser realizadas por un equipo
independiente. Al decir “eficaces” se refiere a realizar pruebas con la más
alta probabilidad de encontrar errores, las cuales no son buenas si son
ejecutadas por los creadores del programa.
17
5. TÉCNICAS DE DISEÑO DE CASOS DE PRUEBAS
El diseño de casos de prueba está totalmente influenciado por la imposibilidad
de probar exhaustivamente el software, por lo que las técnicas de diseño de
casos de prueba tienen como objetivo conseguir una confianza aceptable en que
se detectarán los defectos o errores existentes (ya que la seguridad total sólo
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 diseño de casos de prueba consiste en
elegir algunas de ellas que, por sus características, 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 elección, conociendo la función específica para la que fue diseñado 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 también pruebas estructurales, en este tipo, las condiciones de las
pruebas son diseñadas examinando el código. El encargado de diseñar las
pruebas se guía por la estructura del programa o sistema, examinando la lógica
y sin tener en cuenta los requerimientos específicos. Luego de analizar el
código, se usa toda esta información 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 lógicos y probar las estructuras de datos más importantes.
En resumen, las pruebas de caja blanca usan la estructura de control del diseño
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 módulo.
• Que se ejerciten todas las decisiones lógicas en sus vertientes verdadera
y falsa.
• Que se ejecuten todos los bucles en sus límites operacionales.
19
• Que se ejerciten las estructuras internas de datos para asegurar su
validez.
El enfoque del diseño de casos debe basarse en la elección 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 lógica.
Una posible clasificación de criterios de cobertura lógica es la siguiente:
Cobertura de sentencias: Se trata de generar los casos de prueba necesarios para que cada sentencia o
instrucción del programa se ejecute al menos una vez.
Cobertura de decisiones: Consiste en escribir casos suficientes para que cada decisión tenga, por lo
menos una vez, un resultado verdadero y, al menos una vez, uno falso. En
general, una ejecución de pruebas que cumple la cobertura de decisiones
cumple también la cobertura de sentencias.
Cobertura de condiciones: Se trata de diseñar tantos casos como sea necesario para que cada condición
de cada decisión 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 decisión/condición: Consiste en exigir el criterio de cobertura de condiciones obligando a que se
cumpla también el criterio de decisiones.
20
Criterio de condición múltiple: En el caso de que se considere que la evaluación de las condiciones de cada
decisión no se realiza de forma simultánea, se podría considerar que cada
decisión multicondicional se descompone en varias decisiones unicondicionales.
En este caso se debe conseguir que todas las combinaciones posibles de
resultado (verdadero/ falso) de cada condición en cada decisión se ejecuten al
menos una vez.
La cobertura de caminos (secuencia de sentencias) es el criterio más 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 número de
caminos en un programa pequeño puede ser impracticable para las pruebas, por
lo que para reducir el número de caminos a probar, se habla del concepto de
camino de prueba, que es un camino del programa que atraviesa, como máximo,
una vez el interior de cada bucle que encuentra.
La idea en que se basa consiste en que ejecutar un bucle más 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 ejecutándolo una vez y otra más ejecutándolo dos veces.
Esto último es interesante para comprobar cómo se comporta a partir de los
valores de datos procedentes, no del exterior del bucle (como en la primera
iteración), sino de las operaciones de su interior.
Si se trabaja con los caminos de pruebas, existe la posibilidad de cuantificar el
número total de caminos utilizando algoritmos basados en matrices que
representan el grafo de flujo del programa. Así, existen diversos métodos
basados en ecuaciones, expresiones regulares y matrices que permiten tanto
calcular el número de caminos como enumerar dichos caminos expresados
como series de arcos del grafo de flujo. Saber cuál es el número de caminos del
grafo de un programa ayuda a planificar las pruebas y a asignar recursos a las
21
mismas, ya que indica el número de ejecuciones necesarias. También sirve de
comprobación a la hora de enumerar los caminos.
Se destacan las siguientes variantes de pruebas de caja blanca:
Prueba del camino básico: Es una técnica para obtener casos de prueba. Permite obtener una medida de
la complejidad lógica del diseño procedimental y usarla para definir un conjunto
básico de caminos de ejecución que garanticen que cada sentencia del
programa se recorre al menos una vez (cobertura de sentencias). Esta medida
puede ser usada como guía a la hora de definir un conjunto básico de caminos
de ejecución (diseño de casos de prueba).
Prueba de condición: Técnica 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
condición es sencilla. La segunda, que la cobertura de la prueba de las
condiciones de un programa da una orientación para generar pruebas
adicionales del programa. El propósito de la prueba de condiciones es detectar,
no sólo los errores en las condiciones de un programa, sino también otros
errores en dicho programa.
Prueba de flujo de datos: Técnica de prueba de caja blanca que selecciona caminos de prueba de un
programa de acuerdo con la ubicación de las definiciones y los usos de las
variables del programa. Dado que las sentencias de un programa están
relacionadas entre sí de acuerdo con las definiciones de las variables, el
enfoque de prueba de flujo de datos es efectivo para la protección contra
errores.
22
Prueba de bucles: Técnica 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
También denominadas pruebas de comportamiento. Considera el sistema como
una caja negra, cuyo comportamiento es determinado únicamente a partir de sus
entradas y salidas. Están diseñadas basadas en la funcionalidad del producto,
para qué fue creado y qué hace.
El encargado de realizar las pruebas de caja negra debe tener información de
los datos de entrada y observar qué pasa con la respuesta o salidas del sistema,
sin tener en cuenta cómo 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 lógica 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 inicialización y terminación.
Las ventajas que presentan este tipo de métodos de prueba son dos:
• Reducen el número de casos de prueba que se deben diseñar.
• Detectan clases de errores en vez de errores simples.
Método de la partición 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 están relacionados.
Cada una de estas clases es una partición 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 válidas y no válidas.
Se debe intentar dividir el dominio de entrada en un número 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 demás posibles casos de
prueba en la misma clase detectarán el mismo error.
24
Si un caso de prueba no detecta error, podemos pensar que ningún otro caso de
prueba en esa clase encontrará el error.
Identificación de las clases de equivalencia.
Se identifican dividiendo en dos o más grupos cada condición de entrada,
pueden ser:
• Un valor numérico específico.
• Un rango de valores.
• Número de valores.
• Un conjunto de valores relacionados:
• Una condición booleana.
Método 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 después diseñando una serie de pruebas que
cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones
para descubrir los errores.
Análisis de valores límite
Mediante la experiencia se ha podido constatar que los errores tienden a darse
más en los límites del campo de entrada que en el centro. Por ello se ha
desarrollado el análisis de valores límite como técnica de prueba de caja negra,
la cual lleva a una elección de casos de prueba que ejerciten los valores límite, y
25
que complementa de esta manera la técnica de partición equivalente. Así en
lugar de seleccionar cualquier elemento de una clase de equivalencia, esta
técnica lleva a la elección de casos de prueba en los extremos de la clase, y
además de centrarse solamente en las condiciones de entrada, se obtienen
casos de prueba también para el campo de salida.
Prueba de comparación Hay situaciones en las que la fiabilidad del software es algo absolutamente
crítica. 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 aplicación, 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 idéntica. Luego, se
ejecutan todas las versiones en paralelo y se hace una comparación 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 críticas, se deben desarrollar versiones
de software independientes, incluso aunque sólo se vaya a distribuir una de las
versiones en el sistema final basado en computadora. Esas versiones
independientes son la base de esta técnica de prueba de caja negra. Si las
salidas producidas por las distintas versiones son idénticas, se asume que todas
las implementaciones son correctas. Si la salida es diferente, se investigan
todas las aplicaciones en una o más versiones.
Prueba de la tabla ortogonal Hay muchas aplicaciones en que el dominio de entrada es relativamente
limitado. Es decir, el número de parámetros de entrada es pequeño y los
26
valores de cada uno de los parámetros están claramente delimitados. Cuando
estos números son muy pequeños, es posible considerar cada permutación de
entrada y comprobar exhaustivamente el proceso del dominio de entrada. En
cualquier caso, cuando el número de valores de entrada crece y el número 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 pequeño pero demasiado grande para posibilitar
pruebas exhaustivas, siendo particularmente útil al encontrar errores asociados
con fallos localizados, como por ejemplo una categoría de error asociada con
defectos de la lógica dentro de un componente software. De manera que esta
técnica proporciona una buena cobertura de prueba con bastantes menos casos
de prueba que en la estrategia exhaustiva.
Conjetura de errores Técnica 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. Después se generan casos de prueba con base en
dicha lista, que se suelen corresponder con defectos que aparecen comúnmente
y no con aspectos funcionales.
Esta técnica también se ha denominado generación de casos (o valores)
especiales, ya que no se obtienen con base en otros métodos sino mediante la
intuición o la experiencia.
Utilización de casos de uso del sistema para la realización de pruebas de caja negra.
27
Una buena práctica para la realización de pruebas de caja negra, es diseñar los
casos de prueba basándose en los casos de uso de las funcionalidades que
serán probadas. La utilización de los casos de uso para el diseño de los casos
de prueba, le facilitará al tester la realización de las pruebas ya que éste puede
tener mas conocimiento acerca de las funcionalidades a probar, acercar de
cómo debe responder el sistema ante determinadas acciones, pues en un caso
de uso se encuentran indicados los posibles escenarios de éxito y/o fallo
permitiéndole 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 continuación 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
cómo 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.
Garantías 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 básico): 1. El cliente llega a un terminal PDV con artículos que comprar.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artículo.
4. El sistema registra la línea de venta y presenta la descripción del artículo,
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 envía la información 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 mercancía.
Extensiones (o flujos alternos): 3a. Identificador no válido:
1. El sistema señala el error y rechaza la entrada.
3b. Hay muchos artículos de la misma categoría y tener en cuenta una única
identidad del artículo no es importante:
1. El cajero puede introducir el identificador de la categoría del artículo y la
cantidad.
3-6a. El cliente le pide al cajero que elimine un artículo de la compra.
1. El cajero introduce el identificador del artículo 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 artículo 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 tecnología y variaciones de datos:
3a. El identificador del artículo se introduce mediante un escáner láser de código
de barras o a través del teclado.
En el caso de uso anterior se observan diferentes secciones que indican cómo
es el proceso y qué se debe tener en cuenta para su correcto funcionamiento,
además presenta la sección de flujos alternos, que le da al tester una idea
acerca de otras condiciones adicionales que deben ser probadas. A continuación
29
se presenta el ejemplo de un formato para la realización 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.
Garantías de éxito(Postcondiciones)
Se registra la venta. El impuesto se calcula de maneracorrecta. Se actualizan la contabilidad y el inventario. Seregistran las comisiones. Se genera el recibo. Seregistran las autorizaciones de pago aprobadas.
Curso Normal de Eventos Acción del usuario Respuesta del sistema Falló / Pasó
1. El cliente llega a un terminal PDV con artículos que comprar.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artículo.
4. El sistema registra la línea de venta y presenta la descripción del artículo, 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 envía la información 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 válido: El sistema señala el error y rechaza la entrada.
3b. Hay muchos artículos de la misma categoría y tener en cuenta
una única identidad del artículo no es importante:
El cajero puede introducir el identificador de la categoría del artículo y la cantidad.
30
3-6a. El cliente le pide al cajero que elimine un artículo de la
compra:
El cajero introduce el identificador del artículo 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 artículo 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 tecnología y variaciones de datos: 3a. El identificador del artículo se introduce mediante un escáner láser de código de barras o a través 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 técnicas de diseño
de casos de prueba en una serie de pasos bien planificados que dan como
resultado una correcta construcción del software. Cualquier estrategia de
prueba debe incorporar la planificación de la prueba, el diseño de casos de
prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos
resultantes.
6.1 Pruebas de unidad
La prueba de unidad centra el proceso de verificación en la menor unidad del
diseño del software: módulos. Se trata de las pruebas formales que permiten
declarar que un módulo está listo y terminado (no las informales que se realizan
mientras se desarrollan los módulos)
Hablamos de una unidad de prueba para referirnos a uno o más módulos que
cumplen las siguientes condiciones [IEEE, 1986a]:
• Todos son del mismo programa.
• Al menos uno de ellos no ha sido probado.
• El conjunto de módulos es el objeto de un proceso de prueba.
La prueba de unidad puede abarcar desde un módulo hasta un grupo de
módulos.
Algunas pruebas que pueden hacerse como pruebas de unidad son:
• Pruebas de interfaz.
• Pruebas de estructuras de datos.
• Pruebas de condiciones límite.
32
• Pruebas de caminos independientes,
• Pruebas de caminos de manejo de errores.
6.2 Pruebas de integración Implican una progresión ordenada de pruebas que van desde los componentes o
módulos y que culminan en el sistema completo.
El orden de integración elegido afecta a diversos factores, como lo siguientes:
• La forma de preparar casos.
• Las herramientas necesarias.
• El orden de codificar y probar los módulos.
• El coste de la depuración.
• El coste de preparación de casos.
Tipos fundamentales de integración Integración incremental: Se combina el siguiente módulo que se debe probar
con el conjunto de módulos que ya han sido probados
• Ascendente: Se comienza por los módulos hoja.
• Descendente: Se comienza por el módulo raíz.
Integración no incremental: Se prueba cada módulo 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 ingeniería de software
e ingeniería de sistemas en un único marco de referencia.
CMMI incorpora material de las últimas versiones de estándares y modelos
como los relacionados con ingeniería de software: ISO/IEC TR 15504, ISO/IEC
12207, CMMI-SW, entre otros.
CMMI es un modelo descriptivo que detalla los atributos esenciales que
deberían caracterizar a una organización en un determinado nivel de
maduración.
Es un modelo normativo donde las prácticas detalladas caracterizan los tipos
normales de comportamiento esperables en una organización que ejecuta
proyectos a gran escala.
La mejora continua de los procesos se basa en muchos pasos pequeños y
evolutivos en vez de innovaciones revolucionarias.
CMMI proporciona un marco para organizar estos pasos evolutivos dentro de
cinco niveles de maduración que sientan fundamentos sucesivos para la mejora
continua del proceso, cada uno de ellos queda caracterizado por la presencia (o
ausencia) de determinadas prácticas.
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
organización.
Los niveles se observan a continuación:
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 básicos
para administrar sus proyectos; se monitorean costos, planes y
funcionalidad.
• Definido: Hay un proceso estándar que integra prácticas de gestión e
ingeniería.
• Cuantitativamente Administrado: El proceso facilita la obtención de
mediciones detalladas del desempeño del proceso y de la calidad de los
productos desarrollados.
• Optimizado: El proceso está bajo control estadístico y en un ciclo de
mejora continua.
35
CMMI cuenta con 23 PA’s (process areas) clasificadas en los siguientes grupos:
• Procesos administrativos: Los procesos administrativos se utilizan para
establecer la visión, metas, estrategia y la dirección de la empresa. Los
procesos administrativos iniciados, planean y realizan las actividades que
conllevarán al logro de los objetivos de la empresa, de la organización, o
del proyecto. Supervisan la ejecución 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 PA’s cuando
estas los necesitan y contribuyen al éxito y la calidad de los demás
procesos.
Dentro de los procesos del ciclo de vida se encuentra la PA 08: Pruebas del
sistema y evaluación; 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, métodos y el ambiente para la evaluación
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 análisis de las evaluaciones mediante los resultados de
éstas para soportar la aceptación o las acciones correctivas del sistema.
36
A continuación se presentan las prácticas llevadas a cabo en esta PA y cómo
están relacionadas con la metodología propuesta:
• BP 08.01 Estrategia de Evaluación.
Práctica relacionada con el paso de “Planeación de las pruebas”.
• BP 08.02 Procedimientos de Evaluación.
Práctica relacionada con el paso “Evaluación y ejecución de las pruebas”.
• BP 08.03 Establecer y mantener el ambiente de evaluación.
Práctica relacionada con los pasos: “Planeación de las pruebas” y
“Preparar las siguientes pruebas”.
• BP 08.04 Evaluar el crecimiento del producto.
Esta práctica está relacionada con toda la base de la metodología, la cual
es cíclica y está basada en el mejoramiento continuo del producto.
• BP 08.05 Verificar productos finales.
Esta práctica está relacionada con el paso ”Dirigir las pruebas del
sistema”.
• BP 08.06 Validar productos finales.
Esta práctica está relacionada con el paso “Dirigir las pruebas de
aceptación”
• BP 08.07 Analizar resultados de la evaluación.
Esta práctica está relacionada con los pasos “Preparar las siguientes
pruebas” y “Resumen de pruebas y reporte final”.
37
8. METODOLOGÍA 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 metodología de pruebas que se
presenta a continuación se puede ver como un proceso de mejoramiento
continuo que debe ser integrado con la metodología de desarrollo. La
integración 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 metodología de pruebas
de software. Dichas etapas se encuentran inmersas dentro del ciclo PHVA
(Planear, Hacer, Verificar y Actuar).
Figura 4. Pasos Metodología de Pruebas
38
FASE 1: PLANEAR
Figura 5. Fase: Planear (PHVA)
La etapa uno (Recolección de la información) y la etapa dos (Planeación de las
pruebas) se encuentran en la fase “Planear”.
A continuación se detallan las actividades que se llevan a cabo en cada una de
estas etapas:
39
1. RECOLECCIÓN DE INFORMACIÓN El propósito de la fase de recolección de información es obtener información
relevante del proyecto de desarrollo de software, para entender qué se quiere
realizar, cuáles son los objetivos y qué alcance tiene el proyecto. Toda esta
información será utilizada para empezar la elaboración o construcción del plan
de pruebas.
1.1 Preparación de la entrevista
Para la realización de la entrevista a los participantes (que serán identificados en
el siguiente punto), es importante definir los objetivos y el alcance que va a tener
ésta. Antes de su realización 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 estén
involucradas personas de las diferentes áreas, como el área de calidad,
desarrollo y líderes de proyectos.
En el área de calidad se deben elegir máximo dos personas, una que tenga el
papel de dirigir la entrevista y otro que lleve registro o nota de la información que
se vaya generando. Esto con el fin de que el entrevistador tenga un mayor
enfoque en la obtención de información. Es recomendable que el encargado de
dirigir la entrevista, sea la persona líder 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. Además esta persona servirá de soporte al
entrevistador.
También el encargado de tomar nota debe ser uno de los ingenieros de pruebas
o líder de pruebas que se asignen al proyecto.
Por parte del área de desarrollo, deben estar en la entrevista, el líder 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 demás participantes.
La agenda debe contener los puntos necesarios para que la entrevista cumpla
con el objetivo de recopilar la información suficiente para el aseguramiento de la
calidad del proyecto y la elaboración de un plan de pruebas. La agenda debe
contener una introducción, 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.
También el entrevistador debe presentarse ante los participantes, comunicar sus
funciones como líder, 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 información general y básica del proyecto como:
• ¿Cuál es el proyecto del que se va a hablar?
• ¿Cuáles son los objetivos generales del proyecto?
• ¿Es un proyecto nuevo, en desarrollo o de mantenimiento?
• ¿Cuándo empieza el proyecto? (nuevos proyectos)
• ¿Qué tiempo se tiene estimado para el proyecto?
• ¿Quiénes son los participantes en el proyecto?
• ¿Qué recursos están asignados a cada participante?
• ¿Cuáles son las responsabilidades de cada participante?
• ¿Quiénes son los usuarios del proyecto?
• ¿Cuáles son los principales problemas o riesgos del proyecto?
• ¿Cuál 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 propósito de esta tarea es entender el alcance, las
necesidades y los requerimientos del proyecto.
Algunas preguntas que se pueden realizar para tal propósito son:
• ¿Qué tipo de proyecto se está realizando, o se va a realizar?
• ¿Por qué se va a realizar?
• ¿Qué análisis o qué modelos se han hecho del sistema?
• ¿Qué tipo de usuarios lo van a utilizar?
• ¿Cuáles 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 planeación del proyecto
El propósito 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. También es necesario conocer las actividades y
tareas que se realizarán y los recursos que se emplearán para el proyecto.
Para obtener esta información se pueden realizar preguntas como:
• ¿En qué estado se encuentra el proyecto?
• ¿Hay algún plan de trabajo para el proyecto?
• ¿Qué actividades o tareas hay programadas?
43
• ¿Cuáles son las actividades principales planeadas?
• ¿Horas estimadas?
• ¿El tiempo estimado para el desarrollo es apropiado?
• ¿Qué tan detallado es el plan de trabajo?
• ¿Están asignados los recursos para cada actividad del plan de trabajo?
• ¿El plan de trabajo es actualizado periódicamente?
• ¿Cuáles son los mayores riesgos estimados?
1.2.4 Conocer la metodología de desarrollo
En todo proyecto de desarrollo de software, la planeación y ejecución de las
pruebas debe estar integrada con el ciclo de vida y con la metodología que se
utilice para el desarrollo del proyecto.
Considerar las pruebas como una función 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 metodología de desarrollo, se asignarán los recursos
apropiadamente y se evitará que algunas actividades continúen sin haber
realizado las pruebas necesarias.
Además, las actividades de pruebas necesariamente tendrán que afectar la
metodología de desarrollo, agregando o modificando algunas tareas. Debe
conocerse también, cuándo se pueden comenzar las pruebas y cuáles serán las
actividades planeadas para corregir los errores detectados.
Algunas preguntas que se pueden realizar son:
• ¿Qué metodología de desarrollo es usada usualmente por la
organización?
• ¿Cuál metodología va a ser utilizada para el proyecto?
44
• ¿Cuáles son los pasos o actividades principales de la metodología?
• ¿Qué tanto se sigue esta metodología?
• ¿Qué estándares se siguen?
• ¿Qué documentación se lleva?
1.2.5 Conocer las reglas de negocio
Cada organización, dependiendo de la metodología que utilice en el desarrollo
de los productos de software, tiene diferentes formas de hacer la toma de
requerimientos de un proyecto. La especificación de los requerimientos define
las funciones del producto en un ambiente específico.
El entrevistador o líder 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 aplicación, planear el diseño de
las pruebas y estimar los requisitos que requieren la implementación de estas.
Las preguntas que se deben realizar para obtener información sobre los
requerimientos y reglas del negocio son:
• ¿Qué tipo de aplicación es? ( Financiera, control de inventarios, ventas,
etc.)
• ¿Cuáles son las principales funciones que debe realizar el sistema? (Se
deben pedir detalles de cada función.)
• ¿Para qué sistema operativo se va a desarrollar?
• ¿Qué interfaces serán utilizadas?
• ¿Qué plataforma será utilizada?
• ¿Requerimientos mínimos del sistema? ( Espacio en disco, memoria
RAM, otros requerimientos.)
• ¿Cuál es el rendimiento esperado?
45
• ¿Qué reglas o políticas de seguridad se deben cumplir?
• ¿Qué políticas o qué restricciones se deben cumplir?
• ¿Qué otros aspectos se deben probar?
1.2.6 Análisis de riesgos
El propósito de esta tarea es analizar qué tipo de riesgos tiene la aplicación y
qué tipo criticidad tiene cada módulo del proyecto. Esto puede ayudar a
identificar y realizar pruebas más exhaustivas en estas aplicaciones.
Para obtener esta información se pueden realizar estas preguntas:
• ¿Cuáles son los módulos principales del proyecto?
• ¿Cuál es el tamaño del proyecto?
• ¿Qué impacto tiene el proyecto en el cliente?
• ¿Qué tipo de cliente es?
• ¿Número de usuarios del sistema?
• ¿Qué predicción hay de costos para el usuario por fallos de la aplicación?
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
información 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 tenía prevista. Si todos no han sido
cumplidos, y se requiere una próxima reunión, ésta se debe programar en ese
46
momento, ya que todos lo miembros están 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 estén 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 organización que lo requieran.
47
2. PLANEACIÓN DE LAS PRUEBAS
La planeación de las pruebas es una de las etapas más importantes de un
proceso de pruebas y por lo tanto de la metodología, ya que puede proveer la
forma más 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 aprobación
y utilizarlo como retroalimentación. 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 también una
definición 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
mayoría de los defectos y cubrir la mayor parte del código.
CONSTRUIR EL PLAN DE PRUEBAS El propósito 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 mnemónica que permita relacionarlo con su
48
alcance. Además deberá llevar a fecha y la versión del plan, ya que puede ser
modificado durante la ejecución de las pruebas.
2.2 Preparar la introducción
La primera parte del plan de pruebas debe ser la introducción, en donde
describe por qué el plan va a ser desarrollado y cuáles son sus objetivos.
También se da una descripción 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 implementación de procesos de
mejoramiento, o la adición de nuevas funcionalidades.
Además, los riesgos de la aplicación, el alcance, los objetivos, el propósito y los
factores de éxito deben ser documentados en la introducción.
Cualquier otra documentación, como la especificación de requerimientos,
especificaciones funcionales, especificaciones de diseño, planes de trabajo,
modelos de datos deben ser listados y se debe describir su estado.
Adicionalmente en la introducción se deben mencionar los riesgos que pueden
tener las pruebas.
2.3 Identificar los requerimientos Esta sección 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.
También, comprende las pruebas de la interfaz de usuario, la descomposición
jerárquica de las funciones ( estructura de los menús, el flujo que siguen, etc.), el
diseño de las ventanas y el estándar que sigue su diseño.
2.4 Identificar los tipos de prueba
En este paso, se describe cómo 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 integración.
• Pruebas de volumen.
• Pruebas de estrés.
• Pruebas de rendimiento.
• Pruebas globales del sistema.
Para cada tipo de prueba se debe detallar lo siguiente:
• Objetivo: EL objetivo principal de la prueba.
• Técnica: Documentar cómo los casos de prueba van a ser desarrollados,
las herramientas que se van a utilizar, cómo 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 físico o
50
de software, o cualquier otro que deba tenerse en cuenta para el éxito de
las pruebas.
• Criterio de terminación: Documentar cuándo se dan por terminadas las
pruebas.
• Definir cuándo y cómo 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 diseñar 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 aplicación, 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 cuándo terminar las pruebas
Uno de los principales problemas que se encuentra al realizar pruebas es
identificar cuándo terminarlas ya que por ejemplo es imposible determinar
cuándo un programa o una aplicación está libre de defectos.
Existen algunos criterios para terminar las pruebas:
• Termina el tiempo estimado para realizar las pruebas
• Se encuentra un número especificado de errores.
• Todas las pruebas programadas han terminado.
• Combinación de las anteriores.
La mayoría de los proyectos deberían utilizar una combinación de los criterios
anteriores.
51
2.6 Establecer la estrategia de pruebas de regresión.
Probar la aplicación cada que se realice un cambio, cada que se haga la
corrección de un error, o cada que se haga una mejora en una nueva versión 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 aplicación no afectaron
los demás módulos o no tuvieron efectos no esperados en el comportamiento
del programa. Correcciones de errores que tengan relación con el flujo de
control o con la lógica y errores de interfaces son un ejemplo de cuándo 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 políticas para poder hacer una buena elección
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 aplicación.
• Se deben repetir pruebas que fueron diseñadas antes de hacerse el o los
cambios.
• Se deben hacer pruebas que sean diseñadas 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
• Métricas: Documento con los aspectos que se van a medir durante el
desarrollo de las pruebas.
• Casos de pruebas: Formato con información 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. ( Sección: 6.3 )
• Reporte Final: Reporte del resultado final de las pruebas. Este reporte se
elabora luego de terminar todo el proceso de pruebas. ( Sección: 9 )
• Reporte de errores: Formatos con la información de los errores
descubiertos durante el proceso de pruebas. ( Sección: 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 también representar el grupo de
usuarios, técnicos, 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 líder del grupo.
El líder debe encargarse también de dirigir el equipo de pruebas, ser el
intermediario entre los desarrolladores y los ingenieros de pruebas. Además
entre otras responsabilidades están:
• 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.
• Diseñar 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 están:
• 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 aparición de los errores en un principio.
2.9 Establecer el ambiente de pruebas
El propósito 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
implementación.
Es importante dentro del ambiente de pruebas contar con la tecnología
adecuada y las herramientas de pruebas adecuadas. Esta tecnología 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 físico 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 comunicación y puedan interactuar fácilmente para llegar a fines
comunes.
El hardware y el software necesarios, deberán ser configurados adecuadamente
para llevar a cabo las pruebas exitosamente.
55
2.10 Seleccionar las herramientas de pruebas
Para la selección de las herramientas, se debe tener en cuenta que las
escogidas deben ser las que más se adapten al ambiente de pruebas, y al tipo
de aplicación 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 deberán revisar y aprobar el uso de ellas ya que la selección y el uso
deben ir de acuerdo con el plan de pruebas.
La selección de estas herramientas puede ser por la experiencia que se tenga
en su utilización o en la experiencia del equipo de pruebas.
2.11 Programar las pruebas
En este punto se especifica cuándo cada módulo de la aplicación va a estar listo
para ser probado, el tiempo estimado para realizar dichas pruebas, fecha de
inicio y fecha estimada de finalización. También 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 metodología 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 información, como dónde fue encontrado y el
estado en que se encuentra:
56
• Abierto: Aún no se ha asignado para corrección.
• En revisión: 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 información acerca de los defectos debe estar al alcance de los
desarrolladores y es útil para tener las estadísticas de errores o el estado
general de una aplicación. Como por ejemplo cuántos errores se han
encontrado y cuántos se encuentran sin corregir en el sistema.
Básicamente la información que se debe suministrar es:
• Identificador del error.
• Nombre del error.
• Descripción del error.
• Fecha en que fue descubierto.
• Tipo de error. ( funcional, interfaz, lógico...)
• Severidad del error.
• Circunstancias en las que se encontró el error.
• Datos ingresados.
• Ambiente donde ocurrió.
• Diagnóstico del error (código).
• Efecto que tiene el error en el programa.
• Comentarios adicionales.
57
2.13 Definición de los objetivos de las métricas
Definir las métricas
Michael [‘99] define las métricas de software como “La aplicación continua de
mediciones basadas en técnicas para el proceso de desarrollo del software y sus
productos para suministrar información relevante a tiempo, así el administrador
junto con el empleo de estas técnicas mejorará el proceso y sus productos”.
Las métricas de software proveen la información necesaria para la toma de
decisiones técnicas.
Se puede decir que una métrica tiene las siguientes características:
• Medible.
• Independiente.
• Contable.
• Precisa
El objetivo de recolectar métricas es hacer el proceso de pruebas más 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 métricas que se pueden utilizar son:
• Análisis de defectos: Cada defecto debe ser analizado para identificar
su causa, cómo fue detectado, en dónde, y por quién.
• Efectividad de las pruebas: Que tan bien se están realizando las
pruebas.
• Corrección de errores: Cuantos errores se han corregido
completamente y cuantos no.
58
• Estimación de costo y esfuerzo.
• Estado de las pruebas.
El siguiente es un ejemplo del contenido de un plan de pruebas:
1. Introducción
1.1 Propósito
1.2 Resumen del proyecto
1.3 Documentación 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 aceptación
2.4.1 Pruebas de rendimiento
2.4.2 Pruebas de seguridad
2.4.3 Pruebas de volumen
2.4.4 Pruebas de estrés
2.4.5 Pruebas de compatibilidad
2.4.6 Pruebas de usabilidad
2.4.7 Pruebas de documentación
2.4.8 Pruebas de backup y recuperación
2.4.9 Pruebas de instalación
2.5 Pruebas de regresión
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 regresión
3.7 Seguimiento de errores
3.8 Solución de errores
3.9 Recursos
3.9.1 Personal de pruebas
3.9.2 Ambiente de pruebas
3.9.3 Herramientas
3.10 Programación de las pruebas
3.11 Administración de la configuración
3.12 Entregables
3.13 Métricas
3.14 Criterio de terminación de las pruebas
3.15 Reportes
3.16 Aprobación
2.14 Revisar y aprobar el diseño
2.14.1 Programar y preparar la revisión
La revisión 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 reunión que se lleve a cabo para la revisión, se debe primero hacer la
introducción 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 revisión debe contemplar el tiempo estimado para
terminar todos los puntos. En caso de no terminarse se debe programar una
siguiente reunión.
El propósito de esta revisión 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 Aprobación
El plan de pruebas debe ser revisado por todos los responsables de su
ejecución, y debe ser aprobado por el equipo de pruebas, líderes del proyecto y
líderes de desarrollo.
Es recomendable hacer una reunión donde se apruebe entre todos el plan de
pruebas.
61
FASE 2: HACER
Figura 7: Fase: Hacer (PHVA)
La etapa tres (Diseño de casos de prueba) y la etapa cuatro (Planeación de las
pruebas) se encuentran en la fase “Hacer”.
A continuación se detallan las actividades que se llevan a cabo en cada una de
estas etapas:
62
3. DISEÑO DE CASOS DE PRUEBA.
El principal objetivo del diseño de casos de prueba es obtener un conjunto de
pruebas que tengan la mayor probabilidad de descubrir los defectos del
software.
3.1 Diseñar las pruebas de función.
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
especificación funcional es una lista detallada de las funciones del negocio, la
cual además contiene la estructura y los estándares de las ventanas, los
mínimos requisitos del sistema para soportar la aplicación, los tipos de
actividades que se realizan y perfiles de usuario, definiendo así con este
conjunto de datos las funciones básicas del sistema y la forma en que el usuario
interactúa con éste.
Una función de negocio es un aspecto controlable del negocio y es un pequeño
componente del sistema, cada uno de estos debe ser nombrado y descrito
utilizando el verbo – objeto que indique la función que se quiere especificar del
sistema (Ej. cerrar caja). El criterio a usar para determinar la ejecución exitosa
de cada función debe ser indicado.
Una especificación funcional es usada para ilustrar los procesos (funciones del
negocio) en una estructura jerárquica con sucesivos niveles de detalle. Los
procesos elementales no son descompuestos en la especificación (Ver tabla 1).
La especificación funcional sirve como base para las pruebas funcionales, las
63
cuales tendrán mínimo un caso de prueba por cada nivel en la jerarquía.
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 aplicación en varias
interfaces; una buena manera de recolectar esta información (las diferentes
funciones) es mediante la descomposición detallada de los procesos y/o la
elaboración de un flujo de datos del negocio.
Requerimientos de Prueba Funcionales (Administración)
Procesamiento de Ordenes
Crear Orden
Llenar Orden
Editar Orden
Borrar Orden
Ver Detalle
Administración de Clientes
Crear Cliente
Editar Cliente
Borrar Cliente
Administración Financiera
Recibir Pago de Cliente
Depositar Pago
Pagar Nómina
Tabla 1. Especificación Funcional
64
La estructura funcional de una ventana describe cómo serán implementadas las
funciones en este ambiente, qué información 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 número
de orden.
c. La información presentada es de solo lectura.
d. Por cada orden en el listado, se presentan los siguientes datos:
1. Número de Orden.
2. Nombre del Cliente.
3. Identificación del Cliente.
4. Fecha de creación de la Orden.
5. Número de factura.
6. Valor total
7. Icono que permite ver detalle de la Orden haciendo un click.
e. Al hacer doble click sobre un número de orden, se desplegará la ventana
de edición de orden, en la cual es posible modificar la información.
f. No se genera scroll horizontal.
g. En la parte inferior del listado, a la izquierda aparece botón “Regresar”
para ubicarse nuevamente en el menú principal, y a la derecha botón
“Nuevo” para crear nueva orden.
65
3.1.2 Construir una matriz de función/prueba
En este punto, se debe construir una matriz que relacione cada funcionalidad de
la aplicación con el caso de prueba correspondiente, ilustrando de esta forma,
cuál 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 ejecución de las pruebas y adicionalmente puede ser utilizada
durante el mantenimiento de la aplicación, por ejemplo, si una función es
cambiada, el equipo de mantenimiento puede utilizar la matriz para determinar
cuál 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 número.
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
Administración de Clientes
Crear Cliente ACC01 ACC02
Editar Cliente EC01 EC02
Borrar Cliente BC01
Administración Financiera
Recibir Pago de Cliente RPC01 RPC02 RPC03
Depositar Pago ADP01 ADP02
Pagar Nómina PN01
Tabla 2. Matriz de función/prueba
Es importante diferenciar cuáles casos de prueba se ejecutan manualmente y
cuáles automáticamente; para esto se puede definir un estándar en la
asignación del código del caso de prueba, como en el ejemplo, los casos de
prueba que son automáticos comienzan por la letra “A” y van seguidos por las
iniciales del nombre de la funcionalidad.
3.2 Diseñar pruebas de GUI. (Interfaz gráfica de usuario)
El objetivo de un buen diseño de GUI debe ser consecuente con la amigabilidad
(apariencia y facilidad de uso) de la aplicación para los usuarios. Un buen
67
diseño de GUI tiene dos componentes clave: interacción y apariencia. La
interacción esta asociada a la manera como el usuario interactúa con la
aplicación, y la apariencia a cómo luce la interfase para el usuario.
Las pruebas de GUI conciernen a la confirmación de una correcta navegación
por la aplicación, las siguientes son algunos aspectos del diseño de GUI que el
encargado de realizar las pruebas debe tener en cuenta mientras prueba la
aplicación:
Nueve directivas para un buen diseño 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 diseño 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 aplicación.
9. Hacerlo fácil.
3.2.1 Definir componentes GUI de la aplicación.
La interfaz gráfica de usuario (GUI) provee múltiples canales de comunicación
usando palabras, gráficos, animación, sonido y video. Cinco componentes base
de la interfaz de usuario son: ventanas, menús, formas, íconos y controles.
68
• Ventanas: En un ambiente de ventanas, todas las interacciones del
usuario con la aplicación ocurren a través de ventanas. Esto incluye una
ventana principal, junto con un número de ventanas secundarias
generadas de la principal.
• Menús: los menús se presentan en una variedad de estilos y formas, por
ejemplo: menús de acción (radio botones), listas desplegables, menús de
opciones, menús en cascada.
• Formas: Las formas son ventanas en las cuales el usuario puede
adicionar información.
• Iconos: Los íconos son valiosos por su fácil reconocimiento, aprendizaje
y facilidad de navegación a través de la aplicación.
• Controles: un componente de control aparece en una ventana que
permite al usuario interactuar con la aplicación y se identifica por medio
de su correspondiente acción. Los controles incluyen barras de menús,
listas desplegables, radio botones, cajas de chequeo, entre otros.
Un acercamiento para el diseño 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 Diseñar pruebas de GUI
En la tarea anterior, los componentes de aplicación 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.
• Vínculos de ayuda.
• Barra de botones.
• Iconos de acceso.
• Posibilidad de múltiples ventanas abiertas.
• Cambiar la medida de las ventanas.
• Aceptación de valores válidos en formularios.
• Manejo de valores inválidos en los formularios.
• Minimización y maximización de las ventanas.
• Color.
• Tabulación de secuencias.
• Cajas de chequeo.
• Fuentes.
• Arrastrar y soltar.
• Cancelar.
70
• Salir.
• Aceptar.
• Teclas rápidas.
• Desplegar y plegar árboles.
Adicionalmente a los chequeos de componentes de GUI, se tiene un estándar de
diseño de GUI, el cual es esencial para asegurar que se siguen unas reglas de
construcción con el fin de lograr los niveles de consistencia deseados. Los
siguientes son algunos de los estándares GUI:
• Usar colores llamativos.
• Alineamiento de ventanas y tablas.
• Funciones y teclas rápidas.
• Consistencia en la ubicación de los elementos en las ventanas.
• Consistencia en los colores y gráficos usados.
• Presentación de mensajes de error y características de las ayudas.
• Secuencia lógica de objetos.
• Consistencia en el tipo de letra.
3.3 Definir las pruebas de sistema y de aceptación.
3.3.1 Identificar las pruebas potenciales del sistema
Las pruebas de sistema se encuentran en el nivel más alto de la fase de pruebas
ya que estas evalúan la funcionalidad del sistema como un todo, su rendimiento
y su adaptabilidad. Estas pruebas normalmente son ejecutadas internamente y
son orientadas a las características técnicas, por el contrario, las pruebas de
aceptación son pruebas orientadas a los usuarios.
71
Las pruebas de sistema consisten en una o más pruebas que se basan en los
objetivos iniciales de la aplicación y que fueron definidos en la entrevista que fue
realizada en la fase de recolección de la información. El propósito 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 aplicación para garantizar la integridad y al
confidencialidad de la información.
• Pruebas de volumen: Probar la aplicación con volúmenes grandes de
datos para verificar que sea capaz de manejarlos.
• Pruebas de estrés: Probar la aplicación en condiciones que
sobrecarguen los recursos. Se debe observar principalmente el tiempo
de respuesta.
• Pruebas de compatibilidad: Probar la compatibilidad de la aplicación
con otras aplicaciones o con otros sistemas.
• Pruebas de usabilidad: Determinar que tan bien los usuarios van a
entender y a usar la aplicación.
• Pruebas de la documentación: Asegurarse que la documentación es
apropiada y guíe correctamente por la aplicación 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 recuperación: Verificar la viabilidad del sistema para
recuperarse luego de una falla de software o hardware.
• Pruebas de instalación: Probar la instalación y que esta sea exitosa.
3.3.2 Diseñar pruebas de fragmentos del sistema.
Una Prueba de fragmentos del sistema es la división de una prueba del sistema
que puede realizarse durante el desarrollo de la aplicación. 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, documentación y procedimientos. Por el
contrario, no pueden ser fragmentadas pruebas de instalación, recuperación,
etc.
3.3.3 Identificar pruebas potenciales de Aceptación
Las Pruebas de aceptación son pruebas que corren los usuarios para verificar
que la aplicación cumple con los requerimientos especificados. El objetivo de
estas pruebas es demostrar que el sistema funciona. En ellas se hace menos
énfasis en las características técnicas y se centra en si la aplicación es útil para
el usuario final.
73
3.4 Revisar y aprobar el diseño
3.4.1 Programar y preparar la revisión
La revisión del diseño 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 diseño de las pruebas.
En la reunión que se lleve a cabo para la revisión, se debe primero hacer la
introducción 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 revisión debe contemplar el tiempo estimado para
terminar todos los puntos. En caso de no terminarse, se debe programar una
siguiente reunión.
El propósito de esta revisión es lograr que se apruebe el diseño de las pruebas
tanto por el gerente del proyecto como por los desarrolladores. Cualquier
sugerencia o cambio debe ser realizado e incorporado al diseño de las pruebas.
3.4.2 Aprobación
El objetivo de la aprobación es lograr que los participantes del proyecto estén de
acuerdo con el diseño de las pruebas. Esta aprobación se debe realizar por
escrito y debe estar firmada por el gerente del proyecto, el líder de pruebas y el
líder de los desarrolladores. Se debe también elaborar y entregar un
documento donde encuentre la ultima copia del diseño 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 utilización en la ejecución 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 función/prueba que referencia los
casos de prueba con las funciones de la aplicación. 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 información:
• El nombre del caso de prueba
• Número del caso.
• La función 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 quién realiza la prueba
• Fecha de realización de la prueba.
75
El siguiente formato se puede tomar como muestra de recolección de
información 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 diseñaron las pruebas de fragmentos del sistema. Estas
son pruebas de partes más pequeñas de la aplicación 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 podrán ser más 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 revisión
La revisión 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 revisión debe contemplar el tiempo estimado para la
revisión de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunión.
El propósito de esta revisión 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 Aprobación
El objetivo de la aprobación es lograr que los participantes del proyecto estén de
acuerdo con el desarrollo de las pruebas. Esta aprobación se debe realizar por
escrito y debe estar firmada por el gerente del proyecto, el líder de pruebas y el
líder de los desarrolladores. Se debe también elaborar y entregar un
documento donde se encuentre la última copia del diseño 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 metodología de pruebas (Evaluación y ejecución de las
pruebas) hace parte de las fases 2 y 3 (Hacer y verificar) del ciclo PHVA.
A continuación se detallan las actividades que se llevan a cabo en esta etapa:
78
5. EVALUACIÓN Y EJECUCIÓN DE LAS PRUEBAS.
El objetivo de esta etapa es ejecutar los casos de pruebas y evaluar los
resultados obtenidos.
5.1 Ejecución y Documentación de las pruebas. (HACER)
5.1.1 Ejecución de las pruebas de regresión.
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 aplicación ocasionados por correcciones o modificaciones
al código.
A lo largo de la vida del software, debe ser mantenido y dispuesto para su
utilización un conjunto de casos de prueba. Estos casos de prueba deben ser lo
suficientemente completos de tal modo que las funcionalidades de la aplicación
puedan ser probadas a fondo. Mediante una matriz de reexaminación (retest) se
pueden ubicar fácilmente los casos de prueba que serán utilizados para probar
los defectos encontrados en pruebas pasadas.
Una matriz de reexaminación relaciona los casos de prueba con las funciones de
la aplicación. Una entrada de chequeo en la matriz indica que el caso de prueba
es ejecutado nuevamente cuando la función (unidad del programa) sea
modificada debido a mejoras o correcciones. La matriz de reexaminación puede
ser construida al inicio de las pruebas y debe ser mantenida durante las
siguientes pruebas, debido a que las funciones de la aplicación 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 realización 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 sesión de pruebas.
El objetivo de esta actividad es ejecutar las pruebas (casos de prueba) que
fueron creadas desde la última ejecución 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 automáticas), las pruebas de
fragmentos del sistema y las pruebas de aceptación, en preparación para las
siguientes pruebas. En este punto todas estas pruebas son ejecutadas.
5.1.3 Documentar los defectos arrojados por las pruebas.
Durante la ejecución de las pruebas, los resultados deben ser reportados en la
base de datos de defectos. Los defectos generalmente están 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 información relacionada con el
defecto. Es recomendable realizar el registro de los defectos digitalmente ya
que de esta forma es más fácil hacerles seguimiento y localizar los defectos
duplicados.
80
5.2 Evaluación de las pruebas. (VERIFICAR)
5.2.1 Analizar las métricas.
El uso de métricas 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 métricas para tener un buen control sobre el proceso de
pruebas.
En una actividad anterior se identificaron las métricas que van a ser utilizadas, y
durante las pruebas se ha recogido información que permite realizar un análisis
de los resultados obtenidos, esto incluye la cuantificación de las métricas y la
elaboración de gráficos con estos datos.
La siguiente es la información clave que un líder de pruebas necesita para saber
que las pruebas han sido finalizadas:
• Estado de la ejecución de los casos de prueba.
Cuántos casos de prueba fueron ejecutados, cuántos no fueron ejecutados y
cuántos descubrieron defectos. Estas preguntas proveen información acerca
de la productividad de las pruebas. Si los casos de prueba no han sido
ejecutados oportunamente, esto puede indicar la necesidad de asignar más
personal al proyecto.
• Análisis de la diferencia de defectos.
Cuál es la diferencia entre el número de defectos que han sido descubiertos
y los que han sido corregidos. Esto provee información acerca de la habilidad
de los desarrolladores para la corrección de defectos oportunamente. Si
81
existe una diferencia relativamente alta, esto puede indicar que quizá más
desarrolladores deban ser asignados al proyecto.
• Estado de la severidad de los defectos.
En este punto se debe evaluar cómo es la distribución de la severidad de los
defectos (Ej. : severidad crítica, mayor y menor). Cuántos defectos con
severidad crítica, mayor y menor se encuentran abiertos, cuántos se han
resuelto. Si por ejemplo se encuentra un alto porcentaje de defectos con
severidad crítica abiertos, probablemente exista un número considerable de
características de la arquitectura y del diseño con debilidades.
• Análisis de la curva ingreso de defectos.
Graficar el número de defectos descubiertos periódicamente con el fin de
conocer los defectos que ingresan en cada lapso de tiempo y tomar medidas
según la inclinación de la curva, si ésta se aproxima a cero indica que los
defectos están disminuyendo, de lo contrario se concluye que el
descubrimiento de defectos es aun muy robusto y que muchos más 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 finalización 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 líder 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 evaluación.
Si el progreso de las pruebas no está según lo planeado, el líder de pruebas
debe determinar los factores que ocasionaron el retrazo; generalmente una
causa de esto es la subestimación 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 corrección de éstos.
5.2.3 Identificar los cambios en requerimientos.
Con anterioridad los requerimientos funcionales fueron analizados mediante una
descomposición jerárquica funcional, la estructura funcional y los estándares de
las ventanas y los requerimientos mínimos del sistema.
Durante el proceso de desarrollo, nuevos requerimientos pueden ser
introducidos, tales como:
• Nuevas interfaces o componentes GUI
• Modificación de funciones.
• Nuevas funciones.
• Eliminación de funciones.
• Nuevos requerimientos de sistema, Ej. hardware.
Cada nuevo requerimiento debe ser identificado, registrado, analizado y
actualizado en el plan, el diseño y los scripts de pruebas.
83
FASE 4: ACTUAR
Figura 9: Fase: Actuar (PHVA)
La etapa seis de la metodología de pruebas (Preparar las siguientes pruebas)
hace parte de las fases 4 (Actuar) del ciclo PHVA.
A continuación 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 según los
nuevos requerimientos y los resultados de las pruebas anteriores.
6.1 Refinar las pruebas.
6.1.1 Actualizar la matriz función / prueba.
El propósito de esta tarea es actualizar el diseño de las pruebas y la matriz de
función / prueba con los nuevos requerimientos. En el caso de la matriz las
nuevas funciones se añaden verticalmente y los nuevos casos de prueba
horizontalmente.
Para las pruebas de GUI, se deben actualizar los formatos añadiendo 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 aceptación.
En un punto anterior se definieron las posibles pruebas de aceptación. Estas
pruebas son posibles pruebas orientadas al usuario que lo llevan a comprobar
que la aplicación cumple con los requerimientos especificados.
85
El objetivo de este paso es actualizar las pruebas de aceptación 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 líder del equipo
de pruebas debe mirar que casos de prueba se llevaron a cabo de acuerdo con
el plan de pruebas. Debe también evaluar el cumplimiento de las tareas que se
habían programado y sacar conclusiones de cómo ha sido el comportamiento
del equipo. Si es necesario, el líder 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 tecnología y el hardware. También es necesario
revisar la configuración 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 líder 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 ejecución de los casos de prueba puede ayudar a
identificar el estado de la aplicación y a hacer predicciones de cuándo puede
estar lista la liberación de una nueva versión. (Figura 10.)
Se puede también con este reporte observar si hay muchos casos de pruebas
que no han sido ejecutados, y esto llevaría 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 número de casos de pruebas que no se han
corregido o que corren con errores.
Otro reporte que puede ser útil, es la distribución de los errores encontrados
divididos en tres categorías: crítica, media, baja. ( Figura 11. )
87
Estado de los casos de pruebas
0
10
20
30
40
50
60
casoscompletados
casos conerrores
casos noejecutados
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 todavía. Esto puede significar que son necesarios más recursos para
evacuar un mayor número de casos de prueba y poder liberar una nueva versión
mas rápidamente.
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 gráfico se observa que el 33% de los errores encontrados son críticos,
esto puede indicar errores en las fases de diseño 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 metodología de pruebas (Dirigir las pruebas del sistema) y la
etapa 8 (Dirigir las pruebas de aceptación) hacen parte de las fases 1,2,3 y 4
(Planear, hacer, verificar y actuar) del ciclo PHVA.
A continuación se detallan las actividades que se llevan a cabo en estas etapas:
90
7. DIRIGIR LAS PRUEBAS DEL SISTEMA
Las pruebas del sistema evalúan el comportamiento, la funcionalidad y el
rendimiento de la aplicación viéndola como un todo. Estas pruebas consisten en
pruebas de estrés, volumen, rendimiento, seguridad, recuperación, etc. El
objetivo de esta tarea es discutir cómo se deben preparar las pruebas, cómo
diseñarlas, 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 según los objetivos
originales del proyecto que fueron definidos durante la fase de recolección de la
información.
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 estrés.
Luego:
• Pruebas de seguridad del sistema.
• Pruebas de Backup y recuperación.
91
Y por último:
• Pruebas de compatibilidad con otros módulos o sistemas.
• Pruebas a la documentación.
• Pruebas de instalación.
También, en esta fase se define qué pruebas se pueden realizar con
herramientas automáticas. La ventaja de estas pruebas es que pueden ser
repetitivas y con ellas se pueden realizar más exhaustivamente pruebas de
estrés 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 ejecución de las pruebas del sistema. Se debe
especificar la fecha de inicio y la fecha en la que se deben terminar, así como
también 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 diseñar, ejecutar y evaluar
los resultados de las pruebas. Está encargado también de reportar los errores y
las anomalías 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 aplicación o para corroborar que las
fallas se han corregido.
92
En el equipo de pruebas debe haber un líder encargado de:
• Organizar el equipo de trabajo.
• Estabilizar y adecuar el ambiente de trabajo.
• Organizar las políticas y estándares a utilizar.
• Trabajar de acuerdo con el plan de pruebas.
• Coordinar la documentación.
7.1.4 Estabilizar el ambiente de pruebas:
El propósito 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 tecnología
adecuada y las herramientas de pruebas adecuadas. Esta tecnología 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 físico 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 comunicación y puedan interactuar fácilmente para llegar a fines
comunes.
El hardware y el software necesarios, deberán 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 diseñados 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 combinación 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 aplicación. Para
las pruebas de caja blanca es necesario definir qué módulos, instrucciones o
tareas específicas se quieren probar.
Algunas medidas que se pueden tomar en cuenta para la evaluación de pruebas
de rendimiento son:
• Uso del procesador.
• Lectura / Escritura en discos.
• Número de Lecturas / Escrituras por instrucción.
• Velocidad de respuesta en red.
• Utilización de memoria.
• Tiempo medio de ejecución por módulo.
• Porcentaje de tiempos de espera.
• Espera entre módulos.
• Tiempo de inicio de la aplicación o módulos.
• Tiempo de respuesta del sistema a las instrucciones.
94
• Número de transacciones por minuto.
Las pruebas de rendimiento asumen que la aplicación funciona, es estable y
sólida. Por tanto, es importante eliminar tantas variables como sea posible de
las pruebas. Por ejemplo, los errores en el código pueden crear la apariencia de
un problema de rendimiento o incluso enmascarar un problema de rendimiento.
Para comparar con precisión los resultados de diferentes pasadas de las
pruebas de rendimiento, la aplicación debe funcionar correctamente. Es
especialmente importante restablecer la funcionalidad de la aplicación si el
proceso de ajuste ha modificado la implementación de un componente. La
aplicación debe pasar las pruebas de funcionalidad para poder probar su
rendimiento. Además de los cambios de la aplicación, puede haber cambios
inesperados en el hardware, el tráfico de la red, la configuración del software, los
dispositivos del sistema, etc.
Para ajustar correctamente el rendimiento, deben mantenerse registros precisos
y completos de cada ejecución de las pruebas. Los registros deben incluir:
• La configuración exacta del sistema, especialmente los cambios de
pasadas anteriores de las pruebas.
• Los datos sin formato y los resultados calculados de las herramientas de
supervisión del rendimiento.
Estos registros no indican sólo si la aplicación cumple los objetivos de
rendimiento, sino que ayudan a identificar las posibles causas de problemas
futuros de rendimiento.
Durante cada ejecución 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 aplicación. 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 aplicación antes de
comenzar la prueba.
7.2.2 Pruebas de seguridad
El objetivo de las pruebas de seguridad es evaluar que la aplicación tenga las
funciones adecuadas para asegurar la integridad y confidencialidad de la
información.
Uno de los puntos que debe probarse es el acceso a los recursos de la
aplicación. Analizar diferentes caminos de usar un recurso con fines ilícitos o
dañinos. También es importante probar que la información sólo pueda ser
cambiada o manipulada según el tipo de usuarios o según el módulo de la
aplicación.
Otros aspectos que se deben tener en cuenta son:
• Acceso de usuarios al sistema.
• Políticas de vencimiento o bloqueo de passwords de usuarios.
• Roles de los usuarios.
• Accesos remotos.
• Las acciones maliciosas que puedan causar perdidas o daños..
• Que daños pueden ocurrir a la información en caso de acciones
maliciosas.
• Funciones o controles que se deben tener en cuenta para prevenir
acciones que puedan causar daños o perdidas en la información.
• Funciones de seguridad para resguardar la información 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
volúmenes de datos y comprobar que sea capaz de manejarlo y comportarse de
la manera esperada.
Las pruebas de volumen extienden el sistema a sus límites de diseño con
grandes volúmenes de transacciones, datos, etc. Examina el funcionamiento del
sistema cuando está trabajando con grandes volúmenes de datos y con
cantidades de datos no permitidas.
7.2.4 Pruebas de estrés
El objetivo de las pruebas de estrés 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 aplicación.
Las pruebas de estrés ayudan a descubrir errores sutiles que, de otro modo, no
se detectarían hasta que se hubiese implementado la aplicación. Estas pruebas
son pruebas del límite del sistema, por ejemplo la máxima cantidad de usuarios
concurrentes.
7.2.5 Pruebas de compatibilidad
El objetivo de estas pruebas es chequear la compatibilidad de la aplicación con
otros módulos de la aplicación, otras aplicaciones u otros sistemas. Estos tipos
de pruebas se deben realizar antes de salir a producción, 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 aplicación comparte datos con
otras aplicaciones o está instalada en el mismo servidor con otros sistemas
compartiendo recursos como memoria.
7.2.6 Pruebas de Documentación
El objetivo de las pruebas de documentación es verificar que la documentación
del usuario sea correcta y que los procedimientos que se indican en ella
funcionen adecuadamente.
Una buena documentación ayuda a rebajar los costos de post venta ya que los
usuarios pueden resolver preguntas fácilmente 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 comprensión.
Algunas recomendaciones pueden ser:
• Usar la documentación como fuente para la elaboración de casos de
pruebas.
• Usar el sistema exactamente como dice la documentación.
• Probar todos los puntos y recomendaciones del manual.
• Documentar los errores encontrados.
• Asegurarse que la documentación contemple todas las funcionalidades
del sistema.
• Asegurarse que no se hable en terminología muy técnica.
98
7.2.7 Pruebas de Backup y Recuperación
El objetivo de estas pruebas es ver la facilidad del sistema para realizar respaldo
y recuperación de los datos y de la aplicación 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 automáticos si estos están contemplados.
• Verificar procedimientos de seguridad durante el backup.
• Realizar el procedimiento completo de backup.
• Restaurar parcialmente backups anteriores.
• Restaurar completamente backups anteriores.
• Realizar restauraciones automáticas.
7.2.8 Pruebas de instalación
El objetivo de estas pruebas es comprobar que la aplicación se instale
correctamente. También se deben incluir pruebas de desinstalación y
reinstalación y comprobar su funcionamiento.
7.3 Revisar y aprobar las pruebas del sistema.
7.3.1 Programar y preparar la revisión
La revisión de la planeación de pruebas del sistema debe ser programada. Es
importante que los participantes de la reunión para la revisión tengan la última
copia del documento del plan de pruebas del sistema.
99
La agenda realizada para la revisión debe contemplar el tiempo estimado para la
revisión de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunión.
El propósito de esta revisión 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 Aprobación
El objetivo de esta actividad es que sea aprobado el diseño de las pruebas del
sistema por el equipo de calidad y el equipo de desarrollo. Esta aprobación se
debe realizar por escrito y debe estar firmada por el gerente del proyecto, el líder
de pruebas y el líder de los desarrolladores. Se debe también elaborar y
entregar un documento donde se encuentre la última copia del diseño 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, enfocándose en las funciones
que se han modificado o que han sido objeto de correcciones.
100
Mediante una matriz de reexaminación (retest) se pueden ubicar fácilmente los
casos de prueba que serán 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 ejecución 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 automáticas), las pruebas de
fragmentos del sistema y las pruebas de aceptación, en preparación para las
siguientes pruebas. En este punto todas estas pruebas son ejecutadas.
7.4.3 Documentar los defectos arrojados por las pruebas.
Durante la ejecución de las pruebas, los resultados deben ser reportados en la
base de datos de defectos. Los defectos generalmente están 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 información relacionada con
el defecto. Es recomendable realizar el registro de los defectos digitalmente ya
que de esta forma es más fácil hacerles seguimiento y localizar los defectos
duplicados.
101
8. DIRIGIR LAS PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación son pruebas ejecutadas por un usuario para
demostrar que la aplicación cumple con los objetivos del negocio y
requerimientos del sistema. Usualmente están compuestas por subconjuntos de
pruebas del sistema. A continuación se indica cómo preparar, diseñar y ejecutar
las pruebas de aceptación y adicionalmente cómo reportar los defectos
descubiertos durante las pruebas.
8.1 Completar la planeación de las pruebas de aceptación.
8.1.1 Identificar los tipos de pruebas de aceptación.
En esta actividad, la lista de la clasificación de las pruebas iniciales de
aceptación es refinada y son seleccionadas las pruebas que serán ejecutadas.
Las pruebas de aceptación demuestran la habilidad de la aplicación para reunir
todos los requerimientos del usuario. El objetivo de estas pruebas es demostrar
que la aplicación funciona, en este punto se hace menos énfasis en las
características técnicas y más 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 estrés
con el fin de sobrepasar los límites del sistema.
8.1.2 Finalizar el cronograma de las pruebas de aceptación.
En esta actividad el cronograma de las pruebas de aceptación debe ser
finalizado incluyendo los pasos de las pruebas, fechas de inicio, finalización y
responsables. El cronograma adicionalmente debe describir cómo será
revisado, cómo se le hará seguimiento y cómo será aprobado.
102
Para las pruebas de aceptación, 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 continuación se presenta un ejemplo de un
cronograma de pruebas de aceptación:
Paso de la prueba Fecha de inicio
Fecha de finalización
Responsable
Organización general
Organizar el equipo de pruebas
de aceptación. 08/01/2004 08/07/2004
John, Director
de pruebas
Establecer el ambiente para las
pruebas de aceptación 08/08/2004 08/09/2004
John, Director
de pruebas
Establecer las herramientas para
las pruebas de aceptación 08/10/2004 08/10/2004 Juan, Tester
Pruebas de Aceptación
Diseño / Escritura de las
pruebas 12/11/2004 12/15/2004
Juan (usuario),
Testers
Revisión de las pruebas 12/16/2004 12/16/2004 Jhon, Director
de pruebas
Ejecución de las pruebas 12/17/2004 12/22/2004 Juan (usuario),
Testers
Probar nuevamente los defectos
de aceptación 12/23/2004 12/25/2004
Juan (usuario),
Testers
Tabla 5: Cronograma de pruebas
103
8.1.3 Organizar el equipo de pruebas de aceptación.
El equipo de pruebas de aceptación es responsable de diseñar 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 corrección. El equipo de pruebas de
aceptación usualmente cuenta con un representante de los usuarios de la
aplicación que finalmente es quien acepta el sistema.
El equipo de pruebas de aceptación 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 políticas de pruebas, procedimientos y estándares.
• Asegurar la preparación de las pruebas.
• Trabajar en el plan de pruebas y controlar el proyecto.
• Hacer seguimiento de costos de las pruebas.
• Asegurar que la documentación de las pruebas es exacta y oportuna.
• Coordinar el equipo.
8.1.4 Establecer el ambiente de pruebas de aceptación.
Durante esta actividad se finaliza el ambiente para las pruebas de aceptación, el
cual generalmente es el mismo que se usó para las pruebas del sistema. El
propósito 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 implementación.
104
Los componentes principales del ambiente de pruebas incluyen la facilidad, la
tecnología, y las herramientas de las pruebas. El componente facilidad de las
pruebas se refiere a la disposición y configuración física. La tecnología 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, librerías de pruebas y
software de soporte.
La facilidad de las pruebas y el lugar de trabajo deben ser establecidos. Este
puede extenderse de una configuración individual del lugar de trabajo a un
laboratorio de pruebas formal; de cualquier forma, es importante que los
probadores estén juntos y cerca del equipo de desarrollo. Esto facilita la
comunicación y la tenencia del sentido de una meta común.
El hardware y el software de pruebas deben ser instalados. Esto en
coordinación con los vendedores, los usuarios y el personal de tecnología de
información. 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 aceptación.
Durante esta actividad, las herramientas para las pruebas de aceptación son
instaladas y verificadas. Se debe realizar una ejecución de los casos de prueba
y de los scripts de las pruebas para verificar que las herramientas están listas
para las pruebas de aceptación. Algunas otras consideraciones para tener en
cuenta en la preparación de las herramientas son:
• Capacitar al equipo de pruebas en el uso de las herramientas.
• Verificar compatibilidad de las herramientas con el ambiente de
operación.
105
• Asegurar espacio en disco para las herramientas.
• Garantizar comunicación 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 versión de las herramientas.
8.2 Completar los casos de pruebas de aceptación.
En esta actividad, los casos de prueba de aceptación se diseñan y se escriben.
Los casos de prueba funcionales, se transforman en casos reutilizables para
pruebas de aceptación con los datos de prueba creados.
8.2.1 Identificar el subconjunto de pruebas del sistema que se utilizarán para pruebas de aceptación.
Los casos de prueba de aceptación generalmente (no siempre) son
desarrollados por el usuario final y normalmente no son responsabilidad de la
empresa desarrolladora, porque las pruebas de aceptación 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 serán ejecutadas en el ambiente de
trabajo del usuario final o no.
Generalmente, las pruebas de aceptación consisten en un subconjunto de las
pruebas del sistema que se han diseñado ya durante las pruebas del sistema.
Por tanto, la tarea actual consiste en identificar cuáles de las pruebas del
sistema serán utilizadas para las pruebas de aceptación.
106
8.2.2 Diseñar y escribir pruebas de aceptación adicionales
Las pruebas de sistema que se ejecutarán nuevamente durante las pruebas de
aceptación, pueden ser complementadas con condiciones especiales para
maximizar la aceptabilidad del sistema. Por ejemplo, una prueba de aceptación
pudo requerir que un cierto rendimiento de procesamiento esté sostenido por un
período de tiempo con límites de tolerancia aceptables del tiempo de respuesta.
Otras pruebas no diseñadas 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 también ayuda al usuario a
estar listo para lo que se va a instalar y a poner en producción realmente de
manera que no se creen falsas expectativas.
El diseño de las pruebas de aceptación puede incluir el uso de datos coherentes,
porque probablemente se dará más fácilmente la aceptación de los resultados
de las pruebas si se parecen a los datos reales del usuario.
8.3 Revisar el plan de pruebas de aceptación.
8.3.1 Programar y llevar a cabo la revisión.
La revisión del plan de pruebas de aceptación se debe programar antes de la
revisión real y los participantes deben tener la última versión del plan de
pruebas.
Como con cualquier entrevista o revisión, 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 duración estimada para la revisión y aclarar que si el
tiempo expira antes de terminar todos los puntos de la agenda deberá ser
programada otra revisión para continuar.
El propósito 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 revisión, estos deben ser incorporados
en el plan.
8.3.2 Aprobar el plan de pruebas de aceptación.
La aprobación del plan de pruebas es crítica ya que ayuda a proporcionar los
acuerdos necesarios entre las pruebas, los desarrolladores, y el gerente del
proyecto. Esta aprobación se debe realizar por escrito y debe estar firmada por
el gerente del proyecto, el líder de pruebas y el líder 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 están de acuerdo con el plan.
8.4 Ejecutar las pruebas de aceptación.
8.4.1 Ejecutar las pruebas de aceptación de los errores encontrados en las pruebas anteriores.
El propósito de esta tarea es ejecutar nuevamente las pruebas que descubrieron
defectos en las anteriores pruebas de aceptación. 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 aplicación a fondo. El problema se enfoca en
108
cómo localizar esos casos de prueba para probar los defectos descubiertos
durante las pruebas anteriores, un buen mecanismo es la matriz de
reexaminación.
Como se mencionó anteriormente, una matriz de reexaminación 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
función (o la unidad del programa) sea modificada debido a una mejora o a una
corrección. Ninguna entrada significa que la prueba no necesita ser ejecutada
nuevamente. La matriz de reexaminación 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 reexaminación en la preparación para las
siguientes pruebas.
Si se observa que algunas funciones están estables y no han tenido
modificaciones recientes, se puede retirar (sí existe) su chequeo de la matriz de
reexaminación.
8.4.2 Ejecutar las actuales pruebas de aceptación.
El propósito de esta tarea es ejecutar las pruebas de aceptación creadas desde
la última ejecución de pruebas. Durante este lapso de tiempo, el equipo de
pruebas debe haber puesto al día las funciones/GUI, los fragmentos del sistema,
y las pruebas de aceptación en la preparación para estas pruebas.
109
8.4.3 Documentar los defectos de aceptación.
Durante la ejecución de las pruebas de aceptación, los resultados de las
pruebas deben ser reportados en la base de datos de defectos. Estos defectos
generalmente están 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 ejecución 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 información del defecto.
Existen herramientas que se pueden utilizar para consolidar y registrar defectos
dependiendo de los métodos de la ejecución de la prueba. Si los defectos se
registran en papel, la consolidación implica recoger y organizar todos los
papeles. Si los defectos se registran electrónicamente, las características de
búsqueda pueden localizar fácilmente los defectos duplicados.
110
9. RESUMEN DE PRUEBAS Y REPORTE FINAL
9.1 Resumen y consolidación de la información 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 algún error que no
ha sido resuelto se debe dar mayor énfasis a él y se debe disponer de los
recursos necesarios para estabilizar la aplicación.
9.1.2 Consolidar los errores por casos de prueba y funciones.
En esta fase, el equipo de pruebas debe consolidar la información que se
encuentra en la documentación 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 número de errores para dicho caso.
9.1.3 Documentar errores no corregidos
Para los errores que no han sido corregidos, se debe especificar también el caso
de prueba y la función en donde ocurrió. Esto se debe documentar en la matriz
de prueba / función.
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 aplicación.
9.2.1 Resumir las actividades y eventos durante el desarrollo de las pruebas.
Se debe resumir información sobre:
• El equipo de pruebas: Especificar quiénes conforman el equipo de
pruebas, qué papel desempeña cada uno dentro del equipo y qué cargo
tienen. ( ej. Diseñador de pruebas, ejecutor, etc. )
• El ambiente de pruebas: Describir el ambiente de hardware y software en
que se ejecutaron las pruebas, como tecnologías utilizadas, herramientas,
redes, etc.
• Tipos de pruebas: Especificar qué tipos de pruebas se utilizaron y cuántas
por cada tipo ( pruebas de sistema, pruebas de aceptación, etc. )
• Eventos: Indicar qué eventos externos e internos afectaron el desarrollo
de las pruebas y qué impacto tuvieron sobre la aplicación.
9.3 Crear y analizar gráficos de métricas.
El objetivo de esta tarea es analizar las métricas que se midieron durante el ciclo
de pruebas del proyecto. Para ello se deben crear gráficos que ayuden a un
mejor análisis y comprensión de los resultados de las pruebas. Este análisis
sirve como instrumento para determinar la calidad y la aceptabilidad del sistema
así como para futuros proyectos.
Algunas métricas y gráficos sugeridos son:
112
• Seguimiento de errores En este gráfico 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 función:
Analizar el número de defectos encontrados por cada una de las funciones o
grupos de funciones de la aplicación. Con esta medida se puede identificar
cuales funciones presentaron más problemas y encontrar así posibles causas de
esto; por ejemplo un mal diseño de los requerimientos. ( tabla 6 )
113
FUNCIONALIDAD
Número 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 Administración de Clientes Crear Cliente 4 8 Editar Cliente 4 8 Borrar Cliente 3 6 Administración Financiera Recibir Pago de Cliente 0 0 Depositar Pago 3 6 Pagar Nómina 4 8 Total 50 100
Tabla 6: Defectos por función
• Severidad de los errores encontrados
El objetivo de esta métrica es mostrar los errores encontrados divididos según
su severidad y el efecto en la aplicación. En este reporte se observa que los
errores críticos en las pruebas finales fueron pocos y que la aplicación en
general presentó errores de severidad baja. ( Figura 13 )
114
Severidad de los errores
0102030405060708090
Critica Media Baja
Porcentaje
Figura 14: Severidad de errores
• Diferencia entre errores encontrados y errores corregidos
Este gráfico debe mostrar la mayor similitud posible entre la línea 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 aplicación.
• 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 gráfico 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 diseño de las funcionalidades. ( Figura 14)
115
Figura 15: Causas del error
• Quién encontró los errores
El objetivo es mostrar quién encontró los errores de la aplicación, como por
ejemplo clientes externos, el equipo de calidad, etc. La mayoría 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 ejecución de los casos de prueba
El reporte del estado final de la ejecución de los casos de prueba muestra qué
casos han sido resueltos y nos indican si la aplicación esta lista para su
liberación a producción. Al final, en este reporte se debe indicar que todos las
funcionalidades han sido probadas y están correctas; si se encuentra alguna
excepción esta debe estar completamente documentada. (Figura 15)
Estado de los casos de pruebas
0
20
40
60
80
100
casoscompletados
casos conerrores
casos noejecutados
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 aplicación no es la adecuada o requiere una mejora.
118
• Reporte de defectos en las pruebas de aceptación
El objetivo de este reporte es demostrar que la aplicación cumple con los
objetivos del negocio y requerimientos del sistema y que la aplicación funciona.
Este reporte puede estar compuesto por los tipos de prueba del sistema. Al final
la mayor parte de los requerimientos deben quedar según las exigencias de los
usuarios.
Figura 18: Defectos en pruebas de aceptación
119
9.4 Conclusiones y Recomendaciones
En esta sección 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 leídas por los participantes del
proceso para comprobar que sean correctas y que se puedan realizar. Cada
conclusión y recomendación debe ser documentada.
9.4.1 Programar y preparar la revisión
La revisión del reporte final debe ser programada. Es importante que los
participantes de la reunión para la revisión tengan la última copia del reporte
final.
La agenda realizada para la revisión debe contemplar el tiempo estimado para la
revisión de todos los puntos. En caso de no terminarse se debe programar una
siguiente reunión.
El propósito de esta revisión 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 Aprobación
El objetivo de la aprobación es lograr que los participantes del proyecto estén de
acuerdo con el reporte. Esta aprobación se debe realizar por escrito y debe
estar firmada por el gerente del proyecto, el líder de pruebas y el líder de los
desarrolladores. Se debe también 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, organización y administración de cambios.
• El diseño de pruebas es uno de los mecanismos más efectivos de
prevención 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 verificación tales como
inspecciones del software, planeación y diseño temprano de las pruebas.
Estas actividades proporcionan información oportuna para reducir
defectos cuando es menos costoso fijar y mejorar los métodos, técnicas y
procesos en el desarrollo. Adicionalmente, brindan la información
necesaria para preparar la siguiente fase de las pruebas haciéndolas más
completas y enfocándose siempre en el mejoramiento continuo.
• Menos defectos en software conducen a menos esfuerzo en la ejecución
de las pruebas, cuantas menos pruebas encuentren defectos, menos
pruebas necesitan ser realizadas de nuevo debido a que se corrigen
menos defectos.
• La realización de pruebas ineficazmente, o peor aun, la ausencia de un
proceso claro para la ejecución 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
implementación de la metodología para la realización 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 realización de pruebas de software es una parte importante del
proceso de desarrollo de software. No es una simple actividad que se
lleva a cabo después de la implementación del código pues es parte de
cada etapa del ciclo de vida. Una estrategia de pruebas exitosa debe
comenzar desde la especificación de los requerimientos. Los detalles de
las pruebas serán especificados a través de los diseños de alto y bajo
nivel del sistema y las pruebas serán 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 más 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, insatisfacción del usuario,
escasa productividad y la baja calidad en el software producido. Las
empresas son conscientes de que el mercado valora, cada día más, la
calidad. Por tanto, las compañías exigen la disminución de errores y
penalizan los retrasos en entregas y las cancelaciones de proyectos. El
problema esta en que a menudo los profesionales no saben cómo
aumentar la calidad de sus desarrollos de software de una forma eficaz.
Una herramienta clave para conseguir una aplicación de alta calidad y
libre de errores es contar con un proceso de pruebas efectivo.
Lamentablemente, y aunque es una de las técnicas 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 metodología y/o con las herramientas adecuadas para
diseñar e implementar un proceso de pruebas adecuado a sus
necesidades.
123
Debido a la complejidad de probar una aplicación, la etapa de pruebas
puede llegar a ser de las más lentas del proceso de desarrollo de
software. Sin embargo, si un proceso de pruebas se desarrolla siguiendo
una planificación, una metodología y unas herramientas adecuadas se
pueden conseguir importantes disminuciones en los costos de desarrollo
y mantenimiento del software, así como una reducción en el número de
errores.
124
BIBLIOGRAFÍA
Pressman, Roger S. (2002). Ingeniería del Software: Un enfoque práctico; Quinta edición. 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). Ingeniería de Software; Sexta edición. Pearson Educación, México, 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
