مرحباً هابر. في BackendConf الأخير ، تحدث أنطون أوليفسكي ، رئيس قسم اختبار البرمجيات ومراقبة الجودة ، عن أهم شيء ، وربما ، أهم شيء - وهو الموقف الواعي للعمل.
هذا هو الشيء. أصبحت سرعة تنفيذ أفكار الأعمال عاملاً رئيسياً. يتم تقدير هذه السرعة في SJ بمتوسط الوقت المستغرق لإكمال المهمة. في الشركة كانت هذه المرة تساوي 65 يومًا. نعم ، شهران من إنشاء مهمة وإرسالها إلى المستخدم.
يقول أنطون أنهم تمكنوا من تسريع العمليات 3 مرات بفضل الاختبار الواعي. الآن سنخبرك ما هو وكيف بالضبط.
كيف كان ذلك من قبل؟
كانت العملية على هذا النحو:
- يتم اختبار كل مهمة على حدة ؛
- دمج المهام النهائية في فرع الإصدار ؛
- عند الإصدار ، يتم إجراء اختبار القبول ؛
ثم الاندماج.
إذا كانت النتيجة ناجحة ، تم إرسال الإصدار إلى المستخدمين ، وكانت 50-60 مهمة في انتظار الاختبار معلقة باستمرار على اللوحة.
كيف عملت مع المهمة:
- من التطوير ، دخلت المهمة في الاختبار وفقدت في قائمة لا تنتهي من الآخرين ينتظرون ؛
- في القائمة ، يمكن أن تتدلى من يومين إلى شهر.
- ثم تم فحص المهمة من قبل المختبر ، تم عمل الأخطاء عليها وتم إرسالها إلى التطوير ؛
- قام المبرمج بإصلاح الخلل وأعاد المهمة مرة أخرى للاختبار.
تم تكرار الدورة ويمكن أن تتجمد المهمة في مرحلة الاختبار لعدة أشهر. من وجهة نظر فنية ، كان كل شيء على ما يرام ، وتم إصدار الميزات فقط ببطء وكان العمل غير سعيد. استمع المختبرون باستمرار إلى حقيقة أن التطور يسير ببطء شديد ، وانهيار المواعيد النهائية ، والأعمال التجارية تخسر المال.
مثل أي اختبار عادي ، يقرأ الرجال الكتب الذكية في الاختبار ويعتقدون أن الشيء الرئيسي هو جودة المنتج. مثل ، تحتاج إلى العثور على أكبر عدد ممكن من الأخطاء وإصلاحها كلها بالتأكيد. لكن لا.
لما لا؟
لأننا لا نحتاج إلى إصلاح الأخطاء ، ولكننا نساعد الشركة ، لذلك ذهب أنطون إلى منتج Dima للتعامل مع الموقف. هناك قرروا أن الشيء الرئيسي هو سرعة إصدار الميزات. والحقيقة هي أن الأعمال لا تحب أن تخسر الأموال في تطوير المشاريع وإصلاحها ، وهو أمر غير واضح ما إذا كان سيحقق فوائد. لذلك ، من الأفضل إطلاق مشروع غير كامل ، واستنادًا إلى نتائج نجاحه ، قرر ما إذا كان سيجعله مثاليًا أم يقلله. اجتمع المختبرون وحاولوا فهم كيفية زيادة سرعة الإصدار. اتضح أن كل شيء واضح.
لدى SJ قبول (مجموعة من الحالات في المجالات الرئيسية للوظيفة ، لفحص المنتج ككل ، على سبيل المثال ، إذن المستخدم ، والتوظيف ، وما إلى ذلك) ، والذي يتكون من 150 حالة ويستغرق 1.5 يومًا من المختبر. إنه طويل جداً.
على محمل الجد ، هذا عبارة عن 1.5 يومًا من الفحوصات اليدوية مرتين في الأسبوع. ما الذي يجب القيام به مع الفحوصات اليدوية المتكررة؟ أتمتة.
اتضح لأتمتة 100 حالة. ظلت الحالات غير المربحة للمشاركة في الأتمتة وإرسال الرسائل وتلقي الرسائل القصيرة غير مربحة. كان المختبرون سعداء ، حيث كانت هناك تكاليف منتظمة أقل لإصدارات الاختبار - 3 ساعات ، بدلاً من 1.5 يومًا. ثانيًا ، تقدم الاختبارات الذاتية ملاحظات سريعة حول ما إذا كان يجب بدء مشاهدة إصدار على الإطلاق والتقاط الأخطاء حتى قبل بدء المهمة في الإصدار.
تم تحديد كل شيء تقريبًا ، ولكن بعد ذلك جاء CTO.
ما الخطأ الآخر؟
جاء وقال أننا بحاجة لمعرفة أين لا تزال جرعة زائدة من ساعات العمل تذهب. جلس الرجال وأدركوا أن الإجراءات المتكررة كانت فقط في الإصدارات - كان القبول والاندماج.
ماذا عن التكامل. باختصار ، كان هناك موقف عندما أرسلوا إصدارًا وأصبح منتج Dim غاضبًا من أن المهمة التي وعدوا بها لم تأت إلى المعركة. بدأوا في معرفة أين ذهبت. اتضح أنه عند الاحتفاظ بالمهام لفرع الإصدار فقد بعض الالتزام وفقدت المهمة بصريًا للمستخدمين.
بدأ Devops في إصلاح البرامج النصية للبناء ، ويراجع المختبرون الحالات مرة أخرى لكل مهمة في الإصدار للتأكد من أن كل شيء سار معًا وأن جميع المهام في مكانها الصحيح. يبدو أنه من الصعب التحقق من المهام التي بدت بالفعل. ولكن اتضح أن هناك حوالي 5 مهام لكل اختبار في الإصدار ، وقد ظهرت حالات معقدة ، مثل تغيير شيء في قاعدة البيانات ، وتشغيل برنامج نصي ، والتحقق من الرسالة المستلمة. استغرقت هذه المرحلة بأكملها الكثير من الوقت: من 2 إلى 10 ساعات من عمل جميع المختبرين.
أخذ الرجال إحصاءات لعدة أشهر من هذه الممارسة وتبين أنه لم يكن هناك المزيد من الحالات مع ضعف إصدارات الإصدار وفي هذه المرحلة لم يكن هناك سوى بضع مرات من الأخطاء غير الحرجة التي تم تفويتها عند اختبار المهام. وزن جميع الإيجابيات والسلبيات وقررت التخلي عن هذه المرحلة.
حسنا الان؟
ليس بخير. في عالم تكنولوجيا المعلومات ، لا يمكنك الاستمتاع بالنجاح لفترة طويلة ، لأن هناك دائمًا شيء ما يجب تحسينه. في حالتنا ، تم إصدارها مرتين في الأسبوع. على سبيل المثال ، فحص المختبرون المهمة صباح الأربعاء وأرسلوها للإفراج ، ولن تصل إلى المستخدم إلا يوم الثلاثاء من الأسبوع المقبل.
ماذا ايضا؟ الكثير من الإصلاحات العاجلة من الأعمال. خططت الشركة لإطلاق ميزة لبعض التاريخ ، وأعلن عنها وأطلقت إعلانًا ، والمختبرون هم: "Litter ، مثلي الجنس ، لقد قمنا بتخطيط إصدارات هنا وستبدأ المهمة في الأسبوع المقبل فقط." لذلك ، بالنسبة لكل مهمة من هذا القبيل ، لجأ إليها المنتج Dima.
ويعلم الجميع أنه إذا دخلت ديما في التنمية ، فانتظر الاستعجال. تعبت مثل هذه الغارات من devs والمختبرين. أليس هذا سببا للذهاب إلى غرفة الاجتماعات مرة أخرى ؟! جميعهم أقفلوا أنفسهم معًا وقرروا أن العمل يحتاج إلى الإفراج في كثير من الأحيان ، لذلك تحتاج إلى أتمتة أكثر ، والتحقق من الإصدار في ثلاث ساعات ، وأتمتة الإنشاء اليومي للإصدار وتكوين إطلاق الاختبارات التلقائية على الإصدار وإجراء القبول كل يوم.
كان هذا انتصارًا صغيرًا ، لأن الميزات امتدت بعد اختبار الحد الأقصى في اليوم التالي. كانت هناك مشكلات أقل في الإصلاحات الساخنة ، وتم إرسال بعضها إلى الإصدار الحالي ، وكان البعض ينتظرون إصدار الغد. هذا سمح للمختبرين بعدم تشتيت انتباههم عن طريق هذه الفحوصات وإتاحة الوقت لاختبار المهام الجديدة. بالمناسبة ، لم تتغير الإحصائيات حول الأخطاء التي لم يتم العثور عليها.
ثم جاءت الفاحصة جوليا إلى أنطون وقالت إنها سئمت من ذلك. مثل ، افعل ما تريد ، لكنها لم تعد قادرة على القيام بقبول كل يوم ، بالنظر إلى حقيقة أنه وفقًا للوظيفة الرئيسية ، نادرًا ما يتغير شيء ما ولا يجد أخطاء. لذلك ، عرضت جوليا إجراء القبول مرة واحدة في الأسبوع.
حسنا ، حسنا مثليون جنسيا.
وكيف هي؟
وفر الوقت - 12 ساعة في الأسبوع لاختبار المهام الجديدة ، وقلة الحافز على الشيكات الرتيبة. من السلبيات - يمكن أن تعيش البق حتى 5 أيام من تاريخ الظهور. تم عمل الكثير بنجاح للإسراع ، ولكن في نفس الوقت ، ليس لدى الرجال تأثير كبير على أهم شيء - متوسط الوقت المستغرق لإكمال مهمة في الإنتاج.
تقدموا نحو الهدف ، لكنهم لم يصلوا إليه. نعم ، يمكن للمختبرين تكريس وقتهم لمهام جديدة ، ولكن بالنسبة لسرعة المرور ، كان هناك انخفاض في الدلو.
غادر أنتون للتفكير في المهام التي تخضع للاختبار وأدرك أن كل شيء تقريبًا. والتيار ضخم ، مثل خندق ماريانا ، لذلك من المستحيل معالجة كل شيء. لذلك ، تقرر تحديد الأولويات. في هذه المرحلة ، ساعد المنتج Dima ، الذي تحقق ، مع Anton ، للتحقق من كل شيء غير مهم للأعمال.
بقيت فقط النقاط المتعلقة مباشرة بالمال والأشياء الحرجة للمستخدمين.
باختصار ، لم يتبق سوى 50 عنصرًا من قائمة تضم 300 عنصر.
يمكنك العمل بالفعل مع هذا. بالمناسبة ، ما هي المكافآت التي يمنحها تطوير الويب؟
- القدرة على الاستجابة بسرعة للأخطاء الموجودة في المعركة ؛
- مراقبة المشكلات عبر الإنترنت ؛
- الدعم الفني على اتصال مع المستخدمين.
الآن أهم شيء. نعم ، تعلمك كتب الاختبار كيفية اختبار كل شيء ، لكن كل الظروف أخبرت أنطون أنه ليس كل شيء يحتاج إلى اختبار. وفقا لأنطون ، في هذه الأيام الثلاثة من التفكير ، شعر بأن هاملت في سؤاله "أن أكون أو لا أكون".
جمع كل إرادته في قبضة ، قرر ما يجب أن يكون. ورفض اختبار وظائف غير مهمة. بدأ المختبرون في صب المهام على تلك النقاط الـ 250 بعد التطوير على الفور في الإصدار. بجدية.
لن توافق كل شركة على مثل هذه الخطوة ، وجميع المختبرين الذين يرفضون الاختبار يرفضون الإشاعة. لكن هذا القرار جعل من الممكن التركيز على المهم حقا.
يعد الفشل في الاختبار خطوة مسؤولة وخطيرة.
إذا كنت تريد أيضًا القيام بذلك:- قائمة الوظائف المهمة متاحة للجمهور حتى يتمكن المطورون من الوصول إليها ؛
- لتقييم النهج الجديد ، أضف إلى Jira العلاقة "التي تم إنشاؤها في => spawned". لذلك يمكنك تتبع عدد الأخطاء التي تمر بها في مهام غير قابلة للاختبار ؛
- نظرًا لأنه ليس من الغباء الشديد اختبار معظم المهام ، تحقق من حالتين رئيسيتين فيها ، ولكن في الإصدار حتى لا تبطئ التدفق ؛
- وظيفة حرجة للاختبار وفقًا للمخطط القديم.
ماذا سيتغير؟- ستتوقف معظم المهام عن الانزلاق أثناء مرحلة الاختبار ؛
- سيتعامل المختبرون مع المهام الهامة للأعمال فقط ؛
- يتم أخذ الشيء المهم في الاختبار بشكل أسرع ، لأن غير المهم الآن لا يتدخل على اللوحة.
ما هو سيء للغاية- من المرجح أن يواجه المستخدمون الحقيقيون أخطاء بسيطة ؛
- يزداد الحمل على الدعم الفني ، لأن الأخطاء الفائتة تبدأ في الظهور من المستخدمين.
هل تأذى؟
أكمل الرجال جميع الخطوات الموصوفة في غضون ستة أشهر. نعم ، لقد تألم ، ولكن الناتج كان على النحو التالي:
تم تقليل متوسط الوقت المستغرق لإكمال المهمة إلى 19 يومًا وهو يتناقص باستمرار ؛
يتم تقليل تدفق مهام الاختبار. بدأ المختبرون في الاستعداد لاختبار الميزات المهمة بالتوازي مع التطوير ؛
توقف منتج Dima تمامًا عن الذهاب إلى Anton.
بدلا من الاستنتاجات
لا تستخدم نهجنا في الطب أو بناء الطائرات. في المواقف التي لا ترتبط بخطر على الحياة - اختبر قراراتك ونهجك.
لا تصدق الكتب وتوقف عن الاختبار من أجل الاختبار ، ببساطة لأنه مكتوب في مكان ما.
اسأل نفسك عما إذا كنت تلبي توقعات العمل وما إذا كان كل عنصر في قائمة المهام الخاصة بك مفيدًا حقًا.
كان SuperJob معك. الوعي للجميع!