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

CIS1430IS08V2SOFT: 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 JAVERIANAFACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

2015

1


Contenido1 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

2


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

3


Índice de ilustraciones Ilustración 1. Secciones documento Marco teórico...........................................................................6Ilustración 2. Actividades Empresa.....................................................................................................7Ilustración 3. Ingeniería de requerimientos[14]...............................................................................14Ilustración 4.Proceso de validación y verificación en ciclo de vida, adaptado de [25].....................18Ilustración 5. Actividades de validación y verificación en el modelo en V, tomado de [27].............20Ilustración 6. Modelo Incremental, tomado de [27]........................................................................21Ilustración 7.Modelo en espiral, tomado de [27].............................................................................21Ilustración 8. Modelo de prototipos, tomado de [27]......................................................................22Ilustración 9. Actividades de Validación y Verificación, tomado de [26]..........................................23Ilustración 10.Relación Error, defecto, falla.....................................................................................29Ilustración 11. Origen defectos, tomado de [28]..............................................................................30Ilustración 12. Distribución de los defectos, tomado de [47]...........................................................31Ilustración 13. Esfuerzo para encontrar y corregir defectos, tomado de [47]..................................32Ilustración 14. El costo de la corrección, tomado de [45]................................................................33Ilustración 15.Pruebas de regresión en, tomado de [51]................................................................42Ilustración 16. Pruebas funcionales..................................................................................................45Ilustración 17. Pruebas no funcionales.............................................................................................46Ilustración 18. Depuración de defectos, tomado de [18].................................................................46Ilustración 19.Casos de pruebas, adaptado de [54].........................................................................48Ilustración 20. Técnicas de pruebas, adaptado de [42] , [28], [27]...................................................49Ilustración 21.Técnica de caja negra................................................................................................50Ilustración 22. Partición de equivalencia, tomado de [29]...............................................................50Ilustración 23. Valores de entrada partición de equivalencia..........................................................51Ilustración 24. Análisis de valores limites, adaptado de [29]............................................................51Ilustración 25. Análisis valor frontera...............................................................................................52Ilustración 26.Función grafo de causa – efecto, tomado de [29].....................................................54Ilustración 27. Diagramas posibles de causa – efecto, tomado de [42]............................................55Ilustración 28. Transición de estados...............................................................................................55Ilustración 29. Transición de estados, adaptado de [28]..................................................................56Ilustración 30. Técnica de caja blanca..............................................................................................58Ilustración 31. Pruebas exploratorias...............................................................................................62

4


Índice de Tablas Tabla 1. Desventajas Outsourcing......................................................................................................9Tabla 2. Tipos de Requerimientos y nivel de granularidad...............................................................11Tabla 3. Verificaciones en requerimientos, tomado de [27]............................................................19Tabla 4. Porción costo por fase. Tomado de [47].............................................................................33Tabla 5. Pruebas unitarias................................................................................................................38Tabla 6. Pruebas de integración.......................................................................................................39Tabla 7. Pruebas de sistema.............................................................................................................40Tabla 8. Pruebas de aceptación........................................................................................................41Tabla 9. Pruebas de regresión..........................................................................................................42Tabla 10. Otros niveles de pruebas..................................................................................................44Tabla 11. Tablas de decisión.............................................................................................................53Tabla 12. Ejemplo tabla de decisión.................................................................................................53Tabla 13. Transición de estados por eventos, adaptado de [28]......................................................56Tabla 14. Transición de estados por transición, adaptado de [29]...................................................57Tabla 15. Descripción caso de uso, adaptado de [28],[29]...............................................................58Tabla 16. Técnicas de pruebas de caja blanca..................................................................................60

5


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

6

Sección 1

Presenta el modelo de empresa a la que va dirigida la guía metodológica y la contextualizació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 y verificació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, se presentan los objetivos del proceso, los modelos de ciclo de vida y las actividades de validación y verificación.

Sección 5

Se centra en las pruebas de software, es de las secciones más importantes, debido que en el contexto de la guía la validación y verificación de requerimientos para usuario final se realiza por medio de las pruebas de software.Se presenta información sobre las definiciones que son necesarias para el proceso, como surgen los defectos, el porque las pruebas son necesarias, los principios de las pruebas, las caracterí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 y tener 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.


1.1 Tercerización del desarrolloPor 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.

7

Define y especifica

Requerimientos

Terceriza desarrollo

Recibe desarrollo

Valida y Verifica Requerimientos

Certifica producto

Instalación del producto en producción


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

8


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

9


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 softwareRequerimientos 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

10


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

11


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]

