Get best of the week

كيفية تنظيم الاختبار من أجل تسريع وتثبيت إصدارات المنتج. الجزء 2

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

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



شكل صياغة وقبول المهام والعيوب


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

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

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

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

  • حالة حيث يمكنك إعادة إنتاج الخطأ ؛
  • النتيجة الحقيقية والمتوقعة ؛
  • المهام الفرعية للواجهة الخلفية والواجهة الأمامية مع تعليمات واضحة للمطورين لإصلاحها. "الواجهة الخلفية: بالنسبة لواجهة برمجة التطبيقات هذه ، أعط الإجابة المقابلة للواجهة الأمامية" + مصفوفة من الخيارات التي توضح الإجابات التي يجب أن تكون في كل حالة من المواقف المحتملة. "الواجهة الأمامية: بالنسبة لواجهة برمجة التطبيقات هذه ، بناءً على الاستجابة من الخلف ، تُصدر نص الخطأ المقابل" + مصفوفة الخيارات.

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

الحصول على القاعدة المقابلة لوصف العيب:

  1. قم بإنشاء مهمة مع وصف مشكلة وظيفية ، وحالة لإعادة إنتاج الخطأ ، ورابط للتاريخ ، تم أثناء التحقق من وجود عيب فيه.
  2. . : , , API , use case . , , API, , , , , , .

رفضنا أيضًا تشكيل AC (معايير القبول) على منتجنا ، حيث أننا في مرحلة التخطيط لا نناقش فقط ما نقوم بتطويره واختباره ، ولكن أيضًا كيف.

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

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

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

يبدو أن خيارنا لا يساهم على الإطلاق في تسريع التنمية ، لأنه يتطلب المزيد من الخطوات للبدء. لكن الأمر ليس كذلك.

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

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

لحظات الاختبار


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

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

نتيجة لذلك ، حددنا خمس نقاط حيث يشارك المختبرون بنشاط في عملية التطوير:

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

في البداية ، عندما كان لدينا إصدارات كل أسبوعين ، بدا مخطط العمل كما يلي:



لقد أصبح (إصدار مرة واحدة في الأسبوع):



قواعد تفاعل الواجهة الخلفية - الاختبار - توصيل الواجهة الأمامية


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

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

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

تسريع إصلاح العيوب


في مرحلة تحديد المهمة ، يحدد عميل الأعمال الأولويات - فهو يعرف ما هو المطلوب وما هو الترتيب المطلوب لتطوير المنتج. ولكن بعد البدء في التطوير ، عندما تكون هناك مهام لإصلاح العيوب ، يلتزم المختبر بأولوياته.

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

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

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

وقد سمحت هذه الإجراءات ، إلى جانب المنطق الموحد المتمثل في طرح الكود على مطور البرامج وإطلاقه وهمزهتقليل فترة تصحيح العيوب من 3 أيام إلى 3-4 ساعات.

النتائج


على مدار 9 أشهر من عمل منتج أتمتة المشتريات ، تمكنا من تقصير دورة الإصدار من 2.5 أسبوعًا إلى أسبوع واحد مع إمكانية طرحها يوميًا ، مما يزيد بشكل كبير من استقرار الإصدارات.

ما الذي تغير:

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

BONUS: كان من الممكن تقليل مستوى الضغط في الفريق (آمل) ، وبفضل العمل المنسق للفريق (بفضل التسليم) ، يمكنني بسهولة الذهاب إلى جهاز التحكم عن بعد :-) من خلال تنفيذ

هذه التحسينات ، التزمنا بالعديد من القواعد:

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

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

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

More articles:


All Articles