في فريق scrum، هنالك ثلاثة أدوار: مالِك المُنتَج (Product Owner) وفريق التطوير (Development Team) ومدير الـ scrum أو مايُسمّى (Scrum Master). لا يوجد هنالك ذكر صريح لمختبري البرمجيات وقد يتساءل البعض هل المتخصصون في الاختبار ضروريّون حقًا في الفريق. بعد العمل على العديد من المشاريع، وجد إريك ديلاهاي أنهم ضروريّون ويشاركنا أربعة أسباب لماذا يجب تضمينهم بمجرد التخطيط لـ the first sprint.

من الأساسيات في scrum والتي نعرفها جميعًا نقطة أن إشراك جميع الأدوار التي تجعل عملية التطوير (development) ممكنة هو مفتاح النجاح. بعد سنوات من العمل بهذه المنهجيّة، قمنا بتنفيذ مُمارسة نجحت معنا بشكل جيّد للغاية في مشاريع الأجايل (Agile) التي تحتوي على مختبرين وهي: اكتشاف حالات الاختبار الأكثر صِلَة من مرحلة الـ Sprint Planning.

ماهي هذه المُمارسة؟

نحن نعلم جيدًا أنه أثناء التخطيط لـ sprint معيّنة، يُقدّم الـ product owner قائمة بأولويات الـ user stories ويقترح هدفًا لهذه الـ sprint. من جانبه، يقوم الفريق بمراجعة قائمة المتطلّبات (requirements) وطرح الأسئلة اللازمة وتحديد معايير القبول (acceptance criteria). بمجرّد توفّر كافّة المعلومات، يقوم الفريق بتقدير كل user story وتقسيمها إلى مهام محددة من أجل توزيع قائمة مهام الـ Sprint Backlog.

في هذه المرحلة، يتم تضمين حالات الاختبار (test cases) الرئيسية التي يجب إجراؤها على كل user story. السؤال هو: ماذا نحقق بهذا؟

الجواب على السؤال في النقاط التالية:

• أصبحت أنشطة الاختبار الآن جزءًا من الـ user story وليست مستقلّة عنها.
• يتم تدوين عناوين حالات الاختبار المُكتشَفَة في الـ user story ويتم استكمالها بوصف أكثر قوة للـ user story.
• لا نترُك مسؤولية الاختبار في أيدي المختبرين فقط. تصبح المهمّة نشاطًا متفقًا عليه من الفريق وبالتالي يتم تقاسُم المسؤولية.

بعد أن رأينا كيف يمكّن الـ scrum من العمل معًا لتحقيق الإنتاجية وتحسين جودة التطوير، هنا أربعة أسباب رائعة عن لماذا يجب أن يكون مختبر البرمجيات جزءًا من مرحلة الـ Sprint Planning:

أولًا: جودة أعلى لحالات الاختبار

من خلال تعزيز المناقشة الصحية بين الفريق لتحديد حالات الاختبار، فإننا نحقق جودة أفضل لحالات الاختبار. اعتدنا في السابق على ترك هذه المهمة لمختبر البرمجيات عندما يقوم بمهمّته المتمثلة في كتابة حالات الاختبار في كل user story. يمكن لمختبر البرمجيات الآن التركيز على حالات الاختبار المتبقية الأخرى وبالطبع التركيز كذلك على تصميم وكتابة وتنفيذ حالات الاختبار.

ثانيًا: فهم أفضل للـ User Stories

إن ممارسة التفكير في أهم حالات الاختبار من قبل الفريق بأكمله تثير الأسئلة والمسارات البديلة وتحليل جميع الظروف. وبهذا نحقق فهمًا شاملًا للـ user stories.

إن التفكير في كيفية اختبار كل user story يساعدنا على فهم ما يجب القيام به وما يتوقعه العميل منا بشكل أفضل.

ثالثًا: تقديرات أكثر دقّة

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

ولهذا السبب، أصبحت تقنيات التقدير (Planning Poker) أكثر دقة وعدالة إذا أخذنا في الاعتبار أنه في السابق لم يكن من السهل تحديد حجم جهد الاختبار على سبيل المثال بالنسبة للمطوّر.

رابعًا: العمل الجماعي والتواصل

على الرغم من العمل مع scrum، كان شعورنا أن المختبرين منفصلين عن الفريق وأن المطوّرين لم يكونوا على دراية كبيرة بما كان المختبرون يعملون عليه. كذلك كان الاختبار يُشكّل عقبة في نهاية الـ sprint ولم يتمكّن المختبرون من التعامل مع تنفيذ جميع حالات الاختبار وإدارة الأخطاء (defects management). سبّب هذا الموقف فقط تراكم العمل وفي أسوأ الأحوال تعريض نجاح وجودة التسليم للخطر.

يساعدنا وجود مختبرين من مرحلة الـ Sprint Planning على التكامل والتواصل بشكل أفضل بين المطوّرين والمختبرين منذ بداية الـ sprint planning مما يساعدنا أيضًا على تحقيق تقديرات أكثر دقة والتأكّد من أن كل شخص لديه بعض مهام الاختبار/الجودة كجزء من مسؤولياته.

من المهم ملاحظة أن تنفيذ حالات الاختبار – التي كتبها وصمّمها أعضاء فريق الاختبار سابقًا – وهم الأشخاص الذين يتمتعون بالتخصص والمسؤولية – يمكن الآن بواسطة أي عضو في الفريق خاصة مع الاقتراب من نهاية الـ sprint عندما يكون العمل أكثر تركيزًا على الاختبار وتقِل مهام ال​​عمل لدى المطوّرين.

بهذا يمكن تطبيق أحد أصعب الجوانب النظرية في scrum وهو وجود متخصصين في الفريق ويكون أي عضو في الفريق قادرًا على أداء أي مهمة.

في الختام

إن الاختبار في scrum ليس أسطورة بل هو حقيقة بالنسبة لنا. لقد كان إشراك المختبرين من مرحلة الـ Sprint Planning مُمارسة جيدة ساعدتنا على تحسين جودة البرامج التي نبنيها. لا شك أنه من خلال فهم أفضل للمتطلّبات (requirements) وحالات الاختبار التي يجب العمل عليها، تمكّن الفريق من تحسين الجودة وزيادة الإنتاجية وزيادة الكفاءة وذلك بفضل القضاء على الاختناقات (bottlenecks) التي كانت تظهر في نهاية الـ sprint.

* المصدر: https://www.scrumexpert.com/knowledge/4-reasons-why-scrum-needs-testers-from-day-1