Practical Software Testing (001 100)

Machine Translated by Google
PRÁCTICO
SOFTWARE
PRUEBAS
Saltador
Nueva York
Berlina
Heidelberg
Hong Kong
Londres
Milán
París
tokio
PRÁCTICO
SOFTWARE
PRUEBAS
UN
ORIENTADO A PROCESOS
ACERCARSE
ILENE BURNSTEIN
Ilene Burnstein
Departamento de Ciencias de la
Computación Instituto de Tecnología de
Illinois 10 West 31 Street Chicago, IL
60616 EE. UU. burnstei@babbage2.cs.iit.edu
Datos de catalogación en publicación de la Biblioteca del

Congreso Burnstein, Ilene.
Pruebas prácticas de software: un enfoque orientado a procesos / Ilene Burnstein.
pag. cm.
Incluye referencias bibliográficas e indice.
ISBN 0-387-95131-8 (hc: papel alcalino)
1. Software de computadora—Pruebas. I. Título.
QA76.76.T48 B87 2002 005.1 4– 2002024164
dc21
ISBN 0-387-95131-8 Impreso en papel sin ácido.
2003 Springer-Verlag Nueva York, Inc.

Reservados todos los derechos. Este trabajo no puede ser traducido o copiado en su totalidad o en parte sin el
permiso por escrito del editor (Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY 10010, EE. UU.), a
excepción de breves extractos en relación con revisiones o análisis académicos. Está prohibido el uso en relación
con cualquier forma de almacenamiento y recuperación de información, adaptación electrónica, software de
computadora o metodología similar o diferente ahora conocida o desarrollada en el futuro.
El uso en esta publicación de nombres comerciales, marcas registradas, marcas de servicio y términos similares,
incluso si no están identificados como tales, no debe tomarse como una expresión de opinión sobre si están o no
sujetos a derechos de propiedad.
Modelo de madurez de capacidad y CMM son marcas comerciales registradas del Instituto de ingeniería de software
y la Universidad Carnegie Mellon. Testing Maturity Model y TMM son marcas de servicio del Instituto de Tecnología
de Illinois.
Impreso en los Estados Unidos de América.
987654321 GIRO 10779083
www.springer-ny.com
Springer-Verlag Nueva York Berlín Heidelberg

Miembro de BertelsmannSpringer ScienceBusiness Media GmbH
CONTENIDO
Prefacio XV
INTRODUCCIÓN A LAS PRUEBAS

1
COMO ACTIVIDAD DE INGENIERÍA
1.0 La profesión en evolución de la ingeniería de software 1 1.1

El papel del proceso en la calidad del software 4 1.2 Las pruebas
como proceso 6 1.3 Descripción general del modelo de madurez
de pruebas (TMM) 8
1.3.1 Niveles TMM 10
Lista de términos clave 16
Ejercicios 16
Referencias 17
2 FUNDAMENTOS DE LAS PRUEBAS
2.0 Introducción 19
2.1 Definiciones básicas 19
vi | Contenido
2.2 Principios de prueba de software 26 2.3

El rol del probador en una organización de desarrollo de software 34
Ejercicios 36
Referencias 37
3 DEFECTOS, HIPÓTESIS Y PRUEBAS
3.0 Orígenes de los defectos 39

3.1 Clases de defectos, el repositorio de defectos y el diseño de la prueba 43
3.1.1 Defectos de requisitos y especificaciones 44 3.1.2

Defectos de diseño 46 3.1.3 Defectos de codificación 48
3.1.4 Defectos de prueba 51 3.2 Ejemplos de defectos: el
problema de las monedas 51 3.3 Soporte del desarrollador/
evaluador para desarrollar un repositorio de defectos 57

Ejercicios 58
Referencias 59
4 ESTRATEGIAS Y MÉTODOS PARA EL DISEÑO DE CASOS DE PRUEBA I
4.0 Introducción a las estrategias de diseño de pruebas 61

4.1 El Smart Tester 62
4.2 Estrategias de diseño de casos de

prueba 63 4.3 Uso del enfoque de caja negra para el diseño de casos
de prueba 66 4.4 Pruebas aleatorias 66 4.5 Partición de clases de
equivalencia 67 4.6 Análisis de valor límite 72 4.7 Un ejemplo de la
aplicación de partición de clases de equivalencia y
Análisis de valor límite 73 4.8 Otros

enfoques de diseño de pruebas de caja negra 76
4.8.1 Representación gráfica de causa y efecto

78 4.8.2 Prueba de transición de estado 82
4.8.3 Adivinación de errores 85
Contenido | viii
4.9 Pruebas de caja negra y productos comerciales listos para usar

Componentes (COTS) 86
4.10 Métodos de caja negra y objetivos de madurez de nivel 2 de TMM 88
Ejercicios 92
Referencias 95
5 ESTRATEGIAS Y MÉTODOS PARA EL DISEÑO DE CASOS DE PRUEBA II
5.0 Uso del enfoque de caja blanca para el diseño de pruebas 97

5.1 Criterios de adecuación de las pruebas 98 5.2 Gráficos de flujo
de control y cobertura 101 5.3 Cubriendo la lógica del código 103
5.4 Rutas: su papel en el diseño de pruebas basado en cajas
blancas 108 5.5 Enfoques adicionales de diseño de pruebas de caja
blanca 111
5.5.1 Flujo de datos y diseño de prueba de caja blanca 111

5.5.2 Prueba de bucle 115 5.5.3 Prueba de mutación 116
5.6 Evaluación de los criterios de adecuación de la

prueba 118 5.7 Métodos de prueba de caja blanca y el TMM 124
Ejercicios 127
Referencias 130
6 NIVELES DE PRUEBA
6.0 La necesidad de niveles de prueba 133
6.0.1 Niveles de pruebas y paradigmas de desarrollo de software 135
6.1 Prueba unitaria: funciones, procedimientos, clases y métodos como unidades 137
6.2 Prueba unitaria: la necesidad de preparación 138 6.3 Planificación de la prueba
unitaria 139 6.4 Diseño de las pruebas unitarias 141 6.5 La clase como unidad
comprobable: consideraciones especiales 142 6.6 El arnés de prueba 148
6.7 Ejecutar las pruebas unitarias y registrar los resultados 150

viii | Contenido
6.8 Prueba de integración: objetivos

152 6.9 Estrategias de integración para procedimientos y funciones
153 6.10 Estrategias de integración para clases 158 6.11 Diseño de
pruebas de integración 159 6.12 Planificación de pruebas de integración
162 6.13 Prueba del sistema: los diferentes tipos 163 6.13.1 Pruebas
funcionales 166 6.13.2 Pruebas de rendimiento 167 6.13.3 Pruebas de
estrés 169 6.13.4 Pruebas de configuración 171 6.13.5 Pruebas

de seguridad 172 6.13.6 Pruebas de recuperación 175
6.14 Pruebas de regresión 176

6.15 Pruebas alfa, beta y de aceptación 176 6.16
Declaración resumida sobre los niveles de prueba 178
6.17 La función especial de los casos de uso 179 6.18
Niveles de prueba y el TMM 181
Ejercicios 184
Referencias 186
7 PRUEBA METAS, POLÍTICAS, PLANES Y DOCUMENTACIÓN
7.0 Conceptos introductorios 189 7.1

Objetivos y políticas de pruebas y depuración 191 7.2
Planificación de pruebas 197 7.3 Componentes del plan de
pruebas 200 7.4 Anexos del plan de pruebas 216
7.4.1 Especificaciones del diseño de prueba 217

7.4.2 Especificaciones del caso de prueba 218
7.4.3 Especificaciones del procedimiento de prueba
220 7.5 Ubicación de los elementos de prueba: el informe de transmisión de

prueba 221 7.6 Informe de los resultados de la prueba 221 7.7 El papel de
los tres grupos críticos en la planificación de pruebas y el desarrollo de políticas
226
Contenido | ix
7.8 Proceso y las disciplinas de ingeniería: el papel del individuo

como facilitador del proceso 230

Ejercicios 231
Referencias 232
8 LA ORGANIZACIÓN DE LA PRUEBA
8.0 Presentación del especialista en pruebas 235

8.1 Habilidades que necesita un especialista en
pruebas 237 8.2 Creación de un grupo de pruebas
240 8.3 La estructura del grupo de pruebas 242 8.4 El
programa de capacitación técnica 247 8.5 Trayectorias
profesionales para probadores: un ejemplo de la industria 250 8.6
Certificación de probadores 252
8.7 Integración de las actividades de prueba en el ciclo de vida del software

253 8.8 La organización de la prueba, el programa de capacitación técnica y la integración de
la prueba: soporte de las tres perspectivas críticas 257
Ejercicios 261
Referencias 262
CONTROL Y SEGUIMIENTO
9
EL PROCESO DE PRUEBA
9.0 Definición de términos

263 9.1 Mediciones e hitos para el control y seguimiento 266
9.1.1 Mediciones para monitorear el estado de las pruebas 271

9.1.2 Mediciones para monitorear la productividad del probador 275
9.1.3 Mediciones para monitorear los costos de las pruebas 276 9.1.4
Mediciones para monitorear errores, fallas y fallas 277 9.1.5 Monitorear la
efectividad de las pruebas 279
9.2 Reuniones de estado, informes y problemas de control

283 9.3 Criterios para la finalización de la prueba 289 9.4
Gestión de la configuración del software 292
X | Contenido
9.5 Control y seguimiento: tres puntos de vista críticos 296

Ejercicios 300
Referencias 302
10 REVISIONES COMO ACTIVIDAD DE PRUEBA
10.0 Expansión del paraguas de actividades de prueba 303 10.1

Tipos de revisiones 307 10.1.1 Inspecciones como tipo de revisión
técnica 308 10.1.2 Recorridos como tipo de revisión técnica 310
10.2 Desarrollo de un programa de revisión 311 10.3

La necesidad de políticas de revisión 313
10.4 Componentes de los planes de revisión 314
10.4.1 Objetivos de revisión 315

10.4.2 Condiciones previas y elementos a revisar 315
10.4.3 Roles, participantes, tamaño del equipo y requisitos de tiempo 317 10.4.4
Procedimientos de revisión 320
10.4.5 Revisar la capacitación 320

10.4.6 Revisar las listas de verificación 324
10.5 Informes de los resultados de la revisión 333

10.6 Revisión, repetición del trabajo y seguimiento 337
10.7 Métricas de revisión 337
10.8 Soporte del modelo V ampliado/modificado 340 10.9 Autocomprobación

o revisión personal 340
10.10 Revisiones y puntos de vista críticos de TMM 343

Ejercicios 345
Referencias 347
UN PROGRAMA DE MEDICIÓN PARA APOYAR

11
CALIDAD DE PRODUCTO Y PROCESO
11.0 La necesidad de un programa de medición de prueba formal 349 11.1

Algunas definiciones relacionadas con la medición 353
Contenido | xi
11.2 Inicio de un programa de medición 354 11.3

Evaluación de la calidad del software 364 11.4 Niveles
de medición y TMM 372
11.4.1 Mediciones para TMM Nivel 1 373

11.5 Un programa de medición de pruebas, valoraciones de la calidad del
software y las tres vistas críticas 386
Ejercicios 389
Referencias 391
EVALUACIÓN DE LA CALIDAD DEL SOFTWARE:

12
UN ENFOQUE CUANTITATIVO
12.0 Revisión de los conceptos de calidad 393

12.1 Costos de calidad 395 12.2 ¿Qué es el
control de calidad? 397 12.3 El papel de los
perfiles operativos y modelos de uso en
Control de calidad 399
12.4 Soporte para control de calidad: pruebas estadísticas 407 12.5
Confiabilidad del software 410 12.5.1 Mediciones para la confiabilidad
del software 413
12.6 Decisiones de confiabilidad, control de calidad y parada de prueba 414
12.6.1 Aplicación de modelos de confiabilidad 417
12.7 Niveles de confianza y control de calidad 422 12.8
Pruebas de usabilidad y control de calidad 424 12.9 Un
enfoque para las pruebas de usabilidad 425
12.9.1 Pruebas exploratorias de usabilidad 426
12.9.2 Pruebas de evaluación de usabilidad 427
12.9.3 Pruebas de validación de usabilidad 427
12.9.4 Prueba de comparación 429 12.9.5 Pruebas
de usabilidad: requisitos de recursos 429 12.9.6 Pruebas y
mediciones de usabilidad 430
xi | Contenido
12.10 Control de calidad del software y las tres vistas críticas 433
Ejercicios 436
Referencias 437
13 ANÁLISIS Y PREVENCIÓN DE DEFECTOS
13.0 Procesos y defectos 439 13.1

Historia del análisis y prevención de defectos 441 13.2 Apoyo
necesario para un programa de prevención de defectos 444 13.3
Técnicas para el análisis de defectos 447 13.4 Análisis causal de
defectos 450 13.5 El equipo de acción: Realización de cambios en los
procesos 454 13.6 Supervisión de acciones y cambios en los procesos
457 13.7 Beneficios de un programa de prevención de defectos 459
13.8 Prevención de defectos y los tres puntos de vista críticos 460
Ejercicios 462
Referencias 463
14 EL BANCO DE TRABAJO DE LOS ENSAYADORES
14.0 Objetivos para Testers' Workbench 465 14.1

Evaluación de herramientas de prueba para Workbench 467
14.2 Categorías de herramientas 470
14.2.1 Metas de Madurez para TMM Nivel 1-Inicial 472 14.2.2
Herramientas para TMM Nivel 1 472
14.2.3 TMM Nivel 2: Metas de Madurez para Definición de Fases 474
14.2.4 Herramientas para Definición de Fases 475 14.2.5 TMM Nivel 3:
Metas de Madurez para Integración 478 14.2.6 Herramientas para
Integración 480 14.2.7 TMM Nivel 4: Metas de Madurez para Administración
y
Medida 487
14.2.8 Herramientas de Gestión y Medición 489 14.2.9 TMM
Nivel 5: Metas de Madurez para Optimización/Defecto
Prevención/Control de Calidad 492
14.2.10 Herramientas para Optimización/Prevención de Defectos/Calidad
controlar 494
Contenido | XIII
14.3 El banco de trabajo de probadores y las tres vistas críticas 498
Ejercicios 500
Referencias 501
15 CONTROL Y OPTIMIZACIÓN DE PROCESOS
15.0 Metas de madurez de TMM: soporte para un proceso de prueba de calidad 503 15.1
Ingeniería de procesos y control de calidad 504 15.2 Fundamentos del control cuantitativo
de procesos 509 15.3 Actividades para el control cuantitativo de procesos de prueba 512
15.4 Ejemplos de la aplicación del control estadístico de procesos 516 15.5 Optimización del
proceso de prueba: el Papel de una mejora de procesos
Grupo 518 15.6

Transferencia de Tecnología 523
15.7 Proceso de reutilización 526
15.7.1 Plantillas para procesos reutilizables 529 15.7.2

Procedimientos para la reutilización de procesos 531
15.8 Actividades, tareas y responsabilidades para el control y la optimización

del proceso de prueba 533
Ejercicios 535
Referencias 536
EL MODELO DE MADUREZ DE PRUEBA Y

dieciséis
EVALUACIÓN DEL PROCESO DE PRUEBA
16.0 La necesidad de un modelo de madurez de prueba 537 16.1

Enfoque para el desarrollo del modelo 538 16.2 Representación
del modelo de mejora de procesos 543 16.3 La estructura de TMM: los
niveles de madurez de prueba 545 16.4 El modelo de evaluación de TMM:
enfoque de diseño 548 16.5 Los componentes del modelo de evaluación de
TMM 549
16.5.1 Selección y capacitación del equipo de evaluación 549 16.5.2

El procedimiento de evaluación 551
16.5.3 El cuestionario de evaluación de TMM 556 16.6 El
procedimiento de clasificación de TMM 558 16.7 Formularios y

herramientas para el apoyo a la evaluación 562
xiv | Contenido
16.8 Relación del TMM con otros modelos de mejora de procesos 563 16.9 Aplicaciones
industriales del TMM 569
16.9.1 Aplicación TMM I: evaluación de la usabilidad del TMM

Cuestionario 569
16.9.2 Aplicación TMM II: Identificación de riesgos y áreas problemáticas de
prueba 572
16.9.3 Aplicación TMM III: Consultoría de pruebas de software 573
16.9.4 Aplicación TMM IV: Papel de los factores humanos en el proceso
Evaluación 576
16.9.5 Lecciones aprendidas de los estudios TMM 581
Referencias 583
APÉNDICE I: REFERENCIAS RELACIONADAS CON LA PRUEBA 587
APÉNDICE II: PLAN DE PRUEBA DE MUESTRA 611
APÉNDICE III: PRUEBA DE MADUREZ MODELO 633
Parte 1: El cuestionario TMM 633 Sección

1. Instrucciones para el encuestado 634 Sección 2.
Identificación y antecedentes del encuestado 635 Sección 3.
Antecedentes organizacionales 637 Sección 4. Las preguntas TMM
639 Sección 5. Preguntas de la herramienta de prueba 659 Sección
6. Preguntas de tendencias de prueba 662 Sección 7. Comentarios
de los encuestados 663 Sección 8. Glosario de términos relacionados
con TMM 663 Parte 2: Actividades, tareas y responsabilidades de
TMM 670
Índice 701
PREFACIO
El desarrollo de software se está convirtiendo en una disciplina de ingeniería. indica-

Las partes de esta nueva dirección se pueden encontrar, por ejemplo, en el ''Software
Engineering Body of Knowledge (SWEBOK)'' y el código de ética que se han desarrollado
recientemente a través de los esfuerzos de los grupos de trabajo conjuntos IEEE/ACM
[1,2]. También se están desarrollando procedimientos de concesión de licencias para
ingenieros de software. Las pruebas de software son una subdisciplina en este campo emergente.
La industria del software está buscando y promoviendo activamente
profesionales que estén educados y capacitados en las áreas de pruebas y
control de calidad, y que promuevan el desarrollo de software de alta calidad.
Las escuelas de posgrado han ido respondiendo lentamente a esta necesidad de la
industria, y un número cada vez mayor ofrece cursos centrados en las pruebas de
software y el control de calidad como parte de los programas de grado avanzado en
ingeniería de software. Para respaldar estos programas, así como las necesidades
educativas de los profesionales en ejercicio de la industria, se necesita un nuevo tipo de
libro sobre pruebas de software. El libro debe tener una orientación de ingeniería/proceso
y promover el crecimiento y el valor de las pruebas de software como profesión. Este
texto fue desarrollado para satisfacer estas necesidades. Ha sido diseñado para servir
como (i) un texto para estudiantes matriculados en una clase de evaluación/control de
calidad de nivel de posgrado, y (ii) una fuente de conocimiento y una herramienta de
aprendizaje para los profesionales que trabajan actualmente en el campo.
Prefacio
xi |
El texto es único en su enfoque para presentar el campo del software.

pruebas. Introduce conceptos de prueba que son gerenciales, técnicos y
de naturaleza orientada a procesos. Se enfatiza el proceso debido a su importancia
papel en todas las disciplinas de la ingeniería. La aplicación generalizada del modelo
de madurez de capacidad (CMM) y otros modelos de mejora de procesos atestigua
la importancia del proceso en el desarrollo de software actual.
industria. Desafortunadamente, las discusiones sobre este tema faltan en la mayoría
de los libros sobre pruebas de software.
El autor hace uso del Testing Maturity Model (TMM)SM, que
fue desarrollado para ayudar a las organizaciones a evaluar y mejorar su
procesos de prueba, como un marco guía para presentar conceptos de prueba,
y como contexto para presentar al lector los problemas del proceso de prueba. El texto
utiliza niveles y metas de TMM para apoyar una presentación estructurada de
conceptos fundamentales y avanzados relacionados con las pruebas para el lector. El TMM
estructura destaca las relaciones importantes entre el proceso de prueba
y actores clave como gerentes, evaluadores y grupos de clientes. El lector
Debe tener en cuenta que la adaptación del Modelo de Madurez de Pruebas no es una
condición necesaria para usar este texto para aprender sobre las pruebas de software. Utilizando
este texto, puede obtener información sobre buenas prácticas de prueba y problemas del proceso de prueba
y aplicarlos en el contexto de sus necesidades individuales y organizacionales.

Finalmente, el autor cree que el material educativo desarrollado para
los ingenieros de software deben guiarse por los contenidos del Cuerpo de
conocimientos de ingeniería de software (SWEBOK). En este contexto, este texto se
esfuerza por cubrir muchos de los temas descritos en "Pruebas de software".
capítulo del SWEBOK. También cubre material de los capítulos sobre
''Calidad del Software'' y ''Proceso de Ingeniería del Software''
Metas
En vista del crecimiento de la profesión de ingeniería de software, los requisitos

educativos de un especialista en pruebas de software y la necesidad de enfatizar los
problemas del proceso, los objetivos del autor para este texto son:
• introducir conceptos, técnicas y mejores prácticas de prueba de una manera

sistemática que refleje una evolución ordenada del crecimiento del proceso de prueba
tanto a nivel individual como organizacional;
Prefacio | xvii
• introducir una visión de las pruebas como un proceso que pasa por un conjunto de
etapas evolutivas hasta un estado óptimo de mejora continua;
• introducir conceptos, estándares, mediciones y prácticas de calidad de software

que apoyen la producción de software de calidad;
• permitir que un profesional de software construya un proceso de prueba individual

del más alto calibre que sea integrable con un proceso de prueba organizacional;
• permitir que un profesional de software actúe como agente de cambio cuando una
organización decida que su proceso general de pruebas necesita mejoras;
• introducir los conceptos de evaluación y mejora del proceso de prueba

y su importancia para la industria del software;
• apoyar el crecimiento de la profesión de especialista en pruebas de software

proporcionando la formación necesaria para un profesional en ese campo.
Organización y Características
Cada capítulo de este texto cubre un tema relacionado con la gestión, técnica y/o
proceso relacionado con las pruebas. Los temas están diseñados para apoyar el
crecimiento del lector como especialista en exámenes. Dentro de cada capítulo, se
describe la relación del contenido del capítulo con uno o más objetivos de madurez de TMM.
Los primeros nueve capítulos contienen material básico que permite al lector dominar
los conceptos fundamentales de las pruebas a nivel técnico y aprender sobre los
conceptos básicos de gestión que promueven un proceso de pruebas repetible y
definido. Estos capítulos también destacan la importancia de un grupo de prueba
independiente y promueven el seguimiento y control del proceso de prueba. Los
objetivos de madurez en los niveles 2 y 3 del TMM están integrados en el material
del capítulo.
Los capítulos 10 a 15 cubren temas más avanzados relacionados con los niveles
4 y 5 del TMM. Estos capítulos respaldan las revisiones como una actividad de
prueba y la automatización de las actividades de prueba con herramientas. También
promueven la evaluación cualitativa y cuantitativa del proceso de prueba y su
evolución continua. También se aborda la evaluación cualitativa y cuantitativa del
producto de software bajo prueba. El capítulo 16 proporciona una discusión de la prueba
Prefacio
xviii |
evaluación de procesos utilizando el modelo de evaluación TMM, y describe