12


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

.

13


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

14

Ingeniería de Requerimientos

Desarrollo de Requerimientos

Levantamiento o Recolección Análisis

EspecificaciónVerificación y

Validación

Administración de

Requerimientos

Captura

Trazar

Monitoreo y Reporte

Administración del cambio


[18], se define de manera detallada las funcionalidades, el comportamiento, las capacidades y restricciones del sistema que se va a construir. [14], [20]

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.

15


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 implementada2. Criterios de Verificación y Validación son necesarios y requeridos son identificados3. 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.

16


4.1 Objetivo de la Validación y VerificaciónEl 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.

17


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]

18

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


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]

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

19


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]

20


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]

21


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.

22

Escuchar al cliente

Contruir prototipo

El cliente prueba el prototipo


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

23

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ón Métricas de Calidad


firmas1,predicados2, hechos3” y de afirmaciones específicas[30], para realizar un 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:

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

24


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

25


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]

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]

26


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

27


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 PruebasLas 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 ErrorEntre 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 DefectoLa 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

28


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 FallaEl 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

29

ErrorAcción humana Genera un resultado incorrecto

DefectoConsecuencia del errorConocido como Bug en el Software

FallaConsecuencia del defecto Desviación del componenteAfecta la producción


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:

30


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

RequerimientosDiseñoOtrosCodificación

56%

Ilustración 12. Distribución de los defectos, tomado de [47]

31

27%

10%7%


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

RequerimientosDiseñoOtrosCodificación

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

32

82%

4 % 1 %13%


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 costoRequerimiento 1Diseño 3-6Codificación 10Pruebas de sistema / Integración 15-40Pruebas de aceptación de usuario 30-70Operació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

33


• 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

34


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 defectos3. 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:

35

Principio 1- Las pruebas demuestran la presencia de defectos

Principio 2 - Las pruebas exhaustivas no existen


1. Sistema con 20 pantallas 2. Cada pantalla presenta 4 menús 3. Cada menú presenta 3 opciones4. Cada pantalla tiene por lo menos 10 campos5. Cada campo recibe 2 tipos de datos de entrada6. Existen 100 posibles valores

Por lo tanto se tiene que:

Son necesarias 20×4×3×10×2×100=480.000 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 prueba×1Segundo=480.000 segundos

480.00060

segundos=8.000minutos

8.000minutos60minutos

=133.33horas7.5horas

=17.7dias

Si el tiempo de ejecución de las pruebas es de diez segundos, se requieren 35 semanas para ejecutar las pruebas:

10 segundos=177.7 dias

177.7dias5dias

=35 semanas

Si el tiempo de ejecución de las pruebas es de 1 minuto, se requieren 4 años para ejecutar las pruebas:

1minuto=4 años Si el tiempo de ejecución de las pruebas es de 10 minutos, se requieren 40 años

para ejecutar las pruebas :

10minutos=40años

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

36

Principio 3 - Pruebas tempranas

Principio 4 - Agrupación de defectos


• 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 pruebasAtributos 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]

37

Principio 5 – Paradoja del pesticida

Principio 6 – Las pruebas dependen del contexto

Principio 7 – Falacia de ausencia de errores


5.6 Niveles de pruebasLas 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 componenteDescripció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


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

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas

• Verificar la integración de los componentes del sistema.• Evaluar la interacción entre los distintos sistemas o entre el hardware y el software. [2]

• Pruebas unitarias ejecutadas [18].• Producto integrado• Plan de pruebas de integración. [27]

De acuerdo al ISTQB [2]:• Diseño de software y

sistema• Arquitectura• Flujos de trabajo• Casos de uso

• Implementación de base de datos de subsistemas [2]

• Infraestructura [2]• Interfaces [2]• Configuración del

sistema y datos de configuración [2]

Quien ejecuta la prueba:• Grupo de desarrollo

del sistema, ingenieros de software. [18]

• Ingeniero de pruebas [27]

• Jefe de desarrollo[27]

• Informe de Pruebas de Integración.[27]

• Producto listo para su entrega a pruebas[27]

Técnicas o estrategias

Integración Big-bang

• Todos los componentes y unidades del sistema se ensamblan resultando un sistema completo[27]• Ventaja: no es necesario simular ninguna parte del sistema porque todo está integrado listo para iniciar las pruebas.[27]• Desventaja: No es fácil encontrar la causa del error debido que no es posible aislar los errores encontrados[27]

Arriba hacia abajo (top-down)

