جودة حالات الاختبار ومراجعتها

لماذا يهم

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

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

ما الذي يجعل حالة الاختبار جيدة

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

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

قائمة تحقق لمراجعة حالات الاختبار

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

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

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

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

العيوب التي تكشفها المراجعة في حالات الاختبار

لحالات الاختبار عيوب كأي منتج عمل آخر. وكل نوع مما يلي يجعل الحالة تنجح حين يجب أن تفشل، أو تفشل حين يجب أن تنجح، أو يستهلك الوقت دون أن يضيف تغطية.

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

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

مثال تطبيقي: مراجعة حالة لإلغاء طلب

القصة ORD-31 تتيح للعميل إلغاء الطلب قبل شحنه. المعيار AC1: يمكن إلغاء الطلب الذي حالته «تم الطلب» أو «مدفوع» من صفحة «طلباتي» بعد التأكيد. المعيار AC2: يظهر الطلب الملغى بحالة «ملغى»، ويبدأ استرداد المبلغ كاملاً إلى وسيلة الدفع الأصلية. المعيار AC3: الطلب الذي حالته «تم الشحن» لا يظهر فيه زر «إلغاء الطلب».

كتب زميلك الحالة TC-ORD-07. تراجعها والقصة مفتوحة أمامك، وتصنّف كل ملاحظة رئيسية (قد تعطي الحالة نتيجة خاطئة) أو ثانوية (الحالة أصعب في القراءة أو الصيانة).

الجزء 1:1ID:              TC-ORD-07
الجزء 2:2Title:           Order cancellation
الجزء 3:3Requirement:     -
الجزء 4:4Preconditions:   User is logged in
الجزء 5:5Test data:       Any order
الجزء 6:6Steps:
  1. Open My orders and select the order
  2. Click "Cancel order" and confirm
الجزء 7:7  3. Check the refund and that a shipped order cannot be cancelled
الجزء 8:8Expected result:
  Order is cancelled correctly and the refund works

• ما نجح: المعرّف (ID)، والخطوتان 1 و2، فهما إجراءان واضحان يستطيع عضو جديد في الفريق اتباعهما، ولا تضيف إليهما إعادة العمل إلا اسم الزر في نافذة التأكيد.
• العنوان، ثانوية: يسمّي ميزة لا سلوكاً. المقترح: «يمكن إلغاء الطلب المدفوع قبل شحنه».
• المتطلب (Requirement)، رئيسية: فارغ، مع أن الحالة تغطي AC1 وAC2 من القصة ORD-31.
• الشروط المسبقة وبيانات الاختبار، رئيسية: قد يكون «أي طلب» طلباً مشحوناً، فتفشل الحالة على منتج سليم، ولا يوجد مبلغ استرداد يُقارن به.
• الخطوة 3، رئيسية: تفحص AC2 وAC3 معاً، مع أن AC3 يحتاج إلى طلب مشحون وإلى حالة خاصة به.
• النتيجة المتوقعة، رئيسية: «بشكل صحيح» و«يعمل» لا يمكن ملاحظتهما، فلا يمكن للحالة أن تفشل.
• المجموعة، رئيسية: لا تغطي أي حالة AC3، ولا إلغاء طلب حالته «تم الطلب» لم يُدفع بعد.

ID:              TC-ORD-07
Title:           إلغاء الطلبات
Requirement:     -
Preconditions:   المستخدم مسجّل الدخول
Test data:       أي طلب
Steps:
  1. افتح «طلباتي» واختر الطلب
  2. انقر «إلغاء الطلب» ثم أكّد
  3. تحقّق من الاسترداد ومن أن الطلب المشحون لا يمكن إلغاؤه
Expected result:
  يُلغى الطلب بشكل صحيح ويعمل الاسترداد

تسجيل الملاحظات والتحقق من إعادة العمل

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

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

ID:              TC-ORD-07
Title:           يمكن إلغاء الطلب المدفوع قبل شحنه
Requirement:     ORD-31 AC1, AC2
Preconditions:   العميلة مسجّلة الدخول بالحساب sara.k@example.com
                 حالة طلبها «مدفوع» (ORD-1042)
Test data:       ORD-1042
                 بقيمة 349.00 ريال، مدفوع بالبطاقة
Steps:
  1. افتح «طلباتي» واختر الطلب ORD-1042
  2. انقر «إلغاء الطلب»
  3. في نافذة التأكيد انقر «نعم، ألغِ الطلب»
Expected result:
  - تظهر حالة الطلب «ملغى» في «طلباتي»
  - لم يعد زر «إلغاء الطلب» ظاهراً
  - تعرض تفاصيل الطلب استرداد 349.00 ريال إلى البطاقة بحالة «بدأ»

أضافت المراجعة:
  TC-ORD-08  لا يظهر زر «إلغاء الطلب» في طلب حالته «تم الشحن» (ORD-31 AC3)
  TC-ORD-09  يمكن إلغاء طلب حالته «تم الطلب» ولم يُدفع بعد (ORD-31 AC1)

جرّبها: مقارنة النصوص (Diff) جرّبها: محسّن حالات الاختبار بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017إطار عام لمراجعة مخرجات العمل — عملية المراجعة وأدوارها وتقنياتها.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.