كيف تكتب سيناريوهات اختبار قبول لنظام الأرشفة؟

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

عناصر السيناريو الذي يمكن تنفيذه وقياسه

الفرق بين سيناريو قبول مفيد وآخر شكلي يظهر عند أول خلاف: هل نجح الاختبار أم لا؟ السيناريو الذي يقول «التحقق من عمل البحث» سينجح دائمًا في نظر من نفذه، ويفشل دائمًا في نظر من ينتظر نتيجة محددة. لذلك اجعل لكل سيناريو العناصر التالية:

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

سيناريو قبول مثال مكتوب بالكامل

المثال التالي سيناريو شامل يمر بعدة وحدات في مسار واحد، وهذا النوع يكشف مشكلات لا تظهر في اختبار كل وحدة منفردة، مثل صلاحية لا تنتقل مع الوثيقة من مرحلة إلى أخرى.

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

التغطية: كيف تعرف أن السيناريوهات كافية؟

لا تقاس التغطية بعدد السيناريوهات، بل بما لا يغطيه أي منها. ابنِ مصفوفة تتبع بسيطة: صفوفها المتطلبات المرفقة بالعقد، وأعمدتها أرقام السيناريوهات، وضع علامة حيث يغطي السيناريو المتطلب. كل صف فارغ فجوة. ثم تأكد من وجود الأنواع التالية:

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

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

صياغة النتيجة المتوقعة: من الانطباع إلى القياس

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

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

الأدلة: ما يُحفظ وكيف

الدليل هو ما يبقى بعد أن ينسى الجميع يوم الاختبار. وهو ما سيُطلب عند مراجعة داخلية، أو عند خلاف على ملاحظة، أو عند تسليم المشروع لمسؤول نظام جديد. اتفق على ثلاثة أمور قبل البدء:

1. نوع الدليل لكل خطوة: مكتوب في السيناريو نفسه، حتى لا يُكتفى بلقطة شاشة واحدة للسيناريو كله.
2. تسمية الملفات: رقم السيناريو ثم رقم الخطوة ثم تاريخ التنفيذ، مثل «قب-مسار-02_06_التاريخ». هذا يغني عن ملف شرح منفصل.
3. مكان الحفظ: احفظ الأدلة في نظام الأرشفة نفسه، في ملف المشروع بنوع وثيقة «دليل اختبار قبول»، بصلاحيات فريق المشروع. هكذا تكون الأدلة نفسها أول ملف يُدار بالنظام، ويُستخرج لها سجل تدقيق.

وسجل التدقيق في النظام دليل قوي بحد ذاته، لأنه يوثق من نفذ الخطوة ومتى. اجعل استخراجه خطوة أخيرة في كل سيناريو شامل كما في المثال.

إدارة الملاحظات وإعادة الاختبار

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

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

أما طلبات التحسين، فهي أكثر ما يطيل مرحلة القبول دون داعٍ. سجلها في قائمة منفصلة، وقيّمها لاحقًا كطلبات تغيير لها أثر على المدة والتكلفة، ولا تجعلها شرطًا لتوقيع المحضر ما لم تكن في المتطلبات.

محضر القبول: ما يجب أن يتضمنه

المحضر ليس ورقة توقيع، بل ملخص يمكن لمن لم يحضر الاختبار أن يفهم منه ما قُبل وما بقي. تأكد من أن يتضمن:

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

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

أخطاء شائعة في مرحلة اختبار القبول

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

الخطوة التالية: اجعل القبول جزءًا من العرض والعقد

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

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

أسئلة شائعة