سيناريوهات قبول المستخدم

سيناريو اختبار قبول المستخدم (UAT Scenario) وصفٌ لعمل حقيقي من أعمال المنشأة ينفّذه مستخدم مقصود في النظام الجديد ليحكم على ما إذا كان النظام يدعم هذا العمل: من يؤديه، وانطلاقاً من أي وضع في العمل، وماذا يفعل بلغة العمل، وما النتيجة التي يتوقعها العمل. مثال ذلك: تسجّل موظفة الحسابات الدائنة فاتورة مورّد بقيمة ⁦18,400.00⁩ ريال تطابق أمر الشراء، فيعتمدها المدير المالي، فتظهر في دفعة السداد يوم الخميس.

وهو ينطلق من سيناريو الاختبار بالمعنى الذي عرفته في درس سيناريوهات الاختبار، أي حالة ونتيجة تهمّ، لكن الكلمة في اختبار القبول تشمل عادةً أكثر من ذلك: فالسيناريو يقدّم أيضاً بيانات واقعية وبضع خطوات مكتوبة بلغة العمل، حتى يستطيع المستخدم تنفيذه دون مختبِر. وهذا يقرّبه من حالة اختبار شاملة من البداية إلى النهاية (End-to-End)، وتسمّيه بعض الفرق نصّ اختبار القبول (UAT Script). ويختلف كذلك في ثلاثة أمور: يُكتب لمستخدمي الأعمال ويراجعونه، ويتبع عملية عمل (Business Process) عبر الأدوار والشاشات بدلاً من وظيفة واحدة، ونتيجته المتوقعة نتيجة في العمل لا قيمة حقل. وقد حدّدت خطة اختبار القبول من يختبر وأين ومتى؛ أما السيناريوهات فتحدد ما الذي سيفعلونه فعلاً.

لماذا يهم

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

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

كتابة السيناريوهات من عمليات العمل

ابدأ من طريقة عمل المنشأة، لا من الشاشات ولا من قائمة المتطلبات. خذ كل عملية عمل داخلة في نطاق اختبار القبول، مثل «من الشراء إلى الدفع» (Procure to Pay) أو «من التوظيف إلى انتهاء الخدمة» (Hire to Retire)، وراجعها خطوةً خطوةً مع مالك العملية (Process Owner) أو مستخدم رئيسي (Key User)، أي مستخدم متمرّس يمثّل زملاءه في الدور نفسه. دوّن كل نشاط بترتيبه، والدور الذي يؤديه، والحدث الذي يبدأ عنده، وما الذي ينتج عنه، وإلى أين ينتقل العمل بعده، بما في ذلك التسليم إلى فرق وأنظمة أخرى.

ثم اكتب سيناريو رئيسياً واحداً من البداية إلى النهاية للمسار المعتاد: العمل كما يجري في يوم عادي وببيانات عادية. فهو يُثبت أن العملية متماسكة عبر الأدوار. بعد ذلك أضف سيناريوهات فرعية (Variants) للحالات الأخرى التي يجب أن يتعامل معها العمل. ويسمّي منهج ISTQB لاختبار القبول (Acceptance Testing) هذا الأسلوبَ الاختبارَ المبني على عمليات العمل (Business Process-Based Testing): تُشتق اختبارات القبول من نماذج عمليات العمل وقواعدها، فتغطي المسارات عبر العملية والقرارات في قواعدها.

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

جرّبها: المتطلبات ← سيناريوهات اختبار جرّبها: قصة المستخدم ← سيناريوهات اختبار

لغة يستطيع مستخدمو الأعمال العمل بها

