<<Testing a travs del ciclo de

vida del software>>

Curso: Proceso de Pruebas de Software

NDICE DE CONTENIDOS
NDICE DE CONTENIDOS

01. Modelos de Desarrollo de Software

02. Niveles de las Pruebas

03. Tipos de Pruebas

04. Pruebas de Mantenimiento

Ing. Alejandro Bartra

01
MODELOS DE DESARROLLO DE SOFTWARE

01 MODELOS DE DESARROLLO DE SOFTWARE

INTRODUCCIN
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 segn 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 prueba del mismo.

En todos los ciclos de vida, una parte de las pruebas est enfocada a la
Verificacin y otra parte a la Validacin.

Ing. Alejandro Bartra

01 MODELOS DE DESARROLLO DE SOFTWARE

MODELO CASCADA

El modelo de cascada fue uno de los primeros modelos que se diseo. Tiene una lnea 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).

Ing. Alejandro Bartra

01 MODELOS DE DESARROLLO DE SOFTWARE

V-MODEL

El V-modelo se desarroll para abordar algunos de los problemas experimentados utilizando el

mtodo de cascada tradicional.

El

V-model es un modelo que ilustra cmo las actividades de las pruebas (verificacin y
validacin) pueden ser integradas en cada fase del ciclo de vida. Dentro del V-model, las
pruebas de validacin se llevan a cabo especialmente durante las primeras etapas, por ejemplo
revisar los requisitos del usuario, y al final del ciclo de vida, por ejemplo, durante las pruebas de
aceptacin del usuario.

Ing. Alejandro Bartra

01 MODELOS DE DESARROLLO DE SOFTWARE

V MODEL

Los cuatro niveles de prueba utilizados son los siguientes:

Pruebas de componentes: busca defectos y verifica el funcionamiento del componente de

software (por ejemplo, mdulos, programas, objetos, clases) que se comprueban por separado.
Pruebas de integracin: pruebas de interfaces entre los componentes, las interacciones a
diferentes partes de un sistema, por ejemplo: el sistema operativo, sistema de archivos y
hardware o interfaces entre los sistemas.
Pruebas del sistema: concernientes al comportamiento de todo el sistema / producto tal
como est definido por el alcance del proyecto. El objetivo principal de las pruebas del
sistema es la verificacin de los requerimientos especificados.
Pruebas de aceptacin: las pruebas de validacin con respecto a las necesidades del
usuario, requerimientos y procesos empresariales, para determinar si procede o no aceptar el
sistema.

Ing. Alejandro Bartra

V-Model: Niveles de pruebas

Requerimientos

Pruebas de
aceptacin

De negocio
Especificacin
Del proyecto
Especificacin
Del sistema
Especificacin
Del diseo

Codificacin

Pruebas de Integracin
Ms amplias

Pruebas de sistema

Pruebas de Integracin
pequeas

Pruebas de
Componentes

Ing. Alejandro Bartra

V-Model: Diseo de pruebas tardas

Tests

Requerimientos

Pruebas de
aceptacin

De negocio
Especificacin
Del proyecto

Tests Pruebas de Integracin

Nosotros no tenemos

Ms amplias

tiempo para disear

Especificacin
Del sistema

Tests

pruebas tempranas

Especificacin
Del diseo

TestsPruebas de Integracin
pequeas

Tests
Codificacin

Pruebas de sistema

Pruebas de
Componentes

Diseo
De
pruebas?

Ing. Alejandro Bartra

V-Model: Diseo de pruebas tempranas

Tests

Tests

Requerimientos
De negocio

Pruebas de
aceptacin

Tests

Tests

Especificacin
Del proyecto

Pruebas de Integracin
Ms amplias

Tests

Tests

Especificacin
Del sistema

Pruebas de sistema

Tests
Especificacin
Del diseo

Tests
Pruebas de Integracin
pequeas

Tests Tests
Diseo
De
pruebas

Codificacin

Pruebas de
Componentes

Ejecucin
De
pruebas

Ing. Alejandro Bartra

10

01 MODELOS DE DESARROLLO DE SOFTWARE

V-MODEL

