TECNOLOGICO DE ESTUDIOS SUPERIORES DE

COACALCO

ING. EN SISTEMAS COMPUTACIONALES








VALIDACION Y VERIFICACION

UNIDAD 2: PRUEBAS









ndice

2.1 Tipos de pruebas ............................................................................................... 3
2.2 Coberturas de las pruebas ................................................................................ 5
2.3 Preparacin de las pruebas ............................................................................... 7
2.5 Criterios para la realizacin de pruebas ............................................................ 8
2.6 Plan de pruebas (verificacin y validacin) ....................................................... 8
2.7 Estructura de los casos de prueba .................................................................. 10
2.8 Conceptos generales de los diseos de las pruebas (verificacin y validacin)
.............................................................................................................................. 10
2.9 Reporte y seguimiento de errores ............................................................... 11
2.10 Informe de las pruebas ................................................................................ 12
2.11 Fuentes de informacin de QA para el control estadstico o mtrico ............ 14
2.13 Importancia de la calidad, mtricas y control estadstico............................... 15
Conclusiones ......................................................................................................... 16
Referencias ........................................................................................................... 16













2.1 Tipos de pruebas

Existen dos tipos diferentes de prueba, que se utilizan en las diferentes etapas de
desarrollo del software:
Las pruebas de defectos: Pretenden encontrar las inconsistencias entre un
programa y su especificacin. Estas inconsistencias se deben habitualmente a los
fallos o defectos en el cdigo del programa. Las pruebas se disean para revelar la
presencia de defectos en el sistema, ms que para evaluar su capacidad
operacional.
Las pruebas estadsticas: se utilizan para probar el desempeo y la fiabilidad del
programa y comprobar cmo trabaja bajo condiciones operacionales. Las pruebas
se disean para reflejar las entradas de los usuarios y su frecuencia.
Despus de llevar a cabo las pruebas, se puede hacer una estimacin de la
fiabilidad operacional del sistema contando el nmero de cadas observadas en el
sistema. La capacidad del programa se valora midiendo el tiempo de ejecucin y el
tiempo de respuesta del sistema cuando procesa los datos estadsticos de la
prueba.
No existe una separacin clara entre estos dos tipos de pruebas. Durante las
pruebas de defectos los desarrolladores obtienen una visin intuitiva de la fiabilidad,
y durante las pruebas estadsticas, se descubren obviamente muchos fallos.
El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema
software antes de entregar el producto.
--Una prueba de defectos exitosa es aquella que descubre un fallo, esto es, un
comportamiento contrario a la especificacin.
--Las pruebas de defectos demuestran la existencia de un fallo, y no la ausencia de
cualquier fallo.
Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de
casos de prueba. Se deben establecer polticas para establecer esos casos de
prueba. Por ejemplo:
--Que todas las instrucciones del programa se ejecuten al menos una vez
--Se deben probar todas las funciones del sistema que se acceden a travs de
men.

