You are on page 1of 118

CIS1430IS08

V2Soft: guía metodológica para


el proceso de validación y
verificación de requerimientos
para el usuario final

Guía
Metodológica
Trabajo de grado – Ingeniería
de Sistemas
Pontificia Universidad
Javeriana.
2015

María Ximena Narváez Barrera

0
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

CIS1430IS08
V2SOFT: GUÍA METODOLÓGICA PARA EL PROCESO DE VALIDACIÓN Y
VERIFICACIÓN DE REQUERIMIENTOS PARA EL USUARIO FINAL

MARÍA XIMENA NARVÁEZ BARRERA

PONTIFICIA UNIVERSIDAD JAVERIANA


FACULTAD DE INGENIERIA
CARRERA DE INGENIERIA DE SISTEMAS
BOGOTÁ, D.C.
2015

1
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Contenido
1 Aspectos generales........................................................................................................................... 8
1.1 Objetivo de la guía..................................................................................................................... 8
1.2 Alcance de la guía ...................................................................................................................... 8
1.3 A quien va dirigida la guía ......................................................................................................... 8
1.4 Uso recomendado ..................................................................................................................... 9
1.5 Supuestos y restricciones de la guía......................................................................................... 9
1.5.1 Supuestos: .......................................................................................................................... 9
1.5.2 Restricciones: ..................................................................................................................... 9
2 Marco de referencia ....................................................................................................................... 10
2.1 Tercerización del desarrollo .................................................................................................... 10
2.2 Ventajas y desventajas de tercerizar....................................................................................... 11
2.2.1 Ventajas ............................................................................................................................ 11
2.2.2 Desventajas ...................................................................................................................... 12
3 Marco teórico ................................................................................................................................. 13
3.1 Validación y Verificación de requerimientos .......................................................................... 13
3.1.1 Objetivo de la Validación y Verificación ........................................................................... 14
3.2 Pruebas de Software ............................................................................................................... 14
3.2.1 Conceptos ......................................................................................................................... 14
3.2.2 ¿Porque las pruebas son necesarias?............................................................................... 16
3.2.3 Pruebas a realizar ............................................................................................................. 17
3.2.4 Objetivos de quien realiza pruebas. ................................................................................. 17
3.2.5 Principios de las pruebas .................................................................................................. 17
3.2.6 Características de las pruebas .......................................................................................... 20
3.3 Niveles de pruebas .................................................................................................................. 20
3.3.1 Niveles de pruebas ........................................................................................................... 21
3.4 Tipos de pruebas .................................................................................................................... 26
3.4.1 Pruebas de funciones o pruebas funcionales................................................................... 26
3.4.2 Pruebas asociadas a cambios ........................................................................................... 26
3.5 Casos de pruebas .................................................................................................................... 27
3.5.1 ¿Qué es un caso de prueba? ............................................................................................ 27
3.5.2 Características y beneficios de un caso de prueba ......................................................... 27

2
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.5.3 Elementos de un caso de prueba ..................................................................................... 29


3.6 Técnicas de pruebas ................................................................................................................ 29
3.6.1 Basada en la especificación (Caja negra) ......................................................................... 30
3.7 Basadas en la experiencia ....................................................................................................... 39
3.7.1 Predicción de error ........................................................................................................... 39
3.7.2 Pruebas Exploratorias ...................................................................................................... 39
4 Guía Metodológica V2Soft ............................................................................................................. 41
4.1 Proceso de pruebas para la Validación y Verificación de requerimientos .............................. 41
4.1.1 Componentes proceso ..................................................................................................... 41
4.1.2 Equipo de pruebas y roles ................................................................................................ 45
4.1.3 Proceso de pruebas de acuerdo al ISTQB ........................................................................ 48
4.1.4 Actividades de proceso de pruebas en el modelo en V ................................................... 48
4.2 Actividades procesos de pruebas para la Validación y Verificación de requerimientos......... 51
4.2.1 Planeación ........................................................................................................................ 51
4.2.2 Herramientas para la planeación ..................................................................................... 54
4.2.3 Análisis.............................................................................................................................. 68
4.2.4 Herramientas para el análisis ........................................................................................... 69
4.2.5 Diseño............................................................................................................................... 70
4.2.6 Herramientas para el diseño ............................................................................................ 73
4.2.7 Control .............................................................................................................................. 79
4.2.8 Herramientas para la actividad de control....................................................................... 83
4.2.9 Implementación y ejecución ............................................................................................ 94
4.2.10 Herramientas para las actividades de Implementación y ejecución.............................. 95
4.2.11 Evaluación de criterios de salida e informes ................................................................ 109
4.2.12 Actividades de cierre .................................................................................................... 111
5 Referencias y Bibliografía ............................................................................................................. 114
6 Anexos .......................................................................................................................................... 117
6.1 Plantilla plan de pruebas ....................................................................................................... 117
6.2 Plantilla documento gestión de riesgos ................................................................................ 117
6.3 Plantilla documento casos de pruebas ................................................................................. 117
6.4 Plantilla para la ejecución de casos de pruebas. ................................................................... 117
6.5 Plantilla para el informe de avance de pruebas. ................................................................... 117
6.6 Documento marco de referencia – Way Of. ......................................................................... 117

3
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Índice de ilustraciones
Ilustración 1. Alcance de la guía .......................................................................................................... 8
Ilustración 2. Actividades Empresa ................................................................................................... 10
Ilustración 3.Relación Error, defecto, falla ........................................................................................ 16
Ilustración 4.Pruebas de regresión en, tomado de [26] .................................................................. 25
Ilustración 5. Pruebas funcionales .................................................................................................... 26
Ilustración 6. Depuración de defectos, tomado de [24] ................................................................... 27
Ilustración 7.Casos de pruebas, adaptado de [31] ............................................................................ 29
Ilustración 8. Técnicas de pruebas, adaptado de [15] , [28], [21] ..................................................... 30
Ilustración 9.Técnica de caja negra ................................................................................................... 31
Ilustración 10. Partición de equivalencia, tomado de [27] ............................................................... 31
Ilustración 11. Valores de entrada partición de equivalencia .......................................................... 31
Ilustración 12. Análisis de valores limites, adaptado de [27] ............................................................ 32
Ilustración 13. Análisis valor frontera ............................................................................................... 33
Ilustración 14.Función grafo de causa – efecto, tomado de [27] ..................................................... 35
Ilustración 15. Diagramas posibles de causa – efecto, tomado de [15]............................................ 35
Ilustración 16. Transición de estados ................................................................................................ 36
Ilustración 17. Transición de estados, adaptado de [28] .................................................................. 36
Ilustración 18. Pruebas exploratorias................................................................................................ 40
Ilustración 19. Áreas de empresa ...................................................................................................... 44
Ilustración 20. Roles y trabajo en equipo .......................................................................................... 45
Ilustración 21. Proceso de pruebas, adaptado de [37] ..................................................................... 48
Ilustración 22. Actividades modelo en V de acuerdo al proceso ISTQB, adaptado de [21] .............. 49
Ilustración 23. Proceso de pruebas, adaptado del modelo en V ...................................................... 50
Ilustración 24. Subproceso pruebas ................................................................................................. 50
Ilustración 25. Niveles del proceso de pruebas ................................................................................ 51
Ilustración 26. Entradas y salidas de planeación............................................................................... 53
Ilustración 27. Consideraciones y recomendaciones planeación ..................................................... 53
Ilustración 28. Plantilla SVVP............................................................................................................. 56
Ilustración 29. Proceso de estimación. ............................................................................................. 58
Ilustración 30. Entradas externas, tomada de [39] ........................................................................... 62
Ilustración 31. Salidas externas, tomada de [39] .............................................................................. 63
Ilustración 32. Puntos de función, tomado de [40] ......................................................................... 67
Ilustración 33. Condición de prueba, tomado de [8], [20] ................................................................ 69
Ilustración 34. Entradas y salidas de la actividad diseño .................................................................. 72
Ilustración 35. Consideraciones y recomendaciones diseño ............................................................ 72
Ilustración 36. Proceso Diseño .......................................................................................................... 73
Ilustración 37. Consideraciones Proceso de diseño .......................................................................... 74
Ilustración 38. Plantilla de documento de casos de pruebas ............................................................ 79
Ilustración 39. Subproceso control, adaptado de [37] ...................................................................... 81
Ilustración 40. Recomendaciones y consideraciones para el control ............................................... 82
Ilustración 41. Tipo de riesgos del proyecto ..................................................................................... 83

4
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 42. Matriz de riesgos ....................................................................................................... 85


Ilustración 43. Plantilla documento gestión de riesgos .................................................................... 87
Ilustración 44. Proceso de métricas, basado en [48] ........................................................................ 88
Ilustración 45. Métricas de calidad del Software [34] ...................................................................... 89
Ilustración 46. Calidad Externa e Interna, [34], [48], [50] ................................................................. 90
Ilustración 47. Consideraciones y recomendaciones implementación y ejecución .......................... 95
Ilustración 48. Ejecución de casos de prueba ................................................................................. 100
Ilustración 49. Plantilla ejecución de casos de prueba ................................................................... 101
Ilustración 50. Flujo de estado de los defectos ............................................................................... 104
Ilustración 51. Plantilla informe de avance de pruebas .................................................................. 108
Ilustración 52. Evaluación de criterios de salida e informes ........................................................... 110
Ilustración 53. Recomendaciones evaluación de criterios de salida e informes ............................ 111
Ilustración 54. Actividad de cierre................................................................................................... 112
Ilustración 55. Recomendaciones actividades de cierre ................................................................. 113

5
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Índice de Tablas
Tabla 1. Desventajas Outsourcing ..................................................................................................... 12
Tabla 2. Pruebas unitarias ................................................................................................................. 21
Tabla 3. Pruebas de integración ........................................................................................................ 22
Tabla 4. Pruebas de sistema .............................................................................................................. 23
Tabla 5. Pruebas de aceptación ........................................................................................................ 24
Tabla 6. Pruebas de regresión ........................................................................................................... 25
Tabla 7. Tablas de decisión................................................................................................................ 34
Tabla 8. Ejemplo tabla de decisión.................................................................................................... 34
Tabla 9. Transición de estados por eventos, adaptado de [28] ........................................................ 37
Tabla 10. Transición de estados por transición, adaptado de [27] ................................................... 37
Tabla 11. Descripción caso de uso, adaptado de [28],[27] ............................................................... 39
Tabla 12. Componentes proceso de Validación y Verificación de requerimientos .......................... 44
Tabla 13. Rol líder de pruebas ........................................................................................................... 47
Tabla 14. Rol analista de pruebas ..................................................................................................... 47
Tabla 15. Rol ejecutor de pruebas .................................................................................................... 48
Tabla 16. Descripción actividad Planeación ...................................................................................... 52
Tabla 17. Cantidad defectos por iteración ........................................................................................ 58
Tabla 18. Descripción de actividades del proceso de estimación ..................................................... 59
Tabla 19. Técnicas de estimación, basada en [27] ............................................................................ 62
Tabla 20. Clasificación EI, tomada de [39]........................................................................................ 64
Tabla 21. Clasificación EO y EQ, tomada de [39]............................................................................... 64
Tabla 22. Clasificación ILF y EIF, tomada de [39]............................................................................... 64
Tabla 23. Valores de transacciones por clasificación, tomada de [39] ............................................. 64
Tabla 24. Valores de por clasificación, Tomada de [39] .................................................................... 65
Tabla 25. Calculo de punto de función, tomado de [39]................................................................... 65
Tabla 26. Complejidad el factor, tomada de [39].............................................................................. 66
Tabla 27. Factores puntos de función para pruebas, adaptado de [38] ........................................... 66
Tabla 28. Punto de función y defectos, tomado de [45] ................................................................... 68
Tabla 29. Descripción actividad Análisis............................................................................................ 69
Tabla 30. Lista de condiciones de pruebas........................................................................................ 70
Tabla 31. Matriz de trazabilidad........................................................................................................ 70
Tabla 32. Descripción actividad diseño ............................................................................................. 71
Tabla 33. Descripción de actividades del proceso de diseño ............................................................ 74
Tabla 34. Plantilla Escenarios ............................................................................................................ 75
Tabla 35. Plantilla Eventos ................................................................................................................ 75
Tabla 36. Plantilla casos de prueba ................................................................................................... 76
Tabla 37. Ejemplo caso de prueba matricula estudiante .................................................................. 77
Tabla 38. Matriz de trazabilidad de las pruebas ............................................................................... 78
Tabla 39. Descripción actividad Control ............................................................................................ 80
Tabla 40. Descripción actividades del subproceso control ............................................................... 82
Tabla 41. Nivel de probabilidad de los riesgos, tomada de [46] ....................................................... 84
Tabla 42. Nivel de impacto del riesgo en el proyecto, tomada de [46] ............................................ 84
Tabla 43. Tabla de riesgos ................................................................................................................. 85

6
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Tabla 44. Métricas proyecto, tomado de [34], [48] .......................................................................... 93


Tabla 45. Descripción de actividades Implementación y ejecución. ................................................. 94
Tabla 46. Priorización Casos de Prueba ............................................................................................ 97
Tabla 47. Atributos priorización, basado en [52] .............................................................................. 97
Tabla 48. Plantilla para ejecución de casos de prueba ..................................................................... 99
Tabla 49. Categoría de los defectos, basado en [53] ...................................................................... 102
Tabla 50. Severidad de los defectos, basada en [53] ...................................................................... 103
Tabla 51. Prioridad de los defectos ................................................................................................. 103
Tabla 52. Estado de los defectos ..................................................................................................... 104
Tabla 53. Plantilla para reportar defectos....................................................................................... 105
Tabla 54. Información actividad Evaluación de criterios de salida e informes ............................... 109
Tabla 55. Definición actividad cierre de pruebas ............................................................................ 111

7
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

1 Aspectos generales

1.1 Objetivo de la guía


La guía metodología busca ser un apoyo para el proceso de Validación y Verificación de
requerimientos funcionales de software para el usuario final, bajo las características de las
empresas que no desarrollan software, por lo tanto busca:

 Brindar una alternativa de mejora para el proceso de Validación y Verificación de


requerimientos.
 Fortalecer el proceso de Validación y Verificación de requerimientos.
 Dar claridad al proceso de Validación y Verificación de requerimientos.
 Reducir riesgos referentes al proceso de Validación y Verificación de requerimientos.
 Presentar la importancia del proceso de Validación y Verificación de requerimientos.

1.2 Alcance de la guía


La guía va dirigida a empresas que realizan la Validación y Verificación de requerimientos y no
desarrollan software, lo que significa que el alcance de la guía se encuentra en el marco de las
pruebas dinámicas de software y no contempla las pruebas basadas en la estructura debido que
las empresas no conoce el código del sistema. En la Ilustración 1 se presenta el alcance de la guía
en cuanto a las técnicas consideradas.

Basado en
especificación
Validación y Pruebas
Verificación Dinámicas
Basado en la
experiencia

Ilustración 1. Alcance de la guía

Esta guía, es fácilmente adaptable a todos los ciclos de vida del software, para efectos prácticos se
aplicó en el modelo en V.

1.3 A quien va dirigida la guía


La guía va dirigida principalmente a las empresas que realizan el proceso de Validación y
Verificación de requerimientos a los sistemas o programas que fueron implementados por
empresas especialistas en el desarrollo de software mediante el outsourcing. A partir de la
Validación y Verificación de requerimientos la empresa garantiza la calidad del software y
constata el cumplimiento de los objetivos del sistema y los requerimientos.

8
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Pero también, la guía va dirigida a estudiantes, profesores y personas interesadas en la


Validación y Verificación de requerimientos que buscan mejorar y conocer del proceso.

1.4 Uso recomendado


De acuerdo al ámbito en el que se desarrolla la guía, se recomienda que sea implementada a nivel
organizacional bajo el esquema de la empresa a quien va dirigida la guía. Pero se considera que la
guía puede tenerse en cuenta en el ámbito académico con el fin de profundizar sobre la
Validación y Verificación de requerimientos y concientizar a los estudiantes sobre la importancia
del proceso.

1.5 Supuestos y restricciones de la guía


La guía metodológica debe iniciar su aplicación, cuando se cuenta con los requerimientos
definidos y sin ambigüedades, para que exista un involucramiento temprano por parte del equipo
de pruebas, para que conozcan el sistema, y se realice de manera anticipada la actividad de
planeación del proceso, debido que no requiere la ejecución del software, permitiendo que estén
preparados para el inicio de las pruebas cuando el sistema esté listo.

1.5.1 Supuestos:
• Se cuenta con la información necesaria para la creación de los casos de prueba.
• Los documentos entregados para el proceso no presentan inconsistencias y son
completos.
• Las pruebas basadas en la estructura son ejecutadas por el equipo responsable de la
empresa que realiza el desarrollo y las realizan antes de entregar el sistema.

1.5.2 Restricciones:
• La guía no se debe aplicar, cuando se realizan pruebas técnicas o pruebas no funcionales,
por lo que deben estar a cargo de expertos junto a herramientas que permitan su
ejecución. Las pruebas identificadas, con las que no se debe usar la guía son:
o Recuperación
o Seguridad
o Resistencia
o Desempeño
o Rendimiento
o Carga
o Stress
o Portabilidad
o Fiabilidad
o Mantenibilidad
o Usabilidad

9
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

2 Marco de referencia

2.1 Tercerización del desarrollo


Por estrategia, necesidades, competencia y oportunidades, las empresas requieren crear nuevos
productos o servicios y realizar mejoras a los existentes, para ofrecerlos a sus clientes tanto
externos como internos y así optimizar procesos que van acorde a su negocio.
En Colombia y en diferentes partes del mundo, existe la tendencia de tercerizar el desarrollo de
software en empresas especialistas en esta labor mediante el outsourcing, para cubrir sus
necesidades y productos de software, debido que este proceso no hace parte de su modelo de
negocio y de esta manera se orientan en cumplir sus propios objetivos y metas, como lo menciono
Fernando Basto en portafolio [1], respecto al outsourcing “Así podemos enfocarnos a producir,
porque de lo contrario tendría que asumir desarrollos que no podría soportar con personal de
dedicación exclusiva y que aumenta la carga prestacional” y para responder con mayor rapidez a
un mercado cada vez más exigente y competitivo “En esas condiciones, todas las empresas
necesitan servicios especializados, porque ninguna organización puede hacer de todo con buena
rentabilidad.”[1]
A grandes rasgos, para poder cumplir con el objetivo de tercerizar el desarrollo de software, la
empresa interesada realiza la definición y especificación de los requerimientos necesarios para el
producto, entrega la información a la empresa subcontratada para que ella realice la
implementación, quedando así a la espera de ver estos requerimientos en una aplicación funcional
dentro de los tiempos previstos.
Una vez que se cumple con el proceso de desarrollo y se recibe el producto, existen empresas
como por ejemplo del sector financiero, del sector bancario, empresas de seguridad o de
telecomunicaciones, que realizan una fase adicional para asegurar la calidad del producto, antes
de ponerlo a disposición de los usuarios finales. Realizan la Validación y Verificación de los
requerimientos en el software, este proceso, permite evaluar la completitud, consistencia y
comportamiento del producto, para así tener la garantía que se cumplieron los requerimientos
establecidos y generar una certificación para el paso a producción.
En la Ilustración 2, se sintetizan las actividades anteriormente mencionadas, correspondientes a la
empresa que busca el outsourcing como alternativa para el desarrollo:

Define y
Terceriza Recibe
especifica
desarrollo desarrollo
Requerimientos

Instalación del
Certifica Valida y Verifica
producto en
producto Requerimientos
producción

Ilustración 2. Actividades Empresa


10
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Los encargados de realizar la validación y verificación de requerimientos en el software, en este


modelo, son Stakeholders que conocen el negocio y la operación del día a día, son conocidos como
los expertos del negocio, identifican con mayor precisión las posibles falencias, conocen el uso
esperado, la razón por la que se construyó el sistema y no necesariamente son expertos en
desarrollo, ni conocen del proceso de construcción de software.

Dentro de las ventajas de este modelo se encuentra que:

• Los Stakeholders que validan y verifican requerimientos en el software, identifican más y


diferentes defectos y son objetivos respecto a los encargados de validar y verificar
requerimientos en el desarrollo. [2]
• Los Stakeholders que validan y verifican requerimientos en el software, pueden
comprobar los supuestos planteados durante las fases de especificación e implementación
del sistema. [2]

Por otro lado, la empresa encargada del outsourcing, cumple con lo definido en el documento de
requerimientos, pero no es posible que garanticen al ciento por ciento que el sistema realiza lo
que cliente realmente espera, es el usuario o Stakeholder el que evalúa dicho cumplimiento.

2.2 Ventajas y desventajas de tercerizar


Es importante conocer los beneficios que trae consigo la tercerización del proceso de desarrollo de
software, para la empresa que utiliza el servicio. En esta sección se incluyen las ventajas de
tercerizar el desarrollo y las desventajas que se presentan.

2.2.1 Ventajas
 El proveedor, es experto en el área donde desarrolla su trabajo. [3]
 El proveedor, conoce mejor las tecnologías aplicables al área de su servicio.[3]
 El proveedor, tiene un mejor enfoque y visión para el cubrimiento de las necesidades del
cliente.[3]
 El proveedor, tiene acceso a servicios especializados para dar mejor atención a los clientes
[3]
 Las tareas de reingeniería empresarial, se tornan más factibles. [3]
 Los riesgos empresariales se distribuyen [3]
 El outsourcing puede ayudarle a optimizar los procesos de negocio a la empresa que lo
contrata. [4]
 “Permite que la organización se dedique exclusivamente a desarrollar las funciones
medulares de su negocio, es decir, que la organización fije todos sus recursos y esfuerzos
en el desarrollo de sus competencias esenciales, enfocando los recursos y esfuerzos en las
actividades principal de la organización”. [5]

11
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

2.2.2 Desventajas
Las desventajas identificadas en el proceso de tercerización del desarrollo de software se
clasificaron en la Tabla 1, se presenta las implicaciones que trae al proceso de Validación y
verificación de requerimientos, tomados de [4] y [6].

Desventaja Implicación en proceso V&V (el autor)


Es necesario que se gestione la empresa Obliga a la empresa a estar pendiente de la
tercera que es responsable de las tareas empresa tercera para garantizar el cumplimento
de desarrollo. [4] de las entregas esperadas.
Existe el riesgo que la empresa de
Se puede presentar retrasos en los proyectos que
outsourcing se declare en quiebra o pase
dependen directamente del desarrollo.
por dificultades importantes. [4]
Implica que los desarrollos o solución a los
La empresa tercera, atiende a otros defectos encontrados en el proceso de validación
clientes, o la empresa que subcontrata no y verificación de requerimientos no se den en los
es atendida con la dedicación necesaria.[4] tiempos esperados, generando retraso en los
objetivos de la empresa.
La comunicación no es la esperada, debido
Los desarrollos no cumplen con la funcionalidad
que no se expresan inquietudes, dudas o
esperada, debido que la empresa supone muchas
preguntas, que se pueden presentar a lo
de las respuestas.
largo del desarrollo del proyecto. [4]
Se dependerá de los tiempos de respuesta para
Dependencia con el proveedor del
solucionar los problemas, o defectos encontrados
servicio.[4],[6]
en el proceso.
Puede perderse el control sobre el Surge, la necesidad de la validación y verificación
producto final y verse afectada la calidad. de los requerimientos para el usuario final.
[4],[6]
Al tercerizar el desarrollo es la empresa tercera
Se puede afectar la confidencialidad de los quien materializara la idea, por lo tanto los
productos nuevos y novedosos. [4], [6] servicios y productos novedosos dependerán de la
confidencialidad que se establezca.[3]
Tabla 1. Desventajas Outsourcing

12
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3 Marco teórico

3.1 Validación y Verificación de requerimientos


El proceso de Validación y Verificación de los requerimientos, busca garantizar que los
requerimientos que se especificaron se cumplan en todo el proceso del desarrollo de software, tal
como se define en Sommerville, “La verificación y la validación (V & V) es el nombre dado a estos
procesos de análisis y pruebas. La verificación y validación tienen lugar en cada etapa del proceso
de software. V & V comienza con revisiones de los requerimientos y continua con revisiones del
diseño e inspecciones de código hasta la prueba del producto” [7], este proceso permite
comprobar que de los requerimientos desarrollados se encuentran conforme a los
requerimientos que se especificaron y cumplen un propósito. El International Software Testing
Qualifications Board define la verificación como la "Confirmación mediante examen y mediante el
suministro de evidencia objetiva que la especificación de los requisitos se han cumplido."[8] y la
validación es la "Confirmación mediante examen y mediante el suministro de evidencia objetiva de
que se han cumplido los requisitos para un uso específico previsto o aplicación."[8].

Es importante diferenciar la validación y la verificación de requerimientos ya que no son lo mismo


y a menudo estos dos términos se confunden entre sí debido que las definiciones no presentan de
manera clara la diferencia. Boehm en [7], [9], definió de la siguiente manera:

 “Validación: ¿Estamos construyendo el producto correcto?”


 “Verificación: ¿Estamos construyendo el producto correctamente?”

Lo que significa que con el proceso de verificación se busca detectar o corregir errores que
desvían del resultado esperado acorde a los requerimientos definidos, que el software cumple
con los requerimientos funcionales y no funcionales [7]; mientras que con el proceso de validación
se busca detectar o corregir los errores que desvían los requerimientos, necesidades y
expectativas del cliente [7]. Con la verificación se evidencia si el software se cumple con lo
especificado, mientras que con la validación se evidencia si realmente el software hace lo que
debe realizar.

El estándar internacional ISO/IEC 12207 [10] define que “El propósito de la Verificación del
software es confirmar que cada producto, servicio o proyecto, refleja adecuadamente los
requerimientos especificados” y “El propósito del proceso de Validación es confirmar que se
cumplen con los requerimientos para un uso específico y cumple con lo previsto del producto de
software”.

Como resultado esperado de la implementación del proceso de Verificación y Validación se tiene,


de acuerdo a [10]:

1. Una estrategia para la Verificación y Validación desarrollada e implementada.


2. Criterios de Verificación y Validación son necesarios y requeridos son identificados.
3. Ejecución de actividades de Verificación y Validación.
4. Defectos y problemas son identificados y registrados.

13
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

5. El resultado del proceso se define que el software o producto es apto y se pone a


disposición del cliente y partes interesadas.

3.1.1 Objetivo de la Validación y Verificación


El proceso de Validación y Verificación de requerimientos permite realizar una evaluación objetiva
de los productos de software durante su ciclo de vida, permitiendo así:

• Determinar si el software cumple el propósito por el que fue creado.[11]


• Garantizar que el sistema es lo suficientemente bueno para su uso pretendido. [11]
• El nivel de confianza requerido depende del propósito del sistema, las expectativas de los
usuarios del sistema y el entorno de mercado actual del sistema.[11]

Entre los beneficios del proceso:

• Facilitar la detección temprana y la corrección de las anomalías [12]


• Asegurar los requerimientos del usuario.[11]
• Remover los defectos del producto fuera del ciclo de vida del proyecto, reduciendo el
volver a trabajar sobre el mismo aspecto, y reduciendo los costos por la baja calidad. [11]
• Asegurar que las necesidades de los usuarios son comprendidas y asegurar que los
productos satisfagan el entorno previsto para el que fueron desarrollados. [11]
• Mejorar la calidad de los procesos y los productos. [11], [12]
• Mejorar la comprensión de la gestión de riesgos de procesos y productos.[12]
• Proporcionar evidencia objetiva de conformidad del producto para apoyar al proceso de
certificación.[12]
• Soporte a las actividades de mejora de procesos. [12]

3.2 Pruebas de Software


En esta sección se presenta la información del marco teórico recolectada y analizada sobre
pruebas de software que permite soportar los procesos de validación y verificación dinámica de
los requerimientos.

3.2.1 Conceptos
3.2.1.1 Pruebas
Las pruebas de software son un proceso que permite determinar la calidad de un producto o
sistema, validar y verificar que el software realiza las funciones esperadas y satisface el propósito
para la cual fue diseñado. A continuación se presentan distintas definiciones sobre las pruebas de
software:

 Según la definición de IEEE “Las pruebas son un proceso de analizar un elemento de


software para detectar las diferencias entre las condiciones existentes y las condiciones
necesarias, y evaluar las características de un elemento de software.” [13].
 El Swebok define “Las pruebas de software consiste en la verificación dinámica del
comportamiento de un programa sobre un conjunto finito de casos de prueba,

14
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

adecuadamente seleccionados a partir del dominio de ejecución generalmente infinito, en


relación con el comportamiento esperado”[14]
 Myers en el libro the art off software testing, define “La prueba es el proceso de ejecución
de un programa con la intención de encontrar defectos” [15], señala la importancia del
significado, debido que anteriormente se tenía el concepto errado sobre las pruebas: "El
proceso de demostrar que los errores no están presentes.", basándose en aspectos
psicológico del ser humano, “Si nuestro objetivo es demostrar que un programa no tiene
errores, entonces subconscientemente estará dirigido hacia este objetivo; es decir,
seleccionara los datos de prueba que tienen una baja probabilidad de causar el programa
falle. Por otro lado, si nuestro objetivo es demostrar que un programa tiene errores, los
datos de prueba tendrán una mayor probabilidad de encontrar errores.”[15]

3.2.1.2 Error
Entre las definiciones de la Real Academia de la lengua Española, se presenta que un error es una
“Acción desacertada o equivocada” o “Cosa hecha erradamente” [16]. La IEEE presenta varias
definiciones de lo que es un error, pero para este contexto se encuentra “acción humana que
produce un resultado incorrecto”[17], “acción humana que genera un fallo en el software. Por
ejemplo: omisión o mala interpretación de requerimientos, traducción incorrecta, o la omisión de
requerimientos en el diseño”[18].
3.2.1.3 Defecto
La IEEE define el defecto como “un problema que, si no se corrige, podría causar la falla en una
aplicación o producir resultados incorrectos.” [17], o, “Una anomalía producto”[18]. El
International Software Testing Qualifications Board (ISTQB), define un defecto como la
“Imperfección en un componente o sistema que puede causar que el componente o sistema falle
en desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos
incorrectas. Si se localiza un defecto durante una ejecución puede causar un fallo en el
componente o sistema.”[8].
En la industria del software, un defecto se produce cuando[19]:
1. El software no hace algo que la especificación dice que debe hacer.[19]
2. El software hace algo que en la especificación del producto dice que no debe hacer.[19]
3. El software hace algo que en la especificación no se menciona.[19]
4. El software no hace algo que la especificación no se menciona pero debería.[19]
5. El software es difícil de entender, difícil de usar, lento, o el probador de software con ojos
de usuario final sabe que el software no está bien.[19]
3.2.1.4 Falla
El International Software Testing Qualifications Board (ISTQB), define la falla como la “Desviación
del componente o del sistema respecto de prestación, servicio o resultado esperado”[8], la IEEE
define la falla como “La terminación de la capacidad de una unidad funcional para realizar su
función requerida. (2) Un evento en el que un sistema o componente del sistema no realiza una
función determinada dentro de los límites especificados.”[18]

15
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

En la Ilustración 3, se presenta la relación entre los términos anteriormente presentados, en


resumen se tiene que:

 Una falla es un evento.


 El defecto es un estado del software, causado por un error.
 Las pruebas buscan defecto en el software.
 Las pruebas pueden descubrir defectos y fallas, pero es el error el que se debe
solucionar.[14]

•Acción humana
Error • Genera un resultado
incorrecto

•Consecuencia del error


Defecto •Conocido como Bug en
el Software

•Consecuencia del
defecto
Falla •Desviación del
componente
•Afecta la producción

Ilustración 3.Relación Error, defecto, falla

3.2.2 ¿Porque las pruebas son necesarias?


Las pruebas de software son necesarias debido a que:

• Mide la calidad de un producto, como lo define la IEEE las pruebas brindan información
sobre las características de calidad del producto. [20]
• Permite conocer si el producto de software realiza lo que se espera que haga. [20]
• Las pruebas permiten identificar defectos.
• Las pruebas permiten verificar y validar el software de manera dinámica, para confirmar si
el software cumple con los requerimientos especificados y su propósito.
• Las pruebas aportan fiabilidad y confianza del sistema, cada vez se encuentran defectos y
estos son solucionados, la calidad del software aumenta. [2]
• Disminuye los costos de mantenimiento post – producción. [21]
• Disminuye los riesgos por incumplimiento de tareas. [21]

Un producto de software es imposible crearlo perfecto, por lo tanto, el proceso de pruebas es


obligatorio y debe realizarse de manera eficaz, para garantizar la funcionalidad esperada y el
hallazgos de defectos, para reducir la probabilidad de ocurrencia de errores en el ambiente
productivo y la materialización de los riesgos asociados. Un error en producción impacta a los
usuarios y sistemas finales, es mejor evitar problemas que solucionarlos. [20]

16
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.2.3 Pruebas a realizar


Cuando se realizan pruebas de software, se debe determinar la cantidad de pruebas que se van a
ejecutar en el sistema debido a que no es recomendable, ni viable probar todo, ver principio 2 de
la sección 3.2.5.

Para determinar la cantidad de pruebas a realizar, se recomienda tener en cuenta aspectos como:

1. Niveles de riesgo: Permite determinar por donde iniciar las pruebas, donde se debe
probar más[2]. Evaluando desde el punto de vista tecnológico, del negocio, de pruebas,
de proyecto y el impacto de la materialización del riesgo.
2. Restricciones del proyecto: por ejemplo tiempo, presupuesto y recursos.
3. Requerimientos que constituyen el software: Por ejemplo requerimientos contractuales o
legales o Requerimientos específicos.
4. Priorizar las pruebas: Asignar un grado de importancia a cada prueba dependiendo del
impacto de la funcionalidad en el negocio, permite determinar el orden de ejecución de
las pruebas y donde enfocar los esfuerzos de pruebas. Algunos criterios para la
priorización de pruebas incluyen los siguientes aspectos [2], [22]:
• Donde el fallo puede ser más severo.
• Donde el fallo puede ser más visible.
• Donde un fallo es más probable.
• Basado en las prioridades asignadas por el negocio y por los usuarios.
• Basado en la criticidad para el negocio del cliente.
• Basado en las áreas o módulos que cambian más a menudo.
• Basado en las áreas con el mayor número de problemas en el pasado.
• Basado en las áreas o módulos más complejas.
• Basado en las áreas o módulos técnicamente más vulnerables.

3.2.4 Objetivos de quien realiza pruebas.


Los objetivos de quien ejecuta las pruebas, de acuerdo a Patton [19] son:

 Encontrar defectos, no solo probar por bien, ni crear casos de prueba para que sean
exitosos. [19]
 Encontrar defectos y encontrarlos lo más pronto posible. La persona que realiza pruebas
“Son los ojos de cliente, son los primeros que ven funcionando el software, por lo tanto
habla por el cliente y debe exigir perfección”.[19]
 Encontrar errores, encontrarlos lo antes posible, y asegurarse de que se arreglen.[19]

3.2.5 Principios de las pruebas


Dentro del proceso de pruebas, existen siete principios que buscan dar pautas para el momento
de ejecutar las pruebas. Estos se definen en [2]:

17
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Principio 1- Las pruebas demuestran la presencia de defectos

Principio 1- Las pruebas demuestran la presencia de defectos


• Las pruebas permiten encontrar defectos, pero no demuestran su ausencia [2], lo que
define
Principio que:pruebas demuestran la presencia de defectos
1- Las

1. El proceso de pruebas puede probar la presencia de defectos


2. El proceso de pruebas no puede demostrar la ausencia de defectos
3. Las pruebas reducen la probabilidad de defectos, pero nunca se puede asegurar
que no quede uno oculto

“La prueba de software puede demostrar la existencia de fallos, pero nunca podría demostrar la
ausencia de los mismos.” E.W.Dijkstra.

Principio 2 - Las pruebas exhaustivas no existen

Principio
• Salvo1- Las pruebas
para demuestran
casos triviales, la presencia
las pruebas de defectos
exhaustivas son imposibles debido que se debería
considerar
Principio todas las
1- Las pruebas precondiciones,
demuestran todas las
la presencia decombinaciones
defectos de datos de entradas, todos
los caminos posibles, se convierte en un problema intratable.[2]
• Por lo tanto, es recomendable realizar análisis de riesgo, asignar prioridades a las pruebas
identificadas y realizar un plan de pruebas.
• Las cuatro razones que no permiten realizar las pruebas exhaustivas :
 El número de entradas posibles es muy grande.[19]
 El número de posibles salidas es muy grande.[19]
 El número de rutas a través del software es muy grande.[19]
 La especificación de software es subjetiva. Se podría decir que un fallo está en el
ojo del que mira. [19]
Al multiplicar estos cuatro factores "muy grandes", se obtiene un conjunto de condiciones
de prueba que es demasiado grande como para probar.
Por ejemplo, se desea realizar pruebas sobre una aplicación que presenta las siguientes
condiciones:

1. Sistema con 20 pantallas


2. Cada pantalla presenta 4 menús
3. Cada menú presenta 3 opciones
4. Cada pantalla tiene por lo menos 10 campos
5. Cada campo recibe 2 tipos de datos de entrada
6. Existen 100 posibles valores

Por lo tanto se tiene que:

 Son necesarias 20 × 4 × 3 × 10 × 2 × 100 = 𝟒𝟖𝟎. 𝟎𝟎𝟎 pruebas


 Si el tiempo de ejecución de cada prueba es de un segundo, se requieren 17.7 días
para ejecutar las pruebas:
480.000 𝑝𝑟𝑢𝑒𝑏𝑎 × 1 𝑆𝑒𝑔𝑢𝑛𝑑𝑜 = 480.000 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠

18
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

480.000
𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 = 8.000 𝑚𝑖𝑛𝑢𝑡𝑜𝑠
60

8.000 𝑚𝑖𝑛𝑢𝑡𝑜𝑠 133.33 ℎ𝑜𝑟𝑎𝑠


= = 17.7 𝑑𝑖𝑎𝑠
60 𝑚𝑖𝑛𝑢𝑡𝑜𝑠 7.5 ℎ𝑜𝑟𝑎𝑠1
 Si el tiempo de ejecución de las pruebas es de diez segundos, se requieren 35
semanas para ejecutar las pruebas:

10 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 = 177.7𝑑𝑖𝑎𝑠
177.7𝑑𝑖𝑎𝑠
= 35 𝑠𝑒𝑚𝑎𝑛𝑎𝑠
5 𝑑𝑖𝑎𝑠2
 Si el tiempo de ejecución de las pruebas es de 1 minuto, se requieren 4 años para
ejecutar las pruebas:
1 𝑚𝑖𝑛𝑢𝑡𝑜 = 4 𝑎ñ𝑜𝑠
 Si el tiempo de ejecución de las pruebas es de 10 minutos, se requieren 40 años
para ejecutar las pruebas :

10 𝑚𝑖𝑛𝑢𝑡𝑜𝑠 = 40 𝑎ñ𝑜𝑠
Principio 3 - Pruebas tempranas

Principio
• Las1-pruebas
Las pruebas demuestran
tempranas, la presencia
permiten de defectos
identificar defectos en fases iniciales del desarrollo,
estas
Principio 1- deberían iniciar
Las pruebas lo más pronto
demuestran posiblede
la presencia yadefectos
que permite reducir costos en la solución
de errores y generar una mayor confianza en el producto. [2]
Principio 4 - Agrupación de defectos

Principio
• Los 1- Las pruebasgeneralmente
defectos demuestran lase presencia de defectos
encuentran agrupados bajo el mismo modulo o
componentes,
Principio nodemuestran
1- Las pruebas distribuidoslaapresencia
lo largo de
deldefectos
sistema. Los defectos van en grupo, se
encuentran de manera uniforme a lo largo del mismo.[2]
• Los esfuerzos de las pruebas pueden enfocarse en los módulos donde se hayan detectado
la mayor cantidad de defectos.

Principio 5 – Paradoja del pesticida

• Cuando
Principio 1- Las se efectúan
pruebas las mismas
demuestran pruebas de
la presencia unadefectos
y otra vez, lo más seguro es que no se
encuentren más defectos, estos casos de pruebas pierden la efectividad conforme se
Principio 1- Las pruebas demuestran la presencia de defectos
ejecutan de manera repetitiva. [2]
• Los casos de prueba pueden haber eliminado cierto tipo de defectos por lo tanto no van a
presentarse más, pero no pueda que exista otro tipo de errores que no serán identificados
con estos casos de pruebas.
• Por lo tanto repetir pruebas bajo las mismas condiciones no es efectivo, estas se deben
revisar y modificar de manera periódica.

1
Suponiendo que las horas diarias laborales empleadas para pruebas son 7.5
2
Suponiendo que la semana cuenta con cinco días hábiles que son los empleados para pruebas

19
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Principio 6 – Las pruebas dependen del contexto

Principio
• Las1-pruebas
Las pruebas demuestran
se deben realizanladepresencia
manerade defectossegún el contexto, no es lo mismo
diferente
probar
Principio un pruebas
1- Las sitio webdemuestran
que un software de seguridad.
la presencia [2]
de defectos
• Los objetos de pruebas diferentes, se prueban de manera diferente.

Principio 7 – Falacia de ausencia de errores

Principio 1- Las pruebas


• El proceso demuestran
de pruebas la presencia
puede permitir de defectos
la detección y la corrección de errores, pero esto no
será1-útil
Principio Lassipruebas
el sistema no cumplelalaspresencia
demuestran expectativas y necesidades del usuario. Las pruebas no
de defectos
miden la satisfacción del usuario final, ni que el software vaya a tener éxito. [2]

3.2.6 Características de las pruebas


Atributos para una buena prueba:

 Una buena prueba tiene una elevada probabilidad de encontrar un error: es necesario
que la persona que realiza la prueba conozca el software y las posibilidades de falla. [23]
 Una buena prueba no es redundante: Cada caso de prueba debe tener su propio objetivo
y propósito. [23]
 Una buena prueba debe ser “la mejor de su clase”: “Un grupo de casos de pruebas con
un objetivo similar y recursos limitados podría optarse por la ejecución de un solo
subconjunto de ellas. En este caso, debe usarse la prueba que tenga la mayor
probabilidad de descubrir un tipo completo de errores.” [23]
 Una buena prueba no debe ser ni muy simple ni demasiado compleja: una prueba puede
contener otra prueba pero esto puede llevar a que no se evidencien los errores si no
estos se enmascaren, lo recomendable es mínimo un caso de prueba por
requerimiento.[23]

3.3 Niveles de pruebas


Las pruebas se realizan en diferentes niveles durante su desarrollo y mantenimiento, dependiendo
de su propósito, uso, comportamiento o estructura[14]. Por lo tanto el nivel de prueba es un
grupo de actividades organizadas y gestionadas de manera conjunta [8], define el objetivo de la
prueba, el enfoque, el propósito y el momento en el que se ejecutan, permiten validar y verificar
el software desde un punto de vista de los responsables del proyecto.[14]

En la sección 3.3.1 se presentan los niveles de pruebas que son mencionados en la guía.

20
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado

3.3.1 Niveles de pruebas


3.3.1.1 Pruebas unitarias o de componente
Descripción: Permite verificar los componentes o módulos del sistema de manera individual. [24], [23]

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas


• Localizar defectos[2] Roles que intervienen
• Comprobar y asegurar el en la prueba:
• Componentes o
funcionamiento de los • Participa el
módulos [2], [17]
módulos del software, De acuerdo al ISTQB desarrollar del sistema.
• Módulo/ • Programas [2]
programas, objetos, [2]: [2],[21] • Modulo Probado
componente • Conversación de
clases, del sistema objeto • Requerimientos de Corrección de [21]
desarrollado datos[2]
de la prueba.[2] componentes defectos: • Modulo listo
• Diseño • Procedimientos
• Verificar que los flujos de • Diseño detallado • Se corrigen defectos para integrar[21]
detallado[21] asociados.[17]
control y de datos se • Código cuando son
• Módulos de bases
encuentren cubiertos, y detectados, por lo
de datos. [2]
que funcionen según lo tanto no necesitan una
esperado. [23] gestión formal. [2]
Tabla 2. Pruebas unitarias

21
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.3.1.2 Pruebas de integración


Descripción: Permite verificar la interacción entre los componentes del software. [14]

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas


• Pruebas Quien ejecuta la
• Verificar la integración unitarias • Implementación prueba:
de los componentes del ejecutadas De acuerdo al ISTQB [2]: de base de datos • Grupo de desarrollo • Informe de
sistema. [23]. • Diseño de software y de subsistemas [2] del sistema, Pruebas de
• Evaluar la interacción • Producto sistema • Infraestructura [2] ingenieros de Integración.[21]
entre los distintos integrado • Arquitectura • Interfaces [2] software. [23] • Producto listo
sistemas o entre el • Plan de • Flujos de trabajo • Configuración del • Ingeniero de pruebas para su entrega a
hardware y el software. pruebas de • Casos de uso sistema y datos de [21] pruebas[21]
[2] integración. configuración [2] • Jefe de desarrollo[21]
[21]
Técnicas o estrategias
• Todos los componentes y unidades del sistema se ensamblan resultando un sistema completo[21]
• Ventaja: no es necesario simular ninguna parte del sistema porque todo está integrado listo para iniciar las
Integración Big-bang
pruebas.[21]
• Desventaja: No es fácil encontrar la causa del error debido que no es posible aislar los errores encontrados[21]
• Las pruebas inician con los módulos de nivel superior, es decir los módulos con mayor nivel de abstracción, para ir
Arriba hacia abajo (top- descendiendo de manera progresiva a los más inferiores y probar así su integración.[21]
down) • Al no tener el sistema completo integrado, es necesario que se desarrollen programas auxiliares de nivel inferior
que simulen el correcto funcionamiento. [21]
• Las pruebas inician con los módulos de nivel inferior, es decir los módulos más especializados, para ir ascendiendo
Abajo a arriba (bottom- de manera progresiva a los más superiores.[21]
up) • No se dispone del sistema completo hasta el final, por lo tanto es necesario que se desarrollen programas
auxiliares de nivel superior que permiten probar la integración. [21]
Tabla 3. Pruebas de integración

22
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.3.1.3 Pruebas de sistema


Descripción: Permiten realizar la validación total del sistema implementado, y en la interacción entre los componentes integrados o sistemas

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas


• Verificar la
Roles que intervienen:
funcionalidad del
• Equipo de pruebas
sistema a través de sus
independiente[2]
interfaces externas
• Ingeniero de pruebas[21] De acuerdo a
• Comprobar que la
• Pruebas de De acuerdo al • Manuales de • Analista funcional[21] INTECO [21]:
funcionalidad
integración ISTQB [2]: sistema, • Jefe de pruebas[21] • Informe de
corresponda a la
ejecutadas. [21] • Especificación de usuario y Técnicas: Pruebas de
esperada de acuerdo a
• Definición de requerimientos funcionamiento • Basadas en especificación: Sistema.
los requerimientos. [14]
un conjunto de • Casos de uso [2] técnicas de caja negra [2] y • Manual de
• Las pruebas del
objetivos • Especificaciones • Configuración • Basadas en estructuras: Usuario.
sistema no se limita a
medibles para funcionales del sistema[2] técnicas de caja blanca [2] • Manual de
sistemas. Si el producto
el producto.[15] • Informe de • Datos de Corrección de defectos: Administración.
es un programa, las
• Plan de pruebas análisis de configuración. • Se reportan las • Plan e Informe de
pruebas del sistema es
de sistema[21] riesgos [2] inconsistencias encontradas. Pruebas
el proceso de tratar de
• Se genera nueva versión del • Sistema probado
demostrar cómo el
software con la solución del
programa, en su
defecto y es entregado para
conjunto, no cumple
pruebas de sistema.
con sus objetivos.[15]
Tabla 4. Pruebas de sistema

3.3.1.4 Pruebas de aceptación


Descripción: Las pruebas que busca determinar si el sistema satisface los criterios de aceptación.[25]Por lo tanto permite “Verificar la idoneidad
de uso del sistema por parte de los usuarios”[2]. Estas pruebas son importantes, tal cual se menciona en Pressman “En la práctica es imposible
que un desarrollador de software prevea cómo utilizará el usuario realmente el programa. Es imposible que se malinterpreten las instrucciones

23
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

de uso, que se utilicen con regularidad extrañas combinaciones de datos, que una salida en apariencia clara para el responsable de las pruebas
sea ininteligible para el usuario de campo”[23]

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas


• Determinar si el usuario,
cliente, u otra entidad
autorizada acepta el
Quien ejecuta la
sistema o componente
• Ejecución de De acuerdo al ISTQB prueba:
objeto de la
pruebas de [2]: • Procesos de • Analistas de
prueba.[25],[17]
sistema[21] • Requerimientos de negocio [2] pruebas • Resultados de
• Validar los requerimientos
• Especificación usuario • Procesos • Usuario del pruebas [21]
[23]
de • Requerimientos de operativos y de sistema[2] • Producto
• “El objetivo principal de las
requerimientos sistema mantenimiento [2] • Ingeniero de aceptado [21]
pruebas de aceptación no
[21] • Casos de uso • Procedimientos de pruebas [21] • Informe de
es localizar defectos, si no
• Manuales de • Procesos de usuario[2] • Jefe de pruebas pruebas de
evaluar la buena
usuario[21] negocio • Formularios [2] [21] aceptación [21]
disposición de un sistema
• Plan de • Informes de • Informes [2] • Jefe del proyecto
para su despliegue y
pruebas[21] análisis de riesgos [21]
uso.”[2], demostrando que
el software se encuentra
listo para el paso a
producción. [21]
Estrategias de pruebas de aceptación
• El usuario o cliente realiza pruebas del sistema en el entorno de desarrollo [2],[21]
• Se trabaja en un entorno controlado y el cliente siempre tiene un experto que le ayuda a usar el
Pruebas Alfa (α)
sistema.[23],[21]
• El desarrollador registra los defectos encontrados y los problemas de uso. [21]
• Se realizan después de las prueba alfa. [21]
• Las pruebas se realizan en el entorno del cliente, es decir en un entorno externo a desarrollo [14], [21]
Pruebas Beta (β)
• Las pruebas las realizan los clientes o clientes potenciales [2]
• El cliente realiza las pruebas del producto y registra e informa los fallos encontrados al desarrollador. [23],[21]
Tabla 5. Pruebas de aceptación

24
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.3.1.5 Pruebas de regresión


Descripción: Ejecución de casos de pruebas anteriormente ejecutados cuando se implementan cambios en el software. [23]

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas


• Asegurar que los cambios en el sistema • Las pruebas de regresión se pueden realizar en cada uno de los niveles
no afecte de manera negativa el software • Incorporación de de pruebas mencionados anteriormente. [14]
(comportamientos no esperados o un cambio en el • Las pruebas de regresión se realizan en durante todo el ciclo de vida
errores adicionales).[23] sistema, sea por del sistema y se ejecutan cada vez que se modifica un componente del
• Permite asegurar los cambios del nuevas sistema [26], en la Ilustración 4 se presenta como las pruebas de
sistema.[23] funcionalidades o regresión hacen parte de las pruebas de las pruebas unitarias,
• Verificar el correcto funcionamiento del mejoras a las ya integración y pruebas de sistema.
software ante cambios del mismo.[21] existentes • Por lo tanto los documentos bases, el objeto de prueba, otros aspectos
• Demostrar que las pruebas que fueron • Solución a y salida dependen del nivel de prueba en el que se realiza la prueba de
exitosas en el software, continúan siendo defectos. [21] regresión.
exitosas. [14]
Tabla 6. Pruebas de regresión

