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

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

وش الفرق بين اختبار المبرمج واختبارك؟

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

جهّز سيناريوهات قبل ما تفتح التطبيق

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

قائمة الفحص الأساسية

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

اختبر ببيانات حقيقية

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

اكتب الملاحظات بطريقة تُصلح بسرعة

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

أشياء تُنسى عادة في الاختبار

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

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

متى تدفع الدفعة الأخيرة؟

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

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