--Si la entrada es introducida por el operador, todas las funciones deben probarse
con entradas correctas e incorrectas.
Pruebas funcionales (Caja negra) Las pruebas funcionales o de caja negras
es una poltica de seleccin de casos de pruebas basado en la especificacin del
componente o programa.
Las pruebas se seleccionan en funcin de la especificacin y no de la estructura
interna del software.
Las pruebas funcionales o de caja negra son una estrategia para seleccionar las
pruebas de fallos basndose en las especificaciones de los componentes y
programas, y no del conocimiento de su implementacin. El sistema se considera
como una caja negra cuyo comportamiento slo se puede determinar estudiando
las entradas y de contrastarlas con las respuestas que proporciona el sistema.
Pruebas estructurales (Caja blanca) En las pruebas estructurales las pruebas
se seleccionan en funcin del conocimiento que se tiene de la implementacin del
mdulo.
Se suelen aplicar a mdulos pequeos. El probador analiza el cdigo y deduce
cuntos y qu conjuntos de valores de entrada han de probarse para que al menos
se ejecute una vez cada sentencia del cdigo. Se pueden refinar los casos de
prueba que se identifican con pruebas de caja negra.
Pruebas de integracin Se prueban la respuesta de grupos de mdulos
interconectados a fin de detectar fallos resultantes de la interaccin entre los
componentes.
Las pruebas de integracin se realizan con referencia a las especificaciones del
programa.
La principal dificultad de las pruebas de integracin es la localizacin de los fallos.
Para facilitar la deteccin de los errores se utilizan tcnicas incrementales.
--Una vez que se han probado los componentes individuales del programa, deben
integrarse para crear un sistema parcial o completo. En el proceso de integracin
hay que probar el sistema resultante con respecto a los problemas que surjan de
las interacciones de los componentes.
--Las pruebas de integracin se desarrollan a partir de la especificacin del sistema
y se inician tan pronto como estn disponible versiones utilizables de algunos
componentes del sistema.

2.2 Coberturas de las pruebas

Uno de los principales problemas a la hora de realizar las pruebas de un sistema es
el gran nmero de casos de prueba necesarios para obtener una seguridad de que
el sistema bajo prueba funciona correctamente, o con otras palabras, tener un
conjunto de casos de prueba con la calidad suficiente para estar seguros que el
programa bajo prueba funciona correctamente.
Un criterio de cobertura se puede entender segn M. Broy et al. Con dos significados
diferentes:
- Como un criterio de adecuacin, el cual sirve para determinar cundo un conjunto
de casos de prueba tiene la calidad suficiente, por lo que el sistema bajo prueba
que probado correctamente
- Como un criterio de seleccin el cual nos sirve para aadir casos de prueba nuevos
a nuestro conjunto de casos de prueba y de esta manera mejorar la calidad del
mismo.
Ambos significados dan la idea de que los criterios de cobertura son interesantes
para medir la calidad de los conjuntos de casos de prueba. Dentro del mbito de las
pruebas de caja blanca, las cuales tienen en cuenta la estructura interna del
programa bajo prueba para comprobar el correcto funcionamiento del mismo, los
criterios de cobertura se pueden clasificar en base a los siguientes tres aspectos:
Los criterios estructurales se usan para medir la calidad de un conjunto de casos de
prueba. Esta calidad se mide en funcin del porcentaje alcanzado en funcin del
criterio que se haya escogido. Como su propio nombre indica, estos criterios s
definen en base a la estructura del programa bajo prueba, por ejemplo, si tenemos
una mquina de estados, un criterio estructural podra definirse en funcin de los
estados de la misma o en funcin de las transiciones. Una clasificacin bastante
aceptada de los diferentes criterios de cobertura para las pruebas de caja blanca,
es clasificar estos criterios en dos grandes grupos: criterios basados en el flujo de
control y criterios basados en flujo de datos.
Criterios de cobertura basados en el flujo de control este tipo de criterios estn
basados en las expresiones lgicas introducidas en la especificacin del sistema
bajo prueba que determinan cuando existen saltos o bucles dentro de la
implementacin, en otras palabras, se basa en las condiciones de las estructuras If-
THENELSE y los LOOP que existe dentro de la implementacin del sistema. Los
criterios de cobertura de este tipo ms usados son los siguientes:

