Capitulo 2

CAPÍTULO 2.
PRUEBAS DURANTE EL
CICLO DE VIDA DEL
SOFTWARE
Capítulo 2. Pruebas durante el Ciclo de Vida del Software
2.1 Modelos de desarrollo de software
2.1.1 (K2) Desarrrollo de software y pruebas de software.
2.1.2 (K1) Modelos de ciclo de vida de desarrollos de software
en contexto.
2.2 Niveles de prueba
2.2.1 (K2) Pruebas de componente.
2.2.2 (K2) Pruebas de integración.
2.2.3 (K2) Pruebas de sistema.
2.2.4 (K2) Pruebas de aceptación.
2.3 Tipos de Pruebas
2.3.1 (K2) Pruebas funcionales, no funcionales y caja blanca.
2.3.2 (K1) Tipos y niveles de pruebas.
2.3.3 (K2) Pruebas de confirmación y regresión.
2.4 Proceso de mantenimiento
2.4.1 (K2) Activadoes de mantenimiento.
2.4.2 (K2) Análisis de impacto.
Capítulo 2. Pruebas durante todo el
ciclo de vida del software
Modelos de desarrollo secuenciales
Un modelo de desarrollo secuencial describe el proceso de desarrollo de
software como un flujo lineal y secuencial de actividades. Esto significa que
cualquier fase en el proceso de desarrollo debe comenzar cuando se complete
la fase anterior. En teoría, no hay superposición de fases, pero en la práctica, es
beneficioso tener retroalimentación temprana de la siguiente fase.
Estos modelos entregan software que contiene el conjunto completo de

características, pero generalmente requieren mucho tiempo para su entrega a
los interesados y usuarios.
Los modelos secuenciales estan representados por un diagrama en cascada o en

V.
Modelo de Ciclo de Vida en Cascada “Waterfall”
Las actividades de desarrollo
se completan una tras otra.
El tiempo se establece desde el inicio del proyecto, por lo que es
posible que alguna de las partes del alcance y la funcionalidad
Requisitos original no se entregue o se entregue sin tiempo suficiente para
probar, por lo que la calidad del producto se ve afectada.
Diseño Para resolver este problema, se creó el

Modelo "V", donde las actividades de
prueba se alinearon con los niveles de
desarrollo.
Supone que todos los
Implementación
requisitos se pueden recopilar
por adelantado durante la fase
de requisitos.
Verificación
Las actividades de prueba solo ocurren

después de que se completan las
actividades de desarrollo. Mantenimiento
Modelo de Ciclo de Vida en “V” “V Model”
Las etapas se desarrollan en secuencia y no se inicia una nueva
actividad hasta que la anterior este completa.
Requisitos de Diseño de Pruebas de
pruebas de
Negocio Aceptación
El lado izquierdo aceptación El lado derecho
describe las describe las
actividades de actividades de
desarrollo Especificación Diseño de Pruebas de pruebas
pruebas de
Funcional Sistema
sistema
Diseño de
pruebas de
Pruebas de
Diseño Técnico
integración Integración
Los requisitos de negocio se
usan para generar las De forma temprana se generan
pruebas de aceptación, las pruebas necesarias para
Especificación Diseño de
mientras que el siguiente Pruebas verificar que los distintos niveles
de pruebas
nivel, se usa para derivar las Unitarias
Componentes unitarias de desarrollo se han
pruebas del sistema implementado según lo definido
en los requisitos
Incluye ciclos de retroalimentación Creación de Código

para que los requisitos y el código
mejoren antes de su entrega.
Verificación Validación Desarrollo
Modelo de desarrollo “Iterativo Incremental”
Este modelo establece requisitos, diseña, construye y prueba un sistema
en partes, lo que significa que las características del software aumentan
gradualmente. El tamaño de estos incrementos de características varía
dependiendo del modelo.
Iteración 1
Análisis Diseño Construcción Pruebas Incremento +1
Iteración 2
Iteración 3
Estrategia de programación en la que varias partes del sistema se desarrollan en diferentes

momentos y se integran a medida que se completan.
En el desarrollo iterativo se agrupan características que se especifican, diseñan,
construyen y prueban en una serie de ciclos/iteraciones que generalmente
tienen una duración fija.
Durante las iteraciones pueden haber cambios en las características

desarrolladas en iteraciones pasadas y/o cambios en el alcance del proyecto.
Cada iteración entrega un software funcional que es un subconjunto cada vez

