ما مدى أهمية اختبار البرمجيات في عالم تطوير البرمجيات اليوم؟ يتناول هذا الموضوع أهمية اختبار البرمجيات وكيف يمكن تحقيق أقصى استفادة من اختبار البرمجيات وكذلك تحسين الاختبارات.

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

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

الحقيقة هي أن الأمر لا يتعلق بضمان الجودة

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

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

إزالة الأخطاء هو ليس تحقيق الجودة، لكن إزالة جميع الأخطاء يعني تحقيق الحد الأدنى من القبول (acceptance). ولكن بدلاً من تسمية هذه العملية ضمان الجودة، سيكون من الأنسب تسميتها إدارة المخاطر وسيتم توضيح السبب في اقتراح هذه التسمية.

حدود الواقع بالنسبة لاختبار البرمجيات (Limitations of Reality)

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

هنا تُسهِم أدوات أتمتة الاختبارات (test automation tools) بشكل كبير في تحسين قدرتنا على إجراء جميع اختبارات الـ regression التي يُمكن أتمتتها. كما تدعم أتمتة الاختبارات الاختبار الاستكشافي (exploratory testing)، إذ تُتيح لنا إنشاء اختبارات مؤتمتة تتابع تقدّمنا ​​في إصلاح الأخطاء التي نكتشفها (وتُصبح هذه الاختبارات من ضمن اختبار الـ regression للتأكد من عدم عودة أي خطأ مرة أُخرى). إضافةً إلى ذلك وبالاقتران مع نظام تقارير فعّال (reporting)، تُقلّل أتمتة الاختبارات من الوقت اللازم لتحديد سبب الخطأ ويُساعِد في إبقاء الإدارة على اطلاع دائم بتقدّم البرمجيات نحو الإصدار (release).

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

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

الحقيقة حول قيمة الاختبار (Test Value)

ثمّة حقيقة حول تنفيذ الاختبارات (conducting tests): إنها الطريقة الوحيدة التي نثق بها لاكتشاف الأخطاء. هنا لا يَهُم إن كنا نتحدث عن الاختبار الاستكشافي (exploratory testing) أو الـ regression testing أو اختبار قبول المستخدم (user acceptance testing) أو أي جزء آخر من منهجية الاختبار فنحن نؤمن بإجراء الاختبارات وهذا ما يجعل الاختبار نشاطًا ضروريًا.

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

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

الحقيقة حول جدولة الاختبارات (Tests Scheduling)

الحقيقة النهائية هي أنه لا يمكنك البدء بالاختبار مبكّرًا بما فيه الكفاية. ابدأ باختبار/التحقق من صحّة تلك المتطلّبات (requirements) لضمان أن المطورين يبنون ويختبرون الأشياء الصحيحة. اختبر الكود مبكرًا حتى تتأكد من أنه يفي بالمتطلّبات ولتضمن أن الكود اللاحق يُبنَى عليه ويتكامل معه بشكل صحيح (integration).

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

* المصدر: https://www.softwaretestingmagazine.com/knowledge/optimizing-testing-testing-realities
** الصورة من موقع: https://hyperight.com/optimizing-marketing-strategies-using-a-b-testing-with-machine-learning