83SISTEMAS& TELEMÁTICA
Aplicación práctica del diseño de pruebasde software a nivel de programación
Fecha de recepción: 11-12-2003 Fecha de aceptación: 20-4-2004
Oscar Hernando Guzmán Corté[email protected]
ABSTRACTTests must be present in all softwarelife cycle phases, including require-ments, analysis and design, progra-mming, implementation and mainte-nance.
This article presents the design andexecution scheme of software test,specifically centered in programmingtests defined to Software Develop-ment department of Icesi University.The requirements tests scheme isshown in a basic form. The schemesof analysis and design tests, imple-mentations tests, and maintenancetests, are not shown because theyaren’t totally defined.
KEYWORDSProgramming test, requirementstest, test design.
RESUMENLas pruebas deben presentarse a lolargo de todo el ciclo de vida del de-sarrollo de software, pasando por re-querimientos, análisis y diseño, pro-gramación, puesta en marcha y man-tenimiento.
El siguiente artículo presenta el es-quema de diseño y ejecución de prue-bas de software, centrándose especí-ficamente en las pruebas de progra-mación, definidas para el departa-mento de Desarrollo de Sistemas de
84 SISTEMAS& TELEMÁTICA
la Universidad Icesi. El esquema depruebas de requerimientos se mues-tra de manera general, mientrasque del esquema de pruebas de aná-lisis y diseño, de puesta en marchay de mantenimiento no se presen-tan por no estar todavía totalmentedefinidas.
PALABRAS CLAVESPruebas de programación, pruebas derequerimientos, diseño de pruebas.
Clasificación: B
85SISTEMAS& TELEMÁTICA
INTRODUCCIÓNEn el mundo de la computación tancambiante de hoy en día, y sobre todode gran evolución tecnológica, y envista de las exigencias que ha traídola globalización, se ha hecho necesa-rio desarrollar metodologías para ase-gurar la calidad de los productos desoftware y obtener un mejoramientocontinuo de todos los procesos rela-cionados con el desarrollo de soft-ware. Entre tantas metodologías, sepueden mencionar: STD (SoftwareTechnology Diagnostic), CMM (Capa-bility Maturity Model), Bootstrap,Trillium, y HealthCheck. Vale la penaaclarar que CMM es un esquema dediagnóstico y de evaluación de lamadurez del proceso de desarrollo desoftware, más que un esquema demejoramiento de procesos.
Todos estos mecanismos de evalua-ción y mejora en el desarrollo de soft-ware han permitido que las empre-sas implementen la metodología quemás se ajuste a sus necesidades y for-ma de trabajar. Desde este enfoque,el equipo de Desarrollo de Sistemasde la Universidad Icesi ha acopladoalgunos conceptos relevantes de
CMM y establecido estándares paradefinir su propio modelo de asegura-miento de la calidad de software; ano-tando que algunos elementos de di-cho modelo están en proceso de defi-nición, otros ya se están implemen-tando, y otros están pendientes deajustarlos a nuestras necesidades.
A continuación, se presenta el proce-so de diseño y ejecución de pruebasde software (básicamente pruebas deprogramación) que se ha definidopara el departamento de Desarrollode Sistemas de la Universidad Icesi.
1. ¿CÓMO LLEGARA LA DEFINICIÓNDEL ESQUEMA DE PRUEBASDE SOFTWARE?CMM, en términos generales, proveeuna guía de cómo obtener el controldel proceso de desarrollo y manteni-miento de software, de cómo evolu-cionar hacia una cultura de ingenie-ría de software. La Figura 1 muestrael esquema general de cinco nivelesde madurez del proceso de softwarepropuesto por CMM, y la Figura 2revela la estructura de cada nivel demadurez.
Figura 1. Niveles de madurez del proceso de software.
86 SISTEMAS& TELEMÁTICA
Como se ha mencionado anteriormen-te, se ha revisado el esquema pro-puesto por CMM para determiar elestado actual del proceso de desarro-llo de software, y establecer las ac-ciones a tomar en búsqueda de alcan-zar un mayor nivel de madurez endicho proceso.
Y, en lo concerniente específicamen-te al esquema del plan de asegura-miento de calidad de software, seidentificó para los tres primeros ni-veles lo siguiente:
• Nivel 1. Proceso Inicial:— Proceso ad hoc que puede ser
caótico.
— No hay procedimientos forma-lizados, estimados de costos yplaneación de proyectos.
— Las herramientas no estánbien integradas con el procesoni se aplican de manera uni-forme.
— El control de cambios no es es-tricto.
— La instalación y el manteni-miento del software presentanproblemas.
— No hay un mecanismo que ase-gure la utilización de procedi-mientos formales.
— Se debe establecer un plan for-mal de aseguramiento de cali-dad de software.
• Nivel 2. Proceso Repetible:
— Riesgos:
* Nuevas herramientas ymétodos podrían afectar elproceso.
Figura 2. Estructura de los niveles de madurez de CMM.
87SISTEMAS& TELEMÁTICA
* Nuevo tipo de producto pue-de cambiar todo el proceso.
* Cambios organizacionalesgrandes.
— Establecer un grupo de proce-sos: Es el encargado de la de-finición del proceso de desarro-llo, la identificación de necesi-dades y oportunidades a nivelde tecnología, la asesoría aproyectos, informes gerencia-les quincenales sobre el esta-do y desempeño de los proce-sos. Si son de menos de cuatropersonas, es suficiente con uncomité conformado por profe-sionales con experiencia o con-sultores.
El propósito del grupo es elmejoramiento del proceso desoftware.
— Establecer una arquitecturadel proceso de desarrollo desoftware (ciclo de vida de de-sarrollo de software): Son lasactividades técnicas y admi-nistrativas requeridas para laejecución apropiada del proce-so de desarrollo. Como arqui-tectura se entiende tareas consus prerrequisitos, descripcio-nes funcionales, procedimien-tos de verificación y especifi-caciones que indican si una ta-rea se ha completado.
— Introducir una familia de mé-todos de ingeniería de soft-ware y tecnologías, tal comoinspecciones de código y dise-ño, métodos formales de dise-ño, sistemas de control de li-brerías y métodos de prueba,
prototipos, lenguajes de imple-mentación sofisticados, etc.
— Se debía establecer un progra-ma de SQA que asegurará que:
* Se utiliza una metodologíade desarrollo de softwareapropiada.
* Los proyectos utilizan es-tándares y procedimientos.
* Se llevan a cabo revisionesy auditorías independien-tes.
* Existe documentación parasoportar mantenimiento ymejoras.
* La documentación se pro-duce durante y no despuésdel desarrollo de software.
* Hay mecanismos para con-trolar cambios.
* Las pruebas hacen énfasisen las áreas de alto riesgo.
* Cada tarea de software secompleta a satisfacción,antes de continuar con lasiguiente.
* Las desviaciones con res-pecto a estándares y proce-dimientos se detectan lomás pronto posible.
* El trabajo de control de ca-lidad de software se traba-ja con respecto a unos es-tándares establecidos.
* El plan de aseguramientode calidad y el plan de de-sarrollo de software soncompatibles.
88 SISTEMAS& TELEMÁTICA
— Este nivel contempla cincoáreas claves: gestión de reque-rimientos, planeación del pro-yecto, seguimiento y supervi-sión del proyecto, asegura-miento de la calidad, gestiónde la configuración del soft-ware, y gestión de los subcon-
tratos de software. En la Ta-bla 1 se muestra el puntajeobtenido para las actividadesdefinidas del área clave deaseguramiento de calidad. Y,en la Tabla 2 se muestra laescala de puntajes utilizada.
0.0 1
0.0 2
0.0 3
0.0 4
0.0 5
Actividades Puntaje Prioridad
Un plan de SQA es preparado para el pro-yecto de software de acuerdo con los proce-dimientos existentes y documentados, y sesigue por parte de los integrantes del Equi-po de Desarrollo de Software.
Las actividades del grupo de SQA son rea-lizadas de acuerdo con el plan de SQA defi-nido.
El líder del proyecto revisa las actividadesdel GIS para verificar el cumplimiento delplan y los estándares.
Se debe presentar el informe de calidad delproyecto, teniendo en cuenta las desviacio-nes identificadas en las actividades o en losproductos de software.
El encargado de investigar SQA debe defi-nir, programar y coordinar revisiones pe-riódicas de las actividades, para garantizarel cumplimiento total del plan SQA.
Puntaje máximo 5.0
Puntaje total obtenido 0.0
Tabla 1. Puntajes y prioridades de las actividadesdel área clave de aseguramiento de calidad.
Tabla 2. Escala de puntajes
Puntaje Descripción
0.0 No se realiza0.5 Se realiza parcialmente1.0 Se realiza totalmente
89SISTEMAS& TELEMÁTICA
• Nivel 3. Proceso definido:
Se requiere trabajar en los siguien-tes aspectos:
— Estándares de software.
— Inspecciones de software.
— Pruebas de software.
— Trabajo adicional en gestión deconfiguraciones.
— Definición del proceso de soft-ware.
— Conformación del grupo delproceso de ingeniería de soft-ware.
Debido a este análisis anterior, sedecidió crear el Equipo de Asegura-miento de Calidad de Software, elcual se encarga de todo el proceso desqa. En el Anexo 1 se presenta unalista de chequeo de aseguramiento decalidad. Dentro del proceso de sqa, semuestra en el siguiente punto, lo re-lacionado con el diseño y ejecución delas pruebas de software.
2. DISEÑO Y EJECUCIÓNDE PRUEBAS DE SOFTWAREUna definición que se puede dar depruebas es la siguiente: “Una activi-dad en la cual un sistema o uno desus componentes se ejecuta en cir-cunstancias previamente especifica-das, los resultados se observan y re-gistran, y se realiza una evaluaciónde algún aspecto”.
La prueba es un elemento crítico parala calidad del software. La importan-cia de los costos asociados a los erro-res promueven la definición y aplica-ción de un proceso de pruebas minu-ciosas y bien planificadas. Las prue-bas permiten validar y verificar elsoftware, entendiendo como valida-ción del software el proceso que de-termina si el software satisface losrequisitos, y verificación como el pro-ceso que determina si los productosde una fase satisfacen las condicio-nes de dicha fase.
Las estrategias de pruebas permitenenfocar el plan de pruebas; éste com-prende la visión global del proceso depruebas, y la definición de activida-des y roles involucrados en cada unade ellas.
Las pruebas que se han considerado,dentro del plan de pruebas, son lassiguientes:
• Pruebas de requerimientos.• Pruebas de análisis (pendiente).
• Pruebas de diseño (pendiente).
• Pruebas de unidad.
• Inspecciones.
• Pruebas de información no perió-dica.
La Figura 3 muestra, gráficamente,las pruebas de software consideradas.
90 SISTEMAS& TELEMÁTICA
Figura 3. Pruebas de software consideradas.
con la lista de chequeo general deldocumento y la lista de chequeo derequerimientos.
La corrección del contenido del docu-mento será responsabilidad del ana-lista y el usuario líder, quienes sonlos encargados de aprobar los reque-rimientos definidos en el documento.El diagrama del proceso de elicitaciónde requerimientos se muestra en laFigura 4, y el detalle del mismo en laTabla 3, que se presentan a continua-ción.
2.1 Pruebas de requerimientos
Los requerimientos de software de-ben tener una explicación clara, pre-cisa y completa del problema que fa-cilite el análisis de errores y la gene-ración de casos de prueba. Un asun-to de gran importancia es asegurarla corrección, coherencia y exactitudde los requisitos.
Durante el proceso de elicitación derequerimientos, una persona, desig-nada por el Equipo de Aseguramien-to de Calidad, revisará el documentode especificación de requerimientos,
91SISTEMAS& TELEMÁTICA
Figura 4. Proceso de elicitación de requerimientos
Detalle
Se determina si los objetivos son claros,verificables y necesarios (entre otros).El resultado de esta revisión se consig-na en la lista de chequeo de objetivos.
Mediante un proceso iterativo se definela funcionalidad esperada del software,y se consigna usando el documento derequisitos del sistema.
Debe verificar el documento de requeri-mientos, usando la lista de chequeo ge-neral del documento de especificación derequerimientos LCH lista de chequeogeneral del documento de elicitación yanálisis de requerimientos.
Revisan cada requerimiento (consisten-cia, ambigüedad, etc.), usando para ellola lista de chequeo de requerimientos.
Encargado
Revisor SQA
Especificador derequerimientos
Revisor SQA
Revisor SQA
Recursos
Lista de chequeode objetivos
Requerimientosdel sistema
Lista de chequeogeneral del documentode elicitación y análisis
de requerimientos
Lista de chequeo derequerimientos.
Tabla 3. Detalle del proceso de elicitación de requerimientos.
INICIO
Solicitud
Obtener información sobredominio del problema
Preparar las reuniones
Actualiza sistemacon los objetivos
Actualiza sistemacon requisitos
Establecimientodocumento línea base
FIN
Define e identifica losobjetivos del sistema
Aprueba y firmael documento
DefinirRequisitosfuncionales
DefinirRequisitos nofuncionales
Verifica los requisitosSí No
Aprobación
Verificaciónde objetivos
Sí
No
Aprobación
Aprobación
Verificaciónde requerimientos
Sí No
92 SISTEMAS& TELEMÁTICA
2.2. Pruebas de unidad
El proceso de pruebas de unidad sedescribe en el siguiente diagrama de
la Figura 5, así como el detalle delmismo en la Tabla 4.
2.3. Inspecciones
¿Aprobado?
Programador Diseñador de pruebas Ejecutor de pruebas
Programación
Entrega pruebas de funcionalidad
Revisión estándares gráficos
Revisión funcionalidad
No
Sí
Entrega casos de prueba y/o formato inspecciones
Preparar casos de prueba
Diseñar Caja Blanca
No
Ejecutar Caja Negra
Ejecutar Caja Blanca
Inspecciones
Figura 5. Proceso de pruebas de unidad.
¿Crítico?
93SISTEMAS& TELEMÁTICA
Det
alle
El e
ncar
gado
de
elab
orar
los
caso
s de
pru
eba
reci
be d
el a
nalis
-ta
el d
iseñ
o de
la fo
rma/
repo
rte
y un
a de
scri
pció
n de
la fu
ncio
-na
lidad
, usa
ndo
el f
orm
ato
de p
rueb
as d
e fu
ncio
nalid
ad. A
sím
ism
o, e
l dis
eñad
or d
e lo
s ca
sos
de p
rueb
a de
be r
ecib
ir la
s lis
-ta
s de
che
queo
de
prog
ram
ació
n ya
rev
isad
as p
or e
l ana
lista
/pr
ogra
mad
or (V
er A
nexo
s 4,
5, 6
, y 8
).
Si e
l mód
ulo
es n
uevo
, se
elab
ora
el á
rbol
de
clas
es e
quiv
alen
tes,
la ta
bla
de p
arti
cion
es y
un
lista
do d
e ca
sos
de p
rueb
a.
Si e
l mód
ulo
no e
s nu
evo,
deb
en r
evis
arse
los
docu
men
tos
deca
ja n
egra
par
a es
tabl
ecer
los
cam
bios
, que
pue
den
ser:
i.E
limin
ació
n de
ent
rada
s, lo
cua
l sig
nific
a qu
e se
deb
en r
e-vi
sar
todo
s lo
s ca
sos
de p
rueb
a qu
e in
cluy
an e
stas
ent
ra-
das
para
mod
ifica
rlos
apr
opia
dam
ente
.
Tam
bién
es
posi
ble
que
se e
limin
en a
lgun
os c
asos
de
prue
ba.
ii.In
clus
ión
de e
ntra
das,
lo c
ual s
igni
fica
revi
sar
los
caso
s de
prue
ba e
xist
ente
s y
adic
iona
r nu
evos
cas
os.
iii.
Elim
inac
ión/
Incl
usió
n de
sal
idas
: im
plic
a re
visa
r lo
s ca
sos
de p
rueb
a pa
ra e
stab
lece
r lo
s ca
mbi
os.
Cad
a ca
so d
e pr
ueba
deb
e de
jars
e do
cum
enta
do y
se
debe
in-
gres
ar e
sta
info
rmac
ión
en e
l sis
tem
a.Tab
la 4
. Det
alle
del
pro
ceso
de
pru
ebas
de
un
idad
1. P
rep
arac
ión
de
caso
s d
e p
rueb
a
Res
tric
cion
esE
ncar
gado
sR
ecur
sos
Form
ato
de p
rueb
as d
e ca
jane
gra
(Ver
Ane
xo 1
0)
Form
ato
de c
asos
de
prue
ba(V
er A
nexo
12)
Form
ato
de p
rueb
as d
efu
ncio
nalid
ad (V
er A
nexo
13)
.A
nalis
ta d
iseñ
ador
de c
asos
de
prue
ba.
Dis
eñad
or d
e ca
sos
de p
rueb
a.
Dis
eñad
or d
e ca
sos
de p
rueb
a.
94 SISTEMAS& TELEMÁTICA
Tab
la 4
. Det
alle
del
pro
ceso
de
pru
ebas
de
un
idad
2. R
evis
ión
de E
stán
dare
s gr
áfic
os
Det
alle
Rea
lizar
la re
visi
ón in
dica
da e
n la
list
a de
cheq
ueo
de e
stán
da-
res,
y d
ejar
con
sign
ados
los
resu
ltad
os y
la fe
cha
de la
rev
isió
nen
el s
iste
ma.
Res
tric
cion
es
List
a de
che
queo
de p
rese
ntac
ión
de fo
rmas
(Ver
Ane
xo 7
)
Enc
arga
dos
Ana
lista
Com
prob
ar q
ue s
e cu
mpl
a lo
est
able
cido
en
la li
sta
de c
hequ
eode
func
iona
lidad
de
form
as o
rep
orte
s, s
egún
cor
resp
onda
. De-
jar
docu
men
tado
el r
esul
tado
y la
fech
a de
rea
lizac
ión
de e
sta
acti
vida
d en
el s
iste
ma.
3. R
evis
ión
de fu
ncio
nali
dad
List
a de
che
queo
de
func
io-
nalid
ad d
e ap
licac
ione
s-fo
rmas
(Ver
Ane
xo 2
)
List
a de
che
queo
de
func
io-
nalid
ad d
e ap
licac
ione
s–re
port
es (V
er A
nexo
3)
Ana
lista
Rec
urso
s
El e
jecu
tor
debe
con
tar
con
el m
ódul
o de
sarr
olla
do y
ten
er t
o-do
s lo
s pe
rmis
os q
ue te
ndrí
a el
usu
ario
fina
l.A
dem
ás, d
ebe
cont
ar c
on lo
s ca
sos
de p
rueb
as d
iseñ
ados
.
Se d
eben
eje
cuta
r to
dos
los
caso
s de
pru
eba
y co
nsig
nar
los
re-
sult
ados
obt
enid
os e
n el
form
ato.
4. E
jecu
ción
de
prue
bas
de c
aja
negr
a
Eje
cuto
r de
pru
ebas
.
Form
ato
de r
esul
tado
s de
ejec
ució
n de
pru
ebas
(Ver
Ane
xo 1
1).
Eje
cuto
r de
prue
bas.
95SISTEMAS& TELEMÁTICA
5. D
iseñ
o y
ejec
ució
n de
pru
ebas
de
caja
bla
nca
[opc
iona
l]
Tab
la 4
. Det
alle
del
pro
ceso
de
pru
ebas
de
un
idad
Dis
eñad
or d
e pr
ueba
s.
Rec
urso
sR
estr
icci
ones
Enc
arga
dos
Det
alle
s
Prep
arac
ión
de lo
s ca
sos
de p
rueb
a us
ando
la t
écni
ca d
el c
a-m
ino
bási
co. E
l ana
lista
pro
porc
iona
el c
ódig
o de
la fu
nció
n y
el c
álcu
lo d
e la
com
plej
idad
cic
lom
átic
a.
Se e
stab
lece
la li
sta
de c
asos
de
prue
ba y
se
docu
men
ta c
ada
uno.
Se e
jecu
tan
las
prue
bas
para
cad
a ca
so e
ncon
trad
o y
se c
on-
sign
an lo
s re
sult
ados
.
Dis
eñad
or d
e pr
ueba
s.
Eje
cuto
r de
pru
ebas
.
6. I
nspe
ccio
nes
[opc
iona
l]
Rea
lizar
la in
spec
ción
sig
uien
do la
list
a de
cheq
ueo
y an
otan
-do
los
erro
res
enco
ntra
dos
en e
l for
mat
o.
Rea
lizar
la r
euni
ón d
e in
spec
ción
, ori
enta
da p
or e
l mod
era-
dor.
El r
evis
or y
el m
oder
ador
exp
onen
los
erro
res
halla
dos.
El a
nalis
ta a
clar
a la
s du
das
o in
dica
si h
ubo
un e
rror
de
apre
-ci
ació
n
Se co
nsig
nan
los
resu
ltad
os co
nsol
idad
os d
e la
insp
ecci
ón y
se
entr
egan
al a
nalis
ta.
FOR
Ins
pecc
ione
s-R
egis
tro
dede
fect
os (V
er A
nexo
9).
Rev
isor
Mod
erad
orA
nalis
ta
Rev
isor
Mod
erad
or
Ana
lista
Mod
erad
or
Exc
epci
ones
Cua
ndo
el m
ódul
o se
a cr
ític
o, s
e ej
ecut
an la
s pr
ueba
s de
caj
a bl
anca
y la
s in
spec
cion
es
96 SISTEMAS& TELEMÁTICA
2.3 Inspecciones
El objetivo de las inspecciones es im-plementar un proceso formal de revi-sión detallada del producto por partede pares y un moderador, con el pro-
pósito de encontrar defectos en unaetapa muy temprana del desarrollodel producto. El diagrama de la Fi-gura 6 muestra el proceso de inspec-ciones. El detalle de dicho proceso seencuentra en la Tabla 5.
Figura 6. Proceso de inspecciones.
Programador
Preparar producto, listasde chequeo y material soporte.
Revisiónindividual
Moderador Revisor
Corrección dedefectos
Asignaciónde revisores
Reunión deInspección
Revisión Sí
¿Cambiogrande?
No
Aprobaciónde código
97SISTEMAS& TELEMÁTICA
Tab
la 5
. Det
alle
del
pro
ceso
de
insp
ecci
ón
1. E
labo
rar
docu
men
tos
para
insp
ecci
ón
El
anal
ista
pre
para
los
sig
uien
tes
elem
ento
s pa
ra l
a in
spec
-ci
ón:
—có
digo
fue
nte
(líne
as n
umer
adas
o i
dent
ifica
ción
de
cada
sub-
mód
ulo)
.
—m
ater
ial d
e so
port
e, c
omo
desc
ripc
ión
de la
func
iona
lidad
.
—lis
ta d
e ch
eque
o pa
ra in
spec
cion
es.
Det
alle
Res
tric
cion
es
Form
ato
de in
spec
cion
es–
Reg
is-
tro
de d
efec
tos
(Ver
Ane
xo 9
).
Enc
arga
dos
Ana
lista
Rec
urso
s
2. A
sign
ació
n de
rev
isor
es
El m
oder
ador
asi
gna
dos
revi
sore
s pa
ra e
ste
mód
ulo,
con
expe
-ri
enci
a en
des
arro
llo d
e pr
ogra
mas
en
el le
ngua
je e
n el
cua
l se
elab
oró
el m
ódul
o a
eval
uar
o, s
i est
o no
es
posi
ble,
con
exp
e-ri
enci
a en
pro
gram
ació
n en
gen
eral
.
Una
vez
asi
gnad
os lo
s re
viso
res,
se
les
entr
ega
una
copi
a de
lm
ater
ial q
ue p
rese
ntó
el a
nalis
ta y
el f
orm
ato
para
con
sign
arlo
s re
sult
ados
de
la in
spec
ción
.
Se e
stab
lece
una
fech
a de
reu
nión
y s
e in
dica
est
a fe
cha
a lo
sre
viso
res
y al
ana
lista
.
Uno
de
los
revi
sore
s de
be d
ese
r de
un p
roye
cto
dife
rent
e al
del p
rodu
cto
insp
ecci
onad
o.
Se r
ealiz
a la
insp
ecci
ón s
igui
endo
la li
sta
de c
hequ
eo y
ano
tan-
do lo
s er
rore
s en
cont
rado
s en
el f
orm
ato.
3. R
evis
ión
indi
vidu
alFo
rmat
o de
insp
ecci
ones
.
Reg
istr
o de
def
ecto
s.
Mod
erad
or
Rev
isor
Mod
erad
or
Mod
erad
or
Mod
erad
or
98 SISTEMAS& TELEMÁTICA
Det
alle
Res
tric
cion
esE
ncar
gado
sR
ecur
sos
El m
oder
ador
ori
enta
est
a re
unió
n, h
acie
ndo
que
cada
revi
sor
(y é
l mis
mo)
exp
onga
n br
evem
ente
los
erro
res
enco
ntra
dos.
El a
nalis
ta a
clar
a du
das
o in
dica
si h
ay u
n er
ror
de a
prec
ia-
ción
por
par
te d
e lo
s re
viso
res,
per
o no
pue
de t
rata
r de
dar
expl
icac
ione
s so
bre
algú
n er
ror o
indi
car f
orm
as d
e co
rreg
irlo
.
El m
oder
ador
cons
igna
en
el fo
rmat
o lo
s re
sult
ados
cons
olid
a-do
s de
la in
spec
ción
y lo
s pa
sa a
l ana
lista
par
a qu
e lo
s co
rrija
.
4. R
euni
ón d
e In
spec
ción
Mod
erad
orR
evis
or
Mod
erad
or
Ana
lista
Exc
epci
ones
Si e
l mod
erad
or e
s nu
evo,
se
debe
exp
licar
en
qué
cons
iste
el p
roce
so d
e in
spec
cion
es.
Tab
la 5
. Det
alle
del
pro
ceso
de
insp
ecci
ón
99SISTEMAS& TELEMÁTICA
2.4. Pruebas de información noperiódica
La Figura 7 muestra el diagrama del
proceso de pruebas de información noperiódica. El detalle del proceso seencuentra en la Tabla 6.
Usuario
Solicitud a travésde solicitudes
No
¿Correcto?
Sí
No
¿Correcta lainformacióngenerada?
Sí
Firma documentoCINP
Analista
Reunión para detallar el requerimientoy pactar conclusiones
Impresión formato “Control deInformación no periódica”
Generación deinformación
No
SíEnvío de
información
TerminaciónRequerimiento
Tester
Revisión Listasde Chequeo
¿Bien?
Figura 7. Proceso de pruebas de información no periódica.
100 SISTEMAS& TELEMÁTICA
Tab
la 6
. Det
alle
del
pro
ceso
de
pru
ebas
par
a in
form
ació
n n
o pe
riód
ica
Det
alle
Rec
urso
sR
estr
icci
ones
Enc
arga
dos
Usu
ario
Ingr
eso
de la
solic
itud
a tr
avés
del
sist
ema
de so
licitu
des.
Reun
ión
para
det
alla
r el r
eque
rimie
nto
y pa
ctar
conc
lusi
ones
.
Se im
prim
e el
form
ato
de co
ntro
l de
info
rmac
ión
no p
erió
dica
: (*1
).
El u
suar
io v
erifi
ca la
info
rmac
ión
en e
l for
mat
o.
Com
prob
ado
el fo
rmat
o, se
gen
era
la in
form
ació
n pe
dida
.
Revi
sión
de
las l
ista
s de
cheq
ueo.
(*2)
Apro
bada
la in
form
ació
n, se
env
ía a
l usu
ario
.
El u
suar
io co
rrob
ora
la in
form
ació
n ge
nera
da.(*
3)
Si la
info
rmac
ión
es co
rrec
ta, f
irma
el d
ocum
ento
CIN
P.
Fina
liza
el re
quer
imie
nto.
1. P
rueb
as e
insp
ecci
ones
par
a in
form
ació
n no
per
iódi
ca
Ana
lista
Usu
ario
Ana
lista
Usu
ario
Ana
lista
SQA
Ana
lista
Usu
ario
Usu
ario
Ana
lista
Exc
epci
ones
(*)
1.Si
el f
orm
ato
de c
ontr
ol d
e in
form
ació
n no
per
iódi
ca n
o es
cor
rect
o, s
e vu
elve
a r
ealiz
ar la
reu
nión
del
ana
lista
y e
l usu
ario
par
a de
talla
r el
requ
erim
ient
o.
2.Si
la r
evis
ión
de la
list
a de
che
queo
no
es a
prob
ada,
el a
nalis
ta v
uelv
e a
gene
rar
la in
form
ació
n.
3.Si
el u
suar
io n
o ap
rueb
a la
info
rmac
ión
gene
rada
, se
vuel
ve a
rea
lizar
la r
euni
ón d
el a
nalis
ta y
el u
suar
io p
ara
deta
llar
el r
eque
rim
ient
o y
el p
roce
so c
onti
núa
desd
e es
a et
apa.
101SISTEMAS& TELEMÁTICA
3. AUTOEVALUACIÓN SOBREEL PROCESO DE PRUEBASLas encuestas y evaluaciones son unaherramienta de gran valor para me-dir la percepción y el conocimiento delas personas con respecto a algúntema en particular. Como parte de unproceso de concientización, evalua-ción y aprendizaje por parte de losprogramadores, se ha diseñado un
formato de autoevaluación que per-mite determinar, en alguna medida,el conocimiento que se tiene del pro-ceso de pruebas. Los resultados de laautoevaluación sirven de retroali-mentación dentro del proceso de prue-bas de software, y son utilizados paradireccionar las medidas que se ten-gan que tomar para solucionar losproblemas identificados (Ver Tabla 7).
Tabla 7. Formato de autoevaluación sobre el proceso de pruebas
Determine si las siguientes afirmaciones son verdaderas o falsas.En el caso de las falsas explique la razón
1. Deben realizarse inspecciones para todos los módulos nuevos.
2. Antes de codificar un módulo nuevo el usuario debe haber aprobadoel diseño gráfico (I/O) del mismo.
3. Al terminar un módulo, el analista debe revisar los estándares gráfi-cos y consignar los resultados de esta revisión en el sistema.
4. El analista, además de programar, está involucrado en las siguientesactividades de pruebas: revisiones de funcionalidad, revisiones de es-tándares gráficos y aprobación del diseño gráfico por parte del usua-rio.
5. Cuando se modifica un módulo debe realizarse de nuevo la prueba decaja negra completa (incluir todos los casos de prueba).
Complete las siguientes frases
1. En un proceso de inspecciones, el papel de un analista (diferente aquien realizó el módulo a inspeccionar), es:
2. Si otro analista le envía un nuevo módulo para que lo revise, usteddebe realizar las siguientes actividades:
3. Si al realizar pruebas de caja negra se encuentran errores, el analistadebe recibir los siguientes documentos:
Y los pasos a seguir son:
4. Las técnicas de caja blanca que se usarán, de acuerdo con el procesode pruebas del equipo, son:
5. Para que la persona encargada de las pruebas pueda elaborar los ca-sos de prueba usando la caja negra, el analista debe proporcionarle:
Y usando caja blanca:
102 SISTEMAS& TELEMÁTICA
Table 7. Formato de autoevaluación sobre el proceso de pruebas
Preguntas
1. Explique algunas de las actividades que realiza una persona de SQA.
2. Si usted es nombrado revisor en un proceso de inspección, ¿dóndedebe buscar información sobre este proceso? Si se requiere llenarun formato, ¿dónde debe buscarlo?
3. ¿Quién define cuándo un módulo es crítico? ¿Por qué es necesariosaber si un módulo es crítico?
4. ¿Cómo puede usted contribuir a mejorar este proceso?
Repaso final
1. Exponga, con un ejemplo, un caso donde no es necesario seguir todoel proceso de pruebas y explique por qué no lo considera conveniente.
2. Exponga, con un ejemplo, un caso de un módulo que se deba consi-derar como crítico.
3. Explique, con sus propias palabras, todo lo que tiene que hacer (re-lacionado con las pruebas) cuando se va a desarrollar un módulonuevo.
4. Explique qué cambia con respecto al punto anterior cuando se varealizar una modificación a un módulo existente.
103SISTEMAS& TELEMÁTICA
Fecha: Analista:
ANEXOS
Anexo 1
Lista de chequeo de aseguramiento de calidad
¿Existe alguien en su organización res-ponsable por los procesos de pruebas?
¿Tiene y usa un estándar para el plande pruebas?
¿Tiene y usa un estándar para las prue-bas de unidad?
¿Tiene y usa un estándar para el repor-te de la ejecución de las pruebas?
¿La planeación y ejecución de pruebasse realiza en paralelo con el proceso dedesarrollo de software?
¿Se verifica que las especificaciones es-tén correctamente implementadas?
¿Se verifica que las expectativas delcliente sean satisfechas?
¿Los probadores verifican la precisión ycompletitud de productos internos talescomo el documento de requerimientos olos diseños?
¿Los probadores reportan los defectos alequipo de desarrollo de software para co-rrección?
¿Los probadores identifican la prioridadde los riesgos del negocio para el desa-rrollo del plan de pruebas?
¿Existen objetivos de pruebas mediblespara cada sistema de software que estásiendo probado?
¿Los objetivos están alineados con losriesgos del negocio?
Revisión de aseguramiento de calidad
Actividad Sí No No Informaciónaplica adicional
104 SISTEMAS& TELEMÁTICA
¿Se usan métricas para mejorar el pro-ceso de aseguramiento de la calidad?
¿Los probadores han definido pronós-ticos de defectos basándose en datosy experiencias previos?
¿Existe un proceso de mejoramientocontinuo para su proceso de pruebas?
¿Los tipos de defectos están identifi-cados?
¿Se registra, acumula y se usan losdatos de fallas para evaluar la efecti-vidad del proceso de pruebas y produ-cir un software libre de defectos?
¿Se usan métricas para planear y eva-luar el proceso de pruebas?
¿Tiene un proceso de entrenamientode probadores?
¿El uso de una herramienta automa-tizada de pruebas es parte significa-tiva de su proceso?
Revisión de aseguramiento de calidad
Actividad Sí No No Informaciónaplica adicional
105SISTEMAS& TELEMÁTICA
Revisión de estándares de presentación
Actividad Sí No No Informaciónaplica adicional
¿Están claramente definidos los blo-ques de información (Frames)?
¿Tiene los encabezados de título y nom-bre de aplicación correctos?
¿Las etiquetas de los campos son cla-ras y representativas?
¿Los campos de despliegue están com-pletamente inhabilitados y del colorrespectivo?
¿Los campos de solamente despliegueestán claramente identificados?
¿Tiene los colores estándar?
¿Los campos fecha tienen el formatoDD-MON-RRRR y se puede ingresarlos datos como Ej: 12ago2001?
Cuando se tiene una forma con múlti-ples tabs, ¿se conoce cuál es el registropadre de los tabs?
¿La forma tiene la dimensión correcta?
¿Los Radio Groups tienen un frame quelos abarca?
¿Los campos están alineados en formacorrecta?
¿Los campos requieren y tienen Tooltip?
¿Los LOVs tienen el tamaño y la posi-ción adecuados (que no requieran sermovidos)?
¿Los LOV’s están heredados?
Anexo 2
Lista de chequeo de estándares de presentacióny funcionalidad de la aplicación para formas
Fecha:
Forma: Descripción:
Analista: Revisor:
106 SISTEMAS& TELEMÁTICA
Revisión de aseguramiento de calidad
Actividad Sí No No Informaciónaplica adicional
¿Los barras de Scroll son blancas y deancho 15?
¿Están los RadioButtons azules y he-redan de la propiedadVA_RadioButtons?
¿Están habilitados los botones del tool-bar de manera adecuada y correspon-den con las teclas de función?
Revisión de funcionalidad
Actividad Sí No No Informaciónaplica adicional
¿La forma realiza la función que senecesita?
¿La forma ha sido ingresada a SIABDcon todas las funciones, tablas y rolesasociados?
¿Los datos de la forma cambian en for-ma sincronizada?
¿Es rápido y fácil el manejo de la for-ma?
Cuando se cambia el valor de un campode entrada, ¿se modifica también elcampo de despliegue?
¿Los bloques hijos están coordinadoscon el bloque padre en consulta, borra-do y cuando se limpia la forma?
Los campos que hacen referencia a da-tos de otras tablas ¿tienen cada uno sulista de valores?
¿Las listas de valores son lentas pararecuperar la información?
¿El tiempo de respuesta es adecuado?
107SISTEMAS& TELEMÁTICA
Revisión de funcionalidad
Actividad Sí No No Informaciónaplica adicional
¿El orden de navegación de los camposes el correcto?
¿Los mensajes graves son manejadosadecuadamente?
¿Los campos Validate from LOV funcio-nan adecuadamente?
¿Si el reporte requiere mucho tiempo,esto le es notificado al usuario?
¿Está la forma documentada?
¿Si llama reportes, la extensión de losreportes es la correcta? (NO rdf, debeestar sin extensión).
Revisión del código y los datos que retorna
Actividad Sí No No Informaciónaplica adicional
¿Se ha realizado el proceso de pruebaformal?
¿Está la mayor cantidad de código enla base de datos?
¿Se ha realizado el proceso de afina-miento Sql?
Comentarios adicionales
108 SISTEMAS& TELEMÁTICA
Revisión de estándares de presentación
Actividad Sí No No Informaciónaplica adicional
¿El reporte tiene el nombre del siste-ma correcto?
¿El reporte tiene los encabezados de tí-tulo y nombre de aplicación correctos?
¿El reporte tiene la fecha de genera-ción?
¿El reporte tiene el número de páginay el total de páginas?
¿Están claramente definidos los blo-ques de información?
¿Las etiquetas de los campos son cla-ras y representativas?
¿El reporte tiene los colores estánda-res? Negro y tonos de grises.
¿Los campos fecha tienen el formatoDD-MON-YYYY?
¿Los campos están alineados en formacorrecta?
¿Se ha utilizado la indentación paramejorar la legibilidad del reporte?
¿El reporte tiene enumeradas las filas?
¿El reporte tiene subtotales y totalesde control?
¿El reporte tiene, en la parte superior,las condiciones de generación del lista-do?
¿El reporte tiene el visto bueno delusuario?
Anexo 3
Lista de chequeo de estándares de presentacióny funcionalidad de la aplicación para reportes
Fecha:
Reporte: Descripción:
Analista: Revisor:
109SISTEMAS& TELEMÁTICA
Revisión del Código
Actividad Sí No No Informaciónaplica adicional
¿Se ha hecho revisión por pares?
¿Se ha realizado el proceso de afina-miento sql?
¿Está la mayor cantidad de código en labase de datos?
¿El código cumple con los estándares?
¿Está el reporte registrado en SIABD?
110 SISTEMAS& TELEMÁTICA
Anexo 4
Lista de chequeo de estándares de tablas
Fecha:
Tabla: Descripción:
Analista:
Estándares de las tablas
Actividad Sí No No Informaciónaplica adicional
¿El nombre de la tabla es correctosegún los estándares?
¿Tiene las descripciones de la co-lumna en la base de datos?
¿Tiene las llaves e índices adecua-dos?
¿La tabla ha sido recreada tenien-do en cuenta su uso?
111SISTEMAS& TELEMÁTICA
Anexo 5
Lista de chequeo de estándares de funciones y procedimientos
Revisión de estándares
Actividad Sí No No Informaciónaplica adicional
Fecha:
Func/Proc: Descripción:
Analista: Revisor:
¿El nombre cumple con los estándares?
¿El código cumple con los estándares?
¿Está la función/procedimiento docu-mentado?
¿Se ha realizado el proceso de afina-miento sql?
¿Se ha registrado en SIABD?
¿Se usan todas las variables, constan-tes y parámetros?
¿La asignación de valores a las varia-bles, constantes y parámetros tiene unpropósito?
¿Son correctas las validaciones de con-diciones?
Por ejemplo: código no alcanzable, ciclosinfinitos, división por cero, verificaciónde rangos, redondeos.
¿Faltan validaciones?
¿Se manejan todas las posibles excep-ciones?
¿Las variables que guardan datos decolumnas de tablas se han definido deacuerdo con esto?
Tabla.columna%type
Si se llaman otras funciones y/o proce-dimientos, ¿tienen el número de pará-metros y el tipo de datos adecuado?
112 SISTEMAS& TELEMÁTICA
Anexo 6
Lista de chequeo de estándares de programación-Código
Código en general
¿Está el código indentado a, por lo me-nos dos espacios?
¿Están ordenadas alfabéticamente lasconstantes, variables y cursores?
¿Están alineados a la izquierda lasconstantes, variables y cursores?
¿Están alineados a la izquierda la defi-nición del tipo de dato de las constan-tes, variables y cursores?
¿Está definida sola una constante, va-riable o cursor por línea?
Documentación
¿Está toda la documentación en una lí-nea diferente al código que se está do-cumentando?
¿Comprende la documentación de fun-ciones/procedimiento tres partes: unadescripción general de lo que hace lafunción o procedimiento, la descripciónde los parámetros de entrada y la des-cripción de los posibles valores y/o pa-rámetros de salida?
Parámetros
¿El nombre de los parámetros empiezacon la letra p minúscula y es significa-tivo?
Constantes
¿El nombre de las constantes empieza conla letra c minúscula y es significativo?
Elemento a revisar Sí No No Informaciónaplica adicional
Objeto
Fecha de revisión
Revisado por
Sí No
Aprobado
113SISTEMAS& TELEMÁTICA
Variables
¿El nombre de las variables empiezacon la letra v minúscula y es signifi-cativo?
Cursores
¿El nombre de los cursores empiezacon las letras cur minúsculas y es sig-nificativo?
¿Están los nombres de los cursores ali-neados a la izquierda junto con la de-finición del tipo de dato de las cons-tantes y variables?
Instrucciones Select, Insert, Up-date y Delete
¿Están todas las instrucciones Select,Insert, Update y Delete escritas enminúsculas, a excepción de variablesque hagan referencia a campos de lasformas?
Instrucciones Select
¿Están las cláusulas Select, Into,From, Where, Order BY, Group BY yHaving escritas en líneas diferentes?
Instrucciones Insert¿Están las cláusulas Insert Into yValues escritas en líneas diferentes?
Instrucciones Update
¿Están las cláusulas Update, SET yWhere escritas en líneas diferentes?
¿Está cada columna que se actualiceen una línea diferente?
¿Están todas las columnas que se ac-tualicen alineadas a la izquierda?
Instrucciones Delete
¿Están las cláusulas Delete y Whereescritas en líneas diferentes?
Elemento a revisar Sí No No Informaciónaplica adicional
114 SISTEMAS& TELEMÁTICA
Anexo 7
Lista de chequeo de estándares de presentación - Formas
Elemento a revisar Sí No No Informaciónaplica adicional
Forma
Fecha de revisión
Revisado por
Sí No
Aprobado
Forma
¿Tiene la forma la descripción y su tí-tulo de acuerdo con los estándares?
¿Tiene la forma la dimensión correcta?
Cuando se tiene una forma con múlti-ples tabs, ¿se conoce cuál es el registropadre de los tabs?
Título del frame
¿Está el título en mayúscula inicial?
Si el frame es de un solo registro, ¿estásu título en singular?
Si el frame es multirregistro, ¿está sutítulo en plural?
¿Está localizado el título en la parte su-perior izquierda del frame?
Campos
¿Tiene el contenido del campo la alinea-ción adecuada, de acuerdo con su tipode dato?
Si existen varios campos organizadosverticalmente, ¿están alineados todos ala izquierda?
Etiquetas
Si la organización NO es tabular, ¿es-tán situadas las etiquetas a la izquier-da del campo al que pertenecen?
Si la organización SÍ es tabular, ¿estánsituadas las etiquetas en la parte supe-rior del campo al que pertenecen?
115SISTEMAS& TELEMÁTICA
Etiquetas
Si la organización SÍ es tabular, ¿es-tán las etiquetas centradas?
¿Están las etiquetas en mayúscula ini-cial?
¿Están las etiquetas sin los dos pun-tos al final?
Si existen varios campos organizadosverticalmente, ¿están alineadas todaslas etiquetas a la derecha?
¿Están las etiquetas formadas de ma-nera que no utilicen abreviaturas niexpresiones de solicitud?
Radio Buttons y Check Box
¿Emplean mayúscula inicial?
En cuanto a su estructura, ¿empleanorientación en forma de columna?
En cuanto a su estructura, ¿empleanalineamiento a la izquierda?
¿Están organizadas las opciones en elorden esperado, de mayor a menor fre-cuencia de ocurrencia?
¿Están enmarcados dentro de unframe?
Listas de valores
¿Están organizados los descriptoresalineados a la izquierda en forma decolumna?
¿Están organizados los descriptores enorden alfabético o numérico, según seael caso?
¿Están los descriptores en mayúsculainicial?
¿El ancho es suficiente para evitar eluso de scroll horizontal?
¿Tienen las listas de valores la posi-ción adecuada, de forma que no requie-ran ser movidas?
Elemento a revisar Sí No No Informaciónaplica adicional
116 SISTEMAS& TELEMÁTICA
Scroll
¿Están las barras de scroll vertical ubi-cadas a la derecha?
¿Están las barras de scroll vertical igua-les a la altura de sus campos asociados?
¿Están las barras de scroll horizontalubicadas en la parte inferior?
¿Están las barras de scroll horizontaliguales al ancho de sus campos asocia-dos?
¿Son las barras de scroll blancas?
Botones
Si están ubicados horizontalmente,¿están en la parte inferior de la pan-talla?
Si están ubicados verticalmente,¿están a la derecha de la pantalla?
Los botones organizados horizontal-mente, ¿tienen la misma altura?
Los botones organizados vertical-mente, ¿tienen el mismo ancho?
¿Está colocada la opción más fre-cuente a la izquierda o en el tope,según corresponda?
¿Usan los botones mayúscula ini-cial?
¿Incluye puntos suspensivos (...) sila acción despliega otra ventana?
Elemento a revisar Sí No No Informaciónaplica adicional
117SISTEMAS& TELEMÁTICA
Anexo 8
Lista de chequeo de programación - Formas
Elemento a revisar Sí No No Informaciónaplica adicional
Forma
Fecha de revisión
Revisado por
Sí No
Aprobado
Nombres de los objetos
¿Cumplen los siguientes objetos conlos estándares?
Alert
Bloques
Canvas
Forma o reporte
Funciones y/o procedimientos
Gráficos
Librerías
Listas de valores
Object Group
Parámetros
Push Button
Radio Group
RecordGroup
Relación
Variables
Atributos visuales
Ventanas
Título del frame
¿Hereda el título del frame el atribu-to visual VA_TITULO?
118 SISTEMAS& TELEMÁTICA
Elemento a revisar Sí No No Informaciónaplica adicional
Campos
¿Hereda el campo el atributo visualcorrespondiente?
¿Hereda el prompt del campo el atri-buto visual VA_ETIQUETA?
Si el campo pertenece a un bloquemultirregistros, ¿hereda el atributovisual VA_CURRENTRECORD?
Si el campo es tipo date, ¿tiene el for-mato DD-MON-RRRR?
Si el campo es numérico y representadinero, ¿lleva delante de él el signode pesos ($)?
Si el campo indica hora, ¿tiene el for-mato HH24:MI (hora militar)?
Si el campo es un porcentaje, ¿estáubicado el símbolo “%” después delnúmero?
¿Heredan los radio_buttons el atribu-to VisualVA_RADIO_BUTTON?
¿Heredan las listas de valores el atri-buto visual VA_LOV?
Scroll
¿Tienen las barras de scroll un anchode 15 puntos?
Canvas
¿Heredan los canvas el atributo visualVA_CANVAS?
119SISTEMAS& TELEMÁTICA
Código Nombre Descripción
Anexo 9
Formato de registro de defectos - Inspecciones
10 Documentación Comentarios, mensajes
20 Sintaxis Ortografía de los comandos, puntuación,errores de tecleo, formato de las instrucciones
30 Manejo de versiones Manejo de cambios, librerías,control de versiones
40 Asignación Declaraciones, identificadores duplicados,alcance y límites de los mismos
50 Interfaces Llamadas y referencias a procedimientos, I/O, interfaz de usuario
60 Validación Mensajes de error, validaciones incorrectas
70 Datos Estructuras, contenidos, inicializaciones
80 Funciones Defectos de lógica, puntero, ciclos,recursividad, cálculo y funcionamiento
90 Sistema Configuración, memoria, tiempo de respuesta
100 Entorno Problemas de diseño, compilación,pruebas del ambiente de desarrollo
Listado de defectos encontrados
CódigoDefecto Localización Descripción del defecto encontrado
Objeto: Revisor:
Fecha: Inspección No.
Tabla de tipos estándar de defectos
121SISTEMAS& TELEMÁTICA
Anexo 10
Formato de pruebas de caja negra – Partición equivalente
< > - Tabla de particiones
Campos Clases válidas Clases no válidas
122 SISTEMAS& TELEMÁTICA
1. .
2. .
3. .
4. .
5. .
6. .
7. .
8. .
9. .
10. .
11. .
12. .
13. .
14. .
15. .
16. .
17. .
18. .
19. .
20. .
21. .
22.
23. .
24. .
25. .
26. .
27. .
28. .
29. .
30. .
31. .
32. .
33. .
34. .
35. .
36. .
37. .
38. .
39. .
40. .
41. .
42. .
43. .
44. .
Árbol de clases equivalentes
< > – Casos de Prueba
123SISTEMAS& TELEMÁTICA
Anexo 11
Formato de resultados, ejecución de pruebas
No. de ejecución:
Aprobado: Sí No
Ejecutor:
Forma:
Fecha:
Casos:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
Errores:
Caso:Observaciones: Entradas: Salidas:
Caso:Observaciones: Entradas: Salidas:
Caso:Observaciones: Entradas: Salidas:
Caso:Observaciones: Entradas: Salidas:
124 SISTEMAS& TELEMÁTICA
Anexo 12
Formato de casos de pruebas
Descripción
Entradas
Salidas esperadas
Caso No. 1
Tipo de prueba:
Objeto: Complejidad:
Descripción:
Descripción
Entradas
Salidas esperadas
Caso No. 2
125SISTEMAS& TELEMÁTICA
Anexo 13
Formato de pruebas de funcionalidad
Forma:
Analista:
Sistema:
Descripción/Observaciones/Reportes
Pantallas:
Ejecución: 1 2 3 4 5
Aprobado:
Tiene Sí Noscripts:
Diseño:
Ejecución:
126 SISTEMAS& TELEMÁTICA
CONCLUSIONES• Las acciones correspondientes a la
calidad de software que se estabanllevando a cabo eran acciones ais-ladas no contempladas en un planformal. Esto se daba, principal-mente, por el tamaño del departa-mento de Desarrollo de Sistemas,pues no se trata de una compañíadesarrolladora de software.
• El aseguramiento de calidad desoftware se podía trabajar, den-tro de cada una de las activida-des de desarrollo, de la siguientemanera:
— Realizando una revisión porpares para cada proyecto.
— Haciendo seguimiento formala los proyectos, no sólo entiempos y costos, sino en cum-plimiento con estándares ymetodología de desarrollo desoftware.
— Consolidando la metodologíade desarrollo de software enbusca de alcanzar niveles su-periores de madurez.
— Involucrando puntos de che-queo y pruebas de software.
— Desarrollando estándaresmuy concretos para programa-ción e interfase de usuario.
• Los objetivos básicos de las ins-pecciones son:
— Encontrar errores lo más tem-prano posible en el ciclo de de-sarrollo.
— Asegurar que todos los parti-cipantes están de acuerdo enla parte técnica del trabajo.
— Verificar que el trabajo cum-ple con los criterios preestable-cidos.
— Completar formalmente unatarea técnica.
— Suministrar información so-bre el producto y el proceso deinspección.
• Como beneficios secundariosde las inspecciones se desta-can:
— Asegurar que las personasasociadas estén familiarizadastécnicamente con el producto.
— Ayudar a crear un equipo téc-nico efectivo.
— Ayudar a utilizar los mejorestalentos de la organización.
— Ayudar a los participantes adesarrollar sus habilidadescomo revisores.
• Vale la pena hacer una distinciónentre los diferentes tipos de revi-siones que se pueden llevar a cabodurante el proceso de desarrollo,teniendo en cuenta que las inspec-ciones son tan sólo un tipo:
— Revisiones gerenciales: Bus-can asegurar el progreso, re-comendar acciones correctivasy asegurar el suministro ade-cuado de recursos.
— Revisiones técnicas: Evalúanel cumplimiento de especifica-ciones y planes y aseguran laintegridad de los cambios.
— Inspecciones de software: Bus-can detectar e identificar de-fectos y verificar resoluciones.
— “Walkthrough”: Buscan detec-tar defectos, examinar alter-nativas y ser un foro para elaprendizaje.
127SISTEMAS& TELEMÁTICA
Todas las revisiones anteriores sepueden combinar durante las diver-
sas etapas del proyecto. La Tabla 8muestra un ejemplo de ello.
Tabla 8. Ejemplo de revisiones durante las etapas del proyecto
• Para toda prueba debe haber unplan que incluye:
— Objetivos para cada fase deprueba.
— Cronograma y responsabilida-des para cada actividad deprueba.
— Disponibilidad de herramien-tas, documentación y libreríasde prueba.
— Procedimientos y estándares aser utilizados para planear yllevar a cabo las pruebas y re-portar los resultados.
— Criterios para determinar sila prueba está completa,como también el éxito de cadaprueba.
• Después de tener el plan de prue-bas, se deben generar los casos deprueba, siguiendo cualquier técni-ca de prueba.
• Cada caso de prueba se debe eje-cutar y al final debe quedar un re-porte de las pruebas con la si-guiente información:
— Proyecto y programas que seestán probando, objetivo de laprueba y el plan de pruebas.
— Responsables y participantesde las pruebas.
— Casos de prueba.
— Herramientas especiales uti-lizadas.
— Configuraciones de hardwarey software utilizadas.
— Resultados de las pruebas.
— Identificación de los elementosque quedan en la librería depruebas.
— Firma de los responsables delas pruebas y certificación de
Etapa Inspecciones Walkthroughs Revisiones técnicas
Requerimientos Requerimientos Requerimientosdetallados iniciales
Planeación Planes de desarrollo
Desarrollo Diseño detallado Diseño del sistemaCodificación Diseño de alto nivel
Publicaciones Publicacionesen borrador
Publicaciones finales
Pruebas Implementaciónde pruebas
128 SISTEMAS& TELEMÁTICA
que se siguió el procedimientoapropiado.
• Como parte del reporte del proce-so de pruebas, es deseable clasifi-car los errores encontrados, con elfin de tomar correctivos en el pro-ceso de prueba o retroalimenta-ción para los desarrolladores.
• Las pruebas deben ser analizadasteniendo en cuenta:
— Los errores graves encontra-dos deben ser analizados engrupo, para hallar solucionesy maneras de que no vuelvana ocurrir.
— Analizar el tipo de error másfrecuente y revisar qué ocu-rren y cómo se pueden mejo-rar las inspecciones.
— Revisar la efectividad de laspruebas y reforzar aquellasque más errores detectan.
— Los métodos y herramientas deprueba a emplear pueden ser cual-quiera, siempre y cuando se utili-cen dentro de un plan de pruebas.
• Uno de los beneficios de las au-toevaluaciones es que los analis-
tas/programadores pueden suge-rir mejoras dentro de todo el pro-ceso de desarrollo de software,para así incrementar su calidad yproductividad en el trabajo.
BIBLIOGRAFÍA• The Capability Maturity Model.
Carnegie Mellon University -Software Engineering Institute.Addison-Wesley. 1994
• http://www.sei.cmu.edu/cmm/cmms/cmms.html
• http://www.sei.cmu.edu/cmmi/
CURRÍCULOOscar Hernando Guzmán Cortés.
Ingeniero de Sistemas de laUniversidad Icesi, grado cumlaude. Especialista en gerenciade Informática Organizacionalde la Universidad Icesi. Analis-ta senior del departamento deDesarrollo de Sistemas de laUniversidad Icesi. Profesor dela Universidad Icesi, en los cur-sos de Estructuras de datos yBases de datos.