الجودة هي مسؤولية الفريق. لدينا تجربة ضمان الجودة

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

أولا ، لفترة وجيزة حول عملية التنمية لدينا. لدينا إصدارات عملاء يومية و 3 إلى 5 إصدارات خادم في الأسبوع. يضم فريق التطوير أكثر من 60 شخصًا مقسمًا إلى 10 فرق سكروم وظيفية.

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

كيف بدأت التجربة؟

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

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

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

القصة الأولى: تراجع المهمة التي لا نهاية لها

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

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



نتيجة لذلك ، يزداد إجمالي وقت العمل في المهمة عدة مرات ، تليها زيادة الوقت في السوق ، وهذا أمر بالغ الأهمية بالنسبة لنا كشركة أغذية. هناك عدة أسباب لزيادة الوقت الذي تستغرقه المهمة:

1. المهمة تتحول باستمرار بين التطوير والاختبار.
2. المهمة هي الخمول في انتظار اختبار أو المطور.
3. يتعين على المطور والاختبار التبديل بين المهام بانتظام ، الأمر الذي يتطلب وقتًا إضافيًا وطاقة.

القصة الثانية: خط متزايد من المهام

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

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

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

الاستنتاج من كلتا القصتين هو نفسه - تعتمد الفرق كثيرا على اختبار:

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

دعونا زيادة موظفي اختبار؟

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

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

دعونا تحسين عمليات التنمية

أهداف التجربة:

• لإزالة اعتماد الفريق على المختبرين ، ولكن دون فقدان الجودة والوقت.
• تحسين ضمان الجودة من قبل المهندسين QA في فرق.

كانت الخطوة الأولى هي تغيير تفكير الفريق. الجميع معتادون على حقيقة أن المختبر مسؤول عن جودة الفريق.

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

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

1. عرض الإنتاج.
2. الحل التقني وسيناريو الاختبار.
3. التنمية والتحقق.
4. الافراج عنهم.

بيان المشكلة

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

الحل الفني

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

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

فيما يلي مثال لبعض الكتل من الحل التقني:

وصف المهمة

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

هل يتغير نموذج البيانات؟

للخادم نحن نتحدث عن الأشياء والنماذج.
إذا كان نموذج البيانات معقدًا ، يمكنك تقديمه في شكل مخطط UML ، أو كتوصيف نصي.

هل التفاعل بين العميل والخادم يتغير؟

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

سيناريو الاختبار

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

لتجميع وتخزين البرامج النصية نستخدم HipTest.

التنمية والتحقق من الصحة

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

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

الافراج عن وظيفة جاهزة

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

الوثائق والأدوات

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

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

نتائج التجربة

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



يمكن ملاحظة أن مستوى الخط الأحمر ظل في نفس المستوى ، باستثناء الانفجار في بداية التجربة. لا يوجد المزيد من الأخطاء ، مما يعني أننا حافظنا على المستوى الحالي للجودة.

في الوقت نفسه ، انخفض متوسط ​​وقت العمل في المهام بنسبة 2٪ فقط: قبل بدء التجربة ، كانت 12 ساعة و 40 دقيقة ، وبعد - 12 ساعة و 25 دقيقة. لذلك تمكنا من الحفاظ على السرعة الحالية للعمل على المهام.

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

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

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

أشياء يجب تذكرها قبل بدء التجربة

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

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

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

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