اختبارات مواقع الشركات: كيف نتحقق من رحلة العميل قبل النشر؟

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

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

ابدأ بوعد يمكن التحقق منه

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

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

مثال عملي: طلب الانضمام إلى ورشة

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

1. المسار الناجح: يختار الزائر الورشة المفتوحة ويرسل بيانات صحيحة. يتحقق الاختبار من وجود رقم مرجعي ومن حفظ طلب واحد بحالة «بانتظار المراجعة»، ثم من ظهوره للموظف المناسب.
2. بيانات ناقصة: يترك الزائر حقلا إلزاميا فارغا أو يملؤه بمسافات. تظهر رسالة مفهومة قرب الحقل، ولا ينشأ طلب. تبقى المدخلات السليمة كي لا يبدأ الزائر من الصفر.
3. تغير التوفر: يغلق التسجيل بعد فتح الصفحة وقبل الإرسال. يرفض الخادم الطلب وفق القاعدة المتفق عليها، وتوضح الواجهة سبب الرفض وخطوة المتابعة.
4. إرسال متكرر: ينقر الزائر مرة أخرى أو يعيد المحاولة بعد انقطاع الاتصال. يفحص الاختبار عدد السجلات والرقم المرجعي، وليس اختفاء الزر وحده.
5. مراجعة مخولة: يستطيع الموظف المسؤول قراءة الطلب وتغيير حالته، بينما يفشل الحساب الآخر دون كشف بيانات مقدم الطلب.

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

اختر موضع الاختبار بحسب السؤال

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

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

اختبر الرفض والتعافي بوضوح

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

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

اجعل النتيجة جديرة بالثقة

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

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

اربط الاختبارات بقرار النشر

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

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

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

أُعد هذا المقال بمساعدة الذكاء الاصطناعي؛ وأُدرجت المراجع التقنية للتحقق منها.