Competencia:

Reconocer la importancia de las pruebas para

lograr la calidad del software identificando los
conceptos claves de pruebas de software.

UNIDAD 1. FUNDAMENTOS DE
PRUEBAS
1.1. Introduccin.
1.2. Las pruebas como un proceso.
1.3. Definiciones bsicas.
1.4. Principios para las pruebas del software.
1.5. El rol del ingeniero de pruebas.
1.6. Origen de los defectos.
1.6.1. Defectos en los requerimientos y la especificacin.
1.6.2. Defectos en el diseo.
1.6.3. Defectos en el cdigo.
1.7. Defectos en las pruebas

1.1. Introduccin
El software es cada vez ms difcil de construir.
El software est jugando un papel importante en la

sociedad, por lo que las personas con habilidades de

desarrollo de software estn en demanda.
Existen nuevos mtodos, tcnicas y herramientas que

estn disponibles para apoyar las tareas de desarrollo y

mantenimiento del software.
Actualmente se exige a los desarrolladores un software

de alta calidad.

1.1. Introduccin
El desarrollador altamente calificado asegura que
sus productos de software se basan en el
,
dentro del
, y son de la mejor
calidad con respecto a los atributos tales como la
,
,
, y la capacidad
de
con todos los requisitos de los
usuarios.

1.1. Introduccin
La ingeniera de software es una nueva disciplina
que se relaciona con otras disciplinas de la
ingeniera , y tiene asociado un cuerpo definido de
conocimientos , un cdigo de tica , y un proceso
de certificacin.

1.1. Introduccin

Elementos de las disciplinas de

ingeniera

1.1. Introduccin
La IEEE y la ACM han unido fuerzas para definir un

cuerpo de conocimientos que debe adquirir la

ingeniera de software y un cdigo de tica para el
ingeniero de software.

1.1. Introduccin
Un especialista de pruebas:
Es quien tiene una educacin basada en
principios, prcticas y procesos que constituyen la
ingeniera de software.
Se enfoca especficamente en las pruebas de
software.
Est entrenado como un ingeniero que tiene los
conocimientos de principios relacionados con
las pruebas, procesos, mtricas,

normas, planes, herramientas y

mtodos.

1.1. Introduccin
La necesidad en los productos de software de tener alta

calidad, por lo que presiona a los desarrolladores a

identificar y cuantificar los factores de calidad tales
como la usabilidad, capacidad de pruebas,
mantenimiento y fiabilidad, y para identificar las
prcticas de ingeniera que apoyan la produccin de
software de calidad que tienen estos atributos.

1.1. Introduccin
Proceso, en el dominio de la ingeniera de software, es

el conjunto de mtodos, prcticas, normas,

documentos, actividades, polticas y procedimientos
que los ingenieros de software utilizan para desarrollar
y mantener un sistema y sus artefactos asociados, tales
como los proyectos y planes de prueba, diseo
documentos, cdigo, y manuales.

Componentes
de un proceso
de ingeniera

 La mayora de los ingenieros de software estaran

de acuerdo en que las pruebas son un componente
vital de un proceso de software de calidad, y es una
de las actividades ms difciles y costosas
realizadas durante el desarrollo y mantenimiento
de software.

 A pesar de papel vital de las pruebas en la produccin

de software de calidad, los modelos de evaluacin y

mejora de procesos existentes, como el CMM,
Bootstrap, e ISO-9000 no han abordado
adecuadamente los problemas del proceso de pruebas.

 El Modelo de Madurez de Pruebas (TMM), se ha

desarrollado en el Instituto de Tecnologa Illinois por

un grupo de investigacin, para subsanar las
deficiencias de estas reas.

1.1 INTRODUCCIN
Que es una prueba?

Que es un Software?
Es el conjunto de los programas de cmputo, procedimientos, reglas,
documentacin y datos asociados que forman parte de las operaciones
de un sistema de computacin.

El software como producto puede

tener defectos o fallas, desde el
momento de concebirlo y
modelarlo, durante su desarrollo y
despus de la puesta en
produccin de la aplicacin del
software