• Las pruebas inician con los módulos de nivel superior, es decir los módulos con mayor nivel de abstracción, para ir descendiendo de manera progresiva a los más inferiores y probar así su integración.[27]• Al no tener el sistema completo integrado, es necesario que se desarrollen programas auxiliares de nivel inferior que simulen el correcto funcionamiento. [27]

Abajo a arriba (bottom-up)

• Las pruebas inician con los módulos de nivel inferior, es decir los módulos más especializados, para ir ascendiendo de manera progresiva a los más superiores.[27]• No se dispone del sistema completo hasta el final, por lo tanto es necesario que se desarrollen programas auxiliares de nivel superior que permiten probar la integración. [27]

39


Tabla 6. Pruebas de integración

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

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas• Verificar la

funcionalidad del sistema a través de sus interfaces externas

• Comprobar que la funcionalidad corresponda a la esperada de acuerdo a los requerimientos. [10]

• Las pruebas del sistema no se limita a sistemas. Si el producto es un programa, las pruebas del sistema es el proceso de tratar de demostrar cómo el programa, en su conjunto, no cumple con sus objetivos.[42]

• Pruebas de integración ejecutadas. [27]

• Definición de un conjunto de objetivos medibles para el producto.[42]

• Plan de pruebas de sistema[27]

De acuerdo al ISTQB [2]:• Especificación de

requerimientos• Casos de uso• Especificaciones

funcionales• Informe de

análisis de riesgos

• Manuales de sistema, usuario y funcionamiento [2]

• Configuración del sistema[2]

• Datos de configuración. [2]

Roles que intervienen:• Equipo de pruebas

independiente[2]• Ingeniero de pruebas[27]• Analista funcional[27]• Jefe de pruebas[27]Técnicas:• Basadas en especificación:

técnicas de caja negra [2] y• Basadas en estructuras:

técnicas de caja blanca [2]Corrección de defectos:• Se reportan las

inconsistencias encontradas.• Se genera nueva versión del

software con la solución del defecto y es entregado para pruebas de sistema.

De acuerdo a INTECO [27]:• Informe de

Pruebas de Sistema.

• Manual de Usuario.

• Manual de Administración.

• Plan e Informe de Pruebas

• Sistema probado

Tabla 7. Pruebas de sistema

40


Pruebas de aceptaciónDescripció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 uso, que se utilicen con regularidad extrañas combinaciones de datos, que una salida en apariencia clara para el responsable de las pruebas sea ininteligible para el usuario de campo”[18]

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas• Determinar si el usuario,

cliente, u otra entidad autorizada acepta el sistema o componente objeto de la prueba.[39],[33]

• Validar los requerimientos [18]

• “El objetivo principal de las pruebas de aceptación no es localizar defectos, si no evaluar la buena disposición de un sistema para su despliegue y uso.”[2], demostrando que el software se encuentra listo para el paso a producción. [27]

• Ejecución de pruebas de sistema[27]• Especificación de requerimientos [27]• Manuales de usuario[27]• Plan de pruebas[27]

De acuerdo al ISTQB [2]:• Requerimientos de usuario• Requerimientos de sistema• Casos de uso• Procesos de negocio• Informes de análisis de riesgos

• Procesos de negocio [2]• Procesos operativos y de mantenimiento [2]• Procedimientos de usuario[2]• Formularios [2]• Informes [2]

Quien ejecuta la prueba:

• Analistas de pruebas

• Usuario del sistema[2]• Ingeniero de pruebas [27]• Jefe de pruebas [27]• Jefe del proyecto [27]

• Resultados de pruebas [27]• Producto aceptado [27]• Informe de

pruebas de aceptación [27]

Estrategias de pruebas de aceptación

Pruebas Alfa (α)

• El usuario o cliente realiza pruebas del sistema en el entorno de desarrollo [2],[27]• Se trabaja en un entorno controlado y el cliente siempre tiene un experto que le ayuda a usar el sistema.[18],[27]• El desarrollador registra los defectos encontrados y los problemas de uso. [27]

Pruebas Beta (β) • Se realizan después de las prueba alfa. [27]

41


• 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

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

Objetivo Entradas Documentos base Objeto de prueba Otros aspectos Salidas• Asegurar que los cambios en el sistema no afecte de manera negativa el software (comportamientos no esperados o errores adicionales).[18]• Permite asegurar los cambios del sistema.[18]• Verificar el correcto funcionamiento del software ante cambios del mismo.[27]• Demostrar que las pruebas que fueron exitosas en el software, continúan siendo exitosas. [10]

• Incorporación de un cambio en el sistema, sea por nuevas funcionalidades o mejoras a las ya existentes• Solución a defectos. [27]

