SDLC وSTLC: دورتا التطوير والاختبار

SDLC وSTLC: ماذا يعني كل مصطلح

تصف SDLC كيف تُبنى البرمجيات وتُصان. تحمل مراحلها أسماء مختلفة في المؤسسات والنماذج المختلفة، لكن العمل واحد في كل مكان: الاتفاق على ما سيُبنى (المتطلبات)، وتقرير كيف سيُبنى (البنية المعمارية والتصميم)، وكتابته (التنفيذ)، وتجميع أجزائه (التكامل)، وإتاحته للمستخدمين (الإصدار والنشر)، ثم تشغيله ومراقبته وتغييره (التشغيل والصيانة). ولا تنتهي SDLC عند الإصدار الأول؛ بل تنتهي حين يُسحب المنتج من الخدمة.

وتصف STLC كيف يُنظَّم الاختبار داخل ذلك الجهد. النسخة التي تُدرَّس في أغلب المواد التدريبية لها ست مراحل: تحليل المتطلبات، وتخطيط الاختبار، وتطوير حالات الاختبار، وتجهيز بيئة الاختبار، وتنفيذ الاختبار، وإغلاق دورة الاختبار. لكل مرحلة مدخلات ومخرجات ومعايير تحدد متى يجوز أن تبدأ ومتى تُعدّ منتهية.

وهنا دقة مهمة: «STLC» مصطلح صناعي يُستخدم في الدورات والمقابلات وإعلانات الوظائف، وليس مصطلحاً يعرّفه ISTQB. فمنهج ISTQB للمختبِر المعتمد – المستوى التأسيسي (CTFL) الإصدار 4.0 يصف عملية اختبار (Test process) من سبع مجموعات أنشطة: تخطيط الاختبار، ومتابعة الاختبار والتحكم فيه، وتحليل الاختبار، وتصميم الاختبار، وتهيئة الاختبار (Test implementation)، وتنفيذ الاختبار، وإتمام الاختبار. ويصف المعيار ISO/IEC/IEEE 29119-2 عمليات الاختبار على المستوى المؤسسي ومستوى إدارة الاختبار ومستوى الاختبار الديناميكي. الجوهر واحد، وتختلف الأسماء والحدود بين الخطوات. وباختصار:

• تحليل المتطلبات ≈ تحليل الاختبار (Test analysis) — تقرير ما الذي سيُختبر (شروط الاختبار) وإيجاد العيوب في أساس الاختبار.
• تخطيط الاختبار ≈ تخطيط الاختبار — ومعه متابعة الاختبار والتحكم فيه، وليس لهما مرحلة خاصة في STLC بل يمتدان من التخطيط حتى الإتمام.
• تطوير حالات الاختبار ≈ تصميم الاختبار (كيف نختبر: حالات الاختبار وعناصر التغطية واحتياجات البيانات) ومعظم تهيئة الاختبار (الإجراءات والسكربتات والحزم والبيانات).
• تجهيز بيئة الاختبار ≈ جزء البيئة من تهيئة الاختبار؛ ويعامله المعيار ISO/IEC/IEEE 29119-2 كعملية مستقلة.
• تنفيذ الاختبار ≈ تنفيذ الاختبار، بما فيه الإبلاغ عن العيوب واختبار التأكيد (Confirmation testing) واختبار الانحدار (Regression testing).
• إغلاق دورة الاختبار ≈ إتمام الاختبار (Test completion).

العلاقة بين دورة حياة التطوير ودورة حياة الاختبار

أبسط صورة دقيقة هي مساران متوازيان تربط بينهما صلات. وكل مُخرَج من مخرجات التطوير يغذّي أعمال الاختبار في مرحلته. فالمتطلبات والتصاميم وعقود الواجهات البرمجية هي أساس الاختبار (Test basis) الذي يقرؤه تحليل الاختبار وتصميمه: المتطلب هو ما يقرؤه تحليل الاختبار، وعقد الواجهة البرمجية هو ما تُشتق منه اختبارات التكامل. أما البناء (Build)، ثم النظام العامل لاحقاً، فهو موضوع الاختبار (Test object)، أي ما يُنفَّذ عليه الاختبار. وكل مُخرَج من مخرجات الاختبار يعود إلى التطوير: تعليق المراجعة يغيّر متطلباً، وتقرير العيب يغيّر الكود، وتقرير إتمام الاختبار يُغذّي قرار الإصدار.