Las pruebas de software

corresponde a la necesidad de
garantizar un producto de calidad

Por qu es importante hacer pruebas de

software:
Sistema libre de errores
Eficiencia de la aplicacin
Aseguramiento de la calidad del software

Evaluacin de la flexibilidad del software construido

Misiones fallidas
Impacto inesperado en la ejecucin operacional

Falta de confiabilidad en casos de que no se ejecute

acertadamente

1.2 Las pruebas como un proceso

Las pruebas son parte esencial del proceso de
desarrollo del software. Esta parte del proceso
tiene la funcin de detectar los errores de
software lo antes posible.

Proceso de pruebas en el ciclo de vida de desarrollo de

software

1.2 Las pruebas como un proceso

Dentro del proceso de desarrollo de software se tienen

algunos procesos como las pruebas.

1.2 Las pruebas como un proceso

Procesos de validacin y verificacin
1

Validacin: Proceso de evaluar un sistema o

componente durante o al final del proceso de
desarrollo para determinar si satisface los
requisitos especificados.
Se basa en la ejecucin de cdigo

Verificacin: Proceso de evaluar un sistema o

componente para determinar si los productos
de una determinada fase satisfacen las
condiciones impuestas al comienzo de la fase.
Se basa en revisar los entregables del software

Estamos construyendo
el producto correcto?
Se ajusta a los
requisitos del cliente?

Estamos construyendo el
producto correctamente?
implementa correctamente
una funcin especfica?

1.2 Las pruebas como un proceso

Definicin de pruebas:
Como un conjunto de procedimientos que se llevan a cabo para
evaluar algn aspecto de un componente de software.
Como un proceso utilizado para revelar defectos en el software, y
para establecer que el software ha alcanzado un grado especfico
de calidad con respecto a los atributos seleccionados.
Estas definiciones comprenden tanto
actividades de validacin como de
verificacin.

1.2 Las pruebas como un proceso

Estas definiciones:
Incluyen: revisiones tcnicas, planificacin de pruebas,
seguimiento de pruebas, diseo de casos de prueba,
pruebas unitarias, pruebas de integracin, pruebas del
sistema, pruebas de aceptacin y las pruebas de
usabilidad.
Describen las pruebas como un proceso de doble
propsito, uno que revela los defectos, as como uno
que se utiliza para evaluar los atributos de calidad del
software como la fiabilidad, seguridad, facilidad de
uso, y la correccin.

1.2 Las pruebas como un proceso

Tambin tenga en cuenta que las pruebas y

depuracin son dos actividades muy diferentes.

El proceso de depuracin se inicia despus de la

prueba se ha realizado y el probador ha sealado que el

software no se est comportando como se especifica.

1.2 Las pruebas como un proceso

Las Pruebas como un proceso tiene aspectos:
Econmicos
Tcnicos
Gestin.

1.2 Las pruebas como un proceso

Aspectos Econmicos:
Estn relacionados con los recursos y tiempo

disponibles para el grupo de pruebas.

En muchos casos las pruebas no se completan debido a

estas limitaciones econmicas.

Una organizacin debe estructurar su proceso de

prueba para que pueda ofrecer software a tiempo y

dentro del presupuesto, y tambin satisfacer las
necesidades del cliente.

1.2 Las pruebas como un proceso

Aspectos Tcnicos:
Estn relacionadas con las tcnicas, mtodos, mtricas

y herramientas que se utilizan para asegurar que el

software est libre de defectos y es fiable para las
condiciones y limitaciones bajo las que debe funcionar.

1.2 Las pruebas como un proceso

Aspectos de Gestin:
La prueba es un proceso, y como un proceso que debe

administrado.
Significa que una poltica organizacional para la

prueba debe ser definida y documentada.

Los procedimientos y fases de las pruebas deben ser

definidos y documentados.

1.2 Las pruebas como un proceso

Las pruebas deben ser planificadas, los Testers deben

