Las pruebas durante

todo el ciclo de vida

del Software
 Contenido
01 Modelos de ciclo de vida
Desarrollo de software y prueba de software
Modelos de ciclo de vida de desarrollo de software

Niveles de prueba
Pruebas de integración
02 Pruebas de sistemas
Pruebas de aceptación

Tipos de pruebas
Pruebas funcionales
03 Pruebas no funcionales
Pruebas de caja blanca
Pruebas relacionadas con el cambio
Tipos y niveles de pruebas

04 Pruebas de Mantenimiento
Causas para el mantenimiento
Análisis del impacto para el mantenimiento
INTRODUCCION

Las pruebas de software dentro de una

organización y en nuestra vida diaria, son muy
importante ya que en gran medida nuestros
procesos se llegan a realizar con un software y el
defecto de presentar errores dentro del software
que se usan llegan a tener gran perdida de
recursos como, usuarios, perdida de dinero y
reputación comercial. La prueba y calidad de
software es una forma de evaluar la calidad de
software y mitigar el riesgo de fallos del
software en producción.

3
Modelos de ciclo de vida del
software

▪ Un modelo de ciclo de vida de desarrollo

de software describe los tipos de actividad
que se realizan en cada etapa de un
proyecto de desarrollo de software, y cómo
las actividades se relacionan entre sí de
manera lógica y cronológica.

4
Desarrollo de software y pruebas de software
Se tiene como punto importante del papel de un probador es familiarizarse con los modelos comunes de ciclo
de vida de desarrollo de software para que puedan llevarse a cabo las actividades de prueba adecuadas.

Características:
▪ Para cada actividad de desarrollo, corresponde una actividad de
prueba.
▪ Cada nivel presenta objetivos de pruebas específicas.
▪ Durante el desarrollo correspondiente se comienzas el análisis y
diseño dooo0e prueba.
▪ Los probadores participan en las discusiones para definir y refinar los
requisitos y el diseño, y participan en la revisión de productos de
trabajo.

5
2 MODELOS DE DESARROLLO DE SOFTWARE
▪ Modelos de desarrollo secuencial
Se basa en que cada fase de desarrollo de implementa de una forma lineal y secuencial. Es decir, cada
fase de proceso se comienza cuando haya terminado la anterior.

6
2 MODELOS DE DESARROLLO DE SOFTWARE

▪ Modelos de desarrollo
iterativo e incremental
El desarrollo iterativo ocurre
cuando los grupos de prestaciones
se especifican, diseñan,
construyen y prueban juntos en
una serie de ciclos, a menudo de
una duración fija.

7
Niveles de Pruebas de Software

Son grupos de actividades de prueba que se organizan y administran juntas.

Los niveles de prueba se caracterizan por los

siguientes atributos:
▪ Objetivos específicos
▪ Base de prueba, referenciada para derivar
casos de prueba
▪ Objetos de prueba (es decir, lo que se está
probando)
▪ Defectos y fallos típicos
▪ Enfoques y responsabilidades específicas
Pruebas de Componente

Objetivo Base de Prueba Defectos y fallos típicos

• Funcionalidad incorrecta (p.

• Diseño detallado ej., no como se describe en las
• Reducir el riesgo • Código especificaciones de diseño)
• Verificar si los comportamientos
• Modelo de datos • Problemas de flujo de datos.
funcionales y no funcionales del
• Especificaciones de los componentes
componente son como se diseñaron
y especificaron
• Crear confianza en la calidad del
componente Objetos de Prueba
• Encontrar defectos en el
componente
• Prevenir que los defectos escapen a • Componentes, unidades o módulos
niveles de prueba más elevados • Código y estructuras de datos
• Clases
• Módulos de base de datos
Pruebas de Integración

Objetivo Base de Prueba Defectos y fallos típicos

• Datos incorrectos, datos

