grupo 6 - procesos de verificacion y validacion en el desarrollo de software

Procesos de Validación y Verificación en el

Desarrollo de Software

“AÑO DE LA INTEGRACION NACIONAL Y EL RECONOCIMIENTO DE NUESTRA DIVERSIDAD”

UNIVERSIDAD NACIONAL

“SAN LUIS GONZAGA DE ICA”

FACULTAD DE INENIERIA DE SISTEMAS

Procesos de Validación y Verificación en el

Desarrollo de Software

TEMA

Bendezú Pizarro Sergio Raúl

Buendía Chilquillo Fredy Darío

Campos Rosas Raúl Alonso

Cruz Rivas Christian Fernando

Massa Morón Fredy Martín

INTENGRANTES

Calidad de Software

CURSO

Ing. Alonso Morales Loayza

DOCENTE

ICA – PERÚ

2012

DEDICATORIA

El presente trabajo está dedicado en primer lugar a Dios, hacedor de

todo y quien nos ha brindado la oportunidad de disfrutar la vida

siempre guiados por seres especiales.

A nuestros padres, quienes son aquellos seres, pilares fundamentales de

nuestra formación como personas de bien y porque es a ellos a quienes

le debemos todo lo que tenemos en la vida.

A nuestros docentes, que nos guían en el aprendizaje diario buscando

convertirnos en excelentes profesionales y brindándonos los últimos

conocimientos para nuestro buen desenvolvimiento en la sociedad.

ENTREGABLES

MONOGRAFÍA

Documento compuesto por 6 áreas y 12 secciones distribuidas de la siguiente

manera:

ÁREAS

1. Titulo

2. Conceptos Básicos

3. Resumen del Proyecto

4. Contenido

5. Recomendaciones y Conclusiones

6. Referencias Bibliográficas

SECCIONES

1. Procesos de Verificación y Validación de Software

2. Inspección de Software

3. Lista De Fallos

4. Pruebas de Software

5. Técnicas de Pruebas

6. Ciclo de Pruebas de Software

7. Planificación y Diseño de Pruebas de software

8. Ejecución de pruebas de software

9. Herramientas para la Ejecución de Pruebas

10. Recomendaciones para la Ejecución de Pruebas

11. Documentación para la Ejecución de pruebas

12. Proceso de Depuración

DVD

Contiene el trabajo monográfico en su versión digital, así como la bibliografía y

recursos utilizados para su desarrollo.

SKYDRIVE

El presente trabajo de investigación se encuentra disponible en la nube, al cual

puede acceder desde la siguiente dirección:

http://sdrv.ms/UvO2Iz

http://sdrv.ms/UvO2Iz%0c

Conceptos

Básicos

RESUMEN

Durante y después del proceso de implementación, el programa que se está

desarrollando debe ser comprobado para asegurar que satisface su especificación y

entrega la funcionalidad esperada por las personas que pagan por el software.

La verificación y la validación es el nombre dado a estos procesos de análisis y

pruebas, que son un conjunto de actividades que se realizan durante cada etapa del

proceso de software.

Según Boehm 1979 expreso la diferencia entre ellas:

Validación: ¿estamos construyendo el producto correcto?

Verificación: ¿estamos construyendo el producto correctamente?

Esto implica que la verificación debe estar de acuerdo con especificación, satisfacer

sus requerimientos funcionales y no funcionales.

La validación sin embargo es un proceso más general cuyo objetivo es que el

software satisfaga las expectativas del cliente.

El objetivo primordial es la seguridad de que el sistema está hecho para un

propósito.

Dentro de la verificación y validación existen dos conceptos complementarios tales

como: Inspecciones de software y Pruebas de software

Las inspecciones son un proceso de verificación y validación estática en el que un

sistema se revisa para encontrar errores omisiones y anomalías.

El proceso de inspección siempre se realiza utilizando una lista de los errores o fallos

comunes de los programadores. Esta se somete a discusión por el personal con

experiencia y se actualiza frecuentemente según se vaya teniendo experiencia.

Las Pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser

implementadas en cualquier momento de dicho proceso de desarrollo.

Las técnicas de prueba de software son aplicables como buenas prácticas en el

proceso de prueba en la etapa de desarrollo, cada una de ellas es importante y

mientras más compleja sea la codificación más de estas técnicas se utilizaran, los

códigos así como las interfaces tienen sus propias técnicas de prueba y en cada una

de ellas depende necesariamente de los involucrados en el desarrollo y de qué

manera aplicarlas.

El ciclo de vida del software presenta 4 componentes que son: Planear, Ejecutar,

Chequear y Actuar; que es un ciclo que se repetirá hasta llegar a los puntos de

validación acordados.

El objetivo del proceso de diseño de casos de pruebas es crear un conjunto de

casos de pruebas que sean efectivos descubriendo defectos y muestren que el

sistema satisface sus requerimientos, existen distintas aproximaciones para diseñar

casos de prueba. La documentación es una parte fundamental de las pruebas para

poder tener una guía exacta de lo que se realiza y no desperdiciar horas de trabajo.

El diseño de casos de prueba es una parte de las pruebas de componentes y

sistemas en las que se diseña los casos de prueba (entradas y salidas esperadas)

para probar el sistema. El objetivo del proceso de diseño de casos de pruebas es

crear un conjunto de casos de pruebas que sean efectivos descubriendo defectos y

muestren que el sistema satisface sus requerimientos.

La ejecución de pruebas de software se aplica como una etapa más del proceso de

desarrollo de software, su objetivo es asegurar que el software cumpla con las

especificaciones requeridas y eliminar los posibles defectos que este pudiera tener.

Para realizar la ejecución de pruebas de software necesitamos de herramientas

dedicadas a pruebas dentro de la organización. En la actualidad las herramientas

para la ejecución de pruebas de software son numerosas ya que estas deben hacer

frente a una gran cantidad de metodologías de desarrollo, lenguajes de

programación, sistemas operativos, hardware, etc.

En un principio la mayoría de empresas de desarrollo contaban con una etapa de

pruebas demasiado informal, en la actualidad las pruebas de software se han

convertido en una de las etapas más críticas del ciclo de vida del desarrollo de

software y esto ha causado el origen de diversas metodologías.

Durante la ejecución de las pruebas es fundamental conocer el estado del proceso

de prueba, saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué

defectos se han encontrado, etc. Para ello, se crean los registros de pruebas,

Informes de Incidentes e Informes resumen de pruebas.

Una vez realizadas las pruebas y definidos los posibles fallos o errores se procede a

entrar en el proceso de depuración, que es la corrección de errores que sólo afectan

a la programación, porque no provienen de errores previos en el análisis o en el

diseño.

A veces la depuración se hace luego de la entrega del sistema al cliente y es parte

del mantenimiento.

OBJETIVOS

OBJETIVO GENERAL

El objetivo General del proceso de verificación y validación de software es entender

la importancia del modelo de trabajo a seguir para desarrollar productos de

software donde lo que se busca es mejorar la calidad del software producido.

OBJETIVOS FUNDAMETALES

Producir un modelo que represente el comportamiento de sistema real lo

suficientemente próximo como para que el modelo pueda sustituir al sistema

con el objetivo de experimentar determinados aspectos del mismo.

Aumentar a un nivel aceptable la credibilidad del modelo, para que sea

aceptado por los gestores y usuarios finales a nivel de toma de decisiones

sobre los resultados proporcionados por dicho modelo.

OBJETIVOS ESPECÍFICOS

Entender la diferencia entre verificación y validación.

Tener claro los tipos de pruebas y las técnicas para usarlas.

Entender el ciclo de vida de las pruebas.

Dar herramientas para la planificación, diseño y ejecución de las pruebas de

software.

VOCABULARIO TÉCNICO

Verificar

Comprobar o examinar la verdad de algo. Es el proceso que se realiza para revisar si

un determinado producto está cumpliendo con los requisitos y normas previstos.

Validar

Dar fuerza o firmeza a algo, hacerlo válido. Es el proceso que se realiza para revisar

si un determinado producto es el que el usuario necesita.

Barry W. Boehm

Es un ingeniero informático estadounidense especialista en ciencias tecnológicas,

conocido por sus múltiples aportes a este campo.

Trazabilidad

Es la propiedad del resultado de una medida o del valor de un estándar donde éste

pueda estar relacionado con referencias especificadas, usualmente estándares

nacionales o internacionales, a través de una cadena continua de comparaciones

todas con incertidumbres especificadas.

Michael Fagan

Reconocido por ser el inventor de oficiales inspecciones de software que se refieren

a un proceso estructurado que trata de encontrar defectos en los códigos de

programación durante las diversas fases del proceso de desarrollo de software.

Alexander Graham Bell

Fue un científico, inventor y logopeda británico. Contribuyó al desarrollo de las

telecomunicaciones y la tecnología de la aviación.

Stakeholder

Es un término en inglés para referirse a «quienes pueden afectar o son afectados

por las actividades de una empresa».

Testing

Conocido como pruebas de software cuyo objetivo es proporcionar información

objetiva e independiente sobre la calidad del producto a la parte interesada

o stakeholder.

Stubs

Un stub es, en el contexto del testeo del software, un trozo de código usado como

sustituto de alguna otra funcionalidad. Un stub puede simular el comportamiento de

código existente o ser el sustituto temporal para un código aún no desarrollado.

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_inform%C3%A1tica

http://es.wikipedia.org/wiki/Estados_Unidos

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dfagan%26hl%3Des%26biw%3D1366%26bih%3D705%26prmd%3Dimvnsb&rurl=translate.google.com.pe&sl=en&twu=1&u=http://en.wiktionary.org/wiki/defect&usg=ALkJrhiYo93wjSaLt7jYX-7KE7-Ano_FHg

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dfagan%26hl%3Des%26biw%3D1366%26bih%3D705%26prmd%3Dimvnsb&rurl=translate.google.com.pe&sl=en&twu=1&u=http://en.wikipedia.org/wiki/Source_code&usg=ALkJrhhAUrJb0CSVQkFcxb6REkR3CV7I7Q

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dfagan%26hl%3Des%26biw%3D1366%26bih%3D705%26prmd%3Dimvnsb&rurl=translate.google.com.pe&sl=en&twu=1&u=http://en.wikipedia.org/wiki/Source_code&usg=ALkJrhhAUrJb0CSVQkFcxb6REkR3CV7I7Q

http://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=/search%3Fq%3Dfagan%26hl%3Des%26biw%3D1366%26bih%3D705%26prmd%3Dimvnsb&rurl=translate.google.com.pe&sl=en&twu=1&u=http://en.wikipedia.org/wiki/Software_development_process&usg=ALkJrhjc7oj1TvQnCKZpB9A7N6sxR7bYzw

http://es.wikipedia.org/wiki/Cient%C3%ADfico

http://es.wikipedia.org/wiki/Logopedia

http://es.wikipedia.org/wiki/Reino_Unido

http://es.wikipedia.org/wiki/Empresa

http://es.wikipedia.org/wiki/Stakeholder

Beta Tester

Es un usuario de programas que usan sus conocimientos informáticos y su tiempo

para detectar errores en el software y así poder informar de éstos para que los

desarrolladores los corrijan.

Feedback

Conocido como retroalimentación y que es un mecanismo de control de los

sistemas dinámicos por el cual una cierta proporción de la señal de salida se redirige

a la entrada, y así regula su comportamiento.

Walkthrough

Es una revisión estructurada de software hecha por colegas en la cual un diseñador

o programador lidera a los miembros de un equipo de desarrollo y donde los

participantes hacen preguntas y comentarios acerca de posibles errores.

Parámetros

Una variable que puede ser recibida por una rutina o subrutina. Puede alterar su

comportamiento en el tiempo de ejecución.

Almacenamiento dinámico

Incrementar o reducir de forma dinámica el número de elementos.