ser entrenado, el proceso debera haber asociado

metas cuantificables que pueden ser medidos y
controlados.
Las pruebas como un proceso debe ser capaz de

evolucionar a un nivel donde no se dispone de

mecanismos para hacer mejoras continuas.

PRUEBAS DE SOFTWARE
Las pruebas de software (testing en ingls) son los procesos que
permiten verificar y revelar la calidad de un producto software
antes de su puesta en marcha. Bsicamente, es una fase en el
desarrollo de software que consiste en probar las aplicaciones
construidas.
Las pruebas de software se integran dentro de las diferentes fases
del ciclo de vida del software dentro de la Ingeniera de software. En
este sentido, se ejecuta el aplicativo a probar y mediante tcnicas
experimentales se trata de descubrir qu errores tiene.
Para determinar el nivel de calidad se deben efectuar unas medidas
o pruebas que permitan comprobar el grado de cumplimiento
respecto de las especificaciones iniciales del sistema

1.3. DEFINICIONES BSICAS

1.3. DEFINICIONES BSICAS

Errors (errors)
Un error es un equivocacin, confusin o malentendido por

parte de un desarrollador de software.

Desarrollador (Ingenieros de software, programadores,

analistas y Testers).

Una accin del ser humano que produce un resultado

incorrecto.

Ejemplos:
Notacin de diseo
Tipo de variable asignado incorrectamente

1.3. DEFINICIONES BSICAS

Defectos (Faults)
Un defecto en el software es originado como el

resultado de un error.
Es una anomala en el software que puede causar un
comportamiento incorrecto, y no de acuerdo a su
especificacin.

1.3. DEFINICIONES BSICAS

Defectos (Faults)
Son tambin llamados Bugs. Aunque este trmino

trivializa el impacto de los defectos en la calidad de

software.
El trmino de Defectos es tambin asociado con los
artefactos del software como requerimientos y
documentos de diseo.

1.3. DEFINICIONES BSICAS

Fallas (Failures)
La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones

requeridas dentro de los requisitos de

rendimiento especificados.
Ejemplo:
Durante la ejecucin del sistema o componente
se observa que produce los resultados
esperados.

1.3. DEFINICIONES BSICAS

Fallas (Failures)
Cuando se tiene una falla en un sistema, indica
que algn tipo de defecto est presente.
Un desarrollador con experiencia/Tester debe
tener una base de conocimientos de los casos de

defectos/sntomas/fallas.

1.3. DEFINICIONES BSICAS

Fallas (Failures)
El comportamiento incorrecto puede incluir:
La produccin de valores incorrectos en las variables de
salida,
Una respuesta incorrecta por parte de un dispositivo,
Una imagen incorrecta en una pantalla.

NOTA: Las fallas se identifican por los Testers, y los defectos

se localizan y se reparan por los desarrolladores.
Cuando el software est en operacin, los usuarios son
quienes identifican las fallas.

 Un fallo en el cdigo no siempre produce un fracaso.

Sin embargo, cuando se producen las condiciones

adecuadas el fallo se manifestar como un fracaso:
(Voas)
1. La entrada al software debe causar la declaracin
defectuosa al ejecutarse.
2. El estado defectuoso debe producir un resultado
diferente al correcto.
3. El estado interno incorrecta debe propagar a la
salida, de modo que el resultado de la falla es
observable.

La siguiente figura muestra la relacin entre error,

defecto y fallo:

Figura 1.1: Relacin entre error, defecto y fallo

 Caso de prueba (test case)

Se define como: Un conjunto de entradas,

condiciones de ejecucin y resultados
esperados, diseados para un objetivo
particular.

Tester y Aseguramiento de la
calidad
El tester que prueba el software tiene como principal
funcin encontrar bugs, lo ms temprano posible, y
asegurarse de que sean arreglados.
La persona encargada del aseguramiento de la
calidad del software tiene como responsabilidad
principal crear y hacer cumplir los estndares y los
mtodos para mejorar el proceso de desarrollo y
prevenir que los bugs aparezcan.

 Defecto (defect, fault, bug)

