كيفية قياس جودة منتج البرمجيات

Question

لدي منتج، X، نقوم بتسليمه إلى العميل، C كل شهر، بما في ذلك إصلاحات الأخطاء والتحسينات والتطوير الجديد وما إلى ذلك.) كل شهر، يُطلب مني أن أخطئ في "ضمان" جودة المنتج.

ولهذا نستخدم عددًا من الإحصائيات التي تم الحصول عليها من الاختبارات التي نقوم بها، مثل:

• معدل إعادة الفتح (عدد الأخطاء التي أعيد فتحها/عدد الأخطاء التي تم تصحيحها والتي تم اختبارها)
• معدل الأخطاء الجديد (عدد الأخطاء الجديدة، بما في ذلك الانحدارات، والأخطاء التي تم اكتشافها أثناء الاختبار/عدد الأخطاء التي تم تصحيحها والتي تم اختبارها)
• لكل تحسين جديد، معدل الأخطاء الجديد (عدد الأخطاء الموجودة لهذا التحسين/عدد أيام العمل)

وشخصيات أخرى مختلفة.

من المستحيل، لأسباب لن نخوض فيها، أن نختبر كل شيء في كل مرة.

إذن سؤالي هو:

كيف يمكنني تقدير عدد ونوع الأخطاء المتبقية في برنامجي؟ما هي استراتيجيات الاختبار التي يجب علي اتباعها للتأكد من أن المنتج جيد؟

أعلم أن هذا سؤال مفتوح إلى حد ما، ولكن مهلاً، أعلم أيضًا أنه لا توجد حلول بسيطة.

شكرًا.

Answer 1

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

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

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

أيضًا، هذا أمر زائد عن الحاجة وواضح بعض الشيء، ولكن تأكد من أن لديك برنامجًا جيدًا لتتبع الأخطاء.:)

Answer 2

السؤال هو من الذي يطلب منك تقديم الإحصائيات.

إذا كان الأمر يتعلق بأشخاص غير تقنيين، فقم بتزييف الإحصائيات.أعني بكلمة "مزيفة" "تقديم أي أرقام حقيقية لا معنى لها حتماً" من النوع الذي ذكرته.

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

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

Answer 3

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

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

Answer 4

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

كيفية حساب المخاطر؟

إذا كان ذلك حادثًا ، فهذا 5 إذا كان حادثًا ، لكن يمكنك توفير عمل حوله ، فهو رقم أقل من 5.إذا كان الخطأ يقلل من الوظيفة، فهو 4

كيفية حساب الاحتمال؟

هل يمكنك إعادة إنتاجه في كل مرة تقوم فيها بالتشغيل، إنها 5.إذا كان الحل البديل المقدم لا يزال يتسبب في تعطله، فأقل من 5

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

Answer 5

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

Answer 6

الأسئلة التي سمعتها كانت، كيف يمكنني تقدير الأخطاء الموجودة في برنامجي؟وما هي التقنيات التي أستخدمها للتأكد من أن الجودة جيدة؟

بدلاً من متابعة دورة كاملة، إليك طريقتان.

كيف يمكنني تقدير الأخطاء في برنامجي؟

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

ما هي التقنيات التي أستخدمها للتأكد من أن الجودة جيدة؟

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

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

نأمل أن تعطيك هذه بداية جيدة.حظ سعيد!

Answer 7

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

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