نطاق الاختبار

لماذا يهم

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

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

ما الذي يحدّده نطاق الاختبار

بيان النطاق المفيد محدد بما يكفي لأن يعطي شخصان الإجابة نفسها عن سؤال «هل هذا مُختبَر؟»: فهو يسمّي العناصر بمعرّفاتها وإصداراتها لا بكلمات مثل «الدفع» أو «التطبيق». ابدأ من النطاق الافتراضي في استراتيجية الاختبار وطبّقه على ما تغيّر، عبر هذه الأبعاد:

• عناصر الاختبار (Test Items): أجزاء موضوع الاختبار (Test Object) التي ستُختبر، كالتطبيقات والخدمات، كلٌّ بإصداره، مثل الموقع ⁦4.2⁩ وتطبيقي iOS وAndroid ⁦4.2⁩ وواجهة الدفع البرمجية v3.
• الميزات والتغييرات: القصص أو المتطلبات أو طلبات التغيير بمعرّفاتها، والميزات الحالية التي يؤثر فيها التغيير.
• خصائص الجودة وأنواع الاختبار: الوظيفي والأداء والأمان وإمكانية الوصول والتوافق، وأيّها ينطبق هذه المرة.
• مستويات الاختبار: مثل اختبار النظام واختبار تكامل الأنظمة على يد فريق الجودة، واختبار المكونات على يد المطورين في خط التكامل المستمر (CI).
• المنصات والمتصفحات والأجهزة واللغات والمناطق التي ستُستخدم فعلاً.
• الواجهات: أين يتوقف اختبارنا، مثل «جانبنا من التكامل مع مزوّد الدفع، في بيئة التجربة (Sandbox) الخاصة به».
• العمق: «ضمن النطاق» ليس علامة نعم أو لا. ففي منهج ISTQB يحدّد تحليل مخاطر المنتج نطاق الاختبار ودرجة تعمّقه معاً: لكل عنصر مستوى خطر وعمق اختبار ينتج عنه.

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

خارج النطاق: قرار له سبب

قائمة «خارج النطاق» قائمة قرارات، لا قائمة بما نسيته. كل استبعاد يسجّل العنصر والسبب ومن يغطيه بدلاً منك ومن وافق عليه؛ وإن ترك خطراً، يقبله صراحةً صاحب قرار الإصدار، وهو عادةً مالك المنتج. ومعيار توثيق الاختبار ISO/IEC/IEEE ⁦29119-3⁩ يطلب جوهر ذلك في قسم نطاق الاختبار من خطة الاختبار: الميزات المستبعدة من الاختبار ومبرر استبعادها.

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

أسباب تصمد عادةً في مراجعة النطاق:

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

كيف تتفق على النطاق وتوثّقه

يقترح فريق الاختبار النطاق، ويتفق عليه من يملكون المنتج والإصدار، وغالباً في مراجعة نطاق قصيرة.

• اجمع الأساس: ملاحظات الإصدار، والقصص ومعايير قبولها، وقائمة التغييرات، والنطاق الافتراضي في الاستراتيجية.
• حدّد ما يمسّه التغيير: اسأل المطورين أيّ المكونات والبيانات والتكاملات تتأثر؛ والتتبّع (Traceability) يُظهر المتطلبات والاختبارات المرتبطة بها.
• اكتب القائمتين، ضمن النطاق مع المعرّف والخطر والعمق، وخارج النطاق مع السبب والمسؤول، وسجّل الأسئلة المفتوحة بدلاً من التخمين.
• راجعهما مع مالك المنتج وقائد فريق التطوير وكل من يغطي عنصراً مستبعداً. اقرأ قائمة «خارج النطاق» بصوت مسموع، فهناك يظهر سوء الفهم.
• سجّل النتيجة في قسم النطاق من خطة الاختبار أو في خطة اختبار السبرنت ذات الصفحة الواحدة، مع رقم النسخة والتاريخ والمعتمِد.
• اتفق على قاعدة التغيير: من يحق له طلب التغيير، ومن يقدّر أثره، ومن يقرر.

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

مثال تطبيقي: نطاق إصدار الدفع بالتقسيط

البيان التالي هو النطاق المتفق عليه لإصدار «بستان ماركت» ⁦4.2⁩ بعد مراجعة استغرقت ⁦30⁩ دقيقة. لكل سطر خارج النطاق سبب ومسؤول، والحدّ مع المزوّد محدد بدقة، والخطر الوحيد المقبول مكتوب.

يحوّل عمود العمق (Depth) كل مستوى خطر إلى اختبارات محددة: فالبند BUS-902 يذكر قيم الحدود لمدى المبالغ المؤهلة وفق تحليل القيم الحدّية الثنائي، وسطر الانحدار يُدخل طرق الدفع التي لم تتغيّر ضمن النطاق لأنها تشترك في شيفرة الدفع التي تغيّرت.

TEST SCOPE - Bustan Market 4.2 "Pay in instalments" (fictional)          v1.0
Basis: BUS-901..905, test strategy v1.2     Agreed: PO, dev lead, QA lead (day 1)

IN SCOPE                                            Risk    Depth
BUS-901  Instalment option at checkout,             High    boundaries, negative,
         web + iOS + Android, ar/en                         exploratory, auto API
BUS-902  Eligibility: total 200.00 to 5,000.00      High    199.99 / 200.00 /
         SAR, signed-in customers only                      5,000.00 / 5,000.01
BUS-903  Instalment schedule in "My orders"         Medium  dates, amounts, ar/en
BUS-904  Refund, partial refund, cancellation       High    before and after the
         of instalment orders                               first instalment
BUS-905  Our handling of provider webhooks          Medium  approved, declined,
         (approved, declined, expired)                      expired, duplicate
Regr.    Card, mada, Apple Pay, cash on delivery    Medium  automated checkout
         (they share the checkout code)                     suite + 2 devices

OUT OF SCOPE                Reason                      Covered by
Provider credit decision    provider-owned service      provider; we test our
and the provider app                                    side in its sandbox
Seller portal               unchanged in 4.2            nightly regression suite
Load test of provider API   not ours to load-test       provider SLA (PO agreed)

Accepted risk  provider outage tested with mocked responses only (PO, day 1)
Assumptions    provider sandbox from day 1; synthetic customers only
Changes        request to PO -> QA impact note -> PO decides -> scope v1.1, v1.2

زحف النطاق: كيف تكتشفه وتتحكم فيه

زحف النطاق (Scope Creep) هو نموّ النطاق بعد الاتفاق عليه دون تغيير مقابل في الوقت أو الأشخاص أو معايير الخروج. ونادراً ما يصل في صورة طلب رسمي، بل يبدو هكذا: «وبما أنك تختبر، هل يمكنك أيضاً أن تتحقق من…»، أو معايير قبول أُعيدت كتابتها بعد تصميم الاختبار (قارن النص القديم بالجديد لترى ما تغيّر بالضبط)، أو تغيير متأخر دُمج في فرع الإصدار.

التغيير في حد ذاته أمر طبيعي. فدليل Scrum لعام ⁦2020⁩ ينص على أن النطاق أثناء السبرنت يمكن توضيحه وإعادة التفاوض عليه مع مالك المنتج كلما عُرف المزيد، وعلى أنه لا تُجرى تغييرات تعرّض هدف السبرنت للخطر. المشكلة في التغيير الذي يتجاوز الاتفاق.

في الأسبوع الثاني من إصدار «بستان ماركت» تصل رسالة: «هل يمكن أن يعمل التقسيط أيضاً مع طلبات بطاقات الهدايا؟ تغيير صغير». فيرد المختبِر بمذكرة أثر (قاعدة استرداد مختلفة، وانحدار مسار الدفع ببطاقات الهدايا، ونحو ثلاثة أيام عمل إضافية لمختبِر) وبثلاثة خيارات: تمديد الاختبار، أو نقله إلى الإصدار ⁦4.3⁩، أو تقليل الاختبار الاستكشافي لخيار التقسيط (BUS-901) مع قبول ذلك الخطر. فيختار مالك المنتج الإصدار ⁦4.3⁩، وتسجّله النسخة ⁦v1.1⁩ من النطاق.

• قيّم: الاختبارات الجديدة، والانحدار، والجهد، والخطر.
• اعرض الخيارات: وقت إضافي، أو تأجيل التغيير، أو تقليل شيء آخر مع قبول خطره.
• قرّر وسجّل: صاحب القرار يختار، ثم تُحدَّث نسخة النطاق والتقدير ومعايير الخروج.
• راقب الاتجاه المعاكس: ترك اختبارات مخططة في النهاية لنفاد الوقت يغيّر النطاق المتفق عليه أيضاً؛ فهو يحتاج إلى القرار نفسه، ويُبلَّغ عنه بوصفه مخاطر متبقية، ولا يُعاد تصنيفه على أنه «خارج النطاق».

جرّبها: مولّد سيناريوهات الانحدار جرّبها: مقارنة النصوص (Diff)

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.