Un defecto puede ser definido como:

Un paso, proceso o definicin de dato incorrecto en un programa de

computadora. El resultado de una equivocacin.

Una variacin de una caracterstica deseada del producto.

Un defecto puede dividirse en dos categoras:

Defectos en la especificacin del producto: el producto

construido vara del producto especificado.

Variaciones en las expectativas del cliente/usuario: estas

variaciones son algo que el usuario quiere que no est en el

producto final, pero stas adems no fueron especificadas para ser
incluidas en el producto.

1.4. PRINCIPIOS PARA LAS

PRUEBAS DEL SOFTWARE

1.4. PRINCIPIOS PARA LAS PRUEBAS

DEL SOFTWARE

1.4. PRINCIPIOS PARA LAS PRUEBAS

DEL SOFTWARE
Los principios proporcionan la base para el desarrollo

del conocimiento y la adquisicin de habilidades de las

pruebas.
Proporcionan una gua para definir las actividades de
pruebas.

1.4. PRINCIPIOS PARA LAS PRUEBAS

DEL SOFTWARE
Un principio se puede definir como:
Un general o fundamental, el derecho, la doctrina, o
la presuncin;
2. Una regla o cdigo de conducta;
3. Las leyes o hechos de la naturaleza que se basa el
funcionamiento de un dispositivo artificial.
1.

1.4. PRINCIPIOS PARA LAS PRUEBAS

DEL SOFTWARE
En la ingeniera de software, los principios se refieren a

las leyes reglas o doctrinas que se relacionan con el

software, cmo construirlos y cmo se comportan.
Pueden referirse a normas o cdigos de conducta
relativos a los profesionales que disean, desarrollan,
prueban y mantienen los sistemas.
Las pruebas como un componente de la ingeniera de
software tambin tiene un conjunto de principios que
sirven de gua para el Tester.

1.4. PRINCIPIOS PARA LAS PRUEBAS

DEL SOFTWARE
Glenford Myers fue el primero que seal una serie de
principios de las pruebas de software en su libro El Arte
de pruebas de software
Estos principios son mencionados con modificaciones

realizadas para reflejar la evolucin de las pruebas.

Se refieren a las pruebas basadas en ejecucin.

1.4 Principios para las pruebas de

software.

Principio 1: Las pruebas son el

proceso de ejecutar un componente de
software
usando
un
conjunto
seleccionado de casos de prueba, con
la intencin de:
(i) revelar defectos, y
(ii) evaluar la calidad.

Este principio apoya la prueba como una actividad basada en la ejecucin para
detectar defectos.
El trmino "componente de software" se utiliza en este contexto para representar
cualquier unidad de software.

1.4 Principios para las pruebas de

software.

Principio 2: Cuando el objetivo

de la prueba es detectar defectos,
entonces un buen caso de prueba es
aquel que tiene una alta probabilidad
de revelar defecto(s) todava no
detectado(s).

Soporta el diseo cuidadoso de casos de pruebas

El objetivo es detectar defectos.

1.4 Principios para las pruebas de

software.

Principio 3: Los resultados de la

prueba deben ser
examinados
minuciosamente.

Pueden producirse varios escenarios errneos y costosos si no se tiene cuidado.

Un fallo puede ser pasado por alto.
Un fallo puede sospecharse cuando en realidad no existe.
El resultado de una prueba de calidad puede ser mal entendido.

1.4 Principios para las pruebas de

software.
Principio 4: Lo

El resto se trabajo en clase, lo encontrars en la plataforma.

1.5. El Rol del

ingeniero de
pruebas

El trabajo del Tester es:

Revelar defectos,
Encontrar puntos dbiles,
Encontrar comportamiento incoherente, y
Encontrar circunstancias en las que el software no

funciona como se esperaba.

El Tester necesita para ser eficaz:

Una amplia experiencia en programacin con el fin de

entender cmo se construye el cdigo, y dnde, y qu

