U5 – Software Configuration Management

Conceptos de Software Configuration Management (SCM)

Gestión de Configuración de Software

La Gestión de Configuración de Software es una disciplina orientada a administrar la evolución

de Productos, Procesos y Ambientes , definiendo mecanismos para administrar diferentes
versiones de los mismos, controlando los cambios efectuados, y auditando y reportando la
actividad de cambios realizada

Su propósito es establecer y mantener la integridad de los artefactos del proyecto de software

a lo largo del ciclo de vida del mismo.

Software

Conceptos clave

• Ítem de Configuración (IC)

o Es cualquier elemento involucrado en el desarrollo del producto y que está bajo
el control de la gestión de configuración
o Para cada ítem se conoce información específica para poder identificarlo, como
por ejemplo: nombre, versión, fecha de creación, autor, entre otros atributos.

• Configuración (De Software)

o Es el conjunto de ítems de configuración que gestionaremos para la construcción
de nuestro producto Software
o La Configuración de Software puede o no contener código, dependerá del
momento en la construcción del producto Software.
o Ej: Sistemas operativos compuesto por makefile, máquinas virtuales,
especificación de entregas, scripts de pruebas y ejecución, etc.

• IC’s de Proceso
o Son los ítems generados por el proceso de desarrollo. Ejemplos: Plan de CM,
Propuestas de Cambio, Plan de desarrollo, Plan de Calidad, Lista de Control de
entrega, Planes de proyecto
 o Algunos de estos ítems sólo son gestionados durante una parte de la vida del
producto sw, ejemplo, el plan de proyecto solo es gestionado durante el
proyecto y luego se deja de gestionar o se elimina
o Otros ítems de proceso pueden seguir siendo gestionado durante toda la vida
del producto sw, ejemplo el plan de CM

• IC’s de Producto
o Son los ítems propios del producto software y que son gestionados durante todo
el ciclo de vida del mismo. Son transversales a todos los ciclos de mantenimiento
del producto. Ejemplos: Requerimientos, Plan de Integración, Manual de
Usuario, Arquitectura del Software, Estándares de codificación, Casos de
prueba, Código fuente, Documento de despliegue

• Línea Base (Baseline)

o Conjunto de ítems de configuración que
forman/generan una configuración a
partir de la cual puedo tomar decisiones
y puedo establecer un determinado
acuerdo en algún momento. Es decir
ponerse de acuerdo que esta es la versión
que funciona y qué tiene por
componentes. Estos componentes me
son significativos por algún motivo y me
generan una configuración que me sirve
de referencia. Ej: configuración inicial.
o Se establece porque se verifica que esta configuración del ítem o conjunto de
ítems satisface (n) algunos requerimientos funcionales o técnicos.
o Esta línea base puede no contener código y puede no coincidir con un release
de Software

• Trazabilidad: Es la capacidad de rastrear un ítem de configuración a lo largo de todo el

proceso

• Trazabilidad Horizontal: Representa la capacidad de tracear todos los ítems de

configuración generados en cada etapa del proceso por un mismo requerimiento.
• Trazabilidad Vertical: Representa la capacidad de tracear todos los ítems de
configuración del mismo tipo, generados en la misma etapa

• Branching
o Es la acción de crear líneas de desarrollo separadas de una línea de trabajo. Se
las conoce usualmente como branches
o Estos branches son mecanismos utilizados por los equipos para que puedan
desarrollar nuevas funcionalidades utilizando un entorno de trabajo separado
del resto.
o Estas líneas utilizan las líneas base de un repositorio existente como punto de
partida, de esta forma, las features y bug fixes son desarrolladas de forma
separada que facilitando el trabajo de estos temas en paralelo.
o Permite a los miembros del equipo trabajar en múltiples versiones de un
producto, utilizando el mismo set de Ítems de Configuración

• Ambiente (Environment)
o Un entorno de implementación es una colección de servidores, clústeres y
servicios configurados que colaboran para proporcionar un entorno para alojar
módulos de software.
o Cada entorno se construye con un propósito, pudiendo tener características
funcionalmente similares pero no necesariamente ser iguales a nivel
infraestructura.
▪ Un ejemplo asociado a esto son los entornos de pre-producción y
producción. No necesariamente son iguales a nivel infraestructura pero
deberían ser equivalentes a nivel software.
▪ El propósito del ambiente es decidido por la organización o el equipo de
trabajo. Es decir cada organización o equipo decide para qué será
utilizado el ambiente y en qué etapa del proceso de desarrollo se
utilizará.
o Ambientes comunes en el desarrollo suelen ser desarrollo, staging, producción
Funciones de SCM (Software Configuration Management)

Identificación de la configuración de software

Definir qué elementos (ICs) estarán controlados por la gestión de configuración.

• No todo necesita estar bajo SCM: El ítem de configuración tiene que tener un uso, un
valor para ser gestionado
• Es necesario contar o definir con guías para qué elementos son parte o no. Define
momentos o condiciones para establecer una línea de base o bien para liberarla (es
decir, llevarla a otro ambiente, también conocido como “release”).

Define momentos o condiciones para establecer una línea de base o bien para liberarla (es
decir, llevarla a otro ambiente, también conocido como “release”).

