You are on page 1of 29

FUNDAMENTOS DE PRUEBAS DE SOFTWARE

Pgina 1


1. CALIDAD Y EL SOFTWARE
1.1. Calidad
Definiciones: Podemos encontrar muchas definiciones en los textos de calidad, todas
ellas muy similares:

Propiedad o conjunto de propiedades inherentes a un objeto que permiten
apreciarlo como mejor, igual o peor que otros objetos de su especie [DRAE:
Diccionario de la Real Acadmica Espaola]
Conjunto de propiedades y de caractersticas de un producto o servicio que le
confieren capacidad para satisfacer necesidades expresadas o implcitas. [ISO
8042:1994]
Grado en el que un conjunto de caractersticas inherentes cumple con los requisitos.
[ISO 9000: 2000]

Las definiciones ms completas o formales:

Calidad, significa desarrollar, disear, producir y mantener un producto que
sea el ms econmico, el ms til y siempre satisfactorio para el consumidor.
[Kaoru Ishikawa]

Figura 1.1 Kaoru Ishikawa
Calidad, es la aplicacin de los principios y tcnicas estadsticas en todas las fases
de la produccin, dirigida a la fabricacin ms econmica de un producto
(servicio) que es til en grado mximo y que tiene mercado. [William Edwards
Deming]
PRUEBAS DE SOFTWARE
NOVENO CICLO
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 2


Figura 1.2 William Edwards Deming

Conceptos de Calidad: Segn la UNE 66-001-92 [AENOR, 1992], se define la calidad como:
Totalidad de caractersticas de un producto o servicio que le confieren su aptitud para
satisfacer unas necesidades expresadas o implcitas

La consecucin de la calidad puede tener tres orgenes:

Calidad Realizada: La que es capaz de obtener la persona que realiza el trabajo.
Calidad Programada: La calidad que se ha pretendido obtener.
Calidad Necesaria: La calidad que el cliente exige con mayor o menor grado de
concrecin.





1.2. Calidad en la Ingeniera de Software

Hay que tener en cuenta a la hora de abordar la calidad en el software un conjunto de
caractersticas del mismo que lo hace un producto peculiar:

Se desarrolla, no se fabrica en el sentido clsico del mismo.
Se trata de un producto lgico, sin existencia fsica.
No se degrada con el uso.
Por la complejidad del SW y la ausencia de controles adecuados, se suele
entregar el SW conscientemente con defectos (incluso pblicamente
declarados).
Un gran porcentaje de la produccin se hace an a medida en vez de emplear
componentes existentes y ensamblar.
Es muy flexible. Se puede cambiar con facilidad e incluso reutilizar
fragmentos.

1.3. Calidad del Software

Definicin oficial (IEEE Std. 610-1990) Es el grado con el que un sistema,
componente o proceso cumple:
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 3


Los requisitos especificados.
Las necesidades o expectativas del cliente o usuario.

Concordancia del software producido con los requisitos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo software
desarrollado profesionalmente. [Pressman, 1998]



o Los requisitos establecidos explcitamente se reflejan en el documento de
especificacin de requisitos del sistema:
o Funcionales: funciones a realizar por el software.
o No funcionales (o extendidos): requisitos de seguridad, de rendimiento, etc
o Los requisitos implcitos no aparecen en el documento de especificacin de
requisitos del sistema. Si se cumplen los explcitos y no los implcitos, la calidad
del software queda en entredicho.
o El uso de estndares y las normas de desarrollo permiten que se consiga
una calidad tcnica.


1.4. Aseguramiento de calidad de software (Software Quality Assurance , SQA)
El propsito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar
a la administracin una visibilidad adecuada del proceso utilizado y los productos
construidos mediante acciones planificadas y sistemticas que aseguren la calidad de
dichos procesos y productos.
Por ello, SQA abarca revisar, auditar e informar a la administracin del proyecto sobre la
adherencia de los productos y procesos a los estndares y procedimientos establecidos. El
proceso incluye todas las actividades, mtodos y prcticas para desarrollar o mantener
software y sus productos asociados. El producto comprende el software y todos los
artefactos creados como parte de la definicin, mantencin y uso del proceso de software,
incluyendo especificaciones, descripciones de procesos, planes, procedimientos, cdigo y
documentacin relacionada.
Basndose en lo anterior, los objetivos principales de SQA (Aseguramiento de la Calidad)
son:
1. Planificar las actividades de SQA.
2. Verificar la adherencia de los productos de trabajo y de las actividades a los
estndares, procedimientos y requerimientos establecidos.
3. Informar a los grupos e individuos afectados sobre las actividades de SQA y sus
resultados.
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 4

