2 • LAS PRUEBAS A TRAVÉS DEL CICLO
DE DESARROLLO DE SOFTWARE
CAPITULO 2 • FUNDAMENTOS DE PRUEBAS
DE SOFTWARE
BASADO EN EL PROGRAMA DE PROBADOR CERTIFICADO ISTQB
[Link]
El ciclo de vida de desarrollo de software comprende las etapas
por las cuales avanza un proyecto de software, describe cómo las
actividades se relacionan entre sí, y en qué momento deberían
llevarse a cabo.
MODELOS DE CICLO DE DESARROLLO DE SOFTWARE
Los modelos de ciclo de vida de desarrollo de software más comunes, se
clasifican en:
Modelos de desarrollo secuenciales: cada fase comienza cuando la
anterior ha finalizado, como el modelo en cascada.
Modelos de desarrollo iterativos e incrementales: se repiten las
fases tantas veces como sea necesario, como el modelo "V" ó Scrum.
Los modelos se seleccionan en base a las metas, el tipo de producto, el
negocio, y los riesgos asociados, entre otras consideraciones, pueden ser
combinados entre sí.
[Link] por Julio César Oropeza Diseño y contenido por Kelly Aguilar Zambrano
NIVELES DE PRUEBAS
Las pruebas de software son un conjunto de
actividades organizadas y gestionadas en Los Stubs y Drivers nos permiten
distintos niveles y relacionadas con su simular el comportamiento de las
partes de software ausentes durante
respectiva actividad de desarrollo:
el desarrollo.
Pruebas de componentes
Pruebas de Integración: Stubs: Es llamado desde el componente
de componentes y sistema
que se está probando.
Pruebas de Sistema Driver: llama al componente bajo prueba.
Pruebas de Aceptación:
Pruebas de Aceptación de usuarios,
Pruebas de Aceptación operativa,
COTS: son las siglas de Commercial off-
Pruebas de Aceptación Contractual the-shelf o software comercial de
y de Regulación, distribución masiva, por ejemplo Microsoft
Office o Adobe Photoshop.
Pruebas Alfa y Beta
Buenas prácticas en la ejecución de las pruebas
[Link] por Julio César Oropeza
Diseño y contenido por Kelly Aguilar Zambrano
Cada ciclo de desarrollo debe contar con pruebas de validación y verificación
Cada actividad de desarrollo tiene una actividad correspondiente de pruebas
Cada nivel de pruebas tiene objetivos específicos
El análisis y diseño de cada nivel de pruebas debe comenzar durante la actividad
de desarrollo que corresponda
Los probadores deben participar en las discusiones de definición y refinamiento
de requerimientos y diseño
NIVELES DE PRUEBAS [Link] por Julio César Oropeza
Nivel Objetivos Objetos de Prueba Bases de Prueba Defectos típicos Responsables
Conseguir defectos y
fallas en objetos de
Código / Estructuras de Especificaciones de Funcionamiento no Realizado por el
Componentes
prueba
datos Componentes acorde a la especificación desarrollador
Reducir el riesgo
Clases Código Problemas de flujos de
Construir confianza en la datos
Módulos de bases de Modelo de datos
calidad del componente
datos Código y lógica incorrecta
Prevenir defectos que
escalen a niveles de
prueba más altos
Datos incorrectos,
faltantes o mal codificados
Diseño de software y
Secuenciación o
Conseguir defectos y sistemas
sincronización incorrecta a
fallas entre las las llamadas de interfaz
interfaces de módulos y Subsistemas Diagrama de secuencias Las pruebas de
sistemas, así como en Incompatibilidad de la integración de
los módulos en sí Bases de Datos Especificaciones de componentes son a
interfaz
mismos interfaz y protocolos de menudo responsabilidad
Integración
Infraestructura comunicación de los desarrolladores
Fallos en la comunicación
Reducir el riesgo de componentes
Interfaces Casos de uso Las pruebas de
Construir confianza en Fallos en la comunicación integración de sistemas
la calidad de las Interfaces de Arquitectura a nivel de son responsabilidad de los
entre componentes
interfaces comunicación de componentes o sistemas probadores
manejados
aplicaciones API’s
inadecuadamente o no
Prevenir defectos que Flujos de trabajo
manejados en absoluto
escalen a niveles de Microservicios
prueba más altos Definiciones de interfaces
Suposiciones incorrectas
externas
acerca del significado,
unidades o límites de
datos transmitidos entre
componentes
Reducir el riesgo
Especificaciones de
Verificar que los Requisitos del sistema
requerimientos del
sistema son los Informes de análisis de
diseñados y a su vez riesgo
validarlos con lo
especificado por el Aplicaciones Casos de Uso Cálculos incorrectos
usuario
Sistemas de hardware y Épicas e historias de Comportamiento
Sistemas
Validar que el sistema software usuarios incorrecto de tareas del
está completo y funciona sistema Realizadas generalmente
como se esperaba Sistemas operativos por probadores
Modelos de
comportamiento del Control de datos o flujos independientes
Generar confianza en la Sistema bajo prueba de datos incorrectos
calidad del sistema en su sistema
dentro del sistema
conjunto
Configuración del sistema Diagramas de estado
y datos de configuración Funcionamiento
Encontrar defectos y
Manuales de Sistema y de incorrecto del sistema
fallas
Usuario
Evitar que los defectos
escapen a niveles de
prueba más altos, como
las pruebas de
aceptación o producción.
Diseño y contenido por Kelly Aguilar
NIVELES DE PRUEBAS [Link] por Julio César Oropeza
Nivel Objetivos Objetos de Prueba Bases de Prueba Defectos típicos Responsabilidades
Generales:
Procesos de negocio
Requisitos del usuario o
del negocio
Regulaciones, contratos
legales y estándares
Casos de uso
Requisitos del sistema
Documentación del
sistema o del usuario
Establecer confianza en Sistema bajo prueba Las reglas de negocio no Clientes, usuarios de
la calidad del sistema Procedimientos de se implementan negocio, propietarios
como un todo Configuración del sistema instalación correctamente de productos o los
y datos de configuración operadores de un
Validar que el sistema Informes de análisis de El sistema no cumple los sistema y otras partes
está completo y Procesos empresariales riesgos requisitos contractuales o interesadas
funciona como se para un sistema reglamentarios
espera totalmente integrado Operativas:
Aceptación
Procedimientos de Fallas no funcionales
Verificar que los Sistemas de recuperación respaldo y restauración
requerimientos y sitios activos
funcionales y no Procedimientos de
funcionales del sistema Procesos operativos y de recuperación ante
cumplen con las mantenimiento desastres
especificaciones
Formularios Requisitos no funcionales
Satisfacer requisitos
legales o regulatorios. Reportes Datos de Documentación de
producción operaciones
Instrucciones de
despliegue e instalación
Objetivos de rendimiento
Paquetes de bases de
datos
Normas o regulaciones
de seguridad
[Link] por Julio César Oropeza Diseño y contenido por Kelly Aguilar
NIVELES DE PRUEBAS: Tipos de Pruebas de Aceptación
Pruebas de Aceptación de Usuario: se
centra en validar que el sistema cumple los
requisitos de funcionamiento esperado en un
entorno operativo real o simulado.
Pruebas de Aceptación Operativa: valida si
el sistema cumple con los requisitos de
operación y la realizan los usuarios y los
administradores de la aplicación.
Pruebas de Aceptación Contractual: se
realiza según los criterios de aceptación de un
contrato para producir software desarrollado a
medida.
Pruebas Alfa y Beta: se realizan para recibir
retroalimentación de usuarios, clientes y/u
operadores potenciales o existentes antes de la
liberación del producto de software al mercado.
Pruebas Alpha: se realizan en las
instalaciones de la organización que
desarrolla, pero no por el equipo de
desarrollo.
Pruebas Beta: se realiza en las propias
ubicaciones del cliente, fuera de la
organización que desarrolla.
[Link] por Julio César Oropeza Diseño y contenido por Kelly Aguilar Zambrano
TIPOS DE PRUEBAS: [Link] por Julio César Oropeza
Pruebas Funcionales: se encargan del "qué"
debe hacer el sistema.
Pruebas No Funcionales: prueban las
características del producto de software, qué
tan bien se ejecutan elementos como:
recuperación, mantenibilidad, seguridad,
resistencia a fallos, volumen, estrés y carga.
Pruebas de Caja Blanca: se enfocan en la
estructura interna del sistema, entiéndase el
código, arquitectura o flujos de datos dentro
del sistema. Suele ejecutarse en el nivel de
Componente e Integración.
Pruebas Relacionadas a Cambios: Click aqui para ver el
capitulo completo
Pruebas de Confirmación: garantiza que
el defecto reparado pase las pruebas
que previamente falló.
Pruebas de Mantenimiento: Suceden
cuando se realizan cambios como parte del
Pruebas de Regresión: garantizan que no
mantenimiento del software, evalúan el
se hayan generado nuevos problemas
éxito del cambio en sí mismo y verifican
secundarios como consecuencia de los
posibles efectos secundarios. Es decir,
ajustes realizados al software.
constan de dos partes:
Probar los cambios y,
Pruebas de regresión.
Disparadores de Mantenimiento: Son
modificaciones, migración y retiro del software.
Análisis de impacto evalúa las consecuencias
de la implementación de un cambio en el
software.
Diseño y contenido por Kelly Aguilar Zambrano
