الجمعة العظيمة الجميع ، الأصدقاء! في نهاية يونيو ، نطلق مجموعة جديدة في دورة
أخصائي ضمان الجودة ، والتي ستكون محور نشر اليوم.
هناك العديد من المؤشرات التي يمكنك من خلالها قياس فعالية فريق الاختبار. أحدها هو نسبة العيوب المرفوضة ، أو عدد تقارير الخطأ المرفوضة مقسومة على العدد الإجمالي للتقارير المستلمة. يجب أن تفكر في أنه إذا كان عدد التقارير المرفوضة هو صفر ، فهذا جيد ، لكنه ليس بهذه البساطة. دعونا نلقي نظرة على أنواع الأخطاء المرفوضة ، ونرى كيف تؤثر على معدل الخطأ المرفوض ، ونحسب النسبة الصحيحة لفريقك.
هناك ثلاث فئات من الأخطاء المرفوضة:
- أخطاء غير قابلة للإنتاج ؛
- أخطاء غير صحيحة
- أخطاء مكررة.
لنبدأ بالأخطاء نفسها.
أخطاء غير قابلة للإنتاج
هناك نوعان من الأخطاء غير القابلة للإصلاح. الأول خطأ يصعب إعادة إنتاجه. قد يكون هذا خطأ ناتج عن تفاعل عدة معلمات ، بعضها لا تعرفه حتى.
افترض أنك أجريت العديد من الاختبارات على التوالي ، وأن أحد الاختبارات قام بتغيير معلمة التكوين من القيمة الافتراضية أ إلى بعض القيم الأخرى ب. يحدث الخطأ فقط عندما تحتوي معلمة التكوين على القيمة B وتكون قيمة الإدخال هي C. عند محاولة إعادة إنشاء الخطأ ، من المرجح أنك سترغب في البدء بحالة معروفة من أجل تهيئة النظام (أو ، ربما ، إجراء تثبيت نظيف). لن يحدث أي خطأ لأن المعلمة التكوين الآن مرة أخرى تحتوي على القيمة الافتراضية أ.
البديل الآخر لهذا النوع من الخطأ غير القابل للإنتاج هو عندما يكون الاختبار قد وجد بالفعل خللًا ، ولكن لا توجد بيانات في معلومات التشغيل: خطوة أو قيمة إدخال محددة أو فهم يحدث الخطأ فقط مع إجراء معين. نتيجة لذلك ، لا تؤدي محاولات إعادة إنشاء الخطأ إلى أي شيء.
في كلتا الحالتين المذكورتين أعلاه ، ومع ذلك ، هناك بالفعل خلل في المنتج نفسه.
النوع الثاني من الخطأ غير القابل للإصلاح هو عندما لا يمكن تكرار الخطأ لأنه غير موجود. ربما يكون المختبر قد لاحظ شيئًا ما ، لكن قد أسيء تفسيره ، أو قد يواجه النظام المستخدم للاختبار نوعًا من المشكلات ، مثل مكون جهاز خاطئ أو برنامج تشغيل غير متوافق أو إعدادات وصول غير صحيحة. تفشل محاولات إعادة إنشاء الخطأ على نظام مكون بشكل صحيح.
عادةً ما يتم وضع علامة على كلا النوعين من الأخطاء في أنظمة الإبلاغ عن الأخطاء على أنه "مرفوض - لا يمكن إعادة إنتاجه".
أخطاء غير صحيحة
يحدث هذا النوع من الخطأ إذا قرر المختبر أن المنتج يجب أن يتصرف بطريقة معينة ويبلغ عن خطأ عندما لا يفي السلوك بتوقعاته. ومع ذلك ، توضح دراسة أكثر تفصيلاً للمتطلبات أن توقعات المختبر كانت خاطئة وأن المنتج يعمل بشكل صحيح بالفعل. وهذا يعني أن المنتج الذي تم اختباره يعمل بشكل صحيح ، وقد أخطأ الفاحص الذي لم يكن على دراية كافية بالمتطلبات.
عادةً ما يتم وضع علامة على هذه الأخطاء في أنظمة الإبلاغ عن الأخطاء باعتبارها "مرفوضة - لا خطأ" أو "مرفوضة - من قبل الهندسة المعمارية" (أي أن السلوك يتسق مع البنية).
أخطاء مكررة
الأخطاء المتكررة هي تلك الأخطاء التي أبلغ عنها الشخص بالفعل ، والتقارير التالية بعدها. يكون الخطأ متكرراً فقط إذا كانت "أعراض" ظهوره متماثلة. وإذا كان السبب الجذري للخطأ هو نفسه ، ولكن تبين أن "الأعراض" مختلفة ، فهذا ليس تكرار الخطأ!
يتم تمييز هذه الأخطاء عادة في أنظمة الإبلاغ عن الأخطاء بأنها "مرفوضة - مكررة / مكررة".
كيف تؤثر الأخطاء المرفوضة على الفريق
من الواضح أن الخطأ غير الصحيح هو نوع من مضيعة الوقت الذي يقضيه المختبر في إعادة إنتاج الخطأ والإبلاغ عنه ، والوقت الذي يقضيه أولئك الذين يصنفون الأخطاء في قراءتها وفهمها ، والوقت الذي يقضيه المطورون في محاولة إعادة إنتاج خطأ غير قابل للإنتاج أو لإصلاح (وخلل) شيء لا يحتاج إلى هذا الإصلاح.
بالإضافة إلى حقيقة أن نسبة الخطأ المرفوضة أو RDR هي مقياس لعدم كفاءة فريق الاختبار ، فإنه يتحدث أيضًا عن مهنية المحترفين بشكل عام. يشير الخطأ الذي لا يمكن استنساخه بسبب عدم توفر المعلومات اللازمة في التقرير إلى أن الفاحصين لم يكونوا دقيقين ولم يعملوا بجد كافٍ لإعادة إنتاج هذا الخطأ باستخدام الخطوات الموضحة أعلاه. بالإضافة إلى ذلك ، بالنسبة للأخطاء التي يتم تكرارها بشكل متكرر ، لم يلاحظ المختبرون بشكل عام تردد التشغيل المنخفض في التقرير.
يشير ظهور خطأ غير صحيح إلى أن المختبرين لا يفهمون تمامًا متطلبات المنتج. تشير الأخطاء المتكررة إلى أن الفاحصين لم يقوموا بالحد الأدنى من البحث في قاعدة بيانات الأخطاء المحلية للتحقق مما إذا كان قد حدث في وقت سابق. أو ، هذا يعني أن المتخصص الذي أبلغ عن هذا الخطأ لم يكن أول من أدرج الكلمات الأساسية الصحيحة في الاسم لتسهيل البحث عن زملائه الآخرين.
بالمقابل ، إذا تبين أن الخطأ الذي وجدته مرفوض ، فأنا أشعر بالاستياء لأنني اعتُبرت شخصًا عاديًا. من ناحية ، هذا يعني أنني سأدافع عن الأخطاء التي تم العثور عليها. عندما يتم رفض تقريري ، أتابع ما يلي:
- أتحقق مرة أخرى مما إذا كان الخطأ يتكاثر في نظامي وأضيف خطوات التشغيل إذا فاتني شيء ما ؛
- إذا كان سوء فهم المتطلبات الخاص بي ناجمًا عن شرط غامض أو وثائق غير صحيحة ، فسوف أصر على أن يتم تمييز الخطأ كخطأ في الوثائق وإغلاقه فقط عند تصحيح الوثائق ؛
- إذا كنت تعتقد أن سلوك المنتج عند الوفاء بالمتطلبات غير صحيح ، فسأتحدث عن المتطلبات مع المهندسين المعماريين والمطورين ، وحاول إقناعهم بضرورة تحديث المتطلبات (في النهاية ، أمثل رأي العميل!) ؛
- إذا تم رفض الخطأ باعتباره تكرارًا ، فسوف أتأكد من أنه لم يتم تمييزه بالطريقة نفسها ، أو أنه لا يظهر "وفقًا للسيناريو نفسه".
من ناحية أخرى ، هناك احتمال معين لرفض الخطأ يجعلني حذرا. إذا لم أكن متأكدًا تمامًا من أنني عثرت على خطأ ، فسوف أقضي بعض الوقت في التحقق قبل الإبلاغ. غالبًا ما أسأل أحد الزملاء عما إذا كنت أفسر المتطلبات بشكل صحيح ، أو أتحقق مما إذا كان الخطأ مستنسخًا على نظام شخص آخر.
الرأي ضد الغياب التام للأخطاء المرفوضة
يجب على فريق الاختبار مراقبة مستوى RDR والسعي لتحقيقه. والسؤال الوحيد هو ، ما RDR ينبغي اعتبارها جيدة؟
للوهلة الأولى ، يبدو أن 0٪ هي النتيجة المثلى ، لكنني لا أوافق بشدة على ذلك. أعتقد أنه عندما يتم الحفاظ على RDR في بعض المستويات الصحية ، فهذا أمر طبيعي ، لأنه إذا كان قريبًا من الصفر ، فمن الواضح أن فريق الاختبار يعاني من مشاكل ليست أقل خطورة من RDR عالية للغاية.
يجب أن يبذل فريق الاختبار جهودًا كبيرة لتحقيق معدل منخفض للغاية من حالات RDR. سيتم تحليل كل خطأ مرفوض لفهم الخطأ الذي حدث ، وسيحتاج كل اختبار قام بالإبلاغ عن خطأ تم رفضه إلى توضيح ما حدث بالفعل وكيف يمكن تجنب مثل هذا الموقف في المستقبل. نتيجة لذلك ، سيقوم المختبرون بالإبلاغ عن الأخطاء التي يكونون متأكدين تمامًا من خلالها.
إذا لاحظوا سلوكًا يعتقدون أنه سيضر بإمكانية استخدام المنتج ، فسيفضلون اتخاذ مثل هذا السلوك كأمر مسلم به ، بدلاً من تبرير أنهم قد وجدوا خطأًا ، في الواقع ، ليس خطأ استنادًا إلى المتطلبات. إذا كانت لديهم أدلة على حدوث خطأ ، ولكن لا يوجد سيناريو جيد لاستنساخه ، فسيفضلون عدم الإبلاغ عنه ؛ انهم حقا لا يريدون أن يزعجوا أنفسهم. إذا واجهوا خطأ تافه ، فقد يقررون عدم الإبلاغ عنه على الإطلاق ، لأن الأخطاء الطفيفة لا تعمل دائمًا على حلها ، فلماذا تخاطر وتخشى أن الخطأ الذي وجدته سيتم رفضه؟
باختصار ، السعي إلى الحصول على RDR منخفض للغاية يولد التوتر والسلوك غير الصحي في فريق الاختبار ، ويزيد أيضًا من احتمال أن تمر بعض الأخطاء دون أن يلاحظها أحد.
نحتاج إلى مختبرين لا يقومون بالإبلاغ عن الأخطاء الواضحة فحسب ، بل يحذرون أيضًا من أي سلوك مشبوه في المشروع. نعتقد أن المختبرين الذين يولون أهمية كبيرة لضمان عدم تخطي الخطأ ، حتى على حساب التقارير المكررة ، أفضل من المختبرين الذين يمضون ساعات في التحقق مما إذا كان قد تم الإبلاغ عن خطأ بالفعل في التقارير أم لا ، خوفًا من أنهم جعل مكررة. نريد أن يشعر المختبرون بالراحة من خلال التشكيك في كلمة مهندس النظام أو مواصفات المتطلبات ، حتى لو كان ذلك يعني أن بعض أخطائهم سيتم تعليمها على أنها مرفوضة.
نحتاج إلى مختبرين لا يخشون ارتكاب أخطاء من وقت لآخر. هذا يعني أن هناك حاجة إلى التوازن ، لذلك يعتبر بعض RDR الصغيرة مقبولة.
العثور على أفضل عيب رفض معامل
قاعدتي الأساسية هي أن RDR يجب أن يكون 15 بالمائة. تستند هذه القيمة إلى تجربتي مع فريق الاختبار ، والذي كان ، بكل المقاييس ، فريقًا جيدًا وفعالًا. كان لدينا RDR خلال العديد من المشاريع التي ذهبت واحدة تلو الأخرى ، في حين أن الفريق الآخر ، الذي كان يعمل في نفس المشاريع وبالتوازي معنا ، على الرغم من أنه كان أقل وعي المنتج واعتبر أقل فعالية ، وكان RDR 30 في المئة .
لا أعتقد أن هناك أي مبرر لهذا المعنى بخلاف شعوري الداخلي. هذا بالتأكيد ليس علميًا. لن أجادل مع فريق يهدف إلى 10 أو 20 بالمائة ، لكنني أعتقد أن طرح 30 بالمائة أو تحديد هدف 5 بالمائة يمثل مشكلة بالفعل.
في النهاية ، هذا قرار يجب أن يتخذه فريق الاختبار ، استنادًا إلى ميزات المنتج ومستوى خبرة الفريق ونموذج التطوير وخبرة فريق التطوير والمزيد. أوصي بشدة أن تراقب RDR وتفكر فيما إذا كنت بحاجة إلى القيام بشيء ما. وإذا كانت مرتفعة أو منخفضة للغاية ، يجب اتخاذ التدابير المناسبة.
وفقًا للتقاليد ، ننتظر تعليقاتك وندعوك إلى
ندوة عبر الإنترنت مجانًا ، والتي ستعقد في 14 يونيو. اراك قريبا!