لماذا يتأخر فحصك الآلي لعام 2024 خمس سنوات عن تطبيق Jetpack Compose لديك

ما الذي يجيده الفحص الآلي

لنكن منصفين أولاً. للفحص الآلي مكانه المستحق: فهو سريع وقابل للتكرار وزهيد التكلفة عند تشغيله مع كل بناء.

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

المشكلة ليست في فئة الأداة، بل فيما نفترض أن التقرير النظيف يخبرنا به.

التحوّل: من الصفحات إلى الحالة

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

لا تعمل تطبيقات Jetpack Compose بهذه الطريقة. الواجهة دالة في الحالة. فما يراه المستخدم، وما يسمح به التطبيق، يتوقفان على من سجّل الدخول، وما الذي جرى تحميله، وما الذي اختير قبل لحظات، وما قاله آخر رد.

في تطبيق Compose المعتاد، الشاشة ليست وجهة بقدر ما هي عرض للحالة الراهنة. والتنقل نفسه غالباً حالة أيضاً. وبعض الحالات لا توجد إلا بعد تسلسل محدد، وبتوقيت محدد، وببيانات محددة.

الزاحف الذي يستكشف الشاشات سيرى ما يستطيع الوصول إليه منها. وليس لديه ما يدعوه إلى معرفة ما لا يصل إليه.

مثال تخيلي

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

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

قد يزور الفحص صفحة بصفحة كل شاشة في ذلك التطبيق ولا يبلّغ عن شيء. فالحالة التي تهم لم تُعرض عليه أصلاً.

لماذا يهم هذا

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

نادراً ما تكون العواقب التجارية دراماتيكية في اليوم الأول. إنها أهدأ من ذلك:

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

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

• مخاطر خارطة الطريق. النتائج التي تصل متأخرة، قرب إطلاق أو عملية تدقيق، تُعالَج تحت الضغط وتزاحم أعمالاً أخرى.

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

الفحص النظيف معلومة مفيدة، لكنه ليس دليلاً على تغطية التدفقات المعتمدة على الحالة.

صندوق الأثر

كيف يبدو الاختبار الجيد

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

• رسم التدفقات والحالات. تحديد الرحلات المهمة والحالات التي تمر بها، بما فيها غير المعتادة.

• تتبّع البيانات عبر حاملات الحالة. متابعة البيانات الحساسة والقرارات من مصدرها، مروراً بـ ViewModel والحالة، وصولاً إلى ما يُعرض وما يُطبَّق.

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

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

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

ماذا تسأل المزوّد

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

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

من أين تبدأ

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

هل لديك سؤال عن منتجك؟ اترك بريدك الإلكتروني وسنتواصل معك خلال 1–2 يوم عمل.