كيف تقرأ الـ SRS وتستخرج Test Cases قبل كتابة الكود؟

أحد أكبر المفاهيم الخاطئة لدى المبتدئين في مجال ضمان الجودة هو أن عمل الـ QA يبدأ فقط عندما يجهز الكود ويستلم المطور النسخة للبدء بالفحص المباشر (Dynamic Testing).

الحقيقة هي أن أفضل مهندسي ضبط الجودة يبدأون عملهم في مرحلة المبكرة جداً عبر الاختبار الساكن (Static Testing) وتحليل وثيقة متطلبات النظام (Software Requirements Specification - SRS) أو قراءة الـ User Stories.

اكتشاف المشاكل في المتطلبات قبل كتابة السطر الأول من الكود يوفر مئات الساعات والتكاليف. في هذا الدليل، سنأخذك خطوة بخطوة لكيفية تشريح وثيقة المتطلبات وتحويلها إلى حالات اختبار (Test Cases) متكاملة بثقة.

1. تفكيك المتطلبات وفهم الصورة الكبيرة (Understanding Context)

قبل البدء بكتابة حالات الاختبار، يجب قراءة المتطلبات للوصول إلى هدف الميزة (Feature Goal):

• تحديد نوع المتطلب: هل المتطلب وظيفي (Functional Requirement) مثل تسجيل الدخول، أم غير وظيفي (Non-Functional Requirement) مثل الأداء والسرعة والأمان؟
• معرفة أطراف العملية (Actors / Users): من هو المستخدم المتأثر بهذا المتطلب؟ (مثل: Admin, Customer, Guest).
• فهم تدفق العمل (Business Logic & Workflow): ما هي الخطوات المنتظمة المتوقعة للحصول على النتيجة المطلوبة؟

2. مراجعة معايير القبول (Acceptance Criteria - AC)

في بيئات العمل الحديثة (Agile)، تأتي المتطلبات على شكل User Story ومرفق معها معايير القبول (Acceptance Criteria). هذه المعايير هي منبعك الرئيسي لكتابة الـ Test Cases:

• طريقة Given-When-Then:
  • Given: حالة النظام الحالية أو الإعدادات الأولية (Pre-conditions).
  • When: الإجراء أو الفعل الذي يقوم به المستخدم (User Action).
  • Then: النتيجة التلقائية المتوقعة من النظام (Expected Result).
• مثال عملي:
  • Given مستخدم يقف على صفحة تسجيل الدخول.
  • When يدخل بريد إلكتروني غير مسجل ويضغط على “دخول”.
  • Then يظهر النظام رسالة خطأ: “البريد الإلكتروني غير موجود”.

3. تطبيق تقنيات تصميم الاختبار (Test Design Techniques)

عند قراءة النصوص في الـ SRS، لا تكتفِ بالسيناريوهات البسيطة، بل طبق تقنيات تصميم الاختبار لاستخراج كافة الحالات الممكنة:

• تقسيم التكافؤ (Equivalence Partitioning - EP): تجميع البيانات في مجموعات تتصرف بنفس الطريقة لتعديل نطاق الاختيارات (مثال: فحص الخانات التي تقبل من عمر 18 إلى 60).
• تحليل قيم الحدود (Boundary Value Analysis - BVA): فحص القيم الدقيقة التي تقع على الحدود تماماً (مثال: فحص قيم 17 و 18 و 60 و 61).
• جدول القرار (Decision Table Testing): إذا كانت المتطلبات تحتوي على شروط متعددة تؤدي لنتائج مختلفة (مثل: شروط استحقاق الخصومات بناءً على نوع العضوية وقيمة السلة).

4. استخراج الحالات من بين السطور (Implicit Requirements & Edge Cases)

الـ SRS الجيد يخبرك بما يجب أن يفعله النظام، لكنه نادراً ما يخبرك بما يجب ألا يفعله، وهنا يأتي دور الـ QA في استخراج المتطلبات الضمنية (Implicit Requirements):

• الأخطاء والاستثناءات (Error Handling): ماذا لو توقفت استجابة الـ API أثناء معالجة البيانات؟
• الربط مع الخوادم وقواعد البيانات (Database Integration): عند إنشاء حساب جديد، هل تتحدث قاعدة البيانات فوراً وتسجل تاريخ ووقت الإنشاء؟
• جلسات العمل والصلاحيات (Permissions & Session Timeout): هل يستطيع مستخدم بدون صلاحية الوصول لهذه الصفحة عبر نسخ رابطها المباشر (URL Navigation)?

5. مراجعة المتطلبات وتحديد الثغرات (Requirements Review & Bug Finding)

أثناء كتابة الـ Test Cases من الـ SRS، ستكتشف العديد من التناقضات والغموض. هذه الأخطاء تُعتبر بَجات مبكرة في وثيقة المتطلبات نفسها (Requirements Bugs):

• الغموض (Ambiguity): كلمات مثل “سريع”، “سهل الاستخدام”، “مناسب” هي كلمات مبهمة يجب التساؤل عنها وتحديد قيم دقيقة لها.
• التناقض (Inconsistency): إذا كانت الصفحة الأولى تقول “يتم إرسال رمز OTP خلال 30 ثانية” والصفحة التالية تقول “خلال 60 ثانية”.
• النقصان (Incompleteness): عدم وجود توضيح لما يحدث عند فشل عملية معينة.

قم برفع هذه ملاحظات مباشرة للـ Product Owner أو Business Analyst لتوضيحها قبل البدء في الكود.

6. ربط المتطلبات بحالات الاختبار (Requirements Traceability Matrix - RTM)

بعد الانتهاء من كتابة حالات الاختبار، قم بربط كل Test Case برقم المتطلب الخاص بها في وثيقة الـ SRS أو بطاقة الجيرا (Jira Ticket):

• يضمن هذا الربط تحقيق تغطية كاملة للمتطلبات (100% Test Coverage).
• يسهل عليك معرفة الحالات التي يجب إعادة فحصها عندما يتغير متطلب معين لاحقاً.

ملخص خطة تحويل الـ SRS إلى Test Cases

1. ✅ Read & Understand (فهم سياق الميزة والهدف الرئيسي).
2. ✅ Analyze Acceptance Criteria (تفكيك معايير القبول إلى خطوات متتالية).
3. ✅ Apply Test Techniques (تطبيق EP و BVA وجداول القرارات).
4. ✅ Find Implicit Cases (استخراج حالات الأخطاء والـ Edge Cases الضمنية).
5. ✅ Raise Requirement Bugs (تحديد نقاط الغموض والتناقض في الوثيقة).
6. ✅ Link with RTM (ربط الـ Test Cases بالمتطلبات للتحقق من التغطية).