كيف تختبر تطبيقك قبل الإطلاق: خطة عملية لما قبل الإطلاق
لاختبار تطبيقك قبل الإطلاق، اكتب الرحلات القليلة التي يجب أن يكون المستخدم قادراً على إتمامها، وشغّل كل واحدة كمستخدم جديد تماماً على حاسوب وهاتف، ثم جرّب الطرق التي قد تفشل بها: بيانات فارغة، ومدخلات سيئة، وحساب ثانٍ، واتصال بطيء. اختبر بعناية إضافية أي شيء يتعلق بالمال أو البيانات الخاصة، وكرر الرحلات الرئيسية على الرابط الحي بعد النشر. وأخيراً، راقب شخصاً لم يرَ التطبيق من قبل وهو يحاول استخدامه.
لا تحتاج إلى فريق ضمان جودة أو إطار اختبار لهذا. تحتاج إلى قائمة، وساعة أو ساعتين، والانضباط في أن تمر عليها فعلاً.
الخطوة 1: اكتب الرحلات المهمة
الرحلة هي مهمة من البداية للنهاية يأتي المستخدم لإنجازها. معظم التطبيقات لها ثلاث إلى ست رحلات تهم فعلاً. بالنسبة لتطبيق حجوزات:
- التسجيل وتأكيد الحساب
- البحث عن حصة وحجزها
- إلغاء حجز
- الدفع مقابل باقة حصص
- للموظفين: رؤية حجوزات اليوم
إذا كنت قد كتبت قصص المستخدم، فإن معايير قبولها هي حالات اختبارك جاهزة. إن لم تكن قد كتبتها، فاكتب سطراً واحداً لكل رحلة يصف ما يعني «النجاح».
رتّبها حسب الأولوية. الرحلات التي تحقق المال أو يمر بها كل مستخدم (التسجيل، وتسجيل الدخول، والإجراء الأساسي) تُختبر أولاً وأكثر.
الخطوة 2: اختبر المسار السعيد كمستخدم جديد
«المسار السعيد» هو أن تسير الرحلة كما صُممت تماماً. اختبرها كما يعيشها غريب:
- استخدم نافذة متصفح خاصة، حتى لا تكون مسجّل الدخول ولا تملك بيانات محفوظة.
- استخدم حساباً جديداً ببريد حقيقي تستطيع التحقق منه.
- ابدأ من الصفحة الرئيسية أو من رابط، لا من صفحة حفظتها في المفضلة أثناء البناء.
المستخدمون الجدد لا يملكون بيانات. كثير من الأخطاء لا تظهر إلا عندما تكون قائمة فارغة، أو عندما لا توجد صورة في الملف الشخصي، أو عندما لم يُشترَ شيء بعد. حسابك الشخصي المليء ببيانات الاختبار يخفي هذه الأخطاء.
الخطوة 3: حاول كسره
كرر كل رحلة، وافعل الخطأ عمداً.
| جرّب هذا | ما الذي تتحقق منه |
|---|---|
| أرسل النماذج فارغة، أو بمسافات فقط | الحقول الإلزامية مفروضة، مع رسالة واضحة |
| نص طويل جداً، أو رموز تعبيرية، أو أسماء بحروف مُعلّمة | التخطيط يصمد، والبيانات تُحفظ بشكل صحيح |
| صيغ خاطئة: حروف في حقل الهاتف، أو تاريخ في الماضي | التحقق يعمل في الصفحة وعلى الخادم معاً |
| انقر زر الإرسال مرتين | لا تكرار للطلبات أو الحجوزات |
| زر الرجوع في المتصفح في منتصف التدفق | لا حالة معطلة ولا بيانات مفقودة |
| أعد تحميل كل صفحة | البيانات تبقى؛ ولا صفحة بيضاء أو خطأ 404 |
| سجّل الخروج ثم اضغط الرجوع | الصفحات الخاصة لا تظهر |
| تبويبان يعدّلان الشيء نفسه | الحفظ الأخير لا يمحو الأول بصمت |
إعادة التحميل تستحق التنبيه: إذا كان التطبيق يعمل عند النقر، لكن إعادة التحميل على صفحة أعمق تظهر خطأ 404، فراجع كيف تصلح أخطاء 404 بعد النشر.
الخطوة 4: اختبر الصلاحيات بحسابين
هذا أهم اختبار لأي تطبيق فيه حسابات، وهو الأكثر إغفالاً.
أنشئ مستخدمين عاديين، أ وب، وإذا كان لتطبيقك مسؤول، فمسؤول أيضاً.
- كمستخدم أ، أنشئ سجلاً. سجّل الدخول كمستخدم ب. هل يستطيع ب رؤيته أو تعديله أو حذفه؟ لا ينبغي ذلك، إلا إذا كان التصميم يقتضيه.
- كمستخدم أ، انسخ رابط أحد سجلاتك. سجّل الدخول كمستخدم ب وافتح الرابط مباشرة.
- كمستخدم عادي، حاول فتح صفحات المسؤول بكتابة روابطها.
- سجّل الخروج تماماً وجرّب الروابط نفسها.
إذا وجدت مشكلة هنا، فلا تُطلق حتى تُصلح. يجب أن يحدث التحقق على الخادم، لا بإخفاء زر فقط. وتتعمق قائمة الأمان للتطبيقات المبنية بالذكاء الاصطناعي في ذلك.
الخطوة 5: اختبر على أجهزة حقيقية
افتح التطبيق على هاتف فعلي، لا على نافذة متصفح ضيقة فقط.
- هل تستطيع النقر على كل زر دون تكبير؟
- هل تغطي لوحة المفاتيح الحقل الذي تكتب فيه؟
- هل تتمرر الجداول والمحتوى العريض أو يلتف النص، بدلاً من أن يدفع الصفحة جانبياً؟
- هل النص مقروء دون تقريب بالأصابع؟
جرّب على الأقل آيفون واحداً (Safari) وهاتف أندرويد واحد (Chrome) إن أمكن. وSafari بالتحديد له مشكلاته الخاصة مع التواريخ والفيديو والعناصر ذات الموضع الثابت.
الخطوة 6: اختبر المال والبريد من البداية للنهاية
أي شيء يخصم من البطاقات أو يرسل رسائل بريدية يحتاج إلى تجربة كاملة.
المدفوعات. استخدم وضع الاختبار لدى مزوّد الدفع وأرقام بطاقات الاختبار. تحقق من عملية دفع ناجحة، وبطاقة مرفوضة، وإلغاء للدفع. تأكد من أن الطلب أو الاشتراك يظهر في تطبيقك بعد الدفع، لا في لوحة المزوّد فقط. إذا كان تطبيقك يعتمد على الـwebhooks (رسائل يرسلها مزوّد الدفع إلى خادمك)، فتحقق من وصولها على التطبيق المنشور، لا في بيئة التطوير فقط. ثم، قبل الإطلاق، انتقل إلى المفاتيح الحية واشترِ شيئاً صغيراً حقيقياً واسترد ثمنه.
رسائل البريد. سجّل بعناوين حقيقية لدى مزوّدَي بريد أو ثلاثة. تحقق من أن الرسائل تصل، ولا تذهب إلى الرسائل غير المرغوب فيها، وأن كل رابط فيها يشير إلى النطاق الحي، لا إلى عنوان معاينة.
الخطوة 7: تحقق من السرعة والأخطاء
- افتح أدوات المطور في المتصفح (انقر بزر الفأرة الأيمن ← Inspect / فحص) وانظر إلى تبويب Console في كل صفحة رئيسية. الأخطاء الحمراء تستحق الإصلاح حتى لو لم يبدُ أن شيئاً معطل.
- حمّل الموقع على الهاتف باستخدام بيانات الجوال لا Wi-Fi. إذا استغرقت الشاشة الأولى عدة ثوانٍ، فابدأ بأحجام الصور.
- شغّل تدقيقاً مجانياً مثل Lighthouse في أدوات المطور في Chrome لقراءة سريعة للأداء وإمكانية الوصول.
الخطوة 8: اختبر التطبيق المنشور، لا المعاينة فقط
المعاينة والتطبيق المنشور ليسا البيئة نفسها. قبل أن تخبر أحداً بالإطلاق، كرر الرحلات الرئيسية على الرابط الحي:
- هل تم تعيين كل متغيرات البيئة والأسرار للتطبيق المنشور؟
- هل يستخدم قاعدة البيانات الصحيحة، مع البيانات التي تتوقعها؟
- هل توجّه إعادة التوجيه بعد تسجيل الدخول وروابط البريد إلى النطاق الحي؟
- هل يُحمّل التحديث على صفحة عميقة بشكل صحيح؟
الخطوة 9: راقب شخصاً آخر وهو يستخدمه
أعطِ شخصاً أو اثنين هدفاً («احجز حصة يوغا يوم السبت»)، لا تعليمات. راقب دون أن تساعد، واكتب الأماكن التي يتردد فيها. هذه أسرع طريقة لاكتشاف صياغة مربكة أو أزرار مخفية. وللنسخة الأكبر من ذلك، انظر كيف تُجري اختبار بيتا.
وعندما يصطدم بخلل، اكتبه بشكل سليم: خطوات، والنتيجة المتوقعة، والنتيجة الفعلية. دليلنا حول كتابة تقرير خلل جيد يعرض الصيغة.
استخدام الذكاء الاصطناعي في الاختبار
إذا كنت تبني بالذكاء الاصطناعي، يمكنك أن تطلب منه المساعدة في تخطيط الاختبارات وتنفيذها:
اذكر رحلات المستخدم الرئيسية في هذا التطبيق، ولكل رحلة، الحالات الحدية الأكثر احتمالاً للكسر: الحالات الفارغة، والمدخلات غير الصالحة، والصلاحيات، وإعادة التحميل. ضعها في قائمة أستطيع العمل عليها.
سجّل الدخول كمستخدمَي اختبار مختلفين وتحقق مما إذا كان المستخدم ب يستطيع رؤية أو تغيير أي شيء أنشأه المستخدم أ، بما في ذلك بفتح روابط سجلات أ مباشرة. أبلغ عما تجده قبل إصلاح أي شيء.
اعتبر تقرير الاختبار الذي يكتبه الذكاء الاصطناعي مسودة أولى. ومع ذلك، اختبر رحلات المال والصلاحيات بنفسك.
الاختبار في Mythex
في Mythex، يشغّل الأمر /test ميزة اختبار التطبيق: يقود الوكيل متصفحاً على المعاينة الحية، وينقر عبر الصفحات، ويلتقط لقطات شاشة، ويبلغ عن التدفقات المعطلة في المحادثة. يعمل أفضل مع رحلة محددة، مثل «اختبر التسجيل وحجز حصة». أصلح ما يجده بالأمر /fix أو برسالة عادية، ثم شغّل /test مرة أخرى. اختبار التطبيق يستخدم المعاينة، لذا تحقق من الرحلات الرئيسية على الرابط المنشور بنفسك بعد النشر. انظر اختبار التطبيقات في الوثائق، ودليلنا حول تصحيح الأخطاء في تطبيق مبني بالذكاء الاصطناعي عندما يفشل شيء ما.
أخطاء شائعة
- الاختبار بصفتك أنت فقط. حساب المسؤول الخاص بك المليء بالبيانات يخفي أخطاء الحالات الفارغة والصلاحيات.
- الاختبار على الحاسوب فقط. أغلب زوار كثير من المواقع يأتون من الهاتف.
- تخطي الحساب الثاني. تسرّب البيانات بين المستخدمين هو أخطر خلل يمكن أن يُطلق به تطبيق.
- الثقة بالمعاينة. التطبيق الحي له إعدادات مختلفة؛ اختبره أيضاً.
- إصلاح الأخطاء دون إعادة اختبار ما حولها. إصلاح نموذج واحد قد يكسر نموذجاً آخر يشارك الشيفرة نفسها.
قائمة ما قبل الإطلاق
- الرحلات الرئيسية مكتوبة ومرتبة حسب الأولوية
- كل رحلة تنجح لمستخدم جديد تماماً في نافذة خاصة
- المدخلات الفارغة وغير الصالحة والطويلة والمكررة مُعالجة
- إعادة التحميل تعمل على كل صفحة
- لا يستطيع المستخدمون رؤية بيانات بعضهم أو تغييرها، حتى عبر الروابط
- صفحات المسؤول محجوبة عن المستخدمين العاديين والزوار غير المسجلين
- يعمل على آيفون حقيقي وهاتف أندرويد حقيقي
- اختُبرت المدفوعات: النجاح، والرفض، والإلغاء، وتحديث التطبيق بعدها
- تصل رسائل البريد، وتتجنب الرسائل غير المرغوب فيها، وتشير إلى النطاق الحي
- لا توجد أخطاء حمراء في الكونسول على الصفحات الرئيسية
- كُررت الرحلات الرئيسية على الرابط المنشور
- جرّب شخص من خارج الفريق التطبيق بينما أنت تراقب
الأسئلة
كم من الاختبار يحتاج التطبيق الصغير قبل الإطلاق؟
يكفي لأن تتأكد من أن الرحلات الرئيسية تعمل لمستخدم جديد تماماً على الهاتف والحاسوب، وأن المستخدمين لا يرون بيانات بعضهم، وأن كل ما يتعلق بالمال يعمل من البداية للنهاية. ولمعظم التطبيقات الصغيرة يكفي ذلك بضع ساعات مركزة، لا أسابيع.
هل أحتاج إلى اختبارات آلية لمنتج أولي (MVP)؟
ليس بالضرورة. الاختبار اليدوي للرحلات الأساسية يلتقط معظم الأخطاء التي تمنع الإطلاق. الاختبارات الآلية تبدأ في الإفادة عندما تغيّر التطبيق كثيراً وتريد أن تعرف بسرعة أنك لم تكسر شيئاً كان يعمل.
هل أختبر على المعاينة أم على التطبيق الحي؟
الاثنان. اختبر بعناية في المعاينة، ثم كرر الرحلات الرئيسية على التطبيق المنشور، لأن متغيرات البيئة المفقودة أو قاعدة بيانات مختلفة أو إعدادات التوجيه قد تجعل النسخة الحية تتصرف بشكل مختلف.
من يجب أن يختبر تطبيقي غيري؟
شخص واحد على الأقل لم يره من قبل. أعطه هدفاً لا تعليمات، وراقبه دون مساعدة. المطورون يتجنبون دون وعي المسارات التي تنكسر.