ويصوغ CTFL الإصدار 4.0 ذلك كممارسة جيدة في أي نموذج دورة حياة: لكل نشاط تطوير نشاط اختبار مقابل؛ ولكل مستوى اختبار أهدافه الخاصة؛ ويبدأ تحليل الاختبار وتصميمه لمستوى معيّن أثناء مرحلة التطوير المقابلة له؛ ويشارك المختبِرون في مراجعة مخرجات العمل بمجرد توفر مسوداتها. والفريق الذي يتبع هذه القواعد الأربع قد وافق فعلياً بين STLC وSDLC أياً كانت الأسماء التي يستخدمها.

• النطاق — تغطي SDLC المنتج كله من الفكرة حتى السحب من الخدمة؛ وتغطي STLC أعمال التحقق والمصادقة (Verification and validation) داخلها.
• المُخرَج — تنتج SDLC برنامجاً يعمل ووثائقه؛ وتنتج STLC أدوات الاختبار ومخرجاته (Testware): شروط الاختبار والحالات والبيانات والسكربتات والنتائج وتقارير العيوب وتقارير الحالة والإتمام، إضافة إلى تقييم للجودة والمخاطر المتبقية.
• الملكية — SDLC ملك الفريق كله بقيادة المنتج والهندسة؛ وSTLC يقودها عادةً دور الاختبار، لكن المطورين يملكون اختبارات المكوّنات ومالكي المنتج يملكون القبول.
• التكرار — للمنتج دورة SDLC واحدة بتكرارات كثيرة؛ أما STLC فتتكرر مع كل إصدار وكل سبرنت وكل مستوى اختبار، وكل إصلاح عيب يطلق دورة صغيرة من اختبار التأكيد والانحدار.
• مقياس النجاح — في SDLC القيمة المسلَّمة للمستخدمين؛ وفي STLC مقدار الثقة المبرَّرة التي يمنحها الدليل وقلة العيوب المتسرّبة إلى الإنتاج.

أين يشارك ضمان الجودة في كل مرحلة من مراحل SDLC

المختبِر الذي لا ينضم إلا حين يصبح البناء جاهزاً يستطيع أن يجد الإخفاقات لكنه لا يستطيع منع العيوب. القائمة التالية تبيّن ما يفعله المختبِر في كل مرحلة تطوير، ونوع المشكلة التي تكون تلك المرحلة الأنسب لاكتشافها.

• المتطلبات — مراجعة القصص والمواصفات بحثاً عن الغموض والتناقضات ومسارات الخطأ الناقصة وقابلية الاختبار؛ واقتراح معايير القبول (Acceptance criteria)؛ وحصر مخاطر المنتج. أمثلة نموذجية لما يُكتشف: «الاسترداد خلال مدة معقولة» بلا رقم؛ ولا شيء يقول ماذا يحدث لطلب شُحن جزء منه.
• التصميم — مراجعة البنية المعمارية وعقود الواجهات البرمجية وتصاميم الواجهة من حيث قابلية الاختبار: هل تعمل الخدمة مع مزوّد دفع محاكى؟ هل تُسجَّل الأخطاء مع معرّف الطلب؟ هل يمكن ضبط المنطقة الزمنية واللغة؟ واشتقاق شروط اختبار التكامل من عقود الواجهات، والمطالبة بأهداف غير وظيفية رقمية (زمن الاستجابة، ومستوى إمكانية الوصول، والتخطيط من اليمين إلى اليسار).
• التنفيذ — إعداد حالات الاختبار وبياناته والفحوص الآلية بينما تُبنى الميزة؛ والعمل مع المطورين على اختبارات المكوّنات؛ والتأكد من أن التحليل الساكن (Static analysis) ومراجعة الكود يعملان في خط التكامل. وهدف المختبِر هنا أن يجتاز أول بناء يُسلَّم الفحوص البديهية.
• التكامل — تنفيذ اختبارات تكامل المكوّنات وتكامل الأنظمة: عقود الواجهات، وتدفق البيانات عبر الخدمات، والتعامل مع مهل الأطراف الخارجية واستجابات الخطأ؛ وتشغيل حزمتي الدخان (Smoke) والانحدار على كل بناء مدمج.
• الإصدار — اختبار النظام واختبار القبول، والانحدار الكامل على المرشّح للإصدار، وتقييم معايير الخروج، والمساهمة في قرار الإطلاق أو عدمه (Go/no-go)، والتحقق مباشرة بعد النشر من أن الإصدار يعمل في البيئة المستهدفة.
• التشغيل — مراجعة إشارات الإنتاج (الأخطاء وزمن الاستجابة وبلاغات المستخدمين)، واختبار الإصلاحات العاجلة، وإجراء اختبار الصيانة (Maintenance testing) حين تتغير المنصة أو إحدى الاعتماديات أو البيانات، وتحويل كل عيب متسرّب إلى اختبار انحدار.

جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي جرّبها: مولّد معايير القبول

خريطة المقابلة بين SDLC وSTLC

يقرن الجدول كل مرحلة تطوير بأنشطة الاختبار التي تجري خلالها، ومخرجات الاختبار التي تنتجها، ومستوى الاختبار الذي تُعِدّه أو تنفّذه. اقرأه صفاً صفاً: يبدأ نشاط الاختبار في صف ما حين يوجد مُخرَج التطوير في الصف نفسه، لا حين يصل المشروع كله إلى ذلك الصف.

• المتطلبات — مُخرَج التطوير: القصص والمواصفات والمتطلبات غير الوظيفية. أنشطة الاختبار: تحليل المتطلبات (≈ تحليل الاختبار) وبدء تخطيط الاختبار. مخرجات الاختبار: ملاحظات المراجعة وشروط الاختبار وقائمة المخاطر ومسودة خطة الاختبار. المستوى: القبول (يُخطَّط له).
• التصميم — مُخرَج التطوير: البنية المعمارية وعقود الواجهات البرمجية وتصاميم الواجهة. أنشطة الاختبار: تحليل وتصميم اختبارات مستويي التكامل والنظام، وتحديد احتياجات البيئة. مخرجات الاختبار: شروط اختبار التكامل ومتطلبات البيئة. المستوى: التكامل والنظام (يُخطَّط لهما).
• التنفيذ — مُخرَج التطوير: الكود واختبارات الوحدة والبناءات. أنشطة الاختبار: تصميم الاختبار وتهيئته، وبيانات الاختبار، وتجهيز البيئة، والفحوص الآلية، والتحليل الساكن في CI. مخرجات الاختبار: حالات الاختبار والسكربتات والبيانات والفحوص الآلية. المستوى: المكوّن (يتولاه المطورون).
• التكامل — مُخرَج التطوير: البناء المدمج. أنشطة الاختبار: النشر في بيئة الاختبار وتنفيذ اختبارات الدخان والتكامل. مخرجات الاختبار: سجلات الاختبار وتقارير العيوب. المستوى: تكامل المكوّنات وتكامل الأنظمة.
• الإصدار — مُخرَج التطوير: المرشّح للإصدار ثم النسخة المنشورة. أنشطة الاختبار: تنفيذ اختبارات النظام والانحدار والقبول، والمتابعة والتحكم، وتقييم معايير الخروج، والتحقق من النشر، وإتمام الاختبار. مخرجات الاختبار: النتائج والعيوب وتقارير الحالة ومدخلات قرار الإطلاق وتقرير الإتمام. المستوى: النظام والقبول، وفحص دخان في الإنتاج.
• التشغيل — مُخرَج التطوير: النظام العامل وتغييراته. أنشطة الاختبار: اختبار الصيانة والانحدار للإصلاحات، ومراجعة إشارات الإنتاج. مخرجات الاختبار: حزمة انحدار محدَّثة ودروس مستفادة. المستوى: أي مستوى يمسّه التغيير.

SDLC phase      | Development output          | Test activities (STLC ~ ISTQB)              | Test work products                 | Test level
----------------|-----------------------------|---------------------------------------------|------------------------------------|---------------------------
Requirements    | Stories, specs, NFRs        | Requirement analysis ~ test analysis;       | Review findings, test conditions,  | Acceptance (planned)
                |                             | test planning starts                        | risk list, draft test plan         |