4. Comunicar a la administracin superior sobre desviaciones no resueltas dentro del
proyecto.
Para alcanzar estos objetivos se requiere comprender la necesidad de un grupo responsable
de SQG (Software Quality Group), las actividades del proceso de SQA, sus tareas a lo largo
del ciclo de vida de un proyecto y su relacin con otras reas de prcticas del desarrollo de
software.
1.4.1. Grupo de SQA
El rol del grupo de SQA es guiar al equipo de desarrollo para alcanzar un producto de alta
calidad. La implantacin de la calidad es responsabilidad de la administracin superior y de
los grupos de desarrollo.
Es ms, la existencia de un grupo de calidad dedicado no garantiza por s sola que los
procesos sean seguidos y que la calidad se introduzca mgicamente en el producto. Debe
existir un compromiso de toda la organizacin por orientarse hacia una cultura de calidad.
Dentro de las actividades de este grupo destacan:
Preparar el Plan de SQA para cada proyecto
Participar en el desarrollo de la descripcin del proceso de software para un proyecto.
Revisar las actividades de ingeniera en acuerdo con el proceso definido.
Auditar los productos de trabajo designados, para verificar su adherencia con aquellos
definidos en el modelo de proceso.
Asegurar que las desviaciones en el desarrollo y en los productos de trabajo sean
documentadas y apoyadas por el procedimiento de documentacin.
Registrar cualquier disconformidad e informar a la administracin superior.
Coordinar la gestin de configuracin.
Apoyar la recoleccin y anlisis de mtricas de software.
1.4.2. Actividades del proceso de Aseguramiento de la calidad de software
SQA se define como un conjunto de actividades planificadas y sistemticas, cuyo primer
objetivo es evaluar la calidad y la adherencia de los productos de software a los estndares,
procesos y procedimientos.
Estndares

Revisiones

Prueba

Anlisis de defectos

Gestin de Configuracin
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 5



1.4.3. Tcnicas de Aseguramiento de la calidad de software
El aseguramiento de la calidad aborda principalmente tres reas o tcnicas:
1. Mtricas del software: para el control del proyecto
2. Verificacin y validacin: a lo largo del ciclo de vida del software, incluyendo
pruebas y procesos de revisin.
3. Gestin de la configuracin del software

A. Mtricas del software
Por trmino general, para la evaluacin de la calidad, es ms habitual centrarse en
medidas del producto que en medidas del proceso.
Una mtrica es una asignacin de un valor a un atributo (tiempo, complejidad, etc.) de una
entidad software, ya sea un producto (cdigo) o un proceso (pruebas). Dentro de las
mtricas de las caractersticas del software se puede clasificar de la siguiente manera:
Clasificacin 1:
Mtricas de producto.
Mtricas de proceso.
Clasificacin 2:
A) Mtricas basadas en atributos internos del producto:
Medidas de estructuracin de un programa.
Mtricas de complejidad.
Mtricas de cobertura de pruebas.
Mtricas de calidad del diseo.

B) Mtricas basadas en atributos externos del producto:
Mtricas de portabilidad.
Mtricas de defectos.
Mtricas de usabilidad.
Mtricas de mantenibilidad.
Mtricas de fiabilidad.

C) Mtricas basadas en cdigo fuente:
N de lneas de cdigo.
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 6

N de lneas de comentario.
N de instrucciones.
Densidad de documentacin.

D) Mtricas basadas en estructura de diseo:
Relacionadas con el control intramodular.
Relacionadas con el acoplamiento entre clases.

E) Mtricas para sistemas orientados a objetos:
Acoplamiento.
Herencia.
Cohesin.
B. Verificacin y validacin
Verificacin y validacin es el proceso de garantizar que un diseo cumple con los
requisitos.
La verificacin confirma que los productos reflejan los requisitos especificados para
cada caso concreto, garantizando que desarroll el producto correctamente.

La validacin confirma que el producto final se ajustar al uso pretendido,
garantizando que desarroll el producto correcto.


C. Gestin de la configuracin de software
Es un conjunto de actividades diseadas para identificar y definir los elementos en el sistema que
probablemente cambien, controlando el cambio de estos a lo largo del ciclo de vida, estableciendo
relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos
elementos, y auditando e informando de los cambios realizados.

2. MODELOS DE CALIDAD DE SOFTWARE
2.1. Estructura De Un Modelo De Calidad De Software
Tienen una estructura, por lo general, en tres niveles:


Factores de Calidad
Mtricas del Producto
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 7





Figura 2.1. Estructura de un Modelo de Calidad Del Software
Factores de Calidad: Es el nivel ms alto de la jerarqua, representa la calidad
desde un punto de vista del usuario. Son las caractersticas que componen la
calidad. Se les llama Atributos de Calidad Externos.
Criterios de Calidad de un Producto: Cada uno de los factores se descomponen en
un conjunto de Criterios de Calidad. Cuando estn presenten contribuyen al
aspecto de la calidad. Se les llama Atributos de Calidad Internos.
Mtricas del Producto: Para cada uno de los Criterios de Calidad se definen un
conjunto de Mtricas, que son medidas cuantitativas de ciertas caractersticas del
producto que, cuando estn presentes, dan una indicacin del grado en que dicho
producto posee un determinado atributo de calidad.
2.2. Modelos de Calidad del Software
2.2.1. Modelos de Calidad del Software a nivel proceso
A. Modelo CMMI (Capability Maturity Model Integration)
Bsicamente el CMMI son normas para calidad enfocada al mundo del Software.
Estas se aplican a los diferentes procesos que hay que llevar a cabo para lograr
producir software con calidad, es muy importante mencionar que igual que las
normas ISO 90003, este modelo nos dice que hay que hacer, y no como hay que
hacerlo.
El modelo CMMI permite:

Describir los componentes del modelo y sus relaciones.
Comprender las reas de proceso.
Localizar informacin relevante en el modelo.
Aplicar los conocimientos a su entorno de trabajo y en un equipo de
evaluacin de componentes y sus relaciones de un modelo.

Modelo Escalonado
Se representa mediante niveles o escalones para calificar la madurez de una
organizacin.

Niveles de Madurez:
Definen 05 niveles

Nivel 1: Inicial
Criterios de Calidad de un
Producto
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 8


Nivel 2: Gestionado

Nivel 3: Definido

Nivel 4: Cuantitativamente Gestionado

Nivel 5: Optimizado




Modelo Continuo
Enfoca las actividades de mejora y evaluacin en la capacidad de los diferentes
procesos, el cual es medido en diferentes niveles de capacidad.

Niveles de Capacidad
Definen 06 Niveles

Capacidad 0: Incompleto

Capacidad 1: Realizado

Capacidad 2: Gestionado

Capacidad 3: Definido

Capacidad 4: Gestionado Cuantitativamente

Capacidad 5: Optimizado


B. Modelo ISO/IEC 15504 Spice

El modelo ISO/ IEC 15504, utiliza una gua para la evaluacin de proyectos, que
envuelve la medicin de un proceso, este mtodo de medicin plantea uso de
Mtricas de calidad, la administracin de datos (incluyendo datos histricos), y el
manejo de mtricas en la organizacin, su principal objetivo es la generacin de
mtricas de proceso y de producto para dar soporte a la planificacin efectiva y as
mejorar la calidad de los productos, Este engloba un modelo de referencia para los
procesos y sus potencialidades sobre la base de la experiencia de compaas
grandes, medianas y pequeas.

Niveles de Madurez

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 9

Nivel 0: Organizacin Inmadura

Nivel 1: Organizacin Bsica:

Nivel 2: Organizacin Gestionada

Nivel 3: Organizacin Establecida

Nivel 4: Organizacin Predecible

Nivel 5: Organizacin Optimizada




C. Modelo IT MarK
Es un servicio internacional de certificacin que estudia los procesos tcnicos y de
negocio, diseado especialmente para PYMES del sector Ti, para medir el
reconocimiento de Excelencia en Tecnologas de la Informacin. Tambin
podemos decir que es un servicio clave diseado para PYMES, que las ayuda a
posicionarse a travs de la Mejora Continua con sostenibilidad.
.
Niveles IT Mark

I.T. Mark

I.T. Mark Premium

I.T. Mark Elite

2.2.2. Modelos
A. Modelo de McCall
La calidad de un sistema, aplicacin o producto es tan buena como los requisitos
que describen el problema, el diseo que modela la solucin, el cdigo que
conduce a un programa ejecutable y las pruebas que ejercitan el software para
detectar errores. Un buen Ingeniero del Software utiliza mediciones que evalan la
calidad del anlisis y los modelos de diseo, el cdigo fuente y los casos de prueba
que se han creado al aplicar la Ingeniera de Software. Para lograr estas
evaluaciones de la calidad en tiempo real, el Ingeniero debe utilizar medidas
tcnicas que evalan la calidad con objetividad, no con subjetividad. Hace 25 aos
se definieron factores de calidad como los primeros pasos hacia el desarrollo de
mtricas de calidad del software.

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 10

El modelo de McCall se basa en 11 factores de calidad, que se organizan de la
siguiente:

Visin del Usuario Factores de Calidad Segn McCall
Operacin del Producto Facilidad de Uso Integridad Correccin
Confiabilidad Eficiencia.
Revisin del Producto Facilidad de Mantenimiento Facilidad de Prueba
- Flexibilidad
Transicin del Producto Reusabilidad Interoperabilidad - Portabilidad
Tabla 1. Visin del Usuario respecto a los Factores de Calidad del Modelo de
McCall




Operacin del Producto
Requiere que el software pueda ser entendido fcilmente, que opere
eficientemente y que los resultados obtenidos sean los requeridos
inicialmente por el usuario.

Revisin del Producto
Tiene como objetivo realizar revisiones durante el proceso de desarrollo para
detectar los errores que afecten a la operacin del producto.

Transicin del Producto
Requiere de la definicin de estndares y procedimientos que sirvan como
base para el desarrollo de software.


B. Modelo de Boehm

Este modelo es el ms conocido y representado por Barry Boehm en 1978
este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al
nivel general de calidad.

I. Caractersticas de Alto Nivel

Las caractersticas de alto nivel representan requerimientos generales de
uso, pueden ser:

Utilidad per-se cuan (usable, confiable, eficiente) es el producto en s
mismo.
Mantenibilidad cun fcil es modificarlo, entenderlos y retestearlo.
Utilidad general si puede seguir usndose si se cambia el ambiente.
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 11


II. Caractersticas de Nivel Intermedio

Las caractersticas de nivel intermedio representan los factores de
calidad de Boehm:

Portabilidad (utilidad general).
Confiabilidad (utilidad per-se).
Eficiencia (utilidad per-se).
Usabilidad (utilidad per-se).
Testeabilidad (mantenibilidad).
Facilidad de entendimiento (mantenibilidad).
Modificabilidad o flexibilidad (mantenibilidad).
III. Caractersticas Primitivas

El nivel ms bajo corresponde a caractersticas directamente
asociadas a una o dos mtricas de calidad:

A. DE PORTABILIDAD

B. DE EFICIENCIA

C. DE USABILIDAD

D. DE TESTEABILIDAD

E. DE ENTENDIBILIDAD

F. DE MODIFICABILIDAD

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 12

C. Modelo ISO 9126

El estndar 9126 propone un modelo de calidad que se divide en tres vistas: interior,
exterior y de uso. Estas estn compuestas por caractersticas, las que se dividen en
sub caractersticas

I. Caractersticas de Calidad Internas y Externas

En ISO 9126 se reconocen seis factores de calidad que se pueden considerar tanto
internos como externos.

A. FUNCIONALIDAD

B. CONFIABILIDAD

C. EFICIENCIA

D. USABILIDAD

E. MANTENIBILIDAD

F. PORTABILIDAD


II. Caractersticas de Calidad de Uso

En ISO 9126 se reconocen cuatro factores de calidad de uso.

Eficiencia
Productividad
Satisfaccin
Seguridad










Figura. Caractersticas de Vista de Uso (Calidad de Uso)

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 13

3. VERIFICACIN Y VALIDACIN

3.1. Definiciones de Verificacin y Validacin:

La verificacin y la validacin no son lo mismo, aunque a menudo se confunden.
Boehm expres la diferencia entre ellas de la siguiente manera:
- Verificacin: Se est construyendo el producto de la manera correcta?
- Validacin: Se est construyendo el producto correcto?
A. DEFINICIN DE VERIFICACIN:
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.
B. DEFINICIN DE VALIDACIN:
Dar fuerza o firmeza a algo, hacerlo vlido. Es el proceso que se realiza para revisar si un
determinado producto es el que el usuario necesita.
3.2. Objetivo De La Verificacin Y Validacin
El objetivo es establecer la seguridad de que el sistema es lo suficientemente bueno para su
uso predeterminado. Ayuda en la toma de decisiones con respecto a cundo hay que dejar
de probar y liberar el software.
3.3. Tcnicas De Verificacin Y Validacin
Existen 2 Tcnicas de Verificacin y Validacin:
Tcnicas dinmicas, tambin conocido como prueba o Experimentacin.
Tcnicas estticas, tambin conocido como Anlisis.
I. TECNICAS DINMICAS (PRUEBA, EXPERIMENTACIN)
Concepto
Se realiza durante la ejecucin del software, y comprueba dinmicamente su
comportamiento; Para ello introducen una serie de valores de entrada, y examinan la salida
comparndola con los resultados esperados.


FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 14

Clasificaciones de las tcnicas dinmicas









Figura 3.2: clasificaciones de las tcnicas dinmicas.
a) Basadas en la especificacin: Son conocidas como tcnicas de pruebas de caja negra o
conducida por entradas/salidas, porque tratan el software como una caja negra con
entradas y salidas, pero no tienen conocimiento de cmo est estructurado el programa.
A continuacin, se detallarn las tcnicas basadas en la especificacin ms comunes.
Particionamiento de equivalencia
Anlisis de valor frontera
Una tabla de decisin
Las pruebas de transicin de estados
Los casos de uso
b) Basadas en la estructura: Las pruebas estructurales son una aproximacin al diseo de
casos de prueba donde las pruebas se derivan a partir del conocimiento de la estructura e
implementacin del software. Esta aproximacin se denomina a veces pruebas de caja
blanca.
Pruebas de sentencia
Pruebas de decisin
Pruebas de caminos

c) Basadas en la experiencia: Las tcnicas basadas en experiencia son aquellas a las que se
recurre cuando no hay una especificacin adecuada desde la que crear casos de prueba
basados en especificacin, ni hay tiempo suficiente para ejecutar la estructura completa
del paquete de pruebas.
Adivinar errores: Las tcnicas basadas en experiencia usan la experiencia de los usuarios y
de los tcnicos de pruebas.
Pruebas exploratorias: Tcnicas de pruebas ms sofisticadas que se realizan sobre la base
del conocimiento y experiencia de los tcnicos de pruebas;

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 15

II. TCNICAS ESTTICAS (ANLISIS)
Concepto
Analizan y comprueban las representaciones del sistema tales como el documento de
requerimientos, diagramas de diseo y cdigo fuente del programa. Puede usarse en todas
las etapas del proceso. La mayora de las tcnicas estticas son tcnicas de verificacin que
pueden probar cualquier tipo de documentacin ya sea cdigo fuente, o documentacin y
modelos de diseo, o especificacin funcional o de requisitos.
Clasificacin de las tcnicas estticas

Las revisiones: son una tcnica esttica que consiste en realizar un anlisis de un documento
con el objetivo de encontrar y eliminar errores.
No existe una revisin perfecta, sino que cada una tiene un propsito distinto durante las
etapas del ciclo de vida del documento. Los principales tipos de revisiones se describen a
continuacin:

Informal: Dar un borrador de un documento a un colega para que lo lea es el ejemplo ms
simple de revisin. Es una forma de conseguir beneficios (limitados) a un bajo costo ya que
no siguen ningn proceso formal a seguir.
Walkthrough: Un walkthrough se caracteriza porque el autor del documento bajo revisin
va guiando al resto de participantes a travs del documento exponiendo sus ideas para
conseguir un entendimiento comn y recoger respuestas.
Revisin tcnica: Una revisin tcnica es una reunin que se centra en conseguir consenso
sobre el contenido tcnico de un documento, por lo que es posible que sea dirigida por un
experto tcnico.
Inspecciones: La inspeccin es el tipo de revisin ms formal. El documento bajo
inspeccin es preparado y validado minuciosamente por revisores antes de la reunin, se
compara el producto con sus fuentes y otros documentos, y se usan listas de
comprobacin. En la reunin de la inspeccin, se registran los defectos encontrados y se
pospone toda discusin para la fase de discusin. Todo esto hace que la inspeccin sea
una reunin muy eficiente.









FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 16

4. OBJETIVOS Y RESTRICCIONES

4.1. Objetivos de Las Pruebas
Las pruebas presentan una interesante anomala para el ingeniero del software.
Durante las fases anteriores de definicin y de desarrollo, el ingeniero intenta construir el
software partiendo de un concepto abstracto y llegando a una implementacin tangible. A
continuacin, llegan las pruebas. El ingeniero crea una serie de casos de prueba que
intentan demoler el software construido. De hecho, las pruebas son uno de los pasos de la
ingeniera del software que se puede ver como destructivo en lugar de constructivo.
(Pressman, 2005)
Algunos objetivos de las pruebas de software de acuerdo a Pressman (2002) son:
La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.
Una prueba tiene xito si descubre un error no detectado hasta entonces.
En general los objetivos de las pruebas de software es disear pruebas que
sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor
cantidad de tiempo y de esfuerzo.
4.2. Limitaciones de las Pruebas de Software

Algunas de las limitaciones existentes a nivel de pruebas de software son:
No existe una recopilacin formal que especifique y describa los tipos de prueba que se
deben aplicar a una pieza de software y se detalle la implementacin precisa de cada uno de
ellos. Aunque existen algunos documentos, en su mayora son de carcter muy acadmico y
poco prctico. Por otro lado, y aunque ISO plantea en normas como la ISO/FDIS 9126 ciertos
aspectos en los cuales el producto de software debe ser conforme, no es suficientemente
especifico.

Figura 4.2: estndar internacional
Las tcnicas de pruebas generalmente son subestimadas como tiles, en tanto que no se
usan en la prctica para el diseo de casos de prueba formales. En general y en entornos
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 17

productivos, las tcnicas utilizadas para la deteccin de errores son del tipo suposicin de
errores y en el mejor de los casos de tipo aleatorio el cual por sus caractersticas propias no
es un mtodo que aporte mucho a la deteccin de errores en el producto de software.
Los estndares y modelos planteados en torno al aseguramiento de la calidad de los
productos de software por su carcter de universales y genricos son muy poco especficos
a la hora de describir la forma de realizar implementaciones en entornos productivos reales;
en la mayora de los casos la generalidad es una de sus principales caractersticas. Esto
permite que su aplicacin en diversos ambientes sea posible, pero limita las prcticas a
realizar puesto que deben ser diseadas en su detalle por la organizacin, lo cual en muchos
casos exige un conocimiento experto y asesoras externas que hacen a una compaa
aferrarse a una prctica con un conjunto de particularidades que no siempre son las
mejores.
Tomando en cuenta que una organizacin debe estar basada en un modelo de calidad que
permita un tratamiento global de los procesos, y que adicionalmente deben existir un
conjunto de estndares, reglas, prcticas y normativas extras no especificadas en el modelo
aplicado a la misma, es importante comentar la inexistencia casi total de una descripcin
formal que encierre en conjunto un modelo de calidad, un modelo de pruebas, una
metodologa y unas prcticas especficas en pruebas de software que sean concordantes
entre si y entre las polticas generales de un modelo de calidad determinado; en cambio de
ello toda la informacin est desagregada mediante modelos y estndares.
Adicionalmente por ser modelos de calidad orientados a la madurez de los procesos y los
productos, los periodos de tiempo necesarios para que la madurez llegue a un nivel
deseable son relativamente largos, lo cual conlleva a que aunque se logren avances en la
calidad de los productos paulatinamente se logra la madurez, solo se empieza a tener un
esfuerzo ms proporcional al beneficio cuando todo el proceso es idealmente maduro y la
organizacin logra converger hacia las prcticas que plantea el modelo de calidad general
implantado.
Los estndares diseador por la ISO especficamente el ISO/FDIS 9126, ISO 14598 e
ISO/IEC 15504 presentan un nivel de complejidad variable al momento de ser usados de
acuerdo a la organizacin en donde se desee implantar, sin embargo, una caracterstica
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 18

anexa, es que aunque es posible su establecimiento en una organizacin que no cuenta de
antemano con un modelo de calidad ya preestablecido, lo recomendable y casi requisito no
especificado, es que si lo exista, ya que dichos estndares exigen elementos como proceso
definidos, polticas de aseguramiento de la calidad claras, y prcticas que lleven a la
madurez entre otras para cumplir sus propios objetivos. Lo ms comn es tener modelos de
calidad y de mejoramiento continuo como ISO 9000 y CMMI con el fin de que la aplicacin
de estndares de aseguramiento de calidad exigentes como los mencionados tengan
elementos suficientes como para que su adhesin a los procesos organizacionales sea
exitosa.
La razn por la cual la industria no adopta metodologas y estndares es la dificultad de la
utilizacin de estos para pruebas de software. En las pequeas y medianas empresas la
dificultad radica en la necesidad que estas tienen de competir mediante tiempos y precios y
dada la poco practicidad que los estndares tienen asociados se incurre en consumos de
recursos poco tolerables; por otra parte las grandes compaas adems de los factores
anteriores, compiten mediante calidad y para lograr un buen indicador deben implementar
los diferentes metodologas y estndares que garanticen la madurez de los procesos, para
estas compaas la falta de practicidad de los estndares en ms un requisito de sus clientes
que un riesgo asociado al uso de recursos.






Implementar un proceso de pruebas al interior de una compaa es costoso, adems el
proceso debe madurar para que se adapte a las necesidades especficas de la organizacin;
este hecho obliga a muchas empresas a subcontratar los procesos de pruebas. En ocasiones
esta es una buena opcin puesto que evita posibles sesgos en las pruebas pero en general
Figura 4.3: usos de metodologas
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 19

puede conllevar serios problemas al interior de la organizacin que van desde la
confidencialidad de la informacin hasta el incremento de los tiempos de desarrollo.
Las pruebas de software ms complejas basan su diseo y su ejecucin en los artefactos
desarrollados en etapas de anlisis y diseo; si estos artefactos no son construidos o tienen
deficiencias como falta de consistencia y coherencia; aparte de afectar todo el proceso de
desarrollo se ver comprometido el aseguramiento de la calidad y dentro de est las
pruebas los tipos de pruebas de software que buscan hallar defectos ms profundos. La
buena ingeniera de software se convierte en una necesidad bsica para el correcto
desarrollo
de las pruebas de
software.






Figura 4.4: Diferencia con respecto al proceso de desarrollo y el proceso de pruebas
En general los problemas que se encuentran en un proceso de pruebas son:
- Los probadores desconocen el dominio o los tipos y tcnicas a utilizar cuando se requieren
pruebas de alto nivel, en general este problema se da al tener personal poco capacitado
para la labor.
- Los proveedores de pruebas generalmente posponen la labor de pruebas a las etapas
finales del ciclo de vida del software, lo que ocasiona problemas por retrasos. Estos
retrasos se dan generalmente por que el equipo de pruebas debe adquirir el conocimiento
del dominio necesario y disear las pruebas, tareas que se pueden realizar de forma
transversal al proceso de desarrollo optimizando los recursos disponibles.



FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 20









Figura 4.5: problemas o Retrasos en las pruebas de software
- En ocasiones los probadores no cuentan con los insumos necesarios para realizar un
proceso de pruebas maduro y completo. Estos insumos corresponden a una buena
documentacin y a un completo y correcto levantamiento de requisitos, que orienten al
probador, tanto en la ejecucin y desarrollo de las pruebas como en el aprendizaje del
dominio.
- Muchas organizaciones contemplan su proceso de QA basado en las pruebas de software
lo cual trae perjuicios en la calidad de los productos al no incluir procesos como medicin,
anlisis, verificacin y validacin, todos ellos componentes esenciales de QA.}







4.3. Errores por la Falta de Pruebas de Software
Apagn de 2003 en Norteamrica
Priv de electricidad a un estimado de 50 millones de personas. El apagn se debi a un
error en el software de monitoreo basado en Unix de General Electric, que impidi que los
operadores se dieran cuenta de un corte local de energa. El efecto domin de la falla afect
a ocho estados de Estados Unidos y a Ontario, en Canad.



FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 21






Figura 4.6: Apagn en EE.UU
Therac-25
Estuvo envuelta en al menos seis accidentes entre 1985 y 1987, en los que los pacientes
recibieron sobredosis masivas de radiacin, de aproximadamente cien veces la dosis
esperada. Tres de los seis pacientes murieron como consecuencia directa. Estos accidentes
remarcaron los riesgos del control por software de sistemas de seguridad crtica, y estos se
convirtieron en un caso de estudio tpico de la informtica mdica y la ingeniera de
software.







Figura 4.7: mquina de radioterapia


5. PLANIFICACIN
5.1. Planificacin
La planificacin de la calidad es el proceso en el cual se desarrolla un plan de calidad para un
proyecto. El plan de calidad define la calidad de software deseado y describe como valorar
sta. Por lo tanto, define lo que es software de alta calidad. Sin sta definicin, los
diferentes ingenieros pueden trabajar en direcciones opuestas para optimizar los atributos
del proyecto.
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 22

El plan de calidad selecciona los estndares organizacionales apropiados para un producto y
un proceso de desarrollo particulares. Si el proyecto utiliza nuevos mtodos y herramientas,
se tienen que definir nuevos estndares.
5.2. Plan de Prueba.
El plan de prueba es un documento con un abordaje sistemtico para la prueba de sistemas
como hardware o software. Generalmente consiste en un modelado detallado del flujo de
trabajo durante el proceso.
El plan de prueba es uno de los ocho documentos descritos en la IEEE 829, una norma que
especifica la forma y el conjunto de artefactos en la prueba de software. En consonancia con
ella, la estructura del plan de prueba consiste de una serie de secciones descritas a
continuacin.
5.2.1. Caso de Prueba.
En la ingeniera del software, los casos de PRUEBA o Test Case son un conjunto de
condiciones o variables bajo las cules el analista determinar si el requisito de una
aplicacin es parcial o completamente satisfactorio.
Estructura de los Casos de Pruebas
I. Introduccin/visin general: Contiene informacin general acerca de los Casos de
Prueba.
Identificador: Es un identificador nico para futuras referencias, por ejemplo,
mientras se describe un defecto encontrado.
Caso de prueba dueo/creador: Es el nombre Del analista o diseador de pruebas,
quien ha desarrollado pruebas o es responsable de su desarrollo.
Versin: La actual definicin del caso de prueba.
Nombre: El caso de prueba debe ser un ttulo entendible por personas, para la fcil
comprensin del propsito del caso de prueba y su campo de aplicacin.
Identificador de requerimientos el cual est incluido por el caso de prueba. Tambin
aqu puede ser un identificador de casos de uso o de especificacin funcional.
Propsito: Contiene una breve descripcin del propsito de la prueba, y la
funcionalidad que chequea.
Dependencias: Indica qu otros subsistemas estn involucrados y en qu grado.
II. Actividades de los Casos de Pruebas.
Ambiente de prueba/configuracin: Contiene informacin acerca de la
configuracin del hardware o software en el cul se ejecutar el caso de prueba.
Inicializacin: Describe acciones, que deben ser ejecutadas antes de que los casos
de prueba se hayan inicializado. Por ejemplo, debemos abrir algn archivo.
Finalizacin: Describe acciones, que deben ser ejecutadas despus de realizado el
caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el
analista debe restaurarla antes de que otro caso de prueba sea ejecutado.
Acciones: Pasos a realizar para completar la prueba.
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 23

