الإبلاغ عن جودة المنتج للقيادة

لماذا يهم

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

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

ثلاثة تقارير لثلاثة جماهير

«تقرير ملخص الاختبار» (Test Summary Report) الذي تطلبه قوالب كثيرة هو تقرير إتمام الاختبار (Test completion report) من درس تقارير الاختبار؛ فقد استخدم منهج ISTQB التأسيسي لعام 2018 الاسم القديم. وهو يختم مرحلة واحدة من الاختبار مقابل معايير الخروج، لمن يقبل ذلك الإصدار.

أما القيادة فتطرح أسئلة أخرى على مدى أطول: هل تتحسن الجودة؟ أين يتضرر العملاء؟ ما المخاطر التي نحملها؟ ماذا تحتاجون؟ لذا استخدم ثلاثة تقارير:

• تقرير إتمام الاختبار: لكل مرحلة اختبار، لمن يقبل الإصدار؛ ما الذي اختُبر وما الذي بقي مفتوحاً.
• بيان المخاطر المتبقية (Residual risk): لكل إصدار، لصاحب قرار المضي أو التوقف (Go/No-Go)؛ ما الذي قد يضر المستخدمين، ومن يقبله.
• مراجعة الجودة: لوحة مؤشرات شهرية واجتماع كل ربع سنة للقيادة؛ الجودة عبر الإصدارات والفرق، والأسباب، والمخاطر المرحّلة، والقرارات المطلوبة.

الجمع بين نتائج الاختبار وإشارات الإنتاج

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

• الأدلة قبل الإصدار: المؤشرات الاستباقية من مجموعة مؤشراتك، مثل الاختبارات عالية المخاطر الناجحة عند الإصدار.
• معدل التسرّب (Escape rate): العيوب التي وُجدت في الإنتاج خلال نافذة متفق عليها، كنسبة من كل العيوب التي وُجدت لتلك الإصدارات (وهو مكمّل DDP من درس مقاييس العيوب). اذكر الأعداد والنافذة: «9% (⁦4⁩ من ⁦44⁩، خلال ⁦30⁩ يوماً)».
• الحوادث (Incidents): أحداث غير مخطط لها في الإنتاج تضر المستخدمين أو العمل، تؤخذ من سجل الحوادث وتُعرض حسب مستوى الخطورة (وكثيراً ما يكون Sev1 أخطرها، ولكل شركة تعريف مستوياتها) والأثر على المستخدمين. وصنّف كل حادثة: فإخفاقات السعة والإعدادات والأطراف الخارجية ليست عيوباً متسرّبة.
• نسبة فشل التغييرات (Change fail rate): بحسب DORA هي نسبة عمليات النشر التي تحتاج إلى تدخل فوري، مثل التراجع (Rollback) أو إصلاح عاجل (Hotfix). وهي تلتقط إخفاقات النشر التي لا تراها اختبارات الشيفرة أبداً.

جرّبها: حاسبة النسبة المئوية

مثال تطبيقي: مراجعة جودة ربع سنوية

لتطبيق توصيل الطعام من الدرس السابق ثلاثة فرق: الدفع (Checkout) والطلب (Ordering) وتطبيق المندوبين (Courier app). وكل ربع سنة يرسل قائد ضمان الجودة إلى القيادة هذه المراجعة ذات الصفحة الواحدة قبل يومين من اجتماع مدته ⁦45⁩ دقيقة، مبنيةً على بيانات تحتفظ بها الفرق أصلاً، ويراجعها كل قائد فريق أولاً حتى لا يُفاجأ أحد.

الجزء 1:1QUARTERLY QUALITY REVIEW · Food-delivery app · Q3 · data as of 2 Oct
Readers: CTO, head of product, engineering managers, support lead
Sources: test management tool, defect tracker, incident and deployment logs

الجزء 2:2HEADLINE  Checkout improved and met its targets. Courier app quality fell:
          2 of the 3 Critical escapes this quarter came from it.
          Decision needed by 15 Oct: test devices for the courier app.

                               Checkout          Ordering          Courier app
الجزء 3:3BEFORE RELEASE (Q3)
  High-risk tests passed       100%              96%               71%
الجزء 4:4IN PRODUCTION (Q2 -> Q3)
  Escape rate, 30 days         18% -> 9% (4/44)  12% -> 11% (3/27) 10% -> 21% (7/33)
  Critical escapes             2 -> 0            0 -> 1            0 -> 2
  Change fail rate             14% -> 8% (4/50)  10% -> 10% (3/30) 8% -> 25% (3/12)
  Sev1 incidents               1 -> 0            0 -> 0            0 -> 1
  Sev2 incidents               3 -> 1            1 -> 2            1 -> 3
الجزء 5:5TARGETS  escape rate <= 10% · no Critical escapes · change fail rate <= 10%

الجزء 6:6WHY  Courier: 10 of 35 high-risk tests could not run (no older Android
     devices), and 5 of its 7 escapes occur only on those versions. The Sev1
     (live tracking down for 3 hours) followed an Android permission change.
     Ordering: the Critical escape was a stale menu price after an admin edit.
     Checkout: contract tests added in Q2 stopped 6 breaking payment-API
     changes before release.

الجزء 7:7RESIDUAL RISK CARRIED INTO Q4
  R1  Courier app on older Android versions: untested until devices arrive
  R2  New payment provider in November: no load test possible before go-live
  R3  14 Minor defects deferred, each with a workaround (list attached)

الجزء 8:8ASKS  1. Approve renting 6 older Android test devices (quote attached),
         by 15 Oct
      2. Head of product: accept R2 at the November go/no-go, or move the date

• سطر العنوان أولاً: الاتجاه والقرار المطلوب مع موعده النهائي. وكل نسبة تُعرض مع أعدادها والربع السابق والقيمة المستهدفة، ويُقرأ كل فريق مقابل ماضيه، ولا تُرتَّب الفرق. ولا يدخل معدلَ التسرّب إلا الإصدارات التي أُغلقت نافذتها البالغة ⁦30⁩ يوماً قبل تاريخ البيانات، أما الإصدارات اللاحقة فتدخل المراجعة التالية.
• الأدلة فوق النتائج ليقارن القرّاء بينهما. وفي تطبيق المندوبين تتفقان: لم ينجح إلا 71% من الاختبارات عالية المخاطر، وتسرّب 21% من العيوب، فقد أنذر المؤشر الاستباقي قبل الإصدار؛ وفي المرة القادمة تصرّف بناءً على إنذاره قبل الإطلاق. أما اختبارات ناجحة مع تسرّب متزايد فتعني عادةً أن الاختبارات لا تغطي ما يفعله المستخدمون، وتسرّب مستقر مع نسبة فشل تغييرات متزايدة يشير إلى النشر أو البنية التحتية.
• أسطر «لماذا» مأخوذة من تحليل العيوب المتسرّبة (لماذا أفلت كل عيب متسرّب من الاختبار) ومن مراجعات الحوادث دون لوم (Blameless postmortems)، وهي تبحث عن الظروف التي أدت إلى الإخفاق لا عن شخص تلومه. وتُكتب بلغة الأثر على المستخدمين، فيقضي الاجتماع وقته في الطلبات.

QUARTERLY QUALITY REVIEW · Food-delivery app · Q3 · data as of 2 Oct
Readers: CTO, head of product, engineering managers, support lead
Sources: test management tool, defect tracker, incident and deployment logs

HEADLINE  Checkout improved and met its targets. Courier app quality fell:
          2 of the 3 Critical escapes this quarter came from it.
          Decision needed by 15 Oct: test devices for the courier app.

                               Checkout          Ordering          Courier app
BEFORE RELEASE (Q3)
  High-risk tests passed       100%              96%               71%
IN PRODUCTION (Q2 -> Q3)
  Escape rate, 30 days         18% -> 9% (4/44)  12% -> 11% (3/27) 10% -> 21% (7/33)
  Critical escapes             2 -> 0            0 -> 1            0 -> 2
  Change fail rate             14% -> 8% (4/50)  10% -> 10% (3/30) 8% -> 25% (3/12)
  Sev1 incidents               1 -> 0            0 -> 0            0 -> 1
  Sev2 incidents               3 -> 1            1 -> 2            1 -> 3
TARGETS  escape rate <= 10% · no Critical escapes · change fail rate <= 10%

WHY  Courier: 10 of 35 high-risk tests could not run (no older Android
     devices), and 5 of its 7 escapes occur only on those versions. The Sev1
     (live tracking down for 3 hours) followed an Android permission change.
     Ordering: the Critical escape was a stale menu price after an admin edit.
     Checkout: contract tests added in Q2 stopped 6 breaking payment-API
     changes before release.

RESIDUAL RISK CARRIED INTO Q4
  R1  Courier app on older Android versions: untested until devices arrive
  R2  New payment provider in November: no load test possible before go-live
  R3  14 Minor defects deferred, each with a workaround (list attached)

ASKS  1. Approve renting 6 older Android test devices (quote attached),
         by 15 Oct
      2. Head of product: accept R2 at the November go/no-go, or move the date

جرّبها: منسّق Markdown جرّبها: تحويل Markdown إلى PDF

عرض المخاطر المتبقية لجمهور قرار المضي أو التوقف

قبل كل إصدار يضيق السؤال: ما الذي قد يضر المستخدمين إن أطلقنا، ومن يقبل ذلك؟ صنّف ما يبقى كما يفعل دليل الاختبار المبني على المخاطر (خُفّض، جزئي، مفتوح، لم يُختبر، خارج النطاق)، ثم أعد كتابة كل بند مهم لقرّاء لا يعرفون أرقام المخاطر ولا أعداد الاختبارات. وهذا هو الخطر R2 من المراجعة بخمسة أجزاء، لقرار المضي أو التوقف في نوفمبر؛ أما الاجتماع نفسه فموضوع درس جاهزية الإصدار.

• الأثر، بلغة المستخدمين: إذا تباطأ مزوّد الدفع الجديد في ذروة مساء الجمعة، ينتظر العملاء عند الدفع ويتخلى بعضهم عن طلباتهم.
• الدليل: نجحت اختبارات الدفع على بيئة الاختبار لدى المزوّد، وهي تحدّ معدل الطلبات، فلم يُختبر حِمل الذروة قط.
• الاحتمال، حكماً معلَّلاً لا نسبة مخترعة: غير معروف، إذ لا دليل في أي اتجاه، وهذا هو الخطر.
• الاحتواء: تذهب 10% من المدفوعات إلى المزوّد الجديد في الأسبوع الأول، ويصدر تنبيه إذا تجاوزت عملية الدفع ⁦5⁩ ثوانٍ، والعودة المجرَّبة إلى المزوّد القديم تستغرق أقل من ⁦15⁩ دقيقة.
• القبول، مع توصيتك موسومةً بأنها توصيتك: يقرر رئيس المنتج، ويوصي فريق ضمان الجودة بالبدء بنسبة 10%.

جرّبها: مولّد الاختبار المبني على المخاطر

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
• DORA's software delivery performance metricsDORA (Google Cloud)مقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.
• Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Google / O'Reilly Media · 2016مراجعات ما بعد الحوادث الخالية من اللوم: أيّ الحوادث تستدعيها، وما الذي تسجّله — الأثر والأسباب الجذرية وإجراءات المتابعة — ولماذا يُستبعد منها اللوم.