CMMI
ISO / IEC 12207
Ing. Alejandro Bartra

11

01 MODELOS DE DESARROLLO DE SOFTWARE

W-MODEL
The W-Model and static test techniques

Ing. Alejandro Bartra

12

01 MODELOS DE DESARROLLO DE SOFTWARE

W-MODEL
The W-Model and dynamic test techniques

Ing. Alejandro Bartra

13

01 MODELOS DE DESARROLLO DE SOFTWARE

CICLOS DE VIDA ITERATIVO

En lugar de trabajar en una gran lnea de tiempo, se puede dividir un proyecto en pequeas ciclos
de vida, de manera que se puedan aplicar las revisiones y pruebas a cada iteracin de principio a
fin.

(*)Pruebas de integracin y
regresin
Ing. Alejandro Bartra

14

01 MODELOS DE DESARROLLO DE SOFTWARE

CICLOS DE VIDA ITERATIVO

Ejemplos de modelos de desarrollo iterativo o incremental son: Prototipos, Desarrollo

Rpido de Aplicaciones (RAD), Rational Unified Process (RUP) y Desarrollo gil (Scrum).

RAD: funciones/componentes son desarrolladas en paralelo como si se trataran de mini proyectos.

Ing. Alejandro Bartra

15

01 MODELOS DE DESARROLLO DE SOFTWARE

CICLOS DE VIDA ITERATIVO: Caractersticas

Desarrollo en paralelo de componentes y funciones.

Rpidos resultados iniciales (El cliente puede ver algo del proyecto desde un principio)
Rpida respuesta ante los cambios en los requerimientos de los clientes.
Retroalimentacin por parte de los clientes.

Ing. Alejandro Bartra

16

01 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 especfico para ese nivel.
El anlisis y diseo de las pruebas para un nivel de prueba debe comenzar durante
las actividades de desarrollo correspondientes.
El Tester deben participar en la revisin de los documentos tan pronto como estn
disponibles en el ciclo de desarrollo.

Ing. Alejandro Bartra

17

02
NIVELES DE PRUEBA

02 NIVELES DE PRUEBA

Descomposicin de las pruebas por niveles:

Pruebas de Bajo Nivel:
Pruebas de Componentes o Unitarias
Pruebas a nivel de cdigo de componentes individuales. Varios Niveles. Pruebas tcnicas.
Tpicamente realizadas por los mismos desarrolladores

Pruebas de Integracin
Pruebas de integracin de varios componentes. Varios niveles en funcin del nmero y
completitud de los componentes a integrar. Pruebas tcnicas.

Pruebas de Alto Nivel

Pruebas de Sistema
Pruebas extremo a extremo que incluye a todos los componentes del sistema. Pruebas
Funcionales + Pruebas Tcnicas.

Pruebas de Aceptacin
Pruebas a realizar en las que participa normalmente el usuario, para dar por bueno un
desarrollo. Pruebas funcionales.

Ing. Alejandro Bartra

19

02 NIVELES DE PRUEBA

Pruebas Unitarias (o de componentes ):

Las pruebas unitarias, tambin conocidas como de mdulo o de programa.

Verifica

el funcionamiento y busca defectos de los componentes de software que

pueden ser analizados individualmente. (Ej.: mdulos, programas, objetos y clases).

Como se analizan individualmente, se utilizan stubs y drivers para reemplazar el

software faltante y simular las interfaces entre los componentes del software. El
driver reemplaza a un componente que llama al componente a ser probado;
mientras que el stubs reemplaza a un componente que es llamado por el
componente bajo prueba.

Ing. Alejandro Bartra

20

02 NIVELES DE PRUEBA

Pruebas Unitarias:
Generalmente ejecutados por desarrolladores.
Se utilizan herramientas del entorno de desarrollo, depuradores, etc. que permiten el
acceso al cdigo.
Usualmente los errores se arreglan al momento (sin necesidad de documentarlos).
El conocimiento del cdigo permite la aplicacin de mtodos de caja blanca.
Puede incluir pruebas de funcionalidad y no funcionales (por ejemplo, prdidas de
memoria), el rendimiento robustez, as como las pruebas estructurales (por ejemplo, la
decisin, cobertura).