Design          | Architecture, API contracts,| Analysis and design for integration and     | Integration test conditions,       | Integration, system
                | UI designs                  | system levels; environment needs identified | environment requirements           | (planned)
Implementation  | Code, unit tests, builds    | Test design and implementation; test data;  | Test cases, scripts, data,         | Component (developers)
                |                             | environment set-up; automated checks;       | automated checks                   |
                |                             | static analysis in CI                       |                                    |
Integration     | Integrated build            | Deploy to test env; smoke and integration   | Test logs, defect reports          | Component integration,
                |                             | test execution                              |                                    | system integration
Release         | Release candidate, then     | System, regression and acceptance           | Results, defects, status reports;  | System, acceptance;
                | deployed version            | execution; monitoring and control;          | go/no-go input, completion report  | smoke in production
                |                             | exit-criteria evaluation; deployment        |                                    |
                |                             | verification; test completion               |                                    |
Operation       | Running system, changes     | Maintenance and regression testing for      | Updated regression suite,          | Whatever the change touches
                |                             | fixes; review of production signals         | lessons learned                    |

جرّبها: المتطلبات ← حالات اختبار

الإزاحة لليسار والإزاحة لليمين في الاختبار

الإزاحة لليسار (Shift-left) تعني نقل أنشطة الاختبار إلى وقت أبكر في دورة الحياة حتى تُكتشف العيوب حين يكون إصلاحها أرخص. يصف CTFL الإصدار 4.0 هذا النهج ويذكر ممارسات نموذجية: مراجعة المواصفات من منظور المختبِر، وكتابة حالات الاختبار قبل كتابة الكود، واستخدام التكامل المستمر (Continuous integration) للحصول على تغذية راجعة سريعة، وإجراء التحليل الساكن قبل الاختبار الديناميكي، والبدء بالاختبار غير الوظيفي على مستوى المكوّن حيثما أمكن. ويشير المنهج أيضاً إلى جانب الكلفة: قد تتطلب الإزاحة لليسار تدريباً أو جهداً أو كلفة إضافية في بداية المشروع يُتوقع أن توفّر جهداً لاحقاً. والإزاحة لليسار ممارسة راسخة.

والإزاحة لليمين (Shift-right) تعني مدّ الاختبار والمراقبة إلى بيئة الإنتاج: إطلاق التغيير لنسبة صغيرة من الحركة أولاً ومقارنته بخط الأساس (الإطلاق الكناري Canary release كما يصفه كتاب SRE العملي من Google)، وإخفاء الميزات غير المكتملة خلف أعلام الميزات (Feature flags)، وتشغيل فحوص اصطناعية على نقاط النهاية الحية، ومراقبة معدلات الخطأ وزمن الاستجابة بعد كل نشر. الإطلاق الكناري ومراقبة الإنتاج ممارسة راسخة في الفرق التي تنشر باستمرار؛ أما تجارب حقن الأعطال المضبوطة في الإنتاج (وتُسمى غالباً هندسة الفوضى Chaos engineering) فتذهب خطوة أبعد.

والنهجان متكاملان لا بديلان. تقلّل الإزاحة لليسار عدد العيوب التي تصل إلى البناء؛ وتحدّ الإزاحة لليمين من ضرر العيوب التي تصل إلى المستخدمين رغم ذلك، وتخبرك أيّها فات اختباراتك قبل الإصدار. ولا يحل الاختبار في الإنتاج محل الاختبار قبل الإصدار أبداً، ويحتاج إلى ضمانات: حسابات اختبار مخصصة، ولا بيانات شخصية حقيقية في معاملات الاختبار، وعلَم أو تراجع (Rollback) يستطيع إيقاف التغيير خلال دقائق.

• أمثلة على الإزاحة لليسار — مراجعة معايير القبول قبل تخطيط السبرنت؛ وكتابة اختبارات عقد الواجهة من مستند OpenAPI قبل وجود نقطة النهاية؛ وفحوص الوحدة والفحوص الساكنة على كل طلب دمج (Pull request).
• أمثلة على الإزاحة لليمين — إطلاق كناري على 5% من الحركة مع تراجع تلقائي إذا ارتفع معدل الخطأ فوق خط الأساس؛ وفحص اصطناعي لتسجيل الدخول كل دقيقة؛ وفحص صحة بعد النشر لكل الواجهات البرمجية العامة.

