الاختبار المبني على المخاطر

مخاطر المنتج مقابل مخاطر المشروع

يفصل منهج ISTQB للمستوى التأسيسي بين نوعين من المخاطر، والخلط بينهما أكثر سبب شيوعاً لتحوّل سجل المخاطر إلى وثيقة بلا فائدة. خطر المنتج (Product risk)، المرتبط بخصائص جودة المنتج، هو طريقة قد يفشل بها المنتج نفسه في تلبية حاجة: إجمالي خاطئ عند الدفع، أو صفحة بحث بطيئة، أو تسرّب بيانات بين الحسابات. أما خطر المشروع (Project risk) فهو طريقة قد يفشل بها المشروع في التسليم: تأخر بيئة الاختبار، أو غياب الشخص الوحيد الذي يعرف تكامل الدفع، أو تسليم مورّد لواجهة API متأخراً بسبرنت.

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

• أمثلة على مخاطر المنتج: حساب خاطئ لضريبة القيمة المضافة، وجلسة لا تُلغى عند تسجيل الخروج، ونص عربي يفيض خارج زر، وتقرير تنتهي مهلته عند أحجام نهاية الشهر.
• أمثلة على مخاطر المشروع: بيئة staging مشتركة مع فريق آخر، وتأخر تسليم بيانات الاختبار، وعدم توفر الوصول إلى بيئة sandbox لمزوّد الدفع، ومعايير قبول غير واضحة.

كيف تحدد المخاطر

ينجح تحديد المخاطر (Risk identification) أكثر عندما تحضر وجهات نظر متعددة، لأن كل دور يرى أعطالاً مختلفة. المطوّر يعرف أي وحدة هشّة، ومالك المنتج يعرف أي فشل قد يصل إلى الأخبار، والدعم الفني يعرف ما يشتكي منه العملاء أصلاً، والمختبِر يعرف أين تكدّست العيوب في المرة السابقة.

• ورشة المخاطر — من 45 إلى 90 دقيقة بحضور المنتج والتطوير والاختبار والعمليات، والأمن والدعم عند الحاجة. امشِ في مسار الميزة خطوة خطوة واسأل عند كل خطوة: ما الذي قد يسوء هنا، ومن سيلاحظ ذلك؟
• قوائم التحقق — أعد استخدام قائمة مخاطر من ميزات مشابهة (الدفع، والمصادقة، ورفع الملفات، والتقارير) حتى لا تبدأ الورشة من صفحة بيضاء.
• خصائص الجودة — استخدم ISO/IEC 25010 قائمةً محفِّزة: الملاءمة الوظيفية، وكفاءة الأداء، والتوافق، وقابلية التفاعل، والموثوقية، والأمن، وقابلية الصيانة، والمرونة، والسلامة. واسأل عن كل منها: هل يهمّ الفشل هنا لهذه الميزة؟
• العيوب السابقة — جمّع عيوب الإصدارات السابقة حسب المكوّن والسبب الجذري؛ فالمناطق التي كثرت فيها العيوب المتسرّبة أو المعاد فتحها مرشّحة للفشل مجدداً.
• أثر التغيير — ما الجديد أو المعدَّل في هذا الإصدار، وما الذي يعتمد عليه، وما مدى تعقيد التغيير. الشيفرة الجديدة والمعاد كتابتها والتي لمسها كثيرون تحمل احتمالاً أعلى.
• المقابلات ومراجعة الخبراء — في المجالات المنظَّمة أو المتخصصة اسأل من يعرفون القواعد (المالية، والامتثال، والطاقم السريري) كيف يبدو الفشل غير المقبول.

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

تقييم المخاطر: الاحتمال × الأثر

يحصل كل خطر منتج محدَّد على تقديرين. الاحتمال (Likelihood) هو مدى ترجيح وجود الفشل وحدوثه أثناء الاستخدام؛ ويرتفع مع التعقيد والجِدّة وضعف المتطلبات وضغط الوقت وكثرة التكاملات وتاريخ العيوب. والأثر (Impact) هو مدى سوء الفشل إن وقع: خسارة مالية، أو تعرّض قانوني أو تنظيمي، أو سلامة، أو عدد المستخدمين المتأثرين، أو ضرر بالسمعة، أو توفر حل بديل. ويجمع مستوى الخطر (Risk level) بين الاثنين، غالباً كحاصل ضرب درجتين ترتيبيتين.