mayor del conjunto general de características hasta que se entrega el software
final o se detiene el desarrollo.
Construcción Construcción Construcción

Pruebas Pruebas Pruebas
Diseño Diseño Diseño
Requisitos Requisitos Requisitos
Entregas iterativas/incrementales
Algunos • RUP
modelos • SCRUM
interativos • Kanban
incrementales
• Spiral
Rational Unified Process (RUP)
Proceso de desarrollo orientado a objetos, que provee una guía, plantillas y
ejemplos para todas las etapas del desarrollo de sistemas utilizando la notación
UML para el modelado de requisitos. En RUP los casos de uso son usualmente
utilizados como la base de pruebas.
La duración de las iteraciones

generalmente es larga [de dos a
tres meses] por lo tanto los
incrementos de características
también son grandes.
SCRUM
Es un marco de trabajo para la gestión y desarrollo de software, basado en
iteraciones incrementales, centrada en la creación y entrega de software con
el valor más alto para negocio en el menor tiempo. La base de pruebas que
sirve como entrada para el proceso de pruebas son las historias de usuario.
Kanban
En japonés, la palabra "Kan" significa "visual" y "ban" significa "tarjeta",
KANBAN BOARD por lo que Kanban se refiere a las tarjetas visuales. En el tablero se
administra el trabajo en progeso.
PULL
Las tareas no están programadas, esperan en
el backlog y se mueven al tablero Kanban en
cuanto hay espacio disponible, cuando el
equipo tiene la capacidad de trabajar en ella.
Kanban es entregar lo que el proceso necesita

exactamente cuando se necesita.
• Es fácil de aprender, mejora el flujo de trabajo y
WIP (Work in progress) minimiza tiempos de entrega.
Limita el trabajo en progreso de • Enfocado en la entrega continua.
• Reduce el “desperdicio” del proceso [tiempos de
acuerdo al rendimiento del equipo
espera].
para visualizar el flujo de trabajo. • Mayor productividad y eficiencia.
Este modelo se centra en la gestión de riesgos. Esta basado en prototipos, usa ciclos
Spiral iterativos para desarrollar software y cada ciclo consiste en 4 pasos:
Planeacion Analisis de
Se determinan
riesgos
objetivos, alternativas y Evaluación de alternativas,
restricciones. se identifican y resuelven
12 riesgos.
43
• Prototipo 1
• Prototipo 2
evaluacion • Prototipo 3 ingenieria

• Prototipo
Operativo Desarrollo y verificación
El cliente evalúa los del siguiente nivel de
resultados y sugiere producto.
modificaciones.
Consideraciones importantes…
Los componentes o sistemas desarrollados utilizando estos métodos, generalmente
implican la superposición de los niveles de prueba durante el desarrollo. Idealmente,
cada función se prueba en varios niveles de prueba a medida que avanza hacia la
entrega.
En algunos casos, los equipos utilizan la entrega continua o la integración continúa, lo

que implica para los testers una automatización importante de múltiples niveles de
prueba como parte de sus entregas.
Estos métodos también incluyen el concepto de equipos de "auto-organizados", que

pueden cambiar la forma en que se organiza el trabajo de prueba, así como la relación
entre los testers y los desarrolladores.
Las pruebas de regresión son cada vez más importantes a medida que el sistema crece.
A diferencia de los modelos secuenciales, los modelos iterativos e incrementales pueden

entregar software utilizable en semanas o incluso días, pero el conjunto completo de
requisitos del producto puede durar meses o incluso años.
Modelos de ciclo de vida de desarrollo de sw en contexto
Los modelos del ciclo de vida de desarrollo de software deben seleccionarse y adaptarse al
contexto del proyecto y del producto de acuerdo a lo siguiente:
• Objetivo del proyecto

• Tipo de producto
• Prioridades del negocio, como tiempo de entrega.
• Riesgos de producto y de proyecto identificados
Por ejemplo, el desarrollo de un sistema de gestión interna debe diferir del desarrollo de
un sistema de seguridad critica.
En algunos casos los problemas de la organización y la cultura pueden disminuir la

comunicación entre los miembros del equipo, lo que puede impedir el desarrollo iterativo.
Dependiendo del contexto del proyecto, puede ser necesario combinar o reorganizar los
niveles de prueba y/o las actividades de prueba.
También es posible combinar los propios modelos del ciclo de vida de desarrollo de
software.
2.1.2 (K1) Modelos de ciclo de vida de desarrollos de software en
contexto.
2.4.1 (K2) Activadoes de mantenimiento.
Capítulo 2. Pruebas durante todo el ciclo de vida del software
2.2 Niveles de Pruebas
Los niveles de prueba son grupos de actividades de prueba que se

