Get best of the week

كيفية تحسين أداء الفرق الرشيقة من خلال الاختبار

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



وضع القواعد من خلال الاختبار


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

في حالتنا ، كان الوضع مشابهًا جدًا: قسم تطوير منتجات البيانات الضخمة لمجموعة X5 Retail موجود لمدة عامين ، وفي البداية تم الحفاظ على جودة المنتجات فقط من قبل المطورين أنفسهم - لم يكن هناك دور متخصص متخصص في ضمان الجودة ، وظهر قسم الاختبار وأول اختبار في المنتج قبل عام واحد فقط ، عندما بدأت المنتجات بالفعل.

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

1. الغوص في العملية


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


النضج خريطة الحرارة

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

2. نحن نقدم توصيات للتحسين




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

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • نقوم بإصلاح مراحل العدو السريع وإحدى النقاط الحرجة - النقطة "تجميد الرمز".

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

3. نقدم تحسيناتنا لقادة الفرق وأصحاب المصلحة ، مع التركيز على المشاكل التي ستحلها هذه التحسينات


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

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

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

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

ما الذي تغير


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

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



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

ما استطاع قسم الاختبارات لدينا القيام به خلال العام الماضي:

  • ظهر اختبار وظيفي منتظم في 7 منتجات من قسم البيانات الضخمة X5 Retail Group ، توصل 2 منها إلى إصدارات مستقرة في PROM دون تعليقات نقدية. نظمت اختبار الحمل المنتظم ل 3 منتجات.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

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

More articles:


All Articles