Calidad y

metodologías ágiles
 Información general de la materia
Introducción:
Reny Evert Pech Ortega

Herramienta de trabajo:
Teams → Avance programático, Portafolio de evidencias, Materiales de clase (presentación y otros
artefactos), Tareas, etc.

Forma de trabajo:
● Clases en general (presentación y lectura).
● Apuntes en clase.
● Evaluaciones (prácticas).
● Tareas asignadas.
● Horas límite para las tareas.
● Manejo de portafolio de evidencias (parciales y nombres).
● Contacto por Teams (prudentes).
● Separación del temario en 2 (calidad y agilidad).
● * Presentar el Teams para mostrar el avance
 Información general de la materia
Asistencias y faltas:
● Todas las clases se pasa lista sin falta.
● Tolerancia previo a la clase.
● 2 faltas por la cantidad de clases.

Fechas importantes:
● Primer parcial: 30 de septiembre y 02 de octubre
● Segundo parcial: 11 de noviembre
● Ordinario/Proyecto: 04 de diciembre
● Expotrónica: 11 de diciembre
● Días inhábiles: 16 de septiembre y 18 de noviembre (que nos afectan)

Ordinario:
Posible premio de acuerdo al comportamiento en el semestre.
Control de calidad y
Pruebas de software
Aplicando la calidad al producto
 Índice de contenido
01 02
Pruebas de software Ciclo de vida
Conceptos básicos, beneficios y Proceso de las pruebas de software
objetivos

03 04
Estrategia pruebas Categorías y tipos de prueba
Niveles de pruebas de software Algunas de las pruebas aplicadas en
software
 01
Pruebas de
software
Conceptos básicos, beneficios y objetivos
Pruebas de software
Método para comprobar si el producto de software real coincide con
los requisitos esperados y para garantizar que esté libre de defectos.

Verificación: “¿Construimos el producto correctamente?”

Validación: “¿Construimos el producto correcto?”

Se ejecutan componentes de software utilizando herramientas

manuales o automatizadas para evaluar uno o más componentes.
 ¿Por qué son importantes las pruebas?
Un producto de software debidamente probado garantiza confiabilidad, seguridad y alto rendimiento

Ejemplos reales de la importancia de las pruebas

Nissan Starbucks China Airlines

● Retiraron del mercado ● Se vieron obligados a ● El Airbus A300 se estrelló
más de 1 millón de cerrar alrededor del 60 debido a un error de
automóviles debido a por ciento de las tiendas software el 26 de abril de
una falla del software en en Estados Unidos y 1994.
los detectores sensoriales Canadá debido a una
de las bolsas de aire. falla de software en su
sistema.
Beneficios de las pruebas de software
Rentable Seguridad
Probar cualquier proyecto La gente busca productos
de TI a tiempo ayuda a confiables. Ayuda a
ahorrar dinero a largo eliminar riesgos y
plazo problemas antes de
afectar al usuario final.

Calidad del producto Satisfacción de cliente

Las pruebas garantizan El principal objetivo de
que se entregue un cualquier producto es dar
producto de calidad a los satisfacción a sus clientes.
clientes Pruebas UI/UX pueden
servir.
Diferencias entre error, defecto y falla
Error
Equivocación de origen Falso positivo
humano Pruebas reportadas como
fallidas, con defectos que en
realidad no lo son
Defecto (bug)
En el código o la
documentación
Falso negativo
Son pruebas que no
Falla detectan defectos que se
Resultado de ejecutar deberían haber detectado.
un código defectuoso
 Siete principios de pruebas
Las pruebas muestran la Las pruebas exhaustivas
presencia de defectos, no 1 2 son imposibles
su ausencia

Las pruebas tempranas

ahorran tiempo y dinero 3 4 Los defectos se agrupan

Paradoja del pesticida Las pruebas dependen

5 6 del contexto

7 La ausencia de errores es
una falacia
 Primer principio
Las pruebas muestran la presencia de defectos, no su ausencia

Es decir, las pruebas de software reducen la probabilidad de que queden defectos no

descubiertos en el software, pero no encontrar defectos, no es un indicio de que este esté libre
de ellos.
 Segundo principio
Las pruebas exhaustivas son imposibles

Pruebas exhaustivas = Un enfoque de prueba en el que el juego/set/script de pruebas

comprende todas las combinaciones de valores de entrada y condiciones previas.

Necesitamos la cantidad óptima de pruebas basadas en la evaluación de riesgos de la

aplicación.

¿Cómo se determina este riesgo?

¿Qué operación es más probable que provoque que el sistema falle?
 Tercer principio
Las pruebas tempranas ahorran tiempo y dinero

Numerosos defectos se introducen muy temprano.

Las pruebas deben comenzar lo antes posible en el ciclo de vida del desarrollo de software. Es
mucho más económico corregir un defecto en las primeras etapas del proyecto.
 Cuarto principio
Los defectos se agrupan

Una pequeña cantidad de módulos contienen la mayoría de los defectos detectados.

Principio de Pareto a las pruebas de software: aproximadamente el 80% de los defectos se

encuentran en el 20% de los módulos.
 Quinto principio
Paradoja del pesticida

Si se realiza el mismo conjunto de pruebas repetitivas, el método será inútil para descubrir
nuevos defectos.

Los casos de prueba deben revisarse y ajustarse periódicamente, agregando casos de prueba
nuevos y diferentes para ayudar a encontrar más defectos
 Sexto principio
Las pruebas dependen del contexto
Es necesario tener en cuenta los contextos antes de decidir qué enfoque de prueba aplicar.

● Contexto “empresarial” de uso del software.

● Contexto(s) de operación del software.
● Antecedentes del proyecto.
 Séptimo principio
La ausencia de errores es una falacia

La ausencia de errores no refleja la calidad del software.

Es posible que un software que esté 99% libre de errores todavía no se pueda utilizar. Este
puede ser el caso si el sistema se prueba minuciosamente para detectar el requisito incorrecto.
 02
Ciclo de
vida
Proceso de las pruebas de software
 Ciclo de vida de las pruebas
Análisis

Planificación

Desarrollo

Configuración

Ejecución

Cierre
 Análisis de requisitos
El equipo estudia o examina los requisitos desde un punto de vista de pruebas para identificar
posibles pruebas y también para comprender a detalle todos los requisitos.

¿Requisitos funcionales o no funcionales?

¿Podemos automatizar?

Ejemplo de requerimiento: Como encargado de inventario, necesito realizar un seguimiento