organizan y gestionan en conjunto.
1 3
Pruebas
Unitarias
2 Pruebas de 4
[Desarrollador] Pruebas de Sistema Pruebas de
Integración [Tester] Aceptación
[Desarrollador & [Usuario
Tester] final/cliente]
La separación de las pruebas por niveles permite que se analicen con

mayor detalle los riesgos que una aplicación puede tener, logrando un
proceso de pruebas más eficaz.
Se debe realizar siempre un análisis para determinar el nivel que debe

aplicarse en cada proyecto, considerando que estos niveles se
complementan.
Atributos de los niveles de pruebas:
• Objetivos específicos.
• Bases de prueba, referencias para generar casos de prueba.
• Objeto de prueba (es decir, lo que se está probando).
• Defectos y fallos que pueden encontrar.
• Enfoques y responsabilidades.
Se requiere un ambiente de prueba adecuado para cada nivel.

Por ejemplo, en las pruebas de aceptación, el ambiente de
prueba debe de ser similar al de producción, mientras que en
la pruebas de componente los desarrolladores utilizan su
propio ambiente de desarrollo.
Pruebas de Componente [Unit level]

También conocidas como pruebas unitarias o de modulo, están
centradas en componentes individuales que se pueden probar Aceptación
por separado, para comprobar la funcionalidad y detectar
defectos. Sistema
Objetivos
• Reducir el riesgo. Integración
• Verificar que los comportamientos funcionales y no

funcionales del componente son los diseñados y Componente
especificados.
• Generar confianza en la calidad del componente.
• Encontrar defectos en el componente. Niveles de
• Prevenir la propagación de defectos a los siguientes Pruebas
niveles.
Bases de pruebas
• Especificación de componentes
• Código
• Diseño detallado
• Modelo de datos
01010101
010100 Objetos de prueba
• Componentes, unidades o módulos
• Código y estructura de datos
• Clases
• Módulos de bases de datos
Defectos y fallos
• Funcionamiento incorrecto, por ejemplo con respecto a la
especificación de diseño.
• Problemas de flujo de datos.
• Código y lógica incorrectos.
Enfoques de prueba y reponsabilidades
• Realizadas por el desarrollador
• Test Driven Development
• Pruebas funcionales, no funcionales, estructurales.
Ambiente de pruebas
• Ambiente de desarrollo.
• En este nivel no todos los componentes o funcionalidad se
encuentran desarrollados, así que para poder probar, es necesario el
uso de arneses [driver y stubs].
Pruebas de integración [Integration level]

En este nivel las unidades o módulos se combinan y se prueban en
conjunto, centradas en las interacciones entre componentes o
Aceptación
sistemas.
El propósito de este nivel es detectar fallas en las interfaces y la Sistema

interacción entre unidades, componentes o sisetmas integrados.
Se pueden utilizar arneses [drivers o stubs] en este nivel.
Integración
Objetivos
• Reducir el riesgo. Componente
• Verificar que los atributos funcionales y no funcionales de las
interfaces sean los diseñados y especificados.
• Generar confianza sobre la calidad de las interfaces. Niveles de
• Encontrar defectos en las interfaces, componentes o sistemas.
Pruebas
• Prevenir la propagación de defectos a niveles de prueba
superiores.
Para este plan de estudios se consideran 2 niveles de pruebas de
integración:
1. Integración de componentes: prueban las interacciones e interfaces entre los
componentes integrados. Se realizan después de las pruebas de componentes y
generalmente están automatizadas. En el desarrollo iterativo e incremental, las pruebas
de integración de componentes suelen formar parte del proceso de integración
continua.
Módulo/ Módulo/
Sistema A Sistema B
Pruebas de Integración
2. Integración de sistemas: prueban las interacciones e interfaces entre sistemas,

paquetes y microservicios. También pueden cubrir las interacciones con interfaces de
organizaciones externas. Se pueden realizar después de las pruebas de sistema o en
paralelo con las actividades de pruebas de sistema en curso [tanto en el desarrollo
secuencial como en el desarrollo iterativo e incremental].
Base de Pruebas
• Diseño de software.
• Diagramas de secuencia.
• Especificaciones de interfaz y protocolos de comunicación.
• Casos de uso y flujos de trabajo.
• Arquitectura a nivel de componente o de sistema.
• Definiciones de interfaces externas.
Objetos de Prueba típicos

