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


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


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


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


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


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.


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


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].


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


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


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]


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]


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].

.


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


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.


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.


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.


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


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]


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]


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]


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


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


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]


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]


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]


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]


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


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


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:


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%


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%


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


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


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 2 - Las pruebas exhaustivas no existen




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




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 5 – Paradoja del pesticida



Principio 6 – Las pruebas dependen del contexto



Principio 7 – Falacia de ausencia de errores




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


39

Pruebas de integración Descripción: Permite verificar la interacción entre los componentes del software. [10]


• 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


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


• 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


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]


• 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


42

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


• 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


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


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


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


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


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


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


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


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


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


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]


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.


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.


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


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


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.


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

=


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]


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],


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]


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.


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.


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.


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.

marco teórico - trabajos de grado de la facultad de...

Documents