• Reducir el riesgo • Diseño de software y de sistema faltantes o codificación de
• Verificar si los comportamientos • Diagramas de secuencia datos incorrecta
funcionales y no funcionales del • Especificaciones de interfaz y • Secuenciación o
componente son como se diseñaron protocolo de comunicación sincronización de llamadas de
y especificaron interfaz incorrecta.
• Crear confianza en la calidad de las
interfaces
• Encontrar defectos (que pueden Objetos de Prueba
estar en las interfaces o en los
componentes o sistemas)
• Prevenir que los defectos escapen a • Subsistemas
niveles de prueba más elevados • Bases de datos
• APIs
• Microservicios
Pruebas de Sistemas

Objetivo Base de Prueba Objetos de Prueba

• Especificaciones de requisitos del

• Reducir el riesgo sistema y software (funcionales y • Aplicaciones
• Verificar si los comportamientos no funcionales). • Sistemas de
funcionales y no funcionales del • Informes de análisis de riesgo. hardware/software.
sistema son como se diseñaron y • Casos de uso. • Sistemas operativos
especificaron. • Epopeyas e historias de usuario • Sistema Sujeto a Prueba
• Validar que el sistema está completo y (SUT).
funcionará como se espera. • Configuración del sistema y
• Crear confianza en la calidad del Defectos y fallos típicos datos de configuración
sistema como un todo.
• Encontrar defectos.
• Prevenir que los defectos escapen a • Cálculos incorrectos.
niveles de prueba o producción más • Comportamiento funcional o no
elevados. funcional del sistema incorrecto o
inesperado.
Pruebas de Aceptación

Pruebas de aceptación
Pruebas de aceptación Pruebas de aceptación
contractuales y Pruebas alfa y beta
del usuario (PAU) operativa (PAO)
regulatorias
• El objetivo principal es • Se realizan • Las pruebas de • Son utilizadas para
crear confianza en generalmente en un aceptación obtener comentarios
que los usuarios entorno (simulado) de contractuales se de usuarios, clientes u
pueden usar el producción. Se realizan según los operadores con el
sistema para incluyen en: prueba criterios de objetivo de generar
satisfacer sus de copia de aceptación de un confianza donde el
necesidades, cumplir seguridad, instalación, contrato para producir sistema se puedas
con los requisitos y desinstalación y software desarrollado usar en condiciones
realizar procesos de actualización, a la medida. normales.
negocios con recuperación de
dificultad, costos y desastres, gestión de
riesgos mínimos. usuarios, tareas
mantenimiento.
Tipos de pruebas
Un tipo de prueba es un grupo de actividades de prueba destinadas a probar características específicas de un
sistema de software, o una parte de un sistema, basado en objetivos de prueba específicos. Tales objetivos
pueden incluir:

▪ Evaluar las características de calidad funcional, como son la integridad, exactitud y pertinencia.
▪ Evaluar las características de calidad no funcionales, como son la confiabilidad, eficiencia del
rendimiento, seguridad, compatibilidad y usabilidad
▪ Evaluar si la estructura o arquitectura del componente o sistema es correcta, completa y según lo
especificado.
▪ Evaluar los efectos de los cambios, como son confirmar que los defectos se han solucionado.
▪ (pruebas de confirmación) y buscar cambios no intencionados en el comportamiento que resulten de los
EXPERIENCIA
cambios DE USUARIO
en el software o el entorno (pruebas de regresión)

13
Pruebas Funcionales

Las pruebas funcionales de un sistema involucran pruebas que evalúan las funciones que debe realizar el
sistema. Los requisitos funcionales pueden describirse en productos de trabajo, como son especificaciones
de requisitos comerciales, epopeyas, historias de usuario, casos de uso o especificaciones funcionales, o
pueden no estar documentados.
Las funciones son “lo qué” el sistema debe hacer.
Las pruebas funcionales tienen en cuenta el comportamiento del software, por lo que se pueden usar técnicas
de caja negra para derivar las condiciones de prueba y los casos de prueba para la funcionalidad del
componente o sistema.

14
Pruebas NO Funcionales

Las pruebas no funcionales de un sistema evalúan las características de los sistemas y el software, como son
la usabilidad, la eficiencia del rendimiento o la seguridad.

Usabilidad Eficiencia del rendimiento Seguridad

• Facilidad de aprendizaje. • Pruebas de carga • Control acceso a los

• Evaluar si cada una de • Pruebas de estrés módulos mediante roles
las vistas del sistema son • Pruebas de estabilidad de usuario.
de fácil uso (UI / UX). • Pruebas de picos • Pruebas de inyección
• Comportamiento del SQL.
sistema o aplicación en • Ataques mediante lista
diferentes entornos. de contraseñas y
ataques de diccionarios.

Norma ISO/IEC 25010

15
La prueba no funcional es la prueba de “qué tan bien” se comporta el
Sistema.
Pruebas de caja blanca

Las pruebas de caja blanca derivan 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.

El diseño y la ejecución de pruebas de caja blanca pueden involucrar habilidades o conocimientos

especiales, como la forma en que se construye el código (p. ej., para usar herramientas de cobertura de
códigos), cómo se almacenan los datos (p. ej., para evaluar posibles consultas de bases de datos) y cómo usar 16
herramientas de cobertura e interpretar correctamente sus resultados.
Pruebas NO Funcionales

Las pruebas no funcionales de un sistema evalúan las características de los sistemas y el software, como son
la usabilidad, la eficiencia del rendimiento o la seguridad.

Usabilidad Eficiencia del rendimiento Seguridad

• Facilidad de aprendizaje. • Pruebas de carga • Control acceso a los

• Evaluar si cada una de • Pruebas de estrés módulos mediante roles
las vistas del sistema son • Pruebas de estabilidad de usuario.
de fácil uso (UI / UX). • Pruebas de picos • Pruebas de inyección
• Comportamiento del SQL.
sistema o aplicación en • Ataques mediante lista
diferentes entornos. de contraseñas y
ataques de diccionarios.

Norma ISO/IEC 25010

17
La prueba no funcional es la prueba de “qué tan bien” se comporta el
Sistema.
Pruebas relacionadas al cambio

Cuando se realizan cambios en un sistema, ya sea para corregir un defecto o debido a una funcionalidad
nueva o cambiante, se deben realizar pruebas para confirmar que los cambios han corregido el defecto o
implementado la funcionalidad correctamente, y no han causado consecuencias adversas imprevistas.

Pruebas de confirmación

• Una vez que se soluciona un defecto, se puede probar el software con todos los
casos de prueba que fallaron debido al defecto, que deben volver a ejecutarse en la
nueva versión del software.
• El propósito de una prueba de confirmación es confirmar si el defecto original se ha
solucionado correctamente.

Pruebas de regresión

• Es posible que un cambio realizado en una parte del código, ya sea una solución u
otro tipo de cambio, pueda afectar accidentalmente el comportamiento de otras
partes del código, ya sea dentro del mismo componente, en otros componentes del
mismo sistema, o incluso en otros sistemas. 18
• Las pruebas de regresión involucran la ejecución de pruebas para detectar dichos
efectos secundarios no deseados.
Tipos y niveles de pruebas – Pruebas FUNCIONALES

Para las pruebas de componente, las pruebas se diseñan en función de cómo un componente debe
calcular el interés compuesto.

Para las pruebas de integración de componentes, las pruebas se diseñan en función de cómo la
información de la cuenta capturada en la interfaz de usuario se pasa a la lógica comercial.

Para las pruebas de sistema, las pruebas se diseñan en función de cómo los titulares de cuentas
pueden solicitar una línea de crédito en sus cuentas corrientes.

Para las pruebas de integración del sistema, las pruebas se diseñan en función de cómo el sistema
utiliza un microservicio externo para verificar la calificación crediticia del titular de una cuenta.

Para las pruebas de aceptación, las pruebas se diseñan según la forma en que el banquero se encarga de
aprobar o rechazar una solicitud de crédito.
Tipos y niveles de pruebas – Pruebas NO FUNCIONALES

Para las pruebas de componente, las pruebas de rendimiento están diseñadas para evaluar la cantidad de
ciclos de CPU necesarios para realizar un cálculo de interés total complejo.

