كيف تختبر تطبيق الموبايل قبل نشره؟ دليل QA شامل مع قائمة اختبار عملية

• فريق Triple

كيف تختبر تطبيق الموبايل قبل نشره؟ دليل QA شامل مع قائمة اختبار عملية

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

كيف تختبر تطبيق الموبايل قبل نشره؟ دليل QA شامل لأصحاب المنتجات

هل انتهى فريق البرمجة من تطوير تطبيقك وأخبرك أنه جاهز للنشر على App Store وGoogle Play؟ قبل الموافقة على إطلاقه، هناك سؤال أهم من عدد الشاشات التي اكتملت: هل تم اختبار التطبيق في الظروف التي سيستخدمه فيها العملاء فعلًا؟

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

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

لذلك تُعد عملية اختبار تطبيقات الموبايل (Mobile App Testing) جزءًا أساسيًا من تطوير أي منتج رقمي، سواء كان تطبيق حجوزات أو متجرًا إلكترونيًا أو منصة خدمات أو نظامًا داخليًا للشركات.

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

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

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

ما هو اختبار تطبيقات الموبايل Mobile App Testing؟

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

ولا يعني الاختبار فتح التطبيق والتنقل بين شاشاته لبضع دقائق.

فقد تظهر مشكلة فقط عندما تنقطع شبكة الإنترنت، أو يعود المستخدم إلى التطبيق بعد مكالمة، أو يستخدم هاتفًا بمقاس شاشة صغير، أو يُدخل رقم هاتف من دولة مختلفة.

ما الفرق بين Testing وQA وUAT؟

رغم استخدام هذه المصطلحات معًا، فإن لكل منها دورًا مختلفًا.

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

ولا يغني اختبار قبول المستخدم عن الاختبارات التقنية والأمنية.

لماذا لا يكفي أن يقول المبرمج إن التطبيق يعمل؟

قد يكون المطور قد اختبر الوظيفة التي نفذها وتأكد من نجاحها في الظروف المعتادة.

لكن ذلك لا يعني بالضرورة أن جميع أجزاء النظام تعمل معًا بصورة صحيحة.

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

ولهذا يجب اختبار رحلة المستخدم كاملة، وليس كل شاشة بصورة منفصلة فقط.

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

أولًا: حدد ما الذي يجب اختباره قبل بدء QA

أفضل نقطة بداية هي الرجوع إلى وثيقة متطلبات التطبيق ونطاق الإصدار المطلوب نشره.

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

ما المعلومات التي يحتاجها فريق الاختبار؟

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

كذلك حدد بيئة الاختبار، وحسابات التجربة، وطريقة إنشاء بيانات تجريبية آمنة.

ومن المهم توضيح الاختبارات المرتبطة بعمليات حساسة، مثل المدفوعات أو حذف الحساب أو تعديل الصلاحيات.

ما الفرق بين بيئة الاختبار وبيئة التشغيل الفعلية؟

بيئة الاختبار Staging: تُستخدم لتجربة الوظائف باستخدام إعدادات وبيانات مناسبة للاختبار، دون التأثير غير المقصود على العملاء الفعليين.

بيئة الإنتاج Production: البيئة التي يستخدمها العملاء الحقيقيون.

يُفضل أن تكون بيئة الاختبار قريبة من إعدادات الإنتاج بما يكفي لاكتشاف مشكلات التكامل والإعدادات.

لكن يجب تجنب استخدام بيانات العملاء الحقيقية أو تنفيذ معاملات مالية فعلية دون ضرورة وضوابط واضحة.

ما الذي يجب أن تتسلمه؟

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

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

ثانيًا: اختبر رحلة المستخدم الأساسية من البداية للنهاية

كل تطبيق لديه مهمة رئيسية يجب أن يستطيع المستخدم إكمالها.

في تطبيق متجر إلكتروني، قد تكون المهمة إتمام عملية شراء.

وفي تطبيق حجوزات، قد تكون اختيار موعد وتأكيد الحجز.

أما تطبيق مندوبي المبيعات، فقد تكون تسجيل طلب وإرساله إلى النظام الإداري.

ما المقصود باختبار End-to-End؟

هو اختبار رحلة كاملة تشمل الأجزاء المرتبطة ببعضها، مثل التطبيق والـBackend وقاعدة البيانات ولوحة التحكم والخدمات الخارجية.

مثال: اختبار رحلة حجز خدمة

يمكن تجربة السيناريو التالي:

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

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

الوظيفة ليست مكتملة لمجرد نجاح الشاشة؛ يجب التأكد من أن النتيجة المطلوبة تحققت داخل النظام كله.

ثالثًا: اختبر تسجيل الدخول والتسجيل ورمز OTP

تسجيل الدخول من أول الوظائف التي يتعامل معها العميل، وقد يمنعه أي خلل فيها من استخدام التطبيق بالكامل.

ما الذي يجب اختباره؟

ما الذي يجب مراعاته في مصر والخليج؟

إذا كان التطبيق يستهدف عدة دول، اختبر أرقام الهواتف بصيغ البلدان المدعومة، مثل مصر (+20)، والسعودية (+966)، والإمارات (+971).

واختبر إدخال الرقم بصيغته المحلية والدولية إذا كان التطبيق يعلن دعمه لكليهما.

كذلك تحقق من صحة رسائل OTP باللغة المناسبة، ومن وضوح تجربة إعادة الإرسال عند التأخير أو عدم وصول الرسالة.

ولا تعتمد على حساب اختبار واحد سبق تسجيل الدخول إليه؛ جرب إنشاء حساب من البداية على هاتف نظيف.

رابعًا: اختبر الدفع والطلبات دون المخاطرة بأموال العملاء

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

يجب التأكد من أن حالة الدفع صحيحة لدى مزود الدفع والنظام الخلفي، وأن الطلب لا يُنشأ أو يُحصّل بصورة مكررة.

ما السيناريوهات التي تستحق الاختبار؟

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

مثال على اختبار الدفع المتكرر

لنفترض أن العميل ضغط على زر «ادفع الآن» مرتين بسبب تأخر الاستجابة.

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

ومن المهم اختبار آليات منع التكرار على مستوى Backend والتكامل مع مزود الدفع، وليس من خلال تعطيل الزر بصريًا فقط.

ما الذي ينبغي أن يراجعه صاحب المنتج؟

اطلب أدلة على أن حالات الدفع تتوافق مع بيانات الطلبات والفواتير، وأن العمليات الملغاة أو الفاشلة لا تظهر على أنها مبيعات مكتملة.

استخدم بيئة اختبار الدفع (Sandbox) عندما يوفرها المزود، مع التأكد من اختبار إعدادات الإنتاج بالطرق الآمنة المناسبة قبل استقبال معاملات حقيقية.

ولا تخلط بين اختبار الدفع لمنتج مادي ومتطلبات شراء المحتوى الرقمي داخل التطبيق؛ فقد تختلف قواعد Apple وGoogle بحسب نوع المنتج.

خامسًا: اختبر الإشعارات في جميع حالات التطبيق

ولا تفترض أن جميع الإشعارات ستصل فورًا في كل حالة؛ فالسلوك يتأثر بنظام التشغيل والصلاحيات والاتصال ونوع الرسالة.

ماذا عن الإشعارات التسويقية؟

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

كما يجب اختبار ظهور النصوص العربية وعدم اقتطاع المعلومات المهمة بصورة تجعلها مضللة.

سادسًا: اختبر التطبيق على أجهزة أندرويد وآيفون حقيقية

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

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

كيف تختار أجهزة الاختبار؟

لا تحتاج بالضرورة إلى تجربة كل جهاز متاح في السوق.

اختر مجموعة تمثل جمهور التطبيق، مع مراجعة:

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

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

لا تنسَ تحديث التطبيق

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

تحقق من استمرار تسجيل الدخول حيث يكون ذلك مناسبًا، وعدم فقدان البيانات المحلية، وعمل الترقيات والتغييرات المرتبطة بقاعدة البيانات.

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

سابعًا: اختبر ضعف الإنترنت وانقطاعه ومقاطعات الهاتف

هذه من أهم الاختبارات التي قد تُنسى عندما يعتمد فريق التطوير على شبكة Wi-Fi مستقرة طوال العمل.

في الاستخدام الحقيقي، قد ينتقل العميل من Wi-Fi إلى بيانات الهاتف، أو تنقطع الشبكة أثناء إرسال طلب، أو يستقبل مكالمة خلال عملية حساسة.

سيناريوهات يجب تجربتها

هل يجب أن يعمل كل تطبيق دون إنترنت؟

لا. هناك فرق بين دعم العمل الكامل دون اتصال (Offline-first) وبين التعامل الجيد مع انقطاع الشبكة.

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

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

ثامنًا: اختبر اللغة العربية وتجربة المستخدم في مصر والخليج

لا ينبغي اعتبار اختبار الواجهة العربية مجرد التأكد من ترجمة النصوص.

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

ما الذي يجب اختباره؟

راجع اتجاه القوائم والعناصر، وخطوط اللغة العربية، ووضوح النصوص على الهواتف الصغيرة، وصحة الرسائل العربية والإنجليزية.

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

مثال عملي

إذا كان التطبيق يعرض أسعار خدمات في مصر والسعودية والإمارات، فلا يكفي تغيير رمز العملة فقط.

يجب التحقق من أن السعر والعملة والضرائب أو الرسوم المعروضة تتوافق مع قواعد العمل المطبقة في السوق المستهدف.

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

ماذا عن إمكانية الوصول؟

اختبر قابلية قراءة الخطوط والتباين وإمكانية استخدام التطبيق مع تكبير النص وقارئات الشاشة، مثل TalkBack على أندرويد وVoiceOver على iOS، بحسب إمكانات التطبيق.

وتقدم W3C إرشادات لإمكانية الوصول على الموبايل يمكن الاسترشاد بها عند تحديد الاختبارات المناسبة.

تاسعًا: اختبر الأمان والصلاحيات وحماية بيانات المستخدم

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

أمثلة على اختبارات الأمان المهمة

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

ويوفر OWASP MASVS مرجعًا لمتطلبات أمان تطبيقات الموبايل، بينما يساعد OWASP MASTG في فهم أساليب اختبار تلك الضوابط.

هل تكفي أداة فحص أمني آلية؟

لا. قد تساعد الأدوات على اكتشاف بعض المشكلات، لكنها لا تكفي للتحقق من جميع قواعد العمل والصلاحيات.

وقد تحتاج التطبيقات التي تتعامل مع بيانات حساسة أو عمليات مالية إلى مراجعة أمنية متخصصة واختبارات تتناسب مع مستوى المخاطر.

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

عاشرًا: اختبر الأداء والاستقرار واستهلاك الموارد

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

ما المؤشرات التي يمكن قياسها؟

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

لكن لا توجد قيمة واحدة مناسبة لكل التطبيقات في جميع الحالات.

كيف تضع أهدافًا واضحة؟

بدل كتابة «يجب أن يكون التطبيق سريعًا»، حدد العمليات المهمة والأجهزة وظروف القياس.

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

تُحدد الأرقام بعد مراجعة متطلبات المنتج وإمكانات النظام، وليست ضمانات عامة لجميع الأجهزة والشبكات.

ما دور Crashlytics؟

تساعد Firebase Crashlytics فرق التطوير على جمع تقارير الأعطال وتجميع المشكلات حسب أسباب متشابهة وتحديد الإصدارات المتأثرة.

لكن انخفاض عدد الأعطال المبلغ عنها لا يعني أن جميع الوظائف تعمل بصورة صحيحة.

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

الحادي عشر: اختبر التطبيق يدويًا وآليًا

قد تسأل شركة البرمجة: هل نحتاج إلى Manual Testing أم Automated Testing؟

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

الاختبار اليدوي Manual Testing

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

الاختبار الآلي Automated Testing

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

وقد تشمل الاختبارات الآلية:

• Unit Tests للتحقق من وحدات برمجية صغيرة.
• Integration Tests للتحقق من تفاعل المكونات.
• UI Tests لاختبار التفاعل مع الواجهات.
• End-to-End Tests لمحاكاة مسارات استخدام كاملة.

لا يُعد عدد الاختبارات الآلية وحده دليلًا على جودة التطبيق.

فالاختبار الذي يتحقق من نتيجة غير مهمة لا يقدم قيمة كبيرة، حتى لو مر بنجاح آلاف المرات.

ما اختبارات Regression؟

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

مثلًا، إذا عدّل الفريق منطق الخصومات في متجر، ينبغي إعادة اختبار السلة والدفع والفواتير والاسترجاع المرتبط به.

الثاني عشر: كيف توثّق الأخطاء بطريقة تساعد على إصلاحها؟

إذا اكتشفت مشكلة، لا تكتفِ بإرسال رسالة تقول «التطبيق بيهنج» أو «الزر مش شغال».

ينبغي أن يستطيع المطور إعادة تنفيذ الخطوات نفسها وفهم النتيجة المتوقعة والفعلية.

نموذج Bug Report

هذا مثال افتراضي وليس عطلًا حدث في أحد مشروعات Triple.

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

ما الفرق بين Severity وPriority؟

Severity — درجة الخطورة: حجم الضرر الذي يسببه الخطأ للوظيفة أو المستخدم.

Priority — أولوية الإصلاح: مدى استعجال الفريق لمعالجة الخطأ مقارنة ببقية الأعمال.

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

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

كيف تحدد الأخطاء التي تمنع إطلاق التطبيق؟

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

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

نموذج تصنيف الأخطاء

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

متى توافق على النشر؟

يمكن وضع بوابة قرار تسمى Go / No-Go.

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

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

قرار الإطلاق الجيد لا يعتمد على عبارة «معظم التطبيق شغال»، بل على أدلة اختبار ومخاطر مفهومة ومعتمدة.

كيف تنفذ اختبار قبول المستخدم UAT قبل النشر؟

يُعد UAT فرصة لصاحب المنتج للتحقق من أن التطبيق يلبي الاحتياجات المتفق عليها، دون الاكتفاء بتقارير فريق التطوير.

من يجب أن يشارك؟

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

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

ماذا تفعل أثناء UAT؟

اطلب من المشاركين تنفيذ مهام محددة دون شرح كل خطوة لهم.

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

ثم سجل النتائج، وحدد المشكلات التي يجب إصلاحها قبل توقيع قبول المرحلة.

ما الذي يجب استلامه؟

من الأفضل أن تحصل على تقرير يوضح:

• الوظائف التي تم اختبارها.
• حالات الاختبار الناجحة والفاشلة.
• الأخطاء المتبقية ودرجة خطورتها.
• الأجهزة وإصدارات الأنظمة المستخدمة.
• رقم النسخة التي تم اختبارها.
• الإصلاحات التي أُعيد اختبارها.
• قرار قبول الإصدار أو تأجيله وأسباب القرار.

وبذلك يصبح قبول التطبيق مرتبطًا بمعايير واضحة بدل الاعتماد على الانطباع الشخصي.

كيف تختبر التطبيق قبل النشر على App Store وGoogle Play؟

بعد اكتمال الاختبارات الداخلية، يمكنك توزيع نسخ تجريبية على مجموعة مختارة قبل الإطلاق العام.

اختبار تطبيق iOS باستخدام TestFlight

توفر Apple خدمة TestFlight لتوزيع نسخ تجريبية وجمع ملاحظات المختبرين.

ووفق الوثائق الرسمية، يمكن دعوة ما يصل إلى 100 مختبر داخلي من أعضاء الفريق المخولين، وما يصل إلى 10,000 مختبر خارجي، مع خضوع بعض النسخ المخصصة للاختبار الخارجي للمراجعة.

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

اختبار تطبيق Android باستخدام Google Play Console

توفر Google Play مسارات مختلفة، منها:

• Internal Testing للاختبار مع مجموعة محدودة.
• Closed Testing للاختبار مع جمهور يتم التحكم فيه.
• Open Testing عند توافر شروطه.
• Production للنشر العام.

هل يحتاج كل تطبيق Android إلى 12 مختبرًا لمدة 14 يومًا؟

لا.

تشترط Google Play حاليًا على حسابات المطورين الشخصية المنشأة بعد 13 نوفمبر 2023 إجراء اختبار مغلق يضم 12 مختبرًا على الأقل، ظلوا مشاركين لمدة 14 يومًا متصلة، قبل تقديم طلب الوصول إلى النشر الإنتاجي.

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

كما أن استيفاء عدد المختبرين والمدة لا يضمن الموافقة على الإنتاج؛ فقد تتطلب Google معلومات إضافية عن الاختبار وجاهزية التطبيق.

ما الذي تختبره قبل إرسال الإصدار للمراجعة النهائية؟

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

كذلك ينبغي مراجعة القواعد المتعلقة بحذف الحساب وجمع البيانات والمشتريات داخل التطبيق عندما تنطبق.

وتوضح إرشادات Apple App Reviewأن التطبيقات ينبغي أن تكون مكتملة ومختبرة على الأجهزة، وأن تتضمن بيانات صحيحة وتمكّن فريق المراجعة من تجربة الوظائف.

للتفاصيل الإجرائية، اقرأ دليل Triple لنشر التطبيقات على App Store وGoogle Play.

ما الذي يجب أن يراجعه صاحب المنتج بنفسه؟

من الأفضل تجربة حساب عميل جديد، ثم حساب موظف تشغيل، ثم مراجعة النتيجة من لوحة الإدارة.

واختبر على الأقل بعض الحالات التي تفشل فيها العملية، وليس السيناريو الناجح فقط.

فنجاح الحجز عند اتصال قوي لا يكفي إذا كانت تجربة الإلغاء أو انقطاع الشبكة تسبب فقدان الطلبات.

كم يستغرق اختبار تطبيق الموبايل قبل النشر؟

تعتمد المدة على عدد الوظائف والأجهزة والأنظمة والتكاملات، ومدى جاهزية التطبيق قبل بدء دورة الاختبار.

وقد يحتاج تطبيق محدود الوظائف إلى فترة اختبار أقصر من منصة تحتوي على عدة أنواع مستخدمين ومدفوعات وتكاملات مع أنظمة خارجية.

لكن لا توجد مدة واحدة تصلح لجميع المشاريع.

ما الذي يطيل مرحلة QA؟

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

أما شروط الاختبار الخاصة بحسابات Google Play الشخصية الجديدة فهي متطلبات نشر منفصلة يجب احتسابها في الجدول الزمني عندما تنطبق.

لا تجعل موعد الإطلاق سببًا لتجاوز مشكلة حرجة أو تعطيل فحص أمني ضروري.

كيف تساعدك Triple في تجهيز تطبيقك للإطلاق؟

تقدم Triple خدمات تصميم وبرمجة تطبيقات الموبايل لأندرويد وiOS، وتشمل بحسب نطاق المشروع تصميم الواجهات والتطوير والاختبارات وتجهيز النشر.

ومن المهم عند الاتفاق مع أي شركة تطوير، بما فيها Triple، تحديد خطة اختبار التطبيق والمخرجات التي ستُسلَّم، ومعايير قبول الوظائف والأجهزة المستهدفة ومسؤوليات معالجة الأخطاء.

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

ويمكنك أيضًا مراجعة دليل Triple لأسباب رفض التطبيقات لفهم الفروق بين مشكلات الجودة التقنية ومخالفات سياسات المتاجر.

كيف تتأكد أن تطبيقك جاهز للنشر؟

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

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

بعد ذلك، نفّذ UAT مع أصحاب المصلحة المناسبين، وراجع الأخطاء المفتوحة، وحدد قرار النشر بناءً على المخاطر الفعلية لا على ضغط موعد الإطلاق.

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

الأسئلة الشائعة

• 1- ما أهم اختبارات الموبايل قبل النشر؟

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

• 2- هل يمكن اختبار التطبيق دون معرفة البرمجة؟

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

• 3- ما الفرق بين QA وUAT في تطبيقات الموبايل؟

QA يشمل ممارسات ضمان الجودة وتخطيط الاختبارات ومتابعتها، بينما UAT يركز على التأكد من أن المنتج يحقق احتياجات العمل كما تم الاتفاق عليها. ولا يُغني أحدهما عن الآخر.

• 4- هل يجب اختبار التطبيق على أجهزة حقيقية؟

نعم، من المهم تجربة التطبيق على مجموعة من الأجهزة الحقيقية التي تمثل جمهورك، مع الاستفادة من المحاكيات والأدوات الآلية لزيادة التغطية. وتؤكد Apple أهمية الاختبارات على الأجهزة الفعلية قبل المراجعة.

• 5- هل يشترط Google Play اختبار التطبيق لمدة 14 يومًا؟

ينطبق شرط اختبار مغلق يضم 12 مختبرًا مشاركين لمدة 14 يومًا متصلة على حسابات المطورين الشخصية المنشأة بعد 13 نوفمبر 2023، وفق شروط Google الحالية. ولا يُطبق تلقائيًا على جميع الحسابات، ولا يضمن اجتيازه الموافقة على النشر.

• 6- هل يمكن نشر التطبيق مع وجود أخطاء بسيطة؟

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