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

تفشل تطبيقات الأعمال بطرق قليلة متوقعة، ومجموعة صغيرة من الاختبارات الموجهة إلى هذه الطرق تساوي أكثر من ألف اختبار للمسار السعيد. وهذه عشرة فحوص نبدأ بها دائمًا. ومع كل فحص ما يُختبر ومثال تستطيع تعديله (مكتوب بـ Pest لـ Laravel، لكن الفكرة واحدة في أي تقنية).

1. المال والتقريب

أخطاء المال صغيرة وباهظة. اختبر الحساب على أرقام ملتوية لا مستديرة.

  • إجمالي بخصم نسبة لا تنقسم تمامًا (33.33% من 100.01).
  • ضريبة على مجموع فرعي فردي، وضريبة على إجمالي بعد خصم.
  • إجماليات يجب أن تساوي مجموع بنودها. اختبر أنها تساويه.
  • مبالغ مخزّنة: أعداد صحيحة أو عشرية، لا عائمة أبدًا.
it('keeps invoice totals equal to the sum of their lines', function () {
    $invoice = Invoice::factory()->withLines([19.99, 0.01, 33.33])->taxed(14)->create();

    expect($invoice->total)->toBe($invoice->lines->sum('total'));
});

2. الصلاحيات، تُختبر من الخارج

أخطر خطأ في تطبيق أعمال أن يرى شخص أو يغيّر شيئًا لا يحق له. اختبر الصلاحيات بالتصرف بصفة كل دور ومحاولة كل ما لا يجب أن يفعله.

  • لكل دور، قائمة نقاط نهاية يجب أن تُرفض، مع توقع الرفض (403 أو 404).
  • الوصول على مستوى الكائن: مستخدم يفتح سجل مستخدم آخر بتغيير الرقم في الرابط. وهذا من أكثر العيوب شيوعًا في الواقع، ولا يلتقطه اختبار يدخل بصفة مدير فقط.
  • من فقد دورًا يجب أن يفقد الوصول فورًا.
it('refuses a clerk who opens another branch\'s invoice', function () {
    $invoice = Invoice::factory()->for(Branch::factory())->create();
    $clerk = User::factory()->clerkOf(Branch::factory()->create())->create();

    actingAs($clerk)->getJson("/api/invoices/{$invoice->id}")->assertForbidden();
});

اكتب هذه الاختبارات من جدول أدوار وإجراءات، فتبرز نقطة نهاية جديدة بلا سطر في الجدول.

3. تغيّرات حالة يجب ألا تحدث

يستطيع الطلب أن ينتقل من «جديد» إلى «مدفوع» إلى «مشحون». ولا يجوز أن ينتقل من «مشحون» إلى «جديد»، ولا من «ملغى» إلى «مدفوع». اختبر الانتقالات الممنوعة بالعناية نفسها التي تختبر بها المسموحة: كل حركة غير مشروعة يجب أن تفشل بصوت عالٍ وتترك البيانات كما كانت.

4. الزر المضغوط مرتين

اتصال بطيء، أو نقرة مزدوجة عصبية، أو تطبيق موبايل يعيد المحاولة: يصل الطلب نفسه مرتين. اختبر أنه ينشئ شيئًا واحدًا.

  • أرسل الدفعة أو الطلب أو التحويل نفسه مرتين متتاليتين؛ وتوقع سجلًا واحدًا.
  • شغّل اثنين في اللحظة نفسها (في الاختبار، بقفل أو بطلب متواز) وتوقع أن يبقى المخزون أو الرصيد متسقًا.
  • تأكد أن الواجهة تعطّل الزر، وأن الخادم لا يعتمد على ذلك.

5. التزامن عند الحدود

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

6. التواريخ والأوقات والمناطق الزمنية

  • سجل أُنشئ في 23:30 ويُعرض في منطقة زمنية أخرى.
  • نهاية الشهر ونهاية السنة: يجب أن تشمل التقارير اليوم الأخير وتستثني التالي.
  • التوقيت الصيفي حيث تطبّقه الدولة، وأيام من 23 أو 25 ساعة.
  • أسبوع يبدأ السبت أو الأحد بحسب المستخدم.
  • انتهاء صلاحية عند «منتصف الليل»: أي منتصف، وبأي منطقة زمنية؟

خزّن الأوقات بتوقيت UTC، وحوّل للعرض فقط، واجعل اختبارًا واحدًا على الأقل يعمل بمنطقة زمنية للتطبيق غير UTC.

7. مدخلات عربية ومختلطة الاتجاه

إن كان مستخدموك يكتبون بالعربية، فيجب أن تكتب اختباراتك بها.

  • أسماء وعناوين بحروف عربية وتشكيل وأرقام هندية.
  • بحث يجد «أحمد» حين يكتب المستخدم «احمد».
  • نصوص طويلة، ونص يخلط العربية باسم منتج إنجليزي.
  • الاستيراد والتصدير: ملف CSV فيه عربي يُفتح صحيحًا في Excel.
  • ملف PDF أو بريد فيه عربي، يفتحه ويقرؤه شخص.

8. الاستيراد والتصدير والبيانات السيئة

البيانات الحقيقية متسخة، وسيرفع المستخدمون الملف الذي لم تتوقعه.

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

9. القوائم والبحث والحجم

نظام سريع مع عشرة سجلات قد لا يُحتمل مع عشرة آلاف. زرع حجمًا واقعيًّا في قاعدة اختبار أو تجريب، وافحص الشاشات التي تكبر: القوائم والتقارير ولوحات المؤشرات والبحث.

  • هل تقسّم كل قائمة الصفحات وترتّب في الخادم؟
  • هل هناك استعلامات تعمل مرة لكل صف (مشكلة N+1)؟ أفشل اختبارًا حين تشغّل صفحة استعلامات أكثر من المتوقع.
  • هل ينتهي أثقل تقرير في زمن معقول؟

10. الفشل والاسترداد

يجب أن يتصرف برنامج الأعمال جيدًا حين يحدث خطأ ما.

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

اجعلها روتينًا

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

قائمة مراجعة

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

وإن أردت فريقًا يبني هذه الفحوص منذ الإصدار الأول، أو عينين إضافيتين على نظام يعمل بالفعل، تحدث إلينا. وضمان الجودة أحد التخصصات الستة التي تعمل بها BENAA.