Para las pruebas de integración de componentes, las pruebas de seguridad están diseñadas para
vulnerabilidades de desbordamiento de búfer debido a los datos que pasan desde la interfaz de
usuario a la lógica comercial.

Para las pruebas de sistema, las pruebas de portabilidad están diseñadas para verificar si la capa
de presentación funciona en todos los navegadores y dispositivos móviles compatibles.

Para las pruebas de integración del sistema, las pruebas de confiabilidad están diseñadas para
evaluar la solidez del sistema, si el microservicio de calificación crediticia no responde.

Para las pruebas de aceptación, las pruebas de usabilidad están diseñadas para evaluar la accesibilidad
de la interfaz de procesamiento de crédito del banquero para personas con discapacidades.
Tipos y niveles de pruebas – Pruebas de caja Blanca

Para las pruebas de componente, las pruebas están diseñadas para lograr una cobertura completa de
sentencias y de decisiones para todos los componentes que realizan cálculos financieros.

Para las pruebas de integración de componentes, las pruebas están diseñadas para ejercer la forma
en que cada pantalla en la interfaz del navegador pasa los datos a la siguiente pantalla y a la lógica
comercial.

Para las pruebas de sistema, las pruebas están diseñadas para cubrir secuencias de páginas Web
que pueden ocurrir durante una aplicación de línea de crédito.

Para las pruebas de integración del sistema, las pruebas están diseñadas para ejercer todos los
tipos de consultas posibles enviadas al microservicio de calificación crediticia.

Para las pruebas de aceptación, las pruebas están diseñadas para cubrir todas las estructuras de archivos
de datos financieros compatibles y los rangos de valores para las transferencias de banco a banco.
Pruebas de Mantenimiento

Una vez implementado en los entornos de producción, el software y los sistemas se deben mantener. Los
cambios de varios tipos son casi inevitables en el software y los sistemas entregados, ya sea para corregir los
defectos detectados en el uso operacional, para agregar una nueva funcionalidad, o para eliminar o alterar
una funcionalidad ya entregada.

El alcance de las pruebas de mantenimiento depende de:

• El grado de riesgo del cambio, por ejemplo, el grado en que el área cambiada del software
se comunica con otros componentes o sistemas.
• El tamaño del sistema existente.
• El tamaño del cambio.

22
Causas para el Mantenimiento

Hay varias razones por las que se realiza el mantenimiento del software y, por lo tanto, pruebas de
mantenimiento tanto para cambios planificados como no planificados.

Modificación La migración Retiro

• Tales como mejoras • Como la de una • Como cuando una

planificadas (p. ej., plataforma a otra, que aplicación llega al final de
basadas en versiones), puede requerir pruebas su vida útil.
cambios correctivos y de operativas del nuevo
emergencia, cambios en entorno así como del
el entorno operativo software modificado, o
(como las actualizaciones pruebas de conversión de
planificadas de sistemas datos cuando los datos de
operativos o bases de otra aplicación se
datos), actualizaciones migrarán al sistema que
del software COTS y se está manteniendo.
parches para defectos y
vulnerabilidades. 23
Análisis de impacto

El análisis de impacto evalúa los cambios que se realizaron para una entrega de mantenimiento para
identificar las consecuencias previstas, así como los efectos secundarios esperados y posibles de un cambio,
y para identificar las áreas en el sistema que se verán afectadas por el cambio.

El análisis del impacto puede realizarse antes de que se realice un cambio, para ayudar a decidir si el
cambio se debe realizar, en función de las posibles consecuencias en otras áreas del sistema.

El análisis del impacto puede ser difícil si:

• Las especificaciones (p. ej., requisitos comerciales, historias de usuario, arquitectura) están
desactualizadas o faltan
• Los casos de prueba no están documentados o están desactualizados
• La trazabilidad bidireccional entre pruebas y la base de pruebas no se ha mantenido
• El soporte para las herramientas es débil o inexistente
• Las personas involucradas no tienen conocimiento de dominio y/o del sistema
• Se ha prestado poca atención a la capacidad de mantenimiento del software durante el desarrollo

24
THANKS!
25