استخدم مقاييس نوعية بتعريفات مكتوبة حتى يقيّم شخصان بالطريقة نفسها. مقياس من 1 إلى 4 يكفي عادة؛ فالمقاييس الأدق تفتح جدالاً حول الفرق بين 6 و7 لا يستطيع أحد حسمه. اتفقوا على التعريفات قبل الورشة لا أثناءها. ويعمل مقياس من 1 إلى 5 بالطريقة نفسها — وهو المستخدم في أمثلة «بستان ماركت» في دليلَي استراتيجية الاختبار وخطة الاختبار — ما دام كل سجل يستخدم مقياساً واحداً بتعريفات مكتوبة وشرائح ثابتة، ولا تُقارن درجات مقاييس مختلفة ببعضها. وأداة «مولّد الاختبار المبني على المخاطر» المرتبطة أدناه تستخدم مقياساً مختلفاً من هذا النوع: الاحتمال والأثر من 1 إلى 5، وشرائح منخفض (أقل من 4) ومتوسط (⁦4–8⁩) وعالٍ (⁦9–14⁩) وحرج (⁦15–25⁩)، ولا حدّ أدنى فيها مرتبطاً بالأثر. لذا أعد تقدير المخاطر على مقياسها بدلاً من إدخال درجات ⁦1–4⁩ الواردة في هذه الصفحة، وطبّق قاعدة الأثر الخاصة بك على نتائجها إن كانت استراتيجيتك تنص على قاعدة كهذه.

• مقياس الاحتمال في المخطط أدناه: 1 نادر — شيفرة بسيطة لم تتغير ومختبَرة جيداً؛ 2 ممكن — تغيير معتدل؛ 3 مرجّح — شيفرة معقدة أو جديدة؛ 4 مرجّح جداً — شيفرة جديدة ومعقدة ومتطلباتها ضعيفة.
• مقياس الأثر: 1 منخفض — عيب شكلي له حل بديل سهل؛ 2 متوسط — ميزة متدهورة لدى بعض المستخدمين؛ 3 عالٍ — مسار أساسي معطّل أو بيانات خاطئة؛ 4 شديد — عواقب مالية أو قانونية أو أمنية أو على السلامة.
• في المصفوفة تمثّل الصفوف الاحتمال (من 4 في الأعلى إلى 1 في الأسفل) وتمثّل الأعمدة الأثر (من 1 إلى 4)، وفي كل خانة حاصل الضرب ومستواه. الشرائح: من 1 إلى 3 منخفض، ومن 4 إلى 6 متوسط، ومن 8 إلى 9 عالٍ، ومن 12 إلى 16 عالٍ جداً.
• القاعدة: كل خطر أثره 4 لا يقل مستواه عن «عالٍ» مهما كان حاصل الضرب؛ فالخانة الوحيدة التي تتغير بذلك هي احتمال 1 مع أثر 4، إذ ترتفع درجتها 4 من متوسط إلى عالٍ.

Likelihood                      Impact
1 Rare     – simple, unchanged,   1 Low      – cosmetic, easy workaround
             well tested          2 Medium   – feature degraded, some users
2 Possible – moderate change      3 High     – core flow broken or wrong data
3 Likely   – complex or new code  4 Severe   – money, legal, security or
4 Very likely – new + complex +                 safety consequence
             weak requirements

                     IMPACT
               1 Low   2 Medium  3 High   4 Severe
LIKELIHOOD 4 |  4 M  |   8 H   |  12 VH |  16 VH |
           3 |  3 L  |   6 M   |   9 H  |  12 VH |
           2 |  2 L  |   4 M   |   6 M  |   8 H  |
           1 |  1 L  |   2 L   |   3 L  |   4 M  |

Bands: 1–3 Low · 4–6 Medium · 8–9 High · 12–16 Very high
Rule: any risk with Impact 4 is at least High, whatever the product.

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

من مستوى الخطر إلى أولوية الاختبار وعمقه

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

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

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

استخدام المخاطر لاختيار اختبارات الانحدار

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

• اسرد ما تغيّر — الـ commits وطلبات الدمج وملاحظات الإصدار وترحيلات قاعدة البيانات وتحديثات الإعدادات والاعتماديات.
• تتبّع الاعتماديات — أي الشاشات وواجهات API والمهام المجدولة والتقارير والمكوّنات المشتركة تستدعي ما تغيّر أو تقرؤه؛ فالأداة المساعدة المشتركة أو جدول قاعدة البيانات يمسّ أكثر مما يوحي به اسم ملفه.
• شغّل النواة دائماً — مجموعة ثابتة من اختبارات الدخان والمسارات الحرجة (تسجيل الدخول، والدفع، والمعاملة الأساسية) تعمل عند كل بناء بغضّ النظر عن التغيير.
• أضف الاختبارات المتأثرة — الاختبارات المرتبطة بالمناطق المتغيّرة والمعتمدة عليها، الأعلى خطراً أولاً.
• املأ الوقت المتبقي — حسب مستوى خطر المناطق التي لم يمسّها التغيير، مع تدوير المناطق المتوسطة والمنخفضة عبر الإصدارات حتى لا تبقى إحداها دون اختبار طويلاً.
• سجّل ما لم يُشغَّل — الاختبارات غير المختارة جزء من بيان المخاطر المتبقية.

جرّبها: مولّد سيناريوهات الانحدار جرّبها: مولّد اختبارات الانحدار بالذكاء الاصطناعي

مثال عملي: سجل مخاطر لميزة إتمام الشراء

على سبيل المثال، متجر إلكتروني افتراضي يضيف صفحة إتمام شراء جديدة مع بطاقات محفوظة ورموز خصم وتحقق 3-D Secure. أنتجت الورشة السجل أدناه. تستخدم الدرجات مقياسَي ⁦1–4⁩ السابقين، لا مقياس ⁦1–5⁩ الذي يعتمده «مولّد الاختبار المبني على المخاطر» المرتبط أدناه؛ فإدخال هذه الأرقام في المولّد يعطي مستويات مختلفة (يخرج R4 متوسطاً، لأن المولّد لا يطبّق قاعدة «الأثر 4»). و«استجابة الاختبار» (Test response) هي ما تلتزم به الخطة لكل خطر.

• السجل بإيجاز (الاحتمال، ثم الأثر، ثم الدرجة والمستوى): R1 خصم المبلغ من البطاقة دون إنشاء طلب بسبب انتهاء مهلة البوابة بعد التحصيل — 3 و4، الدرجة 12، عالٍ جداً؛ R2 إجمالي خاطئ عند اجتماع الخصم وضريبة القيمة المضافة — 3 و4، الدرجة 12، عالٍ جداً؛ R3 الإرسال المزدوج ينشئ طلبين — 2 و4، الدرجة 8، عالٍ؛ R4 ظهور بطاقة محفوظة لمستخدم آخر (خلل في التحكم بالوصول) — 1 و4، الدرجة 4، رُفع إلى عالٍ بقاعدة «الأثر 4»؛ R5 فشل تحدي 3-D Secure على Safari في الجوال — 2 و3، الدرجة 6، متوسط؛ R6 تأخر رسالة التأكيد أكثر من 5 دقائق — 2 و2، الدرجة 4، متوسط؛ R7 اقتطاع العنوان العربي في إيصال PDF — 3 و1، الدرجة 3، منخفض.
• ترتيب العمل: R1 وR2 أولاً، ثم R3 وR4، ثم R5 وR6، وأخيراً R7.
• يحصل R1 وR2 على معظم الجهد: تقنيتان لكل منهما، واختبارات API مؤتمتة في خط التكامل (Pipeline)، وجلسة استكشافية حول حالات فشل الدفع.
• احتمال R4 منخفض لكن أثره شديد؛ ودرجته 4 وحدها تجعله متوسطاً، فترفعه قاعدة «الأثر 4» إلى عالٍ كي لا تخفي الدرجةُ احتمالَ خرق للبيانات.
• يحصل R7 على حالة اختبار واحدة؛ وإذا تأخر الجدول فهو أول ما يُحذف، ويُكتب الحذف في بيان المخاطر المتبقية.

Feature: Checkout v2 (saved cards, discount codes, 3-D Secure)   Release 5.3

ID  Risk                                            L  I  Score Level  Test response
R1  Card charged but no order created               3  4  12    VH     State transitions of payment; gateway
    (gateway timeout after capture)                                     timeout/5xx via mock; retry and
                                                                        reconciliation check; exploratory
R2  Wrong total when discount and VAT combine       3  4  12    VH     Decision table promo x VAT x rounding;
    (e.g. 99.99 SAR, 10% code, 15% VAT)                                boundary amounts 0.01 / max; API tests
R3  Double submit creates two orders                2  4   8    H      Double click, browser back, network
                                                                        retry; idempotency key verified
R4  Another user's saved card visible              1  4   4    H*     Two-account authorization tests;
    (broken access control)                                            added to security regression
R5  3-D Secure challenge fails on mobile Safari      2  3   6    M      Target devices: happy + cancel path
R6  Confirmation email delayed over 5 minutes       2  2   4    M      One end-to-end check; alert in staging
R7  Arabic address truncated on receipt PDF          3  1   3    L      One case in localisation pass

* raised from Medium to High by the Impact-4 rule.
Order of work: R1, R2 -> R3, R4 -> R5, R6 -> R7.

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

تخفيف المخاطر ومتابعتها أثناء الإصدار

الاختبار وسيلة تخفيف واحدة من عدة وسائل. يمكن خفض خطر عالٍ أيضاً بتغيير التصميم (مفاتيح عدم التكرار Idempotency keys ضد الطلبات المزدوجة)، أو بتقليل التعرّض (علم ميزة Feature flag أو إطلاق تدريجي)، أو باكتشاف الفشل سريعاً في الإنتاج (مراقبة وتنبيهات على مطابقة المدفوعات). ويجب أن يسمّي سجل المخاطر وسيلة التخفيف، لا الاختبارات فقط.

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

• أضف خطراً عندما يكشف الاختبار نمط فشل جديداً؛ لا تنتظر الورشة التالية.
• اربط كل عيب بالخطر الذي يؤكده، حتى يعرض السجل أدلة لا آراء فقط.
• لا تغلق خطراً إلا بعد تنفيذ اختباراته المخطط لها ونجاحها، أو بعد قبوله رسمياً من مالكه.

الإبلاغ عن المخاطر المتبقية

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

Residual risk — Checkout v2, release 5.3

Reduced:   R1, R2, R3, R4 — planned tests executed and passed; no open defects
Partial:   R5 — tested on 2 of 4 target devices (Android tablet and
           older iOS not available); owner: product manager, accepted
Open:      R6 — defect CHK-214 (email delayed up to 12 min under load)
           open, severity Major; mitigation: alert on queue length
Not tested: R7 — cut for schedule; one known cosmetic issue possible
Out of scope: refunds flow (unchanged this release; smoke only)

Recommendation: release with the R5 and R6 conditions above accepted in writing.

جرّبها: محلّل تغطية الاختبار بالذكاء الاصطناعي

حدود الاختبار المبني على المخاطر

• الدرجات ذاتية. الاحتمال خصوصاً حكم تقديري؛ ومجموعات مختلفة تقيّم الخطر نفسه بشكل مختلف، وقد يثبّت أعلى الأصوات في الورشة تقديرات الآخرين. قيّموا منفردين أولاً ثم ناقشوا الفروق.
• الدقة الزائفة. ضرب رقمين ترتيبيين ينتج رقماً يبدو دقيقاً وليس كذلك: 12 ليست أخطر من 8 بنسبة 50% بالضبط. استخدم الدرجات للفرز والتصنيف في شرائح، ولا تحسب منها نسباً مئوية أو متوسطات.
• المخاطر المجهولة تبقى مجهولة. لا يحتوي السجل إلا الأعطال التي تخيّلها أحد. خصّص وقتاً للاختبار الاستكشافي غير مرتبط بأي خطر مدرج.
• السجلات تتقادم. سجل كُتب في بداية المشروع ولم يُحدَّث يعطي ثقة زائفة. أعد التقييم عند نقاط ثابتة.
• الخطر المنخفض ليس انعدام خطر. المناطق منخفضة الخطر تحصل مع ذلك على فحص أدنى، وتأجيلها المتكرر عبر الإصدارات خطر بحد ذاته.
• البيروقراطية. للتغيير الصغير تكفي محادثة من خمس دقائق بالسؤالين نفسيهما — ما مدى الاحتمال، وما مدى السوء؛ فالطريقة قابلة للتصغير.

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

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
• 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المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.