جرّبها: مولّد معايير القبول

نماذج دورة الحياة وكيف يختلف الاختبار في كل منها

يحدد نموذج دورة الحياة متى يمكن أن تجري أنشطة الاختبار، وكم يُوثَّق منها، وما أكبر مخاطر الاختبار. أنشطة الاختبار نفسها — التحليل والتصميم والتنفيذ والإتمام — موجودة في كل نموذج؛ وما يتغير هو توقيتها ودرجة تفصيلها.

• التتابعي (الشلالي Waterfall) — تجري المراحل بالترتيب وتنتهي كل مرحلة قبل أن تبدأ التالية. يتركّز الاختبار الديناميكي في مرحلة اختبار بعد التنفيذ؛ ويُنجَز تخطيط الاختبار وتوثيقه مسبقاً وبصورة رسمية عادةً. والخطر الرئيسي هو التأخر: عيوب المتطلبات تُكتشف بعد أشهر من كتابتها، وحين يتجاوز التطوير موعده تكون مرحلة الاختبار هي التي تُضغط. والعلاج إجراء الاختبار الساكن (Static testing) — مراجعات المتطلبات والتصميم — في المراحل المبكرة حتى لو انتظر الاختبار الديناميكي.
• نموذج V (V-model) — ما زال تتابعياً، لكنه يقرن كل مستوى تطوير بمستوى اختبار: المتطلبات مع اختبار القبول، ومواصفة النظام مع اختبار النظام، والتصميم المعماري مع اختبار التكامل، والتصميم التفصيلي مع اختبار المكوّن. يبدأ تحليل الاختبار وتصميمه لكل مستوى بمجرد إنتاج نظيره في التطوير، وهذا شكل مبكر من الإزاحة لليسار؛ أما التنفيذ فيظل على الجانب الأيمن من حرف V بعد وجود الكود.
• التكراري والتزايدي (Iterative and incremental) — يُبنى المنتج على زيادات، وتمر كل زيادة بتصميمها وبنائها واختبارها. يتكرر الاختبار في كل دورة، فتصبح حزمة الانحدار المتنامية الكلفة الرئيسية؛ ودون أتمتة تنفق كل دورة وقتاً أطول في إعادة فحص السلوك القديم ووقتاً أقل في الجديد.
• الرشيق / Scrum — يعرّف دليل Scrum سبرنتات مدتها شهر أو أقل، وزيادة (Increment) يجب أن تستوفي تعريف الإنجاز (Definition of Done)، وثلاث مسؤوليات (مالك المنتج، وScrum Master، والمطورون) دون دور منفصل للمختبِر: كل من يصنع الزيادة هو «مطوّر»، فالاختبار مسؤولية الفريق كله داخل السبرنت. التوثيق أخف، ومعايير القبول وتعريف الإنجاز تعمل كمعايير خروج، وممارسات الاختبار أولاً (TDD وATDD وBDD) شائعة. والخطر الرئيسي أن تُعدّ القصة «منجزة» قبل أن يكتمل اختبارها، ولذلك يُدرَج الاختبار في تعريف الإنجاز. وتساعد أرباع الاختبار الرشيق (Agile testing quadrants) — التي عرّفها بريان ماريك (Brian Marick) ووصفتها ليزا كريسبن وجانيت غريغوري في كتابهما Agile Testing — الفريقَ على التأكد من حضور الاختبار الموجّه للأعمال والموجّه للتقنية، اليدوي والآلي.
• DevOps والتسليم المستمر — يمر كل تغيير عبر خط CI/CD يبني وينشر ويشغّل الاختبارات الآلية، فيصبح خط التكامل المحرك الرئيسي لتنفيذ الاختبار وتقيم فيه بوابات الجودة (Quality gates). الإصدارات صغيرة ومتكررة، ما يخفض مخاطر كل منها، وتُغلق مراقبة الإنتاج الحلقة. ويُعدّ مقياسا DORA — نسبة فشل التغييرات (Change fail rate) وزمن التعافي من النشر الفاشل — إشارتين مفيدتين على أداء الاختبار داخل الخط. ويشير CTFL الإصدار 4.0 إلى أن الاختبار اليدوي من منظور المستخدم يظل مطلوباً، وأن خط التكامل نفسه يجب أن يُبنى ويُصان. والخطر الرئيسي هنا خط بطيء أو متذبذب النتائج (Flaky) ونقاط عمياء لا تصلها الفحوص الآلية؛ ويصبح سجل الخط نفسه هو التوثيق، والممارسة المحورية حزم اختبار سريعة مع مراقبة الإنتاج.