preciso del stock de productos en el almacén para garantizar que siempre haya suficiente
inventario disponible y para satisfacer la demanda de los clientes
Análisis de requisitos (actividades y entregables)
Algunas de las actividades de esta fase pueden ser:

● Identificar los tipos de pruebas a realizar.

● Recopilar detalles sobre las prioridades y el enfoque de las pruebas.
● Preparar Matriz de Trazabilidad de Requisitos (RTM).
● Identificar los detalles del entorno de prueba donde se supone que se llevarán a cabo las
pruebas.
● Análisis de viabilidad de automatización (si es necesario).

Salidas:
● Matriz de trazabilidad de requisitos
● Informe de viabilidad de automatización (si es aplicable)
 Planificación de pruebas
El líder de control de calidad determina la estrategia del plan de pruebas junto con los esfuerzos
y las estimaciones de costos.

Se determinan los recursos, el entorno de prueba, las limitaciones de la prueba y el calendario

de pruebas.

El Plan de Prueba se prepara y finaliza en la misma fase.

Planificación de pruebas (actividades y entregables)
Algunas de las actividades de esta fase pueden ser:

● Elaboración de un plan de pruebas o documento de estrategia para varios tipos de

pruebas.
● Selección de herramientas de prueba.
● Estimación del esfuerzo de prueba.
● Planificación de recursos, roles y sus responsabilidades.
● Plan de entrenamiento

Salidas:
● Plan de pruebas o documento de estrategia
● Estimación de esfuerzo
 Desarrollo de casos de prueba
Implica la creación, verificación y reelaboración de casos de prueba y scripts de prueba una vez
que el plan de prueba esté listo.

Los datos de prueba se identifican, luego se crean, revisan y luego se reelaboran en función de
las condiciones previas.

El equipo de control de calidad inicia el proceso de desarrollo de casos de prueba para

unidades individuales
Desarrollo de casos de prueba (actividades y
entregables)
Algunas de las actividades de esta fase pueden ser:

● Crear casos de prueba, scripts de automatización (si corresponde)

● Revisión y casos de prueba y scripts de referencia.
● Crear datos de prueba (si el entorno de prueba está disponible)

Salidas:
● Casos de prueba/script de pruebas
● Datos de prueba
 Configuración del entorno de pruebas
Condiciones de software y hardware bajo las cuales se prueba un producto de trabajo. Se puede
realizar en paralelo con la fase de desarrollo del caso de prueba.

Es posible que el equipo de prueba no participe en esta actividad si el equipo de desarrollo

proporciona el entorno de prueba
 Configuración del entorno de pruebas
(actividades y entregables)
Algunas de las actividades de esta fase pueden ser:

● Comprender la arquitectura requerida, la configuración del entorno y preparar la lista de

requisitos de hardware y software para el entorno de prueba.
● Configuración del entorno de prueba y datos de prueba
● Realizar prueba de humo en la construcción.

Salidas:
● Entorno listo con datos de prueba configurados
● Resultados de la prueba de humo.
 Ejecución de pruebas
Se realiza la prueba del software en función de los planes de prueba y los casos de prueba
preparados.

Se ejecuta el script de pruebas, el mantenimiento del script de pruebas y el informe de errores.

En caso de existir fallos, se informa al equipo de desarrollo para su corrección y se realizan

nuevas pruebas.
 Ejecución de pruebas (actividades y entregables)
Algunas de las actividades de esta fase pueden ser:

● Ejecutar pruebas según el plan.

● Documentar los resultados de las pruebas y registrar los defectos de los casos fallidos.
● Asignar defectos a casos de prueba en RTM
● Vuelva a probar las correcciones de defectos
● Seguimiento de los defectos hasta el cierre.

Salidas:
● RTM completado con el estado de ejecución.
● Casos de prueba actualizados con resultados.
● Informes de defectos
 Cierre del ciclo de pruebas
Implican varias actividades como informes de finalización de la prueba, recopilación de
matrices de finalización de la prueba y resultados de la prueba.

Los miembros del equipo de pruebas se reúnen, discuten y analizan los artefactos de prueba
para identificar estrategias que deben implementarse en el futuro, tomando lecciones del ciclo
de pruebas actual.
 Cierre del ciclo de pruebas
Algunas de las actividades de esta fase pueden ser:

● Evaluar los criterios de finalización del ciclo en función del tiempo, la cobertura de la
prueba, el costo, el software, los objetivos comerciales críticos y la calidad.
● Métricas de prueba basadas en los parámetros anteriores.
● Documentar el aprendizaje del proyecto.
● Elaborar informe de cierre de prueba.
● Informes cualitativos y cuantitativos de la calidad del producto del trabajo al cliente.
● Análisis de resultados de pruebas para conocer la distribución de defectos por tipo y
gravedad.

Salidas:
● Informe de cierre de prueba
● Métricas de prueba
 Estrategia
03 pruebas
Niveles de las pruebas de software
 Estrategia/niveles de pruebas

(UAT) Aceptar el sistema

de software antes de
Ayuda a saber si la
mover la aplicación al
unidad individual
del código funciona
Componentes entorno de producción
correctamente

Aceptación

Se comprueba que El software se

las unidades compila y se prueba
integradas
Integración Sistema en su totalidad
funcionan
 Pruebas de componentes (I)
Se enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software:
función, método, procedimiento, módulo u objeto individual.

Estas pruebas se enfocan en la lógica de procesamiento interno y de las estructuras de datos

dentro de la frontera de un componente y se usan para garantizar que la información fluya de
manera adecuada hacia y desde la unidad de software que se está probando.

Se pueden realizar en paralelo para múltiples componentes.

 Pruebas de componentes (II)
1. Prueba del flujo de datos a través de la interfaz: Antes de realizar cualquier otra prueba, se
verifica que los datos puedan entrar y salir de un componente de manera adecuada.

2. Evaluación de las estructuras de datos locales: Examinar las estructuras de datos utilizadas
dentro del componente y comprender cómo afectan a los datos globales del sistema. Ej:
variables locales, matrices, listas, colas, pilas o cualquier otra estructura.

3. Prueba selectiva de las rutas de ejecución: Es necesario diseñar casos de prueba que se
centren en descubrir errores relacionados con cálculos incorrectos, comparaciones
inadecuadas o problemas en el flujo de control del programa.

4. Pruebas de frontera: Pruebas críticas que se centran en verificar el comportamiento del

software en los límites de sus operaciones. Ej: Mínimo permitido, máximo permitido, límites
de iteración, valores extremos o excepcionales.

