يعد تطوير البرامج سريعًا وفعالًا أمرًا لا يمكن تصوره بدون مهام سير العمل الجيدة: يتم نقل كل مكون إلى التجميع في وقت التثبيت ، ولا يقف المنتج خاملاً. منذ عامين ، إلى جانب M.Video ، بدأنا في إدخال مثل هذا النهج في عملية التطوير في متاجر التجزئة واليوم نواصل تطويره. ما هي المجاميع الفرعية؟ أثمرت النتيجة بالكامل: بفضل التغييرات المنفذة ، كان من الممكن تسريع إصدار الإصدارات بنسبة 20-30 ٪. تريد بعض التفاصيل؟ أهلا وسهلا بك في الكواليس لدينا.

من سكروم إلى كانبان

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



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

ما هي ميزة كانبان؟ لا تنتظر الفرق نهاية السباق ، ولكن تجمع بين تغييراتها المحلية والفرع الرئيسي عند الانتهاء من المهمة ، في كل مرة تبحث عن تضارب التصادم. في اليوم المحدد ، يتم حظر جميع الارتباطات مع السيد وبدء اختبارات الانحدار.



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

الأتمتة في كل مكان

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

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

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

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

جنبا إلى جنب مع M.Video ، قمنا بأتمتة اختبار حاصرات بنسبة 95 ٪ ، من السيناريوهات المتبقية - بنحو 50 ٪. لماذا حوالي نصف غير الآلي؟ هناك العديد من الأسباب ، ومختلفة. هناك سيناريوهات بدائية غير قابلة للتشغيل الآلي. هناك حالات تكامل معقدة يتطلب التحضير لها العمل اليدوي ، على سبيل المثال ، الاتصال بالبنك وإلغاء طلب القرض ، والاتصال بقسم المبيعات وإلغاء الطلبات في بيئة إنتاجية.
أتمتة اختبارات الانحدار خفضت مدتها. ولكن ذهبنا إلى أبعد من ذلك واختبارات الدخان الآلي للحاصرات بعد كل دمج فروع القيادة مع الفرع الرئيسي.

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

غيركين لانقاذ

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

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

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

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

نحن لم نتوقف عند هذا الحد.

كتل وظيفة

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

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

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

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

المشكلة مع المدرجات

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

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

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

الكرز على الكعكة

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

بشكل عام ، تبدو العملية كما يلي: لقد وجدوا حادثة ، وأخذوها إلى العمل ، وأكملوها ، وسلموها للاختبار ، واختبروها ، وأغلقوها.



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



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

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

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

النتائج

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

نتائج الأتمتة:

• ما يصل إلى 4 أيام (بدلاً من الأيام العشرة السابقة) خفضت مدة اختبارات الانحدار ؛
• انخفض فريق الاختبار اليدوي بنسبة 50 ٪.
• من 30 إلى 35 يومًا ، تم تقليل الوقت المستغرق في السوق - منذ اللحظة التي دخلت فيها الميزة إلى تراكم الفريق حتى دخلت التجريبية.

اختبار أتمتة فريق ، جت Infosystems