التحسين المستمر

التحسين المستمر (Continuous Improvement) يعني أن يغيّر الفريق طريقة عمله بخطوات صغيرة ومنتظمة، ويتحقق من كل خطوة بالأدلة، بدلاً من انتظار إعادة تنظيم كبيرة. وفي الاختبار يشمل ذلك عملية الاختبار كلها: كيف يصل العمل إلى الاختبار، وكيف تُصمَّم الاختبارات وتُنفَّذ، وكيف يتعلم الفريق من العيوب التي أفلتت.

مثال ذلك: يكشف الاجتماع الاستعادي (Retrospective) أن قصصاً كثيرة يُعاد فتحها بعد الاختبار. فبدلاً من إضافة خطوة موافقة يمرّ بها الجميع، يجرّب الفريق تغييراً واحداً لمدة سبرنتين، ويعدّ القصص المعاد فتحها قبل التغيير وبعده، ثم يقرر هل يُبقي عليه. هذه الحلقة، خطّط ونفّذ وافحص وتصرّف، هي جوهر هذا الدرس.

لماذا يهم

تتكرر مشكلات العملية بصمت: الاختبار المتأخر نفسه، والبيئة غير المستقرة نفسها، والنوع نفسه من العيوب المتسربة، سبرنتاً بعد سبرنت. وكل تكرار يكلّف إعادة عمل وتأخيراً، ويعتاد الفريق عليه. ويصف منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) الاجتماعات الاستعادية بأنها حاسمة للتحسين المستمر، ويؤكد أهمية متابعة التحسينات المقترحة فيها. ومن دون هذه المتابعة تعود الشكاوى نفسها ويتوقف الناس عن طرح المشكلات.

يرى المختبِر أين ينتظر العمل، ومن أين تأتي العيوب، وأيّ الفحوص مفقودة، ويملك كثيراً من البيانات التي تُثبت ذلك. وتحويل هذه الرؤية إلى تغييرات صغيرة يُقاس أثرها يجعل الاختبار أسرع وأكثر فاعلية، ويُري الفريق أن طرح المشكلة يؤدي إلى نتيجة.

اجتماعات استعادية تقود إلى التغيير

عرّفك درسا Scrum وثقافة الجودة بالاجتماع الاستعادي. ويضيف منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) التفاصيل: يُعقد غالباً في نهاية التكرار أو المشروع، أو عند محطة إصدار رئيسية (Release milestone)، أو عند الحاجة؛ ويشارك فيه المطورون ومالك المنتج وغيرهم، لا المختبِرون وحدهم؛ ويسأل: ما الذي نجح ويجب الإبقاء عليه؟ وما الذي يمكن تحسينه؟ وكيف نضع التحسينات موضع التنفيذ؟ وتُسجَّل نتائجه، وعادةً ما تكون جزءاً من تقرير إتمام الاختبار.

وكثيراً ما تتعثر الاجتماعات الاستعادية في الأدلة وفي المتابعة، والمختبِر يساعد في الاثنين:

  • أحضر حقائق لا انطباعات: القصص المعاد فتحها، وأيام الانتظار قبل الاختبار، وتعطّل بيئة الاختبار، والعيوب المتسربة.
  • اسأل «لماذا؟» حتى تصل إلى سبب يستطيع الفريق تغييره؛ فعبارة «الاختبار متأخر دائماً» عَرَض لا سبب.
  • اخرج بإجراء أو إجراءين، لكلٍّ منهما مسؤول وموعد، وابدأ الاجتماع التالي بمراجعتهما.
  • احتفظ بقائمة تحسينات واحدة (Improvement backlog) لإجراءات الاجتماعات الاستعادية، وإجراءات مراجعات ما بعد الحادثة (Postmortem)، والدروس المستفادة عند إتمام الاختبار.

مقاييس العملية: أدلة قبل التغيير وبعده

