تصميم حالة الاختبار ومسؤولية المختبرين والمطورين والعملاء [مغلقون

Question

لذلك يبدو أن الكثير من الناس يلعبون لعبة اللوم في المكان الذي أعمل فيه ، ويطرح سؤالًا مثيرًا للاهتمام.

المعروفين:

المتطلبات فريق يكتب متطلبات المنتج. يقوم المطورون بإنشاء اختبارات الوحدة الخاصة بهم وفقًا للمتطلبات. يقوم فريق الاختبار بإنشاء شروط الاختبار وتصميم الاختبار وحالات الاختبار وفقًا للمتطلبات.

تم إصدار المنتج إذا وفقط إذا تم تمرير X ٪ من حالات الاختبار من فريق الاختبار.

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

سؤال:

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

Answer 1

البيان "المنتج الذي تم إصداره إذا وفقط إذا كان X ٪ من Testcases من Testing Team يمر" يزعجني حقًا. قد يرغب الفريق في التفكير في الحصول على معايير إصدار أفضل والتي يتم وضعها في أكثر من مجرد معدلات تمرير. على سبيل المثال ، هل السيناريوهات معروفة ، مفهومة ، تم حسابها (واختبارها)؟ بالتأكيد لن يتم إصلاح كل الأخطاء ، ولكن هل تم تأجيلها أو عدم إصلاحها بشكل صحيح؟ هل وصلت إلى أهداف اختبار الإجهاد والأداء الخاص بك؟ هل تهديد على غرار وحساب التخفيف من التهديدات المحتملة؟ هل تم نشر X كمية من العملاء (داخلي/خارجي) تم نشرهم وقدموا ملاحظات قبل الإصدار (أي "Dogfood")؟ هل يفهم المطورون الأخطاء القادمة من الحقل والمختبرين لإنشاء اختبارات وحدة الانحدار؟ هل يفهم فريق المتطلبات هذه الأخطاء القادمة لمعرفة سبب عدم حساب السيناريوهات؟ هل هناك نقاط تكامل رئيسية بين الميزات التي لم يتم حسابها في المواصفات أو التطوير أو الاختبار؟

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

Answer 2

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

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

Answer 3

السؤال الأول في ذهني هو "كيف تتكدس العيوب مقابل المتطلبات؟"

إذا قرأ المتطلب ، "يجب أن يكون زر OK Blue" وأن العيب هو "زر موافق أخضر" ، فأنا ألوم التطوير والاختبار - بوضوح ، لا أقرأ المتطلبات. من ناحية أخرى ، إذا كانت الشكوى ، "زر OK ليس أصفر" ، بوضوح ، كانت هناك مشكلة في جمع المتطلبات أو عملية التحكم في التغيير.

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

Answer 4

"المنتج الذي تم إصداره إذا وفقط إذا تم مرور X ٪ من حالات الاختبار من فريق الاختبار" - هو أحد المعايير للإصدار. في هذه الحالة ، "تغطية الاختبارات" في TCS المكتوبة مهمة للغاية. إنه يحتاج إلى مراجعة جيدة لـ TCS سواء تم تفويت أي وظيفة أو سيناريو أم لا. إذا تم تفويت أي شيء في TCS ، فقد يكون هناك إمكانية للعثور على الأخطاء لأن بعض المتطلبات غير مشمولة في حالات الاختبار.

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

إذا وجد العميل/العميل أي خطأ/عيب ، فمن الضروري التحقيق على النحو التالي: I) ما نوع الأخطاء الموجودة؟ 2) هل هناك أي حالة اختبار مكتوبة بخصوص ذلك؟ (3) إذا كانت هناك حالة (قضية) اختبار فيما يتعلق بتنفيذها بشكل صحيح؟ 4) إذا كان غائبًا في TCS ، فلماذا فاته؟ وهلم جرا

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