Aplicación práctica del diseño de pruebas de software a ... · Pruebas de software consideradas....

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


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.


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.


* 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.


— 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


• 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.


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,


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


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?


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.


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.


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


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


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


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


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.


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.


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:


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.


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


¿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 estándares de presentación


¿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:




¿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


¿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?


Revisión de funcionalidad


¿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


¿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


Revisión de estándares de presentación


¿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:


Revisión del Código


¿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?


Anexo 4

Lista de chequeo de estándares de tablas

Fecha:

Tabla: Descripción:

Analista:

Estándares de las tablas


¿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?


Anexo 5

Lista de chequeo de estándares de funciones y procedimientos

Revisión de estándares


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?


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


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?



Anexo 7

Lista de chequeo de estándares de presentación - Formas


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?


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?



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?



Anexo 8

Lista de chequeo de programación - Formas


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?



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?


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


Comentarios generales


Anexo 10

Formato de pruebas de caja negra – Partición equivalente

< > - Tabla de particiones

Campos Clases válidas Clases no válidas


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


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:





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


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:


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.


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


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.

Aplicación práctica del diseño de pruebas de software a ... · Pruebas de software consideradas....

Documents

Transcript of Aplicación práctica del diseño de pruebas de software a ... · Pruebas de software consideradas....