Sobre o projeto

O BGSTM (Better Global Software Testing Methodology) é um framework de testes e base de conhecimento destinado a organizar o trabalho de qualidade desde o planejamento até o relatório. Sua ideia central é manter-se agnóstico em relação à metodologia: o mesmo ciclo de seis fases deve funcionar sob modelos de entrega Agile, Scrum, Waterfall ou híbridos, sem impor um processo de desenvolvimento específico à equipe. O framework define exatamente seis fases canônicas, e a documentação ressalta que domínios especializados reutilizam essas fases em vez de adicionar novas. Elas são: planejamento de testes (escopo, estratégia, riscos, recursos, cronogramas); desenvolvimento de casos de teste (cenários e casos rastreáveis); preparação do ambiente de teste (infraestrutura, ferramentas, acesso, dados de teste); execução de testes (execução de testes, coleta de evidências, gerenciamento de defeitos); análise de resultados de testes (interpretação de resultados, tendências e sinais de qualidade); e relatórios de resultados de testes (comunicação de descobertas para apoiar decisões de lançamento). A última fase alimenta a primeira para o próximo ciclo. Os princípios fundamentais declarados incluem cobertura end-to-end do ciclo de vida da qualidade, manutenção da rastreabilidade entre requisitos, testes, resultados, defeitos, evidências e decisões, dimensionamento do rigor dos testes conforme o risco, relatórios baseados em evidências e adoção prática que começa com metodologia e templates antes de adicionar tooling. O repositório é primariamente documentação. Fornece guias por fase, guias metodológicos cobrindo Agile, Scrum, Waterfall e uma comparação entre eles, templates reutilizáveis de teste para planos, casos, relatórios, riscos e artefatos de rastreabilidade, e exemplos práticos. Um exemplo aplica todas as seis fases à validação semântica de pipelines de dados ETL; o README nota explicitamente que isto não é uma fase extra. Junto com a metodologia, o projeto hospeda uma aplicação de referência open-source que demonstra como partes do framework podem ser representadas em software. Combina frontend React, backend FastAPI e banco de dados PostgreSQL, e cobre funcionalidades de rastreabilidade, prontidão de lançamento e dashboards de KPIs de qualidade, controle de acesso baseado em função, notificações e exportações. A configuração é orientada por scripts: um script shell para macOS/Linux e um arquivo batch para Windows verificam Docker e Docker Compose, criam um arquivo de ambiente, iniciam serviços, aguardam health checks e opcionalmente carregam dados de amostra. O frontend, API backend e documentação da API ficam então acessíveis em portas locais. Verificações de qualidade estão embutidas. O backend é testado com pytest, ruff e mypy; o frontend com scripts de lint e type-check; e uma suíte end-to-end Playwright cobre autenticação, CRUD, sugestões, rastreabilidade, exportações, RBAC, notificações, prontidão de lançamento e dashboards de qualidade. Workflows de integração contínua são fornecidos para backend, frontend, builds Docker e testes end-to-end, e um workflow separado verifica links Markdown internos na documentação. Uma especificação em rascunho, External Results v1, descreve padrões para incorporação de resultados de automação externa. O projeto posiciona-se separadamente de tooling de execução: um repositório companheiro, bgstm-playwright-frameworks, oferece scaffolding de automação Playwright com rastreabilidade nativa BGSTM e reporta resultados de volta ao BGSTM, mantendo a metodologia independente de qualquer framework de automação específico. Contribuições são bem-vindas para documentação, exemplos, templates, melhorias metodológicas, código da aplicação e integrações, e duas regras de documentação são destacadas para contribuidores: manter a metodologia em seis fases e tratar docs/templates-de-teste como diretório de templates canônico. O projeto é licenciado sob MIT License.