5. Manejo de errores: Un buen diseño de software debe anticipar las condiciones de error y
definir cómo se manejan estos errores de manera adecuada.
 Pruebas de componentes (III)
Estas pruebas también deben consideran 2 elementos:

Drivers (controlador): parte del código de prueba que simula la

interacción y llama al software bajo prueba con componentes externos
o dependencias.

Stub (representante): son componentes mínimos que proporcionan

respuestas predefinidas a las llamadas de funciones o métodos que el
software bajo prueba haría a la dependencia real.

Stub (representante)
Function IdentCategoria(calidad, cantidad)
Software bajo pruebas (SUT) {
Function ContProducto(calidad, cantidad) Driver (controlador)
……… Function PruebaUnidad ( )
{ const inventario = {
……… {
"Malo": 100, ………
const resultado = IdentCategoria(calidad, cantidad); "Bueno": 200, const TotalProducto = ContProducto( );
}; }
return resultado;
} return inventario;
}
 Actividad 1
En equipos:

● Investigar cómo se realizan las pruebas de

componentes/unitarias (videos, documentos, etc).
● Realizar y ejecutar las pruebas en un proyecto que ya
tengan o, de lo contrario, de alguna función nueva
que quieran hacer (ej. Sumar dos números).
● Para entregarlo, deberán tomar captura de pantalla
de los resultados de las pruebas y del archivo donde
programaron sus pruebas de componente.

Nota: Pueden utilizar cualquier lenguaje de programación

para realizar esta actividad.
 Pruebas de integración (I)
Técnica sistemática para construir la arquitectura del software mientras se llevan a cabo
pruebas para descubrir errores asociados con la interfaz.

El objetivo es tomar los componentes probados de manera individual y construir una estructura
de programa que se haya dictado por diseño.

¡Realiza pruebas integrales incrementalmente y no con todos los componentes!

Integración: Sistemas Integración: Componentes

 Pruebas de integración (II)
Integración descendente (top-down) Integración ascendente (bottom-up)

1. El módulo del driver principal se usa como un driver 1. Los componentes en el nivel inferior se combinan en
de prueba y los stubs se sustituyen con todos los grupos (en ocasiones llamados construcciones o
componentes directamente subordinados al módulo builds) que realizan una subfunción de software
del driver principal. específica.
2. Los stubs subordinados se sustituyen uno a la vez 2. Se escribe un controlador (un programa de control
con componentes reales. para pruebas) a fin de coordinar la entrada y salida
3. Las pruebas se llevan a cabo conforme se integra de casos de prueba.
cada componente. 3. Se prueba el grupo.
4. Al completar cada conjunto de pruebas, otro stub se 4. Los controladores se eliminan y los grupos se
sustituye con el componente real. combinan moviéndolos hacia arriba en la estructura
5. Se realizan pruebas de regresión. del programa.
 Pruebas de sistema
Serie de diferentes pruebas cuyo propósito principal es ejercitar por completo el sistema
basado en computadora.

Aunque cada prueba tenga un propósito diferente, todo él funciona para verificar que los
elementos del sistema se hayan integrado de manera adecuada y que se realicen las funciones
asignadas.

Algunos tipos de pruebas que valen la pena para sistemas de software:

- Pruebas de recuperación
- Pruebas de seguridad
- Pruebas de rendimiento
- Pruebas de despliegue
 Pruebas de aceptación (I)
Conjunto de pruebas realizadas para verificar si un sistema de software satisface los criterios de
aceptación definidos por los stakeholders.

Estas pruebas se llevan a cabo en un entorno que simula condiciones de uso reales, y su
objetivo es confirmar que el software es funcional, cumple con los requisitos del usuario y es
adecuado para su despliegue en producción.

¡Los usuarios finales validan y aceptan el software!

 Pruebas de aceptación (II)
Normalmente se realizan pruebas alfa y beta para estas pruebas.

● Pruebas alfa: se lleva a cabo en el sitio del desarrollador por un grupo representativo de
usuarios finales. El software se usa en un escenario natural con el desarrollador “mirando
sobre el hombro” de los usuarios y registrando los errores y problemas de uso. Las
pruebas alfa se realizan en un ambiente controlado.

● Pruebas beta: se realiza en uno o más sitios del usuario final y por lo general el
desarrollador no está presente. es una aplicación “en vivo” del software en un ambiente
que no puede controlar el desarrollador.
Pruebas de aceptación (III)
 04
Categorías y
tipos de prueba
Algunas de las pruebas aplicadas en software
 Pruebas estáticas y dinámicas
Pruebas que se encuentran en una capa por encima de los
tipos de prueba.

Testing

Dynamic
Static Testing
Testing

Functional Non-Functional Etc. Reviews

 Comparativa en categorías

Pruebas estáticas Pruebas dinámicas

La prueba se realiza sin ejecutar el programa, La prueba se realiza ejecutando el programa.
por lo que no requieren compilar nada. Es necesario compilar la aplicación o sistema.

Las pruebas estáticas tratan de la prevención Las pruebas dinámicas consisten en

de defectos. encontrar y corregir los defectos.

Las pruebas dinámicas generan

Las pruebas estáticas brindan una evaluación
errores/cuellos de botella en el sistema de
del código y la documentación.
software.

Las pruebas estáticas implican una lista de Las pruebas dinámicas implican casos de
verificación y un proceso a seguir. prueba para su ejecución.
 Comparativa en categorías

Pruebas estáticas Pruebas dinámicas

El costo de encontrar defectos y repararlos es El costo de encontrar y reparar defectos es
menor. alto.

El ROI alto porque se realiza en una etapa El ROI bajo porque se implica después de la
temprana. fase de desarrollo.

Comparativamente requiere menos

Requiere muchas reuniones**
reuniones
¿Qué pruebas
estáticas se les
ocurren?
 Técnicas de prueba estática

Revisiones Revisiones
Tutorial Inspección
informales técnicas
No sigue ningún Los pares revisan El autor del producto El objetivo principal
proceso para principalmente las explica el producto a es encontrar defectos
encontrar errores en especificaciones su equipo. Los y la reunión está
el documento. Solo técnicas del producto participantes pueden dirigida por un
revisa el documento y de software y hacer preguntas (si moderador
hace comentarios comprueban si es las hubiera). Una capacitado. En esta
informales sobre él. adecuado para el reunión es dirigida revisión se sigue un
proyecto. Intentan por el autor y el proceso estricto para
encontrar
escriba toma nota de encontrar defectos
discrepancias en las
los comentarios de la usando una lista de
especificaciones y
revisión. verificación para
estándares seguidos.
Plan de pruebas, ERS,
revisar los productos
código, etc. del trabajo.
 Ejemplo de una prueba estática

Revisión de código estático

Es una plataforma basada en la nube que
ofrece análisis de calidad de código para
Esta es una revisión del código fuente del proyectos de software. Es una solución que
software sin ejecutar el código. Comprueba la permite a los equipos de desarrollo medir,
sintaxis del código, los estándares de gestionar y mejorar la calidad de su código
codificación, la optimización del código, etc. fuente de manera continua. Analiza
Esto también se denomina prueba de caja automáticamente el código y proporciona
blanca. Esta revisión se puede realizar en información detallada sobre aspectos clave
cualquier momento durante el desarrollo. como la seguridad, la mantenibilidad, la
cobertura de pruebas, y la adherencia a las
reglas de codificación.
 Actividad 2
En equipos y de un proyecto desarrollado (actual o previo) deberán hacer lo siguiente:

1. Instalar y configurar la herramienta SonarCloud para que realice el análisis del código
que hayan generado.
2. Correr el Sonar en su proyecto en la rama/archivo seleccionado.
3. Tomar fotos de los resultados que obtuvieron; es decir, tomar una foto de los errores que
encontró la herramienta y una foto al fragmento de código afectado. Si es más de un
error, tomar 3 errores como mínimo. Si no encuentran errores, tomar otro proyecto,
archivo o rama según corresponda.
4. Corregir los errores identificados.
5. Correr nuevamente la herramienta.
6. Tomar evidencia de la resolución de los bugs identificados.
 Actividad 3
Con los mismos equipos que en la actividad anterior:

1. Deberán compartir un archivo de código de un proyecto ya trabajado con otro equipo, que
será asignado por el profesor.
2. El equipo receptor del código deberá utilizar el checklist proporcionado por el profesor
para identificar posibles defectos en el código.
3. Deberán llenar el checklist y dejar los comentarios, de los errores identificados, en el mismo
documento.
4. Al finalizar la revisión, deberán entregar el checklist completo, incluyendo comentarios y
sugerencias al equipo original y deberán subirlo al Teams.

Notas:
● No es necesario corregir los defectos identificados.
● Es importante agregar sugerencias adicionales más allá de los puntos específicos del
checklist.
 Tipos de prueba (dinámicas)
Grupo de actividades destinadas a probar un componente o sistema enfocado en un objetivo
de prueba específico; es decir, por ejemplo:
● Pruebas funcionales: se centran en evaluar si el software cumple con los requisitos
funcionales.
● Pruebas no funcionales: se centran en evaluar atributos de calidad que no están
directamente relacionados con las funciones específicas de la aplicación.
● Pruebas estructurales: evaluar el código relacionadas con la aplicación.
● Pruebas relacionadas con cambios: se realizan cuando se implementan cambios en el
software, ya sea nuevas características, correcciones de errores o actualizaciones.

Un tipo de prueba puede tener lugar en uno o más niveles de prueba

o fases de prueba
 Tipos de prueba (dinámicas)
CATEGORÍA DE PRUEBA TIPOS DE PRUEBA

● Unitarias
● Pruebas integrales
Pruebas funcionales ● Smoke/humo
● Localización
● Funcionalidad

● Carga
● Estrés
● Escalabilidad
Pruebas no funcionales
● Resistencia
● Usabilidad
● Seguridad

● Cobertura de código
Pruebas Estructurales
● Flujo de datos

● Regresión
Relacionados con cambios
● Migración
Matriz de pruebas y pruebas funcionales
Reporte de un defecto
 Actividad 4
De manera individual:

● Realizar los casos de prueba de la Historia de usuario que el maestro les

asignó aleatoriamente.

● Deberán utilizar la misma plantilla o formato visto en clase.

● Deberán llenar SOLO las celdas de las columnas de la A - E, todas las demás
columnas NO deberán llenarse.

● No existen un máximo de pruebas, solo consideren la mayor cantidad de

escenarios que se puedan probar.
 Actividad 5
En equipos:

● Investigar qué es un Plan de pruebas.

● Investigar y descargar plantillas/artefactos de un Plan de
pruebas.
● De acuerdo a lo solicitado en cada sección, llenar la
información utilizando algún proyecto propio (actual o
anterior) o cualquier otro sistema/app que gusten.

Nota:
● Lo que se entregará será el documento Plan de pruebas
llenado.
 Actividad 6
Individualmente:

● Realizar la instalación del Cypress siguiendo la guía que se muestra en su

página: Seamless Cypress Installation Guide
● Consideren que la configuración utiliza, en ciertas partes, Node Js, por lo
que es importante que también realicen la instalación correspondiente si
es que no cuentan con ella.
● Deberán seguir todos los pasos allí mencionados hasta llegar a la parte que
indica el siguiente enlace: Open the App with Cypress: Step-by-Step Guide

Nota:
● El entregable será la foto donde se muestre que ya pueden abrir el Cypress
(como se muestra en el último enlace).
 Pruebas manuales
Las pruebas manuales son aquellas donde el tester ejecuta casos de prueba
manualmente, sin la ayuda de herramientas automatizadas, y valida si el software
cumple con las expectativas.

Ventajas y características:
● Ideal para pruebas que requieren observación humana directa.
● Útil en casos donde la interfaz cambia frecuentemente.
● Útil para pruebas de usabilidad, exploratorias o interfaces gráficas (UI).
● Flexibilidad para realizar pruebas ad-hoc.

Desventajas:
● Proceso lento y propenso a errores humanos.
● Menos eficiente en la repetición de pruebas.
● Dificultad para escalar en proyectos grandes o complejos.
 Pruebas automatizadas
Las pruebas automatizadas utilizan herramientas y scripts para ejecutar
automáticamente los casos de prueba. Estas pruebas son programadas para
ejecutarse de manera repetida sin intervención manual.

Características:
● Uso de scripts o herramientas de software
● Se pueden ejecutar múltiples veces con diferentes entradas de datos.

Ventajas:
● Ahorro de tiempo en pruebas repetitivas.
● Mayor cobertura y precisión en la ejecución.
● Escalabilidad para proyectos grandes.
● Consistencia: las pruebas se ejecutan de la misma manera cada vez.
 Pruebas automatizadas
Desventajas:

● Costo inicial alto en tiempo y recursos para desarrollar los scripts.

● No siempre es útil para pruebas de usabilidad o experiencia de usuario.
● Mantenimiento constante, especialmente cuando hay cambios en el software.

Usarlo cuando:
● Hay regresión frecuente en el código.
● Para proyectos con ciclo de vida largo o entornos estables.
● En pruebas de rendimiento, carga o estrés.
 Comparativa Manuales vs Automatizadas
Pruebas
Criterio Pruebas Manuales
Automatizadas
Tiempo de ejecución Lento Rápido

Costo inicial Bajo Alto

Repetibilidad Baja Alta

Cobertura Limitada Amplia

Interacción humana Requiere intervención directa Ejecución automática

Flexibilidad Alta (pruebas exploratorias) Limitada a lo programado

 Herramientas para automatización
Selenium Playwright Cypress Appium

Herramienta Herramienta para Herramienta enfocada Herramienta open-source

open-source que pruebas web, en la automatización para aplicaciones móviles
desarrollada por de pruebas de (Android e iOS). Permite
Soporta múltiples
Microsoft. Soporta front-end para escribir pruebas usando
navegadores diferentes lenguajes de
(Chrome, Firefox, múltiples navegadores aplicaciones web. Está
programación y no
Edge, etc.) y lenguajes y es compatible con optimizada para requiere modificar el
de programación JavaScript/TypeScript. trabajar con JavaScript código fuente de la
(Java, Python, C#, Se destaca por su y tiene una integración aplicación. Soporta tanto
capacidad de pruebas fluida con el desarrollo aplicaciones nativas
etc.)
en navegadores sin ágil y las pruebas como híbridas y web.
cabeza continuas.
Ejemplo pruebas automatizadas
 Actividad 7
Individualmente:

● De la página vista en clase como ejemplo para las automatizaciones,

deberán automatizar el registro de un nuevo usuario.
● Deberán agregar toda la información necesaria, guardarla y la tarea se
considerará correcta cuando el Assertion/Should identifique que el toast
diga: “Successfully Saved” (como se muestra en la imagen de ejemplo)

Nota:
● La información que agreguen para el registro es indiferente, siempre y
cuando logren el registro del usuario.
● Pueden ayudarse de la documentación de Cypress o cualquier otro foro o
herramienta para realizar la tarea.
Fin del primer parcial
Metodologías Ágiles y
modelos de calidad
Aplicando la calidad al proceso
 01
Calidad del
software
Concepto, procesos, beneficios y objetivos
 Calidad del software
Entendemos entonces que en términos generales la calidad se refiere a:
Propiedades y características de un producto o servicio para satisfacer
necesidades explícitas o implícitas.

La calidad de software se estructura en dos grandes ramas:

● QC = Quality Control = Encargado de realizar actividades de
verificación en el producto desarrollado.
● QA = Quality Assurance = Encargado de revisar que las actividades
realizadas para el desarrollo del producto sean las correctas y
adecuadas.

Muchas veces se confunden ambos términos y creemos que son el mismo

rol; sin embargo, su enfoque de trabajo es diferente.
 Aseguramiento de la calidad

Además de haber realizado unas pruebas adecuadas para corroborar que todo funciona
correctamente, es importante que los procesos de todo el ciclo de vida de ese producto se haya
seguido de la manera adecuada.

¿Qué es un proceso?

Es un conjunto de actividades coordinadas que combina e implementa recursos y capacidades para

producir un resultado, el cual, directa o indirectamente, crea valor para un cliente o parte involucrada.

Entonces, podemos inferir que el QA es el encargado de gestionar procesos y asegurar su

uso/cumplimiento.
 Estructura de un proceso
Todo proceso debe contener el siguiente mínimo indispensable para su uso:

● Título: Nombre que recibe el proceso

● Entradas: Elementos de insumo de un sistema y pueden ser tanto elementos
físicos (materia prima, documentos), como elementos humanos (personal) o
técnicos (información). Pueden agregarse entradas generales en el proceso o
individuales por cada una de las actividades.
● Actividades: Operaciones o pasos realizados por un rol definido en el proceso.
● Salidas: Son los resultados que se obtienen de procesar las entradas que, al igual
que estas, pueden ser adoptadas en forma de productos, servicios o información.
Estas salidas también pueden ser generales en el proceso o individuales por cada
una de las actividades.
 Estructura de un proceso
Ejemplo:
Título: Revisión y Aprobación de Documentos

1. Recepción del documento

Entrada: Documento creado
Actividades: El Asistente administrativo revisa que el documento esté completo y
cumpla con el formato requerido.
Salidas: Documento listo para revisión.

2. Revisión de contenido
Entrada: Documento listo para revisión
Actividades: El Revisor técnico revisa el contenido para asegurar calidad, coherencia y
precisión técnica
Salidas: Comentarios y anotaciones sobre el documento.
 Estructura de un proceso
Ejemplo:
Título: Revisión y Aprobación de Documentos

3. Revisión de comentarios y ajustes

Entrada: Comentarios y anotaciones
Actividades: El Autor del documento revisa los comentarios y realiza las correcciones
necesarias.
Salidas: Documento corregido.

4. Aprobación final
Entrada: Documento corregido
Actividades: El Gerente de proyecto revisa el documento final para confirmar que
todos los cambios y correcciones han sido implementados correctamente.
Salidas: Documento aprobado o rechazado (con observaciones finales).
Ejemplos de Procesos
Beneficios de los procesos
Consistencia Eficiencia
Se obtienen resultados Eliminan redundancia
predecibles y, por lo tanto, asegurando que los
se obtiene confianza en recursos se utilicen de
clientes y usuarios. manera óptima.

Calidad Control
Seguir un proceso Monitorear el progreso es
continuo hace que los más eficiente y sencillo y
errores sean menos todas las decisiones se
probables y maximiza la toman de manera
coherencia. informada.
¿Cuándo usamos procesos?
 Procesos Flexibles

Entonces … ¿los procesos pueden ser flexibles?

Sí, todo proceso debe tener cierta flexibilidad y estructura. Por ejemplo: El cepillarse
los dientes lo puedes hacer con cualquier tipo de cepillo, mientras realices la acción
definida.

Los procesos están en continua evolución y cambio, pero estos cambios también
deben de ser controlados ya que estas son una guía para evitar el caos.

Esta flexibilidad se maneja en las metodologías ágiles con un enfoque de mejora

continua de procesos.
 02
Ciclo de vida
de software
El ciclo completo para desarrollar un software
 Ciclo de vida de desarrollo de Software
Ciclo de vida de desarrollo de software (SDLC): Es una serie de procesos o fases que
un equipo de desarrollo utilizan para crear software de alta calidad de manera
eficiente y rentable.
Comúnmente se componen de las siguientes fases:

Análisis o
Planeación Diseño Implementación Pruebas
Requisitos

Despliegue Mantenimiento
 Fase: Planeación
Rol: Gestor del proyecto

Actividad: En esta fase se establecen y comunican los objetivos, logros y metas del proyecto alineadas
con las necesidades del cliente o negocio. También se define qué incluye y qué no incluye el proyecto,
así como la identificación de todos los stakeholders. Se desglosan las actividades en tareas pequeñas y
manejables con el estimado de recursos y tiempo, entre otros tipos de actividades de planeación.

Salida: Plan integral del proyecto

 Fase: Análisis
Rol: Analista

Actividad: Esta fase consiste en identificar el QUÉ o definir los requisitos del cliente a un nivel más
detallado mediante entrevistas o reuniones para, posteriormente, identificar los requisitos funcionales
y no funcionales. Se puede considerar realizar el modelado de requisitos (diagramas de casos de uso)
para representar cómo interactúan los usuarios con el sistema. Se identifican la criticidad de los
requisitos o su prioridad y por último se aseguran que los requisitos sean correctos, completos y
entendibles por todos los interesados.

Resultado: Documento de Especificación de requisitos de software (ERS)

 Fase: Diseño
Rol: Arquitecto

Actividad: Esta fase describe el CÓMO se implementarán los requisitos especificados en la ERS; es
decir, damos respuestas a lo analizado con el cliente y comúnmente cubre los siguientes aspectos:
Arquitectura de software, Diseño detallado, Diagrama de clases, secuencia y estado, Diseño de la
interfaz de usuario, Tecnologías y herramientas.

Resultado: Documento de Especificación de diseño de software (EDS) o Diseño Detallado del Software
(DDS).
 Fase: Implementación
Rol: Programador, implementador, desarrollador

Actividad: Fase en donde los responsables traducen el diseño a código. Este último debe seguir las
especificaciones y estructuras definidas en el DDS considerando la eficiencia y optimización en cuanto
al rendimiento, consumo de recursos y mantenimiento. La calidad del código debe cumplir con los
estándares definidos, debe ser legible, modular y reutilizable.

Salida: Código fuente, informe de las pruebas

 Fase: Pruebas
Rol: Ingeniero de pruebas

Actividad: De manera general, esta fase corrobora o verifica que lo definido en la fase de análisis se
vea reflejado en lo desarrollado en la fase anterior. Aquí se planean las pruebas, se diseñan los casos
de prueba, se ejecutan las pruebas, se registran y dan seguimiento a los defectos hasta su cierre y, si
aplica, se automatizan las pruebas.

Salida: Suite de pruebas, defectos/bugs, código corregido.

 Fase: Despliegue
Rol: Equipo de operaciones (todo el equipo).

Actividad: El equipo completo se prepara para transferir lo desarrollado al servidor del cliente; por lo
que debe existir una planeación del despliegue (cuándo y cómo se realizará), se configura el entorno
(servidores, base de datos, redes, etc), instalación y migración, validación en producción (realizar
pruebas en el entorno de producción) y entrenamiento de usuarios para el uso del sistema.

Salida: Software probado y en producción con su versión

 Fase: Mantenimiento
Rol: Ingenieros de soporte

Actividad: Los responsables realizan actividades de soporte, como asistencia a los usuarios finales
para resolver un problema o responder preguntas relacionadas con el uso del software. Estas
actividades de mantenimiento se pueden clasificar en: Mantenimiento correctivo (solución de errores
o fallos que no se detectaron previamente), adaptativo (ajustes del software para adaptarse a cambios
en el hardware, sistemas operativos, bases de datos), perfectivo (Mejoras en la funcionalidad o
rendimiento sin que haya errores presentes) o preventivo (acciones para prevenir problemas, como
refactorización del código o mejora de seguridad).

Salida: Registros de problemas resueltos, Nuevas versiones

 Actividad 8
En equipos:
● Realizar una investigación según la metodología que les haya tocado:
(Kanban, XP, Lean, Crystal o Devops).
● Deberán crear una presentación explicando las siguientes características:
○ Origen y contexto: Breve historia y cómo se originó
○ Enfoque, principios clave u objetivos de la metodología
○ Fases, procesos, ciclo de vida
○ Aplicación práctica en el desarrollo de software
○ Ventajas y desventajas, así como explicar cuándo utilizar la
metodología.
● Para las herramientas que les tocó, deberán explicar a, grandes rasgos, qué
características o funciones tiene y cómo utilizarían dicha herramienta para
llevar a cabo su metodología (caso práctico).
● Para Devops, deberán especificar qué herramientas son ideales para
utilizar.
 Metodologías
03 ágiles
Y su impacto con las metodologías tradicionales
 Ejercicio práctico
01. Nos separaremos en 2 equipos y se les entregarán fichas.

02. Deberán lanzar las fichas al aire hasta que salga cara

03. Una vez les salga cara deberán pasar las fichas a su compañero de al lado

04. Se les darán indicaciones adicionales a cada equipo

05. Mientras no lanzan las fichas, los demás integrantes del equipo deberán ver el comportamiento del
equipo contrario

06. Uno del equipo deberá vigilar que el equipo contrario cumpla con las reglas anteriormente
mencionadas

Consideraciones:
* No se pueden lanzar todas las fichas al mismo tiempo
* Para evitar hacer ruido, tratar de tomar las fichas en el aire.
¿Cuál es la principal diferencia que
encontraron entre los equipos?
 Resultados del ejercicio

¿Fichas? ¿Cara de la ficha? ¿Ficha en el aire?

Todas las actividades o Progreso de la tarea en días
Una actividad completada
tareas u horas

¿Personas? ¿Pasar fichas? ¿Fichas diferentes?

Las fases del ciclo de vida y las Metodologías ágiles y Metodologías ágiles y
personas responsables tradicionales tradicionales
 Metodología tradicional
La metodología tradicional en el desarrollo de software se refiere a enfoques lineales y estructurados
para la gestión de proyectos. Un ejemplo típico es el modelo de cascada (Waterfall), que se caracteriza
por dividir el proceso en fases secuenciales, donde cada etapa depende de la finalización de la
anterior.

Este enfoque suele seguir el ciclo de vida que hemos visto anteriormente: Requisitos, Diseño,
Implementación, Pruebas, Despliegue y mantenimiento.

La forma de operar de estas metodologías era finalizar todas las actividades de cada fase para luego
entregarlo al cliente, independientemente de cuánto lleve este flujo de actividades.
 Historia de la metodología ágil
