اختر تتبع الأخطاء المناسب

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

مقدمة

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

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

من أين بدأنا ، أم جيرا

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

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

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



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

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

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

وداعا جيرا ، تحيا كايتن

في ربيع عام 2018 ، هجرنا جيرا وانتقلنا إلى كايتن. كان سبب تغيير الأدوات هو السبب الذي جعل أندريه أريفيف قد كتب في مقالته "لماذا بدأت Dodo Pizza في استخدام Kaiten بدلاً من حفنة من Trello و Jira". بعد الانتقال إلى Kaiten ، لم يتغير نهجنا في التعامل مع الأخطاء:

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

• تم تسجيل الأخطاء التي تم العثور عليها في prod في تراكم "مالك المنتج" وتحديد أولوياتها وتحديد تلك التي سنصلحها.

وقت التجربة أم لا

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

اعادة النمل

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



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

طريقتنا المثالية للتعامل مع الأخطاء الآن

في نهاية عام 2018 - بداية عام 2019 ، حدث عدد من التغييرات في شركتنا والتي أثرت على عملية العمل مع الأخطاء.

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

ثانياً ، لقد تخلينا عن اختبار الانحدار اليدوي لصالح التلقائية.

ثالثًا ، اعتمدنا "سياسة الخلل الصفري". في المقالة " #zerobugpolicy أو كيفية إصلاح الأخطاء " ، توضح bevzuk كيف نختار الأخطاء التي نصلحها .

اليوم عملية العمل مع الأخطاء هي كما يلي:

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

النتائج

باختصار ، لقد تخلينا عن نظام تتبع الأخطاء . باستخدام هذا النهج للعمل مع الأخطاء ، حللنا العديد من الآلام:

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

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

وكيف يتم ترتيب عملية التعامل مع الأخطاء في شركتك؟