Model          | When dynamic testing runs        | Documentation      | Main testing risk                     | Key practice
---------------|----------------------------------|--------------------|---------------------------------------|------------------------------
Waterfall      | After implementation, one phase  | Formal, up front   | Requirement defects found late;       | Early reviews of requirements
               |                                  |                    | test phase squeezed                   | and design
V-model        | Per level, right side of the V   | Formal, per level  | Execution still late                  | Design tests per level early
Iterative      | Every iteration                  | Moderate           | Regression effort grows each round    | Automate regression
Scrum          | Inside every Sprint              | Light, just enough | "Done" without testing done           | Testing in Definition of Done
DevOps / CD    | On every change, in the pipeline | Pipeline as record | Slow or flaky pipeline; blind spots   | Fast suites + monitoring

معايير الدخول والخروج عبر دورة الحياة

تحدد معايير الدخول (Entry criteria) الشروط المسبقة لبدء نشاط ما؛ وتحدد معايير الخروج (Exit criteria) ما يجب تحقيقه قبل إعلان اكتماله. ويشير CTFL الإصدار 4.0 إلى أن معايير الخروج تُسمى غالباً في الفرق الرشيقة تعريف الإنجاز (Definition of Done)، وأن معايير الدخول لقصة المستخدم تُسمى تعريف الجاهزية (Definition of Ready). يقدّم الدليل المحوري لضمان الجودة الشامل النظرة العامة، وتقدّم صفحة دورة حياة الاختبار معايير كل مرحلة من مراحل STLC؛ أما على مستوى SDLC فالبوابات المفيدة هي نقاط التسليم بين مراحل التطوير:

• المتطلبات ← التصميم — لكل قصة ضمن النطاق معايير قبول تشمل مسارات الخطأ؛ ومراجعة الغموض منجزة؛ وللأسئلة المفتوحة مالك وتاريخ.
• التصميم ← التنفيذ — عقود الواجهات البرمجية منشورة؛ والأهداف غير الوظيفية أرقام لا صفات؛ واحتياجات بيئة الاختبار متفق عليها.
• التنفيذ ← التكامل — البناء أخضر؛ واختبارات الوحدة ناجحة؛ والتحليل الساكن لا يُظهر نتائج حرجة جديدة؛ والتغيير خضع لمراجعة الكود.
• التكامل ← الإصدار — المرشّح للإصدار (Release candidate) يُنشر في بيئة الاختبار؛ وحزمة الدخان تجتاز؛ وخط أساس بيانات الاختبار محمَّل. وهذه بوابة الدخول إلى اختبار النظام واختبار القبول على المرشّح للإصدار.
• داخل مرحلة الإصدار، من المرشّح للإصدار إلى الإنتاج (قرار الإطلاق أو عدمه Go/no-go) — الاختبارات المخططة نُفّذت أو استُبعدت صراحةً؛ ولا عيوب حاجبة أو حرجة مفتوحة؛ وحزمة الانحدار خضراء؛ والمخاطر المتبقية مقبولة كتابياً من مالك المنتج.
• الإصدار ← التشغيل — التحقق من النشر اجتاز؛ ولوحات المراقبة والتنبيهات موجودة للسلوك الجديد؛ والتراجع جُرِّب مسبقاً.

مثال تطبيقي: ميزة واحدة عبر الدورتين

على سبيل المثال، يضيف متجر إلكتروني افتراضي في الرياض خيار «الدفع على 4 أقساط» عند إتمام الشراء للطلبات بين 200 و5,000 ريال، عبر مزوّد أقساط خارجي. إليك ما يفعله الاختبار في كل مرحلة من مراحل SDLC.

