bgstm

BGSTM (Better Global Software Testing Methodology) is a testing framework and knowledge base aimed at organising quality work from planning through to reporting. Its central idea is to stay methodology-agnostic: the same six-phase lifecycle is meant to work under Agile, Scrum, Waterfall, or hybrid delivery models without forcing a particular development process on the team. The framework defines exactly six canonical phases, and the documentation stresses that specialised domains reuse these phases rather than adding new ones. They are: test planning (scope, strategy, risks, resources, timelines); test case development (traceable scenarios and cases); test environment preparation (infrastructure, tools, access, test data); test execution (running tests, collecting evidence, managing defects); test results analysis (interpreting outcomes, trends and quality signals); and test results reporting (communicating findings to support release decisions). The last phase feeds back into the first for the next cycle. Stated core principles include end-to-end coverage of the quality lifecycle, maintaining traceability between requirements, tests, results, defects, evidence and decisions, scaling test rigour according to risk, evidence-based reporting, and practical adoption that starts from methodology and templates before adding tooling. The repository is primarily documentation. It provides per-phase guides, methodology guides covering Agile, Scrum, Waterfall and a comparison of them, reusable test templates for plans, cases, reports, risk and traceability artifacts, and worked examples. One example applies all six phases to ETL and data-pipeline semantic validation; the README explicitly notes this is not an extra phase. Alongside the methodology, the project hosts an open-source reference application that demonstrates how parts of the framework can be represented in software. It combines a React frontend, a FastAPI backend and a PostgreSQL database, and covers traceability features, release readiness and quality KPI dashboards, role-based access control, notifications and exports. Setup is script-driven: a shell script for macOS/Linux and a batch file for Windows check for Docker and Docker Compose, create an environment file, start services, wait for health checks and optionally load sample data. The frontend, backend API and API documentation are then reachable on local ports. Quality checks are built in. The backend is exercised with pytest, ruff and mypy; the frontend with lint and type-check scripts; and a Playwright end-to-end suite covers authentication, CRUD, suggestions, traceability, exports, RBAC, notifications, release readiness and quality dashboards. Continuous integration workflows are provided for backend, frontend, Docker builds and end-to-end tests, and a separate workflow checks internal Markdown links in the documentation. A draft specification, External Results v1, describes patterns for pulling in results from external automation. The project positions itself separately from execution tooling: a companion repository, bgstm-playwright-frameworks, offers Playwright automation scaffolding with BGSTM-native traceability and reports results back into BGSTM, which keeps the methodology independent of any single automation framework. Contributions are invited for documentation, examples, templates, methodology improvements, application code and integrations, and two documentation rules are highlighted for contributors: keep the methodology at six phases, and treat docs/test-templates as the canonical template directory. The project is released under the MIT License.