Fundamentos de Pruebas de Software - Introducción

CONTENIDO
PRÓLOGO
OBJETIVOS
DESTINATARIOS
UNA BREVE HISTORIA DE LAS PRUEBAS DE SOFTWARE
CAPÍTULO 1
FUNDAMENTOS DE PRUEBAS
1.1 ¿POR QUÉ SON NECESARIAS LAS PRUEBAS?
1.2 ¿QUÉ SON LAS PRUEBAS?
1.2.1 EJERCICIOS
Ejercicio 1
Solución del Ejercicio 1
1.3 PRINCIPIOS GENERALES DE LAS PRUEBAS
1.3.1 EJERCICIOS
Ejercicio 1
1.4 PROCESO DE PRUEBAS BÁSICO
1.4.1 EJERCICIOS
Ejercicio 1
1.5 LA PSICOLOGÍA DE PRUEBAS
1.5.1 EJERCICIOS
Ejercicio 1
1.6 CÓDIGO DE ÉTICAS
PREGUNTAS DE EXAMEN DE MUESTRA Y SIMULACIÓN
Sección 1.1: ¿Por qué son necesarias las pruebas? (K2)
Sección 1.2: ¿Qué son las pruebas? (K2)
Sección 1.3: Principios generales de las pruebas (K2)
Sección 1.4: Proceso de pruebas básico (K1)
Sección 1.5: La psicología de las pruebas (K2)
Sección 1.6: Código de éticas (K2)
Capítulo 1 Pregunta que cubre secciones
Preguntas del Examen de simulación 1
Preguntas del Examen de Simulación 2
CAPÍTULO 2

PRUEBAS A TRAVÉS DEL CICLO DE VIDA DE SOFTWARE
2.1 MODELOS DE DESARROLLO DE SOFTWARE
2.1.1 EJERCICIOS
Ejercicio 1
Ejercicio 2
2.2 NIVELES O FASES DE PRUEBAS
2.2.1 EJERCICIOS
Ejercicio 1
2.3 TIPOS U OBJETIVOS DE LAS PRUEBAS
2.3.1 EJERCICIOS
Ejercicio 1
2.4 PRUEBAS DE MANTENIMIENTO
2.4.1 EJERCICIOS
Ejercicio 1
Sección 2.1 Modelos de desarrollo de software (K2)
Sección 2.2 Niveles de pruebas (K2)
Sección 2.3: Tipos de pruebas (K2)
Sección 2.4: Pruebas de mantenimiento (K2)
Capítulo 2 Preguntas a través de las secciones
CAPÍTULO 3
TÉCNICAS ESTÁTICAS
3.1 TÉCNICAS ESTÁTICAS Y EL PROCESO DE PRUEBAS
3.1.1 EJERCICIOS
Ejercicio 1
3.2 PROCESO DE REVISIÓN
3.2.1 EJERCICIOS
Ejercicio 1
3.3 ANÁLISIS ESTÁTICO POR MEDIO DE HERRAMIENTAS

3.3.1 EJERCICIOS
Ejercicio 1
Sección 3.1 Técnicas estáticas y el proceso de pruebas (K2)
Sección 3.2 Proceso de revisión (K2)
Sección 3.3: Análisis estáticos por herramientas (K2)
Capítulo 3 Pregunta a través de las secciones
CAPÍTULO 4
TÉCNICAS DE DISEÑO DE PRUEBAS
4.1 PROCESO DE DESARROLLO DE PRUEBAS
4.1.1 EJERCICIOS
Ejercicio 1
Ejercicio 2
4.2 CATEGORÍAS DE LAS TÉCNICAS DE DISEñO DE PRUEBAS
4.2.1 EJERCICIOS
Ejercicio 1
Ejercicio 2
Ejercicio 3
Ejercicio 4
4.3 TÉCNICAS BASADAS EN LA ESPECIFICACIÓN
4.4 TÉCNICAS BASADAS EN LA ESTRUCTURA
4.4.1 EJERCICIOS
Ejercicio 1
4.5 TÉCNICAS BASADAS EN LA EXPERIENCIA
4.5.1 EJERCICIOS
Ejercicio 1
4.6 SELECCIÓN DE LAS TÉCNICAS DE PRUEBAS
4.6.1 EJERCICIOS
Ejercicio 1