Compilador

Programa informático que traduce un lenguaje de programación a otro lenguaje de

programación, generando un equivalente que la máquina será capaz de interpretar

Lenguaje formal

Lenguaje cuyos símbolos primitivos y reglas para unir esos símbolos están

formalmente especificados.

Test Plan

Documento que detalla un enfoque sistemático para probar un sistema. Contiene

típicamente una comprensión detallada de lo que es el flujo de trabajo.

Scripts

Un archivo de órdenes o archivo de procesamiento por lotes que se almacena en un

archivo de texto plano.

GUI

Graphic User Interface o interfaz gráfica de usuario.

Identificador

Son símbolos léxicos que nombran entidades.

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Bugs

http://es.wikipedia.org/wiki/Se%C3%B1al

Resumen del

Proyecto

INTRODUCCIÓN

El presente documento pretende dar a conocer todo lo referente al proceso de

verificación y validación en el desarrollo de software, así como también extender el

conocimiento sobre los conceptos de inspección de software, pruebas de software

y las herramientas necesarias para realizar estas, además de entender el ciclo de

vida de las pruebas de software basándose en sus 4 pasos: Planear, Ejecutar,

Chequear y Actuar.

Estos conceptos son fundamentales a la hora de gestionar la calidad de un proyecto

de software pero muchas veces no aplicados o no entendidos, es por ello que este

documento pretende ser una guía de apoyo a la implementación de dichas áreas de

proceso, y de sus metas y actividades.

Describiremos las diferentes actividades relacionadas con dichos procesos. Se hará

un estudio de las pruebas, definiendo posibles estrategias, niveles y tipos de

pruebas, buenas prácticas, y por otra parte de las revisiones o inspecciones.

Tras la definición de las actividades de validación y verificación se propondrán una

serie de técnicas y metodologías a seguir además de algunas herramientas a utilizar

para realizar las pruebas de software desde su concepción, es decir cómo deben ser

planificadas, su documentación y como deben ser ejecutadas las mismas, así como

también herramientas que pueden ser muy útiles para su ejecución y de esta

manera facilitar el desarrollo de las tareas relacionadas con dichos procesos.

Por último se hará referencia a ciertas conclusiones y recomendaciones relacionadas

con dichas áreas de proceso útiles para tener otra perspectiva de los procesos.

INDICE GENERAL

1.- Procesos de Verificación y Validación de Software ……………………………………… 17

Objetivos …………………………………………………………………………………………………. 17

Técnicas …………………………………………………………………………………………………... 17

Planificación ………………………………………………………………………………………..….. 20

2.- Inspección de Software ……………………………………………………………………………….… 22

Ventajas ……………………………………………………………………………………………………. 22

Proceso de inspección de programas ……………………………………………………. 22

Actividades en el proceso de inspección ……………………………………………….. 23

Comprobaciones de inspección ……………………………………………………………… 24

Analisis estático automatizado ………………………………………………………………… 25

-Etapas ………………………………………………………………………………………….. 25

3.- Lista De Fallos …………………………………………………………………………………………………. 26

Fallos de datos

Fallos de Control

Fallos de entrada/salida

Fallos de la interfaz

Fallos de Gestión de Almacenamiento

Fallos de Gestión de las Excepciones

4- Pruebas de Software ……………………………………………………………………………………….. 28

Tipos De Pruebas de Software …………………………………………………………………. 28

- Revisiones de Código …………………………………………………………………. 28

- Pruebas Unitarias ………………………………………………………………………… 29

- Pruebas de Integración ………………………………………………………………. 29

- Pruebas de Sistema …………………………………………………………………….. 30

-Pruebas de Aceptación ………………………………………………………………… 31

5.- Técnicas de Pruebas ………………………………………………………………………………………… 32

Técnicas de Pruebas dinámicas ………………………………………………………………… 32

Basadas en la Especificación ………………………………………………………….. 33

Basadas en la Estructura ………………………………………………………………… 35

Basadas en la experiencia ………………………………………………………………. 36

Técnicas de Control Estáticas …………………………………………………………………….. 36

Revisiones ………………………………………………………………………………………... 38

Analisis Estático ……………………………………………………………………………….. 39

6.- Ciclo de Pruebas de Software …………………………………………………………………………… 41

Planear

Ejecutar

Chequear

Actuar

Calidad de Software Ing. Alonso Morales Loayza

Procesos de Verificación y Validación en el Desarrollo de Software 14

7.- Planificación y Diseño de Pruebas de software ………………………………………………… 43

Diseño de casos de prueba …………………………………………………………………………. 43

Pruebas Funcionales (CAJA NEGRA) ……………………………………………….. 44

Pruebas Estructurales (CAJA BLANCA) ……………………………………………. 45

Enfoque práctico recomendado para el diseño de casos ………………………… 46

Documentación del diseño de pruebas ………………………………………………………. 47

Plan de Pruebas …………………………………………………………………………………………….. 48

Especificación del Diseño de Pruebas …………………………………………………………. 48

Especificación de Caso de Pruebas ……………………………………………………………… 49

Especificaciones del Procedimiento de Prueba …………………………………………… 49

8.-Ejecución de pruebas de software ………………………………………………………………………. 51

El proceso de ejecución ………………………………………………………………………………….. 51

El proceso de comprobación …………………………………………………………………………. 52

9.- Herramientas para la Ejecución de Pruebas ……………………………………………………… 53

Herramientas

E-Tester …………………………………………………………………………………………………………… 53

Rational Functional Tester ……………………………………………………………………………… 53

Rational Manual Tester …………………………………………………………………………………… 54

Beneficios del Uso de Herramientas …………………………………………………………………………. 55

Riesgos del Uso de Herramientas ……………………………………………………………………………… 56

Factores a tener en cuenta para introducir una herramienta en una organización...57

10.- Recomendaciones para la Ejecución de Pruebas ……………………………………………… 59

11.- Documentación para la Ejecución de pruebas ………………………………………………….. 60

Histórico de Pruebas ………………………………………………………………………………………. 60

Informe de Incidente ………………………………………………………………………………………. 61

Informe resumen de pruebas …………………………………………………………………………. 61

12.- Proceso de Depuración ……………………………………………………………………………………… 63

Definición…….…………………………………………………………………………………………………… 63

Pasos para la Depuración ………………………………………………………………………………. 64

INDICE DE FIGURAS

Clasificación de Técnicas Dinámicas (Figura 1)………………………………………………………… 32

Clasificación de Técnicas Estáticas (Figura 2)……………………………………………………….….. 37

Ciclo de Prueba de Software – PDCA (Figura 3)……………………………………………………… 41

Esquema de una prueba de particiones (Figura 4)…………………………………………..……….44

Esquema de una prueba estructural (Figura 6)………………………………………………………… 46

Documentación de un diseño de pruebas según el estándar IEEE (Figura 7)…..……. 47

Proceso de Ejecución de Pruebas (Figura 8)………………………………………………………..……. 51

Software Rational (Figura 9)………………………………………………………………………………..……… 53

Documentación para la ejecución de pruebas (Figura 10)……………………………….………. 60

Depuración (Figura 11)………………………………………………………………………………………………… 63

INDICE DE TABLAS

Equipo de Inscripción de Programas (Tabla 1)……………………………………………………… 23

Comprobación de inversión de software (Tabla 2)…………………………………….………… 24

Contenido


Procesos de Verificación y Validación en el Desarrollo de Software - 18 -

1. PROCESOS DE VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE

La verificación y validación se realiza durante cada etapa del proceso de software

desde las revisiones de los requerimientos, las etapas de diseño e inspecciones de

código hasta la prueba del producto.

Para entender el concepto que implica el proceso de verificación de software

partiremos primero por descubrir en términos exactos lo que quiere decir

Verificación y Validación.

La verificación y validación son conceptos distintos aunque suelen confundirse. La

diferencia mayor radica en la respuesta a dos preguntas:

Según Boehm en 1979 expresó lo siguiente:

¿Estamos construyendo el producto correctamente? Es decir se comprueba que el

software cumple los requisitos funcionales y no funcionales de su especificación

(Verificación).

¿Estamos construyendo el producto correcto? Es decir asegurar que el sistema

satisface las expectativas del usuario (Validación)

Esto implica que la verificación debe estar de acuerdo con especificación, satisfacer

sus requerimientos funcionales y no funcionales.

La validación sin embargo es un proceso más general cuyo objetivo es que el

software satisfaga las expectativas del cliente.

1.1. Objetivo del proceso de verificación y validación

El objetivo primordial del proceso de verificación y validación es la

seguridad de que el sistema está hecho para un propósito, es decir que el

sistema debe ser lo bastante bueno para su uso pretendido.

1.2. Técnicas de verificación y validación

Existen 2 Técnicas de Verificación y Validación



1.2.1 Técnicas Estáticas (Revisiones):

Revisión de software: analizan y comprueban las representaciones del

sistema tales como el documento de requerimientos, diagramas de diseño y

código fuente del programa. Puede usarse en todas las etapas del proceso

Las revisiones software pueden ser

Informales

No hay procedimientos definidos, por lo que la revisión se realiza de

la forma más flexible posible.

Ventajas: menor coste y esfuerzo, preparación corta, etc.

Desventajas: Detectan menos defectos

Semi - Formales

Se definen unos procedimientos mínimos a seguir (walkthroughs).

Formales (Inspecciones)

Se define completamente el proceso. Revisión en detalle, por una

persona o grupo distintos del autor, para:

Verificar si el producto se ajusta a sus especificaciones o

atributos de Calidad y a los estándares utilizados en la empresa.

Señalar las desviaciones sobre los estándares y las

especificaciones.

Recopilar datos que realimenten inspecciones posteriores

defectos recogidos, esfuerzo empleado, etc.).

1.2.2 Técnicas Dinámicas (Pruebas):

Pruebas de software:

Implica ejecutar una implementación del software con datos de prueba. Se

examinan las salidas del software y su entorno operacional para comprobar

que funciona tal y como se requiere.



Solo puede probarse un sistema cuando está disponible un prototipo o

versión ejecutable del sistema.

Las técnicas de inspección comprenden las inspecciones del programa el

análisis automático del código fuente y la verificación formal.

Sin embargo las técnicas estáticas solo pueden comprobar la

correspondencia entre un programa y su especificación (verificación) no

pueden demostrar que el software es operacionalmente útil. Tampoco se

pueden usar técnicas estáticas para comprobar las propiedades emergentes

del software como rendimiento y fiabilidad.

1.3. Planificación de la verificación y validación

La verificación y validación es un proceso caro, es necesario una planificación

cuidadosa para obtener el máximo provecho de las inspecciones y pruebas

controlando los costos del proceso de verificación y validación.

Debería comenzarse desde etapas tempranas del proceso de desarrollo.

Como parte del proceso de planificación de verificación y validación habría

que decidir un equilibrio entre las aproximaciones estáticas y dinámicas de la

verificación y validación, pensar en estándares y procedimientos para las

inspecciones y pruebas de software, establecer listas de comprobación y

definir el plan de pruebas de software.

El relativo esfuerzo destinado a las inspecciones y las pruebas depende del

tipo de sistema a desarrollar y de los expertos de la organización en la

inspección de programas.

La planificación de las pruebas está relacionada con el establecimiento de

estándares para el proceso de pruebas, no solo con la descripción de los

productos de las pruebas. Los planes de pruebas además de ayudar con los

gestores a asignar recursos y estimar el calendario de las pruebas, son de

utilidad para los ingenieros del software implicados en el diseño y la

realización de las pruebas de sistema. Estos ayudan al personal técnico a

obtener una panorámica general de las pruebas del sistema y ubicas su

propio trabajo en este contexto.



Los principales componentes de un plan de pruebas para un sistema grande

son:

El proceso de pruebas: Una descripción de las principales fases del