ينبغي أن يقرأ مستخدم الأعمال السيناريو فيقول «نعم، هذا عملي» قبل أن ينفّذه. اكتب بمفردات المستخدمين أنفسهم، وبلغتهم إن كانوا يعملون بالعربية أو الهندية. واطلب من مستخدم رئيسي مراجعة الصياغة قبل الجلسة؛ فالسيناريو الذي يربك قارئه يهدر أندر وقت في اختبار القبول.

  • ضع هدف العمل في العنوان: «سداد فاتورة مورّد مطابقة لأمر الشراء»، لا «TC_AP_014 حفظ الفاتورة».
  • اكتب الغرض لا النقرات: «يعتمد فيصل الفاتورة»، لا «انقر btnApprove في اللوحة اليمنى». فمسارات النقر تخفي سؤال العمل وتتعطل حين تتغير الشاشة. وإن كان المستخدمون جدداً على النظام، فأعطهم دليل استخدام قصيراً منفصلاً.
  • استخدم مصطلحات العمل: المورّد، واستلام البضاعة، ودفعة السداد، لا vendor_id ولا «سجل GRN»، إلا إذا كان المستخدمون أنفسهم يتحدثون هكذا.
  • قدّم بيانات واقعية يعرفها المستخدمون: مورّداً باسمه، ومبالغ، وتواريخ، والدور وحساب الاختبار الذي يُستخدم.
  • اذكر نتيجة العمل المتوقعة التي يستطيع المستخدم التحقق منها: ما يراه، وما يصل إلى الشخص التالي في العملية، وأي مستند أو مبلغ ينتج.
  • اجعل لكل سيناريو هدف عمل واحداً وبضع خطوات، واترك مكاناً لحكم المستخدم وملاحظاته.

تغطية قواعد العمل

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

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

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

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

مثال تطبيقي: سداد فاتورة مورّد

شركة تُجري اختبار القبول لنظام مالي جديد. والجزء المشمول هنا من عملية «من الشراء إلى الدفع» له أربع خطوات: تسجّل موظفة الحسابات الدائنة فاتورة المورّد، ويطابقها النظام مع أمر الشراء ومع سجل استلام البضاعة (Goods Receipt) الذي يثبت وصولها، ويعتمدها المدير المالي، ثم تُسدَّد في دفعة السداد الأسبوعية. وقد أكّد مالك العملية أربع قواعد.

السيناريو الرئيسي UAT-01، المكتوب كاملاً أدناه، ينفّذ الخطوات الأربع بفاتورة تجتاز كل القواعد. وكل قاعدة يمكن أن تغيّر النتيجة تضيف سيناريو فرعياً واحداً على الجانب الذي يتغير:

  • BR-1: لا تُسجَّل الفاتورة إلا مقابل أمر شراء مفتوح للمورّد نفسه. السيناريو الفرعي UAT-02: فاتورة تشير إلى أمر شراء مغلق، فيرفض النظام تسجيلها وترى الموظفة السبب.
  • BR-2: الفاتورة التي تزيد على أمر الشراء بأكثر من ⁦2%⁩ تُعلَّق حتى يعالجها موظف المشتريات. السيناريو الفرعي UAT-03: فاتورة بقيمة ⁦18,952.00⁩ ريال مقابل أمر بقيمة ⁦18,400.00⁩ ريال، أي بزيادة ⁦3%⁩.
  • BR-3: يعتمد المدير المالي الفواتير حتى ⁦50,000.00⁩ ريال؛ وما زاد على ذلك يعتمده الرئيس التنفيذي للمالية (CFO) أيضاً. السيناريو الفرعي UAT-04: فاتورة بقيمة ⁦50,400.00⁩ ريال.
  • BR-4: تُسدَّد الفواتير المعتمدة في دفعة السداد التالية يوم الخميس. لها نتيجة واحدة فقط، فلا تحتاج إلى سيناريو فرعي: يُظهرها UAT-01.
عملية فاتورة المورّد: ينفّذ UAT-01 الخطوات الأربع بفاتورة عادية، وكل قاعدة يمكن أن تغيّر النتيجة تضيف سيناريو فرعياً: أمر شراء مغلق، وزيادة ⁦3%⁩ على الأمر، وفاتورة بقيمة ⁦50,400⁩ ريال.
  1. خطوة العملية والدور:
    1تسجيل الفاتورةموظفة الحسابات الدائنة
    السيناريو الفرعي للقاعدة:
    UAT-02: فاتورة تشير إلى أمر مغلقيُرفض تسجيلها وترى الموظفة السبب
  2. خطوة العملية والدور:
    2المطابقة مع الأمر والاستلامالنظام، وتراجع الموظفة النتيجة
    السيناريو الفرعي للقاعدة:
    UAT-03: ⁦18,952.00⁩ ريال مقابل أمر بقيمة ⁦18,400.00⁩ ريالزيادة ⁦3%⁩: معلّقة حتى يعالجها موظف المشتريات
  3. خطوة العملية والدور:
    3الاعتمادالمدير المالي، ومعه الرئيس التنفيذي للمالية فوق ⁦50,000.00⁩ ريال
    السيناريو الفرعي للقاعدة:
    UAT-04: فاتورة بقيمة ⁦50,400.00⁩ رياليعتمدها المدير المالي والرئيس التنفيذي للمالية كلاهما
  4. خطوة العملية والدور:
    4السداددفعة السداد الأسبوعية
    السيناريو الفرعي للقاعدة:
    لا سيناريو فرعياً: نتيجة واحدةيُظهرها UAT-01