Sección 4.1 El proceso de desarrollo de pruebas (K3)
Sección 4.2 Categorías de las técnicas de diseño de pruebas (K2)
Sección 4.3 Técnicas basadas en la especificación o de caja negra (K3)
Sección 4.4 Técnicas basadas en la estructura de caja blanca (K3)
Sección 4.5 Técnicas basadas en la experiencia (K2)
Sección 4.6 Selección de las técnicas de pruebas (K2)
Capítulo 4 Pregunta de todas las secciones
CAPÍTULO 5
GESTIÓN DE PRUEBAS
5.1 ORGANIZACIÓN DE PRUEBAS
5.1.1 EJERCICIOS
Ejercicio 1
5.2 PLANIFICACIÓN Y ESTIMACIÓN DE PRUEBAS
5.2.1 EJERCICIOS
Ejercicio 1
5.3 MONITOREO Y CONTROL DEL PROGRESO DE LAS PRUEBAS
5.3.1 EJERCICIOS
Ejercicio 1
5.4 GESTIÓN DE CONFIGURACIÓN
5.4.1 EJERCICIOS
Ejercicio 1
5.5 RIESGO Y PRUEBAS
5.5.1 EJERCICIOS
Ejercicio 1
5.6 GESTIÓN DE DEFECTOS O INCIDENCIAS
5.6.1 EJERCICIOS
Ejercicio 1
Sección 5.1 Organización de pruebas (K2)
Sección 5.2 Planificación y estimación de pruebas (K2)
Sección 5.3 Monitoreo y control del progreso de pruebas (K2)
Sección 5.4 Gestión de Configuraciones (K2)

Sección 5.5 Riesgos y Pruebas (K2)
Sección 5.6 Gestión de incidencias (K3)
CAPÍTULO 6
SOPORTE DE HERRAMIENTAS PARA LAS PRUEBAS
6.1 TIPOS DE HERRAMIENTAS DE PRUEBAS
6.1.1 EJERCICIOS
Ejercicio 1
6.2 USO EFECTIVO DE HERRAMIENTAS, LOS BENEFICIOS Y LOS RIEGOS POTENCIALES
6.2.1 EJERCICIOS
Ejercicio 1
6.3 INTRODUCCIÓN DE UNA HERRAMIENTA EN UNA ORGANIZACIÓN
6.3.1 EJERCICIOS
Ejercicio 1
Sección 6.1 Tipos de herramientas de pruebas (K2)
Sección 6.2: Utilización efectiva de las herramientas: beneficios y riesgos potenciales
(K2)
Sección 6.3: Introducción de una herramienta en una organización (K1)
APÉNDICE A
OMNINET: EL INTERNET EN TODAS PARTES
DOCUMENTO DE LOS REQUISITOS DE MARKETING
1. ALCANCE
1.1 Términos, Acrónimos y Abreviaciones
1.2 Documentos Aplicables
2. FECHA DE LA VERSIÓN REQUERIDA
3. DESCRIPCIÓN DE LOS REQUISITOS
3.1 Requisitos técnicos generales

