ضمان جودة المنتج من البداية إلى النهاية

الخطوة ⁦1⁩، المتطلبان R1 وR2. يبدو R1 قابلاً للاختبار، ولهذا يسهل أن تفوت ثغراته. أسئلة لريم: هل المبلغان ⁦10⁩ و⁦5,000⁩ ريال مسموحان كلاهما كما توحي الصياغة؟ وهل يجوز للمتبرع أن يتبرع بالهللات، مثل ⁦10.50⁩؟ متى يُخصم التبرع في شهر لا يوجد فيه يومه، كتبرع بدأ في اليوم ⁦31⁩ في شهر من ⁦30⁩ يوماً، أو تبرع بدأ في اليوم ⁦29⁩ أو ⁦30⁩ أو ⁦31⁩ في فبراير؟ وهل يُخصم التبرع الأول عند إنشائه؟ وماذا يحدث حين يفشل خصم شهري؟ إذا كانت المبالغ بالريال الكامل وكان الطرفان مسموحين، فالقيم الحدّية في الصيغة الثنائية (2-value BVA) هي ⁦9⁩ (مرفوض) و⁦10⁩ (مقبول) و⁦5,000⁩ (مقبول) و⁦5,001⁩ (مرفوض)؛ وإذا سُمح بالهللات فالخطوة ⁦0.01⁩، فتصبح القيم ⁦9.99⁩ و⁦10.00⁩ و⁦5,000.00⁩ و⁦5,000.01⁩. ولموعد الخصم، ابدأ تبرعات في الأيام ⁦28⁩ و⁦29⁩ و⁦30⁩ و⁦31⁩ وتابعها عبر شهر من ⁦30⁩ يوماً وعبر فبراير. أما R2 فيسقط عند سؤال الدليل مباشرة: لا أحد يستطيع أن يقول إن الصفحة «سريعة» أثناء «حملة»، فلا يمكن الحكم عليه بالنجاح أو الفشل. أسئلة لريم: أي الصفحات وأي طلبات الواجهة البرمجية تُعدّ صفحات تبرع؟ وكم متبرعاً كانوا يتبرعون في الوقت نفسه عند ذروة الحملة الماضية؟ ثم أعد كتابته بأرقام توافق عليها ريم، مأخوذة من حركة المرور في الحملة الماضية، مثلاً: «حين يُكمل ⁦500⁩ متبرع تبرعاً في الوقت نفسه، لا يتجاوز زمن الاستجابة عند المئين ⁦95⁩ (p95) لصفحة التبرع ولواجهة التبرع البرمجية ثانيتين، ويفشل أقل من ⁦1%⁩ من الطلبات». الأرقام هنا مثال فقط؛ والصيغة نفسها — الحمل والمئين والحد ومعدل الخطأ — هي ما يجعل المتطلب قابلاً للاختبار.

الخطوة ⁦1⁩، المتطلب R3. يصف مسار النجاح فقط، بينما ينبّه الدليل إلى أن معظم حوادث الإنتاج تعيش في مسارات الخطأ. معايير قبول مع مساري خطأ: (أ) بافتراض متبرع لديه تبرع شهري نشط بقيمة ⁦100⁩ ريال، عندما ينجح الخصم الشهري، عندئذ يُسجَّل خصم واحد فقط بقيمة ⁦100.00⁩ ريال، ويُرسل بريد إيصال واحد فيه المبلغ والتاريخ ورقم مرجعي، بلغة المتبرع. (ب) بافتراض المتبرع نفسه، عندما يرفض مزوّد الدفع الخصم، عندئذ لا يُرسل إيصال، ويُعلَّم التبرع بحالة «فشل الدفع»، ويُطلب من المتبرع تحديث البطاقة. (ج) بافتراض خصم نجح، عندما يتعذر إرسال بريد الإيصال، عندئذ لا تُخصم البطاقة مرة أخرى، ويُعاد إرسال البريد وحده. المعيار (ج) هو D-71 نفسه: لو كُتب قبل التطوير لكان سؤالاً في جلسة التحسين (Refinement)، لا عيباً حرجاً قبل الإطلاق بأسبوع. أما عدد مرات إعادة المحاولة، ومتى يُعلَّق التبرع، فقراران لريم؛ ومعاييرك تجعلها تتخذهما. وكل هذا مراجعة، أي اختبار ساكن (Static testing) بمصطلحات ISTQB، تُجرى على النص قبل أن يعمل أي كود.

الخطوة ⁦2⁩، خصائص الجودة. الملاءمة الوظيفية: مبالغ أو مواعيد خصم أو إيصالات خاطئة (R1 وR3)؛ اختبارات القيم الحدّية والاختبارات السلبية، معظمها على مستوى التكامل عبر الواجهة البرمجية، مع تغطية حساب موعد الخصم أيضاً في اختبارات الوحدة التي يكتبها المطورون. الموثوقية وكفاءة الأداء: خصم يفشل أو تنتهي مهلته أو يتكرر، وهو الخطر الذي أظهره D-71، وذروة الحملة بعد الإطلاق بثلاثة أسابيع؛ اختبارات لحالات الفشل على مستوى الواجهة البرمجية مع محاكاة (Mock) مزوّد الدفع وخدمة البريد لتعيدا رفضاً أو انتهاءً للمهلة أو فشلاً في الإرسال، واختبار حمل مقابل أهداف R2 على بيئة مهيأة مثل الإنتاج، وهو نشاط على مستوى النظام له موعده الخاص في الخطة. الأمان: البيانات الشخصية للمتبرعين ومدفوعاتهم؛ خط الأساس من OWASP على Staging بحسابَي متبرعَين اختباريين: هل يستطيع متبرع أن يرى التبرع الشهري لمتبرع آخر أو يلغيه بتغيير معرّف في طلب إلى الواجهة البرمجية (التحكم في الوصول)، وهل معالجة الجلسات وترويسات الأمان صحيحة؟ وذلك على مستويي الواجهة البرمجية والنظام. التوافق وقابلية الاستخدام: منتج عربي أولاً بتخطيط من اليمين إلى اليسار، وأسماء عربية في الإيصالات، وهواتف ومتصفحات رئيسية؛ اختبارات نظام وجلسة استكشافية في الواجهة العربية ببيانات اختبار عربية، وكانت ستجد D-74 وD-75 قبل العرض التجريبي. قابلية الصيانة: تغيير لاحق في منطق الخصم أو الإيصال يكسر التبرعات المتكررة دون أن يلاحظه أحد، بينما لا يُشغَّل فحص الانحدار الوحيد للواجهة البرمجية إلا يدوياً مرة في كل إصدار؛ مجموعة الواجهة البرمجية في CI بوصفها حزمة الانحدار، على مستوى التكامل (الواجهة البرمجية)، حتى يمكن إجراء التغيير التالي بأمان. وفوق ذلك كله اختبار القبول: تنفّذ ريم معايير القبول للمتطلبات ⁦R1–R3⁩ على Staging أو تشاهد تنفيذها، وعليه يقوم قرار الإصدار.

