تعريف الجاهزية وتعريف الإنجاز
تعريف الإنجاز (Definition of Done) قائمة يتفق عليها الفريق بمقاييس الجودة التي يجب أن يستوفيها كل عمل قبل أن يُعدّ منتهياً. ويصفه دليل Scrum لعام 2020 بأنه وصف رسمي لحالة الزيادة (Increment) حين تستوفي مقاييس الجودة التي يتطلبها المنتج. فإذا نصّ تعريف الإنجاز على «مراجعة الشيفرة، وتغطية معايير القبول باختبارات ناجحة في خط التكامل المستمر (CI pipeline)، وعدم وجود عيوب مفتوحة بخطورة حاجب (Blocker) أو حرج (Critical)»، فالقصة التي تعمل على حاسوب المطور ولديها اختبار فاشل واحد ليست منجزة، مهما قالت لوحة المهام.
ويطبّق تعريف الجاهزية (Definition of Ready) الفكرة نفسها في البداية: قائمة تحقق قصيرة يُفترض أن يستوفيها عنصر قائمة المهام قبل أن يأخذه الفريق إلى السبرنت. وهو ليس جزءاً من دليل Scrum، بل ممارسة تضيفها فرق كثيرة. ويعامل منهج ISTQB CTFL v4.0 التعريفين على أنهما الاسمان اللذان تستخدمهما الفرق الرشيقة (Agile) لمعايير الخروج ومعايير الدخول، وهي موضوع الدرس السابق.
لماذا يهم
من دون تعريف مشترك تعني كلمة «منجز» للمطور «دُمجت الشيفرة»، ولمالك المنتج «يستطيع العملاء استخدامه»، وللمختبِر «فُحص على المتصفحات المتفق عليها وباللغتين». فيبدو العمل منتهياً وهو يُخفي عملاً غير منجز، كاختبارات ناقصة وشيفرة لم تُراجَع ورسائل لم تُترجم، يظهر وقت الإصدار كومةً من العيوب. وتعريف الإنجاز يضع المعيار نفسه لكل عنصر، فيكون التقدم المعروض في مراجعة السبرنت (Sprint Review) حقيقياً.
ويعالج تعريف الجاهزية الكلفة المعاكسة: قصص تدخل السبرنت بقواعد غامضة أو اعتمادية معطّلة، فيكتشف المختبِر الثغرات في منتصف السبرنت حين تكون الأسئلة أغلى ما تكون. ومعاً يحوّل التعريفان عبارة «اختبره جيداً من فضلك» إلى معايير متفق عليها وقابلة للفحص يملكها الفريق كله.
تعريف الإنجاز في دليل Scrum
كما رأينا في درس «Scrum للمختبِرين»، تعريف الإنجاز هو الالتزام الخاص بالزيادة: فالعنصر الذي لا يستوفيه لا يُصدَر ولا يُعرض في مراجعة السبرنت. وتهمّ نقطتان أخريان من دليل Scrum لعام 2020 عند كتابته. فالفرق التي تعمل على المنتج نفسه تتشارك تعريف إنجاز واحداً. ولا يحدد الدليل محتواه؛ فهو قرار الفريق، ولهذا ينبغي أن يشارك المختبِرون في كتابته.
- ينطبق على كل عنصر. أما القواعد الخاصة بقصة بعينها فهي معايير قبول تلك القصة.
- نتيجته ثنائية: إما أن يستوفي العنصر كل معيار، وإما أنه غير منجز. ولا توجد حالة «شبه منجز».
معايير الجودة التي ينبغي أن يتضمنها تعريف الإنجاز
المعيار الجيد قابل للفحص، أي يستطيع أي شخص أن يجيب عنه بنعم أو لا ويشير إلى دليل، ويمكن استيفاؤه داخل السبرنت. فعبارة «تم اختباره» غير قابلة للفحص؛ أما «كل معيار قبول تغطيه حالة اختبار تنجح في خط CI» فقابلة له. وأدرج الجودة غير الوظيفية أيضاً؛ فخصائص الجودة في المعيار ISO/IEC 25010 قائمة تذكير مفيدة. ونموذج تعريف الإنجاز في درس «Scrum للمختبِرين» بداية جيدة. فإذا أضفت إليه مراجعة الشيفرة وإمكانية الوصول (Accessibility) والفحص الأمني، وجعلت بنوده الأخرى أدق، فقد يبدو هكذا:
- راجع مطور آخر الشيفرة، ودُمجت في الفرع الرئيسي.
- كل معيار قبول تغطيه حالة اختبار، والاختبارات المؤتمتة تنجح في خط CI.
- حزمة الانحدار تنجح على الفرع الرئيسي.
- لا عيوب مفتوحة بخطورة حاجب أو حرج لهذا العنصر، وتُسجَّل العيوب الأخرى في قائمة مهام المنتج (Product Backlog).
- الشاشات الجديدة أو المعدّلة فُحصت من حيث إمكانية الوصول: كل عنصر تحكم يعمل بلوحة المفاتيح وحدها وله اسم يستطيع قارئ الشاشة نطقه، ورسائل الخطأ واضحة.
- الشاشات فُحصت بالعربية والإنجليزية على هاتف وعلى متصفح حاسوب.
- لا نتائج جديدة عالية الخطورة في الفحص الأمني.
تعريف الجاهزية: ممارسة يتبنّاها الفريق
لا يعرّف دليل Scrum شيئاً اسمه تعريف الجاهزية. بل يقول فقط إن العناصر التي يستطيع الفريق إنجازها خلال سبرنت واحد تُعدّ جاهزة للاختيار في تخطيط السبرنت (Sprint Planning)، وذلك عادةً بعد تهذيب قائمة المهام (Refinement). وتعريف الجاهزية يكتب هذا التوقع في صورة قائمة تحقق قصيرة تُستخدم أثناء التهذيب.
تعامل معه كأداة للحوار لا كعقد. فتعريف الجاهزية الذي يشترط كل التفاصيل مسبقاً يحوّل كل سبرنت إلى نموذج شلالي (Waterfall) مصغّر، ولهذا تأخذ فرق كثيرة عنصراً شبه جاهز إذا أمكن حسم السؤال المفتوح في بداية السبرنت. ومن بنوده المعتادة:
- تذكر القصة من يحتاج ماذا ولماذا.
- معايير القبول مكتوبة، وراجعها مطور ومختبِر من حيث قابليتها للاختبار.
- الاعتماديات، مثل واجهة برمجية يملكها فريق آخر أو ترجمات، معروفة ومتاحة.
- التصاميم مرفقة لتغييرات الواجهة، بما فيها التخطيط من اليمين إلى اليسار.
- احتياجات بيانات الاختبار معروفة، والعنصر يتسع لسبرنت واحد؛ وإلا فيُقسَّم.
كيف يرتبط التعريفان بمعايير الدخول والخروج
يذكر منهج ISTQB CTFL v4.0 أن معايير الخروج في التطوير الرشيق كثيراً ما تُسمّى تعريف الإنجاز، أي المقاييس الموضوعية التي يضعها الفريق لعنصر قابل للإصدار، وأن معايير الدخول التي يجب أن تستوفيها قصة المستخدم قبل بدء التطوير والاختبار تُسمّى تعريف الجاهزية. والتطابق قريب، لكن ثلاثة فروق تهمّ في العمل:
- النطاق: معايير الخروج في خطة الاختبار تُحدَّد عادةً لكل مستوى اختبار أو إصدار؛ أما تعريف الإنجاز فاتفاق دائم لكل عنصر في كل سبرنت.
- المحتوى والملكية: يغطي تعريف الإنجاز أيضاً مراجعة الشيفرة والتوثيق والنشر، ويملكه فريق Scrum كله لا مدير الاختبار.
- المستويات: تحتفظ بعض الفرق بقائمة تحقق منفصلة للإصدار (انحدار كامل، واختبار أداء) للفحوص التي لا تتسع لكل سبرنت. تعمل هذه القائمة كمعايير خروج للإصدار، وكل ما بقي مفتوحاً فيها عمل غير منجز، والمراجعة الاستعادية (Sprint Retrospective) هي المكان المناسب لنقل هذه الفحوص إلى تعريف الإنجاز.
تعريف الجاهزية (Definition of Ready)DoR
هل يستطيع الفريق البدء بهذا العنصر دون تخمين؟
- المصدر:
- ممارسة فريق؛ ليست في دليل Scrum لعام 2020
- متى يُفحص:
- أثناء التهذيب، قبل أن يُختار العنصر في تخطيط السبرنت
- ينطبق على:
- كل عنصر في قائمة مهام المنتج قبل اختياره
- اسمه في ISTQB CTFL v4.0:
- معايير الدخول لقصة المستخدم
- إذا لم يُستوفَ:
- يُهذَّب أو يُقسَّم، وينتظر في قائمة مهام المنتج
- بنود يفحصها المختبِر عادةً:
- معايير قبول قابلة للاختبار، وبيانات اختبار معروفة، واعتماديات متاحة
تعريف الإنجاز (Definition of Done)DoD
هل اكتمل هذا العنصر دون عمل خفيّ متبقٍّ؟
- المصدر:
- دليل Scrum لعام 2020: الالتزام الخاص بالزيادة (Increment)
- متى يُفحص:
- قبل عرض العنصر في مراجعة السبرنت أو إصداره
- ينطبق على:
- كل عنصر، والزيادة ككل
- اسمه في ISTQB CTFL v4.0:
- معايير الخروج لعنصر قابل للإصدار
- إذا لم يُستوفَ:
- لا يُعرض ولا يُصدر، ويعود إلى قائمة مهام المنتج
- بنود يفحصها المختبِر عادةً:
- الاختبارات تنجح في خط CI، وحزمة الانحدار تنجح، ولا عيوب مفتوحة بخطورة حاجب أو حرج
مثال تطبيقي: قصة واحدة من الجاهزية إلى الإنجاز
القصة: «بصفتي عميلاً عائداً، أريد حفظ ما يصل إلى خمسة عناوين توصيل حتى يكون إتمام الشراء أسرع». في جلسة التهذيب يفحصها المختبِر مقابل تعريف الجاهزية، فلا يتحقق بندان: لا شيء يذكر ما يحدث مع عنوان سادس، والواجهة البرمجية للتحقق من العناوين التي يملكها فريق آخر لن تتوفر قبل السبرنت القادم. فيضيف الفريق معياراً («يُرفض العنوان السادس برسالة تذكر أن الحد خمسة عناوين»)، وينقل مالك المنتج التحقق من العناوين إلى قصة منفصلة. الآن أصبحت القصة جاهزة لتخطيط السبرنت.
وقبل مراجعة السبرنت يفحص الفريق تعريف الإنجاز ويربط الدليل بالقصة:
- المراجعة، واختبارات القبول (حفظ العنوان الخامس ورفض السادس)، وحزمة الانحدار، والشاشات بالعربية والإنجليزية على الهاتف والحاسوب، والفحص الأمني: مستوفى.
- العيوب: كشفت جلسة الاختبار الاستكشافي عيباً واحداً بخطورة ثانوي (Minor) سُجّل في قائمة المهام، ولا عيب مفتوحاً بخطورة حاجب أو حرج: مستوفى.
- فحص إمكانية الوصول: غير مستوفى، فزر الحذف الذي يظهر كأيقونة يمكن بلوغه بلوحة المفاتيح، لكن ليس له اسم ميسَّر (accessible name)، وهو النص الذي تقرؤه التقنيات المساعدة لعنصر التحكم، فلا يعلن قارئ الشاشة إلا كلمة «زر».
- النتيجة: القصة غير منجزة. يضيف المطور الاسم ويعيد المختبِر الفحص في اليوم نفسه (اختبار التأكيد). ولو بقي العيب لما عُرضت القصة في مراجعة السبرنت ولعادت إلى قائمة مهام المنتج، ولا تُسجَّل أبداً بأنها «منجزة ما عدا إمكانية الوصول».
أخطاء شائعة
- التعامل مع تعريف الإنجاز كقائمة توقيع خاصة بالمختبِر. فهو التزام الفريق كله، والاختبار الذي يتطلبه يجري داخل السبرنت.
- كتابة معايير لا يمكن فحصها مثل «تم اختباره» أو «لا أخطاء». فالاختبار يُظهر وجود العيوب لا غيابها: «لا عيوب مفتوحة بخطورة حرج» يمكن تأكيده، أما «لا أخطاء» فلا.
- الخلط بين معايير القبول وتعريف الإنجاز، أو افتراض أن استيفاء معايير قبول القصة وحده يجعلها منجزة.
- الإبلاغ عن عنصر بأنه «منجز ما عدا الاختبار» أو ترحيل الفحوص إلى «سبرنت اختبار» لاحق، وهذا يُخفي العمل غير المنجز حتى الإصدار.
- تحويل تعريف الجاهزية إلى بوابة جامدة، أو تقديمه على أنه جزء من Scrum.
- عدم مراجعة تعريف الإنجاز أبداً، فيتسرّب النوع نفسه من العيوب سبرنتاً بعد سبرنت.
من منظور ضمان الجودة
في جلسات التهذيب كثيراً ما يكون المختبِر أول من يرى أن القصة غير جاهزة: حالات سلبية ناقصة، أو صياغة غير قابلة للاختبار، أو بيانات اختبار مجهولة. اسأل هناك، وحين تتكرر ثغرة ما اقترح بنداً في تعريف الجاهزية يلتقطها. وفي تخطيط السبرنت تأكّد أن تصميم الاختبار والأتمتة وجلسات الاختبار الاستكشافي مخططة كمهام في السبرنت، وإلا فلن يمكن استيفاء تعريف الإنجاز في الوقت المحدد.
اربط دليل كل معيار من تعريف الإنجاز بالقصة: تشغيل خط CI، وملاحظات الجلسة، وفحص إمكانية الوصول. وحين يتسرّب عيب، احمل إلى المراجعة الاستعادية اقتراحاً محدداً مثل «تُفحص النماذج بلوحة المفاتيح وحدها». وإذا أراد أحد اعتبار عنصر منجزاً بينما أحد المعايير غير مستوفى، فاجعل ذلك ظاهراً: تغيير تعريف الإنجاز قرار يتخذه الفريق علناً، وليس استثناءً صامتاً لقصة واحدة.
تمرين عملي
أعد كتابة تعريف إنجاز ضعيف وافحص جاهزية قصة
تعريف الإنجاز لدى فريق يبني نظام حجز مواعيد لعيادة هو: «اكتملت الشيفرة. تم الاختبار. لا أخطاء. مالك المنتج راضٍ. حُدّث التوثيق عند الحاجة». أعد كتابته في صورة معايير قابلة للفحص، تتضمن جانبين على الأقل من الجودة غير الوظيفية.
ثم اكتب تعريف جاهزية قصيراً وافحص به هذه القصة: «بصفتي مريضاً، أريد رفع صورة بطاقة التأمين الخاصة بي قبل موعدي حتى يكون تسجيل الوصول في العيادة أسرع». دوّن ما لا تستوفيه القصة والأسئلة التي ستطرحها في جلسة التهذيب.
- اسأل عن كل سطر في تعريف الإنجاز: هل يستطيع أحد أن يجيب بنعم أو لا مع دليل؟ أعد كتابته أو احذفه.
- أضف معايير لجوانب الجودة الناقصة.
- اكتب تعريف الجاهزية وافحص القصة مقابله.
- اكتب أسئلتك لمالك المنتج.
إظهار الإجابة النموذجية
لماذا لا تصلح الأسطر: «اكتملت الشيفرة» و«تم الاختبار» غير قابلين للفحص، و«لا أخطاء» لا يمكن أن يؤكده الاختبار أبداً، و«مالك المنتج راضٍ» شعور لا معيار، و«عند الحاجة» يترك مفتوحاً من يقرر.
تعريف إنجاز معاد كتابته: مراجعة الشيفرة ودمجها؛ كل معيار قبول تغطيه حالة اختبار تنجح في خط CI؛ حزمة الانحدار تنجح؛ لا عيوب مفتوحة بخطورة حاجب أو حرج؛ الشاشات الجديدة فُحصت بلوحة المفاتيح وحدها وفُحص وضوح رسائل الخطأ؛ الشاشات فُحصت بالعربية والإنجليزية على الهاتف والحاسوب؛ نصوص المساعدة حُدّثت حين يتغيّر سلوك يراه المستخدم. وفحص لوحة المفاتيح وفحص اللغتين والأجهزة هما المعياران غير الوظيفيين.
تعريف الجاهزية: القيمة مذكورة؛ معايير القبول مكتوبة ومراجَعة؛ الاعتماديات متاحة؛ التصاميم مرفقة؛ بيانات الاختبار معروفة؛ العنصر يتسع لسبرنت واحد. ولا تستوفي القصة إلا بند القيمة: فلا معايير قبول لها، واعتمادياتها مجهولة (هل يجري التحقق من البطاقة لدى شركة التأمين، وهل تلك الخدمة متاحة؟)، ولا تصميم لشاشة الرفع، وبيانات الاختبار غير واضحة: تحتاج إلى صور بأنواع ملفات وأحجام مختلفة، وصورة ضبابية، وبطاقة منتهية الصلاحية، وكلها اصطناعية لأن بطاقات التأمين الحقيقية بيانات شخصية. وما دام التحقق لدى شركة التأمين غير محسوم فلا أحد يعرف هل تتسع القصة لسبرنت واحد، وقد تُقسَّم إلى الرفع الآن والتحقق لاحقاً.
الأسئلة: ما أنواع الملفات المقبولة وما الحجم الأقصى؟ هل يجري التحقق من البطاقة لدى شركة التأمين، وماذا يرى المريض إذا كانت منتهية الصلاحية أو مرفوضة؟ من يحق له الاطلاع على الصورة، وكم مدة الاحتفاظ بها؟ هل يستطيع المريض استبدالها أو حذفها؟ ماذا يحدث إذا انقطع الرفع في منتصفه؟
أسئلة شائعة
ما الفرق بين تعريف الجاهزية ومعايير الدخول في خطة الاختبار؟
كلاهما يحدد ما يجب أن يتحقق قبل بدء العمل (ويسمّي منهج ISTQB CTFL v4.0 تعريفَ الجاهزية معاييرَ الدخول لقصة المستخدم)، لكنهما يختلفان في النطاق والتوقيت. فمعايير الدخول في خطة الاختبار تُحدَّد عادةً لمستوى اختبار أو نشاط اختبار، وتُفحص مرة واحدة قبل بدئه، مثل «بيئة الاختبار متاحة واختبارات الدخان (Smoke tests) ناجحة». أما تعريف الجاهزية فيُفحص لكل عنصر في قائمة المهام أثناء التهذيب، ويسأل: هل فُهم هذا العنصر بما يكفي لبنائه واختباره؟ ويمكن للفريق أن يستخدم الاثنين: تعريف الجاهزية لقصصه، ومعايير الدخول لاختبار القبول لدى العميل مثلاً.
كيف يفحص الفريق تعريف الإنجاز لكل عنصر دون أن يتباطأ؟
دع خط CI يفحص ما يستطيع فحصه: اختبارات معايير القبول وحزمة الانحدار والفحص الأمني تعمل مع كل تغيير، وتُربط نتائجها بالقصة. واجعل الفحوص التي يجب أن يجريها شخص، مثل فحص لوحة المفاتيح وفحص اللغتين، صغيرة، وخطّطها كمهام في السبرنت. وأدوات فحص إمكانية الوصول الآلية لا تكتشف إلا بعض المشكلات، مثل غياب الاسم الميسَّر، فهي تدعم فحص لوحة المفاتيح ولا تحلّ محله.
من يقرر ما يدخل في تعريف الإنجاز؟
إذا وضعت المؤسسة تعريف إنجاز كمعيار، فعلى كل فريق اتباعه كحدّ أدنى. وإلا فيضعه فريق Scrum، والمطورون (Developers) ملزمون بالتقيّد به، ويفحصه الفريق في كل مراجعة استعادية للسبرنت. ويسهم المختبِرون باقتراح معايير جودة قابلة للفحص، مدعومة بالعيوب التي تسرّبت.
هل يحلّ تعريف الإنجاز محل معايير الخروج في خطة الاختبار؟
بالنسبة إلى العمل داخل السبرنت يحلّ محلها عادةً. أما المشاريع ذات الالتزامات التعاقدية أو التنظيمية، أو التي فيها مستويات اختبار منفصلة مثل اختبار القبول لدى العميل، فكثيراً ما تظل تحدد معايير خروج لتلك المستويات أو للإصدار في خطة اختبار.
المراجع
- The 2020 Scrum Guideتعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Certified Tester Foundation Level Agile Tester (CTFL-AT)امتداد ISTQB للمستوى التأسيسي حول الاختبار داخل فرق Agile؛ وهو في طور الإيقاف (امتحانات الإنجليزية متاحة حتى 6 مايو 2027) لصالح CTFL v4.0 وCTAL-AT.
تدرّب بأدوات متقن
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
للتعمّق أكثر
- دورة حياة اختبار البرمجيات (STLC)STLC في السبرنت وفي خط التكامل، والأخطاء الشائعة
- كيف تكتب خطة اختبار (Test Plan)خطة اختبار خفيفة للفرق الرشيقة
- SDLC وSTLC: دورتا التطوير والاختبارمعايير الدخول والخروج عبر دورة الحياة
- ضمان جودة المنتج من البداية إلى النهايةبوابات الإصدار وإدارة العيوب والأرقام التي تستحق المتابعة
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.