3.1.1 Bienvenida
3.1.2 Pago
3.1.3 Navegador de Internet
3.1.4 Rendimiento
3.1.5 Localización
3.1.6 Control de Contenido
3.1.7 Terminación de la Sesión
3.1.8 Confidencialidad
3.2 Administración
3.2.1 Actualizaciones de Software
3.2.2 Vista de los Quioscos
3.2.3 Vista de los Usuarios
3.2.4 Modificar el Usuario
3.2.5 Terminar el Usuario
APÉNDICE B
OMNINET: EL INTERNET EN TODAS PARTES. DOCUMENTO DE LOS
REQUISITOS DEL SISTEMA
REQUISITOS FUNCIONALES DEL SISTEMA
REQUISITOS DE FIABILIDAD DEL SISTEMA
REQUISITOS DE USABILIDAD DEL SISTEMA
REQUISITOS DE EFICIENCIA DEL SISTEMA
REQUISITOS DE MANTENIBILIDAD DEL SISTEMA
REQUISITOS DE PORTABILIDAD DEL SISTEMA
MODELOS DEL DISEñO
Arquitectura del Sistema Omninet
Tabla de Decisiones del Procesamiento del Pago
Flujo del Módulo del Quiosco
Diagrama de Transiciones de Estado del Quiosco
Tabla de Transiciones de Estado del Quiosco
Array Ortogonal de la Configuración del Quiosco con respecto al Sistema Operativo
del Quiosco/el Navegador/la Velocidad de Conexión
APÉNDICE C
SOLUCIONES DE LAS PREGUNTAS DE EXAMEN DE MUESTRA Y SIMULACIÓN
CAPÍTULO 1: FUNDAMENTOS DE PRUEBAS (K2)
Sección 1.1: ¿Por qué son las pruebas necesarias? (K2)
Sección 1.2: ¿Qué son las pruebas? (K2)
Sección 1.3: Principios generales de pruebas (K2)

Sección 1.4: Proceso de pruebas básico (K1)
Sección 1.5: La psicología de las pruebas (K2)
Sección 1.6: Código de éticas (K2)
CAPÍTULO 2: PRUEBAS A TRAVÉS DEL CICLO DE VIDA DE SOFTWARE (K2)
Sección 2.1 Modelos de desarrollo de software (K2)
Sección 2.2 Niveles de pruebas (K2)
Sección 2.3: Tipos de pruebas: los objetivos de las pruebas (K2)
Sección 2.4: Pruebas de mantenimiento (K2)
CAPÍTULO 3.0: TÉCNICAS ESTÁTICAS (K2)
Sección 3.1 Revisiones y el proceso de pruebas (K2)
Sección 3.2 Proceso de revisión (K2)
Sección 3.3: Análisis estático por herramientas (K2)
CAPÍTULO 4.0: TÉCNICAS DE DISEÑO DE PRUEBAS (K3)
Sección 4.1 Proceso de desarrollo de pruebas (K3)
Sección 4.2 Categorías de las técnicas de diseño de pruebas (K2)
Sección 4.3 Técnicas basadas en la especificación o de caja negra (K3)
Sección 4.4 Técnicas basadas en la estructura o de caja blanca (K3)
Sección 4.5 Técnicas basadas en la experiencia (K2)
Sección 4.6 Selección de las técnicas de pruebas (K2)
CAPÍTULO 5.0: GESTIÓN DE PRUEBAS (K3)
Sección 5.1 Organización de las pruebas (K2)
Sección 5.2 Planificación y estimación de pruebas (K2)
Sección 5.3 Monitoreo y control del progreso de las pruebas (K2)
Sección 5.4 Gestión de configuraciones (K2)
Sección 5.5 Riesgo y pruebas (K2)
Sección 5.6 Gestión de incidencias (K3)
CAPÍTULO 6.0: SOPORTE DE HERRAMIENTAS PARA PRUEBAS (K2)
Sección 6.1 Tipos de herramientas de pruebas (K2)
Sección 6.2: Utilización efectiva de herramientas: beneficios y riesgos potenciales
(K2)

Sección 6.3: Introducción de una herramienta en una organización (K1)
APÉNDICE D
LISTA DE LOS ESTÁNDARES DE PRUEBAS
APÉNDICE E
PREPARACIÓN PARA EL EXAMEN
APÉNDICE F
ACRÓNIMOS
APÉNDICE G
BIBLIOGRAFÍA
PERFIL DE RBCS
PERFIL DE BUSINESS INNOVATIONS
ÍNDICE ANALÍTICO
Acerca de los Autores