proceso de prueba.

Trazabilidad de requerimientos: Los usuarios son los más interesados

que el sistema sea de calidad.

Elementos probados: deberían especificarse los elementos que van a

ser probados.

Calendarios de pruebas: Un calendario de todas las pruebas y

asignación de recursos.

Procedimiento de registro de pruebas: No es suficiente ejecutar

simplemente las pruebas los resultados deben ser registrados

sistemáticamente.



2. INSPECCIONES DE SOFTWARE

Son un proceso de Verificación y Validación estática en el que un sistema se revisa

para encontrar errores, omisiones y anomalías. Generalmente las inspecciones se

centran en el código fuente pero puede inspeccionarse cualquier representación

legible de software como requerimientos o modelos de diseño.

2.1 Ventajas

Existen 3 ventajas fundamentales de la inspección sobre las pruebas

Durante las pruebas los errores pueden enmascarar otros errores.

Cuando se descubre un error nunca se puede estar seguro de si otras

anomalías de salida son debidas a un nuevo error o son efectos laterales

del error original.

Pueden inspeccionarse versiones incompletas de un sistema sin costes

adicionales.

Una inspección también puede considerar atributos de calidad más

amplios de un programa tales como grado de cumplimiento con los

estándares portabilidad y mantenibilidad.

2.2 El proceso de inspección de programas

Son revisiones cuyo objetivo es la detección de defectos en el programa. El

concepto de un proceso de inspección formalizado se desarrolló por IBM

en los años 70 (Fagan 1976 -1986).

Actualmente es un método bastante utilizado de verificación de programa,

especialmente en ingeniería de sistemas críticos. A partir del método

original de Fagan, se han desarrollado varias aproximaciones alternativas de

las inspecciones (Graham 1993). Todas ellas están basadas en un grupo con

miembros que tienen diferentes conocimientos realizando una revisión

cuidadosa línea por línea del código fuente de programa.

La diferencia principal entre las inspecciones de programas y otros tipos de

revisiones de calidad es que el objetivo primordial de las inspecciones es

encontrar defectos en el programa en lugar de considerar cuestiones de

diseño más generales.



Los defectos pueden ser errores lógicos anomalías en el código que

podrían indicar una condición errónea o el incumplimiento de los

estándares del proyecto o la organización.

Por otra parte otros tipos de revisión pueden estar más relacionados con la

agenda, los costes, el progreso frente a hitos definidos o la evaluación de si

es probable que el software cumpla con los objetivos fijados por la

organización

La inspección de programas es un proceso formal realizado por un equipo

de al menos cuatro personas. Los miembros del equipo analizan

sistemáticamente el código y señalan posibles defectos.

EQUIPO DE INSCRIPCIÓN DE PROGRAMAS

Autor o Propietario

El programador o diseñador responsable de generar el programa o

documento. Responsable de reparar los defectos descubiertos durante

el proceso de inspección.

Inspector

Encuentra errores, omisiones o inconsistencias en los programas y

documentos. También puede identificar cuestiones más generales que

están fuera del ámbito de inspección.

Lector Presenta el código o documento en una reunión de inspección

Secretario Registra los resultados de la reunión de inspección

Presidente o Moderador Gestiona el proceso y facilita la inspección. Realiza un informe de

resultados del proceso para el moderador jefe

Moderador Jefe Responsable de las mejoras del proceso de inspección actualización de

las listas de comprobación, estándares de desarrollo

TABLA 1

2.3. Actividades en el proceso de inspección

Antes que se comience una inspección del programa es esencial que:

Se tenga una especificación precisa del código a inspeccionar.

Los miembros del equipo de inspección estén familiarizados con los

estándares de la organización.

Se haya distribuido una versión compatible y actualizada del código a todos

los miembros del equipo.



Las Actividades que debe seguir un proceso de inspección son:

Planificación: El moderador del equipo de inspección es el responsable

de la planificación de la inspección. Esto implica seleccionar un equipo de

inspección, organizar una sala de reuniones y asegurar que el material a

inspeccionar y sus especificaciones están completas.

Visión de conjunto: El programa a inspeccionar se presenta al equipo de

inspección durante la etapa de revisión general cuando el autor del

código describe lo que el programa debe hacer.

Preparación Individual: A continuación cada miembro del equipo estudia

la especificación, el programa y busca defectos en el código.

Reunión de inspección: La inspección en si misma debería ser bastante

corta no mayor a dos horas y debería centrarse en la detección de

defectos, cumplimiento de estándares y detectar programación de baja

calidad.

Repetición de trabajo: El autor del programa deberá realizar los cambios

para corregir los problemas identificados. En esta etapa el moderador

deberá decidir si se requiere una re-inspección de código o es aprobado.

Durante una inspección a menudo se utiliza una lista de comprobación de errores

de programación comunes para centrar el análisis.

2.4. Comprobaciones de inspección

Las comprobaciones de inspección son las principales inspecciones que se

realizan en el software. Las Comprobaciones y lo que realiza cada una son:

COMPROBACIONES DE INVERSIÓN DE SOFTWARE

Defecto de Datos ¿Se Inicializa todas las variables?, ¿Tiene nombre todas las

constantes?

Defectos de Control ¿Se garantiza que termina cada bucle?

Defectos Entrada/Salida ¿Se utilizan todas las variables de entrada? ¿Se les asigna un

valor a todas las variables de salida?

Defectos de Interfaz ¿Concuerdan los tipos de parámetros reales y formales?

¿Están en orden todos los parámetros?

Defectos de Gestión de

Almacenamiento

Si una estructura enlazada se modifica ¿Se reasigna

correctamente todos los enlaces? Si se utiliza almacenamiento

dinámico ¿Se asigna correctamente el espacio de memoria?

Defectos de Manejo de Excepciones ¿Se tienen en cuenta todas las condiciones de error posibles?

TABLA 2



2.5. Análisis estático automatizado

Los analizadores estáticos son herramientas de software que escanean el código

fuente de un programa y detectan posibles defectos y anomalías.

Pueden detectar si las sentencias están bien formadas, hacer inferencias sobre el

flujo de control del programa y calcular el conjunto de todos los posibles valores

para los datos del programa.

Complementan las facilidades de detección de los errores proporcionados por el

compilador del lenguaje. Pueden utilizarse como parte del proceso de inspección

o como una actividad separada del proceso de verificación y validación.

El objetivo del análisis estático automatizado es llamar la atención del inspector

sobre anomalías del programa, tales como variables que se utilizan sin

inicialización, variables que no se usan o datos cuyo valor podía estar fuera de

alcance

2.5.1. Etapas del análisis estático automatizado

Las etapas implicadas en el análisis estático comprenden:

Análisis del flujo de control: esta etapa identifica y resalta bucles con

múltiples salidas o puntos de entrada y código no alcanzable.

Análisis de uso de los datos: Esta etapa revela cómo se utilizan las

variables del programa detectan variables que se utilizan sin

inicialización previa, variables que se asignan dos veces y no se

utilizan.

Análisis de interfaces este análisis comprueba la consistencia de las

declaraciones de funciones y procedimientos y su utilización.

Análisis del flujo de información: Esta fase identifica las dependencias

entre las variables de entrada y salida. Mientras no detecte anomalías

muestra cómo se deriva el valor de cada variable del programa a

partir de otros valores de variables. En esta fase debería ser capaz de

encontrar valores que han sido calculados erróneamente.

Análisis de caminos: esta fase del análisis semántico identifica los

posibles caminos del programa y muestra la sentencia ejecutadas en

dicho camino.



3.- LISTAS DE FALLOS O ERRORES

El proceso de inspección siempre se realiza utilizando una lista de los errores

comunes de los programadores. Esta se somete a discusión por el personal con

experiencia y se actualiza frecuentemente según se vaya teniendo experiencia.

La lista de errores debe estar en función del lenguaje de programación que se

utilice.

La cantidad de código que se puede inspeccionar debe estar limitado, ya que a

partir de un tiempo de inspección se baja la atención y se hace ineficaz. Existen

estudios que establecen que no deberían examinarse más de 125 líneas de código

por sesión, y no más de 2 horas.

Clases de Fallos:

Fallos de datos:

1. ¿Las variables se inicializan antes que de que se utilicen los valores?

2. ¿Todas las constantes tienen nombre?

3. ¿El límite superior de los arrays es igual al tamaño de los mismos?

4. Las cadenas de caracteres tienen delimitadores explícitos.

5. ¿Existe posibilidad que el buffer se desborde?

Fallos de control:

1. Para cada instrucción condicional ¿Es correcta la condición?

2. ¿Todos los ciclos terminan?

3. ¿Los bloques están delimitados correctamente?

4. En las instrucciones case ¿Se han tomado en cuenta todos los casos?

5. Si se requiere un break ¿Se ha incluido?

6. ¿Existe código no alcanzable?

Fallos de entrada/salida:

1. ¿Se utilizan todas las variables de entrada?

2. Antes de que salgan ¿Se le han asignado valores a las variables de salida?

3. ¿Provocan corrupción de los datos las entradas no esperadas?

Fallos de la interfaz:

1. ¿Las llamadas a funciones y métodos tienen el número correcto de

parámetros?

2. ¿Concuerdan los tipos de los parámetros formales y reales?

3. ¿Están los parámetros en el orden adecuado?

4. ¿Se utilizan los resultados de las funciones?

5. ¿Existen funciones o procedimientos no invocados?



Fallos de gestión de almacenamiento:

1. Si una estructura con punteros se modifica, ¿Se reasignan correctamente

todos los punteros?

2. Si se utiliza almacenamiento dinámico, ¿se asigna correctamente el espacio?

3. ¿Se desasigna explícitamente la memoria después de que se libera?

Fallos de gestión de las excepciones:

1. ¿Se toman en cuenta todas las condiciones de errores posibles?



4.- PRUEBAS DE SOFTWARE

Las Pruebas de Software, o "Testing" es una investigación empírica y técnica cuyo

objetivo es proporcionar información objetiva e independiente sobre la calidad del

producto bajo pruebas a la parte interesada o Stakeholder.

Las Pruebas de Software son una actividad más en el proceso de "Aseguramiento de

la Calidad"

Las Pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser

implementadas en cualquier momento de dicho proceso de desarrollo.

4.1. Tipos de Pruebas de Software

4.1.1. Revisiones de código

Las revisiones de código son las únicas que se podrían omitir de todos los tipos de

pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:

Pruebas de escritorio

La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero

es una costumbre difícil de desterrar. Es bueno concentrarse en buscar

anomalías típicas, como variables u objetos no inicializados o que no se usan,

ciclos infinitos y demás

Recorridos de código

Los recorridos rinden mucho más. Son exposiciones del código escrito frente

a pares. El programador, exponiendo su código, encuentra muchos errores.

Además da ideas avanzadas a programadores nuevos que se lleva a recorrer.

Inspecciones de código

Las llamadas inspecciones de código consisten en reuniones en conjunto

entre los responsables de la programación y los responsables de la revisión.

Tienen como objetivo revisar el código escrito por los programadores para

chequear que cumpla con las normas que se hayan fijado y para verificar la

eficiencia del mismo. Se realizan siguiendo el código de un pequeño

porcentaje de módulos seleccionados al azar o según su grado de

complejidad.



4.1.2. Pruebas Unitarias

Las pruebas unitarias se realizan para controlar el funcionamiento de pequeñas

porciones de código como ser subprogramas (en la programación estructurada) o

métodos (en POO).

Generalmente son realizadas por los mismos programadores puesto que al conocer

con mayor detalle el código, se les simplifica la tarea de elaborar conjuntos de datos

de prueba para testearlo.

Si bien una prueba exhaustiva sería impensada teniendo en cuenta recursos, plazos,

etc., es posible y necesario elegir cuidadosamente los casos de prueba para recorrer