tipo de defectos es probable que se produzca.
Trabajar con los desarrolladores para producir software
de alta calidad que cumple con los requisitos de los
clientes.
Tienen que trabajar con ingenieros de requisitos para
garantizar que los requisitos son comprobables, y
planificar para el sistema y prueba de aceptacin.

El Tester necesita para ser eficaz:

Probadores tambin tienen que trabajar con los

diseadores para planificar la integracin y la unidad de

prueba.
Los administradores de las pruebas tendrn que cooperar
con los administradores de proyectos con el fin de
desarrollar planes de pruebas razonables, y con la alta
gestin para proporcionar informacin para el desarrollo y
mantenimiento de las normas de organizacin de pruebas,
polticas y metas.
Tienen que cooperar con el personal de aseguramiento de
la calidad del software y de los miembros de grupos de
procesos de ingeniera de software.

Ejemplo:
Si usted es empleado de una organizacin que se evala en los

niveles 1 o 2 del TMM, es posible que no existe una funcin de

prueba de software independiente en su organizacin.
Los Testers, en este caso pueden ser parte del grupo de
desarrollo, pero con una misin especial de pruebas, o pueden
ser parte del grupo de calidad del software.
De hecho, incluso en los niveles 3 y superiores de la TMM los
probadores no necesariamente pertenecen a una entidad
organizativa independiente, a pesar de que es el caso ideal.
Sin embargo, los Testers siempre deben tener autonoma de
gestin de los desarrolladores como se describe en el Principio 8,
y en el TMM a nivel 3.

Los Testers son especialistas, su

funcin principal es:
Planificar, ejecutar, registrar y analizar las pruebas.
No depurar software. Se asegura que lo haga el

software.

Los Testers necesitan el apoyo de

la direccin
Los desarrolladores, analistas y personal de marketing

tienen que darse cuenta de que los Testers agregan valor a un

producto de software en que se detectan defectos y evalan
la calidad tan pronto como sea posible en el ciclo de vida
del software.
Esto asegura que los desarrolladores liberan cdigo con

pocos o sin defectos, y que los vendedores pueden ofrecer

software que satisfaga los requisitos de los clientes, y es
fiable, til y correcto.

Los Testers necesitan el apoyo de

la direccin
Software con bajos o sin defectos tambin tiene la ventaja de

reducir los costos, tales como las llamadas de soporte,

reparacin de software operativo y la mala voluntad que
puede derivar en acciones legales debido a la insatisfaccin
de los clientes. En vista de su papel esencial, probadores
necesita tener una visin positiva de su trabajo. La gerencia
debe apoyarlos en sus esfuerzos y reconocer sus
contribuciones a la organizacin.

 Metafricamente, el tester es

los ojos del cliente.

Habilidades del tester

Un tester se caracteriza por los siguientes rasgos:
Buen juicio
Discreto y diplomtico
Persuasivo
Contar con el respeto de sus compaeros
Explorador
Implacable
Creativo
Perfeccionista
Buen nivel de conocimiento tcnico

Por qu probar lo ms temprano posible

Permite encontrar y resolver defectos tan pronto

como sea posible

Ayuda a reducir el riesgo de fracaso del proyecto
Ayuda a reducir los costos globales de desarrollo
Provee datos valiosos en la evaluacin de viabilidad

del proyecto

1.6. Origen de los defectos

Defectos en los requerimientos y la especificacin.

Defectos en el diseo.
Defectos en el cdigo.
Defectos en las pruebas.

1.6 Origen de los defectos

Introduccin
Un defecto, en su sentido ms amplio, es

una anomala en la especificacin, diseo o

implementacin de un producto.

Defectos en
Especificaciones/Requerimientos
Es un defecto en la definicin de las

necesidades del usuario para el sistema o

componente.

Defectos en
Especificacion
es/Requerimi
entos

 El comienzo del ciclo de vida del software es crtico

para garantizar un alta calidad en el software que esta