Algunas aplicaciones del TMM en la industria.
Las últimas secciones del texto son sus apéndices. Apéndice I, denominado
"Referencias complementarias", contiene una colección de referencias relacionadas con
las pruebas que el lector encontrará útiles para complementar el material en el
texto. En este apéndice una bibliografía completa, ordenada alfabéticamente
por autor que incluye todas las referencias en los capítulos del libro.
También contiene una lista de libros de texto, documentos y sitios de Internet adicionales.
que son ricas fuentes de material para el especialista en pruebas. Ellos apoyan
crecimiento profesional continuo en un campo en rápida evolución. Apéndice II
contiene un plan de prueba de muestra para ilustrar los contenidos típicos de tal
documento. El Apéndice III contiene el Cuestionario de TMM, los algoritmos de
clasificación y el conjunto completo de Actividades, Tareas y Responsabilidades de TMM
(ATR) para aquellos lectores interesados en la evaluación del proceso de prueba.
Otras características a tener en cuenta en este texto incluyen definiciones de términos clave en
cada capítulo que se muestran en cursiva. Al final de la mayoría de los capítulos.

el lector encontrará ejercicios que le ayudarán a aprender los conceptos
que se discuten. Algunos ejercicios brindan experiencia práctica en la aplicación de los
conceptos. Se incluye un conjunto de referencias al final de cada capítulo.
para el lector que desee una discusión más profunda de los temas.
Este texto es una de las herramientas que puedes utilizar para desarrollarte como profesional.
probador de software. Para usar el texto de manera efectiva, debe tener un fondo
en conceptos básicos de ingeniería de software y algo de experiencia en software
desarrollo. El mejor enfoque para aprender el material es leer el
capítulos cuidadosamente y resuelva los ejercicios al final de cada capítulo.
Comentarios de un instructor con respecto a los ejercicios de tarea y
exámenes también es muy valioso. Las discusiones con instructores, compañeros de
clase y/o colegas también lo ayudarán a integrar y aclarar conceptos. El objetivo del
autor es ayudarlo a acumular el conocimiento y la experiencia que necesita para
desarrollarse como probador de software profesional.
Público objetivo
Los lectores que se beneficiarían de este texto son estudiantes universitarios y

estudiantes de posgrado en ciencias de la computación y programas de ingeniería de
software, y profesionales de software que estén interesados en mejorar su
habilidades de prueba y aprender más sobre la prueba como proceso. Para estudiantes,
Prefacio | xix
el texto es una herramienta que se puede utilizar para desarrollar las habilidades de prueba necesarias
convertirse en un probador de software profesional. Para aquellos en la industria del

software, puede ayudar a mejorar las habilidades de prueba y proporcionar pautas para
evaluar y mejorar los procesos de pruebas organizacionales. Para usar el texto
efectivamente, los lectores deben tener conocimientos básicos de ingeniería de software y
algo de experiencia en el desarrollo de software.
Notas para los educadores
Este texto se puede utilizar para varios tipos de cursos de posgrado, incluidos los
en pruebas de software, aseguramiento de la calidad del software, verificación de software y
validación e ingeniería de sistemas. También se puede utilizar como texto para un
curso de pregrado de ingeniería de software de dos semestres.
Para los educadores que utilizan este libro como texto para un curso de un semestre en
Las pruebas de software, que cubren los primeros diez capítulos y el Capítulo 14, le darán
sus estudiantes una base sólida en los fundamentos de las pruebas para que puedan
convertirse en probadores de software profesionales. Los capítulos que cubren temas más
avanzados, incluido el TMM, se pueden analizar si el tiempo lo permite. A los estudiantes
se les debe asignar problemas de tarea de los capítulos y recibir retroalimentación sobre
sus resultados. Un proyecto de equipo sugerido para el curso es
el desarrollo de un plan de prueba del sistema con archivos adjuntos para un sistema de
software simple. Los estudiantes necesitarán una descripción de requisitos y/o diseño
dependiendo de la naturaleza del plan de prueba solicitado.
Para los profesionales de software que usan este texto, hay mucho material que
puede ayudar a mejorar su conocimiento del campo de las pruebas. El material
relacionados con el TMM se pueden aplicar para evaluar y hacer cambios en su
proceso de prueba de una manera consistente con las metas organizacionales.
permisos
Definiciones de términos IEEE, componentes del plan de prueba y pasos en una metodología
de métricas de calidad de software reimpreso con permiso de:
Glosario estándar IEEE de terminología de ingeniería de software (IEEE

Estándar 610.12-1990), copyright 1990 por IEEE
Estándar IEEE para documentación de prueba de software (ANSI/IEEE Std

829–1983), copyright 1983 por IEEE.
Prefacio
XX |
Estándar IEEE para una metodología de métricas de calidad de software (IEEE

Std 1061–1992), copyright 1993, por IEEE.
El IEEE se exime de cualquier responsabilidad u obligación que resulte de la

colocación y el uso de la manera descrita.
Pearson Education ha otorgado permiso para el uso de material de ''Métricas
de software: establecimiento de un programa para toda la empresa'' de Grady y
Caswell.
[1] A. Abran, J. Moore, P. Bourque, R. Dupuis, editores, "Guía del cuerpo de conocimientos de
ingeniería de software, versión de prueba", IEEE Computer Society Press, Los Alamitos, CA, 2001.
[2] D. Gotterbarn, K. Miller, S. Rogerson, "Computer Society and ACM Approv Software
Engineering Code of Ethics", IEEE Computer, vol. 32, núm. 10, 1999, págs. 84–88.
Expresiones de gratitud
En la preparación de este texto he contado con el apoyo de muchas personas,

incluidos familiares, colegas, estudiantes y editores. El apoyo ha sido de muchas
formas diferentes. En primer lugar, me gustaría agradecer a mi universidad, el
Instituto de Tecnología de Illinois, por concederme una licencia sabática que me
permitió completar una buena parte de este texto. Los colegas que han apoyado
mi trabajo incluyen a la profesora Anneliese A. Andrews (Universidad Estatal de
Colorado), el profesor Robert Carlson (Instituto de Tecnología de Illinois) y la
profesora Martha Evens (Instituto de Tecnología de Illinois).
He usado borradores de este texto en mi clase de ''Pruebas de software y

control de calidad'' durante los últimos dos años y me gustaría agradecer a los
estudiantes de estas clases (CS 589) por sus comentarios sobre el texto. Milisegundo.
Yachai Limpiyakorn, quien fue el asistente de enseñanza del curso, también
proporcionó comentarios útiles.
Quisiera reconocer las importantes contribuciones de los Dres. Taratip
Suwannasart y Ariya Homyen (Wichitnuntakorn) al desarrollo del modelo Testing
Maturity durante el curso de sus estudios de doctorado.
El modelo proporcionó el marco para el desarrollo de este texto.
Mis editores en Springer-Verlag, en particular, Wayne Wheeler y Wayne Yuhasz,
han sido muy pacientes y me han brindado sugerencias y comentarios útiles que
he incorporado al texto. Los revisores anónimos también han sido muy útiles al
sugerir cambios que mejoraron la calidad del texto.
Prefacio | xxx
Finalmente, quisiera agradecer a mi esposo, Ray Burnstein, por su

aliento y consejo en la redacción de este texto, y por siempre
''estar ahí'' para mí. Me gustaría agradecer a mis hijos Kenneth y Jona que han
expresado su entusiasmo por este proyecto de autor. Gracias
usted uno y todos!
Ilene Burnstein
Esta página se dejó en blanco intencionalmente

1
INTRODUCCIÓN A
PRUEBA COMO
ACTIVIDAD DE INGENIERÍA
1.0 La profesión en evolución de la ingeniería de software
Este es un momento emocionante para ser un desarrollador de software. Los sistemas

de software son cada vez más difíciles de construir. Están jugando un papel cada vez
más importante en la sociedad. Las personas con habilidades de desarrollo de software
están en demanda. Están disponibles nuevos métodos, técnicas y herramientas para
apoyar las tareas de desarrollo y mantenimiento.
Debido a que el software ahora tiene un papel tan importante en nuestras vidas,
tanto económica como socialmente, existe presión para que los profesionales del software
se concentren en los problemas de calidad. El software de mala calidad que puede causar
la pérdida de vidas o propiedades ya no es aceptable para la sociedad. Las fallas pueden
resultar en pérdidas catastróficas. Las condiciones exigen personal de desarrollo de
software con interés y capacitación en las áreas de calidad de producto y proceso de software.
El personal altamente calificado garantiza que los productos de software se construyan a
tiempo, dentro del presupuesto y sean de la más alta calidad con respecto a atributos
como confiabilidad, corrección, facilidad de uso y la capacidad de cumplir con todos los
requisitos del usuario.
2
| Introducción a las pruebas como actividad de ingeniería
En respuesta a la demanda de software de alta calidad y la necesidad

para los profesionales de software bien educados, hay un movimiento para cambiar
la forma en que se desarrolla y mantiene el software, y la forma en que los desarrolladores
y los mantenedores son educados. De hecho, la profesión de ingeniería de software está
emergiendo lentamente como una disciplina de ingeniería formal. como nuevo
disciplina estará relacionada con otras disciplinas de la ingeniería y tendrá asociado un
cuerpo definido de conocimientos, un código de ética y un
proceso de certificación. El movimiento hacia esta nueva profesión es el
enfoque de toda la edición de noviembre/diciembre de 1999 de IEEE Software.
La educación y formación de ingenieros en cada disciplina de la ingeniería.
se basa en la enseñanza de principios científicos relacionados, procesos de ingeniería,
estándares, métodos, herramientas, medidas y mejores prácticas como
se muestra en la Figura 1.1. Como reflejo del movimiento hacia un software
profesión de ingeniería, y estas necesidades educativas, el IEEE Computer
Society y la Association of Computing Machinery (ACM), las dos
principales sociedades de profesionales del software, han designado tareas conjuntas
efectivo. Los objetivos de los equipos del grupo de trabajo son definir un cuerpo de conocimiento
que cubre la disciplina de ingeniería de software, para discutir la naturaleza de
educación para esta nueva profesión, y definir un código de ética para la
ingeniero de software [1]. Previendo el surgimiento de esta nueva ingeniería
disciplina, algunos estados ya están preparando exámenes de licencia para
ingenieros de software [2].
Este texto se basa en la filosofía de que el desarrollo de software
debe verse y enseñarse como una disciplina de ingeniería y esa calidad
tanto en el proceso como en el producto son de primera importancia para los profesionales
de este campo. El uso de un enfoque de ingeniería para el desarrollo de software implica que:
• el proceso de desarrollo se entiende bien;
• los proyectos están planificados;
•
los modelos de ciclo de vida están definidos y se cumplen;
• existen estándares para productos y procesos;
• se emplean mediciones para evaluar la calidad del producto y del proceso;
• los componentes se reutilizan;

1.0 La profesión en evolución de la ingeniería de software | 3
Ingenieria
Eléctrica
Principios básicos
Ingeniería Ingeniería
Procesos
Mecánica Química
Estándares
Mediciones
Instrumentos
Métodos Ingeniería
Ingeniería civil
Informática
Mejores prácticas
Código ético
Cuerpo de
conocimientos
Trabajo en progreso
Pruebas
Ingeniería de software
HIGO. 1.1
Elementos de las disciplinas de ingeniería.
• los procesos de validación y verificación juegan un papel clave en la determinación

de la calidad;
• los ingenieros tienen la educación, capacitación y certificación adecuadas.
El objetivo de este texto es apoyar la educación de un profesional de software

llamado especialista en pruebas. Un especialista en pruebas es aquel cuya educación
se basa en los principios, prácticas y procesos que constituyen la disciplina de
ingeniería de software, y cuyo enfoque específico está en un área de esa disciplina:
las pruebas de software. Un especialista en pruebas que esté capacitado como
ingeniero debe tener conocimiento de los principios, procesos, mediciones, estándares,
planes, herramientas y métodos relacionados con las pruebas, y debe aprender a
aplicarlos a las tareas de prueba que se realizarán.
4
Este texto tiene como objetivo educar al lector en la disciplina de las

pruebas. Los conceptos de prueba, en lugar de presentarse como una colección
aislada de actividades técnicas y de gestión, se integrarán en el contexto de un
proceso de prueba de calidad que crece en competencia y utiliza principios de
ingeniería para guiar el crecimiento de la mejora. De esta forma, todos los
elementos de la disciplina de evaluación emergen de manera incremental y
permiten que el evaluador agregue conocimientos y habilidades que siguen un
patrón evolutivo natural. El marco integrador para presentar los conceptos de
prueba en este texto es el Testing Maturity Model (TMM)SM [3–7].* En las
secciones siguientes se ofrece una explicación del valor de este enfoque
orientado al proceso para presentar la disciplina de las pruebas de software. de este capitu
1.1 El papel del proceso en la calidad del software
La necesidad de productos de software de alta calidad ha presionado a los

profesionales a identificar y cuantificar factores de calidad como la usabilidad, la
capacidad de prueba, la mantenibilidad y la confiabilidad, y a identificar prácticas
de ingeniería que respalden la producción de productos de calidad que tengan
estos atributos favorables. Entre las prácticas identificadas que contribuyen al
desarrollo de software de alta calidad están la planificación de proyectos, la
gestión de requisitos, el desarrollo de especificaciones formales, el diseño
estructurado con uso de ocultación y encapsulación de información, el diseño y
la reutilización de código, las inspecciones y revisiones, las medidas de
productos y procesos, educación y formación de profesionales del software,
desarrollo y aplicación de herramientas CASE, uso de técnicas de prueba
eficaces e integración de actividades de prueba en todo el ciclo de vida. Además
de identificar estas mejores prácticas técnicas y de gestión individuales, los
investigadores de software se dieron cuenta de que era importante integrarlas
en el contexto de un proceso de desarrollo de software de alta calidad. El
proceso en este contexto se define a continuación y se ilustra en la Figura 1.2.
Proceso, en el dominio de la ingeniería de software, es el conjunto de métodos,

prácticas, estándares, documentos, actividades, políticas y procedimientos que los
ingenieros de software utilizan para desarrollar y mantener un sistema de software y
sus artefactos asociados, como proyectos y planes de prueba, diseño documentos, códigos y ma
*Modelo de madurez de prueba y TMM son marcas de servicio del Instituto de Tecnología de Illinois.
1.1 El papel del proceso en la calidad del software | 5
Actividades
Políticas Normas y
documentos
planes
Prácticas
Proceso de
ingeniería,
versión 1.0
Métodos y Procedimientos
técnicas
Evolución del proceso
Versión
1.1
Versión
2.0
Versión
XX
HIGO. 1.2
Componentes de un proceso de ingeniería.
También quedó claro que agregar prácticas individuales a un proceso

de desarrollo de software existente de manera ad hoc no era satisfactorio. El
proceso de desarrollo de software, como la mayoría de los artefactos de
ingeniería, debe diseñarse. Es decir, debe diseñarse, implementarse,
evaluarse y mantenerse. Como en otras disciplinas de ingeniería, un proceso
de desarrollo de software debe evolucionar de manera consistente y
predecible, y las mejores prácticas técnicas y de gestión deben integrarse de manera s
Se desarrollaron modelos como Capability Maturity Model (CMM)* y SPICE
para abordar problemas de procesos [8,9]. Estos modelos permiten que una
organización evalúe su proceso de software actual y obtenga una comprensión
de su estado. Los modelos brindan un fuerte respaldo para la mejora
incremental del proceso, en consonancia con la evolución histórica del
proceso y la aplicación de principios de calidad. Los modelos han re-
*El Modelo de Madurez de Capacidad y CMM son marcas registradas del Instituto de Ingeniería de
Software y la Universidad Carnegie Mellon.
6
recibido mucha atención de la industria, y se han invertido recursos en

esfuerzos de mejora de procesos con muchos éxitos registrados [8].
Todos los modelos de mejora de procesos de software que han tenido amplia
aceptación en la industria son modelos de alto nivel, en el sentido de que se enfocan
en el proceso de software como un todo y no ofrecen soporte adecuado para
evaluar y mejorar subprocesos específicos de desarrollo de software tales
como diseño y pruebas. La mayoría de los ingenieros de software estarían de acuerdo en que las pruebas
es un componente vital de un proceso de software de calidad, y es uno de los más

actividades desafiantes y costosas llevadas a cabo durante el desarrollo de software
y mantenimiento. A pesar de su papel vital en la producción de calidad
software, evaluación de procesos existentes y modelos de mejora tales como
CMM, Bootstrap e ISO-9000 no han abordado adecuadamente los problemas del proceso
de prueba [3–7,10]. El modelo de madurez de prueba (TMM), como se describe a lo largo
de este texto, ha sido desarrollado en el Instituto de Illinois
de Tecnología por un grupo de investigación encabezado por el autor, para subsanar las
deficiencias de estas áreas.
1.2 Pruebas como proceso
El proceso de desarrollo de software ha sido descrito como una serie de

fases, procedimientos y pasos que dan como resultado la producción de un software
producto. Incrustados en el proceso de desarrollo de software hay varios
otros procesos, incluidas las pruebas. Algunos de estos se muestran en la Figura 1.3.
La prueba en sí está relacionada con otros dos procesos llamados verificación y validación,
como se muestra en la Figura 1.3.
La validación es el proceso de evaluar un sistema o componente de software durante, o

al final del ciclo de desarrollo para determinar si cumple
requisitos especificados [11].
La validación generalmente se asocia con las pruebas tradicionales basadas en la ejecución,

es decir, ejercitar el código con casos de prueba.
La verificación es el proceso de evaluar un sistema o componente de software

para determinar si los productos de una fase de desarrollo determinada satisfacen las condic
impuesto al comienzo de esa fase [11].
1.2 Pruebas como proceso | 7
Proceso de desarrollo de software

Análisis de
requerimientos
proceso
Proceso
de especificación
del producto
Proceso de diseño
Proceso de prueba
Verificación Validación
proceso proceso
HIGO. 1.3
Procesos de ejemplo integrados en el
proceso de desarrollo de software.
La verificación generalmente se asocia con actividades como inspecciones y revisiones de

entregables de software. La prueba en sí se ha definido de varias maneras. A continuación se
muestran dos definiciones.
Las pruebas generalmente se describen como un grupo de procedimientos llevados a cabo
para evaluar algún aspecto de una pieza de software.
La prueba se puede describir como un proceso utilizado para revelar defectos en el software
y para establecer que el software ha alcanzado un grado específico de calidad con respecto a
los atributos seleccionados.
Tenga en cuenta que estas definiciones de prueba son de naturaleza general. Cubren las
actividades de validación y verificación, e incluyen en las pruebas todo lo siguiente: revisiones
técnicas, planificación de pruebas, seguimiento de pruebas, diseño de casos de prueba, prueba
unitaria, prueba de integración, prueba del sistema, prueba de aceptación y prueba de
usabilidad. Las definiciones también describen las pruebas como un proceso de doble
propósito: uno que revela defectos y otro que se utiliza para evaluar los atributos de calidad
del software, como la confiabilidad, la seguridad, la facilidad de uso y la corrección.
También tenga en cuenta que la prueba y la depuración, o la localización de fallas, son

dos actividades muy diferentes. El proceso de depuración comienza después de que se hayan
realizado las pruebas y el probador haya notado que el software no se está comportando
según lo especificado.
8
La depuración o localización de fallas es el proceso de (1) ubicar la falla o

defecto, (2) reparar el código y (3) volver a probar el código.
La prueba como proceso tiene aspectos económicos, técnicos y de gestión.

Los aspectos económicos están relacionados con la realidad de que los recursos y el
tiempo están disponibles para el grupo de prueba de forma limitada. De hecho, la
prueba completa en muchos casos no es práctica debido a estas limitaciones
económicas. Una organización debe estructurar su proceso de prueba para que pueda
entregar el software a tiempo y dentro del presupuesto, y también satisfacer los requisitos del clie
Los aspectos técnicos de las pruebas se relacionan con las técnicas, métodos,
mediciones y herramientas que se utilizan para garantizar que el software que se está
probando esté libre de defectos y sea lo más confiable posible para las condiciones y
restricciones bajo las cuales debe operar. La prueba es un proceso, y como proceso
debe gestionarse. Como mínimo, eso significa que se debe definir y documentar una
política organizacional para las pruebas. Los procedimientos y pasos de prueba deben
definirse y documentarse. Las pruebas deben planificarse, los probadores deben estar
capacitados, el proceso debe tener objetivos cuantificables asociados que puedan
medirse y monitorearse. Las pruebas como proceso deberían poder evolucionar hasta
un nivel en el que existan mecanismos para realizar mejoras continuas.
1.3 Una descripción general del modelo de madurez de las pruebas
Varias cuestiones importantes relacionadas con las pruebas han surgido de la

discusión anterior. hemos aprendido que
1. existe una demanda de software de alta calidad con pocos defectos; 2. el

proceso es importante en la disciplina de ingeniería de software; 3. Las pruebas
de software son un importante subproceso de desarrollo de software; 4. Los modelos
existentes de evaluación y mejora del software no han abordado adecuadamente los
problemas de prueba.
Ahora se presenta al lector una introducción al modelo de prueba de madurez como un

marco para la discusión de estos temas y como un medio para abordarlos. El modelo
se analiza con más detalle en capítulos posteriores de este texto. El TMM se centra en
las pruebas como un proceso en sí mismo que

| 9
puede ser evaluado y mejorado. En el dominio de pruebas posibles beneficios

de mejora del proceso de prueba son los siguientes:
• evaluadores más inteligentes
• software de mayor calidad
• la capacidad de cumplir con el presupuesto y los objetivos de programación
• planificación mejorada
• la capacidad de cumplir objetivos de prueba cuantificables
La mejora del proceso de prueba está respaldada por el conjunto de niveles y madurez.
metas en el TMM. El logro de los objetivos de madurez da como resultado una mejora
incremental del proceso de prueba de una organización. El modelo de evaluación de TMM
admite la evaluación del proceso de prueba. La sección 1.3 da la
lector una descripción general del conjunto de niveles y objetivos de madurez. Los niveles y
objetivos sirven como pautas para la organización de este texto y definen el
secuencia para la introducción de los conceptos de prueba.
El desarrollo de la versión 1.0 del TMM estuvo guiado por el trabajo
hecho en el modelo de madurez de capacidad para software (CMM), un proceso
modelo de mejora que ha recibido un amplio apoyo de la industria del software en los Estados
Unidos [8]. El CMM se clasifica arquitectónicamente como un modelo de mejora de procesos
por etapas. Este tipo de arquitectura de modelo de mejora de procesos prescribe las etapas
que una organización
debe proceder de manera ordenada para mejorar su proceso de desarrollo de software. Se
pueden describir otros modelos de mejora de procesos
como tener un tipo continuo de arquitectura, por ejemplo, el SPICE
modelo. En este tipo de arquitectura no hay un conjunto fijo de niveles o etapas
para proceder. Una organización que aplica un modelo continuo puede
seleccionar áreas de mejora de muchas categorías diferentes.
El CMM tiene cinco niveles o etapas que describen un patrón evolutivo de madurez del
proceso de software y sirven como guía para la mejora.
Cada nivel tiene un conjunto de Áreas de Proceso Clave (KPA) que una organización necesita
concentrarse para alcanzar la madurez a ese nivel. También hay prácticas clave
asociados con cada nivel que brindan apoyo para implementar mejoras en ese nivel. El CMM
también cuenta con un procedimiento de evaluación
que permite a una organización evaluar el estado actual de su software
proceso e identificar las fortalezas y debilidades del proceso.
Introducción a las pruebas como actividad de ingeniería

