تتبع الأخطاء

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

توضح "Tutorials Point" أن "تتبع العيوب عملية مهمة في هندسة البرمجيات، حيث تحتوي الأنظمة المعقدة والحيوية للأعمال على مئات العيوب." "أحد العوامل الصعبة هو إدارة هذه العيوب وتقييمها وتحديد أولوياتها. يتضاعف عدد العيوب على مدى فترة زمنية ولإدارتها بشكل فعال، يتم استخدام نظام تتبع العيوب لتسهيل المهمة."¹

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

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

خلال فترة حياته، يمكن أن يمر عيب واحد بعدة مراحل أو حالات. وتشمل ما يلي:

• نشط: التحقيق جارٍ
• الاختبار: تم إصلاحه وجاهز للاختبار
• تم التحقق: تم إعادة اختباره والتحقق منه بواسطة ضمان الجودة (QA)
• تم الانتهاء: يمكن إغلاقه بعد إعادة اختبار ضمان الجودة أو إذا لم يعتبر عيبًا
• أعيد فتحه: لم يتم إصلاحه وأعيد تنشيطه ³

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

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

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

يُقدّر أن مطوري البرمجيات يرتكبون من 100 إلى 150 خطأ لكل ألف سطر من التعليمات البرمجية.⁴ وفقًا لتقرير صادر عن اتحاد جودة برمجيات تكنولوجيا المعلومات (CISQ): "حتى لو كانت نسبة صغيرة فقط، ولنقل 10 بالمائة، من هذه الأخطاء خطيرة، فإن تطبيقًا صغيرًا نسبيًا يبلغ 20 ألف سطر من التعليمات البرمجية سيحتوي على ما يقرب من 200 خطأ برمجي خطير." ⁵

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

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

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

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

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

في مجلة Harvard Business Review، يحدد Nicholas Bowen عملية إدارة العيوب. الخطوة الأولى هي التصنيف وتحديد الأولويات: "بشكل عام، ستعطي الفرق الأولوية لنوعين من الأخطاء: تلك التي تتسبب في تعطل النظام وتلك الأقل خطورة ولكنها قد تكون منتشرة....بعد ذلك، حدد وقت الاستجابة المستهدف لكل مستوى من مستويات الخطورة. إذا كان نظام إدارة الجودة جديدًا ، فيجب أن يكون التركيز الأولي على إصلاح أخطر الأخطاء في غضون ساعات أو أيام. بينما تستخدم نظامك، يمكنك جمع بيانات حول مقياسين رئيسيين: معدلات الأخطاء الواردة وإنتاجية مصلحي الأخطاء، وتعديل أهدافك حسب الحاجة. قال إنه يتعين على المؤسسات أيضًا إنشاء نظام يمكن من خلاله مراجعة العيوب والوقت اللازم لحلها على جميع المستويات، من الرئيس التنفيذي إلى الموظفين.⁷

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

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