مقياس العملية (Process measure) يصف كيف يجري العمل، مثل الانتظار وإعادة العمل وسرعة التغذية الراجعة، لا جودة المنتج نفسه. ابدأ بالهدف وبالسؤال الذي يُظهر التقدم، ثم اختر المقياس؛ وهذه هي فكرة نهج الهدف والسؤال والمقياس (Goal-Question-Metric).

سجّل خط الأساس (Baseline) على مدى عدة سبرنتات قبل أي تغيير، لأن الأعداد الصغيرة تتذبذب، وأبقِ تعريف المقياس كما هو بعد التغيير. وفضّل مقياساً استباقياً (Leading) يتحرك خلال أسابيع على مقياس متأخر (Lagging) مثل عدد الحوادث في الربع، وأضف مقياساً موازناً (Balancing measure) يكشف أي أثر جانبي. وقِس عملية الفريق لا الأفراد: فكما بيّن درس مقاييس الجودة ومؤشرات الأداء الرئيسية، المقياس الذي يصبح هدفاً شخصياً يفقد قدرته على القياس.

  • الانتظار: الأيام من «جاهز للاختبار» حتى بدء الاختبار، وساعات عدم توفر بيئة الاختبار.
  • إعادة العمل: نسبة القصص المعاد فتحها بعد الاختبار.
  • التغذية الراجعة: الوقت من إيداع الشيفرة (Commit) حتى نتيجة الاختبار، وحالات فشل خط التسليم (Pipeline) التي سببتها اختبارات متذبذبة.
  • المتابعة: إجراءات الاجتماعات الاستعادية المنجزة في موعدها المتفق عليه.

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

تجارب صغيرة: خطّط، نفّذ، افحص، تصرّف

معظم تغييرات العملية تخمينات، لذا نفّذ كلاً منها تجربةً صغيرة بدورة خطّط ونفّذ وافحص وتصرّف (Plan-Do-Check-Act أو PDCA)، المرتبطة باسمي والتر شوهارت (Walter Shewhart) وإدوارد ديمنغ (W. Edwards Deming). اكتب التجربة قبل أن تبدأ حتى لا تُفسَّر النتيجة لاحقاً على غير ما اتُّفق عليه، وغيّر شيئاً واحداً في كل مرة.

  • خطّط (Plan): المشكلة ودليلها، وفرضية («إذا فعلنا…، فسيحدث…، لأن…»)، وتغيير واحد، والمقياس وخط أساسه، ومقياس موازن، ومدة محددة (Timebox)، وقاعدة قرار.
  • نفّذ (Do): طبّق أصغر نسخة من التغيير، على بضع قصص أو فريق واحد، طوال المدة المحددة.
  • افحص (Check): قارن النتيجة بخط الأساس وبقاعدة القرار، وابحث عن الآثار الجانبية.
  • تصرّف (Act): اعتمد التغيير واجعله معياراً، مثلاً في تعريف الإنجاز (Definition of Done) أو في قائمة تحقق؛ أو عدّله وابدأ دورة أخرى؛ أو تخلَّ عنه وسجّل ما تعلمته.

مثال تطبيقي: قصص أقل يُعاد فتحها بعد الاختبار

يراجع فريق يبني تطبيق ويب لحجز مواعيد العيادات السبرنتات من ⁦10⁩ إلى ⁦12⁩: أُعيد فتح ⁦9⁩ من ⁦24⁩ قصة منجزة (⁦37.5%⁩) بعد الاختبار. صنّف المختبِر الأسباب، فكانت ⁦6⁩ من الـ⁦9⁩ بسبب قواعد عمل لم يناقشها أحد، مثل حجز موعدين في الوقت نفسه.