• Subsistemas.
• Bases de datos.
• Infraestructura.
• Interfaces.
• API's
• Microservicios.
Defectos y fallos
Integración de componentes:
• Componentes que transmiten datos incorrectos o el dato no se
transmite.
• Codificación incorrecta de datos.
• Mala o nula comunicación entre componentes.
• Secuenciación o sincronización incorrecta de las llamadas a la
interfaz.
• Incompatibilidad de la interfaz.
Integración de sistemas:
• Estructuras de mensajes inconsistentes entre sistemas.
• Datos incorrectos, datos faltantes o codificación incorrecta de datos.
• Incompatibilidad de la interfaz.
• Fallos en la comunicación entre sistemas.
• Incumplimiento de las normas de seguridad obligatorias.

• Las pruebas de integración de componentes generalmente son
responsabilidad de los desarrolladores.
• Las pruebas de integración de sistemas generalmente son

responsabilidad de los testers.
• Deben centrarse en la comunicación entre los módulos/sistemas,

no en la funcionalidad de los módulos/sistemas individuales.
• Pruebas funcionales, no funcionales y estructurales.
• Dependiedo de la arquitectura podrían tener diferentes enfoques

como:
- Ascendente [Top-down]
- Descendente [Bottom-up]
- Big bang
Ambiente de Pruebas
• Ambiente de desarrollo y pruebas.
• En este nivel puede ser necesario la utilización de arnéses de prueba
[drivers o stubs] para comprobar la integración.
• Usan monitores, para observar el tráfico de datos entre
componentes.
Pruebas de sistema (System level)

Estas pruebas están centradas en el comportamiento y las
capacidades de todo un sistema o producto, generalmente
Aceptación
consideras las tareas de punto a punto que el sistema puede
realizar y los comportamientos no funcionales que exhibe
mientras realiza esas tareas. Sistema
Objetivos Integración
• Verificar que los comportamientos funcionales y no funcionales
del sistema son los diseñados y especificados.
• Validar que el sistema está completo y que funcionará como se Componente
espera.
• Generar confianza en la calidad del sistema considerado como
un todo. Niveles de
• Encontrar defectos.
• Prevenir la propagación de defectos a niveles de prueba
Pruebas
superiores o a producción.
Bases de pruebas
• Especificaciones de requisitos del sistema y del software,
[funcionales y no funcionales].
• Informes de análisis de riesgo.
• Casos de uso.
• Épicas e historias de usuario.
• Modelos de comportamiento del sistema.
• Diagramas de estado.
• Manuales de sistema y de usuario.
Objetos de prueba
• Aplicaciones.
• Sistemas hardware/software.
• Sistemas operativos.
• Sistema sujeto a prueba (System Under Test).
• Configuración del sistema y datos de configuración.
Defectos y fallos
• Cálculos incorrectos.
• Comportamiento funcional o no funcional del sistema incorrecto o
inesperado.
• Control y/o flujos de datos incorrectos dentro del sistema.
• Incapacidad para llevar a cabo, de forma adecuada y completa, las
tareas funcionales punto a punto.
• Fallo del sistema para operar correctamente en el/los entorno/s de
producción.
• Fallo del sistema para funcionar como se describe en los manuales
del sistema y de usuario.

• El tester es el responsable de las pruebas de este nivel.
• Pruebas funcionales: como adecuación, exactitud, Interoperabilidad,
seguridad, cumplimiento de funcionalidad (“compliance”).
• Pruebas no funcionales: típicamente aplican las de performance,
carga, estrés.
• Técnicas de caja negra y caja blanca.
• El alcance de este nivel de prueba deberá estar documentado en el
plan maestro de pruebas.
Ambiente de pruebas
El ambiente en condiciones ideales debe de corresponder al ambiente
objetivo final o de producción.
Pruebas de aceptación [Acceptance level]

Este nivel está las pruebas se centran en el comportamiento y las
capacidades de todo un sistema o producto. Aceptación
Objetivos Sistema
• Establecer confianza en el sistema, evaluar el correcto

funcionamiento para su despliegue o uso. Integración
• Validar que el sistema está completo y que funcionará
como se espera.
Componente
• Verificar que los comportamientos funcionales y no
funcionales del sistema sean como los especificados.
Niveles de
Pruebas
Las pruebas de aceptación pueden producir información para

evaluar el grado de preparación del sistema para su despliegue y
uso por parte del cliente [usuario final].
Se pueden encontrar defectos durante las pruebas de aceptación, aunque no

suele ser un objetivo, y encontrar un gran número de defectos durante este
nivel puede considerarse un riesgo importante para el proyecto.
Estas pruebas también pueden satisfacer o normas legales o requisitos

regulatorios.
1 Pruebas de aceptación de usuario
Formas comunes 2 Pruebas de aceptación operativa
de pruebas de 3 Pruebas de aceptación contractual y regulación
aceptacion: 4 Pruebas alfa y beta

1. Pruebas de aceptación de usuario

El cliente o usuario valida la idoneidad y el adecuado funcionamiento del sistema para su
uso en producción. El objetivo principal es crear confianza en que los usuarios pueden
utilizar el sistema para satisfacer sus necesidades, cumplir con los requisitos y realizar los
procesos de negocio con la mínima dificultad, costo y riesgo.
2. Pruebas de aceptación operativa

Las realiza el administrador del sistema, generalmente incluye pruebas como:
• Instalación, desinstalación y actualización.

• Copia de seguridad, respaldo y restauración.
• Gestión de usuarios.
• Tareas de mantenimiento.
• Recuperación de desastres.
• Carga de datos y tareas de migración.
• Comprobación de vulnerabilidades de seguridad.
• Pruebas de rendimiento.
3. Pruebas de aceptación contractual y normativa
• Las pruebas de aceptación contractual se realizan en función de los criterios de
aceptación del contrato del desarrollo de software a la medida.
• Las pruebas de aceptación normativa se llevan a cabo para validar cualquier norma
que deba cumplirse, gubernamentales, legales o de seguridad física. El principal
objetivo es crear confianza en que se ha logrado la conformidad contractual o
normativa.
4. Pruebas alfa y beta

Generalmente se utilizan para la aceptación de productos COTS*, con el objetivo de
obtener retroalimentación de clientes potenciales o existentes antes de que el producto
sea liberado.
• Alfa: La característica de estas pruebas es que se realizan con un determinado número

de usuarios de la organización en un ambiente de prueba controlado por desarrollo.
• Beta: En esta prueba el software es liberado a los clientes potenciales para que sea
probado en su propio ambiente, es una prueba de bajo costo que retroalimenta
eficientemente a la organización, pues el software será usado en diferentes ambientes.
Bases de pruebas
• Procesos de negocio.
• Requisitos de usuario y negocio.
• Normativas, contratos legales y estándares.
• Casos de uso, historías de usuario.
• Requisitos del sistema.
• Documentación del sistema o del usuario.
• Procedimientos de instalación.
• Informes de análisis de riesgo.
Objetos de prueba
• Sistema sujeto a prueba [SUT].
• Configuración del sistema y datos de configuración.
• Procesos de negocio para un sistema totalmente integrado.
• Sistemas de recuperación y sitios críticos
• Procesos operativos y de mantenimiento.
• Formularios.
• Informes.
• Datos de producción existentes y transformados.
Defectos y fallos
• Flujos de trabajo del sistema que no cumplen con requisitos de
negocio o de usuario.
• Las reglas de negocio no se implementan de forma correcta.
• El sistema no satisface los requisitos contractuales o reglamentarios.
• Fallos como vulnerabilidades de seguridad, rendimiento o
funcionamiento inadecuado en una plataforma soportada.

• Responsabilidad de los clientes, usuarios de negocio, propietarios de
producto u operadores de un sistema, o cualquier implicado [stakeholder].
• En los desarrollos secuenciales se consiferan el último nivel de prueba.
• Para un producto de software comercial de distribución masiva [COTS]
pueden ocurrir cuando se instala o integra.
• En el desarrollo iterativo, se pueden emplear durante y al final de cada
iteración, como las que se centran en verificar una nueva característica en
relación con sus criterios de aceptación y las que se centran en validar que
una nueva característica satisface las necesidades de los usuarios.
Ambiente de pruebas
• Las pruebas deben realizarse en un entorno de pruebas lo más parecido al
entorno productivo.
• En este nivel el sistema debe de estar instalado completamente, ya no deben
utilizarse controladores (drivers) y cabos (Stubs)para realizar las pruebas, a
menos que estos cumplan una funcion de algo que no existe en nuestro
ambiente como podría ser una conexión con una entidad externa.
2.1.2 (K1) Modelos de ciclo de vida de desarrollos de software
en contexto.
2.4.1 (K2) Activadores de mantenimiento.
Un tipo de prueba es un grupo de actividades destinadas a probar

características específicas de un sistema de software, o de una parte de un
sistema, basadas en objetivos de prueba específicos.
Los objetivos pueden incluir:
• Evaluar características de calidad funcional, como la completitud,

corrección y adecuación.
• Evaluar características de calidad no funcionales, como fiabilidad, eficiencia
de desempeño, seguridad, compatibilidad y usabilidad.
• Evaluar si la estructura o arquitectura del componente o sistema es correcta
y completa según lo especificado.
• Evaluar los efectos de los cambios, confirmar que los defectos han sido
corregidos (pruebas de confirmación) y buscar cambios no deseados en el
comportamiento que resulten de cambios en el software o en el entorno
(pruebas de regresión).
Pruebas Pruebas No
Funcionales Funcionales
Pruebas
Pruebas de
Asociadas al
Caja Blanca
Cambio
Pruebas Funcionales
Se centran en probar la funcionalidad del sistema y prestaciones descritas en
requisitos funcionales y en productos de trabajo como: especificaciones de
requisitos de negocio, épicas, historias de usuario, casos de uso,
especificaciones funcionales, o requisitos sin documentar. Las funciones
describen:
¿QUÉ DEBE HACER EL SISTEMA?

• Aplican para todos los niveles de prueba, aunque el enfoque es diferente.
• Consideran el comportamiento del software, por lo que se pueden utilizar
técnicas de caja negra para obtener condiciones y casos de prueba.
• Se pueden medir a través de la cobertura funcional. Esta cobertura es la
medida en que se ha ejercido algún tipo de elemento funcional mediante
pruebas y se expresa como un porcentaje.
• El diseño y la ejecución de pruebas funcionales implican habilidades o
conocimientos del negocio del problema que resuelve el software.
Pruebas No Funcionales
Evalúan las características de los sistemas y el software, como la usabilidad, la
eficiencia del desempeño o seguridad. Estas pruebas verifican:
¿QUÉ TAN BIEN LO HACE?

• Aplican en todos los niveles de pruebas, se deben realizar lo antes posible.
• Se pueden utilizar técnicas de caja negra para obtener condiciones y casos
de prueba, por ejemplo el "análisis de valores límite" para definir las
condiciones de estrés para pruebas de rendimiento.
• Estas pruebas se pueden medir a través de la cobertura no funcional, medida
expresada en porcentaje.
• El diseño puede involucrar habilidades o conocimientos especiales como las
debilidades del diseño o tecnología así como vulnerabilidades de seguridad.
Pruebas de Caja Blanca

Son pruebas basadas en la estructura interna o la implementación del sistema.
La estructura interna puede incluir código, arquitectura, flujos de trabajo y/o
flujos de datos dentro del sistema.
Se puede medir la intensidad de las pruebas de caja blanca a través de la

cobertura estructural, que es la medida en que un juego de pruebas ha
probado la estructura del código y se expresa en porcentaje.
Pueden realizarse en todos los niveles de prueba, aunque son utilizadas

generalmente en los niveles de componente e integración.
El diseño y la ejecución de las pruebas de caja blanca pueden implicar

habilidades o conocimientos de cómo está construído el código, cómo se
almacenan los datos y cómo utilizar las herramientas de cobertura e interpretar
correctamente sus resultados.
Pruebas Asociadas al Cambio

El objetivo es probar cuando el software ha sufrido algún cambio, estos
cambios pueden ser después de detectar y corregir un defecto o
asociados a nueva funcionalidad.
Nueva Integrar Nuevos

funcionalidad casos de prueba
Pruebas de Liberación del
Regresión Software
Corrección de Pruebas de
un defecto confirmación REGRESSION
TEST
ConFIRMATION
TEST
Pruebas de Confirmación [Confirmation Test]
Una vez que corregido un defecto debe de ser probado, la prueba que
se realiza para confirmar la corrección exitosa se denomina prueba de
confirmación.
Esta prueba debe ser repetida de la misma forma que la primera vez
utilizando los mismos casos de prueba, datos de entrada y en el
mismo ambiente.
Se pueden realizar en cualquier nivel de pruebas.

Pruebas de Regresión [Regression Testing]

Estas pruebas se realizan para comprobar que los cambios que se han
realizado en un programa debido a correcciones o modificaciones, no
han introducido nuevos defectos.
• Deben ser realizadas al final de todos los niveles de prueba, en las

pruebas funcionales, no funcionales y pruebas estructurales.
• Dada su constante ejecución estos casos de prueba deben estar

claramente identificados y documentos, para su reutilización, esta es
también una razón por la cual son perfectos candidatos para la
automatización.
Hay que determinar qué tan extensiva debe ser la regresión, las
posibilidades pueden ser las siguientes:
• Volver a ejecutar parte del sistema en donde se han detectado fallas y que
se han corregido en la nueva versión de software.
• Probar las partes del programa que fueron modificadas.
• Probar las partes del sistema que fueron recientemente integradas.
• Probar aquellas partes del programa que tienen mayor riesgo para la
aplicación.
• ¡Probar el sistema completo!, (en los casos en los que el entorno de
prueba cambia completamente, ya que existirán efectos colaterales).
La decisión de una regresión a todo el sistema puede ser costoso para el

proyecto y consume tiempo, así que se debe hacer un balance entre riesgo y
costo, el análisis de impacto de los cambios ayudará a tomar esta decisión.
Criterios para seleccionar los casos de prueba de regresión:
Seleccionar solo los casos de prueba de alta prioridad de acuerdo con el

test plan.
Seleccionar solo los casos de prueba positivos que forman parte de la

funcionalidad principal.
Seleccionar los casos de prueba con configuraciones especiales, por

ejemplo casos de prueba que corresponder al perfil de administrador del
sistema.
Seleccionar casos de prueba de ciertos subsistemas o niveles de prueba.

Especialmente en los ciclos de vida de desarrollo iterativos e

incrementales, las nuevas características, los cambios y la refactorización
dan como resultado cambios frecuentes en el código, por lo que son
muy importantes las pruebas asociadas al cambio.
Particularmente relevantes para los sistemas de “Internet de las cosas”

[IoT], donde los objetos individuales (por ejemplo, los dispositivos) se
actualizan o reemplazan con frecuencia.
Los juegos de pruebas de regresión se ejecutan muchas veces y

generalmente evolucionan lentamente, por lo que las pruebas de
regresión son un fuerte candidato para la automatización.
La automatización de estas pruebas debería comenzar al principio del

proyecto.
2.1.2 (K1) Modelos de ciclo de vida de desarrollos de software en
contexto.
2.4.1 (K2) Activadores de mantenimiento.
2.4 Pruebas de Mantenimiento
Un software en producción no esta libre de

defectos ya que existe la posibilidad de que
sufra actualizaciones, se agregue nueva
funcionalidad y/o deba ser retirado de
producción. Por lo tanto requerirá de pruebas
de mantenimiento.
¿Qué son las pruebas de

Mantenimiento?
Son las pruebas que se realizan
después que el cliente dio el visto
bueno al producto y esta en
funcionamiento en producción.
Alcance
• Corregir defectos descubiertos en el uso operativo.
• Extensión de funcionalidad para eliminar o modificar funcionalidades ya
entregadas.
• Conservar o mejorar las características de calidad no funcionales del
componente o sistema a lo largo de su vida útil, especialmente: eficiencia
de desempeño, fiabilidad, seguridad, compatibilidad y portabilidad.
• Corrección de funcionalidad existente por fallos en producción.
El mantenimiento puede incluir entregas planificadas y no planificadas [hot

fixes]. Una entrega de mantenimiento puede requerir pruebas en múltiples
niveles, utilizando varios tipos de prueba, según el alcance que depende de:
• Áreas afectadas del cambio, se comunica con otros componentes o sistemas.

• El tamaño del sistema existente.
• El tamaño del cambio.
Activadores de Mantenimiento
Se pueden clasificar en:
• Mejoras planificadas, cambios correctivos y de emergencia, cambios en el ambiente

operativo [actualizaciones previstas del sistema operativo o de la base de datos],
actualizaciones del "COTS", así como parches para los defectos y vulnerabilidades.
• Migración de una plataforma a otra, que puede requerir pruebas operativas del nuevo
entorno y del software modificado, o pruebas de conversión de datos cuando los datos
de otra aplicación se migren al sistema en mantenimiento.
• Retirada, cuando una aplicación llega al final de su vida útil.
En el caso de los sistemas de IoT [internet of the things], estas pruebas se

hacen por la introducción de cosas nuevas o modificadas, tales como
dispositivos de hardware y servicios de software. Especialmente en las pruebas
de integración a diferentes niveles y en los aspectos de seguridad.
Análisis de impacto para el mantenimiento

El análisis de impacto evalúa los cambios que se hicieron para una entrega de
mantenimiento con el objetivo de:
• Identificar las consecuencias previstas, así como los efectos secundarios

esperados y posibles de un cambio.
• Identificar las áreas del sistema que se verán afectadas por el cambio.
• Identificar el impacto de un cambio en las pruebas existentes.
Los efectos secundarios y las áreas afectadas en el sistema necesitan ser

probados por las regresiones.
Se puede realizar un análisis de impacto antes de realizar un cambio,

para ayudar a decidir si se debe realizar el cambio, basándose en las
consecuencias potenciales en otras áreas del sistema.
El análisis de impacto puede ser difícil si:
• Las especificaciones están desactualizadas o no existen.

• Los casos de prueba no están documentados o están desactualizados.
• No está actualizada la trazabilidad bidireccional.
• El soporte de herramientas es débil o inexistente.
• Las personas involucradas no tienen conocimientos de dominio y/o
sistema.
• No se ha dado mantenimiento del software durante el desarrollo.

Capitulo 2

Cargado por

Copyright:

Formatos disponibles

Capitulo 2

Cargado por

Información del documento

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

Capitulo 2

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 2.

Estos modelos entregan software que contiene el conjunto completo de

Los modelos secuenciales estan representados por un diagrama en cascada o en

Diseño Para resolver este problema, se creó el

Las actividades de prueba solo ocurren

Incluye ciclos de retroalimentación Creación de Código

Análisis Diseño Construcción Pruebas Incremento +1

Análisis Diseño Construcción Pruebas Incremento +2

Análisis Diseño Construcción Pruebas Incremento +3

Estrategia de programación en la que varias partes del sistema se desarrollan en diferentes

Durante las iteraciones pueden haber cambios en las características

Cada iteración entrega un software funcional que es un subconjunto cada vez

Construcción Construcción Construcción

Requisitos Requisitos Requisitos

La duración de las iteraciones

Kanban es entregar lo que el proceso necesita

evaluacion • Prototipo 3 ingenieria

En algunos casos, los equipos utilizan la entrega continua o la integración continúa, lo

Estos métodos también incluyen el concepto de equipos de "auto-organizados", que

A diferencia de los modelos secuenciales, los modelos iterativos e incrementales pueden

• Objetivo del proyecto

En algunos casos los problemas de la organización y la cultura pueden disminuir la

Los niveles de prueba son grupos de actividades de prueba que se

La separación de las pruebas por niveles permite que se analicen con

Se debe realizar siempre un análisis para determinar el nivel que debe

Atributos de los niveles de pruebas:

Se requiere un ambiente de prueba adecuado para cada nivel.

Pruebas de Componente [Unit level]

• Verificar que los comportamientos funcionales y no

Pruebas de integración [Integration level]

El propósito de este nivel es detectar fallas en las interfaces y la Sistema

2. Integración de sistemas: prueban las interacciones e interfaces entre sistemas,

Objetos de Prueba típicos

Enfoques de prueba y reponsabilidades

• Las pruebas de integración de sistemas generalmente son

• Deben centrarse en la comunicación entre los módulos/sistemas,

• Pruebas funcionales, no funcionales y estructurales.

• Dependiedo de la arquitectura podrían tener diferentes enfoques

Pruebas de sistema (System level)

Enfoques de prueba y reponsabilidades

Pruebas de aceptación [Acceptance level]

• Establecer confianza en el sistema, evaluar el correcto

Las pruebas de aceptación pueden producir información para

Se pueden encontrar defectos durante las pruebas de aceptación, aunque no

Estas pruebas también pueden satisfacer o normas legales o requisitos

Formas comunes 2 Pruebas de aceptación operativa

de pruebas de 3 Pruebas de aceptación contractual y regulación

aceptacion: 4 Pruebas alfa y beta

1. Pruebas de aceptación de usuario

2. Pruebas de aceptación operativa

• Instalación, desinstalación y actualización.

4. Pruebas alfa y beta

• Alfa: La característica de estas pruebas es que se realizan con un determinado número

Enfoques de prueba y reponsabilidades

Un tipo de prueba es un grupo de actividades destinadas a probar

Los objetivos pueden incluir:

• Evaluar características de calidad funcional, como la completitud,

¿QUÉ DEBE HACER EL SISTEMA?

¿QUÉ TAN BIEN LO HACE?

Pruebas de Caja Blanca