Prólogo
En los últimos años hemos observado que la producción de software ha crecido
exponencialmente en todo el mundo. La cantidad de software en todo tipo de
dispositivos está aumentando rápidamente. Por ejemplo, se espera que la cantidad de
código fuente en un teléfono móvil aumente a 10 millones de líneas de código entre
los años 2010 y 2011 1. En el mismo período, el software de un automóvil podría
crecer hasta un máximo de 100 millones de líneas de código. El sistema de software
del control de vuelo del Boeing 787 consta de 6,5 millones de líneas de código, cerca
de tres veces más que el Boeing 7772. Todo tipo de nuevas aplicaciones e
infraestructuras dependen en gran medida del software, incluidas las redes sociales,
el video por Internet, los sistemas de alerta temprana, los sistemas de información
médica y los sistemas financieros. A raíz de este crecimiento las exigencias de la
calidad del software ahora son mayores y el cliente espera el menor número de fallas
posibles cuando el software ya está funcionando con clientes finales, por lo tanto eso
significa mayores ganancias en el negocio y la reducción de los riesgos de las
pérdidas económicas, de tiempo y reputación, los desastres ambientales, las lesiones
o la muerte. Por ejemplo:
“Millones de cuentas bancarias fueron impactadas por defectos debido a la
instalación de un código de software probado incorrectamente en el sistema de
procesamiento de transacciones del banco North American Bank en E.E.U.U. Las
pérdidas excedieron los 100 millones de dólares”.
No hay suficientes estadísticas publicadas acerca del porcentaje de instituciones que
han tenido problemas en el software pero eso no quiere decir que no hay defectos o
pérdidas en el negocio.
Esos incidentes originan una serie de preguntas. ¿Por qué los problemas del software
no fueron detectados antes a pesar de todas las herramientas modernas a disposición
de los ingenieros de sistemas? ¿Cómo puede ser remediada esta situación? Una gran
parte de las respuestas a estas preguntas caen en una de las áreas más desatendidas
del desarrollo y despliegue de productos de software—Las Pruebas de Software.
Las Pruebas de Software son predominantemente consideradas como una actividad
periférica, casi una formalidad, antes del despliegue del software. Un cambio de
actitud hacia las Pruebas de Software puede reducir tremendamente los problemas
normalmente asociados con el lanzamiento del nuevo software y minimizar los riesgos
implicados. Las Pruebas de Software consisten en un proceso crítico para asegurar
que el software sea entregado al cliente libre de defectos, y debería ser tratado como
tal.
En la actualidad la mayoría de las organizaciones no cuentan con un personal
profesional en Pruebas de Software para gestionar un proceso de control de calidad

paralelo al proceso de desarrollo porque las empresas tercerizadas están más
orientadas al desarrollo por lo cual hay una cierta parcialización hacia el software
desarrollado por parte del fabricante. Las Pruebas de Software requieren un
conocimiento especializado y profesional con una metodología diferente que escribir
código o construir software. Un peligro inherente de contratar los servicios de control
de calidad del software del mismo fabricante es el conflicto de interés.
Por lo tanto, debido a este conflicto de interés y la criticidad del software tiene
sentido la separación del desarrollo y las Pruebas de Software en equipos separados
y además las Pruebas de Software deben ser llevadas a cabo por personas que
conocen las técnicas y métodos, y tienen experiencia y conocimiento del dominio del
negocio y las herramientas de Pruebas de Software. Entonces en el mundo se han
creado diversos programas estándar de estudios para satisfacer las necesidades en la
calidad del software, de los cuáles uno de los más reconocidos a nivel mundial es la
Certificación en Pruebas de Software (“Software Testing Certification”) del ISTQB
(“International Software Testing Qualifications Board”) que propone diversos cursos
de estudios para distintos niveles de experticia, así como el nivel básico, tres niveles
avanzados, el nivel avanzado completo y el nivel experto. En este libro trataremos el
nivel básico según el programa de estudios 2011.
Por Gary Rueda Sandoval

