ING, CFTL

ALEX VIDAURRE

Curso Taller

ISTQB Foundation
“Taller de Preparación para la Certificación”

Módulo 02
Las pruebas en el ciclo de vida de
software

P-1
www.jbenterprisegroup.com
 Agenda
• Modelos de desarrollo de software.
• Niveles de pruebas.
– Pruebas de componentes.
– Pruebas de integración.
– Pruebas de sistema.
– Pruebas de aceptación.
• Tipos de pruebas.
• Pruebas de mantenimiento.

MODELOS DE DESARROLLO DE
SOFTWARE
INTRODUCCIÓN

• El proceso de desarrollo adoptado para un proyecto, dependerá de sus objetivos

y proyecciones.

• Las pruebas se dan dentro del ciclo de vida del desarrollo de software. El tipo y
nivel de la prueba se define según la parte del ciclo de vida en el que se encuentra el
desarrollo del software.

• Es importante conocer el modelo de ciclo de vida adoptado por el proyecto para

poder definir correctamente la estrategia de pruebas del mismo.

• En todos los ciclos de vida, una parte de las pruebas está enfocada a la
“Verificación” y otra parte a la “Validación”.

P-2
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO CASCADA

• El modelo de cascada fue uno de los primeros modelos que se diseño. Tiene una
línea de tiempo natural, donde las tareas se ejecutan de manera secuencial.

DEFICIENCIAS:
• Los errores se encontraban en
etapas muy avanzadas del proyecto
(generaba mayores costos y tiempo)

• Es un modelo muy lineal y en

consecuencia no puede soportar
muchas iteraciones (cambios o
variaciones en el ciclo de vida).

MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V (V-MODEL)

• El modelo V se desarrolló para abordar algunos de los problemas experimentados

utilizando el método de cascada tradicional.

• El modelo V es un modelo que ilustra cómo las actividades de las pruebas

(verificación y validación) pueden ser integrados en cada fase del ciclo de vida.
Dentro de el modelo V, las pruebas de validación se lleva a cabo especialmente
durante los primeros etapas, por ejemplo revisar los requisitos del usuario, y al final
del ciclo de vida, por ejemplo, durante las pruebas de aceptación del usuario.

• Realizar pruebas tan pronto como sea

posible en el ciclo de vida.
• Realizar las actividades de pruebas en
paralelo con las actividades de desarrollo
del software. (trabajo en conjunto)

P-3
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V

– Los cuatro niveles de prueba utilizados son los siguientes:

• Pruebas de componentes: busca defectos y verifica el funcionamiento de
los componentes de software (por ejemplo, módulos, programas, objetos,
clases, etc.). Cada componente es probado por separado.
• Pruebas de integración: pruebas de interfases entre los componentes, las
interacciones entre diferentes partes de un sistema; como: un sistema
operativo, sistema de archivos y hardware o interfases entre los sistemas.
• Pruebas del sistema: que se trata del comportamiento de todo el
sistema/producto definido por el alcance de un proyecto. El objetivo
principal de las pruebas del sistema es la verificación de los requerimientos
especificados.
• Pruebas de aceptación: las pruebas de validación con respecto a las
necesidades del usuario, requerimientos y procesos empresariales, para
determinar si se procede o no a aceptar el sistema.

MODELOS DE DESARROLLO DE
SOFTWARE

MODELO V

• CMMI
• ISO / IEC 12207

P-4
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: NIVELES DE PRUEBA
Requerimientos Pruebas
de Negocio de Aceptación

Especificación Pruebas de Integración

del Proyecto De Sistemas

Especificación
Pruebas de Sistemas
Del Sistema

Pruebas de Integración
Especificación de Diseño
De Componentes

Código Pruebas de Componentes

MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: DISEÑO DE PRUEBA FINAL Prueba

Requerimientos Pruebas
del Negocio de Aceptación

Prueba

Especificación “No hay Pruebas de

del Proyecto tiempo para diseñar Integración de Sitemas
las pruebas tempranamente”
Prueba

Especificaciones
Pruebas de Sistemas
del Sistema
Prueba
Pruebas de
Especificaciones
integración de
de Diseño
Componentes
Prueba

Pruebas de
¿Diseño de
Código Pruebas?
Componentes

P-5
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: DISEÑO DE PRUEBAS TEMPRANAS

Prueba
Requerimientos Pruebas
del Negocio de aceptación

Prueba Pruebas de
Especificación
integración de
del Proyecto
Sistemas
Prueba
Especificaciones
Sistema de prueba
del Sistema

Prueba Prueba de
Especificaciones integración de
de Diseño
Componentes
Prueba Ejecución
Diseño de Componente
Código de
Pruebas de pruebas Pruebas

MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: DISEÑO DE PRUEBAS TEMPRANAS

– El diseño de las pruebas encuentra defectos.

– Los defectos se hallan tempranamente y son más baratos de
reparar.
– Los defectos más significativos se hallan tempranamente.
– Los defectos evitados, no se construyen.
– Ningún esfuerzo adicional, rediseñar del calendario de
pruebas.
– Cambios en los requisitos causados por el diseño de las
pruebas.

El diseño de pruebas anticipado ayuda en la

construcción de la calidad, y detiene la
multiplicación de las fallas.

P-6
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: INFORME DE EXPERIENCIA - FASE 1

Fase 1: Plan 2 meses 2 meses

desarrollo prueba
“tiene que ir en"
Pero no funcionó

Real

tensión, muchas horas extras de desarrollo

Calidad prueba 1er mes. usuario

no
150 fallas 50 fallas feliz

MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: INFORME DE EXPERIENCIA- FASE 2

Fase 2: Plan 2 meses 6 semanas

según pruebas: semana
desarrollo prueba completa (vs. medio día)

Real a tiempo

sin problemas, desarrollo no tuvo mucho que hacer

Calidad pruebas 1er mes

Usuario
50 defectos 0 defectos feliz!

Fuente: Simon Barlow y Veitch, Alan, Scottish Widows, febrero 96

P-7
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: VALIDACIÓN, VERIFICACIÓN Y PRUEBAS

– Verificación
• Confirmación por evaluación y a través de la aportación de evidencia
objetiva que se han satisfecho los requisitos especificados. [ISO 9000]

– Validación
• Confirmación por examen y a través de la aportación de evidencia objetiva
que han sido satisfechos los requisitos para un uso o aplicación previstos.
[ISO 9000]

– Pruebas
• El proceso de ejercitar el software para confirmar que se satisfacen los
requisitos especificados y para detectar defectos.

MODELOS DE DESARROLLO DE
SOFTWARE
MODELO V: VERIFICACIÓN, VALIDACIÓN Y PRUEBAS
Validación

Prueba
Fase

Verificación

P-8
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
CICLO DE VIDA ITERATIVO

• En lugar de trabajar en una gran línea de tiempo, se puede dividir un proyecto en

pequeñas ciclos de vida, de manera que se puedan aplicar las revisiones y pruebas a
cada iteración de principio a fin.

(*)Pruebas de integración y
regresión

MODELOS DE DESARROLLO DE
SOFTWARE
CICLO DE VIDA ITERATIVO

– Ejemplos de modelos de desarrollo iterativo o incremental son:

Prototipos, Desarrollo rápido de aplicaciones (RAD), Rational Unified Process
(RUP) y Desarrollo ágil.
• RAD: funciones/componentes son desarrolladas en paralelo como si se
trataran de mini proyectos.

P-9
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
• CICLO DE VIDA ITERATIVO

• Desarrollo en paralelo de componentes y funciones

• Rápidos resultados iniciales (El cliente puede ver algo del proyecto desde un
principio)
• Rápida respuesta ante los cambios en los requerimientos de los clientes
• Ayuda a recibir retroalimentación por parte de los clientes

MODELOS DE DESARROLLO DE
SOFTWARE
CICLOS DE VIDA ITERATIVO

– XP: Se preparan todos los casos de prueba posibles, para luego

automatizarlos. Cada vez que se realiza un cambio, se realiza una prueba de
componente y luego se integra con el resto. Los cambios se realizan sobre la
marcha.

– Promueve la generación de historias de negocios para definir la

funcionalidad.
– Exige un cliente en el lugar para una continua retroalimentación para
definir y llevar a cabo las pruebas de aceptación funcional.
– Promueve la programación por parejas y la propiedad de código
compartido.
– Los Scripts de pruebas de componentes deberá ser escrito antes de
que el código está escrito y que las pruebas sean automatizados.
– Integración y pruebas se realizan varias veces al día.
– Implementar la solución más simple para solucionar los problemas del
día a día.

P-10
www.jbenterprisegroup.com
 MODELOS DE DESARROLLO DE
SOFTWARE
PRUEBAS DENTRO DE UN MODELO DE CICLO DE VIDA

– Por cada actividad de desarrollo existe una actividad de prueba

correspondiente.
– Cada nivel de prueba tiene un objetivo de prueba específico para ese
nivel.
– El análisis y diseño de las pruebas para un un nivel de prueba debe
comenzar durante las actividades de desarrollo correspondientes.
– El Tester deben participar en la revisión de los documentos tan pronto
como estén disponibles en el ciclo de desarrollo.

