كيف تكتبون معايير القبول لتطبيق ويب صغير
اكتبوا كل معيار قبول في ثلاثة أجزاء قصيرة: الوضع الذي تبدأون منه، والشيء الوحيد الذي يفعله المستخدم، والنتيجة التي تتوقعون رؤيتها. اجعلوا كل معيار يخص سلوكاً واحداً، واستخدموا قيماً محددة، وصيغوه بحيث يستطيع شخص لم يبنِ الميزة أن يقول بوضوح هل نجحت. اتفقوا على المعايير قبل بدء العمل لا بعده.
ما الغاية من معايير القبول
تحدّد معايير القبول ما يجب أن يتحقق لتُعدّ الميزة منجزة. وهي تُنهي الجدال في نهاية المشروع، لأن الاتفاق كُتب في البداية. كما تمنح المنفّذ هدفاً محدداً يعمل نحوه، بدلاً من فكرة عامة مثل «ينبغي أن يكون الحجز سهلاً».
النمط ذو الأجزاء الثلاثة
تصف وثائق Cucumber الخاصة بـ Gherkin بنية تُستخدم للمواصفات القابلة للتنفيذ. تصف خطوات Given السياق الابتدائي للنظام. وتصف خطوات When حدثاً. وتصف خطوات Then نتيجة متوقعة. لا تحتاجون إلى أي برنامج للاستفادة من الفكرة. فالكتابة بهذا الترتيب تفرض الوضوح ببساطة.
ويذكر مرجع Cucumber أيضاً أن الغرض من خطوات Given هو وضع النظام في حالة معروفة قبل أن يبدأ المستخدم بالتفاعل معه، وينصح بتجنب الحديث عن تفاعل المستخدم فيها. فإذا بدت خطوة Given لديكم كأنها فعل، فمن المرجّح أن مكانها في When.
سلوك واحد في كل مرة
اجعلوا كل معيار يخص سلوكاً واحداً. المعيار «Given a customer has chosen a free slot, when they submit the form, then they see a confirmation with the date and time» قابل للتحقق. أما «النموذج يعمل جيداً ويبدو جميلاً» فليس كذلك. وإذا احتاجت جملة إلى كلمة «و» بين نتيجتين، ففكّروا في تقسيمها.
استخدموا قيماً محددة
استبدلوا الكلمات الغامضة بقيم يمكن اختبارها: تاريخ محدد ومبلغ محدد ورسالة بنصّها الدقيق. يبيّن مرجع Gherkin كيف يمكن جمع أمثلة متشابهة في مخطط سيناريو مع جدول قيم. وببساطة: إذا انطبقت القاعدة نفسها على عدة حالات، فاكتبوا القاعدة مرة واحدة وسرّدوا القيم تحتها.
غطّوا حالات الرفض والحالات الحدّية
لكل ميزة، أضيفوا معياراً واحداً على الأقل لما لا ينبغي أن يحدث: موعد محجوز مسبقاً، أو عنوان بريد إلكتروني ناقص، أو شخص بلا صلاحية. كثير من الخلافات في نهاية المشروع تتعلق بحالة حدّية لم يدوّنها أحد.
- النتيجة المتوقعة عند إدخال بيانات غير صالحة
- ما الذي يراه مستخدم بلا صلاحية
- ما الذي يحدث مع قائمة فارغة أو مستخدم جديد
- كيف تبدو الصفحة على شاشة هاتف ضيقة
- ما الخطوات التي يجب أن تظل تعمل بلوحة المفاتيح وحدها
مثال افتراضي
تخيّلوا تطبيقاً صغيراً يطلب فيه العملاء زيارة صيانة. المعيار الأول: Given عميل مسجّل الدخول وليس لديه طلب مفتوح، when يرسل طلباً مع وصف ويوم مفضّل، then يظهر الطلب في قائمته بحالة «تم الاستلام». والثاني: Given الوصف فارغ، when يرسل، then يبقى النموذج مفتوحاً ويعرض رسالة بجانب حقل الوصف. والثالث: Given عميل مسجّل الدخول، when يفتح عنوان طلب عميل آخر، then تظهر له صفحة رفض الوصول. يمكن التحقق من كل منها في دقيقة. هذا المثال افتراضي.
اتفقوا عليها واحتفظوا بها
راجعوا المعايير مع الشخص الذي سيقبل العمل، قبل البناء. وعندما يتغير شيء، غيّروا المعايير أيضاً ودوّنوا التاريخ. وعند التسليم، استعرضوها واحداً واحداً معاً. نجاح كل المعايير لا يثبت أن التطبيق مثالي، لكنه يجعل الاتفاق مرئياً ويجعل التسليم هادئاً.