El criterio de cobertura de sentencias, es el criterio ms simple de todos, define
que han de recorrerse todas las lneas o sentencias del cdigo del programa al
menos una vez.
El criterio de cobertura de decisiones o cobertura de ramas expuesto por primera
vez en requiere que cada posible valor (verdadero o falso) que pueda tomar cada
una de las decisiones del sistema bajo prueba se d al menos una vez, sabiendo
que una decisin es un conjunto de condiciones relacionadas mediante operadores
lgicos (and, or) y una condicin es un conjunto de expresiones algebraicas
relacionadas con operadores relacionales (<, <=, >, >=).
El siguiente criterio es la cobertura de condiciones, el cual requiere que cada
condicin de cada decisin tome todos los posibles valores al menos una vez.
Siguiendo con el ejemplo anterior, en este caso necesitaramos dos casos de
prueba, uno que evale A Falso y B verdadero y otro A Verdadero, y B Falso. A
pesar de que este criterio es ms restrictivo que el anterior no alcanza la cobertura
de decisiones, ya que en el ejemplo siempre se evaluara a falso la decisin y nunca
se ejecutara S.
EL siguiente criterio de cobertura que soluciona los problemas de los dos anteriores,
es el criterio de cobertura de condicin decisin, el cual requiere que cada posible
valor de cada condicin de cada decisin del programa es producida al menos una
vez y que adems se produzca cada posible valor de cada decisin. Siguiendo el
ejemplo anterior para este criterio nos bastara con tener dos casos de prueba, uno
que evaluase A falso y B falso y otro que evaluase A verdadero y B verdadero. De
esta manera si un conjunto de casos de prueba cumple este criterio va a cumplir
todos los criterios expuestos anteriormente.
Criterios de cobertura basados en el flujo de datos este tipo de criterios de
cobertura se basa en el anlisis de los flujos de los datos. Aqu se requiere que los
casos de prueba ejecuten secuencias de instrucciones en las cuales se asignen
valores a variables y posteriormente se usen esos valores. Para definir estos
criterios de cobertura hay que definir previamente lo que es el grafo de control
asociado al sistema bajo prueba. Este grafo est compuesto por una serie de nodos
en los cuales se representan secuencias lineales de instrucciones y una serie de
enlaces que representan trasferencias de control entre los nodos, de manera que a
cada enlace se asocia una expresin booleanas que contiene la condicin
correspondiente a la trasferencia de control. El criterio de cobertura de todas las
definiciones, se basa en que para cada variable exista al menos un caso de prueba
de manera que este ejecute las instrucciones del sistema para que se recorra un
camino en el grafo de control del sistema en el cual se defina la variable y al menos
se use una vez. Este criterio de cobertura no es muy rigoroso porque podemos tener
conjuntos de casos de prueba que dejen sin probar muchos usos de las variables.
Para solucionar ese problema existe el criterio de cobertura de todos los usos, en
cual se basa en que para cada variable existan dentro del conjunto de casos de

prueba, suficientes casos de prueba para que se recorran los caminos del grafo de
control del sistema en los que se defina la variable y se alcancen todos los usos de
dicha, es decir, que se ejecuten en el mismo caso de prueba la definicin junto con
los usos de la variable y en el caso de que no se puedan cubrir todos los usos con
un nico caso de prueba, aadir ms casos reprueba que cubran siempre la
definicin de la variable hasta que se cubran todos los usos de dicha variable. Este
criterio a pesar de que cubre todos los usos de las variables tiene el problema de
que existe la posibilidad de que a cada uso se pueda llegar desde varios caminos
diferentes, porque puede ser que existan errores que se den solo llegando desde
un camino concreto y no sean detectados por el conjunto de casos de prueba.
Para solucionar el problema presentado anteriormente surge el criterio de
cobertura de caminos definicin/uso, el cual se basa en recorrer todos los
caminos posibles desde la definicin hasta el uso de una variable, para todos los
usos de una variable y para todas las variables. Este criterio de cobertura es muy
costoso de conseguir y adems existe un problema con los bucles ya que estos
introducen la posibilidad de que existan caminos infinitos.
2.3 Preparacin de las pruebas

A la hora de realizar este tipo de pruebas, es imposible probar una clase con todas
sus posibilidades, ya que es impracticable probar todos los nmeros enteros para
un mtodo que recibe un entero como parmetro, por ejemplo. Con lo cual,
necesitamos criterios para elegir el conjunto de casos de prueba ptimos, de
manera que podamos saber si el conjunto de casos de prueba tiene calidad o no.
Un caso de prueba est bien elegido si cumple lo siguiente:
- Reduce el nmero de casos necesarios para que las pruebas sean de una calidad
razonable. Esto implica que el caso ejecute el nmero mximo de posibilidades de
entrada diferentes para as reducir el total de casos.
- Cubre un conjunto extenso de otros casos posibles, es decir, indica algo acerca
de la ausencia o la presencia de defectos en el conjunto especfico de entradas, as
como de otros conjuntos similares.
En este tipo de pruebas existen algunas tcnicas y criterios que nos pueden ayudar
a seleccionar el conjunto de casos de prueba ptimo, las cuales se podran adoptar
para medir la calidad, aunque no han sido desarrolladas para ese fin, sino para
seleccionar un conjunto de valores de prueba ptimo.




2.5 Criterios para la realizacin de pruebas

Criterios de cobertura a parte de los criterios mencionados anteriormente existen
otros criterios de cobertura que se suelen usar la prctica como: la cobertura de
funciones, que se verifica cuando se han ejecutado todas las funciones del sistema
bajo prueba; la cobertura de llamadas, que se verifica cuando se cubren todas las
llamadas a funciones que existen en el programa bajo prueba y la cobertura de
tablas, que se verifica cuando se han hecho referencia a todos los elementos de
las tablas
En definitiva, estos criterios de cobertura pueden ser tiles para medir la clida de
los casos de prueba, siempre teniendo en cuenta que hablamos de pruebas de caja
blanca y tenemos acceso al cdigo del programa bajo prueba.
Cuando no hay acceso al cdigo del sistema, todos los criterios expuestos
anteriormente no se pueden usar, por lo que la calidad de las pruebas va a venir
dada por los valores de prueba. As, para medir la calidad tendremos que fijarnos
en la clida de los valores que usen los casos de prueba.
Criterios de cobertura para los valores de las pruebas con estos criterios, viene
a medirse el grado en que los diferentes valores interesantes seleccionados con
una de las tcnicas expuestas anteriormente o manualmente se utilizan en la batera
de casos de prueba, ya que aunque seleccionemos valores de prueba de calidad
para ejecutar las pruebas, las diferentes combinaciones de estos valores van a
influir en la calidad final del conjunto de casos de prueba. El criterio de cobertura
de cada uso (each-use, o 1-wise) es el ms simple y el que menos calidad aporta
al conjunto de casos de prueba. Se satisface cuando cada valor interesante de cada
parmetro se incluye, al menos, en un caso de prueba, As, mediante las tcnicas
expuestas anteriormente podramos seleccionar como buenos valores de prueba 0,
1 y 2 para cada uno de los parmetros correspondientes a cada uno de los lados
del tringulo. Un conjunto de casos de prueba que satisface el criterio 1-wise estara
formado por los casos de prueba que ejecutara los valores siguientes: (0, 1, 2), (2,
0, 1) y (1, 2, 0) sobre la funcionalidad descrita.
2.6 Plan de pruebas (verificacin y validacin)

Proporcionan un plano o gua para el desarrollador del software, para la
organizacin de control de calidad y para el cliente. Es una gua que describe los
pasos a llevar a cabo como parte de la prueba, cundo se deben planificar y realizar
esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir., por lo tanto,

cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el
diseo de los casos de prueba, la ejecucin de las pruebas y la agrupacin y
evaluacin de los datos resultantes.
Etapas de un plan de pruebas
especificar los objetivos de las pruebas.
determinar con precisin los criterios a seguir en su realizacin.
Integrar al personal y los elementos necesarios para el desarrollo de las
pruebas.
Aplicacin de la prueba o pruebas segn los criterios seleccionados.
evaluacin de los resultados y consideraciones para llevar a cabo una nueva
serie de pruebas.
Un enfoque estratgico para la prueba del software
Generalmente se proporciona una plantilla para la prueba con las siguientes
caractersticas generales:
--La prueba comienza en el nivel de mdulo y trabaja "hacia fuera", hacia la
integracin de todo el sistema basado en computadora. Se usa el enfoque bottom-
up.
--En diferentes momentos se utilizarn diferentes tcnicas de prueba
--La prueba la lleva a cabo el que desarrolla el software y (para grandes proyectos)
un grupo de prueba independiente.