Control de la CS

• Ya pasé la etapa de código, tengo todo el código y creo que funciona.

• Debemos establecer un orden para hacer los cambios en el software. (Cómo se solicita
y quien acepta o rechaza).
• Ahora tengo que operar el SW con las situaciones tradicionales que va a tener, cambios
por:
o Requerimientos
o Bugs
o Cambios

Status & Accounting de la configuración

• Seguimiento y control de la configuración.

• Ahora comienza la ejecución (los devs programan, se opera el SW, PRs, branches, etc).
• Se implementa siempre con una herramienta de control de versiones.
• Registrar y reportar la información necesaria para administrar la configuración de
manera efectiva.
o Listar los ICs aprobados
o Mostrar el estado de los cambios que fueron aprobados
o Reportar la trazabilidad de todos los cambios efectuados al baseline.
Administración del proceso de Gestión de Configuración del Software

La Administración del Proceso de Gestión de Configuración del Software define herramientas,

reportes y procesos que serán utilizados, en la organización o el proyecto, para la gestión de
configuración.

Se encarga de definir cómo serán incorporados los ICs, cuando se realizarán las líneas base,
como será la estrategia de desarrollo en paralelo, y como serán nomencladas las versiones,
entre otras definiciones.

Generalmente se realiza mediante la definición de un plan de CM o Plan de Gestión de

Configuración

Branching strategies

• La estrategia de Branching es la estrategia que adoptan los equipos de desarrollo de

software al escribir, mergear e implementar código cuando usan un sistema de control
de versiones (git / SVN / TFS).
• Es esencialmente un conjunto de reglas que los desarrolladores pueden seguir para
estipular cómo interactúan con una base de código compartida.
• Una estrategia de branching tiene como objetivos:
o Mejorar la productividad al garantizar una coordinación adecuada entre los
desarrolladores
o Facilitar el desarrollo paralelo
o Ayudar a organizar una serie de lanzamientos planificados y estructurados
o Trazar un camino claro al realizar cambios en el software hasta la producción
o Mantenga un código libre de errores donde los desarrolladores puedan
corregir problemas rápidamente y hacer que estos cambios vuelvan a la
producción sin interrumpir el flujo de trabajo de desarrollo.

Gitflow

• Consiste en dos ramas principales que existen a lo largo de todo el ciclo de vida del
desarrollo, master y develop y tiene una serie de branches de soporte. En Master vive
el código productivo.
Github Flow

• Creado por GitHub, busca ser una alternativa simplificada del desarrollo
• Existe una rama Master de donde parten las ramas de desarrollo
• Cada nueva feature se trabaja en una rama separada que es integrada nuevamente en
master cuando el trabajo finaliza

Trunk based Flow

Un modelo de branching de control de fuente, donde los desarrolladores colaboran en el

código en una sola rama llamada "troncal", resiste cualquier presión para crear otras ramas de
desarrollo de larga duración mediante el empleo de técnicas documentadas. Por lo tanto,
evitan fusionar el infierno, no rompen la construcción y viven felices para siempre.

Ejemplo de proceso de SCM

Podemos decir que tenemos un proceso definido cuando:

NOTA: Estos puntos no son todo lo que hay que tener, son una base mínima necesaria para
garantizar la gestión.

Identificación de la configuración

La identificación de la configuración es la actividad de definir qué elementos (ICs) estarán

controlados por la gestión de configuración ya que no todos los artefactos necesitan ser
gestionados para garantizar la integridad del producto.

Para esto, la actividad establece guías o criterios para entender qué elementos son parte o no
de una configuración.

La identificación de la configuración también define momentos o condiciones para establecer

una línea de base o bien para liberarla (es decir llevarla a otro ambiente, también conocido
como “release”)
¿Cómo se registran ICs?

La actividad tiene que identificar los ítems de configuración que serán gestionados. Para ello, se
pueden ejecutar distintas acciones, como por ejemplo:

• Identificar Código
o Buscar fuentes
o Chequear repositorios
o Entender la arquitectura
• Identificar ambientes de ejecución
o Tratar de instalar una versión
o Identificar Bases de datos, servers, configuraciones
• Identificar Documentación
o Buscar especificaciones
o Entender cambios anteriores

¿Qué elementos se registran de un IC?

Nombre, Versión, Autor / Revisores, Módulos o ítems relacionados, Última modificación, Tipo
de IC (código, scripts, diagramas, requerimientos, etc).

Estos atributos serán registrados y se utilizarán como información útil en la actividad de Status
& Accounting de la configuración

Control de Cambios de la configuración

El Control de Cambios de la Configuración asegura que los ítems de configuración mantienen

su integridad ante los cambios a través de:

• La identificación del propósito del cambio

• La evaluación del impacto y aprobación del cambio
• La planificación de la incorporación del cambio
• El control de la implementación del cambio y su verificación

El Control de Cambios de la Configuración consiste en establecer un procedimiento de control

de cambios y controlar el cambio y la liberación de ICs a lo largo del ciclo de vida.

Software configuration control board

Es quién tiene la autoridad de aceptar o rechazar un cambio en la configuración de Software.

En proyectos grandes puede ser mas de una persona. También puede haber diferente niveles
de autorización de acuerdo a diferente criterios.
Change management process