tantos caminos lógicos como sea posible. Inclusive procediendo de esta manera,

deberemos estar preparados para manejar un gran volumen de datos de prueba.

El tipo de prueba a la cual se someterá a cada uno de los módulos dependerá de su

complejidad. Recordemos que nuestro objetivo aquí es encontrar la mayor cantidad

de errores posible. Si se pretende realizar una prueba estructurada, se puede

confeccionar un grafo de flujo con la lógica del código a probar. De esta manera se

podrán determinar todos los caminos por los que el hilo de ejecución pueda llegar a

pasar, y por consecuencia elaborar los juegos de valores de pruebas para aplicar al

módulo, con mayor facilidad y seguridad.

4.1.3. Pruebas de Integración

Las pruebas de integración tienen como base las pruebas unitarias y consisten en

una progresión ordenada de testeos para los cuales los distintos módulos van

siendo ensamblados y probados hasta haber integrado el sistema completo.

Si bien se realizan sobre módulos ya probados en forma individual, no es necesario

que se terminen todas las pruebas unitarias para comenzar con las de integración.

El orden de integración de los módulos influye en:

La forma de preparar los casos de prueba.

Las herramientas a utilizar (módulos ficticios, muñones, impulsores o “stubs”).

El orden para codificar y probar los módulos.

El costo de preparar los casos.

El costo de la depuración.



Existen principalmente dos tipos de integración:

La integración incremental

Consiste en combinar el conjunto de módulos ya probados con los siguientes

módulos a probar. Luego se va incrementando progresivamente el número de

módulos unidos hasta que se forma el sistema completo.

La integración no incremental o Big Bang

Se combinan todos los módulos de una vez.

Para ambos tipos de integración se deberán preparar los datos de prueba junto con

los resultados esperados.

Si en algún momento de la prueba se detectara uno o más errores, se dejará

constancia del hecho y se reenviarán los módulos afectados al responsable de la

programación para que identifique la causa del problema y lo solucione. Luego se

volverán a efectuar las pruebas programadas y así sucesivamente hasta que el

sistema entero esté integrado y sin errores.

4.1.4. Pruebas de Sistema

Las pruebas de sistema se realizan una vez integrados todos los componentes. Su

objetivo es ver la respuesta del sistema en su conjunto, frente a distintas situaciones.

Se simulan varias alternativas que podrían darse con el sistema implantado y en

base a ellas se prueba la eficacia y eficiencia de la respuesta que se obtiene.

Se pueden distinguir varios tipos de prueba, por ejemplo:

Pruebas negativas: se trata de que el sistema falle para ver sus debilidades.

Pruebas de recuperación: se simulan fallas de software y/o hardware para

verificar la eficacia del proceso de recuperación.

Pruebas de rendimiento: tiene como objeto evaluar el rendimiento del

sistema integrado en condiciones de uso habitual.

Pruebas de resistencia o de estrés: comprueban el comportamiento del

sistema ante situaciones donde se demanden cantidades extremas de

recursos (número de transacciones simultáneas anormal, excesivo uso de las

memorias, etc.).



Pruebas de seguridad: se utilizan para testear el esquema de seguridad

intentando vulnerar los métodos utilizados para el control de accesos no

autorizados al sistema.

Pruebas de instalación: verifican que el sistema puede ser instalado

satisfactoriamente en el equipo del cliente, incluyendo todas las plataformas

y configuraciones de hardware necesarias.

Pruebas de compatibilidad: se prueba al sistema en las diferentes

configuraciones de hardware o de red y de plataformas de software que

debe soportar.

4.1.5. Pruebas de Aceptación

Las pruebas de aceptación, al igual que las de sistema, se realizan sobre el producto

terminado e integrado; pero a diferencia de aquellas, estas están concebidas para

que sea un usuario final quien detecte los posibles errores.

Se clasifican en dos tipos: Pruebas Alfa y Pruebas Beta.

Las pruebas Alfa se realizan por un cliente en un entorno controlado por el equipo

de desarrollo. Para que tengan validez, se debe primero crear un ambiente con las

mismas condiciones que se encontrarán en las instalaciones del cliente. Una vez

logrado esto, se procede a realizar las pruebas y a documentar los resultados.

Por otro lado, las pruebas Beta se realizan en las instalaciones propias de los

clientes.

Para que tengan lugar, en primer término se deben distribuir copias del sistema para

que cada cliente lo instale en sus oficinas, dependencias y/o sucursales. Si se tratase

de un número reducido de clientes, el tema de la distribución de las copias no

representa grandes dificultades, pero en el caso de productos de venta masiva, la

elección de los Beta Tester debe realizarse con sumo cuidado.

En el caso de las pruebas Beta, cada usuario realizará sus propias pruebas y

documentará los errores que encuentre para que el equipo de desarrollo los tenga

en cuenta al momento de analizar las posibles modificaciones.

Cuando el sistema tenga un cliente individual, las pruebas de aceptación se hacen

de común acuerdo con éste, en cambio cuando se está desarrollando un producto

masivo, los usuarios para pruebas se determinan de formas menos estrictas, y hay

que ser muy cuidadoso en la evaluación del Feedback que proveen. Por lo tanto, en

este segundo caso hay que dedicar un esfuerzo considerable a la planificación de las

pruebas de aceptación.



5.- TÉCNICAS DE PRUEBAS DE SOFTWARE

Existen distintas técnicas de pruebas de software, con sus debilidades y sus puntos

fuertes. Cada una de ellas es buena para encontrar un tipo específico de defectos.

Las pruebas realizadas en distintas etapas del ciclo de desarrollo del software

encontrarán diferentes tipos de defectos.

Las pruebas dinámicas sólo se aplican sobre el código del producto para detectar

defectos y determinar atributos de calidad del software, por lo que estarían más

orientadas al área de validación. Por otra parte, las técnicas de pruebas estáticas son

útiles para evaluar o analizar documentos de requisitos, documentación de diseño,

planes de prueba, o manuales de usuario, e incluso para examinar el código fuente

antes de ejecutarlo. En este sentido, ayudan más a la implementación del proceso

de verificación.

Las pruebas estáticas y las pruebas dinámicas son métodos complementarios ya que

ambas tratan de detectar distintos tipos de defectos de forma efectiva y eficiente,

aunque las pruebas estáticas están orientadas a encontrar defectos mientras que las

dinámicas fallos.

5.1. Técnicas de pruebas dinámicas

Las técnicas de pruebas dinámicas ejecutan el software. Para ello introducen una

serie de valores de entrada, y examinan la salida comparándola con los resultados

esperados.

Basadas en

Especificacion

Particionamiento

de Equivalencia

Analisis Frontera

Tabla de decision

Transicion

estados

Caso de uso

Basadas en Estructura

Pruebas de

Sentencia

Pruebas de

Decision

Pruebas de

Caminos

Basadas en

Experiencia

Adivinar errores

Pruebas

exploratorias

Figura 1. Clasificación de Técnicas Dinámicas



a) Basadas en la especificación

Son conocidas como técnicas de pruebas de caja negra o conducidas por

entradas/salidas, porque tratan el software como una caja negra con

entradas y salidas, pero no tienen conocimiento de cómo está estructurado el

programa o componente dentro de la caja. Esencialmente, el técnico de

pruebas se concentra en qué hace el software y no en cómo lo hace.

A continuación, se detallarán las técnicas basadas en la especificación más

comunes.

- Particionamiento de equivalencia

Esta técnica consiste en dividir un conjunto de condiciones de prueba en

grupos o conjuntos que puedan ser considerados iguales por el sistema.

Esta técnica requiere probar sólo una condición para cada partición. Esto

es así porque se asume que todas las condiciones de una partición serán

tratadas de la misma manera por el software. Si una condición en una

partición funciona, se asume que todas las condiciones en esa partición

funcionarán. De la misma forma, si una de las condiciones en una partición

no funciona, entonces se asume que ninguna de las condiciones en esta

partición en concreto funcionará.

- Análisis de valor frontera

Los errores generados por los programadores tienden a agruparse

alrededor de las fronteras. El análisis del valor frontera está basado en

probar los valores frontera de las particiones. Al hacer comprobaciones de

rango, probablemente se esté usando de forma inconsciente el análisis del

valor frontera. En esta técnica, también, se cuenta con fronteras válidas (en

las particiones válidas) y frontera no válidas (en las particiones no válidas).

- Tablas de decisión

Las técnicas de Particionamiento de equivalencia y análisis del valor

frontera son aplicadas con frecuencia a situaciones o entradas específicas.

Sin embargo, si diferentes combinaciones de entradas dan como resultado

diferentes acciones, resulta más difícil usar las técnicas anteriores.

Las especificaciones suelen contener reglas de negocio para definir las

funciones del sistema y las condiciones bajo las que cada función opera.



Las decisiones individuales son normalmente simples, pero el efecto global

de las condiciones lógicas puede ser muy complejo. Los técnicos de

pruebas necesitan ser capaces de asegurarse que todas las combinaciones

de las condiciones que puedan ocurrir han de ser probadas, por lo tanto,

hay que capturar todas las decisiones de una forma que permita explorar

sus combinaciones. El mecanismo usado con frecuencia para capturar las

decisiones lógicas es la tabla de decisión.

Una tabla de decisión lista todas las condiciones de entrada que pueden

ocurrir y todas las acciones que pueden surgir de ellas. Están estructuradas

por filas, con las condiciones en la parte de arriba de la tabla y las posibles

acciones en la parte de abajo. Cada columna, representa una regla de

negocio individual y muestra cómo se combinan las condiciones de

entrada para producir acciones. De esta manera, cada columna representa

un posible caso de prueba, ya que identifica ambas entradas y salidas.

- Transición de estados

La técnica anterior (tabla de decisión) es particularmente útil cuando las

combinaciones de condiciones de entrada producen varias acciones. La

técnica de transición de estados se utiliza con sistemas en los que las

salidas son desencadenadas por cambios en las condiciones de entrada, o

cambios de “estado”.

Las pruebas de transición de estados se usan cuando alguno de los

aspectos del sistema se pueden describir en lo que se denomina una

“máquina de estados finitos”. Esto significa que el sistema puede estar en

un número (finito) de estados, y las transiciones de un estado a otro están

determinadas por las reglas de la “máquina”. Este es el modelo en el que

se basan el sistema y las pruebas.

Un sistema de estados finitos se suele representar mediante un diagrama

de estados.

- Pruebas de casos de Uso

Las pruebas de caso de uso son una técnica que ayuda a identificar casos

de prueba que ejerciten el sistema entero transición a transición desde el

principio al final.

Un caso de uso es una descripción de un uso particular del sistema por un

actor (un usuario del sistema).



Cada caso de uso describe las interacciones que el actor tiene con el

sistema para conseguir una tarea concreta. Los actores son generalmente

gente pero pueden ser también otros sistemas. Resumidamente, los casos

de uso son una secuencia de pasos que describen las interacciones entre

el actor y el sistema.

b) Basadas en la estructura

Las pruebas estructurales son una aproximación al diseño de casos de

prueba donde las pruebas se derivan a partir del conocimiento de la

estructura e implementación del software. Esta aproximación se denomina a

veces pruebas de caja blanca.

La comprensión del algoritmo utilizado en un componente puede ayudar a

identificar particiones adicionales y casos de prueba, asegurando así un

mayor rango de pruebas. Las técnicas más sofisticadas proporcionan, de

forma incremental, una cobertura de código completa. A continuación, se

detallarán las técnicas basadas en la estructura más comunes.

- Pruebas de sentencia

El objetivo de las pruebas de sentencia es ir probando las distintas

sentencias a lo largo del código. Si se prueban todas y cada una de las

sentencias ejecutables del código, habrá una cobertura de sentencia

total. Es importante recordar que estas pruebas sólo se centran en

