عن المشروع

BGSTM (Better Global Software Testing Methodology) هو إطار عمل وقاعدة معرفة يهدف إلى تنظيم عمل الجودة من التخطيط حتى التقارير. الفكرة المركزية هي البقاء محايدًا تجاه المنهجية: نفس دورة الحياة المكونة من ست مراحل مُعدة للعمل ضمن نماذج تسليم أجايل، سكروم، ووترفال، أو النماذج الهجينة دون فرض عملية تطوير معينة على الفريق. يحدد الإطار بالضبط ست مراحل أساسية، وتؤكد الوثائق أن المجالات المتخصصة تعيد استخدام هذه المراحل بدلاً من إضافة مراحل جديدة. وهي: تخطيط الاختبار (النطاق، الاستراتيجية، المخاطر، الموارد، الجداول الزمنية)؛ تطوير حالات الاختبار (السيناريوهات والحالات القابلة للتتبع)؛ إعداد بيئة الاختبار (البنية التحتية، الأدوات، الوصول، بيانات الاختبار)؛ تنفيذ الاختبار (تشغيل الاختبارات، جمع الأدلة، إدارة العيوب)؛ تحليل نتائج الاختبار (تفسير النتائج، الاتجاهات وإشارات الجودة)؛ وإعداد تقارير نتائج الاختبار (نقل النتائج لدعم قرارات الإصدار). تغذي المرحلة الأولى للدورة التالية. تشمل المبادئ الأساسية المذكورة تغطية شاملة من النهاية إلى النهاية لدورة حياة الجودة، والحفاظ على التتبع بين المتطلبات، الاختبارات، النتائج، العيوب، الأدلة والقرارات، وتوسيع صرامة الاختبار وفقًا للمخاطر، والتقارير القائمة على الأدلة، والاعتماد العملي الذي يبدأ من المنهجية والقوالب قبل إضافة الأدوات. المستودع يتكون أساسًا من توثيق. يقدم أدلة لكل مرحلة، وأدلة منهجية تغطي أجايل، سكروم، ووترفال ومقارنة بينها، وقوالب اختبار قابلة لإعادة الاستخدام للخطط، الحالات، التقارير، المخاطر ومُصنوعات التتبع، وأمثلة عملية. يطبق أحد الأمثلة جميع المراحل الستة على التحقق الدلالي لـ ETL وخطوط أنابيب البيانات؛ ويشير ملف README صراحةً إلى أن هذا ليس مرحلة إضافية. بالإضافة إلى المنهجية، يستضيف المشروع تطبيق مرجعي مفتوح المصدر يوضح كيف يمكن تمثيل أجزاء من framework في البرمجيات. يجمع بين واجهة أمامية React، وخلفية FastAPI، وقاعدة بيانات PostgreSQL، ويغطي ميزات التتبع، والاستعداد للإصدار، ولوحات تحكم مؤشرات الأداء الرئيسية للجودة، والتحكم في الوصول المستند إلى الأدوار، والإشعارات، والتصدير. الإعداد يُدار بواسطة نص: نص شيفرة لـ macOS/Linux وملف دفعي لـ Windows يتحقق من وجود Docker وDocker Compose، ينشئ ملف بيئة، يبدأ الخدمات، ينتظر فحوصات الصحة ويختار تحميل بيانات عينة. بعد ذلك يصبح الواجهة الأمامية، وواجهة برمجة التطبيقات الخلفية، ووثائق واجهة برمجة التطبيقات متاحة على المنافذ المحلية. تُدمج فحوصات الجودة. يتم اختبار الخلفية باستخدام pytest، ruff و mypy؛ والواجهة الأمامية باستخدام نصوص lint وفحص النوع؛ وتغطي مجموعة end-to-end الخاصة بـ Playwright المصادقة، CRUD، الاقتراحات، التتبع، التصدير، RBAC، الإشعارات، الاستعداد للإصدار ولوحات تحكم الجودة. تُوفّر سير عمل تكامل مستمر للخلفية، الواجهة الأمامية، بناء Docker واختبارات end-to-end، بالإضافة إلى سير عمل منفصل يتحقق من الروابط الداخلية لـ Markdown في التوثيق. تصف مواصفة مسودة تسمى External Results v1 أنماطًا لجلب النتائج من الأتمتة الخارجية. يضع المشروع نفسه منفصلاً عن أدوات التنفيذ: مستودع مصاحب باسم bgstm-playwright-frameworks يقدم هيكل أتمتة Playwright مع إمكانية تتبع أصلية لـ BGSTM ويعيد إرسال النتائج إلى BGSTM، مما يحافظ على استقلالية المنهجية عن أي إطار أتمتة واحد. يُدعى المساهمون للمساهمة في التوثيق، الأمثلة، القوالب، تحسينات المنهجية، كود التطبيق والتكاملات، ويتم تسليط الضوء على قاعدتين توثيقيتين للمساهمين: الحفاظ على المنهجية عند ست مراحل، ومعاملة دليل docs/test-templates كدليل تمهيدي نموذجي canonical. يُصدر المشروع تحت رخصة MIT.