10 |
Otras fuentes de entrada para el desarrollo de TMM incluyen Gelperin y Hetzel's

Evolution of Testing Model [12], que describe la evolución del proceso de prueba en
la industria durante un período de 40 años; el modelo de prueba de Beizer, que
describe la evolución del pensamiento del probador individual [13]; y el Informe de
encuesta de prácticas de prueba de software [14], que identifica las mejores prácticas
de prueba en la industria a partir de 1993. En capítulos posteriores de este texto se
encuentran más detalles relacionados con estos elementos, así como con los
objetivos de madurez de TMM y el Modelo de evaluación de TMM.
1.3.1 Niveles TMM

Como en el caso del CMM, el TMM también sigue lo que se denomina una
arquitectura por etapas para los modelos de mejora de procesos. Contiene
etapas o niveles por los que pasa una organización a medida que su proceso
de prueba evoluciona de uno ad hoc y no administrado a uno administrado,
definido, medido y optimizable. La estructura interna del TMM es rica en
prácticas de prueba que se pueden aprender y aplicar de manera sistemática
para respaldar un proceso de prueba de calidad que mejora en pasos
incrementales. Hay cinco niveles en el TMM que prescriben una jerarquía de
madurez y un camino evolutivo para probar la mejora del proceso. Las
características de cada nivel se describen en términos de capacidad de prueba,
objetivos organizacionales y roles/responsabilidades de los actores clave en el
proceso de prueba, los administradores, desarrolladores/probadores y usuarios/clientes.
Cada nivel a excepción del nivel 1 tiene una estructura que consta de lo
siguiente:
• Un conjunto de objetivos de madurez. Los objetivos de madurez identifican los

objetivos de mejora de las pruebas que deben abordarse para lograr la madurez
en ese nivel. Para ubicarse en un nivel, una organización debe satisfacer las
metas de madurez en ese nivel. Los niveles de TMM y los objetivos de madurez
asociados se muestran en la Figura 1.5.
• Subobjetivos de madurez de apoyo. Definen el alcance, los límites y

logros necesarios para un nivel en particular.
• Actividades, tareas y responsabilidades (ATR). Los ATR abordan cuestiones

de implementación y adaptación organizacional en cada TMM

| 11
Niveles
indicar Contiene
Pruebas
Metas de madurez
capacidad
Apoyado por
Subobjetivos de madurez
conseguido por
Actividades/tareas/responsabilidades
dirección organizado por
Implementación
y organizacional Puntos de vista críticos
adaptación
Gerente Desarrollador/probador usuario/cliente
HIGO. 1.4
La estructura interna de TMM
niveles de madurez.
nivel. Se identifican actividades y tareas de apoyo y se asignan responsabilidades a los

grupos apropiados.
La figura 1.4 ilustra la estructura de niveles de TMM. Cada objetivo de madurez en

cada nivel de TMM está respaldado por un conjunto de subobjetivos de madurez. La madurez
Las submetas se logran a través de un grupo de actividades y tareas con responsabilidades
(ATR). Las actividades y tareas se definen en términos de acciones.
que debe realizarse a un nivel determinado para mejorar la capacidad de prueba; ellos
están vinculados a compromisos organizacionales. Se asignan responsabilidades
para estas actividades y tareas a tres grupos que los desarrolladores de TMM creen
representan a los participantes clave en el proceso de prueba: gerentes, desarrolladores/
probadores y usuarios/clientes. En el modelo se los denomina “los tres
puntos de vista críticos (CV).” La definición de sus roles es esencial en el desarrollo de un
marco de madurez. La visión del gerente involucra compromiso y habilidad.
12 | Introducción a las pruebas como actividad de ingeniería
capacidad para realizar actividades y tareas relacionadas con la mejora de la capacidad de prueba.
La visión del desarrollador/probador abarca las actividades y tareas técnicas que, cuando se
aplican, constituyen prácticas de prueba de calidad. La vista del usuario o del cliente se define
como una vista de cooperación o de apoyo. Los desarrolladores/evaluadores trabajan con grupos
de clientes/usuarios en actividades y tareas relacionadas con la calidad que conciernen a las
necesidades orientadas al usuario. La atención se centra en solicitar el apoyo, el consenso y la
participación del cliente/usuario en actividades como el análisis de requisitos, las pruebas de
usabilidad y la planificación de pruebas de aceptación.
Las metas de madurez en cada nivel del TMM se muestran en la Figura 1.5. Se describen
completamente en artículos publicados y también se enumeran a continuación junto con una breve
descripción de las características de una organización en cada nivel de TMM [2–6]. La descripción
presentará al lector el camino evolutivo prescrito en el TMM para la mejora del proceso de prueba.
Se proporcionan detalles adicionales en capítulos de texto posteriores.
Nivel 1—Inicial: (Sin metas de madurez)
En el nivel 1 de TMM, las pruebas son un proceso caótico; está mal definido y no se distingue de
la depuración. A menudo no existe un conjunto documentado de especificaciones para el
comportamiento del software. Las pruebas se desarrollan de manera ad hoc una vez que se
completa la codificación. Las pruebas y la depuración se intercalan para eliminar los errores del
software. El objetivo de las pruebas es mostrar que el software funciona (es mínimamente funcional)
[1,5]. Los productos de software a menudo se lanzan sin garantía de calidad. Faltan recursos,
herramientas y personal debidamente capacitado. Este tipo de organización estaría en el nivel 1
del CMM.
Nivel 2—Fase Definición: (Objetivo 1: Desarrollar objetivos de prueba y depuración;

Meta 2: Iniciar un proceso de planificación de pruebas; Meta 3: Institucionalizar técnicas y métodos
básicos de prueba)
En el nivel 2 de TMM, la prueba se separa de la depuración y se define como una fase que sigue a
la codificación. Es una actividad planificada; sin embargo, la planificación de la prueba en el nivel 2
puede ocurrir después de la codificación por razones relacionadas con la inmadurez del proceso
de prueba. Por ejemplo, puede existir la percepción en el nivel 2 de que todas las pruebas se basan
en la ejecución y dependen del código; por lo tanto, debe planificarse solo cuando el código esté
completo.
El objetivo principal de las pruebas en este nivel de madurez es mostrar que el software
cumple con las especificaciones establecidas [2,5]. Técnicas básicas de prueba
1.3 Una descripción general del modelo de madurez de las pruebas | 13
Nivel 5: Optimización/Prevención de
Defectos y Control de Calidad
Optimización del proceso de prueba

Control de calidad
Aplicación de datos de proceso para la prevención de defectos
Nivel 4: Gestión y Medición
Evaluación de la calidad del software

Establecer un programa de medición de pruebas
Establecer un programa de revisión en toda la organización
Nivel 3: Integración
Controlar y monitorear el proceso de prueba.

Integrar las pruebas en el ciclo de vida del software
Establecer un programa de formación técnica.
Establecer una organización de pruebas de software
Nivel 2: Definición de Fase
Institucionalizar técnicas y métodos de prueba básicos.

Iniciar un proceso de planificación de pruebas
Desarrollar objetivos de prueba y depuración.
Nivel 1: Inicial
HIGO. 1.5
La estructura de 5 niveles del modelo

de madurez de prueba.
y los métodos están en su lugar; por ejemplo, el uso de estrategias de prueba de

caja negra y caja blanca, y una matriz de referencia cruzada de validación. Las
pruebas tienen varios niveles: hay niveles de unidad, integración, sistema y
aceptación. Muchos problemas de calidad en este nivel de TMM ocurren porque la
planificación de las pruebas ocurre tarde en el ciclo de vida del software. Además,
los defectos se propagan desde los requisitos y las fases de diseño hasta el código. No hay re
14 | Introducción a las pruebas como actividad de ingeniería
programas hasta ahora para abordar este importante tema. Código postal, las pruebas basadas en la
ejecución todavía se consideran la actividad de prueba principal.
Nivel 3—Integración: (Objetivo 1: Establecer una organización de prueba de software;
Meta 2: Establecer un programa de capacitación técnica; Objetivo 3: Integrar las pruebas
en el ciclo de vida del software; Objetivo 4: Pruebas de control y seguimiento)
En el nivel 3 de TMM, la prueba ya no es una fase que sigue a la codificación, sino que es
integrado en todo el ciclo de vida del software. Las organizaciones pueden aprovechar
las habilidades de planificación de pruebas que han adquirido en el nivel 2. A diferencia del nivel 2, la
planificación de las pruebas en el nivel 3 de TMM comienza en la fase de requisitos y
continúa durante todo el ciclo de vida respaldado por una versión del modelo V
(ver Sección 8.7) [2]. Los objetivos de la prueba se establecen con respecto a la
requisitos basados en las necesidades del usuario/cliente, y se utilizan para el diseño de casos de prueba.
Hay una organización de pruebas, y las pruebas son reconocidas como profesionales.
actividad. Hay una organización de capacitación técnica con un enfoque de prueba.
Las pruebas se supervisan para garantizar que van de acuerdo con el plan y las acciones.
se puede tomar si se producen desviaciones. Las herramientas básicas respaldan las actividades de prueba clave,
y el proceso de prueba es visible en la organización. Aunque las organizaciones de este nivel comienzan
a darse cuenta del importante papel de las revisiones en la calidad
control, no existe un programa de revisión formal y las revisiones aún no se llevan a cabo.
lugar a lo largo del ciclo de vida. Un programa formal de medición de prueba no ha
aún no se han establecido para cuantificar un número significativo de atributos de procesos y productos.
Nivel 4—Gestión y medición: (Objetivo 1: Establecer un programa de revisión en toda la organización;
Objetivo 2: Establecer un programa de medición de pruebas; Objetivo 3: Evaluación de la calidad del
software)
La prueba en el nivel 4 se convierte en un proceso que se mide y cuantifica.
Las revisiones en todas las fases del proceso de desarrollo ahora se reconocen como
actividades de prueba/control de calidad. Son un complemento a las pruebas basadas en la ejecución
para detectar defectos y evaluar y mejorar la calidad del software.
Se puede utilizar una extensión del modelo V, como se muestra en la Figura 1.6, para respaldar la
implementación de este objetivo [6,7]. Los productos de software se prueban
para atributos de calidad tales como confiabilidad, usabilidad y mantenibilidad.
Los casos de prueba de todos los proyectos se recopilan y registran en una base de datos de casos de
prueba con el fin de reutilizarlos y realizar pruebas de regresión. Defectos
se registran y se les asigna un nivel de gravedad. Algunas de las deficiencias que se presentan

| 15
Ejecutar prueba de aceptación
Ejecutar prueba del sistema

Especificar requisitos
Requisitos Aceptación del sistema

revisión
revisión/auditoría del plan de prueba
Especificar/diseñar Código
Pruebas de sistema/aceptación
Diseño Ejecutar integración

pruebas
Plan de prueba de integración

Revisión de diseño
revisión/auditoría
Pruebas de integración
unidad de ejecución
Código
pruebas
Revisiones de código plan de prueba unitaria

revisión/auditoría
Pruebas unitarias
HIGO. 1.6
El modelo V extendido/ modificado.
en el proceso de prueba se deben a la falta de una filosofía de prevención de defectos,

y la porosidad del soporte automatizado para la recolección, análisis y
difusión de métricas relacionadas con las pruebas.
Introducción a las pruebas como actividad de ingeniería

16 |
Nivel 5—Optimización/Prevención de Defectos/Control de Calidad: (Objetivo 1:

Prevención de defectos; Meta 2: Control de calidad; Objetivo 3: Optimización del
proceso de prueba)
Debido a la infraestructura que existe a través del logro de los objetivos de

madurez en los niveles 1 a 4 del TMM, ahora se dice que el proceso de prueba
está definido y gestionado; su costo y efectividad pueden ser monitoreados.
En el nivel 5, existen mecanismos para que las pruebas se puedan ajustar y mejorar
continuamente. Se practican la prevención de defectos y el control de calidad. El muestreo
estadístico, las mediciones de los niveles de confianza, la confianza y la confiabilidad impulsan el
proceso de prueba. Las herramientas automatizadas son totalmente compatibles con la ejecución
y repetición de casos de prueba. Las herramientas también brindan soporte para el diseño de
casos de prueba, el mantenimiento de elementos relacionados con la prueba y la recopilación y
el análisis de defectos. La recopilación y el análisis de métricas relacionadas con las pruebas
también cuentan con soporte de herramientas. La reutilización de procesos también es una
práctica en el nivel 5 de TMM respaldada por una biblioteca de activos de procesos (PAL).
TÉRMINOS CLAVE
depuración
Proceso
Pruebas
Validación
Verificación
EJERCICIOS
1. ¿Cuáles son las diferencias entre prueba y depuración? ¿Qué tareas específicas
están involucradas en cada uno? ¿Qué grupos deberían tener la responsabilidad de
cada uno de estos procesos?
2. ¿Cuáles son las diferencias entre verificación y validación? ¿Cómo maneja su

organización cada una de estas actividades?
3. Utilizando la versión del modelo V que se muestra en la figura 1.6, describa las
actividades relacionadas con las pruebas que se deben realizar y por qué se deben
realizar durante las siguientes fases del proceso de desarrollo de software:
especificación de requisitos, diseño, codificación, instalación.

| 17
4. Identificar los miembros de los tres grupos críticos en el proceso de prueba.
¿Cómo se representan en la estructura de TMM?
5. Su organización ha trabajado muy duro para mejorar su proceso de prueba. La