siendo desarrollado. Los defectos incluidos en las
primeras faces pueden persistir y ser muy difciles de
eliminar en faces posteriores.
Desde que los documentos de requerimiento han sido
escritos usando un lenguaje natural de representacin
ha habido bastantes ocurrencias de ambigedad,
contradiccin,
redundancia
y
requerimientos
imprecisos.

 En muchas organizaciones, las especificaciones son

tambin desarrolladas usando un lenguaje natural de

representacin y esto tambin ha sido causa de los
mismos problemas mencionados anteriormente.
A lo largo de los aos muchas organizaciones han

introducido el uso de lenguajes de especificacin

formales que, cuando son acompaados por
herramientas, ayudan a prevenir descripciones
incorrectas del comportamiento del sistema.

Requisitos o
especificaciones

Funcionalidad

Descripcin mala de los requisitos del

usuario

Caractersticas del sistema incorrectas o

incompatibles

Interfaz de usuario, Especificaciones incorrectas sobre como

el producto interacciona con el entorno
software y hardware
Descripcin
Funcional

La total descripcin de lo que el producto hace y

como debera comportarse, es incorrecta,
ambigua, y/o incompleta.

Defectos de caractersticas:

Las caractersticas deberan ser descritas como caractersticas

distintivas de un componente de software o sistema.
Las caractersticas hacen referencia a los aspectos funcionales
del software que asignan requerimientos funcionales como
descritos por los usuarios y clientes. Las caractersticas tambin
asignan requerimientos de calidad como desempeo y
confiabilidad. Los defectos de caractersticas suceden debido a
descripciones de caractersticas que son olvidadas,
incorrectas, incompletas o superfluas.

Defectos en interaccin de las caractersticas:

Estos son debido a una incorrecta descripcin de como las

caractersticas deberan interactuar. Por ejemplo, supongamos
que una caracterstica de un sistema de software apoya la
adicin de un nuevo cliente a una base de datos de clientes.
Esta caracterstica interacta con otra que clasifica al nuevo
cliente. La caracterstica de clasificacin impacta sobre donde
coloca al nuevo cliente el algoritmo de almacenamiento y
tambin afecta a otra caracterstica que peridicamente est
enviando publicidad a una categora especifica de clientes.
Cuando probemos, ciertamente queremos enfocarnos en la
interaccin entre estas dos caractersticas.

Conclusiones
Es muy importante detectar los defectos en los

requisitos lo mas prontamente posible, ya que estos se

acarrearn durante todo el proceso de desarrollo de
software, lo cual puede conllevar grandes costos pues
el proyecto tendr que ser reestructurado desde el
comienzo y prcticamente tendr que iniciarse otra
vez.
Por esto es muy necesario tener una buena
comunicacin con el cliente y ser lo mas meticuloso
posible para evitar que las necesidades del usuario no
sean cumplidas o se haga trabajo de mas.

1.6.1 DEFECTO DE DISEO

Introduccin
Los defectos del diseo ocurren en los componentes

del sistema y sus interacciones con otros

componentes del sistema y componentes de
hardware/software de fuera. Estos defectos estan en
el diseo de algoritmos, control, logica, etc

Causas
Defectos de algoritmo y procesamiento

Defectos de control, lgica y secuencia

Defectos de datos
Defectos en la descripcin de mdulos de interfaz

Defectos de descripcin funcional

Defectos de descripcin para interfaces externas

Defectos de algoritmo y
procesamiento
Ocurre cuando los pasos de procesamiento en el

algoritmo son descritos de forma incorrecta

Defectos de control, lgica y

secuencia
Ocurre cuando el flujo del seudocdigo es

incorrecto dando paso a cdigo inalcanzable

Defectos de datos
Estn asociados a un mal diseo de la estructura de

datos

Defectos en la descripcin de
mdulos de interfaz
Se da por el uso de tipos inconsistentes de

parmetros

Defectos de descripcin funcional

La descripcin del funcionamiento de los mdulos

es errnea o incompleta

Defectos de descripcin para

interfaces externas
La descripcin de componentes de sistemas