sentencias ejecutables a la hora de medir la cobertura. Es muy útil el uso

de gráficos de flujo de datos para identificar este tipo de sentencias, que

se representan mediante rectángulos.

- Pruebas de decisión

El objetivo de estas pruebas es asegurar que las decisiones en un

programa son realizadas adecuadamente. Las decisiones son parte de las

estructuras de selección e iteración, por ejemplo, aparecen en

construcciones tales como: IF THEN ELSE, o DO WHILE, o REPEAT UNTIL.

Para probar una decisión, es necesario ejecutarla cuando la condición

que tiene asociada es verdadera y también cuando es falsa. De esta

forma, se garantiza que todas las posibles salidas de la decisión se han

probado.

Al igual que las pruebas de sentencias, las pruebas de decisión tienen

una medida de cobertura asociada e intentan conseguir el 100% de la

cobertura de decisión.



- Pruebas de caminos

Las pruebas de caminos son una estrategia de pruebas estructurales

cuyo objetivo es probar cada camino de la ejecución

independientemente. En todas las sentencias condicionales, se

comprueban los casos verdadero y falso. En un proceso de desarrollo

orientado a objetos, pueden utilizarse las pruebas de caminos cuando se

prueban los métodos asociados a los objetos.

Las pruebas de caminos no prueban todas las posibles combinaciones de

todos los caminos en el programa. Para cualquier componente distinto

de un componente trivial sin bucles, este es un objetivo imposible. Existe

un número infinito de posibles combinaciones de caminos en los

programas con bucles. Incluso cuando todas las sentencias del programa

se han ejecutado al menos una vez, los defectos del programa todavía

pueden aparecer cuando se combinan determinados caminos.

c) Basadas en la experiencia

Las técnicas basadas en experiencia son aquellas a las que se recurre cuando

no hay una especificación adecuada desde la que crear casos de prueba

basados en especificación, ni hay tiempo suficiente para ejecutar la estructura

completa del paquete de pruebas.

- Adivinar errores

Las técnicas basadas en experiencia usan la experiencia de los usuarios y

de los técnicos de pruebas para determinar las áreas más importantes de

un sistema y ejercitar dichas áreas de forma que sean consistentes con el

uso que se espera que tengan.

- Pruebas exploratorias

Técnicas de pruebas más sofisticadas que se realizan sobre la base del

conocimiento y experiencia de los técnicos de pruebas; dicha base es un

factor decisivo para el éxito de las pruebas.

5.2 Técnicas de control estáticas

Aunque las técnicas estáticas son utilizadas cada vez más, las pruebas

dinámicas siguen siendo las técnicas predominantes de validación y

verificación.



Las técnicas estáticas permiten encontrar las causas de los defectos. Aplicar un

proceso de pruebas estáticas sobre el proceso de desarrollo permite una

mejora del proceso evitando cometer errores similares en el futuro.

Las técnicas de pruebas estáticas proporcionan una forma de mejorar la

productividad del desarrollo del software. El objetivo fundamental de las

pruebas estáticas es mejorar la calidad de los productos software, ayudando a

los ingenieros a reconocer y arreglar sus propios defectos en etapas tempranas

del proceso de desarrollo. Aunque las técnicas de este tipo de pruebas son

muy efectivas, no conviene que sustituyan a las pruebas dinámicas.

Estas pruebas, son las primeras que se aplican al software y buscan defectos sin

ejecutar código. Por esta razón, también se llaman “técnicas de no ejecución”.

Las técnicas estáticas tienen que ver con el análisis y control de las

representaciones del sistema, es decir de los diferentes modelos construidos

durante el proceso de desarrollo de software.

La mayoría de las técnicas estáticas son técnicas de verificación que pueden

probar cualquier tipo de documentación ya sea código fuente, o

documentación y modelos de diseño, o especificación funcional o de

requisitos.

Figura 2. Clasificación de técnicas de control estáticas

Revisiones

Informal

Walkthrough

Revisión Técnica

Inspección

Análisis Estático

Analisis de flujo de control

Analisis de uso de los datos

Analisis de Interfaz

Analisis de flujo de informacion

Analisis de caminos



a) Revisiones

Las revisiones son una técnica estática que consiste en realizar un análisis de

un documento con el objetivo de encontrar y eliminar errores. El tipo de

una revisión varía en función de su nivel de formalidad. En este caso,

„formalidad‟ se refiere a nivel de estructura y documentación asociada con

la revisión. Unos tipos de revisión son completamente informales mientras

que otros son muy formales.

No existe una revisión perfecta, sino que cada una tiene un propósito

distinto durante las etapas del ciclo de vida del documento. Los principales

tipos de revisiones se describen a continuación:

- Informal

Dar un borrador de un documento a un colega para que lo lea es el

ejemplo más simple de revisión. Es una forma de conseguir beneficios

(limitados) a un bajo costo ya que no siguen ningún proceso formal a

seguir. La revisión puede implementarse mediante „pares de

programadores‟, donde uno revisa el código del otro, o mediante un

técnico que lidere el diseño de las revisiones y el código.

- Walkthrough

Un Walkthrough se caracteriza porque el autor del documento bajo

revisión va guiando al resto de participantes a través del documento

exponiendo sus ideas para conseguir un entendimiento común y recoger

respuestas. Es especialmente útil si los asistentes no están relacionados

con el software, o no son capaces de entender los documentos de

desarrollo de software. En las revisiones Walkthrough se explica el

contenido del documento paso a paso hasta llegar a un consenso en los

cambios y en el resto de información. La reunión es dirigida por los

autores y a menudo está presente un documentador, y para facilitar su

ejecución pueden usarse escenarios y simulaciones para validar el

contenido.

- Revisión técnica

Una revisión técnica es una reunión que se centra en conseguir consenso

sobre el contenido técnico de un documento, por lo que es posible que

sea dirigida por un experto técnico. Los expertos necesarios para una

revisión técnica son, por ejemplo, responsables del diseño y usuarios

clave.



El objetivo principal de este tipo de revisiones es evaluar el valor de

conceptos técnicos y alternativas del entorno del proyecto y del propio

producto. Este tipo de revisión a menudo se lleva a cabo por “pares”

(peer reviews) y para facilitar su ejecución suelen utilizarse listas de

comprobación o listas de registro.

- Inspección

La inspección es el tipo de revisión más formal. El documento bajo

inspección es preparado y validado minuciosamente por revisores antes

de la reunión, se compara el producto con sus fuentes y otros

documentos, y se usan listas de comprobación. En la reunión de la

inspección, se registran los defectos encontrados y se pospone toda

discusión para la fase de discusión. Todo esto hace que la inspección sea

una reunión muy eficiente.

La inspección es dirigida normalmente por un moderador formado, no

por el propio autor del documento, quien realiza un seguimiento formal

aplicando criterios de salida. Los defectos encontrados son

documentados en una lista de registro, y de manera opcional, para

mejorar los procesos y aprender de los defectos encontrados, se realiza

un análisis de las causas de los mismos. También, es habitual tomar

métricas que posteriormente son agrupadas y analizadas para optimizar

el proceso.

b) Análisis estático

El análisis estático, al igual que las revisiones, busca defectos sin ejecutar el

código. Sin embargo, el análisis estático se lleva a cabo una vez que se

escribe el código. Su objetivo es encontrar defectos en el código fuente y en

los modelos del software.

Se utilizan herramientas de software para procesar código fuente. Éstas

analizan sintácticamente el programa y tratan de descubrir condiciones

potencialmente erróneas y llamar la atención del equipo de validación y

verificación.

Existen distintos tipos de análisis sintáctico, entre los que se encuentran:

- Análisis de flujo de control

Comprueba los bucles con múltiples puntos de entrada o salida,

encuentra códigos inalcanzables.



- Análisis de uso de los datos

Detecta variables no inicializadas, variables escritas dos veces sin que

intervenga una asignación, variables que se declaran pero nunca se usan.

- Análisis de interfaz

Comprueba la consistencia de una rutina, las declaraciones del

procedimiento y su uso.

- Análisis de flujo de información

Identifica las dependencias de las variables de salida. No detecta

anomalías en sí pero resalta información para la inspección o revisión del

código.

- Análisis de caminos

Identifica los caminos del programa y arregla las sentencias ejecutadas

en el camino. Es potencialmente útil en el proceso de revisión.



6.- CICLO DE PRUEBA DE SOFTWARE

Existen múltiples enfoques del ciclo de la prueba de software basados en las

experiencias de distintos profesionales, si bien todos son válidos existen pasos que

podemos considerar comunes y que se podrían agrupar entre todos los distintos

modelos.

Figura 3. Ciclo de Prueba de Software (PDCA)

a) Planear

Es establecer los objetivos y procesos necesarios para conseguir resultados

de acuerdo con los requisitos del cliente y las políticas de la organización.

1. Identificar servicios

2. Identificar clientes

3. Identificar requerimientos de los clientes

4. Trasladar los requerimientos del cliente a especificaciones

5. Identificar los pasos claves del proceso (diagrama de flujo)

6. Identificar y seleccionar los parámetros de medición

7. Determinar la capacidad del proceso

8. Identificar con quien compararse



Un caso de prueba bien diseñado tiene gran posibilidad de llegar

resultados más fiables y eficientes, mejorar el rendimiento del sistema, y

reducir los costos en tres categorías (Perry, 1995):

1) Productividad: menos tiempo para escribir y mantener los casos

2) Capacidad de prueba: menos tiempo para ejecutarlos

3) Programar la fiabilidad: estimaciones más fiables y efectivas.

b) Hacer o Ejecutar

Hacer las condiciones. Realizar trabajo de entrenamiento y aprendizaje.

Acordar el procedimiento. Se procede a ejecutar la prueba según los

parámetros previamente fijados y se documentan los resultados haciendo

un seguimiento del camino de los fallos, si hubiera, dentro del sistema y sus

características. Generando un historial de las ejecuciones. La ejecución de

las pruebas debería ser en un mínimo de tiempo y con el mínimo de

esfuerzo.

La ejecución nos genera: documentación de los detalles de la prueba y sus

salidas, lista de fallos y sus orígenes. Vemos que en este punto la

documentación es muy importante pues lo que buscamos es expresar de la

mejor manera el error y resultados. Para ello la documentación tiene que

ser detallada pero en un lenguaje formal.

c) Chequear o Verificar

Chequear el programa y los resultados obtenidos.

En este punto se comparan los resultados obtenidos de las pruebas con los

resultados esperados: información obtenida, tiempos de respuesta,

respuestas ante ataques a la seguridad, etc.

Donde se falla o que parte del software necesita ser reformulada, con el

listado de los errores se generaran informes a los stakeholders. Se

generaran sugerencias y niveles de prioridad a los errores.

d) Actuar

Tomar los cursos de acción decididos respectos de los errores hallados sea

reparar, replantear o implementar alguna otra solución. Se documentaran

los detalles de las modificaciones del software y se pedirá que se ejecuten

de nuevo pruebas a los sectores que han sido modificados.



7. PLANIFICACIÓN Y DISEÑO DE PRUEBAS DE SOFTWARE

7.1. Diseño de casos de prueba

El diseño de casos de prueba es una parte de las pruebas de componentes y

sistemas en las que se diseña los casos de prueba (entradas y salidas esperadas)

para probar el sistema. El objetivo del proceso de diseño de casos de pruebas

es crear un conjunto de casos de pruebas que sean efectivos descubriendo

defectos y muestren que el sistema satisface sus requerimientos.

Para diseñar un caso de prueba, se selecciona una característica del sistema o

componente que se está probando. A continuación, se selecciona un conjunto

de entradas que ejecutan dicha característica, documentan las salidas esperadas

o rango de salidas y, donde sea posible, se diseña una prueba automatizada

que prueba que las salidas reales y esperadas fueron las mismas.