Objetivos
Este libro proporciona a los Ingenieros de Pruebas y Jefes de Pruebas el fundamento, los
procesos, las herramientas y habilidades esenciales que ellos necesitan para posicionarse
en un camino hacia el verdadero profesionalismo en pruebas. Este libro práctico cubre las
principales técnicas de diseño de pruebas por medio de la clase y los ejercicios. El libro
proporciona la metodología detrás de un programa de pruebas exitoso y cubre una amplia
gama de temas, desde aquellos relacionados con el probador individual hasta los
relacionados con el departamento de pruebas en su totalidad. El proceso de pruebas es
presentado, tanto a través de la teoría como mediante ejercicios prácticos que siguen un
proyecto como ejemplo, incluyendo las tareas difíciles como el seguimiento y la
presentación de los resultados de las pruebas. Así mismo incluye la creación de un entorno
de pruebas y automatización de pruebas junto con los ciclos de vida del desarrollo de
sistemas y cómo estos afectan a las pruebas.
Este libro le proporciona una guía de auto-estudio para pasar el examen Probador
Certificado ISTQB Nivel Básico (ISTQB Certified Tester Foundation Level”) que incluye
los seis capítulos, un glosario de los términos más importantes, ejercicios prácticos y sus
soluciones por cada capítulo junto con dos exámenes de simulación y con más de 200
preguntas de muestra que abarcan cada objetivo del aprendizaje del Programa de Estudios
(“Syllabus”) 3, una orientación acerca de cómo prepararse para el examen, y más.

A través de los capítulos, la argumentación y los ejercicios prácticos, usted aprenderá a:
Explicar los efectos y el daño que los defectos pueden causar.
Articular la necesidad de las pruebas.
Describir el rol de las pruebas en el aseguramiento de la calidad.
Identificar los objetivos, los principios y los propósitos comunes de las pruebas.
Introducir procesos de pruebas estructurados, pre-planificados.
Adaptarse a los factores psicológicos y gestionarlos para el éxito de las pruebas.
Relacionar las actividades de desarrollo y pruebas.
Adaptar los modelos de desarrollo de software al contexto del proyecto y el
producto.
Seleccionar e implementar niveles o fases adecuadas de las pruebas, con los
participantes, los objetivos, las metas y los ítems apropiados sometido a prueba
para cada nivel o fase de prueba.
Seleccionar y planificar los principales tipos u objetivos de las pruebas,
incluyendo las pruebas funcionales y no funcionales, las pruebas estructurales,
las pruebas de confirmación y las pruebas de regresión.
Explicar las razones para las pruebas de mantenimiento y cómo las pruebas de
mantenimiento se diferencian de las pruebas de aplicaciones nuevas.
Entender el valor, la importancia y la utilización de las técnicas estáticas y el
análisis estático, y la diferencia entre las técnicas estáticas y dinámicas.
Explicar las fases, los roles y las responsabilidades de una revisión formal
típica, y comparar los diferentes tipos de revisiones.
Comprender los factores para las revisiones exitosas.
Comprender y realizar un análisis de los riesgos de calidad para que sirva como
la base para las pruebas, utilizando los factores de probabilidad e impacto para
determinar el nivel de riesgo.
Escribir diseños, casos y procedimientos de prueba, relacionarlos entre sí, y
rastrear estos ítems a la base de las pruebas.
Desarrollar un cronograma de ejecución de las pruebas.
Explicar las características, las diferencias y las razones para las pruebas
basadas en la especificación (caja negra), basadas en la estructura (caja blanca),
y basadas en la experiencia.
Escribir casos de prueba utilizando el particionamiento4 (“partitioning”) de
equivalencias, el análisis de valores límite, las tablas de decisión y los
diagramas de transición de estados, comprendiendo el propósito principal de
cada técnica y qué cantidad de cobertura es suficiente para cada técnica.
Escribir y medir los casos de prueba utilizando los conceptos de pruebas
estructurales como la cobertura, la cobertura de sentencia y decisión y otras
técnicas de diseño de pruebas del flujo de control.
Comprender los factores que influyen en la selección de las técnicas apropiadas
de diseño de pruebas.
Explicar la importancia de las pruebas independientes.
Comprender los beneficios y las desventajas de las pruebas independientes.