Descripcin de los datos de entrada
III. Resultados.
Salida esperada: Contiene una descripcin de lo que el analista debera ver tras
haber completado todos los pasos de la prueba.
Salida obtenida: Contiene una breve descripcin de lo que el analista encuentra
despus de que los pasos de prueba se hayan completado.
Resultado: Indica el resultado cualitativo de la ejecucin del caso de prueba, a
menudo con un Correcto/Fallido.
Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal.
Evidencia: En los casos que aplica, contiene un link al print de pantalla (screenshot)
donde se evidencia la salida obtenida.
Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al defecto
implicado se debe enumerar en esta columna. Contiene el cdigo correlativo del
defecto, a menudo corresponde al cdigo del sistema de tracking de bugs que se
est usando.
Estado: Indica si el caso de prueba est: No iniciado, En curso, o terminado.
6. MTRICAS Y MEDICIONES

Las revisiones son el mtodo ms utilizado para validar la calidad de un proceso o de un
producto. Involucran a un grupo de personas que examinan todo o una parte del proceso
del software.

Las revisiones de la calidad son caras. Si se hace durante la etapa de desarrollo, consumen
tiempo e inevitablemente retrasan la entrega del software. Idealmente, sera
posible acelerar el proceso de revisin utilizando herramientas que procesarn el diseo de
software o el programa e hiciesen valoraciones automticas del software. Estas
valoraciones permitirn comprobar que el software evaluado tiene un umbral de calidad
requerido.

6.1. Medicin del Software

Las mediciones de software se utilizan para recoger datos cuantitativos acerca del
software y sus procesos.

La medicin del software se refiere a derivar un valor numrico desde algn atributo del
software o del proceso del software. Comparando estos valores entre s y con los
estndares aplicados en la organizacin, es posible sacar conclusiones sobre la calidad del
software o de los procesos para desarrollarlo.

Las mediciones de software pueden realizarse para:

o Hacer predicciones generales acerca del sistema: Haciendo mediciones de las
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 24

caractersticas de los componentes del| sistema y reuniendo stas, podremos
derivar una estimacin general de algunos atributos del sistema, como el nmero
de fallos.

o Identificar componentes anmalos: Mediante las mediciones podemos identificar
los componentes que se salgan de lo normal. Por ejemplo podemos identificar los
de complejidades ms altas, los cuales suponemos que tendrn ms errores,
para centrarnos en ellos en el proceso de revisin.

Los pasos claves para el proceso de medicin son:

Seleccionar las medidas a realizar.
Seleccionar los componentes a evaluar.
Medir las caractersticas de los componentes.
Identificar las mediciones anmalas
Analizar los componentes anmalos


6.2. Mtricas de Software

Una mtrica de software es cualquier tipo de medida relacionada con un sistema, proceso
o documentacin de software. Algunos ejemplos son las medidas que se utilizan para
calcular el tamao de un producto en lneas de cdigo.

Los valores de las mtricas de software recogidas se utilizan para hacer inferencias de la
calidad del producto o proceso.


Las mtricas pueden ser:
Mtricas de control, generalmente asociadas a los procesos.

Mtricas de prediccin, asociadas a los productos.

Ambas pueden influir en la toma de decisiones de gestin.


FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 25





























Figura 6.2 Mtricas de prediccin y control.




Ejemplo de las mtricas de control o de procesos son el esfuerzo y tiempo promedio
requeridos para reparar los defectos encontrados.

Ejemplo de mtricas de prediccin o de producto son la complejidad ciclomtica de un
mdulo, la longitud media de los identificadores de un programa, y el nmero de atributos
y operaciones asociadas con los objetos de un diseo.

Las mtricas del producto se refieren a las caractersticas del software mismo, estas
mtricas se dividen en dos clases:

o Mtricas dinmicas, que son recogidas por las mediciones hechas en un programa
en ejecucin.

o Mtricas estticas, que son recogidas por las mediciones hechas en las
representaciones del sistema como el diseo, el programa o la documentacin.

Estas diferentes mtricas estn relacionadas con diversos atributos de calidad. Las
mtricas dinmicas ayudan a valorar la eficiencia y fiabilidad de un programa. Las
mtricas estticas ayudan a valorar la complejidad, la comprensin y
mantenibilidad de un sistema de software.


FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 26

Frecuentemente, es imposible de medir los atributos de software directamente. Los
atributos de calidad como la mantenibilidad, la comprensin y la usabilidad son atributos
externos que nos dicen cmo ven el software los desarrolladores y los usuarios. Estos se
ven afectados por diversos factores y no existe un camino simple para medirlos. Ms
bien es necesario medir atributos internos del software y suponer que existe una
relacin entre lo que queremos medir y lo que queremos saber.


6.3. Panorama de las Mtricas del Producto.
Aunque se proponen una amplia variedad de taxonomas mtricas, el siguiente esquema
atiende las reas ms importantes de las mtricas:

Mtricas para el modelo de anlisis.

Mtricas para el modelo de diseo.

Mtricas para el cdigo fuente.

Mtricas para pruebas.


6.3.1. Mtricas para el Modelo de Anlisis.

Estas mtricas examinan el modelo del anlisis con la intencin de predecir el tamao del
sistema resultante. El tamao es, en ocasiones (pero no siempre), un indicador de la
complejidad del diseo y casi siempre resulta un indicador de un mayor esfuerzo de
codificacin, integracin y prueba.


Estas mtricas incluyen:

o Funcionalidad entregada: proporciona una medida indirecta de la
funcionalidad que se empaqueta en el software.

o Tamao del sistema: mide el tamao general del sistema, definido desde el punto
de vista de la informacin disponible como parte del modelo de anlisis.

o Calidad de la especificacin: proporciona una indicacin de la
especificidad o el grado en que se ha especificado la especificacin de requisitos.

6.3.2. Mtricas para el Modelo de Diseo.

Muchos expertos argumentan que se necesita ms experimentacin antes que emplear las
mediciones de diseo. Sin embargo un diseo sin medicin es inaceptable.

Mtricas arquitectnicas: proporcionan un indicio de la calidad del diseo
FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 27

arquitectnico.

Mtricas a nivel de componente: miden la complejidad de los
componentes del software y de sus caractersticas que impactan la calidad.
Mtricas de diseo de interfaz: se concentran principalmente en la facilidad
de uso.

Mtricas especializadas en diseo orientado a objetos:
6.3.3. Mtricas para el Cdigo Fuente.

Mtricas de Halstead: controversiales pero fascinantes, estas mtricas
proporcionan medidas nicas de un programa de cmputo.

Mtricas de complejidad: miden la complejidad lgica del cdigo fuente
(Esta se consideran mtricas de diseo a nivel de componentes).

Mtricas de longitud: proporcionan un indicio del tamao del software.

6.3.4. Mtricas para Pruebas.

En general, quienes aplican las pruebas, deben depender de las mtricas de anlisis, diseo
y cdigo como gua para el diseo y ejecucin de los casos de prueba.

Mtricas de cobertura de instrucciones y ramas: lleva al diseo de casos de prueba
que proporcionan cobertura del programa.

Mtricas relacionadas con los defectos: se concentran en encontrar defectos y
no en las propias pruebas.

Efectividad de la prueba: proporcionan un indicio en tiempo real de la
efectividad de las pruebas aplicadas.

Mtricas en el proceso: mtricas relacionadas con el proceso que se
determinan a medida que se aplican las pruebas.

6.4. Anlisis de las Mediciones.

Uno de los problemas con la recogida de datos cuantitativos en el software y en los
proyectos de software es comprender lo que significan realmente los datos. Es fcil
malinterpretar los datos y hacer inferencias incorrectas. Las mediciones se deben de
analizar cuidadosamente para comprender lo que realmente significan.

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 28

7. PROCESOS DE V & V EN EL DESARROLLO
DE SOFTWARE

7.1. Actividades de Verificacin

Revisiones tcnicas, walkthroughs e inspecciones de software.

Comprobar que los requerimientos de software son trazables a los requerimientos
del usuario.
Comprobar que los componentes del diseo son trazables a los requerimientos
del software.

Pruebas unitarias.
Pruebas de integracin
Pruebas del sistema.
Pruebas de aceptacin
Auditoria.


7.2. V&V Prevencin y eliminacin de fallos




Fallo: defecto (ya sea hardware o software) dentro de un sistema o de usuario o
procedimiento.

Error: la desviacin detectada a partir de la especificacin de requisitos.

Fracaso: incapacidad software de componentes para realizar una funcin determinada (ya
sea prdida de funcin o mal funcionamiento)

Causas de fallos:

Requisitos SW son incorrectos, incompletos o ambiguos, por ejemplo, no
controlada estados o condiciones ambientales no controladas, no conformidad en
el software o deficiencias en el cdigo (que provocan fallos de software)

Requisitos de SW no se han aplicado, validado y verificado adecuadamente.

SW no se ha probado suficientemente o se ha probado inadecuadamente.

FUNDAMENTOS DE PRUEBAS DE SOFTWARE


Pgina 29

Defectos de software:

Software se utiliza incorrectamente.

Mal diseo o implementacin.

Eventos raros puede llevar a estados no controlados.

Procesos gestin de fallos.

Tcnicas de prevencin de fallos se puede utilizar en cualquier ingeniera o actividades de
desarrollo para evitar fallas.

Tcnicas de tolerancia a fallos son mecanismos directos que se implementado en
el diseo y el cdigo con el fin de tolerar fallos.

Para verificar que las tcnicas de tolerancia estn siendo utilizados como diseado
para, fallas tcnicas de remocin se necesitan: desviacin detectada especificacin
de requisitos

You might also like