Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones
Abstract
En los entornos de desarrollo de software, los equipos de QA juegan un papel clave en la validación de la calidad del producto antes de su entrega. Sin embargo, a menudo se enfrentan a metodologías poco estructuradas, afectando directamente a la eficiencia del proceso, a la calidad del software y a la autonomía del equipo. Este Trabajo de Fin de Grado, titulado “Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones”, plantea una solución metodológica adaptada a equipos que trabajan en marcos ágiles. La propuesta parte del análisis del funcionamiento actual de un equipo QA en un proyecto real del sector e-commerce y busca rediseñar su flujo de trabajo para hacerlo más equilibrado, trazable y sostenible en el tiempo. Para ello, se ha definido una metodología basada en la estandarización de test cases mediante Xray, la centralización de documentación clave en Confluence y la creación de un nuevo flujo de validación adaptado a las fases del sprint. Además, se ha desarrollado una versión alternativa del proceso orientada a situaciones de alta carga de trabajo, ofreciendo mayor flexibilidad sin comprometer la calidad. El proyecto se ha aplicado en un entorno real, con integración directa en las dinámicas de equipo existentes, lo que ha permitido validar la utilidad práctica de las mejoras propuestas. Además de los aspectos técnicos, el trabajo incorpora un análisis de riesgos, una planificación temporal y económica detallada, así como una visión estratégica para futuras fases del proyecto. Todo ello desde una perspectiva alineada con los principios de eficiencia, escalabilidad y mejora continua propios de la ingeniería de sistemas de información.
Full text
id191515 HACIA UNA METODOLOGÍA DE TESTING MÁS EFICAZ: ANÁLISIS Y RECOMENDACIONES XAVIER AGUILAR GODAY Director: RICARDO LEAL LAMATA Ponente: ENRIC MAYOL SARROCA (Departamento de Ingeniería de Servicios y Sistemas de Información) Titulación Grado en Ingeniería Informática (Sistemas de Información) Memoria del trabajo de fin de grado Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 15/05/2025
Resumen En los entornos de desarrollo de software, los equipos de QA juegan un papel clave en la validación de la calidad del producto antes de su entrega. Sin embargo, a menudo se enfrentan a metodologías poco estructuradas, afectando directamente a la eficiencia del proceso, a la calidad del software y a la autonomía del equipo. Este Trabajo de Fin de Grado, titulado “Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones”, plantea una solución metodológica adaptada a equipos que trabajan en marcos ágiles. La propuesta parte del análisis del funcionamiento actual de un equipo QA en un proyecto real del sector e-commerce y busca rediseñar su flujo de trabajo para hacerlo más equilibrado, trazable y sostenible en el tiempo. Para ello, se ha definido una metodología basada en la estandarización de test cases mediante Xray, la centralización de documentación clave en Confluence y la creación de un nuevo flujo de validación adaptado a las fases del sprint. Además, se ha desarrollado una versión alternativa del proceso orientada a situaciones de alta carga de trabajo, ofreciendo mayor flexibilidad sin comprometer la calidad. El proyecto se ha aplicado en un entorno real, con integración directa en las dinámicas de equipo existentes, lo que ha permitido validar la utilidad práctica de las mejoras propuestas. Además de los aspectos técnicos, el trabajo incorpora un análisis de riesgos, una planificación temporal y económica detallada, así como una visión estratégica para futuras fases del proyecto. Todo ello desde una perspectiva alineada con los principios de eficiencia, escalabilidad y mejora continua propios de la ingeniería de sistemas de información.
Resum En els entorns de desenvolupament de programari, els equips de QA tenen un paper clau en la validació de la qualitat del producte abans de la seva entrega. No obstant això, sovint s'enfronten a metodologies poc estructurades, fet que afecta directament l'eficiència del procés, la qualitat del programari i l'autonomia de l'equip. Aquest Treball de Fi de Grau, titulat “Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones”, planteja una solució metodològica adaptada a equips que treballen en marcs àgils. La proposta parteix de l’anàlisi del funcionament actual d’un equip de QA en un projecte real del sector e-commerce i busca redissenyar-ne el flux de treball per fer-lo més equilibrat, traçable i sostenible en el temps. Per a això, s’ha definit una metodologia basada en l’estandardització dels test cases mitjançant Xray, la centralització de la documentació clau a Confluence i la creació d’un nou flux de validació adaptat a les fases de l’sprint. A més, s’ha desenvolupat una versió alternativa del procés orientada a situacions de càrrega de treball elevada, oferint una major flexibilitat sense comprometre la qualitat. El projecte s’ha aplicat en un entorn real, amb integració directa en les dinàmiques d’equip existents, la qual cosa ha permès validar la utilitat pràctica de les millores proposades. A més dels aspectes tècnics, el treball incorpora una anàlisi de riscos, una planificació temporal i econòmica detallada, així com una visió estratègica per a futures fases del projecte. Tot plegat des d’una perspectiva alineada amb els principis d’eficiència, escalabilitat i millora contínua propis de l’enginyeria de sistemes d’informació.
Abstract In software development environments, QA teams play a key role in ensuring product quality before release. However, they often face poorly structured methodologies, which directly affect the efficiency of the process, software quality, and team autonomy. This Final Degree Project, titled “Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones”, presents a methodology adapted to teams working under agile frameworks. The proposal is based on an in-depth analysis of a QA team’s current workflow within a real e-commerce project, aiming to redesign it to become more balanced, traceable, and sustainable over time. The methodology includes standardized test cases using Xray, centralized documentation in Confluence, and a revised validation flow aligned with sprint phases. In addition, an alternative version of the process was designed for periods of high workload, providing greater flexibility without compromising quality. The project was applied in a real context, fully integrated into the team’s existing dynamics, which made it possible to validate the practical utility of the proposed improvements. Besides the technical enhancements, the work includes a risk analysis, detailed time and cost planning, and a strategic vision for future phases, such as test automation. All of this is approached from a perspective aligned with the principles of efficiency, scalability, and continuous improvement inherent to Information Systems Engineering.
Índice 1. Introducción............................................................................................................................................7 1.1 Contexto......................................................................................................................................... 7 1.2 Definición de conceptos..................................................................................................................8 1.3 Identificación del problema...........................................................................................................10 1.4 Stakeholders o actores implicados...............................................................................................10 1.5 Objetivos del proyecto.................................................................................................................. 11 1.6 Competencias técnicas.................................................................................................................12 2. Justificación o estado del arte.............................................................................................................. 13 2.1 Revisión de metodologías actuales de testing............................................................................. 13 2.2 Justificación..................................................................................................................................15 3. Gestión del Proyecto............................................................................................................................ 17 3.1 Alcance.........................................................................................................................................17 3.2. Metodología de Trabajo y Herramientas de Seguimiento........................................................... 19 3.3. Planificación temporal..................................................................................................................20 3.4. Descripción de Tareas.................................................................................................................20 3.5. Estimaciones y Gantt...................................................................................................................28 3.6. Gestión de Riesgo.......................................................................................................................29 3.7. Presupuesto del Proyecto............................................................................................................31 3.8. Sostenibilidad del Proyecto......................................................................................................... 36 4. Modificación de la Planificación............................................................................................................39 4.1 Cambios aplicados en la planificación..........................................................................................39 4.2 Consecuencias e impacto en los costes.......................................................................................39 5. Análisis de la metodología actual.........................................................................................................40 5.1 Revisión de la Metodología Actual............................................................................................... 41 5.2 Análisis de la Carga de Trabajo del Equipo QA........................................................................... 42 5.3 Identificación del Conocimiento Clave..........................................................................................42 5.4 Análisis de Herramientas y Tecnologías Existentes.....................................................................43 6. Requisitos de la nueva metodología.................................................................................................... 45 7. Diseño de Mejoras................................................................................................................................47 7.1 Importancia y Beneficios de Crear una Plantilla para Casos de Prueba......................................47 7.2 Integración con Xray.....................................................................................................................50 7.3 Herramientas de Documentación Descentralizada...................................................................... 52 7.4 Diseño de Estrategias de Reorganización de Carga....................................................................54 8. Metodología..........................................................................................................................................56 9. Aplicación de mejoras.......................................................................................................................... 58 9.1 Test Case y Test Execution...........................................................................................................58 9.2 Carga de Trabajo..........................................................................................................................60 9.3 Panel de visibilidad del testing......................................................................................................60 10. Rediseño de metodología en caso de alta carga de trabajo.............................................................. 62 11. Visión y valoración del equipo sobre la metodología..........................................................................64 12. Trabajo futuro..................................................................................................................................... 65 13. Conclusiones......................................................................................................................................66 13.1 Cumplimiento de los objetivos del proyecto............................................................................... 66
13.2 Competencias técnicas trabajadas.............................................................................................67 13.3 Valoración personal del proyecto................................................................................................68 14. Bibliografía..........................................................................................................................................69 Índice de Figuras Figura 1: SDLC V-Model...........................................................................................................................14 Figura 2: Diagrama de Gantt....................................................................................................................28 Figura 3: Flujo Antiguo de Testing............................................................................................................41 Figura 3: Flujo de trabajo QA por sprints..................................................................................................56 Figura 4: Ejemplo de Dashboard..............................................................................................................57 Figura 5: Test Case en Xray.....................................................................................................................58 Figura 6: Dashboard de monitorización....................................................................................................61 Figura 7: Flujo de trabajo QA................................................................................................................... 63 Índice de Tablas Tabla 1: Comparación de metodologías...................................................................................................15 Tabla 2: Resumen tareas GEP.................................................................................................................26 Tabla 3: Resumen tareas del desarrollo...................................................................................................27 Tabla 4: Resumen tareas de cierre...........................................................................................................27 Tabla 5: Sueldos de cada rol.................................................................................................................... 31 Tabla 6: Coste humano en € por actividad............................................................................................... 33 Tabla 7: Amortización equipamiento.........................................................................................................34 Tabla 8: Coste con contingencias.............................................................................................................34 Tabla 9: Estimación de costes por riesgo.................................................................................................35 Tabla 10: Presupuesto final...................................................................................................................... 36
1. Introducción Este Trabajo Final de Grado (TFG) con título “Hacia una Metodología de Testing Más Eficaz: Análisis y Recomendaciones” pertenece al Grado en Ingeniería Informática de la Universidad Politécnica de Cataluña (UPC), en concreto en la facultad de Informática de Barcelona (FIB). El proyecto corresponde a la especialidad de Sistemas de información, siendo este de modalidad B dado que es elaborado en una empresa externa. Este proyecto no está sujeto a una cláusula de confidencialidad específica para el TFG, ya que dicha confidencialidad queda cubierta por el contrato profesional vigente del autor. Por este motivo, no se puede revelar el nombre de la empresa, ni detallar aspectos sobre su funcionamiento interno, organización o clientes. En consecuencia, a lo largo de este trabajo se ha optado por anonimizar al máximo cualquier referencia directa a la empresa. Tanto las pruebas, como la metodología, los resultados y los datos presentados han sido generalizados con el fin de respetar las limitaciones impuestas por el acuerdo contractual. No obstante, se ha procurado mantener la fidelidad al contexto real del proyecto, reflejando la experiencia vivida sin vulnerar ninguna condición de confidencialidad. 1.1 Contexto El testing es esencial en los proyectos de software para garantizar la calidad de los productos. En un entorno competitivo, donde los clientes demandan soluciones más eficientes y sólidas, el testing se vuelve un instrumento crucial para identificar y corregir fallos en el desarrollo. La identificación temprana de errores en un proyecto no solo previene que el software a entregar llegue con defectos, sino también, permite abaratar costes al reducir significativamente los costes asociados a las correcciones posteriores. Además, los sistemas de software están presentes en muchas actividades críticas,como transacciones en línea y sistemas de salud, donde un mal funcionamiento puede acarrear consecuencias severas, incluyendo fallos catastróficos y pérdida de vidas, como ha ocurrido en situaciones como el caso de la máquina de radioterapia Therac-25 [1]. Por lo tanto, el testing debe ser considerado no como una etapa aislada del desarrollo, sino como un proceso continuo que se debe integrar en cada fase del proyecto. Es fundamental realizar pruebas alineadas con los objetivos y requisitos del cliente desde el inicio para asegurar que se cumplan con los estándares esperados. y funcione correctamente en el entorno para el que fue diseñado. 7
1.2 Definición de conceptos Pruebas unitarias: Estas son evaluaciones que se realizan a los componentes más pequeños y aislados del software, típicamente funciones o métodos individuales. Su finalidad es garantizar que cada fragmento del código opere correctamente de manera independiente. Generalmente, se automatizan para facilitar su ejecución frecuente y su integración continua. Pruebas de integración: Se centran en verificar que diferentes módulos o componentes del software funcionen correctamente cuando se integran entre sí. Es posible que los módulos pasen las pruebas unitarias de forma individual, pero fallen al interactuar entre sí. Estas aseguran que la interacción entre componentes es coherente y funcional. Pruebas funcionales: Se enfocan en verificar que cada función del software opere según los requisitos establecidos. Su meta es confirmar que las características implementadas funcionan tal como se espera desde la perspectiva del usuario. Pruebas de regresión: El propósito de estas pruebas es comprobar que las modificaciones recientes en el código —ya sean nuevas funciones o correcciones de errores— no impacten negativamente en las funcionalidades que ya existían. Las pruebas de regresión son cruciales para asegurar que el software continúe funcionando correctamente tras recibir actualizaciones o cambios. Pruebas exploratorias: Se trata de una forma de evaluación no estructurada, donde el tester explora el sistema de forma libre y sin casos de prueba preestablecidos. Estas pruebas se fundamentan en la experiencia y conocimiento del tester, con el objetivo de identificar errores o comportamientos inesperados en el software. Pruebas de estrés: Estas evaluaciones exponen el sistema a situaciones extremas que superan los límites de operación establecidos, con el fin de analizar su estabilidad y comportamiento ante cargas intensas. La meta es detectar posibles fallos o vulnerabilidades en el sistema. Pruebas no funcionales: Estas evaluaciones se centran en elementos que no están directamente vinculados a las funciones específicas del software, como su rendimiento, usabilidad, seguridad y compatibilidad. Su finalidad es garantizar que el sistema mantenga eficiencia y solidez en diversas circunstancias. Pruebas End-to-End (E2E): Son aquellas pruebas que verifican el sistema completo en un entorno real o lo más cercano posible, desde el inicio hasta el fin de un proceso.La intención es asegurar que todos los flujos del sistema operen correctamente en un entorno integrado, con el objetivo de que el sistema sea funcional desde la perspectiva del usuario. 8
Quality Assurance: Se refiere a la persona responsable de llevar a cabo un conjunto de procedimientos y prácticas que aseguran que el software esté alineado con los estándares de calidad estipulados. Su tarea consiste en prevenir errores y asegurar que el producto final sea confiable y operativo, empleando metodologías de trabajo y pruebas sistemáticas durante todo el ciclo de desarrollo. Test cases: Los test cases son documentos que detallan las circunstancias en las que se llevarán a cabo las pruebas de un sistema. Incluyen el objetivo de la prueba, las etapas a seguir, los datos a utilizar y los resultados esperados. Verificación: Este proceso consiste en confirmar que el software ha sido desarrollado de manera adecuada conforme a los requisitos técnicos establecidos. Se lleva a cabo durante la etapa de desarrollo a través de revisiones o pruebas técnicas, como las unitarias o de integración. Validación: Este proceso se encarga de examinar si el software satisface las necesidades del usuario final. Se efectúa al finalizar el desarrollo o en etapas avanzadas, mediante pruebas de aceptación o de tipo end-to-end. Sandbox: Entorno de pruebas inicial donde se valida el funcionamiento básico de los desarrollos, sin afectar a otros entornos. Staging: Entorno de preproducción que replica el entorno final, utilizado para realizar validaciones completas antes de pasar a producción. Producción: Entorno real en el que los usuarios interactúan con el sistema. Cualquier error en este entorno puede tener impacto directo sobre el servicio. Merge Request (MR): Solicitud de integración de código a la rama principal del repositorio, revisada por el equipo técnico y validada por QA. DONE: Estado final de un ticket que indica que todas las tareas han sido completadas y validadas satisfactoriamente. Sanity: Prueba rápida que se realiza tras una corrección o cambio en el software para verificar que las funciones principales siguen funcionando y que no se han introducido errores graves. 9
No se elegiría el modelo Waterfall debido a su rigidez y a la dificultad para adaptarse a cambios en los requisitos una vez que el desarrollo ha comenzado. Por otro lado, el V-Model, aunque ofrece un enfoque estructurado, también presenta limitaciones en su flexibilidad y en la detección tardía de errores. Ambos modelos, por lo tanto, no se alinean con la necesidad de un enfoque dinámico y receptivo que promueva la colaboración y la mejora continua que Scrum Testing puede ofrecer. 16
3. Gestión del Proyecto 3.1 Alcance Este TFG se centra en el diseño y aplicación parcial de una mejora metodológica para el proceso de testing en un entorno real de desarrollo de software. La propuesta se aplicará específicamente a un proyecto de e-commerce, que se utiliza como caso de estudio, pero se plantea con la intención de ser escalable y reutilizable en otros proyectos similares de la empresa. La mejora metodológica abordará principalmente los siguientes tipos de pruebas: ● Pruebas funcionales: para verificar que las funcionalidades cumplen con los requisitos establecidos. ● Pruebas de regresión: para asegurar que nuevas implementaciones no afectan negativamente al software existente. ● Pruebas exploratorias: basadas en la experiencia de los testers para detectar errores inesperados. ● Pruebas End-to-End (E2E): que validan los flujos completos del sistema desde el punto de vista del usuario. Además, se aplicarán los conceptos de verificación (comprobar que el sistema ha sido desarrollado correctamente según los requisitos) y validación (asegurar que el sistema cumple con las expectativas y necesidades del cliente). 3.1.1 Alcance del proyecto El proyecto no contempla el diseño de una metodología completamente nueva, sino la identificación de debilidades en la metodología actual y la propuesta de mejoras sobre ella. Estas mejoras se centrarán en aspectos clave como la organización del trabajo del equipo QA, la trazabilidad de las pruebas, la documentación del conocimiento y la visibilidad del proceso de testing. Como caso de estudio, las mejoras han sido aplicadas y validadas dentro de un proyecto real de e-commerce, lo que ha permitido observar en profundidad los desafíos actuales del equipo de QA y la efectividad de las propuestas en un entorno real. Dentro del alcance del TFG se incluye: ● El análisis de la situación actual del equipo QA y su metodología de trabajo. ● El diseño de una propuesta de mejora estructurada y documentada. ● La implementación parcial de estas mejoras dentro de un proyecto real. ● La evaluación de su impacto mediante observaciones, métricas y feedback del equipo. 17
Se espera que, como resultado del trabajo, se genere una base metodológica sólida, accesible y aplicable a otros entornos similares, contribuyendo a la profesionalización y estandarización del trabajo del equipo de QA en distintos proyectos de desarrollo de software dentro de la empresa. 3.1.2 Obstáculos y riesgos Uno de los principales obstáculos que se podrían enfrentar al implementar mejoras en la metodología actual es la resistencia al cambio. Los miembros del equipo pueden estar acostumbrados a las prácticas existentes y mostrar reticencia a adoptar nuevas formas de trabajo, incluso si estas son beneficiosas a medio o largo plazo. Además, la falta de compromiso o implicación activa por parte del equipo podría dificultar la adopción de las nuevas iniciativas, ralentizando su implantación o reduciendo su impacto. Por otro lado, la creación de documentación clara, accesible y actualizada puede convertirse en un reto si no se dispone del tiempo necesario para elaborarla de forma adecuada. Asimismo, las limitaciones de recursos, tanto humanos como técnicos, pueden representar una barrera importante si el equipo no cuenta con las herramientas necesarias para aplicar las mejoras propuestas. La falta de una comunicación efectiva entre los diferentes perfiles involucrados puede generar malentendidos sobre responsabilidades, estados de avance o prioridades, dificultando la colaboración y la resolución de incidencias. La concentración del conocimiento en personas concretas también supone un riesgo relevante. En caso de que algún miembro clave del equipo se ausente, se podría producir una fuga de conocimiento que afecte negativamente a la continuidad del trabajo. A ello se suma la posible dependencia de herramientas específicas que, en caso de fallo, podrían paralizar parte del flujo de trabajo si no se han definido mecanismos alternativos. Finalmente, cabe tener en cuenta la posible subestimación del tiempo y recursos necesarios para llevar a cabo todas las acciones previstas, lo que podría derivar en desviaciones de calendario y aumentar la presión sobre el equipo. A estos riesgos generales se suman algunos elementos propios del contexto del TFG. En primer lugar, existe el riesgo derivado de la inexperiencia en la definición de metodologías y procesos de testing, lo que podría requerir una curva de aprendizaje adicional o revisiones más frecuentes durante el desarrollo del proyecto. En segundo lugar, se identifica la dificultad para compaginar las tareas propias del TFG con las responsabilidades laborales, especialmente en momentos de alta carga de trabajo en la empresa, lo cual puede afectar al ritmo previsto y generar desviaciones en la planificación inicial. Todos estos riesgos han sido tenidos en cuenta en el análisis de costes y previsión de contingencias desarrollado en el presupuesto del proyecto, permitiendo una estimación más realista del esfuerzo y los recursos necesarios. 18
3.2. Metodología de Trabajo y Herramientas de Seguimiento 3.2.1 Metodología utilizada Para el desarrollo de este Trabajo Final de Grado se adoptará una metodología ágil, inspirada en los principios de Scrum, aunque adaptada al contexto específico de un proyecto individual. Dado que el TFG será realizado por una sola persona, no se aplicará Scrum en su forma tradicional con roles definidos ni con ceremonias formales como las reuniones diarias o retrospectivas de equipo. En su lugar, se empleará una versión simplificada y personalizada, que mantendrá los valores fundamentales de la agilidad: planificación iterativa, mejora continua, flexibilidad ante cambios y entrega progresiva de valor. El trabajo se organizará en sprints individuales de dos semanas, en los que se establecerán objetivos concretos y tareas priorizadas. Al finalizar cada sprint, se realizará una revisión de los avances y, si es necesario, se reajustará la planificación para el siguiente ciclo. Este enfoque permitirá un seguimiento constante, facilitará la detección temprana de desviaciones, y ayudará a mantener un ritmo de trabajo sostenido y realista. Además, se definirán entregables intermedios claros, vinculados a fases específicas del proyecto (análisis, diseño, implementación, evaluación), lo que permitirá mantener una estructura organizada y una visión clara del progreso global.3.2.2 Herramientas de seguimiento Para garantizar que se alcanzan los objetivos del proyecto y se cumplen las expectativas, se utilizarán diversas herramientas de seguimiento que facilitan la gestión y el monitoreo del progreso. Entre las herramientas más relevantes se encuentran: Jira: Esta herramienta de gestión de proyectos es crucial para planificar y gestionar el trabajo del equipo. A través de Jira, se pueden crear historias de usuario, tareas y bugs, así como asignar responsabilidades y hacer seguimiento del avance de cada sprint. Además, se integrará Xray [7], una herramienta de gestión de pruebas dentro de Jira, que ayudará a organizar y ejecutar las pruebas de manera eficiente, permitiendo crear casos de prueba, realizar seguimientos de los resultados y generar informes detallados. Confluence [8]: Se utilizará para la documentación del proyecto, permitiendo al equipo centralizar la información y las mejores prácticas. Confluence facilita la colaboración, ya que todos los miembros pueden contribuir a la documentación y acceder fácilmente a ella en cualquier momento. 19
Microsoft Teams: Esta herramienta será utilizada para la comunicación interna del equipo, ofreciendo funcionalidades de chat, videollamadas y colaboración en documentos, lo que fomentará una comunicación fluida y efectiva entre los miembros del equipo. Slack [9]: Para la comunicación externa con stakeholders y otras partes interesadas, se empleará Slack, que permite una comunicación rápida y efectiva, asegurando que todos estén al tanto de los avances y cambios en el proyecto. 3.3. Planificación temporal El proyecto se desarrollará entre el 18 de septiembre de 2024 y el 20 de enero de 2025, con una duración total de 540 horas (18 ECTS), distribuidas en 90 horas para GEP y 450 para el desarrollo y cierre. Al compaginarse con una jornada laboral completa, se ha previsto una dedicación media de 4 horas diarias, dentro de una planificación flexible. El trabajo se organizará mediante un diagrama de Gantt, que permitirá hacer un seguimiento del progreso y ajustar la planificación si es necesario. Sin embargo, debido a una elevada carga de trabajo laboral durante el desarrollo del TFG, la dedicación real ha sido de aproximadamente 2 horas diarias, lo que ha implicado una ampliación del periodo del proyecto hasta el 12 de mayo de 2025. Esta reorganización temporal asegura que se pueda alcanzar la carga total prevista de 540 horas, respetando los objetivos y entregables definidos. 3.4. Descripción de Tareas 3.4.1 Gestión de proyectos GEP1 - Contexto y objetivos del proyecto Descripción: Se elaborará un documento que describa el contexto del proyecto, explicando la situación actual de la empresa, las necesidades que pretende cubrir el proyecto y los objetivos específicos que se desean alcanzar. Incluirá una descripción detallada del alcance del proyecto, los stakeholders involucrados y los principales desafíos identificados. Estimación: 25 horas. Secuencia: Tarea inicial, sin dependencias. Recursos necesarios: Documentación existente. 20
GEP2 - Planificación del proyecto Descripción: Se desarrollará un plan temporal detallado que cubra todas las fases del proyecto, con un cronograma que refleje las tareas principales y los hitos. Este documento garantizará una correcta organización de las actividades, permitiendo un seguimiento eficiente y la detección de posibles desviaciones en el desarrollo del trabajo. Estimación: 18 horas. Secuencia: Dependiente de GEP1. Recursos necesarios: Herramientas de planificación. GEP3 - Estudio de viabilidad y recursos Descripción: Este entregable incluirá el cálculo del presupuesto necesario para llevar a cabo el proyecto, teniendo en cuenta los costos humanos, materiales y tecnológicos. Además, se evaluará la viabilidad económica y la sostenibilidad del proyecto, analizando su impacto a largo plazo tanto a nivel financiero como ambiental, asegurando que se puedan sostener los beneficios del proyecto una vez implementado. Estimación: 22 horas. Secuencia: Dependiente de GEP2. Recursos necesarios: Información de costos, herramientas de análisis financiero. GEP4 - Documentación final e integración Descripción: En esta tarea se integrará toda la documentación generada a lo largo del proyecto en un único informe. Se llevará a cabo una revisión exhaustiva de todos los apartados del documento, corrigiendo y mejorando aquellos que requieran atención, para garantizar la coherencia y calidad del documento final del TFG. Se asegurará que todas las lecciones aprendidas y recomendaciones estén debidamente documentadas para futuros proyectos. Estimación: 25 horas. Secuencia: Dependiente de GEP3. Recursos necesarios: Documentación generada durante el proyecto, herramientas de edición y formato de documentos. 3.4.2 Desarrollo del Proyecto Fase 1: Análisis y planificación DF1.1 - Revisión de la metodología actual Descripción: Evaluar la metodología de testing vigente y detectar puntos débiles. Estimación: 14 horas. Secuencia: Tarea inicial, sin dependencias. Recursos necesarios: Documentación de la metodología actual, entrevistas con el equipo de QA. 21
DF1.2 - Análisis de carga de trabajo del equipo de QA Descripción: Analizar la distribución de tareas y tiempos durante el sprint. Estimación: 20 horas. Secuencia: Dependiente de DF1.1. Recursos necesarios: Herramientas de seguimiento de tareas, entrevistas con miembros del equipo. DF1.3 - Identificación de conocimiento clave Contexto: Actualmente, la información clave del proyecto se encuentra dispersa entre distintos perfiles del equipo, lo que dificulta su acceso y gestión. Descripción: Identificar qué información está centralizada en individuos. Estimación: 15 horas. Secuencia: Dependiente de DF1.1. Recursos necesarios: Entrevistas con el equipo de QA . DF1.4 - Análisis de herramientas y tecnologías existentes Descripción: Revisar compatibilidad y escalabilidad de herramientas actuales. Estimación: 12 horas. Secuencia: Dependiente de DF1.1. Recursos necesarios: Documentación de herramientas, entrevistas con el equipo técnico. Fase 2: Diseño de mejoras DF2.1 - Redefinición de procesos de testing Descripción: Crear guías y plantillas para la definición de casos de prueba. Estimación: 28 horas. Secuencia: Dependiente de DF1.1. Recursos necesarios: Documentación de pruebas actuales, feedback del equipo. DF2.2 - Diseño de estrategias de reorganización de carga Descripción: Diseñar nuevas formas de distribuir el trabajo del equipo QA. Estimación: 16 horas. Secuencia: Dependiente de DF1.2. Recursos necesarios: Información sobre carga de trabajo actual, herramientas de gestión. DF2.3 - Plan de documentación descentralizada Descripción: Crear un repositorio común para documentar el conocimiento clave. Estimación: 14 horas. Secuencia: Dependiente de DF1.3. Recursos necesarios: Herramientas de documentación, soporte técnico. 22
DF2.4 - Diseño de trazabilidad en los procesos de testing Descripción: Definir cómo se implementará la trazabilidad de las pruebas. Estimación: 14 horas. Secuencia: Dependiente de DF1.4. Recursos necesarios: Herramientas de gestión de requisitos y pruebas. DF2.5 - Planificación del seguimiento de mejoras Descripción: Diseñar cómo se evaluarán las mejoras y el progreso. Estimación: 16 horas. Secuencia: Dependiente de DF2.4. Recursos necesarios: Herramientas de seguimiento de proyectos. Fase 3: Implementación DF3.1 - Implementación de nuevas guías de test cases Descripción: Crear y distribuir las plantillas de casos de prueba entre el equipo. Estimación: 16 horas. Secuencia: Dependiente de DF2.1. Recursos necesarios: Documentación de pruebas, soporte del equipo. DF3.2 - Distribución de la carga de trabajo de QA Descripción: Aplicar las nuevas reglas para equilibrar el trabajo en los sprints. Estimación: 15 horas. Secuencia: Dependiente de DF2.2. Recursos necesarios: Herramientas de gestión de tareas, feedback del equipo. DF3.3 - Implementación del sistema de documentación Descripción: Configurar y migrar el conocimiento al nuevo repositorio centralizado. Estimación: 15 horas. Secuencia: Dependiente de DF2.3. Recursos necesarios: Herramientas de documentación, soporte técnico. DF3.4 - Creación de un panel de visibilidad del testing Descripción: Establecer un dashboard que muestre el estado de las pruebas en tiempo real. Estimación: 20 horas. Secuencia: Dependiente de DF2.4. Recursos necesarios: Herramientas de visualización de datos. 23
Fase 4: Capacitación y colaboración DF4.1 - Formación del equipo en nuevas prácticas y herramientas Descripción: Capacitar a los miembros del equipo sobre las nuevas prácticas y procesos de testing implementados, así como el uso de las herramientas actualizadas. Se organizarán sesiones de formación y se proporcionarán recursos adicionales para asegurar una comprensión adecuada de las metodologías y herramientas. Estimación: 28 horas. Secuencia: Dependiente de DF3.1. Recursos necesarios: Materiales de formación, presentaciones.. DF4.2 - Mejorar la comunicación interdepartamental Descripción: Establecer canales y reuniones regulares para coordinar entre QA y desarrollo, asegurando que la comunicación sea fluida y efectiva. Se implementarán reuniones semanales para revisar el progreso y resolver problemas. Estimación: 15 horas. Secuencia: Tarea continua a lo largo del proyecto, puede empezar después de DF3.3. Recursos necesarios: Herramientas de comunicación y tiempo de los participantes. Fase 5: Seguimiento DF5.1 - Monitoreo de la implementación de mejoras Descripción: Evaluar si las nuevas prácticas están mejorando la eficiencia del equipo. Se realizará un seguimiento regular. Estimación: 16 horas. Secuencia: Dependiente de DF3.1, DF3.2, DF3.3 y DF3.4. Recursos necesarios: Herramientas de análisis y métricas de rendimiento. DF5.2 - Identificación y gestión de riesgos Descripción: Monitorear los riesgos asociados con la implementación de nuevas prácticas, tales como la resistencia al cambio o la falta de comprensión de los nuevos procesos. Estimación: 14 horas. Secuencia: Dependiente de DF5.1. Recursos necesarios: Herramientas de gestión de riesgos y tiempo de los responsables del seguimiento. 24
DF5.3 - Ajustes en la reorganización de trabajo y documentación Descripción: Realizar ajustes en la distribución de tareas y la documentación según el feedback recibido del equipo y la efectividad observada de las nuevas prácticas. Estimación: 14 horas. Secuencia: Dependiente de DF5.1. Recursos necesarios: Documentación existente, feedback del equipo y tiempo de los involucrados. DF5.4 - Revisión de resultados y productividad Descripción: Comparar la productividad del equipo antes y después de la implementación de las mejoras. Estimación: 18 horas. Secuencia: Dependiente de DF5.1. Recursos necesarios: Herramientas de análisis de datos y tiempo de los responsables de la evaluación. 3.4.3 Tareas de cierre de proyecto TCP.1 - Evaluación final del proyecto Descripción: Documentar los resultados obtenidos tras la implementación de las mejoras y evaluar el éxito del proyecto. Se incluirán métricas de rendimiento y comparativas con el estado inicial para determinar el impacto de las acciones realizadas. Estimación: 25 horas. Secuencia: Dependiente de DF5.4. Recursos necesarios: Herramientas de análisis, datos recopilados durante el seguimiento, tiempo de los responsables de evaluación. TCP.2 - Entrega del proyecto Descripción: Preparar la documentación final del proyecto. Esto incluirá la creación de un informe completo que resuma todo el trabajo realizado, los resultados obtenidos y las lecciones aprendidas. Estimación: 90 horas. Secuencia: Dependiente de TCP.1 . Recursos necesarios: Documentación generada. TCP.3 - Preparación de la Defensa Descripción: Preparar la defensa del proyecto ante el tribunal. Estimación: 25 horas. Secuencia: Dependiente de TCP.2 . Recursos necesarios: Documentación final generada. 25
Cabe añadir que para el coste bruto por hora se ha tenido en cuenta ese 30% de más que incluye la seguridad social. Con esta información se puede obtener el coste por actividad a desarrollar durante el proyecto, anteriormente mostrada mediante Gantt, por lo que a costes de personal se refiere. ID Jefe de Proyecto (h) People Manager (h) QA Lead (h) QA Tester (h) BA (h) Desarrollador (h) Total (€) GEP 1 25 781,25 GEP 2 18 562,5 GEP 3 22 687,5 GEP 4 25 781,25 DF1. 1 14 339,64 DF1. 2 20 485,2 DF1. 3 1 6 6 2 370,59 DF1. 4 9 3 288,84 DF2. 1 3 20 5 697,51 DF2. 2 10 6 380,48 DF2. 3 14 382,76 DF2. 4 4 10 372,48 DF2. 5 4 8 4 415,88 DF3. 1 3 14 1 421,21 DF3. 2 3 3 9 377,01 DF3. 3 15 410,1 32
DF3. 4 2 12 6 493,94 DF4. 1 3 5 10 6 4 719,39 DF4. 2 15 487,05 DF5. 1 16 388,16 DF5. 2 3 4 4 3 368,39 DF5. 3 4 3 3 3 1 380,33 DF5. 4 6 12 485,94 TCP. 1 25 781,25 TCP. 2 90 2812,5 TCP. 3 25 781,25 Total horas 230 48 146 76 46 6 - Total € 7187,5 1.558,56 3.541,96 1.746,48 1.257,64 160,26 15.452,4 Tabla 6: Coste humano en € por actividad Además, se ha estimado una dedicación de aproximadamente 10 horas por parte del director del TFG, destinadas a consultas, revisión de entregables y sesiones de mentoría durante el desarrollo del proyecto. Obteniendo un total de 15.764,9 € 3.7.1.2 Costes recursos generales En este apartado se incluyen todos los costes indirectos y generales relacionados con el proyecto. Estos costes no están directamente vinculados a una tarea específica, sino que corresponden a necesidades generales que permiten llevar a cabo el proyecto de manera eficiente durante toda su duración. 33
Tenemos costes de espacio donde el trabajo se realizará desde la residencia del estudiante, quien vivirá en casa de sus padres durante el desarrollo del proyecto. Los únicos gastos asociados al espacio de trabajo serán los costes eléctricos, ya que no se incurrirá en gastos adicionales de alquiler o servicios de internet. Por tanto, el coste asociado al espacio de trabajo es mínimo y no se contempla una partida específica para este apartado. Por otro lado están los costes de equipamiento, se utilizará un portátil HP Altran con un procesador Intel i5 de octava generación. Para calcular el coste de utilizar este equipo a lo largo del proyecto, se ha estimado su amortización considerando una vida útil de 4 años [12], un total de 90 días hábiles con jornadas de 4 horas diarias, y una duración total del proyecto de 400 horas. Equipamiento Coste Inicial Amortización por año Amortización durante el proyecto Portátil HP Altran 600 € 150 € 37,5 € Tabla 7: Amortización equipamiento 3.7.2 Estimación de costes En esta sección se presenta una estimación de los costes asociados al proyecto, teniendo en cuenta tanto los costes directos ya identificados como las contingencias y los posibles riesgos que puedan surgir durante el desarrollo del proyecto. 3.7.2.1 Estimación de contingencias Para garantizar que el proyecto pueda enfrentar imprevistos o posibles desviaciones durante su ejecución, se ha añadido una contingencia del 10% sobre el coste total estimado. Esta contingencia permitirá cubrir cualquier eventualidad que no haya sido considerada en la planificación inicial, como retrasos en el cronograma, aumento en los costes de personal, o adquisición de materiales o herramientas adicionales no previstas. Si aplicamos el 10% de contingencias a cada tipo de coste nos queda el resultado siguiente: Tipo de coste Coste en € Contingencia Coste total en € Coste de personal 15.764,9 10% 17.341,39 Coste de equipamiento 37,5 € 10% 41,25 Tabla 8: Coste con contingencias 34
3.7.2.2 Estimación de riesgos Para cada riesgo tenemos una probabilidad de que ocurra. Diferenciamos entre baja, un 25% de probabilidades de suceder, media, un 50% y alta, un 75% de probabilidad. Obstáculo/Riesgo Tiempo Adicional Recurso Humano Implicado Probabilidad Coste total Resistencia al cambio +10 horas QA Testers Baja 57,45€ Falta de compromiso del equipo +2 horas Developers QA testers Baja 24,85€ Creación de documentación accesible +5 horas BA Baja 34,18€ Limitaciones de recursos +3 horas People Manager Media 48,71€ Impacto en la productividad +20 horas QA Testers Media 229,80€ Falta de comunicación clara +2 horas People Manager QA Lead Baja 28,37€ Fuga de conocimiento +4 horas QA Lead BA Alta 77,27€ Dependencia de herramientas específicas +3 horas QA tester Desarrollador Media 74,54€ Subestimación de tiempo y recursos +2 horas QA Lead Baja 12,13€ Inexperiencia en definición de metodologías y procesos +5 horas QA Lead Media 60,65€ Compatibilización TFG y trabajo profesional +15 horas Director/QA Lead Alta 153,75€ Total 71 horas - - 801,7€ Tabla 9: Estimación de costes por riesgo 35
3.7.3 Presupuesto final Una vez hecha la estimación de costes podemos obtener el presupuesto final. Tipo de coste Coste en € Costes recursos humanos 17.341,39 Costes recursos generales 41,25 Costes de riesgos 801,7 Total 18.184,34 Tabla 10: Presupuesto final 3.8. Sostenibilidad del Proyecto 3.8.1. Autoevaluación de Competencia Mi autoevaluación sobre el dominio de la competencia en sostenibilidad se sitúa en un nivel moderado. A lo largo de mi formación universitaria, he adquirido conocimientos en diversas áreas que me han proporcionado un entendimiento básico de los aspectos relacionados con la sostenibilidad en los proyectos. Este conocimiento me ha permitido comprender la importancia de integrar prácticas sostenibles en los diferentes procesos, tanto a nivel económico como social y ambiental. Además, considero que tengo una fuerte conciencia medioambiental, ya que siempre he sido consciente de la necesidad de reducir el impacto ecológico y de promover el uso responsable de los recursos. Sin embargo, reconozco que mi experiencia directa en proyectos específicamente orientados a mejorar la sostenibilidad es limitada. No he participado en iniciativas concretas que aborden esta temática de manera práctica, lo que me impide tener un enfoque más aplicado y profundo sobre cómo llevar la sostenibilidad a la práctica en diferentes sectores o tipos de proyectos. A pesar de estar familiarizado con los conceptos teóricos, me falta experiencia en la utilización de herramientas o métricas que se emplean para evaluar y medir el nivel de sostenibilidad en un proyecto o en una empresa. 3.8.2 Dimensión Económica El coste estimado para la realización del proyecto incluye gastos asociados a recursos humanos y equipamiento. Estos costes han sido calculados considerando una planificación ajustada a los recursos disponibles, con contingencias para mitigar posibles desviaciones. El coste final es competitivo respecto a proyectos similares, permitiendo que las fases del proyecto se lleven a cabo dentro de los plazos estimados sin comprometer la calidad. Actualmente, los aspectos de costes relacionados con la vida útil del proyecto se abordan mediante la amortización del equipamiento y la optimización de recursos humanos. 36
El equipo utilizado se ha estimado con una vida útil de cuatro años, y su coste se distribuye proporcionalmente a lo largo del tiempo de uso del proyecto. A nivel de estado del arte, las soluciones actuales buscan minimizar los costos de mantenimiento y operación a través de la utilización de tecnologías más eficientes, lo cual es una prioridad también en este proyecto. Económicamente, la solución propuesta mejorará en la optimización de costos a través de la automatización de ciertos procesos y la reducción de dependencia en recursos externos. El enfoque en la trazabilidad y la documentación clara permitirá una mayor eficiencia a la hora de abordar futuros desarrollos o ajustes, reduciendo significativamente el tiempo y los recursos necesarios. 3.8.3 Dimensión Social En lo personal, llevar a cabo este proyecto representa una oportunidad significativa para el desarrollo de competencias en áreas técnicas y de gestión, sobre todo en lo que respecta a la organización de grupos de trabajo y la mejora de procesos. Asimismo, se contribuirá a la adquisición de habilidades para abordar problemas en el ámbito de las pruebas de software, lo que favorecerá una mayor flexibilidad y una mejor capacidad para tomar decisiones en situaciones complicadas. En la actualidad, muchas empresas abordan el problema que se trata de forma dispersa y reactiva, generando así ineficiencias. La propuesta presentada en este proyecto tiene como objetivo aumentar la claridad en las pruebas y la asignación de tareas, lo que facilitará una mejora en la calidad de vida de los integrantes del equipo, aliviando el estrés derivado de la sobrecarga de trabajo y optimizando la gestión del tiempo. Se identifica una necesidad real para la implementación de este proyecto. Mejorar la trazabilidad y la organización del equipo de aseguramiento de la calidad es fundamental para incrementar la eficiencia y disminuir el tiempo perdido debido a una documentación inadecuada y una mala asignación de responsabilidades. Esta iniciativa responde a una necesidad específica dentro de la empresa y del sector en general, donde la optimización de procesos de pruebas y aseguramiento de la calidad se vuelve cada vez más prioritaria. 3.8.4 Dimensión Ambiental El impacto ambiental del proyecto ha sido estimado teniendo en cuenta los recursos energéticos que serán utilizados. Como el trabajo se realizará desde casa y utilizando un único equipo (portátil), el consumo eléctrico es relativamente bajo. Además, el proyecto no genera residuos físicos significativos, ya que todo se gestiona de manera digital. Una de las estrategias para minimizar el impacto ambiental ha sido la reutilización de recursos ya existentes. 37
El portátil utilizado para llevar a cabo el proyecto es un equipo que ya estaba en posesión del desarrollador, lo que evita la compra de nuevos equipos y la consecuente generación de residuos electrónicos. Actualmente, el problema de sostenibilidad en proyectos de desarrollo tiende a resolverse mediante la optimización del uso de recursos y la digitalización de procesos, lo cual reduce la necesidad de materiales físicos y la huella ecológica. 38
4. Modificación de la Planificación A lo largo del desarrollo del proyecto, se han presentado cambios importantes en comparación con la planificación inicial, principalmente debido a factores ajenos al TFG mismo. En particular, el equipo de aseguramiento de calidad involucrado en el entorno laboral ha enfrentado una carga de trabajo extremadamente alta durante varios meses. El aumento inesperado en la carga laboral ha hecho que no sea posible mantener la dedicación diaria que se había planificado originalmente, lo que ha frenado el progreso del trabajo y ha llevado a retrasar la entrega del proyecto. Esta situación ha resultado en una extensión del calendario de ejecución hasta el 12 de mayo de 2025, lo que permite ajustar el desarrollo del TFG sin poner en riesgo su calidad y objetivos. 4.1 Cambios aplicados en la planificación Aunque el orden establecido de las tareas ha permanecido igual, ha habido un cambio importante en la forma de trabajar del proyecto que no se había planificado al principio. Frente a una situación de elevada carga laboral, se ha visto la necesidad de modificar parte de la metodología de pruebas, haciéndola más adaptable y sostenible. Esta reorganización ha implicado tareas no anticipadas, como crear una nueva propuesta metodológica, informar al cliente sobre estos cambios, presentar oficialmente la nueva metodología y ofrecer una explicación detallada al equipo de QA para garantizar su correcta implementación. Estas actividades, aunque no estaban en el plan original, han sido esenciales para asegurar la continuidad y coherencia del proyecto. 4.2 Consecuencias e impacto en los costes Estos cambios han tenido un efecto económico menor, que se debe principalmente a dos riesgos que se manifestaron durante el avance del proyecto: en primer lugar, la falta de experiencia en la definición de la metodología, y en segundo, las dificultades para equilibrar el TFG con el trabajo profesional. Estos dos elementos han requerido un esfuerzo adicional estimado en 20 horas, un gasto que ya se había considerado y registrado en el análisis de riesgos en la sección 3. 7. 2. 2. Gracias a esta planificación, no se han presentado desviaciones significativas en el presupuesto, ni ha sido necesario modificar el presupuesto total del proyecto. 39
5. Análisis de la metodología actual Antes de identificar las limitaciones del proceso de testing, es importante presentar una visión objetiva de cómo se llevan a cabo actualmente las actividades de QA en el entorno de trabajo de la empresa. El proceso de testing se organiza de forma alineada con los sprints de desarrollo. Durante la primera semana, el equipo de QA valida los tickets que formarán parte del sprint y revisa su contenido. Si la información es insuficiente o ambigua, se solicita al equipo correspondiente que lo complete antes de continuar. En la segunda y tercera semana del sprint, los tickets pasan por las fases de prueba en diferentes entornos: ● Primero en Sandbox, donde el QA valida si el desarrollo cumple con los criterios establecidos. ● Si la validación es correcta, el ticket pasa a estar listo para Merge Request. ● Posteriormente, se despliega en el entorno de Staging, donde se realiza una última validación antes de mover el ticket a DONE. ● En caso de errores, el ticket se marca como KO y se devuelve al desarrollador. El flujo de trabajo puede visualizarse en el siguiente diagrama de flujo, que refleja las actividades, roles implicados y decisiones clave en el proceso de validación: Tras llevar a cabo las entrevistas y el análisis correspondiente, se ha obtenido una visión detallada de la situación actual del equipo QA en el proyecto de e-commerce. El trabajo realizado ha permitido identificar las principales deficiencias metodológicas, los desequilibrios en la carga de trabajo, la dependencia del conocimiento individual y la adecuación de las herramientas y tecnologías existentes. 40
Figura 3: Flujo Antiguo de Testing 5.1 Revisión de la Metodología Actual A partir de la información recabada, se ha constatado que no existe un sistema formal y estructurado que permita documentar de manera ordenada los casos de prueba y los resultados obtenidos. Actualmente, el trabajo de testing se registra mediante comentarios individuales en los tickets, lo que dificulta la visibilidad del progreso y la calidad de las pruebas realizadas. ● Falta de trazabilidad: La ausencia de documentación estructurada impide hacer un seguimiento histórico de los errores detectados, su evolución y las acciones correctivas implementadas. ● Dificultad en la evaluación del alcance de las pruebas: Sin registros formales, resulta complejo determinar qué áreas del sistema se han cubierto durante las pruebas y cuáles requieren mayor atención. ● Dependencia del criterio individual: La ejecución de las pruebas depende en gran medida del enfoque y juicio personal de cada QA, lo que genera inconsistencias en el proceso. Estas limitaciones afectan directamente la capacidad del equipo para planificar y gestionar los sprints con eficiencia. 41
Un control claro permite, al equipo QA, determinar de manera rápida el estado de las pruebas y, asigne prioridad a las áreas críticas de acuerdo con las necesidades del proyecto. Tener una documentación bien estructurada garantiza que se pueda seguir el rastro de los casos de prueba que han sido completados, aquellos que han fallado y qué módulos necesitan atención urgente. Además, facilita la comunicación del progreso a los stakeholders, mejorando la gestión del tiempo y los recursos. En un e-commerce de venta de productos, un ejemplo práctico sería implementar un dashboard que refleje el estado del testing en tiempo real. Por ejemplo, la plataforma podría mostrar que el módulo de pagos tiene un 70% de casos de prueba completados, un 10% en progreso y un 20% pendiente de revisión. Esto permite al equipo QA y a los responsables del proyecto tomar decisiones basadas en datos, centrándose en resolver los problemas más críticos antes del lanzamiento del producto. Este enfoque garantiza una gestión más eficiente del proceso y refuerza la confianza en el resultado final. A continuación, se detalla cada sección de la plantilla diseñada para cubrir estas necesidades y maximizar la efectividad del equipo QA. 7.1.1 Explicación de las Partes de la Plantilla Información Básica del Caso de Prueba Esta sección incluye datos fundamentales para identificar y categorizar el caso de prueba: ● ID del Caso de Prueba: Código único para diferenciar cada caso. ● Título: Resumen breve del objetivo de la prueba. ● Descripción: Propósito del caso y su relación con los objetivos del proyecto. ● Prioridad: Nivel de importancia del caso según el impacto en el sistema. ● Módulo Asociado: Funcionalidad o área específica del software que se prueba. ● Autor y Fecha: Responsable de la creación y actualización del caso. Precondiciones Configura el estado inicial necesario antes de ejecutar la prueba (por ejemplo, datos de usuario, configuración del entorno). Pasos Detallados Secuencia de acciones a realizar durante la prueba, descrita de manera precisa para evitar interpretaciones ambiguas. Resultados Esperados Resultados previstos tras la ejecución de cada paso. Deben ser concretos y verificables. 48
Datos de Prueba Valores específicos que se usarán durante la prueba, como credenciales de usuario o configuraciones del sistema. Criterios de Aceptación Condiciones necesarias para considerar que el caso de prueba ha sido exitoso. Registro de Resultados ● Estado final del caso: Pendiente, aprobado, fallido o bloqueado. ● Evidencias: Capturas de pantalla, videos o registros que respalden los resultados obtenidos. Notas Adicionales Observaciones o comentarios que puedan ser útiles para revisiones futuras o para entender problemas específicos encontrados. 7.1.2 Ejemplo de Plantilla Completa ID del Caso de Prueba: P 00140-0001 Título: Verificación del inicio de sesión con credenciales válidas Descripción: Este caso de prueba tiene como objetivo confirmar que los usuarios registrados pueden acceder al sistema utilizando credenciales válidas. Prioridad: Alta Módulo Asociado: Homepage Login Autor: Xavier Aguilar Fecha de Creación: 25/11/2024 Última Actualización: N/A Precondiciones: ● El usuario debe estar registrado previamente en el sistema con un correo electrónico válido y una contraseña asociada. Pasos Detallados: 1. Abrir la página de inicio de sesión del sistema. 2. Introducir el correo electrónico válido en el campo correspondiente: [email protected]. 3. Introducir la contraseña válida en el campo correspondiente: test1234. 4. Hacer clic en el botón "Iniciar sesión". 49
Resultados Esperados: ● El sistema redirige al dashboard del usuario. ● El nombre del usuario aparece en la parte superior derecha de la pantalla como confirmación de inicio de sesión exitoso. Datos de Prueba: ● Correo electrónico: [email protected] ● Contraseña: ****** Criterios de Aceptación: ● El usuario es redirigido correctamente al dashboard. ● No se presentan mensajes de error inesperados. Registro de Resultados: ● Estado: Aprobado ● Evidencias: Captura de pantalla del dashboard mostrando el nombre del usuario y los elementos de navegación. Notas Adicionales: ● Durante la ejecución, se observó un tiempo de carga de 5 segundos, superior al límite aceptable de 3 segundos. ● Se recomienda revisar el rendimiento del sistema en esta funcionalidad. 7.2 Integración con Xray XRay se destaca sobre otras herramientas principalmente por su integración nativa con JIRA, lo que permite gestionar tanto los casos de prueba como los defectos y los requisitos dentro del mismo sistema. Esto elimina la necesidad de herramientas externas y facilita la colaboración entre equipos de desarrollo y QA, ya que ambos pueden trabajar con los mismos tickets y flujos de trabajo. Uno de sus mayores beneficios es la trazabilidad completa entre requisitos, pruebas y defectos. Esto no solo mejora la visibilidad del progreso del testing, sino que también permite generar informes detallados sobre la cobertura de requisitos y el estado de las pruebas, lo cual es esencial en sectores como la fabricación de dispositivos médicos, donde las auditorías son estrictas [13]. 50
También es altamente compatible con herramientas de automatización como Selenium, Cucumber y Jenkins, lo que permite ejecutar pruebas automatizadas directamente desde la herramienta y registrar los resultados sin necesidad de interfaces adicionales [14]. Un complemento clave de esta integración es la posibilidad de diseñar dashboards dinámicos que utilicen queries avanzadas para ofrecer información en tiempo real sobre el estado de los tickets, tanto a nivel diario como semanal y mensual. Estas visualizaciones permiten identificar patrones, prever cuellos de botella y optimizar los recursos del equipo QA y del equipo. A continuación se nombran diferentes queries que se usarán para generar el dashboard de seguimiento: Número Total de Tickets Creados y Test Cases Creados 𝑝𝑟𝑜𝑗𝑒𝑐𝑡 = "𝑃𝑅𝑂𝐽𝐸𝐶𝑇_𝐾𝐸𝑌" 𝐴𝑁𝐷 𝑖𝑠𝑠𝑢𝑒𝑡𝑦𝑝𝑒 𝐼𝑁 ("𝑇𝑎𝑠𝑘", "𝑇𝑒𝑠𝑡") 𝐴𝑁𝐷 𝑐𝑟𝑒𝑎𝑡𝑒𝑑 >= 𝑠𝑡𝑎𝑟𝑡𝑂𝑓𝑀𝑜𝑛𝑡ℎ() Esta query permite visualizar la cantidad total de tickets creados junto con los test cases generados durante un periodo, como el mes actual, ayudando a evaluar si el trabajo generado está siendo adecuadamente respaldado por pruebas. Para esta información, se sugiere un gráfico de barras agrupadas, donde cada barra representa la evolución semanal o diaria del número de tickets y test cases creados. Esto facilita la comparación directa entre ambos elementos, identificando rápidamente si hay un desbalance que pueda comprometer la cobertura de pruebas. Este enfoque ayuda a ajustar recursos de forma efectiva y asegura que todas las tareas cuentan con validación adecuada. Número de Test Cases en OK y KO 𝑝𝑟𝑜𝑗𝑒𝑐𝑡 = "𝑃𝑅𝑂𝐽𝐸𝐶𝑇_𝐾𝐸𝑌" 𝐴𝑁𝐷 𝑖𝑠𝑠𝑢𝑒𝑡𝑦𝑝𝑒 = "𝑇𝑒𝑠𝑡 𝐸𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛" 𝐴𝑁𝐷 𝑠𝑡𝑎𝑡𝑢𝑠 𝐼𝑁 ("𝑂𝐾", "𝐾𝑂") 𝐴𝑁𝐷 𝑒𝑥𝑒𝑐𝑢𝑡𝑒𝑑 >= 𝑠𝑡𝑎𝑟𝑡𝑂𝑓𝑊𝑒𝑒𝑘() Esta query muestra el estado de los test cases ejecutados durante una semana, dividiéndolos entre los que pasaron (OK) y los que fallaron (KO), proporcionando una visión clara de la calidad de las entregas. Un gráfico circular es ideal para destacar la proporción entre OK y KO, mientras que un gráfico de barras puede segmentar los resultados por módulos o funcionalidades. Esto ayuda no solo a identificar las áreas más problemáticas, sino también a priorizar correcciones, permitiendo al equipo de desarrollo mejorar su desempeño y reducir defectos recurrentes. 51
Estados de los Tickets 𝑝𝑟𝑜𝑗𝑒𝑐𝑡 = "𝑃𝑅𝑂𝐽𝐸𝐶𝑇_𝐾𝐸𝑌" 𝐴𝑁𝐷 𝑖𝑠𝑠𝑢𝑒𝑡𝑦𝑝𝑒 𝐼𝑁 ("𝑇𝑎𝑠𝑘", "𝐵𝑢𝑔", "𝑇𝑒𝑠𝑡") 𝐴𝑁𝐷 𝑠𝑡𝑎𝑡𝑢𝑠 𝐼𝑁 ("𝑇𝑜 𝐷𝑜", "𝐼𝑛 𝑃𝑟𝑜𝑔𝑟𝑒𝑠𝑠", "𝑄𝐴 𝑇𝑒𝑠𝑡𝑖𝑛𝑔", "𝐷𝑜𝑛𝑒") 𝐴𝑁𝐷 𝑢𝑝𝑑𝑎𝑡𝑒𝑑 >= 𝑠𝑡𝑎𝑟𝑡𝑂𝑓𝑆𝑝𝑟𝑖𝑛𝑡() Esta query identifica la cantidad de tickets distribuidos en los diferentes estados del flujo de trabajo, como "To Do", "In Progress", "QA Testing" y "Done", para un periodo como el sprint actual. Un gráfico de barras apiladas permite visualizar claramente la distribución de los tickets, mostrando tanto el progreso global como posibles acumulaciones en estados intermedios. Esta información ayuda a detectar cuellos de botella y ajustar recursos para garantizar que los tickets fluyan de manera eficiente hacia su finalización, mejorando la gestión del sprint. 7.3 Herramientas de Documentación Descentralizada Si bien ya hay en uso una herramienta de documentación en el proyecto, no se le da el uso necesario y por ende pierde eficiencia y oportunidades de mejora. A continuación, se presenta una tabla que resume las ventajas y limitaciones de 3 de las principales herramientas de Documentación. Herramienta Ventajas Limitaciones Confluence ❖ Orientado a equipos grandes con funciones avanzadas de edición y estructuración de documentos. ❖ Integración nativa con herramientas Atlassian como Jira y Trello. ❖ Funciones robustas de control de versiones y permisos. ❖ Escalabilidad y seguridad a nivel empresarial. ❖ Curva de aprendizaje más pronunciada debido a su complejidad. ❖ Menor flexibilidad para personalización comparada con Notion. ❖ Costos más elevados para planes avanzados 52
Notion ❖ Gran flexibilidad y personalización con un sistema basado en bloques. ❖ Ideal para pequeñas empresas o usuarios individuales. ❖ Funciones integradas como bases de datos y tableros Kanban. ❖ Interfaz intuitiva y colaboración en tiempo real. ❖ Limitaciones en la gestión de grandes equipos o documentación compleja. ❖ Integraciones menos profundas con herramientas específicas de software corporativo. ❖ Rendimiento reducido con bases de datos muy grandes o complejas Google Workspace ❖ Ecosistema integrado que incluye correo electrónico, almacenamiento en la nube, calendarios y herramientas de colaboración como Docs, Sheets y Meet. ❖ Amplia escalabilidad y accesibilidad multiplataforma. ❖ Enfoque en comunicación con Google Meet y Chat. ❖ Funcionalidades limitadas para crear documentación estructurada y bases de conocimiento robustas. ❖ Dependencia de Internet para la mayoría de las funcionalidades. ❖ Menor nivel de personalización y control avanzado comparado con Confluence y Notion Al analizar las alternativas, Confluence destaca como la herramienta más adecuada para implementar un plan de documentación descentralizada en este proyecto. Confluence permite organizar el conocimiento de manera jerárquica mediante árboles de páginas [15], ideal para gestionar grandes volúmenes de documentación técnica. Esta estructura es particularmente útil en proyectos complejos, donde se requiere mantener una relación ordenada entre diferentes secciones de información . [16] Se integra de forma nativa con Jira, lo que permite enlazar fácilmente tareas, requisitos y documentación. Esto garantiza una trazabilidad total en el ciclo de vida del proyecto, facilitando la gestión y actualización constante de la información La herramienta ofrece permisos granulares a nivel de usuario y página, asegurando que solo los miembros autorizados puedan editar o acceder a la información. Además, su historial de versiones facilita el control de cambios y auditoría [17]. 53
También permite la edición simultánea, comentarios en línea y notificaciones en tiempo real, lo que promueve un trabajo colaborativo eficiente. La posibilidad de reutilizar contenido mediante macros agiliza la creación y el mantenimiento de la documentación [18]. Si bien Notion destaca por su flexibilidad y facilidad de uso, y Google Workspace por su integración general con herramientas cotidianas, ambas soluciones presentan limitaciones significativas para proyectos técnicos complejos. Confluence, por otro lado, sobresale por su estructura avanzada, integración nativa con el software principal del proyecto y funcionalidades colaborativas, lo que la convierte en la opción más adecuada para la implementación del plan. 7.4 Diseño de Estrategias de Reorganización de Carga En el contexto actual del equipo QA, se observa un desequilibrio relevante en la distribución de la carga de trabajo a lo largo del sprint. Al inicio del sprint, los QA suelen tener una carga baja debido a que los tickets se encuentran en fase de desarrollo y no es posible realizar pruebas inmediatas. Sin embargo, hacia el final del sprint, la acumulación de tickets listos para prueba provoca una carga de trabajo elevada, generando cuellos de botella, presión adicional y riesgos de calidad. Para mitigar este problema y optimizar la distribución de tareas, se propone una estrategia que maximice la productividad del equipo QA al inicio del sprint, preparándolo para afrontar las etapas críticas de manera eficiente. La solución planteada se estructura en dos áreas clave: preparación proactiva y mantenimiento del repositorio de documentación. Preparación de Casos de Prueba (Test Cases) Durante la fase inicial del sprint, cuando los tickets están en desarrollo y no pueden ser probados, los QA se dedicarán a entender a fondo los tickets asignados. Esta tarea implica revisar los requisitos, identificar los criterios de aceptación y, en función de ellos, diseñar test cases detallados con pasos específicos y resultados esperados. Esta actividad permitirá anticipar las pruebas necesarias, reduciendo significativamente la carga de trabajo durante las últimas etapas del sprint. Los test cases diseñados servirán como referencia para otros miembros del equipo, facilitando la ejecución de pruebas en caso de imprevistos como ausencias o reasignaciones de tareas. 54
Actualización del Repositorio de Documentación en Confluence Con el fin de complementar la preparación de pruebas, se sugiere destinar una parte del tiempo del inicio del sprint a la revisión y mejora de la documentación actual en Confluence. Esta tarea incluye: ● Documentar nuevas características que se han integrado en el proyecto. ● Actualizar o corregir cualquier documentación desactualizada o incompleta que pueda obstaculizar la realización de pruebas y el aprendizaje de nuevos miembros del equipo. ● Elaborar o actualizar guías sobre procedimientos para flujos de trabajo complejos, asegurando que la información esté centralizada y accesible. Esto permite utilizar de manera efectiva el tiempo que se tiene al inicio del sprint, distribuyendo las tareas de forma más equitativa y reduciendo el estrés y los posibles errores en las etapas finales. Además, la implementación de esta estrategia fomentará una mayor anticipación y preparación, fortaleciendo el proceso de testing y mejorando la calidad del producto final. Esta estrategia optimiza la gestión de las cargas de trabajo de los QA al aprovechar el comienzo del sprint para actividades de preparación y documentación, facilitando así la realización de pruebas en las fases posteriores y contribuyendo a un flujo de trabajo más sostenible y organizado. 55
8. Metodología Como resultado de la evaluación del proceso de pruebas actual y los requisitos mencionados antes, se ha establecido un método que se adapta a la realidad del equipo. El método elegido se adapta al ciclo del sprint y se divide en dos fases funcionales. En la primera semana del sprint, se lleva a cabo la validación de los tickets que han sido incorporados en ese ciclo. Después de la validación, el QA verifica si hay un caso de prueba asociado a cada ticket. Si no hay uno, se desarrolla y se agrega al plan de pruebas correspondiente. Si ya existe un caso de prueba, se comprueba si fue creado durante el sprint en curso. Si no es el caso, se revisa para asegurar que siga siendo relevante y completo, considerando nuevas funciones. Durante la segunda y tercera semana del sprint, cuando los tickets están listos para ser probados, el QA comienza el proceso de validación. Si el ticket todavía no tiene un caso de prueba, se crea en ese instante. Luego, se establece una ejecución de prueba para validar el comportamiento del ticket. Si la ejecución tiene éxito, se valida el ticket y se registra su ejecución en el plan de pruebas. Si no es así, se considera que el ticket no ha pasado la validación y se envía al desarrollador para que haga las correcciones necesarias. Figura 3: Flujo de trabajo QA por sprints 56
Al mismo tiempo que se documentan en Confluence varios aspectos funcionales importantes del producto, con la intención de crear un repositorio que sea accesible y útil para el equipo. Esta información incluye datos sobre los métodos de pago por país, procesos complejos como las devoluciones, y la explicación de nuevas funciones que se han añadido. Este trabajo se realiza principalmente en la primera y segunda semana del sprint, y ayuda a reducir la dependencia del conocimiento individual,facilita la capacitación de nuevos QA y mejora la autonomía del equipo en su conjunto. La metodología implica diferentes perfiles profesionales ya establecidos en el proyecto. Los QA Testers son los encargados de crear test cases, ejecutar pruebas y validar tickets. El QA Lead supervisa que se cumplan los pasos definidos, revisa casos más complejos y garantiza que el proceso sea trazable y coherente. Los desarrolladores reciben los tickets que no pasaron la validación y deben implementar las correcciones que sean necesarias. Por otro lado, el Business Analyst (BA) ayuda a definir con precisión los requisitos para que los test cases estén bien fundamentados, mientras que el People Manager gestiona los recursos del equipo y ayuda a resolver posibles bloqueos o desvíos en la ejecución del proceso. Como complemento al proceso definido, la metodología incorpora el uso de dashboards en Xray para disponer de una visión consolidada del estado del testing al finalizar cada sprint. A través de estas vistas se pueden consultar datos clave como la cobertura de ejecución, los resultados agregados de los test cases y la evolución general del sprint en términos de calidad. Figura 4: Ejemplo de Dashboard 57
11. Visión y valoración del equipo sobre la metodología Durante el transcurso del proyecto, he recibido diversos comentarios por parte de miembros del equipo que participaron en la validación y el desarrollo. Estos comentarios han surgido de manera natural durante las reuniones, en canales de comunicación internos o al aplicar directamente la metodología. A continuación, se recogen algunos mensajes representativos: “Muy buen trabajo estructurando todo. Da mucha claridad.” — Javier Redondo, Project Manager “Los test cases ahora sí tienen sentido común. Buen avance. Quizás estaría bien destacar mejor los casos más críticos.” — QA “Gracias por documentar bien lo de devoluciones, lo consulté ayer. Quizás podríamos añadir algún ejemplo visual.” — María Montes, Developer “El nuevo flujo es mucho más fácil de seguir. Buen trabajo :).” — Brian Romero, Developer El feedback recibido ha confirmado que la estructura, la documentación y los flujos de trabajo diseñados aportan valor al equipo y aumentan su autosuficiencia. Además, las recomendaciones proporcionadas han ayudado a seguir ajustando la propuesta, reforzando el enfoque iterativo y de mejora continua que ha guiado todo el desarrollo del proyecto. 64
12. Trabajo futuro Tras la implementación de la nueva metodología de testing y la estandarización de los test cases mediante Xray, se abren nuevas posibilidades de evolución del proceso de calidad en la organización. Una de las líneas más relevantes a futuro es la automatización de pruebas manuales, especialmente aquellas que son repetitivas o estables. Como primer paso, se sugiere automatizar pruebas de tipo sanity, que permiten comprobar rápidamente la estabilidad del sistema después de cada despliegue. Gracias a la existencia de test cases detallados, ya documentados paso a paso, resulta viable transformarlos en scripts reutilizables que se puedan ejecutar automáticamente [19]. Más allá del sanity, se plantea el desarrollo de un plan de automatización para flujos funcionales críticos, como el proceso de compra, el inicio de sesión o las devoluciones. Para ello, sserá necesario construir una matriz de priorización que ayude a decidir qué pruebas automatizar primero, teniendo en cuenta factores como la frecuencia de uso, la importancia funcional o la estabilidad del flujo. Esta estrategia permitirá escalar la automatización de forma progresiva, maximizando su impacto en la eficiencia del equipo QA y en la calidad del producto. Una estrategia adicional es la proyección de la metodología a otros equipos o proyectos dentro de la organización. Aunque la aplicación actual se ha enfocado en un caso particular de comercio electrónico, los principios metodológicos definidos son lo suficientemente flexibles y podrían ser implementados, con ajustes menores, en una variedad amplia de productos digitales que adopten el desarrollo ágil. Esta adaptabilidad facilitaría una mayor coherencia entre los equipos y fortalecería la cultura de calidad en la empresa. Por último, se explora la opción de aprovechar los materiales generados durante el proyecto como herramientas de capacitación, tanto para los nuevos integrantes del equipo de QA como para los roles intermedios que necesiten participar en actividades de pruebas. La documentación en Confluence, junto con los diagramas de flujo, los planes de prueba y los test cases estandarizados, representa una base sólida para desarrollar programas de capacitación técnica que optimicen el tiempo de integración y garanticen una comprensión clara y uniforme del proceso. 65
13. Conclusiones 13.1 Cumplimiento de los objetivos del proyecto A lo largo del desarrollo del Trabajo de Fin de Grado se han alcanzado satisfactoriamente todos los objetivos específicos definidos al inicio del proyecto: Analizar el funcionamiento actual del equipo de QA, identificando las principales limitaciones en su metodología de trabajo. ● Se ha realizado un análisis detallado del proceso de testing, detectando deficiencias como la falta de visibilidad, la escasa trazabilidad, la documentación descentralizada y una sobrecarga significativa al final de cada sprint. Este diagnóstico ha servido de base para todas las decisiones posteriores. Diseñar una estructura estandarizada para la documentación de test cases. ● Se ha creado un modelo general y reutilizable para la creación de test cases en Xray, lo que ha permitido homogeneizar su redacción, facilitar su mantenimiento y favorecer el trabajo colaborativo. Establecer un sistema de documentación accesible y centralizado. ● Se ha habilitado un repositorio común en Confluence donde se almacena la información clave del proceso de testing, facilitando el acceso por parte de todo el equipo y reduciendo la dependencia del conocimiento individual. Definir un nuevo flujo de trabajo del equipo QA. ● Se ha diseñado una metodología estructurada, con tareas distribuidas a lo largo del sprint, revisión en etapas tempranas y mayor colaboración entre QA y desarrollo, lo que ha permitido optimizar el proceso sin comprometer la calidad. Aplicar principios de metodologías ágiles. ● La propuesta metodológica se basa en principios ágiles como la iteración, la mejora continua y la flexibilidad en la planificación. Además, se ha diseñado una versión adaptativa para situaciones de sobrecarga, que ha demostrado ser útil en entornos exigentes. Fomentar una mejor comunicación y autonomía dentro del equipo. ● Se han introducido mecanismos que mejoran la colaboración entre perfiles, la visibilidad del estado del testing y la incorporación de nuevos miembros. Todo ello ha contribuido a una mayor autonomía operativa del equipo QA. 66
13.2 Competencias técnicas trabajadas Durante el proyecto se han desarrollado distintas competencias clave de la especialidad de Sistemas de Información, todas ellas aplicadas en un entorno profesional real: CSI2.1: Demostrar comprensión y aplicar los principios y técnicas de gestión de calidad e innovación tecnológica en las organizaciones. ● A través del rediseño del proceso de testing he podido aplicar de forma práctica los principios de calidad y mejora continua, buscando siempre optimizar la trazabilidad, la reutilización de pruebas y la estandarización de tareas dentro del equipo. Ha sido una oportunidad para implementar soluciones reales con impacto directo en la eficiencia del equipo QA. CSI2.2: Concebir, desplegar, organizar y gestionar sistemas y servicios informáticos en contextos empresariales o institucionales para mejorar sus procesos de negocio; responsabilizarse de su puesta en marcha y mejora continua, valorando su impacto económico y social. ● He diseñado y desplegado una metodología que se integra dentro del flujo de trabajo real de la empresa, con el objetivo de mejorar los procesos internos del equipo QA. Me he responsabilizado de su estructuración, implementación parcial y evaluación, valorando siempre su aplicabilidad práctica y sostenibilidad a largo plazo. CSI3.1: Demostrar comprensión de los principios de evaluación de riesgos y aplicarlos correctamente en la elaboración y ejecución de planes de actuación. ● Durante el proyecto he identificado riesgos reales asociados al contexto laboral, como la sobrecarga de trabajo o la dependencia del conocimiento individual, y he planteado medidas preventivas y correctivas. He aprendido a valorar su impacto tanto en la planificación como en el presupuesto del proyecto. CSI3.5: Proponer y coordinar cambios para mejorar la explotación del sistema y de las aplicaciones. ● He liderado la propuesta de varios cambios organizativos que han mejorado la manera en que el equipo QA utiliza las herramientas (Xray, Confluence) y gestiona su día a día. Estos cambios han contribuido a una mejor visibilidad del trabajo y a una explotación más eficiente del sistema de testing. 67
CSI1: Demostrar comprensión y aplicar los principios y prácticas de las organizaciones, actuando como enlace entre los perfiles técnicos y de gestión, y participando activamente en la formación de los usuarios. ● He ejercido de puente entre diferentes perfiles del equipo (QA, desarrollo, análisis funcional), facilitando la comunicación, alineando objetivos y ayudando a documentar procesos clave para que sean comprensibles y reutilizables. También he trabajado para que la incorporación de nuevos miembros sea más ágil gracias a los recursos generados. 13.3 Valoración personal del proyecto La realización de este Trabajo de Fin de Grado ha supuesto un reto importante, pero también una experiencia muy enriquecedora tanto a nivel técnico como personal. Me ha permitido aplicar muchos de los conocimientos adquiridos durante la carrera en un contexto real y, al mismo tiempo, aprender cosas nuevas que difícilmente habría podido experimentar solo desde el entorno académico. Uno de los aspectos más destacables ha sido poder trabajar sobre un caso real, dentro de mi entorno laboral, y ver cómo las mejoras propuestas tenían un impacto directo y tangible en el día a día del equipo. Esto me ha motivado mucho más a cuidar cada detalle, sabiendo que no era solo un ejercicio académico, sino una oportunidad para aportar valor real. También ha sido un desafío compaginar el desarrollo del TFG con una carga laboral elevada, lo que me obligó a reorganizar la planificación inicial y adaptar algunas fases del trabajo. A pesar de las dificultades, creo que esto ha reforzado mi capacidad de adaptación y gestión personal del tiempo, competencias que valoro tanto como las técnicas. Estoy especialmente satisfecho de haber podido diseñar una metodología que no solo responde a una necesidad concreta del equipo QA, sino que también deja una base sólida para seguir mejorando en el futuro. Ver que la documentación, los test cases o los flujos diseñados ya se están utilizando es algo que me hace sentir orgulloso del trabajo realizado. En definitiva, este proyecto me ha servido para cerrar una etapa académica con una experiencia que ha sido útil, realista y con sentido práctico. Me ha ayudado a crecer como profesional y me ha permitido ver la importancia de las metodologías bien diseñadas como una herramienta clave para mejorar la calidad y la eficiencia en equipos técnicos. 68
14. Bibliografía [1] campusMVP. (2015, mayo 22). GAMBADAS: Therac-25, la máquina de radiación asesina. campusMVP.es. https://www.campusmvp.es/recursos/post/gambadas-therac-25-la-maquina-de-radiacion-asesina.aspx [2] QUÉ ES EL TESTING DE SOFTWARE Y POR QUÉ ES TAN IMPORTANTE EN EL DESARROLLO DE SOFTWARE – Pacifitic. (s. f.). https://pacifitic.org/que-es-el-testing-de-software-y-por-que-es-tan-importante-en-el-desarrollo-de-softwa re/ [3] Pruebas de software: Tipos e importancia | UNIR México. (s. f.). https://mexico.unir.net/noticias/ingenieria/pruebas-software/ [4] Waterfall Software Testing. (2019, junio 19). GeeksforGeeks. https://www.geeksforgeeks.org/waterfall-software-testing/ [5] Scrum Testing. (2019, septiembre 25). GeeksforGeeks. https://www.geeksforgeeks.org/scrum-testing/ [6] SDLC V-Model—Software Engineering. (2018, julio 13). GeeksforGeeks. https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/ [7] Atlassian. (s. f.). How to create and manage test cases with Xray and Jira. Atlassian. https://www.atlassian.com/devops/testing-tutorials/jira-xray-integration-manage-test-cases [8] Atlassian. (s. f.). Get Started with Confluence—A Beginner’s Guide. Atlassian. https://www.atlassian.com/software/confluence/resources/guides/get-started/overview [9] Slack. (s. f.). ¿Qué es Slack? Slack Help Center. https://slack.com/intl/es-es/help/articles/115004071768-%C2%BFQu%C3%A9-es-Slack [10] Salario en España—Salario Medio. (s. f.). Talent.com. https://es.talent.com/salary [11] Seguridad Social: Cotización / Recaudación de Trabajadores. (s. f.). https://www.seg-social.es/wps/portal/wss/internet/Trabajadores/CotizacionRecaudacionTrabajadores/48 410 [12] Cómo calcular la amortización de equipos informáticos. (2022, noviembre 17). https://www.holded.com/es/blog/amortizacion-de-equipos-informaticos [13] The complete guide to Xray Test Management for Jira—Xray Blog. (s. f.). https://www.getxray.app/blog/xray-test-management-for-jira [14] idalko. (2020, mayo 14). The Comprehensive Guide to Xray for Jira: The Leading Test Management Tool. Idalko. https://idalko.com/xray-for-jira/ [15] Atlassian. (s. f.). Technical Documentation with Confluence. Atlassian. https://www.atlassian.com/software/confluence/use-cases/technical-documentation [16] Abdullahi, A. (2024, abril 26). Notion vs Confluence (2024): Which Tool Should You Choose? TechRepublic. https://www.techrepublic.com/article/confluence-vs-notion/ 69
[17] Use Confluence for technical documentation | Confluence Cloud. (s. f.). Atlassian Support. https://support.atlassian.com/confluence-cloud/docs/use-confluence-for-technical-documentation/ [18] Confluence vs Notion: Ease of Use, Features, Pricing & More. (2024, septiembre 15). Penguin Mind. https://penguinmind.com/notion/notion-vs-confluence/ [19] Ali, H. M., Hamza, M. Y., & Rashid, T. A. (2024). A Comprehensive Study on Automated Testing with the Software Lifecycle (No. arXiv:2405.01608). arXiv. https://doi.org/10.48550/arXiv.2405.01608 70