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

تنويه: هذا هو ترجمة لمقال . جميع الحقوق تنتمي إلى مؤلف المقال الأصلي وشركة ميرو.

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

أولا لفترة وجيزة حول عملية التنمية لدينا. لدينا إصدارات يومية من جانب العميل و 3 إلى 5 إصدارات أسبوعية من جانب الخادم. فريق لديه 60+ الناس يبصق على 10 فرق سكروم الوظيفية.

أنا أعمل في فريق التكامل. مهامنا هي:

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

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

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

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

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

الحالة 1: مهمة كرة الطاولة

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

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

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

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

الحالة 2: قائمة انتظار المهام يتم رفع

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

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

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

النتيجة من كلتا الحالتين في نفس الوقت - تعتمد الفرق أيضًا على اختبار المهندسين:

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

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

الفكرة الواضحة - دعنا نزيد كمية مهندسي الاختبار. قد يعمل ذلك حتى لحظة معينة: ستزيد كمية المهام ولكن من المستحيل زيادة عدد مهندسي الاختبار بشكل مستمر. سيكون مكلفا للغاية وغير فعالة.

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

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

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

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

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

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

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

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

بيان المهمة

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

الحل الفني

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

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

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

وصف المهمة

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

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

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

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

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

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

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

لإنشاء سيناريوهات الاختبار والاحتفاظ بها ، نستخدم HipTest.

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

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

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

الافراج عن وظيفة القيام به

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

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

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

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

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

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

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

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

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

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

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

ما ينبغي أن تضع في الاعتبار قبل إطلاق تجربة

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

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

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

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