اليوم ، يحتفل العالم بيوم المختبر. في هذه المناسبة ، قررنا مساعدتك في إلقاء نظرة على عمل هؤلاء المتخصصين من وجهات نظر مختلفة ، حتى يحقق التعاون لجميع المشاركين أقصى قدر من الفائدة والحد الأدنى من الضغط.
مصدر الصورة: David Goehring CC BY
1. "تحقق مرة أخرى ، لا يوجد بالتأكيد خطأ"
لنبدأ بالمشكلة الأساسية. يحتوي منتدى Ars Technica على خيط قديم يتحدث فيه أحد المطورين عن الكراهية العميقة للمختبرين "المتحذلقين". انه منزعج للغاية من أن بعض خبراء الاختبار يقضون ساعات في البحث عن أصغر الأخطاء. وما هو غير سار للغاية ، ما زالوا يجدونها.
ما يمكن أن يحدث خطأ : ليس الجميع على استعداد للاعتراف بأخطائهم. يبدأ شخص أغنية قديمة عن "ليس خطأ ، ولكن ميزة" ، في محاولة لإثبات أن كل شيء كان المقصود. يطلب الآخرون باستمرار التحقق مرة أخرى من الرمز والتأكد من عدم وجود خطأ. يحاول المختبر فقط أن يقوم بعمله بشكل جيد ، وبدلاً من الامتنان يتم إرساله لإعادة الفحص.
كيف تكون : الأمر بسيط: إذا وجد المختبر خللاً في التعليمات البرمجية الخاصة بك وفهمت أنه على حق ، فمن الأفضل الاعتراف بهذه الحقيقة. كلاكما لديهما هدف واحد - لإطلاق منتج تصحيح وتصحيح. الفكاهة تساعد على فهم هذه المسألة. في ما يلي مقالة جمع فيها المختبرون "صندوقًا ذهبيًا" لبيانات مطورين يحاولون حماية شفرتهم. ننصحك بالاطلاع عليها وتخيل كيف تبدو هذه العبارات "الكلاسيكية" من وجهة نظر المختبر.
2. "قبل أسبوع من الإفراج. آمل أنك لم تخطط لأشياء أخرى لليومين القادمين ".
في بعض الأحيان يأتي الرمز إلى المختبرين قبل الإصدار ببضعة أيام. ثم عليهم العمل على عجل. يعتقد بعض خبراء ضمان الجودة أن الزملاء ببساطة يقللون من شأن عملهم. يُزعم أنهم يعتقدون أن العثور على الأخطاء أمر سهل وسريع ، لذلك قاموا بتأجيل تصحيح الأخطاء في اللحظة الأخيرة.
ما قد يحدث خطأ : في حالة الطوارئ ، لا ينزعج المختبرون فحسب ، بل يفقدون يقظتهم أيضًا. يعد ضيق الوقت أحد الأسباب الرئيسية وراء تخطي المختبرين للأخطاء.
كيف تكون : هناك العديد من نماذج التطوير. من وجهة نظر ضمان الجودة ، هناك نهجان رئيسيان: المتتالية وأجيل. في الحالة الأولى ، يتلقى المختبرون أجزاء من التعليمات البرمجية على مراحل. في الحالة الثانية ، يقومون باختبار الرمز بالتوازي مع كتابته.
تساعد رشيقة على إشراك محترفي ضمان الجودة في المشروع في وقت مبكر. بفضل هذا ، ليس عليك اختبار "ساعة قبل الإصدار". بالإضافة إلى ذلك ، لا يسمح هذا النهج بالعثور على الأخطاء ، ولكن لمنع حدوثها. إذا كان المختبرون يشكون من ضغط الوقت المستمر ويفقدون الأخطاء ، ألق نظرة على هذه المنهجية.
الصورة: Tim Regan CC BY
3. "قمت بتعديل التعليمات البرمجية بسرعة. انظر من فضلك. "
افترض أن فريقك يعمل على نموذج متتالي ويعرف كيف يخطط مراحل التطوير بشكل صحيح. يحصل المختبرون على الرمز ، ويبدو أن هناك وقتًا كافيًا لتصحيح الأخطاء. ولكن لدى المطورين عادة بذل الحد الأدنى من الجهد في هذه المرحلة. يتلقون تقريرًا تفصيليًا بالأخطاء ، ويقرؤونه بشكل سطحي ، ويزيلون بسرعة الأخطاء الواضحة ويرسلون الرمز إلى دورة الاختبار التالية.
ما الخطأ الذي قد يحدث : المشكلة هي أن الكود بعد التغييرات السطحية غالبًا ما يعود بمزيد من الأخطاء. قضى المختبر وقتًا في إعداد تقرير مفصل ، وردًا على ذلك تلقى نوعًا من الرد. عليه أن يذهب بهذه الطريقة عدة مرات لمجرد أن المطور لا يريد قضاء الوقت على "الأخطاء الطفيفة".
كيف تكون : من الواضح ، لا تتسرع. لكن هذا لا يكفي. تحتاج إلى معرفة سبب عدم إيلاء الاهتمام الواجب للتقرير. إذا كان هذا هو الكسل المبتذلة ، يمكنك فقط مساعدة نفسك. هناك أسباب أخرى. على سبيل المثال ، تعتقد أن مهندسي ضمان الجودة يغرقونك بتقارير عن أخطاء غير مهمة. ثم تحتاج إلى توضيح هذه القضية على مستوى القيادة - إذا كان المختبرون يشتتون انتباهك "في التفاصيل". على الأرجح ، سيكون الجواب نعم. حتى أن بعض مديري المنتجات يطلبون من المطورين إضافة أخطاء صغيرة على وجه التحديد إلى الشفرة بحيث يكون المختبرون على أهبة الاستعداد دائمًا. من المهم اتباع هذا النهج ومعالجة تقارير الأخطاء مع الاهتمام الواجب.
4. "يبدو أنني قد تعاملت بالفعل مع هذا الخطأ. لكنني لا أتذكر بالضبط "
في بعض الأحيان يكون النهج السطحي مشكلة نظامية. في بعض الفرق ، تُفقد تقارير الأخطاء في الزمان والمكان. لا أحد يستجيب بشكل صحيح للتقارير ، ولا يشير إلى ما إذا كان قد تم حل المشكلة أم أنها لا تزال في طي النسيان.
ما يمكن أن يحدث خطأ : يعمل المطورون على إصلاح نوع من الأخطاء ، وإجراء ما يعتقدون أنه تغييرات "ثانوية" على الشفرة ، ونسيان إخطار المختبرين بذلك ، وإرسال الرمز إلى الإصدار. ونتيجة لذلك ، تظهر المشكلة عندما يفوت الأوان. وغالبًا ما يكون المختبر "المتطرف".
كيف تكون : يجب حل مشكلة الفوضى بشكل منهجي. تضر الفوضى بالتطور ، لذا يجب عليك إعادة هيكلة عملية الاتصال بالكامل في الفريق. هنا يجدر استخدام النصائح الأساسية لإنشاء الاتصال بين المطورين والمهندسين ضمان الجودة: لتحديد المصطلحات ؛ صياغة المتطلبات بوضوح ؛ إدخال التسلسل الهرمي للأولوية لمختلف الأخطاء. أما بالنسبة للخلط مع البق ، فهناك نصائح عملية جيدة: أ) دع البق يبلّغ عن كل شيء ؛ ب) من المهم بعد ذلك ترتيبها حسب الأولوية ؛ ج) أي خلل مغلق يعني أنه سيتم كتابة اختبار وظيفي ؛ د) لم يتم تعيين الحالة "تم حلها" بواسطة المطور ، ولكن بواسطة المختبر. يضمن هذا النهج أن يتم حل المشكلة حقا.
الصورة: Tim Regan CC BY
5. "لماذا يجب أن أختبر هذا؟ أنا لست مختبرا! "
في بعض الفرق ، تقع مسؤولية تصحيح الأخطاء بالكامل على عاتق المختبرين. لا يهتم المطورون بإضاعة الوقت في أكثر اختبارات الوحدة وضوحًا. إنهم على يقين من أن هذه ليست وظيفتهم. بشكل عام ، على الرغم من وجود وجهات نظر مختلفة حول هذه القضية (يمكن الاطلاع على آراء المجتمع هنا ).
ما يمكن أن يحدث خطأ : يجب على المختبرين في هذه الحالة التعامل مع جميع أوجه القصور على التوالي - حتى مع الأخطاء الأكثر بدائية وغباء. بالطبع هذا مزعج.
كيف تكون : يفضل العديد من المطورين اختبارات مستقلة قبل إرسالها إلى قسم ضمان الجودة. هذا لا يساعد فقط على تخفيف المختبرين ، ولكن أيضًا على تعلم النظر إلى المنتج من وجهة نظر الناقد والمستخدم. ويعتقد أن هذا مفيد للمحترفين وله أفضل تأثير على النتيجة النهائية. بالنسبة لأولئك الذين لا يريدون أن يزعجوا أنفسهم بالشيكات ، هناك أدوات تلقائية. أنها تساعد في العثور على الأخطاء الأكثر وضوحا. على أي حال ، حتى إذا كان لدى الفريق مهندسون لضمان الجودة ، فإن الفصل الصارم بين المطورين وضمان الجودة ليس هو أفضل نهج.
6. "إيغور ، اليوم تعمل جنبًا إلى جنب مع أوليغ. سوف تعجبك
لا يقتصر مديرو المنتجات على نهج المتتالية و Agile. البعض منهم يحب التجربة. على سبيل المثال ، قم بترتيب زوج من جلسات البرمجة والاختبار.
ما قد يحدث خطأ : هذه طريقة فعالة للقبض على الأخطاء ، ولكن لها أيضًا عيوب - قد لا يكون الناس متحمسين للابتكارات. قد يكون أخصائي ضمان الجودة ، الذي اعتاد على العمل بمفرده ، في طابق آخر وعلى معداته ، غير مرتاحًا لمغادرة البيئة المألوفة. بالإضافة إلى ذلك ، قد لا يكون مبتذلًا مع خبرة ومعرفة الشريك. ونتيجة لذلك ، بدلاً من الاختبارات الإنتاجية ، يحصل مديرو المنتجات على موظفين غير راضين.
كيف تكون : النصيحة الرئيسية هي عدم قطع كتفك. قد تبدو ممارسات Agile و DevOps جذابة ، لكنها لن تنجح بدون التحضير المناسب.
7. "سآخذ جهازك للاختبارات ، هل تمانع؟"
المطور لديه الوقت لبدء التصحيح ، يسأل المختبر لجهاز اختبار "حرفيا لمدة 20 دقيقة" ويترك معه لساعات طويلة.
ما الذي قد يحدث خطأ : في أغلب الأحيان ، لا يعيد المطور الجهاز إلى مكانه على الإطلاق ، وإذا حدث ذلك ، فسيتم تفريغه بالكامل. وبالنظر إلى أن المختبرين يمكن أن يكون لديهم مهام متوازية على هذا الجهاز ، لا يمكن إلا أن يزعجوا.
كيف تكون : ضع لنفسك تذكيرًا ، ألصق ملصقات ، افعل أي شيء ، ولكن يرجى إعادة أشياء المختبرين إلى مكانهم وفي الوقت المحدد.
الصورة: Dave Allen CC BY
والنصيحة الرئيسية للمطورين ومديري المنتجات ، والتي تقترح نفسها من كل ما سبق: احترام عمل الآخرين ووقتهم ، وفي كثير من الأحيان تضع نفسك في مكان المختبر. بعد كل شيء ، إن لم يكن له ، لكان العالم كله يعرف عن البق الخاص بك.