الخطوة ⁦3⁩، الممارسات مقابل قائمة التحقق. P1: معايير القبول تأتي بعد التطوير ولا تغطي إلا مسار النجاح؛ اكتبها قبل التطوير، بما فيها مسارات الخطأ، وراجعها مع ريم. P2: رتّب ميزات الإصدار حسب المخاطر، أي الاحتمال مضروباً في الأثر — الخصومات المتكررة والإيصالات أولاً — واجعل خطة الاختبار تتبع هذا الترتيب. P3: تشغيل اختبارات الوحدة عند كل إيداع ممارسة جيدة؛ والمشكلة في المقياس فقط (الخطوة ⁦4⁩). P4: مجموعة الواجهة البرمجية أفضل ما يملكه الفريق للانحدار، وهي تُشغَّل يدوياً مرة واحدة قبل الإصدار؛ ضعها في CI عند كل تغيير، مع تأكيدات (Assertions) على رموز الحالة وأجسام الأخطاء، واجعل نجاح تشغيلها شرطاً للإصدار. P5: إعادة تشغيل الاختبارات حتى تنجح تُفقد اللون الأخضر معناه؛ اعزل الاختبارات المتذبذبة الخمسة، وأصلحها أو احذفها، ولا تحتسب إلا النجاح من التشغيل الأول. P6: الاختبار الاستكشافي واختبار الأداء واختبار الأمان يحتاج كل منها إلى نشاط مجدول خاص به (الخطوة ⁦2⁩)؛ فلا شيء منها يحدث كأثر جانبي للاختبار الوظيفي. P7: بيانات اختبار لاتينية فقط لا تكشف العيوب العربية؛ أضف أسماء عربية بالتشكيل، وأسماء طويلة، ومدخلات تخلط العربية بالإنجليزية. P8 أخطرها: البيانات الشخصية لمتبرعين حقيقيين موجودة في بيئة مفتوحة لكل من يملك صلاحية الوصول إلى بيئة الاختبار، وهو ما يعدّه نظام حماية البيانات الشخصية السعودي معالجة تحتاج إلى أساس وضمانات؛ ومع عناوين بريد إلكتروني حقيقية على Staging، يمكن لأي اختبار لميزة الإيصال أن يرسل بريداً إلى متبرع حقيقي. أوقف النسخ الأسبوعي، واحذف البيانات المنسوخة، وولّد متبرعين اصطناعيين بالعربية والإنجليزية، واجعلهم مجموعة بيانات أساسية معروفة يمكن للحزمة إعادة الضبط إليها. ولاحظ أن D-74 لم يظهر إلا عبر حساب ريم الحقيقي المنسوخ من الإنتاج، لأنه لا يوجد حساب اختبار باسم عربي؛ والبيانات العربية الاصطناعية تكشف العيب نفسه دون بيانات شخصية لأحد. P9: حاكِ مزوّد الدفع عند حدوده حتى يستطيع الاختبار أن يختار رفضاً أو انتهاءً للمهلة أو رداً متأخراً، واحتفظ ببضع تشغيلات على Sandbox للتكامل الحقيقي. P10: امنح كل عيب أولوية إلى جانب الخطورة، واكتب معايير الدخول والخروج (الخطوة ⁦5⁩).

الخطوة ⁦4⁩، الأرقام. معدل تسرّب العيوب في الإصدار ⁦1.9⁩: ⁦6 ÷ (18 + 6) = 6 ÷ 24 = 25%⁩، أي أن عيباً من كل أربعة عيوب عُرفت بعد ⁦30⁩ يوماً من الإصدار لم يُكتشف إلا في الإنتاج؛ ونسبة اكتشاف العيوب (DDP)، وهي مكمّلته، ⁦75%⁩. وبعض الفرق تعبّر عن معدل التسرّب بنسبة بين عددين بدلاً من ذلك: ⁦6⁩ عيوب في الإنتاج مقابل ⁦18⁩ اكتُشفت قبل الإصدار (عيب تسرّب مقابل كل ثلاثة اكتُشفت)؛ وكلتا الصيغتين صالحة ما دام التقرير يذكر أيهما يستخدم ويثبت عليها من إصدار إلى إصدار. تغطية المتطلبات في الإصدار ⁦2.0⁩: لـ ⁦14⁩ معياراً من معايير القبول الـ ⁦20⁩ اختبار ناجح، أي ⁦70%⁩. ولـ ⁦16⁩ معياراً من ⁦20⁩ (⁦80%⁩) اختبار من نوع ما، لكن المعيار الذي يفشل اختباره ليس مغطى بعد، و⁦4⁩ معايير لم تُختبر أصلاً. أما «تغطية الأسطر ⁦72%⁩» فتقول أي الأسطر نفّذتها اختبارات الوحدة، لا ما إذا كان أي متطلب يعمل: ويسمّيها الدليل مقياساً للمطورين لا مقياساً للجودة. اتركها للمطورين، واعرض بدلاً منها ثلاثة أرقام مع كل إصدار: معدل التسرّب، وتغطية المتطلبات، وصحة حزمة الانحدار — وهي اليوم تشغيل لواجهة المستخدم مدته ⁦45⁩ دقيقة فيه ⁦5⁩ اختبارات متذبذبة من ⁦38⁩ (نحو ⁦13%⁩)، ومجموعة للواجهة البرمجية ليست في CI أصلاً.

الخطوة ⁦5⁩، معايير الخروج والإجابة. معايير الخروج للإصدار ⁦2.0⁩، مكتوبة ومتفق عليها مع ريم: نُفّذت كل الاختبارات المخططة؛ لكل معيار قبول اختبار ناجح؛ لا عيب حاجباً (Blocker) أو حرجاً (Critical) مفتوحاً؛ حزمتا الانحدار للواجهة البرمجية ولواجهة المستخدم خضراوان من التشغيل الأول؛ أهداف الأداء في R2 متحققة على البيئة المهيأة مثل الإنتاج؛ وأي عيب رئيسي (Major) مفتوح قبلته ريم كتابةً وله حل بديل. وعند تطبيقها على rc1 لا يتحقق أي منها: لم تُشغَّل مجموعة الواجهة البرمجية على rc1، و⁦4⁩ معايير بلا اختبار؛ ومعياران يفشلان؛ وD-71 عيب حرج مفتوح؛ وحزمة واجهة المستخدم لم تنجح إلا في تشغيلها الثالث؛ وليس للأداء هدف ولا قياس؛ وD-74 عيب رئيسي مفتوح بلا قبول ولا حل بديل. لذلك فالتوصية لـ rc1: لا إطلاق. أجب ريم كتابةً: «ليس بـ rc1. ما زال الإطلاق في ⁦1⁩ نوفمبر ممكناً إذا أُصلح D-71 وD-74 حتى الخميس ⁦29⁩ أكتوبر واجتازا اختبار التأكيد (Confirmation testing)، واجتاز مرشح جديد للإصدار مجموعة الواجهة البرمجية وحزمة واجهة المستخدم من التشغيل الأول، وصار للمعايير الستة المفتوحة اختبارات ناجحة، وحقق اختبار حمل أهداف R2 التي توافقين عليها. ويمكن أن يُطلق D-75 بوصفه مشكلة معروفة». ويقع D-74 في قائمة ما يجب إصلاحه رغم أنه رئيسي: ففي منتج عربي أولاً سيحمل معظم الإيصالات اسماً لا يستطيع أحد قراءته. وللمرشح التالي أضف معايير دخول: البناء ينشر على Staging، واختبار الدخان يجتاز، ولكل قصة فيه معايير قبول. ويبقى قرار الإصدار لريم؛ ودورك أن تجعل الخطر ظاهراً ومكتوباً. وإن تعذّر تحقيق الشروط في الوقت، فإطلاق لاحق يسبق الحملة أقل كلفة من خصم مزدوج أثناءها.

الخطوة ⁦5⁩، التغييرات الثلاثة التي تبدأ بها، مرتبةً. أولاً P8، بيانات اصطناعية بدلاً من نسخ الإنتاج: فهي انكشاف قانوني ومخاطرة بالخصوصية في كل أسبوع تستمر فيه، أياً كان مصير الإصدار. ثانياً P4، مجموعة الواجهة البرمجية في CI عند كل تغيير وضمن معايير الخروج: إحدى نقطتي البداية اللتين يقترحهما الدليل على الفريق الصغير، وهي المستوى الذي يمكن فيه اختبار سيناريو D-71 — فشل البريد بعد خصم ناجح — بمحاكاة خدمة البريد. ثالثاً P1، معايير قبول بمسارات الخطأ قبل التطوير: نقطة البداية الأخرى في الدليل، وR3 يُظهر كلفة تأخيرها. وتليها مباشرة أهداف الأداء والأمان (P6) قبل الحملة، ثم جلسة استكشافية لكل ميزة جديدة حين تستقر هذه الثلاثة. ترتيب آخر مقبول إن دافعت عنه بالمخاطر؛ أما تأجيل P8 فغير مقبول.

كيف تتحقق من عملك. ينبغي أن تحتوي إجابتك على: سؤال واحد على الأقل لكل متطلب، وأرقام في R2؛ ومعيار لمسار خطأ في R3 يطابق D-71؛ ومستوى اختبار لكل نشاط في الخطوة ⁦2⁩؛ وتسمية P8 مشكلةً في البيانات الشخصية لا مسألة راحة؛ و⁦25%⁩ (أو النسبة ⁦6⁩ إلى ⁦18⁩ مع التصريح بأنها نسبة بين عددين) و⁦70%⁩ مع المعادلتين اللتين أنتجتاهما؛ وتوصية بعدم إطلاق rc1 مع الشروط التي تحوّلها إلى إطلاق. واختلاف أرقام المثال في R2، أو التغيير الأول، أو إضافة معايير خروج أخرى، كل ذلك مقبول إن كُتب السبب.