El problema con los Métodos Tradicionales:

En la década de 1990, la industria del software se enfrentaba a numerosos desafíos debido a la

creciente complejidad de los proyectos y la rapidez con que cambiaban las necesidades del mercado y
los clientes.

El enfoque lineal y secuencial de estos métodos tradicionales de gestión de proyectos tenían varios
inconvenientes:

● Rigidez y falta de adaptabilidad

● Ciclos largos de desarrollo
● Desconexión con el cliente
● Altos índices de fracaso
 Historia de la metodología ágil

Manifiesto ágil como solución:

En respuesta a estos desafíos, un grupo de 17 desarrolladores de software y líderes de la industria se

reunió en febrero de 2001 en Snowbird, Utah, con el objetivo de encontrar una solución a estos
problemas.

El resultado de esta reunión fue la creación del Manifiesto Ágil, que estableció una nueva dirección
para el desarrollo de software, enfocándose en cuatro valores fundamentales y doce principios.
https://agilemanifesto.org/iso/es/manifesto.
html
 Historia de la metodología ágil
Los principios del Manifiesto Ágil:

● Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de

software con valor.

● Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.

● Entregamos software funcional frecuentemente, prefiriendo el tiempo más corto posible.

● Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

● Los proyectos se desarrollan en torno a individuos motivados.

● El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

https://agilemanifesto.org/iso/es/principles.
html
 Historia de la metodología ágil
● El software funcionando es la medida principal de progreso.

● Los promotores (stakeholders), desarrolladores y usuarios debemos ser capaces de mantener un

ritmo constante de forma indefinida.

● La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

● La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

● Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

● A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en consecuencia.

https://agilemanifesto.org/iso/es/principles.
html
 Definición y principios de agilidad
Las metodologías ágiles son enfoques de gestión y desarrollo de proyectos que enfatizan la
colaboración, la flexibilidad y la entrega rápida de productos de alta calidad.

Estas metodologías utilizan técnicas que se aplican en ciclos de trabajo cortos, para realizar entregas
continuas del proyecto, dejando de lado la necesidad de esperar hasta el término del mismo.

Se centran en responder de manera eficiente a los cambios y necesidades del cliente.

Forma de las personas en agilidad
 04
SCRUM
Como marco de referencia en agilidad
 Breve Historia
Se introdujo el framework “Scrum” en un artículo de la
Harvard Business Review en 1986.

Takeuchi y Nonaka tomaron el término “Scrum” del rugby,

explicando que “como en el rugby, los miembros del
equipo se pasan la pelota entre sí, a medida que avanzan
como una unidad por el campo de juego”.

Ikujiro Nonaka y Hirotaka Takeuchi

 Breve Historia

Más tarde Ken Schwaber y Jeff Sutherland en 1993 crearon el

proceso de desarrollo Scrum y en 1995 Ken Schwaber
publica por primera vez un informe hablando de la
metodología y Proceso de Desarrollo SCRUM y,
posteriormente, se publica también el Manifiesto ágil.

Desde su publicación inicial ambos han publicado la Guía de

Scrum, un documento dinámico que actualizan de forma
regular en el que se explica detalladamente qué es Scrum y
cómo ponerlo en práctica. De acuerdo con la Guía de Scrum,
Scrum alienta a “los equipos a observar cuán efectivas son
sus técnicas de trabajo y los desafía a evolucionar y
mejorarlas continuamente”.
 Definición y Elementos de Scrum
Scrum es un marco de trabajo ágil a través del cual las personas pueden abordar problemas
complejos adaptativos a la vez que se entregan productos de forma eficiente y creativa con el máximo
valor.

Esta metodología proporciona una serie de elementos para ayudar a los equipos a concentrarse en la
iteración y construcción de proyectos:

● Roles
● Eventos
● Artefactos
 Roles en Scrum
Product Owner o responsable del producto: Esta es la persona a cargo de la lista de trabajo
pendiente del producto (product backlog). Transmite el punto de vista del usuario a su equipo y a
otros ejecutivos involucrados y aportan claridad sobre qué es lo siguiente que se debe entregar
debido a su importancia (ordenan el backlog). También deberían ser ellos quienes decidan cuándo
algo está listo para ser entregado (con una tendencia a realizar entregas con frecuencia).
 Roles en Scrum

Scrum Master: Es la persona que dirige y facilita los distintos eventos de Scrum. Este rol puede ser
desempeñado por el gerente del proyecto. El Scrum Master organizar las reuniones de planificación
de sprints, organizar las reuniones diarias, eliminar los obstáculos, realizar análisis retrospectivos
 Roles en Scrum

Development Team: Es responsable del trabajo realizado en el sprint y de cómo se realizará. Como
equipo autoorganizado y multifuncional, encuentran las mejores soluciones para entregar
incrementos del producto de manera efectiva. Inspeccionan su trabajo y se adaptan para lograr
mejores resultados, pero también para aumentar la creatividad en el equipo.
 Roles en Scrum

Equipo Scrum: El equipo de Scrum son todos los que están trabajando en el sprint. Los miembros
del equipo deben auto-organizarse y ser colaborativos para lograr el objetivo de Scrum de mejora
continua.
 Eventos en Scrum
Sprints: Son eventos de duración fija (normalmente de 1 a 4 semanas) para crear consistencia. Un nuevo
Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Todo el trabajo necesario para lograr el Objetivo del Producto, incluido la Sprint Planning, Daily Scrums, Sprint
Review y Sprint Retrospective, ocurre dentro de los Sprints.

Durante el Sprint:
● No se realizan cambios que pongan en peligro el Objetivo del Sprint;
● La calidad no disminuye;
● El Product Backlog se refina según sea necesario; y,
● El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más
 Eventos en Scrum
Sprint Planning: Es la primera actividad que se realiza en el sprint para establecer el trabajo que se realizará.
Este evento aborda los siguientes temas:

Tema uno: ¿Por qué es valioso este Sprint?

El Product Owner comienza compartiendo una visión de cómo el Sprint puede mejorar el producto para inspirar al equipo
con una dirección clara y una justificación de por qué este Sprint será útil para los stakeholders. Con esta idea inicial, el
equipo Scrum trabaja junto para definir un Objetivo del Sprint. Este objetivo es una declaración breve y clara de lo que el
equipo pretende lograr en ese ciclo, en términos de impacto o valor, en lugar de sólo características técnicas o tareas. Esto
da al equipo una meta clara que va más allá de completar user stories o tareas.

Ejemplos de objetivos del sprint:

E-commerce: “Mejorar la experiencia de compra al reducir el tiempo de carga de la página de productos en un 30%
para aumentar la tasa de conversión."

Aplicación de finanzas personales: "Permitir a los usuarios visualizar y categorizar automáticamente sus gastos del
mes para mejorar el control financiero."
 Eventos en Scrum

Sprint Planning: Es la primera actividad que se realiza en el sprint para establecer el trabajo que se realizará.
Este evento aborda los siguientes temas:

Tema dos: ¿Qué se puede hacer en este Sprint?

A través de una conversación con el Product Owner, los Developers seleccionan elementos del Product Backlog para
incluirlos en el Sprint actual. El Scrum Team puede refinar estos elementos durante este proceso, lo que aumenta la
comprensión y la confianza.

Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío. Sin embargo, cuanto más sepan los
Developers sobre su desempeño pasado, su capacidad actual y su Definición de Terminado (DOD), más confiados estarán
en sus pronósticos para el Sprint.
 Eventos en Scrum
Sprint Planning: Es la primera actividad que se realiza en el sprint para establecer el trabajo que se realizará.
Este evento aborda los siguientes temas:

Tema tres: ¿Cómo se realizará el trabajo elegido?

Para cada elemento del Product Backlog seleccionado, los Developers planifican el trabajo necesario para crear un
Incremento que cumpla con la Definición de Terminado. A menudo, esto se hace descomponiendo los elementos del
Product Backlog en elementos de trabajo más pequeños de un día o menos. La forma de hacerlo queda a criterio
exclusivo de los Developers. Nadie más les dice cómo convertir los elementos del Product Backlog en Incrementos de
valor.
El Objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos se
denominan juntos Sprint Backlog.

El Sprint Planning tiene un límite de tiempo de máximo ocho horas para un Sprint de un mes. Para Sprints más cortos, el
evento suele ser de menor duración
 Eventos en Scrum
Daily Scrum: El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar
el Sprint Backlog según sea necesario, ajustando el trabajo planificado entrante.

Este evento es realizado a la misma hora y en el mismo lugar todos los días hábiles del Sprint por el
Development Team y su duración debe ser de 15 minutos. El equipo puede decidir tener sesiones más
detalladas sobre algún tema en particular que se habló durante la Daily Scrum que, en algunos casos, pudiera
impactar en adaptar o volver a planificar el resto del trabajo del sprint.

Si el Product Owner o Scrum Master están trabajando activamente en elementos del Sprint Backlog,
participan como Developers.

Las Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de
decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.
Eventos en Scrum
 Eventos en Scrum
Sprint Review:
El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. El Scrum Team
presenta los resultados de su trabajo a los interesados clave y se discute el progreso hacia el Objetivo del Producto.

Durante el evento, el Scrum Team y los interesados revisan lo que se logró en el Sprint. Con base en esta información, los
asistentes colaboran sobre qué hacer a continuación. El Product Backlog también se puede ajustar para satisfacer nuevas
oportunidades.

La Sprint Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación. La Sprint Review es el
penúltimo evento del Sprint y tiene un límite de tiempo de máximo cuatro horas para un Sprint de un mes y menor
duración para sprints más cortos.
 Eventos en Scrum
Sprint Retrospective:
El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad. El Scrum Team
inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su
Definición de Terminado. Se identifican los supuestos que los llevaron por mal camino y se exploran sus orígenes. El
Scrum Team analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos
problemas.

El Scrum Team identifica los cambios más útiles para mejorar su efectividad. Las mejoras más impactantes se abordan lo
antes posible. Incluso se pueden agregar al Sprint Backlog para el próximo Sprint.

La Sprint Retrospective concluye el Sprint. Tiene un tiempo limitado a máximo tres horas para un Sprint de un mes y
menor duración para sprints más cortos.
 Artefactos en Scrum
Product Backlog: El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto.

Los elementos del Product Backlog que el Scrum Team puede dar por Terminados dentro de un Sprint se consideran
preparados para ser seleccionados en un evento de Sprint Planning. Suelen adquirir este grado de transparencia tras las
actividades de refinamiento. El refinamiento del Product Backlog es el acto de dividir y definir aún más los elementos
del Product Backlog en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como
una descripción, orden y tamaño.

Los Developers que realizarán el trabajo son responsables del dimensionamiento. El Product Owner puede influir en los
Developers ayudándolos a entender y seleccionar sus mejores alternativas.
Eventos en Scrum
 Artefactos en Scrum
Sprint Backlog:
El Sprint Backlog se compone de todas las actividades que se realizarán en el sprint y que fueron planeadas
por y para los Developers.
Este se actualiza a lo largo del Sprint a medida que se aprende más. Debe tener suficientes detalles para que
puedan inspeccionar su progreso en la Daily Scrum; la transparencia es clave.

Durante la retrospectiva del sprint, el equipo Scrum debe seleccionar al menos una mejora e incluirla en el
backlog del sprint.

Ese es el mejor enfoque para asegurarse de que las mejoras discutidas en la retrospectiva del sprint formen
parte del sprint. Esto generará una mejora continua y ayudará al equipo de desarrollo a convertirse en un
equipo de alto rendimiento.
 Artefactos en Scrum
Increment:
Un Increment es un peldaño concreto hacia el Objetivo del Producto. Cada Increment se suma a todos los
Increments anteriores y se verifica minuciosamente, lo que garantiza que todos los Increments funcionen
juntos. Para proporcionar valor, el Increment debe ser utilizable.

Se pueden crear múltiples Increments dentro de un Sprint. La suma de los Increments se presenta en la Sprint
Review apoyando así el empirismo. Sin embargo, se puede entregar un Increment a los interesados antes del
final del Sprint. La Sprint Review nunca debe considerarse una puerta para liberar valor.

El trabajo no puede considerarse parte de un Increment a menos que cumpla con la Definición de Terminado.
 Anexos de Scrum

Burndown chart:
Es una gráfica utilizada para visualizar el progreso del trabajo en un Sprint. Muestra cómo va disminuyendo la
cantidad de trabajo pendiente (normalmente en horas o puntos de historia) a lo largo del tiempo.

En el eje X se muestra el tiempo (generalmente días del Sprint) y en el eje Y el trabajo restante. La línea ideal de
burn down va descendiendo hasta llegar a cero al finalizar el Sprint, lo que indica que todo el trabajo
planificado se ha completado.

Es una herramienta útil para el equipo, ya que permite identificar si están avanzando según lo planeado o si
hay riesgos de no completar el Sprint a tiempo.
Anexos de Scrum
Anexos de Scrum