التخطيط: إذا اتفق مالك المنتج ومطوّر والمختبِر على أمثلة لكل قصة قبل التطوير، فسيقل عدد القصص المعاد فتحها، لأن القواعد تُحسم قبل البرمجة. التغيير: جلسة أمثلة مدتها ⁦20⁩ دقيقة لكل قصة طوال سبرنتين. المقياس: القصص المعاد فتحها (خط الأساس ⁦37.5%⁩)؛ والمقياس الموازن: القصص المنجزة في السبرنت (خط الأساس ⁦8⁩). القاعدة: اعتمد التغيير إذا لم يُعَد فتح أكثر من ⁦3⁩ قصص في السبرنتين، وأُنجزت ⁦7⁩ قصص على الأقل في كل سبرنت.

  • التنفيذ: يعقد الفريق الجلسات لـ⁦16⁩ قصة، ويسجّل المختبِر أسباب إعادة الفتح بالتصنيفات نفسها المستخدمة من قبل.
  • الفحص: أُعيد فتح ⁦3⁩ من ⁦16⁩ قصة (⁦18.75%⁩)، واحدة فقط منها بسبب قاعدة لم تُناقش، وأُنجزت ⁦8⁩ قصص في كل سبرنت، فتحققت قاعدة القرار. وست عشرة قصة عيّنة صغيرة، لكن الأسباب تغيّرت كما توقعت الفرضية.
  • التصرف: يعتمد الفريق الجلسة، ويضيف «أمثلة متفق عليها» إلى تعريف الجاهزية (Definition of Ready)، ويواصل العدّ، ويأخذ المشكلة التالية من قائمة التحسينات.
دورة واحدة من خطّط ونفّذ وافحص وتصرّف في المثال التطبيقي: بعد الاتفاق على الأمثلة قبل التطوير انخفضت القصص المعاد فتحها من ⁦9⁩ من ⁦24⁩ إلى ⁦3⁩ من ⁦16⁩، فاعتمد الفريق التغيير.
  1. 1خطّطفرضية ومقياس وخط أساس وقاعدة قرارالاتفاق على الأمثلة قبل التطوير؛ خط الأساس ⁦9⁩ من ⁦24⁩ أُعيد فتحها (⁦37.5%⁩)
  2. 2نفّذأصغر نسخة، لمدة محددةجلسة أمثلة مدتها ⁦20⁩ دقيقة لكلٍّ من ⁦16⁩ قصة خلال سبرنتين
  3. 3افحصالمقارنة بخط الأساس وبالقاعدةأُعيد فتح ⁦3⁩ من ⁦16⁩ (⁦18.75%⁩)؛ و⁦8⁩ قصص منجزة في كل سبرنتتحققت القاعدة
  4. 4تصرّفاعتمد أو عدّل أو تخلَّالاعتماد: تنضم «أمثلة متفق عليها» إلى تعريف الجاهزية

عودة إلى الخطوة 1 الدورة التالية: المشكلة التالية من قائمة التحسينات

ست عشرة قصة عيّنة صغيرة: يواصل الفريق العدّ بعد اعتماد التغيير.

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

نماذج تحسين عملية الاختبار

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

  • نماذج مرجعية للعملية تقيس النضج: TMMi (Test Maturity Model integration) نموذج متدرّج بخمسة مستويات نضج، من Initial إلى Optimization؛ وTPI NEXT يقيّم كل مجال رئيسي (Key area) من عملية الاختبار على حدة.
  • نماذج مرجعية للمحتوى، مثل Critical Testing Processes (CTP) وSystematic Test and Evaluation Process (STEP)، تصف الممارسات الجيدة لأنشطة الاختبار الرئيسية دون سلّم نضج.
  • المناهج التحليلية تبدأ من بياناتك أنت، مثل تحليل أسباب العيوب أو نهج الهدف والسؤال والمقياس.

أخطاء شائعة

  • إنهاء الاجتماع الاستعادي بعشرة إجراءات بلا مسؤولين ولا مواعيد، ثم عدم مراجعتها أبداً.
  • تغيير عدة أشياء في وقت واحد، فلا يعرف أحد أيّ تغيير أفاد.
  • غياب خط الأساس، أو تغيير طريقة حساب المقياس في منتصف التجربة.
  • إعلان النجاح بعد سبرنت واحد، مع أن الأعداد الصغيرة تتذبذب.
  • تحويل مقياس العملية إلى هدف للأفراد، مثل عدد العيوب التي يجدها كل مختبِر.
  • السعي إلى مستوى نضج بدلاً من حل مشكلات الفريق الفعلية.