Seleccionar los distintos miembros del equipo para su inclusión en un equipo de
pruebas.
Saber las tareas de un líder y probador típico.
Comprender y escribir varios tipos de planes de pruebas dependiendo del
proyecto, los niveles y los objetivos.
Estimación de las pruebas a través de las métricas y la experticia, y reconocer
los factores que afectan una estimación.
Comprender, utilizar e interpretar las métricas comunes para monitorear la
preparación y la ejecución de las pruebas.
Explicar cómo la gestión de configuración apoya a las pruebas.
Saber los daños típicos y riesgos potenciales para las pruebas.
Diferenciar entre los riesgos de proyecto y calidad (del producto).
Escribir un buen informe de defecto o incidencia, con el contenido apropiado.
Conocer los diferentes tipos de las herramientas de pruebas, incluyendo las
herramientas de pruebas de los programadores.
Explicar las diferentes técnicas de guiones para las herramientas de ejecución de
pruebas, incluyendo las dirigidas por datos y las dirigidas por palabras clave.
Saber los beneficios y los riesgos potenciales de la automatización de pruebas.
Planificar la introducción de una herramienta de pruebas en una organización.
Formular las metas de una prueba de concepto para la evaluación de una
herramienta de pruebas.
Explicar los factores necesarios para un buen soporte de herramientas.

Destinatarios
Este libro no es sólo para los probadores sino también para quienes están encargados de la
adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de
la Calidad/Control de la Calidad (“QA/QC”), gerentes de sistemas, jefes de proyectos de
software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.

Una breve historia de las Pruebas de Software
Desde los comienzos de la computación hubo pruebas. La siguiente clasificación (por
supuesto hay más) fue creada en 1988 por D. Gelperin y W.C. Hetzel 5. Ellos clasificaron
las pruebas de software con las siguientes fases y metas:
Hasta 1956 fue el período orientado a la depuración, donde las pruebas eran asociadas a la
depuración: no había una clara diferencia entre las pruebas y la depuración.
De 1957 a 1978 fue el período orientado a la demostración, donde la depuración y las
pruebas fueron diferenciados ahora – en este período fue demostrado que el software
satisface los requisitos.

De 1979 a 1982 fue el período orientado a la destrucción, donde la meta era de encontrar
errores.
De 1983 a 1987 fue el período orientado a la evaluación: la intención aquí es de que
durante el ciclo de vida del software una evaluación del producto es proveído y una
medición de su calidad.
De 1988 hasta la fecha fue el período de la prevención donde las pruebas estarían para
demostrar que el software satisface su especificación, para detectar y prevenir los
defectos.
_____________________________
1. R.N. Charette, “Why Software Fails,” IEEE Spectrum, vol. 42, no. 9, 2005, pp. 42–
49.
M. Mecham, “Boeing Faces ‘Pretty Tight’ 787 Delivery Schedule,” Aviation Week, 9
2
Sept. 2007
Es un programa, esquema o plan de estudios de un texto, una conferencia o curso de
3
estudio.
Aunque no está definido en la Real Academia Española, es un término muy utilizado
4
para indicar el sustantivo de la acción de partir algo en particiones.
Gelperin, D.; B. Hetzel (1988). “The Growth of Software Testing”. CACM 31 (6).
5
ISSN 0001-0782.
1

Fundamentos de Pruebas de Software - Introducción

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (16)

Similaire à Fundamentos de Pruebas de Software - Introducción

Similaire à Fundamentos de Pruebas de Software - Introducción (20)

Plus de Professional Testing

Plus de Professional Testing (20)

Dernier

Dernier (20)

Fundamentos de Pruebas de Software - Introducción