• Identificar el cambio: formalizar el pedido de cambio

• Evaluar el impacto: se analiza el cambio y se determina el impacto que tendrá en el
software, el equipo que trabaja en él y quienes lo usarán.
• Decidir hacer o no el cambio: entendiendo el impacto en el negocio, o en el calendario
o en el equipo.
• Planificar la implementación del cambio: incorporarlo dentro de las tareas a realizar

Mediciones realizadas a change requests

• Successful Changes: Cuenta la cantidad de cambios que han sido aprobados y

desplegados en producción sin generar incidentes.
• Emergency Changes: Cuenta la cantidad de cambios que han sido aprobados por
canales de urgencia o emergencia.
• Changes in Backlog: mide la cantidad de cambios pendientes de ser analizados. Es un
indicio de la eficiencia del proceso de aprobación de cambios y se puede utilizar para
evaluar la velocidad del equipo

Status Accounting de la Configuración

Status Accounting tiene la función de registrar y reportar la información necesaria para

administrar la configuración de manera efectiva. Para ello debe:

• Listar los ICs aprobados

• Mostrar el estado de los cambios que fueron aprobados
• Reportar la trazabilidad de todos los cambios efectuados al baseline

Una implementación exitosa de esta actividad debe poder contestar:

• ¿Qué cambios se realizaron al sistema?

• ¿Cuándo se realizaron dichos cambios?
• ¿Quién lo cambió?
• ¿Qué cambió?

También responder acerca del proceso de cambios

• ¿Quién aprobó el cambio?

• ¿Quién solicitó el cambio?

Auditorías de la Configuración de Software

Una auditoría de Configuración de Software es una examinación de un trabajo, producto o set

de artefactos para evaluar aspectos técnicos, de seguridad, legales y de cumplimiento de
normas con respecto a especificaciones, estándares, acuerdos contractuales u otros criterios.

Las auditorías son llevadas a cabo de acuerdo a procesos definidos y pueden ser ejecutadas
con diferentes niveles de formalidad, desde Revisiones informales basadas en checklists hasta
Pruebas exhaustivas de la configuración que son planificadas con anticipación.
Tipos de auditorías

Release Management

Release Management consiste en asegurar la construcción exitosa del paquete de software,

basada en los ICs requeridos para la funcionalidad a entregar, para luego liberarlo en forma
controlada a otros entornos ya sea de pruebas, producción, usuario final, etc.

Se divide en 2 partes:

- Software Building
- Release Management

Comprende también la administración, identificación y distribución de un producto Software

Software Building

Software Building es la construcción del paquete de software que será distribuido, utilizando
las versiones correctas de los Ítems de Configuración y las herramientas apropiadas para
construirlo.

• Build: es el proceso de convertir archivos de código fuente en artefactos de software

independientes que se pueden ejecutar en un entorno. Hay distintos tipos de build:
o Local builds: El developer lo realiza localmente en su entorno de desarrollo,
corre Pruebas Unitarias (UT)
o Integration builds: su objetivo es generar el entorno completo para pruebas de
integración Nightly builds: su objetivo es ejecutar la construcción en forma
diaria y generar reportes con información sobre estabilidad, tiempo de build,
etc.
o Release builds: Se disparan cuando bien un administrador decide crear una
nueva versión a ser liberada, o por el mismo sistema de integración si se utiliza
el modo de deployment contínuo
Release Management

Software Release Management gestiona la identificación (Identification), ensamblado (packing)

y la entrega (Delivery / Deployment) de los elementos de un producto Software (por ejemplo,
un ejecutable, documentación, notas de lanzamiento o datos de configuración)

Define también el proceso de planificación, calendarización y gestión del software construido a

lo largo de las etapas de desarrollo, testing, despliegue y soporte productivo.

Comprende también la administración, identificación y distribución de un producto Software

Tenemos el código, hicimos los cambios pedidos, debemos construir nuestra configuración y
habilitarla para que pueda ser utilizada por los usuarios (A.K.A producción).

Con el software que construimos necesitamos desplegarlo en algún ambiente

Desplegar SW: Cualquier software o build que sale del ambiente que fue desarrollado se dice
que está siendo desplegado.

Una vez generada la versión o release debemos buscar el mecanismo más efectivo para hacer
despliegue -deploy- controlado a los distintos usuarios. A estos mecanismos se los denomina
Deployment Strategies

Definiciones del software reléase management

• Versión: es una instancia de un sistema que es funcionalmente distinta en algún

aspecto de otras instancias.
• Variante: una instancia de un sistema que es funcionalmente igual a otras instancias,
pero difiere a niveles no funcionales (Ejemplo: Mismo producto para Version Linux /
Version Windows)
• Release: el término “Release” utilizado en este contexto, hace referencia a la
distribución del Software fuera del entorno de desarrollo. En algunas herramientas, se
utiliza el concepto de un “tag” como equivalente de release.
Es una propuesta de un set de reglas y requerimientos que dictaminan como los
números de versión son asignados e incrementados.
Semantic versioning

Dado un número de versión MAJOR.MINOR.PATCH, se incrementa:

• El número de versión MAJOR cuando se realizan cambios incompatibles en la API o SW