من منظور ضمان الجودة

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

احتفظ ببطاقة كل تجربة مع نتيجتها وقرارها، ليتذكر الفريق سبب وجود كل ممارسة ويتخلى عنها حين تتوقف عن الإفادة. ومن الأسئلة المفيدة: «ماذا سنرى لو نجح هذا؟» و«ما الذي قد يسوء؟» و«أيّ إجراء سابق ما زال مفتوحاً؟»

تمرين عملي

حوّل ملاحظات اجتماع استعادي إلى تجربة واحدة

المطلوب

عقد فريق يبني بوابة إلكترونية لمطالبات التأمين اجتماعه الاستعادي للسبرنت ⁦14⁩، وكتب تحت «ما لم يسر جيداً»: الاختبار يحدث دائماً في آخر ثلاثة أيام من السبرنت؛ تعطلت بيئة Staging مرة أخرى يوم الثلاثاء؛ تسرّب عيبان إلى الإنتاج، كلاهما في رسائل البريد التي تُبلغ بحالة المطالبة؛ الاجتماعات كثيرة. وبيانات آخر ثلاثة سبرنتات أدناه.

اختر مشكلة واحدة تبدأ بها، وبرّر اختيارك بالبيانات، واكتب لها بطاقة تجربة. ثم بيّن ما ينبغي أن يحدث للمشكلات الأخرى.

المادة
Insurance claims portal - data for the sprint 14 retrospective (2-week sprints)

                                            Sprint 12   Sprint 13   Sprint 14
Stories finished                                  9           8           9
Stories reopened after testing                    3           4           3
Average days a story waited for testing         2.5         3.0         2.8
Staging unavailable (hours)                       6          11           9
Defects escaped to production                     1           0           2
Open actions from earlier retrospectives          2           4           6
الخطوات
  1. حدّد أيّ الأرقام مستقرة وأيّها يرتفع أو ينخفض.
  2. اكتب الفرضية بصيغة «إذا فعلنا…، فسيحدث…، لأن…»، مع تغيير واحد.
  3. احسب خط الأساس على السبرنتات الثلاثة، واختر مقياساً موازناً، وحدّد قاعدة القرار.
  4. قرّر أين تذهب كل مشكلة متبقية.
إظهار الإجابة النموذجية
الإجابة النموذجية

قراءة البيانات: القصص المعاد فتحها (Stories reopened) وأيام الانتظار مستقرة، وتعطّل Staging والعيوب المتسربة يتذبذبان، أما الإجراءات المفتوحة من الاجتماعات السابقة (Open actions) فترتفع من ⁦2⁩ إلى ⁦6⁩.

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

البطاقة: تنتظر القصص نحو ⁦2.8⁩ يوم في المتوسط قبل الاختبار (متوسط ⁦2.5⁩ و⁦3.0⁩ و⁦2.8⁩). الفرضية: إذا حدّ الفريق العمل قيد التنفيذ (WIP) بثلاث قصص في التطوير، فستنتظر القصص وقتاً أقل قبل الاختبار، لأن المطورين يُنهون قصة قبل أن يبدؤوا التالية، فتصل القصص إلى المختبِر واحدة تلو الأخرى بدلاً من أن تصل دفعة واحدة في آخر السبرنت. التغيير: هذا الحد لمدة سبرنتين. المقياس: متوسط أيام الانتظار، وخط أساسه ⁦2.8⁩. المقاييس الموازنة: القصص المنجزة في السبرنت، وخط أساسها نحو ⁦9⁩ (⁦26⁩ في ثلاثة سبرنتات)، والقصص المعاد فتحها، وخط أساسها ⁦10⁩ من ⁦26⁩ (⁦38%⁩). القاعدة: اعتمد التغيير إذا انخفض الانتظار إلى أقل من ⁦1.5⁩ يوم، وأُنجزت ⁦8⁩ قصص على الأقل في السبرنت، ولم تتجاوز نسبة القصص المعاد فتحها ⁦38%⁩؛ وعدّله وابدأ دورة أخرى إذا انخفض الانتظار لكنه بقي ⁦1.5⁩ يوم أو أكثر، أو إذا ساء أحد المقاييس الموازنة؛ وتخلَّ عنه إذا لم ينخفض الانتظار.

ارتفاع الإجراءات المفتوحة (⁦2⁩ ثم ⁦4⁩ ثم ⁦6⁩) يعني أن المتابعة متعثرة: اتفقوا على إجراءين على الأكثر في كل اجتماع، لكلٍّ منهما مسؤول وموعد، وراجعوهما أولاً في الاجتماع التالي، وأغلقوا الإجراءات الستة المفتوحة أو أسقطوها صراحةً.

العيبان المتسربان في رسائل حالة المطالبة يمرّان بمسار التعلم من الحوادث: مراجعة ما بعد الحادثة، وثغرات الاختبار، واختبارات انحدار جديدة. ويبقى تعطّل Staging في قائمة التحسينات مرشحاً للدورة التالية، ويُسجَّل في سجل مخاطر المشروع مع مسؤول، لأنه يهدد تنفيذ الاختبار. أما «الاجتماعات كثيرة» فلا بيانات عنها بعد، فاسألوا في الاجتماع التالي: أيّ الاجتماعات، وكم تستغرق؟

أسئلة شائعة

ما الفرق بين الاجتماع الاستعادي ومراجعة ما بعد الحادثة؟

يُعقد الاجتماع الاستعادي بانتظام، في نهاية سبرنت أو تكرار أو إصدار، ويتناول طريقة عمل الفريق سواء وقعت مشكلة أم لا. أما مراجعة ما بعد الحادثة فتبدأ بسبب حادثة واحدة وتحلل ذلك الحدث. وكلاهما يجب أن يكون دون لوم، وإجراءات الاثنين تنتمي إلى قائمة التحسينات نفسها. وبعض المؤسسات تسمّي الاجتماع الاستعادي في نهاية المشروع أيضاً «مراجعة ما بعد المشروع» (Post-mortem أو Post-project meeting)، فتأكد من المقصود.

هل يحتاج الفريق إلى TMMi أو TPI NEXT ليتحسن؟

لا. تكفي معظمَ الفرق الاجتماعاتُ الاستعادية وبضعة مقاييس للعملية وتجارب صغيرة. ويفيد النموذج حين تريد مؤسسة تقييماً منهجياً عبر فرق كثيرة، أو عليها أن تُثبت عملية محددة لعميل أو مدقق. وحتى عندئذٍ يُفضَّل إدخال كل تغيير يقترحه النموذج خطوةً صغيرة يُقاس أثرها.

ماذا لو لم تنجح التجربة؟

تكون قد تعلمت شيئاً بتكلفة قليلة. سجّل النتيجة وسبب إخفاقها في رأيك، وتخلَّ عن التغيير أو عدّله، وأبقِ المشكلة في قائمة التحسينات. ولا تخفق التجربة حقاً إلا إذا لم تعلّمك شيئاً، كأن يغيب خط الأساس أو تُحدَّد قاعدة القرار بعد ظهور النتيجة.

كم تجربة نُجري في الوقت نفسه، وكم مرة نراجعها؟

تجربة أو اثنتان في الوقت نفسه، بحسب إيقاع الفريق: في Scrum راجعوها في كل مراجعة استعادية للسبرنت (Sprint Retrospective)، وفي Kanban أو التدفق المستمر على فترة ثابتة مثل كل أسبوعين. وكلما زادت التجارب المتوازية صعُب معرفة أيّ تغيير أحدث أيّ أثر.

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.

تدرّب بأدوات متقن

حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.

أدوات مساعدة

احسب الفرق الدقيق بين تاريخين بالسنوات والأشهر والأيام والساعات والوحدات الإجمالية.

أدوات مساعدة

ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.

تصميم الاختبارات

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة