Modelo QA Software PDF
Modelo QA Software PDF
Modelo QA Software PDF
INGENIERA DE SISTEMAS
UNIVERSIDAD EAFIT
MEDELLN
MAYO / 2010
1
TABLA DE CONTENIDO
1. Introduccin. ............................................................................................................. 5
2. Objetivos................................................................................................................... 8
2.1 Objetivo General. ................................................................................................ 8
2.2 Objetivos Especficos. ......................................................................................... 8
3. Justificacin del proyecto. ....................................................................................... 10
4. Alcance y productos................................................................................................ 12
5. Antecedentes. ......................................................................................................... 13
6. Contexto. ................................................................................................................ 15
6.1 Pruebas Funcionales de Software..................................................................... 17
6.1.1 Objetivos de las Pruebas Funcionales de Software. ................................... 18
6.1.2 Caso de Prueba Funcional. ........................................................................ 19
6.1.2.1 Diseo de casos de prueba. ................................................................ 20
6.1.2.2 Ejecucin de un Caso de Prueba Funcional. ....................................... 21
7. Procedimiento para realizar pruebas funcionales de software basado en
componentes. ............................................................................................................. 22
7.1 Etapas de la Metodologa de Testing para las Fases del Software Desarrollado a
Base de Componentes. .......................................................................................... 26
7.1.1 Fase de Diseo de la Arquitectura. ............................................................ 27
7.1.1.1 Descripcin. ........................................................................................ 27
7.1.1.2 Etapa de la Metodologa: Planeacin de Pruebas. .............................. 27
7.1.1.3 Objetivo. .............................................................................................. 28
7.1.1.4 Cubrimiento. ........................................................................................ 28
7.1.1.5 Entradas .............................................................................................. 29
7.1.1.6 Actividades. ......................................................................................... 29
7.1.1.7 Salidas. ............................................................................................... 31
7.1.1.8 Plantilla o Documento para el Plan de Pruebas. .................................. 32
7.1.1.9 Determinacin del avance. .................................................................. 32
7.1.1.10 Definicin de Artefactos ..................................................................... 33
7.1.1.10.1 Especificacin de Requerimientos. ............................................. 33
7.1.1.10.2 Documento de Entendimiento. .................................................... 33
7.1.1.10.3 Cronograma del Proyecto. .......................................................... 33
7.1.1.10.4 Especificacin de Cubrimiento de Requerimientos. .................... 33
7.1.1.10.5 Plan de Pruebas. ........................................................................ 33
7.1.1.10.6 Cronograma de Pruebas............................................................. 33
7.1.2 Fase de Especificacin y Bsqueda de Componentes. .............................. 34
7.1.2.1 Descripcin. ........................................................................................ 34
7.1.2.2 Etapa de la Metodologa: Diseo de Casos de Prueba........................ 34
7.1.2.3 Objetivo. .............................................................................................. 35
7.1.2.4 Cubrimiento ......................................................................................... 35
7.1.2.5 Entradas. ............................................................................................. 36
7.1.2.6 Actividades. ......................................................................................... 37
7.1.2.7 Salidas. ............................................................................................... 39
7.1.2.8 Documentos y Recursos asociados..................................................... 40
7.1.2.9 Determinacin del avance ................................................................... 40
7.1.2.10 Definicin de Artefactos. .................................................................... 40
7.1.2.10.1 Documento de Identificacin de Componentes ........................... 40
7.1.2.10.2 Modelo de Interaccin de Componentes..................................... 40
7.1.2.10.3 Especificacin de Componentes (reutilizados o desarrollados)... 41
7.1.2.10.4 Plan de Pruebas. ........................................................................ 41
7.1.2.10.5 Set de Datos. .............................................................................. 41
7.1.2.10.6 Documento Descripcin de Casos de Prueba (componentes). ... 41
2
7.1.2.10.7 Documento de Trazabilidad. ....................................................... 41
7.1.2.10.8 Documento Descripcin de Casos de Prueba (aplicativo final). .. 42
7.1.2.10.9 Informe de Avance...................................................................... 42
7.1.3 Fase de Adaptabilidad de Componentes. ................................................... 42
7.1.3.1 Descripcin. ........................................................................................ 42
7.1.3.2 Etapa de la Metodologa: Ejecucin de Casos de Pruebas.................. 42
7.1.3.3 Objetivo. .............................................................................................. 43
7.1.3.4 Cubrimiento. ........................................................................................ 43
7.1.3.5 Entradas. ............................................................................................. 44
7.1.3.6 Actividades. ......................................................................................... 45
7.1.3.7 Salidas. ............................................................................................... 50
7.1.3.8 Documentos y Recursos Asociados. ................................................... 51
7.1.3.9 Determinacin del Avance. .................................................................. 51
7.1.3.10 Definicin de Artefactos. .................................................................... 52
7.1.3.10.1 Descripcin de Casos de Prueba (componentes y aplicativo final).
.................................................................................................................... 52
7.1.3.10.2 Especificacin de Componentes (reutilizados o desarrollados)... 52
7.1.3.10.4 Documento de Cambios realizados sobre los componentes. ...... 52
7.1.3.10.4 Versin ejecutable de cada uno de los Componentes y del
Aplicativo Final. ........................................................................................... 52
7.1.3.10.5 Plan de administracin de recursos y mejoras en el desarrollo. .. 52
7.1.3.10.6 Documentacin Tcnica. ............................................................ 53
7.1.3.10.7 Resultados de Ejecucin de Casos de Prueba (componentes). .. 53
7.1.3.10.8 Resultados de Ejecucin de Casos de Prueba (aplicativo final). . 53
7.1.3.10.9 Reporte de Issues....................................................................... 53
7.1.3.10.10 Informe de Avance.................................................................... 53
7.1.4.1 Descripcin. ........................................................................................ 54
7.1.4.2 Etapa de la Metodologa: Evaluacin de Pruebas. .............................. 54
7.1.4.3 Objetivo. .............................................................................................. 57
7.1.4.4 Cubrimiento. ........................................................................................ 57
7.1.4.5 Entradas. ............................................................................................. 57
7.1.4.6 Actividades. ......................................................................................... 58
7.1.4.7 Salidas. ............................................................................................... 60
7.1.4.8 Documentos y Recursos Asociados. ................................................... 61
7.1.4.9 Determinacin del Avance. .................................................................. 61
7.1.4.10 Definicin de Artefactos. .................................................................... 61
7.1.4.10.1 Resultados de Ejecucin de Casos de Prueba (componentes y
aplicativo final). ........................................................................................... 61
7.1.4.10.2 Reporte de Issues....................................................................... 61
7.1.4.10.3 Documento de Integracin de Componentes. ............................. 61
7.1.4.10.4 Resumen de Pruebas sobre Componentes y Aplicativo Final. .... 62
7.1.4.10.5 Carta de Certificacin. ................................................................ 62
7.2 Definicin de Actores para la Metodologa Propuesta. ...................................... 62
7.2.1 Analista de Pruebas. .................................................................................. 62
7.2.2 Analista Lder de Pruebas. ......................................................................... 62
7.2.3 Diseador de Pruebas................................................................................ 63
7.2.4 Ejecutor de Pruebas. .................................................................................. 63
7.3 Diagrama de Estados del Issue. ....................................................................... 63
7.3.1 Flujo de los Estados de los Issues ............................................................. 64
7.4 Informe de Incidentes........................................................................................ 66
7.4.1 Estructura Fijada en el Estndar. ............................................................... 66
7.5 Buenas Prcticas de Pruebas Exitosas. ............................................................ 67
8. Glosario de trminos. .............................................................................................. 69
3
9. Conclusiones. ......................................................................................................... 71
10. Bibliografa. ........................................................................................................... 73
11. Anexos.................................................................................................................. 75
4
1. INTRODUCCIN.
Como bien se sabe, el desarrollo de software es una actividad que est sujeta a los
errores humanos, por tanto es probable encontrarse en cualquier desarrollo con
defectos, errores y fallas. Para tratar de evitar esas situaciones al mximo existen ya
definidas metodologas de desarrollo que si bien no garantizan la eliminacin total de
errores si disminuyen altamente la probabilidad de falla. Pero an as y por ms que se
quieran evitar este tipo de sucesos, se dificulta ya que son inesperados, es all donde
cobra importancia un adecuado proceso de pruebas de software que permita certificar
desde el punto de vista de la calidad un producto de software, si bien es una tarea que
necesita de diversos recursos como el esfuerzo, planeacin, organizacin,
documentacin y tiempo no se debe tomar como un impedimento, sino como una
inversin que se ver retribuida en la satisfaccin del usuario final o cliente.
Con el propsito entonces de realizar estas pruebas de software y gestionar los
errores o fallas que se pueden presentar durante el desarrollo, a travs de una manera
eficiente han surgido diferentes metodologas de Testing aplicadas a los diversos
mtodos de desarrollo, en especial a los ms populares como son el mtodo de
desarrollo RUP, cascada y espiral.
Sin embargo y a pesar de que los anteriores mtodos de desarrollo que han sido
mencionados siguen siendo populares, hay otros mtodos que han probado tambin
ser muy eficientes, es el caso del mtodo del desarrollo de software basado en
componentes que cada vez es ms usado como modelo para el desarrollo. Este
modelo tiene como gran ventaja la reutilizacin de cdigo y es all precisamente donde
radica su fortaleza haciendo de este mtodo una gran alternativa de desarrollo de
software que cada da tiene ms acogida entre el gremio de desarrolladores ya que
facilita la labor de estos, disminuyendo los tiempos y aumentando considerablemente
la eficiencia durante la etapa de construccin de un software.
5
metodologa adaptada al modelo que gestione los errores y las fallas, podran
presentarse muy probablemente una serie de eventos que suceden a menudo en
muchas compaas cuya razn social es el desarrollo de software.
Sucede muy a menudo debido a las mismas caractersticas que tiene este modelo de
desarrollo que el mismo desarrollador no sabe cmo replicar el issue detectado, ya
que por la naturaleza del mismo modelo que implica la reutilizacin de cdigo, el
desarrollador no puede reproducir el issue y por tanto no lo puede solucionar, o en
caso de poder reproducirlo, a menudo el desarrollador piensa que ha solucionado el
issue, realiza modificaciones sobre algn componente que funcionaba pero igual el
issue persiste a causa de que realmente no sabe cmo deba funcionar. O en caso de
poder solucionarlo nadie se entera, al cliente nunca le llega el aplicativo solucionado
debido a una comunicacin deficiente con el mismo.
6
En otras ocasiones, las compaas si intentan tener una metodologa de testing
adaptada para el desarrollo de sus aplicaciones pero no hacen el trabajo completo,
simplemente tienen un sistema donde se reportan los issues, pero no se hace la
correcta gestin de los mismos. Es aqu donde se empiezan a presentar situaciones
en donde el desarrollador no posee la suficiente informacin para tomar las decisiones
ms acertadas. Por ejemplo, siempre existen issues, unos ms importantes que otros,
y supongamos como casi siempre sucede que el tiempo est limitado, los
desarrolladores pierden el tiempo solucionando issues triviales mientras que los issues
crticos siguen sin ser solucionados, esto a causa de que los issues no estn
priorizados. O la persona que est pendiente que se solucionen los problemas
interrumpe constantemente al desarrollador para consultar el estado de los issues,
esto podra ser fcilmente controlado de tenerse implementada una metodologa que
gestione el listado de los issues con sus respectivos estados de resolucin.
7
2. OBJETIVOS.
Definir una serie de artefactos que permitan un mayor control y una mayor
eficacia a la hora de realizar las pruebas funcionales sobre estas aplicaciones
que han sido desarrolladas con el mtodo de desarrollo basado en
componentes.
8
Especificar los roles definidos por el mtodo de desarrollo para software
basado en componentes y las funciones que tienen dentro del procedimiento
propuesto.
9
3. JUSTIFICACIN DEL PROYECTO.
La primera justificacin para llevar a cabo este proyecto surge a partir del
conocimiento previo que se tiene de la cantidad de procedimientos para realizar
pruebas que existen actualmente, sin embargo tambin se sabe que muchos de estos
procedimientos son privados y muy concretos sobre la empresa y no sobre el
producto, otros son demasiado complejos para que una empresa pequea los pueda
utilizar, otros que no se encuentran bien gestionados, pues utilizan herramientas que
no son las ms adecuadas como archivos planos y los desarrolladores no pueden
hacer seguimiento a sus productos y por ltimo existen otros que se enfocan a
diferentes mtodos de desarrollo de software pero ninguno al particular que nos
concierne, el desarrollo de software basado en componentes. Debido a esto y
queriendo aprovechar el cargo como analista de pruebas que ocupo actualmente en
una reconocida compaa de testing de software y ya que siempre he tenido inters en
el tema surge la idea de realizar este proyecto adems con el valor agregado de que
hago parte y laboro diariamente con este tema y he conocido las debilidades,
oportunidades y fortalezas del testing que existen en nuestro entorno.
Y a pesar de que los beneficios de este proceso de pruebas de software son claros,
las compaas desarrolladoras siguen viendo esta prctica como un proceso aparte
que no tiene mucha importancia y que slo produce costos operativos, en gran medida
gracias a que no han adoptado un proceso claro y adecuado acorde con sus
necesidades, es por ello que con el presente proyecto se pretende proponer una
herramienta ms que pueda servir a este tipo de compaas y que cada vez ms, el
uso de buenas prcticas de pruebas de software se implemente en estas empresas.
10
Habiendo expuesto lo anterior es que el presente proyecto cobra validez, porque
propone un procedimiento nuevo para este tipo de desarrollo, que podra ser adoptado
fcilmente por una compaa para que de esta manera se haga una buena gestin,
seguimiento y control de los errores en un desarrollo de software basado en
componentes.
11
4. ALCANCE Y PRODUCTOS.
El Proyecto tiene como alcance el desarrollo de una nueva metodologa para realizar
pruebas de software desarrollado a base de componentes sobre aplicativos de
software que se hayan desarrollado o que estn en proceso de desarrollo
centrndome en la funcionalidad del producto y no en sus otras caractersticas ya que
las pruebas de funcionalidad o funcionales de software se realizan durante casi todo el
ciclo de desarrollo del producto. Adems la metodologa que se propondr tendr
especialmente enfoque en las pruebas a realizar sobre la reutilizacin e integracin de
componentes la cual es la mayor ventaja y el mayor riesgo respectivamente que se
tienen al utilizar ste mtodo de desarrollo marcando as una diferencia con las
metodologas de testing tradicionales. Con la aplicacin de esta nueva metodologa les
ser posible a las empresas desarrolladoras apoyar las reas de prueba en forma
eficaz y efectiva de manera que podrn notar de manera satisfactoria el mejoramiento
y la optimizacin de sus procesos cuando este mtodo de desarrollo haya sido
escogido como el ms ptimo para el desarrollo de un aplicativo.
Cabe aclarar que en mi proyecto no se contempla la elaboracin o elicitacin de los
requisitos del software1, ya que esta actividad concierne a personas especializadas en
el tema. Como se mencion anteriormente, el proyecto tiene funcionalidad y validez a
partir de los requisitos ya elicitados.
1
La elicitacin de requisitos abarca la primera y quizs ms importante fase dentro del desarrollo de un
software. Su objetivo principal es garantizar que los requisitos del software sean consistentes con las
necesidades de la organizacin donde se utilizar el mismo y con las futuras necesidades de los usuarios.
12
5. ANTECEDENTES.
13
los ms populares RUP, cascada, espiral, etc, perfeccionando as la armona que debe
existir entre el mtodo de desarrollo y su metodologa de testing.
En la actualidad han surgido mtodos de desarrollo innovadores como ya lo hemos
mencionado, es el caso del desarrollo de software basado en componentes que tiene
como su gran fortaleza la reutilizacin de cdigo, es por eso que al igual que lo
hicieron los otros mtodos de desarrollo en su momento, el desarrollo de software
basado en componentes debe ir evolucionando y adoptando una metodologa de
testing propia que satisfaga sus necesidades en cuanto a calidad se refiere, una
metodologa de testing que adems ataque las debilidades del desarrollo basado en
componentes que en este caso bien podra ser la propia especialidad del mtodo, es
decir la reutilizacin de cdigo (componentes). La reutilizacin tiene muchas ventajas
entre las que se destaca la reduccin de tiempo en desarrollo y en pruebas si se dan
las condiciones, pero a su vez puede implicar la insercin de muchos issues que
acarrea la utilizacin de cdigo ajeno, esto sin contar los problemas funcionales que
puede traer consigo la integracin de componentes, momento crtico en el desarrollo, y
la metodologa de testing necesaria para ste mtodo debe saber entender esto y
atacar estos problemas de la manera ms adecuada.
Hemos visto las metodologas de testing han jugado un papel muy importante en la
evolucin de los mtodos de desarrollo, pero a pesar de ello an existen opiniones
encontradas sobre el Proceso de pruebas, como por ejemplo:
En contra:
El testing del software puede ser usado para mostrar la presencia de issues, pero
nunca su ausencia. Dijkstra.
"Nunca podemos estar seguros que un sistema de pruebas es correcto" Manna.
A favor:
"Testing es el proceso de evaluacin de un sistema o componente para verificar que
satisface los requisitos especificados, o identificar diferencias entre lo esperado y los
resultados obtenidos". IEEE
14
6. CONTEXTO.
Los sistemas de hoy en da son cada vez ms complejos, deben ser construidos en
tiempo rcord y deben cumplir con los estndares ms altos de calidad. Para hacer
frente a esto, se concibi y perfeccion lo que hoy conocemos como Ingeniera de
Software Basada en Componentes (ISBC), la cual se centra en el diseo y
construccin de sistemas computacionales que utilizan componentes de software
reutilizables. Esta ciencia trabaja bajo la filosofa de "comprar, no construir", una idea
que ya es comn en casi todas las industrias existentes, pero relativamente nueva en
lo que a la construccin de software se refiere.
Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y,
de la misma forma, muchos se preguntan da a da el por qu son tan pocos los que
realmente alcanzan el xito siguiendo esta filosofa. La realidad es que an se ha
tanteado poco las posibilidades del software basado en componentes, y es justo hora,
en la presente dcada, que la industria del software despegar y se perfeccionar para
estar a la par de cualquier otra industria del medio, este camino hacia el
perfeccionamiento de este modelo de desarrollo tan prometedor debe incluir
necesariamente la concepcin de su propia metodologa de testing que apoye y
garantice la calidad del software desarrollado con este modelo, haciendo que cada vez
ms sea tenido en cuenta por esta industria, la del desarrollo de software.
15
se convierta en un factor diferenciador para el incremento de la productividad en reas
de Tecnologas de Informacin.
2
El ciclo PDCA, tambin conocido como "Crculo de Deming" (de Edwards Deming), es una estrategia
de mejora continua de la calidad en cuatro pasos, basada en un concepto ideado por Walter A. Shewhart.
Tambin se denomina espiral de mejora continua
16
6.1 Pruebas Funcionales de Software.
17
6.1.1 Objetivos de las Pruebas Funcionales de Software.
Detectar:
- Funcionamiento incorrecto o incompleto.
- Issues de interface y de accesos a estructuras de datos externas.
- Problemas de rendimiento.
- Issues de inicio y terminacin.
3
Las pruebas de caja blanca son pruebas que realizan un seguimiento al cdigo fuente segn se
van ejecutando los casos de prueba, de manera que se determinan de manera concreta las
instrucciones, bloques, etc. en los que existen defectos.
18
6.1.2 Caso de Prueba Funcional.
Interfaz Grfica
19
6.1.2.1 Diseo de casos de prueba.
Un buen diseo de caso de prueba, es aquel diseo que incluye los casos de prueba
que tengan la mayor probabilidad de encontrar el mayor nmero de issues con la
mnima cantidad de esfuerzo y tiempo. Es por esto que hay tener criterios para elegir
buenos casos de prueba a la hora de elaborar un diseo.
Un caso de prueba funcional es bien elegido si cumple con las siguientes condiciones:
20
Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo
acerca de la ausencia o la presencia de issues en el conjunto especfico de
entradas que prueba, as como de otros conjuntos similares.
Tomemos como ejemplo el Caso de Prueba CP1 anterior; entonces: cmo probar el
caso de prueba y validar si ha tenido xito?
21
7. PROCEDIMIENTO PARA REALIZAR PRUEBAS FUNCIONALES DE
SOFTWARE BASADO EN COMPONENTES.
22
Este modelo, denominado ciclo de vida gemelo (twin life cycle), divide el proceso de
desarrollo de software en dos grandes bloques paralelos, tal como se ilustra en la
Figura 3. El primer bloque (amarillo), conocido como Ingeniera de Dominios,
contempla los procesos necesarios para desarrollar activos de software reutilizables
en un dominio particular. El segundo bloque (azul) es denominado Ingeniera de
Aplicaciones. Su propsito es el desarrollo de aplicaciones basado en la reutilizacin
de activos de software producidos a travs de la Ingeniera de Dominios. Y el tercer
bloque (rojo) correspondiente al testing se software que acompaa el ciclo de vida a lo
largo de todas sus etapas (es all donde centraremos nuestro enfoque).
23
Por otro lado est el modelo de ciclo de vida Watch el cual combina los procesos ms
relevantes de la Ingeniera de Software Orientada a Objetos con el modelo de
Ingeniera de Aplicaciones del ciclo de vida gemelo. Una caracterstica importante de
este modelo es la integracin de los procesos gerenciales con los procesos tcnicos
del desarrollo de software basado en componentes. Esta integracin facilita la labor
del lder del proyecto, al describir cmo se debe llevar a cabo una gestin del proyecto
integrada a los procesos tcnicos del desarrollo de software. La estructura del mtodo
WATCH se ilustra en la Figura 4. Esta estructura emplea la metfora de un reloj de
pulsera para describir el orden de ejecucin de los procesos tcnicos de desarrollo de
aplicaciones, indicando adems cmo los procesos gerenciales controlan o coordinan
el orden de ejecucin de los procesos tcnicos. Los procesos gerenciales estn
ubicados en el centro de la estructura para indicar explcitamente que ellos programan,
dirigen y controlan el proceso de desarrollo. Los procesos tcnicos estn ubicados en
el entorno siguiendo la forma que tiene el dial de un reloj. Ello indica que el orden de
ejecucin de las fases tcnicas se realiza en el sentido de las agujas del reloj. Los
procesos gerenciales pueden, sin embargo, invertir el orden de ejecucin para repetir
algunas de las fases anteriores.
Las tres primeras fases del modelo son similares a los modelos de procesos
tradicionales. La fase de Anlisis del Contexto permite que el grupo de desarrollo
adquiera un conocimiento adecuado del dominio o contexto del sistema en desarrollo.
Las fases de Descubrimiento, Anlisis y Especificacin de Requerimientos se
encargan de identificar las necesidades y requerimientos de los usuarios, as como
analizarlos, especificarlos grficamente y documentarlos. La fase de diseo del
sistema establece y describe la arquitectura del software. Describe cada uno de los
componentes que requieren tal estructura y cmo esos componentes se interconectan
para interactuar. El grupo de desarrollo debe, a partir de esta arquitectura, determinar
cules componentes se pueden reutilizar y cules requieren ser desarrollados en su
totalidad. Los componentes reutilizados deben ser adaptados, para satisfacer los
requerimientos del sistema; mientras que los componentes nuevos, deben ser
diseados, codificados y probados separadamente durante la fase de Implementacin.
Finalmente, la fase de Entrega se encarga de la instalacin, adiestramiento de
usuarios y puesta en operacin del sistema.
24
Como nuestra rea de enfoque ser en el flujo de trabajo Testing de software o
pruebas de software, la cual hace parte de ambos ciclos de vida. Y como bien
mencionaba anteriormente el ciclo de vida Watch es una combinacin entre los
procesos ms relevantes de la Ingeniera de Software Orientada a Objetos con el
modelo de Ingeniera de Aplicaciones del ciclo de vida gemelo, tomaremos como
referencia las partes coincidentes de ambos ciclos de vida para desarrollar nuestra
propuesta metodolgica de pruebas de software, es decir tomaremos el ciclo de vida
gemelo y sus fases ya que estas a su vez estn contenidas en el ciclo de vida Watch
haciendo que nuestra propuesta obviamente sea totalmente adaptable al ciclo de vida
gemelo pero que tambin sirva como metodologa de pruebas para el ciclo de vida
Watch con algunas adaptaciones. Entonces las fases que consideraremos como ciclo
de vida del desarrollo de software basado en componentes son:
Diseo de la arquitectura
Especificacin de componentes
Bsqueda de componentes
Adaptabilidad de componentes
Integracin de componentes
Planeacin de pruebas
Diseo de casos de prueba
Ejecucin de pruebas
Evaluacin de pruebas
Tanto las fases del ciclo de vida del desarrollo de software basado en componentes
como las etapas de la metodologa de pruebas se pueden observar en la Figura 5.
25
FIGURA 5: Procedimiento para realizar pruebas funcionales de software basado en
componentes
26
7.1.1 Fase de Diseo de la Arquitectura.
7.1.1.1 Descripcin.
La fase de diseo describe la arquitectura del software. Describe cada uno de los
componentes que requieren tal estructura y cmo esos componentes se interconectan
para interactuar, as como el ambiente y los principios que orientan su diseo. El grupo
de desarrollo debe, a partir de esta arquitectura, determinar cules componentes se
pueden reutilizar y cules requieren ser desarrollados en su totalidad. Los
componentes reutilizados deben ser adaptados, para satisfacer los requerimientos del
sistema, mientras que los componentes nuevos, deben ser diseados, codificados y
probados separadamente durante la fase de implementacin. En esta fase de diseo
de la arquitectura es posible redefinir el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto.
27
FIGURA 6: Etapa de planeacin de pruebas
7.1.1.3 Objetivo.
7.1.1.4 Cubrimiento.
Va desde el comienzo de la planeacin del proyecto, hasta los comienzos del anlisis
y durante el diseo de la arquitectura del software.
28
7.1.1.5 Entradas
7.1.1.6 Actividades.
Responsable Actividad
PLANEAR
Analista de Revisar toda la documentacin, es decir la especificacin de
Pruebas/Analista lder requerimientos, aquellos requerimientos que fueron cubiertos
del proyecto por componentes, documento de entendimiento y
29
cronograma del proyecto, con el fin de identificar previamente
a. Posibles riegos. (Tener en cuenta especialmente aquellos
requerimientos que hayan sido cubiertos con la reutilizacin
de componentes y la integracin de componentes que
siempre supone un momento crtico durante el desarrollo)
b. Recursos que sean necesarios tanto de hardware como de
software.
c. Recursos humanos para el proyecto.
d. Estimacin de tiempos y esfuerzos del proceso de
desarrollo.
e. Elaboracin de los escenarios de las pruebas.
HACER
Analista de En base a los artefactos recibidos, especificacin de
Pruebas/ requisitos, documento de entendimiento, cronograma del
Coordinador de proyecto y especificacin de cubrimiento de requerimientos
Proyecto hace el documento con los supuestos que se asumirn para
el proceso de pruebas.
Analista de Realiza la matriz de riesgos para cada una de las
Pruebas/ funcionalidades del aplicativo. Para cada funcionalidad se
Coordinador de estima de 1 a 3 (siendo 3 la probabilidad mayor) tanto el
Proyecto impacto y la posibilidad de falla, estos dos factores se
multiplican y luego se totaliza el promedio para todas las
funcionalidades. Tener muy presente que para aquellas
funcionalidades o requerimientos que fueron cubiertos por los
componentes reutilizados, el nivel de riesgo debera ser ms
alto, adicionalmente se debe estimar el riesgo de la
funcionalidad final que depende estrictamente de la
integracin de los componentes, momento crtico del
desarrollo con este mtodo, por tanto se supone un alto nivel
de riesgo para este caso.
Analista de Define la configuracin del ambiente de pruebas para que
Pruebas / sea igual o lo ms semejante posible al de produccin.
Coordinador de Revisa estimacin de tiempos y esfuerzos del proceso de
Proyecto desarrollo realizado.
Genera el documento de plan de pruebas.
30
Equipo de control Reunin con el equipo de proyecto para sensibilizar acerca
de calidad del proceso de control de calidad de software que se va a
Funcional realizar.
VERIFICAR
Comit de Revisa y aprueba el plan de pruebas y el cronograma de
Cambios Control de calidad funcional de aplicaciones.
Registra los cambios que considere necesarios en los
documentos.
ACTUAR
Analista de Realiza las correcciones necesarias en el documento de plan
pruebas/Coordinador de pruebas y cronograma de actividades de control de
de proyecto calidad funcional de software.
7.1.1.7 Salidas.
31
nombre y puesto desempeado.
Descripcin de cada tipo de
prueba.
Entregables del proyecto.
Necesidades ambiente.
Recursos humanos.
Datos de acceso y conectividad.
Estadsticas y mtricas a obtener.
- Analista de Pruebas / Actividades a realizar en el
Coordinador de Cronograma de proceso por fases.
proyecto pruebas. Porcentaje de tiempo de cada
- Comit de cambios fase en el proyecto.
Tiempo estimado por actividad.
Fecha inicio y final actividad.
La metodologa propuesta tiene para cada una de las etapas dentro de todo el proceso
de las pruebas una plantilla o documento, en este caso la plantilla asociada a la etapa
del Plan de Pruebas durante la fase del diseo de la arquitectura.
32
7.1.1.10 Definicin de Artefactos
Este documento contiene cada uno de los requerimientos con las especificaciones de
cada uno de ellos y que se esperan sean cumplidos a cabalidad por parte de los
componentes. Adems es el documento que contiene la informacin general e inicial
sobre el proyecto, tales como el por qu del proyecto, lo que espera obtener despus
de integrados los componentes.
Listado con todos los requerimientos que fueron cubiertos tanto por los componentes
reutilizados como por los componentes desarrollados.
Cronograma que estipula los tiempos a dedicar a cada etapa durante todo el proceso
de las pruebas funcionales, registra tanto las horas a dedicar por da a determinada
actividad como el porcentaje esperado de avance por da.
33
7.1.2 Fase de Especificacin y Bsqueda de Componentes.
7.1.2.1 Descripcin.
34
FIGURA 7: Etapa de diseo de casos de pruebas
7.1.2.3 Objetivo.
Especificar los casos de prueba que servirn como escenarios para realizar las
pruebas funcionales al aplicativo con el fin de validar la implementacin tal cual se
consign en los requerimientos y encontrar la mayor cantidad de issues en el software
a evaluar. Esto quiere decir, que el aplicativo desarrollado cumpla a cabalidad con el
objetivo principal para el cual fue creado.
7.1.2.4 Cubrimiento
35
7.1.2.5 Entradas.
36
7.1.2.6 Actividades.
Responsable Actividad
PLANEAR
Identificar cada uno de los componentes que son la
herramienta base para cumplir con los requerimientos del
desarrollo y a su vez de insumo para el diseo de los casos
Analista de pruebas prueba.
Identificar las interacciones entre los componentes que hacen
parte del desarrollo y como estos se complementan para
cumplir con la funcionalidad del desarrollo. Interacciones que
servirn de escenarios para elaborar los casos de prueba.
Identificar como fueron aplicados los componentes a lo largo
del desarrollo validando si restringieron el software
construido.
HACER
Identificar y describir casos de prueba tanto para cada uno de
los componentes como para la integracin final de estos:
Cada uno de los casos de prueba debe ser Identificado,
especificado y descrito. En el Diseo de Casos de Prueba, se
deben especificar los siguientes atributos para cada caso de
prueba:
1. Cdigo: Este cdigo es el identificador del caso de
prueba.
2. Nombre: Es el nombre que identifica cada caso de prueba.
3. Descripcin: Es la descripcin del caso de prueba.
4. Responsable: Es el nombre del responsable de elaborar
el caso de prueba.
5. Configuracin: Describe en forma detallada el ambiente
(tanto de software como de hardware) en el cual se
Analista de pruebas
realizarn las pruebas.
6. Entradas de prueba: Especifica cada uno de los
requisitos y caractersticas que conforman dicho caso de
prueba.
7. Precondiciones: Son los requisitos que se deben dar para
poder ejecutar el caso de prueba.
8. Post-condiciones: Son los requisitos que se deben dar al
terminar la ejecucin del caso de prueba.
9. Criterio de xito: Es la meta que se debe cumplir para
definir si un caso de prueba tuvo o no xito al ser ejecutado.
10. Procedimientos de prueba: Es la descripcin de todos
los pasos y puntos de validacin que se deben seguir al
ejecutar un caso de prueba.
37
11. Procedencia: Procedencia del componente para el caso
de prueba a evaluar. Si el caso de prueba a probar hace
parte de una funcionalidad que fue cubierta por un
componente reutilizado se debe marcar con una R este caso
con el fin de advertir entre los casos de prueba que cubren
funcionalidades que fueron desarrolladas con componentes
propios y aquellas que fueron desarrolladas con
componentes reutilizables.
Identificar y estructurar procedimientos de prueba:
El procedimiento de prueba es la forma ordenada de ejecutar
un caso de prueba. El procedimiento de prueba se compone
bsicamente de dos elementos:
1. Paso: Es un procedimiento que se debe implementar
utilizando una funcin de la aplicacin.
2. Punto de validacin: Es una comprobacin que se realiza
para asegurase que un paso o varios estn siendo
completados satisfactoriamente o no.
Identificar el Set de datos, es decir el conjunto de datos de
prueba que servirn para ejecutar las pruebas funcionales de
software. En este proceso se deben identificar datos
positivos, que conducen la prueba para identificar que las
funciones estn correctas, y datos negativos, que conducen
la prueba a encontrar issues. Se deben tener en cuenta los
Analista de pruebas siguientes parmetros en el set de datos.
1. Profundidad: Cantidad de datos del set de datos de
prueba. Es ms precisa la ejecucin de pruebas funcionales
mientras ms escenarios de un caso de prueba simulen la
realidad.
2. Amplitud: Es la variacin en los valores de los datos de
prueba.
3. Alcance: Importancia de los valores comunes (datos
positivos) y no comunes (datos negativos) en el Set de datos.
Disear los casos de prueba de regresin:
Las pruebas de regresin son un conjunto de pruebas (ya
realizadas antes) que aseguran que los cambios no han dado
lugar a cambios colaterales.
VERIFICAR
Verificar que cada caso de prueba se encuentra completo y
38
contiene todos los atributos exigidos, adems que se
diferencien aquellos casos de prueba correspondientes a las
Analista de pruebas / funcionalidades desarrolladas con componentes propios de
Analista lder del aquellas funcionalidades desarrolladas con componentes
proyecto reutilizables.
Revisar y controlar la cobertura de requisitos:
Esta actividad permite mantener un control sobre el
cubrimiento de requisitos por los casos de prueba, para
identificar si se est abarcando completamente el sistema y
trazando de forma adecuada los casos de prueba respecto a
los requisitos y/o casos de uso.
ACTUAR
Analista de pruebas Completar los atributos faltantes en los casos de prueba.
Incorporar nuevos casos de prueba de ser necesario.
7.1.2.7 Salidas.
39
la integracin de los
componentes.
- Analista lder del -Informe de avance. Debe contener un reporte
proyecto. con el avance del proyecto
- Comit de cambios. y los problemas
encontrados en la etapa
en forma diaria.
El avance del diseo de casos de prueba ser del 100% solo cuando estn diseados
el 100% de casos de prueba, es decir que todos los requerimientos estn
completamente cubiertos implcita o explcitamente en el diseo de dichos casos de
prueba con sus respectivos procedimientos de prueba y set de datos siempre y
cuando estos apliquen.
Este documento debe ilustrar como los componentes van a trabajar de modo
coordinado, las relaciones que van a existir entre ellos y el modo de interactuar para
conseguir la funcionalidad deseada.
40
7.1.2.10.3 Especificacin de Componentes (reutilizados o desarrollados).
Este artefacto define una lista de variables y sus posibles valores a introducir para la
ejecucin de las pruebas, as como tambin los resultados esperados de la ejecucin
para propsitos comparativos. Se pueden tomar en cuenta valores especficos o
describir rangos de valores. Los Datos de Pruebas se utilizan como fuente de engao
al objeto de prueba y as encontrar issues. Cabe destacar que cada caso de prueba
deber ser ejecutado una vez por cada combinacin de valores.
Documento donde se definen los casos de prueba que se van a ejecutar para cada
uno de los componentes a probar.
Representacin grafica de las relaciones existentes entre los requisitos y los casos de
prueba, y la manera como se encuentran estas relaciones.
41
7.1.2.10.8 Documento Descripcin de Casos de Prueba (aplicativo final).
Documento donde se definen los casos de prueba que se van a ejecutar para la fase
de integracin de los componentes que da como resultado el aplicativo final.
Informe con los avances que se han realizado en el proceso de pruebas funcionales.
7.1.3.1 Descripcin.
42
componentes que da como resultado el aplicativo final, as mismo como el registro de
los issues encontrados.
7.1.3.3 Objetivo.
Ejecutar cada uno de los casos de prueba y reportar los issues encontrados en el
software.
7.1.3.4 Cubrimiento.
43
7.1.3.5 Entradas.
44
y seguridad.
-Manual de uso y ayudas
en lnea.
7.1.3.6 Actividades.
Responsable Actividad
PLANEAR
Configuracin de la ambientacin de equipos de pruebas: En
este paso se debe adaptar el ambiente de pruebas donde
ser probado la versin de la aplicacin. Se deben configurar
tanto el software (sistema operativo, base de datos, servicios
Equipo de plataforma y protocolos, entre otros) como el hardware (Procesador,
memoria, disponibilidad de espacio en disco, entre otros).
Configuracin de las herramientas de pruebas:
Si se van a utilizar herramientas para automatizacin de
pruebas, estas deben ser configuradas en el servidor y/o en
el (los) cliente (s).
Conocer y explorar el componente, antes de ejecutar un caso
de prueba el analista deber realizar una prueba exploratoria
(smoke test) para conocer el componente y cada uno de los
mdulos o funciones que se van a probar. Tambin se hace
con el fin de saber las acciones necesarias para suspender o
Analista de Pruebas detener la prueba (cuando los acontecimientos no previstos
lo obliguen). El mismo procedimiento se debe seguir al
momento de ejecutar un caso de prueba del aplicativo final.
Verificar que cada mdulo de la aplicacin que vaya a
ser probado haya sido verificado:
Cada mdulo que se vaya a probar debe haber sido
verificado por un miembro del equipo de desarrollo, para lo
cual debe entregar la lista de chequeo correspondiente.
HACER
Ejecucin de los casos de prueba para los componentes:
En esta actividad se realiza la ejecucin de los casos de
45
prueba que se planearon y disearon, los cuales son
ejecutados a travs de la interfaz de usuario y se conocen
como pruebas de caja negra. Esta ejecucin se debe hacer
teniendo en cuenta el cronograma, los diseos de casos de
prueba tanto los normales como los que fueron marcados
con R ya que sus componentes son aquellos componentes
reutilizados y las pruebas funcionales realizadas
anteriormente sobre cada uno de los componentes (tanto los
desarrollados como los reutilizados). A continuacin entonces
las condiciones a tener en cuenta durante la ejecucin de los
casos de prueba:
46
este mtodo de desarrollo y no se prueba
nuevamente.
- Pero si fue crtico y se evidenciaron problemas
durante las pruebas realizadas, se convierte en una
desventaja el uso de componentes reutilizables y se
debe probar el caso de prueba no solo una vez sino
tambin hacerle una regresin en particular para
descartar issues inherentes a la reutilizacin.
47
registrar en el documento llamado Resultados de
Ejecucin, todos los eventos que sucedan durante la
ejecucin de cada escenario de cada caso de prueba.
Se debe especificar en el Registro de Pruebas:
- Cdigo del caso de prueba.
- Nombre del caso de prueba.
- Mdulo al que corresponde el caso de prueba
- Resultado Obtenido.
- Estado de ejecucin (Pas, Fall, No se pudo
ejecutar).
- Issues Asociados durante ese ciclo.
- Fecha de ejecucin.
- Analista de Pruebas.
Este documento permitir obtener mtricas y estadsticas
comparativas.
VERIFICAR
Investigar los resultados inesperados:
Una vez reportados los issues, stos son analizados por el
Equipo de Desarrollo equipo de desarrollo quien debe resolver los nuevos issues
que aparecen reportados, en el orden de prioridad e impacto,
que se les haya asignado.
Evaluacin de la ejecucin de pruebas:
La evaluacin de la ejecucin de pruebas permite
determinar si los criterios de completitud de los casos de
prueba se han alcanzado satisfactoriamente, si se han
Analista de Pruebas encontrado issues nuevos o reincidentes o se han detenido
casos de prueba que se estaban ejecutando debido a
problemas externos o a issues que paralizan el
funcionamiento; determinando as, si hubo una terminacin
normal o anormal. Una terminacin normal, es aquella donde
los casos de prueba dispuestos para un ciclo en particular,
pudieron ser ejecutados. Una terminacin anormal, es donde
varios casos de prueba, no se pudieron completar o cuando
hubo una falla del sistema y se debi detener la ejecucin de
las pruebas debido a un issue stopper. En este caso, toda la
48
ejecucin de las pruebas se debe volver a realizar y no ser
considerada como ciclo normal de pruebas.
Equipo de Desarrollo Implementar la solucin para cada issue reportado por el
Analista de Pruebas.
Analista de Pruebas Verificar solucin de issues (tambin llamado Test de
Regresin) esto independientemente de las regresiones
particulares que se hayan hecho para algunos casos de
prueba como se indic anteriormente: Una vez implementada
la solucin de un issue, se deben realizar la evaluacin y la
ejecucin de los casos de prueba respectivos para verificar lo
siguiente:
a. Que la solucin del issue ha sido incorporada
correctamente.
b. Que no se generaron issues adicionales despus de
implementar la solucin.
Hasta que la solucin de todos los issues no sea verificada,
no se considerar finalizado.
ACTUAR
Coordinador de Ejecutar casos de prueba con issues reincidentes:
proyectos / Si existen issues reincidentes, es decir issues que han sido
Analista de Pruebas reportados durante varios ciclos de prueba, el equipo de
prueba deber elaborar un informe en el cual se especifique
el alcance del issue y el impacto que tiene en la aplicacin,
en caso de que el issue sea reincidente durante ms de 2
ciclos se levantar una accin correctiva y ser escalado al
analista lder del proyecto.
Analista de Pruebas Identificar y describir nuevos casos de prueba:
Si durante la etapa de ejecucin se llega a la
conclusin que existe un escenario de la aplicacin, que
no se haba identificado, el cual aporta un nuevo caso
de prueba, este se debe adicionar al gestor de pruebas,
e identificar los atributos correspondientes, (ver Etapa
Diseo de casos de prueba) para ese nuevo caso.
49
7.1.3.7 Salidas.
50
- Analista lder del Resultados de ejecucin ejecutado debe tener:
Proyecto. de casos de prueba Cdigo del caso de
- Etapa de Evaluacin de (aplicativo final) prueba.
pruebas. Nombre del caso de
prueba.
Resultado esperado.
Resultado Obtenido.
Estado de ejecucin.
(Pas, Fall, No se pudo
ejecutar).
Ciclo correspondientes.
Issues Asociados.
Fecha de ejecucin.
Analista de Pruebas.
Las pruebas del sistema estarn completas en un 100% cuando todos los casos de
prueba se hayan alcanzado y todos los issues reportados hayan sido solucionados y
no se encuentren issues reincidentes o nuevos. Para obtener un valor de porcentaje
ms exacto, se recomendara dividir el total del 100% entre la cantidad de casos de
prueba que se tienen y de esta manera obtener un valor para cada caso
individualmente.
51
7.1.3.10 Definicin de Artefactos.
Documento donde se definen los casos de prueba que se van a ejecutar tanto para los
componentes como para el aplicativo final que viene despus de la integracin de los
componentes.
Documento que contiene los cambios realizados en caso tal de que los componentes
utilizados hubieran sido modificados. Por ms mnima que sea la actualizacin debe
haber sido reportada en este documento.
Versin ejecutable de los componentes sobre los cuales se van a realizar las pruebas
y posteriormente integrados para cumplir con la funcionalidad final del aplicativo.
Este artefacto define los posibles cambios o mejoras que se le pueden realizar a cada
uno de los componentes. Este documento es importante ya que al leer estas posibles
sugerencias al desarrollo puede ser posible en ocasiones descifrar algunas
52
debilidades de los componentes utilizados que seguramente sern muy tiles al
momento de la ejecucin de los casos de prueba.
Informe con los avances que se han realizado en el proceso de pruebas funcionales.
53
7.1.4 Fase de Integracin de Componentes.
7.1.4.1 Descripcin.
Sin embargo no son solo ventajas las que ofrece la integracin de componentes, se
debe mencionar adems que este modo de desarrollo tiene tambin sus desventajas y
propios riesgos. El punto crtico en la integracin de componentes es precisamente
esa, la integracin, lograr integrar los componentes usados de manera tal que logren
cumplir con la funcionalidad propuesta en ocasiones no es tarea sencilla, esto
precisamente no se garantiza validando que cada uno de los componentes funcione
individualmente como debiera, el resultado del trabajo conjunto de todos los
componentes a pesar de que todos hayan sido probados por separado y funcionen
como debieran, es inesperado y pueden presentarse incompatibilidades.
54
los casos de prueba fueron ejecutados y todos los datos son vlidos. Una terminacin
anormal, es donde uno o varios casos de prueba, no se pudieron completar o cuando
hubo una falla del sistema y se debi detener la ejecucin de las pruebas. En este
caso toda la ejecucin de las pruebas se debe volver a realizar. De lo contrario si hubo
una terminacin normal, se debe evaluar que el aplicativo en su conjunto funcione
como se especific inicialmente, es decir se evala que el hecho de haber probado las
funcionalidades con sus componentes por separado se vea reflejado en la integracin
final de los componentes que cumplan con la funcionalidad principal para la cual fue
pensado el aplicativo en un primer lugar.
Para que se genere mayor facilidad en el proceso de pruebas, los issues son
reportados en una aplicacin que permita el seguimiento de estos issues y permita
obtener un registro e historial de los mismos. Esta actividad forma la metodologa
conocida como Change Control Management (CCM)4.
Los reportes de issues se llevan a una matriz de control llamada Bug Tracker en
donde se hace seguimiento del estado de cada uno de los problemas reportados.
4
Metodologa con la cual se administra todo el proceso de control de cambios y seguimiento de issues en
el software.
55
Dependiendo de la gravedad del issue y los criterios de salida de la prueba, se debe
dar prioridad a estos para una accin correctiva. Los de menor gravedad debern ser
documentados y manejarse segn los procedimientos de informes y seguimiento del
problema para tener la seguridad de una correccin posterior.
La idea es conformar un comit de cambios el cual se debe reunir peridicamente
(mximo cada semana) con el fin de asignar los issues al desarrollador o grupo de
desarrolladores, definir prioridad, severidad, nivel de impacto y establecer
compromisos concretos de solucin.
Se evalan los resultados de las pruebas funcionales, analizando las incidencias
recibidas y comprobando que se han llevado a cabo todos los casos de prueba
establecidos en el Plan de Pruebas.
La evaluacin consiste en:
56
7.1.4.3 Objetivo.
7.1.4.4 Cubrimiento.
7.1.4.5 Entradas.
57
7.1.4.6 Actividades.
Responsable Actividad
PLANEAR
Analista de Recoleccin de resultados arrojados en la etapa de
Pruebas. Ejecucin de Pruebas.
HACER
Anlisis de los resultados:
Es el anlisis de las diferencias entre los resultados
esperados y los resultados obtenidos, se documenta toda la
etapa de ejecucin de casos de prueba y los resultados
obtenidos.
Evaluacin de la cobertura de los requisitos:
El objetivo de esta actividad, es el registro de medidas con el
fin de determinar cuntos y cules requisitos se encuentran
cubiertos, es decir, cuantos estn asociados con casos de
prueba para verificar que estn correctamente
implementados. Tambin se mide la cantidad de issues por
requisito y el impacto en los cambios. Las medidas claves
estn dadas por 2 factores:
Cobertura: La cobertura identifica que tan completas han
sido las pruebas funcionales del sistema, indicando el
porcentaje de casos de prueba que fueron ejecutados, para
determinar qu porcin de requisitos fueron cubiertos.
Calidad: Identifica si las pruebas realizadas han alcanzado
los criterios de completitud definidos en los casos de prueba.
Analista de Pruebas De esta manera, se puede saber que tan coherente es el
sistema y si en verdad cumple con los propsitos
consignados en los requisitos.
58
que tena propuesto el aplicativo. Lo anterior se debe realizar
ya que las pruebas individuales realizadas para cada
funcionalidad sobre cada uno de los componentes no
garantiza que a pesar de que estos hubieran pasado las
pruebas al trabajar conjuntamente no presenten ningn tipo
de incompatibilidad, por tanto se hace necesario que
despus de la integracin de componentes cumplan con la
funcionalidad principal del aplicativo. Estas pruebas
realizadas deben quedar registradas en el documento
Resultado de ejecucin del aplicativo final.
Anlisis de issues:
En esta actividad se analizan, describen y miden todos los
issues detectados. El reporte de medida de un issue est
dado por tres factores:
Densidad del issue: Muestra el nmero de issues en una
categorizacin dada, ejemplo, por prioridad, severidad,
mdulos.
Antigedad del issue: Los reportes de antigedad del issue
demuestran cunto tiempo un issue se ha encontrado en un
estado particular, por ejemplo, cunto tiempo se ha
encontrado en el estado abierto sin que se le haya tratado.
Tendencia del issue: Muestra el nmero de issues en una
categora dada sobre un periodo de tiempo, por ejemplo,
nmero de issues abiertos en 6 semanas.
Creacin del resumen de pruebas:
El resumen de pruebas es un reporte objetivo de todo el
proceso de pruebas funcionales de un proyecto determinado,
Analista de Pruebas en l se consignan:
Los resultados de pruebas
Las medidas de la pruebas
Los reportes de medidas
Recomendaciones o acciones sugeridas
59
Seguimiento del cronograma de actividades: Se verifica que
se hayan cumplido con los tiempos y la ejecucin de las
actividades.
VERIFICAR
Comit de cambios. Revisar el resumen de pruebas: verificar que el resumen de
pruebas esta correcto y cumple con los objetivos.
ACTUAR
Analista de Realizar las correcciones necesarias al documento resumen
Pruebas. de pruebas.
7.1.4.7 Salidas.
60
7.1.4.8 Documentos y Recursos Asociados.
Al recolectar todos los datos estadsticos (mtricas de calidad) del proceso de pruebas
funcionales y haber generado el resumen de pruebas, se puede decir que se ha
completado en un 100%.
61
7.1.4.10.4 Resumen de Pruebas sobre Componentes y Aplicativo Final.
Resumen general con los resultados del proceso de pruebas sobre los componentes y
el aplicativo final.
Carta de certificacin donde se dice que las pruebas se realizaron y la aplicacin est
libre de issues.
62
7.2.3 Diseador de Pruebas.
Este rol es responsable de ejecutar las actividades bsicas para las pruebas, las
cuales involucran las pruebas correspondientes e informes de stas.
63
7.3.1 Flujo de los Estados de los Issues
Pendiente: El issue queda en estado pendiente cuando hace falta algn tipo
de informacin o recurso para su correccin. De este estado, solo puede
regresar el estado asignado.
64
Funciona como se Dise: Cuando la explicacin del desarrollador para la no
solucin del issue reportado es que la funcionalidad evaluada no tiene
precisamente un error sino que por el contrario funciona as debido a factores
externos como por ejemplo el ambiente de pruebas que no refleja exactamente
el ambiente de produccin entonces se dice que el issue funciona como se
dise. Luego, se informa en el comit de cambios que el issue no fue
solucionado debido a la razn descrita.
65
Prioridad del Issue.
Prioridad: Rapidez con que se necesita resuelto un reporte.
Alto: El issue debe de ser resuelto tan pronto como sea posible porque es
imperativo para las actividades de pruebas. El issue no detiene la prueba, pero
sta es severamente afectada hasta que el issue sea arreglado.
El objetivo del informe de incidentes es documentar cada incidente (por ejemplo, una
interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.)
ocurrido en la prueba y que requiera una posterior investigacin.
Este procedimiento propuesto para realizar pruebas de software contiene una plantilla
de Informe de Incidentes.
Identificador.
Resumen del incidente.
Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados,
etc).
Impacto que tendr sobre las pruebas.
66
7.5 Buenas Prcticas de Pruebas Exitosas.
En general, es una buena prctica contar con el manual de uso del aplicativo a
probar, y en este caso, para pruebas de software basado en componentes
sera an mejor si se puede contar con el manual de uso propio de cada
componente usado durante el desarrollo del aplicativo, de este modo se puede
obtener una idea ms concreta de las funcionalidades clave del aplicativo
La experiencia parece indicar que donde hay un issue hay otros, es decir, la
probabilidad de descubrir nuevos issues en una parte del software es
proporcional al nmero de issues ya descubierto.
67
Nunca pensar que una funcionalidad es muy obvia para ser probada. Las
mejores pruebas realizadas sobre un aplicativo son aquellas que evalan
incluso las funcionalidades ms obvias y no suponen ni asumen ningn
resultado antes de ser realizadas.
No se puede ser confiado del aplicativo, por qu por muy remoto que parezca,
esa funcionalidad que pensamos que no debe fallar y por tanto no le prestamos
la suficiente atencin a las pruebas que le realizaremos puede presentar
resultados inesperados, ninguna funcionalidad est exenta de este tipo de
sucesos.
68
8. GLOSARIO DE TRMINOS.
Stakeholders: Son todas las personas que pueden afectar o verse afectadas
por las actividades realizadas durante el proceso.
Deck de Pruebas: Son las pruebas unitarias que realiza el desarrollador sobre
su aplicativo desarrollado con el fin de ilustrar el bsico funcionamiento de este,
69
ayudando de este modo al analista de pruebas a entender de una mejor
manera la funcionalidad principal del aplicativo en s, y elaborar a partir de all
el resto de casos de prueba.
70
9. CONCLUSIONES.
Por ltimo, los mtodos ms usados de desarrollo son aquellos que cuentan
con una metodologa ya establecida para todas sus etapas del ciclo de
desarrollo, incluyendo la metodologa de testing a lo largo de dicho ciclo. Por
tanto, es de esperarse que el desarrollo de software basado en componentes
que an sigue siendo un mtodo relativamente nuevo de desarrollo de
aplicativos siga tomando cada vez ms fuerza entre el gremio desarrollador ya
que al tener una metodologa de testing, como la propuesta en este proyecto,
71
que se adapte exactamente al ciclo de desarrollo de este mtodo dar un
nuevo impulso a la expansin de este mtodo.
72
10. BIBLIOGRAFA.
The Complete Guide to Software Testing - Second Edition, Hetzel, B., QED
Information Sciences Inc, Massachusetts, 1988.
73
Software Testing Best Practices. Ram Chillarege. Center for Software Engineering.
IBM Research.
74
11. ANEXOS.
75
Caractersticas de Calidad en Componentes
En general, no existe un consenso a la hora de definir y clasificar las caractersticas de
calidad que debe presentar un producto software. Por tanto, utilizaremos los
estndares internacionales, fundamentalmente el ISO-9126. Aunque actualmente en
proceso de revisin, ha sido el primero en definir y concretar este tipo de
caractersticas.
Siguiendo su terminologa, entendemos por caracterstica de calidad de un producto
software a un conjunto de propiedades mediante las cuales se evala y describe su
calidad. Una caracterstica se puede refinar en mltiples niveles de sub-caractersticas.
Ejemplos de caractersticas son la funcionalidad, la fiabilidad o la facilidad de uso. A su
vez, la caracterstica funcionalidad se puede descomponer en sub-caractersticas
como correccin, interoperatividad y seguridad, entre otras.
Llamaremos atributo a una propiedad de calidad a la que puede asignrsele una
mtrica, entendiendo por mtrica un procedimiento que examina un componente y
produce un dato simple, un smbolo (p.e. Excelente, S, No) o un nmero. Hay que
tener en cuenta que no todas las propiedades son medibles (p.e. la demostrabilidad).
Con todo esto, un modelo de calidad se define como un conjunto de caractersticas y
sub-caractersticas, junto con las relaciones que existen entre ellas. Por supuesto, el
modelo de calidad a utilizar va a depender del tipo de producto a probar. En este
sentido, los estndares y propuestas existentes definen modelos de calidad generales,
vlidos para grandes familias de productos. Sin embargo, su alto grado de
generalizacin y abstraccin hacen difcil su aplicacin a temas concretos. Tambin,
es importante tratar de refinar esos modelos generales, particularizndolos a casos
concretos. Por ello, resultara de gran inters y utilidad poder contar con un modelo de
calidad particularizado para componentes. Desde nuestro punto de vista, dicho modelo
de calidad ha de ser simple y concreto si queremos que pueda ser utilizado con ciertas
garantas de xito.
Uno de los principales objetivos de tal modelo de calidad para componentes es el de
detectar los atributos que pueden describir los proveedores (externos o internos) de
componentes COTS (Commercial-Off-The-Shelf) en la informacin que suministran
acerca de los mismos y que, por tanto, permitiran facilitar su valoracin y seleccin
por parte de los diseadores y desarrolladores de productos software.
76
Clasificacin de los atributos de calidad
Para los componentes, y teniendo en cuenta como posible objetivo la definicin de un
modelo de calidad especfico, es fundamental primero realizar una taxonoma, tratando
de clasificar las caractersticas de calidad de acuerdo a su naturaleza y a distintos
parmetros que intervienen en su medida. Se pueden realizar distintos tipos de
clasificaciones.
77
puedan tener efectos sobre la arquitectura final. As, por ejemplo, el tamao de un
componente puede ser importante a la hora de tener en cuenta los requisitos de
espacio de la aplicacin.
78
Anexo 2 Articulo: Pruebas de Software.
Por: CETIC - Comit Estatal de Tecnologas de Informacin y Comunicaciones de
Mxico.
PRUEBAS DE SOFTWARE
La prueba del software es un elemento crtico para la garanta de la calidad del
software. El objetivo de la etapa de pruebas es garantizar la calidad del producto
desarrollado. Adems, esta etapa implica:
La prueba es un proceso que se enfoca sobre la lgica interna del software y las
funciones externas. La prueba es un proceso de ejecucin de un programa con la
intencin de descubrir un error. Un buen caso de prueba es aquel que tiene alta
probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene
xito si descubre un error no detectado hasta entonces.
79
Durante las etapas iniciales del proceso, el desarrollador realiza todas las pruebas. Sin
embargo, a medida que avanza este proceso se irn incorporando especialistas en
pruebas.
Las pruebas de caja negra son las que se aplican a la interfaz del software. Una
prueba de este tipo examina algn aspecto funcional de un sistema que tiene poca
relacin con la estructura interna del software. La prueba de caja blanca del software
se basa en un examen cercano al detalle procedimental. Se prueban rutas lgicas del
software y la colaboracin entre componentes, al proporcionar casos de prueba que
ejerciten conjuntos especficos de condiciones, bucles o ambos.
80
La prueba de la caja negra intenta encontrar errores de las siguientes categoras:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores de rendimiento.
Errores de inicializacin y de terminacin.
Una estrategia de prueba del software integra los mtodos de diseo de caso de
pruebas del software en una serie bien planeada de pasos que desembocar en la
eficaz construccin del software. La estrategia proporciona un mapa que describe los
pasos que se darn como parte de la prueba, indica cundo se planean y cundo se
dan estos pasos, adems de cunto esfuerzo,
tiempo y recursos consumirn. Por tanto, en cualquier estrategia de prueba debe
incorporar la planeacin de pruebas, el diseo de casos de pruebas, la ejecucin de
pruebas y la recoleccin y evaluacin de los datos resultantes.
Una estrategia de prueba del software debe ser lo suficientemente flexible como para
promover un enfoque personalizado. Al mismo tiempo, debe ser lo adecuadamente
rgido como para promover una planeacin razonable y un seguimiento administrativo
del avance del proyecto. Si se considera el proceso desde un punto de vista
procedimental, la prueba consiste en una serie de pasos que implementan de manera
secuencial. Estos pasos se describen a continuacin:
Pruebas de unidad:
81
descubrir errores dentro del mbito del mdulo. La prueba de unidad hace uso
intensivo de las tcnicas de prueba de caja blanca.
Prueba de integracin:
82
aplicaciones de cliente para asegurar que los datos se almacenan, actualizan y
recuperan apropiadamente. Tambin se prueba la funcin de archivado.
Pruebas de transaccin: se crea una serie de pruebas para asegurar que cada
clase de transacciones se procesa de acuerdo con sus requisitos. Las pruebas
se concentran en determinar si es correcto el procesamiento y en aspectos de
desempeo.
Pruebas de comunicaciones de red: con estas pruebas se verifica que la
comunicacin entre los nodos de la red ocurre de manera correcta y que el
paso de mensajes, transacciones y el trfico de la red relacionado se realiza
sin errores. Tambin es posible realizar pruebas de seguridad de la red como
parte de estas pruebas.
83
Pruebas de regresin:
Las pruebas de regresin son una estrategia de prueba en la cual las pruebas que se
han ejecutado anteriormente se vuelven a realizar en la nueva versin modificada,
para asegurar la calidad despus de aadir la nueva funcionalidad. El propsito de
estas pruebas es asegurar que:
84