Afsala
Quality Assurance Manager
هناك محادثة تحدث في كل مشروع برمجي تقريبًا في مرحلة ما. الموعد النهائي قريب، والميزانية محدودة، ويقترح أحدهم تقليص مرحلة الاختبار لتعويض الفارق. يبدو الأمر وكأنه مقايضة معقولة في الوقت الحالي - لقد عمل المطورون على هذا الأمر لعدة أشهر، وهم يعرفون الكود، وبالتأكيد لا بأس بذلك.
نادرا ما يكون على ما يرام.
يعد اختبار ضمان الجودة هو المرحلة الأكثر شيوعًا التي يتم تخطيها أو تجاهلها في تطوير التطبيقات والبرامج. وهو أيضًا، دائمًا، القرار الذي يؤدي في النهاية إلى تكبد الشركات أكبر قدر من التكاليف - في تكاليف الإصلاح المباشرة، وثقة المستخدم، وتقييمات متجر التطبيقات، وأحيانًا العملاء الذين يغادرون ولا يعودون.
فيما يلي نظرة صادقة على سبب استمرار حدوث ذلك، وما هي العواقب الحقيقية، وكيف يبدو ضمان الجودة المناسب في الواقع عندما يتم ذلك بشكل صحيح.
لماذا يتم قطع ضمان الجودة؟
والأسباب مفهومة حتى عندما يكون القرار خاطئا. لا يُنتج الاختبار مخرجات مرئية كما يفعل التطوير. لا توجد ميزة جديدة للإشارة إليها، ولا توجد شاشة لإظهار أصحاب المصلحة. يمكن أن يبدو الأمر كما لو أن الوقت قد تم قضاؤه في عدم البناء - وعندما يتم ضغط الجداول الزمنية، فإن هذا هو أول شيء يجب التخلص منه.
هناك أيضًا مشكلة ثقة. المطورين قريبون من الكود. لقد اختبروا عملهم أثناء إنشائه، وهم يعرفون كيف من المفترض أن يتصرف التطبيق، ويعمل على أجهزتهم. إن الافتراض بأن هذا يترجم إلى العمل بشكل صحيح لكل مستخدم على كل جهاز وفي كل ظروف العالم الحقيقي هو المكان الذي تبدأ فيه الأمور بالسير على نحو خاطئ.
ثم هناك محادثة الميزانية. يضيف ضمان الجودة التكلفة إلى المشروع. عندما يحاول شخص ما خفض عرض أسعار، فإن إزالة مرحلة الاختبار أو تقليلها يعد رقمًا يسهل قطعه. ما لا يظهر في هذا الحساب هو تكلفة إصلاح الأخطاء بعد الإطلاق - وهي أعلى بكثير من العثور عليها وإصلاحها قبل الإطلاق.
ما الذي يحدث فعليًا عندما تقوم بالشحن دون إجراء اختبار مناسب؟
إن العواقب المترتبة على عدم كفاية ضمان الجودة تتجلى بطرق يمكن التنبؤ بها، وليس أي منها رخيص الثمن.
إصلاح الأخطاء في عملية الإنتاج أمر مكلف. تكلف الأخطاء التي يتم العثور عليها أثناء التطوير جزءًا بسيطًا من تكلفة إصلاحها بعد الإطلاق. بمجرد ظهور الخطأ، فإنك تتعامل مع وقت الطوارئ للمطورين، ونشر الإصلاح العاجل، والتأخير المحتمل لمراجعة متجر التطبيقات، والتعطيل التشغيلي لإدارة منتج معطل أثناء محاولة المستخدمين استخدامه بنشاط.
تتلقى تقييمات متجر التطبيقات النتيجة على الفور. يترك المستخدمون الذين يواجهون الأخطاء تعليقاتهم. إن المراجعة ذات النجمة الواحدة التي تقول "يتعطل التطبيق في كل مرة أحاول التحقق منها" تؤدي إلى ضرر دائم لمعدل التحويل الخاص بك من صفحة المتجر - وهو ضرر يستغرق شهورًا من المراجعات الإيجابية للتعافي منه. لا يمكنك إلغاء نشر مراجعة سيئة.
من الصعب إعادة بناء ثقة المستخدم. الانطباعات الأولى في البرامج تكون دائمة بطريقة يسهل الاستهانة بها. نادرًا ما يمنح المستخدم الذي يواجه خطأً فادحًا في جلسته الأولى التطبيق فرصة ثانية. وفي سوق مثل دولة الإمارات العربية المتحدة، حيث تشتد المنافسة على جذب انتباه المستخدم، فقد اختفى هذا المستخدم المفقود.
تصبح الثغرات الأمنية مسؤوليتك. من المرجح أن تحمل التعليمات البرمجية غير المختبرة عيوبًا أمنية. في بيئة تتزايد فيها الوعي والتنظيم بشأن حماية البيانات، فإن أي خرق أو تسرب للبيانات ناتج عن ثغرة أمنية لم يتم اكتشافها يحمل عواقب تتجاوز بكثير التعرض الفني والقانوني، والإضرار بالسمعة، وفقدان ثقة العملاء التي يصعب استردادها للغاية.
ما الذي يغطيه ضمان الجودة المناسب فعليًا
ضمان الجودة الجيد لا يعني قيام شخص واحد بالنقر فوق أحد التطبيقات في اليوم السابق لإطلاقه. إنها عملية منظمة تعمل بالتوازي مع التطوير وتغطي عدة أنواع مختلفة من الاختبارات.
الاختبار الوظيفي يتحقق من أن كل ميزة تعمل على النحو المحدد. كل زر، كل نموذج، كل سير عمل، كل حالة حافة. هذا هو خط الأساس - إذا لم يقم التطبيق بما يفترض أن يفعله، فلن يهم أي شيء آخر.
اختبار الانحدار يضمن عدم تعطل التعليمات البرمجية الجديدة لشيء كان يعمل سابقًا. مع نمو التطبيقات وتغيرها، يصبح هذا الأمر بالغ الأهمية بشكل متزايد. يتم تشغيل مجموعات الانحدار الآلي عند كل عملية دفع للتعليمات البرمجية، مما يؤدي إلى اكتشاف الأعطال على الفور بدلاً من اكتشافها يدويًا بعد أيام.
يؤكد الاختبار عبر الأجهزة والأنظمة الأساسية أن التطبيق يعمل بشكل صحيح عبر مجموعة من الأجهزة الحقيقية وإصدارات نظام التشغيل التي سيمتلكها المستخدمون بالفعل. التطبيق الذي يعمل بشكل مثالي على أحدث أجهزة iPhone قد يتصرف بشكل مختلف على أجهزة Android متوسطة المدى التي تعمل بإصدار نظام تشغيل عمره عامين - وفي أسواق مثل الإمارات العربية المتحدة والشرق الأوسط الأوسع، تعتبر تجزئة الجهاز أحد الاعتبارات الحقيقية.
اختبار الأداء يضع التطبيق تحت التحميل لتحديد كيفية عمله في ظل ظروف الاستخدام الواقعية. أين تتدهور أوقات الاستجابة؟ في أي نقطة تكافح الواجهة الخلفية؟ ماذا يحدث عندما يحاول مائة مستخدم القيام بنفس الشيء في وقت واحد؟ هذه الأسئلة تحتاج إلى إجابات قبل الإطلاق، وليس بعده.
اختبار قبول المستخدم (UAT) يتضمن مستخدمين حقيقيين - أو ممثلين عن جمهورك المستهدف - يتفاعلون مع التطبيق في بيئة خاضعة للرقابة قبل بدء البث المباشر. يؤدي هذا إلى اكتشاف مشكلات قابلية الاستخدام وفجوات سير العمل التي لن يظهرها الاختبار الفني وحده.
اختبار الأمان يتحقق من الثغرات الأمنية الشائعة، مثل نقاط الضعف في المصادقة، وتخزين البيانات غير الآمن، ونقاط نهاية واجهة برمجة التطبيقات غير المحمية، ومخاطر الحقن. بالنسبة لأي تطبيق يتعامل مع بيانات المستخدم أو المدفوعات، فهذا أمر غير قابل للتفاوض.
حالة أتمتة الاختبار
يعد الاختبار اليدوي أمرًا قيمًا وضروريًا، لكنه لا يمكن التوسع فيه. مع نمو تطبيقك، تصبح إعادة اختبار كل ميزة يدويًا بعد كل تغيير في التعليمات البرمجية أمرًا غير عملي. هذا هو المكان الذي يكتسب فيه الاختبار الآلي مكانه.
يتم تشغيل مجموعة الاختبار الآلي جيدة التصميم في دقائق، وتغطي مئات السيناريوهات، وتعطي فريق التطوير الخاص بك تعليقات فورية حول ما إذا كان التغيير قد تسبب في تراجع في مكان ما في النظام. إن الاستثمار الأولي في بناء هذه المجموعة يؤتي ثماره بسرعة - سواء في الوقت الذي تم توفيره في الاختبار اليدوي أو في الأخطاء التي تم اكتشافها قبل أن تصل إلى المستخدمين.
تعمل أفضل مسارات عمل التطوير على دمج الاختبار الآلي مباشرة في مسار CI/CD، بحيث يؤدي كل دفع للتعليمة البرمجية إلى تشغيل اختبار كامل تلقائيًا. إذا تعطل شيء ما، يعرف الفريق على الفور - وليس بعد أيام عندما يصل المختبر إليه.
كيفية التفكير في ميزانية ضمان الجودة
المعيار المعقول للاستثمار في ضمان الجودة هو ما يقرب من 20 إلى 25٪ من إجمالي ميزانية التطوير الخاصة بك. غالبًا ما يفاجئ هذا الناس، لكنه يعكس النطاق الفعلي للعمل المتضمن في اختبار تطبيق غير تافه بشكل صحيح.
عندما تقوم بتقييم المقترحات المقدمة من وكالات أو فرق التطوير، انظر إلى كيفية تحديد نطاق ضمان الجودة. إذا كان الاختبار عبارة عن بند غامض أسفل عرض الأسعار وبجواره رقم صغير، فاسأل على وجه التحديد عما يغطيه. ما هي أنواع الاختبارات المضمنة؟ كم عدد حالات الاختبار التي سيتم كتابتها؟ هل ستكون هناك تغطية الانحدار الآلي؟ ما هي الأجهزة التي سيتم الاختبار عليها؟
ستخبرك الإجابات كثيرًا عن مدى جدية الفريق في التعامل مع الجودة، ومدى احتمالية تحقيق انطلاقة سلسة.
التحول العقلي الصحيح
إن الطريقة الأكثر إنتاجية للتفكير في ضمان الجودة ليست من حيث التكلفة، بل من حيث التأمين. أنت تدفع مبلغًا معروفًا ويمكن التحكم فيه مقدمًا لتجنب تكلفة غير معروفة، وربما أكبر بكثير لاحقًا. الشركات التي تتعامل مع ضمان الجودة كجزء لا يتجزأ من عملية التطوير الخاصة بها، بدلاً من كونها مرحلة يتم ضغطها أو تخطيها عندما تصبح الأمور صعبة، تشحن باستمرار منتجات أفضل، وتحتفظ بعدد أكبر من المستخدمين، وتنفق أموالًا أقل على إصلاح المشكلات في الإنتاج.
البرمجيات التي تعمل ليست من قبيل الصدفة. إنها نتيجة عملية مدروسة ومنظمة من البناء والتحقق، على قدم المساواة. مرحلة الاختبار ليست حيث ينتهي التطوير. ومن هنا تبدأ الثقة.
Shipping without confidence is a risk you don't need to take.
At Joyboy, QA is built into every project we deliver — not bolted on at the end. From automated regression suites to real-device testing, we make sure what ships actually works. Learn about our QA process.