• El número de versión MINOR cuando se agrega funcionalidad de una manera
compatible con versiones previas
• El número de versión PATCH cuando se arreglan bugs de forma compatible con
versiones anteriores

Se pueden agregar etiquetas adicionales para pre-releases o metadatos de build como

extensiones al formato MAJOR.MINOR.PATCH.

Consideraciones antes de realizar un release

Una vez generada la versión o release debemos buscar el mecanismo más efectivo para hacer
despliegue -deploy- controlado a los distintos usuarios. A estos mecanismos se los denomina
Deployment Strategies

Aspectos a evaluar para realizar un release:

• Qué usuarios deberán recibir los cambios (geográfico, premium, por segmento)
• En qué forma se deberá hacer el despliegue
• Entornos por los que deberá pasar (testing, staging, producción, otros)
• Procesos de Roll Forward
• Procesos de Rollback
• Validación de despliegue correcto / incorrecto
• Riesgos del despliegue y cómo se minimizan
• Aprobación por el negocio y/o área de QA
• Quienes realizarán el deployment de la versión definida

Integración continua (CI)

• La integración continua (CI) es una práctica de desarrollo de software mediante la cual

los desarrolladores combinan los cambios en el código en un repositorio central de
forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas.
• La integración continua se refiere en su mayoría a la fase de integración del
proceso de publicación de software y conlleva un componente de automatización
• Es una práctica requerida para poder realizar entregas continuas (Continuous Delivery)
Ventajas de CI

• Detección temprana y mejorada de errores, y métricas que le permiten abordar los

errores a tiempo, a veces tras solo unos minutos de la incorporación
• Progreso continuo para mejorar el feedback
• Mejor colaboración en equipo; todos los miembros del equipo pueden cambiar el
código, integrar el sistema y determinar rápidamente los conflictos con otras partes del
software
• Integración mejorada del sistema, lo que reduce las sorpresas al final del ciclo de vida
de desarrollo del software
• Menor número de errores durante las pruebas del sistema
• Sistemas actualizados constantemente en los que realizar las pruebas
• Fin del “en mi máquina funciona”

Continuous delivery

La Entrega Continua es un conjunto de prácticas que permiten

asegurar que el software puede desplegado en producción
rápidamente y en cualquier momento, aplicando el concepto de
pipelines

Esto lo logra haciendo que cada cambio llegue a un entorno de

staging o semi productivo, donde se corren exhaustivas pruebas de
sistema. Luego se puede pasar a producción manualmente cuando
alguien apruebe el cambio con solo apretar un botón.

Pipelines en CD

Los procesos de Continuous Delivery establecen un pipeline de acciones (pasos a seguir) para
poder construir e instalar el producto Software:

• Testing and QA del Software Construido: ejecuta las pruebas automáticas

• Change Management, Governance, and Approvals: contiene las actividades de
aprobación de los cambios a desplegar
• Deployment Strategies: define la estrategia con la que el Software será desplegado en
el ambiente
• Verification: define las actividades para verificar que el software fue correctamente
desplegado
• Rollback: define las acciones para volver al estado anterior, en el caso de que falle la
verificación

El Continuous deployment es el paso siguiente al Continuous Delivery, en donde también el

despliegue a producción se realiza en forma automática por un proceso y no por personas.
Diferencias entre integración continua (CI), entrega continua (CD) y despliegue continuo

El Continuous deployment es el paso siguiente al Continuous Delivery, en donde también el

despliegue a producción se realiza en forma automática por un proceso y no por personas.

Deployment strategies

El objetivo es realizar el cambio sin generar un downtime, de forma tal que los usuarios finales
no noten el cambio de la aplicación.

• Basic deployment: Todos los nodos de la aplicación son actualizados en el mismo

momento con la nueva versión. Es simple de utilizar pero tiene un gran riesgo de
downtime
• Blue / Green Deployment:
o Disponemos de dos ambientes lo más similar posible, uno “green” y el otro
“blue”
o El despliegue se realiza sobre uno de los ambientes, mientras el otro contiene
la versión anterior
o Un balanceador selecciona a qué grupo de servers utilizar como productivo
o Simple de implementar
o Costoso manter dos ambientes productivos
• Rolling Deployment
o Los nodos de un ambiente son actualizados 1 a 1 (o en lotes) con la nueva
versión del software.
o Ventaja: rollout gradual con un incremento de tráfico controlado. Simple de
hacer rollback
o Desventajas: App / BD necesitan mantener consistencia para trabajar con
versiones distintas (+1 y -1 en cada pod)
• Canary Deployment

Metricas del release magement

• Deployment Frequency: Cada cuanto tiempo una organización despliega software a

Producción satisfactoriamente
o Medida: Cant. Deployments por día
o ¿Para qué? : Indica cada cuanto tiempo agregamos valor a los clientes
 • Change Failure Rate: El porcentaje de despliegues que llevaron a una degradación del
servicio
o Medida: Número de Incidentes / Número de despliegues
o ¿Para qué? : Incrementar la satisfacción de los clientes al reducir el número de
downtimes
• Mean Time To Recovery (MTTR): El tiempo que le demora a la organización
recuperarse luego de un incidente
o Medida: Tiempo medido en horas
o Para qué? :Incrementar la satisfacción de los clientes al reducir el número de
downtimes
• Lead Time for Changes: el tiempo que le lleva a un Commit llegar a Producción
o Medida: Lead Time en días
o ¿Para qué? : Potencialmente puede indicar la productividad del proceso de
desarrollo

Software Configuration Management Tools

Las herramientas dan soporte a la gestión de configuración en diferentes niveles. Cada

organización define qué herramientas utiliza en esta gestión.

Las herramientas tienen distintos propósitos:

• Herramientas que gestionan las versiones de los código fuente, archivos de

configuración y artefactos relacionados.
• Herramientas que ayudan en la automatización del Build y establecen mecanismos (Vía
Pipelines) para permitir el delivery continuo
• Repositorios que almacenan las historias de los builds
• Herramientas que gestionan los cambios funcionales y el control de cambios
• Herramientas que dan soporte al despliegue de aplicaciones
• Herramientas colaborativas para comunicar
Devops - La fusión entre desarrollo y operaciones

En las organizaciones tradicionales antes:

• El que desarrolla no escribe los requerimientos

• El que desarrolla no hace testing funcional
• El que desarrolla no pasa a producción
• El que desarrolla no está de guardia

Durante décadas el equipo de operaciones experimentó grandes diferencias con

desarrolladores que no consideraban:
 • Que los entornos pueden tener diferencias
• Que la puesta en producción no es gratuita
• Cuestiones como la escalabilidad, performance, disponibilidad, tolerancia a fallos,
entre otros.
• Hacer software no es fire & forget, y esperaban que operaciones maneje
automáticamente cualquier problema, sin conocimiento del dominio

DevOps es un conjunto de prácticas destinadas a reducir el tiempo entre el cambio en un

sistema y su pasaje a producción, garantizando la calidad y minimizando el esfuerzo.

Es también un cambio cultural, ya que en un modelo de DevOps, los equipos de desarrollo y

operaciones ya no están “aislados”. A veces, los dos equipos se fusionan en uno solo, donde los
ingenieros trabajan en todo el ciclo de vida de la aplicación, desde el desarrollo y las pruebas
hasta la implementación y las operaciones, y desarrollan una variedad de habilidades no
limitadas a una única función.

DevOps NO es una metodología, es más bien un conjunto de prácticas, herramientas y una

filosofía cultural que automatizan e integran los procesos entre los equipos de desarrollo de
software y IT.

CALMS

• Cultura: Ser dueños del cambio para mejorar la colaboración y comunicación.

• Automatización: Eliminar el trabajo manual y repetitivo lleva a procesos repetibles y
sistemas confiables, reduciendo el error humano.
• Lean: Remover la burocracia para tener ciclos más cortos y menos desperdicio
• Métricas: Medir todo, usar datos para refinar los ciclos.
• Sharing: Compartir experiencias de éxito y fallas para que otros puedan aprender.
Ciclo de vida DevOps

• Planificación del Cambio

o Conversación y colaboración
• Coding & Building
o Automated Build Pipelines
o Infrastructure as Code
• Testing
o Automated Testing
o Chaos Testing / Fault Injection
• Release & Deployment
o Continuous Integration
o Continuous Delivery
• Operation & Monitoring
o Virtualization & Containers
o Monitoring & Alerting tools
 U6 – Testing

¿Qué es un SW de calidad?

• Aquel que cumpla con los requisitos

• Aquel que al ser usado no tenga fallos

Aseguramiento de calidad

Testing es una actividad de QA pero no la única

El Aseguraniento de la Calidad implica la revisión y auditoría de los productos y actividades

para verificar que cumplen los procedimientos y estándares aplicables y suministrando a los
gerentes de proyecto y otros del resultado de estas revisiones y auditorías.

Asegurar la Calidad vs Controlar la Calidad

• La Prueba del Software es una de las actividades involucradas en el Aseguramiento de

Calidad
• Una vez definidos los requerimientos de calidad tengo que tener en cuenta que:
o La calidad no puede “inyectarse” al final
o La calidad del producto depende de tareas realizadas durante el proceso
o Detectar errores en forma temprana ahorra esfuerzos, tiempo, recursos

Objetivo de la prueba

Si el objetivo del testing es encontrar fallas como corolario podríamos decir que si no se
encuentran fallas ¿el testing falla?

Sabemos que siempre podemos encontrar una falla por mas mínima que sea, sin embargo
debemos tener en cuenta que el testing debe ser:

• Eficiente
o Lo mas rápido posible
o Lo mas barato posible
• Eficaz
o Encontrar la mayor cantidad de fallas
o No detectar fallas que no son
o Encontrar las mas importantes

Prueba del SW

SEGÚN IEEE: Una actividad en la cual un sistema o componente es ejecutado bajo condiciones
específicas, los resultados de dicha ejecución son observados o registrados y, a partir de los
mismos, se realiza una evaluación de algún aspecto del sistema o componente

Testing

• Es una actividad dinámica: Necesito ejecutar algo, algo que haya compilado y que
pueda correr. No es una revisión de código, ver una porción de código o un script.
• Si no tengo los requerimientos, no sé los resultados que debo esperar, no sé qué
probar, y al final del día los termina pensando el tester
Proceso de la prueba