• Las pruebas de regresión se pueden realizar en cada uno de los niveles de pruebas mencionados anteriormente. [10]

• Las pruebas de regresión se realizan en durante todo el ciclo de vida del sistema y se ejecutan cada vez que se modifica un componente del sistema [51], en la Ilustración 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]

42

Pruebas de Aceptación

Pruebas de Sistema

Pruebas de integración

Pruebas unitarias

PRUEBAS DE REGRESIÓ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:

• Verificar si el sistema soporta el número de carga especificado.

• Validar la respuesta del sistema ante las cargas que se realizan.


• Número de usuarios accediendo de manera concurrente [21]

• Documentos extremadamente grandes.

• Número de transacciones que se pueden procesar de forma concurrente.[21]

• Determinar el número de carga 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]

44


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]

45

Pruebas funcionales

Especifición de requerimientos Casos de uso Especificación

funcionalFunciones no

documentadas


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.

46

Pruebas no funcionales

Pruebas de rendimiento

Pruebas de carga

Pruebas de Stress

Pruebas de usabilidad

Pruebas mantenibilidad

Pruebas de fiabilidad

Pruebas de portabilidad


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 pruebaUn 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

47


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]

48

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]

PrecondicionesEstado 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


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

49

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


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<X<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 X ≤0 y X ≥10 son valores de entrada inválidos.

50

Calculadora

10

5 + 5=


• Todos los valores numéricos de entrada que se encuentren dentro del rango 0<X<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],

Y4. “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

51


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<X<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<X<10, donde las fronteras

son excluidas en el rango.• -1, 0, 10, 11 representan valores de prueba para el rango 0<X<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]

52


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 NEntrada 1 Si No SiEntrada 2 Si N/A NoEntrada N Si N/A Si

Salidas/RespuestasSalida 1 Si No SiSalida 2 Si No NoSalida 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/RespuestasCotiza pensión. No No No Si N/ARecibe 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.

53


• 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

f (Estado actual , entrada )→ (Nuevo estado , salida )f (EA 1 , EA2 ..EA n ,EA n+1 ,E1 , E2 ..En, En+1 )→ (N E1 ,NE2 ..NEn ,NEn+1 , S1 , S2 ..Sn , Sn+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.

54

Estado

inicial

Estado Final

Transición

Descripción del evento


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.

55

Si E1 entonces S1

S1E1

Si no E1 entonces S1

S1E1

E2

Si E1 y E2 entonces S1

S1E1

E3

E2

Si E1 o E2 o E3 entonces S1

S1

E1

Inicio

Inserta tarjeta Espera

Clave Ingreso clave

Primer Intento

SegundoIntento

Clave

incorrecta

Tercer Intento

Acceso a la cuenta

Clave Correcta

Clave incorrecta

Clave Correcta

Clave Correcta

Clave

incorrecta

Bloquear tarjeta

T1T2

T3

T4

T5

T6

T7

T8


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.

EventosEstado 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 Tabla14 se representa el ejemplo de la Ilustración 29.

56

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


Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 Caso 7 Caso 8Transició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

incorrectaEstado

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.

57


Caso de uso Acceso a la cuenta de un cliente a través de su tarjetaObjetivo Describir el flujo de acceso a la cuenta a través de la tarjeta de un cliente

Actor Cliente tarjeta

Precondiciones Usuario con tarjeta activaCuenta sin bloqueo

Descripción

Flujo normal

No paso Actor No

paso Sistema

1 Inserta la tarjeta 2 Valida tarjeta y solicita clave3 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]

58

5 + 5=

10

Calculadora


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]

Cobertura desentencia= Númerode sentenciasejecutadasNúmerototal de sententias ejecutables

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

Cobertura dedecisión=Número total deresultadosdedecisión cubiertosNúmero total de posibles resultadosdedecisión

×100 %

• El 100% de cobertura de decisión, garantiza el 100% de cobertura de sentencia, pero no viceversa. [2], [28]


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 V (G ) del grafo generado. [18] El valor de V (G ) 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 ) .V (G )=E−N+2

Donde E: Número de aristas y N el número de nodos.O, (2 ) .V (G )=P+1Donde P: Número de nodos predicados4 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

4 Suponiendo que las horas diarias laborales empleadas para pruebas son 7.5

60


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

62

ExplorarEncontrarInformación del sistema (para incluir y mejorar pruebas) [44] Defectos del sistema.

Identificar en el sistemaQue funciona.Que no funciona.El uso.Fortalezas.Debilidades.


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.

63


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

64


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

65

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

Documents