دليل لمختبري البرمجيات للإبلاغ الفعال عن الأخطاء 2

دليل لمختبري البرمجيات للإبلاغ الفعال عن الأخطاء 2

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

  • إصدارات البرامج والأجهزة

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

  • قابليّة إعادة الإنتاج (Reproducibility)

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

  • الشروط المُسْبَقة (Preconditions)

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

  • خطوات إعادة إنتاج الأخطاء

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

  • دليل مرئي (Visual Proof)

هذه الخطوة تشرح نفسها بنفسها. يُعَد جمْع دليل مرئي لكيفيّة إعادة إنتاج الخطأ وآثاره طريقة سهلة لشرح طبيعة المشكلة. في بعض الأحيان، تكون خطوات إعادة إنتاج الخطأ معقدة، لذا فإن عرض مقطع فيديو أو لقطة للشاشة يساعد المطوّر على معرفة الخطأ بالتحديد وكيفية التعامل معه. في حال كان الدليل عبارة عن فيديو، يجب أن تُظهِر كيفيّة حدوث الخطأ ووقت حدوثه أثناء تسجيل مقطع الفيديو. أفضل ممارسة لتسجيل الفيديو هي استخدام مُسجّل الشاشة (screen recorder) ومن الناحية المثالية تمكين مُكوّن إضافي (plugin) يُظهِر مكان النقر أو خطوة النقر على الشاشة. في حال كان الخطأ من النوع البسيط أو من الأخطاء الثابتة بطبيعتها، فإنك لا تحتاج بالضرورة إلى فيديو ففي مثل هذه الحالات يكفي استخدام لقطة للشاشة وتحديد جزء الشاشة الذي به المشكلة. ومع ذلك، يُفضّل تسجيل مقطع فيديو في معظم الحالات.

  • السجلّات (Logs)

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

مع الأخذ بعين الاعتبار توقعات المشروع

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

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

* المصدر: https://www.methodsandtools.com/archive/bugreport.php

** الصورة من موقع: https://www.testdevlab.com

لا توجد تعليقات

شاركني رأيك