Figura 2: proceso de plan de pruebas

2.7 Estructura de los casos de prueba

Existen mltiples tcnicas para medir o asegurar la calidad de un conjunto de casos
de prueba, como las mediciones de cobertura que alcanzan las pruebas, la cantidad
de fallos encontrados por la pruebas, sin embargo, todas estas tcnicas, que son
estudiadas en las siguientes secciones, no contribuyen con sus mediciones a la
evaluacin de la calidad del conjunto de casos de prueba en el marco de un modelo
de calidad propiamente dicho, sino que simplemente son intentos de mejorar la
calidad de forma prctica.
De hecho no existe un modelo de calidad propiamente dicho para los conjuntos de
casos de prueba, de manera que solo se podra aplicar el modelo presentado en la
ISO 9126, adaptndolo convenientemente a las caractersticas del software
referente al conjunto de casos de prueba.
2.8 Conceptos generales de los diseos de las
pruebas (verificacin y validacin)

Pruebas de la estructura de control
La prueba de condicin se centra en encontrar errores en condiciones lgicas en un
mdulo, aunque tambin puede detectar errores adicionales en el programa.
En una condicin se pueden dar los siguientes errores:
Error de operador lgico
Error en una variable lgica.
Error en una condicin simple o compuesta.
Error en un operador relacional.
Error en una expresin aritmtica.
La prueba de flujo de datos selecciona caminos de prueba de un programa de
acuerdo con la ubicacin de las definiciones y los usos de las variables del
programa.
La prueba de bucles es una tcnica de prueba de caja blanca que se centra
exclusivamente en la validez de las construcciones de condiciones. Hay cuatro tipos
de estructuras de control: simples, concatenadas, anidadas y no estructuradas. De
acuerdo al tipo de estructura es la prueba que se aplicar.
Pruebas de caja negra
Mtodos de prueba basados en grafos

Particin equivalente
Anlisis de valores lmites
Prueba de comparacin
Este tipo de prueba se centra en los requisitos funcionales del software y
permite obtener entradas que prueben todos los requisitos funcionales del
programa. Con este tipo de pruebas se intenta encontrar:
Funciones incorrectas o ausentes.
Errores de interfaz
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores de rendimiento.
Errores de inicializacin y terminacin.
Prueba de comparacin
Esta tcnica consiste en la comparacin de salidas de un mismo software
pero de sus diferentes versiones.
2.9 Reporte y seguimiento de errores
Quien crea la entrada puede ser un desconocido al proyecto los reportes de fallos y
las solicitudes de caractersticas provienen tanto de los usuarios como de los
desarrolladores. Una vez enviada, la entrada entra en un estado llamado abierto
porque ninguna accin ha sido tomada aun. Algunos gestores etiquetan las nuevas
entradas como sin verificar o como sin iniciar. No est asignada a nadie, o en
algunos sistemas, es asignada a un usuario fantasma que representa la falta de una
asignacin real. Llegado a este punto, la entrada se encuentra en el rea de espera:
ha sido registrada, pero a un no ha sido integrada en la conciencia del proyecto.
1. Otros leen la entrada, aaden comentarios y quizs soliciten el
esclarecimiento de algunos puntos a quien realizo la entrada.
2. El fallo es reproducido. Este puede que sea el momento ms importante en
su ciclo vital, ya que incluso que el fallo a un no ha sido resuelto, el hecho de
que alguien haya podido reproducirlo adems de quien creo la entrada
prueba que es genuino y, no menos importante, confirma al creador de la
entrada que ha contribuido al proyecto reportando un fallo real.
3. El fallo es diagnosticado: su causa es identificada, y si es posible, es
estimado el esfuerzo requerido para repararlo. Hay que asegurarse de que
todo esto es registrado en la entrada, ya que en el case en que quien haya
hecho el diagnostico abandona el proyecto (lo cual sucede a menudo con
desarrolladores voluntarios), alguien ms debe ser capaz de continuar con
su trabajo.

2.10 Informe de las pruebas

Informes de Verificacin
Documento Se genera un documento Informe de Verificacin
Unitaria por cada prueba unitaria que se realice al
sistema.
Creado por Las personas que ejecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea
de verificacin, que detalla los errores encontrados
para que puedan ser corregidos.
Fecha de liberacin Ser liberado luego de cada verificacin unitaria.
[Indique la versin y la fecha de liberacin de todas
las versiones de este informe.]

Documento Se genera un documento Informe Consolidacin
por cada consolidacin que se realice al sistema.
Creado por Las personas que ejecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea
de consolidacin, que detalla los errores
encontrados para que puedan ser corregidos.
Fecha de liberacin Ser liberado luego de cada consolidacin.
[Indique la versin y la fecha de liberacin de todas
las versiones de este informe.]

Documento Se genera un documento Informe de Verificacin
de Integracin por cada prueba de integracin que
se realice al sistema.
Creado por Las personas que ejecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea
de verificacin, que detalla los errores encontrados
para que puedan ser corregidos.
Fecha de liberacin Ser liberado luego de cada verificacin de
integracin. [Indique la versin y la fecha de
liberacin de todas las versiones de este informe.

Documento Se genera un documento Informe de Verificacin
de Sistema por cada prueba de sistema que se
realice.
Creado por Las personas que ejecutan las pruebas.
Para quien Es el retorno para los implementadores de la tarea
de verificacin, que detalla los errores encontrados
para que puedan ser corregidos.
Fecha de liberacin Ser liberado luego de cada verificacin de sistema.
[Indique la fecha de liberacin de este informe.]
Evaluacin de la verificacin
Documento Se genera un documento Evaluacin de la
verificacin por cada prueba que se realice al
sistema. Este documento contiene las fallas
encontradas en el sistema, la cobertura de la
verificacin realizada y el estado del sistema.
Creado por El Responsable de verificacin, que toma como
fuente de su trabajo los Informes de verificacin.
Para quien Es el resumen de la tarea de verificacin y es el
retorno para todo el equipo de trabajo del estado del
sistema.
Fecha de liberacin Ser liberado luego de cada verificacin, unitaria,
de integracin y de sistema.
[Indique la versin y la fecha de liberacin de todas
las versiones de este informe.
Documento El documento Informe final de verificacin es el
resumen de la verificacin final del sistema antes de
que sea liberado al entorno del usuario.
Creado por El Responsable de verificacin, que toma como
fuente de su trabajo los Informes de verificacin.
Para quien Indica el estado del sistema.
Fecha de liberacin Ser liberado luego de la verificacin final del
sistema.





2.11 Fuentes de informacin de QA para el control
estadstico o mtrico

Elementos de medida.
Medir es asignar nmeros o smbolos a los atributos de una entidad de acuerdo a
unas reglas definidas para caracterizar los atributos. Segn esto tenemos los
siguientes elementos de medida:
Entidades, que deben de ser objeto de inters
Atributos, que son las caractersticas de las entidades
Reglas, que determinan la asignacin de valores a los atributos.
Mtrica, es el establecimiento de un patrn que se utiliza de referencia para las
medidas que tengan relacin de homogeneidad con l. De esta manera se puede
aceptar un convenio que permita definir la distancia entre dos elementos.
Entidades y Atributos.
Algunos ejemplos de entidades pueden ser:
Productos Procesos Recursos
Actividades Organizaciones Entornos
Pero entidades tambin pueden ser un conjunto de otras entidades. Por ejemplo,
un proceso software puede contener a muchos subprocesos, y cada uno de ellos
estar produciendo, transformando o transmitiendo productos asociados. De la
misma manera, estos productos ms atmicos, los subprocesos, y sus elementos
de datos son en s mismo entidades que determinadas organizaciones pueden
desear caracterizar. Los atributos son caractersticas o propiedades de las
entidades. De la misma manera que un coche puede describirse por su longitud,
nmero de puertas, cilindrada, velocidad mxima o consumo, en definitiva atributos,
las entidades software pueden definirse por atributos tales como tamao, coste,
tiempo, esfuerzo consumido, tiempo de respuesta, nmero de transacciones por
unidad de tiempo, nmero de defectos encontrados, etc. La habilidad debe estar en
saber que atributos deben usarse para obtener medidas que proporcionen datos
tiles.
Cada entidad est acompaada por algunos atributos que la caracterizan y por
medidas que pueden ser usadas para cuantificar los atributos.

Entidades
de
Recursos
Atributos Medidas posibles
Personal
asignado
Tamao del equipo

Nmero de personas
asignadas
Experiencia Aos de experiencia
en programacin
Perfil profesional Nombre del perfil
profesional (Jefe de
proyecto, Analista,
Programador)
Herramient
as CASE
Tipo

Es usada ?
Nombre del tipo

Si/No
Tiempo Fecha comienzo,
Fecha fin

Duracin
Fechas del calendario

Das (laborables o de
calendario).
Figura 6: Ejemplos de medidas de recursos

Escalas de Medida las escalas de medida proporcionan valores y unidades para la
descripcin de los atributos. Por ejemplo: un proyecto software puede producir
30.000 lneas de cdigo, tener una duracin planificada de 12 meses y usar 10.000
horas de esfuerzo para su desarrollo. Cada una de esas observaciones ha sido
cuantificada con un valor a partir de una escala que se supone est bien definida.
Cualquiera que sea la medida y su forma, siempre requiere de una escala bien
definida para la captura y registro de los resultados de medida.
2.13 Importancia de la calidad, mtricas y control
estadstico

Las medidas de los procesos y los productos, y por tanto los datos que de ellas se
derivan, deben estn orientadas a demostrar la adecuacin y la eficiencia del
sistema de gestin de la calidad de la organizacin. Del anlisis de estos datos
podrn encontrarse oportunidades de mejora, que junto con otras fuentes de
informacin como resultados de auditoras, polticas de calidad de la organizacin,

etc. darn lugar a la puesta en marcha de acciones correctivas o preventivas en el
intento de mejorar continuamente la eficacia del sistema de gestin de calidad.
La figura 9 muestra un Sistema de Gestin de la Calidad basado en los procesos,
tal como se define en ISO 9000:2000. Podemos observar cmo los procesos de
medidas, anlisis y mejora, son una parte integrada dentro del conjunto de procesos
de la organizacin.
Conclusiones

En este trabajo nos damos cuenta que tan importante son la pruebas en el desarrollo
de software ya que si en ellas el software a realizar llevara bastantes errores, son
de suma importancia, si se realizan este tipos de pruebas se podrn corregir los
errores encontrados a tiempo, y de igual forma poder corregirlo.
Referencias
capacitacion y guia para el desarrollo del software. (s.f.). Obtenido de
http://materias.fi.uba.ar/7548/PruebasSoftware.pdf
Mateo, P. R. (s.f.). Master en tecnologas informticas avanzadas . Obtenido de http://alarcos.inf-
cr.uclm.es/doc/cmsi/trabajos/Pedro%20Reales.pdf
software. (s.f.). Obtenido de
http://www.historianaval.cl/publico/publicacion_archivo/publicaciones/2_4.pdf