كيف تكتب تقرير خطأ (Bug Report)

فرز المسودة (الخطوة 1). تخلط المسودة ثلاث مشكلات. أولاها أن دفع الفاتورة يخفق لبعض المبالغ: هذا هو العيب الرئيسي، وله تقريره الخاص. وثانيتها أن تسمية زر الدفع مقطوعة في الواجهة العربية عند العرض الضيق: عيب مستقل له سببه وإصلاحه ودورة حياته، فله تقرير خاص أيضاً. وثالثتها «رسالة الخطأ بلا فائدة»: الرسالة العامة سلوك معقول أمام خطأ غير متوقع في الخادم، والمتطلب BILL-3 لا يقول شيئاً عن صياغة رسائل الخطأ، وبعد إصلاح الرمز ⁦500⁩ لن تظهر الرسالة لهذه الدفعات أصلاً. فهي ليست عيباً؛ وإن رأيت أن صياغتها يجب أن تتغير فاطرحها على مالك المنتج اقتراحَ تحسين مستقلاً. أما الطلب المنسوخ والاستجابة ذات الرمز ⁦500⁩ فليسا مشكلتين مستقلتين: بعد تنظيفهما (الخطوة 5) يدخلان التقرير الرئيسي دليلاً. والباقي لا يدخل أي تقرير: «معطّل تماماً» و«عاجل» و«بأسرع وقت» رأي، و«خطأ في كل مرة» ادعاء غير مقيس تنقضه المحاولتان 1 و6.

عزل المحفّز (الخطوة 2). لا تختلف المحاولتان 1 و2 إلا في المبلغ: الدفع بمبلغ ⁦250.00⁩ ينجح وبمبلغ ⁦250.75⁩ يفشل، والمحاولة 3 تكرر المحاولة 2 بالنتيجة نفسها، فالأمر ليس حادثة عابرة. وتغيير المتصفح (المحاولة 4) لا يغيّر شيئاً. وتغيّر المحاولة 5 الحساب والجهة المفوترة والمبلغ معاً وتفشل مع ذلك، فالإخفاق لا يحتاج إلى أيٍّ من تلك القيم بعينها. وتنجح المحاولة 6 (⁦1000.00⁩) كما نجحت المحاولة 1. فالمحفّز إذن مبلغ جزؤه العشري غير صفري. ونجحت المحاولة 7 على الإصدار ⁦7.2.4⁩، وهذا يشير إلى انحدار (Regression) دخل مع الإصدار ⁦7.3.0⁩؛ لكن بيئة UAT تختلف عن staging في أكثر من البناء، فاذكره قرينةً قوية لا حقيقةً مثبتة. وسطر السجل يدلّ المطوّر على موضع البحث (AmountMapper.java:58)، لكن المختبِر يقدّمه دليلاً، لا تشخيصاً في العنوان.

التقرير النموذجي للعيب الرئيسي. العنوان: «دفع فاتورة» يعيد ⁦500⁩ ولا يُنشئ دفعة عندما يكون للمبلغ جزء عشري غير صفري، مثل ⁦250.75⁩. البيئة: الخدمات المصرفية عبر الإنترنت ⁦7.3.0⁩ في بيئة staging، على ⁦Chrome 129 / Windows 11⁩، وأُعيد إنتاجه أيضاً على ⁦Firefox 131 / Windows 11⁩، بالواجهة العربية ودور عميل أفراد، وحسابا الاختبار test-cust-07 وtest-cust-12. الخطورة: حرج (Critical). الأولوية: عالية (High). التكرار: دائماً — فشلت المحاولات الأربع كلها بمبلغ كهذا (المحاولات من 2 إلى 5)، ونجح المبلغان الخاليان من الكسور كلاهما.

الشروط المسبقة: مستخدم مسجّل الدخول بدور عميل أفراد (مثل test-cust-07)، ولديه جهة مفوترة محفوظة («الكهرباء»، BLR-ELEC-01) وحساب (ACC-TEST-0007) رصيده يغطي المبلغ. خطوات إعادة الإنتاج: 1. افتح «المدفوعات» ثم «دفع فاتورة». 2. اختر الجهة المفوترة «الكهرباء» والحساب ACC-TEST-0007. 3. أدخل ⁦250.75⁩ في حقل «المبلغ». 4. انقر «ادفع الفاتورة».

النتيجة المتوقعة: تُنشأ الدفعة، وتعرض صفحة التأكيد رقماً مرجعياً، وتظهر الدفعة في سجل الحساب بالرقم نفسه، وينقص الرصيد ⁦250.75⁩ (المتطلب BILL-3: أي مبلغ من ⁦1.00⁩ إلى ⁦10,000.00⁩ ريال بمنزلتين عشريتين على الأكثر). النتيجة الفعلية: يظهر شريط أحمر نصه «حدث خطأ ما. يُرجى المحاولة لاحقاً.»، ويعيد POST /api/v2/bill-payments رمز الحالة ⁦500⁩ مع الجسم {"error":{"code":"INTERNAL","message":"Unexpected error","requestId":"b7e2-41c9"}}؛ ولا تظهر أي دفعة في السجل، والرصيد لم يتغير.

الأدلة: لقطة شاشة للشريط؛ والاستجابة أعلاه؛ وسطر سجل الخادم لمعرّف الطلب b7e2-41c9، وهو java.lang.NumberFormatException: For input string: "250.75" في bank.payments.AmountMapper.toMinorUnits(AmountMapper.java:58)؛ والطلب أمرَ cURL منظّفاً: curl 'https://staging.bank.example/api/v2/bill-payments' -H 'accept: application/json' -H 'authorization: Bearer [REDACTED]' -H 'content-type: application/json' --data-raw '{"billerId":"BLR-ELEC-01","fromAccount":"ACC-TEST-0007","amount":"250.75"}'. وُضع [REDACTED] مكان رمز Bearer لأن كل من يستطيع قراءة المتتبّع يستطيع استخدامه ما دام صالحاً، ويضع المطوّر مكانه رمزاً لحساب اختبار خاص به. ويُحذف الخيار -b كله أيضاً: فهو يحمل ملف تعريف ارتباط الجلسة، وهو قابل للاستخدام بالقدر نفسه، وملف تعريف ارتباط التحليلات _ga. ففي الأمر المنسوخ قد تأتي ملفات تعريف الارتباط في -b لا في ترويسة، فافحص الموضعين عند الحجب. وتُحذف ترويسات accept-language وsec-ch-ua-platform وuser-agent لأن المتصفح يضيفها من تلقاء نفسه، والمحاولة 4 تُظهر أن المتصفح لا يغيّر النتيجة. وتبقى ترويستا accept وcontent-type لأنهما تصفان ما يُرسَل في الطلب وما يُتوقَّع في الاستجابة؛ ولولا content-type لوسم curl جسم --data-raw بالنوع application/x-www-form-urlencoded. وفي العمل الفعلي شغّل الأمر المنظّف مرة واحدة برمز جديد خاص بك قبل إرفاقه: فإن أعاد الرمز ⁦500⁩ نفسه، فلم يكن أي شيء مما حذفته لازماً.

ملاحظات: المبالغ الخالية من الكسور تنجح (⁦250.00⁩ و⁦1000.00⁩)، والإخفاق لا يتعلق بالمتصفح ولا بالحساب ولا بالجهة المفوترة (المحاولتان 4 و5). والدفعة نفسها بمبلغ ⁦250.75⁩ تنجح في بيئة UAT التي تعمل بالإصدار ⁦7.2.4⁩، فالأرجح أن الإصدار ⁦7.3.0⁩ أدخل العيب؛ ولأن UAT تختلف عن staging في أكثر من البناء، فهذه قرينة قوية لا دليل قاطع. ولم يُعثر على عيب مفتوح عند البحث عن bill-payments وNumberFormatException.

لماذا حرج: انزل على مقياس الخطورة في الدليل من الأعلى. لا ينطبق حاجب (Blocker)، لأن دفع الفواتير ما زال يعمل للمبالغ الخالية من الكسور. وينطبق حرج: فهذا فشل دفع، ولا يستطيع العميل دفع المبلغ الدقيق لأي فاتورة فيها كسور. وقد تحتج بعض الفرق بأنه حاجب لأن كثيراً من الفواتير الحقيقية فيها كسور؛ ومع هذا التبرير يمكن الدفاع عن أيٍّ من المستويين، أما رئيسي (Major) أو ما دونه فلا، لأن الدفعات تفشل. ولماذا عالية: بيئة الإنتاج ما زالت تعمل بالإصدار ⁦7.2.4⁩، وهو البناء الذي تنجح عليه الدفعة نفسها في بيئة UAT، فإطلاق ⁦7.3.0⁩ بهذا العيب سيجعل كل دفعة فاتورة لمبلغها جزء عشري غير صفري تفشل لدى العملاء، ويجب إصلاحه قبل الإصدار. ولو كان ⁦7.3.0⁩ قد وصل إلى الإنتاج لكانت الأولوية قصوى (Highest). وأنت بصفتك المختبِر تقترح الأولوية، ويقررها اجتماع فرز العيوب أو مالك المنتج.

التقرير الثاني. العنوان: تسمية زر «ادفع الفاتورة» مقطوعة في الواجهة العربية عند عرض ⁦360 px⁩ لنافذة العرض. البيئة: الخدمات المصرفية عبر الإنترنت ⁦7.3.0⁩ في بيئة staging، وشريط أجهزة Chrome بعرض ⁦360 px⁩؛ وتتسع التسمية عند ⁦412 px⁩، وتتسع التسمية الإنجليزية عند ⁦360 px⁩. الخطورة: ثانوي (Minor)، فهو عيب شكلي والزر ما زال يعمل. الأولوية: متوسطة (Medium) مقترحة (السبرنت القادم)، لأنه الإجراء الرئيسي في الصفحة لمستخدمي الواجهة العربية على الهواتف الضيقة؛ وقد يرفعها مالك المنتج إلى عالية قبل الإصدار. أرفق لقطتي شاشة عند ⁦360 px⁩ و⁦412 px⁩، وإن استطعت فتأكد على هاتف حقيقي بهذا العرض واذكر طرازه: فمحاكاة الجهاز ليست الجهاز نفسه.

بعد الإصلاح: يعيد اختبار التأكيد (Confirmation testing) الخطوات نفسها بالمبلغين ⁦250.75⁩ و⁦99.50⁩. وأضف فحوص انحدار حول التغيير: مبالغ خالية من الكسور، وحدود المتطلب BILL-3 (⁦1.00⁩ و⁦10,000.00⁩ مقبولان، و⁦0.99⁩ و⁦10,000.01⁩ مرفوضان)، ومبلغاً بمنزلة عشرية واحدة مثل ⁦250.5⁩ (مقبول)، وآخر بثلاث منازل مثل ⁦250.755⁩ (مرفوض، لأن BILL-3 يسمح بمنزلتين على الأكثر).

راجع عملك. تقريرك كامل إذا استطاع مطوّر لم يرَ المسودة أن يعيد إنتاج الإخفاق من خطواتك وحدها؛ وإذا ذكر العنوان العَرَض والمكان والشرط بلا رأي؛ واستخدمت الخطوات مبلغاً دقيقاً واحداً وتركت بقية المحاولات للملاحظات؛ وأشارت النتيجة المتوقعة إلى BILL-3؛ ونقلت النتيجة الفعلية الشريط ورمز الحالة ومعرّف الطلب بدقة؛ وحُجب رمز Bearer واختفت ملفات تعريف الارتباط؛ وحُددت الخطورة والأولوية كلٌّ على حدة مع سبب؛ ولم يدخل هذا التقريرَ عيبُ الزر ولا الشكوى من صياغة رسالة الخطأ. وبمصطلحات ISTQB فإن ما لاحظته إخفاق (Failure): رمز الحالة ⁦500⁩ والدفعة الغائبة؛ والتقرير يعطي المطوّر ما يحتاجه ليجد العيب (Defect) الكامن وراءه، وسطر السجل دليل لا تشخيصك.