GRUPO 6 - Procesos de Verificacion y Validacion en El Desarrollo de Software
Transcript of 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
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.
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.
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
Calidad de Software Ing. Alonso Morales Loayza
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 19 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 20 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 21 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 22 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 23 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 24 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 25 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 26 -
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?
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 27 -
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?
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 28 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 29 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 30 -
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.).
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 31 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 32 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 33 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 34 -
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).
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 35 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 36 -
- 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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 37 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 38 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 39 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 40 -
- 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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 41 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 42 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 43 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 44 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 45 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 46 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 47 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 48 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 49 -
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).
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 50 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 51 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 52 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 53 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 54 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 55 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 56 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 57 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 58 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 59 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 60 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 61 -
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.
11.2.1 Estructura fijada en el estándar (IEEE 829)
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 62 -
11.3.1 Estructura fijada en el estándar (IEEE 829)
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 63 -
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software - 64 -
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
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software 66
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software 67
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
http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba
s/HTML%20-%20Pruebas%20de%20software/node21.html
http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba
s/HTML%20-%20Pruebas%20de%20software/node22.html
http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba
s/HTML%20-%20Pruebas%20de%20software/node23.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.
http://200.69.103.48/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Prueba
s/HTML%20-%20Pruebas%20de%20software/node19.html.
Beizer B. Software Testing Techniques. Segunda Edicion. 1990.
Bohem. Graphical Development Process Asistant. USA, 1979.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software 70
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.
Calidad de Software Ing. Alonso Morales Loayza
Procesos de Verificación y Validación en el Desarrollo de Software 71