PRUEBAS DE REGRESIÓN

Pruebas Pruebas de Pruebas de Pruebas de


unitarias integración Sistema Aceptación
Ilustración 4.Pruebas de regresión en, tomado de [26]

25
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.4 Tipos de pruebas


A continuación se presentan dos distintos tipos de pruebas, que dependen del tipo de prueba que
se va a ejecutar y del objetivo, estas se dividen de la siguiente manera de acuerdo a [2]:

• Una función que realiza el software.


• Pruebas asociadas a cambios

3.4.1 Pruebas de funciones o pruebas funcionales


Las pruebas funcionales, como su nombre lo indican se basan en validar y verificar la funcionalidad
del sistema, “la función de un sistema es ‘lo que hace’ dicho sistema”[21], funcionalidades
definidas en los diferentes artefactos del sistema, en la Ilustración 5, se presentan algunos
ejemplos de los documentos que sustentan las pruebas funcionales que están dadas por las
funciones descritas en los documentos del sistema y funciones entendidas por las personas
responsables de las pruebas que no necesariamente se encuentran documentadas. [2]

Pruebas funcionales
Especifición de Especificación Funciones no
Casos de uso
requerimientos funcional documentadas

Ilustración 5. Pruebas funcionales

• El principal objetivo de las pruebas funcionales, es verificar que el sistema tiene el mismo
comportamiento descrito en los documentos de especificaciones, por lo tanto, confirman
si el software cumple con las funciones específicas para los que han sido creados. [14],
[21]
• Las pruebas funcionales no tienen en cuenta el mecanismo interno del sistema, si no se
centran en las respuestas que el sistema proporciona a determinadas entradas y a las
condiciones de ejecución, por lo tanto se basan en las técnicas de caja negra.[17]

3.4.2 Pruebas asociadas a cambios


Las pruebas asociadas a los cambios, corresponden a las pruebas que se realizan cada vez que es
necesario repetir una prueba o ejecutar pruebas de regresión debido a modificaciones realizadas
en el software, se pueden realizar en cualquier nivel de pruebas. [2] Para mayor información ver la
Tabla 6.

Cada vez que se ejecutan los casos de pruebas y en los resultados se detectan defectos,
independiente del nivel de pruebas, el equipo de desarrollo realiza su respectiva revisión,
seguimiento y corrección. Para la revisión es común que se realice la depuración de código,
permitiendo que en algunos de los casos encontrar la causa de los defectos y otros casos, en los
que no se encuentran la causa directa “sospechar” los posibles orígenes.[23]

26
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Por lo anterior, durante las pruebas el software se encuentra en constante cambio y es necesario
realizar re pruebas del sistema, con el fin de:
o Confirmar que los defectos originales son corregidos. [2]
o Rectificar que no se presenten defectos en funcionalidades previamente probadas. [2]
o Verificar que no se presenten nuevos defectos. [2]
En la Ilustración 6, se presenta el ciclo de pruebas y el proceso de depuración.

Ilustración 6. Depuración de defectos, tomado de [24]

3.5 Casos de pruebas


Uno de los conceptos más importantes en el proceso de pruebas de software, son los casos de
prueba, debido que suministran la información necesaria para la ejecución y el paso a paso que
debe ejecutar el probador para la prueba. En esta sección se encuentra la información relacionada
a los casos de pruebas.

3.5.1 ¿Qué es un caso de prueba?


De acuerdo a la IEEE y al ISTQB, un caso de prueba es un conjunto de valores de entradas,
condiciones previas de ejecución, resultados esperados y condiciones posteriores de ejecución,
para cumplir con un objetivo en particular, condición de prueba, evento, o sistema, desarrollado
para verificar o validar el cumplimento de los requerimientos. [8], [17],[25]
 Define los pasos a seguir para poder verificar el comportamiento esperado del sistema y
los requerimientos establecidos.
 Permite realizar la evaluación sobre un objeto de prueba.
 La definición de los casos de prueba debe ser un proceso iterativo. [27]
 Un caso de prueba puede cubrir una o varias condiciones de pruebas.
 Debe ser repetible, verificable y localizable en los requerimientos.[2]

3.5.2 Características y beneficios de un caso de prueba


Un caso de prueba, se encuentra completo si su definición cumple con las siguientes
características, de acuerdo a [28], [27]:
• Preciso: Describe que se va a probar
• Efectivo: Tiene una probabilidad de encontrar defectos. [27]

27
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

• Trazable: El caso de prueba se encuentra relacionado a un requerimiento. [2]


• Evolutivo: Fácil de mantener[27]
• Eficiente: El caso de prueba presenta únicamente los pasos que son necesarios, evitando
los pasos innecesarios. [27]
• Estado inicial: Luego de la ejecución del caso de prueba, el ambiente de pruebas retorna a
su estado normal
Por lo tanto, si un caso de prueba se encuentra bien definido, brindara los siguientes beneficios
para el proceso de pruebas[29]:
1. Registra el comportamiento del sistema.
2. Registra el límite y/o alcance del caso de prueba.
3. El caso de prueba puede ser reutilizable.
4. Se puede determinar el momento exacto en el que se produce un error.
5. Se puede utilizar el caso de prueba como una unidad medible.

28
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.5.3 Elementos de un caso de prueba


Los casos de prueba deben definir la información necesaria para la ejecución de las pruebas, en la
Ilustración 7, se presenta los elementos que debe incluirse en la definición de los casos de prueba.

Identificador único • Identificador del caso de prueba de manera única, permite distinguir
el caso de los demás. [31]

• Define el propósito del caso de prueba, el como se debe probar y


Objetivo que se va a probar: Que se va a validar o a verificar. [30],[31]
•Se puede incluir el riesgo o la prioridad [31]

•"Un elemento o evento de un componente o sistema que debería


ser verificado por uno o más casos de prueba, por ejemplo, una
Condición de prueba
función, transacción, característica, atributo de calidad, o elemento
estructural." [8]

•Datos de entra o datos de pruebas (test data) que son requeridos


para la ejecución del caso.[31]
Entradas
•Valores de entrada o nombre de archivos o constantes que se
utilicen.[31]

•Estado y condiciones previas que el sistema debe cumplir para la


Precondiciones ejecución del caso de prueba. [30]

•Comportamiento esperado del sistema a partir de las entradas y las


condiciones de ejecución.[31]
Resultados esperados
•Salidas, cambios de estados, valores especificos.[31]

Condiciones •Estado esperado del sistema luego de la ejecución del caso de


Posteriores prueba.[31]

Configuración de •Definir las necesidades a nivel de hardware, software, que son


ambiente requeridas para la ejecución de las pruebas. [31]

•Relación de casos de pruebas que deben ser ejecutados antes del


Dependencias
caso de prueba, debido a la dependencia [31]

Ilustración 7.Casos de pruebas, adaptado de [31]

3.6 Técnicas de pruebas


Las técnicas de pruebas son procedimientos que permite la selección y diseño de pruebas
ejecutables de manera efectiva, permite identificar las condiciones de pruebas, casos de pruebas y
datos de pruebas.[2] Existen dos grandes grupos de técnicas de pruebas, las técnicas basadas en la
especificación del sistema comúnmente llamadas técnicas de caja negra y las técnicas basadas en
la estructura conocidas como técnicas de caja blanca [2],[21]. Esta última no es objetivo de la guía
por lo tanto no se presenta la descripción, ni sus métodos. El tercer grupo de técnicas de pruebas
están basadas en la experiencia de la persona que realiza las pruebas. En la Ilustración 8, se
presenta la clasificación de los tres grupos de técnicas.

Las técnicas de pruebas corresponden a la validación y verificación dinámica de los


requerimientos, sólo se aplican sobre el código del producto para detectar defectos y determinar

29
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

atributos de calidad del software.[21] Las técnicas de pruebas, permiten realizar: pruebas efectivas
ya que permiten encontrar más defectos y pruebas eficientes ya que encuentra los defectos en el
menor tiempo posible.

Basada en Basada en
Basadas en
especificación estructura (Caja
experiencia
(Caja negra) Blanca)

Partición de Pruebas de Predicción


equivalencia sentencia de error

Análisis de Pruebas de Pruebas


valores limites decisión Exploratorias

Tabla de Pruebas de
decisión caminos

Grafos de
causa- efecto

Transición de
estados

Casos de uso

Ilustración 8. Técnicas de pruebas, adaptado de [15] , [28], [21]

3.6.1 Basada en la especificación (Caja negra)


Las técnicas basadas en especificación o pruebas de caja negra, no necesitan conocer la lógica
interna del sistema a probar para el desarrollo de los casos de prueba [2]. Se basan en las posibles
entradas, las salidas del sistema como resultado y la validación del resultado[19], las pruebas son
exitosas si el resultado cumple los criterios de aceptación, en caso contrario la prueba revela un
defecto (salida errónea)[30]. Quien ejecuta las pruebas se basa en que hace el software y no en el
cómo[21], tiene en cuenta las respuestas del sistema y no la trayectoria interna de cálculos y
procesamiento realizado. [30]

La IEEE define esta técnica como “un enfoque que trata a un sistema o componente cuyas
entradas, salidas y funciones en general son conocidos, pero cuyo contenido o implementación
son desconocidos o irrelevantes” [17]. En la Ilustración 9, se presenta un ejemplo sobre pruebas
sobre una calculadora, que como entrada recibe los números y las operaciones que se requieren
ejecutar sobre ellos y devuelve una salida con el resultado de la operación. [19]

30
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

5 Calculadora
+ 10
5
=
Ilustración 9.Técnica de caja negra

En las siguientes subsecciones se presentan las técnicas de pruebas de acuerdo a este enfoque.

3.6.1.1 Partición de equivalencia


Como su nombre lo indica, esta técnica busca dividir las entradas o salidas del sistema en grupos
de acuerdo a un común comportamiento o por características comunes, por lo tanto se espera que
sean procesados de la misma manera,[2],[27] el resultado de la prueba para una entrada de una
clase es representativo para todas las entradas de la misma clase.[15]

 Dividir las entradas o salidas, en grupos equivalentes[26],[27]. En la Ilustración 10 se


presenta ejemplo sobre la partición.
 Supuesto: Si un valor da resultado esperado, el resto del grupo harán lo mismo.[15], o por
el contrario, si un valor de una partición no funciona, entonces se asume que el resto de la
partición no funcionará.[21]
 La partición de equivalencia puede aplicarse en todos los niveles de pruebas.[2]

Ilustración 10. Partición de equivalencia, tomado de [27]

Por ejemplo, para el rango 0 < 𝑋 < 10

Se identifican tres particiones para realizar los casos de prueba:

• Todos los valores numéricos de entrada que se encuentren dentro de los rangos 𝑋 ≤ 0 y
𝑋 ≥ 10 son valores de entrada inválidos.
• Todos los valores numéricos de entrada que se encuentren dentro del rango 0 < 𝑋 < 10
son valores de entrada válidos.

Ilustración 11. Valores de entrada partición de equivalencia

Pressman define cuatro directrices para la definición de particiones equivalentes[23], se define


una clase de equivalencia válida y dos no validas si la condición de entrada:

1. Especifica un rango[23]

31
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

2. Requiere un valor especifico[23]


3. Especifica un miembro de un conjunto [23]
4. “Se define una clase de equivalencia y otra no valida, si la condición de entrada es
booleana”[23]

3.6.1.2 Análisis de valores limites


Esta técnica toma como base la anterior y se centra en el análisis del valor frontera de las
particiones para identificar su valor límite, [27] de modo que para cada partición, se define un
caso de prueba que cubra el límite superior e inferior.[26]

 Los valores máximos y mínimos de una partición corresponden a los valores límites.[2]
 Los limites o fronteras son un buen lugar para encontrar defectos, debido que los
defectos tienden a encontrarse alrededor de ellos.[27] Es probable que se presente un
error en los valores justo fuera del rango por ser aceptados o los valores justo en el límite
del rango por ser rechazados.[21] En la Ilustración 12, se presenta un ejemplo sobre este
error.

Ilustración 12. Análisis de valores limites, adaptado de [27]

 Los limites válidos constituye al valor límite de las particiones válidas y limites no válidos
corresponde a valor límite de las particiones no válidas. [2],[21] Por lo tanto un valor límite
es el valor en un límite de una partición de equivalencia. [27]
 Las pruebas deben considerar los valores válidos, valores inválidos, valores límite válidos y
valores límite inválidos. [2] Cuando se selecciona un valor límite, se debe seleccionar el
valor límite, al menos un valor dentro del límite y otro valor fuera del límite, por lo tanto
por cada límite se seleccionan tres valores. [27] Es importante tener cuidado con el valor
fuera del límite de la partición, debido que esta puede ser el valor de la frontera de otra
clase, lo que puede estar reduciendo los valores de selección a dos: el valor límite y un
valor dentro del límite.[27]
 El análisis de valores límite puede aplicarse en todos los niveles de pruebas.[2]
 Con frecuencia se presentan inconvenientes en el momento de definir los valores límites
de una partición, por lo que es necesario basarse en la especificación de los
requerimientos, y como segunda instancia buscar los límites de manera indirecta u
ocultos. [27]

En el ejemplo anterior para el rango 0 < 𝑋 < 10, se tienen las mismas particiones con las
fronteras: 0 y 10.

32
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 13. Análisis valor frontera

Se tiene los siguientes valores de pruebas:

• Valores identificados para las tres particiones: -1, 0, 1, 5, 9, 10, 11


• 0, 1, 9, 10 representan valores de prueba para el rango 0 < 𝑋 < 10, donde las
fronteras son excluidas en el rango.
• -1, 0, 10, 11 representan valores de prueba para el rango 0 < 𝑋 < 10, donde las
fronteras no son excluidas en el rango.

3.6.1.3 Tabla de decisión


Las tablas de decisión, comprende un conjunto de condiciones (entradas) y un conjunto de
acciones (salidas). Para cada conjunto de condiciones, se relaciona la entrada con las opciones
“Si”, “No”, o “No aplica” como respuesta y una lista de resultados esperados de acuerdo a las
reglas seleccionadas. [26]

 Las tablas de decisión permite registrar todas las condiciones de entrada posibles junto
con todas las acciones resultantes del sistema. [21], [27]
 Facilita la definición de las decisiones lógicas del sistema, debido que las tablas
representan relaciones lógicas entre las condiciones. [14], [21]
 Las tablas de decisión, son muy útiles cuando se tienen reglas de negocio complejas y se
cuenta con varias condiciones de entradas que producen varias salidas.[2],[21]
 Las tablas de decisión permiten determinar si los requerimientos están completos, los
casos de prueba se crean a partir de cualquier texto o documento y a menudo permiten
evidenciar ambigüedades o falencias en los requerimientos. [27]
 Las combinaciones posibles de la tabla de decisión se deriva de los requerimientos,[27] se
debe analizar la especificación para identificar las condiciones y acciones del sistema.[2]
 Las filas de la tabla de decisión especifican las condiciones de entrada o acciones que son
realizadas en el sistema. [31]
 Las columnas de la tabla de decisión, representan los casos de prueba, especifican las
acciones que pueden ocurrir.[2],[31] Representa un conjunto único de combinaciones de
entrada.

Entrada / Acciones Prueba 1 Prueba 2 Prueba N


Entrada 1 Si No Si
Entrada 2 Si N/A No
Entrada N Si N/A Si
Salidas/Respuestas
Salida 1 Si No Si
Salida 2 Si No No

33
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Salida N No Si N/A
Tabla 7. Tablas de decisión

En la Tabla 8 se presenta un ejemplo sobre la técnica de tablas de decisión. Las entradas


corresponden a los estados de las personas que ingresan a un sistema y las salidas corresponden a
las salidas de acuerdo a las entradas.

Entrada /Acciones Prueba 1 Prueba 2 Prueba 3 Prueba 4 Prueba 5


¿Mayor de edad? Si Si Si Si No
¿Empleado? Si No No Si N/A
¿Esta pensionada? Si Si No No N/A
¿Estudia en
No No No No Si
colegio?
Salidas/Respuestas
Cotiza pensión. No No No Si N/A
Recibe ingresos
Si Si N/A N/A N/A
por pensión.
Recibe sueldo por
Si No N/A Si N/A
trabajo.
Depende
económicamente N/A N/A N/A N/A Si
de los padres.
Tabla 8. Ejemplo tabla de decisión

Así por ejemplo se tienen las siguientes entradas para definir los casos de pruebas y las salidas o
respuestas esperadas:
• El primer caso de prueba, las entradas definen a una persona que es mayor de edad, esta
empleada, es jubilada y no estudia en colegio. Por lo tanto, no cotiza pensión, recibe ingresos
por pensión y recibe sueldo por trabajo.
• El segundo caso de prueba, las entradas definen a una persona que es mayor de edad, no está
empleada, esta pensionada y no estudia en un colegio. Por lo tanto, no cotiza pensión, recibe
ingresos por pensión y no recibe sueldo por trabajo.
• El quinto caso de prueba, las entradas definen a un menor de edad y que estudia en el colegio.
Por lo tanto, depende económicamente de sus padres.

3.6.1.4 Grafos de causa- efecto


Técnica de prueba que busca representar de manera gráfica las “entradas o estímulos (causas) del
sistema con las salidas asociadas (efectos) del sistema.” [27]

 El grafico es el resultado del análisis de los requerimientos[27]


 Los casos de prueba se generan a partir del diagrama. [15], [27]
 Es útil para los casos donde las funciones dependen de más de una entrada[27]
 Las entradas y las salidas tienen que ser las declaraciones que son verdaderas o falsas.[27]
 “El contenido semántico de la especificación se analiza y se transforma en un grafo de
Boole con las causas y los efectos”[15],[27], ver la Ilustración 14

34
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

𝑓(𝐸𝑠𝑡𝑎𝑑𝑜 𝑎𝑐𝑡𝑢𝑎𝑙, 𝑒𝑛𝑡𝑟𝑎𝑑𝑎) → (𝑁𝑢𝑒𝑣𝑜 𝑒𝑠𝑡𝑎𝑑𝑜, 𝑠𝑎𝑙𝑖𝑑𝑎)


𝑓(𝐸𝐴1 , 𝐸𝐴2 . . 𝐸𝐴𝑛 , 𝐸𝐴𝑛+1 , 𝐸1 , 𝐸2 . . 𝐸𝑛 , 𝐸𝑛+1 ) → (𝑁𝐸1 , 𝑁𝐸2 . . 𝑁𝐸𝑛 , 𝑁𝐸𝑛+1 , 𝑆1 , 𝑆2 . . 𝑆𝑛 , 𝑆𝑛+1 )

Ilustración 14.Función grafo de causa – efecto, tomado de [27]

Para la creación de casos de pruebas es necesario:

1. Cuando un requerimiento no es atómico es difícil de manejar , por lo que se recomienda


Dividir el requerimiento en varios segmentos viables, que puedan ser representados
como causa – efecto.[15]
2. Identificar las causas y los efectos del requerimiento. A cada una de las causas y efecto se
le debe asignar un identificador único. [15],[27]
3. Para cada efecto generar una expresión booleana que exprese las causas. [27]
4. Generar el grafo, en las conexiones se incluye el tipo de combinación entre las causas y
efectos.
a. Si se presenta el operador booleano ∧ (y), significa que todas las causas deben ser
verdaderas para que el efecto sea verdadero. [27]
b. Si se presenta el operador booleano ∨ (o), significa que al menos una causa debe
ser verdadera para que el efecto sea verdadero. [27]
c. Si se presenta un ∼ , representa la negación, lo verdadero debe entenderse
como falso, y viceversa. [27]
d. Si se presenta un arco∡, significa que todas las causas se deben combinar con el
operador. [27]
5. Cuando se presenten consideraciones que no son posibles incluir en el grafo (ejemplo. Una
restricción ambiental), se debe incluir la anotación en el diagrama.[15]
6. Es posible transformar el grafo a una tabla de decisión, donde las columnas de la tabla
representan un caso de prueba. [15]

En la Ilustración 15, se presenta una representación de los grafos de causa – efecto.

E1 S1 E1 S1

Si E1 entonces S1 Si no E1 entonces S1

E1

S1 E1 S1
E2

E2
E3

Si E1 o E2 o E3 entonces S1 Si E1 y E2 entonces S1
Ilustración 15. Diagramas posibles de causa – efecto, tomado de [15]

35
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.6.1.5 Transición de estados


La técnica de transición de estados, es indicada cuando el sistema presenta estados y realiza
transiciones entre ellos de acuerdo a los eventos presentados. Se representa por medio de un
diagrama de máquina de estados finitos, donde los estados son los círculos, las transiciones son
flechas entre los estados y los eventos son un texto que se encuentra junto a la transición, [28] ver
Ilustración 16.

Estado Transición Estado


inicial Descripción del Final
evento

Ilustración 16. Transición de estados

 El sistema tiene un número finito de estados, las transiciones de un estado a otro


dependen de los eventos y reglas definidas. El sistema presenta un comportamiento
dependiendo de las entradas y su estado previo. [2],[21]
 La transición de estados inicia cuando se presenta un evento, el evento desencadena una
acción y el sistema cambia de estado. [27], [32]
o Transición: Estado inicial+ Evento + Acción + Estado final [27]
 Útil cuando el sistema presenta diferentes salidas bajo la misma entrada.[21]
 Un estado representa todas las características del sistema en un determinado momento,
“incluyendo todos los datos visibles, todos los datos almacenados, y cualquier forma
actual y campo”[27]
 Los casos de pruebas deben corresponder a cada uno de sus estados y transiciones. [14]

En la Ilustración 17, se presenta un ejemplo de transición de estados para el acceso de una cuenta
a través de una tarjeta que se ingresa a un sistema.

Bloquear
Segundo tarjeta
T3
Intento T6
Inicio T8
T5
Inserta Tercer
Espera T2 Primer Clave Intento
tarjeta
T1 Clave Ingreso Intento Correcta
clave T7
Clave Clave
Correcta Acceso a Correcta
la cuenta
T4

Ilustración 17. Transición de estados, adaptado de [28]

36
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Una transición de la Ilustración 17, es por ejemplo:


T1 = Inicio + Inserta tarjeta + Mensaje del sistema “Por favor ingrese su clave” + Espera clave

Estado inicial
Transición: Eventotarjeta + Mensaje
Inicio +Inserta Acción del
(no sistema
re presentada en laingrese
“Por favor ilustración)
su clave” +Estado
Esperafinal
clave

Para generar los casos de pruebas a partir de los diagramas de estado, es necesario traducir el
diagrama a tablas que representen las transiciones de los estados y las condiciones que hacen que
estos cambien. Dentro la investigación se encontró dos aproximaciones:

1. En la primera columna se definen los estados del sistema y en la primera fila los eventos.
En las intersecciones de fila, columna se relacionan el estado final por la transición de la
combinación estado inicial, evento. En la Tabla 9 se representan el ejemplo de la
Ilustración 17.

Eventos Inserta Ingreso Clave Clave


Estado inicial Tarjeta clave correcta incorrecta
(S1)Inicio S2 - - -
(S2)Espera clave - S3 - -
(S3)Primer intento - - S6 S4
(S4)Segundo intento - - S6 S5
(S5)Tercer intento - - S6 S7
(S6)Acceso a la cuenta - - - -
(S7)Bloquear tarjeta S1 - - -
Tabla 9. Transición de estados por eventos, adaptado de [28]

2. La segunda aproximación, define por cada columna de la tabla la transición, el estado


inicial, el evento, la acción y el estado final y representa cada caso de prueba. En la Tabla
10 se representa el ejemplo de la Ilustración 17.

Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 Caso 7 Caso 8


Transi
T1 T2 T3 T4 T5 T6 T7 T8
ción
Estado
S1 S2 S3 S3 S4 S4 S5 S5
inicial
Inserta Ingreso Clave Clave Clave Clave Clave Clave
Evento
tarjeta de clave incorrecta correcta correcta incorrecta correcta incorrecta
Mensaje Mensaje Mensaje Mensaje
Solicita Recibe Solicita Solicita
Acción clave clave clave clave
clave clave clave clave
correcta correcta correcta incorrecta
Estado
S2 S3 S4 S6 S6 S5 S6 S7
final
Tabla 10. Transición de estados por transición, adaptado de [27]

Los casos de pruebas deben identificar: el estado inicial, las entradas del sistema o eventos, los
resultados esperados (acciones) y el estado final esperado. [32]

37
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

3.6.1.6 Casos de uso


Técnica de pruebas que se basa en los casos de uso del sistema, debido a que brindan información
importante y completa del sistema, específica las funcionalidades del negocio, los escenarios, los
flujos de procesos entre el sistema y el actor, describen los usos particulares del sistema para
cada usuario u otro sistema, presenta el sistema de principio a fin. [2],[28],[21]. “Un sistema se
describe por la suma de sus casos de uso”.[31] Las ventajas de los casos de uso son:

 Los casos de uso manejan lenguaje natural con términos del negocio y no un lenguaje
técnico. [28], [21] Describe las interacciones de los usuarios con el sistema de manera
secuencial. [28] ,[21]
 Los casos de uso tiene precondiciones que el sistema debe cumplir antes de la ejecución y
post condiciones que indican los resultados finales del que el sistema luego de su
ejecución.[2]
 Los casos de uso describen un flujo del sistema principal basado en el uso más probable y
otros flujos asociados que describen las posibles excepciones que se pueden presentar.
[28]
 Cada escenario de un caso de uso representa un caso de prueba.[31]
 Permite asegurar el cumplimento de los requerimientos del sistema y las expectativas del
usuario.[31] Por lo tanto son una base para las pruebas de aceptación.[27]
 Dentro de los casos de pruebas se deben incluir los flujos normales de los actores
descritos en los casos de uso, los flujos de las excepciones o variantes que se describan, la
información adicional suministrara información sobre el propósito de la prueba, las
precondiciones . [27]

En la Tabla 11, se presenta la descripción del caso de uso de acceso a la cuenta del ejemplo de
la Ilustración 17.