طوال الخطوات 1–4 UAT-01، السيناريو الرئيسي: فاتورة بقيمة ⁦18,400.00⁩ ريال مطابقة لأمرها تجتاز كل خطوة على الجانب المعتاد من كل قاعدة

UAT-01  سداد فاتورة مورّد مطابقة لأمر الشراء
العملية: من الشراء إلى الدفع، الخطوات 1 إلى 4    القواعد الظاهرة: BR-1، BR-2، BR-3، BR-4
من:      هدى، موظفة الحسابات الدائنة؛ فيصل، المدير المالي
البداية: أمر الشراء PO-5521 لمؤسسة النور للتوريدات: 40 كرسياً مكتبياً،
         18,400.00 ريال، مفتوح؛ استُلمت الكراسي الأربعون كلها

الخطوات
1. تسجّل هدى فاتورة النور INV-7730 بمبلغ 18,400.00 ريال مقابل PO-5521.
2. تراجع هدى نتيجة المطابقة الظاهرة للفاتورة.
3. يعتمد فيصل الفاتورة من قائمة الفواتير التي تنتظر اعتماده.
4. تفتح هدى دفعة السداد التالية يوم الخميس.

نتيجة العمل المتوقعة
- الفاتورة مطابقة لأمر الشراء ولاستلام البضاعة، وغير معلّقة.
- اعتماد فيصل يكفي: لا تُحال الفاتورة إلى الرئيس التنفيذي للمالية.
- دفعة السداد تدفع لمؤسسة النور 18,400.00 ريال عن INV-7730.

حكم مستخدم الأعمال: تعمل كما نعمل / تعمل مع ملاحظات / لا تعمل
الملاحظات:

أخطاء شائعة

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

من منظور ضمان الجودة

في الفرق الحقيقية كثيراً ما يكتب المختبِر أو محلل الأعمال مسودة السيناريوهات، وتبقى ملكيتها لجهة الأعمال. اكتب المسودة من مراجعة العملية خطوةً خطوةً، ثم اعقد مراجعة قصيرة مع مالك العملية ومستخدم رئيسي أو اثنين: هل يطابق كل سيناريو طريقة عملهم؟ هل القواعد صحيحة؟ هل ينقص شيء يفعلونه كل شهر؟ وتصحيحاتهم كثيراً ما تكون أثمن نتائج التحضير لاختبار القبول، لأنها تكشف متطلبات لم يكتبها أحد.

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

تمرين عملي

اكتب سيناريوهات قبول لمطالبات المصروفات

المطلوب

شركة تُجري اختبار القبول لعملية جديدة لمطالبات المصروفات. يقدّم الموظف المطالبة مع الإيصالات، ويعتمدها مديره المباشر، وتراجعها الإدارة المالية، ثم تُصرف مع الراتب. وقد أكّدت الإدارة المالية القواعد أدناه.

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

المادة
مطالبات المصروفات: قواعد أكّدتها الإدارة المالية

EC-1  يلزم إيصال لكل بند قيمته 100.00 ريال أو أكثر.
EC-2  يعتمد المدير المباشر المطالبات حتى 3,000.00 ريال؛
      وما زاد على ذلك يعتمده مدير الإدارة المالية أيضاً.
EC-3  تُرفض البنود التي مضى عليها أكثر من 60 يوماً.
EC-4  لا يعتمد أحد مطالبته بنفسه: مطالبة المدير تذهب إلى مديره.
EC-5  تُصرف المطالبات المعتمدة مع الراتب الشهري التالي.
الخطوات
  1. اكتب خطوات العملية والدور الذي يؤدي كل خطوة.
  2. اكتب السيناريو الرئيسي: العنوان، ومن يؤديه، والوضع في البداية، والخطوات، ونتيجة العمل المتوقعة.
  3. لكل قاعدة يمكن أن تغيّر النتيجة، أضف سيناريو فرعياً واحداً ببيانات واقعية قريبة من الحد.
  4. ابنِ مصفوفة القواعد والسيناريوهات، وتأكد من ظهور كل قاعدة، ودوّن أي سؤال للإدارة المالية.
إظهار الإجابة النموذجية
الإجابة النموذجية

العملية: يقدّم الموظف المطالبة مع الإيصالات؛ يعتمدها المدير المباشر؛ تراجعها الإدارة المالية؛ تصرفها إدارة الرواتب مع الراتب التالي.

السيناريو الرئيسي UAT-10 «مطالبة بغداء عمل مع عميل وأجرة سيارة». من: سارة، مسؤولة المبيعات؛ وعمر، مديرها المباشر؛ ولينا، موظفة في الإدارة المالية. البداية: دفعت سارة الأسبوع الماضي ثمن غداء مع عميل بقيمة ⁦240.00⁩ ريالاً ولديها إيصاله، وأجرة سيارة بقيمة ⁦45.00⁩ ريالاً دون إيصال. الخطوات: 1. تقدّم سارة مطالبة واحدة بالبندين مع إيصال الغداء. 2. يعتمدها عمر من قائمة المطالبات التي تنتظر اعتماده. 3. تراجعها لينا. 4. تفتح سارة كشف راتبها التالي. المتوقع: يرى عمر البندين والإيصال؛ وبعد اعتماده تنتقل المطالبة إلى الإدارة المالية دون المرور بمدير الإدارة المالية؛ وتجدها لينا مكتملة فتحيلها إلى الصرف؛ ويتضمن كشف راتب سارة التالي ⁦285.00⁩ ريالاً مصروفات. ويُظهر السيناريو EC-1 (إيصال لبند ⁦240.00⁩ فقط)، وEC-2 (أقل من ⁦3,000.00⁩، فيكفي عمر)، وEC-3 (بنود حديثة)، وEC-5.

السيناريوهات الفرعية: UAT-11، بند مواقف سيارات بقيمة ⁦100.00⁩ ريال دون إيصال: لا يمكن تقديم المطالبة حتى يُرفق الإيصال (EC-1). UAT-12، رسوم مؤتمر بقيمة ⁦3,200.00⁩ ريال: يجب أن يعتمدها مدير الإدارة المالية إلى جانب عمر (EC-2). UAT-13، بند مؤرخ قبل ⁦61⁩ يوماً: يُرفض هذا البند ويظهر سبب الرفض (EC-3). UAT-14، يقدّم عمر مطالبته الخاصة: تذهب إلى مديره، ولا تصل إليه هو أبداً (EC-4).

مصفوفة القواعد والسيناريوهات: EC-1: UAT-10 وUAT-11؛ EC-2: UAT-10 وUAT-12؛ EC-3: UAT-10 وUAT-13؛ EC-4: UAT-14؛ EC-5: UAT-10. كل قاعدة تظهر مرة واحدة على الأقل.

أسئلة للإدارة المالية: هل يوقف غيابُ الإيصال المطالبةَ عند تقديمها كما يفترض UAT-11، أم تعيدها الإدارة المالية لاحقاً؟ هل تُحسب الأيام الستون حتى تاريخ تقديم المطالبة أم حتى تاريخ اعتمادها؟ إذا رُفض بند واحد، فهل تستمر بقية المطالبة؟ ومن يعتمد عند غياب مدير الإدارة المالية؟

أسئلة شائعة

هل تُكتب سيناريوهات اختبار القبول بصيغة Given/When/Then؟

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

من يكتب سيناريوهات اختبار القبول: المختبِرون أم مستخدمو الأعمال؟

أيٌّ منهما، لكن يجب أن تكون ملكيتها لجهة الأعمال. كثيراً ما يكتب مختبِر أو محلل أعمال المسودة من مراجعة العملية خطوةً خطوةً، ثم يراجعها المستخدمون الرئيسيون ويكملونها؛ وفي بعض المؤسسات يكتبها المستخدمون بمساعدة مختبِر. والمهم أن يتفق من سيقبلون النظام على أن السيناريوهات تمثّل عملهم.

كم سيناريو أحتاج إليه في اختبار القبول؟

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

هل أعيد استخدام حالات اختبار النظام في اختبار القبول؟

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

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019منهج ISTQB التخصصي لاختبار القبول: اختبار قبول المستخدم والقبول التعاقدي والتنظيمي، واختبارا ألفا وبيتا، وتعاون المختبِرين مع مالكي المنتج ومحللي الأعمال.
  • ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.

تدرّب بأدوات متقن

حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.

تصميم الاختبارات

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

تصميم الاختبارات

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة