من المطلب إلى شرط قبول

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

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

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

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

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

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