المتطلب الذي يسمح باختبارين متناقضين

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

يمكن صياغة مثال قبول على صورة «إذا/عندما/فإن» بشرط أن تحمل الخطوات بيانات تكشف القرار. بعد حسم السياسة لتكون الإلغاء مسموحًا قبل الموعد بـ24 ساعة تمامًا، شاملاً لحظة الحد، اكتب: إذا كان الموعد في 20 يونيو 09:00، وعندما يطلب صاحبه الإلغاء في 19 يونيو 09:00، فإن الحالة تصبح ملغاة ويصدر رد للمبلغ المحدد. وعند 19 يونيو 09:00:01 يُرفض الطلب ولا يتغير الموعد. هذان المثالان يختبران الفرق بين `<=` و`<` والثانية المجاورة، لكنهما لا يثبتان صحة معالجة كل منطقة زمنية. أضف مثالًا لهوية غير مالك للحجز إذا كانت الصلاحية جزءًا من القاعدة. يظهر من الأمثلة نفسها ما يجب تسجيله: الحالة السابقة واللاحقة، وقت الطلب، هوية الفاعل، والمبلغ.

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