-
العنوان الأصلي: لماذا لا يتم إصلاح الأخطاء
المؤلف: آلان بيج، مدير التميز في هندسة الاختبار في Microsoft، شارك في تأليف كتاب How We Test Software at Microsoft (المترجم بالصينية باسم "طريقة اختبار برمجيات Microsoft").
ترجمة: لو Yueli، لو Mengyan، وانغ هونغ
لقد واجهت مؤخرًا المزيد والمزيد من الأشخاص الذين فوجئوا بأننا سنطلق منتجًا به عربات التي تجرها الدواب. ما أدهشني هو أن العديد من هؤلاء الأشخاص كانوا من مختبري البرمجيات، واعتقدت أنهم يعرفون ذلك بالفعل. أقترح عليك قراءة مقال إريك سينك السابق (ولكنه ممتاز) أولاً. لست متأكدًا من مدى قدرتي على المساهمة في هذا الموضوع، لكني أريد أن أحاول.
العديد من الأخطاء لا تستحق الإصلاح. "هل أنت أحد المختبرين؟"، سوف تصرخ في وجهي، "المختبرون هم حراس جودة المنتج." يمكنني تكرار ذلك مرة أخرى (إذا لزم الأمر) فالعديد من الأخطاء لا تستحق الإصلاح. "دعني أخبرك بالسبب. في معظم الحالات، يتطلب إصلاح الخلل تغيير الكود. ويتطلب تغيير الكود استثمارًا للموارد (الوقت) ويؤدي إلى مخاطر. هذا أمر سيئ، لكنه صحيح. في بعض الأحيان، إذا كانت المخاطر والاستثمار بعيدًا تفوق قيمة إصلاح الأخطاء، لذلك لن نصلحها.
إن قرارنا بشأن إصلاح الخلل لا يعتمد، ولا ينبغي أن يكون، على "الإحساس". أحب استخدام مفهوم "ألم المستخدم" لمساعدتي في اتخاذ القرارات. أستخدم ثلاثة عوامل رئيسية للنظر في "ألم المستخدم" وتحديده:
1. الخطورة - ما هو تأثير هذا الخطأ - هل سيؤدي إلى تعطل البرنامج بأكمله؟ هل سيؤدي ذلك إلى فقدان معلومات المستخدم؟ أم أن الأمر ليس بهذه الخطورة؟ هل هناك حل أسهل؟ أم أنها مجرد مسألة لا علاقة لها بالموضوع؟
2. التردد - هل يواجه المستخدمون هذه المشكلة بشكل متكرر؟ هل هو جزء من سير العمل الرئيسي للبرنامج؟ أم أنها مخفية في ميزة غير شائعة الاستخدام؟ من المحتمل أن تحتاج المشكلات الصغيرة الموجودة في الأجزاء الأكثر استخدامًا من البرنامج إلى الإصلاح، في حين يمكن وضع بعض المشكلات الكبيرة الموجودة في الأجزاء الأقل استخدامًا من البرنامج جانبًا.
3. التأثير على العملاء – إذا قمت بأداء واجبك بشكل جيد، فيجب أن تعرف بالفعل من هم عملاؤك وعدد المستخدمين (أو العدد الذي تأمل أن يكون لديك) في كل مجموعة من مجموعات عملائك. ثم عليك أن تقرر ما إذا كانت هذه المشكلة ستؤثر على كل مستخدم أم على بعض الأشخاص فقط. إذا كان بإمكانك تتبع كيفية استخدام العملاء لمنتجك، فيمكنك الحصول على بيانات أكثر دقة.
العوامل الثلاثة المذكورة أعلاه تشكل صيغة. قم بتعيين مجموعة من القيم لكل عامل من العوامل المذكورة أعلاه وقم بإجراء بعض الحسابات - يمكنك إضافة أو ضرب أو إضافة أوزان مباشرة بناءً على تطبيقك وعوامل السوق. على سبيل المثال، نحتاج فقط إلى إجراء عملية الجمع وتعيين نطاق رقمي من 10 نقاط لكل خطأ.
الخطأ رقم 1: على سبيل المثال هو خلل يعطل البرنامج (10 نقاط)، وهو موجود في جزء رئيسي من البرنامج (10 نقاط)، ويؤثر على 80% من العملاء (8 نقاط)، لذلك يتسبب هذا الخلل "ألم المستخدم" "حجم الصوت هو 28 نقطة ونراهن أننا سنصلحه.
الخطأ رقم 2: إنه مجرد خطأ في الترتيب (نقطتان)، يظهر في النافذة الثانوية (نقطتان)، وجزء البرنامج الذي يوجد به الخطأ سيتم استخدامه فقط في الإصدارات الأقدم (نقطتان). ولذلك فإن قيمة "ألم المستخدم" لهذا الخطأ هي 6 نقاط، وربما لن نتمكن من إصلاحه.
لسوء الحظ، العديد من الحالات ليست بهذه البساطة كما هو مذكور أعلاه. الخطأ رقم 3 هو مشكلة فقدان البيانات (10 نقاط) الموجودة في جزء كبير من التطبيق ولكنها تفشل فقط في ظل ظروف معينة (5 نقاط) (البيانات ذاتية، بالمناسبة)). تثبت أبحاث العملاء أنه نادرًا ما يستخدم (نقطتان). ولذلك فإن قيمة "ألم المستخدم" الخاصة بها هي 17 نقطة، وهذه بيانات غامضة، ويمكن تعديلها أم لا. من ناحية، فإن الاستثمار المطلوب لإصلاحها قد لا يستحق كل هذا العناء، ولكن طالما أن المشكلة مفهومة ولا تحتوي على أي نقاط عمياء، فمن المحتمل أن يكون تجاهل الخطأ هو النهج الصحيح.
ومن ناحية أخرى، عليك أن تقارنه بالأخطاء الأخرى في النظام. نحن نطبق تأثير "النافذة المكسورة" هنا - إذا كان هناك عدد كبير جدًا من الأخطاء ذات العتبة المتوسطة في التطبيق، فستتأثر جودة المنتج (أو على الأقل إدراك الجودة) بشكل كبير. عند النظر في كل خطأ في النظام، يجب عليك أيضًا مراعاة الأخطاء الأخرى (المعروفة) في النظام، واستخدام ذلك لتحليل وتحديد الأخطاء التي تحتاج إلى إصلاح وتلك التي لا تستحق الإصلاح.
إن وجود أخطاء في البرامج التي تم إصدارها رسميًا يعد أمرًا سيئًا للغاية - ولكن استنادًا إلى أدوات التطوير الحالية ولغات التطوير لدينا، لم نجد حتى الآن حلاً أكثر منطقية.
تجديد:
بينما أكتب هذا، أعتقد أنني أفتقد عاملًا رابعًا في الصيغة: تاريخ الإصدار. يلعب هذا العامل أيضًا دورًا رئيسيًا في قرار إصلاح/عدم إصلاح الخلل مع اقتراب تاريخ الإصدار. ومع ذلك، لست متأكدًا مما إذا كان هذا هو العامل الرابع، ولا ما هو الحد الأدنى لمقدار "ألم المستخدم" المطلوب لإصلاح خطأ يقترب من الإصدار.