Ing. Alejandro Bartra

21

02 NIVELES DE PRUEBA

Prueba de integracin :
Prueba interfaces entre distintos componentes o interacciones ente distintas
partes de un sistema.
Se puede dividir en:
Pruebas de integracin de componentes
Prueba las interacciones entre los componentes de un sistema. Se realiza despus
de las pruebas Unitarias (o de componentes)

Pruebas de integracin de sistemas

Prueba las interacciones entre los sistemas. Generalmente se realiza despus de
las pruebas de sistema.

Ing. Alejandro Bartra

22

02 NIVELES DE PRUEBA

Prueba de integracin - Enfoques :

Pruebas de integracin Big-Bang

Se realiza cuando todos los componentes o sistemas estn completamente integrados

Se prueba el integrado como un todo.
Ventaja: No se tienen que simular partes.
Desventaja: Ocupa tiempo y dificulta rastrear fallas.

Pruebas de integracin paso por paso

Los componentes se integran uno por uno y en cada integracin se realizan las pruebas.
Testeo incremental.
Ventaja: Fcil de rastrear las fallas
Desventaja: Se deben simular partes, por lo que demanda ms tiempo.

Ing. Alejandro Bartra

23

02 NIVELES DE PRUEBA

Prueba de integracin - Opciones de Prueba:

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.
Funcionalidades: Las pruebas se llevan a cabo en base a las funcionalidades, segn lo
documentado en la especificacin funcional.

Ing. Alejandro Bartra

24

02 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, segn 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 tambin
requerimientos no funcionales (desempeo).
Se realiza en un entorno de pruebas, para tener mayor control sobre el proceso.
Tipo: Verificacin.

Ing. Alejandro Bartra

25

02 NIVELES DE PRUEBA

Prueba de aceptacin :

Se presenta el software al cliente para su aceptacin.

Es el cliente el que debe decidir si el producto ya 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: Validacin

las pruebas de componentes

Las pruebas de aceptacin para una nueva mejora de funcionalidad se deben realizar
antes de las pruebas de sistema.

Tambin se puede dividir en niveles. Ejemplos:

Las pruebas de aceptacin de usabilidad de componentes se deben realizar durante

Ing. Alejandro Bartra

26

02 NIVELES DE PRUEBA

Prueba de aceptacin :
Pruebas de aceptacin del usuario

Funcionalidad

Pruebas de aceptacin operacional

Pruebas de backup, restore, recuperacin de informacin, seguridad, tareas de
mantenimiento, etc.

Pruebas de contrato de aceptacin

Se prueba el sistema contra un criterio de aceptacin previamente definido en un
contrato.

Ing. Alejandro Bartra

27

02 NIVELES DE PRUEBA

Prueba de aceptacin :
Pruebas de regulacin de aceptacin

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

Pruebas Alfa
Pruebas internas.

Se realiza en el entorno del desarrollador.

Pruebas Beta
Tambin 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.

Ing. Alejandro Bartra

28

03
TIPOS DE PRUEBA

03 TIPOS DE PRUEBA

TIPOS DE PRUEBA:
Los tipos de prueba son un medio para clarificar el objetivo de ciertos niveles de prueba
en un programa o proyecto.
Enfocar las Pruebas en un especfico objetivo de prueba y seleccionar el apropiado tipo
de prueba hace ms fcil comunicar y tomar decisiones.
Un tipo de prueba est enfocado en un particular objetivo de prueba, el cual podra ser la
prueba de una funcin a ser realizada por un componente o sistema; una caracterstica
no funcional, tal como la confiabilidad o la usabilidad; la estructura o arquitectura de un
componente o sistema; o pruebas relativas a los cambios, como pruebas de confirmacin
o de regresin.
Dependiendo de los objetivos las pruebas son organizadas de maneras diferentes.
Los tipos son:
Prueba Funcional
Prueba No Funcional
Prueba Estructural
Prueba relacionadas a los cambios

Ing. Alejandro Bartra

30

03 TIPOS DE PRUEBA

Es un medio para definir claramente los objetivos de un cierto

nivel de prueba para un programa o proyecto.

Un tipo de prueba se concentra en un determinado Objetivo de Prueba.

Ing. Alejandro Bartra

31

03 TIPOS DE PRUEBA

Prueba Funcional
La prueba funcional considera el comportamiento especificado y se denomina tambin:
Prueba de Caja Negra.
El funcionamiento de un sistema o componente, est especificado en:
Especificacin de Requerimientos
Especificacin Funcional
Especificacin de Componentes
Casos de Uso
Historias de Usuario, etc.
Pueden existir funciones no documentadas que sern tambin parte de los
requerimientos de un sistema.
Puedes ser realizada desde dos perspectivas:
Basada en los requerimientos
Basada en los procesos de negocio

Ing. Alejandro Bartra

32

03 TIPOS DE PRUEBA

Prueba No Funcional
Un segundo objetivo de las pruebas es la prueba de las caractersticas de calidad o
atributos no funcionales del sistema.
Probamos algo que necesitamos medir en alguna escala de medida.
La prueba no funcional, as como la prueba funcional es realizada en todos los niveles de
prueba.
Incluye las pruebas de:
Performance
Stress
Usabilidad
Mantenibilidad
Confiabilidad
Portabilidad

Ing. Alejandro Bartra

33

03 TIPOS DE PRUEBA

Prueba Estructural
Un tercer objetivo es la estructura del sistema o componente. Es frecuentemente llamado
Prueba de caja blanca, debido a que el inters est en lo que ocurre dentro de la caja.
Es frecuentemente usado como un modo para medir la rigurosidad de las pruebas a
travs de la cobertura de un conjunto de elementos estructurales.
Es comnmente aplicado a nivel de prueba de componentes y pruebas de integracin.

Ing. Alejandro Bartra

34

03 TIPOS DE PRUEBA

Pruebas relativas a los cambios

El ltimo objetivo de las pruebas es la prueba de los cambios.
Prueba de Confirmacin: Ejecutar de nuevo la prueba para confirmar que el defecto
haya sido reparado.
Pruebas de regresin: Las pruebas se realizan con la intencin de comprobar que el
sistema no ha retrocedido (es decir, que no tienen ahora ms defectos en ella como
consecuencia de algn cambio)

Ing. Alejandro Bartra

35

04
PRUEBAS DE MANTENIMIENTO

04 PRUEBAS DE MANTENIMIENTO

Una vez desplegado, el sistema est a menudo propenso a corregirse, modificarse o

ampliarse. La prueba que se ejecuta durante esta fase del ciclo de vida se llama "prueba
de mantenimiento.

Un proceso de prueba de mantenimiento por lo general comienza con la recepcin de

una solicitud de cambio o un plan de lanzamiento

Ing. Alejandro Bartra

37

04 PRUEBAS DE MANTENIMIENTO

Por lo general, las pruebas de mantenimiento constarn de

dos partes:

Pruebas de los cambios.

Pruebas de regresin

Actividad principal dentro de las pruebas de mantenimiento:

Anlisis de impacto.

Ing. Alejandro Bartra

38

04 PRUEBAS DE MANTENIMIENTO

Desencadenantes
1.
2.
3.
4.
5.
6.

Las modificaciones correctivas y de Emergencias.

La migracin de Plataformas.
Cambios de mejora.
Cambios del entorno.
Actualizaciones de base de datos.
Parches para vulnerabilidades descubiertas recientemente.

Ing. Alejandro Bartra

39

04 PRUEBAS DE MANTENIMIENTO

Modificaciones correctivas ad-hoc

Tiene que ver con defectos que requieren una solucin inmediata, por ejemplo:

Una cada en produccin a altas horas de la noche.

La red pierde seal con cientos de usuarios en lnea.
Un correo con direcciones incorrectas.
Hay diferentes reglas y procedimientos resolver los problemas de este tipo.
Ser imposible que se adopten las medidas Estructuradas necesarias para realizar las
pruebas respectivas; sin embargo las medidas tomadas nos servirn para especificar un
set de pruebas que estarn acorde con el tipo de problema y correccin.

Ing. Alejandro Bartra

40