Caso de uso Acceso a la cuenta de un cliente a través de su tarjeta


Objetivo Describir el flujo de acceso a la cuenta a través de la tarjeta de un cliente
Actor Cliente tarjeta
Usuario con tarjeta activa
Precondiciones
Cuenta sin bloqueo
Descripción
No
No
pas Actor Sistema
paso
o
Flujo normal
1 Inserta la tarjeta 2 Valida tarjeta y solicita clave
3 Ingresa la clave 4 Valida clave
5 Permite el acceso a la cuenta
2a Tarjeta no valida: el sistema presenta mensaje y rechaza la tarjeta
Clave no valida: el sistema presenta mensaje y permite realizar reintento
4a
Excepciones de clave
Clave invalida 3 veces: el sistema bloquea la tarjeta y no permite el
4b
acceso.
Post Actor accede a su cuenta

38
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

condiciones
Tabla 11. Descripción caso de uso, adaptado de [28],[27]

3.7 Basadas en la experiencia


Esta técnica de pruebas, se basa en la habilidad, intuición, conocimiento, imaginación y
experiencia de la persona que ejecuta las pruebas y representan un factor decisivo en el éxito y la
calidad de los casos de pruebas derivados.[2], [21]

Aportan un valor agregado en la creación de casos de pruebas, debido que permiten identificar
casos especiales que comúnmente no son previstos mediante otros métodos, por lo tanto estas
técnicas deben ser complemento a las técnicas formales [28], a continuación se presentan las
técnicas: Predicción de error y pruebas exploratorias.

3.7.1 Predicción de error


Como su nombre lo indica, esta técnica busca identificar de manera anticipada los errores que se
pueden presentar en el sistema, se basan en la experiencia, en el conocimiento del sistema, en su
funcionamiento y en el conocimiento de ejecución de pruebas por parte del probador, para
identificar debilidades y los posibles defectos del sistema [28], [31]. Así como también, en el
historial de problemas presentados en versiones anteriores o sistemas similares. [31] Es
importante tener en cuenta los siguientes puntos:

 No existen reglas que especifiquen como adivinar errores [28]


 Los casos de pruebas se creen a partir de las situaciones identificadas como debilidades o
posibles fallas. [28]
 Es importante incluir en los casos de pruebas, eventos que fueron definidos como “Eso
nunca sucede”, debido que son suposiciones que pueden generar errores. [28]
 Una buena práctica, es crear una base de conocimientos de problemas presentados en el
sistema y diseñar casos que lo validen. [2], [28]
 Este enfoque no solamente se puede usar para la validación dinámica del sistema, sino
también en etapas anteriores como son los requerimientos, el diseño, el desarrollo y
posteriores como operación y mantenimiento.[31]
 “Estudios realizados por la IBM Corporation, indican que los mismos tipos de defectos de
software se producen con la misma frecuencia de proyecto a proyecto,.., los expertos en
pruebas de software puede predecir los tipos de defectos que se producirán en el
software.”[31]

3.7.2 Pruebas Exploratorias


En esta técnica de pruebas, se busca realizar pruebas del sistema sin que los casos de pruebas se
encuentren definidos de manera formal, pero se cuenta con el conocimiento del alcance de la
prueba, el enfoque de las pruebas y problemas esperados en una “carta de pruebas” que presenta
dicha información.[2],[28]

39
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

 Útil cuando se cuenta con poca documentación, mala calidad de las especificaciones de los
requerimientos, “y existe una importante presión temporal”[2]
 Los casos de prueba y su ejecución se realizan de manera inmediata. [28]
 Las pruebas exploratorias se realiza de manera simultánea: el aprendizaje, el diseño de la
prueba y la ejecución de pruebas. [27], por lo tanto a medida que se ejecutan pruebas, se
va generando la documentación de las pruebas, se realiza el reporte de defectos y en caso
de identificar nuevos eventos, estos son incluidos. [28]
 Un aspecto importante sobre esta técnica es el aprendizaje del software por parte del
ejecutor de pruebas: su uso, sus fortalezas y sus debilidades. [28]
 Permite complementar otras técnicas de pruebas. [28]
 Si el probador tiene experiencia podrá analizar, razonar y tomar decisiones sobre la
marcha. [27]

En la Ilustración 18, se presenta la información sobre lo que permiten conocer las pruebas
exploratorias.[28]

Explorar
Encontrar Identificar en el sistema
•Información del sistema •Que funciona.
(para incluir y mejorar •Que no funciona.
pruebas) [44] •El uso.
•Defectos del sistema. •Fortalezas.
•Debilidades.

Ilustración 18. Pruebas exploratorias

40
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4 Guía Metodológica V2Soft


La guía metodológica para la Validación y Verificación de requerimientos, tomo como base el
proceso de pruebas definido por el “International Software Testing Qualifications Board” ISTQB,
teniendo en cuenta las actividades que corresponden a la etapa del usuario final.

4.1 Proceso de pruebas para la Validación y Verificación de requerimientos


El proceso de pruebas abarca cada una de las actividades requeridas antes, durante y después de
la ejecución de pruebas, estas actividades permiten planear con anterioridad las pruebas a
ejecutar, reconocer las precondiciones, los criterios de éxito, así como la evaluación de los
resultados obtenidos, estas actividades brindan un apoyo al desarrollo de las pruebas, a su
comprensión y permiten organizar el proceso de pruebas. [33]

4.1.1 Componentes proceso


A continuación, en la Tabla 12 se presentan los componentes del proceso de pruebas para la
Validación y Verificación de requerimientos.

Componente del Descripción


proceso
- Definir el proceso para la Validación y Verificación de
requerimientos para el usuario final, donde se presentan las
Objetivos actividades que se deben implementar.
- El proceso permite garantizar, constar la calidad y funcionalidad del
sistema requerido para la empresa.
- Las actividades correspondientes a ejecución, se deben realizar
cuando el sistema es entregado al área dueña del proceso de
Validación y Verificación de requerimientos.
- Existen actividades que se pueden y deben realizar con antelación a
la ejecución de pruebas.
Reglas del proceso y
- Para dar inicio al proceso, se debe contar con los documentos
del negocio.
requeridos y descritos en “Información / Objetos”
- La aprobación del proceso de Validación y Verificación de
requerimientos, se debe contar con un ente certificador que evalúe
objetivamente los resultados del proceso, y será el encargado de la
funcionalidad en el ambiente productivo.
- Documento de especificación de requerimientos: Define los
requerimientos que debe cumplir el sistema.
Información / - Documentos técnicos que permitan complementar información
Objetos para pruebas (Opcional): Permite conocer las consideraciones
técnicas que se tuvieron para el cumplimiento del desarrollo de los
requerimientos. En algunos casos dentro de la documentación

41
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

técnica se encuentran los casos de uso del sistema, que permiten


conocer la interacción de los usuarios con los escenarios del
sistema.
- Documento de pruebas sugeridas: Documento con las pruebas
sugeridas por parte del área de tecnología.
- Presentación del diseño técnico: La presentación del diseño
técnico, permite conocer los impactos del requerimiento sobre
otras funcionalidades ya existentes.
- Presentación de entrega al área (Necesaria para dar inicio a la
ejecución de pruebas, más no del proceso): En la presentación se
entrega de manera formal los cambios en el sistema, se informa los
impactos y las consideraciones que deben ser tenidas en cuenta
para el proceso de pruebas.
- Las medidas de desempeño se toman de las actividades de cierre
del proceso.
- En general se tendrán en cuenta las siguientes medidas del
proceso:
• Funcionalidades: Mediciones relacionadas con las
funcionalidades probadas durante el ciclo. [34]
Medidas de
• Casos de prueba: Mediciones relacionadas con la planificación,
desempeño
diseño y ejecución de los casos de prueba. [34]
• Incidentes: Mediciones relacionadas con los incidentes
encontrados durante un ciclo de pruebas. [34]
• Esfuerzo: Tiempo invertido en realizar las actividades del
Proceso. [34]
• Obstáculos: Problemas presentados durante las pruebas. [34]
El líder del proceso debe ser el jefe del departamento encargado de la
Validación y Verificación de requerimientos y el gerente del área de
Líder de proceso
aseguramiento de la calidad de la empresa quien vela por el
cumplimento de las políticas del proceso.
Las áreas o departamentos que se relacionan con el proceso de
Validación y Verificación de los requerimientos, son:
- Área de procesos: Se encarga del levantamiento y especificación
de los requerimientos.
- Área de tecnología: Se encargan de analizar los requerimientos,
Unidades o generar un diseño técnico, tercerizar el desarrollo, realizar gestión
departamentos sobre los desarrollos, entregar la solución al departamento de
Validación y Verificación de requerimientos.
- Área de aseguramiento de la calidad: Se encarga de garantizar el
proceso de Validación y Verificación de los requerimientos y de
gestionar los cambios.

42
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

El departamento encargado del proceso de Validación y


Verificación de requerimientos, debe estar conformado por sub
áreas que corresponden a las coordinaciones del proceso, siempre
y cuando sea necesario dividir en grupos las especialidades de los
temas y aplicaciones que manejan.
Por ejemplo, en el ámbito universitario, se pueden dividir por
facultades o carreras, o bien por nivel de estudio (pre
universitario, pregrado o posgrado) y en cada división manejan
sus propias aplicaciones.
O bien, en un nivel más general: Se divide la universidad en:
estudiantes, profesores y empleados de bienestar universitario.
En la coordinación de estudiantes se tendrán aplicaciones para la
gestión de matrícula y consulta cursos, otra para materias
virtuales y otra aplicación para el seguimiento académico. En el
caso de la coordinación de los profesores, se tendrá una
aplicación de gestión de estudiantes (notas), una aplicación para
la gestión de materias y una aplicación para gestión de sus
investigaciones. Y en el caso de la coordinación de los empleados
de bienestar universitario, se tendrán varias aplicaciones que
permitan por ejemplo: la gestión de las matriculas, la gestión de
egresados y aspirantes, la gestión de los recursos de la
universidad, la gestión de los recursos de biblioteca, la gestión de
la página web de la universidad.
La división en coordinaciones, hace que el trabajo se divida en
especialidades, que cada especialidad conozca mejor el negocio y
la cooperación del trabajo en equipo, muchas veces será
necesario solicitar datos o transacciones a otra coordinación.
- Área de usuario: Se encarga de dar soporte a la operación del día
a día, en el proceso es el encargado de certificar el sistema objeto
de las pruebas.
En la Ilustración 19, se presenta la organización de la empresa.
Los roles del proceso de Validación y Verificación de requerimientos,
está conformado por:
1. Jefe del departamento: Es el encargado de atender las necesidades
de los coordinadores, suministrar los recursos que se requieren y
Roles y trabajo en en caso de ser necesario escalar los inconvenientes que se
equipo presenten en el proceso a instancias más altas para la gestión.
Adicional:
a. Supervisa el cumplimiento de la estrategia de Pruebas.
b. Define la Metodología y el proceso de Pruebas
2. Coordinadores de equipos de pruebas: Son los responsables de

43
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

coordinar los equipos de pruebas y realizar seguimientos.


Adicional:
a. Difunde a su equipo de trabajo los Objetivos, estándares,
alcance y propósitos definidos en la estrategia de pruebas
b. Asegura que las prácticas y metodología de pruebas definida
en la estrategia de pruebas se cumplan por el equipo de
trabajo.
c. Coordina reuniones de estatus de los proyectos.
d. Coordina las necesidades de pruebas con sistemas externos
3. Equipo de pruebas: Líder de pruebas, Analista de pruebas y
Ejecutor de pruebas. Para mayor detalle ver la sección 4.1.2.
En la Ilustración 20, se presenta la relación de los roles y trabajo en
equipo para el proceso.
Flujo del proceso El flujo del proceso se encuentra definido en la Ilustración 21.
El medio de comunicación principal del proceso hacia las áreas
interesadas, será el correo electrónico donde se enviara los avances de
Medios de las pruebas y cada vez que sea necesario, las inquietudes o solicitudes.
comunicación Se deben realizar reuniones periódicas con el equipo de pruebas
donde se valide el avance, las necesidades y los inconvenientes que se
vayan presentando.
Se debe contar con herramientas de ofimática para realizar los
documentos, cálculos y toma de evidencias requeridas.
Adicional es necesario que se cuente con:
Tecnología
- Herramienta para la ejecución de casos de pruebas.
- Herramientas para la gestión de incidentes.
- Equipos para la ejecución de las pruebas.
Tabla 12. Componentes proceso de Validación y Verificación de requerimientos

Unidades o departamentos

Empresa

Área de
Área de Área de Área de
aseguramiento
procesos tecnología de la calidad
usuario

Departament
o encargado
V&V

Ilustración 19. Áreas de empresa

44
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Roles y trabajo en equipo

Departamento
Coordinación Coordinación Coordinación
encargado
1 2 n
V&V

Lider de
pruebas

Equipo de Analista de
pruebas 1 pruebas
Coordinador
1
Equipo de Ejecutor de
Jefe pruebas n pruebas
departameto
Coordinador Equipo de
n pruebas 1

Ilustración 20. Roles y trabajo en equipo

4.1.2 Equipo de pruebas y roles


El equipo de pruebas, debe estar conformado por un grupo de personas que tengan
conocimientos tanto funcionales en aplicaciones como técnicas relacionadas a pruebas, se
considera que el equipo debe presentar los roles de: Líder de pruebas, Analista de pruebas y
Ejecutor de pruebas.

En cuanto a las capacidades, James McCaffre en [35] definió ocho cualidades que identifica a un
buen probador de software y que el equipo de pruebas debería tener, las siete primeras son
cualidades tácticas, mientras que la octava hace referencia a una cualidad analítica que a
continuación son presentadas:

1. Pasión por el análisis y las pruebas: el éxito de cualquier trabajo radica en tener pasión
por lo que se hace. [35]
2. Habilidades técnicas: Para poder comprender el sistema que prueba. [35]
3. Capacidad Intelectual pura: Debe ser una persona inteligente con capacidades lógicas y
analíticas que debe emplear en el momento de realizar las pruebas. [35]
4. Capacidad para priorizar y organizar: Por la dinámica de los proyectos que presentan
cambios constantes, el probador debe tener la capacidad de reconocer, interpretar y
organizarse en torno a los factores de cambio. [35]
5. Capacidad de adaptación y aprendizaje: Debe estar en constante aprendizaje y buscando
mejorar sus habilidades, debido que las tecnologías evolucionan a diario. [35]

45
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

6. Capacidad para trabajar sin supervisión directa: Realizar el trabajo sin la necesidad que
otra persona supervise el trabajo, debe tener la capacidad de diferenciar las actividades
que requieren una gestión adicional para continuar con su trabajo. [35]
7. Capacidad para comunicarse: Debe tener habilidades de comunicación tanto verbal como
escrita, ser capaz de leer y analizar los documentos del sistema, escribir planes de prueba,
realizar reportes de errores claros, realizar informes sobre el estado de las pruebas, y
tener la capacidad de escuchar y hablar críticamente en las reuniones. [35]
8. Capacidad para comprender la estrategia de negocios: la capacidad de ver el panorama
más amplio de la estrategia general de negocios de una empresa, participando
activamente, puede identificar las fortalezas y debilidades estratégicas de un sistema de
software. [35]
Otras características definidas para un buen probador son:
1. Inteligente: Las pruebas son un trabajo intelectual.[27]
2. Creativo: Las pruebas deben ser inventivas y a su vez eficaces. [27]
3. Perseverante: Muchas veces durante el proceso es necesario repetir una y otra vez más
las pruebas, por lo tanto la persona tiene que realizar cada vez sus labores a pesar de la
resistencia y de la presión. [27]
4.1.2.1 Roles
A continuación se presenta la descripción y las funciones de los roles Líder de pruebas ver Tabla
13, Analista de pruebas ver Tabla 14 y Ejecutor de pruebas ver Tabla 15.

Rol Líder de pruebas


Persona encargada de dirigir el proyecto que se encuentra en la etapa de
Descripción pruebas de software, es el responsable de realizar la gestión del proceso y
coordinar al equipo de pruebas.
1. Definir la estrategia y los objetivos de las pruebas.[33]
2. Gestión de las pruebas: Estimaciones y planificación, seguimiento y
control [27]
3. Presentación de informes [27]
4. Gestión de personas (Analistas de pruebas y ejecutores de
pruebas)[27], [33]
5. Establecer la comunicación entre el equipo de trabajo. [33]
6. Analiza los documentos de “Información / Objetos” para
Funciones y
determinar la información de los Casos de prueba (Objetivo,
responsabilidades
descripción, alcance y precondiciones de ejecución)
7. Apoya al analista de pruebas en el desarrollo de casos de prueba y
al ejecutor de pruebas a identificar posibles defectos.
8. Es el responsable de validar la documentación requerida para el
diseño y desarrollo de Casos de prueba.
9. Administra los defectos del proyecto, revisa las respuestas recibidas
por parte de tecnología y asigna responsables para la validación de
las soluciones.

46
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

10. Gestiona con los encargados, la solución de los problemas


presentados en el ambiente de pruebas.
• Plan de pruebas. [36]
Artefactos a cargo
• Resumen de resultado de pruebas. [36]
• Liderazgo.
• Comunicación.
• Negociación.
• Capacidad para la toma de decisiones y resolver problemas.
Conocimientos y
• Conceptos básicos de pruebas
habilidades
• Técnicas de desarrollo de pruebas
• Gestión de Riesgos
• Administración, registro y levantamiento de defectos.
• Técnicas de estimación y ejecución de pruebas.
Tabla 13. Rol líder de pruebas

Rol Analista de pruebas


Persona encargada de analizar el sistema a probar para identificar y definir
Descripción
las pruebas requeridas.
1. Estructurar las tareas definidas en la estrategia de pruebas. [33]
2. Analizar el sistema a profundidad. [33]
3. Evaluar y analizar los requerimientos del sistema y documentos que
presenten especificaciones para determinar la validez del dominio
[27], [33]
Funciones y
4. Preparar y ejecutar las actividades adecuadas e informar sobre
responsabilidades
cómo progresan
5. Diseñar casos de pruebas usando técnicas para el diseño.[27]
6. Identifican y generan los datos de pruebas requeridos para la
ejecución de las pruebas, en caso de ser necesario realizan la
solicitud a los dueños de la data.
• Casos de pruebas. [36]
Artefactos a cargo • Datos de pruebas. [36]
• Resultados de pruebas. [36]
• Técnicas de pruebas
• Capacidad de redacción y escritura
Conocimientos y
• Conceptos básicos de pruebas
habilidades
• Técnicas de desarrollo de pruebas
• Registro y levantamiento de defectos.
Tabla 14. Rol analista de pruebas

47
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Rol Ejecutor de pruebas


Descripción Persona que ejecuta los casos de pruebas aprobados.
Funciones y 1. Verificar y ejecutar los casos pruebas. [27]
responsabilidades 2. Analizar y recolectar las evidencias de las pruebas. [27]
3. Realiza la validación de resultados. [27]
4. Realiza el reporte de inconsistencias en la herramienta definida.
5. Informa al líder de pruebas los inconvenientes presentados en la
ejecución de pruebas
Artefactos a cargo • Registro de pruebas
Conocimientos y • Capacidad de análisis de resultados.
habilidades • Capacidad de redacción y escritura.
• Conceptos básicos de pruebas
• Técnicas de desarrollo de pruebas
• Registro y levantamiento de defectos.
Tabla 15. Rol ejecutor de pruebas

4.1.3 Proceso de pruebas de acuerdo al ISTQB


El proceso de pruebas, de acuerdo al ISTQB [33], está conformado por los cinco sub procesos:
“Planeación y control”, “Análisis y diseño”, “Implementación y ejecución”, “Evaluación de criterio
de éxito e informes” y “Actividades de cierre”. En Ilustración 21, se presentan el proceso de
pruebas, que se desarrollaran a lo largo de esta sección, este proceso no es el único que existe y
cada empresa debe acoplar su propio modelo a sus necesidades.[27]

Las actividades se realizan de manera secuencial, pero es posible que en algunos casos se ejecuten
de manera paralela [33].

Ilustración 21. Proceso de pruebas, adaptado de [37]

4.1.4 Actividades de proceso de pruebas en el modelo en V


El proceso de pruebas se considera parte de la totalidad del ciclo de vida de desarrollo de
software, por lo tanto debe estar alineado el proceso con el modelo de ciclo de vida en V. [33]

Las actividades del proceso de pruebas y el modelo en v, pueden alinearse de la siguiente manera:

- La planeación de las pruebas es simultánea a la planificación del proyecto. [33]


- El control debe existir durante todo el modelo del ciclo de vida hasta la actividad de cierre.
[33]

48
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

- El análisis y diseño de las pruebas concurren con la especificación de los requerimientos, la


especificación del diseño de alto y bajo nivel. [33]
- La implementación del entorno de pruebas puede iniciarse durante el diseño del sistema,
aunque algunas veces esta actividad se realiza días antes de la ejecución de pruebas. [33]
- La ejecución de pruebas de sistema se realizan cuando se cumplen los criterios de entrada
de las pruebas de sistema, en el caso de la guía se deben iniciar cuando se hayan finalizado
las pruebas unitarias y de integración de componentes. [33] Y deben realizarse hasta que
se cumplan los criterios de aceptación definidos.
- La evaluación de criterios de salida y la elaboración de informes sobre los resultados de las
pruebas, se deben realizar a lo largo de la ejecución de las pruebas. [33]
- Las actividades de cierre, se realizan cuando se cumplan con todos los criterios de salida
de las pruebas y se han completado las ejecuciones de las diferentes pruebas. [33]

El proceso de pruebas debe poderse modificar en función del contexto del proyecto y estar
conforme al ciclo de vida de desarrollo. En la Ilustración 22, se presenta el modelo en V y las
actividades del proceso de pruebas.

Ilustración 22. Actividades modelo en V de acuerdo al proceso ISTQB, adaptado de [21]

El proceso de pruebas adaptado al modelo en v, se presenta en la Ilustración 23 y en la Ilustración


24 el subproceso de pruebas.

49
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 23. Proceso de pruebas, adaptado del modelo en V

Ilustración 24. Subproceso pruebas

50
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2 Actividades procesos de pruebas para la Validación y Verificación de


requerimientos
El estándar de la ISO/IEC/IEEE FDIS 29119-2 [37], define el proceso de pruebas en dos grupos de
niveles, el primero que corresponde a la gestión de pruebas y el segundo al proceso dinámico de
las pruebas, donde se agrupan las tareas del proceso de pruebas, ver Ilustración 25.

Proceso de planificación de pruebas

Proceso de Nivel de gestión de Seguimiento y control al proceso de


pruebas prueba pruebas

Definiciones del Proceso de cierre de pruebas


proceso de pruebas
de la organización
como politicas,
estrategias, procesos Diseño e implementación de
y procedimientos. pruebas
Configuración y mantenimiento de
Nivel dinámico de pruebas
pruebas Ejecución de pruebas

Repote de incidentes de pruebas

Ilustración 25. Niveles del proceso de pruebas

En esta sección se presentan la descripción de las actividades del proceso de pruebas presentado
en la Ilustración 23 y la Ilustración 24.

4.2.1 Planeación
La planeación de pruebas, establece la información necesaria para la ejecución de las pruebas, su
propósito es verificar la misión de las pruebas, para definir los objetivos y para la toma de
decisiones, y así transformar la estrategia en un plan operativo que permita su ejecución.[27]

La planificación, se realiza al inicio del proyecto y permitirá identificar las actividades y los recursos
necesarios. [33] Las actividades definidas se podrán ejecutar a lo largo de este e
independientemente del modelo de ciclo de vida que se adopte.

En la Tabla 16, se presenta la descripción de la actividad de planeación.

51
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ítem Definición
Actividad Planeación
Actividad que busca realizar la planeación del proceso de pruebas para
Descripción
el sistema que requiere la Validación y Verificación de requerimientos.
Definir el plan de pruebas, los objetivos, alcance, enfoque, recursos y
Objetivo
cronograma de las actividades de pruebas.
- Documentos de especificación de los requerimientos
Entradas
- Documentos técnicos
Participante - Líder de pruebas
Realizar documentos de:
Forma de trabajar - Generar el plan de pruebas.
- Identificar los riesgos asociados al proceso
- Documento de plantilla para el plan de pruebas
Forma de soportar
- Métodos para la estimación de tiempos
Forma de Modelar - Clasificación de las actividades en el cronograma
Mediante la actividad de control, se realizara seguimiento del plan de
Forma de controlar
pruebas durante todo el proyecto.
- Plan de pruebas.
Salidas
- Documento de riesgos identificados.
Tabla 16. Descripción actividad Planeación

Debe existir una primera planificación a nivel global de donde resulta un plan de pruebas maestro,
luego se realiza la planificación detallada para cada nivel de pruebas basado en el plan principal,
donde se definirán las actividades .[27]

Para construir el plan de pruebas, se debe realizar las siguientes tareas:

1. Definir el alcance, los riesgos y los objetivos de las pruebas.


a. En el alcance, incluir el sistema al que se le realizaran pruebas, por ejemplo:
Modulo, producto, software u otro. [28]
b. En los riesgos, incluir los riesgos identificados a nivel de negocio, sistema o
proyecto para que se tengan en cuenta para su mitigación.[2],[28]
c. El propósito de las pruebas, debe definir la intención de las pruebas, por ejemplo:
validar que el sistema cumpla con los requerimientos, validar que el sistema
cumple con el propósito. [28]
2. Definir las necesidades para la ejecución de las pruebas: el método a emplear, como se
llevaran a cabo, las técnicas a usar, la cobertura, participantes y momentos de ejecución,
que se tendrá como resultado, como se documentara el resultado.[28]
3. En caso que la organización cuente con políticas de pruebas o una estrategia para las
pruebas, se debe asegurar que el plan cumpla con las definiciones. [28]
4. Definir los recursos requeridos para la ejecución de las pruebas, estos pueden ser recursos
humanos, hardware y software. [28]
5. Definición del calendario de pruebas, actividades y tareas para: el análisis y diseño de
pruebas, ejecución de pruebas y evaluación de los resultados.[28]

52
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

6. Definir los criterios de salida y los criterios de cobertura, que permitirán registrar el avance
de las pruebas. Definir las tareas y los controles que se deben completar en cada nivel
prueba para determinar cuándo se finaliza la prueba. [28]

En la Ilustración 26, se presentan las entradas y salidas de la actividad de planeación.

Plan de
pruebas
Documento de
requerimientos

Planeación Cronograma
de pruebas

Documento
técnicos
Plan de
métricas

Entradas Salidas
Ilustración 26. Entradas y salidas de planeación

A continuación se presenta la Ilustración 27, donde se encuentran las consideraciones y


recomendaciones para la actividad de planeación

Consideraciones Recomendaciones

Cuando se presenten
restricciones para la
ejecución de las pruebas,
En el documento de plan incluir la definición en el
de plan de pruebas plan de pruebas
incluya diagramas que
faciliten la comprensión
del documento. Por Definir el alcance de manera
ejemplo incluir diagrama clara ya que este establecera
grant para el cronograma el limite de las pruebas.

Deje por escrito todas las


limitantes del proyecto

Ilustración 27. Consideraciones y recomendaciones planeación

53
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.2 Herramientas para la planeación


A continuación se incluyen dos herramientas para la planeación:

- La plantilla para el plan de pruebas


- Información sobre la estimaciones

4.2.2.1 Plantilla Plan de pruebas

Para la creación del plan de pruebas se propone el uso de plantillas que presenten la información
requerida. A continuación, se realiza la descripción de una plantilla basada en [12]. Ver anexo 6.1

54
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

55
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 28. Plantilla SVVP

4.2.2.2 Estimación de tiempos


Para realizar el cronograma de pruebas, se requiere definir el tiempo que será empleado para las
actividades, lo que obliga a que se realice una actividad que corresponde a la estimación de
tiempos.

La estimación corresponde a una actividad de predecir la cantidad de tiempo que se necesita para
realizar una tarea, se basa en un cálculo aproximado que tiene una probabilidad de ser cierta y
permitirán realizar una planeación más efectiva sobre el esfuerzo, los recursos, y tiempo necesario

56
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

para realizar el proceso de pruebas. [27],[38] Por lo tanto es importante recordar que las
estimaciones son sobre el futuro, lo que significa que son inciertas, por lo que se pueden o no
cumplir.

Existen muchas maneras de expresar las estimaciones, pero se recomienda que sean expresadas
en términos de horas, con el fin de no comprometer fechas que se pueden ver afectadas por
factores externos al proceso de pruebas. [27]

Las estimaciones deben documentarse y se debe incluir un cálculo de incertidumbre de la


estimación. Por otra parte, las estimaciones deberían siempre acompañada de la justificación,
junto con cualquier hipótesis y requisitos previos. [27]

4.2.2.3 Principios para la estimación


Para realizar la estimación, es importante tener en cuenta los siguientes aspectos:

- Se deben incluir todas las actividades y tareas que se presentan en el proceso, desde la
planificación de las pruebas hasta la comprobación final. [27]
- La estimación del proceso de pruebas, difiere de otras estimaciones, porque depende del
el número de defectos que se pueden presentar en el software. Este número no se
conoce de antemano sino hasta la ejecución de pruebas, aunque se puede estimar. [27]
- El número de iteraciones necesarias, como regla general, se dice que al menos tres
iteraciones deben tenerse en cuenta, aunque en algunos casos no es suficiente, a menos
que el criterio de finalización sea la ejecución de todos los casos de prueba, e
independiente del número de defectos pendientes de solución y la cobertura de las
pruebas. [27]
- La estimación del proceso de pruebas debe incluir el tiempo para:
o El reporte de defectos. [27]
o El análisis de defectos.[27]
o La corrección de defectos[27]
o Realizar pruebas de regresión y validación de las soluciones (mínimo tres
iteraciones) [27]
- La corrección de los defectos reportados, pueden introducir nuevos defectos en el
sistema o hacer evidente fallos que antes existían y que no se habían reportado. En la
literatura de las pruebas en base a la experiencia en general, señalan que el 50% de la
cantidad original de defectos permanece después de la corrección distribuidos de la
siguiente manera[27]:
o Defectos persistentes después de la corrección: 20% [27]
o Defectos antes no evidenciados después de la corrección:10% [27]
o Nuevos defectos después de la corrección: 20% [27]
Por ejemplo, si en la primera iteración se reportaron 100 defectos, en la segunda iteración
se tendrían 50 defectos, 25 defectos en la tercera iteración y 12 defectos en una cuarta
[27], ver Tabla 17.

57
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Cantidad de defectos
Segunda iteración
anterior iteración
20% 20
10% 10
1ª iteración: 100
20% 20
Total Defectos iteración 2 50
Tercera iteración
20% 10
2ª iteración: 50 10% 5
20% 10
Total Defectos iteración 3 25
Cuarta iteración
20% 5
3ª iteración: 25 10% 2,5
20% 5
Total Defectos iteración 4 12,5
Tabla 17. Cantidad defectos por iteración

4.2.2.4 El proceso de estimar


Para la guía metodológica, se define el proceso de la Ilustración 29 para realizar una estimación,
en la Tabla 18. Se describe las actividades del proceso.

Ilustración 29. Proceso de estimación.

Detalle de las actividades del proceso de estimación.

58
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Actividad Descripción
En esta actividad se define el propósito de la estimación. ¿Es la
Definir el propósito primera estimación de una propuesta, o es una planificación
detallada? [27]
Definir las tareas Realizar la planificación de las tareas para realizar la estimación. [27]
Definición de las bases para la estimación, se debe incluir: El alcance,
el tamaño del objeto de la estimación y los factores que pueden
Definir las bases influir en la estimación, como por ejemplo: La naturaleza del
proyecto y del proceso, las personas con las que se trabaja y los
riesgos a los que se enfrenta. [27]
En esta actividad, se definen todas las actividades en relación con el
Definir las actividades a
propósito que se van a incluir en la estimación de manera
estimar
desglosada. [27]
Esta actividad corresponde a la estimación por medio de técnicas
Realizar estimación
apropiadas para dicho fin. [27]
Comparar estimación Esta actividad, hace referencia al monitoreo y control continuo del
versus realidad trabajo estimado versus el que realmente se va realizando. [27]
Tabla 18. Descripción de actividades del proceso de estimación

4.2.2.5 Técnicas de estimación


Existen diferentes técnicas de estimación que se presentadas a continuación en la Tabla 19, se
realizara énfasis en la técnica de puntos de función que corresponden a la técnica que tendrá en
cuenta en la guía.

Técnica Descripción
Esta técnica se basa en el juicio de la persona que realiza la estimación,
de alguna u otra manera se basa en la experiencia y en supuestos
(inconscientes).
FIA (finger in the air) o
Esta técnica es inexacta por lo tanto el nivel de confianza es baja y a
mejor conjetura
menudo no es repetible.
La incertidumbre en esta estimación es alrededor de un 200% a un
400%.
Esta técnica se basa en el conocimiento adquirido en otros proyectos
similares, dependiendo la información con la que se cuente:
1. Se compara tiempo que se tomó la ejecución con la cantidad de
personas, se compara con el proyecto actual en cuanto a tamaño
Basado en la
(más grande o pequeño) y cantidad de personas disponibles. para
experiencia ; Analogías
suponer un tiempo. [27]
y expertos
2. Se puede basar en métricas recogidas de pruebas anteriores:
- Estimar el número de iteraciones de pruebas necesarias sobre
la base de los registros de los últimos esfuerzos de pruebas
similares. [27]

59
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

- Calcular el esfuerzo promedio requerido para una prueba, en


base al esfuerzo implementado en las pruebas anteriores y se
multiplica por el número de pruebas estimadas para
determinar el esfuerzo requerido. [27]
Se debe nombrar un grupo para la estimación, se puede incluir a las
partes interesadas o expertos en las tareas que se estiman.
Los pasos para esta técnica son:
1. Cada miembro del grupo da una estimación.
2. El grupo es informado sobre la media y la distribución de las
estimaciones.
3. Las estimaciones dan en el cuartil inferior y uno superior. La
persona que dio el valor del cuartil superior debe explicar la
estimación realizada.
Técnica Delphi
4. El grupo estima de nuevo, teniendo el resultado anterior y los
argumentos proporcionados.
5. Este ciclo se puede realizar varias veces hasta que la variación en
las estimaciones es suficientemente pequeño.
Por lo general, el promedio de las estimaciones no cambia mucho, pero
la variación se reduce rápidamente. Esto le da confianza en el resultado
de la estimación final.
La técnica se puede combinar con otras técnicas, por ejemplo los
participantes pueden dar sus estimaciones en base a otras técnicas. [27]
La estimación de tres puntos es un cálculo estadístico de la probabilidad
para terminar dentro de un tiempo dado, es útil para cuantificar la
incertidumbre de la estimación. [27]
La técnica también se conoce como el cálculo sucesivo porque las tareas
son descomponen y las estimaciones son calculadas sucesivamente
hasta que la varianza se encuentra dentro de límites aceptables. [27]
Tres puntos de
Estimación de tres puntos se basa en tres estimaciones:
estimación
1. El momento más optimista (condiciones ideales)
2. El momento más probable (si hacemos lo de siempre)
3. El momento más pesimista (Murphy está con nosotros hasta el
final)
A partir de estas tres estimaciones es posible definir la función de
distribución por el tiempo para terminar.
La estimación se basa en un modelo del producto, por ejemplo, la
especificación de los requerimientos o un prototipo, presenta las
Estimación Puntos
siguientes características:
basada en de
- Un usuario para los puntos de función comprende el sistema, desde
modelos función
un punto de vista funcional. [39]
- Como los puntos de función miden los sistemas desde el punto de

60
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

vista funcional, son independientes de la tecnología. [39]


- Sin importar el lenguaje, el método de desarrollo, el hardware, la
plataforma, el número de puntos de función, permanecerá
constante. [39]

Tiene en cuenta cinco aspectos del sistema, que se deben contar a


partir del modelo:
1. Entradas externas (EI)
2. Salidas externas (EO)
3. Consultas externas (EQ)
4. Archivos lógicos internos (ILF)
5. Archivos de interfaz externos (EIF)
El valor de cada aspecto se multiplica por un peso asignado y el total de
los recuentos ponderada es la suma sin ajustar. El esfuerzo real en
horas se calcula a partir de un factor de ajuste obtenido de los datos de
proyectos anteriores. [27]
Comparaciones continuas del tiempo real dedicado y las estimaciones
son esenciales para obtener el mejor factor de ajuste. [27]
La técnica se basa en la técnica del punto de función, y proporciona una
unidad de medida para el tamaño de la prueba de alto nivel (sistema y
la aceptación pruebas) a ejecutar. [27]
La técnica convierte los puntos de función en los puntos de prueba
Puntos basados en el impacto de factores específicos que afectan de pruebas,
de como:
prueba • La calidad de los requerimientos.
• El tamaño y la complejidad del sistema.
• La calidad de los documentos base para las pruebas.
• La medida en que se utilizan las herramientas de pruebas.

Esta técnica también es llamada como la estimación de arriba hacia


abajo. La idea fundamental es que los esfuerzos de prueba se derivan
de los esfuerzos de desarrollo. [27] El siguiente paso es utilizar fórmulas
(por lo general porcentajes) para distribuir el esfuerzo total sobre las
tareas definidas, incluyendo las tareas de pruebas. Las fórmulas están
Distribu
basadas en datos empíricos, y varían ampliamente de una organización
ción
a otra, por lo tanto se deben determinar los propios de la organización.
porcent
Si no se cuenta con algún dato se podría suponer que el esfuerzo total
ual
para pruebas es un 25-30% del esfuerzo total del proyecto. [27]
A continuación se incluye una tabla basada en Capers Jones, tomada
de[27].
Actividad Porcentaje (%)
Requerimientos 9.5

61
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Diseño 15.5
Desarrollo 20
Pruebas (Todas las
27
fases)
Gestión de proyecto 13
Gestión de la
3
configuración
Documentación 9
Instalación y
3
capacitación
Tabla 19. Técnicas de estimación, basada en [27]

4.2.2.6 Puntos de función


Para la estimación del esfuerzo requerido en términos de tiempo, se enfocara en el método de
estimación de puntos de función, a continuación se verá en detalle.

El proceso se encuentra dividido en los siguientes seis pasos:


1. Obtener Información del Sistema: La información puede obtenerse de los requerimientos,
modelos o prototipos del sistema.
2. Identificar los Componentes del Sistema: Determinar cuáles son los componentes del
sistema. Existen cinco componentes del sistema, los tres primeros realizan transacciones
contra archivos por lo tanto son llamados transaccionales:
- Entradas externas (EI): Procesos que requieren el ingreso de datos por parte del
usuario u otra aplicación y realiza la actualización de información interna, ver
Ilustración 30.
a) El flujo de los datos es de afuera hacia a adentro. [39]
b) Los datos pueden ser usados para mantener uno o más archivos lógicos.
[39]
c) Los datos pueden ser de control de información, o de información del
negocio.[39]
d) Si los datos son de control de información no se actualizan archivos lógicos
internos, esto puede ser un filtro de búsqueda. [39]

𝐼𝐿𝐹𝐴
EI

ILFB

Ilustración 30. Entradas externas, tomada de [39]

- Salidas externas (EO): Procesos en los que se envía datos al exterior de la


aplicación, ver Ilustración 31
a) Los datos son derivados, el flujo de los datos es de adentro hacia afuera.
[39]

62
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

b) Pueden actualizar archivos internos lógicos (ILF). [39]


c) Los datos crean reportes o archivos de salida para enviar a otras
aplicaciones. [39]
d) Estos reportes y archivos son creados por uno o más archivos lógicos
internos, y archivos de interface externa. [39]

𝐼𝐿𝐹𝐴
EO
𝐼𝐿𝐹𝐵

Ilustración 31. Salidas externas, tomada de [39]

- Consultas externas (EQ): Procesos donde existe la combinación de una entrada y


una salida.
a) Un proceso elemental, con componentes de entrada y salida que resultan
de la obtención de datos de uno más archivos internos lógicos e archivos
de interface externa. [39]
b) La entrada del proceso no hace ninguna actualización de archivos lógicos.
[39]
c) La salida no contiene datos derivados. [39]

Los 2 siguientes son donde los datos son almacenados y combinados para formar la
información lógica.
- Archivos lógicos internos (ILF): Grupos de datos relacionados entre sí,
identificables por el usuario, que residen dentro del límite de la aplicación, y es
mantenido por entradas externas. [39]
- Archivos de Interfaces externas (EIF): Grupos de datos que se mantienen
externamente.
a) Un grupo de datos lógicamente relacionados, identificables por el usuario,
que son usados, únicamente, con propósitos de referencia. [39]
b) Los datos residen por fuera del aplicativo, y son mantenidos por otra
aplicación. [39]
c) Los archivos de interfaz externa, son los lógicos internos de otras
aplicaciones. [39]
3. Calcular el número de elementos del componente y su complejidad
Los elementos deben ser contados y calificados de acuerdo a su complejidad, se asigna un
valor entre alto, promedio o bajo.[39]
o Para las transacciones, la valoración se basa en el número de archivos actualizados
o referenciados (FTR3) y el número de tipos de datos (DET4). Se basa en las tablas

3
FTR: corresponden a las siglas en inglés “File Types Referenced”
4
DET: corresponden a las siglas en ingles “Data Element Type”

63
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

de clasificación, para EI ver Tabla 20, para EO y EQ ver Tabla 21 y para ILF y EIF ver
Tabla 22.
o Para los otros dos, la valoración se basa en los tipos de elementos a grabar (RET 5),
y los tipos de datos (DET), ver Tabla 21
Clasificación EI:

Elementos de datos
FTR´s
1–4 5 – 15 Mayor a 15
0-1 Bajo Bajo Promedio
2 Bajo Promedio Alto
3 o más Promedio Alto Alto
Tabla 20. Clasificación EI, tomada de [39]

Clasificación EO Y EQ:

Elementos de datos
FTR´s
1–5 6 – 19 Mayor a 19
0-1 Bajo Bajo Promedio
2 Bajo Promedio Alto
3 o más Promedio Alto Alto
Tabla 21. Clasificación EO y EQ, tomada de [39]

Clasificación ILF y EIF

RET´s Elementos de datos


(registros) 1 – 19 20 –50 Mayor a 50
1 Bajo Bajo Promedio
2-5 Bajo Promedio Alto
5 o más Promedio Alto Alto
Tabla 22. Clasificación ILF y EIF, tomada de [39]

4. Calcular los puntos funcionales sin Ajustar (PFSA)


Para realizar el cálculo de los puntos funcionales sin ajuste, se realiza el cálculo de la
cantidad de transacciones en cada nivel multiplicado por los valores de clasificación
presentaos en la Tabla 23 para las transacciones y en la Tabla 24 para tipo de
información, que relaciona la clasificación (alto, promedio y bajo) y el tipo de transacción
para representar un peso que permite el cálculo de la ponderación de los puntos
funcionales. [39]
Valores
Clasificación
EI EO EQ
Bajo 4 3 3
Promedio 5 4 4
Alto 7 6 6
Tabla 23. Valores de transacciones por clasificación, tomada de [39]

5
RET: Corresponden a las siglas en ingles de “Record Element Type”

64
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Valores
Clasificación
ILF EIF
Bajo 7 5
Promedio 10 7
Alto 15 10
Tabla 24. Valores de por clasificación, Tomada de [39]

Por ejemplo si la cantidad de EI en bajo es 3 y el peso asignado de acuerdo a la Tabla 23 es


4, el punto función para EI con clasificación baja es de 7.
Para realizar el cálculo de todos los niveles se puede usar la Tabla 25, donde se realiza el
cálculo de acuerdo el dominio de la información y los valores de clasificación. Por cada
dominio se realiza la suma en cada nivel y la sumatoria total representa el punto de
función sin ajuste. [39]

Valor del domino Factor de ponderación


de información Bajo Medio Alto Sub Total
Entradas externas
___X 3 =____ ___X 4 =_____ ___X 6 =____ Suma de EI
(EI)
Salidas externas
___X 4 =____ ___X 5 =_____ ___X 7 =____ Suma de EO
(EO)
Consultas ___X 3 =____ ___X 4 =_____ ___X 6 =____ Suma de EQ
externas (EQ)
Archivos de lógica ___X 7 =____ ___X 10 =____ ___X 15 =___ Suma de ILF
interna (ILF)
Archivos de
interfaz externa ___X 5 =____ ___X 7 =____ ___X 10 =___ Suma de EIF
(EIF)
Suma
TOTAL subtotales
(PFSA)
Tabla 25. Calculo de punto de función, tomado de [39]

5. Calcular los puntos funcionales ajustados (PFA)


Para realizar el cálculo de los puntos funcionales ajustados, se requiere realizar el cálculo
del factor de ajuste (VAF) que se basa en la evaluación de las características definidas para
el proceso de pruebas, estas pueden ser modificadas incluyendo o eliminando factores,
para efectos de la guía se proponen los factores presentados en [38] e incluidos en la
Tabla 27, donde se presenta el factor a tener en cuenta y la descripción.
A cada factor se le asigna, un valor que corresponde al grado de influencia en las pruebas,
presentado en la Tabla 26.

65
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Significado del valor Valor


No presente o no influye 0
influencia incidental 1
influencia moderada 2
Influencia promedio 3
Influencia significativa 4
Influencia fuerte 5
Tabla 26. Complejidad el factor, tomada de [39]

Factores Descripción Valor


Entrada sin retrasos de la Se entrega la documentación a tiempo
documentación de para dar soporte al proceso de
pruebas pruebas
Cumplimiento de lo
planificado en el
Se entregan las respuestas a las no
cronograma de pruebas
conformidades en el tiempo pactado
por parte del equipo de
desarrollo
Nivel de capacitación para Capacitación del negocio que se
las pruebas imparte al equipo de pruebas
Existe suficiente personal Se cuenta con los probadores
disponible para la necesarios para la realización de la
realización de la prueba prueba
El personal empleado está En el caso contrario los probadores
familiarizado y no se presentan afectaciones
dificulta la solicitud
Los especialistas y El personal posee la suficiente
probadores poseen experiencia o habilidad en el proceso
experiencias en las de pruebas
pruebas
Especialistas capacitados Nivel de capacitación de los expertos
en herramientas de
en los diferentes técnicas de pruebas y
pruebas el uso de herramientas
Comunicación con los Nivel de comunicación entre el equipo
desarrolladores y el
de desarrollo y el equipo de pruebas
equipo de pruebas en relación a aspectos de pruebas
Existen equipos expertos para la
Entorno de pruebas
preparación de e senarios de pruebas
Nunca existen fallos en la electricidad
Problemas técnicos
o en la conexión de la red
Disponibilidad de puestos Existen computadores necesarios para
de trabajo realizar las pruebas
La documentación a probar no tiene
Documentación técnica
complejidad técnica
Tabla 27. Factores puntos de función para pruebas, adaptado de [38]

66
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

La sumatoria de los valores asignados a los factores representa el valor de ajuste VA, el
cual es necesario para ajustar los puntos de función identificados en el paso 4. El VAF se
calcula a partir de la siguiente ecuación.

𝑉𝐴𝐹 = 𝑃𝐹𝑆𝐴 ∗ [0.65 + [0.01 ∗ 𝑉𝐴]]


Ecuación 1. Cálculo de VAF, adaptado de [23]

6. Cálculo del Esfuerzo: El cálculo esto dada en horas y representa el esfuerzo general
necesario para realizar las pruebas en las aplicaciones. [38] Es necesario tener métricas
históricas de esfuerzo del tiempo requerido o de productividad del equipo de pruebas
para el:
- Cálculo de tiempo creación de casos de pruebas
- Cálculo del tiempo de ejecución de los casos de pruebas
Cuando se tenga el valor del esfuerzo de realizar la actividad por un punto de función, el
valor se multiplica por el valor de los puntos de función ajustados para determinar el
tiempo necesario para cubrir la aplicación.
En la Ilustración 32, se presenta el proceso de puntos de función.

Ilustración 32. Puntos de función, tomado de [40]

En otros estudios relacionados a puntos de función, se ha determino la relación entre los casos de
pruebas y los defectos con los puntos de función.

De acuerdo a [41], existe una relación muy fuerte entre los puntos de función y la cantidad de
casos de pruebas, Capers Jones estima que el número de total de casos de prueba será
aproximadamente igual al número de Puntos de Función elevado a la potencia de 1,2.

67
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑐𝑎𝑠𝑜𝑠 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 ≈ 𝑃𝐹1.2 y el número de casos de pruebas para aceptación
se puede estimar multiplicando los puntos de función por 1,2 [42]. Los casos de prueba crecen a
un ritmo más rápido que los puntos de función.

Los puntos de función, permiten realizar un cálculo potencial de la cantidad de defectos que se
pueden presentar en la aplicación. Así por ejemplo, el número máximo de defectos potenciales es
igual los puntos de función multiplicados por 1,2. [42] En la Tabla 28, se presenta una estimación
de los puntos de función en relación a los defectos, donde se presenta el valor máximo de
defectos que se pueden presentar y tres valores (perfecto, medio, malo) que corresponden a una
medida de calidad del sistema respecto a la cantidad de defectos y el tamaño de los puntos de
función. [42]

Tamaño Puntos Max Defectos Total de defectos


de función potenciales Perfecto Medio Malo
100 120 12 66 102
200 240 24 132 204
500 600 60 330 510
1,000 1,200 120 660 1,020
2,500 3,000 300 1,650 2,550
5,000 6,000 600 3,300 5,100
10,000 12,000 1,200 6,600 10,200
20,000 24,000 2,000 13,200 20,400
Tabla 28. Punto de función y defectos, tomado de [45]

4.2.3 Análisis
Durante el análisis de pruebas, se identifican las condiciones de pruebas, los objetivos y alcance de
las pruebas, en la Tabla 29 se presenta la descripción de la actividad.

Ítem Definición
Actividad Análisis
Analizar la información del sistema para identificar la información
Descripción
requerida para el diseño de los casos de pruebas.
- Identificar:
Objetivos • Las condiciones de pruebas
• Los objetivos
- Documentos de especificación de los requerimientos
- Documentos técnicos
Entradas
- Alcance de las pruebas
- Plan de pruebas
Participante Analista de pruebas y Líder de pruebas
Realizar lista de condiciones de pruebas y matriz de trazabilidad de los
Forma de trabajar
las condiciones de pruebas.
- Técnicas de diseño de pruebas, ver sección 3.6
Forma de soportar
- Principios de pruebas, ver sección 3.2.5
Forma de Modelar - Matriz de trazabilidad de requerimientos con las condiciones de

68
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

pruebas
Lista de condiciones de pruebas
Salidas
Matriz de trazabilidad de las condiciones de pruebas
Tabla 29. Descripción actividad Análisis

Durante el análisis de pruebas, se identifican las condiciones de pruebas para el diseño de los
casos de pruebas para que se cumplan con las condiciones identificadas y los objetivos definidos.
[33]. En la Ilustración 33, se presenta la definición de condición de prueba.

Condición de prueba
•Elemento o evento de un componente o sistema que debería ser verificado por uno
o más casos de prueba, por ejemplo una función, transacción, característica,
atributo de calidad o elemento estructural.

Ilustración 33. Condición de prueba, tomado de [8], [20]

Las tareas principales que se realizan en esta etapa son:

• Revisar y analizar los documentos base para las pruebas, por ejemplo especificaciones de
requerimientos, definiciones de diseño o de interfaz, que permitan comprender el sistema
que debe ser construido y que permita identificar con precisión lo que el sistema debe
realizar en cada punto.[28]
• Identificar las condiciones de las pruebas basadas en las revisiones realizadas, como
resultado se tendrá una lista de alto nivel de lo que interesa probar. [28]
• Las condiciones de pruebas permiten determinar que se va a probar en el sistema. [43]
• Las condiciones de pruebas de alto nivel que definen los objetivos generales de las
pruebas, como por ejemplo: la funcionalidad de la pantalla x. [43]
• Las condiciones de pruebas, más detalladas definen la base de los casos de prueba, como
por ejemplo: el campo de la pantalla x acepta números de la longitud 10.[43]
• El uso de del enfoque jerárquico para las condiciones de pruebas son un apoyo para
asegurar la cobertura de las pruebas. [43]
• El analista de pruebas debe saber qué las pruebas específicas son diseñadas y definidos a
partir de la condición de pruebas.[43]
• Evaluar la capacidad de prueba de los requerimientos del sistema, estos deben ser escritos
de tal manera que permita diseñar pruebas. [28]

4.2.4 Herramientas para el análisis


A continuación se incluyen dos herramientas para el análisis:

- Lista de condiciones de pruebas


- Matriz de trazabilidad

69
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.4.1 Lista de condiciones de pruebas


La lista de condiciones de pruebas, es una matriz que presenta la información de las condiciones
de pruebas y son el insumo para el diseño de casos de pruebas, se propone el uso de la Tabla 30.

Id condición de prueba Nombre Condición de prueba


Descripción
detallado condición de alto nivel
Nombre
Escribir la condición Descripción de la condición de
Identificador único de la significativo de
de prueba de alto prueba, describir que se debe
condición de prueba la condición de
nivel validar en el sistema.
prueba
Tabla 30. Lista de condiciones de pruebas

4.2.4.2 Matriz de trazabilidad


La matriz de trazabilidad permite reconocer los artefactos que se relacionan con las condiciones
de pruebas definidos, debido que debe existir un documento que sustente el origen de la
condición de prueba.

En la matriz se incluyeron cuatro tipos de documentos y la opción de relacionar otro documento si


es requerido.

1. Requerimiento: Documento con la especificación de requerimiento del sistema que se


realiza prueba
2. Regla de negocio: Regla que se debe cumplir por funcionamiento, reglas o estándares de
la organización.
3. Requerimiento anterior: Corresponde a un documento de especificación de
requerimientos anterior al proyecto, pero que define requerimientos importantes del
sistema que es necesario garantizar con las pruebas del sistema.
4. Documento técnico: Documentos que presenten información del sistema y su propósito
sea la descripción técnica el sistema. Estos documentos los genera tecnología.

Cuando una condición de prueba se originó en uno de los documentos definidos en la matriz, se
debe describir el detalle de la información que permita describir la ubicación. Por ejemplo incluir:
Nombre del documento y la página donde se encuentre la condición.

Id Condición de Regla de Requerimiento Documento Otro


Requerimiento
prueba negocio anterior técnico documento
Incluir el
identificador de Describir la Describir la Describir la Describir la Describir la
la condición de ubicación ubicación ubicación ubicación ubicación
prueba

Tabla 31. Matriz de trazabilidad

4.2.5 Diseño
Ítem Definición
Actividad Diseño
Descripción Actividad que permite el diseño de los casos de pruebas que se

70
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

ejecutaran en el proceso de pruebas.


- Utilizando técnicas de diseño de pruebas se deben identificar
los casos de prueba a probar por prioridades y riesgos en la
funcionalidad.
Objetivos
- Los casos de prueba deben diseñarse para proporcionar la
mayor cantidad de cobertura con el menor número de casos de
prueba.
- Plan de pruebas
- Documentos de especificación de los requerimientos
Entradas - Documentos técnicos
- Lista de condición de pruebas
- Matriz de trazabilidad de condición de pruebas
- Analista de pruebas
Participante
- Líder de pruebas
Realizar documentos de:
Forma de trabajar - Casos de pruebas.
- Gestión de riesgos
- Técnicas de diseño de pruebas, ver sección 3.6
- Análisis de riesgos
Forma de soportar
- Principios de pruebas, ver sección 3.2.5
- Casos de pruebas, ver sección 3.5
Forma de Modelar - Plantilla de casos de pruebas
Mediante la actividad de control, se realizara seguimiento al análisis de
Forma de controlar
casos de pruebas.
- Documento de casos de pruebas de pruebas.
Salidas
- Matriz de trazabilidad actualizado
Tabla 32. Descripción actividad diseño

En el diseño de pruebas, se diseñan los casos de pruebas que cumplan con las condiciones
identificadas y los objetivos definidos en la etapa anterior. [33]

Las tareas principales que se realizan en esta etapa son:

• Diseñar las pruebas, basados en las técnicas definidas en la sección 3.6, permitirán
seleccionar las pruebas representativas que cumplan con las condiciones identificadas y
definir los casos de pruebas y procedimientos de prueba necesarios. [28]
• Evaluar la capacidad de prueba de los requerimientos del sistema, estos deben ser escritos
de tal manera que permita diseñar pruebas. [28]
• Diseñar el entorno de prueba, identificar la infraestructura y las herramientas que son
necesarias para llevar a cabo la ejecución de pruebas. [28]

71
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Diseño de
Plan de casos de
pruebas pruebas

Documento de
Diseño
requerimient
os

Matriz
Documento trazabilidad
de pruebas
técnicos

Salida actividad
análisis

Ilustración 34. Entradas y salidas de la actividad diseño

En la Ilustración 35, se presentan las consideraciones y recomendaciones para la actividad de


diseño.

Consideraciones Recomendaciones

En los casos de pruebas no se


incluyen condicionales, si se
require validar ciclos o
condiciones, se deben crear
casos de pruebas
independientes
Diseñe los casos de pruebas
definiendo el paso a paso.
Los principios de pruebas, Las personas que ejecutan
dan lineamientos para la las pruebas, no
creación de casos de pruebas, necesariamente conocen el
por eso es importante sistema.
conocerlos.

Ilustración 35. Consideraciones y recomendaciones diseño

72
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.6 Herramientas para el diseño


Con el fin de identificar y diseñar los casos de pruebas, se definió el proceso de diseño,
presentado en la Ilustración 36, que facilita y permite determinar de manera más efectiva y clara
los casos de pruebas.

Ilustración 36. Proceso Diseño

En la Tabla 33, se presenta el detalle de las actividades del proceso de diseño.

Actividad Descripción
- Descomponer el requerimiento en unidades funcionales [44]
o Identificar los módulos u opciones que componen el
Determinar escenarios sistema, que se va a probar.
- Identificar los actores que interactúan en cada uno de los
escenarios definidos para el sistema. [44]
- Identificar los flujos que se presentan en cada escenario, se
deben considerar tanto los flujos normales, como los flujos
alternativos y los de excepción que generan error en el
sistema.
o Los diagramas de flujos, de estado o de causa y
Determinar eventos efecto (ver sección 3.6.1.4 Grafos de causa- efecto),
son herramientas de apoyo, para identificar los
caminos presentados en los escenarios.[44], [45]
o Las técnicas presentadas en la sección 3.6, presentan
otra alternativa para reconocer los caminos del
sistema.
- Identificar las condiciones necesarias para la ejecución de los
casos y sus valores requeridos. [44]
o El comportamiento de los sistemas dependen de las
Determinar los casos de
entradas que reciben, por lo tanto es importante
pruebas
identificar cuáles son los posibles datos de entrada y
las combinaciones que se pueden presentar, que
generen ciertas respuestas o salidas. Este

73
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

reconocimiento permite determinar si un caso de


prueba se debe ejecutar más de una vez con las
diferentes entradas, o si existe un comportamiento
común para un grupo de datos, lo que permite
ejecutar una sola vez el caso de prueba.
- Los casos de prueba deben presentar una descripción, con
toda la información que es necesaria para su ejecución.
- Realizar la descripción del paso a paso del caso de prueba de
cada evento identificado, definiendo las acciones que realiza
el actor del sistema y las respuestas generadas.
- En la plantilla de la Tabla 36, se presenta un modelo para la
definición de los casos de pruebas.
Tabla 33. Descripción de actividades del proceso de diseño

En la Ilustración 37, se presentan las consideraciones para el proceso de diseño.

Consideraciones

Los eventos dependen de los escenarios


identificados.

Por cada escenario se pueden presentar más de un


evento.

La información de los escenarios y eventos son parte


de la descripción de los casos de pruebas

Los diagramas de flujos, de estado y de causa -


efecto, permiten identificar los flujos y
dependencias del sistema.

Ilustración 37. Consideraciones Proceso de diseño

A continuación se incluyen herramientas para el diseño, se especifican las plantillas y la


descripción de cada campo.

- Plantilla para los escenarios, eventos de pruebas


- Plantilla para los casos de pruebas.
- Matriz de trazabilidad de pruebas.
- Documento de casos de pruebas.

74
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.6.1 Plantilla para los escenarios y eventos de pruebas


En la Tabla 34 y Tabla 35, se presentan las plantillas para la creación de escenarios y evento.

No. Escenario Escenario Descripción


Descripción y objetivo del
Nombre de escenario.
Identificador de escenario
escenario Incluir los actores que
interactúan en los escenarios.
Tabla 34. Plantilla Escenarios

No. Evento Escenario Evento Descripción

Identificador Descripción y objetivo


Nombre del evento 1
de evento 1 Nombre de del evento 1.
Identificador escenario Descripción y objetivo
Nombre del evento 2
de evento 2 del evento 2.
Tabla 35. Plantilla Eventos

4.2.6.2 Plantilla para los casos de pruebas


A continuación se presenta una plantilla para la descripción de los casos de prueba, donde se
define los campos requeridos su descripción.

Nombre significativo del caso de prueba que permita identificar el


Caso de prueba
propósito de la prueba.
Identificador único del caso de prueba.
Se recomienda que inicie la nomenclatura del nombre:
Identificador caso CPNNNN_NombreCasoDePrueba. Donde CP corresponde a las
de prueba siglas de casos de prueba, NNNN corresponde a la numeración
única del caso de prueba y el NombeCasoDePrueba corresponde al
nombre significativo asignado en el campo caso de prueba.
Definir el modulo, servicio o función que probara con el caso de
Función probar prueba.
Definir el escenario a probar.
Describir que funcionalidad que será probada con el caso de
Objetivo prueba.
Definir el evento a probar.
Descripción Describir y explicar el propósito el caso de prueba.
Definir los criterios de aceptación, que permiten determinar que el
Criterios de éxito
caso de prueba ejecutado es exitoso
Definir los criterios que permiten determinar que el caso de prueba
Criterios de falla
ejecutado es fallido
Describir las condiciones y el estado en las que se debe encontrar el
sistema para la ejecución del caso de prueba, en caso de ser
Precondiciones
necesario incluir los casos de pruebas que se deben ejecutar como
pre requisitos al caso de prueba.
Perfil del usuario Perfil del usuario en el sistema con el que se ejecutara la prueba.
Necesidades para Definir las necesidades para la ejecución de los casos de pruebas,
el caso de prueba como por ejemplo los datos de pruebas, las condiciones adicionales

75
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

a tener en cuenta, configuración de la prueba.


Autor Nombre de la persona que diseña el caso de prueba
Fecha de creación Fecha en la que se diseña el caso de prueba
No
Usuario del sistema Sistema
paso
Acción del usuario en el
sistema, definir las
Orden entradas requeridas en el
en el paso y que realiza el Respuesta del sistema a la
Flujo del caso de
que se usuario durante el paso, acción realizada por el
prueba
ejecuta en caso que presente usuario
el paso entradas, describir que
hace el usuario con las
entradas.

Describir el estado del sistema luego de la ejecución de caso de


Post condiciones
prueba.
Tabla 36. Plantilla casos de prueba

A continuación se presenta un ejemplo de un caso de prueba para la matrícula de un estudiante


en un periodo académico de la universidad.

Caso de prueba MatriculaEstudiante


Identificador
CP0010_ MatriculaEstudiante
caso de prueba
Función probar Función de matrícula del módulo de estudiante
Validar la funcionalidad de matricular estudiante en el sistema
Objetivo
integral de estudiante de la universidad.
El actor con rol de estudiante ingresa a la funcionalidad de matrícula
Descripción
y selecciona la opción matricular
Lista de criterios de éxito:
1- En el sistema queda matriculado el estudiante
Criterios de éxito
2- El sistema informa que la matrícula es exitosa
3- El estudiante queda en estado matriculado
Lista de criterios de falla
1- En el sistema no queda matriculado el estudiante
Criterios de falla
2- Se presenta mensaje de error informando que la matricula
no es exitosa.
1- El usuario estudiante debe existir en el sistema
2- El estudiante debe tener un periodo académico por cursar
Precondiciones 3- Ejecución exitosa del caso de prueba del login en el sistema
integral de estudiante: CP0005_LoginSistema
4- El estudiante se encuentra en el estado: “Pendiente por

76
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

matricular”
Perfil del usuario Estudiante pregrado, estudiante postgrado
Necesidades para
Datos de prueba: ID usuario: 14522, ID usuario: 885555
el caso de prueba
Autor María Ximena Narváez B
Fecha de
13-11-2014
creación
No
Usuario del sistema Sistema
paso
Entradas: Ninguna
El sistema presenta la pantalla
Descripción: Seleccione
“Matricula” con las opciones:
1 la opción de matrícula
Validar ciclo pendiente, consultar
del menú principal
históricos y regresar.

Entradas: Ninguna El sistema presenta la pantalla


Descripción: “Ciclo pendiente de Matricula”
2
Seleccione la opción con las opciones: Realizar
validar ciclo pendiente matricula, cancelar
Flujo del caso de El sistema presenta ventana
Entradas: Ninguna
prueba emergente con el mensaje “Por
Descripción:
3 favor ingrese su clave personal
Seleccione Realizar
para confirmar la matricula” con
matricula
los botones aceptar y cancelar
Entradas: Clave personal 1- El sistema valida la clave
Descripción: 2- Presenta el mensaje “su
1- Ingrese la “clave matrícula fue exitosa.”
personal” en el campo 3- Realiza el registro de la
4
clave de la ventana matrícula del estudiante en el
emergente. sistema.
2- Dar clic en el botón 4- Cambia el estado del
aceptar. estudiante a matriculado.
El estudiante queda matriculado en el ciclo que se encontraba
Post condiciones
pendiente de matrícula.
Tabla 37. Ejemplo caso de prueba matricula estudiante

4.2.6.3 Matriz de trazabilidad de pruebas


La matriz de trazabilidad de pruebas, modifica la matriz generada en la sección 4.2.4, una de las
entradas en la actividad de diseño, se incluye la columna de casos de prueba donde se ingresa la
lista de identificadores únicos de los casos de pruebas que cubre la condición de prueba.

En la Tabla 38, se presenta la matriz de trazabilidad modificada.

77
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Otro
Id Condición Casos de Requerimi Regla de Requerimie Documen
documen
de prueba pruebas ento negocio nto anterior to técnico
to
Incluir el Incluir el
identificador identificador Describir la Describir la Describir la Describir la Describir la
de la condición de los casos ubicación ubicación ubicación ubicación ubicación
de prueba de prueba

Tabla 38. Matriz de trazabilidad de las pruebas

4.2.6.4 Plantilla del documento de casos de pruebas

Para la creación del documento de casos de pruebas se propone el uso de la siguiente plantilla
basada en [27], [43] , ver anexo 6.3.

78
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 38. Plantilla de documento de casos de pruebas

4.2.7 Control
La gestión del plan de pruebas, se realiza mediante el control, que permite medir el progreso de
las pruebas, mediante la evaluación del avance real versus el avance planeado y notificar a los
interesados sobre el estado actual de las pruebas, si se presentan cambios o desviaciones en el
plan, con el fin de mitigar riesgos, tomar medidas, realizar correcciones o generar estrategias para
el cumplimiento de los objetivos.[28], [33] En la Tabla 39, se presenta la información relacionada al
control.

Ítem Definición
Subproceso Control
Actividad que busca establecer los controles necesarios para aplicar en
Descripción
el proceso de pruebas y realizar monitoreo a las actividades.
1- Definir los controles que se ejecutaran para cada una de las
actividades del proceso de pruebas.
2- Evaluar si el proceso de pruebas progresa de acuerdo al plan de
pruebas. [37]
Objetivos
3- Cuando se presenten desviaciones significativas en el progreso
de lo planificado o en la ejecución de las actividades, u otros
aspectos del plan de pruebas, debe establecer las actividades
para corregir o compensar las variaciones resultantes.[37, p. 2]
- Documentos de especificación de los requerimientos
Entradas - Documentos técnicos
- Plan de pruebas
Participante - Líder de pruebas
- Definir métricas
Forma de trabajar - Realizar análisis de riesgos, para establecer plan de mitigación y
de contingencia.
- Documento de riesgos
Forma de soportar
- Métricas del proceso de pruebas para cada ciclo.
Forma de Modelar - Análisis de riesgos y métricas de calidad de software
- Generación de informes las pruebas con los controles
Forma de controlar necesarios para el proceso.
- Matriz de riesgos
- Controles establecidos para el proceso de pruebas
Salidas
- Documento de riesgos: Los riesgos relacionados con las pruebas

79
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

analizan y se toman acciones necesarias. [37]


- Riesgos nuevos identificados
- Progreso contra el plan de pruebas[37]
- Acciones de control identificadas.[37]
Tabla 39. Descripción actividad Control

El control permitirá tomar medidas en el caso que se presenten desviaciones con el plan, por
ejemplo la re – priorización de las pruebas y asignación de recursos para la ejecución. [33]

El control permite:

• Medir y analizar los resultados de pruebas, permite conocer la cantidad de pruebas


exitosas, la cantidad de pruebas fallidas y la información asociada requerida, por ejemplo
criticidad, tipo y prioridad de los defectos.[28]
• Documentar el progreso de las pruebas, su cobertura y los resultados. Es importante que
se informe a los interesados los resultados, conclusiones y la evaluación de riesgos que se
realicen, con el fin de hacer visible a los avances de las pruebas. [28]
• Generar informes sobre el avance de las pruebas, para que los interesados conozcan el
estado de las pruebas, lo que facilita la toma de decisiones. [28]
• Gestión de los defectos, realizando seguimiento de la solución de los reportes. [28]
• Permite la toma de decisiones a partir de la información recogida en las pruebas y los
riesgos del negocio, para continuar con la ejecución de las pruebas, para detener pruebas,
para liberar el software o para devolver el software a etapas anteriores como por ejemplo
a desarrollo. [28]

Como se definió en la sección 4.1.4 y fue expuesto en la Ilustración 23, el control se realiza de
manera paralela a las pruebas y es un sub proceso que contiene diferentes actividades. El
subproceso control se encuentra en la Ilustración 39, las actividades del subproceso son descritas
en la Tabla 40.

80
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 39. Subproceso control, adaptado de [37]

4.2.7.1 Descripción de actividades subproceso de control


A continuación se presenta la descripción de las actividades del subproceso control.

Actividad Descripción
En esta actividad se define:
1. Las medidas adecuadas para el seguimiento del progreso del plan de pruebas.
[37]
Preparar 2. Los medios adecuados para la identificación de riesgos nuevos y cambiantes
deben ser identificados.[37]
3. Las actividades de monitoreo, como por ejemplo los informes del estado de las
pruebas y la recolección de métricas.[37]
El monitoreo se realiza de manera regular, hasta que se determine que las pruebas
del plan de pruebas se han completado, esta actividad se encargada de:
1. Recopilar y registrar las medidas de prueba. [37]
2. Analizar los avances del plan de pruebas por medio de las medidas de pruebas,
e informar el análisis a las partes interesadas. Por ejemplo a través del análisis
de informes del estado de pruebas.[37]
Monitoreo
3. Identificar las diferencias en los avances de las actividades de prueba y los
factores que no permiten que estas avancen.[37]
4. Identificar nuevos riesgos y analizados con el fin de generar un plan de
mitigación e informarlos a los interesados. [37]
5. Realizar seguimiento a los cambios en los riesgos ya conocidos con el fin de
generar un plan de mitigación e informar a los interesados. [37]
El control se encarga de las siguientes actividades:
Control 1. Realizar las tareas y acciones necesarias para implementar el plan de pruebas.
Como por ejemplo la asignación de responsabilidad a las actividades de

81
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

prueba.[37]
2. Realizar las acciones necesarias para implementar las directivas de control
recibidas de los procesos de gestión de alto nivel.[37]
3. Identificar las acciones necesarias para gestionar la diferencia entre la
ejecución de pruebas y el plan de pruebas. Por ejemplo, dentro de las acciones
se podrían establecer cambios en las prueba, en el plan de pruebas, el personal
o cambios en otras áreas.[37]
4. Establecer los medios para el tratamiento de los riesgos identificados y
modificados. [37]
5. Cuando sea necesario:
a. Expedir las directrices de control, cuando se realicen cambios en la manera
que se llevan a cabo las pruebas. [37]
b. Los cambios en el plan de pruebas se deben realizar como actualización
en el documento. [37]
c. Las recomendaciones se realizan a las partes interesadas.
6. Velar por el cumplimiento de los criterios de entrada a cada actividad para su
inicio. [37]
7. Velar por el cumplimiento de los criterios de salida para la finalización de las
actividades de pruebas.[37]
8. Cuando las pruebas han cumplido los criterios de finalización, debe obtener la
aprobación de la decisión de finalización de la prueba.[37]
El reporte presentan las siguientes actividades:
1. Comunicar a los interesados de las pruebas, los avances para un período
Reporte específico mediante un informe. [37]
2. Los nuevos riesgos identificados y los cambios a los existentes se actualizarán
en el documento de riesgos y se comunicaran a los interesados.[37]
Tabla 40. Descripción actividades del subproceso control

En la Ilustración 40, se presentan las recomendaciones y consideraciones para el de control.

•El control, se realiza de manera transversal a las pruebas, por lo


tanto las actividades se realizan de manera constante.
Consideraciones •El estado del proceso de pruebas se determinará comparando el
progreso logrado con respecto al plan de pruebas: medir el progreso
de las pruebas, la cobertura de las pruebas y el cumplimiento de los
criterios de finalización de las pruebas

•A lo largo de las pruebas, se deben recolectar, monitorear,


administrar e informar las métricas que se hayan establecido, el
Recomendaciones
progreso y estado de las pruebas a través de la fase de ejecución
y la generación y solución de defectos

Ilustración 40. Recomendaciones y consideraciones para el control

82
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.8 Herramientas para la actividad de control


4.2.8.1 Análisis de Riesgos
El análisis de riesgos, permite evaluar los riesgos identificados en el plan de pruebas y generar un
plan de acción para mitigar que se presente el riesgo y un plan de contingencia en caso que el
riesgo se haya materializado. Pero también es una técnica que permite definir la prioridad de los
casos de pruebas, por lo tanto el análisis de riesgos se puede realizar en dos sentidos:

1. En cuanto al proyecto, para determinar los riesgos críticos y que necesitan mayor
atención o control.
2. En cuanto a las pruebas, permite determinar la prioridad de ejecución de las prueba.
Basándose en los módulos afectados por el desarrollo y que tengan por ejemplo un mayor
cambio, un mayor impacto en el negocio, o un mayor flujo de información.

Los riesgos del proyecto se pueden clasificar en dos tipos que dependen de su fuente de origen:
del Proyecto o del producto. Para realizar el análisis de riesgos, se debe validar la probabilidad de
ocurrencia y el impacto de la materialización del riesgo, para clasificar el riesgo de acuerdo a su
criticidad. En la Ilustración 41, se presenta la definición de los tipos de riesgos.

Riesgos originados por el desarrollo del producto de software,


afectan el éxito del proyecto porque están directamente
relacionado con el objeto de prueba como:
- Entregar o liberar Software con defectos.
- El software no se ajusten a las necesidades.
Producto
- El software entregado, pueda perjudicar a la organización.
- Entregar software con características pobres o malas
(funcionalidad, seguridad, confiabilidad, usabilidad,
rendimiento).
Corresponde a los riesgos relacionados al proyecto, por
ejemplo:
- Problemas con proveedores como cuestiones del contrato
- No entrega de los productos pactados
Proyecto - Falta de personal
- Personal no capacitado o con bajo desempeño
- Mala comunicación entre los equipos de trabajo
- Requerimientos mal definidos o pobres es la especificación
- Mala calidad del diseño o del código
- Solución arquitectónica mal enfocada o sin aprobación.

Ilustración 41. Tipo de riesgos del proyecto

83
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Para los riesgos asociados a las pruebas:


1. Se debe identificar las funcionalidades o módulos que se encuentran impactados por el
desarrollo, por lo tanto se deben probar de acuerdo con el requerimiento.
2. Evaluar el módulo e identificar los posibles riesgos que traería un mal funcionamiento del
sistema a la organización y a los usuarios del software, por ejemplo: riesgos financieros,
riesgo de afectación a los clientes, riesgo a nivel de normatividad o riesgos a nivel de la
salud y bienestar de las personas.
4.2.8.2 Evaluación de riesgos
Por cada riesgo se debe evaluar y asignar un nivel de probabilidad de ocurrencia y un nivel de
impacto de se materializa el riesgo, teniendo en cuenta que:
• La probabilidad de ocurrencia, mide la posibilidad de materializarse el riesgo, se mide en
una escala del uno al cuatro donde:

Nivel Significado Descripción de nivel de riesgo


Insignificante (se No existe condiciones que impliquen el riesgo
1
incluye ninguna)
Existen condiciones que hacen muy baja la posibilidad de
2 Baja
materializarse el riesgo
Existen condiciones que hacen poco probable la materialización del
3 Media riesgo en el corto plazo, pero no son suficientes para evitarlo en el
largo plazo
La materialización del riesgo es inminente. No existen condiciones
4 Alta
internas y externas que impidan la materialización del riesgo.
Tabla 41. Nivel de probabilidad de los riesgos, tomada de [46]

• El nivel del Impacto de la materialización del riesgo, se refiere al efecto del riesgo en el
proyecto

Impacto Significado Descripción nivel


Insignificante No causa ningún tipo de impacto o daño en la organización. (Ninguno
1
(ninguno) en caso de que elemento sea inexistente)
Causa daño aislado, que no perjudica a ningún componente de la
2 Bajo
organización.
Provocan la desarticulación de un componente de la organización. Si
3 Mediano no se atiende a tiempo, a largo plazo puede provocar la
desarticulación de la organización
4 Alto En el corto plazo desmoviliza o desarticula a la organización
Tabla 42. Nivel de impacto del riesgo en el proyecto, tomada de [46]

Luego de identificar el nivel de impacto y de probabilidad, se debe realizar el cálculo del nivel del
riesgo, este se realiza por medio de la multiplicación de los valores asignados a cada ítem y
registrarlo en la matriz para el análisis de riesgos, donde en las filas corresponden a la probabilidad
de ocurrencia y en las columnas el nivel de impacto de la materialización, en la intersección de las
filas y columnas se debe incluir la multiplicación de los niveles que nos indicara el nivel del riesgo.

84
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

𝑁𝑖𝑣𝑒𝑙 𝑑𝑒𝑙 𝑟𝑖𝑒𝑠𝑔𝑜 = 𝑃𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 𝑑𝑒 𝑜𝑐𝑢𝑟𝑟𝑒𝑛𝑐𝑖𝑎 × 𝐼𝑚𝑝𝑎𝑐𝑡𝑜

1 2 3 4
Impacto
4 8 12 16
3 6 9 12
2 4 6 8
1 2 3 4

1 2 3 4
Probabilidad de amenaza
Ilustración 42. Matriz de riesgos

El nivel del riesgo puede ser bajo, medio o alto, determinados de la siguiente manera:
• Riesgo bajo: Si el valor del nivel del riesgo se encuentra entre 1-6
• Riesgo medio: Si el valor del nivel del riesgo se encuentra entre 8-9
• Riesgo alto: Si el valor del nivel del riesgo se encuentra entre 12-16
Luego de determinar el nivel del riesgo, se debe definir los planes de mitigación del riesgo con el
fin de definir cómo evitar el riesgo y el plan de contingencia para definir los planes de acción si el
riesgo se materializa. La Tabla 43, presenta la plantilla para registrar la información relacionada al
análisis del riesgo.
Nivel de Descripción Plan de
Id riesgo Tipo Plan de Contingencia
riesgo riesgo mitigación
proye Describir un
identificador único Valor del Definición del Describir un plan de
cto o plan de acción
del riesgo asignado nivel del riesgo de la acción si se llegase a
produ para mitigar
en la planeación riesgo planeación materializar el riesgo
cto el riesgo
Tabla 43. Tabla de riesgos

4.2.8.3 Plantilla del documento de gestión de riesgos

Para la creación del documento de gestión de riesgos de las pruebas se propone el uso de la
siguiente plantilla. Ver anexo 6.2.

85
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

86
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 43. Plantilla documento gestión de riesgos

4.2.8.4 Métricas
Para poder hablar de métricas de software, es necesario entender su definición. Pressman, define
las métricas como: una medida que proporciona una indicación cuantitativa de la extensión,
cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto” [23],
y más específicamente sobre las métricas de calidad, menciona que proporcionan un indicador de
cómo se ajusta el software a los requerimientos implícitos y explícitos del cliente. Es decir cómo
se va a medir para que el sistema se adapte a los requerimientos que pide el cliente.[23]

De acuerdo a la IEEE, una métrica calidad de software, es “una función cuyas entradas son datos
de software y cuya salida es un solo valor numérico que se puede interpretar como el grado en el
que el software posee un atributo dado que afecta a su calidad.”[47]
“Cuando puedes medir aquello de lo que hablas, y expresarlo con números, sabes algo acerca de ello;
pero cuando no lo puedes medir, cuando no lo puedes expresar con números, tu conocimiento es pobre
e insatisfactorio: puede ser el principio del conocimiento, pero apenas has avanzado en tus pensamientos a
la etapa de ciencia”
William Thomson Kelvin (1824 - 1907)

Para llevar a cabo un proceso de métricas, es necesario definir que se va a medir y cuál es el
propósito, para así iniciar con la recolección de datos y a partir de estos, realizar los cálculos
necesarios que permitirán evaluar y analizar los resultados de obtenidos. En la Ilustración 44, se
presentan los pasos a seguir en el proceso de métricas.

87
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Pruebas de
software

Calculo de
métricas
•Medidas •Indicadores
•Métricas

Recopilación de Evaluación de
datos métricas

Ilustración 44. Proceso de métricas, basado en [48]

Las medidas y métricas se pueden llevar a cabo a lo largo del ciclo de vida del software, deben
estar bien definidas, y alineadas con los objetivos de las pruebas, de tal manera que permiten
realizar un seguimiento adecuado de los avances y resultados de las pruebas. Lo que permite
informar sobre el resultado de la calidad del sistema de manera consistente y coherente. [49]

Cuando no se cuenta con un proceso claro para evaluar la calidad del software y el proceso de las
pruebas, se tendrán evaluaciones subjetivas, no se tendrá claridad sobre los resultados y la
eficacia de las pruebas y se generar malos entendidos. [49] A continuación, se presentan aspectos
a tener en cuenta en el momento de establecer las métricas:

• Se debe definir, los puntos a evaluar a partir de las métricas, que atributo se va a medir y
la manera como se medirá, así como el propósito y el alcance de la medida. [34], [49]
• Es necesario que se defina como se evaluaran los resultados de las métricas, lo que
establece cuándo se presenta un resultado bueno, aceptable o inaceptable. Permitiendo
tener una única interpretación de los resultados, análisis y tendencias. [49]
• Las métricas de las pruebas de software, permiten realizar seguimientos al proceso de
pruebas y la presentación de informes, proporciona de manera concisa las métricas de
calidad del sistema, así mismo determinar su progreso, tomar acciones correctivas y
evaluar el impacto de tal acción.[34], [49]
• Se deben definir y seleccionar un conjunto de métricas, debido que un conjunto grande se
convierte en una tarea difícil de seguir, pueden tornarse confusas o desorientar en los
informes y convertirse en un aspecto costoso en el proyecto. [49]

Las métricas en la guía, se enfocan en medir y evaluar la calidad del sistema desarrollado y
entregado por el proveedor. Se tomó como base, el estándar ISO 9126, debido que define un
modelo de calidad de un producto de software a partir de: la calidad interna y externa, y calidad
en el uso, cada una con sus propias características[50]. Estas características deben estar
especificadas y evaluadas, usando métricas validadas o aceptadas[34]. El estándar define los tres
tipos de métricas presentados a continuación en la Ilustración 45.

88
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Métricas internas
•Se aplican a un producto de software no ejecutable, sobre el código fuente o la
especificación, durante el diseño y la codificación.
•Permite identificar errores en la calidad e iniciar las acciones correctivas de manera
temprana.
•Busca asegurar que la calidad externa requerida y la calidad en uso sean alcanzadas.

Métricas externas
•Busca medir la calidad del producto de software a partir del corportamiento del sistema.
•Las metricas extermas se aplican cuando el sistema se encuentra en pruebas, o en
operación, a partirt de la observación del software o sistema ejecutado.
Métricas de calidad en el uso
•Miden el grado en el cual un producto satisface las necesidades y objetivos de los
usuarios, como por ejemplo la eficacia, productividad, seguridad y satisfacción en un
contexto especificado de uso.
• Estas metricas se obtienen cuando el sistema se encuentra en ambiente de producción.

Ilustración 45. Métricas de calidad del Software [34]

89
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

La norma, establece en el modelo de calidad interna y externa, seis características: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia,
Mantenibilidad y Portabilidad. Cada característica es subdividida en sub-características, presentadas en la Ilustración 46.

Ilustración 46. Calidad Externa e Interna, [34], [48], [50]

En la Tabla 44, se presentan las métricas externas definidas en ISO 9126 que permiten medir la calidad del sistema durante las pruebas, por lo
que corresponden a las métricas requeridas para la guía.

90
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Característica Nombre Propósito Método Fórmula Interpretación


𝐴
Numero de funciones que 𝑋 =1− 0≤𝑋≤1
𝐵
¿Qué tan adecuadas son capaces de realizar las
Adecuación
son las funciones tareas específicas 𝐴 = Número de funciones con Entre más cercano
funcional
evaluadas? comparado con el número problemas al 1,0 más
de funciones evaluadas 𝐵 = Número de funciones adecuado
evaluadas
Las funciones probadas, se
comportan de acuerdo con 𝐴
𝑋 =1−
la especificación de 𝐵
Completitu ¿Qué tan completa
requerimientos. Contar el 0≤𝑋≤1
d de la es la implementación
número de funciones 𝐴 = Número de funciones faltantes
implement de acuerdo con la
faltantes detectadas 𝐵 = Número de funciones Entre más cercano
ación especificación de los
comparando con el número descritas en la especificación de al 1,0 más
funcional requerimientos?
de funciones descritas en la requerimientos adecuado
Funcionalidad
especificación de los
- Adecuación
requerimientos
𝐴
Las funciones probadas se 𝑋 =1−
𝐵
comportan de acuerdo a la
especificación de 𝐴= Número de funciones
Cubrimient
requerimientos. Contar el implementadas incorrectamente o 0≤𝑋≤1
o de la ¿Qué tan correcta es
número de funciones faltantes
implement la implementación
implementadas 𝐵 = Número de funciones
ación funcional? Entre más cercano
incorrectamente o faltantes descritas en la especificación de
funcional al 1,0 más
detectadas comparando con requerimientos; cuenta el número
adecuado
el número de funciones de funciones que están completas
descritas en la especificación contra las que no

Estabilidad ¿Qué tan estable es Contar el número de 𝐴


de la la especificación funciones descritas en la 𝑋 =1− 0≤𝑋≤1
𝐵

91
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

especificaci funcional previa a especificación funcional que Entre más cercano


ón entrar en operación? han cambiado después de 𝐴= Número de funciones al 1,0 más
funcional que el sistema es puesto en cambiadas después de entrar a adecuado
operación y compararlo con operación, comenzando cuando se
el número de funciones entró a operación;
descritas en la especificación 𝐵= Número de funciones
de requerimientos descritas en la especificación de
requerimientos;
𝐴
𝑋=
𝑇
Contar el número de casos de 𝐴 = Número de
Precisión ¿Las diferencias
Hacer los casos de pruebas y pruebas encontrados por los casos con una
Funcionalidad con las entre lo real y lo
comprar la salida con los usuarios con una diferencia diferencia contra lo
- Precisión expectativa esperado son
resultados esperados inaceptable con los resultados esperado mayor a
s aceptables?
esperados lo aceptable;
𝑇 = tiempo de
operación
Densidad 𝐴1
¿Cuantos errores 𝑋=
de errores Contar el número de errores 𝐴2 0≤𝑋
fueron detectados
contra los encontradas y el número de 𝐴1 = Número de errores detectados En etapas finales,
durante el periodo
casos de casos de pruebas realizados 𝐴2 = Número de pruebas realizadas entre más pequeño
de prueba?
pruebas mejor
𝐴1
Cuenta el número de errores 𝑋=
𝐴2 0≤𝑋≤1
Confiabilidad Resolución ¿Cuántos defectos que no recurrieron durante
𝐴1 = Número de errores resueltos Cuanto más
- Madurez de defectos fueron resueltos? el periodo de pruebas bajo
𝐴2 = Número de errores detectados cercano a 1.0 más
condiciones similares.
adecuado
¿Cuánto de los casos Contar los casos de pruebas 𝐴
𝑋=
Cubrimient de pruebas ejecutados y comparar con 𝐵 0≤𝑋≤1
o de las requeridos durante los casos de pruebas 𝐴 = Número de casos de pruebas Cuanto más
pruebas las pruebas han sido requeridos ejecutados cercano a 1.0 más
ejecutados? 𝐵 = Número de casos de pruebas a adecuado

92
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

ser ejecutados para cubrir los


requerimientos
𝐴
𝑋=
Contar el número de casos 𝐵 0≤𝑋≤1
Madurez de pruebas que pasaron y 𝐴 = Número de casos de pruebas
¿Está el proceso bien
de las compararlos con el número ejecutados que pasaron Cuanto más
probado?
pruebas total de casos de pruebas 𝐵 =Número de casos de pruebas a cercano a 1.0 más
requeridos ser ejecutados para cubrir los adecuado
requerimientos
¿Qué tan seguido el 𝐴 0≤𝑋≤1
Confiabilidad sistema causa la Contar el número de caídas 𝑋=
Prevención 𝐵
– Tolerancia a caída de todo el respecto a la cantidad de
de caídas Cuanto más
fallas entorno de errores 𝐴 = Número de caídas cercano a 1.0 más
producción? 𝐵 =Número de errores adecuado

Tabla 44. Métricas proyecto, tomado de [34], [48]

93
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.9 Implementación y ejecución


A continuación se presentan las actividades de implementación y desarrollo, en una sola tabla
debido a que son actividades que comparten definiciones para los ítems de la tabla y son
actividades que se realizan de manera secuencial.

Ítem Definición
Actividades Implementación y ejecución.
Las actividades realizan la organización de los casos de pruebas para
Descripción
que estos se puedan ejecutar.
- Establecer la manera como se deben ejecutar los casos de
pruebas
Objetivos
- Ejecutar los casos de pruebas
- Gestionar la calidad del sistema.
Entradas - Documento de casos de pruebas
- Ejecutor de pruebas
Participantes - Analista de pruebas
- Líder de pruebas
Forma de trabajar Realizando las tareas definidas para cada actividad
- Herramientas de gestión de pruebas
Forma de soportar
- Documento de recolección de evidencias.
Forma de Modelar Documento de riesgos
Forma de controlar - A través de métricas establecidas en la actividad de control
- Reportes de defectos
Salidas - Informe de avance
- Documento de ejecución de pruebas
Tabla 45. Descripción de actividades Implementación y ejecución.

En la implementación de las pruebas, presenta las siguientes tareas:

• Priorizar los casos de pruebas, para garantizar que se cumple con el objetivos
identificados, de una manera más eficiente. [33]
• Identificar el orden en el que se deben ejecutar las pruebas, teniendo en cuenta las
restricciones, las precondiciones y las dependencias entre los casos. [33]
• Definir, identificar y crear los datos que son necesarios para la ejecución de las pruebas.
[28], [33]
• Establecer el cronograma de ejecución de prueba. [28], [33]
• Implementar y verificar el entorno de las pruebas, para asegurarse que este se encuentre
configurado correctamente.[28]

Como bien su nombre lo indica, en la ejecución de pruebas se ejecutan los casos de pruebas con
los datos previamente seleccionados en el cronograma especificado en la implementación. [33]

• Luego de la ejecución, se debe registrar la información de los resultados obtenidos, los


datos y la versión del sistema en el que se ejecutó el caso de prueba. Permitiendo llevar un
registro de la información de la ejecución. [28], [33]

94
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

• Se comparan los resultados obtenidos en la ejecución, con los resultados esperados. [28],
[33]
• Cuando se presente diferencias entre los resultados obtenidos y los esperados, se debe
realizar el análisis, para determinar si es un error del sistema, o bien, es un error de la
ejecución de las pruebas, debido que se pueden tener reportes mentirosos, donde el
resultado del caso de prueba presenta un error y en realidad no lo hay (falsos negativos), o
casos de pruebas que indican que el resultado es correcto y se omiten errores (falsos
positivos). [28], [33]
• A partir del análisis de los resultados, realizar el reporte de los incidentes, con la
información y los datos utilizados, para el diagnóstico y así garantizar la corrección.[33]
• Cuando el equipo encargado del desarrollo del sistema de la solución a las incidencias
reportadas, se deben realizar pruebas que confirmen la solución y se debe validar que no
se hayan incluido nuevos errores. [33]
• La ejecución de las pruebas, los resultados obtenidos y los eventos ocurridos durante la
ejecución, se deben registrar. Esta información permite medir la cobertura de las pruebas
en un determinado momento y conocer los acontecimientos que pueden causar retrasos
de acuerdo a la planeación. [33] De acuerdo al ISTQB, el registro de la información,
permitirá “dar soporte al control de las pruebas, la elaboración de informes sobre el
proceso de pruebas, la medición de los criterios de salida y la mejora del proceso de
pruebas”. [33]

A continuación en la Ilustración 47, se presentan las consideraciones y recomendaciones para


la implementación y ejecución.

Consideraciones Recomendaciones

Algunas veces los


defectos que se Tome evidencias de
reportan, no se vuelvan los resultado de las
a presentar. Lo ejecuciones de
importante es dejar la pruebas, son el
evidencia y la soporte que algo falla
documentación de de o que algo está bien.
lo sucedido .

Ilustración 47. Consideraciones y recomendaciones implementación y ejecución

4.2.10 Herramientas para las actividades de Implementación y ejecución.


4.2.10.1 Priorización de pruebas
Existen diferentes técnicas que permiten realizar la priorización de los casos de pruebas, a
continuación se presentan metodologías que permitirán realizar este proceso.

95
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.10.1.1 Priorización a partir de la evaluación de los riesgos


Esta técnica se basa en la evaluación de los niveles de riesgo que se presentan en los módulos y
funcionalidades que se van a probar. Se fundamenta en la metodología de análisis de riesgos
presentada en la sección 4.2.8, en la herramienta de control. Permite realizar la priorización de los
casos de pruebas, de la siguiente manera:

1. Se debe identificar los módulos impactados para las pruebas. Estos módulos
corresponden a los escenarios de pruebas definido en la sección 4.2.5.
2. Se debe evaluar el modulo e identificar los posibles riesgos que traería a la
organización y usuarios del sistema, si se presenta un mal funcionamiento.
3. Realizar la evaluación de los riesgos identificados para conocer su nivel. Ver la sección
4.2.8. El nivel del riesgo permite identificar los riesgos en una escala de ser bajo,
medio o alto.
4. Agrupar los riesgos por funcionalidades impactadas.
5. Identificar los módulos con mayor cantidad de riesgos altos.
6. Identificar y agrupar los casos de pruebas por funcionalidades impactadas.
7. La ejecución de casos de pruebas debe iniciarse por donde más se presenten riesgos
de nivel alto, teniendo en cuenta las dependencias entre casos. Se pueden presentar
casos con un nivel alto que los antecede casos de prueba de nivel bajo.

4.2.10.1.2 Enfoque priorización de casos de pruebas a partir de un conjunto de casos


Esta técnica de priorización, se encuentra definida en [51], propone asignar pesos a los factores
que influyen en los casos de pruebas. Estos factores son:

• Prioridad asignada por el cliente o usuario del sistema. Corresponde al nivel de


importancia requerimiento (CP).
• La complejidad del requerimiento. (RC)
• Grado de volatilidad de los requerimientos. (RV)

A cada factor, se le asigna un valor y un peso dentro de la escala del 1 al 10, entre más alto sea el
número, mayor es la necesidad de priorizar el caso de prueba relacionado al requerimiento. A
continuación, se calcula el peso de la priorización (WP), que permite determinar los casos de
pruebas que se deben probar de manera temprana, representa el nivel de importancia asignado
para probar un requerimiento.[51]

𝑊𝑃 = ∑10
𝐼=1 𝑃𝐹𝑉𝑎𝑙𝑜𝑟𝑖 ∗ 𝑃𝐹𝑝𝑒𝑠𝑜𝑖 ;

Donde

𝑃𝐹𝑉𝑎𝑙𝑜𝑟 = 𝐶𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑒 𝑎𝑙 𝑣𝑎𝑙𝑜𝑟 𝑑𝑒 𝑐𝑎𝑑𝑎 𝑓𝑎𝑐𝑡𝑜𝑟: 𝐶𝑃, 𝑅𝐶, 𝑅𝑉


𝑃𝐹𝑝𝑒𝑠𝑜 = 𝐶𝑜𝑟𝑟𝑒𝑠𝑝𝑜𝑛𝑑𝑒 𝑎𝑙 𝑝𝑒𝑠𝑜 𝑑𝑒 𝑐𝑎𝑑𝑎 𝑓𝑎𝑐𝑡𝑜𝑟: 𝐶𝑃, 𝑅𝐶, 𝑅𝑉

Los casos de pruebas, se ordenan de mayor a menor WP, determinado así el orden de ejecución se
debe realizar en ese mismo orden, los requerimientos con mayor WP se ejecutan más rápido

A continuación en la Tabla 46, se presenta una plantilla para realiza el cálculo de la prioridad de
los casos de pruebas.

96
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

FACTORES
Nombre caso de Prioridad asignada por el cliente / Complejidad del
prueba requerimiento / Grado de volatilidad Cálculo WP
Valor Peso Cálculo
Corresponde al
Valor asignado Peso asignado Sumatoria de los
nombre del caso Multiplicación
del 1 al 10, del 1 al 10, cálculos de los
de prueba al que del valor por el
para evaluar el para evaluar el factores del caso de
se le realiza el peso para el
caso en cuanto caso en cuanto prueba, corresponde
cálculo de factor 1.
el factor 1. el factor 1 a la priorización.
prioridad.

Tabla 46. Priorización Casos de Prueba

4.2.10.1.3 Priorización a partir de la técnica Use Case Path Análisis


Esta técnica de priorización, se basa en la creación de casos de pruebas a partir de la definición de
un diagrama de flujo mencionado en la Tabla 33, a continuación se presentan los pasos para
definir la prioridad de los casos de pruebas a partir del diagrama de flujo, tomado de [52]

1. Realizar el diagrama de flujo del requerimiento que se va a probar


2. Identificar todos los caminos posibles en el diagrama de flujo, asignarle un identificador
único, y relacionar los nodos del diagrama de flujo que componen el camino.
3. Analizar y asignar un valor a cada camino a partir de la evaluación de los atributos, de una
caso de prueba, “Esta propuesta deja abierta la posibilidad de analizar tantos atributos
como se considere conveniente y propone dos atributos como ejemplo: la frecuencia con
que se ejecuta el camino y el factor crítico del camino.” [52]
a. Por cada atributo se debe evaluar entre uno y diez donde 1 representa que el
atributo no es significativo y 10 representa un atributo muy significativo en el
camino. En la Tabla 47, se presenta un ejemplo sobe posibles atributos:

Descripción
Atributo Valor bajo Valor alto
atributo
Que tan
Camino muy frecuente,
frecuente es Camino poco
Frecuencia que es ejecutado varias
el camino por frecuente
veces por el usuario.
el usuario.
Que tan Un fallo en un Es posible recuperarse de
crítico es un camino que un fallo, no se genera un
Crítico fallo en un impida seguir gasto en recursos
camino trabajando con el mínimo y no representa
sistema pérdida de información
Tabla 47. Atributos priorización, basado en [52]

4. Se realiza de la evaluación del camino a partir de los valores asignados a cada atributo, el
factor camino representa a la prioridad del camino evaluado.

𝐹𝑎𝑐𝑡𝑜𝑟 𝑐𝑎𝑚𝑖𝑛𝑜 = 𝑉𝑎𝑙𝑜𝑟 𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜1 + 𝑉𝑎𝑙𝑜𝑟 𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜2 +. . +𝑉𝑎𝑙𝑜𝑟 𝐴𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑛

97
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

El valor de resultad, del cálculo del factor camino, representa la prioridad del camino o
caso de prueba identificado, entre más alto es este factor, significa que la prioridad del
camino es alta.

Este enfoque, permite incluir los atributos que se consideran necesarios, modificar la escala de
evaluación del atributo y permite que se modifique la formula a partir de las necesidades, por
ejemplo incluir un peso a cada atributo en función de la importancia. [52]

4.2.10.2 Plantilla de ejecución de casos


Si no se cuenta con una herramienta tecnológica para la ejecución de casos de pruebas, se
propone el uso de la plantilla de casos de prueba donde se le incluye una columna de Resultado
obtenido, donde se llevara el registro de los resultados del sistema a partir de los eventos
ejecutados por el usuario.

Nombre significativo del caso de prueba que permita identificar el propósito de


Caso de prueba
la prueba.
Identificador único del caso de prueba.
Se recomienda que inicie la nomenclatura del nombre:
Identificador CPNNNN_NombreCasoDePrueba. Donde CP corresponde a las siglas de casos
caso de prueba de prueba, NNNN corresponde a la numeración única del caso de prueba y el
NombeCasoDePrueba corresponde al nombre significativo asignado en el
campo caso de prueba.
Función probar Definir el modulo, servicio o función que probara con el caso de prueba.
Objetivo Describir que funcionalidad que será probada con el caso de prueba.
Descripción Describir y explicar el propósito el caso de prueba.
Criterios de Definir los criterios de aceptación, que permiten determinar que el caso de
éxito prueba ejecutado es exitoso
Definir los criterios que permiten determinar que el caso de prueba ejecutado
Criterios de falla
es fallido
Describir las condiciones y el estado en las que se debe encontrar el sistema
para la ejecución del caso de prueba, en caso de ser necesario incluir los casos
Precondiciones
de pruebas que deben estar ejecutados previo a la ejecución del caso de
prueba.
Perfil del usuario Perfil del usuario en el sistema con el que se ejecutara la prueba.
Necesidades Definir las necesidades para la ejecución de los casos de pruebas, como por
para el caso de ejemplo los datos de pruebas, las condiciones adicionales a tener en cuenta,
prueba configuración de la prueba.
Autor Nombre de la persona que diseña el caso de prueba
Fecha de
Fecha en la que se diseña el caso de prueba
creación
No Resultado
Usuario del sistema Sistema
paso obtenido
Orden Acción del usuario en el Describir los
Flujo del caso de Respuesta del
en el sistema, definir las resultados
prueba sistema a la acción
que se entradas requeridas en el obtenidos de la
realizada por el
ejecuta paso y que realiza el ejecución del caso
usuario
el paso usuario durante el paso, de prueba

98
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

en caso que presente


entradas, describir que
hace el usuario con las
entradas.

Post condiciones Describir el estado del sistema luego de la ejecución de caso de prueba.
Tabla 48. Plantilla para ejecución de casos de prueba

4.2.10.2 Ejecución de pruebas


La ejecución de pruebas se realiza, realizando el pasos a paso descrito en los casos de pruebas, a
continuación se incluyen aspectos a tener en cuenta:

- Los resultados de las ejecuciones de los casos de prueba se presentarán por la captura de
la documentación (informes, archivos de descarga) o por la demostración (pantallazos).
- Si todos los resultados obtenidos en la ejecución son iguales a los resultados esperados, en
el paso del caso de prueba ejecutado se deberá marcar como “pasado”.
- La ejecución de un caso de prueba es exitoso si todos sus pasos son exitosos y se
encuentran en estado “pasado”
- Si alguno de los resultados obtenidos en un paso del caso de prueba difiere con los
resultados esperados, se debe crear un defecto y la prueba quedara como fallida.
- Si un paso de un caso de prueba es fallido, todo el caso de prueba es fallido.
- La creación de defectos se debe realizar en la plantilla o en la herramienta definida para
este fin.
- Cuando se encuentra un defecto en uno de los caso de prueba, se debe realizar el
reporte del defecto y seguir ejecutando los casos de prueba posteriores (si es posible), o
que no presentan relación con el caso fallido.
- El equipo de desarrollo realizará la corrección de los defectos reportados en los tiempos
establecidos de acuerdo a al impacto y severidad del defecto.
- El líder de pruebas generara un informe diario de la ejecución de pruebas.

Para la validación de defectos solucionados o re-pruebas:

- Cuando la corrección del defecto es entregada para pruebas, se debe volver a ejecutar el
caso de prueba fallido y no repetir todos los casos de prueba previamente ejecutadas y
pasados. Es importante que se tenga en cuenta los impactos de la solución, debido que la
solución puede generar defectos en los ya solucionados.
- Si se encuentra un defecto común en más de un caso de prueba, se deberá reportar un
solo defecto asociando a todos los casos de pruebas donde es común. Cuando la solución
es entregada para pruebas, los casos de prueba donde se presentaba el mismo defecto se
deben volver a ejecutar sin importar que ya hayan sido ejecutados previamente.

En la Ilustración 48, se presenta el flujo de la ejecución de pruebas descrito anteriormente.

99
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 48. Ejecución de casos de prueba

100
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.10.3 Plantilla para el documento de ejecución de casos de pruebas


Ver anexo 6.4

Ilustración 49. Plantilla ejecución de casos de prueba

101
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.10.4 Reporte de defectos


Como se mencionó en la sección 3.2.1, un defecto es “una anomalía producto”[18], que cuando
son identificados por el equipo de pruebas se reporta a los encargados del desarrollo para que
realicen el diagnóstico e implementen la solución requerida, ver Ilustración 6.

Elementos

La categoría de los defectos: corresponde a la causa que origina el defecto, cuando se reportan
defectos, se define la categoría que se considera que corresponde, es posible que la categoría no
sea la correcta y en caso que esto suceda el área de tecnología, debe solicitar la corrección
basándose en el diagnóstico realizado. En la Tabla 49, se presentan las posibles categorías.

Categoría Descripción
El defecto corresponde a problemas con el desarrollo del sistema, por
ejemplo: Error en la lógica del código, error en variables erróneas o no
Código
inicializadas, error por código fuente incompleto, error por codificación
errada de los parámetros, errores en cálculos, desviación del diseño.
Error generado por los datos de prueba, como por ejemplo información
Datos
incompleta, mala interpretación de los resultados.
El defecto corresponde a un error en la ejecución de pruebas, por ejemplo:
Testing Caso de prueba incompleto, incorrecto o faltante, mala ejecución en el plan
de pruebas, registro de defectos que no son defectos.
El defecto corresponde a un error de hardware o de software del sistema,
Infraestructura como por ejemplo: Error del servidor, fallos del sistema operativo, error de
interfaces.
Error en la documentación del requerimiento, porque está especificado
Requerimiento incorrectamente, o el requerimiento es ambiguo, o presenta conflicto con
otros requerimientos, o no especifica funcionalidades.
El defecto corresponde a error en la parametrización en el ambiente de
Parámetros pruebas, como por ejemplo: Error de parámetros mal configurados, o falta
de configuración de parámetros.
Tabla 49. Categoría de los defectos, basado en [53]

La severidad de los defectos: corresponde al nivel de impacto del defecto en la funcionalidad del
sistema, en la Tabla 50 se describen las posibles severidades de un defecto.

Severidad Descripción
El defecto impide que el sistema o aplicación cumpla con un
requerimiento, implica la pérdida del servicio e impiden
Bloqueante
continuar con la operación del sistema y la ejecución de las
pruebas.
Operaciones esenciales son interrumpidas, compromete la seguridad del sistema o
Crítico de las personas que usan el sistema. Se dividen en crítico mayor o critico menor.
Mayor Las operaciones esenciales se ven afectados, pero permiten

102
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

continuar con la ejecución de pruebas


Menor Operaciones no esenciales se interrumpen
El defecto impide que una función de menor impacto para el
Menor sistema el cumplimiento de los requerimientos del usuario. El
defecto no afecta el servicio.
Defectos originados por la mala ortografía, textos desalineados o
Cosmético elementos en pantalla mal situados o incumplimiento en el “look
and feel” de la organización
Tabla 50. Severidad de los defectos, basada en [53]

La prioridad de los defectos: Establece el grado de impacto del defecto sobre su operación, en la
Tabla 51, se clasifican la prioridad de los defectos.

Prioridad Descripción
El defecto afecta a una función importante o crítica de la aplicación y afectará
Urgente el cronograma de las pruebas. Se requiere la máxima prioridad para el análisis
y solución.
El defecto no tiene una afectación importante sobre el cronograma de las
Medio
pruebas.
Este defecto no tiene impacto sobre el sistema que se encuentra en pruebas,
Baja
ni sobre el cronograma de pruebas.
Tabla 51. Prioridad de los defectos

Estados de los defectos: Estado del defecto durante el ciclo de vida. En la Tabla 52 se describen
los estados de los defectos.

Estado Descripción
Se ha identificado un defecto en el sistema durante las pruebas, corresponde al
Abierto
estado inicial.
Solucionado El defecto ha sido solucionado por el área de desarrollo.
En El defecto ha sido solucionado y se encuentra en el ambiente de pruebas para
validación ser validado.
El defecto ha sido reportado como solucionado pero al realizar la re-prueba y la
Reabierto
solución esta no es correcta y el defecto continúa presentándose.
Cerrado La solución al defecto ha sido verificada y se encuentra correctamente.
En el análisis del defecto, se determinó que el defecto no es un defecto, o es un
Rechazado defecto pre – existente, o, corresponde a un error que no puede ser
solucionado por desarrollo.
Cancelado El defecto fue ha sido rechazado por tecnología y la razón es correcta.
El defecto es pre-existente en la versión del sistema que se encuentra instalada
Preexistente
en ambiente de producción.
El defecto se encuentra en el alcance de la prueba, pero la solución del defecto
Diferido
se realizara en una versión posterior

103
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Tabla 52. Estado de los defectos

A continuación, en la Ilustración 50, encuentra el diagrama de la transición de los estados


definidos.

Ilustración 50. Flujo de estado de los defectos

En la Tabla 53, se presenta la plantilla para el reporte de defectos.

Número de la versión del


Nombre significativo Versión de la
Resumen sistema con el que se reporta
del defecto aplicación
el defecto
Identificador único del Fecha en la que se realiza el
Id defecto Fecha reporte
defecto reporte

Nombre de la persona
Detectado
que ejecuto la prueba Estado Estado del defecto
por
y encontró el error
Nombre del proyecto
Aplicación donde se encontró
Proyecto para el cual se Aplicación - Modulo
el defecto y modulo
ejecutan las pruebas.
Definir si se replica o no el
Definir la categoría
Categoría Replica defecto con otros datos pero
del defecto
ejecutando la misma prueba

104
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Definir la severidad Definir la prioridad del


Severidad Prioridad
del defecto defecto
Caso de prueba Nombre del caso de prueba donde se encontró el error
Incluir el mensaje de error presentado al ejecutar la
Mensaje de error
prueba
Realizar la descripción detallada de la prueba y el error
Descripción detallada
presentado
Incluir los datos de pruebas con los que se ejecutó el
Datos de pruebas
caso de prueba.
Evidencia Incluir pantalla donde se evidencia el error reportado
Incluir los anexos requeridos, ejemplo archivos usados
Anexos
en la prueba.
Tabla 53. Plantilla para reportar defectos

4.2.10.5 Plantilla informe de pruebas


Plantilla para el informe de avances de pruebas, ver anexo 6.5

105
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

106
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

107
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Ilustración 51. Plantilla informe de avance de pruebas

108
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

4.2.11 Evaluación de criterios de salida e informes


En esta etapa se evalúan los criterios de salida respecto a los objetivos definidos en el plan de
pruebas, permitiendo definir si las pruebas se encuentran completas. [28]

Ítem Definición
Subproceso Evaluación de criterios de salida e informes.
Evaluar el comportamiento esperado del sistema versus el
Descripción
comportamiento real, analizar las diferencias y reportar los resultados
Objetivos - Determinar las diferencias entre lo planeado contra lo real
- Métricas
- Plan de pruebas
Entradas
- Resultado de pruebas
- Reporte de defectos
Participante - Líder de pruebas.
Forma de trabajar - Evaluación de los resultados obtenidos con el plan de pruebas
Forma de Modelar Métricas definida en la Tabla 44
Salidas - Informe de evaluación
Tabla 54. Información actividad Evaluación de criterios de salida e informes

Para esto se debe contar con:

1. Criterios de aceptación: Define los criterios con los que se aprueba el sistema. [28]
2. Criterios de medida o determinación: Define las medidas del sistema, como por ejemplo
las respuestas del sistema ante un evento. [28]
3. Criterios de salida: Define las salidas del proceso, que permiten conocer que se han
completado todas las tareas que se deben hacer. [28]

Las tareas principales para la evaluación de los criterios de salida son:

• Validar los resultados de las pruebas contra los criterios de salida definidos en la etapa de
planeación. [28]
• Evaluar si se requieren ejecutar más pruebas o modificar los criterios de salida. Se debe
tener en cuenta, el nivel de cobertura de las pruebas versus el esperado, cantidad de
pruebas ejecutas versus las planeadas o diseñadas y los posibles cambios en riesgos del
proyecto. [28]
• Elaboración de informe sobre las pruebas dirigido a los interesados del proyecto, quienes
deben conocer las pruebas que se ha realizado y el resultado obtenidos. Permitiendo en
caso de ser necesario la toma decisiones. [28]
• Los casos de prueba con prioridad alta fueron ejecutados.
• Los defectos y problemas fueron identificados, documentados y administrados.
• El informe final de pruebas realizado.
• Las pruebas de aceptación de usuario fueron realizada.
• Los informes pueden presentar información relevante del proceso de pruebas, de acuerdo
al ISTQB [33] se pueden incluir los siguientes elementos:

109
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

o “Número previsto y número ejecutado de condiciones de prueba, casos de prueba


o especificaciones de prueba, desglosado en función de si las pruebas se
superaron o fallaron”. [33]
o “Número total de defectos reportados, desglosados por gravedad, prioridad de
acuerdo a los defectos solucionados y los pendientes”. [33]
o “Número de cambios (solicitudes de cambio) planeados, aceptados (construidos) y
probados”. [33]
o “Gasto previsto frente al gasto real”.[33]
o “Tiempo previsto frente al tiempo real transcurrido”. [33]
o “Riesgos identificados desglosados en base a los riesgos mitigados por la actividad
de prueba y cualquier riesgo pendiente”. [33]
o “Porcentaje de tiempo de prueba perdido a causa de eventos de bloqueo”.[33]
o “Elementos que han sido probados repetidamente”.[33]
o “Tiempo de prueba total previsto frente al tiempo de prueba efectivamente
planeado”. [33]

En la Ilustración 52, se presentan las entradas y salidas de la actividad de evaluación de criterios de


salida e informes y en la Ilustración 53 las recomendaciones para la actividad.

Reportes de
defectos

Evaluación de
Resultados de
criterios de salida Informe de
pruebas
e informes evaluación

Plan de
pruebas

Métricas

Ilustración 52. Evaluación de criterios de salida e informes

110
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Recomendaciones

Cuandose presenten inconvenientes debido a


personas diferentes al equipo de pruebas,
incluirlos en el informe.

En caso que durante las pruebas se hayan


presentado inconvenientes , inluya en el informe
los reportados en los avances de pruebas

Ilustración 53. Recomendaciones evaluación de criterios de salida e informes

4.2.12 Actividades de cierre


Las actividades de cierre, se realizan una vez se finaliza las actividades de pruebas, recoge los
datos de las actividades, consolida experiencias y la información de lo validado, presenta un
análisis de hechos y números. [28] A continuación en la Tabla 55, se presenta la descripción de la
actividad de cierre.

Ítem Definición
Subproceso Actividades de cierre.
Las actividades realizan la organización de los casos de pruebas para
Descripción
que estos se puedan ejecutar.
Objetivo Realizar el proceso de cierre del pruebas de software
- Documento de plan de pruebas y artefactos que permitan
Entradas
evaluar la finalización del proceso de pruebas.
Participante - lidera de pruebas
Forma de trabajar - Ejecución de las tareas del proceso
- Documento de lecciones aprendías
Salidas
- Plan de acción de los defectos que no fueron solucionados,
Tabla 55. Definición actividad cierre de pruebas

Esta actividad se realiza por lo general cuando se entrega el sistema para ser instalado en
producción, pero también se debe realizar en los casos en que las pruebas no se realizaron o por
aspectos independientes a las pruebas se canceló el proyecto. [28]

Las tareas principales del cierre son:

• Asegurar que las actividades y entregables planeadas, se hayan llevado a acabo, por
ejemplo se debe validar el estado de los incidentes, que se encuentren solucionados o
diferidos para una versión futura y se encuentren debidamente documentados. [28], [33]
• Remitir los productos del trabajo de valor a los interesados del proyecto y a las personas
que necesitan tener a su disposición dicho conocimiento. [33]

111
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

• Realizar reuniones de evaluación, donde se presenten las lecciones aprendidas, se


establezcan planes de mejora para garantizar que no se vuelvan a presentar los
problemas o inconvenientes detectados en el proyecto, así como también las
oportunidades de mejora para el proceso. [33] Estas reuniones con el tiempo aportarán a
la maduración del proceso de pruebas. La información presentada en la reunión y el
resumen de las pruebas, debe documentarse en un informe de evaluación final del
proyecto. [28]
• Archivar la información del proceso de las pruebas, como la ejecución, los resultados
obtenidos, los reportes, informes realizados y documentos utilizados o generados, en un
repositorio de proyectos asociado al sistema objetivo. [33]
• Generar documento de lecciones aprendidas.
• Verificar que los entregables o documentos planeados han sido entregados.
• Verificar que se cuenta con la aceptación del usuario.

En la Ilustración 54, se presentan las entradas y salidas de la actividad de evaluación de criterios de


salida e informes y en la Ilustración 55 las recomendaciones para la actividad.

Lecciones
aprendidas

Informe de
Actividades de
evaluación Reporte de
cierre métricas

Documento de
aprobación de
usuario

Ilustración 54. Actividad de cierre

112
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

Recomendaciones

Tener un repositorio centralizado con los


artefactos de las pruebas, permite que un
futuro las personas personas conozcan
sobre el historial de proyectos y pruebas del
sistema ,o en caso que se realicen auditorias
al proceso, se cuente con la información
centralizada.

Ilustración 55. Recomendaciones actividades de cierre

113
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

5 Referencias y Bibliografía
[1] «El outsourcing, aliado del ahorro en los negocios», Portafolio, p. 1, 22-jul-2013.
[2] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Foundation
Level Syllabus». 31-mar-2011.
[3] J. E. Romero Pérez, «La externalización de actividades laborales (outsourcing)». [En línea].
Disponible en: http://latindex.ucr.ac.cr/index.php/juridicas/article/download/13379/12644.
[Accedido: 30-sep-2014].
[4] Grupo BN Outsourcing, «Ventajas e inconvenientes del outsourcing». [En línea]. Disponible en:
http://www.bnoutsourcing.com/articulos/ventajas-y-desventajas-del-outsourcing. [Accedido:
26-may-2014].
[5] F. Ganga Contreras y I. Toro Reinoso, «Externalización De Funciones: Algunas Reflexiones
Teóricas», Estudios gerenciales, vol. 24, n.o 107, pp. 107-135, 30-abr-2008.
[6] J. A. Bohon Devars, «Ventajas y desventajas del outsourcing», 31-jul-2009. [En línea].
Disponible en: http://www.cnnexpansion.com/opinion/2009/07/30/ventajas-y-desventajas-
del-outsourcing. [Accedido: 30-jul-2014].
[7] I. Sommerville, Ingenieria del Software. Madrid: Pearson Educacion, 2005.
[8] ISTQB, International Software Testing Qualifications Board, «Glossary Archive - ISTQB®
Glossary of Testing Terms». Erik van Veenendaal (The Netherlands), 19-oct-2012.
[9] B. W. Boehm, «GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE REQUIREMENTS
AND DESIGN SPECIFICATIONS».
[10] I. S. 12207-2008 ISO/IEC 12207, «Systems and software engineering — Software life cycle
processes». 01-feb-2008.
[11] O. R. Puello, «Modelo de verificación y Validación basado en CMMI», Innovación Ing, vol. 1, n.o
1, pp. 20-27, jun-2013.
[12] IEEE Computer Society, «1012-2012 - IEEE Standard for System and Software Verification and
Validation». may-2012.
[13] IEEE Std 1059- 1993, «IEEE Guide for Software Verification and Validation Plans». 02-dic-1994.
[14] IEEE Computer Society, «Guie to the Software Engineering body of Knowledge - SWEBOK
Guide V3.0». 2013.
[15] G. J. Myers, C. Sandler, y T. Badgett, The Art of Software Testing, Edición: 3. Auflage. Hoboken,
N.J: Wiley John + Sons, 2011.
[16] Real Academia Española, «Diccionario de la lengua española», 2014. [En línea]. Disponible en:
http://www.rae.es/. [Accedido: 01-oct-2014].
[17] IEEE Computer Society, «Systems and software engineering – Vocabulary», ISOIECIEEE
247652010E, pp. 1-418, dic. 2010.
[18] «IEEE Standard Dictionary of Measures to Produce Reliable Software», IEEE Std 9821-1988, pp.
1-54, 1989.
[19] R. Patton, Software Testing, 2 edition. Indianapolis, IN: Sams Publishing, 2005.
[20] ISO/IEC/IEEE 29119-1:2013(E), «Software and systems engineering Software testing Part 1:
Concepts and definitions», sep. 2013.
[21] Instituto Nacional de Tecnologías de la Comunicación - INTECO, «Guía de validación y
Verificación», nov-2009. [En línea]. Disponible en:
http://www.inteco.es/qualite_TIC/descargas/guias/?realLang=fr. [Accedido: 16-ago-2014].
[22] G. Rothermel, R. H. Untch, C. Chu, y M. J. Harrold, «Prioritizing test cases for regression
testing», IEEE Trans. Softw. Eng., vol. 27, n.o 10, pp. 929-948, oct. 2001.

114
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

[23] R. S. Pressman, Ingenieria del Software - Un Enfoque Practico, 6.a ed. Madrid: McGraw-Hill
Companies, 2002.
[24] B. Bruegge y Allen H. Dutoit, Ingeniería de Software orientado a objetos, Primera Edición., vol.
1. México: Prentice Hall, 2002.
[25] «IEEE Standard Glossary of Software Engineering Terminology», IEEE Std 61012-1990, pp. 1-
84, dic. 1990.
[26] K. Naik y P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, 1 edition.
Hoboken, N.J: Wiley-Spektrum, 2008.
[27] A. M. J. Hass, Guide to Advanced Software Testing. Boston: Artech House, 2008.
[28] D. Graham, E. V. Veenendaal, I. Evans, y R. Black, Foundations of Software Testing: ISTQB
Certification, Revised edition. Australia: Cengage Learning EMEA, 2008.
[29] A. Eseiza, «Guia para la escritura de casos de prueba», 08-mar-2011. [En línea]. Disponible en:
http://alejandroeseiza.blogspot.com/2011/03/guia-para-la-escritura-de-casos-de.html.
[Accedido: 20-oct-2014].
[30] D. Galin, Software Quality Assurance: From Theory to Implementation, 1 edition. Harlow,
England ; New York: Addison-Wesley, 2003.
[31] W. E. Perry, Effective Methods for Software Testing: Includes Complete Guidelines, Checklists,
and Templates, 3 edition. Indianapolis, IN: Wiley, 2006.
[32] J. Watkins, Testing IT : An Off-the-Shelf Software Testing Handbook. Port Chester, NY, USA:
Cambridge University Press, 2001.
[33] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Advanced Level
Syllabus Test Manager». 19-oct-2012.
[34] B. Pérez Lamancha, «Proceso de Testing funcional Independiente», Universidad de la
República, Montevideo, Uruguay, 2006.
[35] J. McCaffrey, «What Makes A Good Software Tester?», dic-2008. [En línea]. Disponible en:
http://msdn.microsoft.com/en-us/magazine/dd252951.aspx. [Accedido: 11-dic-2014].
[36] Cibertec, «Manual - Pruebas de Software», feb-2012. [En línea]. Disponible en:
https://code.google.com/p/cibertec/downloads/detail?name=Pruebas%20de%20Software.pd
f&can=2&q=. [Accedido: 13-nov-2014].
[37] ISO/IEC/IEEE 29119-1:2013(E), «Software and systems engineering Software testing Part
2:Test processes». 01-sep-2013.
[38] A. Santanach, J. E. Vargas, L. Ramírez, D. R. Prieto, y M. Ramos, «Propuesta de un método de
estimación de tiempo y esfuerzo para las pruebas de liberación, aceptación y piloto», Rev.
Colomb. Comput., vol. 13, pp. 7-22, feb. 2012.
[39] D. Longstreet, «Fundamentals of Function Point Analysis», Software Development Magazine,
2005.
[40] R. Meneses, «Estimación de tamaño de Software: Puntos de función». [En línea]. Disponible
en:
https://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=principal:cso
f5101_-_estimacionpuntosfuncionales.pdf. [Accedido: 22-nov-2014].
[41] «Using Function Points». [En línea]. Disponible en:
http://www.softwaremetrics.com/Articles/using.htm#Section3. [Accedido: 22-nov-2014].
[42] «Test Cases & Defects». [En línea]. Disponible en:
http://www.softwaremetrics.com/Articles/defects.htm. [Accedido: 22-nov-2014].
[43] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Advanced Level
Syllabus Test Analyst». 19-oct-2012.
[44] J. J. Gutiérrez, «Generación de pruebas de sistema a partir de la especificación funcional»,
Universidad de Sevilla, Sevilla España, 2005.

115
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

[45] J. Ryser y M. Glinz, «SCENT: A Method Employing Scenarios to Systematically Derive Test
Cases for System Test», Institut für Informatik, Universität Zürich, Technical Report 2000/03,
2003.
[46] «7. Análisis de Riesgo», Gestión de Riesgo en la Seguridad Informática. [En línea]. Disponible
en: http://protejete.wordpress.com/gdr_principal/analisis_riesgo/. [Accedido: 21-nov-2014].
[47] «IEEE Standard for a Software Quality Metrics Methodology», IEEE Std 1061 TM -1998, 1998.
[48] M. de los Á. Rubalcaba Betancourt, Y. Zambrana Hernández, y H. M. Cruz Torres, «Medición
de la calidad de un producto software durante el proceso de pruebas en un proyecto
productivo», Ser. Científica Univ. Las Cienc. Informáticas SC-UCI, vol. 3, n.o 10, 2010.
[49] R. Black, Advanced Software Testing - Vol. 1: Guide to the ISTQB Advanced Certification as an
Advanced Test Analyst, 1 edition. Santa Barbara, CA: Rocky Nook, 2008.
[50] H. Al-Kilidar, K. Cox, y B. Kitchenham, «The use and usefulness of the ISO/IEC 9126 quality
standard», 2005, pp. 122-128.
[51] S. Roongruangsuwan y J. Daengdej, «Test case prioritization techniques», Journal of
Theoretical and Applied Information Technology, vol. 18, n.o 2, 2010.
[52] J. J. Gutiérrez, M. J. Escalona, M. Mejías, y J. Torres, «Estudio comparativo de propuestas para
la generación de casos de prueba a partir de requisitos funcionales». Escuela Técnica Superior
de Ingeniería Informática. Universidad de Sevilla, feb-2005.
[53] «IEEE Standard Classification for Software Anomalies», IEEE Std 1044-2009 Revis. IEEE Std
1044-1993, pp. 1-23, ene. 2010.

116
Pontificia Universidad Javeriana Guía Metodológica V2Soft– Trabajo de grado

6 Anexos

6.1 Plantilla plan de pruebas


Ver documento [Anexo 1] Plantilla SVVP.

6.2 Plantilla documento gestión de riesgos


Ver documento [Anexo 2] Documento de riesgos.

6.3 Plantilla documento casos de pruebas


Ver documento [Anexo 3] Documento de casos de prueba.

Ver documento [Anexo 6] Documento diseño.

Ver documento [Anexo 7] Ejemplo aplicación documento de diseño.

6.4 Plantilla para la ejecución de casos de pruebas.


Ver documento [Anexo 4] Documento de ejecución de casos de prueba.

6.5 Plantilla para el informe de avance de pruebas.


Ver documento [Anexo 5] Informe Avance de pruebas.

6.6 Documento marco de referencia – Way Of.


Ver documento [Anexo 8] Marco de referencia Guía - Way of.

117