مشكلات التطبيق:
الفحص والإصلاح

ابدأ بعَرَض يمكن إعادة إنتاجه

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

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

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

خطأ: تقدير التطوير اعتمادًا على الصور فقط

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

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

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

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

خطأ: اختبار الشاشة المثالية فقط

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

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

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

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

خطأ: انقطاع الاتصال يتحوّل إلى فقدان بيانات

ينتقل الهاتف بين الشبكات، ويُرسَل التطبيق إلى الخلفية، وقد ينهي النظام عمليته. إذا اختبر الفريق اتصال ⁦Wi-Fi⁩ مستقرًا فقط، فقد تتصرف المسودات وعمليات الإرسال بصورة غير متوقعة. ليس مطلوبًا من كل تطبيق العمل دون اتصال بالكامل، لكن عليه توضيح حدوده بوضوح.

1. ابدأ تعبئة تذكرة ثم افصل الشبكة.
2. احفظ بالطريقة المخصصة ثم أعِد تشغيل التطبيق.
3. تحقّق من الاحتفاظ بالحقول والمرفقات المتفق عليها.
4. أعِد الاتصال وانتظر تأكيد تبادل البيانات.
5. كرّر السيناريو بانقطاع الاتصال بعد الإرسال عندما تكون نتيجة العملية مجهولة.

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

خطأ: تطبيق الصلاحيات بإخفاء الأزرار فقط

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

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

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

لتحديد الفحوص التقنية، استخدم ⁦OWASP MASVS⁩. ناقش المتطلبات المطبقة على التخزين والتفويض وتبادل البيانات والخصوصية. الإشارة الشكلية إلى معيار في التقرير لا تغني عن وصف الفحوص المنفّذة والقيود المكتشفة.

خطأ: اعتبار شاشة النجاح دليلًا على نجاح العملية

استجاب الزر، لكن الطلب لم يصل إلى ⁦CRM⁩. وصل الإشعار، لكنه يفتح سجلًا آخر. حالة الدفع غير محسومة، فيحاول المستخدم تكراره. تُفحص هذه المشكلات عبر سلسلة الأنظمة كاملةً.

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

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

خطأ: «كل شيء يعمل على هاتفنا»

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

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

في تقرير ⁦Google Play⁩ لما قبل الإطلاق، افتح تفاصيل المشكلة واختر جهازًا. تساعد مواد التشخيص على التمييز بين التعطّل والتجمّد ومشكلة الواجهة. أرسل للمطوّر رقم البناء والتفاصيل المتاحة، ثم كرّر الفحص على النسخة المصححة.

لا تحسّن مؤشرًا على حساب وظيفة؛ فإخفاء الصور أو تعطيل المزامنة أو اختفاء شاشة يتطلب تقييم الأثر على المنتج.

خطأ: اختبار التثبيت دون التحديث

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

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

العودة إلى إصدار سابق من الخادم ليست دائمًا متوافقة مع البيانات التي حُدّثت بالفعل. اختبر خطة الاستعادة مسبقًا. وفي ⁦iOS⁩، يتيح ⁦TestFlight⁩ توزيع نسخ التطبيق على مجموعات وجمع الملاحظات المرتبطة بالاختبار.

عالج رفض المتجر بناءً على الملاحظة المحددة. قارن السلوك الفعلي والوصف ووصول المراجع والإفصاحات عن البيانات مع إرشادات مراجعة ⁦App Store⁩ أو قواعد المنصة المختارة. أصلح السبب وأرفق توضيحًا وأعِد اختبار النسخة. لا يمكن ضمان الموافقة.

خطأ: قياس التثبيتات بدل المهام المكتملة

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

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

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

لا تُضِف إلى التحليلات محتوى غير ضروري من النماذج. يكفي للبحث غالبًا اسم الحدث والإصدار والنتيجة التقنية. ومن المفيد ربط خطة اكتساب المستخدمين مع تسويق قابل للقياس بعد التحقق من المسار المؤدي إلى إجراء مفيد.

عالج السبب وأعِد التحقق من النتيجة

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

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

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

ما يجب فحصه قبل إغلاق الملاحظات

أسئلة شائعة عن مشكلات التطبيقات