يُعَدّ تحليل استخدام البرمجيات منجمًا ذهبيًا غير مُسْتَغَل لفِرَق الاختبار وضمان جودة البرمجيات. في هذا الموضوع توضيح لكيفية الاستفادة من تحليل استخدام البرمجيات في تغيير استراتيجية الجودة وكذلك تحسين الجودة من خلال تجربة عمليّة في أحد المشاريع.

قد يفشل النهج التقليدي لضمان الجودة في اكتشاف الأخطاء التي تتسبّب في توقّف العمل لفترات طويلة. حتى مع تغطية الاختبار (test coverage) التي تصل إلى 100% تقريبًا، ما زالت تفشل بعض الفِرَق في إيجاد والتقاط ماهو مُهم والعثور عليه وهو: كيفيّة انتقال المستخدمين في البرمجيات والتفاعل معها في الاستخدام الفعلي. في بعض الحالات، لا تُقدّم مقاييس الجودة التقليدية أو المُعتادة (metrics) مثل تغطية الاختبار أو مُعدّلات العيوب (defect rates) سوى رؤية جزئية. إن الجودة الحقيقية للبرمجيات هي مقياس لقدْرتها على تلبية احتياجات المستخدمين وتوقعاتهم من حيث سهولة الاستخدام ورضا/تجربة العملاء.

هكذا، بدأت رحلتنا بسؤال بسيط للغاية: ماذا لو استطعنا تحويل بيانات استخدام البرمجيات إلى رُؤى جودة عملية؟ بالتعاون مع فريق تحليل استخدام البرمجيات (Software Usage Analytics Team)، طوّرنا إطار عمل أكثر تفصيلاً لالتقاط وتحليل استخدام منصة إدارة المخاطر الخاصة بنا في سيناريوهات واقعية. وكانت النتائج مزعجة للغاية:

• 72% من المستخدمين تخطّوا تمامًا رحلة التشغيل (operating journey) المُحدّدة بدقة شديدة لتحديد ملف المخاطر.
• تقارير الأداء وهي الميزة الأكثر اختبارًا استخدَمَها 11% فقط من مستخدمينا.
• 83% من طلبات دعم العملاء نتجت عن أربع رحلات مستخدم (user journeys) بسيطة لم تُركّز عليها الاختبارات بشكل كافٍ.

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

تغيير استراتيجية الاختبار

لقد قمنا بمراجعة شاملة لمنهجنا في الاختبار ويمكن تلخيص التغييرات الجذريّة في استراتيجية الاختبار بإيجاز في العناصر التالية:

• من التغطية إلى التأثير (From Coverage to Impact)

بدلاً من السعي العشوائي وراء متطلّبات تغطية برمجية عشوائية، اعتمدنا نموذجًا تُخصّص فيه الاختبارات وفقًا لمدى استخدام جوانب مختلفة من البرنامج ومدى أهميتها للأعمال (business). أصبحت تغطية المسارات الحرجة للأعمال (business-critical paths) هي المعيار الجديد للنجاح: إجراء اختبارات مكثفة على مسارات العمل الأكثر أهمية للاحتفاظ بالعملاء ورضاهم. بالنسبة للعملاء، تمت ترجمة هذا إلى حوالي 60% من الاختبارات التي أُجريت على مسارات مرتبطة بحسابات المخاطر وهي المسارات التي أمضى المستخدمون معظم وقتهم عليها والتي كان تأثير الاختبارات الخاطئة عليها هو الأخطر على الأعمال (business).

• من السيناريوهات الافتراضية إلى السيناريوهات الفعليّة

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

• من المساواة في المعاملة إلى تحديد الأولويّات بناءً على المخاطر

بدلاً من إعطاء وزن متساوٍ لجميع مسارات التعليمات البرمجية (code paths)، تم الآن التركيز على الاختبارات بناء على ملفات تعريف المخاطر.

• من المراقبة المنفصلة إلى المراقبة المتكاملة

ساعدتنا هذه المرحلة على تجاوز الحاجز بين مراقبة الإنتاج (production monitoring) واختبار ما قبل الإصدار (pre-release testing). تأثرت حالات الاختبار بأداء الإنتاج (production performance) وبيانات الأخطاء حيث يتم توليدها وتحديد أولوياتها في الوقت الفعلي (real-time) مما يُمثل حلقة تغذية راجعة (feedback loop).

• من المقاييس الفنيّة إلى المقاييس التي تركّز على المستخدم (Metrics)

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

النتائج

بعد أن قمنا بتنفيذ استراتيجية الجودة هذه لمدة 18 شهرًا، جاءت النتائج أعلى مما كنا نأمل في تحقيقه:

1. انخفاض مُعدّل فقدان العملاء بنسبة 32%.
2. انخفضت طلبات الدعم المتعلقة بالبرنامج بنسبة 47%.
3. ارتفعت سرعة الإصدار (release velocity) التي فاقت التوقعات بنسبة 28% مصحوبةً بجهد اختبار أكثر صعوبة (harder test effort).

خاتمة

يُمثّل تحليل استخدام البرمجيات منجمًا ذهبيًا غير مستغل لفِرَق الجودة. فمن خلال ربط سلوك المستخدم باستراتيجية الجودة، يُمكن للبرمجيات تحسين الجودة التقنية وجودة الأعمال (business) بشكل كبير وهذا يتطلّب إعادة تصوّر لنهْج الجودة التقليدي وتحويله إلى الاستثمار في القدرات التحليلية وكسر الحواجز بين فِرَق الجودة وفِرَق البرمجيات ونجاح العملاء. يتعيّن على فِرَق العمل تحويل هذه الحواجز إلى معايير عمل تعاونية لجني ثمار تقليل مُعدّل فقدان العملاء وتحسين الكفاءة وتوطيد العلاقات مع العملاء. إن الاستثمار في تحليل استخدام البرمجيات يُعلّمنا الاستماع أولًا قبل بناء أي شيء فالاستماع إلى سلوك المستخدمين يُمكّننا من بناء برمجيات أفضل.

* المصدر: https://www.softwaretestingmagazine.com/knowledge/mining-gold-from-user-clicks-how-product-analytics-transformed-our-quality-strategy

** الصورة من موقع: https://www.arenasolutions.com/resources/glossary/cloud-software