يبحث قسم ضمان الجودة (QA) عن الأخطاء في البرنامج. تختلف الطرق من شركة إلى أخرى ، ولكن يتم ذلك عادة من قبل الموظفين الذين لديهم دراية بالبرنامج. يستخدمونها بطرق مختلفة ويحاولون العثور على الأخطاء التي أخطأها المطورون.
يمكن أن يشير مصطلح ضمان الجودة إلى العملية نفسها ، إلى المنظمة ، وكذلك إلى اختبار فردي داخل هذه المنظمة. عادةً ، يطلق على المختبرين في مؤسسة ضمان الجودة "ضمان الجودة". في هذه المقالة ، من أجل التناسق ، سوف نستخدم اختصار ضمان الجودة المشترك بدلاً من "اختبار ضمان الجودة" الأكثر دقة.
الشركات المختلفة لديها مسؤوليات مختلفة عن ضمان الجودة عن الجودة الشاملة للمنتج. في بعض الأحيان ، لا ينطبق مصطلح "ضمان الجودة" تمامًا على هذا القسم إذا كان يبحث فقط عن الأخطاء ويحسب عددها.
فيما يلي الأفراد ذوو المشكلات في قسم ضمان الجودة:
خرطوم الحريق
اختبار يقوم بالإبلاغ عن العديد من تقارير الأخطاء بسرعة أن فريق التطوير لن ينتهي أبداً.
- يمكن أن يتحول إلى مثيري الإنذار
- إنه أمر خطير مع مدير المشروع مثل الإحصاءات
- احتمالية التصحيح: عالية
- خطر للمشروع: عالية
المشكلة
إذا تم العثور على خطأ ، فمن المهم تقديم تقرير واضح وتعيينه على الفور إلى المطور المناسب. ومع ذلك ، فإن بعض المختبرين قادرون على العثور على الأخطاء بشكل أسرع من إصلاح فريق التطوير لهم. ولهذا السبب ، فإن قائمة الأخطاء تنمو باستمرار ، ولا يمكن إغلاقها جميعًا.
للوهلة الأولى ، قد يبدو أن هناك مشكلة في جودة المنتج ، ولكن هذا ليس هو الحال دائمًا. على عكس المختبر التقليدي ، الذي يعمل مع برنامج عربات التي تجرها الدواب للغاية ، يولد خرطوم الحريق مجموعة هائلة من التقارير مع واحد أو أكثر من الخصائص المميزة:
- تقاريرهم سيئة التفصيل ، مما يتيح الإبلاغ بشكل أسرع عن المزيد من الأخطاء.
- العديد من الأخطاء هي تكرارات للآخرين ، لأنها مجرد أشكال لسبب رئيسي واحد.
- لا يوجد وقت لإعادة إنتاج الخطأ ، لأنه يكفي رؤيته مرة واحدة لكتابة تقرير.
غالبًا ما تظهر أجهزة اختبار خراطيم الحريق تحت ضغط الشركة المباشر أو غير المباشر:
فكلما وجدت أخطاءً كلما كان عملك أفضل . هذا يؤدي إلى حقيقة أن اختبار QA ، الذين يراقبون بعناية السبب الحقيقي للأخطاء ويبلغون عنها بوضوح وإيجاز ، يعتبرون أقل إنتاجية من خراطيم الحريق التي تصدر أكبر عدد ممكن من التقارير لكل وحدة زمنية.
يمكن أن تسبب أنشطة هؤلاء المختبرين حالة من الذعر في المشروع ، لأنه يبدو أن المنتج ذو جودة رديئة ، وأن المشروع الآن متخلف عن الجدول الزمني. يمكن أن يكون تأثيرهم على الروح المعنوية فوريًا ودراميًا: يصلي فريق التطوير لمقاطعة تدفق تقارير الأخطاء.
الحل
قبل إصلاح خرطوم الحريق ، من الضروري تحديده بدقة وعدم الخلط بينه وبين ضمان الجودة الفعال الذي يصطدم بنظام عربات التي تجرها الدواب للغاية. أوضح دليل يأتي من شكاوى المطور:
- معظم الأخطاء مكررة.
- العديد من الأخطاء لها نفس الأسباب الجذرية الواضحة ، لذلك يمكن الإبلاغ عنها كأخطاء واحدة.
- رسائل الخطأ لا تحتوي على تفاصيل.
لعلاج هذا الوضع ، يجب توضيح خرطوم الحريق بأنه لا يوجد حافز للإبلاغ عن عدد كبير من الأخطاء ، والهدف هو تحسين جودة النظام ومساعدة المطورين. بعد ذلك ، يجب تحسين جودة المنتج بنفس الوتيرة (أو الأفضل) ، ولكن دون ذعر.
المدعي العام
سؤال وجواب ، بعد كل خطأ وجدت تتهم المطورين بعدم اختبار برنامجهم.
- يمكن أن يتحول إلى مثيري الإنذار
- إنه أمر خطير في تركيبة مع مدير المشروع مثل الإحصاءات
- احتمالية التصحيح: عالية
- خطر للمشروع: منخفضة
المشكلة
من الناحية النظرية ، يمكن للمطور العثور على أي خلل وإصلاحه قبل نقل المنتج إلى قسم ضمان الجودة. لذلك ، يرى بعض المختبرين أن كل خطأ تم العثور عليه كدليل آخر على أن المطورين لا يختبرون عملهم بشكل جيد بما فيه الكفاية. هذه الحجة التي لا يمكن دحضها تسمح للمدعي بالتعبير بصوت عالٍ عن رأي رافض حول فريق التطوير.
المدعي العام يأكل معنويات الفريق. بدلاً من المساعدة في تحسين جودة المنتج ، يحاول إثبات أن فريق التطوير لا يقوم بهذه المهمة. تتم إضافة كل خطأ إلى كومة الأدلة التي تعتمد على المطورين بشكل مفرط على ضمان الجودة بدلاً من تحديد الأخطاء من تلقاء أنفسهم.
لسوء الحظ ، يتم إنشاء المدعين العامين نتيجة لعملية نموذجية ويمكن التنبؤ بها إلى حد ما:
- تم اكتشاف خطأ فادح في الإنتاج.
- المختبر متهم بفقدان هذا الخطأ.
يحدث هذا في كثير من الأحيان ، وبالتالي تدافع ضمان الجودة بشكل طبيعي عن طريق استخدام حجة لا يمكن دحضها.
الحل
قبل تصحيح أي متهم ، يجب على المؤسسة أولاً إيقاف إلقاء اللوم على ضمان الجودة في أخطاء الإنتاج. يجب أن يتم تدريب من يقومون بذلك على طرق أكثر إنتاجية لتحسين جودة البرمجيات.
عندما تتوقف المؤسسة عن إلقاء اللوم على ضمان الجودة في الخلل في الإنتاج ، يمكنك إصلاح متهم المختبر بدعوته لتغيير رأيه وموقفه.
يجب تقديمه إلى أن المطورين هم مجرد أشخاص ، ويميل كل الناس إلى ارتكاب الأخطاء. يجب على قسم ضمان الجودة تعويض هذه الخاصية البشرية الطبيعية للمطورين ، كحماية ضد الأخطاء التي تؤثر على العملاء. بالإضافة إلى ذلك ، نظرًا لعملية الترميز المملة والشاقة ، من السهل جدًا على أي مطور عدم رؤية الغابة وراء الأشجار: إنه يركز بشدة على حل مشكلة معينة لدرجة أنه ينسى البحث عن أشياء تبدو واضحة.
تغيير المواقف: يجب أن نتذكر أننا نعمل جميعًا في فريق ، ولا ينبغي أن يلوم الرفاق بعضهم بعضًا على ارتكاب الأخطاء ، ولكن يجب أن يساعدوا في تصحيحها لما فيه خير الفريق. من المهم بشكل خاص أن تنشئ ضمان الجودة شراكات مع فريق التطوير من أجل المشروع ، كما أن العملية المستمرة دون انقطاع للكشف عن الأخطاء والإبلاغ ودورة حياة إصلاحها تعتبر ضرورية لجودة المنتج.
المنبه
ضمان الجودة ، والتي تنص على أن المنتج بأكمله لديه مستوى غير مقبول من الجودة ، في حين أن رأيه يعتمد فقط على انطباع سطحي.
المشكلة
في جوهرها ، ميزات التطبيق المختلفة لها جودة مختلفة. قد يكون بعضها بسيطًا نسبيًا أو مطورًا بواسطة مطورين ذوي مهارات عالية ، وبالتالي لا توجد أخطاء قليلة أو لا توجد أخطاء. البعض الآخر متطور نسبيًا أو مطور من قِبل المطورين الأقل خبرة ، وبالتالي فهو مليء بالأخطاء. لم يكن المحظوظ محظوظًا في مواجهة منطقة ذات جودة رديئة على الفور -
وبدون أي تحقيق إضافي ، أعلن أن المنتج بأكمله غير مناسب .
يمكنك التحدث كثيرًا حول كيفية قيام مطوري ضمان الجودة بإضاعة وقتهم (انظر اختبار النوع
المضلل ) ، ولكن هذا موقف مزدوج. في الواقع ، في كثير من الأحيان ، يعطي المطور بوعي برنامج ضمان الجودة الذي تم اختباره بشكل جيد للحصول على مكافأة مقابل العمل المنجز أو للادعاء بأنه تفي بالموعد النهائي. عندما تبدأ QA في اختبار مثل هذا النظام ، فإنها تواجه على الفور الكثير من الأخطاء التي كان يجب على المطور رؤيتها. لذلك ، من الواضح أنه يستنتج ما رآه للمنتج بأكمله ويدعي جودة منخفضة للغاية.
عادة ما يكون لدى المنبه بعض السلطة في قسم ضمان الجودة ، ويتم احترام رأيه. كلما ارتفع مستوى سلطته ، زاد الأثر المدمر على المشروع. السيناريو النموذجي هو كما يلي:
- يتم نقل المنتج إلى ضمان الجودة.
- يبدأ المنبه في اختبار منطقة ذات جودة رهيبة.
- يوقف المنبه كل الاختبارات ويبلغ السلطات بمشكلة خطيرة تتعلق بجودة المنتج.
هذه هي حالة كلاسيكية من رمي طفل بالماء. في بعض الأحيان ، تقوم إدارة ضمان الجودة بالاختيار الصحيح ، لا سيما عندما يتمتع فريق التطوير بسمعة طيبة لنقل البرامج التي لم يتم التحقق منها إلى ضمان الجودة. ولكن يحدث أن ينطلق الإنذار بسبب مطور ضعيف واحد ، والذي كان رمزه هو أول من وصل إلى صانع الذعر.
الحل
يصبح الفاحص مثيراً للانزعاج إذا خذله فريق التطوير مراراً وتكراراً. إذا كانت تقدم دائمًا برامج عالية الجودة ، فلن يكون هناك سبب لعدم الثقة. ولكن إذا أصبح الفاحص مثار قلق ، فسيكون من الصعب على فريق التطوير استعادة الثقة ، خاصة إذا كان لدى الفريق مطورون بالفعل
فيل في متجر الصين وغير
كفء .
عادة ، في فرق التطوير الكبيرة ، ينشأ كود منخفض الجودة من مطورين فرديين ، وليس من الفريق بأكمله. لذلك ، لا بد من اختبار عمل المطورين الأقل كفاءة أخيرًا ، أو ألا يندرج في المنبه. ومع ذلك ، فإن هذا يخفي المشكلة الحقيقية المتمثلة في وجود
مطورين في الفريق
يؤثرون سلبًا على المشروع .
عالم
اختبار يقضي معظم وقته في توثيق الأخطاء ، وليس البحث عن أخطاء جديدة.
المشكلة
يمكن أن تكون العثور على مشاكل في النظام مثيرة مثل البحث عن الكنز. وعندما تجد هذا الكنز ، فإنه ليس أقل إثارة للاهتمام في حل اللغز. يمكن القول أن المختبر الذي يعتبر أن عملية البحث عن الأخطاء بهذه الطريقة مثالية. ولكن تنشأ مشكلة إذا كان يسعى إلى توثيق رحلته الرائعة بعناية. بدلاً من التركيز على القضية الرئيسية ، يضطر المطور إلى قراءة قصة طويلة مع العديد من التفاصيل غير المفيدة ، في محاولة لتحديد المعلومات ذات الصلة.
يدرك العالم حرفيًا شرط "توثيق الأخطاء بعناية". يصفهم في شكل سجل نصي ، وليس وصفًا موجزًا مع تسلسل واضح من خطوات الاستنساخ. تستغرق قراءة هذه التقارير الكثير من الوقت ، وفي النهاية لا يزال من غير الواضح ماهية المشكلة بالضبط. عادةً ما يتضمن هذا الوصف العديد من الأخطاء ، أثناء الإشارة إلى مساحة واسعة من النظام ، وليس إلى مشكلة محددة.
الشكوى الرئيسية من المطورين عند تلقي رسائل خطأ من العلماء هي أن نسبة الإشارة إلى الضوضاء منخفضة للغاية. يقضون الوقت في غربلة مجرى الوعي ، ويبحثون عن تفاصيل محددة. هذا هو مضيعة للوقت لكل من المطور واختبار.
الحل
من السهل تصحيح عالم ضمان الجودة من خلال تعليمه كيفية كتابة التقارير الصحيحة. في كثير من الأحيان ، يتم التصحيح فورًا بمجرد شرح ما هو مطلوب منه. الطريقة الأكثر فعالية لتدريس الأسلوب الصحيح هي إعادة كتابة تقرير واحد أو أكثر بالتنسيق الصحيح ، والذي سيكون بمثابة نموذج للمستقبل. نتيجةً لذلك ، سيقوم المختبر المتحمس بكتابة تقارير واضحة وموجزة عن الأخطاء التي لا يمكن جعلها أكثر مثالية.
مضللة
يؤدي ضمان الجودة ، الذي غالبًا ما يبلغ عن الأخطاء بشكل غير دقيق ، إلى قيادة المطور بطريقة خاطئة عندما يحاول إعادة إنتاج المشكلة وحلها.
- يمكن أن يتحول إلى رجال الإنذار
- إنه أمر خطير في تركيبة مع مدير المشروع مثل الإحصاءات
- احتمالية التصحيح: عالية
- خطر للمشروع: عالية
المشكلة
يجب أن يتضمن تقرير الخطأ ما يلي:
- القدرة على تحديد أن هناك بالفعل خطأ
- القدرة على تحديد خطوات للعب الشوائب
- وصف كامل للخطأ ، وغالبًا ما يكون السبب الجذري
- خطوات واضحة للعب علة
في أي من هذه المراحل ، يمكن أن يؤدي التقرير إلى تضليل المطور ، مما يؤدي إلى إضاعة الوقت:
- إذا لم يكن هناك خطأ ، فإن المطور يقضي وقتًا في البحث عن مشكلة غير موجودة
- إذا كان الخطأ لا يمكن استنساخه ، فإن المطور يقضي وقتًا في استنساخه
- إذا لم يتم وصف الخطأ بشكل صحيح ، يقضي المطور وقتًا في البحث عن سبب جذر محدد أو واسع جدًا
- إذا كانت خطوات الاستنساخ غير دقيقة ، فإن المطور يقضي وقتًا في محاولة تفسيرها أو قد لا يعلن أي خطأ ، على الرغم من أنه يقوم بذلك
في بعض الأحيان يحصل المطور على حيرة بسبب خطأ بسيط في الاختبار. لكن الفاحص المضلل غالبا ما يولد مثل هذه التقارير ، مما تسبب في استياء كبير بين المطورين. إذا استمر هذا الوضع ، فسيفقد المختبر في النهاية ثقة المطورين ، وسوف يتوقف هؤلاء عن إصلاح الأخطاء الحقيقية ، ويرفضون تقارير الخطأ هذه.
الحل
غالبًا ما يكون ضمان الجودة المضلل مفيدًا في العثور على الأخطاء ، ويؤدي إلى توثيقها فقط. لذلك ، الأمر يستحق الجهد لتدريبه.
واحدة من أكثر الطرق فعالية هي مراقبة المطور ، الذي يحاول ، بناءً على تقريره ، تحديد المشكلة. ما عليك سوى الجلوس بجوار المطور الذي تلقى أحد تقاريره ولاحظ بهدوء (دون تدخل) كيف يحاول المطور معرفة ذلك. عادة ما يؤدي ذلك إلى إجراء محادثة صحية حول أفضل طريقة للإبلاغ عن الأخطاء ، والتي ستفيد كل من المطور و QA.
مضطهد
ضمان الجودة ، الذي تغلب عليه المطورون لدرجة أنه من غير المرجح أن يبلغ عن أي أخطاء ، خوفًا من التنمر من جانبهم.
المشكلة
ربما ليس هناك مظهر من مظاهر التساهل أكثر من الموقف المعتاد للمطورين تجاه ضمان الجودة. بالإضافة إلى ذلك ، يمكن للمرء في كثير من الأحيان أن يرى أن المطورين العدوانيين يخيفون المختبر بشكل علني ، حتى لو كان قد أبلغ عن خطأ طبيعي في الكود. لمواجهة ذلك ، يجب أن يكون ضمان الجودة الناجح عند العمل مع المطورين العدوانيين الخصائص التالية:
- حصل بالفعل على ثقة كبيرة من المطورين ، لذلك دائمًا ما تتم معالجة أخطاءه على محمل الجد.
- قادرة على إظهار ما لا يقل عن العدوان والمثابرة في نزاع مع المطور الذي لا يتعرف على الخطأ.
لسوء الحظ ، ليس لدى العديد من المختبرين هذه الخصائص ، لذلك غالبًا ما يمسح المطورون أقدامهم عنها ويتهمون ضمان الجودة في الأساس باكتشاف خطأ جديد. بغض النظر عن مدى قد يبدو غير منطقي ، فهذه صورة نموذجية وفقًا للشروط التالية:
- يمتلك المطور إحساسًا كبيرًا بالأهمية الذاتية (راجع مطورًا مثل prima donna )
- يعتقد المطور أنه يعرف بشكل أفضل من المختبر كيفية عمل النظام (راجع مطورًا مثل محتجز الرهائن )
بعد أن يتم التغلب بشكل كامل على ضمان الجودة بمرور الوقت ، فإنه عادة ما يتجنب المواجهة مع المطورين العدائيين لتقليل التوتر. نتيجة لذلك ، نادراً ما يتم الإبلاغ عن الأخطاء التي تحدث من هؤلاء المطورين المحددين ، على الرغم من احتمال وجودها. وكقاعدة عامة ، يتم اكتشاف الموقف فقط عندما تنشأ مشاكل في الإنتاج ويبدأ التحقيق لماذا لم يكشف قسم الاختبار عن خطأ. سوف يقدم اختبار الاكتئاب أي من التفسيرات التالية:
- لقد تحدث مع المطور ، وقال إن هذا ليس خطأ.
- قدم تقريرًا بالأخطاء ، لكن المطور رفضها.
- لقد وجد خطأ ، لكنه "لم يظن أنه مهم بما فيه الكفاية".
غالبًا ما تجعل الشخصية غير الفعالة من الصعب التعرف على ضمان الجودة المظلوم. سيكون المفتاح هو تحليل المطورين الذين تعمل معهم ضمان الجودة - للبحث عن علامات واضحة على العداء.
الحل
المطورين في كثير من الأحيان يسخرون مباشرة اختبار. وبالتالي ، ينبغي معاملتهم مثل أي مثيري الشغب:
- مطالبة بالتوقف الفوري للسخرية من ضمان الجودة والامتناع عن السلوك العدواني.
- تدريب الاتصالات المهنية.
- تجاهل إذا كان المطور لا يستطيع إصلاح سلوكه.
في الحالات الشديدة بشكل خاص ، سيتعين على إدارة شؤون الموظفين التدخل ، خاصةً إذا تدهور الوضع إلى عداء مفتوح.
من المحزن أن هذا الموقف هو المعيار وليس الاستثناء. الفرق الوحيد هو درجة العداء.
الفرس عشوائي
سؤال وجواب يبحث عن الأخطاء بطريقة النقر العشوائي.
المشكلة
يتم البحث عن الأخطاء في النظام بطريقتين رئيسيتين:
- وفقًا لخطة الاختبار من خلال المعالجة المنهجية لقائمة حالات الاختبار.
- تجول عشوائي حول التطبيق في محاولة لمحاكاة تصرفات المستخدم.
تعد كتابة خطة اختبار مهمة تستغرق وقتًا طويلًا ، وليس هناك ما يضمن أنه بحلول وقت بدء الاختبار ، ستظل الخطة ذات صلة بعد تغيير المتطلبات. يمكن أن يؤدي هذا إلى حقيقة أن المختبر يتخلى تمامًا عن خطط الاختبار ، ويتفاعل بدلاً من ذلك مع التطبيق على أمل العثور على الأخطاء.
في الواقع ، التفاعل التفاعلي مع التطبيق يكشف عن أخطاء ، خاصة في مرحلة مبكرة من تطوير المنتج. ومع ذلك ، فمع تقدم المنتج في العمر ، سيكون العثور على الأخطاء بهذه الطريقة أكثر صعوبة ، حيث يتم إخفاء الأخطاء المتبقية في حالات الحدود. هذا يؤدي إلى شعور زائف بالأمان ، كما لو أن التطبيق لا يحتوي على أخطاء ، على الرغم من أنه ببساطة لم يتم اختباره كما ينبغي.
من المهم أن تتذكر أن التفاعل العشوائي مع التطبيق يظل منهجية مقبولة ، حيث يمكن أن يكشف عن المواقف التي لم يتم توثيقها في الخطة. , .
الحل
:
- , .
- .
, . , , , .
, . , — . , , , .
, -, .
المشكلة
— , QA . , : , . , - : , , .
- :
, , . QA-, , , . , , . «», , , , , .
الحل
, . , , , . , , , QA , , , , , , .
, . QA, , . , , .
غالبًا ما يكون إزالة اختبار جريء بلا مبالاة أكثر من محاولة إصلاحه. من خلال تصرفاته ، من الواضح أنه يوضح أنه لا يريد الانخراط في الاختبار ، لذا فإن إزالته هي في المصلحة المشتركة.انظر أيضا: