أفضل الممارسات في اختبار الإستراتيجية لفريق سكرم

خطة اختبار Scrum ناقص تساوي POC على المنشطات.

في الوقت الحاضر ، تبدأ معظم المشاريع الناجحة بإثبات المفهوم (POC) ، وهو تقييم صغير الحجم نسبيًا لفكرة ، حيث سيتم التحقق من التكنولوجيا المختارة وحزمة الميزات أولاً ، وتقييم التأثير المحتمل على مستخدمي الأعمال ، وبعد ذلك ، بمجرد إثبات ذلك جديرًا بالاستثمار ، يتم تعيين فريق مشروع كامل الحجم لتصميم وتسليم المنتج كامل الميزات ونشره في الإنتاج.

هذه هي الحالة المثالية لفريق Scrum. يمكن للفريق تطوير النموذج الأولي بسرعة ، مضيفًا ميزات جديدة جوهرية في كل سباق ، بينما يمكن لمستخدمي الأعمال مشاهدة تقدم سريع في الوقت الفعلي وكيف يتم بناء الفكرة من الصفر خلال 10 سباقات سريعة. إنه يترك انطباعًا قويًا (وهو الهدف الرئيسي لـ POC على أي حال) ، ولكن له أيضًا خاصية واحدة مهمة - الحد الأدنى من أنشطة الاختبار أو عدم وجودها ، وحتى التفكير في عملية الاختبار سيكون مزحة مباشرة.

إنه ليس نشاطًا ممتعًا داخل فريق Scrum ، وسيحب الناس في الغالب فكرة التطوير بدون عمليات حول لإبطائهم. هذا هو في الأساس ما سيفعله أي نشاط اختبار ضمنيًا. ومن الذي يريد البطء غير الضروري خلال الوقت الذي نحتاجه لإقناع المستخدم النهائي أكثر من غيره؟

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

ولكن قبل أن يتحول إلى هناك ، سيواجه الفريق وقتًا أصعب من الركض إلى الركض لمواكبة الإصدارات المستقرة ، حيث سيصبح إصلاح مشكلات التدحرج أكثر تعقيدًا.

فيما يلي بعض التقنيات التي أثبتت فعاليتها عندما كنت أتعامل مع مشكلات مماثلة والتي أعتقد أنه يمكن تسميتها بأفضل الممارسات لتنفيذ عمليات اختبار قوية ، لا تزال دون تشويش تقدم التطوير كثيرًا - لأن هذا ما نريد جميعًا أن نكون من أجله فريق سكرم.

وزع الألم

في أي مكان آخر سنبدأ عند التعامل مع الإزعاج غير الضروري بدلاً من تقسيم الألم :).

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

# 1. قم بتطوير كود اختبار الوحدة لكل جزء تم إنشاؤه من الكود الجديد

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

الأسباب واضحة إلى حد ما:

سيجبر المطورين على التفكير في مسارات مختلفة غير قياسية للشفرة. -

• يمكن توصيل اختبارات الوحدة هذه بخطوط أنابيب DevOps الآلية وتنفيذها مع كل عملية نشر في بيئة التطوير أو الاختبار. أيضًا ، يمكن تصدير المقاييس من خط الأنابيب بسهولة ثم استخدامها للتوضيح لمستخدمي الأعمال التغطية المئوية لحالات الاختبار المرتبطة مباشرةً بكود المصدر.

الأهم هو أن تبدأ قريبًا جدًا. كلما بدأ تطوير اختبارات الوحدة لاحقًا ، كلما زاد تشتيت الانتباه بالنسبة للمطورين لإضافتهم في سباق سريع.

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

# 2. قم بعمل روتيني لتنفيذ جميع أجزاء اختبارات الوحدة في بيئة التطوير

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