Existen varias aproximaciones que pueden seguirse para diseñar casos de

pruebas las dos principales son:

Pruebas Funcionales: En donde se identifican particiones de entrada y

salida y se diseñan pruebas para que el sistema ejecute entradas de

todas las particiones y genere salidas en todas las particiones. Las

particiones son grupos de datos que tienen características comunes,

como todos los números negativos, todos los nombres con menos de 30

caracteres, todos los eventos provocados por la elección de opciones en

un menú, y así sucesivamente.

Pruebas Estructurales: En donde se utiliza el conocimiento de la

estructura del programa para diseñar pruebas que ejecuten toldas las

partes del programa. Esencialmente, cuando se prueba un programa,

debería intentarse ejecutar cada sentencia al menos una vez. Las pruebas

estructurales ayudan a identificar casos de prueba que puedan hacer

esto posible

En general cuando se diseñan casos de pruebas se debería comenzar por las

pruebas de más alto nivel, a partir de los requerimientos y luego de forma

progresiva añadir pruebas más detalladas como las pruebas estructurales o de

particiones.



7.1.1 Pruebas Funcionales

Las pruebas funcionales o las pruebas de Caja Negra, se basan en los datos

de entrada y los datos de salida, buscando solamente el resultado sin

preocuparse como se consiguió este.

Sin embargo en estas pruebas los datos de entrada y los resultados de

salida de un programa normalmente se pueden agrupar en varias clases

diferentes que tienen características comunes tales como números positivos,

números negativos y selecciones de menú.

Los programas normalmente se comportan de una forma similar para todos

los miembros de una clase. Es decir, si se prueba un programa que realiza

algún cálculo y requiere 2 números positivos, entonces se esperara que el

programa se comporte de la misma forma para todos los números

positivos.

Debido a este comportamiento equivalente, estas clases de denominan a

menudo particiones de equivalencia o dominios. Una aproximación

sistemática al diseño de casos de prueba se basa en identificar todas las

particiones para un sistema o componente. Los casos de prueba se diseñan

para que las entradas o salidas pertenezcan a estas particiones.



Las particiones de equivalencia son conjuntos de datos en donde todos los

miembros de los conjuntos deberían ser procesados de forma equivalente.

Las particiones de equivalencia de salida son resultados del programa que

tienen características comunes, por lo que pueden considerarse como una

clase diferente.

También se identifican particiones en donde las entradas están fuera de

otras particiones que se han elegido. Estas prueban si el programa maneja

entradas inválidas de forma correcta. Las entradas validas e inválidas

también forman particiones de equivalencia.

Se identifican particiones usando las especificaciones del programa o

documentación del usuario y, a partir de la propia experiencia, se predice

que clases de valores de entrada es probable que detecten errores.

Cuando se están probando problemas con secuencias, vectores o listas,

existen varias recomendaciones que a menudo son útiles para diseñar casos

de prueba:

1. Probar el software con secuencias que reúne solo un valor. Los

programadores piensan de forma natural que las secuencias están

formadas por varios valores y como consecuencia, el programa

puede no funcionar correctamente cuando se te presenta una

secuencia de un único valor.

2. Utiliza varias secuencias de diferentes tamaños en distintas pruebas.

Esto disminuye la probabilidad de que un programa con defectos

produzca accidentalmente una salida correcta debido a alguna

característica ocasional en la entrada.

3. Generar pruebas para acceder al primer elemento, al elemento

central y al último elemento de la secuencia. Esta aproximación pone

de manifiesto problemas en los límites de la partición

7.1.2 Pruebas estructurales

Las pruebas estructurales se derivan a partir del conocimiento de la

estructura e implementación del software. Estas se denominan a veces

pruebas de “caja blanca” para distinguirlas de las pruebas de caja negra.



La comprensión del algoritmo utilizado en un componente puede ayudar a

identificar particiones y casos de prueba.

7.2 Enfoque práctico recomendado para el diseño de casos

El enfoque práctico pretende ser una serie de recomendaciones para el mejor

diseño de casos de pruebas considerando criterios básicos y de distintas

técnicas

1. Si la especificación contiene combinaciones de condiciones de entrada,

comenzar formando grafos de causa-efecto (ayudan la comprensión de

dichas combinaciones).

2. En todos los casos, usar análisis de valores límites para añadir casos de

pruebas.

3. Identificar las clases válidas y no válidas de equivalencia para la entrada

y la salida, y añadir los casos no incluidos anteriormente.

4. Utilizar la técnica de conjetura de errores para añadir nuevos casos,

referidos a valores especiales.

5. Ejecutar los casos generados hasta el momento y analizar la cobertura

obtenida.

6. Examinar la lógica del programa para añadir los casos precisos (de caja

blanca) para cumplir el criterio de cobertura elegido si los resultados de

la ejecución del punto anterior indican que no se ha satisfecho el

criterio de cobertura elegido



A veces los desarrolladores se cuestionan por qué se debe examinar todos los

caminos de un programa si es que la funcionalidad ha sido demostrada con las

pruebas de requisitos:

Los errores lógicos y las suposiciones incorrectas son inversamente

proporcionales a la probabilidad de que se ejecute un camino del

programa

Se suele creer que un camino lógico tiene pocas probabilidades de

ejecutarse cuando, en realidad, se puede ejecutar regularmente.

Los errores tipográficos son aleatorios; pueden aparecer en cualquier

parte del programa (sea muy usada o no).

La probabilidad y la importancia de un trozo de código suele ser

calculada de forma muy subjetiva.

7.3. Documentación del diseño de pruebas

Como se mencionó la documentación es una parte fundamental de las pruebas

para poder tener una guía exacta de lo que se realiza y no desperdiciar horas

de trabajo.

El primer paso se sitúa en la planificación general del esfuerzo de prueba

(plan de pruebas) para cada fase de la estrategia de prueba para el

producto.



Se genera inicialmente la especificación del diseño de la prueba (que surge

de la ampliación y el detalle del plan de pruebas).

A partir de este diseño, se prueba definir con detalle cada uno de los casos

mencionados escuetamente en el díselo de la prueba (se fijan los datos de

pruebas exactos, los resultados esperados, etc.).

Tras generar los casos de prueba detallados se debe especificar cómo

proceder en detalle de la ejecución de dichos casos (procedimiento de

prueba).

Toda la documentación debe ser básica para la ejecución de la prueba pero

son los procedimientos los que determinan como se desarrollara la

ejecución.

7.4 Plan de Pruebas:

Señalar el enfoque, los recursos y el esquema de actividades, así como los

elementos a probar, las características, las actividades, el personal responsable y

los riesgos asociados.

Estructura fijada en el estándar:

Identificador único del documento

Introducción y resumen de elementos y características a probar

Elementos software a probar

Características a probar

Características que no se probarán

Enfoque general de la prueba

Criterios de paso/fallo para cada elemento

Criterios de suspensión y requisitos de reanudación

Documentos a entregar

Actividades de preparación y ejecución de pruebas

Necesidades de entorno

Responsabilidades en la organización y realización de las pruebas

Necesidades de personal y formación

Esquema de tiempos

Riesgos asumidos por el plan y planes de contingencias

Aprobaciones y firmas con nombre y puesto desempeñado



7.5 Especificación del Diseño de Pruebas

Especificar los refinamientos necesarios sobre el enfoque reflejado en el plan e

identificar las características que se deben probar con este diseño de pruebas

Identificador único para la especificación. Proporcionar también una

referencia del plan asociado (si existe)

Características a probar de los elementos software (y combinaciones de

características)

Detalles sobre el plan de pruebas del que surge este diseño, incluyendo

las técnicas de prueba específica y los métodos de análisis de resultados

Identificación de cada prueba:

o Identificador

o Casos que se van a utilizar

o Procedimientos que se van a seguir

Criterios de paso/fallo de la prueba (criterios para determinar si una

característica o combinación de características ha pasado con éxito la

prueba o no).

7.6 Especificación de Caso de Pruebas

Definir uno de los casos de prueba identificando por una especificación del

diseño de las pruebas

Identificador único de la especificación

Elementos software (por ejemplo, módulos) que se van a probar: definir

dichos elementos y las características que ejercitará este caso

Especificaciones de cada entrada requerida para ejecutar el caso

(incluyendo las relaciones entre las diversas entradas; por ejemplo, la

sincronización de las mismas)

Especificaciones de todas las salidas y las características requeridas (por

ejemplo, el tiempo respuesta) para los elementos que se van a probar

Necesidades de entorno (hardware, software y otras como, por ejemplo,

el personal)

Requisitos especiales de procedimiento (o restricciones especiales en los

procedimientos para ejecutar este caso).



Dependencias entre casos (por ejemplo, listar los identificadores de los

casos que se van a ejecutar antes de este caso de prueba)

7.7 Especificaciones del Procedimiento de Prueba

Especificar los pasos para la ejecución de un conjunto de casos de prueba o,

más generalmente, los pasos utilizados para analizar un elemento software con

el propósito de evaluar un conjunto de características del mismo.

Identificador único de la especificación y referencia a la correspondiente

especificación de diseño de prueba.

Objetivo del procedimiento y lista de casos que se ejecutan con él.

Requisitos especiales para la ejecución (por ejemplo, entorno especial o

personal especial).

Pasos en el procedimiento. Además de la manera de registrar los

resultados y los incidentes de la ejecución, se debe especificar:

La secuencia necesaria de acciones para preparar la ejecución.

Acciones necesarias para empezar la ejecución.

Acciones necesarias durante la ejecución.

Cómo se realizarán las medidas (por ejemplo, el tiempo de respuesta)

Acciones necesarias para suspender la prueba (cuando los

acontecimientos no previstos lo obliguen).

Puntos para reinicio de la ejecución y acciones necesarias para el reinicio

en estos puntos.

Acciones necesarias para detener ordenadamente la ejecución.

Acciones necesarias para restaurar el entorno y dejarlo en la situación

existente antes de las pruebas.

Acciones necesarias para tratar los acontecimientos anómalos.



8. Ejecución de pruebas de software

Es la identificación y resolución de problemas antes de ponerlos en producción. Para

asegurarse de que sus aplicaciones funcionen y se ejecuten según los requisitos

empresariales en producción, necesita probarlos antes de la implementación. Junto

con pruebas manuales, para la máxima reutilización y eficacia, deben automatizarse

determinados componentes. La ejecución de pruebas le permite detectar y

solucionar problemas de las aplicaciones antes de ponerlas en producción con el

objetivo de que pueda utilizarlas con seguridad. La ejecución de pruebas evalúa la

capa GUI de la aplicación, así como los componentes fundamentales para una

cobertura integral, junto con pruebas de rendimiento para asegurar la calidad

adecuada en producción.

8.1 El proceso de ejecución

Propiamente dicho De acuerdo con el estándar IEEE Std. 829-2008, consta de las

siguientes fases:

Se ejecutan las pruebas cuyos casos y procedimientos han sido ya

diseñados previamente.

Se comprueba si ha habido algún fallo al ejecutar.



Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva

al proceso de depuración o corrección del código.

Se puede deber también a un defecto en el propio diseño de las pruebas.

En ambos casos, las nuevas pruebas o las corregidas se deberán ejecutar.

De no existir fallos, se pasará a la comprobación de la terminación de las

pruebas.

8.2 El proceso de comprobación

Consta de las siguientes fases:

Tras la ejecución, se comprueba si se cumplen los criterios de compleción

de pruebas descritos en el correspondiente plan de pruebas.

En caso de terminar las pruebas, se pasa a la evaluación de los productos

probados sobre la base de los resultados obtenidos (terminación normal).

En caso de no terminar las pruebas se debe comprobar la presencia de

condiciones anormales en la prueba.

Si hubiesen existido condiciones anormales, se pasa de nuevo a la

evaluación; en caso contrario, se pasa a generar y ejecutar pruebas

adicionales para satisfacer cualquiera de las dos terminaciones.

Los criterios de compleción de pruebas hacen referencia a las áreas

(características, funciones, etc.) que deben cubrir las pruebas y el grado de

cobertura para cada una de esas áreas. Como ejemplos genéricos de este

tipo de criterios se pueden indicar los siguientes:

Se debe cubrir cada característica o requerimiento del software mediante

un caso de prueba o una excepción aprobada en el plan de pruebas.

En programas codificados con lenguajes procedurales, se deben cubrir

todas las instrucciones ejecutables mediante casos de prueba.



9.- HERRAMIENTAS PARA LA EJECUCION DE PRUEBAS

Este apartado va dirigido a conocer los beneficios que pueden aportar herramientas

dedicadas a pruebas dentro de la organización. También se verán los riesgos que

suponen el uso de herramientas en las organizaciones.

9.1. Herramientas

9.1.1. E – Tester

Empirix e-Tester es una herramienta de prueba automatizada que forma parte

de la suite de e-test de aplicaciones. Proporciona a los usuarios la capacidad de

crear scripts automatizados de prueba de funcionamiento. Está diseñado para

ser utilizado para probar web, soluciones inalámbricas y aplicaciones

multimedia.

9.1.2 Rational Functional Tester

Rational Functional Tester permite a los testers y a los desarrolladores de GUI

automatizar los testings funcionales y la regresión de aplicaciones Java, .NET y

basadas en Web.

Esta herramienta de testing automatizada es la mejor de su clase para los

testings funcionales y la regresión de aplicaciones Java, Microsoft Visual

Studio .NET y basadas en web.

Ofrece a los testers avanzados una selección de idiomas de script y un

editor de solidez, Java en Eclipse o Microsoft Visual Basic .NET en Visual

Studio .NET, para la verificación del montaje y la personalización.

Proporciona a los testers con poca experiencia funciones automatizadas

para actividades como, por ejemplo, la generación de pruebas y el

testing dirigido por datos.

Incluye la tecnología ScriptAssure y funciones de coincidencia de patrón

para mejorar la capacidad de recuperación del script de verificación

dado los frecuentes cambios que se producen en la interfaz del usuario

de aplicaciones.

Incorpora soporte para el control de la versión para permitir un

desarrollo paralelo de los scripts de verificación y el uso simultáneo por

parte de equipos distribuidos por el mundo.



Permite la realización de pruebas de aplicaciones creadas con VS.NET

Winforms, J2SE/J2EE, HTML/DHTML, XML, JavaScript y applets de Java e

incluye soporte exclusivo para la biblioteca SWT de Java asociada con el

shell de Eclipse.

Soporta el testing de aplicaciones 3270 (zSeries) y 5250 (iSeries) que

utilizan las aplicaciones basadas en Rational Functional Tester Extension

for Terminal.

Características y Beneficios:

Toda organización que dependa de su propio desarrollo de

aplicaciones para dar servicio a las necesidades de sus clientes o

usuarios internos reconocen que la calidad de las aplicaciones son

un prerequisito para el éxito, no solo una opción.

Un ingrediente crucial para el mismo es tener un proceso de

testing eficiente y disciplinado para verificar que las aplicaciones

hayan alcanzado el nivel de aptitud que cumpla o exceda las

expectativas del proyecto. Los cronogramas imprecisos, los

cambios frecuentes en las interfaces de usuario de la aplicación y

las regresiones recurrentes de las características introducen

variables que las prácticas de testing ad-hoc son incapaces de

manejar. Rational Functional Tester fue creado para cubrir todas

estas necesidades.

Rational Functional Tester es una herramienta avanzada de testing

funcional y de regresión automatizado creada para los

testeadores y los desarrolladores de GUI que necesitan de un

control superior para probar sus aplicaciones Java, Microsoft®

Visual Studio .NET y Web.

9.1.3. Rational Manual Tester

Es una herramienta de ejecución y autorización de pruebas manuales para

testers y analistas de negocio.

Introduce técnicas nuevas de desarrollo para mejorar la velocidad, el

alcance y la fiabilidad de los esfuerzos de pruebas manuales.

Promueve la reutilización de los pasos de pruebas para reducir la

repercusión de los cambios de software realizados en las actividades de

mantenimiento de pruebas.

Proporciona un editor de textos avanzado que soporta adjuntos e

imágenes para mejorar la legibilidad de las pruebas.

http://www.rational.com.ar/herramientas/functionaltesterextension.html

http://www.rational.com.ar/herramientas/functionaltesterextension.html



Facilita la entrada de datos y verificación durante la ejecución de

pruebas para reducir los posibles errores humanos.

Importa pruebas manuales existentes previamente basadas en

Microsoft Word y Excel; exporta los resultados de las pruebas en

archivos basados en CSV para el análisis en las herramientas preferidas

de otros proveedores.

Incorpora los requisitos de equipos exclusivos a través de numerosas

opciones de personalización; permite compartir contenido entre

ubicaciones de pruebas distribuidas.

Gratuito con la adquisición del Rational Functional Tester para ayudar a

los equipos a realizar tanto las pruebas manuales como las

automatizadas.

Características y Beneficios:

Muchas organizaciones les piden a analistas de negocio y testeadores que

validen manualmente la operación del sistema, registrando sus observaciones a

medida que van interactuando con la aplicación. Este proceso de testing manual

puede consumir mucho tiempo y ser propenso a errores, particularmente si la

aplicación experimenta cambios frecuentes. Rational Manual Tester se creó para

resolver este problema.

Es una herramienta para creación y ejecución de tests manuales que promueve

el re-uso de los pasos de test para reducir el impacto del cambio en el software

sobre los testeadores y analistas de negocio.

¿Cómo lo hace?

Rational Manual Tester agrega organización y control a todas las actividades

que están involucradas en el esfuerzo del testing manual, incluyendo:

Creación y modificación del test

Organización y consolidación para miembros del equipo distribuido de

test

Ejecución y colección de resultados del test

Reporte de resultados del test

9.2. Beneficios del uso de herramientas

Realizar el mismo trabajo de manera repetitiva y manualmente puede ser una tarea

tediosa. Las personas tienden a aburrirse y por esa razón aumenta la probabilidad

de que cometan errores al realizar la misma tarea una y otra vez. Este es el caso de

las pruebas de regresión, por ejemplo, donde se introducen los mismos datos de

http://www.rational.com.ar/herramientas/functionaltester.html



prueba una y otra vez, comparando los resultados contra los estándares de

codificación o creando bases de datos de pruebas específicos.

Mediante la utilización de herramientas se puede conseguir reproducir cierto trabajo

previamente realizado, obteniendo resultados consistentes. Esta característica es

especialmente útil para confirmar que un defecto se ha arreglado, o para introducir

datos de entrada a pruebas, por ejemplo.

En ocasiones, si una persona calcula un valor a partir de informes de incidencias, por

ejemplo, puede que omita algo sin darse cuenta o que interprete información de

forma incorrecta (subjetividad). El uso de una herramienta consigue que esa

predisposición a interpretar de forma subjetiva los datos se elimine y de esta forma

la evaluación sea realizada de forma más consistente.

Por otro lado, el tener muchos datos no implica que la información sea comunicada

de la manera correcta ni entendida por las personas interesadas. La información que

se presenta de forma visual es mucho más sencilla de retener e interpretar para la

mente humana por lo que el uso de gráficos es una forma mucho mejor de

comunicar información que una larga lista de números. Existen herramientas de

propósito especial que ofrecen estas funcionalidades de forma directa a partir de la

información que procesan. Algunos ejemplos del uso de gráficos y estadísticas a la

hora de mostrar la información se pueden encontrar en herramientas que permiten

mostrar el progreso de las pruebas, las tasas de incidencias y rendimiento.

En definitiva, los principales beneficios que aporta el uso de herramientas como

medio para llevar a cabo el proceso de pruebas son:

Reducir el trabajo repetitivo

Mejorar la consistencia

Facilitar las evaluaciones objetivas

Facilitar el acceso a información relacionada con pruebas

Además de los beneficios generales que se han descrito, cada tipo de herramienta

ofrece unos beneficios específicos relacionados con el aspecto de las pruebas sobre

el que la herramienta trabaja de forma particular.

9.3. Riesgos del uso de herramientas

Introducir algo nuevo en una organización, en este caso una herramienta, no suele

ser tarea sencilla, ya que siempre habrá problemas técnicos a los que sobreponerse.

El uso por primera vez de una herramienta no siempre se hará de la mejor forma y

consiguiendo los mejores resultados posibles. Es necesario invertir tiempo para



desarrollar métodos a seguir por la organización y así conseguir el máximo

provecho posible de la herramienta.

Otro factor importante que hay que considerar a la hora de hacer uso de

herramientas durante el proceso de pruebas es la habilidad y conocimiento

necesario para realizar buenas pruebas y para usar las herramientas de forma

correcta.

Aunque pueden obtenerse grandes beneficios del uso de herramientas durante el

proceso de pruebas, es necesario tener en cuenta los riesgos que puede acarrear el

uso de herramientas, independientemente de su uso específico. Uno de los más

relevantes es tener expectativas poco realistas de la herramienta. Por ello, es

importante tener claro qué puede hacer la herramienta, y en función de esto

establecer objetivos realistas. Otros riesgos relacionados son:

Subestimación del tiempo, coste y esfuerzo necesario para la introducción

inicial de la herramienta en la organización

Subestimación del tiempo y esfuerzo necesario para conseguir beneficios

significantes y continuos de la herramienta

Subestimación del esfuerzo requerido para mantener los activos de

pruebas generados por la herramienta

Sobre-confianza en la herramienta

9.4. Factores a tener en cuenta para introducir una herramienta en una organización

Para introducir una herramienta en una organización habría que comenzar

trabajando con la organización, más que con la herramienta. Las organizaciones

necesitan estar preparadas para los cambios que supondrá la nueva herramienta. Si,

por ejemplo, las prácticas que sigue una organización al ejecutar las pruebas no son

buenas y la organización no es madura, por lo general sería más eficiente mejorar

dichas prácticas que buscar herramientas que den soporte a este tipo de prácticas.

En ocasiones, se pueden mejorar los propios procesos de la organización de manera

paralela a la inserción de una herramienta que de soporte a dichos procesos. Es

importante tener claro que la herramienta no debería dirigir sino proporcionar

soporte a lo que la organización haya definido.

A la hora de introducir una herramienta en una organización es importante:

Evaluar la madurez de la organización



Identificar las áreas de la organización donde las herramientas puedan

ayudar y dar soporte a los procesos de prueba

Evaluar herramientas contra requisitos claros y criterios objetivos

Planificar la implementación interna de la herramienta

Llevar a cabo una prueba de concepto para comprobar si el producto

funciona como se desea y cumple los requisitos y objetivos definidos. Para

ello se puede utilizar un proyecto piloto.

Los objetivos de un proyecto piloto para una nueva herramienta son aprender más

sobre la herramienta, decidir maneras estándar de usar la herramienta para usuarios

potenciales, ver cómo la herramienta se adapta a los procesos o documentación

existentes y cómo estos procesos deberían cambiar para trabajar bien con la

herramienta y, en definitiva, evaluar el proyecto piloto frente a los objetivos

establecidos.



10.- RECOMENDACIONES PARA LA EJECUCIÓN DE PRUEBAS

El programador debe evitar probar sus propios programas, ya que desea

(consciente o inconscientemente) demostrar que funcionan sin problemas.

Cada caso de prueba debe definir el resultado de salida esperado que se

comparará con el realmente obtenido.

La experiencia parece indicar que donde hay un defecto hay otros, es decir,

la probabilidad de descubrir nuevos defectos en una parte del software es

proporcional al número de defectos ya descubierto.

No deben hacerse planes de prueba suponiendo que, prácticamente, no hay

defectos en los programas y, por lo tanto, dedicando pocos recursos a las

pruebas.

Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder

descubrir posibles síntomas de defectos



11. DOCUMENTACION PARA LA EJECUCIÓN DE PRUEBAS

Durante la ejecución de las pruebas es fundamental conocer el estado del proceso

de prueba, saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué

defectos se han encontrado, etc. Para ello, se crean los registros de pruebas,

Informes de Incidentes e Informe resumen de pruebas.

11.1 Registro de Pruebas (Histórico de Pruebas o Test Log)

Un objetivo fundamental del proceso de prueba es proporcionar información

acerca del sistema que se está probando. El registro de pruebas documenta los

aspectos relativos a la ejecución de las pruebas: qué prueba se han ejecutado,

quién y cuándo los ha ejecutado, en qué orden, en qué entorno, si la prueba ha

pasado o ha fallado.

En este documento es importante también, asociar la información de ejecución

de cada prueba con versiones específicas del software en prueba para

garantizar la trazabilidad. La información recogida en el registro de pruebas

permite conocer el progreso de la fase de ejecución de pruebas y tomar

decisiones acerca de si el software está listo para pasar a la siguiente fase.



11.1.1 Estructura fijada en el estándar (IEEE 829)

A. Identificador

B. Descripción de la prueba: elementos probados y entorno de la prueba

C. Anotación de datos sobre cada hecho ocurrido (incluido el comienzo y el

final de la prueba)

Fecha y hora

Identificador de informe de incidentes

D. Otras Informaciones

11.2 Informe de Incidentes

Hay que resaltar la referencia al término “incidente”; un incidente no tiene

porqué deberse necesariamente a un defecto en el sistema. Un incidente

representa una discrepancia entre los resultados esperados y los resultados

obtenidos. Esta discrepancia puede deberse a varios motivos, como un defecto,

un error en la especificación de los casos de prueba, una mala interpretación de

los requisitos, etc.

El informe de incidentes debe contener toda la información necesaria para la

identificación y resolución del incidente: entradas utilizadas, resultados

esperados, resultados obtenidos, paso del procedimiento en el que se ha

producido el incidente, configuración del entorno, valoración del impacto, etc.


A. Identificador

B. Resumen del incidente

C. Descripción de datos objetivos (fecha/hora, entradas, resultados

esperados, etc.)

D. Impacto que tendrá sobre las pruebas

11.3 Informe de Resumen de Pruebas

El informe final de pruebas se crea en hitos determinados del proyecto o al finalizar

un nivel de pruebas determinado. Permite comunicar a todos los stakeholders los

resultados obtenidos para así decidir si el software está listo para pasar a la siguiente

fase. Este informe proporciona información sobre las pruebas realizadas y el tiempo

consumido, así como valoraciones acerca de la calidad del proceso de prueba

realizado, del nivel de calidad alcanzado en el producto. Este informe final puede

servir como base para planificar mejoras futuras en el proceso de prueba.




A. Identificador

B. Resumen de la evaluación de los elementos probados

C. Variaciones del software respecto a su especificación de

diseño, así como las variaciones en las pruebas

D. Valoración de la extensión de la prueba (cobertura lógica,

funcional, de requisitos, etc.)

E. Resumen de los resultados obtenidos en las pruebas

F. Evaluación de cada elemento software sometido a prueba

(evaluación general del software incluyendo las limitaciones del

mismo)

G. Firmas y aprobaciones de quienes deban supervisar el informe



12. DEPURACION (DEBUGGIN)

12.1 Definición

La depuración es la corrección de errores que sólo afectan a la programación,

porque no provienen de errores previos en el análisis o en el diseño. A veces la

depuración se hace luego de la entrega del sistema al cliente y es parte del

mantenimiento.

En realidad, en las revisiones de código y las pruebas unitarias, encontrar un

error es considerablemente más sencillo, ya que se hace con el código a mano.

Aun cuando se hubiera optado por una prueba unitaria de caja negra, es

sencillo recorrer el módulo que revela un comportamiento erróneo por dentro

para determinar el lugar exacto del error. Existen incluso herramientas de

depuración de los propios ambientes de desarrollo que facilitan esta tarea, que

incluso proveen recorrido paso a paso y examen de valores de datos.

De todas maneras, es importante analizar correctamente si el error está donde

parece estar o proviene de una falla oculta más atrás en el código. Para

encontrar estos casos más complejos son útiles las herramientas de recorrida

hacia atrás, que permiten partir del lugar donde se genera el error y recorrer

paso a paso el programa en sentido inverso.

Las pruebas de integración, de sistema y de aceptación también pueden llevar a

que sea necesaria una depuración, aunque aquí es más difícil encontrar el lugar

exacto del error. Por eso a menudo se utilizan bitácoras, que nos permiten

evaluar las condiciones que se fueron dando antes de un error mediante el

análisis de un historial de uso del sistema que queda registrado en medios de

almacenamiento permanente.



12.2 Pasos para La Depuración

Reproducir el error

Diagnosticar la causa.

Corregirla.

Verificar la corrección.

Si el error no se repite al intentar reproducirlo es muy difícil hacer el diagnóstico.

Como en casi todas las ciencias, se buscan causas y efectos, condiciones

necesarias y suficientes para que se produzca el error. Luego hay que buscar el

sector del código donde se produce el error, lo que nos lleva a las

consideraciones hechas recientemente.

La corrección del error entraña mucho riesgo, porque a menudo se introducen

nuevos errores. Y nunca hay que olvidarse de realizar una nueva verificación

después de la corrección.

Recomendaciones y

Conclusiones



RECOMENDACIONES

1. No deben hacerse planes de prueba suponiendo que, prácticamente,

no hay defectos en los programas y, por lo tanto, dedicando pocos

recursos a las pruebas.

2. El programador debe evitar probar sus propios programas, ya que

desea (consciente o inconscientemente) demostrar que funcionan sin

problemas.

3. Se debe inspeccionar a conciencia el resultado de cada prueba, así,

poder descubrir posibles síntomas de defectos.

4. Cada caso de prueba debe definir el resultado de salida esperado.

5. Al generar casos de prueba, se deben incluir tanto datos de entrada

válidos y esperados como no válidos e inesperados

6. La experiencia parece indicar que donde hay un defecto hay otros, es

decir, la probabilidad de descubrir nuevos defectos en una parte del

software es proporcional al número de defectos ya descubierto.

7. Las pruebas son una tarea tanto o más creativa que el desarrollo de

software. Siempre se han considerado las pruebas como una tarea

destructiva y rutinaria.



CONCLUSIONES

En conclusión , este trabajo demuestra que la verificación y validación son procesos

importantes para el desarrollo de software con calidad, y que una adecuada verificación del

producto durante etapas de vidas del software puede detectar errores en el producto

entregado, y una adecuada validación comprueba que el producto de software vaya de

acorde a los estándares del mercado.

El objetivo principal de la Verificación y Validación es la seguridad de que el sistema está

hecho para un propósito específico y cumpliendo con los requisitos que el cliente necesita.

Dentro de la verificación y validación existen dos conceptos complementarios tales como:

Inspecciones de software y Pruebas de software

Las inspecciones de software, descubren errores que pueden estar ocultos a la vista, una

inspección también puede considerarse como atributos de calidad más amplios de un

programa tales como el grado de cumplimiento con los estándares de portabilidad y

mantenibilidad.

Las Pruebas de software, son básicamente un conjunto de actividades dentro del desarrollo

de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas

en cualquier momento de dicho proceso de desarrollo.

También deducimos que la planificación de las pruebas está relacionada con el

establecimiento de estándares para el proceso de pruebas, no solo con la descripción de los

productos de las pruebas. Los planes de pruebas además de ayudar con los gestores a

asignar recursos y estimar el calendario de las pruebas, son de utilidad para los ingenieros

del software implicados en el diseño y la realización de las pruebas de sistema. Estos ayudan

al personal técnico a obtener una panorámica general de las pruebas del sistema y ubicas

su propio trabajo en este contexto.

En el caso del ciclo de vida de pruebas de software puede tener distintas interpretaciones

pero siempre es importante tener los 4 puntos mencionados: Planear, Hacer, Verificar y

Actuar; es de suma importancia identificar que diseño de casos de prueba debemos usar en

una determinada área del software y depende del criterio de los encargados del testeo,

aunque las recomendaciones es que estos sean distintos de los que codificaron se mantiene.

Con respecto a las herramientas de ejecución de pruebas podemos ver que aunque se han

desarrollado miles de herramientas de soporte, todas han limitado su éxito a entornos muy

concretos, sólo sirviendo para el producto para el que se desarrollaron.

Y por último, durante la ejecución de las pruebas es fundamental conocer el estado del

proceso de prueba, saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué

defectos se han encontrado, etc. Para ello, se crean los registros de pruebas, Informes de

Incidentes e Informe resumen de pruebas.

Referencias

Bibliográficas

BIBLIOGRAFIA

Análisis de los procesos de verificación y validación en las organizaciones

software. – Universidad Carlos III de Madrid

Pressman, R. (2005): Ingeniería del Software: Un Enfoque Práctico. 6º Edición.

McGraw-Hill. (Capítulos 13 y 14)

SWEBOK - Guide to the Software Engineering Body of nowledge, 2004.

(Capítulos 4 y 5) - http://www.computer.org/portal/web/swebok

http://materias.fi.uba.ar/7507/content/20101/lecturas/documentacion_pruebas.p

df

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r56673.PDF

http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba

s/HTML%20-%20Pruebas%20de%20software/node20.html







©2003-2009, Rational Performance Tester Tutorial. Manual de Rational

Performance Tester. Editado por Ben Smith andLaurie Williams. 26 de Agosto de

2007. http://agile.csc.ncsu.edu/SEMaterials/tutorials/rpt/index.html#section8_0

(último acceso: Junio de 2012).

Acuña, Cesar Javier. Pruebas de Software. Universidad Rey Juan Carlos, s.f.

ARQUISOFT, Grupo. Editado por Emilio Barrios. Johanna Rojas. 2007.


s/HTML%20-%20Pruebas%20de%20software/node19.html.

Beizer B. Software Testing Techniques. Segunda Edicion. 1990.

Bohem. Graphical Development Process Asistant. USA, 1979.



Cibertec. Pruebas de Software. Cibertec, 2011.

Compatia. «Estudios realizados por Compatia.» Investigacion, USA, 2004.

Fagan. «Design and Code inspections to reduce errors in program

development» IBM Systems Journal, 1976 -1986: 182–211.

Graham Giib 1993.

Grupo Standish. «Resultados del informe CHAOS.» Investigacion 1995.

Guofeng, Yongkui. Ciclo de vida de las pruebas. 2009.

Jose Luis Aristegui O. «Los casos de prueba en la prueba de software.» Revista

Digital Lampsakos, s.f.: 27-34.

Moranda, Jelinski -. Estimation and Prediction for a Simple Software Reliability

Model. USA, 1972.

Oficina de Cuentas del Gobierno Norteamericano, GAO. «Resultados del

Informe.» Investigacion, USA, 1979.

Parnas. «The use of mathematics in software quality assurance.» IEEE Computer

23, 1990: 17-22.

Plattini Velthuis, Mario, Jose A. Calvo Manzano, Joaquin Cervera Bravo, y Luis

Fernandez Sanz. Analisis y Diseño de Aplicaciones Informaticas de Gestión. Ra-

Ma, s.f.

RAE. Diccionario de la Real Academia Española. 23ª. Madrid: RAE, 2010.

Sommerville, Ian. Ingenieria de Software. Septima Edicion. Traducido por Maria

Isabel Alfonso Galipienso. s.f.

Whitaker. 2002.

grupo 6 - procesos de verificacion y validacion en el desarrollo de software

Documents