bgstm

BGSTM (Better Global Software Testing Methodology) es un marco de prueba y una base de conocimientos destinado a organizar el trabajo de calidad desde la planificación hasta la presentación de informes. Su idea central es mantenerse agnóstico respecto a la metodología: el mismo ciclo de vida de seis fases está pensado para funcionar bajo modelos de entrega Ágil, Scrum, Waterfall o híbridos sin imponer un proceso de desarrollo particular al equipo. El marco define exactamente seis fases canónicas, y la documentación enfatiza que los dominios especializados reutilizan estas fases en lugar de añadir nuevas. Son: planificación de pruebas (alcance, estrategia, riesgos, recursos, cronogramas); desarrollo de casos de prueba (escenarios y casos trazables); preparación del entorno de prueba (infraestructura, herramientas, acceso, datos de prueba); ejecución de pruebas (ejecución de pruebas, recopilación de evidencia, gestión de defectos); análisis de resultados de pruebas (interpretación de resultados, tendencias y señales de calidad); y presentación de resultados de pruebas (comunicación de hallazgos para respaldar decisiones de lanzamiento). La última fase se retroalimenta en la primera para el siguiente ciclo. Los principios fundamentales declarados incluyen cobertura de extremo a extremo del ciclo de vida de la calidad, mantenimiento de la trazabilidad entre requisitos, pruebas, resultados, defectos, evidencia y decisiones, escalado de la rigurosidad de las pruebas según el riesgo, informes basados en evidencia y adopción práctica que comienza con la metodología y las plantillas antes de añadir herramientas. El repositorio consiste principalmente en documentación. Proporciona guías por fase, guías de metodología que cubren Ágil, Scrum, Waterfall y una comparación de ellas, plantillas reutilizables de prueba para planes, casos, informes, riesgos y artefactos de trazabilidad, y ejemplos trabajados. Un ejemplo aplica las seis fases a la validación semántica de ETL y tuberías de datos; el README señala explícitamente que esto no es una fase adicional. Junto con la metodología, el proyecto aloja una aplicación de referencia de código abierto que muestra cómo partes del marco pueden representarse en software. Combina un frontend de React, un backend de FastAPI y una base de datos PostgreSQL, y cubre características de trazabilidad, preparación para lanzamiento y paneles de KPI de calidad, control de acceso basado en roles, notificaciones y exportaciones. La configuración es impulsada por scripts: un script de shell para macOS/Linux y un archivo por lotes para Windows verifican la presencia de Docker y Docker Compose, crean un archivo de entorno, inician los servicios, esperan las comprobaciones de salud y opcionalmente cargan datos de muestra. Luego el frontend, la API del backend y la documentación de la API son accesibles en puertos locales. Los controles de calidad están integrados. El backend se ejercita con pytest, ruff y mypy; el frontend con scripts de lint y verificación de tipos; y un suite end-to-end de Playwright cubre autenticación, CRUD, sugerencias, trazabilidad, exportaciones, RBAC, notificaciones, preparación para lanzamiento y paneles de calidad de los dashboards. Se proporcionan flujos de trabajo de integración continua para el backend, el frontend, las construcciones de Docker y las pruebas end-to-end, y un flujo de trabajo separado verifica los enlaces internos de Markdown en la documentación. Una especificación preliminar, External Results v1, describe patrones para extraer resultados de automatizaciones externas. El proyecto se posiciona por separado de las herramientas de ejecución: un repositorio complementario, bgstm-playwright-frameworks, ofrece un andamiaje de automatización de Playwright con trazabilidad nativa de BGSTM y devuelve los resultados a BGSTM, lo que mantiene la metodología independiente de cualquier marco de automatización único. Se invitan contribuciones para documentación, ejemplos, plantillas, mejoras de metodología, código de la aplicación e integraciones, y se destacan dos reglas de documentación para los contribuyentes: mantener la metodología en seis fases y tratar el directorio docs/test-templates como el directorio canónico de plantillas. El proyecto se publica bajo la Licencia MIT.