NIVELES DE PRUEBA
PRUEBAS DE COMPONENTES

– Las pruebas de componentes, también conocida como prueba

unitaria, módulo o de programa.

– Verifica el funcionamiento y busca defectos en los componentes de

software que pueden ser analizados individualmente. (Ejemplo:
módulos, programas, objetos y clases).
– Como se analizan individualmente, se utilizan “stubs” y “drivers” para
reemplazar el software faltante y simular la interfases entre los
componentes del software. (Test Harness). (El ‘driver’ reemplaza a un
componente que ‘llama’ a otro componente; mientras que el ‘stub’
reemplaza a un componente que es llamado por otro componente).

P-11
www.jbenterprisegroup.com
 NIVELES DE PRUEBA
• PRUEBAS DE COMPONENTES

– Generalmente ejecutados por los desarrolladores.

– Se utilizan herramientas del entorno de desarrollo (IDEs, depuradores,
etc.) que permiten el acceso al código
– Usualmente los errores se arreglan al momento (sin necesidad de
documentarlos).
– El conocimiento del código permite la aplicación de métodos de caja
blanca.
– Puede incluir pruebas de funcionalidad y no funcionales (por ejemplo,
pérdidas de memoria), el rendimiento robustez, así como las pruebas
estructurales (por ejemplo, la decisión, cobertura).
– Utilizados en Extreme Programming (XP) para preparar y automatizar
casos de prueba antes de codificar. Esto se llama una prueba de primer
enfoque o desarrollo basado en pruebas.

NIVELES DE PRUEBA

PRUEBA DE INTEGRACIÓN

Pruebas aplicadas a interfases de distintos componentes o a las

interacciones ente distintas partes de un sistema.
– Se puede dividir en:
Pruebas de integración de componentes
Prueba las interacciones entre los componentes de un sistema. Se
realiza después de las pruebas de componentes.

Pruebas de integración de sistemas.

Prueba las interacciones entre los sistemas. Generalmente se realiza
después de las pruebas de sistemas.

P-12
www.jbenterprisegroup.com
 NIVELES DE PRUEBA

PRUEBA DE INTEGRACIÓN – ENFOQUES

Pruebas de integración ‘Big-Bang’

– Se realiza cuando todos los componentes o sistemas están
completamente probados.
– Se prueba el integrado como un todo.
– Ventaja: No se tienen que simular partes.
– Desventaja: Ocupa tiempo y dificultad para rastrear fallas.

Pruebas de integración ‘paso por paso’

– Los componentes se integran uno por uno y en cada integración se
realizan las pruebas.
– Testeo incremental.
– Ventaja: Es fácil de rastrear las fallas
– Se deben simular partes, por lo que demanda más tiempo.

NIVELES DE PRUEBA

PRUEBA DE INTEGRACIÓN – ENFOQUE “PASO POR PASO”

– Top-Down: Las pruebas se realizan desde el principio hasta el final,

siguiendo el flujo de control.
– Bottom-Up: Las pruebas se realizan desde el final del flujo de control
hasta el principio.
– Funcionales: Las pruebas se llevan a cabo en base a las funcionalidades,
según lo documentado en la especificación funcional.

P-13
www.jbenterprisegroup.com
 NIVELES DE PRUEBA
PRUEBAS DE SISTEMAS

Se concentra en el comportamiento de todo el sistema. Se incluyen pruebas

basadas en requerimientos, riesgos, casos de uso, procesos de negocio, etc.
Se realizan tanto pruebas funcionales como no funcionales.
– Relacionado con el comportamiento de todo el sistema en su totalidad,
según haya sido redefinido en el alcance del proyecto.
– Comprueba que el sistema construido cumpla con todas sus
especificaciones.
– Analiza requerimientos funcionales (Pruebas de caja negra y caja blanca) y
también requerimientos no funcionales (desempeño).
– Se realiza en un entorno de pruebas, para tener mayor control sobre el
proceso.
– Tipo: Verificación.

NIVELES DE PRUEBA
PRUEBAS DE ACEPTACIÓN

– Se presenta el software al cliente para su aceptación.

– Es el cliente quien debe decidir si el producto está listo.
– Se realiza en un entorno de pruebas, simulando ser el entorno donde será
implementado el software.
– No está enfocado en encontrar errores.
– Tipo: Validación.
– También se puede dividir en niveles. Ejemplos:
• Las pruebas de aceptación de usabilidad de componentes se deben realizar
durante las pruebas de componentes.
• Las pruebas de aceptación para una nueva mejora de funcionalidad se deben
realizar antes de las pruebas de sistema.

P-14
www.jbenterprisegroup.com
 NIVELES DE PRUEBA

PRUEBAS DE ACEPTACIÓN

– Pruebas de aceptación del usuario

– Funcionalidad
– Pruebas de aceptación operacional
– Pruebas de backup, restore, recuperación de información,
seguridad, tareas de mantenimiento, etc.
– Pruebas aceptación de contratos
– Se prueba el sistema contra un criterio de aceptación previamente
definido en un contrato.

NIVELES DE PRUEBA

PRUEBA DE ACEPTACIÓN

Pruebas de aceptación regulatorias

– Respecto a regulaciones legales, gubernamentales, de seguridad, etc.

Pruebas Alfa
– Pruebas internas.
– Se realiza en el entorno del desarrollador.

Pruebas Beta
– También llamado ‘pruebas de campo’.
– Usuarios externos usan el producto.
– Ambientes de trabajo reales.
– Los usuarios informan de los errores o incidentes encontrados mientras
usaban el producto

P-15
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS

PRUEBAS DEL SISTEMA

– Funcional
• Pruebas basadas en requisitos funcionales y especificaciones
funcionales.
• Pruebas basadas en los procesos de negocio.

– No-funcionales
• Tan importantes como los requisitos funcionales
• A menudo mal especificadas.
• Deben probarse.

– A menudo son realizadas por un equipo de pruebas independiente.

TIPOS DE PRUEBAS
PRUEBAS FUNCIONALES

– Requisitos funcionales
• Un requisito que especifica una función que un componente del
sistema o el sistema debe realizar (ANSI / IEEE std 729-1983,
ingeniería de software de terminología)

– Especificación funcional
• El documento que describe en detalle las características del
producto con respecto a su capacidad de intención (BS 4778 parte
2, BS 7925-1)

P-16
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS

PRUEBAS BASADAS EN REQUERIMIENTOS

– Utiliza la especificación de requisitos como base para la
identificación de las pruebas.
– El índice de la especificación de requisitos proporciona un
inventario inicial de las condiciones de pruebas.
– Para cada sección/ párrafo/ tema/ área funcional,
• Aplicar análisis de riesgos para identificar los más
importantes/críticas.
• Decidir hasta qué punto va a probar cada área funcional.

TIPOS DE PRUEBAS
PRUEBAS BASADAS EN PROCESOS DE NEGOCIO

— Perfiles de usuario
• ¿Qué se utiliza con mayor frecuencia?
• ¿Qué es crítico para el negocio?

— Escenarios de negocio
• Las transacciones comerciales típicas (desde el inicio hasta el fin).

— Casos de uso
• Casos basados en situaciones reales.

P-17
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS
PRUEBAS NO FUNCIONALES

Diferentes tipos de pruebas del sistema NO funcionales :

– facilidad de uso,
– seguridad,
– documentación,
– volumen,
– configuración/instalación,
– fiabilidad,
– recuperación,
– rendimiento, carga, estrés,
– etc.

TIPOS DE PRUEBAS
PRUEBAS DE RENDIMIENTO

— Pruebas de tiempo
• Respuesta y horario de atención.

— Pruebas de capacidad y volumen

• Cantidad máxima o velocidad de
procesamiento
• Número de registros en el sistema
• Degradación correcta

— Pruebas de resistencia
• (¿24 horas operación?)
• Solidez del sistema.
• Asignación de memoria.

P-18
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS
PRUEBAS MULTIUSUARIO

— Pruebas de concurrencia
• Números pequeños, grandes beneficios
• Detectar los problemas de registro de bloqueo

— Pruebas de carga
• A medición del comportamiento del sistema en virtud realista de
carga multi-usuario

— Pruebas de estrés
• Ir más allá de los límites para el sistema - sé lo que pasará
• Especial relevancia para el comercio electrónico

TIPOS DE PRUEBAS
PRUEBAS DE FACILIDAD DE USO

— ¿Mensajes adaptados y significativos (reales) a los

usuarios?

— ¿ Interfaz coherente y consistente?

— ¿Suficiente redundancia de la información crítica?

— ¿Dentro del “control humano"? (7 ± 2 opciones)

— ¿Retroalimentación (mensajes de espera)?

— ¿Asignaciones claras (cómo salir o cancelar)?

¿Quién debe diseñar/ realizar estas pruebas?

P-19
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS
PRUEBAS DE SEGURIDAD

— Contraseña.

— Cifrado.

— Dispositivos de acceso a hardware.

— Niveles de acceso a la información.

— Autorización.

— Canales ocultos.

— Seguridad física.

TIPOS DE PRUEBAS
FIABILIDAD / CUALIDADES

— Fiabilidad
• " El sistema será confiable "- ¿cómo probar esto?
• " 2 fallos por año durante diez años "
• Tiempo promedio entre fallos (TPEF)
• Modelos de crecimiento de la fiabilidad

— Otras cualidades
• Capacidad de mantenimiento, portabilidad, capacidad de
adaptación, etc.

P-20
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS

DOCUMENTACIÓN DE PRUEBAS
— Revisión de la documentación
• Verificar su exactitud frente a otros documentos.
• Llegar a un consenso sobre el contenido.
• Existe documentación, usa el formato correcto.

— Pruebas de documentación
• ¿Es útil? ¿funciona?
• Manual de usuario.
• Mantenimiento a la documentación.

TIPOS DE PRUEBAS
PRUEBAS DE ACEPTACIÓN DE USUARIO

— Etapa final de validación

• El cliente o usuario deberán realizar o participar en las pruebas.
• El cliente puede realizar cualquier prueba si así lo desea, por lo
general basada en procesos de negocio.
• Usuario final cierre de sesión

— Enfoque
• Mezcla de las pruebas con utilización o NO de procedimientos de
pruebas.

P-21
www.jbenterprisegroup.com
 TIPOS DE PRUEBAS
PRUEBAS DE ACEPTACIÓN - ¿POR QUÉ EL CLIENTE/ USUARIO?

Los usuarios saben:

– Lo que realmente sucede en situaciones de negocios.

– La complejidad de las relaciones comerciales.
– Cómo prefieren hacer su trabajo usando el sistema.
– Las variantes para tareas estándar (por ejemplo, específica de cada
país).
– Ejemplos de casos reales.
– Cómo identificar soluciones sensatas.

Beneficio: conocimiento detallado del nuevo sistema

TIPOS DE PRUEBAS

PRUEBAS DE CONFIRMACIÓN Y REGRESIÓN

– Pruebas de confirmación (re-testing)

• Ejecutar de nuevo la prueba para confirmar que el defecto haya sido
reparado.
– Pruebas de regresión
• Las pruebas se realizan con la intención de comprobar que el sistema
no ha retrocedido (es decir, que no tienen más defectos como
consecuencia de algún cambio).

P-22
www.jbenterprisegroup.com
 PRUEBAS DE MANTENIMIENTO

Prueba para preservar la calidad :

– Secuencia diferente.
• Las pruebas de desarrollo se ejecutan de abajo hacia
arriba.
• Las pruebas de mantenimiento ese ejecutan de arriba
hacia abajo.
• Datos de prueba diferentes.
– Pruebas de amplitud para establecer la confianza en general.
– Pruebas para investigar a fondo los cambios y las áreas críticas.
– Predominan las pruebas de regresión.

PRUEBAS DE MANTENIMIENTO
¿QUÉ SE PRUEBA EN LAS PRUEBAS DE MANTENIMIENTO?
— Se prueba cualquier código nuevo o modificado.
— Análisis del impacto
• ¿Qué área de la aplicación se podría haber impactado por el cambio?
• ¿Cuán importante es un fallo en el área afectada?
• Probar lo que se ha visto afectado, pero ¿cuánto?
– ¿Las zonas afectadas más importantes?.
– ¿Áreas con la mayor probabilidad de ser afectadas?.
– ¿El sistema completo?

• La respuesta: "depende“

P-23
www.jbenterprisegroup.com
 PRUEBAS DE MANTENIMIENTO
ESPECIFICACIONES POBRES O INEXISTENTES
— Considere lo que el sistema debe hacer.
• Hable con los usuarios.

— Documente las supuestos.

• Asegúrese que otras personas tengan la oportunidad de revisarlo.

— Mejore la situación actual.

• Documente lo que sabe.
• Documente sus descubrimientos.

— Realice seguimiento al costo de trabajar con especificaciones pobres.

• Elabore casos de negocio para mejorar las especificaciones.

PRUEBAS DE MANTENIMIENTO
¿QUÉ DEBERÍA HACER EL SISTEMA?
— Alternativas.
• La forma en la que funciona el sistema en la actualidad debe ser la
correcta (a excepción del cambio especificado) - utilice el sistema
existente como base de referencia para pruebas de regresión.
• buscar en los manuales de usuario o guías (si es que existen).
• preguntar a los expertos - a los usuarios actuales.

— Sin una especificación, no podrá probar realmente, sólo explorar. Usted

puede validar, pero no verificar.

P-24
www.jbenterprisegroup.com
 Gracias por su
atención!
Preguntas?

P-25
www.jbenterprisegroup.com