Marco Teórico - Trabajos de Grado de la facultad de...
Transcript of Marco Teórico - Trabajos de Grado de la facultad de...
CIS1430IS08
V2Soft: guía metodológica para
el proceso de validación y
verificación de requerimientos
para el usuario final
Marco Teórico Trabajo de grado – Ingeniería
de Sistemas
Pontificia Universidad
Javeriana.
2015
María Ximena Narváez Barrera
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
1
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
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
2
Contenido 1 Marco teórico ................................................................................................................................... 6
1.1 Tercerización del desarrollo ...................................................................................................... 7
1.2 Ventajas y desventajas de la tercerización ............................................................................... 8
1.2.1 Ventajas .............................................................................................................................. 8
1.2.2 Desventajas ........................................................................................................................ 8
2 Definición requerimiento ............................................................................................................... 10
2.1 Atributos de calidad de los requerimientos ............................................................................ 11
3 La ingeniería de Requerimientos.................................................................................................... 13
4 Validación y Verificación de requerimientos ................................................................................. 16
4.1 Objetivo de la Validación y Verificación .................................................................................. 17
4.2 La Validación y Verificación de requerimientos en el ciclo de vida del Software ................... 17
4.2.1 Modelo en V ..................................................................................................................... 18
4.2.2 Modelo incremental y evolutivo ...................................................................................... 20
4.2.3 Modelo en espiral............................................................................................................. 21
4.2.4 Modelo de prototipos ...................................................................................................... 22
4.3 Actividades de Validación y Verificación ................................................................................. 22
5 Pruebas de Software ...................................................................................................................... 28
5.1 Conceptos ................................................................................................................................ 28
5.2 ¿Cuándo surgen los defectos? ................................................................................................ 30
5.3 ¿Porque las pruebas son necesarias? ..................................................................................... 30
5.3.1 Importancia de la calidad y de las pruebas ...................................................................... 31
5.3.2 Pruebas a realizar ............................................................................................................. 34
5.3.3 Objetivos de quien realiza pruebas. ................................................................................. 35
5.4 Principios de las pruebas ......................................................................................................... 35
5.5 Características de las pruebas ................................................................................................. 37
5.6 Niveles de pruebas .................................................................................................................. 38
5.6.1 Niveles principales ............................................................................................................ 38
5.6.2 Otros niveles de pruebas .................................................................................................. 43
5.7 Tipos de pruebas .................................................................................................................... 45
5.7.1 Pruebas de funciones o pruebas funcionales ................................................................... 45
5.7.2 Pruebas no funcionales o de características no funcionales del software ...................... 45
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
3
5.7.3 Pruebas de estructura o Arquitectura de software ......................................................... 46
5.7.4 Pruebas asociadas a cambios ........................................................................................... 46
5.8 Casos de pruebas .................................................................................................................... 47
5.8.1 ¿Qué es un caso de prueba? ............................................................................................ 47
5.8.2 Características y beneficios de un caso de prueba ......................................................... 47
5.8.3 Elementos de un caso de prueba ..................................................................................... 48
6 Técnicas de pruebas ....................................................................................................................... 49
6.1 Basada en especificación (Caja negra) .................................................................................... 49
6.1.1 Partición de equivalencia ................................................................................................. 50
6.1.2 Análisis de valores limites ................................................................................................ 51
6.1.3 Tabla de decisión .............................................................................................................. 52
6.1.4 Grafos de causa- efecto .................................................................................................... 54
6.1.5 Transición de estados ....................................................................................................... 55
6.1.6 Casos de uso ..................................................................................................................... 57
6.2 Basada en estructura (Caja Blanca) ......................................................................................... 58
6.3 Basadas en experiencia ........................................................................................................... 61
6.3.1 Predicción de error ........................................................................................................... 61
6.3.2 Pruebas Exploratorias ...................................................................................................... 61
7 Bibliografía ..................................................................................................................................... 63
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
4
Índice de ilustraciones Ilustración 1. Secciones documento Marco teórico ............................................................................ 6
Ilustración 2. Actividades Empresa ..................................................................................................... 7
Ilustración 3. Ingeniería de requerimientos[14] ............................................................................... 14
Ilustración 4.Proceso de validación y verificación en ciclo de vida, adaptado de [25] ..................... 18
Ilustración 5. Actividades de validación y verificación en el modelo en V, tomado de [27] ............. 20
Ilustración 6. Modelo Incremental, tomado de [27] ......................................................................... 21
Ilustración 7.Modelo en espiral, tomado de [27].............................................................................. 21
Ilustración 8. Modelo de prototipos, tomado de [27] ...................................................................... 22
Ilustración 9. Actividades de Validación y Verificación, tomado de [26] .......................................... 23
Ilustración 10.Relación Error, defecto, falla ...................................................................................... 29
Ilustración 11. Origen defectos, tomado de [28] .............................................................................. 30
Ilustración 12. Distribución de los defectos, tomado de [47] ........................................................... 31
Ilustración 13. Esfuerzo para encontrar y corregir defectos, tomado de [47] .................................. 32
Ilustración 14. El costo de la corrección, tomado de [45] ................................................................. 33
Ilustración 15.Pruebas de regresión en, tomado de [51] ................................................................ 42
Ilustración 16. Pruebas funcionales .................................................................................................. 45
Ilustración 17. Pruebas no funcionales ............................................................................................. 46
Ilustración 18. Depuración de defectos, tomado de [18] ................................................................. 46
Ilustración 19.Casos de pruebas, adaptado de [54] .......................................................................... 48
Ilustración 20. Técnicas de pruebas, adaptado de [42] , [28], [27] ................................................... 49
Ilustración 21.Técnica de caja negra ................................................................................................. 50
Ilustración 22. Partición de equivalencia, tomado de [29] ............................................................... 50
Ilustración 23. Valores de entrada partición de equivalencia .......................................................... 51
Ilustración 24. Análisis de valores limites, adaptado de [29] ............................................................ 51
Ilustración 25. Análisis valor frontera ............................................................................................... 52
Ilustración 26.Función grafo de causa – efecto, tomado de [29] ..................................................... 54
Ilustración 27. Diagramas posibles de causa – efecto, tomado de [42]............................................ 55
Ilustración 28. Transición de estados ................................................................................................ 55
Ilustración 29. Transición de estados, adaptado de [28] .................................................................. 56
Ilustración 30. Técnica de caja blanca ............................................................................................... 58
Ilustración 31. Pruebas exploratorias................................................................................................ 62
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
5
Índice de Tablas Tabla 1. Desventajas Outsourcing ....................................................................................................... 9
Tabla 2. Tipos de Requerimientos y nivel de granularidad ............................................................... 11
Tabla 3. Verificaciones en requerimientos, tomado de [27] ............................................................. 19
Tabla 4. Porción costo por fase. Tomado de [47] ............................................................................. 33
Tabla 5. Pruebas unitarias ................................................................................................................. 38
Tabla 6. Pruebas de integración ........................................................................................................ 39
Tabla 7. Pruebas de sistema .............................................................................................................. 40
Tabla 8. Pruebas de aceptación ........................................................................................................ 41
Tabla 9. Pruebas de regresión ........................................................................................................... 42
Tabla 10. Otros niveles de pruebas ................................................................................................... 44
Tabla 11. Tablas de decisión.............................................................................................................. 53
Tabla 12. Ejemplo tabla de decisión .................................................................................................. 53
Tabla 13. Transición de estados por eventos, adaptado de [28] ...................................................... 56
Tabla 14. Transición de estados por transición, adaptado de [29] ................................................... 57
Tabla 15. Descripción caso de uso, adaptado de [28],[29] ............................................................... 58
Tabla 16. Técnicas de pruebas de caja blanca .................................................................................. 60
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
6
1 Marco teórico
En este documento se presentan las bases teóricas para el desarrollo del trabajo de grado V2Soft: guía metodológica para el proceso de validación y verificación de requerimientos para el usuario final. El documento se encuentra organizado en siete secciones, que se presentan a continuación en la Ilustración 1.
Ilustración 1. Secciones documento Marco teórico
Sección 1
•Presenta el modelo de empresa a la que va dirigida la guía metodológica y lacontextualización sobre la tercerización del desarrollo.
Sección 2
• Presenta el marco conceptual de lo que es un requerimiento y sus atributos de calidad.
•Es importante conocer que es un requerimiento, debido que la guía busca la validación yverificación de los requerimientos.
Sección 3
•Presenta el proceso de ingeniería de requerimientos.
• Incluye la contextualización del proceso de validación y verificación de requerimientos.
Sección 4
•En esta sección, se profundiza sobre la validación y verificación de requerimientos, sepresentan los objetivos del proceso, los modelos de ciclo de vida y las actividades devalidación y verificación.
Sección 5
•Se centra en las pruebas de software, es de las secciones más importantes, debido que enel contexto de la guía la validación y verificación de requerimientos para usuario final serealiza por medio de las pruebas de software.
•Se presenta información sobre las definiciones que son necesarias para el proceso, comosurgen los defectos, el porque las pruebas son necesarias, los principios de las pruebas, lascaracterísticas de las pruebas, los niveles, los tipos y casos de pruebas.
Sección 6
• Se presentan las técnicas de pruebas que permiten crear casos de pruebas efectivos ytener una mayor exactidud en el momento de su definición.
Sección 7
•Se presenta el proceso de pruebas.
Sección 8
•Se presenta la bibliografía usada en el desarrollo del documento.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
7
1.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:
Ilustración 2. Actividades Empresa
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.
Define y especifica
Requerimientos
Terceriza desarrollo
Recibe desarrollo
Valida y Verifica Requerimientos
Certifica producto
Instalación del producto en producción
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
8
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.
1.2 Ventajas y desventajas de la tercerización
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.
1.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]
1.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].
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
9
Desventaja Implicación en proceso V&V (el autor)
Es necesario que se gestione la empresa
tercera que es responsable de las tareas
de desarrollo.[4]
Obliga a la empresa a estar pendiente de la
empresa tercera para garantizar el cumplimento
de las entregas esperadas.
Existe el riesgo que la empresa de
outsourcing se declare en quiebra o pase
por dificultades importantes.[4]
Se puede presentar retrasos en los proyectos que
dependen directamente del desarrollo.
La empresa tercera, atiende a otros
clientes, o la empresa que subcontrata no
es atendida con la dedicación necesaria.[4]
Implica que los desarrollos o solución a los
defectos encontrados en el proceso de validación
y verificación de requerimientos no se den en los
tiempos esperados, generando retraso en los
objetivos de la empresa.
La comunicación no es la esperada, debido
que no se expresan inquietudes, dudas o
preguntas, que se pueden presentar a lo
largo del desarrollo del proyecto. [4]
Los desarrollos no cumplen con la funcionalidad
esperada, debido que la empresa supone muchas
de las respuestas.
Dependencia con el proveedor del
servicio.[4], [6]
Se dependerá de los tiempos de respuesta para
solucionar los problemas, o defectos encontrados
en el proceso.
Puede perderse el control sobre el
producto final y verse afectada la calidad.
[4], [6]
Surge, la necesidad de la validación y verificación
de los requerimientos para el usuario final.
Se puede afectar la confidencialidad de los
productos nuevos y novedosos. [4], [6]
Al tercerizar el desarrollo es la empresa tercera
quien materializara la idea, por lo tanto los
servicios y productos novedosos dependerán de la
confidencialidad que se establezca.[3]
Tabla 1. Desventajas Outsourcing
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
10
2 Definición requerimiento
Uno de los puntos más importantes para tener el éxito en los proyectos y tener buenos productos,
es el entendimiento de los requerimientos por parte de los interesados[7], debido a que permite
tener claridad sobre lo que se debe realizar y las condiciones que se deben satisfacer, lo que
obliga a que exista un importante trabajo para lograr comprender el objetivo del producto, por lo
tanto es necesario revisar lo que es un requerimiento.
Ahora bien, en la literatura de la ingeniería de software se encuentran diversas definiciones de lo
que es un requerimiento, debido que son la base para el desarrollo de esta área de conocimiento.
Los requerimientos recogen las necesidades y definiciones de un usuario para el desarrollo u
optimización de un sistema, tal como lo define Bruegge un requerimiento es una “Función que
debe tener el sistema (un requerimiento funcional) o una restricción sobre el sistema visible ante
el usuario (Requerimiento no funcional)”[8], o bien Young define “Un requerimiento es un
atributo necesario en un sistema, una declaración que identifica la capacidad, Las características o
cualidades de un sistema, que le da valor y utilidad a un usuario o cliente”[9].
Por lo tanto un requerimiento, en marca las características, funcionalidades y las propiedades
deseadas de un producto de software, las restricciones que se deben cumplir, permite definir lo
que se desea que el sistema realice y el comportamiento esperado, son el cimiento del sistema a
construir, el Swebok define, “Un requerimiento de software es una característica que se debe
exhibir para solucionar un cierto problema del mundo real. La guía se refiere a requerimientos de
software porque se refiere a los problemas que se tratarán por el software. Por lo tanto, un
requerimiento de software es una característica que se debe exhibir por el software desarrollo o
adaptado para solucionar un problema en particular”[10].
Existen diferentes tipos de requerimientos, que dependen del enfoque de la especificación y
origen, correspondientes a los niveles de descripción, en la Tabla 2, se encuentra la definición de
cada requerimiento.
Tipo de requerimientos de software
Requerimientos de sistema “Establecen con detalles las funciones, servicios y
restricciones operativas del sistema. Definen exactamente
lo que se va a implementar”[11], representan los
requerimientos para el sistema en su totalidad y presentan
las características del software. [10]
Se dividen en:
Requerimientos funcionales
Requerimientos no funcionales
Requerimientos Funcionales “Son declaraciones de los servicios que debe proporcionar
el sistema, de la manera en que éste debe reaccionar a
entradas particulares y de cómo se debe comportar en
situaciones particulares.”[11], Describen las funciones que
el software va a ejecutar. [10]
Los requerimientos funcionales se pueden dividir en dos
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
11
categorías: Requerimientos nominales y requerimientos no
nominales.
Requerimientos
nominales
Especifica el comportamiento del
sistema en situaciones normales. [12]
Requerimientos
no nominales
Especifica el comportamiento del
sistema en situaciones especiales o
condiciones de error. [12]
Requerimientos no Funcionales “Son restricciones de los servicios o funciones ofrecidos por
el sistema. Incluye restricciones de tiempo, sobre el
proceso de desarrollo y estándares.”[11], son los
requerimientos que actúan para obligar a una solución y
especifican las propiedades del sistema, se conocen
muchas veces como requisitos de calidad y estos tienen a
ser clasificados de acuerdo a su interés[10]:
Requerimientos de funcionamiento
Requerimientos de capacidad de mantenimiento
Requerimientos de seguridad
Requerimientos de confiablidad, entre otros.
Nivel de granularidad
Requerimientos de usuario
“Son declaraciones, en lenguaje natural y en diagramas de
los servicios que se espera que el sistema proporcione y de
las restricciones bajo las cuales debe funcionar”.[11]
Requerimientos de negocio Corresponden a una descripción a alto nivel de lo que el
sistema debe hacer. [7] por ejemplo presentan: los
objetivos, la visión y el alcance
Requerimientos de dominio “Son requerimientos que provienen del dominio de
aplicación del sistema y que reflejan las características y
restricciones de ese dominio. Pueden ser funcionales o no
funcionales”[11]
Tabla 2. Tipos de Requerimientos y nivel de granularidad
2.1 Atributos de calidad de los requerimientos
Existen características asociados a los requerimientos que definen que este es correcto, por lo
tanto es un requerimiento eficaz que cumple con las características de calidad, las cuales son
importantes debido que apoyan al buen desarrollo del proceso de Validación y Verificación.
1. Correcto: Describe con precisión la funcionalidad requerida, expresando así las
necesidades de los clientes.[13],[14]
2. Viable o factible: El requerimiento debe ser posible implementar dentro de las
capacidades y restricciones del negocio. [13]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
12
3. Necesario: El requerimiento debe representar una necesidad que es requerida por el
cliente, debe presentar un origen y fuente clara que tenga un objetivo a cumplir. [13]
4. Priorizado: Definición de la importancia del requerimiento respecto a la necesidad de
implementación, corresponde al balance lo que se quiere primero y lo que los
desarrolladores creen. [13], [14]
5. Inequívoco: El requerimiento no tiene más de una interpretación, lo que significa que el
requerimiento solo se entiende de una sola forma, no presenta confusiones ni
ambigüedades. [13], [14],[15]
6. Verificable: Es posible evaluar el cumplimiento del requerimiento y su correcta aplicación
en el producto a partir métodos de verificación: pruebas, inspecciones o demostraciones.
[13], permite comprobar que el requerimiento se cumple.[15]
7. Completo: Se describe en el requerimiento la funcionalidad que debe realizar, la
información que se presenta es la necesaria y es completa. [13] Por lo tanto no necesita
que se amplié su descripción y su definición es suficiente para su comprensión.[15]
8. Consistente: El requerimiento no presentan conflictos, ni se contradice con otros
requerimientos. [13], [14], [15]
9. Modificable: Los requerimientos deben ser modificables y especificados por separado, en
caso que se presente un cambio este no debe afectar a otros requerimientos lo que
permite que no se presente ambigüedades y llevar un control de los cambios realizados.
[14]
10. Fácil de seguir: Los requerimientos deben tener una relación en cada uno de los artefactos
existentes en el proyecto como el diseño, el código fuente y los casos de prueba, lo que
permite tener trazabilidad desde su origen hasta su validación. [13],[14]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
13
3 La ingeniería de Requerimientos
La ingeniería de requerimientos, es la ciencia y disciplina de la ingeniería de software, que se
preocupa por encontrar, establecer, analizar, documentar, verificar y administrar los
requerimientos de software, permite denotar una dirección sistemática de los requisitos.[10], [14],
[16]
A continuación se presentan definiciones encontrados sobre la ingeniería de requerimientos
De acuerdo a Sommerville, “La ingeniería de requerimientos es el proceso de desarrollar
una especificación de software. Las especificaciones pretender comunicar las necesidades
del sistema del cliente a los desarrolladores del sistema”. [11]
Según el Departamento de Defensa de América (DoD), la ingeniería de requerimientos
"Implica todas las actividades del ciclo de vida dedicados a la identificación de las
necesidades de los usuarios, el análisis de los requisitos para derivar requisitos adicionales,
la especificación de los requisitos y la validación de los requisitos documentados contra las
necesidades del usuario, así como los procesos que soportan estas actividades".[17]
Pressman menciona en su libro [18] “Ingeniería de Requerimientos ayuda a los ingenieros
de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto
de tareas que conducen a comprender cuál será el impacto del software sobre el negocio,
qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”.
La ingeniería de requerimientos enmarca dos grupos de procesos: el desarrollo y la administración
de requerimientos definidos en la Ilustración 3, que presentan las actividades del ciclo de vida de
los requerimientos que “proporciona el mecanismo apropiado para entender lo que el cliente
quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable,
especificar la solución sin ambigüedades, validar la especificación y administrar los requisitos
conforme éstos se transforman en un sistema operacional”[18].
.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
14
Ilustración 3. Ingeniería de requerimientos[14]
• Desarrollo de requerimientos: se encarga de identificar, acordar, analizar y registrar los
requerimientos.
o Levantamiento o recolección: Actividad dirigida a recopilar los requerimientos, es
una actividad importante debido que los clientes pueden presentar confusiones o
no estar seguros de sus necesidades, por lo tanto es una etapa que permite
aclarar los requerimientos [14],[18]. Permite la comprensión del problema a
solucionar, identificar y establecer los límites del sistema [10].
o Análisis: El objetivo es el análisis de los requerimientos obtenidos en la etapa
anterior, con el fin de comprender, aclarar y refinar las necesidades de los clientes
[14], [19] y permitirá ejecutar las próximas actividades. Permite analizar la
viabilidad del requerimiento y asignarle una prioridad.[14]
De acuerdo con el Swebok [10], el análisis de requerimientos permite:
“Detectar y resolver los conflictos entre los requisitos”[10]
“Descubrir los límites del software y cómo debe obrar recíprocamente con
su ambiente.”[10]
“Elaborar los requisitos del sistema para derivar requisitos software”[10]
o Especificación: Corresponde a la tarea de documentar los requerimientos
definidos y analizados en las etapas anteriores en documento o plantilla estándar
[18], se define de manera detallada las funcionalidades, el comportamiento, las
capacidades y restricciones del sistema que se va a construir. [14], [20]
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Levantamiento o Recolección
Análisis
Especificación
Verificación y Validación
Administración de
Requerimientos
Captura
Trazar
Monitoreo y Reporte
Administración del cambio
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
15
La especificación de requerimientos permite una realizar una evaluación rigurosa
de los requerimientos antes iniciar el diseño y reduciendo así la probabilidad de un
reajuste posterior. Proporciona la base para la estimación de costos y tiempos, así
como la identificación de riesgos y ser la base para todo el proceso de ingeniería
de software.[10], [18]
o Verificación y Validación: “La validación de requerimientos trata de mostrar que
éstos realmente definen el sistema que el cliente desea” [11], Pressman define
este proceso como la etapa donde se "examina la especificación para asegurar
que todos los requerimientos de software se han establecido de manera precisa,
que se han detectado las inconsistencias, omisiones y errores y que éstos han sido
corregidos, y que los productos de trabajo cumplen con los estándares
establecidos para el proceso, proyecto y producto"[18]. Para mayor información,
dirigirse a la sección 4 Validación y Verificación de requerimientos.
• Administración de Requerimientos: Se encarga de administrar los cambios que surgen en
los requerimientos una vez estos se encuentran implementados, permite identificar,
controlar y rastrear los requerimientos y sus cambios. [14], [18]
o Captura: permite identificar requerimientos, definir los atributos de calidad y
priorización de requerimientos. [14]
o Trazar: El objetivo de la actividad es generar una trazabilidad de los
requerimientos a lo largo del proyecto, desde su origen hasta su implementación.
[14]
o Monitoreo y Reporte: Definir las políticas de administración y almacenar los
requerimientos rechazados.[14]
o Administración del cambio: Procedimiento para llevar el control de los cambios
sobre los requerimientos, permitiendo tener un seguimiento de cada cambio de
alcance. [14]
Cuando se realiza un buen proceso de ingeniería de requerimientos, se da la base y los
fundamentos del sistema al equipo de desarrollo y al cliente respecto de lo que será probado y se
espera del sistema, disminuyendo las brechas entre la definición y el desarrollo.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
16
4 Validación y Verificación de requerimientos
El proceso de Validación y Verificación de los requerimientos, busca garantizar que los
requerimientos especificados 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” [11], este proceso permite
comprobar que de los requerimientos desarrollados se encuentran conforme a los requerimientos
especificados 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."[21] 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."[21].
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 [22], [11] 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 [11]; 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 [11]. 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 [23] 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 [23]:
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
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.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
17
4.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.[24]
• Garantizar que el sistema es lo suficientemente bueno para su uso pretendido. [24]
• 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.[24]
Entre los beneficios del proceso:
• Facilitar la detección temprana y la corrección de las anomalías [25]
• Asegurar los requerimientos del usuario.[24]
• 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. [24]
• Asegurar que las necesidades de los usuarios son comprendidas y asegurar que los
productos satisfagan el entorno previsto para el que fueron desarrollados. [24]
• Mejorar la calidad de los procesos y los productos. [24], [25]
• Mejorar la productividad y permite conocer de manera temprana el rendimiento.[24], [25]
• Mejorar la comprensión de la gestión de riesgos de procesos y productos.[25]
• Proporcionar evidencia objetiva de conformidad del producto para apoyar al proceso de
certificación.[25]
• Soporte a las actividades de mejora de procesos. [25]
4.2 La Validación y Verificación de requerimientos en el ciclo de vida del
Software
El proceso de Validación y Verificación de Requerimientos se puede realizar sobre el software, el
hardware y los productos del sistema [26], por lo tanto se cuenta con varias actividades enfocadas
al nivel en el que se realiza el proceso, proporcionando así una evaluación objetiva de los
requerimientos, permitiendo conocer si estos son correctos, completos, exactos, coherentes y
verificables, atributos mencionados en la sección 2.1.
El proceso de Validación y Verificación de software se realiza en todas las etapas del ciclo de vida
del software, permitiendo evaluar que el producto de cada actividad se ajusta a los
requerimientos definidos, si se satisface los usos y necesidades previstos. Las actividades incluyen
la evaluación, el análisis, la revisión, la inspección y pruebas de los productos y procesos.[25] En la
Ilustración 4, se presenta la síntesis del proceso.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
18
Ilustración 4.Proceso de validación y verificación en ciclo de vida, adaptado de [25]
Al poder validar y verificar los requerimientos a lo largo de todo el ciclo de vida del software, se
requiere que la planificación del proceso comience en las etapas tempranas del proceso de
desarrollo, con la ayuda de los modelos de ciclo de vida. En las siguientes secciones se presentara
el proceso de validación y verificación para los modelos de ciclo de vida: Modelo en V, Modelo
incremental, Modelo espiral y Modelo de prototipo. [27]
De manera general, el proceso de validación y verificación de requerimientos a lo largo del ciclo de
vida del software, tiene en cuenta que:
• Por cada actividad de desarrollo, debe existir una actividad de pruebas. [28]
• Cada nivel de prueba tiene objetivos específicos para el nivel. [28]
• El análisis y diseño de pruebas deben comenzar durante la actividad de desarrollo. [28]
• Las personas que prueban el sistema, deben participar en la revisión de documentos. [28]
Aunque existen diferentes modelos de ciclo de vida, los modelos anteriormente mencionados son
los más indicados para el proceso ya que permite encontrar defectos durante todo el ciclo de vida,
a diferencia de otros modelos como por ejemplo el “Modelo en cascada”, en donde la ejecución
de cada etapa es secuencial por lo tanto depende de la finalización de la anterior, las pruebas se
realizaban al finalizar la etapa de desarrollo, como consecuencia los defectos son detectados
demasiado tarde y el costo de solución aumenta.[27],[28]
4.2.1 Modelo en V
El Modelo en V, permite que el proceso de validación y verificación se realice de manera temprana
desde el inicio del ciclo de vida del software y permite la ejecución de actividades de manera
paralela al desarrollo del sistema.[27]Las características del modelo son:
El proceso de validación y verificación de los requerimientos, las actividades no solo se
basan en la ejecución, la validación se inicia con la revisión de la especificación de los
requerimientos de usuario y finaliza con las pruebas de aceptación de usuario.[27]
Proceso de Validación y Verificación
Se realiza durante todo el ciclo de vida del Software, de manera paralela a las actividades y no cuando estas se finalizan.
Producto de actividad
- Determina si el producto se ajusta a los requerimientos de la actividad.
- Dependiendo la etapa o atividad se: Evalua, se analiza, se revisa, se inspecciona, se realizan pruebas a los productos.
Requerimientos actividad
Se evalua si se cumplieron:
- Los requerimientos de la actividad.
- Los objetivos de la actividad
- Los usos y necesidades
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
19
El lado izquierdo del modelo, representa el proceso que permite el desarrollo del sistema
y el lado derecho, presenta los niveles de pruebas que permiten asegurar la calidad del
sistema. [29]
La planificación y especificación de las pruebas se recomiendan iniciar, cuando los
requerimientos se encuentran avanzados. [29]
El Modelo en V presenta los diferentes niveles de pruebas y especifica el momento en el
que se debe realizar la planificación y su ejecución. [2]
Dentro de las ventajas que presenta este modelo se encuentran:
1. Mayor tiempo para planificar y especificar la prueba. [29]
2. Permite la revisión de documentos y del código del sistema. [29]
3. Mayor tiempo para realizar la configuración del ambiente de pruebas. [29]
4. Mayor oportunidad de estar listos para el momento de ejecución de pruebas. [29]
Las actividades se encuentran definidas de la siguiente manera:
• Inicio modelo: El proceso de validación y verificación, comienza con las fases de “iniciación
del proyecto” y “plan del proyecto”, donde se establecen los puntos de control, se
identifican los productos sobre los cuales llevar a cabo el proceso y se define la estrategia
de pruebas.[27]
• Validación de requerimientos: En esta etapa, se realiza la validación de los requerimientos
especificados con el fin de identificar inconsistencias, ambigüedades, omisiones o errores
en la definición del sistema.
Y se deben llevar a cabo las siguientes verificaciones, presentadas en la Tabla 3:
Verificación de
validez
Identificar si el sistema es suficiente o requiere
funcionalidades adicionales o diferentes. [27]
Verificación de
consistencia
Verificar que los requerimientos no presente
contradicciones, con otros requerimientos o con
funcionalidades del sistema. [27]
Verificación de
completitud
Verificar que se definan todas las funcionalidades y
las restricciones que debe cumplir el sistema. [27]
Verificabilidad
Verificar que los requerimientos se encuentren
definidos de tal manera que permitan su verificación
y la creación de casos de prueba. [27]
Tabla 3. Verificaciones en requerimientos, tomado de [27]
• Ejecución de pruebas: Seguido a la etapa de validación de requerimientos, se continúa con
la ejecución de las pruebas en sus diferentes niveles: pruebas de integración, pruebas de
sistema, pruebas de rendimiento y pruebas de aceptación de usuario. [27]
• Disponibilidad operativa y despliegue: Corresponde a la última etapa que permite
asegurar la calidad del sistema en producción. [27]
• Se presentan actividades intermedias entre la validación de los requerimientos y las
pruebas, corresponden a la planificación y diseño de las pruebas que se realizan de
manera paralela al diseño y al desarrollo.[27],[29]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
20
En la Ilustración 5, se presentan el modelo V, donde se encuentran las actividades de validación y
verificación.
Ilustración 5. Actividades de validación y verificación en el modelo en V, tomado de [27]
4.2.2 Modelo incremental y evolutivo
El Modelo incremental busca construir el sistema, incrementando sus funcionalidades,
“este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo
en el calendario. Cada secuencia lineal produce un incremento del software.”[27]
El sistema es construido a partir de iteraciones, cada nueva iteración se incrementan las
funcionalidades. [28]
Para cada incremento se ejecutan pruebas para verificar la nueva funcionalidad, pruebas
de regresión para garantizar las funcionalidades anteriores y pruebas de integración entre
el incremento anterior y al objeto de incremento. [28]
El sistema es analizado, diseñado, codificado y probado en incrementos bien definidos, tal
como se presenta en la Ilustración 6.[27]
Dentro de las ventajas del modelo se encuentra que:
Una versión ejecutable del sistema, está disponible en etapas tempranas del proceso de
desarrollo.[27]
Al ser incremental, el sistema no necesita que las pruebas del sistema se realicen sin tener
la finalización del desarrollo y se realizaran pruebas.[27]
La validación del sistema se realiza cada vez que se realiza un incremento. [27]
Los supuestos del modelo:
o El cliente no expresa bien lo que quiere. [29]
o Los requerimientos pueden cambiar. [29]
o Se realiza retroalimentación continua. [29]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
21
Ilustración 6. Modelo Incremental, tomado de [27]
4.2.3 Modelo en espiral
En el Modelo espiral, las características del sistema evolucionan a lo largo del tiempo. [27]
Es útil cuando el equipo de proyecto no tiene claridad, ni precisión sobre el sistema a
construir, por lo tanto se desarrollan prototipos que se entregan y permiten identificar las
características deseadas. [18],[27]
Las actividades de pruebas, re-diseño, y la construcción de prototipo son continuas hasta
que el desarrollo del conjunto de características haya finalizado. [27]
En la Ilustración 7, se presenta el Modelo en espiral, donde a partir de un concepto se genera el
diseño, prototipo y las pruebas correspondientes. Una vez que se ejecutan las pruebas, se genera
un rediseño teniendo en cuenta nuevas definiciones o modificaciones, se realiza nuevamente el
diseño y se genera un prototipo para pruebas, por lo tanto, se generan varios prototipos antes de
finalizar el sistema, por cada prototipo se modifica del prototipo anterior hasta que el producto
sea el deseado por el usuario, a este prototipo se le realizan las pruebas en los diferentes niveles
de prueba: Unitarias, de integración, de sistema.[27]
Ilustración 7.Modelo en espiral, tomado de [27]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
22
4.2.4 Modelo de prototipos
El Modelo de prototipos, es útil cuando el cliente, conoce los objetivos generales del
sistema, pero no las entradas, el proceso o las salidas esperadas. [27]
En primer lugar, se realiza el levantamiento de requerimientos, el grupo define los
objetivos generales y los requerimientos conocidos. Luego se realiza el diseño
enfocándose en los aspectos visibles al cliente, para generar un prototipo para la
evaluación del cliente, lo que permite refinar los requerimientos a desarrollar [27], ver
Ilustración 8.
La validación y la verificación, son actividades continuas, que permite al desarrollador,
contar con la opinión del cliente y así poder cubrir sus necesidades, a partir de “revisiones
periódicas para conseguir un producto final que cumpla los requerimientos especificados”.
[27]
Ilustración 8. Modelo de prototipos, tomado de [27]
4.3 Actividades de Validación y Verificación
El proceso de Validación y Verificación de requerimientos, presenta diferentes actividades que se
realizan durante el ciclo de vida del software, presentadas en la Ilustración 9.
Escuchar al cliente
Contruir prototipo
El cliente prueba el prototipo
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
23
Ilustración 9. Actividades de Validación y Verificación, tomado de [26]
• Métodos formales: Requiere la especificación de un modelo en lenguaje formal y el uso
de sus propiedades, para asegurar que las declaraciones del sistema hacen parte del
lenguaje del modelo o se puede producir a partir de él.[30] Permite realizar un “análisis
matemático de la especificación, de transformar la especificación a una representación
más detallada semánticamente equivalente; o de verificar formalmente que una
representación del sistema es semánticamente equivalente a otra representación.”[11]
o Comprobación del modelo o “model cheking”: Este modelo busca validar el
sistema de manera formal, el sistema es expresado “a partir de
firmas1,predicados2, hechos3” y de afirmaciones específicas[30], para realizar un
1Firmas: “Refleja una colección de relaciones (denominados campos) y un conjunto de restricciones para los valores. Una firma puede heredar demonios y limitaciones de otras firmas”.[30] 2 Predicados: “define las limitaciones del comportamiento de captura a través de fórmulas generales”.[30]
Validación y Verificación
Métodos Formales
Comprobación del modelo
Pruebas de corrección o
exactitud
Pruebas
Pruebas Estaticas
Inspecciones
Revisiones
Modelos de Verificación
Análisis Estático
Pruebas Dinámicas
Basado en especificación
Basado en la Estructura
Basado en la experiencia
Análisis V&V
Simulación
EvaluaciónMétricas de
Calidad
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
24
análisis algorítmico y demostrar las propiedades de la ejecución del sistema[31].
La comprobación del modelo, permite resolver problemas de restricciones, para
esto, se realiza dos tipos de análisis: análisis de instancias y generación de
contraejemplos:
- En el análisis de las instancias, dadas las especificaciones del usuario, se
verifica la completitud de las instancias, permite encontrar errores donde
acciones del usuario no se encuentran representadas en alguna instancia
del modelo, por lo tanto ayuda a encontrar errores donde el usuario ha
sobre especificado el sistema o donde falta alguna definición [30].
- Cuando se encuentran errores en el modelo debido a la falta de
información, se genera un contraejemplo a partir de las restricciones del
modelo, donde el alcance, la estructura, el funcionamiento y las
condiciones previas del modelo son aceptables, pero que se contradice
con una o más afirmaciones definidas por el usuario.[30]
o Pruebas de corrección: El sistema se visualiza como un objeto matemático, para
demostrar que el programa es correcto, teniendo en cuenta que los lenguajes de
programación se basan en normas rigurosas de la sintaxis y la semántica.[32]
En la práctica, no es aplicable debido que se requiere el código del sistema, lo que
implica que se realiza la validación en una etapa tardía y las pruebas en sistemas
grandes se complican. [32]
• Pruebas: Actividad que tiene como objetivo evaluar y mejorar la calidad de un producto o
sistema. [10], para mayor información ver sección 5.
o Pruebas estáticas: Corresponde al “proceso de evaluación de un sistema o
componente basado en su forma, estructura, contenido, o documentación.” [33]
Inspecciones: Las inspecciones de software analizan y comprueban las
representaciones del sistema, de manera formal, rigurosa y técnica, para
identificar errores, omisiones y anomalías tan pronto como sea posible.
[11],[32] Se efectúan durante todo el ciclo de vida de desarrollo de
software, el enfoque de las inspecciones es encontrar defectos en los
productos (documentos de requerimientos, de diseño, código, planes de
pruebas, etc.), más no descubrir el por qué surgieron, ni cómo se deben
solucionar. [32], [34]
Las inspecciones se realizan en reuniones donde el grupo de personas
cumplen un rol específico, para encontrar, clasificar, informar y analizar
defectos en el producto. [25], [32]
Dentro de las ventajas de las inspecciones se encuentra que:
- En una única reunión de inspección se puede evidenciar varios
errores del sistema. [11]
- Las inspecciones se pueden realizar en sistemas incompletos. [11]
3 Hechos: “fórmulas que toman sin argumentos e imponen restricciones globales sobre las relaciones y los objetos Predicados: limitaciones de comportamiento de captura a través de fórmulas generales”. [30]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
25
- En las inspecciones se puede evidenciar el nivel de cumplimiento
de los atributos de calidad, como por ejemplo de los estándares,
portabilidad y mantenibilidad del sistema. [11]
Revisiones: Evaluación de un elemento de software para determinar
diferencias entre los resultados planeados y recomendar mejoras. [35] Las
revisiones las realiza un equipo del proyecto durante reuniones dedicadas
a este fin, para evaluar que los elementos del software se encuentren
conforme a su especificación y que el desarrollo de un elemento o
software se realiza de acuerdo a las normas, directrices y planes del
proyecto. [35]
Los conflictos, contradicciones, anomalías, errores u omisiones
encontrados en las revisiones se registran en un informe de revisión, para
negociar la solución. [11]
A partir del proceso de revisión, se puede definir que:
- El documento revisado es conforme a lo esperado, por lo tanto no
es necesario que se realice modificaciones. [36]
- El documento revisado se debe modificar, pero no requiere nueva
revisión. [36]
- El documento revisado se debe modificar considerablemente y
requiere de una nueva revisión. [36]
Modelos de verificación: Los modelos de verificación, buscan expresar el
sistema en un modelo numérico de alta precisión donde se expresa la
descripción conceptual del sistema y su solución. [37]
Por lo tanto, es un modelo predictivo que busca demostrar que el
problema fue resuelto y el resultado esperado ofrece un nivel de
confianza determinado por un “nivel medido de los datos experimentales,
el modelo de predicción y la exactitud predictiva del modelo”.[37]
A partir de la verificación, se identifican y eliminan errores en el modelo
mediante la “comparación de las soluciones numéricas y las soluciones
analíticas de referencia o de alta precisión”. [37] También se realiza la
validación de modelo a partir de “la cuantificación de la exactitud del
modelo mediante la comparación de soluciones numéricas a los datos
experimentales. Por lo tanto, la verificación del modelo se considera sobre
las matemáticas asociadas al modelo, mientras la validación del modelo se
considera con la física asociada al modelo.” [37]
Análisis estático: El análisis estático busca “detectar deficiencias y errores
a través del examen del producto de software, manual o
automáticamente, sin ejecutar el código del software” [38], permite
evaluar un sistema o componente, basado en la forma, el contenido y
estructura de especificaciones, de documentos o de entregables, durante
todo el ciclo de vida del software, facilitando detectar errores que
afectarían a las etapas posteriores. [33], [38]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
26
o Pruebas dinámicas: Pruebas que se realizan en la ejecución del software o
sistema. [21]
Basado en especificación: Pruebas que se realizan a partir del análisis de
la especificación funcional o no funcional del sistema [21], para mayor
información ver sección 6.1.
Basado en la estructura: pruebas que se realizan a partir del análisis de la
estructura interna del sistema [21], para mayor información ver sección
6.2.
Basada en la experiencia: pruebas que se realizan a partir de la
experiencia, conocimiento e intuición del probador [21], para mayor
información ver sección 6.3.
o Análisis V&V: El análisis de validación y verificación, permite obtener la evidencia
objetiva que los requerimientos se han cumplido y permite realizar la evaluación
del producto. [38]
Simulación: La simulación es la representación del comportamiento o de
determinadas características de un sistema físico o abstracto por otro
sistema. [21], [33] La IEEE, define la simulación como un “modelo que se
comporta o funciona como un sistema dado cuando se proporciona un
conjunto de entradas controladas.”[39]
Mediante el uso de los datos analíticos y condiciones definidas, la
simulación permite demostrar el cumplimiento teórico y permite realizar
un análisis dinámico del comportamiento del sistema. [38]
Evaluación: La evaluación permite determinar el valor de un elemento o
de un producto y asegurar que se cumple con las especificaciones [40] Se
realiza durante todo el ciclo de vida del software y a todos los productos
del proyecto, se puede realizar de manera individual a un producto
específico o de manera integral con el sistema. [40]
El objetivo principal es descubrir los errores que se pueden presentar en
los productos, con el fin de garantizar que el sistema puede ser usado para
lo que es previsto, por lo tanto busca asegurar que:
1. El sistema es acorde a la especificación. [40]
2. El sistema es el correcto. [40]
3. El sistema es completo, claro y consistente. [40]
4. “Se consideraron las alternativas apropiadas”. [40]
5. El sistema cumple con todas las normas necesarias. [40]
6. El sistema cumple con todas los atributos de calidad especificados.
[40]
También permite conocer el avance del proyecto en cada etapa del ciclo
de vida, permitiendo realizar recomendaciones para la mejora del
proyecto, como:
1. Corrección de documentos.[40]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
27
2. Devolverse a etapas anteriores para corregir errores o problemas
evidenciados. [40]
3. Realizar evaluaciones adicionales para mejorar el sistema. Por
ejemplo simulaciones. [40]
4. Monitorear el desarrollo del proyectos cuando se presentan
problemas con la calidad.[40]
5. Realizar cambios de metodologías o herramientas[40]
6. Modificar calendarios. [40]
7. Tomar decisiones para modificar personal, capacitar o asignación
de responsabilidades. [40]
Métricas de calidad: Las métricas de calidad, permiten medir el
grado de un atributo de calidad deseado en el sistema[33],[41].
Es un enfoque sistemático que permite establecer los
requerimientos de calidad, identificar, implementar, analizar y
validar los procesos del sistema. [41] Se realiza durante todo el
ciclo de vida del software y permite:
o Definir los criterios de aceptación y requerimientos de
calidad. [41]
o Evidenciar el cumpliendo los requerimientos y objetivos
de calidad. [41]
o Evaluar el nivel de calidad alcanzado.[41]
o Evidenciar cambios en la calidad del sistema cuando este
es modificado. [41]
o Encontrar anomalías o problemas del sistema. [41]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
28
5 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.
5.1 Conceptos
5.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.” [38].
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,
adecuadamente seleccionados a partir del dominio de ejecución generalmente infinito, en
relación con el comportamiento esperado”[10]
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” [42], 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.”[42]
5.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” [43]. 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”[33], “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”[44].
5.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.” [33], o, “Una anomalía producto”[44]. 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
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
29
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.”[21].
En la industria del software, un defecto se produce cuando[45]:
1. El software no hace algo que la especificación dice que debe hacer.[45]
2. El software hace algo que en la especificación del producto dice que no debe hacer.[45]
3. El software hace algo que en la especificación no se menciona.[45]
4. El software no hace algo que la especificación no se menciona pero debería.[45]
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.[45]
5.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”[21], 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.”[44]
En la Ilustración 10, 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.[10]
Ilustración 10.Relación Error, defecto, falla
Error•Acción humana
• Genera un resultado incorrecto
Defecto•Consecuencia del error
•Conocido como Bug en el Software
Falla
•Consecuencia del defecto
•Desviación del componente
•Afecta la producción
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
30
5.2 ¿Cuándo surgen los defectos?
Tal como se mencionó en la sección anterior, los errores son cometidos por acciones humanas, los
cuales pueden presentarse en las diferentes etapas del ciclo de vida del software, por ejemplo en
la definición de los requerimientos, en el diseño o en el desarrollo. Entre más temprana es la etapa
en la que se generó el error, se presentaran mayor cantidad de errores en etapas posteriores,
debido a que las etapas posteriores tienen en cuenta la etapa anterior para su ejecución. [28]
En la Ilustración 11, se presentan cuatro requerimientos, tres de los cuales presentan errores
dentro de las etapas definidas. El requerimiento uno presenta una especificación de
requerimientos correcta, lo que permite que tanto el diseño y la construcción sean acordes, por lo
tanto se obtiene un producto conforme a las necesidades y las definiciones son cumplidas. Los
demás requerimientos, presentan errores en diferentes etapas del proyecto que conllevan a
errores en el producto y por lo tanto el sistema no cumple con lo esperado. [28]
Ilustración 11. Origen defectos, tomado de [28]
5.3 ¿Porque las pruebas son necesarias?
Las pruebas de software son necesarias debido a que:
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
31
• Mide la calidad de un producto, de acuerdo con [26] las pruebas brindan información
sobre las características de calidad del producto.
• Permite conocer si el producto de software realiza lo que se espera que haga [26]
• 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. [27]
• Disminuye los riesgos por incumplimiento de tareas. [27]
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. [26]
5.3.1 Importancia de la calidad y de las pruebas
Aun teniendo un buen proceso de desarrollo de requerimientos, se puede presentar
inconsistencias, que no fueron detectadas en etapas anteriores. Por lo tanto, no solo es necesario
que la validación y verificación de requerimientos se realice de manera estática, si no también
dinámica, cuando se cuente con una versión ejecutable, o, el desarrollo de software se haya
concluido, con el fin de garantizar su funcionalidad y su calidad, de acuerdo al ISTQB “un software
que no funciona correctamente puede dar lugar a muchos problemas, incluyendo perdida de
dinero, tiempo o renombre, daños personales o incluso la muerte.”[2]
Estudios sobre los requerimientos basados en pruebas [46] y [47], manifiestan la necesidad e
importancia del proceso de Validación y Verificación de requerimientos, debido que la causa de los
errores pueden surgir en las diferentes fuentes y sus razones [45], causando de la mala calidad de
los productos[48]. En la Ilustración 12, se presentan los porcentajes sobe la causa raíz de los
defectos de un proyecto.
Ilustración 12. Distribución de los defectos, tomado de [47]
Requerimientos
Diseño
Otros
Codificación
56%
27%
10% 7%
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
32
• Más de la mitad de todos los defectos del proyecto, pueden atribuirse al proceso de
levantamiento de requerimientos.
• La causa raíz de que el 56% de todos los defectos identificados en los proyectos, en la fase de
validación y verificación, es el resultado de errores cuyo origen es la fase de desarrollo de los
requerimientos. De estos errores, la mitad de ellos se debe a que están mal escritos,
ambiguos, no son claros o son incorrectos, la otra mitad se debe a los requerimientos que
fueron omitidos[46],[48]. Un proceso bien definido para la validación estática de
requerimientos, mitigaría en gran parte dicho porcentaje de la etapa de requerimientos.
• Los demás porcentajes de la Ilustración 12, está dada por el diseño, otros factores y la
codificación.
Otras estadísticas [48], señalan que:
• El 82% del re trabajo se relaciona a solicitudes de cambio, por errores en los requerimientos.
[48]
• Los problemas en los requerimientos representan el 44% de las razones detrás de las
cancelaciones de proyectos.[48]
• El 54% de los requerimientos iniciales de un proyecto son implementados.[48]
En la Ilustración 13, se definen los porcentajes del estudio [47], donde se muestra el esfuerzo
requerido para solucionar un defecto presentado en etapas anteriores, entre más temprana sea la
etapa donde surge el defecto, más esfuerzo se requerirá para que este sea solucionado y el costo
será mucho mayor.
Ilustración 13. Esfuerzo para encontrar y corregir defectos, tomado de [47]
En este caso, el esfuerzo y costo, de la corrección de un defecto cuyo origen se remonta en los
requerimientos, es incluso más alto que el 82%, puesto que un error en requerimiento se debe
corregir en cada etapas del ciclo de vida del software, como por ejemplo: en el diseño, el código, y
los casos de prueba, en todos los artefactos donde se encuentren definido o relacionado, por lo
tanto representa un esfuerzo de re-trabajo que puede igualar el esfuerzo inicial del requerimiento.
[47],[49]
La relación del costo por el esfuerzo requerido para dar solución a los defectos encontrados en
una determinada fase del ciclo de vida del software, se presenta en la Tabla 4, por ejemplo si se
Requerimientos
Diseño
Otros
Codificación
82%
4 % 1 %
13%
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
33
detecta un defecto en la fase de Operación del sistema, su corrección presentaría un costo de 40
veces a 1000 veces, de lo que hubiera costado corregirlo en la fase de especificación de
Requerimientos.[46]
Fase donde se encuentra el defecto Porción de costo
Requerimiento 1
Diseño 3-6
Codificación 10
Pruebas de sistema / Integración 15-40
Pruebas de aceptación de usuario 30-70
Operación 40-1000
Tabla 4. Porción costo por fase. Tomado de [47]
En la Ilustración 14, se representa de manera gráfica el costo de la solución de un defecto que
crece con el tiempo.
Ilustración 14. El costo de la corrección, tomado de [45]
Estudio sobre la reducción de defectos del software del año 2001[49], estableció que:
1. Encontrar y corregir un defecto del software después de su liberación, es a menudo 100
veces más caro que encontrar y corregir el defecto durante la etapa de requerimientos y la
fase de diseño. [49] Esta medida puede variar dependiendo de la complejidad del sistema.
Actividades como: el análisis y diseño de requerimientos, involucramiento temprano, la
verificación y validación en todo el ciclo de vida del software, prototipos y simulación
permiten evitar costosas correcciones.
2. Proyectos de software gastan aproximadamente 40 a 50 por ciento de su esfuerzo en re
trabajo evitable.[49]
El esfuerzo dedicado a la corrección de los defectos de software que podrían haber sido
descubiertos, corregidos o evitado por completo en etapas tempranas a un menor costo.
3. Alrededor del 80 por ciento de re trabajo evitable proviene del 20 por ciento de los
defectos.[49]
Dos de las principales fuentes de re trabajo se originan por:
• Requisitos especificados apresuradamente
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
34
• Definición tardía de requisitos no nominales causan el mayor re trabajo en diseño,
arquitectura, y en el código.
4. Alrededor del 80 por ciento de los defectos provienen del 20 por ciento de los módulos, y
aproximadamente la mitad de los módulos son defectos.[49]
Casi todos los defectos se agrupan en la mitad de los módulos. El reconocimiento de las
características de los módulos propensos a errores en un entorno particular puede resultar
útil.
5. Acerca del 90% del tiempo de inactividad viene en su mayoría del 10 por ciento de los
defectos.[49]
Algunos defectos afectan de manera desproporcionada el tiempo de inactividad y la
fiabilidad de un sistema. [49]
6. La revisión de pares capturan el 60 por ciento de los defectos. [49]. Estudios presentan que
la revisión de pares ofrece una técnica efectiva debido que permite encontrar entre el 31 y
el 93 por ciento de los defectos, con una mediana de alrededor de 60 por ciento.[49]
5.3.2 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 5.4.
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], [50]:
• 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
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
35
5.3.3 Objetivos de quien realiza pruebas.
Los objetivos de quien ejecuta las pruebas, de acuerdo a Patton [45] son:
Encontrar defectos, no solo probar por bien, ni crear casos de prueba para que sean
exitosos. [45]
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”[45]
Encontrar errores, encontrarlos lo antes posible, y asegurarse de que se arreglen.[45]
5.4 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]:
• Las pruebas permiten encontrar defectos, pero no demuestran su ausencia [2], lo que
define que:
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.
• Salvo para casos triviales, las pruebas exhaustivas son imposibles debido que se debería
considerar todas las precondiciones, todas las combinaciones 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.[45]
El número de posibles salidas es muy grande.[45]
El número de rutas a través del software es muy grande.[45]
La especificación de software es subjetiva. Se podría decir que un fallo está en el
ojo del que mira. [45]
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:
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 2 - Las pruebas exhaustivas no existen
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
36
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 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠
480.000
60 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠 = 8.000 𝑚𝑖𝑛𝑢𝑡𝑜𝑠
8.000 𝑚𝑖𝑛𝑢𝑡𝑜𝑠
60 𝑚𝑖𝑛𝑢𝑡𝑜𝑠 =
133.33 ℎ𝑜𝑟𝑎𝑠
7.5 ℎ𝑜𝑟𝑎𝑠4 = 17.7 𝑑𝑖𝑎𝑠
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𝑑𝑖𝑎𝑠
5 𝑑𝑖𝑎𝑠5 = 35 𝑠𝑒𝑚𝑎𝑛𝑎𝑠
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 𝑎ñ𝑜𝑠
• Las pruebas tempranas, permiten identificar defectos en fases iniciales del desarrollo,
estas deberían iniciar lo más pronto posible ya que permite reducir costos en la solución
de errores y generar una mayor confianza en el producto. [2]
4 Suponiendo que las horas diarias laborales empleadas para pruebas son 7.5 5 Suponiendo que la semana cuenta con cinco días hábiles que son los empleados para pruebas
Principio 3 - Pruebas tempranas
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
37
• Los defectos generalmente se encuentran agrupados bajo el mismo modulo o
componentes, no distribuidos a lo largo del 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.
• Cuando se efectúan las mismas pruebas una y otra vez, lo más seguro es que no se
encuentren más defectos, estos casos de pruebas pierden la efectividad conforme se
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.
• Las pruebas se deben realizan de manera diferente según el contexto, no es lo mismo
probar un sitio web que un software de seguridad. [2]
• Los objetos de pruebas diferentes, se prueban de manera diferente.
• El proceso de pruebas puede permitir la detección y la corrección de errores, pero esto no
será útil si el sistema no cumple las expectativas y necesidades del usuario. Las pruebas no
miden la satisfacción del usuario final, ni que el software vaya a tener éxito. [2]
5.5 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. [18]
Una buena prueba no es redundante: Cada caso de prueba debe tener su propio objetivo
y propósito. [18]
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.” [18]
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.[18]
Principio 4 - Agrupación de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 5 – Paradoja del pesticida
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 6 – Las pruebas dependen del contexto
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 7 – Falacia de ausencia de errores
Principio 1- Las pruebas demuestran la presencia de defectos
Principio 1- Las pruebas demuestran la presencia de defectos
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
5.6 Niveles de pruebas
Las pruebas se realizan en diferentes niveles durante su desarrollo y mantenimiento, dependiendo de su propósito, uso, comportamiento o
estructura[10]. Por lo tanto el nivel de prueba es un grupo de actividades organizadas y gestionadas de manera conjunta [21], 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. En la sección 5.6.1 se presentan los niveles de pruebas principales[10], en la Tabla 10 de la sección 5.6.2 se presentan
otros tipos de niveles de pruebas que se pueden ejecutar sobre el software.
5.6.1 Niveles principales
Pruebas unitarias o de componente
Descripción: Permite verificar los componentes o módulos del sistema de manera individual. [8], [18]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Localizar defectos[2]
• Comprobar y asegurar el
funcionamiento de los
módulos del software,
programas, objetos,
clases, del sistema objeto
de la prueba.[2]
• Verificar que los flujos de
control y de datos se
encuentren cubiertos, y
que funcionen según lo
esperado. [18]
• Módulo/
componente
desarrollado
• Diseño
detallado[27
]
De acuerdo al ISTQB [2]:
• Requerimientos de
componentes
• Diseño detallado
• Código
• Componentes o
módulos [2], [33]
• Programas [2]
• Conversación de
datos[2]
• Procedimientos
asociados.[33]
• Módulos de bases
de datos. [2]
Roles que intervienen
en la prueba:
• Participa el
desarrollar del sistema.
[2],[27]
Corrección de
defectos:
• Se corrigen defectos
cuando son
detectados, por lo
tanto no necesitan una
gestión formal. [2]
• Modulo Probado
[27]
• Modulo listo
para integrar[27]
Tabla 5. Pruebas unitarias
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
39
Pruebas de integración Descripción: Permite verificar la interacción entre los componentes del software. [10]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Verificar la integración
de los componentes del
sistema.
• Evaluar la interacción
entre los distintos
sistemas o entre el
hardware y el software.
[2]
• Pruebas
unitarias
ejecutadas
[18].
• Producto
integrado
• Plan de
pruebas de
integración.
[27]
De acuerdo al ISTQB [2]:
• Diseño de software y
sistema
• Arquitectura
• Flujos de trabajo
• Casos de uso
• Implementación
de base de datos
de subsistemas [2]
• Infraestructura [2]
• Interfaces [2]
• Configuración del
sistema y datos de
configuración [2]
Quien ejecuta la
prueba:
• Grupo de desarrollo
del sistema,
ingenieros de
software. [18]
• Ingeniero de pruebas
[27]
• Jefe de desarrollo[27]
• Informe de
Pruebas de
Integración.[27]
• Producto listo
para su entrega a
pruebas[27]
Técnicas o estrategias
Integración Big-bang
• Todos los componentes y unidades del sistema se ensamblan resultando un sistema completo[27]
• Ventaja: no es necesario simular ninguna parte del sistema porque todo está integrado listo para iniciar las
pruebas.[27]
• Desventaja: No es fácil encontrar la causa del error debido que no es posible aislar los errores encontrados[27]
Arriba hacia abajo (top-
down)
• Las pruebas inician con los módulos de nivel superior, es decir los módulos con mayor nivel de abstracción, para ir
descendiendo de manera progresiva a los más inferiores y probar así su integración.[27]
• Al no tener el sistema completo integrado, es necesario que se desarrollen programas auxiliares de nivel inferior
que simulen el correcto funcionamiento. [27]
Abajo a arriba (bottom-
up)
• Las pruebas inician con los módulos de nivel inferior, es decir los módulos más especializados, para ir ascendiendo
de manera progresiva a los más superiores.[27]
• 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. [27]
Tabla 6. Pruebas de integración
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
40
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
funcionalidad del
sistema a través de sus
interfaces externas
• Comprobar que la
funcionalidad
corresponda a la
esperada de acuerdo a
los requerimientos. [10]
• Las pruebas del
sistema no se limita a
sistemas. Si el producto
es un programa, las
pruebas del sistema es
el proceso de tratar de
demostrar cómo el
programa, en su
conjunto, no cumple
con sus objetivos.[42]
• Pruebas de
integración
ejecutadas. [27]
• Definición de
un conjunto de
objetivos
medibles para
el producto.[42]
• Plan de pruebas
de sistema[27]
De acuerdo al
ISTQB [2]:
• Especificación de
requerimientos
• Casos de uso
• Especificaciones
funcionales
• Informe de
análisis de
riesgos
• Manuales de
sistema,
usuario y
funcionamiento
[2]
• Configuración
del sistema[2]
• Datos de
configuración.
[2]
Roles que intervienen:
• Equipo de pruebas
independiente[2]
• Ingeniero de pruebas[27]
• Analista funcional[27]
• Jefe de pruebas[27]
Técnicas:
• Basadas en especificación:
técnicas de caja negra [2] y
• Basadas en estructuras:
técnicas de caja blanca [2]
Corrección de defectos:
• Se reportan las
inconsistencias encontradas.
• Se genera nueva versión del
software con la solución del
defecto y es entregado para
pruebas de sistema.
De acuerdo a
INTECO [27]:
• Informe de
Pruebas de
Sistema.
• Manual de
Usuario.
• Manual de
Administración.
• Plan e Informe de
Pruebas
• Sistema probado
Tabla 7. Pruebas de sistema
Pruebas de aceptación
Descripción: Las pruebas que busca determinar si el sistema satisface los criterios de aceptación.[39]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 de
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
41
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”[18]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Determinar si el usuario, cliente, u otra entidad autorizada acepta el sistema o componente objeto de la prueba.[39],[33]
• Validar los requerimientos [18]
• “El objetivo principal de las pruebas de aceptación no es localizar defectos, si no evaluar la buena disposición de un sistema para su despliegue y uso.”[2], demostrando que el software se encuentra listo para el paso a producción. [27]
• Ejecución de pruebas de sistema[27] • Especificación de requerimientos [27] • Manuales de usuario[27] • Plan de pruebas[27]
De acuerdo al ISTQB [2]: • Requerimientos de usuario • Requerimientos de sistema • Casos de uso • Procesos de negocio • Informes de análisis de riesgos
• Procesos de negocio [2] • Procesos operativos y de mantenimiento [2] • Procedimientos de usuario[2] • Formularios [2] • Informes [2]
Quien ejecuta la prueba: • Analistas de
pruebas • Usuario del sistema[2] • Ingeniero de pruebas [27] • Jefe de pruebas [27] • Jefe del proyecto [27]
• Resultados de pruebas [27] • Producto aceptado [27] • Informe de
pruebas de aceptación [27]
Estrategias de pruebas de aceptación
Pruebas Alfa (α)
• El usuario o cliente realiza pruebas del sistema en el entorno de desarrollo [2],[27] • Se trabaja en un entorno controlado y el cliente siempre tiene un experto que le ayuda a usar el sistema.[18],[27] • El desarrollador registra los defectos encontrados y los problemas de uso. [27]
Pruebas Beta (β)
• Se realizan después de las prueba alfa. [27] • Las pruebas se realizan en el entorno del cliente, es decir en un entorno externo a desarrollo [10], [27] • 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. [18],[27]
Tabla 8. Pruebas de aceptación
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
42
Pruebas de regresión Descripción: Ejecución de casos de pruebas anteriormente ejecutados cuando se implementan cambios en el software. [18]
Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas
• Asegurar que los cambios en el sistema
no afecte de manera negativa el software
(comportamientos no esperados o
errores adicionales).[18]
• Permite asegurar los cambios del
sistema.[18]
• Verificar el correcto funcionamiento del
software ante cambios del mismo.[27]
• Demostrar que las pruebas que fueron
exitosas en el software, continúan siendo
exitosas. [10]
• Incorporación de
un cambio en el
sistema, sea por
nuevas
funcionalidades o
mejoras a las ya
existentes
• Solución a
defectos. [27]
• Las pruebas de regresión se pueden realizar en cada uno de los niveles
de pruebas mencionados anteriormente. [10]
• Las pruebas de regresión se realizan en durante todo el ciclo de vida
del sistema y se ejecutan cada vez que se modifica un componente del
sistema [51], en la Ilustración 15 se presenta como las pruebas de
regresión hacen parte de las pruebas de las pruebas unitarias,
integración y pruebas de sistema.
• Por lo tanto los documentos bases, el objeto de prueba, otros aspectos
y salida dependen del nivel de prueba en el que se realiza la prueba de
regresión.
Tabla 9. Pruebas de regresión
Ilustración 15.Pruebas de regresión en, tomado de [51]
PRUEBAS DE REGRESIÓN
Pruebas
unitarias
Pruebas de
integración
Pruebas de
Sistema
Pruebas de
Aceptación
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
5.6.2 Otros niveles de pruebas
Nivel de prueba Descripción Objetivo
Pruebas de
recuperación
Tipo de prueba de sistema que
busca generar fallos.[18] Por
ejemplo, un fallo en la
comunicación en la interacción de
sistemas
• Validar la recuperación del
sistema ante un fallo.[18]
• Validar la reanudación del sistema
ante un fallo.[18]
• Verificar la capacidad del software
para reiniciarse después de un
desastre.[10]
Pruebas de
seguridad
Tipo de prueba de sistema que
permite realizar la validación de la
seguridad del sistema ante
ataques de terceros [18]
• Comprobar que los mecanismos
de protección del sistema brinden
la seguridad esperada. [18]
• Medir el nivel de confidencialidad,
integridad y disponibilidad de los
datos. [52]
• Evaluar en nivel de resistencia del
sistema ante posibles ataques.
[52]
• Identificar vulnerabilidades del
sistema.[52]
Pruebas de
resistencia
Tipo de prueba que busca
confrontar al sistema a situaciones
anormales, de modo que sea
necesario que el sistema “requiera
de mayor cantidad, frecuencia o
volumen de recursos”.[18]
• Medir el límite del sistema, para
conocer hasta dónde puede llegar
antes que falle. [18]
Pruebas de
desempeño
Tipo de prueba diseñada para
verificar el desempeño del
software durante su ejecución [18]
• Medir el desempeño del software
Pruebas de
rendimiento
Evaluar la conformidad de un
sistema o componente respecto a
los requerimientos de rendimiento
especificados [33]
• Verificar que el software cumple
los requerimientos de
rendimiento: como la capacidad y
los tiempos de respuesta. [10]
• Existen dos tipos de pruebas de
rendimiento: Pruebas de carga y
pruebas de stress.
Pruebas de
Carga
Tipo de prueba relacionado con
medida del comportamiento de un
componente o sistema con una
carga creciente[21], por ejemplo:
• Número de usuarios
• Verificar si el sistema soporta el
número de carga especificado.
• Validar la respuesta del sistema
ante las cargas que se realizan.
• Determinar el número de carga
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
44
accediendo de manera
concurrente [21]
• Documentos extremadamente
grandes.
• Número de transacciones que
se pueden procesar de forma
concurrente.[21]
que soporta el sistema. [21]
Pruebas de
Stress
Tipo de prueba de rendimiento,
que busca evaluar un sistema o
componente cuando se
suministran valores que superen
los límites especificados en los
requerimientos [33]. Por ejemplo:
Someter al sistema a:
• Elevado número de entradas
• Elevado número de peticiones.
• Acceso a servidores o a
memoria.[39]
• Evaluar un sistema más allá de los
limites especificados [21]
• Encontrar los límites del sistema y
asegurar que tras un fallo en el
sistema, se recupera sin causar
graves problemas.
Pruebas de
usabilidad
Tipo de prueba que busca evaluar
la forma de interacción de las
aplicaciones con el usuario, miden
que tan fácil, cómodo e intuitivo es
el sistema.[27]
• Evaluar la navegación del sistema
y la información presentada.[27]
• Evaluar la presencia y
organización del sistema. [27]
• Evaluar la flexibilidad del sistema.
[27]
Pruebas de
mantenibilidad
Nivel de prueba que busca medir la
facilidad con la que un producto
software puede ser modificado
para corregir defectos.[21]
• Determinar el grado de
mantenibilidad de un software.
[21]
Pruebas de
fiabilidad
Nivel de prueba que busca medir
la habilidad del software para
“realizar funciones requeridas en
condiciones establecidas para un
período de tiempo específico, o
para un número específico de
operaciones”[21]
• Determinar el nivel de fiabilidad
del sistema.[21]
Pruebas de
Portabilidad
Nivel de prueba que busca medir la
“facilidad con la que el software
puede ser transferido de un
entorno hardware o software a
otro.”[21]
• Determinar el nivel de
portabilidad del sistema.[21]
Tabla 10. Otros niveles de pruebas
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
45
5.7 Tipos de pruebas
Existen 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.
• Una característica de calidad no funcional.
• La estructura o arquitectura del sistema.
• Pruebas asociadas a cambios
5.7.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”[27], funcionalidades
definidas en los diferentes artefactos del sistema, en la Ilustración 16, 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]
Ilustración 16. 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. [10],
[27]
• 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.[33]
• Las técnicas relacionadas a las pruebas funcionales, son las técnicas de caja negra que se
presentaran en la sección 6.
5.7.2 Pruebas no funcionales o de características no funcionales del software
Las pruebas no funcionales se refieren a “Como” funciona el sistema, su objetivo es probar la
calidad de las características de un producto software. Permiten verificar si el sistema cumple con
los requerimientos no funcionales establecidos [27] y verifican los atributos de un componente o
sistema que no se refieren a su funcionalidad [21]. En la Ilustración 17, se presentan los tipos de
pruebas que hacen parte de las pruebas no funcionales. [2]
Pruebas funcionales
Especifición de requerimientos
Casos de usoEspecificación
funcionalFunciones no
documentadas
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
46
Ilustración 17. Pruebas no funcionales
• Las pruebas no funcionales, se pueden realizar durante todos los niveles de pruebas.[2]
• Permiten medir las características del sistema cuantificables, por ejemplo los tiempos de
respuesta en las pruebas de rendimiento. [2]
• Tienen en cuenta el comportamiento externo del sistema, en la mayoría de los casos se
usan técnicas de pruebas de caja negra que se presentaran en la sección 6.
5.7.3 Pruebas de estructura o Arquitectura de software
• Permiten medir la exhaustividad de las pruebas mediante una evaluación de cobertura de
un tipo de estructura. [2]
• Se pueden realizar a lo largo de todos los niveles de pruebas, pero aportan un mayor valor
en las pruebas unitarias o de integración ya que permiten validar que el código del sistema
se encuentra en su totalidad cubierto, por ejemplo los caminos de decisión, las sentencias
y condiciones. [2]
• La técnica de pruebas que apoya el desarrollo de las pruebas de estructura son las pruebas
de caja blanca que se presentaran en la sección 6.
5.7.4 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 9.
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.[18]
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 18, se presenta el ciclo de pruebas y el proceso de depuración.
Pruebas no funcionales
Pruebas de rendimiento
Pruebas de carga
Pruebas de Stress
Pruebas de usabilidad
Pruebas mantenibilidad
Pruebas de fiabilidad
Pruebas de portabilidad
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
47
Ilustración 18. Depuración de defectos, tomado de [18]
5.8 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.
5.8.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. [21], [33],[39]
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. [29]
Un caso de prueba puede cubrir una o varias condiciones de pruebas.
Debe ser repetible, verificable y localizable en los requerimientos.[2]
5.8.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], [29]:
• Preciso: Describe que se va a probar
• Efectivo: Tiene una probabilidad de encontrar defectos. [29]
• Trazable: El caso de prueba se encuentra relacionado a un requerimiento. [2]
• Evolutivo: Fácil de mantener[29]
• Eficiente: El caso de prueba presenta únicamente los pasos que son necesarios, evitando
los pasos innecesarios. [29]
• Estado inicial: Luego de la ejecución del caso de prueba, el ambiente de pruebas retorna a
su estado normal
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
48
Por lo tanto, si un caso de uso bien definido, brindara los siguientes beneficios para el proceso de
pruebas[53]:
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.
5.8.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 19, se presenta los elementos que debe incluirse en la definición de los casos de
prueba, basado en [54]
Ilustración 19.Casos de pruebas, adaptado de [54]
Identificador único
• Identificador del caso de prueba de manera única, permite distinguir el caso de los demás. [54]
Objetivo
• Define el propósito del caso de prueba, el como se debe probar y que se va a probar: Que se va a validar o a verificar. [53],[54]
•Se puede incluir el riesgo o la prioridad [54]
Condición de prueba
•"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 función, transacción, característica, atributo de calidad, o elemento estructural." [21]
Entradas
•Datos de entra o datos de pruebas (test data) que son requeridos para la ejecución del caso. [54]
•Valores de entrada o nombre de archivos o constantes que se utilicen. [54]
Precondiciones•Estado y condiciones previas que el sistema debe cumplir para la ejecución del caso de prueba. [53]
Resultados esperados
•Comportamiento esperado del sistema a partir de las entradas y las condiciones de ejecución.[54]
•Salidas, cambios de estados, valores especificos.[54]
Condiciones Posteriores
•Estado esperado del sistema luego de la ejecución del caso de prueba.[54]
Configuración de ambiente
•Definir las necesidades a nivel de hardware, software, que son requeridas para la ejecución de las pruebas. [54]
Dependencias•Relación de casos de pruebas que deben ser ejecutados antes del caso de prueba, debido a la dependencia [54]
CASO DE PRUEBA
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
49
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],[27] El tercer grupo de técnicas de
pruebas está basada en la experiencia de la persona que realiza las pruebas. En la Ilustración 20,
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
atributos de calidad del software.[27] 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.
Ilustración 20. Técnicas de pruebas, adaptado de [42] , [28], [27]
6.1 Basada en 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[45], las pruebas son
exitosas si el resultado cumple los criterios de aceptación, en caso contrario la prueba revela un
defecto (salida errónea)[55]. Quien ejecuta las pruebas se basa en que hace el software y no en el
Basada en especificación (Caja negra)
Partición de equivalencia
Análisis de valores limites
Tabla de decisión
Grafos de causa- efecto
Transición de estados
Casos de uso
Basada en estructura (Caja
Blanca)
Pruebas de sentencia
Pruebas de decisión
Pruebas de caminos
Basadas en experiencia
Predicción de error
Pruebas Exploratorias
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
50
cómo[27], tiene en cuenta las respuestas del sistema y no la trayectoria interna de cálculos y
procesamiento realizado. [55]
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” [33].
En la Ilustración 21, 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. [45]
Ilustración 21.Técnica de caja negra
En las siguientes subsecciones se presentan las técnicas de pruebas de acuerdo a este enfoque.
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],[29] el resultado de la prueba para una entrada de una
clase es representativo para todas las entradas de la misma clase.[42]
Dividir las entradas o salidas, en grupos equivalentes[51],[29]. En la Ilustración 22 se
presenta ejemplo sobre la partición.
Supuesto: Si un valor da resultado esperado, el resto del grupo harán lo mismo.[42], 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á.[27]
La partición de equivalencia puede aplicarse en todos los niveles de pruebas.[2]
Ilustración 22. Partición de equivalencia, tomado de [29]
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.
5
+
5
=
10
Calculadora
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
51
• Todos los valores numéricos de entrada que se encuentren dentro del rango 0 < 𝑋 < 10
son valores de entrada válidos.
Ilustración 23. Valores de entrada partición de equivalencia
Pressman define cuatro directrices para la definición de particiones equivalentes[18], se define
una clase de equivalencia válida y dos no validas si la condición de entrada:
1. Especifica un rango[18]
2. Requiere un valor especifico[18]
3. Especifica un miembro de un conjunto [18],
Y
4. “Se define una clase de equivalencia y otra no valida, si la condición de entrada es
booleana”[18]
6.1.2 Análisis de valores limites
Esta técnica toma como base la anterior, ver la sección 6.1.1 y se centra en el análisis del valor
frontera de las particiones para identificar su valor límite, [29] de modo que para cada partición,
se define un caso de prueba que cubra el límite superior e inferior.[51]
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.[29] 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.[27] En la Ilustración 24, se presenta un ejemplo sobre este
error.
Ilustración 24. Análisis de valores limites, adaptado de [29]
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],[27] Por lo tanto un valor límite
es el valor en un límite de una partición de equivalencia. [29]
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. [29] 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
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
52
clase, lo que puede estar reduciendo los valores de selección a dos: el valor límite y un
valor dentro del límite.[29]
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. [29]
En el ejemplo anterior para el rango 0 < 𝑋 < 10, se tienen las mismas particiones con las
fronteras: 0 y 10.
Ilustración 25. 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.
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. [51]
Las tablas de decisión permite registrar todas las condiciones de entrada posibles junto
con todas las acciones resultantes del sistema. [27], [29]
Facilita la definición de las decisiones lógicas del sistema, debido que las tablas
representan relaciones lógicas entre las condiciones. [10], [27]
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],[27]
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. [29]
Las combinaciones posibles de la tabla de decisión se deriva de los requerimientos,[29] se
debe analizar la especificación para identificar las condiciones y acciones del sistema.[2]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
53
Las filas de la tabla de decisión especifican las condiciones de entrada o acciones que son
realizadas en el sistema. [56]
Las columnas de la tabla de decisión, representan los casos de prueba, especifican las
acciones que pueden ocurrir.[2],[56] 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
Salida N No Si N/A
Tabla 11. Tablas de decisión
En la Tabla 12 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 colegio?
No No No No Si
Salidas/Respuestas
Cotiza pensión. No No No Si N/A
Recibe ingresos por pensión.
Si Si N/A N/A N/A
Recibe sueldo por trabajo.
Si No N/A Si N/A
Depende económicamente
de los padres. N/A N/A N/A N/A Si
Tabla 12. 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.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
54
• 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.
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.” [29]
El grafico es el resultado del análisis de los requerimientos[29]
Los casos de prueba se generan a partir del diagrama. [42], [29]
Es útil para los casos donde las funciones dependen de más de una entrada[29]
Las entradas y las salidas tienen que ser las declaraciones que son verdaderas o falsas.[29]
“El contenido semántico de la especificación se analiza y se transforma en un grafo de
Boole con las causas y los efectos”[42],[29], ver la Ilustración 26
𝑓(𝐸𝑠𝑡𝑎𝑑𝑜 𝑎𝑐𝑡𝑢𝑎𝑙, 𝑒𝑛𝑡𝑟𝑎𝑑𝑎) → (𝑁𝑢𝑒𝑣𝑜 𝑒𝑠𝑡𝑎𝑑𝑜, 𝑠𝑎𝑙𝑖𝑑𝑎)
𝑓(𝐸𝐴1, 𝐸𝐴2. . 𝐸𝐴𝑛, 𝐸𝐴𝑛+1, 𝐸1, 𝐸2. . 𝐸𝑛, 𝐸𝑛+1) → (𝑁𝐸1, 𝑁𝐸2. . 𝑁𝐸𝑛, 𝑁𝐸𝑛+1, 𝑆1, 𝑆2. . 𝑆𝑛, 𝑆𝑛+1)
Ilustración 26.Función grafo de causa – efecto, tomado de [29]
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.[42]
2. Identificar las causas y los efectos del requerimiento. A cada una de las causas y efecto se
le debe asignar un identificador único. [42],[29]
3. Para cada efecto generar una expresión booleana que exprese las causas. [29]
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. [29]
b. Si se presenta el operador booleano ∨ (o), significa que al menos una causa debe
ser verdadera para que el efecto sea verdadero. [29]
c. Si se presenta un ∼ , representa la negación, lo verdadero debe entenderse
como falso, y viceversa. [29]
d. Si se presenta un arco∡, significa que todas las causas se deben combinar con el
operador. [29]
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.[42]
6. Es posible transformar el grafo a una tabla de decisión, ver sección 6.1.3, donde las
columnas de la tabla representan un caso de prueba. [42]
En la Ilustración 27, se presenta una representación de los grafos de causa – efecto.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
55
Ilustración 27. Diagramas posibles de causa – efecto, tomado de [42]
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 28.
Ilustración 28. 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],[27]
La transición de estados inicia cuando se presenta un evento, el evento desencadena una
acción y el sistema cambia de estado. [29], [57]
o Transición: Estado inicial+ Evento + Acción + Estado final [29]
Útil cuando el sistema presenta diferentes salidas bajo la misma entrada.[27]
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”[29]
Los casos de pruebas deben corresponder a cada uno de sus estados y transiciones. [10]
En la Ilustración 29, 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.
Estado
inicial Estado
Final Transición
Descripción del
evento
E1 S1
Si E1 entonces S1
E1 S1
Si no E1 entonces S1
E1 S1
Si E1 y E2 entonces S1
E2
E1
S1
Si E1 o E2 o E3 entonces S1
E2
E3
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
56
Ilustración 29. Transición de estados, adaptado de [28]
Una transición de la Ilustración 29, es por ejemplo:
Transición: Inicio +Inserta tarjeta + Mensaje del sistema “Por favor ingrese su clave” + Espera 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 13 se representan el ejemplo de la
Ilustración 29.
Eventos Estado inicial
Inserta Tarjeta
Ingreso clave
Clave correcta
Clave 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 13. 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
14 se representa el ejemplo de la Ilustración 29.
Inicio
Inserta
tarjeta Espera
Clave Ingreso
clave
Primer
Intento
Segundo Intento
Tercer Intento
Acceso a
la cuenta
Clave
Correcta
Clave
Correcta
Clave
Correcta
Bloquear
tarjeta
T1
T2
T3
T4
T5
T6
T7
T8
T1 = Inicio + Inserta tarjeta + Mensaje del sistema “Por favor ingrese su clave” + Espera clave
Estado inicial Evento Acción (no re presentada en la ilustración) Estado final
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
57
Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 Caso 7 Caso 8
Transición
T1 T2 T3 T4 T5 T6 T7 T8
Estado inicial
S1 S2 S3 S3 S4 S4 S5 S5
Evento Inserta tarjeta
Ingreso de clave
Clave incorrecta
Clave correcta
Clave correcta
Clave incorrecta
Clave correcta
Clave incorrecta
Acción Solicita clave
Recibe clave
Solicita clave
Mensaje clave
correcta
Mensaje clave
correcta
Solicita clave
Mensaje clave
correcta
Mensaje clave
incorrecta
Estado final
S2 S3 S4 S6 S6 S5 S6 S7
Tabla 14. Transición de estados por transición, adaptado de [29]
Los casos de pruebas deben identificar: el estado inicial, las entradas del sistema o eventos, los
resultados esperados (acciones) y el estado final esperado. [57]
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],[27]. “Un sistema se
describe por la suma de sus casos de uso”.[56] 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], [27] Describe las interacciones de los usuarios con el sistema de manera
secuencial. [28] ,[27]
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.[56]
Permite asegurar el cumplimento de los requerimientos del sistema y las expectativas del
usuario.[56] Por lo tanto son una base para las pruebas de aceptación.[29]
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 . [29]
En la Tabla 15, se presenta la descripción del caso de uso de acceso a la cuenta del ejemplo de
la Ilustración 29.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
58
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
Precondiciones Usuario con tarjeta activa Cuenta sin bloqueo
Descripción
Flujo normal
No paso
Actor No
paso Sistema
1 Inserta la tarjeta 2 Valida tarjeta y solicita clave
3 Ingresa la clave 4 Valida clave
5 Permite el acceso a la cuenta
Excepciones
2a Tarjeta no valida: el sistema presenta mensaje y rechaza la tarjeta
4a Clave no valida: el sistema presenta mensaje y permite realizar reintento de clave
4b Clave invalida 3 veces: el sistema bloquea la tarjeta y no permite el acceso.
Post condiciones
Actor accede a su cuenta
Tabla 15. Descripción caso de uso, adaptado de [28],[29]
6.2 Basada en estructura (Caja Blanca)
Las técnicas de pruebas basadas en la estructura, como su nombre lo indica, necesitan conocer la
estructura interna de los componentes del sistema, su implementación y la lógica de las funciones
que lleva a cabo, para cubrir los caminos del programa.[42],[56],[58] Por lo tanto el contenido
interno de la aplicación es conocido [39], ver Ilustración 30.
Los casos de prueba se basan en la implementación del sistema, permitiendo que:
Se valide que se recorre al menos una vez los caminos independientes de cada
módulo.[59],[60]
Se valide todas las decisiones lógicas tanto verdaderas como falsas. [59],[60]
Se valide todos los bucles del sistema dentro y sobre sus límites operacionales.[59],[60]
Se validen las estructuras internas de datos, para asegurar su integridad.[59],[60]
Ilustración 30. Técnica de caja blanca
Las pruebas de caja blanca son útiles cuando se realizan pruebas en los siguientes niveles:
• Pruebas de Componentes: Permite validar la estructura de “las sentencias, las decisiones,
las ramas o caminos que se presentan en el componente”. [2]
• Pruebas de integración: Permite validar la estructura por ejemplo de “árbol de llamadas
(un diagrama en el que los módulos llaman a otros módulos)”[2]
• Pruebas de sistema: Permite validar la estructura de los “menús, procesos de negocio o
una estructura de una página web”.[2]
Calculadora
10
5
+
5
=
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
A continuación en la Tabla 16, se presentas las técnicas de caja blanca: Pruebas de sentencia, pruebas de decisión y pruebas de caminos. La
idoneidad de las pruebas se mide a partir del porcentaje de cobertura, cuando se realizan pruebas bajo todas las condiciones al menos una
vez, se dice que cumple 100% la cobertura. [10]
Técnica de prueba
Objetivo Casos de prueba Descripción de Cobertura
Pruebas de
sentencia
Validar las sentencias del código
en el sistema.[27]
• Los casos de prueba deben diseñarse para ejecutar las sentencias del sistema, por lo tanto deben dirigirse a sentencias específicas, para aumentar la cobertura del sistema. [2],[28],[29]
• Una sentencia del sistema se ejecuta en su totalidad o no en absoluto.[29]
• La cobertura de la sentencia permite evaluar el porcentaje de sentencias ejecutadas del sistema en los casos de pruebas.[2], [28]
𝐶𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎 =𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑡𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑏𝑙𝑒𝑠× 100%
• Aunque el porcentaje de la cobertura de las sentencias es igual al 100%, no asegura que el sistema este correcto, debido que no es posible asegurar que cada decisión del sistema ha sido ejecutado, por ejemplo si el sistema cuenta con sentencias de condición, únicamente se prueba un camino. [56]
• Si el porcentaje de la cobertura es menor que el 100% significa que existe código que no ha sido ejecutado. [56]
Pruebas de
decisión
Validar y asegurar las decisiones
del sistema[27]
(if, do-while,
repeat-until, case)
• Los casos de prueba busca ejecutar los resultados de las decisiones. [2]
• Para definir los casos de prueba, de acuerdo a [29], se debe:
o Dividir el código del sistema en bloques básicos.
o Identificar las decisiones que se presentan en cada bloque, las ramas y sus resultados.
o Diseñar casos de pruebas que cubran los resultados de las decisiones, tanto falsas como verdaderas.
• La cobertura de decisión, permite evaluar el porcentaje de los resultados de decisión, que han sido ejecutados. [2], [28]
𝐶𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛 =𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛 𝑐𝑢𝑏𝑖𝑒𝑟𝑡𝑜𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑝𝑜𝑠𝑖𝑏𝑙𝑒𝑠 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛× 100%
• El 100% de cobertura de decisión, garantiza el 100% de cobertura de sentencia, pero no viceversa. [2], [28]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
60
Pruebas de camino
o ruta básica
Validar los caminos de ejecución
de manera independie
nte en el grafo del
componente de
prueba.[27], [61]
Esta técnica definida por McCabe, se basa en “derivar una medida de complejidad lógica a partir de un diseño procedimental, y usar esta medida como guía para definir un conjunto base de rutas de ejecución”[18]. Para la generación de casos de pruebas es necesario: 1. Convertir el código del sistema en una gráfica de flujo.[18], [62] 2. Calcular la complejidad ciclomática 𝑉(𝐺) del grafo generado. [18] El valor de 𝑉(𝐺) define: El número de rutas que son independientes del programa. [18] El límite superior del número de
pruebas a diseñar. [18] Cuando el valor es mayor a 10, la probabilidad de presentarse defectos es mayor
3. Determinar el conjunto básico de caminos linealmente independientes. [18] 4. Diseñar los casos de pruebas del conjunto de caminos. [18]
Calculo de la complejidad ciclomática [18]: (1). 𝑉(𝐺) = 𝐸 − 𝑁 + 2
Donde E: Número de aristas y N el número de nodos. O, (2). 𝑉(𝐺) = 𝑃 + 1 Donde P: Número de nodos predicados6 del grafo.
Grafica de flujo de acuerdo a instrucciones [18],[63]
Secuencia
Condicional
Mientras
Hasta
Según sea
Tabla 16. Técnicas de pruebas de caja blanca
6 El nodo predicado: corresponde a un nodo que presenta una condición del sistema, donde aparecen uno o más operadores lógicos, creando nodos descendientes por cada condición. [18],
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
6.3 Basadas en 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], [27]
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.
6.3.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], [56]. Así como también, en el
historial de problemas presentados en versiones anteriores o sistemas similares. [56] 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.[56]
“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.”[56]
6.3.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]
Ú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]
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
62
Las pruebas exploratorias se realiza de manera simultánea: el aprendizaje, el diseño de la
prueba y la ejecución de pruebas. [29], 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. [29]
En la Ilustración 31, se presenta la información sobre lo que permiten conocer las pruebas
exploratorias.[28]
Ilustración 31. Pruebas exploratorias
ExplorarEncontrar
•Información del sistema (para incluir y mejorar pruebas) [44]
•Defectos del sistema.
Identificar en el sistema
•Que funciona.
•Que no funciona.
•El uso.
•Fortalezas.
•Debilidades.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
63
7 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», 26-may-2014. [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. N. de T. de la C. INTECO, «Guía avanzada sobre la gestión de requisitos», dic-2008. [En línea]. Disponible en: http://www.inteco.es/qualite_TIC/descargas/guias/?realLang=fr. [Accedido: 24-sep-2014].
[8] B. Bruegge y Allen H. Dutoit, Ingeniería de Software orientado a objetos, Primera Edición., vol. 1. México: Prentice Hall, 2002.
[9] R. R. Young, The Requirements Engineering Handbook. Singapore: Artech House Print on Demand, 2003.
[10] IEEE Computer Society, «Guie to the Software Engineering body of Knowledge - SWEBOK Guide V3.0». 2013.
[11] I. Sommerville, Ingenieria del Software. Madrid: Pearson Educacion, 2005. [12] A. Moreno Peña, «Análisis de requisitos software», 01-dic-2007. [En línea]. Disponible en:
http://bloqnum.com/pfc/proyecto/node11.html. [Accedido: 30-sep-2014]. [13] K. E. Wiegers, «Writing Quality Requirements», Software Development, may-1999. [14] V. C. Loaiza Carvajal y L. C. Zorro Jiménez, «Easy Requirement Management Tool - Marco
teorico», Pontificia Universidad Javeriana, Bogotá, 2011. [15] M. Arias Chaves, «La ingeniería de requerimientos y su importancia en el desarrollo de
proyectos de software», vol. VI, n.o 10, 07-jul-2006. [16] E. Hull, K. Jackson, y J. Dick, Requirements Engineering, Edición: 3. London ; New York:
Springer, 2010. [17] A. D. Carleton, R. E. Park, W. B. Goethert, W. A. Florac, E. K. Bailey, y S. L. Pfleeger, «Software
Measurement for DoD Systems: Recommendations for Initial Core Measures», Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical report CMU/SEI-92-TR-19, 1991.
[18] R. S. Pressman, Ingenieria del Software - Un Enfoque Practico, 6.a ed. Madrid: McGraw-Hill Companies, 2002.
[19] B. Berenbach, D. Paulish, J. Kazmeier, y A. Rudorfer, Software & Systems Requirements Engineering: In Practice, 1 edition. New York: McGraw-Hill Osborne Media, 2009.
[20] A. M. Davis, E. Yourdon, y A. S. Zweig, «Requirements Management Made Easy», 2000. [En línea]. Disponible en: http://homepages.laas.fr/kader/Davis_et_al.pdf. [Accedido: 26-sep-2014].
[21] ISTQB, International Software Testing Qualifications Board, «Glossary Archive - ISTQB® Glossary of Testing Terms». Erik van Veenendaal (The Netherlands), 19-oct-2012.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
64
[22] B. W. Boehm, «GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE REQUIREMENTS AND DESIGN SPECIFICATIONS».
[23] I. S. 12207-2008 ISO/IEC 12207, «Systems and software engineering — Software life cycle processes». 01-feb-2008.
[24] 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.
[25] IEEE Computer Society, «1012-2012 - IEEE Standard for System and Software Verification and Validation». may-2012.
[26] «Software and systems engineering Software testing Part 1: Concepts and definitions», sep. 2013.
[27] 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].
[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. M. J. Hass, Guide to Advanced Software Testing. Boston: Artech House, 2008. [30] R. Gore y S. Diallo, «The need for usable formal methods in verification and validation», en
Simulation Conference (WSC), 2013 Winter, 2013, pp. 1257-1268. [31] R. Jhala y R. Majumdar, «Software Model Checking», ACM Comput Surv, vol. 41, n.o 4, pp.
21:1–21:54, oct. 2009. [32] S. R. Rakitin, Software Verification and Validation: A Practitioner’s Guide. Boston: Artech
House Publishers, 1997. [33] IEEE Computer Society, «Systems and software engineering – Vocabulary», ISOIECIEEE
247652010E, pp. 1-418, dic. 2010. [34] A. Martín, A. Otazú, M. I. Lund, M. del C. Lopez, y S. Zapata, «Inspecciones de software: una
herramienta de mejora de la calidad de software», 1999. [En línea]. Disponible en: http://www.unsj-cuim.edu.ar/portalzonda/Congreso/papers/1999/CON9.PDF. [Accedido: 31-oct-2014].
[35] «IEEE Standard for Software Reviews and Audits», IEEE Std 1028-1988, p. 0_1-, 1989. [36] ISTQB, International Software Testing Qualifications Board, «Certified Tester - Advanced Level
Syllabus Test Manager». 19-oct-2012. [37] B. H. Thacker, S. W. Doebling, F. M. Hemez, M. C. Anderson, J. E. Pepin, y E. A. Rodriguez,
«Concepts of Model Verification and Validation», Los Alamos National Laboratory, oct-2004. [38] IEEE Std 1059- 1993, «IEEE Guide for Software Verification and Validation Plans». 02-dic-1994. [39] «IEEE Standard Glossary of Software Engineering Terminology», IEEE Std 61012-1990, pp. 1-
84, dic. 1990. [40] «IEEE Guide for Software Verification and Validation Plans», IEEE Std 1059-1993, pp. i-87,
1994. [41] «IEEE Standard for a Software Quality Metrics Methodology», IEEE Std 1061 TM -1998, 1998. [42] G. J. Myers, C. Sandler, y T. Badgett, The Art of Software Testing, Edición: 3. Auflage. Hoboken,
N.J: Wiley John + Sons, 2011. [43] Real Academia Española, «Diccionario de la lengua española», 2014. [En línea]. Disponible en:
http://www.rae.es/. [Accedido: 01-oct-2014]. [44] «IEEE Standard Dictionary of Measures to Produce Reliable Software», IEEE Std 9821-1988, pp.
1-54, 1989. [45] R. Patton, Software Testing, 2 edition. Indianapolis, IN: Sams Publishing, 2005.
Pontificia Universidad Javeriana Marco teórico – Trabajo de grado
65
[46] P. Skokovi y M. R. Skokovi, «Requirements Based Testing Process Overview (Originally presented as “Getting it right the first time”)», International Journal of Industrial Engineering and Managem ent (IJIEM), vol. 1, n.o 4, pp. 155 - 161, 2010.
[47] Bender RBT Inc, «Requirements Based Testing Process Overview». Bender RBT Inc, 2009. [48] T. O. A. C. Borland, «Eliminate the testing bottleneck - Maximize software quality with
Requirements Based Testing». ago-2006. [49] B. Boehm y V. R. Basili, «Software Defect Top 10 List», Software Manangement, ene-2001.
[En línea]. Disponible en: http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf. [Accedido: 29-sep-2014].
[50] 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.
[51] K. Naik y P. Tripathy, Software Testing and Quality Assurance: Theory and Practice, 1 edition. Hoboken, N.J: Wiley-Spektrum, 2008.
[52] V&V Quality, «Pruebas de seguridad», V&V Quality Performance, security & Process Solutions, 2013. [En línea]. Disponible en: http://www.vyvquality.com/w1/index.php?option=com_content&view=article&id=79&Itemid=151. [Accedido: 03-oct-2014].
[53] 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].
[54] IEEE Computer Society, «IEEE Standard for Software and System Test Documentation», IEEE Std 829-2008, jul. 2008.
[55] D. Galin, Software Quality Assurance: From Theory to Implementation, 1 edition. Harlow, England ; New York: Addison-Wesley, 2003.
[56] W. E. Perry, Effective Methods for Software Testing: Includes Complete Guidelines, Checklists, and Templates, 3 edition. Indianapolis, IN: Wiley, 2006.
[57] J. Watkins, Testing IT : An Off-the-Shelf Software Testing Handbook. Port Chester, NY, USA: Cambridge University Press, 2001.
[58] M. L. Hutcheson, Software Testing Fundamentals: Methods and Metrics, 1 edition. Indianapolis, Ind: Wiley, 2003.
[59] A. Cálad Álvarez y J. D. Ruíz Calle, «Metodologías de testing de software y su aplicación en el centro de informática de la universidad EAFIT», Universidad EAFIT, Medellin, 2009.
[60] R. Ruiz Tenorio, «Las Pruebas de Software y su importancia en las organizaciones», Monografía, Universidad Veraruzana, Veracruz, 2010.
[61] M. Polo Usaola, «Curso de doctorado sobre Proceso software y gestión del conocimiento - Pruebas de software». 2006.
[62] J. M. Fernández Peña, «Capítulo 3 caminos básicos», 23-nov-2006. [En línea]. Disponible en: http://www.uv.mx/personal/jfernandez/files/2010/07/Cap3-Caminos.pdf. [Accedido: 16-oct-2014].
[63] A. H. Watson y T. J. McCabe, «Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric ». 1996.