• يعمل كود اختبار الوحدة بالفعل لكل جزء (في النهاية هو مجرد رمز آخر يجب التحقق منه). غالبًا ما يتم تخطي هذه الخطوة تمامًا. يُفترض بطريقة ما أنه إذا تم توصيل اختبار الوحدة على أي حال بخط أنابيب DevOps ، فسيتم تنفيذه واختباره في نهاية المطاف في مكان ما افتراضيًا. ومع ذلك ، هذا ليس سوى دفع المشاكل إلى المستويات العليا من أنشطة العدو ، حيث عادة ما يكون لدى الفريق وقت أقل ومزيد من الضغط لإنهاء كل قصة ملتزمة.
• يتم اختبار رمز الميزة الجديد من قبل المطور للوظائف الأساسية. من الواضح أنه لا يمكن توقع من هذا الاختبار أن يتم التحقق من وظائف الأعمال بالكامل ، ولكن على الأقل سيؤكد هذا الاختبار أن الكود يتصرف بالطريقة التي قصدها المطور (تجاهل ، في الوقت الحالي ، حقيقة أن منطق الأعمال يمكن يتم فهمها بشكل غير صحيح أثناء التطوير).

# 3. توقع تنفيذ اختبار الوحدة بعد دمج الكود في الفرع الرئيسي

يعد وجود رمز وظيفي في الفرع المحلي أمرًا واحدًا (حيث لا يقوم أحد غير مالك الفرع بتطوير ميزة جديدة) ، ولكن الأمر مختلف تمامًا أن يكون لديك نفس الكود يعمل بعد طلب السحب والاندماج في الفرع الرئيسي.

يحتوي الفرع الرئيسي على تغييرات من أعضاء فريق Scrum الآخرين ، وحتى إذا تم حل التعارضات وبدا كل شيء على ما يرام ، فإن الكود بعد الدمج وحل التعارضات لا يزال في الأساس جزءًا من الكود لم يتم اختباره ، ومن الخطر إرساله مرة أخرى دون التحقق أولاً لا يزال يعمل بشكل جيد.

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

بالنسبة للمطورين ، قد تكون هذه خطوة إضافية يحتاجون إلى تضمينها في حياتهم ، ولكنها ليست مجهودًا كبيرًا لأنه ، في هذه الحالة ، لا يجب اختراع أي شيء جديد - فقط أعد تنفيذ ما تم القيام به بالفعل مرة واحدة.

الآن ، يمكن تخطي هذه الخطوة في حالة واحدة معينة:

• تعتبر اختبارات الوحدة الآلية في خطوط أنابيب DevOps شاملة للغاية بحيث تغطي بالفعل الاختبار اليدوي الكامل الذي يتم تنفيذه فوق ذلك.

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

ومع ذلك ، فإن تفضيل محتوى السباق لن يكون أبدًا ذريعة لعدم إجراء اختبارات الوحدة ، أو حتى التقليل منها. من خلال القيام بذلك ، سيقوم الفريق بالتحويل مرة أخرى إلى مثل هذه الحالة ، حيث يفتقر الكود إلى الكثير من تغطية اختبار الوحدة ، ومن ثم في حالة اللحاق بالركب ، قد يكون الوقت قد فات بالفعل (مرة أخرى ، الجهد الأكبر لإكمال اختبار الوحدة أكثر من الجهد الفعلي تغيير رمز لسباق السرعة).

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

سيتم إجراء الفحص النهائي لاستعداد الفرع الرئيسي لمرحلة اختبار الإصدار. أيضًا ، سيساعد ذلك في العثور على معظم الأخطاء التقنية (على سبيل المثال ، الأخطاء التي تمنع تنفيذ التعليمات البرمجية المصدر بنجاح حتى النهاية الناجحة) ، مع ترك المرحلة التالية للتركيز فقط على التحقق من وظائف العمل.

الاستعداد للاختبار الوظيفي

يجب أن تؤدي جميع أنشطة الاختبار السابقة إلى استنتاج واحد محدد - كود الفرع الرئيسي خالٍ من الأخطاء التقنية وقابل للتنفيذ دون مشاكل للتدفقات الوظيفية الشاملة.

هذه مرحلة يمكن أن يغطيها بسهولة شخص واحد فقط ، ولا يحتاج هذا الشخص حتى إلى خلفية تقنية.

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

# 1. تستهدف قصص العدو الجديدة الاختبار الوظيفي

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

إنها تجربة محزنة عندما يتم الإعلان أخيرًا عن إطلاق الوظيفة الموعودة (الطويلة) ، فقط لتكتشف في اليوم الآخر أنها لا تعمل بشكل جيد.

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

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