Conceptos relacionados con el testing

• Incidente de testing: toda ocurrencia de un evento que sucede durante la ejecución de

una prueba de software que requiere investigación. No toda incidencia es una falla.
Por ejemplo:
o Equivocaciones al ejecutar las pruebas
o Interpretaciones erróneas
• Equivocación: acción humana que produce un resultado incorrecto
• Defecto: paso, proceso o definición de dato incorrecto. Ausencia de cierta
característica
• Falla: Resultado de ejecución incorrecto. Es el producido por el SW distinto al resultado
esperado
 • Una equivocación lleva a uno o mas
defectos que están presentes en el
código
• Un defecto lleva a cero, una o más
falla
• La falla es la manifestación del
defecto
• Una falla tiene que ver con uno o mas
defectos

• CONDICION DE PRUEBA: Son descripciones de situaciones que quieren probarse ante

las que el sistema debe responder. Crear condiciones es un proceso “creativo”
• CASOS DE PRUEBA: Son lotes de datos necesarios para que se dé una determinada
condición de prueba. Crear condiciones es un proceso “laborioso”
• CRITERIO DE SELECCIÓN: Es una condición para seleccionar un conjunto de casos de
prueba
• PARTICIÓN: todos los posibles casos de prueba los dividimos en clases y todos los casos
de una misma clase detectan los mismos defectos. El éxito está en la selección de la
partición para abarcar todos los posibles defectos.

Depuración

• Depurar es eliminar un defecto que posee el SW

• La depuración NO es una tarea de prueba aunque es consecuencia de ella
• La depuración puede ser fuente de introducción de nuevos defectos

Proceso de depuración

1. Detectar: dada la falla debemos hallar el defecto

2. Depurar:
a. Encontrar el motivo de la falla
b. Hallar una solución y aplicarla
3. Volver a probar: asegurar que sacamos el defecto y que no hemos introducido otros
(regresión)
4. Aprender para el futuro
Economía del testing

Hasta cuando tengo que probar

PROBAR en definitiva es el
proceso de establecer confianza
en que un SW hace lo que se
supone que tiene que hacer y ya
que nunca se va a poder
demostrar que un SW es
correcto, continuar probando es
una decisión económica

Algunos criterios para detener

una prueba pueden ser:

• Para exitosamente el conjunto de pruebas que fue diseñado

• “Good Enough”: cierta cantidad de fallas no críticas es aceptable
• Cantidad de fallas detectadas es similar a la cantidad de fallas estimadas

Como abaratar costos de las pruebas

Hacer pruebas es caro y trabajoso. La forma de abaratarlas y acelerarlas (sin degradar su

utilidad) es DISEÑANDO EL SW PARA SER TESTEADO. Para eso:

• Diseño Modular
• Ocultamiento de Información
• Uso de Puntos de Control
• Programación NO egoísta

Conclusiones

• Las pruebas no mejoran el SW, sólo muestran cuantas fallas se han producido debido a
distintos tipos defectos
• El buen diseño y construcción no solo benefician a las pruebas, sino también a la
corrección de los componentes y su mantenimiento
• El No probar No elimina los errores, ni acorta tiempos, ni abarata el proyecto
• Lo mas barato para encontrar y eliminar defectos es NO introducirlos
• Probar sw es una actividad creativa e intelectualmente desafiante

Prueba funcional – enfoques de prueba

Prueba de caja negra

• Prueba lo que el software debería

hacer:
o Se basa en la definición del
módulo a probar
o Nos desentendemos
completamente del
comportamiento y estructura
interna del componente

Clases de equivalencia

La prueba de caja negra exhaustiva es imposible de realizar ya que se debería probar el

universo completo de casos.

Es por eso que seleccionamos subconjuntos de los datos de entrada posibles, esperando que
cubran un conjunto extenso de otros casos de prueba posibles

Podemos suponer que la prueba de un valor representativo de cada clase es equivalente a la

prueba de cualquier otro valor. Llamamos a c/subconjunto “Clase de Equivalencia”

Partición en clase de equivalencia

El proceso incluye dos pasos:

• Identificar las clases de equivalencia: se hace dividiendo cada condición de entrada en dos
grupos: clases validas y clases invalidas
• Definir casos de prueba

La identificación de clases de equivalencia se hace dividiendo cada condición de entrada en dos

grupos: clases validas y clases invalidas

Condición de borde

La experiencia muestra que los casos de prueba que exploran las condiciones de borde
producen mejor resultado que aquellas que no lo hacen

En términos generales, una condición de borde es aquella que explora los límites o bordes de
un sistema o programa. Son como las instrucciones que te dicen qué hacer cuando estás en
una situación extrema o en la frontera del software, para que todo funcione correctamente y
no se rompa.

Clases invalidas

Se refiere a:

• Caracteres numéricos en vez de alfabéticos

• Alfabéticos en vez de numéricos
• Combinaciones de ambos
• Fechas erróneas
En algunos casos, estas validaciones ya son resueltas por el entorno de desarrollo, y en
consecuencia los casos de prueba no son necesarios