• المتطلبات — تطرح مراجعة المختبِر ثلاثة أسئلة لم تُجب عنها القصة: كيف يُقسَّم مبلغ 999.99 ريال على أربع دفعات (ومن يتحمّل الهللة الناتجة عن التقريب)؟ وماذا يرى المتسوّق إذا رفض المزوّد؟ وكيف يُعالَج الاسترداد الجزئي بعد دفع قسطين؟ تتحول الإجابات إلى معايير قبول.
• التصميم — يُراجَع عقد الواجهة البرمجية للمزوّد؛ ويطلب المختبِر حساباً في بيئة التجربة (Sandbox) ومحاكاة لاستجابتي الرفض وانتهاء المهلة، وقاعدة تحدد كم تنتظر صفحة الدفع قبل أن تتوقف.
• التنفيذ — تُصمَّم حالات الاختبار بالقيم الحدّية (199.99 و200.00 و5,000.00 و5,000.01)، وبفئات تكافؤ لاستجابات المزوّد (موافقة، رفض، انتهاء مهلة، استجابة مشوّهة)، وبترتيب للمخاطر يضع الدفع والاسترداد أولاً؛ وتُؤتمت فحوص الواجهة البرمجية كلما ظهرت نقاط النهاية.
• التكامل — تُنفَّذ الاختبارات على بيئة تجربة المزوّد: موافقة، ورفض، ومهلة 30 ثانية، واستدعاء راجع (Callback) مكرر. ويُكتشف عيب: «الطلب يبقى في حالة PENDING إلى الأبد عندما يصل استدعاء المزوّد مرتين».
• الإصدار — انحدار كامل لمسار الدفع، وتقييم معايير الخروج (لا عيوب حرجة مفتوحة، وكل شروط المخاطر العالية ناجحة)، ثم الإطلاق لـ 5% من الحركة أولاً مع مراقبة معدل أخطاء الأقساط مقارنةً بخط أساس الدفع بالبطاقة.
• التشغيل — يُظهر الإنتاج نسبة صغيرة من انتهاء مهلة المزوّد في ساعات الذروة؛ فيضيف المختبِر اختبار انحدار لمسار إعادة المحاولة وفحص مراقبة لمعدل انتهاء المهلة.

جرّبها: تحليل القيم الحدّية جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار

خريطة هذا الموضوع وإلى أين تتجه بعدها

هذا الدليل المحوري هو نقطة الدخول لأسئلة دورة الحياة. تتناول صفحة دورة حياة اختبار البرمجيات كل مرحلة من مراحل STLC بعمق — المهام ومخرجات العمل ومعايير الدخول والخروج لكل مرحلة — وتقابلها بعملية الاختبار في ISTQB وبالمعيار ISO/IEC/IEEE 29119-2. وتغطي أدلة محورية أخرى الموضوعات المجاورة: الاختبار الساكن والمراجعات (كيف تُراجع المتطلبات والتصاميم قبل تشغيل أي كود)، واستراتيجية الاختبار وتخطيطه والاختبار المبني على المخاطر (كيف يُقرَّر الجهد ويُرتَّب)، ودورة حياة العيب وفرزه (ما يحدث للعيب بعد الإبلاغ عنه)، والاختبار في CI/CD مع اختبارات الدخان والسلامة (Sanity) والانحدار والتحقق من النشر (كيف تجري الدورة داخل خط التكامل).

وللصورة الشاملة لمستويات الاختبار وأنواعه وبوابات الإصدار، راجع الدليل المحوري لضمان الجودة الشامل؛ ولما يُؤتمت وما يبقى يدوياً، راجع مقارنة الاختبار اليدوي والآلي. وهذه مراجعة ذاتية قصيرة لأي فريق:

• يراجع المختبِرون المتطلبات قبل بدء التطوير، لا بعد أول بناء.
• لكل مرحلة تطوير نشاط اختبار مسمّى ومالك.
• توجد معايير دخول وخروج لنقاط التسليم، وتجاوز أي معيار قرار صريح ومسجَّل.
• تعمل حزمة الانحدار تلقائياً على كل بناء مدمج.
• تُراجع إشارات الإنتاج بعد كل إصدار، ويتحول كل عيب متسرّب إلى اختبار انحدار.

الأسئلة الشائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021نموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
• DORA's software delivery performance metricsDORA (Google Cloud)مقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.
• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaإطلاق التغيير لنسبة صغيرة من الحركة أولاً ومقارنته بخط الأساس قبل التعميم — التحقق من النشر كما يُمارس في هندسة موثوقية المواقع.