bgstm

BGSTM (Better Global Software Testing Methodology) est un framework de test et une base de connaissances visant à organiser le travail de qualité, de la planification jusqu’au reporting. Son idée centrale est de rester agnostique par rapport à la méthodologie : le même cycle de vie en six phases doit pouvoir fonctionner sous Agile, Scrum, Waterfall ou des modèles de livraison hybrides, sans imposer un processus de développement particulier à l’équipe. Le framework définit exactement six phases canoniques, et la documentation insiste sur le fait que les domaines spécialisés réutilisent ces phases plutôt que d’en ajouter de nouvelles. Elles sont : planification des tests (périmètre, stratégie, risques, ressources, calendrier) ; développement des cas de test (scénarios et cas traçables) ; préparation de l’environnement de test (infrastructure, outils, accès, données de test) ; exécution des tests (exécution des tests, collecte de preuves, gestion des défauts) ; analyse des résultats de test (interprétation des résultats, tendances et signaux de qualité) ; et reporting des résultats de test (communication des conclusions pour soutenir les décisions de mise en production). La dernière phase alimente la première pour le cycle suivant. Les principes fondamentaux déclarés comprennent une couverture de bout en bout du cycle de vie de la qualité, le maintien de la traçabilité entre les exigences, les tests, les résultats, les défauts, les preuves et les décisions, l’ajustement de la rigueur des tests en fonction du risque, le reporting basé sur les preuves, et une adoption pratique qui commence par la méthodologie et les modèles avant d’ajouter des outils. Le dépôt est principalement constitué de documentation. Il fournit des guides par phase, des guides méthodologiques couvrant Agile, Scrum, Waterfall et une comparaison de ceux-ci, des modèles de test réutilisables pour les plans, les cas, les rapports, les artefacts de risque et de traçabilité, ainsi que des exemples travaillés. Un exemple applique les six phases à la validation sémantique d’ETL et de pipelines de données ; le README précise explicitement que cela ne constitue pas une phase supplémentaire. Parallèlement à la méthodologie, le projet héberge une application de référence open‑source qui montre comment certaines parties du framework peuvent être représentées en logiciel. Elle combine une interface frontend React, un backend FastAPI et une base de données PostgreSQL, et couvre les fonctionnalités de traçabilité, la préparation de la mise en production et les tableaux de bord KPI de qualité, le contrôle d’accès basé sur les rôles, les notifications et les exportations. L’installation est pilotée par des scripts : un script shell pour macOS/Linux et un fichier batch pour Windows vérifient la présence de Docker et Docker Compose, créent un fichier d’environnement, démarrent les services, attendent les contrôles de santé et chargent éventuellement des données d’exemple. Ensuite, le frontend, l’API backend et la documentation de l’API sont accessibles sur les ports locaux. Des contrôles de qualité sont intégrés. Le backend est exercé avec pytest, ruff et mypy ; le frontend avec des scripts de lint et de vérification de type ; et une suite end‑to‑end Playwright couvre l’authentification, le CRUD, les suggestions, la traçabilité, les exportations, le RBAC, les notifications, la préparation de la mise en production et les tableaux de bord de qualité. Des workflows d’intégration continue sont fournis pour le backend, le frontend, les builds Docker et les tests end‑to‑end, et un workflow distinct vérifie les liens Markdown internes dans la documentation. Une spécification de projet, External Results v1, décrit des modèles pour récupérer des résultats provenant d’automatisations externes. Le projet se positionne séparément des outils d’exécution : un dépôt compagnon, bgstm-playwright-frameworks, propose un scaffolding d’automatisation Playwright avec traçabilité native BGSTM et renvoie les résultats vers BGSTM, ce qui maintient l’indépendance de la méthodologie vis‑à‑vis d’un seul framework d’automatisation. Les contributions sont les bienvenues pour la documentation, les exemples, les modèles, les améliorations méthodologiques, le code de l’application et les intégrations, et deux règles de documentation sont mises en avant pour les contributeurs : conserver la méthodologie à six phases, et considérer le répertoire docs/test-templates comme le répertoire canonique des modèles. Le projet est publié sous licence MIT.