Muchas veces, la combinación de los datos de entrada es las que produce una clase válida o
inválida. Por ejemplo: podría ser que si el estado civil es divorciado, los datos del cónyuge se
deben ignorar

Conjetura de errores

Cuando “Sospechamos” que algo puede andar mal, enumeramos una lista de errores posibles
o de situaciones propensas a tener errores y creamos casos de prueba basados en esas
situaciones.

• La creatividad juega un papel clave

• No hay una técnica para la conjetura de errores
• Es un proceso intuitivo y ad hoc
• Se basa mucho en la experiencia

Es interesante utilizarlo cuando:

• Un componente, o parte de él, hecho “a las apuradas”

• Un componente modificado por varias personas en distintos momentos
• Un componente con estructura anidadas, condiciones compuestas, etc...
• Un componente que sospechamos fue armado por la “técnica de copy & paste” de
varios otros componentes

Definiendo condiciones y casos

Partiendo de componentes generados por la etapa de requerimientos.

• Wish list
o Cada statement (declaración) es un requerimiento funcional
o Un requerimiento que no es testeable no es implementable
o Pensar en “variaciones” de las declaraciones funciona muy bien.
• Casos de uso
o La secuencia de eventos dentro de un caso de uso tiene variaciones indicadas
por su texto
o Cada variación de un evento constituye una “condición de prueba”
o Cada condición debe ser ejercitada por, al menos, un caso de prueba
o Cada caso ejercitará uno o varios componentes involucrados
o El conjunto de condiciones y casos constituye la base de la prueba de
aceptación funcional
• Modelo de datos: La integridad referencial entre tablas y la cardinalidad de las
relaciones definen reglas de negocio que deben ser probadas. Por ejemplo:
o Una Mesa de Examen sin Alumnos
o Una Mesa de Examen con un Alumno
o Una Mesa de Examen con muchos (n) Alumnos
• Diagrama de transición de estados: El ciclo de vida de un objeto define reglas de
negocio que deben ser probadas
o Transiciones válidas
o Transiciones inválidas
Conclusiones

• Ninguna técnica es completa

• Las técnicas atacan distintos problemas
• Lo mejor es combinar varias de estas técnicas para complementar las ventajas de c/u

Prueba de caja blanca

• Prueba estructural
• Prueba lo que el software hace
• Se basa en cómo está estructurado el componente internamente y su definición
• Usada para incrementar el grado de cobertura de la lógica interna del componente

Grado de cobertura

• Cobertura de sentencias: Prueba c/instrucción

• Cobertura de decisiones: Prueba c/salida de un “IF” o “WHILE”
• Cobertura de condiciones: prueba cada expresión lógica (A AND B) de los IF, WHILE
• Prueba de camino básico: prueba todos los caminos independientes

Complejidad ciclomatica

Métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un
programa. Se mide a partir de la cantidad de caminos independientes

V(g) = A - N + 2 (A = aristas, N = nodos)

Pruebas de caja gris

Prueba que combina elementos de la caja negra y caja blanca. El conocimiento del sistema es
“parcial”, no “total”

Las pruebas de caja gris prueban el SW como si fuera caja negra, pero suman condiciones y
casos adicionales derivados del conocimiento de la operación e interacción de ciertos
componentes de SW que componen la solución

Tipos de pruebas

Prueba unitaria

• Se realiza sobre una unidad de código claramente definida

• Generalmente lo realiza el área que construyó el módulo
• Los módulos altamente cohesivos son los más sencillos de probar

Prueba de integración

Orientada a verificar que las partes de un sistema que funcionan bien aisladamente también lo
hacen en su conjunto.
Prueba de aceptación de usuario

• Prueba realizada por los usuarios para verificar que el sistema se ajusta a sus
requerimientos
• Las condiciones de pruebas están basadas en el documento de requerimientos
• Es una prueba de “caja negra”

Pruebas no funcionales

Las pruebas no funcionales buscan comprobar la satisfacción de los requerimientos no

funcionales del SW. Se clasifican de acuerdo al req. no funcional bajo testeo:

• Volumen: orientada a verificar a que el sistema soporta los volúmenes máximos

definidos en la cuantificación de reqs:
o Capacidad de almacenamiento
o Capacidad de procesamiento
o Capacidad de transmisión
• Perfomance: Se evalúa la capacidad de respuesta con diferentes volúmenes de carga.
Se realizan de la mano de las de “volumen”
• Stress:
o Orientada a someter al sistema excediendo los límites de su capacidad
definidos en la cuantificación de reqs. Se suele buscar el punto de ruptura en
cuanto a: capacidad de almacenamiento, capacidad de procesamiento,
capacidad de transmisión.
o Se suele buscar el punto de ruptura
o Busca ver el comportamiento en términos de: Estabilidad, Disponibilidad y
Manejo de Errores
• Seguridad: orientada a probar los atributos/requerimientos de seguridad del sistema
(si puede ser vulnerado, si el control de acceso es adecuado, etc...). Por ejemplo:
penetration test.
• Usabilidad: Las pruebas de usabilidad persiguen
o ¿Cuáles son los principales problemas que evitan que el usuario complete su
objetivo?
o ¿Cómo la gente usa o usaría el producto para un fin determinado?
o ¿Qué elementos o aspectos hacen sentir frustrado al usuario?
o ¿Cuáles son los errores más frecuentes?
o Se suele medir:
▪ Éxito en la tarea
▪ Tiempo en la tarea
▪ Errores en la tarea
▪ Satisfacción “subjetiva”

