Este espacio presenta cómo se organiza y documenta
la gestión de calidad del portfolio, relacionando
requisitos, historias de usuario, criterios de aceptación,
escenarios de prueba, defectos y evolución del proyecto.
00. Definición y alcance de la épica
Documento de definición estratégica del proyecto:
justificación, objetivos, alcance y condiciones
para su aceptación.
DOCUMENTO DE GESTIÓN · ÉPICA PRINCIPALEN EVOLUCIÓN
Desarrollo integral del Portfolio QA & AI
Construcción y evolución de una aplicación web
full stack que funciona como portfolio profesional
y sistema bajo prueba (SUT), integrando desarrollo,
automatización, gestión de calidad e inteligencia
artificial como área de especialización.
01
Justificación y valor de negocio
El proyecto surge de la necesidad de presentar
competencias técnicas mediante funcionalidades
reales y verificables, superando una exposición
exclusivamente descriptiva de conocimientos
y herramientas.
Su valor consiste en facilitar la evaluación
profesional del perfil, demostrando capacidades
de desarrollo, validación, automatización,
documentación y resolución de defectos
mediante evidencias consultables.
02
Objetivo principal
Desarrollar una plataforma funcional,
mantenible y verificable que permita
explorar el perfil profesional y comprobar
prácticas reales de aseguramiento de calidad.
03
Alcance de la iniciativa
El alcance funcional comprende el acceso
y registro de visitantes, navegación por
especialidades, formulario de contacto,
servicios API, persistencia de datos,
documentación técnica y presentación
de resultados de pruebas.
Componentes incluidos
Frontend y experiencia de usuario.
Backend, APIs y base de datos.
Validaciones y manejo de errores.
Pruebas manuales y automatizadas.
Gestión de requisitos y defectos.
Documentación y evidencia técnica.
Evolución pendiente
Persistencia del idioma seleccionado
entre todas las páginas.
Implementación de búsqueda global.
Revisión de navegación y
experiencia móvil.
Auditoría final de coherencia
y trazabilidad.
04
Criterios de aceptación y cierre
La épica podrá considerarse completada cuando
las funcionalidades incluidas en su alcance
definitivo estén implementadas, sus criterios
de aceptación hayan sido verificados y los
resultados cuenten con documentación
y evidencia suficiente.
Los defectos abiertos deberán evaluarse según
su impacto, y las funcionalidades pendientes
deberán resolverse o quedar formalmente
excluidas del alcance de cierre.
Esta definición consolida retrospectivamente
la evolución del proyecto. No implica que todos
los requisitos y funcionalidades hayan sido
establecidos desde su inicio.
01. Requisitos
Explorá los requisitos del portfolio y su aplicación
en las funcionalidades implementadas. Seleccioná una
categoría y después un requisito para conocer su
comportamiento o atributo de calidad.
REQUISITO FUNCIONAL
Acceso al portfolio
Seleccioná un requisito para consultar
su descripción y aplicación.
Los requisitos se relacionan con las historias de
usuario, los escenarios de comportamiento y las
verificaciones documentadas en el portfolio.
02. Historias de usuario
Recorrido por las necesidades del visitante,
los criterios de aceptación y su aplicación
en el portfolio. Incluye funcionalidades
implementadas y mejoras planificadas.
HU-001
Registro de visitantes
Implementada
Historia de usuario
Como visitante, quiero registrar mis
datos para acceder al portfolio.
Aplicación en el portfolio
Formulario de acceso, API de visitantes
y persistencia en SQLite.
Criterios de aceptación
1 de 5
Los criterios describen el comportamiento
esperado. Las funcionalidades pendientes
se identifican sin atribuirles resultados
de ejecución que todavía no existen.
03. Escenarios BDD
Explorá los comportamientos esperados del portfolio
mediante escenarios estructurados en Dado, Cuando
y Entonces. Incluye funcionalidades implementadas
y comportamientos previstos para futuras mejoras.
BDD-001
Registro válido
Implementado
DADO
Que el visitante completa los datos
obligatorios correctamente y acepta
el consentimiento.
CUANDO
Envía el formulario de registro.
ENTONCES
El sistema acepta el registro
y permite continuar al portfolio.
Historia relacionada
HU-001
Estos escenarios documentan comportamientos esperados.
No representan ejecuciones automatizadas con Cucumber.
Los escenarios de funcionalidades pendientes se
identifican expresamente.
04. Trazabilidad
Explorá cómo se relacionan los requisitos con
las historias de usuario, los escenarios BDD
y las verificaciones del portfolio.
Seleccioná un requisito para visualizar
su recorrido y su estado actual.
RECORRIDO SELECCIONADO
Registro de visitantes
Implementado
Requisito
RF-02
Registro de visitantes
→
Historia de usuario
HU-001
Registro
→
Escenario BDD
BDD-001
Registro válido
Verificación y evidencia
El registro válido cuenta con
verificaciones funcionales y de API.
Consultar matriz de trazabilidad
Requisito
Historia
BDD
Verificación
Estado
La trazabilidad distingue los comportamientos
implementados de los pendientes. Los vínculos
con casos de prueba se documentan únicamente
cuando existen referencias verificables.
05. Gestión de defectos
La gestión de defectos comprende la identificación,
documentación, comunicación, verificación y cierre
de los problemas detectados durante las pruebas.
Este procedimiento permite mantener evidencias,
facilitar la colaboración del equipo y comprobar
que las correcciones cumplen los resultados esperados.
PROCEDIMIENTO DE QA
Del hallazgo a la verificación
Durante el desarrollo del portfolio, inicié
el seguimiento de defectos mediante registros
estructurados en Excel y posteriormente
incorporé Jira para organizar su documentación,
clasificación y seguimiento. Este proceso
permite aplicar buenas prácticas de QA
en entornos de trabajo colaborativos
y equipos Scrum.
ETAPA 01
Detección y evidencia
Gestión del defecto
Durante la ejecución de las pruebas se
identifica un comportamiento que no coincide
con el resultado esperado. Se recopilan
capturas de pantalla, grabaciones y datos
de prueba para documentar el hallazgo.
Información y actividades clave
1 de 5
Control antes del cierre
Si el defecto continúa reproduciéndose
durante la reprueba, no debe cerrarse.
Se actualiza su seguimiento y vuelve
al circuito de análisis y corrección.
El cierre se realiza únicamente después
de verificar satisfactoriamente
el comportamiento esperado.
EVIDENCIA DEL PROYECTO
Defectos documentados
Los siguientes defectos fueron identificados
durante las pruebas del portfolio y cuentan
con registros de seguimiento. Seleccioná
un identificador para consultar el problema,
su clasificación y las verificaciones
relacionadas.
BUG-001
Teléfono acepta letras
Cerrado
El campo teléfono permitía ingresar
caracteres alfabéticos. Se corrigió
la validación para rechazar entradas
que no cumplen el formato permitido.
Requisito relacionado
FR-008
Caso de prueba
TC-012
Severidad
Media
Prioridad
Alta
Resolución y verificación
Se ajustó la validación del teléfono
y se comprobó que el formulario
rechaza caracteres no permitidos.
Los reportes completos, los casos de prueba
y las evidencias disponibles se encuentran
en la sección de QA del portfolio.
Los cinco defectos se encuentran cerrados
según los registros del proyecto.
Los datos de clasificación y las referencias
se presentan conforme a la documentación
disponible, sin atribuir ejecuciones
adicionales no registradas.
06. Sprints y evolución
El portfolio evolucionó mediante ciclos incrementales
de desarrollo, verificación y mejora. Seleccioná cada
etapa para explorar las actividades realizadas,
sus objetivos y los resultados documentados.
SPRINT 2 · BACKEND Y QA
Sprint 2 · APIs y datos
Desarrollo de servicios backend,
persistencia, validaciones y pruebas.
SPRINT 2
APIs Y DATOS
Desarrollo · QA · Integración
ETAPA 01 · PLANIFICACIÓN
Definición del alcance
Organización de funcionalidades,
validaciones y pruebas del backend.
Los ciclos representan actividades del proyecto
y no certifican la realización de ceremonias Scrum.
Los resultados mostrados corresponden a verificaciones
documentadas. La evolución continua describe
mejoras progresivas, no un sprint cerrado.
07. Backlog, prioridades y riesgos
Documento de planificación y seguimiento de mejoras,
prioridades propuestas, riesgos identificados
y decisiones de implementación.
DOCUMENTO DE GESTIÓN · PLANIFICACIÓNEN EVOLUCIÓN
Planificación y control de la evolución
Este registro diferencia el trabajo pendiente
de las funcionalidades implementadas y reúne
los criterios utilizados para orientar
las próximas mejoras del portfolio.
01
Registro de iniciativas
Las prioridades representan una propuesta
de planificación y no una clasificación
histórica formal.
ID
Iniciativa
Prioridad
Estado
Referencia
BL-01
Persistencia global del idioma
Mantener el idioma seleccionado
al navegar entre páginas.
Alta
Pendiente
HU-004
BL-02
Búsqueda global
Buscador integrado en las seis páginas
del portfolio, con resultados por relevancia,
navegación mediante teclado y mouse,
y diseño adaptable.
Revisar controles, menú y experiencia
en pantallas pequeñas.
Media
En revisión
Interfaz y UX
BL-04
Auditoría de trazabilidad
Revisar requisitos, historias,
BDD, casos y evidencias.
Alta
Pendiente
Gestión de calidad
02
Criterios de priorización
Para organizar las próximas mejoras se propone
considerar los siguientes factores:
Impacto
Valor para el usuario y el proyecto.
Riesgo
Consecuencias de mantener
la mejora pendiente.
Esfuerzo
Complejidad estimada de
implementación y pruebas.
Dependencias
Componentes o decisiones
necesarios para avanzar.
03
Registro de riesgos
Riesgo
Descripción
Mitigación propuesta
Inconsistencia entre páginas
Diferencias de navegación,
idioma y presentación visual
por evolución independiente.
Establecer verificaciones
de regresión entre páginas.
Desalineación documental
Requisitos, casos o evidencias
desactualizados tras cambios
funcionales.
Revisar los artefactos relacionados
al incorporar cada cambio.
Dependencia del entorno local
Funcionamiento condicionado
por servicios backend
y su configuración.
Documentar las condiciones
de ejecución y verificar
los servicios antes de probar.
04
Decisiones de implementación
Decisiones adoptadas durante la evolución
del portfolio para separar responsabilidades
y facilitar la verificación del sistema.
Separación frontend y backend
Organización de la interfaz
y los servicios API como
componentes diferenciados.
Persistencia con SQLite
Almacenamiento de registros
de visitantes para verificar
operaciones reales de datos.
Automatización de verificaciones
Pruebas automatizadas que complementan
la validación manual de interfaz,
API y componentes.
Los identificadores BL-01 a BL-04 organizan
esta propuesta de backlog y no representan
tickets previamente registrados en Jira.
Los riesgos y prioridades se presentan
como criterios de planificación para
la evolución del proyecto.
08. Resultados, aceptación y cierre
Informe de evaluación del avance de la épica,
resultados documentados, evidencia disponible
y condiciones para su cierre formal.
DOCUMENTO DE GESTIÓN · EVALUACIÓNCIERRE PENDIENTE
Evaluación de resultados de la épica
El portfolio integra frontend, backend,
persistencia de datos y actividades de
aseguramiento de calidad. Las funcionalidades
desarrolladas cuentan con verificaciones
documentadas, mientras que otras capacidades
permanecen pendientes de implementación
o revisión.
Estado generalEn evolución · Cierre pendiente
01
Resultados alcanzados
Interfaz funcional
Desarrollo de páginas de presentación,
navegación, formularios y validaciones
de entrada.
Servicios y persistencia
Implementación de endpoints con Node.js
y Express, validaciones del servidor
y almacenamiento de visitantes
mediante SQLite.
Verificación de calidad
Ejecución documentada de pruebas
funcionales, automatizadas, de API
e integración, junto con actividades
de regresión.
Gestión documental
Organización de requisitos, historias
de usuario, escenarios BDD, casos
de prueba, defectos y evidencias.
02
Evidencia de aceptación disponible
Los siguientes resultados corresponden
a ejecuciones previamente documentadas.
No representan una nueva ejecución
ni una aprobación global de la épica.
Conjunto de pruebas
Resultado
Estado
Pruebas funcionales de interfaz
18/18
Aprobado
Pruebas automatizadas de backend
15/15
Aprobado
Pruebas smoke
5/5
Aprobado
Pruebas de integración
3/3
Aprobado
Los conjuntos de pruebas son diferentes
y no deben interpretarse como una única
ejecución consolidada.
Resolver las funcionalidades pendientes
o establecer formalmente cuáles quedan
fuera de la versión de cierre.
Verificar los cambios finales
Ejecutar las comprobaciones necesarias
sobre las mejoras incorporadas
y evaluar posibles regresiones.
Revisar la trazabilidad
Confirmar la coherencia entre requisitos,
historias, escenarios, pruebas
y evidencias.
Documentar la aceptación
Registrar una evaluación final del alcance,
los resultados, los riesgos residuales
y las condiciones de aceptación.
04
Conclusión de gestión
Avance verificable, cierre aún no declarado
El proyecto demuestra la integración
de desarrollo y aseguramiento de calidad
mediante funcionalidades reales y
resultados documentados.
Su evolución continúa y el cierre formal
de la épica permanece pendiente hasta
completar o delimitar el alcance definitivo
y verificar sus criterios de aceptación.
Esta evaluación sintetiza el estado documentado
del portfolio. No constituye una aprobación formal
de entrega ni reemplaza los reportes de ejecución
y evidencia existentes.