ثم يتم تنفيذ حالات الاختبار بهدف التحقق من الوظيفة المطلوبة في المقام الأول. في حالة حدوث أي مشكلة في النتائج ، يتم الاتصال بالمطور المعني فقط (الشخص الذي يمتلك التغييرات المتعلقة بهذا العيب المحدد) لحل المشكلة بشكل سريع كما نأمل.

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

# 2. تنفيذ حالات اختبار الانحدار

يجب أن يكون الجزء الآخر من الاختبار الوظيفي هو التأكد من أن كل ما نجح حتى الآن سيعمل أيضًا بعد الإصدار التالي. هذا هو الغرض من اختبارات الانحدار.

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

عادةً ما يحتوي كل نظام على مثل هذه العمليات التي تمس العديد من المجالات المختلفة ، وهذه هي أفضل المرشحين لحالات اختبار الانحدار.

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

لذلك في معظم الحالات ، ليس من المعقد على الإطلاق إكمال اختبارات الانحدار جنبًا إلى جنب مع اختبارات وظائف قصص العدو الجديدة ، خاصة إذا تم ذلك بانتظام قبل كل إصدار إنتاج ، ولم تكن دورية إصدارات الإنتاج صغيرة جدًا.

الإصرار على تنفيذ اختبارات ضمان الجودة قبل كل إصدار إنتاج

اختبار ضمان الجودة (QA) هو الخطوة الأخيرة قبل إطلاقه في الإنتاج ، وغالبًا ما يتم تخطي هذا الاختبار باعتباره غير مهم. خاصة إذا تمت إدارة فريق scrum بقوة لمحتوى جديد.

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

يجب تنفيذ اختبار ضمان الجودة فقط من قبل الأشخاص من خارج فريق Scrum ، وبشكل مثالي من قبل مستخدمي الأعمال أنفسهم في بيئة مخصصة ، وهي أقرب ما يمكن من الإنتاج المستقبلي. بدلاً من ذلك ، يمكن لمالك المنتج استبدال المستخدمين النهائيين هنا.

على أي حال ، يجب أن يكون هذا اختبارًا نظيفًا وعمليًا من منظور المستخدم النهائي ، دون أي اتصال بفريق dev Scrum. سيقدم عرضًا نهائيًا واحدًا للمنتج وسيتم استخدامه بطريقة ربما لم يتوقعها أحد من فريق سكرم (ليست حالة مثالية على الإطلاق ، ولكن يمكن أن تحدث بالتأكيد). لا يزال هناك وقت لتصحيحات اللحظة الأخيرة.

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

إلى أين نذهب بعد ذلك من هنا؟

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

لكن بالتأكيد لست بحاجة إلى التوقف هنا.

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

الانتقال إلى مستوى أعلى يعني أيضًا إدخال الاختبارات الآلية.

لقد قمت بالفعل بتغطية مجموعة واحدة من الاختبارات الآلية (اختبارات الوحدة في خطوط الأنابيب). ومع ذلك ، يمكنك تطوير اختبارات انحدار كاملة من طرف إلى طرف مؤتمتة بالكامل وتنفيذها بأنفسهم بعد كل نشر في بيئة الاختبار. سيؤدي ذلك إلى تحرير فريق التطوير بشكل أكبر ، ولكنه يتطلب فريقًا مخصصًا لتطوير وصيانة مثل هذه الاختبارات الآلية. سيصبح عملاً مستمراً ، فكلما تغير رمز الإنتاج ، يمكن أن تصبح بعض الاختبارات الآلية الحالية غير صالحة ، ولذلك يجب تحديثها لمواصلة العمل في خطوط الأنابيب. إنه جهد لا يرغب سوى عدد قليل من الأشخاص في دفع ثمنه ، ومع ذلك ، فإن الفوائد التي تعود على فريق dev scrum ستكون رائعة.

هذه موضوعات تتجاوز نطاق هذه المقالة كثيرًا وتكتشف الجدول الزمني والتوقيت المناسبين لكل نوع اختبار مذكور هنا - بحيث يمكنك جعله ضمن نافذة العدو. سأكون سعيدا للغوص في المرة القادمة!