ميزات اختبار الفرضيات للتطبيقات المحمولة

كم يستغرق اختبار الفرضيات لتطبيق الهاتف المحمول؟ دعنا نعول:

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

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

هذا الوضع يجعل من المستحيل تحقيق إيقاع "5 فرضيات في الأسبوع" ، والتي تسعى العديد من فرق المنتج إليها.

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

دعنا نذهب.

تشغيل وإيقاف

قبل الغوص في التفاصيل ، تحتاج إلى إدخال مصطلح إضافي - نمط علامة الميزة (تبديل الميزة) .

بالنسبة للقراء الذين ليس لديهم خلفية تقنية ، قد يكون التوضيح مطلوبًا:

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

لاستخدام نمط علامة الميزة في اختبار التجربة ، ستحتاج إلى:

1. وظائف مطورة بالكامل يمكن تجربتها.
2. رمز التبديل الخاص به في الحالة الافتراضية لـ "إيقاف".
3. التحكم عن بعد التبديل من الخادم.

السؤال هو ، ما هو الوقت الموفر إذا كانت الوظيفة لا تزال بحاجة إلى تطوير قبل إجراء اختبارات A / B؟ دعنا نحاول تحليل مراحل التجربة:

ماذا نرى هنا؟

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

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

وفقًا لهذا المبدأ ، تعمل خدمة Apptimize ، مما يوفر نظامًا جاهزًا لاختبار A / B.

تحليل

لإجراء تجربة ، تحتاج إلى القيام بعدة أشياء:

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

إذا لم تستخدم الحل الجاهز من Apptimize ، فإن الطريقة الأبسط ستكون مزيجًا من Google Analytics for Firebase للتحليلات و Firebase Remote Config لتحديد التكوينات الفردية (المقاطع والاختبارات). هذه الأدوات مصممة للعمل معًا.

وفقا لذلك ، تحتاج:

1. استخدم Google Analytics for Firebase لتتبع مقاييس العمل.
2. استخدم Firebase Remote Config لإدارة إشارات المعالم.
3. استخدم Firebase Remote Config لتحديد المقاطع ومعلمات التجربة.
4. تحليل البيانات من Google Analytics باستخدام مفاتيح من Firebase Remote Config في التحليل. يتم توفير هذه الميزة بواسطة هذه الأدوات "خارج الصندوق".

سوف نحسن كذلك

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

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

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

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

القيد الآخر هو مقدار البيانات المنقولة من Firebase Remote Config. لا يمكن استخدامه لنقل الواجهة بالكامل. من الأفضل تخزينه فقط "المفتاح" لإصدار محدد من الواجهة ، وعند تغيير هذا الرمز ، قم بتحميل الواجهة من خدمة تابعة لجهة خارجية. في حد ذاته ، فإنه لا يحد من اختيار إطار تطوير المحمول ، لكنه يتطلب جهود تنفيذ إضافية.

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

من الناحية الفنية ، يتم تطبيق هذا النهج بسهولة في إطار يتميز بالخصائص التالية:

1. واجهة مستخدم تفاعلية وعالية الأداء لا تستخدم النهج التعريفي افتراضيًا.
2. دعم Google Analytics لـ Firebase و Firebase Remote Config.
3. الحل عبر الأنظمة الأساسية أمر مرغوب فيه لتسريع عملية التطوير بشكل عام.

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

باستخدام الواجهة الديناميكية التي تم إنشاؤها في Flutter و Google Analytics for Firebase و Firebase Remote Config ، يمكنك تطوير التطبيقات التي يمكن مقارنتها بمواقع الويب بسهولة اختبار الفرضيات.