Pruebas de regresión

Orientada a verificar que, luego de introducido un cambio en el código, la funcionalidad

original no ha sido alterada y se obtengan comportamientos no deseados o fallas en módulos
no modificados. Hay que probar “lo viejo”
Prueba de humo

Orientada a verificar de una manera muy rápida que en la funcionalidad del sistema no hay
ninguna falla que interrumpa el funcionamiento básico del mismo. El test es de muy alto nivel
(solo las funcionalidades mas importantes), no se entra “en detalles”.

Pruebas alfa y beta

Se entrega una primera versión al usuario que se considera está lista para ser probada por
ellos. Normalmente hay muchos defectos y es una buena forma de abaratar costos

• ALFA: la hace el usuario en mis instalaciones (en un entorno controlado y suele estar el
developer)
• BETA: la hace el usuario en sus instalaciones. El entorno no es controlado por el
desarrollador

V-model

Es un modelo que nos orienta en como testear en

cada etapa

Exploratory Testing

• Es “unscripted”: el tester va decidiendo tácticamente qué es lo mejor en c/paso de

acuerdo al conocimiento que va adquiriendo de la ejecución de un test
• “Unscripted” no significa “sin preparación”. Apunta a tener mas variantes y no tener
restricciones del “script driven”

Script Driven Testing & Unscripted Testing

• Script driven: se confeccionan las condiciones & casos tempranamente para luego ser
ejecutados
• Unscripted: se confeccionan las condiciones & casos a medida que se aprende de las
distintas ejecuciones, refocalizando las pruebas si fuera necesario (obteniendo ventajas
de lo aprendido).

Script driven testing

• Ventajas
o Puede ser reusado para una nueva ejecución fácilmente
o Es mas fácil de medir los resultados (# de condiciones, # de casos)
• Desventajas
o Laborioso
o No podes reprogramar sobre la marcha si encontras algo que es interesante
testear
Unscripted testing

• Ventajas
o Se pueden variar los test sobre la marcha de acuerdo a lo que se considere mas
apropiado
o Permite mayor cobertura de situaciones sobre posibilidades difíciles de
anticipar
• Desventajas
o Altamente dependiente de quien lo lleva a cabo

Cuando utilizar ET

• Se necesita conocer el producto rápidamente

• Se demanda feedback en poco tiempo
• Se ejecutó “scripted testing” y se quiere diversificar la prueba
• Se pretende chequear el testing realizado por un tercero a través de una breve prueba
independiente
• Hay que atacar un riesgo en particular
• Hay que buscar un bug puntual previamente reportado

Hay numerosos y variados aspectos en c/proyecto que influyen a la hora de testear

(presupuestos, skill de los testers, tecnologías, etc), cada una de las consideraciones influyen a
la hora de seleccionar cómo testear

Conclusión

• ET es una forma de encarar el testing

• ET es dependiente de los Skill / Experiencia / “Personalidad” del tester
• ET es dependiente del conocimiento que se va obteniendo a medida que se ejecuta la
prueba
• No se trata de “script based testing” vs “unscripted based testing”: debe evaluarse la
conveniencia en c/situación

Metricas de testing

• Productividad Diseño
o Ej.: Condiciones Construídas x Unid. Tiempo
• Productividad Ejecución
o Ej.: Casos Ejecutados x Unid. Tiempo
• Eficacia (Pre-Release):
o Ej.: ( Incidentes Reportados Aceptados / Total Incidentes Reportados x 100 )
o Es interesante medir también la eficacia en la resolución de defectos
• Eficacia (Post-Release):
o Ej.: [ Fallas Reportadas / (Fallas Reportados + Fallas Rep. User ]x 100
• “Calidad” del Desarrollo:
o Ej.: Indice de Severidad por Defectos Reportados
• Release Readiness:
o Ej.: Indice de Severidad por Defectos Abiertos
Testing automation

• Las pruebas automáticas tienen que ser un complemento de las manuales: no busca
reemplazar manual testing ni testers
• Automatizar es un trabajo aparte (hay que invertir tiempo y esfuerzo)
• En ciertos proyectos la automatización es necesaria debido a su
magnitud/complejidad. Resulta mas eficiente automatizar los tests

Ventajas/Desventajas

• Ventajas
o Gran cobertura (pruebas de regresión)
o Bajo costo de ejecución
o Independencia del Tester
o Consistencia: si falla, falla siempre
o Reuso
o Rapidez
• Desventajas
o Costo de desarrollo & mantenimiento
o En particular el costo de Test GUI
o Skill de developers
o Las fallas pueden deberse a la automatización

Herramientas de testing

¿Qué automatizar? Conclusiones

• No pretender automatizar todo

• Independizarse lo más posible de una
herramienta en particular
• Separar el equipo de automatización
del equipo de ejecución
• Automatizar es un proyecto mas y su
entregable es una aplicación mas: y como
toda aplicación debe cumplir con ciertos
estándares de calidad