متى تتوقف عن الاختبار؟

Question

في ممارستك، ما المقياس (المقاييس) الذي تستخدمه لمعرفة متى يحين وقت التوقف عن اختبار التطبيق ونقله إلى الإنتاج؟

Answer 1

بالنسبة للمشاريع في مؤسستي، فإن التدابير التي أستخدمها عادة هي كما يلي:

• لا توجد مشكلات تتعلق بالخطورة 1 (إظهار السدادة).
• لا توجد مشكلات تتعلق بالخطورة 2 (تعطيل الوظائف الرئيسية).
• عدد مقبول من مشكلات الخطورة 3 (الوظيفة الثانوية).

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

بمجرد استيفاء هذه الشروط المسبقة، سأعقد اجتماعًا لجميع أصحاب المصلحة (قائد ضمان الجودة، قائد التطوير، قائد دعم التطبيقات وما إلى ذلك)، وأراجع قائمة المشكلات المعلقة، وأتأكد من وجود اتفاق حول مدى الخطورة المخصصة لها القضايا العالقة.بمجرد التأكد من عدم وجود مشكلات معلقة في Sev 1 وSev 2، سأتلقى مكالمات "Go/No Go" من كل صاحب مصلحة.إذا قال الجميع "انطلق"، سأكون مرتاحًا للانتقال إلى الإنتاج.إذا قال أحد أصحاب المصلحة على الأقل "لا تذهب"، فإننا ندرس أسباب "عدم الذهاب"، وإذا لزم الأمر، نتخذ خطوات لحل المشكلات الكامنة وراء ذلك.

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

Answer 2

أولا، لا تتوقف أبدا عن الاختبار.متى أنت انتهيت من الاختبار وقمت بإصداره، كل هذا يعني أن المستخدمين لديك يقومون بالاختبار بدلاً منك.

ثانيًا، عندما تنجح نصوص الاختبار الشامل لديك بمستوى مقبول من الفشل، تكون جاهزًا للمضي قدمًا.

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

Answer 3

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

على سبيل المثال:

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

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

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

Answer 4

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

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

Answer 5

عندما ذهبت جميع سدادات العرض الرئيسية.

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

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

Answer 6

مهرين,

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

Answer 7

جون,

لم أقصد أن أقصد نصوص الاختبار الآلي اختبارات.كنت أشير إلى النهج الأكثر تقليدية المتمثل في قائمة خطوة بخطوة لما يجب اختباره وكيفية اختباره.

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

Answer 8

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