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

لماذا يهم

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

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

النطاق: عمليات عمل لا شاشات

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

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

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

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

المشاركون: أدوار جهة العمل وأدوار ضمان الجودة

سمِّ المشاركين لكل دور داخل النطاق: أشخاص يؤدون العمل كل يوم، من ذوي الخبرة والجدد، لا المديرين أو المستخدمين الخبراء (Super Users) وحدهم ممن يعرفون الحلول البديلة. وأضف مالك عملية العمل صاحب القرار، وتأكد مع مدير كل مشارك من تفريغ وقته.

يقول منهج ISTQB للمستوى التأسيسي إن اختبار القبول يُفضَّل أن يؤديه المستخدمون المقصودون. فجانب ضمان الجودة يجهّز ويدعم، لكنه لا يقبل أبداً نيابةً عن جهة العمل؛ وإذا نفّذ المختبِرون السيناريوهات لأن المستخدمين بلا وقت، فذلك مزيد من الاختبار على يد المختبِرين، لا قبول من المستخدم.

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

الجدول الزمني: احسب بالعكس من موعد الإطلاق

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

• التجهيز: البيئة والبيانات والحسابات والسيناريوهات، من يوم الاتفاق على النطاق.
• فحص الدخول: قبل البدء ببضعة أيام، ما دام في الوقت متسع للتصرف.
• الإحاطة التمهيدية صباح اليوم الأول: النطاق، وطريقة تسجيل النتائج والعيوب، ومن يُتصل به.
• التنفيذ مع فرز يومي للعيوب، ثم الإصلاحات، واختبار التأكيد على يد المختبِرين، وإعادة الاختبار على يد المستخدمين.
• الاعتماد (Sign-off)، ثم التحضير للإصدار.

جرّبها: حاسبة التواريخ

البيئة والبيانات ومعايير الدخول والخروج

يجب أن تشبه بيئة اختبار قبول المستخدم بيئة الإنتاج بقدر ما يتحمله المشروع: الإعدادات والأدوار والصلاحيات والتكاملات نفسها، أو محاكيات متفق عليها. افصلها عن اختبار النظام، ولا تنشر إصدارات جديدة إلا في أوقات متفق عليها، حتى لا يفقد سيناريو نجح في اليوم ⁦2⁩ قيمته بصمت في اليوم ⁦3⁩.

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

ومعايير الدخول تجعل هذا التجهيز بوابة. ويصنّف منهج ISTQB معايير الدخول المعتادة في ثلاث فئات، هي البنود الثلاثة الأولى أدناه: توافر الموارد، وتوافر مواد الاختبار (Testware)، ومستوى الجودة الأولي لموضوع الاختبار (Test Object). وتحدد الخطة أيضاً معايير الخروج (Exit Criteria) التي سيقرر مالك عملية العمل وفقها في نهاية اختبار قبول المستخدم، ومتى تُعلَّق الجلسات ومتى تُستأنف:

• الجودة الأولية: استيفاء معايير الخروج من اختبار النظام، ولا عيب مفتوح بخطورة حاجب (Blocker) أو حرج (Critical) داخل النطاق، ونجاح اختبار الدخان على إصدار اختبار قبول المستخدم.
• الموارد: البيئة والبيانات جاهزة، وكل حساب مجرَّب، ووقت المشاركين مؤكد.
• مواد الاختبار: معايير القبول متفق عليها، والسيناريوهات راجعتها جهة العمل، وطريقة الإبلاغ عن العيوب جاهزة.
• معايير الخروج: تنفيذ كل السيناريوهات المخطط لها، ولا عيب مفتوح بخطورة حاجب أو حرج، واستيفاء كل معيار قبول أو تغطيته بشرط متفق عليه.
• التعليق والاستئناف (Suspension and Resumption): تُعلَّق الجلسة حين يوقف عيب حاجب أو عطل في البيئة معظم السيناريوهات، وتُستأنف حين يجتاز إصدار مُصلَح اختبار الدخان.

جرّبها: مولّد موظفين وهميين جرّبها: مصنع بيانات الاختبار

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

في وحدة مطالبات المصروفات، يصوغ قائد ضمان الجودة الخطة مع المدير المالي ومالك المنتج. والأيام أيام عمل تُعدّ من تاريخ اعتماد الخطة؛ والإطلاق في اليوم ⁦22⁩.

• النطاق: تقديم المطالبة مع الإيصالات، والموافقة أو الرفض، والصرف، والتصدير الليلي إلى نظام المحاسبة. خارج النطاق: مطالبات المسافات بالسيارة (الإصدار التالي)، والنسخ الاحتياطي والاستعادة (القبول التشغيلي).
• الأشخاص: ثلاثة موظفين، ومديران مباشران، وموظفان من المالية؛ المدير المالي يقرر؛ وقائد ضمان الجودة ينسّق.
• البيئة والبيانات: مربوطة بنسخة الاختبار من نظام المحاسبة؛ ⁦60⁩ موظفاً اصطناعياً مع مديريهم وحدود موافقتهم؛ مطالبات في كل حالة؛ سبعة حسابات شخصية.
• الدخول: فئات المعايير الثلاث السابقة، تُفحص بالأدلة في اليوم ⁦8⁩.
• الخروج: تنفيذ كل السيناريوهات المخطط لها، ولا عيب مفتوح بخطورة حاجب أو حرج، واستيفاء كل معيار قبول أو تغطيته بشرط يوافق عليه المدير المالي؛ وتُعلَّق الجلسة إذا أوقف عيب حاجب معظم السيناريوهات، وتُستأنف على إصدار مُصلَح اجتاز اختبار الدخان.
• الجدول: التجهيز في الأيام ⁦1–10⁩، والإحاطة والتنفيذ في الأيام ⁦11–16⁩، والإصلاحات وإعادة الاختبار ⁦17–19⁩، والاعتماد في اليوم ⁦20⁩، والتحضير للإصدار في اليوم ⁦21⁩، وكلها بعيدة عن إقفال نهاية الشهر.
• خطر: أحد موظفَي المالية في إجازة في اليومين ⁦15–16⁩، لذا يُسمّى بديل يحضر الإحاطة أيضاً ويحصل على حساب ثامن.

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019منهج ISTQB التخصصي لاختبار القبول: اختبار قبول المستخدم والقبول التعاقدي والتنظيمي، واختبارا ألفا وبيتا، وتعاون المختبِرين مع مالكي المنتج ومحللي الأعمال.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.