ثقافة الجودة
ثقافة الجودة (Quality Culture) هي مجموعة العادات والتوقعات المشتركة التي تحدد كيف يتعامل الفريق مع الجودة في عمله اليومي: من يشعر بأنه مسؤول عنها، ومتى تُطرح المشكلات، وماذا يحدث بعد أن يسوء أمر ما. وفي ثقافة الجودة القوية تكون الجودة مسؤولية الفريق كله، ويُعامَل كل إخفاق على أنه معلومة يُتعلَّم منها لا سبباً للوم أحد.
مثلاً، تبلّغ مختبِرة أن مسار الدفع الجديد لم يُجرَّب قط على شبكة بطيئة. فيرد فريق «لا وقت لدينا، أطلقوه»، فلا يصل الخطر إلى قرار الإصدار أبداً؛ ويسأل فريق آخر عمّا قد يسوء ويتفق على فحص مدته ساعة واحدة. المهارات واحدة، لكن الثقافة هي التي تقرر هل تُستخدم المعلومة أم لا.
لماذا يهم
ينتج الاختبار معلومات، والمعلومات لا تقلل المخاطر إلا إذا تصرّف الناس بناءً عليها. وحيث تكون الأخبار السيئة غير مرحَّب بها وتُحسب العيوب على الأشخاص، تميل المشكلات إلى البقاء مخفية حتى يجدها العملاء، وكلما تأخر اكتشاف العيب زادت كلفته من إعادة العمل والحوادث والثقة المفقودة.
وبالنسبة إلى المختبِر، تشكّل الثقافة طبيعة العمل نفسه. فحيث تكون الجودة «مهمة فريق ضمان الجودة»، يصبح المختبِر حارس بوابة في نهاية السبرنت، يضيق عليه الوقت ويُلام على كل عيب يفلت إلى المستخدمين. وحيث يتولى الفريق كله مسؤولية الجودة، يبدأ المختبِر من جلسات التحسين (Refinement)، ويساعد على منع العيوب لا على اكتشافها فقط.
نهج الفريق الكامل
قدّم درس أدوار الاختبار ومسؤولياته نهج الفريق الكامل (Whole-team approach) كما يصفه منهج ISTQB للمستوى التأسيسي (الإصدار 4.0). ويشرح المنهج أيضاً سبب نجاح هذا النهج: فأعضاء الفريق يتشاركون مساحة عمل واحدة، فعلية أو افتراضية، مما يسهّل التواصل؛ والنهج يحسّن ديناميكية الفريق والتواصل والتعاون بين أفراده، ويتيح للفريق توظيف مهاراته المختلفة كلها لمصلحة المشروع.
وبالعمل عن قرب مع ممثلي الأعمال والمطورين، ينقل المختبِرون معرفة الاختبار إلى بقية الفريق، ويؤثرون في طريقة بناء المنتج.
وهكذا تتوزع أعمال الجودة على الأدوار وعلى دورة الحياة كلها:
- قبل التطوير: يتفق مالك المنتج (Product Owner) ومطوّر ومختبِر على أمثلة ومعايير قبول لكل قصة، وتسمي بعض الفرق ذلك جلسة «الأصدقاء الثلاثة» (Three Amigos).
- عند التخطيط: يقيّم الفريق مخاطر المنتج معاً ويتفق على عمق اختبار كل خطر.
- بعد الإصدار: يشارك فريقا الدعم والتشغيل الحوادث وشكاوى العملاء، فتصبح أفكار اختبار جديدة.
جرّبها: مولّد معايير القبول جرّبها: مولّد الاختبار المبني على المخاطر
الأمان النفسي ومراجعات ما بعد الحادثة دون لوم
لا يستطيع الفريق تقاسم المسؤولية عن الجودة إلا إذا شعر أفراده بأنهم قادرون على طرح المشكلات. وتسمي الباحثة إيمي إدموندسون (Amy Edmondson) ذلك الأمان النفسي (Psychological Safety): اعتقاد مشترك بين أعضاء الفريق بأن الفريق مكان آمن لخوض المخاطر في التعامل مع الآخرين، مثل طرح سؤال بسيط أو الاعتراف بخطأ أو مخالفة رأي من هو أعلى منصباً. ويحتاج إليه المختبِرون لأن الاختبار ينتج الأخبار السيئة بطبيعته، ويساعدون على بنائه حين ينقلون الحقائق لا الأحكام.
ويُمتحن هذا الأمان أشد امتحان حين يصل إخفاق مهم إلى المستخدمين. فعندها تكتب فرق كثيرة مراجعة ما بعد الحادثة (Postmortem)، ويصفها كتاب هندسة موثوقية المواقع (Site Reliability Engineering) من Google بأنها سجل مكتوب للحادثة وأثرها، والإجراءات التي اتُّخذت لاحتوائها أو حلها، وأسبابها الجذرية، وإجراءات المتابعة التي تمنع تكرارها. والمراجعة دون لوم (Blameless) تفترض أن كل من شارك تصرّف بحسن نية وفق المعلومات التي كانت لديه، وتبحث عن الأسباب المساهمة في الأنظمة والعمليات، لا عن شخص تعاقبه. ويساعد المختبِر عادةً في ثلاثة أجزاء:
- التسلسل الزمني: متى بدأ الإخفاق، وكيف ومتى اكتُشف، ومتى حُلّ.
- الأسباب: تتبّع السلسلة من الخطأ (Error) إلى العيب (Defect) إلى الإخفاق (Failure)، واسأل لماذا كان الخطأ ممكناً ولماذا لم يُكتشف العيب مبكراً.
- الإجراءات: تغييرات محددة، لكل منها مالك وموعد استحقاق، تُتابَع حتى تكتمل.
علامات ثقافة الجودة السليمة
تظهر الثقافة في الممارسة اليومية. فقد صنّف عالم الاجتماع رون ويستروم (Ron Westrum) المؤسسات بحسب طريقة تعاملها مع المعلومات: في الثقافة المرَضية (Pathological) يُعاقَب حامل الخبر ويؤدي الإخفاق إلى البحث عن كبش فداء، وفي الثقافة البيروقراطية (Bureaucratic) يُهمَل حامل الخبر، وفي الثقافة التوليدية (Generative) يُدرَّب حامل الخبر ويؤدي الإخفاق إلى التقصّي. وتستخدم أبحاث DORA في تسليم البرمجيات هذا النموذج. والمختبِر كثيراً ما يكون حامل الخبر، فابحث عن هذه العلامات:
- يشارك المختبِرون في جلسات التحسين، وتُراجَع معايير القبول قبل بدء التطوير.
- تعريف إنجاز (Definition of Done) مشترك يشمل الاختبار، ولا يُسقَط الاختبار منه حين يضيق الوقت. ويعرّفه دليل سكرم (Scrum Guide) لعام 2020 بأنه وصف رسمي لحالة الزيادة (Increment) حين تستوفي مقاييس الجودة المطلوبة للمنتج.
- يُتقصّى سبب البناء أو الاختبار الفاشل أولاً، ولا يُتجاهَل أو يُعاد تشغيله حتى ينجح.
- تُستخدم المقاييس للتعلّم لا لترتيب الأشخاص: لا أهداف لأعداد العيوب، ولا عدّ للعيوب لكل مطوّر.
- تنتهي المراجعات الاستعادية (Retrospectives) بإجراءات تُنفَّذ فعلاً، لا بالشكاوى نفسها في كل سبرنت. ففي سكرم، الغرض من المراجعة الاستعادية للسبرنت هو التخطيط لطرق تزيد الجودة والفاعلية.
ثقافة جودة ضعيفةويستروم: مرَضية أو بيروقراطية
الجودة مهمة المختبِرين
- متى ينضم المختبِرون:
- بعد التطوير، لفحص نسخة البناء
- الأخبار السيئة:
- حامل الخبر يُعاقَب أو يُهمَل، والمخاطر غير المختبَرة لا يُبلَّغ عنها
- بعد عيب أفلت:
- من الذي فاته؟ ومزيد من التواقيع
- السبب الجذري:
- شخص، أو «خطأ بشري»
- تعريف الإنجاز:
- يُسقَط الاختبار منه حين يضيق الوقت
- بناء أو اختبار فاشل:
- يُتجاهَل، أو يُعاد تشغيله حتى ينجح
- المقاييس:
- لترتيب الأشخاص: أهداف لعدد العيوب، وعيوب لكل مطوّر
- المراجعات الاستعادية:
- الشكاوى نفسها في كل سبرنت
ثقافة جودة قويةويستروم: توليدية
الجودة مهمة الفريق كله
- متى ينضم المختبِرون:
- في جلسات التحسين، قبل كتابة الشيفرة
- الأخبار السيئة:
- حامل الخبر يُدرَّب، والمخاطر تصل إلى قرار الإصدار
- بعد عيب أفلت:
- مراجعة دون لوم بإجراءات لها مالك وموعد
- السبب الجذري:
- لماذا كان الخطأ ممكناً ولماذا لم يُكتشف مبكراً
- تعريف الإنجاز:
- مشترك ويشمل الاختبار
- بناء أو اختبار فاشل:
- يُتقصّى سببه أولاً
- المقاييس:
- تُستخدم للتعلّم
- المراجعات الاستعادية:
- إجراءات تُنفَّذ فعلاً
هذه علامات لا درجات: تُظهر معظم الفرق شيئاً من كل عمود.
مثال تطبيقي: عيب واحد أفلت وثقافتان
بعد أحد الإصدارات، لا يستطيع العملاء الذين يستخدمون الواجهة العربية إتمام الدفع: ففي التخطيط من اليمين إلى اليسار يُدفع زر «ادفع الآن» خارج الشاشة على الهواتف الصغيرة. يبلّغ فريق الدعم عن المشكلة بعد ساعتين، فيعيد الفريق النسخة السابقة (Rollback).
في الفريق «أ» يسأل المدير في مجموعة المحادثة: من اختبر هذا؟ ثم تصدر قاعدة جديدة: «يوقّع فريق ضمان الجودة على كل إصدار». لا يتغير شيء آخر، وفي السبرنت التالي يطرح الناس شكوكاً أقل، لأن الشكوك صارت تجلب اللوم.
أما الفريق «ب» فيعقد مراجعة ما بعد الحادثة دون لوم. ويُظهر التسلسل الزمني أن العملاء، لا الفريق، هم من اكتشفوا الإخفاق. ولكل سبب مساهم إجراء، وللمختبِر إجراء أيضاً:
- غطّت التصاميم ومعايير القبول الواجهة الإنجليزية فقط. الإجراء: إضافة التخطيط من اليمين إلى اليسار إلى قائمة فحص جلسة التحسين (مالك المنتج والمختبِر).
- دُمجت القصة بعد ظهر اليوم الأخير من السبرنت. الإجراء: الحدّ من العمل قيد التنفيذ (Work in Progress) حتى تكتمل القصص في وقت أبكر (الفريق كله).
- لم يغطِّ أي فحص انحدار التخطيطَ من اليمين إلى اليسار على الشاشات الصغيرة. الإجراء: إضافة فحص لذلك (المختبِر والمطور).
- لم يصدر أي تنبيه حين انخفضت عمليات الدفع المكتملة في لغة واحدة. الإجراء: إضافة مراقبة (فريق التشغيل).
أخطاء شائعة
- استخدام أعداد العيوب لتقييم الأشخاص، مثل عدد الأخطاء التي يجدها كل مختبِر أو عدد العيوب لكل مطوّر: فيبدأ الناس بالجدال حول الأرقام أو بإخفاء المشكلات بدلاً من إصلاح أسبابها.
- الرد على عيب أفلت بسؤال «من اختبر هذا؟»: فيطرح الناس شكوكاً أقل ويخفون أخطاءهم، فتظهر المشكلة التالية في وقت أكثر تأخراً.
- فهم «دون لوم» على أنها «دون متابعة»: مراجعة بلا إجراءات لها مالك وموعد لا تغيّر شيئاً.
- تسمية شخص، أو «خطأ بشري»، سبباً جذرياً. فهنا تبدأ الأسئلة ولا تنتهي.
- السكوت عن خطر لم يُختبر تجنباً للخلاف، فيُتخذ قرار الإصدار من دونه.
من منظور ضمان الجودة
تتغير الثقافة بممارسات صغيرة متكررة لا بالإعلانات. اسأل عن المخاطر والأمثلة في جلسات التحسين، وأبلغ عن العيوب بوصفها حقائق عن المنتج، وحين يفلت عيب، ساعد في بناء التسلسل الزمني لمراجعة ما بعد الحادثة، واقترح إجراءً واحداً على الأقل يخص الاختبار نفسه، مثل فحص انحدار كان مفقوداً.
سجّل المخاطر التي طرحتها وما تقرر بشأنها، وما لم يُختبر ولماذا، وحالة إجراءات المتابعة. وفي مقابلات العمل اطرح أسئلة تكشف الثقافة: «ما الذي تغيّر بعد آخر مراجعة ما بعد حادثة لديكم؟» و«ماذا يحدث حين يقول المختبِر إن الإصدار غير جاهز؟».
تمرين عملي
أعد كتابة ملاحظة حادثة بصيغة دون لوم
نُشرت ملاحظة الحادثة أدناه في محادثة الفريق بعد إصدار فاشل. أعد كتابتها مراجعةً قصيرة لما بعد الحادثة دون لوم: الملخص، والأثر، والتسلسل الزمني، والأسباب المساهمة، وإجراءات المتابعة مع دور المالك. ثم سمِّ علامتين على ثقافة جودة ضعيفة في الملاحظة، وسؤالاً واحداً تطرحه في المراجعة الاستعادية. ويمكنك كتابتها بصيغة Markdown ومعاينتها بأداة «منسّق Markdown».
ملاحظة حادثة، نُشرت في محادثة الفريق يوم الاثنين
دمج عمر تعديل القسائم الساعة 17:40 يوم الخميس دون إبلاغ فريق ضمان الجودة.
اختبرته لينا 20 دقيقة وفاتها أن القسائم المنتهية ما زالت تعمل.
استخدم العملاء قسائم منتهية طوال عطلة نهاية الأسبوع، واكتشفت المالية ذلك يوم الاثنين.
فاتت فريقَ ضمان الجودة أشياء من قبل. من الآن يوقّع فريق ضمان الجودة على كل إصدار،
ويحتاج عمر إلى موافقة المدير على كل تعديل.- احذف الأسماء والأحكام، واحتفظ بما حدث، ومتى، ولمن.
- اسأل عن كل حقيقة: لماذا كان الخطأ ممكناً، ولماذا لم يُكتشف مبكراً؟
- حوّل كل سبب إلى إجراء واحد مع دور المالك.
إظهار الإجابة النموذجية
الملخص: تعديل على قواعد القسائم، دُمج الساعة 17:40 يوم الخميس وصدر قبل عطلة نهاية الأسبوع، فقَبِل القسائم المنتهية. واكتشفت مراجعة مالية المشكلة يوم الاثنين.
الأثر: حصلت طلبات عطلة نهاية الأسبوع على خصومات لم تقصدها الشركة. واكتُشفت المشكلة في مراجعة مالية، لا بالاختبارات ولا بالمراقبة.
التسلسل الزمني: الخميس 17:40 دُمج التعديل؛ ثم نحو 20 دقيقة من الاختبار وصدر التعديل؛ وطوال عطلة نهاية الأسبوع قبلت الطلبات قسائم منتهية؛ ويوم الاثنين اكتشفت المالية المشكلة. وخذ وقتَي الإصدار والإصلاح بدقة من سجل النشر.
الأسباب المساهمة (تُؤكَّد أثناء المراجعة): دمج متأخر بلا وقت متفق عليه للاختبار؛ ومعايير قبول لا تذكر القسائم المنتهية؛ وحزمة انحدار بلا فحص لانتهاء الصلاحية؛ ولا مراقبة لصلاحية القسائم في الطلبات.
الإجراءات: إضافة قواعد انتهاء القسائم إلى معايير القبول (مالك المنتج والمختبِر)؛ والاتفاق على موعد نهائي للدمج قبل كل إصدار (الفريق)؛ وإضافة حالات القسيمة المنتهية، والقسيمة التي لم يبدأ سريانها، والقسيمة الصالحة إلى حزمة الانحدار (المختبِر والمطور)؛ وتنبيه عند كل طلب بقسيمة منتهية (فريق التشغيل).
علامات الثقافة: تسمية أشخاص ولومهم على إخفاق في النظام، وعلاج المشكلة بمزيد من حراسة البوابات بدلاً من التعاون المبكر. سؤال للمراجعة الاستعادية: «ما الذي كان سيساعد أياً منا على اكتشاف هذا قبل العملاء؟»
أسئلة شائعة
كيف يعرف الفريق هل تتحسن ثقافة الجودة لديه؟
انظر إلى السلوك والاتجاهات، لا إلى رقم واحد. ومن العلامات المفيدة: عدد العيوب التي تصل إلى المستخدمين ومن اكتشفها، الفريق أم العملاء؛ والمدة التي يبقى فيها البناء الفاشل دون إصلاح؛ وعدد إجراءات مراجعات ما بعد الحادثة والمراجعات الاستعادية التي تُنفَّذ فعلاً. وتجنّب المقاييس التي ترتّب الأشخاص، مثل أهداف أعداد الأخطاء أو عدد العيوب لكل مطوّر: فهي تكافئ إخفاء المشكلات والجدال حول الأرقام بدلاً من إصلاح الأسباب.
هل مراجعة ما بعد الحادثة هي نفسها المراجعة الاستعادية؟
لا. مراجعة ما بعد الحادثة تحلل حادثة واحدة بعينها، عادةً بعد وقوعها بقليل، وتنتج سجلاً مكتوباً يتضمن إجراءات. أما المراجعة الاستعادية فاجتماع منتظم عن طريقة عمل الفريق خلال فترة، مثل السبرنت. وكثيراً ما تُتابَع إجراءات مراجعة ما بعد الحادثة في المراجعات الاستعادية.
ماذا أفعل إذا كان فريقي يلوم الأشخاص على العيوب؟
ابدأ بسلوكك: انقل الحقائق لا المذنبين، وصِف الأسباب بلغة العمليات والأنظمة. واقترح صيغة دون لوم لمراجعة الحادثة التالية، بتسلسل زمني وإجراءات لها مالكون، واسأل في المراجعة الاستعادية عمّا كان سيساعد أي شخص على اكتشاف المشكلة مبكراً. التغيير تدريجي، ومراجعة واحدة أُديرت جيداً كثيراً ما تقنع أكثر من الجدال.
هل يعني الأمان النفسي ألا يُنتقد أحد؟
لا. يعني أن الناس يستطيعون طرح المشكلات والأسئلة والاعتراف بالأخطاء دون إهانة أو عقاب. ويبقى العمل خاضعاً للمراجعة النقدية وتبقى المعايير عالية؛ لكن النقد يوجَّه إلى العمل والعملية لا إلى الشخص.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)مراجعات ما بعد الحوادث الخالية من اللوم: أيّ الحوادث تستدعيها، وما الذي تسجّله — الأثر والأسباب الجذرية وإجراءات المتابعة — ولماذا يُستبعد منها اللوم.
- The 2020 Scrum Guideتعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
تدرّب بأدوات متقن
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
قيّم الميزات حسب الاحتمالية والأثر، ثم ولّد خطة اختبار مبنية على المخاطر ومرتّبة حسب الأولوية.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
توحيد تنسيق Markdown (العناوين والقوائم والجداول والتأكيد) ومعاينة النتيجة المعروضة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.