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

ما هو تقرير الأخطاء؟ لماذا تحتاج إلى تقرير خطأ جيد؟
يُعد تقرير الأخطاء وثيقة مهمة في دورة حياة اختبار البرمجيات (STLC) توفر مزايا عديدة لفريق الاختبار. فهو يحافظ على tracيقوم بتحليل جميع العيوب والأخطاء المتعددة والتناقضات الأخرى التي تم العثور عليها أثناء اختبار البرمجيات والإبلاغ عنها.
الغرض من وثائق ما بعد الاختبار هذه هو توفير معلومات لفريق المهنيين المعنيين حول مستوى الأخطاء التي تمت مواجهتها أثناء عملية الاختبار.
إن مهندس تطوير البرمجيات يمكن الاطلاع على جميع العيوب والمشاكل الموجودة في البرنامج باستخدام هذا النوع من التقارير. كما يتيح لك تحديد الخطأ البرمجي، مما يمكنك من استخدام أفضل طريقة لإصلاحه. ويساعدك أيضًا على توفير الوقت والمال من خلال المساعدةping تكتشف الأخطاء والمشاكل.
لماذا يجب أن تهتم بتفسيرات الأخطاء الجيدة؟
فيما يلي النقطة التي يجب عليك مراعاتها عند كتابة تقرير جيد ومفصل عن أخطاء البرامج:
- إنه بمثابة دليل للمساعدة في تجنب نفس الخطأ في الإصدارات المستقبلية.
- وفر الوقت للتواصل (البريد الإلكتروني، المكالمات).
- Less العمل للمطورين (سيفعلون ما تريده بالضبط).
- سيكون لديك اختناقات أقل في المشروع؛ سيتم إصلاح الأخطاء بطريقة أسرع وأكثر كفاءة.
- الفرق الحديثة التي تستخدم Jira أو Linear أو Azure يمكن لفرق DevOps أيضًا ربط تقارير الأخطاء بتذاكر دورات التطوير السريعة وخطوط أنابيب الإصدار، مما يضمن tracإمكانية العمل عبر سير عمل ضمان الجودة وعمليات التطوير والتشغيل.
كيفية كتابة تقرير الأخطاء (قالب تقرير الأخطاء)
لا يوجد نموذج محدد للإبلاغ عن الأخطاء، إذ يعتمد ذلك على نوع الخطأ الذي تواجهه.tracنظام الملك. قد يختلف القالب الخاص بك.
ومع ذلك، هناك حاجة دائمًا إلى الحقول المشتركة التالية عندما تريد كتابة تقرير عن خطأ:
- معرف الخطأ/العنوان.
- الجدية والأولوية.
- الوصف
- البيئة
- خطوات التكاثر.
- نتيجة متوقعة.
- نتيجة فعلية.
- المرفقات (لقطات الشاشة ومقاطع الفيديو والنص)
دعونا نلقي نظرة على كل هذه الأخطاء-tracمكونات الملك واحداً تلو الآخر:
1) معرف العنوان/الخطأ:
يجب أن يكون لكل خطأ رقم تعريف فريد. يجب أن تكون أدوات الإبلاغ عن الأخطاء أرقامًا فريدة للأخطاء التي تم اكتشافها حديثًا حتى نتمكن من تحديد الخطأ بسهولة.
أمثلة:
❌ سيء: "لا أستطيع رؤية المنتج عندما أعود إليه مرة أخرى، فهو لا يظهر."
- مشاكل
- العدواني
- كثير الكلام
ويطالب بتنفيذ الحل.
✅ جيد: "عربة التسوق - العناصر الجديدة المضافة إلى سلة التسوق والتي لا تظهر".
- يحدد هذا النوع من العناوين المشكلة على الفور (عربة التسوق)
- وهو يركز على المشكلة التقنية الفعلية.
2) خطورة الخطأ:
تعد خطورة الخطأ عاملاً مهمًا جدًا في تقرير الخطأ. ويصف تأثير الخلل على أداء التطبيق.
- مانع: يؤدي هذا الخطأ إلى فشل التطبيق.
- الرئيسية: يشير الخطأ الفادح إلى حدوث تغيير كبير في منطق العمل.
- قاصر: مشكلة لا تؤثر على وظائف التطبيق ولكنها تؤثر على النتائج المتوقعة.
- تافه: لا يؤثر ذلك على وظائف التطبيق أو تشغيله. قد يكون خطأ مطبعيًا.
3) أولوية الخطأ:
فيما يلي التدرج العام لتحديد أولوية الخطأ:
- عالي: وهو يغطي أي شيء يؤثر على التدفق أو يمنع استخدام التطبيق.
- متوسط: يؤثر سلبا على تجربة المستخدم.
- قاصر: جميع الأخطاء الأخرى مثل (الأخطاء المطبعية، فقدان الرموز، مشكلات التخطيط، وما إلى ذلك).
4) البيئة:
يمكن أن تظهر الأخطاء في بيئة معينة دون غيرها. على سبيل المثال، في بعض الأحيان يظهر خطأ عند تشغيل موقع الويب Firefox، أو حدوث عطل في التطبيق فقط عند تشغيله على جهاز Android الجهاز ويعمل بشكل جيد على iPhone.
لا يمكن التعرف على تقارير الأخطاء هذه إلا من خلال الاختبار عبر المتصفحات أو عبر الأجهزة. لذلك، عند الإبلاغ عن الخطأ، يجب أن يكون مساعدو الجودة قادرين على تحديد ما إذا كان ينبغي ملاحظة الخطأ في بيئة واحدة أو أكثر محددة.
5) ملخص:
لكن إضافة العنوان فقط في تقرير الخطأ لا تفي بالغرض. لذا، إذا لم يكن العنوان كافيًا، يمكنك إضافة ملخص موجز للتقرير.
ملخصك في أقل عدد ممكن من الكلمات بما في ذلك متى وكيف حدث الخطأ. يجب أيضًا استخدام العنوان ووصف الخطأ في عمليات البحث، لذا يجب عليك التأكد من أنك قمت بتغطية الكلمات الرئيسية المهمة.
أمثلة:
- السيئة: "كنت أحاول إضافة أشياء إلى الاختبار، ولم يظهر أي شيء عندما فعلت ذلك أو نقرت على الزر."
- جيد: عندما حاولت إضافة [المنتج] إلى المتجرping لقد أضفت المنتج إلى سلة التسوق، ولكن لم يحدث شيء عندما نقرت على زر "إضافة" في صفحة عرض المنتج المحددة.
6) خطوات التكاثر:
عند الإبلاغ عن خطأ برمجي، من المهم تحديد خطوات إعادة إنتاجه. يجب عليك أيضًا تضمين الإجراءات التي قد تتسبب في حدوث الخطأ. تجنب هنا استخدام عبارات عامة.
كن محددًا بشأن الخطوات التي يجب اتباعها:
فيما يلي مثال على الإجراء المكتوب جيدًا:
الخطوات التالية:
- حدد المنتج X1.
- انقر فوق إضافة إلى سلة التسوق.
- انقر فوق "إزالة" لإزالة المنتج من سلة التسوق.
7) النتيجة المتوقعة:
في تقارير الأخطاء، من المهم وصف النتيجة المتوقعة لكل مهمة فنية، أو تصميم نتائج حالة الاختبار، أو وفقًا لرأي المختبر. كل هذا يساعد المطورين على التركيز على العثور بسرعة على المعلومات المطلوبة.
فمثلا:
يجب تمييز الحقول المطلوبة باللون الأحمر بعد النقر على زر "إرسال".
8) النتيجة الفعلية:
كما يوحي اسمه، يصف هذا الحقل التأثير الفعلي للخطأ. من المهم جدًا كتابة وصف واضح للنتيجة الفعلية.
فمثلا:
يتم تمييز الحقول المطلوبة باللون الأخضر بعد النقر على زر "إرسال".
9) المرفقات (لقطات الشاشة ومقاطع الفيديو):
في تقارير الأخطاء، من الأفضل إرفاق ملفات بتقارير الأخطاء مما يسهل إدراك المعلومات عندما تحتاج إلى عرضها بشكل مرئي:
فمثلا:
- لقطة شاشة: يمكن أن توضح لقطات الشاشة الأخطاء الموجودة في البرنامج بسهولة؛ يكون الأمر مناسبًا عند تمييز الخطأ بتعليق توضيحي أو دائرة أو صورة سهم محددة).
- : فيديو أحيانًا، يصعب وصف الخلل بالكلمات، لذا من الأفضل إنشاء فيديو حتى يتمكن المطور من تصحيح الخلل في البرنامج.
10) النسخة المتأثرة:
إنه إصدار البرنامج المتأثر الذي تم الإبلاغ عن الخطأ فيه.
11) إصلاح الإصدار:
وهو إصدار البرنامج الذي تم فيه حل الخلل. لذا، عندما يتحقق مسؤول ضمان الجودة الذي أبلغ عن الخطأ من إصلاحه، فإنه يستخدم إصدار البرنامج الصحيح.
12) Target النسخة:
الإصدار المستهدف حيث يجب استهداف الخلل لإصلاحه. لذلك، عندما يعمل فريق التطوير على إصلاح خطأ ما، فإنهم في الغالب يستهدفون إصدارًا معينًا من التطبيق.
13) تاريخ الإغلاق:
إنه التاريخ الذي يتم فيه إغلاق الخطأ من قبل فريق اختبار البرنامج. يعد إغلاق الخطأ جزءًا حيويًا ومتكاملًا من اختبار البرامج.
14) الحالة:
عند إنشاء خطأ جديد، يجب أن تكون حالته مفتوحة. بعد ذلك، يمر بمراحل مثل قيد التقدم، والإصلاح، والتشغيل، وإعادة الفتح، وما إلى ذلك.
نصائح لكتابة تقرير الأخطاء
فيما يلي بعض النصائح المهمة التي يجب أن تتذكرها أثناء كتابة تقرير فعال عن الأخطاء:
- كن دقيقاً عند كتابة تقارير الأخطاء. تأكد من عدم تضمين أي معلومات غير مفيدة أو غير ذات صلة.
- يجب عليك الإبلاغ عن الخطأ فورًا بمجرد اكتشافه.
- قم بإعداد التقرير بالتفصيل لتمكين المطور من استخدام الحقائق والمعلومات لتصحيح المشكلة.
- يجب عليك اختبار حدوث نفس الخطأ على وحدات نمطية أخرى مماثلة للتحقق من صحتها.
- Revقم بمراجعة تقرير الأخطاء مرة واحدة على الأقل قبل إرساله.
- يجب عليك التأكد من أن تقرير الخطأ يحتوي على وصف لخطأ واحد فقط.
- وأخيرًا، يجب ألا تخاف من طلب المساعدة من مدير المشروع إذا كنت تشعر بعدم الوضوح بشأن شيء ما.
- استخدم ميزات الفرز المدعومة بالذكاء الاصطناعي في Jira أو Linear لتصنيف الخطورة تلقائيًا، واقتراح التكرارات، وتوجيه التقرير إلى مالك المكون الصحيح.
أدوات الإبلاغ عن الأخطاء
يتم الآن تنفيذ عملية الإبلاغ عن الأخطاء، التي يتم إجراؤها يدويًا، باستخدام أدوات الإبلاغ عن الأخطاء المتنوعة المتوفرة في السوق.
- Jira
- خطي
- Azure DevOps
- Zoho Bug Tracكير
- Bugzilla
يمكنك التحقق من مراجعتنا التفصيلية لـ أفضل أداة للإبلاغ عن الأخطاء.
المشكلة الشائعة والحل أثناء كتابة تقرير الأخطاء:
فيما يلي بعض المشكلات الشائعة وحلولها أثناء كتابة تقرير الأخطاء:
| مثال لتقرير الأخطاء | المشكلة |
|---|---|
| عند ضرب 2 في 3 يكون الجواب إيجابيا. | قم بالإبلاغ عن النمط، وليس مثالا. |
| سيتم ترتيب القائمة أبجديًا عند إضافة عنصر جديد لتجنب ذلك. | لا تكتفِ بوصف الخطأ فقط |
| فمثلا: للبدء، ستحتاج إلى فتح متصفحك وكتابة عنوان الموقع. URLستجد أن الحقل الأول، "اسم المستخدم"، مكتوب بشكل خاطئ. |
توجه دائمًا إلى صلب الموضوع (لا تحكي القصة أبدًا!). |
| اسم العميل في التقرير به خطأ إملائي. الأولوية: عالية، درجة الخطورة: عالية | لا تخلط أبدًا بين الأولوية والشدة. |
| معادلة حساب الضريبة غير صحيحة !!؟؟ | لا يستخدم الأحرف الكبيرة، والأحرف الحمراء، والدوائر الحمراء، '!'، |
| لا أعتقد أن تصميم واجهة المستخدم للصفحة الرئيسية جيد. | لا تستخدم حكمك الشخصي. |
| مثال للوصف غير الواضح: بخصوص مناقشتنا اليوم، يرجى القيام بالإجراء المطلوب لهذه الصفحة. | اجعل وصفك مفهوما للجميع. |
| يجب أن تكون خلفية الصفحة باللون الأزرق أو البرتقالي أو الأخضر، أو يمكنك جعلها باللون الأسود أو الأبيض.
هذا ليس جيدًا لأنه من غير الواضح ما هو المطلوب من فريق تطوير وتصميم الويب |
تصغير الخيارات |
| في بعض الأحيان لا تعمل صيغة حساب الضريبة كما هو متوقع. | القاعدة الذهبية: لا تستخدم كلمة "أحياناً". |
مثال لتقرير الأخطاء
فيما يلي مثال صغير لتقرير الخطأ:
[حسابي] يتم عرض الخط السفلي عند تحريك الماوس فوق زر التحديث.
الوصف: نحن بحاجة إلى إزالة التسطير عند تمرير الماوس على زر التحديث في قسم حسابي.
الرابط: http://test.com/mv-account/
المتصفح/نظام التشغيل: كروم 25. أو إس إكس يوسمايت 10.10.2
خطوات التكاثر:
1. انتقل إلى www.test.com
2. قم بتسجيل الدخول عبر بيانات اعتماد تسجيل الدخول
3. انتقل إلى حسابي
4. مرر الماوس على زر التحديث
نتيجة فعلية: هناك تسطير.
نتيجة متوقعة: لا تسطير.
بيانات تسجيل الدخول: test@test.com / mysecretpass12
يجب تجنب الأخطاء في كتابة تقرير الأخطاء
فيما يلي بعض الأخطاء المهمة التي يجب عليك تجنبها أثناء كتابة تقرير الأخطاء:
- لا تكتب عن استيائك، ولا تُضمّن مشاعرك الشخصية أبداً.
- إنه يزعج الأشخاص الذين يرغبون في التركيز على المهمة عندما تقوم بتحميل منشورك بالعديد من الرموز التعبيرية.
- لا تفرط أبدًا في تحميل رسالتك بعلامات التعجب؛ لا يسرع العمل.
- لا أحد يريد أن يشعر بالإهانة. إنه يدمر الدافع ويبطئ إدراك القضية.