externos a bases de datos es incorrecta

Conclusin
Este

tipo de defectos ocurren cuando los

componentes del sistema, la interaccin de los
componentes entre ellos, con otros software, con el
usuario estn mal diseados.
Estos defectos recaen en el diseo de algoritmos,
lgica, control, datos y la descripcin del
software/hardware/interfaz de usuario

1.6.2. Defectos en el cdigo

Defectos en el cdigo
Introduccin

Qu es un defecto de cdigo?
Es la derivacin de un error en la implementacin del
cdigo, los cuales estn estrechamente relacionados con
el diseo de las clases sobre todo si se utiliza
pseudocdigo para el diseo.

Defectos en el cdigo
Principalmente los defectos de cdigo provienen de una
mala comprensin del lenguaje de programacin y la
falta de comunicacin entre los diseadores, tambin se
da por transcripcin u omisin.

Tipos de defectos en el cdigo

1.- Defectos algortmicos y de procesamiento.
Se incluyen desbordamiento sin control, comparacin de
tipos de datos inadecuados, la conversin de un tipo de
dato a otro, orden incorrecto de los operadores
aritmticos, mal uso u omisin de parntesis y el uso
incorrecto de signos.

Tipos de defectos en el cdigo

2.- Defectos de control, lgica y secuencia.
A nivel de cdigo pueden incluir expresiones incorrectas
a causa de las declaraciones, iteraciones errneas de
ciclos y rutas desaparecidas.

 3.- Errores tipogrficos

Son principalmente errores de sintaxis, por ejemplo
faltas de ortografa en los nombres de variables,
usualmente detectados por el compilador y
autorevisiones.

Tipos de defectos en el cdigo

4.- Defectos de inicializacin
Ocurren
cuando
se
omiten
declaraciones o son incorrectas. Puede
ocurrir por malentendidos o falta de
comunicacin entre programadores y/o
programadores y diseadores, confusin
en el entorno de programacin.

Tipos de defectos en el cdigo

5.- Defectos de flujo de datos
Hay ciertas secuencias operativas por las cuales los datos
deben fluir. Por ejemplo, una variable debe ser
inicializada antes de ser usada en un clculo o una
condicin. No debe ser inicializada dos veces antes de
que haya un uso intermedio. Por lo tanto, en el sentido
ms estricto de la definicin del trmino defecto, no
pueden considerarse como verdaderos casos defectos.

Tipos de defectos en el cdigo

6.- Defectos de datos
Estos surgen con una implementacin incorrecta de
estructura de datos. Por ejemplo, el programador puede
omitir un campo de un registro, o si el acceso se asigna a
un archivo, una matriz, no se asignaron el nmero
adecuado de elementos, etc. Otros defectos de datos
incluyen indicadores, ndices y constantes configuradas
incorrectamente.

1.6.3 Tipos de defectos en el

cdigo
Defectos de interfaz de mdulo
En el caso del diseo de los elementos del mdulo, los
defectos de interface en el cdigo se deben al uso
incorrecto o inconsistente del tipo de parmetro, un
nmero incorrecto de parmetros . Adems de defectos
debido a un diseo inadecuado, la aplicacin indebida
del diseo. Los programadores pueden implementar una
secuencia incorrecta de las llamadas o las llamadas a
mdulos no existentes.

Tipos de defectos en el cdigo

Defectos en la documentacin de cdigo
Cuando la documentacin del cdigo no refleja lo que el
programa hace actualmente, o est incompleto o
ambiguo. Los testers pueden ser engaados por los
defectos en la documentacin y as reutilizar pruebas
inadecuadas o diseo de nuevas pruebas que no son
apropiadas para el cdigo. Las revisiones de cdigo son
las mejores herramientas para detectar este tipo de
defectos.

Tipos de defectos en el cdigo

Defectos de hardware e interfaces de software
Estos defectos se deben a problemas relacionados con
ajustes del sistema, enlaces a bases de datos, secuencias
de entrada/salida, uso de memoria, uso de recursos etc.