evaluación del proceso de prueba más reciente utilizando el modelo de madurez
de prueba mostró que está en el nivel 3 de TMM. ¿Cómo describiría su proceso
de prueba actual en función de esa evaluación? ¿Cuáles son los objetivos de
madurez que ha logrado en ese nivel de TMM?
REFERENCIAS
[1] D. Gotterbarn, K. Miller, S. Rogerson, "Computer Society and [7] I. Burnstein, T. Suwanassart, CR Carlson, "Desarrollo de un
ACM Approv Software Engineering Code of Ethics", IEEE modelo de madurez de prueba: Parte II", Cross Talk: Journal of
Computer, vol. 32, núm. 10, octubre de 1999, págs. 84–88. Defense Software Engineering, vol. 9, núm. 9, septiembre de
1996, págs. 19–26.
[2] J. Velocidad. “¿Qué quiere decir con que no puedo llamarme [8] M. Paulk, C. Weber, B. Curtis, M. Chrissis, El modelo de
ingeniero de software?” IEEE Software, noviembre/ diciembre de madurez de la capacidad, Addison-Wesley, Reading MA, 1995.
1999, págs. 45–50.
[3] I. Burnstein, A. Homyen, T, Suwanassart, G. Saxena, R. [9] M. Paulk, M. Konrad, "Una descripción general del proyecto
Grom, "Un modelo de madurez de prueba para la evaluación y SPICE de ISO", American Programmer, vol. 7, núm. 2, febrero de
mejora del proceso de prueba de software" 1994, págs. 16–20.
Software Quality Professional, Sociedad Estadounidense para la
Calidad, vol. 1, núm. 4, septiembre de 1999, págs. 8–21. [10] L Osterweil, "Direcciones estratégicas en la calidad del
software", ACM Computing Surveys, vol. 28, núm. 4, 1996, págs.
[4] I. Burnstein, A. Homyen, T, Suwanassart, G. Saxena, R.
738–750.
Grom, "Uso del modelo de madurez de prueba para evaluar y
mejorar su proceso de prueba de software" [11] Glosario estándar IEEE de terminología de ingeniería de
proc. de la Semana Internacional de la Calidad Conf. (QW'99), software (Std610.12-1990). Copyright 1990 por IEEE. Reservados
San José, CA, mayo de 1999. todos los derechos.
[5] I. Burnstein, A. Homyen, R. Grom, CR Carlson, "Un modelo [12] D. Gelperin, B. Hetzel, “El crecimiento de las pruebas de
para evaluar la madurez del proceso de prueba" software”, CACM, vol. 31, núm. 6, 1988, págs. 687–
CrossTalk: Revista del Departamento de Ingeniería de Software 695.
de Defensa, vol. 11, núm. 11, noviembre de 1998, págs. 26–30.
[13] B. Beizer, Software Testing Techniques, segunda edición,
Van Nostrand Reinhold, Nueva York, 1990.
[6] I. Burnstein, T. Suwanassart, CR Carlson, "Desarrollo de un
modelo de madurez de prueba: Parte I", Cross Talk: Journal of [14] J. Durant, Informe de encuesta sobre prácticas de prueba de
Defense Software Engineering, vol. 9, núm. 8, agosto de 1996, software, Centro de investigación de prácticas de software, Informe
págs. 21–24. técnico, TR5-93, mayo de 1993.

2
PRUEBAS
FUNDAMENTOS
2.0 Inicio de un estudio de pruebas
El estudio de las pruebas de software en este texto comienza con una descripción de los elementos de
vocabulario esenciales relacionados con las pruebas. El conocimiento de estos términos básicos es esencial
para garantizar que las discusiones sobre los conceptos de prueba que siguen se basen en un vocabulario
común ampliamente aceptado en la academia y la industria. También se presenta aquí un conjunto de
principios de prueba basados en la ejecución para ayudar a los especialistas en pruebas. Proporcionan una
base para desarrollar conocimientos sobre pruebas, adquirir habilidades de prueba y desarrollar un grupo
esencial de mejores prácticas. Esta introducción al campo de las pruebas de software concluye con una
descripción del rol del especialista en pruebas en una organización de desarrollo de software.
2.1 Definiciones básicas
A continuación, se incluye un conjunto de definiciones básicas de los términos que se utilizarán en este texto.
Definiciones adicionales aparecen en capítulos subsiguientes para ayudar en el concepto

Fundamentos de las pruebas

20 |
comprensión. Muchas de las definiciones utilizadas en este texto se basan en

los términos descritos en la Colección de estándares IEEE para ingeniería de
software [1]. La colección de estándares incluye el Glosario estándar de
terminología de ingeniería de software de IEEE, que es un diccionario dedicado
a describir el vocabulario de ingeniería de software [2]. Contiene definiciones de
trabajo de términos que están en uso tanto en el mundo académico como en el industrial.
Cuando una definición se ha adaptado directamente de un documento de estándares
IEEE, se proporciona una referencia específica.
errores
Un error es un error, un concepto erróneo o un malentendido por parte de un desarrollador

de software.
En la categoría de desarrollador incluimos ingenieros de software, programadores,

analistas y probadores. Por ejemplo, un desarrollador puede malinterpretar una
notación de diseño o un programador puede escribir incorrectamente un nombre de variable.
Averías (Defectos)
Se introduce una falla (defecto) en el software como resultado de un error. Se trata de una
anomalía en el software que puede hacer que se comporte de forma incorrecta y no

conforme a su especificación.
Las fallas o defectos a veces se denominan "errores". El uso del último término
trivializa el impacto que tienen las fallas en la calidad del software. El uso del término
"defecto" también se asocia con artefactos de software, como requisitos y documentos
de diseño. Los defectos que ocurren en estos artefactos también son causados por
errores y generalmente se detectan en el proceso de revisión.
fallas
Una falla es la incapacidad de un sistema o componente de software para realizar sus
funciones requeridas dentro de los requisitos de rendimiento especificados [2].
Durante la ejecución de un componente o sistema de software, un probador,

desarrollador o usuario observa que no produce los resultados esperados. En
algunos casos, un tipo particular de mala conducta indica que cierto tipo de falla es
2.1 Definiciones básicas | 21

presente. Podemos decir que el tipo de mala conducta es síntoma de la falta. Un
desarrollador/probador experimentado tendrá una base de conocimiento de fallas/síntomas/
casos de fallas (modelos de fallas como se describe en el Capítulo 3) almacenada en la
memoria.
El comportamiento incorrecto puede incluir la producción de valores incorrectos para
las variables de salida, una respuesta incorrecta por parte de un dispositivo o una imagen
incorrecta en una pantalla. Durante el desarrollo, los probadores suelen observar las fallas,
y los desarrolladores las localizan y reparan. Cuando el software está en funcionamiento,
los usuarios pueden observar fallas que se informan a la organización de desarrollo para
que se puedan realizar las reparaciones.
Una falla en el código no siempre produce una falla. De hecho, el software defectuoso
puede funcionar durante un largo período de tiempo sin mostrar ningún comportamiento
incorrecto. Sin embargo, cuando se dan las condiciones adecuadas, la falla se manifestará
como una falla. Voas [3] se encuentra entre los investigadores que discuten estas
condiciones, que son las siguientes:
1. La entrada al software debe causar que la declaración defectuosa sea

ejecutado.
2. El enunciado erróneo debe producir un resultado diferente al enunciado correcto. Este

evento produce un estado interno incorrecto para el software.
3. El estado interno incorrecto debe propagarse a la salida, para que el resultado de la

falla sea observable.
Se dice que el software que revela fácilmente sus fallas como fallas es más comprobable.
Desde el punto de vista de los probadores, este es un atributo de software deseable. Los
probadores deben trabajar con los diseñadores para asegurarse de que el software se
pueda probar. Hay otros significados asignados a los términos "comprobable" y
"comprobable" que se describirán más adelante en este capítulo.
Casos de prueba
El enfoque habitual para detectar defectos en una pieza de software es que el probador
seleccione un conjunto de datos de entrada y luego ejecute el software con los datos de
entrada bajo un conjunto particular de condiciones. Para decidir si

22 |
el software ha pasado o fallado la prueba, el probador también necesita saber

cuáles son las salidas adecuadas para el software, dado el conjunto de entradas
y condiciones de ejecución. El probador agrupa esta información en un elemento
llamado caso de prueba.
Un caso de prueba en un sentido práctico es un elemento relacionado con la prueba que contiene la
siguiente información:
1. Un conjunto de entradas de prueba. Estos son elementos de datos recibidos de una fuente externa por
el código bajo prueba. La fuente externa puede ser hardware, software o humano.
2. Condiciones de ejecución. Estas son condiciones requeridas para ejecutar la prueba, por ejemplo, un
determinado estado de una base de datos o una configuración de un dispositivo de hardware.
3. Productos esperados. Estos son los resultados especificados que producirá el código.
bajo prueba.
La descripción anterior especifica la información mínima que debe encontrarse

en un caso de prueba y se basa en la descripción IEEE para este elemento [2]. Una
organización puede decidir que se debe incluir información adicional en un caso de
prueba para aumentar su valor como objeto reutilizable o para proporcionar información
más detallada a los probadores y desarrolladores. Como ejemplo, se podría incluir un
componente de objetivo de prueba para expresar objetivos de prueba, como ejecutar
un grupo particular de declaraciones de código o verificar que se haya satisfecho un
requisito dado. Los desarrolladores, evaluadores y/o el personal de control de calidad
del software deben participar en el diseño de una especificación de caso de prueba
que describa con precisión el contenido de cada caso de prueba. El contenido y su
formato deben aparecer en los estándares de documentación de prueba para la
organización. El Capítulo 7 ofrece una descripción más detallada de un caso de
prueba y otros elementos relacionados con la prueba.
Prueba
Una prueba es un grupo de casos de prueba relacionados, o un grupo de casos de prueba y procedimientos
de prueba relacionados (pasos necesarios para llevar a cabo una prueba, como se describe en el Capítulo 7).
Un grupo de pruebas relacionadas a veces se denomina conjunto de pruebas. Un grupo de

pruebas relacionadas que están asociadas con una base de datos y que generalmente se
ejecutan juntas, a veces se denomina conjunto de pruebas [4].

Prueba de oráculo
Un oráculo de prueba es un documento o pieza de software que permite a los probadores determinar
si una prueba ha sido aprobada o reprobada.
Un programa, o un documento que produce o especifica el resultado esperado de una prueba, puede
servir como un oráculo [5]. Los ejemplos incluyen una especificación
(especialmente uno que contiene condiciones previas y posteriores), un documento de diseño,
y un conjunto de requisitos. Otras fuentes son conjuntos de pruebas de regresión. Él
Las suites suelen contener componentes con resultados correctos para versiones anteriores del
software. Si algunas de las funciones de la nueva versión
se superpone a la versión anterior, se puede extraer la información de Oracle adecuada. Un programa
confiable en funcionamiento puede servir como su propio oráculo en una situación en la que se está
transfiriendo a un nuevo entorno. En este caso su
el comportamiento previsto no debería cambiar en el nuevo entorno [4].
banco de pruebas
Un banco de pruebas es un entorno que contiene todo el hardware y el software necesarios
para probar un componente de software o un sistema de software.
Esto incluye todo el entorno de prueba, por ejemplo, simuladores, emuladores, verificadores de
memoria, sondas de hardware, herramientas de software y todos los demás.
elementos necesarios para apoyar la ejecución de las pruebas.
Calidad del software
En el Glosario estándar de terminología de ingeniería de software de IEEE [2] se encuentran dos
definiciones concisas de calidad :
1. La calidad se relaciona con el grado en que un sistema, componente del sistema o proceso
cumple con los requisitos especificados.
2. La calidad se relaciona con el grado en que un sistema, componente del sistema o proceso
satisface las necesidades o expectativas del cliente o usuario.
Para determinar si un sistema, componente del sistema o proceso es de alta calidad, utilizamos
lo que se denomina atributos de calidad. Estos son
características que reflejan calidad. Para artefactos de software podemos medir


24 |
el grado en que poseen un atributo de calidad dado con métricas de calidad.
Una métrica es una medida cuantitativa del grado en que un sistema,

componente del sistema o proceso posee un atributo dado [2].
Hay métricas de producto y de proceso. Un ejemplo muy común de una métrica de

producto de software es el tamaño del software, generalmente medido en líneas de
código (LOC). Dos ejemplos de métricas de proceso de uso común son los costos y el
tiempo requerido para una tarea determinada. Muchos otros ejemplos se encuentran en
Grady [6]. El Apéndice I brinda referencias adicionales que analizan las métricas en
profundidad. Las métricas de calidad son un tipo especial de métrica.
Una métrica de calidad es una medida cuantitativa del grado en que un

elemento posee un atributo de calidad dado [2].
Se han descrito muchos atributos de calidad diferentes para el software, por ejemplo, en
los estándares IEEE para la metodología de métricas de calidad del software y el trabajo
de Schulmeyer y Grady [6–8]. Algunos ejemplos de atributos de calidad con breves
explicaciones son los siguientes:
corrección: el grado en que el sistema realiza su función prevista
Confiabilidad: el grado en que se espera que el software realice las funciones

requeridas en las condiciones establecidas durante un período de tiempo establecido.
usabilidad: se relaciona con el grado de esfuerzo necesario para aprender, operar,

preparar la entrada e interpretar la salida del software
Integridad: se relaciona con la capacidad del sistema para soportar ataques tanto
intencionales como accidentales.
portabilidad: se relaciona con la capacidad del software para transferirse de un entorno

a otro
mantenibilidad: el esfuerzo necesario para realizar cambios en el software
interoperabilidad: el esfuerzo necesario para vincular o acoplar un sistema a otro.
Otro atributo de calidad que debe mencionarse aquí es la capacidad de prueba. Este
atributo es más interesante para los desarrolladores/evaluadores que para los clientes.
Se puede expresar de las dos formas siguientes:

1. la cantidad de esfuerzo necesario para probar el software para garantizar que funcione de
acuerdo con los requisitos especificados (se relaciona con la cantidad de casos de prueba
necesarios),
2. la capacidad del software para revelar defectos en condiciones de prueba (algunos software
están diseñados de tal manera que los defectos quedan bien ocultos durante las
condiciones de prueba ordinarias).
Los evaluadores deben trabajar con analistas, diseñadores y desarrolladores en todo el sistema
de vida del software para garantizar que se aborden los problemas de capacidad de prueba.
Grupo de aseguramiento de la calidad del software
El grupo de aseguramiento de la calidad del software (SQA) en una organización tiene vínculos
con problemas de calidad. El grupo actúa como representante y defensor de los clientes. Su
responsabilidad es velar por los intereses de los clientes.
El grupo de aseguramiento de la calidad del software (SQA) es un equipo de personas con
la capacitación y las habilidades necesarias para garantizar que se tomen todas las medidas
necesarias durante el proceso de desarrollo para que el software resultante cumpla con
los requisitos técnicos establecidos.
Trabajan con gerentes de proyecto y evaluadores para desarrollar políticas relacionadas con la
calidad y planes de garantía de calidad para cada proyecto. El grupo también participa en la
recopilación y el análisis de mediciones, el mantenimiento de registros y la elaboración de
informes. Los miembros del equipo de SQA participan en revisiones (consulte el Capítulo 10) y
auditorías (tipos especiales de revisiones que se enfocan en el cumplimiento de estándares,
pautas y procedimientos), registran y rastrean problemas y verifican que se hayan realizado las
correcciones. También desempeñan un papel en la gestión de la configuración del software
(consulte el Capítulo 10).
Reseñas
A diferencia de las técnicas de prueba dinámicas basadas en la ejecución que se pueden usar
para detectar defectos y evaluar la calidad del software, las revisiones son un tipo de técnica de
prueba estática que se puede usar para evaluar la calidad de un artefacto de software, como un
documento de requisitos, un plan de prueba , un documento de diseño, un componente de
código. Las revisiones también son una herramienta que se puede aplicar para revelar defectos
en este tipo de documentos. Sigue una definición.

26 |
Una revisión es una reunión de grupo cuyo propósito es evaluar un artefacto de software o un
conjunto de artefactos de software.
La composición de un grupo de revisión puede estar formada por gerentes, clientes,

desarrolladores, evaluadores y otro personal, según el tipo de artefacto que se esté
revisando. Un grupo de control de calidad del software suele realizar un tipo especial
de revisión denominada auditoría con el fin de evaluar el cumplimiento de las
especificaciones y/o estándares y/o acuerdos contractuales.
2.2 Principios de prueba de software
Los principios juegan un papel importante en todas las disciplinas de la ingeniería y, por
lo general, se introducen como parte de la formación académica en cada rama de la
ingeniería. La figura 1.1 muestra el papel de los principios básicos en varias disciplinas
de ingeniería. Los principios de las pruebas son importantes para los ingenieros/
especialistas en pruebas porque proporcionan la base para desarrollar el conocimiento
de las pruebas y adquirir habilidades para las pruebas. También brindan orientación
para definir las actividades de prueba como se realizan en la práctica de un especialista en prueba
Un principio se puede definir como:
1. una ley, doctrina o suposición general o fundamental; 2. una regla o

código de conducta; 3. las leyes o hechos de la naturaleza que subyacen
al funcionamiento de un aparato artificial
dispositivo.
Al extender estas tres definiciones al dominio de la ingeniería de software, podemos

decir que los principios de la ingeniería de software se refieren a leyes, reglas o
doctrinas que se relacionan con los sistemas de software, cómo construirlos y cómo se
comportan. En el dominio del software, los principios también pueden referirse a reglas
o códigos de conducta relacionados con los profesionales que diseñan, desarrollan,
prueban y mantienen sistemas de software. Las pruebas como componente de la
disciplina de ingeniería de software también tienen un conjunto específico de principios
que sirven como guía para el probador. Guían a los probadores en la definición de
cómo probar los sistemas de software y proporcionan reglas de conducta para los
probadores como profesionales. Glen ford Myers ha esbozado este conjunto de
principios de prueba basados en la ejecución en su libro pionero, The Art of Software Testing [9]. A
2.2 Principios de prueba de software | 27

principios se describen a continuación. Los principios 1 a 8 y 11 se derivan directamente
del conjunto original de Myers. El autor ha reformulado estos principios, y
también ha realizado modificaciones al conjunto original para reflejar la evolución de
prueba de un arte, a un proceso relacionado con la calidad en el contexto de un
disciplina de ingeniería. Tenga en cuenta que los principios que se indican a continuación sólo se relacionan
a las pruebas basadas en la ejecución. Los principios relacionados con las revisiones, la prueba
de corrección y la certificación como actividades de prueba no están cubiertos.
Principio 1. La prueba es el proceso de ejercitar un componente de software

utilizando un conjunto seleccionado de casos de prueba, con la intención de (i) revelar
defectos, y (ii) evaluar la calidad.
Los ingenieros de software han hecho grandes progresos en el desarrollo de métodos para
prevenir y eliminar defectos. Sin embargo, los defectos ocurren y tienen
un impacto negativo en la calidad del software. Los probadores necesitan detectar estos defectos.
antes de que el software esté operativo. Este principio apoya las pruebas
como una actividad basada en la ejecución para detectar defectos. También admite la separación
de la prueba de la depuración, ya que la intención de esta última es localizar
defectos y reparar el software. El término "componente de software" se utiliza
en este contexto para representar cualquier unidad de software que varíe en tamaño y complejidad
desde un procedimiento o método individual hasta un software completo
sistema. El término “defectos” tal como se utiliza en este principio y en los subsiguientes
representa cualquier desviación en el software que tenga un impacto negativo en
su funcionalidad, desempeño, confiabilidad, seguridad y/o cualquier otra de sus
atributos de calidad especificados.
Bertolino, en la Guía para el Cuerpo de Conocimientos de Ingeniería de Software, da una
visión de las pruebas como un "proceso dinámico que ejecuta un programa en entradas
valiosas" [10]. Esta vista, así como la definición de prueba
dados en el Capítulo 1, sugieren que además de detectar defectos, probar
es también un proceso utilizado para evaluar la calidad del software. El propósito de
El primero ha sido descrito en el párrafo anterior. en el caso de la
En segundo lugar, el probador ejecuta el software utilizando casos de prueba para evaluar
propiedades como la confiabilidad, la usabilidad, la mantenibilidad y el nivel de rendimiento. Los
resultados de las pruebas se utilizan para comparar las propiedades reales del software con las
especificadas en el documento de requisitos como objetivos de calidad.
Deben abordarse las desviaciones o la imposibilidad de alcanzar los objetivos de calidad.

28 |
El lector debe tener en cuenta que las pruebas pueden tener un alcance más
amplio, como se describe en los modelos de mejora del proceso de prueba, como el
TMM y otros modelos de calidad. Las revisiones y otras técnicas de análisis estático
se incluyen bajo el paraguas de las pruebas en los modelos. Estas técnicas, y cómo
se relacionan con la detección de defectos y la evaluación de la calidad, se
describirán en capítulos posteriores de este texto.
Principio 2. Cuando el objetivo de la prueba es detectar defectos,

entonces un buen caso de prueba es aquel que tiene una alta probabilidad
de revelar defectos aún no detectados.
El Principio 2 respalda el diseño cuidadoso de las pruebas y proporciona un criterio

con el que evaluar el diseño de casos de prueba y la eficacia del esfuerzo de prueba
cuando el objetivo es detectar defectos. Requiere que el evaluador considere el
objetivo de cada caso de prueba, es decir, qué tipo específico de defecto debe
detectar el caso de prueba. De esta manera, el probador aborda la prueba de la
misma manera que un científico aborda un experimento. En el caso del científico hay
de por medio una hipótesis que quiere probar o refutar por medio del experimento.
En el caso del probador, la hipótesis está relacionada con la sospecha de ocurrencia
de tipos específicos de defectos. El objetivo de la prueba es probar/refutar la
hipótesis, es decir, determinar si el defecto específico está presente/ausente. Con
base en la hipótesis, se seleccionan las entradas de prueba, se determinan las
salidas correctas y se ejecuta la prueba. Los resultados se analizan para probar/
refutar la hipótesis. El lector debe darse cuenta de que se invierten muchos recursos
en una prueba, recursos para diseñar los casos de prueba, ejecutar las pruebas y
registrar y analizar los resultados. Un probador puede justificar el gasto de los
recursos mediante un diseño de prueba cuidadoso para que se apoye el principio 2.
Principio 3. Los resultados de las pruebas deben inspeccionarse meticulosamente.
Los evaluadores deben inspeccionar e interpretar cuidadosamente los resultados de las

pruebas. Pueden ocurrir varios escenarios erróneos y costosos si no se tiene cuidado. Por ejemplo:

• Se puede pasar por alto una falla y se le puede otorgar a la prueba un estado de "aprobado"
cuando en realidad el software no pasó la prueba. Las pruebas pueden continuar en base a
resultados de pruebas erróneos. El defecto puede revelarse en alguna etapa posterior de la
prueba, pero en ese caso puede ser más costoso y difícil de localizar y reparar.
• Se puede sospechar una falla cuando en realidad no existe ninguna. En este caso, se le puede
otorgar a la prueba un estado de “reprobado”. Se puede gastar mucho tiempo y esfuerzo
tratando de encontrar el defecto que no existe. Un reexamen cuidadoso de los resultados de
la prueba finalmente podría indicar que no ha ocurrido ninguna falla.
• Es posible que se malinterprete el resultado de una prueba de calidad, lo que da como resultado
una repetición innecesaria del trabajo o la supervisión de un problema crítico.
Principio 4. Un caso de prueba debe contener la salida o resultado esperado.
A menudo es obvio para el probador novato que las entradas de prueba deben ser parte de un caso
de prueba. Sin embargo, el caso de prueba no tiene valor a menos que haya una declaración
explícita de los productos o resultados esperados, por ejemplo, se debe observar un valor de
variable específico o se debe encender un determinado botón del panel.
Los resultados esperados permiten al evaluador determinar (i) si se ha revelado un defecto y (ii) el
estado de aprobación/rechazo de la prueba. Es muy importante tener una declaración correcta de
la salida para que no se pierda tiempo innecesario debido a conceptos erróneos sobre el resultado
de una prueba. La especificación de las entradas y salidas de las pruebas debe ser parte de las
actividades de diseño de las pruebas.
En el caso de las pruebas para la evaluación de la calidad, es útil que los objetivos de calidad
se expresen en términos cuantitativos en el documento de requisitos, si es posible, para que los
evaluadores puedan comparar los atributos reales del software determinados por las pruebas con lo
que se especificó.
Principio 5. Se deben desarrollar casos de prueba para condiciones de entrada válidas

e inválidas.
Un probador no debe asumir que el software bajo prueba siempre contará con entradas válidas. Las
entradas pueden ser incorrectas por varias razones.

30 |
Por ejemplo, los usuarios de software pueden tener malentendidos o carecer de información
sobre la naturaleza de las entradas. A menudo hacen tipografía
errores incluso cuando se dispone de información completa/correcta. Los dispositivos pueden
también proporcione entradas no válidas debido a condiciones erróneas y mal funcionamiento.
El uso de casos de prueba que se basan en entradas no válidas es muy útil para revelar
defectos, ya que pueden ejercitar el código de formas inesperadas y
identificar el comportamiento inesperado del software. Las entradas no válidas también ayudan a los desarrolladores
y los probadores evalúan la robustez del software, es decir, su capacidad para

recuperar cuando ocurren eventos inesperados (en este caso, una entrada errónea).
El Principio 5 apoya la necesidad del grupo de prueba independiente llamado
en el Principio 7 por la siguiente razón. El desarrollador de un software.
componente puede estar sesgado en la selección de entradas de prueba para el componente
y especificar solo entradas válidas en los casos de prueba para demostrar que el
el software funciona correctamente. Un probador independiente también es más apto para
seleccionar entradas válidas.
Principio 6. La probabilidad de existencia de defectos adicionales en

un componente de software es proporcional al número de defectos ya detectados
en ese componente.
Lo que dice este principio es que cuanto mayor sea el número de defectos ya
detectado en un componente, es más probable que tenga defectos adicionales
cuando se somete a más pruebas. Por ejemplo, si hay dos componentes A y B, y los
probadores han encontrado 20 defectos en A y 3 defectos en B,
entonces la probabilidad de la existencia de defectos adicionales en A es mayor
que B. Esta observación empírica puede deberse a varias causas. Defectos
a menudo ocurren en grupos y, a menudo, en código que tiene un alto grado de complejidad
y está mal diseñado. En el caso de dichos componentes, los desarrolladores
y los evaluadores deben decidir si ignorar la versión actual del
componente y trabajar en un rediseño, o planear gastar pruebas adicionales
recursos en este componente para asegurar que cumpla con sus requisitos. Este problema
es especialmente importante para los componentes que implementan la misión o la seguridad
funciones críticas.
Principio 7. Las pruebas deben ser realizadas por un grupo que sea independiente
del grupo de desarrollo.

Este principio es válido tanto por razones psicológicas como prácticas. Eso
Es difícil para un desarrollador admitir o concebir que el software que tiene
creado y desarrollado puede ser defectuoso. Los evaluadores deben darse cuenta de que
(i) los desarrolladores se enorgullecen mucho de su trabajo y (ii) en un nivel práctico
puede ser difícil para ellos conceptualizar dónde se pueden encontrar los defectos.
Incluso cuando las pruebas fallan, los desarrolladores suelen tener dificultades para localizar
los defectos, ya que su modelo mental del código puede eclipsar su visión del código.
código tal como existe en la actualidad. También pueden tener conceptos erróneos o
malentendidos sobre los requisitos y especificaciones relacionados con
El software.
El requisito de un grupo de prueba independiente puede interpretarse

por una organización de varias maneras. El grupo de prueba podría implementarse como
una entidad funcional completamente separada en la organización.
Alternativamente, los probadores podrían ser miembros de un Software Quality Assurance
Grupo, o incluso ser una parte especializada del grupo de desarrollo, pero en el
especialmente en este último caso, necesitan la capacidad de ser objetivos. Informes
a una gestión separada del desarrollo puede apoyar su objetividad e independencia. Como
miembro de cualquiera de estos grupos, los deberes principales y la capacitación de los
evaluadores deben residir en las pruebas y no en
desarrollo.
Finalmente, la independencia del grupo de prueba no exige una relación adversaria
entre desarrolladores y evaluadores. Los probadores deben
No juegue juegos de "te pillé" con los desarrolladores. Los grupos deben cooperar.
para que el software de la más alta calidad sea entregado al cliente.
Principio 8. Las pruebas deben ser repetibles y reutilizables.
El Principio 2 requiere que un probador vea su trabajo como similar al de un

científico experimental. El Principio 8 exige que los experimentos en el campo de la prueba
requieran el registro de las condiciones exactas de la prueba, cualquier condición especial.
eventos que ocurrieron, equipo usado y una contabilidad cuidadosa de los
resultados. Esta información es invaluable para los desarrolladores cuando el código está
devueltos para la depuración para que puedan duplicar las condiciones de prueba. Está
también es útil para las pruebas que deben repetirse después de la reparación del defecto.
La repetición y reutilización de las pruebas también es necesaria durante la prueba de
regresión (la nueva prueba del software que ha sido modificado) en el caso de una nueva versión.

32 |
del software Los científicos esperan que los experimentos sean repetibles por otros,
¡y los probadores deben esperar lo mismo!
Principio 9. Las pruebas deben planificarse.
Los planes de prueba deben desarrollarse para cada nivel de prueba y los objetivos
para cada nivel debe describirse en el plan asociado. Los objetivos
debe expresarse de la forma más cuantitativa posible. Planes, con sus precisamente
objetivos especificados, son necesarios para garantizar que se asignan el tiempo y los recursos
adecuados para las tareas de prueba, y que las pruebas pueden ser monitoreadas
y gestionado.
Las actividades de planificación de pruebas deben llevarse a cabo en todo el software.
ciclo de vida (Principio 10). La planificación de la prueba debe coordinarse con el proyecto.
planificación. El director de pruebas y el director de proyecto deben trabajar juntos para
coordinar actividades. Los probadores no pueden planear probar un componente en un determinado
fecha a menos que los desarrolladores lo tengan disponible en esa fecha. Los riesgos de prueba deben
ser evaluado. Por ejemplo, ¿qué tan probables son los retrasos en la entrega de componentes
de software? ¿Qué componentes probablemente sean complejos y difíciles de probar? ¿Los
evaluadores necesitan capacitación adicional con las nuevas herramientas? un plan de prueba
La plantilla debe estar disponible para el administrador de pruebas para guiar el desarrollo de
el plan de acuerdo con las políticas y normas de la organización. prueba cuidadosa
la planificación evita el desperdicio de pruebas "desechables" y los ciclos improductivos y no
planificados de "prueba-parche-nueva prueba" que a menudo conducen a software de mala
calidad y la incapacidad de entregar software a tiempo y dentro del presupuesto.
Principio 10. Las actividades de prueba deben estar integradas en el software

ciclo vital.
Ya no es factible posponer las actividades de prueba hasta después del código.

ha sido escrito. Actividades de planificación de pruebas según lo respaldado por el Principio 10,
debe integrarse en el ciclo de vida del software comenzando tan pronto como en el
fase de análisis de requisitos, y continúa a lo largo del software
ciclo de vida en paralelo con las actividades de desarrollo. Además de la planificación de
pruebas, se pueden realizar otros tipos de actividades de prueba, como las pruebas de usabilidad.
también puede llevarse a cabo en las primeras etapas del ciclo de vida mediante el uso de
prototipos. Estas actividades pueden continuar hasta que el software se entregue a los
usuarios. Las organizaciones pueden utilizar modelos de proceso como el modelo V o

cualquier otro que apoye la integración de actividades de prueba en el ciclo de vida del software [11].
Principio 11. La prueba es una tarea creativa y desafiante [12].
Las dificultades y desafíos para el probador incluyen lo siguiente:
• Un probador debe tener un conocimiento completo de la disciplina de ingeniería de

software.
• Un evaluador debe tener conocimiento tanto de la experiencia como de la educación sobre

cómo se especifica, diseña y desarrolla el software.
• Un probador debe ser capaz de gestionar muchos detalles.
• Un probador necesita tener conocimiento de los tipos de fallas y dónde fallas de

un cierto tipo puede ocurrir en construcciones de código.
• Un evaluador necesita razonar como un científico y proponer hipótesis relacionadas con la

presencia de tipos específicos de defectos.
• Un probador necesita tener una buena comprensión del dominio del problema del software
que está probando. La familiaridad con un dominio puede provenir de experiencias
educativas, de capacitación y relacionadas con el trabajo.
• Un probador necesita crear y documentar casos de prueba. Para diseñar los casos de
prueba, el evaluador debe seleccionar entradas a menudo de un dominio muy amplio.
Los seleccionados deben tener la mayor probabilidad de revelar un defecto (Principio
2). Familiarizarse con el dominio es esencial.
• Un probador necesita diseñar y registrar procedimientos de prueba para ejecutar el

pruebas
• Un evaluador debe planificar las pruebas y asignar los recursos adecuados.
• Un probador necesita ejecutar las pruebas y es responsable de registrar

resultados.
• Un probador necesita analizar los resultados de la prueba y decidir sobre el éxito o el

fracaso de una prueba. Esto implica comprender y hacer un seguimiento de un enorme

34 |
gran cantidad de información detallada. También se puede requerir un probador

para recopilar y analizar mediciones relacionadas con las pruebas.
• Un evaluador debe aprender a usar herramientas y mantenerse al tanto de las últimas

avances de la herramienta de prueba.
• Un probador necesita trabajar y cooperar con los ingenieros de requisitos,

diseñadores y desarrolladores, y a menudo deben establecer una relación de
trabajo con clientes y usuarios.
• Un probador necesita ser educado y entrenado en esta área especializada y

a menudo se le pedirá que actualice sus conocimientos de forma regular
debido al cambio de tecnologías.
2.3 El papel del probador en una organización de desarrollo de software
Las pruebas a veces se ven erróneamente como una actividad destructiva. Él

El trabajo del probador es revelar defectos, encontrar puntos débiles, comportamiento inconsistente,
y circunstancias en las que el software no funciona como se esperaba. Como un
probador que necesita para sentirse cómodo con este papel. Dada la naturaleza de la
las tareas del probador, puede ver que es difícil para los desarrolladores
probar su propio código (Principios 3 y 8). Los desarrolladores ven su propio código
como su creación, su "bebé", y piensan que nada podría
estar mal con eso! Esto no quiere decir que los evaluadores y los desarrolladores sean
adversarios. De hecho, para ser más efectivo como probador se requiere una amplia
experiencia en programación para comprender cómo se construye el código.
y dónde y qué tipo de defectos es probable que ocurran. Tu objetivo como
probador es trabajar con los desarrolladores para producir software de alta calidad
que cumple con los requisitos de los clientes. Equipos de probadores y desarrolladores.
son muy comunes en la industria, y los proyectos deben tener una adecuada
relación desarrollador/probador. La proporción variará según los recursos disponibles,
el tipo de proyecto y el nivel de TMM. Por ejemplo, un sistema integrado en tiempo real
debe tener una proporción más baja de desarrollador/probador (por ejemplo,
2/1) que una simple aplicación de base de datos (4/1 puede ser adecuado). En más alto
Niveles de TMM donde hay un grupo de prueba bien definido, la relación desarrollador/
probador tendería a estar en el extremo inferior (por ejemplo, 2/1
versus 4/1) debido a la disponibilidad de recursos de prueba. Incluso en este caso,
2.3 El papel del probador en una organización de desarrollo de software

| 35
la naturaleza del proyecto y los problemas de programación del proyecto afectarían

el radio.
Además de cooperar con los desarrolladores de código, los evaluadores también deben
trabajar junto con los ingenieros de requisitos para garantizar que los requisitos
son comprobables, y para planificar el sistema y la prueba de aceptación (los clientes también son
involucrados en este último). Los evaluadores también deben trabajar con los diseñadores para planificar
para integración y prueba unitaria. Además, los gerentes de prueba deberán cooperar con los
gerentes de proyecto para desarrollar planes de prueba razonables,
y con la alta dirección para proporcionar información para el desarrollo y
mantenimiento de los estándares, políticas y objetivos de pruebas de la organización. Finalmente,
los evaluadores también deben cooperar con el personal de control de calidad del software.
y miembros del grupo de procesos de ingeniería de software. En vista de estos requisitos para
múltiples relaciones de trabajo, las habilidades de comunicación y trabajo en equipo son
necesarias para una carrera exitosa como probador.
Si es empleado de una organización evaluada en los niveles de TMM
1 o 2, es posible que no haya una función de prueba de software independiente
en su organización. Los probadores en este caso pueden ser parte del desarrollo.
grupo, pero con asignación especial a las pruebas, o pueden ser parte del
grupo de aseguramiento de la calidad del software. De hecho, incluso en los niveles 3 y superiores de
En el TMM, es posible que los evaluadores no pertenezcan necesariamente a una entidad

organizativa independiente, aunque ese es el caso ideal. Sin embargo, los probadores deben
siempre tener independencia gerencial de los desarrolladores como se describe en
Principio 8, y en el TMM en el nivel 3. Los probadores son especialistas, su principal
función es planificar, ejecutar, registrar y analizar pruebas. no depuran
software. Cuando se detectan defectos durante las pruebas, el software debe ser
devuelto a los desarrolladores que localizan el defecto y reparan el código. Él
los desarrolladores tienen una comprensión detallada del código y son los mejores
personal calificado para realizar la depuración.
Finalmente, los probadores necesitan el apoyo de la gerencia. Los desarrolladores,
analistas y personal de marketing deben darse cuenta de que los evaluadores agregan valor a
un producto de software en el sentido de que detectan defectos y evalúan la calidad lo antes posible.
posible en el ciclo de vida del software. Esto asegura que los desarrolladores publiquen
código con pocos o ningún defecto, y que los vendedores pueden entregar software que
satisface los requisitos de los clientes y es fiable, utilizable y correcto.

El software con pocos defectos también tiene la ventaja de reducir los costos, como el soporte
llamadas, reparaciones del software operativo y mala voluntad que puede convertirse en
acción legal debido a la insatisfacción del cliente. En vista de su papel esencial,
36 | Fundamentos de las pruebas
los probadores necesitan tener una visión positiva de su trabajo. La

gerencia debe apoyarlos en sus esfuerzos y reconocer sus contribuciones
a la organización.
TÉRMINOS CLAVE
Error Calidad del software

Falla grupo de aseguramiento de la calidad del software
Culpa Prueba
Métrico banco de pruebas
Métrica Caso de prueba
de calidad oráculo de prueba
Revisar
EJERCICIOS
1. Repase las definiciones de términos en este capítulo. Asegúrese de entender la diferencia
referencias entre errores, fallas y fallas.
2. Con respecto al Principio 3, ''los resultados de las pruebas deben inspeccionarse meticulosamente'',
¿por qué cree que esto es importante para el probador? Hable sobre cualquier experiencia que haya
tenido en la que la inspección deficiente de los resultados de las pruebas haya provocado retrasos en sus prueb
esfuerzos
3. Dé argumentos a favor o en contra de un grupo de pruebas independiente en una organización.
Considere el tamaño de la organización, los recursos, la cultura y los tipos de sistemas de software
desarrollados como factores en su argumento.
4. Dados los muchos desafíos que enfrenta un probador, ¿qué tipo de habilidades cree que se deben
requerir de una persona contratada como especialista en pruebas? (Puede comparar la lista de
habilidades con la lista presentada en el Capítulo 8).
5. ¿Por qué, de acuerdo con el Principio 5, es importante desarrollar casos de prueba para
condiciones de entrada válidas e inválidas?

2.3 El papel del probador en una organización de desarrollo de software | 37

REFERENCIAS
[1] Colección de estándares IEEE para ingeniería de software, edición [7] Estándar IEEE para métricas de calidad de software
de 1994, copyright 1994 de IEEE, todos los derechos Metodología (IEEE Std 1061-1992), copyright 1993,
reservado. por IEEE, todos los derechos reservados.
[2] Glosario estándar de ingeniería de software IEEE [8] G. Schulmeyer, “Métricas de aseguramiento de la calidad del
Terminología (Std 610.12-1990), copyright 1990 por software”, en Handbook of Software Quality Assurance, G.
IEEE, todos los derechos reservados. Schulmeyer y J. McManus, eds., Van Nostrand
Reinhold, Nueva York, págs. 318–342.
[3] J. Voas, "Un modelo dinámico de fallas para el análisis de
[9] G. Myers, El arte de las pruebas de software, John Wiley,
propagación e infección en programas de computadora"
Nueva York, 1979.
Doctor. Tesis, College of William and Mary en Virginia,
mayo de 1990. [10] A. Bertolino, “Software testing”, en Guía para la
Cuerpo de conocimientos de ingeniería de software, versión de prueba,
[4] B. Beizer, Software Testing Techniques, segunda edición, Van
A. Abran, J. Moore, P. Bourque, R. Dupuis, eds.
Nostrand Reinhold, Nueva York, 1990.
IEEE Computer Society Press, Los Alamitos, CA, 2001.
[5] W. Howden, "Un estudio de los métodos de análisis dinámico", en [11] G. Daich, G. Price, B. Ragland, M. Dawood, Informe de tecnologías
Técnicas de validación y pruebas de software, de prueba de software, agosto de 1994, Centro de soporte de
segunda edición, E. Miller y W. Howden, eds., IEEE tecnología de software (STSC) Hill Air
Computer Society Press, Los Alamitos, CA, 1981. Force Base, UT, agosto de 1994.
[6] R. Grady, Métricas prácticas de software para proyectos [12] J. Whittaker, “¿Qué son las pruebas de software? y por qué
Gestión y Mejora de Procesos, Prentice Hall, ¿Es tan difícil? Software IEEE, enero/ febrero. 2000,
Acantilados de Englewood, Nueva Jersey, 1992. págs. 70–79.

3
DEFECTOS, HIPÓTESIS,
Y PRUEBAS
3.0 Orígenes de los Defectos
El término defecto y su relación con los términos error y falla en el contexto del
dominio de desarrollo de software se discutió en el Capítulo 2. Los defectos tienen
efectos perjudiciales en los usuarios de software, y los ingenieros de software
trabajan muy duro para producir software de alta calidad con un bajo número de
defectos. Pero incluso en las mejores circunstancias de desarrollo, se cometen
errores, lo que da como resultado que se inyecten defectos en el software durante
las fases del ciclo de vida del software. Los defectos que se muestran en la Figura
3.1 provienen de las siguientes fuentes [1,2]:
1. Educación: el ingeniero de software no tenía la formación adecuada para

preparar el artefacto de software. No entendía cómo hacer algo. Por ejemplo,
un ingeniero de software que no entendiera el orden de precedencia de los
operadores en un lenguaje de programación en particular podría inyectar un
defecto en una ecuación que usa los operadores para un cálculo.
2. Comunicación: el ingeniero de software no fue informado sobre algo por un

colega. Por ejemplo, si el ingeniero 1 y el ingeniero 2
40 | Defectos, Hipótesis y Pruebas
Fuentes de defectos
Falta de educación
Mala comunicación
Vigilancia
Transcripción
proceso inmaduro Impacto en los artefactos de software
errores
Averías (defectos)
fallas
Impacto de las opiniones de los usuarios
Software de mala calidad

insatisfacción del usuario
HIGO. 3.1
Orígenes de los defectos.
están trabajando en módulos de interfaz, y el ingeniero 1 no informa al ingeniero

2 que no aparecerá un código de comprobación de errores en el módulo de
interfaz que está desarrollando, el ingeniero 2 podría hacer una suposición
incorrecta en relación con la presencia/ausencia de una comprobación de
errores, y resultará un defecto.
3. Descuido: El ingeniero de software omitió hacer algo. Por ejemplo, un ingeniero
de software podría omitir una declaración de inicialización.
4. Transcripción: El ingeniero de software sabe qué hacer, pero comete un error al
hacerlo. Un ejemplo simple es un nombre de variable mal escrito al ingresar el
código.
5. Proceso: El proceso utilizado por la ingeniera de software desvió sus acciones. Por
ejemplo, un proceso de desarrollo que no permitió suficiente tiempo para
desarrollar y revisar una especificación detallada podría conducir a defectos de
especificación.
Cuando se presentan defectos debido a una o más de estas circunstancias, el

software puede fallar y el impacto en el usuario varía desde un inconveniente menor
hasta hacer que el software no sea apto para su uso. Nuestro objetivo como probadores
3.0 Orígenes de los Defectos | 41
es descubrir estos defectos preferiblemente antes de que el software esté en funcionamiento.
Una de las formas en que hacemos esto es diseñando casos de prueba que tienen una alta probabilidad
de revelar defectos. ¿Cómo desarrollamos estos casos de prueba? Un enfoque es pensar en las
pruebas de software como una actividad experimental. Los resultados del experimento de prueba se
analizan para determinar si el software se ha comportado correctamente. En este escenario experimental,
un probador desarrolla hipótesis sobre posibles defectos (ver Principios 2 y 9). Luego se diseñan casos
de prueba basados en las hipótesis. Se ejecutan las pruebas y se analizan los resultados para probar o
refutar las hipótesis.
Myers tiene un enfoque similar para las pruebas. Él describe la prueba exitosa como aquella que
revela la presencia de un defecto (hipótesis) [3]. Compara el papel de un probador con el de un médico
que está en el proceso de construir un diagnóstico para un paciente enfermo. El médico desarrolla
hipótesis sobre posibles enfermedades utilizando su conocimiento de posibles enfermedades y los
síntomas de los pacientes. Se realizan pruebas para realizar el diagnóstico correcto. Una prueba exitosa
revelará el problema y el médico puede comenzar el tratamiento. Completando la analogía del médico y
el paciente enfermo, uno podría ver el software defectuoso como el paciente enfermo. Los probadores
como médicos necesitan tener conocimiento sobre posibles defectos (enfermedades) para poder
desarrollar hipótesis de defectos. Usan las hipótesis para:
• diseñar casos de prueba;
• procedimientos de prueba de diseño;
• ensamblar conjuntos de prueba;
• seleccionar los niveles de prueba (unidad, integración, etc.)
apropiado para las pruebas;
• evaluar los resultados de las pruebas.
Un experimento de prueba exitoso demostrará que la hipótesis es verdadera, es decir, el defecto
hipotético estaba presente. Entonces el software puede ser reparado (tratado).
Un concepto muy útil relacionado con esta discusión de defectos, pruebas y
el diagnóstico es el de un modelo de falla.

Defectos, Hipótesis y Pruebas

42 |
Un modelo de falla (defecto) se puede describir como un vínculo entre el error

cometido (por ejemplo, un requisito faltante, un elemento de diseño mal entendido, un error tipo
la falla/defecto en el software.
Los ingenieros de sistemas digitales describen modelos similares que relacionan

los defectos físicos en los componentes digitales con los efectos eléctricos (lógicos)
en el sistema digital resultante [4,5]. Los defectos físicos en el mundo digital pueden
deberse a errores de fabricación, desgaste de componentes y/o efectos ambientales.
Los modelos de fallas se utilizan a menudo para generar una lista de fallas o un diccionario.
Desde ese diccionario se pueden seleccionar fallas y se pueden desarrollar entradas
de prueba para componentes digitales. La eficacia de una prueba se puede evaluar
en el contexto del modelo de fallas y está relacionada con el número de fallas
expresadas en el modelo y las que realmente revela la prueba. Este punto de vista
de la eficacia de la prueba (éxito) es similar al punto de vista expresado por Myers
mencionado anteriormente.
Aunque a los ingenieros de software no les preocupan los defectos físicos, y
las relaciones entre las fallas de software, los defectos de software y sus orígenes
no se pueden mapear fácilmente, a menudo usamos el concepto de modelo de
fallas y las listas de fallas acumuladas en la memoria a partir de años de
experiencia para diseñar pruebas y para tareas de diagnóstico durante las
actividades de localización de fallas (depuración). Un ejemplo simple de un modelo
de falla que un ingeniero de software podría tener en la memoria es "se observó
un valor incorrecto para una variable porque el orden de precedencia de los
operadores aritméticos utilizados para calcular su valor era incorrecto". Esto podría
denominarse falla de "orden de precedencia de operadores incorrecto". Se cometió
un error por parte del programador que no entendió el orden en que los operadores
aritméticos ejecutarían sus operaciones. Se hicieron algunas suposiciones incorrectas sobre
El defecto (falla) afloró en el valor incorrecto de la variable. La causa probable es
la falta de educación por parte del programador. Las reparaciones incluyen
cambiar el orden de los operadores o el uso adecuado de paréntesis.
El probador con acceso a este modelo de falla y la frecuencia de ocurrencia de
este tipo de falla podría usar esta información como base para generar hipótesis
de falla y casos de prueba. Esto aseguraría que se realizaran las pruebas
adecuadas para descubrir dichas fallas.
En el pasado, los desarrolladores/evaluadores solían utilizar los modelos de fallas
y las listas de fallas de manera informal, ya que muchas organizaciones no guardaban ni
catalogaban la información relacionada con los defectos en una forma de fácil acceso. Para
3.1 Clases de defectos, repositorio de defectos y diseño de pruebas | 43
aumentar la eficacia de sus procesos de prueba y depuración, las organizaciones de software
necesitan iniciar la creación de una base de datos de defectos, o
depósito de defectos. El concepto de repositorio de defectos admite el almacenamiento y la
recuperación de datos de defectos de todos los proyectos en una ubicación de acceso central.
Un esquema de clasificación de defectos es un primer paso necesario para desarrollar el
repositorio. El repositorio de defectos se puede organizar por proyectos y para
se registran todos los defectos de los proyectos de cada clase, junto con su frecuencia de
ocurrencia, impacto en la operación y cualquier otro comentario útil. Defectos
encontrados durante las revisiones y las pruebas basadas en la ejecución deben catalogarse. Se
puede agregar información complementaria al repositorio de defectos,
por ejemplo, causas raíz del defecto (el análisis causal del defecto es parte de las actividades/
tareas/responsabilidades recomendadas en los niveles superiores del TMM).
Los miembros del personal pueden usar estos datos para la planificación de pruebas, el diseño de pruebas y
diagnóstico de fallas/defectos. Los datos también se pueden utilizar para la prevención de defectos y
esfuerzos de mejora del proceso en niveles más altos de madurez del proceso de prueba.
Para las organizaciones que están iniciando el desarrollo de un repositorio de defectos, hay
muchas fuentes de información sobre defectos, especialmente
clases de defectos, que son útiles para catalogar este tipo de información.
Por ejemplo, Beizer tiene una extensa discusión sobre los tipos de defectos que él
llama una taxonomía de errores [6]. Describe muchos tipos de defectos, por ejemplo,
requisitos, defectos estructurales, de datos, de codificación, de interfaz y de diseño de pruebas.
La clasificación estándar de IEEE para anomalías de software tiene una colección de clases de
anomalías de todas las fases del ciclo de vida [7]. Grady describe
un esquema de clasificación de defectos utilizado en Hewlett-Packard [8]. Kaner et. Alabama.
también contiene una lista extensa de lo que los autores llaman un “bosquejo
de errores comunes de software” [9]. Las categorías de defectos que se describen a continuación
utilizar una combinación de estos esquemas. La atención se centra principalmente en describir
aquellos tipos de defectos que tienen un impacto en el diseño y desarrollo de

Pruebas basadas en la ejecución.
3.1 Clases de defectos, repositorio de defectos y diseño de pruebas
Los defectos se pueden clasificar de muchas maneras. Es importante para una organización
adaptar un esquema único de clasificación y aplicarlo a todos los proyectos. No

importa qué esquema de clasificación se seleccione, algunos defectos encajarán en
más de una clase o categoría. Debido a este problema, los desarrolladores,


44 |
los evaluadores y el personal de SQA deben tratar de ser lo más consistentes posible
al registrar datos de defectos. Los tipos de defectos y la frecuencia de ocurrencia
deben usarse para guiar la planificación y el diseño de las pruebas. Se deben
seleccionar estrategias de prueba basadas en la ejecución que tengan la mayor
posibilidad de detectar tipos particulares de defectos. Es importante que las pruebas
para el software nuevo y modificado se diseñen para detectar los defectos que ocurren
con mayor frecuencia. El lector debe tener en cuenta que las pruebas basadas en la
ejecución detectarán una gran cantidad de los defectos que se describirán; sin
embargo, las revisiones de software, como se describe en el Capítulo 10, también son
una excelente herramienta de prueba para la detección de muchos de los tipos de
defectos que se analizarán en las siguientes secciones.
Los defectos, tal como se describen en este texto, se asignan a cuatro
clases principales que reflejan su punto de origen en el ciclo de vida del
software: la fase de desarrollo en la que se inyectaron. Estas clases son:
requisitos/especificaciones, diseño, código y defectos de prueba, como se
resume en la Figura 3.2. Cabe señalar que estas clases de defectos y subclases asocia
centrarse en los defectos que son el principal foco de atención de los probadores basados
en la ejecución. La lista no incluye otros tipos de defectos que se encuentran mejor en las
revisiones de software, por ejemplo, los defectos relacionados con la conformidad con
estilos y estándares. Las listas de verificación de revisión del Capítulo 10 se centran en
muchos de estos tipos de defectos.
3.1.1 Requisitos y defectos de especificación
El comienzo del ciclo de vida del software es fundamental para garantizar una alta
calidad en el software que se está desarrollando. Los defectos inyectados en fases
tempranas pueden persistir y ser muy difíciles de eliminar en fases posteriores. Dado
que muchos documentos de requisitos se escriben utilizando una representación de
lenguaje natural, muy a menudo se presentan requisitos ambiguos, contradictorios,
poco claros, redundantes e imprecisos. Las especificaciones en muchas
organizaciones también se desarrollan utilizando representaciones en lenguaje
natural, y éstas también están sujetas a los mismos tipos de problemas que se mencionaron ant
Sin embargo, en los últimos años, muchas organizaciones han introducido el uso
de lenguajes de especificación formal que, cuando se acompañan de herramientas,
ayudan a evitar descripciones incorrectas del comportamiento del sistema. Algunos
requisitos específicos/defectos de especificación son:
Especificación de requerimiento Informes/análisis de defectos

Clases de defectos
Descripcion funcional
Rasgo
Interacción de características
Descripción de la interfaz
Informes/análisis de defectos
Clases de defectos de diseño
algorítmica y de procesamiento
Control, lógica y secuencia.
Datos Repositorio de defectos
Descripción de la interfaz del módulo
Descripción de la interfaz externa Clases de defectos
Gravedad
Ocurrencias
Clases de defectos de codificación
algorítmica y de procesamiento
Control, lógica y secuencia.
Flujo de datos tipográficos
Datos
Interfaz del módulo
Documentación de código
Hardware externo, software
Clases de defectos de prueba

Arnés de prueba
Diseño de prueba
Procedimiento de prueba
HIGO. 3.2
Clases de defectos y el repositorio de defectos.
1. Defectos de descripción funcional
La descripción general de lo que hace el producto y cómo debe

comportarse (entradas/salidas) es incorrecta, ambigua y/o incompleta.
2. Defectos de características
Las características pueden describirse como características distintivas de un

componente o sistema de software.

46 |
Las características se refieren a los aspectos funcionales del software que se corresponden
con los requisitos funcionales descritos por los usuarios y clientes. Las características
también se asignan a los requisitos de calidad, como el rendimiento y la confiabilidad. Los
defectos de funciones se deben a descripciones de funciones faltantes, incorrectas,
incompletas o superfluas.
3. Defectos de interacción de características
Estos se deben a una descripción incorrecta de cómo deberían interactuar las

funciones. Por ejemplo, suponga que una característica de un sistema de software
permite agregar un nuevo cliente a una base de datos de clientes. Esta característica
interactúa con otra característica que categoriza al nuevo cliente. La función de
clasificación afecta el lugar en el que el algoritmo de almacenamiento coloca al
nuevo cliente en la base de datos y también afecta otra función que admite
periódicamente el envío de información publicitaria a los clientes en una categoría
específica. Al realizar pruebas, ciertamente queremos centrarnos en las interacciones
entre estas características.
4. Defectos de descripción de la interfaz
Estos son defectos que ocurren en la descripción de cómo el software de destino

debe interactuar con el software, el hardware y los usuarios externos.
Para detectar muchos defectos de descripción funcional, las técnicas de prueba

de caja negra, que se basan en especificaciones funcionales del software, ofrecen
el mejor enfoque. En el Capítulo 4, el lector conocerá varias técnicas de pruebas de
caja negra, como la partición de clases de equivalencia, el análisis de valores límite,
las pruebas de transición de estado y los gráficos de causa y efecto, que son útiles
para detectar tipos funcionales de detecciones. Las pruebas aleatorias y la
suposición de errores también son útiles para detectar este tipo de defectos. El
lector debe tener en cuenta que muchos de estos tipos de defectos pueden
detectarse al principio del ciclo de vida mediante revisiones de software.
Las pruebas basadas en la caja negra se pueden planificar en los niveles de unidad,
integración, sistema y aceptación para detectar requisitos/defectos de especificación.
Muchos defectos de interacción de funciones y descripción de interfaces se detectan
utilizando diseños de prueba basados en caja negra en los niveles de integración y sistema.
3.1.2 Defectos de diseño
Los defectos de diseño ocurren cuando los componentes del sistema, las interacciones
entre los componentes del sistema, las interacciones entre los componentes y el software externo
ware/hardware, o los usuarios están diseñados incorrectamente. Esto cubre defectos en

el diseño de algoritmos, control, lógica, elementos de datos, descripciones de interfaz de
módulo y descripciones de interfaz de usuario/hardware/software externo.
Al describir estos defectos, asumimos que la descripción detallada del diseño de los
módulos de software se encuentra en el nivel de pseudocódigo con pasos de
procesamiento, estructuras de datos, parámetros de entrada/salida y estructuras de
control principales definidas. Si el diseño del módulo no se describe con tanto detalle,
muchos de los tipos de defectos descritos aquí pueden trasladarse a la clase de defectos
de codificación.
1. Defectos algorítmicos y de procesamiento
Estos ocurren cuando los pasos de procesamiento en el algoritmo descritos por el

pseudocódigo son incorrectos. Por ejemplo, el pseudocódigo puede contener un cálculo
especificado incorrectamente, o los pasos de procesamiento en el algoritmo escrito en el
lenguaje del pseudocódigo pueden no estar en el orden correcto. En este último caso,
puede faltar un paso o puede estar duplicado.
Otro ejemplo de un defecto en esta subclase es la omisión de verificaciones de condiciones
de error como la división por cero. En el caso de la reutilización de algoritmos, es posible
que un diseñador haya seleccionado un algoritmo inapropiado para este problema (es
posible que no funcione en todos los casos).
2. Defectos de control, lógica y secuencia
Los defectos de control ocurren cuando el flujo lógico en el pseudocódigo no es correcto.

Por ejemplo, bifurcación pronto, bifurcación tardía o uso de una condición de bifurcación
incorrecta. Otros ejemplos en esta subclase son elementos de pseudocódigo
inalcanzables, anidamiento incorrecto, procedimientos incorrectos o llamadas a funciones.
Los defectos lógicos generalmente se relacionan con el uso incorrecto de operadores
lógicos, como menor que ( ), mayor que ( ), etc. Estos pueden usarse incorrectamente
en una expresión booleana que controla una instrucción de bifurcación.
3. Defectos de datos
Estos están asociados con el diseño incorrecto de las estructuras de datos. Por ejemplo,
es posible que a un registro le falte un campo, que se asigne un tipo incorrecto a una
variable o a un campo en un registro, que una matriz no tenga asignado el número
adecuado de elementos o que el espacio de almacenamiento se asigne incorrectamente. Suave-

48 |
Las revisiones de software y el uso de un diccionario de datos funcionan bien para revelar este
tipo de defectos.
4. Defectos de la descripción de la interfaz del módulo
Estos son defectos derivados de, por ejemplo, el uso de tipos de parámetros incorrectos
y/o consistentes, un número incorrecto de parámetros o un orden incorrecto de los
parámetros.
5. Defectos de descripción funcional
Los defectos en esta categoría incluyen elementos de diseño incorrectos, faltantes y/o
poco claros. Por ejemplo, es posible que el diseño no describa correctamente la
funcionalidad correcta de un módulo. Estos defectos se detectan mejor durante una
revisión del diseño.
6. Defectos de descripción de la interfaz externa
Estos se derivan de descripciones de diseño incorrectas para interfaces con

componentes COTS, sistemas de software externos, bases de datos y dispositivos de
hardware (por ejemplo, dispositivos de E/S). Otros ejemplos son los defectos de
descripción de la interfaz de usuario donde faltan comandos o son incorrectos,
secuencias de comandos incorrectas, falta de mensajes adecuados y/o falta de
mensajes de retroalimentación para el usuario.
3.1.3 Defectos de codificación
Los defectos de codificación se derivan de errores en la implementación del código. Las

clases de defectos de codificación están estrechamente relacionadas con las clases de
defectos de diseño, especialmente si se ha utilizado pseudocódigo para el diseño detallado.
Algunos defectos de codificación provienen de la falta de comprensión de las construcciones
del lenguaje de programación y la falta de comunicación con los diseñadores. Otros pueden
tener orígenes de transcripción u omisión. A veces puede ser difícil clasificar un defecto como
un diseño o como un defecto de codificación. Lo mejor es hacer una elección y ser coherente
cuando el mismo defecto se presenta de nuevo.
1. Defectos algorítmicos y de procesamiento
Al agregar niveles de detalle de programación al diseño, los defectos algorítmicos y de

procesamiento relacionados con el código ahora incluirían desbordamiento sin control y
3.1 Clases de defectos, repositorio de defectos y diseño de pruebas

| 49
condiciones de subdesbordamiento, comparación de tipos de datos inapropiados,

conversión de un tipo de datos a otro, ordenamiento incorrecto de los operadores
aritméticos (quizás debido a una mala comprensión de la precedencia de los
operadores), mal uso u omisión de paréntesis, pérdida de precisión y uso incorrecto de signos.
2. Defectos de Control, Lógica y Secuencia
En el nivel de codificación, estos incluirían la expresión incorrecta de declaraciones

de casos, la iteración incorrecta de bucles (problemas de límite de bucle) y rutas
faltantes.
3. Defectos Tipográficos
Estos son principalmente errores de sintaxis, por ejemplo, la ortografía incorrecta de un

nombre de variable, que generalmente son detectados por un compilador, autoevaluaciones
o revisiones por pares.
4. Defectos de inicialización
Estos ocurren cuando las declaraciones de inicialización se omiten o son incorrectas.

Esto puede ocurrir debido a malentendidos o falta de comunicación entre
programadores y/o programadores y diseñadores, descuido o falta de comprensión
del entorno de programación.
5. Defectos en el flujo de datos
Hay ciertas secuencias operativas razonables a través de las cuales deben fluir los
datos. Por ejemplo, una variable debe inicializarse antes de que se use en un cálculo
o una condición. No debe inicializarse dos veces antes
hay un uso intermedio. No se debe descartar una variable antes de usarla. Las
ocurrencias de estos usos sospechosos de variables en el código pueden, o no,
causar un comportamiento anómalo. Por lo tanto, en el sentido más estricto de la
definición del término “defecto”, no pueden considerarse como verdaderas instancias
de defectos. Sin embargo, su presencia indica que se ha producido un error y que
existe un problema que debe solucionarse.
6. Defectos de datos
Estos se indican mediante la implementación incorrecta de estructuras de datos. Por

ejemplo, el programador puede omitir un campo en un registro, un tipo incorrecto
o se asigna acceso a un archivo, es posible que no se asigne a una matriz el

número de elementos Otros defectos de datos incluyen banderas, índices y constantes
configuradas incorrectamente.
7. Defectos de la interfaz del módulo
Como en el caso de los elementos de diseño del módulo, los defectos de interfaz en el código
puede deberse al uso de tipos de parámetros incorrectos o incoherentes, un número incorrecto
de parámetros o un orden incorrecto de los parámetros. En
Además de los defectos debidos a un diseño incorrecto y una implementación incorrecta.
de diseño, los programadores pueden implementar una secuencia incorrecta de llamadas o
llamadas a módulos inexistentes.
8. Defectos en la Documentación del Código
Cuando la documentación del código no refleja lo que el programa realmente

hace, o es incompleto o ambiguo, esto se llama documentación de código
defecto. La documentación del código incompleta, poco clara, incorrecta y desactualizada
afecta los esfuerzos de prueba. Los probadores pueden ser engañados por defectos de
documentación y, por lo tanto, reutilizar pruebas incorrectas o diseñar nuevas pruebas que no
sean apropiadas para el código. Las revisiones de código son las mejores herramientas para detectar estos
tipos de defectos.
9. Hardware externo, defectos de interfaces de software
Estos defectos surgen de problemas relacionados con llamadas al sistema, enlaces a bases
de datos, secuencias de entrada/salida, uso de memoria, uso de recursos, interrupciones
y manejo de excepciones, intercambios de datos con hardware, protocolos, formatos, interfaces
con archivos de compilación y secuencias de tiempo (condiciones de carrera
puede resultar).
Muchos defectos de inicialización, flujo de datos, control y lógica que ocurren

en el diseño y el código se abordan mejor mediante técnicas de prueba de caja blanca
aplicado a nivel de unidad (módulo único). Por ejemplo, pruebas de flujo de datos.
es útil para revelar defectos de flujo de datos, la prueba de bifurcación es útil para detectar
defectos de control y la prueba de bucle ayuda a revelar defectos relacionados con bucles. Los
enfoques de las pruebas de caja blanca dependen del conocimiento del
estructura interna del software, en contraste con los enfoques de caja negra,
que sólo dependen de especificaciones de comportamiento. El lector
ser introducido a varias tcnicas basadas en caja blanca en el Captulo 5. Muchos
Los defectos de diseño y codificación también se detectan mediante pruebas de caja negra.
3.2 Ejemplos de defectos: el problema de la moneda | 51

tecnicas Por ejemplo, la aplicación de tablas de decisión es muy útil para detectar
errores en expresiones booleanas. Las pruebas de caja negra, como se describe en el
Capítulo 4, aplicadas a los niveles de integración y de sistema, ayudan a revelar
defectos de interfaz de hardware y software externos. El autor enfatizará repetidamente
a lo largo del texto que se necesita una combinación de estos dos enfoques para
revelar los muchos tipos de defectos que probablemente se encuentren en el software.
3.1.4 Defectos de prueba
Los defectos no se limitan al código y sus artefactos relacionados. Los planes de prueba, los casos de
prueba, los arneses de prueba y los procedimientos de prueba también pueden contener defectos. Los
defectos en los planes de prueba se detectan mejor utilizando técnicas de revisión.
1. Pruebe los defectos del arnés
Para probar el software, especialmente a nivel de unidad e integración, se debe

desarrollar código auxiliar. Esto se llama código de plegado de andamios o arnés de
prueba. El Capítulo 6 tiene una discusión más detallada de la necesidad de este
código. El código del arnés de prueba debe diseñarse, implementarse y probarse
cuidadosamente, ya que es un producto de trabajo y gran parte de este código puede
reutilizarse cuando se desarrollan nuevas versiones del software. Los arneses de
prueba están sujetos a los mismos tipos de códigos y defectos de diseño que se
pueden encontrar en todos los demás tipos de software.
2. Defectos en el diseño del caso de prueba y en el procedimiento de prueba
Estos incluirían casos de prueba y procedimientos de prueba incorrectos, incompletos,

perdidos e inapropiados. Una vez más, estos defectos se detectan mejor en las
revisiones del plan de prueba, como se describe en el Capítulo 10. A veces, los
defectos se revelan durante el propio proceso de prueba mediante un análisis cuidadoso
de las condiciones y los resultados de la prueba. Entonces habrá que hacer reparaciones.
3.2 Ejemplos de defectos: el problema de la moneda
Los siguientes ejemplos ilustran algunas instancias de las clases de defectos que se
analizaron en las secciones anteriores. Se muestran una especificación simple, una
descripción detallada del diseño y el código resultante, y se describen los defectos de
cada uno. Tenga en cuenta que estos defectos podrían inyectarse a través de uno o más

52 |
de las cinco fuentes de defectos discutidas al comienzo de este capítulo. También tenga
en cuenta que puede haber más de una categoría que se ajuste a un defecto determinado.
La figura 3.3 muestra un ejemplo de especificación informal para un programa
simple que calcula el valor monetario total de un conjunto de monedas. El programa
podría ser un componente de un sistema de caja registradora interactiva para
apoyar a los empleados de tiendas minoristas. Este sencillo ejemplo muestra
defectos de requisitos/especificaciones, defectos de descripción funcional y
defectos de descripción de interfaz.
Los defectos de descripción funcional surgen porque la descripción funcional
es ambigua e incompleta. No establece que la entrada, número_de_monedas, y la
salida, número_de_dólares y número_de_centavos, deban tener valores de cero o
mayores. number_of_coins no puede ser negativo, y los valores en dólares y
centavos no pueden ser negativos en el dominio del mundo real. Como
consecuencia de estas ambigüedades y especificaciones incompletas, se puede
omitir una rutina de verificación del diseño, lo que permite que el programa final
acepte valores negativos para el número_de_monedas de entrada para cada una
de las denominaciones y, en consecuencia, puede calcular un valor no válido para
los resultados.
Un conjunto más formal de condiciones previas y posteriores sería útil aquí y
abordaría algunos de los problemas con la especificación. Estos también son útiles
para diseñar pruebas de caja negra.
Una condición previa es una condición que debe cumplirse para que un componente de
software funcione correctamente.
En este caso, una condición previa útil sería una que establezca, por ejemplo:
numero_de_monedas 0
Una condición posterior es una condición que debe cumplirse cuando un componente de
software completa su operación correctamente.
Una poscondición útil sería:
numero_de_dolares, numero_de_centavos 0.
Además, la descripción funcional no es clara sobre la mayor cantidad de monedas

de cada denominación permitida y la mayor cantidad de dólares y centavos
permitidos como valores de salida.
HIGO. 3.3
Una especificación de muestra con defectos.
Los defectos de descripción de la interfaz se relacionan con la descripción ambigua

e incompleta de la interacción usuario-software. No queda claro a partir de la especificación
cómo interactúa el usuario con el programa para proporcionar entradas y cómo se reporta
la salida. Debido a las ambigüedades en la descripción de la interacción del usuario, el
software puede ser difícil de usar.
Los orígenes probables de este tipo de defectos de especificación se encuentran en
la naturaleza del proceso de desarrollo y la falta de educación y capacitación adecuadas.
Es posible que un proceso de desarrollo de baja calidad no esté asignando el tiempo y
los recursos adecuados para el desarrollo y la revisión de especificaciones. Además, es
posible que los ingenieros de software no tengan la educación y la capacitación
adecuadas para desarrollar una especificación de calidad. Todos estos defectos de
especificación, si no se detectan y reparan, se propagarán a las fases de diseño y codificación.
Las técnicas de prueba de caja negra, que estudiaremos en el Capítulo 4, ayudarán a
revelar muchas de estas debilidades funcionales.
La figura 3.4 muestra la especificación transformada en una descripción del diseño.
Existen numerosos defectos de diseño, algunos debido a la naturaleza ambigua e
incompleta de la especificación; otros son de reciente introducción.
Los defectos de diseño incluyen lo siguiente:
Defectos de control, lógica y secuenciación. El defecto en esta subclase surge de una

condición de bucle "while" incorrecta (debe ser menor o igual a seis)
Descripción del diseño para el programa calcule_coin_values
Programa calcular_valores_de_monedas
número_de_monedas es un número entero
valor_total_de_monedas es un número
entero número_de_dólares es un número
entero número_de_centavos es un número
entero valores_de_monedas es una matriz de seis números enteros que
representan el valor de cada moneda en centavos inicializados a:
1,5,10,25,25,100 comenzar
inicialice total_coin_value a cero inicialice loop_counter
a uno mientras loop_counter es menor que seis

comenzar
salida "ingrese el número de monedas"

lectura (número_de_monedas)
valor_total_de_monedas = valor_total_de_monedas +
número_de_monedas * valor_moneda[contador_bucle]
incremento contador_bucle
end
number_dollars = total_coin_value/100 number_of_cents
= total_coin_value - 100 * number_of_dollars output (number_of_dollars, number_of_cents)
end
HIGO. 3.4
Una especificación de diseño de muestra
con defectos.
Defectos algorítmicos y de procesamiento. Estos surgen de la falta de verificación de

errores para entradas incorrectas y/o no válidas, falta de una ruta donde los usuarios
puedan corregir entradas erróneas, falta de una ruta para la recuperación de errores de entrada.
La falta de una verificación de errores también podría contarse como un defecto de
diseño funcional, ya que el diseño no describe adecuadamente la funcionalidad adecuada
para el programa.
Defectos de datos. Este defecto se relaciona con un valor incorrecto para uno de los
elementos de la matriz de enteros, coin_values, que debe leer 1,5,10,25,50,100.


Defectos en la descripción de la interfaz externa. Son defectos derivados de la
ausencia de mensajes de entrada o avisos que introduzcan el programa al
usuario y solicitar entradas. El usuario no tiene forma de saber en qué orden
se debe ingresar el número de monedas para cada denominación, y cuándo
dejar de ingresar valores. Hay una ausencia de mensajes de ayuda y comentarios.
para el usuario si desea cambiar una entrada o aprender el formato correcto y
orden para introducir el número de monedas. La descripción de salida y el formato de salida
están incompletos. No hay descripción de lo que las salidas
significa en términos del dominio del problema. El usuario notará que dos valores
se emiten, pero no tiene idea de su significado.
Los defectos de diseño de control y lógica se abordan mejor mediante la caja blanca:
pruebas basadas (pruebas de condición/rama, pruebas de bucle). Estos otros diseños
los defectos necesitarán una combinación de técnicas de prueba de caja blanca y negra
para detección
La figura 3.5 muestra el código para el problema de la moneda en un lenguaje de
programación "tipo C". Sin revisiones efectivas, los defectos de especificación y diseño podrían
propagarse al código. Aquí tienen defectos adicionales
introducido en la fase de codificación.
Defectos de control, lógica y secuencia. Estos incluyen el paso de incremento de variable

de ciclo que está fuera del alcance del ciclo. Tenga en cuenta que bucle incorrecto
condición (i 6) se transfiere desde el diseño y debe contarse como un
defecto de diseño
Defectos algorítmicos y de procesamiento. El operador de división puede causar problemas

si se dividen valores negativos, aunque este problema podría eliminarse con una verificación
de entrada.
Defectos de flujo de datos. La variable total_coin_value no se inicializa. Esta usado
antes de que se defina. (Esto también podría considerarse un defecto de datos).
Defectos de datos. El error al inicializar la matriz coin_values se transfiere

del diseño y debe contarse como un defecto de diseño.
Hardware externo, defectos de interfaz de software. La llamada a la función externa “scanf”
es incorrecta. Se debe proporcionar la dirección de la variable.

(&número_de_monedas).
Defectos en la Documentación del Código. La documentación que acompaña a este

el código es incompleto y ambiguo. Refleja las deficiencias en la descripción de la interfaz
externa y otros defectos que ocurrieron durante la especificación.
/**************************************************** **************** El programa

calcule_coin_values calcula el valor en dólares y centavos de un conjunto de
monedas de diferentes dominaciones ingresadas por el usuario. Las
denominaciones son centavos, cinco centavos, diez centavos, veinticinco
centavos, medio dólar y dólares ****************************************************
****************/ principal () { int total_coin_value; int numero_de_monedas = 0; int
numero_de_dolares = 0; int numero_de-centavos = 0; int coin_values =
{1,5,10,25,25,100}; {int yo = 1; mientras (yo < 6) {
printf("Ingrese el numero de monedas\n");

scanf ("%d", numero_de_monedas);
valor_total_moneda = valor_total_moneda +
(número_de_monedas * valor_moneda{i]);
}
yo = yo + 1;
número_de_dólares = valor_moneda_total/100;
number_of_cents = total_coin_value - (100 * number_of_dollars); printf("%d\n",
numero_de_dolares); printf("%d\n", numero_de-centavos); }
/**************************************************** ***************/
HIGO. 3.5
Un ejemplo de código con defectos.
ficación y diseño. Falta información vital para cualquier persona que necesite reparar,
mantener o reutilizar este código.
Los defectos de flujo de datos de control, lógica y secuencia encontrados en este

ejemplo podrían detectarse usando una combinación de técnicas de prueba de caja blanca
y negra. Las pruebas de caja negra pueden funcionar bien para revelar el micrófono
algorítmico y los defectos de datos. Los defectos de documentación del código requieren
una revisión del código para su detección. El defecto de la interfaz del software externo
probablemente sería detectado por un buen compilador.
La mala calidad de este pequeño programa se debe a defectos inyectados durante
varias de las fases del ciclo de vida con causas probables que van desde la falta de
educación, un proceso deficiente, hasta la supervisión por parte de los diseñadores y
3.3 Compatibilidad con desarrolladores/evaluadores para desarrollar un repositorio de defectos

| 57
desarrolladores Aunque implementa una función simple, el programa es inutilizable debido
a la naturaleza de los defectos que contiene. Dicho software no es aceptable para los
usuarios; como probadores, debemos hacer uso de todas nuestras herramientas de prueba
estáticas y dinámicas, como se describe en los capítulos siguientes, para garantizar que
dicho software de baja calidad no se entregue a nuestro grupo de usuarios/clientes.
Debemos trabajar con analistas, diseñadores y desarrolladores de código para garantizar
que los problemas de calidad se aborden en las primeras etapas del ciclo de vida del
software. También debemos catalogar los defectos y tratar de eliminarlos mejorando la
educación, la capacitación, la comunicación y el proceso.
El enfoque de este capítulo es mostrar con ejemplos algunos de los tipos de defectos más
comunes que ocurren durante el desarrollo de software. Si usted es miembro de una
organización de pruebas, es importante ilustrar a la gerencia ya sus colegas los beneficios
de desarrollar un depósito de defectos para almacenar información sobre defectos. Como
ingenieros de software y especialistas en pruebas, debemos seguir los ejemplos de
ingenieros de otras disciplinas que se han dado cuenta de la utilidad de los datos de
defectos. Un requisito para el desarrollo del repositorio debe ser parte de las declaraciones
de políticas de prueba y/o depuración.
Comienza con el desarrollo de un esquema de clasificación de defectos y luego inicia la
recopilación de datos de defectos de los proyectos organizacionales. Será necesario
diseñar formularios y plantillas para recopilar los datos. Algunos ejemplos son los informes
de incidentes de prueba, como se describe en el Capítulo 7, y los informes de reparación
de defectos, como se describe en el Capítulo 4. Deberá ser consciente de registrar cada
defecto después de la prueba, y también de registrar la frecuencia de aparición de cada
uno de los tipos de defectos. El monitoreo de defectos debe continuar para cada proyecto
en curso. La distribución de defectos cambiará a medida que realice cambios en sus
procesos. Los datos de defectos son útiles para la planificación de pruebas, un objetivo de
madurez de nivel 2 de TMM. Le ayuda a seleccionar técnicas de prueba aplicables, diseñar
(y reutilizar) los casos de prueba que necesita y asignar la cantidad de recursos que deberá
dedicar a detectar y eliminar estos defectos. Esto, a su vez, le permitirá estimar los
cronogramas y costos de las pruebas.
Los datos de defectos también pueden admitir actividades de depuración. De hecho, como
muestra la Figura 3.6, un repositorio de defectos puede ayudar a respaldar el logro y la
implementación continua de varios objetivos de madurez de TMM, incluido el control continuo.
Repositorio de defectos
Planificación de
pruebas y desarrollo
de casos de prueba.
Admite los objetivos de madurez de TMM

Control y
seguimiento
Prevención de defectos
Evaluación Prueba Mejora del

y control de
medición proceso de prueba
calidad
HIGO. 3.6
El repositorio de defectos y la compatibilidad con
los objetivos de madurez de TMM.
control y seguimiento de pruebas, evaluación y control de la calidad del software,

medición de pruebas y mejora del proceso de pruebas. El Capítulo 13 ilustrará la
aplicación de estos datos a las actividades de prevención de defectos y mejora
de procesos. Otros capítulos describirán el papel de los datos de defectos en
varias actividades de prueba.
TÉRMINOS CLAVE
Modelo de falla
Rasgo
Condición previa
poscondición
EJERCICIOS
1. ¿Cuáles son los orígenes típicos de los defectos? Según sus propias experiencias personales,
¿cuáles son las principales fuentes de defectos en los artefactos de software que ha desarrollado?

| 59
2. El programador A y el programador B están trabajando en un grupo de módulos de interfaz.
El programador A tiende a ser un mal comunicador y no se lleva bien con el programador
B. Debido a esta situación, ¿qué tipo de defectos es probable que surjan en estos módulos
de interfaz? ¿Cuáles son los posibles orígenes de los defectos?
3. Suponga que es miembro de un equipo que estaba diseñando un repositorio de defectos.

¿Qué enfoque organizativo sugeriría y por qué? ¿Qué información crees que debería estar
asociada con cada defecto? ¿Por qué es útil esta información?
¿Y quién lo usaría?
4. ¿Qué tipo de esquema de clasificación de defectos utiliza su universidad u organización?

¿Cómo lo compararía con el esquema de clasificación utilizado en este texto en cuanto a
claridad, capacidad de aprendizaje y facilidad de uso?
5. Suponga que estaba revisando un documento de requisitos y notó que una característica
se describió de manera incompleta. ¿Cómo clasificaría este defecto? ¿Cómo se aseguraría
de que se corrigió?
6. Suponga que está probando un componente de código y descubre un defecto: calcula

incorrectamente una variable de salida. (a) ¿Cómo clasificaría este defecto? (b) ¿Cuáles
son las causas probables de este defecto? (c) ¿Qué pasos podrían haberse tomado para
evitar que este tipo de defecto se propague al código?
7. Suponga que está probando un componente de código y encuentra una discrepancia en

el orden de los parámetros para dos de los procedimientos de código. Aborde los mismos
tres elementos que aparecen en la pregunta 6 para este escenario.
REFERENCIAS
[1] J. Gale, J. Tirso, C. Burchfiled, "Implementación del [6] B. Beizer, Software Testing Techniques, segunda edición,
proceso de prevención de defectos en la organización de Van Nostrand Reinhold, Nueva York, 1990.
programación interactiva MVS", IBM Systems Journal, vol.
[7] Clasificación estándar de IEEE para anomalías de
29, N° 1, 1990.
software (IEEE Std. 1044-1993), copyright 1994 de IEEE,
[2] W. Humphrey, Una disciplina para la ingeniería de todos los derechos reservados.
software, Addison-Wesley, Reading, MA, 1995.
[8] R. Grady, Métricas prácticas de software para la gestión
[3] G. Myers, El arte de las pruebas de software, John Wiley, de proyectos y la mejora de procesos, Prentice Hall,
Nueva York, 1979. Englewoood Cliffs, NJ, 1992.
[4] M. Abramovici, M. Brever, A. Friedman, Digital System [9] C. Kaner, J. Falk, H. Nguyen, Testing Computer Software,
Testing and Testable Design, Computer Science Press, Nueva segunda edición, Van Nostrand Reinhold, Nueva York, 1993.
York, 1990.
[5] B. Wilkins, Principios de prueba en circuitos y sistemas

VSLI en silicio, A. Brown, ed., McGraw-Hill, Nueva York, 1991,
págs. 222–250.

4
ESTRATEGIAS Y
MÉTODOS DE PRUEBA
DISEÑO DE CASO I
4.0 Introducción a las estrategias de diseño de pruebas
Como lector de este texto, tiene el objetivo de aprender más sobre las pruebas y
cómo convertirse en un buen probador. Es posible que sea un estudiante de una
universidad que haya completado algunos cursos de ingeniería de software. Al
completar su educación, le gustaría ingresar a la profesión de especialista en
pruebas. O puede ser empleado de una organización que tiene como objetivo
empresarial la mejora del proceso de prueba. Por otro lado, puede ser un consultor
que quiera aprender más sobre las pruebas para asesorar a sus clientes. Puede ser
que juegues varios de estos roles. Es posible que se pregunte: ¿Por dónde empiezo
a aprender más sobre las pruebas? ¿Qué áreas de prueba son importantes?
¿Qué temas deben abordarse primero? El Modelo de Prueba de Madurez
proporciona algunas respuestas a estas preguntas. Puede servir como una
herramienta de aprendizaje, o marco, para aprender acerca de las pruebas. El
soporte para este uso del TMM se encuentra en su estructura. Introduce los
aspectos tanto técnicos como administrativos de las pruebas de una manera que
permite una evolución natural del proceso de pruebas, tanto a nivel personal como organizacio
62 | Estrategias y métodos para el diseño de casos de prueba I
En este capítulo comenzamos el estudio de los conceptos de prueba usando el TMM
como marco de aprendizaje. Comenzamos el desarrollo de las habilidades de evaluación necesarias
para respaldar el logro de los objetivos de madurez en los niveles 2 y 3 del
Prueba del modelo de madurez. TMM nivel 2 tiene tres objetivos de madurez, dos de
que son de carácter gerencial. Estos serán discutidos en posteriores
capítulos La meta de madurez técnicamente orientada en el nivel 2 que exige
una organización para "institucionalizar técnicas y métodos básicos de prueba"
aborda cuestiones técnicas importantes y básicas relacionadas con la ejecución
pruebas. Tenga en cuenta que este objetivo se introduce en un nivel bajo del TMM,
indicando su importancia como bloque de construcción básico sobre el cual se
Se pueden construir fortalezas de prueba. Para satisfacer esta prueba de meta de madurez
especialistas en una organización necesitan adquirir conocimientos técnicos básicos
probarlo y aplicarlo a proyectos organizacionales.
Los capítulos 4 y 5 le presentan aspectos técnicos fundamentales relacionados con las pruebas.
conceptos relacionados con las pruebas basadas en la ejecución. Los ejercicios al final de
el capítulo le ayudará a prepararse para su aplicación a problemas del mundo real. Se discuten
estrategias y métodos de prueba que son tanto básicos como
práctico. La aplicación consistente de estas estrategias, métodos y técnicas por parte de los probadores
en toda la organización respaldará el proceso de prueba.
evolución a niveles de madurez más altos, y puede conducir a un software mejorado
calidad.
4.1 El probador inteligente
Los componentes de software tienen defectos, sin importar qué tan bien se implementen nuestras
actividades de prevención de defectos. Los desarrolladores no pueden prevenir/eliminar
todos los defectos durante el desarrollo. Por lo tanto, el software debe ser probado antes
se entrega a los usuarios. Es responsabilidad de los probadores diseñar las pruebas.
que (i) revelan defectos, y (ii) pueden usarse para evaluar el rendimiento, la usabilidad y la confiabilidad
del software. Para lograr estos objetivos, los evaluadores deben seleccionar
un número finito de casos de prueba, a menudo de un dominio de ejecución muy grande.
Desafortunadamente, las pruebas generalmente se realizan con limitaciones de tiempo y presupuesto.
Los evaluadores a menudo están sujetos a enormes presiones por parte de la gerencia y el marketing
porque las pruebas no están bien planificadas y las expectativas.
son poco realistas. El probador inteligente debe planificar las pruebas, seleccionar los casos de prueba,
y monitorear el proceso para asegurar que los recursos y el tiempo asignado

4.2 Estrategias de diseño de casos de prueba | 63

para el trabajo se utilizan con eficacia. Estas son tareas formidables, y para llevarlas a cabo
de manera efectiva, los evaluadores necesitan una educación y capacitación adecuadas y
la capacidad de obtener el apoyo de la gerencia.
Los probadores novatos, que se toman en serio sus responsabilidades, pueden
intentar probar un módulo o componente utilizando todas las entradas posibles y
ejercitar todas las estructuras de software posibles. El uso de este enfoque, razonan,
les permitirá detectar todos los defectos. Sin embargo, un probador informado y
educado sabe que ese no es un objetivo realista o económicamente factible. Otro
enfoque podría ser que el probador seleccione entradas de prueba al azar, con la
esperanza de que estas pruebas revelen defectos críticos. Algunos expertos en
pruebas creen que las entradas de prueba generadas aleatoriamente tienen un bajo
rendimiento [1]. Otros no están de acuerdo, por ejemplo, Durán [2]. Se encuentran
discusiones adicionales en Chen [3] y Gutjahr [4].
El autor cree que el objetivo del probador inteligente es comprender la
funcionalidad, el dominio de entrada/salida y el entorno de uso del código que se
está probando. Para ciertos tipos de pruebas, el evaluador también debe comprender
en detalle cómo se construye el código. Finalmente, un probador inteligente necesita
usar el conocimiento de los tipos de defectos que comúnmente se inyectan durante
el desarrollo o mantenimiento de este tipo de software. Usando esta información, el
probador inteligente debe seleccionar inteligentemente un subconjunto de entradas
de prueba, así como combinaciones de entradas de prueba que crea que tienen la
mayor posibilidad de revelar defectos dentro de las condiciones y restricciones
impuestas en el proceso de prueba. Esto requiere tiempo y esfuerzo, y el probador
debe elegir cuidadosamente para maximizar el uso de los recursos [1,3,5]. Este
capítulo, así como el siguiente, describen estrategias y métodos prácticos para
ayudarlo a diseñar casos de prueba para que pueda convertirse en un evaluador inteligente.
4.2 Estrategias de diseño de casos de prueba
Un probador inteligente que quiere maximizar el uso del tiempo y los recursos sabe
que necesita desarrollar lo que llamaremos casos de prueba efectivos para pruebas
basadas en la ejecución. Por un caso de prueba efectivo nos referimos a uno que
tiene una buena posibilidad de revelar un defecto (ver el Principio 2 en el Capítulo 2).
La capacidad de desarrollar casos de prueba efectivos es importante para una
organización que evoluciona hacia un proceso de prueba de mayor calidad. Tiene
muchas consecuencias positivas. Por ejemplo, si los casos de prueba son efectivos, hay (i) una
probabilidad de detectar defectos, (ii) un uso más eficiente de los

recursos, (iii) una mayor probabilidad de reutilización de la prueba, (iv) una mayor adherencia a
pruebas y cronogramas y presupuestos del proyecto, y (v) la posibilidad de entregar un producto
de software de mayor calidad. ¿Cuáles son los enfoques de un
debe usar el probador para diseñar casos de prueba efectivos? Para responder a la pregunta nos
debe adoptar la visión de que el software es un producto de ingeniería. Dado este
vista hay dos estrategias básicas que se pueden utilizar para diseñar casos de prueba.
Estas se denominan estrategias de prueba de caja negra (a veces denominada funcional o de
especificación) y de caja blanca (a veces denominada transparente o de caja de cristal).
Los enfoques se resumen en la Figura 4.1.
Usando el enfoque de caja negra, un probador considera que el software bajo prueba es una
caja opaca. No hay conocimiento de su estructura interna.
(es decir, cómo funciona). El probador sólo tiene conocimiento de lo que hace. Él
El tamaño del software bajo prueba usando este enfoque puede variar de un simple
módulo, función miembro o grupo de objetos a un subsistema o a un
sistema de software. La descripción del comportamiento o funcionalidad para el
el software bajo prueba puede provenir de una especificación formal, un diagrama de entrada/
proceso/salida (IPO) o un conjunto bien definido de condiciones previas y posteriores. Otra fuente
de información es un documento de especificación de requisitos que generalmente describe la
funcionalidad del software bajo prueba.
y sus entradas y salidas esperadas. El probador proporciona el especificado
entradas al software bajo prueba, ejecuta la prueba y luego determina si el
los resultados producidos son equivalentes a los de la especificación. Porque el
el enfoque de caja negra solo considera el comportamiento y la funcionalidad del software,
a menudo se denomina prueba funcional o basada en especificaciones. Este enfoque
es especialmente útil para revelar requisitos y defectos de especificación.
El enfoque de la caja blanca se centra en la estructura interna del software.
para ser probado. Para diseñar casos de prueba utilizando esta estrategia, el probador debe tener
un conocimiento de esa estructura. El código, o un pseudocódigo adecuado
la representación debe estar disponible. El probador selecciona casos de prueba para ejercitar
elementos estructurales internos específicos para determinar si están funcionando correctamente.
Por ejemplo, los casos de prueba a menudo están diseñados para ejercitar todas las declaraciones.
o ramas verdadero/falso que ocurren en un módulo o función miembro. Ya que
diseñar, ejecutar y analizar los resultados de las pruebas de caja blanca es muy
requiere mucho tiempo, esta estrategia generalmente se aplica a piezas de menor tamaño
software como un módulo o una función miembro. Las razones del tamaño.
4.2 Estrategias de diseño de casos de prueba

| sesenta y cinco
Prueba del probador Conocimiento

Estrategia Vista Fuentes Métodos
Documento de Partición de clases de

Entradas requisitos equivalencia
Especificaciones Análisis de valor límite
Caja negra Conocimiento del dominio Pruebas de transición de estado

Datos de análisis de Gráficas de causa y efecto
defectos Error al adivinar
Salidas
Diseño de alto nivel Prueba de declaración

Diseño detallado Pruebas de rama
caja blanca Gráficos de flujo Prueba de ruta
de control Pruebas de flujo de datos
Complejidad Pruebas de mutación
ciclomática Prueba de bucle
HIGO. 4.1
Las dos estrategias básicas de prueba.
La restricción se volverá más evidente en el Capítulo 5, donde se describe con más

detalle la estrategia de la caja blanca. Los métodos de prueba de caja blanca son
especialmente útiles para revelar defectos de diseño y control basado en código, lógica
y secuencia, defectos de inicialización y defectos de flujo de datos.
El probador inteligente sabe que para lograr el objetivo de proporcionar a los
usuarios software de alta calidad y con pocos defectos, ambas estrategias deben
usarse para diseñar casos de prueba. Ambos apoyan al probador con la tarea de
seleccionar el número finito de casos de prueba que se aplicarán durante la prueba.
Ninguno de los enfoques por sí solo garantiza revelar todos los tipos de defectos que
hemos estudiado en el Capítulo 3. Los enfoques se complementan entre sí; cada uno
puede ser útil para revelar ciertos tipos de defectos. Con un conjunto de casos de
prueba diseñados utilizando ambas estrategias, el probador aumenta las posibilidades
de revelar los diferentes tipos de defectos en el software que se está probando. El
probador también tendrá un conjunto efectivo de casos de prueba reutilizables para
pruebas de regresión (volver a probar después de cambios) y para probar nuevas versiones del so
Hay una gran cantidad de material para presentar al lector en relación con estas
dos estrategias. Para facilitar el proceso de aprendizaje, el material se ha dividido en
dos capítulos. Este capítulo se enfoca en los métodos de caja negra, y el Capítulo 5
describirá los métodos de caja blanca y cómo aplicarlos para diseñar casos de prueba.
Estrategias y métodos para el diseño de casos de prueba I

66 |
4.3 Uso del enfoque de caja negra para el diseño de casos de prueba
Dada la estrategia de prueba de caja negra en la que consideramos solo entradas y

salidas como base para diseñar casos de prueba, ¿cómo elegimos un conjunto
adecuado de entradas del conjunto de todas las posibles entradas válidas e inválidas?
Tenga en cuenta que no se dispone de tiempo y recursos infinitos para probar
exhaustivamente todas las entradas posibles. Esto es prohibitivamente costoso incluso
si el software de destino es una unidad de software simple. Como ejemplo, suponga
que intenta probar un solo procedimiento que calcula la raíz cuadrada de un número.
Si tuviera que probarlo exhaustivamente, tendría que probar todos los valores de entrada
positivos. ¡Esto es lo suficientemente desalentador! Pero, ¿qué pasa con todos los números
negativos, fracciones? Estas también son entradas posibles. El número de casos de prueba
aumentaría rápidamente hasta el punto de la inviabilidad. El objetivo del probador inteligente
es utilizar de manera efectiva los recursos disponibles mediante el desarrollo de un conjunto
de casos de prueba que brinde el máximo rendimiento de defectos por el tiempo y el
esfuerzo invertidos. Para ayudar a lograr este objetivo utilizando el enfoque de caja negra,
podemos seleccionar entre varios métodos. Muy a menudo se utilizan combinaciones de
los métodos para detectar diferentes tipos de defectos. Algunos métodos tienen mayor
practicidad que otros.
4.4 Pruebas aleatorias
Cada módulo o sistema de software tiene un dominio de entrada desde el cual se

seleccionan los datos de entrada de prueba. Si un evaluador selecciona al azar
entradas del dominio, esto se denomina prueba aleatoria. Por ejemplo, si el dominio
de entrada válido para un módulo son todos los números enteros positivos entre 1 y
100, el probador que utiliza este enfoque seleccionaría valores de forma aleatoria o
no sistemática dentro de ese dominio; por ejemplo, se pueden elegir los valores 55,
24, 3. Ante este planteamiento, algunas de las cuestiones que quedan abiertas son las siguiente
• ¿Son los tres valores adecuados para mostrar que el módulo cumple con sus especificaciones?
¿Cuándo se ejecutan las pruebas? Si se requieren valores adicionales o menores
utilizado para hacer el uso más eficaz de los recursos?
4.5 Partición de clases de equivalencia | 67
• ¿Existen valores de entrada, además de los seleccionados, con mayor probabilidad de

revelar defectos? Por ejemplo, ¿deberían seleccionarse específicamente como
entradas los números enteros positivos al principio o al final del dominio?
• ¿Se deben usar valores fuera del dominio válido como entradas de prueba?
Por ejemplo, ¿deberían los datos de prueba incluir valores de punto flotante,
valores negativos o valores enteros superiores a 100?
Los enfoques más estructurados para el diseño de pruebas de caja negra abordan estos problemas.
El uso de entradas de prueba aleatorias puede ahorrar parte del tiempo y el
esfuerzo que requieren los métodos de selección de entradas de prueba más
cuidadosos. Sin embargo, el lector debe tener en cuenta que, según muchos expertos
en pruebas, la selección aleatoria de entradas de prueba tiene muy pocas posibilidades
de producir un conjunto efectivo de datos de prueba [1]. Ha habido mucha discusión
en el mundo de las pruebas sobre si tal declaración es precisa. La eficacia relativa del
enfoque aleatorio frente a un enfoque más estructurado para generar entradas de
prueba ha sido objeto de muchos trabajos de investigación. Los lectores deben
consultar las referencias [2–4] para algunas de estas discusiones. El resto de este
capítulo y el siguiente ilustrarán enfoques más estructurados para el diseño de casos
de prueba y la selección de entradas. Como nota final, existen herramientas que
generan datos de prueba aleatorios para las pruebas de estrés. Este tipo de prueba
puede ser muy útil especialmente a nivel de sistema. Por lo general, el probador
especifica un rango para el generador de valores aleatorios, o las entradas de prueba
se generan de acuerdo con una distribución estadística asociada con un patrón de uso.
4.5 Partición de clases de equivalencia
Si un probador está viendo el software bajo prueba como una caja negra con entradas
y salidas bien definidas, un buen enfoque para seleccionar las entradas de prueba es
usar un método llamado partición de clase de equivalencia. El particionamiento de
clases de equivalencia da como resultado un particionamiento del dominio de entrada
del software bajo prueba. La técnica también se puede usar para particionar el dominio
de salida, pero este no es un uso común. El número finito de particiones o clases de
equivalencia que resultan permiten al probador seleccionar un miembro dado de una
clase de equivalencia como representante de esa clase. Se supone que todos los
miembros de una clase de equivalencia son procesados de manera equivalente por
el software de destino.
El uso de la partición de clase de equivalencia de un valor de prueba en una clase en particular
es equivalente a un valor de prueba de cualquier otro miembro de esa clase. Por lo tanto, si un caso
de prueba en una clase de equivalencia particular revela un defecto, se espera que todos los demás
casos de prueba basados en esa clase revelen el mismo defecto. También podemos decir que si un
caso de prueba en una clase de equivalencia dada no detectó un tipo particular de defecto, entonces
ningún otro caso de prueba basado en esa clase detectaría el defecto (a menos que un subconjunto
de la clase de equivalencia caiga en otra clase de equivalencia, ya que las clases pueden
superponerse en algunos casos). En Beizer [5] se da una discusión más formal de la partición de
clases de equivalencia.
Con base en esta discusión de partición de clase de equivalencia, podemos decir que la
partición del dominio de entrada para el software bajo prueba usando esta técnica tiene las siguientes
ventajas:
1. Elimina la necesidad de pruebas exhaustivas, que no son factibles.
2. Guía a un probador en la selección de un subconjunto de entradas de prueba con una alta
probabilidad de detectar un defecto.
3. Permite que un probador cubra un dominio más grande de entradas/salidas con un subconjunto
más pequeño seleccionado de una clase de equivalencia.
La mayor parte de la partición de clases de equivalencia tiene lugar para el dominio de entrada.
¿Cómo identifica el probador las clases de equivalencia para el dominio de entrada?
Un enfoque es usar un conjunto de lo que Glen Myers llama condiciones de entrada "interesantes" [1].
Las condiciones de entrada generalmente provienen de una descripción en la especificación del
software que se va a probar. El probador usa las condiciones para dividir el dominio de entrada en
clases de equivalencia y luego desarrolla un conjunto de casos de prueba para cubrir (incluir) todas
las clases. Dado que solo se necesita la información en una especificación de entrada/salida, el
probador puede comenzar a desarrollar pruebas de caja negra para el software al principio del ciclo
de vida del software en paralelo con las actividades de análisis (consulte el Principio 11, Capítulo 2).
El probador y el analista interactúan durante la fase de análisis para desarrollar (i) un conjunto de
requisitos comprobables, y (ii) una especificación de entrada/salida correcta y completa. A partir de
estos, el evaluador desarrolla (i) un plan de prueba de alto nivel y (ii) un conjunto preliminar de casos
de prueba de caja negra para el sistema. Tanto el plan como los casos de prueba experimentan un
mayor desarrollo en las fases posteriores del ciclo de vida. El modelo V, como se describe en el
Capítulo 8, respalda este enfoque.
Hay varios puntos importantes relacionados con la clase de equivalencia par
ciones que se deben hacer para completar esta discusión.

4.5 Partición de clases de equivalencia

| 69
1. El probador debe considerar clases de equivalencia tanto válidas como no válidas.

Las clases no válidas representan entradas erróneas o inesperadas.
2. También se pueden seleccionar clases de equivalencia para las condiciones de salida.
3. La derivación de clases de equivalencia de entradas o salidas es un proceso heurístico.
Las condiciones que se describen en los siguientes párrafos solo brindan al probador
pautas para identificar las particiones.
No hay reglas duras y rápidas. Dado el mismo conjunto de condiciones, los
evaluadores individuales pueden elegir diferentes clases de equivalencia.
A medida que un probador gana experiencia, es más capaz de seleccionar clases
de equivalencia con confianza.
4. En algunos casos, es difícil para el evaluador identificar las clases de equivalencia.

Las condiciones/límites que ayudan a definir las clases pueden estar ausentes u
oscuras, o puede parecer que hay un número muy grande o muy pequeño de clases
de equivalencia para el dominio del problema. Estas dificultades pueden surgir de
una especificación y/o descripción de requisitos ambigua, contradictoria, incorrecta
o incompleta. Es deber del probador buscar a los analistas y reunirse con ellos para
aclarar estos documentos. Puede ser necesario un contacto adicional con el grupo
de usuarios/clientes. Un evaluador también debe darse cuenta de que, para algunos
dominios de problemas de software, definir las clases de equivalencia es
inherentemente difícil, por ejemplo, el software que necesita utilizar el código fiscal.
Myers sugiere las siguientes condiciones como pautas para seleccionar clases de
equivalencia de entrada [1]. Tenga en cuenta que una condición generalmente se asocia
con una variable particular. Tratamos cada condición por separado. Los casos de prueba,
cuando se desarrollan, pueden cubrir múltiples condiciones y múltiples variables.
Lista de condiciones
1. "Si una condición de entrada para el software que se está probando se especifica
como un rango de valores, seleccione una clase de equivalencia válida que cubra
el rango permitido y dos clases de equivalencia no válidas, una fuera de cada
extremo del rango". Por ejemplo, suponga que la especificación de un módulo dice
que una entrada, la longitud de un widget en milímetros, se encuentra en el
rango de 1 a 499; luego seleccione una clase de equivalencia válida que incluya
todos los valores del 1 al 499. Seleccione una segunda clase de equivalencia que
contenga todos los valores
menos de 1, y una tercera clase de equivalencia que consiste en todos los valores
mayores de 499.
2. ''Si una condición de entrada para el software bajo prueba se especifica como un
número de valores, entonces seleccione una clase de equivalencia válida que incluya
el número permitido de valores y dos clases de equivalencia no válida que estén
fuera de cada extremo del número permitido .''
Por ejemplo, si la especificación para un módulo relacionado con bienes raíces

dice que una casa puede tener de uno a cuatro propietarios, entonces seleccionamos
una clase de equivalencia válida que incluye todo el número válido de propietarios y
luego dos clases de equivalencia no válidas para menos de uno. dueño y más de
cuatro dueños.
3. “Si una condición de entrada para el software bajo prueba se especifica como un
conjunto de valores de entrada válidos, seleccione una clase de equivalencia válida
que contenga todos los miembros del conjunto y una clase de equivalencia no válida
para cualquier valor fuera del conjunto. conjunto.'' Por ejemplo, si la especificación
para un módulo de pintura establece que los colores ROJO, AZUL, VERDE y
AMARILLO están permitidos como entradas, entonces seleccione una clase de
equivalencia válida que incluya el conjunto ROJO, AZUL, VERDE y AMARILLO, y
una Clase de equivalencia no válida para todas las demás entradas.
4. ''Si una condición de entrada para el software bajo prueba se especifica como una
condición "debe ser" , seleccione una clase de equivalencia válida para representar
la condición "debe ser" y una clase no válida que no incluya la condición "debe ser".
"condición". Por ejemplo, si la especificación de un módulo establece que el primer
carácter de un identificador de pieza debe ser una letra, seleccione una clase
de equivalencia válida donde el primer carácter sea una letra y una clase no válida
donde el primer carácter sea una letra. no es una carta.
5. “Si la especificación de entrada o cualquier otra información lleva a la creencia de que

un elemento en una clase de equivalencia no es manejado de manera idéntica por
el software bajo prueba, entonces la clase debe dividirse en clases de equivalencia
más pequeñas. .''
Para mostrar cómo las clases de equivalencia pueden derivarse de una especificación,
considere un ejemplo en la figura 4.2. Esta es una especificación para un módulo que
calcula una raíz cuadrada.
La especificación describe para el probador las condiciones relevantes para el
4.5 Partición de clases de equivalencia | 71

Función mensaje
raíz_cuadrada
(x:real) cuando x >
0.0 respuesta
(y:real) donde y > 0.0 y aproximadamente
(y*y,x) de lo contrario respuesta excepción función
final raíz_cuadrada_imaginaria
HIGO. 4.2
Una especificación de una función de
raíz cuadrada.
variables de entrada/salida x e y. Las condiciones de entrada son que la variable x debe ser un
número real y ser igual o mayor que 0.0. Las condiciones para la variable de salida y son que
debe ser un número real igual o mayor que 0.0, cuyo cuadrado sea aproximadamente igual a x.
Si x no es igual o mayor que 0,0, se genera una excepción. A partir de esta información, el
probador puede generar fácilmente clases de equivalencia y límites válidos y no válidos. Por
ejemplo, las clases de equivalencia de entrada para este módulo son las siguientes:
EC1. La variable de entrada x es real, válida.
EC2. La variable de entrada x no es real, no válida.
EC3. El valor de x es mayor que 0.0, válido.
EC4. El valor de x es menor que 0.0, no válido.
Debido a que muchas organizaciones ahora usan algún tipo de especificaciones formales o
semiformales, los probadores tienen una fuente confiable para aplicar las condiciones de entrada/
salida descritas por Myers.
Después de identificar las clases de equivalencia de esta manera, el siguiente paso en el
diseño de casos de prueba es el desarrollo de los casos de prueba reales. Un buen enfoque
incluye los siguientes pasos.
1. A cada clase de equivalencia se le debe asignar un identificador único. un simulador

ple entero es suficiente.
2. Desarrollar casos de prueba para todas las clases de equivalencia válidas hasta que todas
hayan sido cubiertas por (incluidas en) un caso de prueba. Un caso de prueba dado puede
cubrir más de una clase de equivalencia.
3. Desarrollar casos de prueba para todas las clases de equivalencia inválidas hasta que
todas hayan sido cubiertas individualmente. Esto es para asegurar que un caso no válido
no enmascare el efecto de otro ni impida la ejecución de otro.
En la siguiente sección se mostrará un ejemplo de aplicación de partición de clases de

equivalencia.
4.6 Análisis del valor límite
El particionamiento de clases de equivalencia brinda al probador una herramienta útil con la

que desarrollar casos de prueba basados en caja negra para el software bajo prueba. El
método requiere que un probador tenga acceso a una especificación de comportamiento de
entrada/salida para el software de destino. Los casos de prueba desarrollados en base a la
partición de clases de equivalencia pueden fortalecerse mediante el uso de otra técnica
llamada análisis de valores límite. Con la experiencia, los probadores pronto se dan cuenta de
que muchos defectos ocurren directamente sobre, y por encima y por debajo, de los bordes
de las clases de equivalencia. Los casos de prueba que consideran estos límites tanto en los
espacios de entrada como de salida, como se muestra en la figura 4.3, suelen ser valiosos
para revelar defectos.
Mientras que la partición de clases de equivalencia dirige al probador a seleccionar casos
de prueba de cualquier elemento de una clase de equivalencia, el análisis de valor límite
requiere que el probador seleccione elementos cerca de los bordes, de modo que los bordes
superior e inferior de una clase de equivalencia estén cubiertos por casos de prueba. .
Como en el caso de la partición de clases de equivalencia, la capacidad de desarrollar casos
de prueba de alta calidad con el uso de valores límite requiere experiencia.
Las reglas generales que se describen a continuación son útiles para comenzar con el análisis
de valores límite.
1. Si una condición de entrada para el software bajo prueba se especifica como un rango de
valores, desarrolle casos de prueba válidos para los extremos del rango, y en casos de
prueba válidos para posibilidades justo por encima y por debajo de los extremos del rango.
distancia.
Por ejemplo, si una especificación establece que un valor de entrada para un

módulo debe estar en el rango entre 1,0 y 1,0, las pruebas válidas que incluyen valores
para los extremos del rango, así como los casos de prueba no válidos para valores justo
por encima y por debajo de los extremos, deberían ser incluido. Esto daría como
resultado valores de entrada de 1,0, 1,1 y 1,0, 1,1.
4.7 Un ejemplo de la aplicación de partición de clase de equivalencia | 73
Partición de equivalencia
Perímetro Perímetro
HIGO. 4.3
Límites de una partición de

equivalencia.
2. Si una condición de entrada para el software bajo prueba se especifica como un

número de valores, desarrolle casos de prueba válidos para los números mínimo
y máximo, así como casos de prueba no válidos que incluyan uno menor y otro
mayor que el máximo y el mínimo. .
Por ejemplo, para el módulo inmobiliario mencionado anteriormente que
especifica que una casa puede tener de uno a cuatro dueños, se desarrollarían
pruebas que incluyan 0,1 dueños y 4,5 dueños.
El siguiente es un ejemplo de la aplicación del análisis de valores límite a las
clases de equivalencia de salida. Suponga que un módulo va a producir una tabla
de 1 a 100 valores. El evaluador debe seleccionar los datos de entrada para
generar una tabla de salida de tamaño 0, 1 y 100 valores y, si es posible, 101
valores.
3. Si la entrada o salida del software bajo prueba es un conjunto ordenado, como una
tabla o una lista lineal, desarrolle pruebas que se centren en el primer y último
elemento del conjunto.
Es importante que el probador tenga en cuenta que la partición de clase de

equivalencia y el análisis de valor límite se aplican a las pruebas de entradas y salidas
del software que se está probando y, lo que es más importante, las condiciones no se
combinan para la partición de clase de equivalencia o el análisis de valor límite. sís.
Cada condición se considera por separado y se desarrollan casos de prueba para
asegurar la cobertura de todas las condiciones individuales. A continuación se muestra un ejempl
4.7 Un ejemplo de la aplicación de la clase de equivalencia

Partición y análisis de valor límite
Supongamos que estamos probando un módulo que permite a un usuario ingresar nuevos
identificadores de widgets en una base de datos de widgets. Nos centraremos sólo en seleccionar equiv-

74 |
Clases de alencia y valores límite para las entradas. La especificación de entrada para el
módulo establece que un identificador de widget debe constar de 3 a 15 caracteres
alfanuméricos, de los cuales los dos primeros deben ser letras. Tenemos tres condiciones
separadas que se aplican a la entrada: (i) debe constar de caracteres alfanuméricos, (ii) el
rango para el número total de caracteres está entre 3 y 15, y (iii) los primeros dos caracteres
deben ser letras .
Nuestro enfoque para diseñar los casos de prueba es el siguiente. Primero
identificaremos las clases de equivalencia de entrada y les daremos a cada una un
identificador. Luego los aumentaremos con los resultados del análisis de valores límite.
Se utilizarán tablas para organizar y registrar nuestros hallazgos. Etiquetaremos las clases
de equivalencia con un identificador ECxxx, donde xxx es un número entero cuyo valor es
uno o mayor. Cada clase también se clasificará como válida o no válida para el dominio de
entrada.
Primero consideramos la condición 1, el requisito de caracteres alfanuméricos. Esta
es una condición "debe ser". Derivamos dos clases de equivalencia.
EC1. El nombre de la pieza es alfanumérico, válido.
EC2. El nombre de la pieza no es alfanumérico, no es válido.
Luego tratamos la condición 2, el rango de caracteres permitidos 3–15.
EC3. El identificador del widget tiene entre 3 y 15 caracteres, válido.
EC4. El identificador del widget tiene menos de 3 caracteres, no válido.
EC5. El identificador del widget tiene más de 15 caracteres, no válido.
Finalmente tratamos el caso “debe ser” para los dos primeros personajes.
EC6. Los 2 primeros caracteres son letras, válidos.
EC7. Los primeros 2 caracteres no son letras, inválidos.
Tenga en cuenta que cada condición se consideró por separado. Las condiciones no
se combinan para seleccionar clases de equivalencia. El probador puede descubrir más
adelante que un caso de prueba específico cubre más de una clase de equivalencia.
Las clases de equivalencia seleccionadas pueden registrarse en forma de tabla como
se muestra en la Tabla 4.1. Al inspeccionar una mesa de este tipo, el probador puede
4.7 Un ejemplo de la aplicación de partición de clase de equivalencia

| 75
Equivalencia válida Equivalencia no válida

Condición clases clases
1 EC1 EC2
2 EC3 EC4, EC5
3 EC6 EC7
TABLA 4.1
Ejemplo de informe de clase de equivalencia

mesa.
confirme que se han considerado todas las condiciones y las clases de equivalencia
válidas e inválidas asociadas.
El análisis de valores límite ahora se usa para refinar los resultados de la
partición de clases de equivalencia. Los límites en los que centrarse son los que
tienen la longitud permitida para el identificador del widget. Un probador experimentado sabe que
el módulo podría tener defectos relacionados con el manejo de identificadores de widgets que
son de longitud igual y directamente adyacentes al límite inferior de 3
y el límite superior de 15. Se puede usar un conjunto simple de abreviaturas
para representar los grupos de límites. Por ejemplo:
BLB: un valor justo por debajo del límite inferior
LB: el valor en el límite inferior
ALB: un valor justo por encima del límite inferior
BUB: un valor justo debajo del límite superior
UB: el valor en el límite superior
AUB: un valor justo por encima del límite superior
Para nuestro módulo de ejemplo, los valores para los grupos de límites son:
BLB—2 BUB—14
libra-3 UB—15
ALB—4 AUB—16
Tenga en cuenta que en esta discusión del análisis de valores límite, los valores simplemente
por encima del límite inferior (ALB) y justo debajo del límite superior (BUB)

76 |
fueron seleccionados. Ambos son casos válidos y pueden omitirse si el evaluador no cree
que sean necesarios.
El siguiente paso en el proceso de diseño de casos de prueba es seleccionar un
conjunto de valores de entrada reales que cubra todas las clases de equivalencia y los límites.
Una vez más, se puede utilizar una tabla para organizar los resultados. La Tabla 4.2 muestra
las entradas para el módulo de muestra. Tenga en cuenta que la tabla tiene el nombre del
módulo, el identificador, la fecha de creación de los datos de entrada de prueba y el autor
de los casos de prueba.
La Tabla 4.2 solo describe las pruebas para el módulo en términos de entradas
derivadas de las clases de equivalencia y los límites. El Capítulo 7 describirá los
componentes necesarios para un caso de prueba completo. Estos incluyen entradas de
prueba como se muestra en la Tabla 4.2, junto con las condiciones de prueba y los resultados espera
Los registros de prueba se utilizan para registrar las salidas y condiciones reales cuando
se completa la ejecución. Las salidas reales se comparan con las salidas esperadas para
determinar si el módulo ha pasado o no la prueba.
Tenga en cuenta que al inspeccionar la tabla completa, el probador puede determinar
si todas las clases de equivalencia y los límites han sido cubiertos por casos de prueba de
entrada reales. Para este ejemplo, el probador ha seleccionado un total de nueve casos
de prueba. El lector también debe tener en cuenta que, al seleccionar entradas basadas
en clases de equivalencia, se debe incluir un valor representativo en el punto medio de los
límites de cada clase relevante como caso típico. En este ejemplo, se seleccionó un caso
de prueba con 9 caracteres, el promedio de los valores de rango de 3 y 15 (identificador
de caso de prueba 9). El conjunto de casos de prueba presentado aquí no es único: son
posibles otros conjuntos que también cubrirán todas las clases y límites de equivalencia.
Con base en la partición de clase de equivalencia y el análisis de valor límite, estos

casos de prueba deberían tener una alta posibilidad de revelar defectos en el módulo en
lugar de seleccionar entradas de prueba al azar del dominio de entrada. En el último caso,
no hay forma de estimar qué tan productivas serían las elecciones de insumos. Este
enfoque también es una mejor alternativa a las pruebas exhaustivas en las que se tendrían
que usar muchas combinaciones de caracteres, tanto casos válidos como no válidos.
Incluso para este módulo simple, no sería factible realizar pruebas exhaustivas.
4.8 Otros enfoques de diseño de pruebas de caja negra
Existen métodos alternativos a la partición de clase de equivalencia/análisis de valor límite

que un probador puede usar para diseñar casos de prueba basados en la función.
4.8 Otros enfoques de diseño de pruebas de caja negra | 77
Nombre del módulo: Insert_Widget

Identificador del módulo: AP62-Mod4
Fecha: 31 de enero de 2000
Probador: Michelle Jordan
Válido Inválido
equivalencia equivalencia
clases y clases y
Caso de prueba Aporte límites límites
identificador valores cubierto cubierto
1 abc1 EC1, EC3 (ALB) EC6

2 ab1 EC1, EC3 (LB), EC6
3 abcdef123456789 EC1, EC3 (UB) EC6
4 abcde123456789 EC1, EC3 (BUB) EC6
5 a B C* EC3 (ALB), EC6 EC2
6 abdominales
EC1, EC6 EC4 (BLB)
7 abcdefg123456789 EC1, EC6 EC5 (AUB)
8 a123 EC1, EC3 (ALB) EC7
9 abcdef123 EC1, EC3, EC6
(caso típico)
CUADRO 4.2
Resumen de las entradas de prueba utilizando la clase de equivalencia
partición y análisis de valor límite para la muestra

módulo.
especificación nacional para el software que se va a probar. Entre estos se encuentran

los gráficos de causa y efecto, las pruebas de transición de estado y la suposición de
errores. La partición de clases de equivalencia combinada con el análisis de valores límite es un
enfoque práctico para diseñar casos de prueba para software escrito en ambos
lenguajes procedimentales y orientados a objetos, ya que las especificaciones suelen ser
disponible tanto para funciones miembro asociadas con un objeto como para
procedimientos y funciones tradicionales que se escribirán en lenguajes de procedimiento.
Sin embargo, debe enfatizarse que el uso de la partición de clases de equivalencia
debe complementarse con el uso de la caja blanca y, en muchos casos, otros
Enfoques de diseño de pruebas de caja negra. Este es un punto importante para el probador.
darse cuenta. Al combinar estrategias y métodos, el probador puede tener más

Practical Software Testing (001 100)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Practical Software Testing (001 100)

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Datos de catalogación en publicación de la Biblioteca del

ISBN 0-387-95131-8 Impreso en papel sin ácido.

2003 Springer-Verlag Nueva York, Inc.

Impreso en los Estados Unidos de América.

987654321 GIRO 10779083

Springer-Verlag Nueva York Berlín Heidelberg

INTRODUCCIÓN A LAS PRUEBAS

1.0 La profesión en evolución de la ingeniería de software 1 1.1

2 FUNDAMENTOS DE LAS PRUEBAS

2.2 Principios de prueba de software 26 2.3

3 DEFECTOS, HIPÓTESIS Y PRUEBAS

3.0 Orígenes de los defectos 39

3.1.1 Defectos de requisitos y especificaciones 44 3.1.2

evaluador para desarrollar un repositorio de defectos 57

Lista de términos clave 58

4 ESTRATEGIAS Y MÉTODOS PARA EL DISEÑO DE CASOS DE PRUEBA I

4.0 Introducción a las estrategias de diseño de pruebas 61

4.2 Estrategias de diseño de casos de

Análisis de valor límite 73 4.8 Otros

4.8.1 Representación gráfica de causa y efecto

4.9 Pruebas de caja negra y productos comerciales listos para usar

5 ESTRATEGIAS Y MÉTODOS PARA EL DISEÑO DE CASOS DE PRUEBA II

5.0 Uso del enfoque de caja blanca para el diseño de pruebas 97

5.5.1 Flujo de datos y diseño de prueba de caja blanca 111

5.6 Evaluación de los criterios de adecuación de la

6.0 La necesidad de niveles de prueba 133

6.0.1 Niveles de pruebas y paradigmas de desarrollo de software 135

6.7 Ejecutar las pruebas unitarias y registrar los resultados 150

6.8 Prueba de integración: objetivos

estrés 169 6.13.4 Pruebas de configuración 171 6.13.5 Pruebas

6.14 Pruebas de regresión 176

7 PRUEBA METAS, POLÍTICAS, PLANES Y DOCUMENTACIÓN

7.0 Conceptos introductorios 189 7.1

7.4.1 Especificaciones del diseño de prueba 217

220 7.5 Ubicación de los elementos de prueba: el informe de transmisión de

7.8 Proceso y las disciplinas de ingeniería: el papel del individuo

Lista de términos clave 231

8.0 Presentación del especialista en pruebas 235

8.7 Integración de las actividades de prueba en el ciclo de vida del software

9.0 Definición de términos

9.1.1 Mediciones para monitorear el estado de las pruebas 271

9.2 Reuniones de estado, informes y problemas de control

9.5 Control y seguimiento: tres puntos de vista críticos 296

Lista de términos clave 300

10 REVISIONES COMO ACTIVIDAD DE PRUEBA

10.0 Expansión del paraguas de actividades de prueba 303 10.1

técnica 308 10.1.2 Recorridos como tipo de revisión técnica 310

10.2 Desarrollo de un programa de revisión 311 10.3

10.4 Componentes de los planes de revisión 314

10.4.1 Objetivos de revisión 315

10.4.5 Revisar la capacitación 320

10.5 Informes de los resultados de la revisión 333

10.8 Soporte del modelo V ampliado/modificado 340 10.9 Autocomprobación

Lista de términos clave 345

UN PROGRAMA DE MEDICIÓN PARA APOYAR

11.0 La necesidad de un programa de medición de prueba formal 349 11.1

11.2 Inicio de un programa de medición 354 11.3

11.4.1 Mediciones para TMM Nivel 1 373

EVALUACIÓN DE LA CALIDAD DEL SOFTWARE:

12.0 Revisión de los conceptos de calidad 393

13 ANÁLISIS Y PREVENCIÓN DE DEFECTOS