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

إن كتابة حالات الاختبار (test cases) ليست مجانية. يجب على شخصٍ ما في مكانٍ ما تصميمها وتطويرها وصيانتها. كل هذا يكلّف وقت وجهد ومال ولذا يجب أن نحصل على مُقابِل نتيجة لاستثمارنا في كتابة حالات الاختبار. إذًا كيف نثبت أن اختباراتنا وخصوصًا الآلية/المؤتمتة هي ذات قيمة (value) وماهي القيمة التي تقدّمها؟

القاعدة تقول بأن الاختبارات الآلية تكون أكثر قيمة عند اكتشاف الأخطاء من خلال هذه الاختبارات. إذا كانت اختباراتك الآلية دائمًا ما تنجح أو تفشل، فقد حان الوقت لمراجعتها وإعادة النظر فيها. مجموعة الاختبار المؤتمتة (test suite) التي لا تكتشف أي أخطاء هي ليست مفيدة. هناك عدّة أسباب وراء احتمال حدوث ذلك، فربما لم تكن مجموعة الاختبار صارمة بما يكفي أو تطرح أسئلة خاطئة.

تغطية الاختبار (Test Coverage) – مقياس ضعيف لقيمة الاختبار

لا تُثبِت تغطية الاختبار أن لديك اختبارات قيّمة. إذا اتفقنا على أن الاختبارات القيّمة هي تلك التي تكشف عن أخطاء، فإن تتبّع تغطية الاختبار لا يخبرنا بأي شيء عن قيمة الاختبار. لا تخبرنا تغطية الاختبار ما إذا كان الاختبار قد اكتشف أخطاءً أم لا. إذا كان لدي مشروع بتغطية اختبار بنسبة 100٪، فهل هذا يعني أن لدي حزمة اختبار قيّمة (test package)؟ لا يمكننا الإجابة على هذا السؤال. نحن بحاجة إلى التعمّق أكثر.

الذهاب إلى أبعد من تغطية الاختبار (Going Beyond Test Coverage)

إذا كانت تغطية الاختبار تمثّل مقياسًا ضعيفًا لقيمة الاختبار، فما المقاييس التي تعمل جيدًا لاكتشاف قيمة الاختبار؟ هناك كثير من المقاييس التي يمكنك استخدامها وفيما يلي خمسة مقاييس:

• المقياس الأول: False Negative Rate

القاعدة تقول: إذا لم تتمكن من إصلاح الاختبار فيجب عليك إزالته!

الاختبارات تفشل أحيانًا لأي سبب من الأسباب. يمكن أن يرجع ذلك إلى أشياء متعدّدة مثل البيئة (environment) أو التصميم السيئ. تتبّع فشل هذه الاختبارات مهم جدًا. هذا الاختبارات التي تفشل تقلّل من قيمة الاختبار وبمجرّد تحديدها لديك خياران: إصلاحها أو إزالتها.

• المقياس الثاني: False Positive Rate

القاعدة تقول: من الأفضل أن يكون لديك مجموعة اختبار بها إخفاقات في تنفيذها على أن يكون لديك معدّل نجاح بنسبة 100٪.

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

• المقياس الثالث: وقت التنفيذ (Execution Time)

القاعدة تقول: يؤدّي تنفيذ مجموعة الاختبار البطيئة إلى إبطاء فريقك وتقليل قيمة الاختبارات!

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

إذا رأيت التنفيذ يستغرق وقتًا طويلاً، فابدأ في التفكير في كيفية تقليل هذا الوقت. المأمول أن تكون اختباراتك مصمّمة بحيث يمكن تنفيذها بأي ترتيب دون مشاكل. إذا كان هذا هو الحال، فربّما يمكنك إجراء الاختبارات بالتوازي (in parallel).

• المقياس الرابع: تم رفع الأخطاء المؤكدة (Confirmed Defects Raised)

القاعدة تقول: الاختبارات التي تكتشف الأخطاء لها قيمة.

هذا مقياس بسيط ولكنه قوي. ابدأ في تسجيل عدد الأخطاء التي وجدها الاختبار. ليس فقط العدد ولكن أيضًا تأثيرها (impact) وخطورتها (criticality). ابدأ في التعرّف على مدى قيمة الأخطاء التي تجدها اختباراتك. استخدم هذا لإثبات القيمة التي تجلبها مجموعة الاختبار إلى المشروع.

• المقياس الخامس: Defect Clustering

القاعدة تقول: غالبًا ما تحدث الأخطاء في مجموعات. سيساعدك تتبّع هذه المجموعات في التخطيط لاختباراتك.

قسّم مشروعك إلى مجموعات (clusters). يمكن أن يتم ذلك عن طريق المزايا الموجودة (features). في كل مرة يتم العثور على خطأ من خلال مجموعة الاختبار الخاصة بك، تتبّع المجموعة التي تم العثور على الخطأ فيها. استخدم هذا لتوجيه المكان الذي تستثمر فيه وقتك في مجموعة الاختبار.

لا تكفي كتابة الاختبارات وتتبّع التغطية فقط

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

بالتوفيق للجميع…

* المصدر: https://tomdriven.dev/automated-test/2021/03/11/going-beyond-test-coverage.html

** الصورة من موقع: https://testsigma.com/blog/how-create-best-test-case-design-get-maximum-test-coverage