أول Bug - لغة العصر
رئيس مجلس الإدارة : عبدالمحسن سلامة               رئيس التحرير: نبيل الطاروطي

أول Bug


  

أول Bug

فى تمام الساعه الـ 3:45 دقيقة من يوم الثلاثاء، الموافق التاسع من سبتمبر عام 1947، لاحظ العاملون على جهاز MARK II بجامعة هارفارد الأمريكية، أن النظام لا يعمل بالشكل المعتاد، بعد بحث سريع وجدوا أن هناك حشرة (Bug) عالقة بداخل جهاز الكومبيوتر تمنعه من أداء مهامه.
تمت إزالة الحشرة، ومن ثم عاد الجهاز للعمل بشكل طبيعى، قام العاملون بتسجيل تلك الواقعة فى تقريرهم، وأرفقوا الحشرة التى وجدوها ومعها تعليق: “الحالة الأولى للحشرة التى وجدت”.
وعلى سبيل الدعابة، استخدم فريق العمل بهارفارد مصطلح (Bug) للإشارة إلى الأخطاء والمشاكل التى واجهتهم لاحقًا. وشيئًا فشيئًا أصبح العاملون فى البرمجة يستخدمون هذا المصطلح (Bug) كمرادف لأى خطأ أو خلل فى أداء أنظمة الحاسب إلى يومنا هذا.
واعتبر يوم التاسع من سبتمبر كيوم عالمى لمختبرى البرامج. وأصبح مبرمجو ومختبرو البرامج مدينين لفريق هارفارد بمصطلحين هامين، وهما (Bug) للأخطاء، وبالتالى (Debug) لمعرفة أسباب وتصحيح تلك الأخطاء.
إلا أن أمر الأخطاء البرمجية لم يتوقف عند حد وجود حشرة تعوق العمل، ويتم إزالتها لتسير الأمور بصورة طبيعية، بل تطور بمرور الوقت، واختلفت طبيعته عن الـ Bug الأولى تماما.
فمع التطور السريع الذى شهدته صناعة البرامج وزيادة تعقد تلك البرامج، سواء فى اللغة المستخدمة فى كتابتها أو فى الوظائف التى تؤديها. أصبح من الضرورى كتابة وصف دقيق ومفصل لأى Bug يتم اكتشافها حتى يسهل على المبرمجين التعامل معها. أيضًا نتيجة لزيادة عدد الـ  Bugsوتباين آثارها على البرامج، أصبح من الضرورى تضمين مؤشرات تساعد فى تحديد أثر تلك الأخطاء على البرامج  (Severity)وأولوية حلها (Priority) من وجهة نظر مكتشفها.
ظل استخدام مصطلح الـ Bug لوقت طويل مقصورًا على المشاكل التى تعوق البرامج عن أداء وظائفها الأساسية (Functionalities) وبمرور الوقت وزيادة عدد المستخدمين أضيف عنصر جديد، وهو مدى السرعة التى تؤدى بها هذه البرامج وظائفها  (Performance)وبالتالى أصبح عدم ملاءمة سرعة البرنامج لمتطلبات وعدد مستخدميه مشكلة (Bug) تحتاج للحل.
ثم أضافت ضرورة تأمين البرامج والبيانات والحفاظ على سريتها، وما ترتب على عدم تأمينها بشكل جيد من مشاكل وكوارث مالية أو انتهاكات سرية البيانات بعدًا جديدًا، ومختلفًا لمفهوم الـ Bug، وأصبح حتى وجود برنامج يعمل بكامل وظائفه بشكل جيد وبسرعة مناسبة غير كافين للحكم على جودته وخلوه من المشاكل.
ولعقود طويلة كانت البرامج المستخدمة فى بيئة الأعمال تنحصر فى البرامج التى تقوم بتسجيل بيانات المنشأة والمعلومات الخاصة بعمليات ونشاطات تلك المنشأة، واستخراج التقارير التى توضح نتائج هذه الأنشطة، أو مايعرف بنظم التسجيل(System of Record)  وكان استخدام هذه البرامج مقتصر على العاملين بالمنشأة، سواء كانت شركات أو مصارف أو هيئات حكومية.
على نحو متواز، كان هناك تقدم سريع وملحوظ فى تطبيقات الويب وتطبيقات الموبايل، وبدأ الاعتماد عليهما بشكل كبير فى بيئة الأعمال، مما أوجد نوعًا من المشاركة والتفاعل (System of Engagement)  بين المؤسسات وعملائها. وأصبح استخدام البرامج الخاصة بالمنشأة ليس مقصورًا فقط على موظفيها، بل امتد ليشمل العملاء أيضًا. وخير مثال على ذلك، البرامج التى تتيح للعملاء استخدام الخدمات الحكومية عن طريق الإنترنت أو أنظمة الدفع عن طريق الإنترنت أو الموبايل.
نتج عن هذا التفاعل والمشاركة أنواع جديدة من الـ(Bugs)  لا تنحصر فيما يقدمه البرنامج أو التطبيق من وظائف، فالعميل دائمًا ما تكون له تفضيلاته المتعلقة بشكل البرنامج، ونافذة التطبيق  (User Interface)وسهولة الإستخدام  (Usability) وطبعًا لابد أن تكون هذه البرامج متوافقة مع الجهاز الذى يستخدمه أو المتصفح الذى يفضله العميل (Compatibility).
ومع تزايد شراسة المنافسة بين المؤسسات لتوسيع الحصة السوقية، وكسب أكبر عدد من العملاء، صار لزامًا على تلك المؤسسات العمل على توصيل برامجها بشكل أسرع، وبجودة أعلى. وأصبح العنصر البشرى وحده لا يفى بالغرض من اكتشاف الـ (Bugs). ومن هنا بدأت عمليات أتمتة الاختبارات (Testing Automation) بهدف اكتشاف أكبر عدد من الـBugs  بشكل سريع وضمان خلو البرنامج من أى منها قبل إتاحته للمستخدم.
مع العدد الكبير والمتنوع من الـBugs  أصبح من غير المنطقى أو المقبول، أن يتم تسجيلها على ورقة كما فعل فريق هارفارد مع الـBug  الأولى، فالعديد من فريق المشروع أصبح مهتمًا وله دور فى متابعة وحل هذه الـ Bug، بدءًا من فريق البرمجة الذى سيقوم بحلها إلى مدير المشروع، الذى يجب أن يتأكد من أنها سوف تحل فى الوقت المحدد لحلها، وصولًا لفريق الاختبارات الذى من واجبه أن يتأكد من متابعة وحل الـBug  بشكل سليم وعدم تأثر باقى وظائف البرنامج. وهناك أيضًا العميل الذى من حقه أن يسجل الأخطاء التى يلاحظها ويتابع إجراءات حلها. كل هذه العوامل أدت إلى ضرورة وجود برامج مهمتها تسجيل وتتبع هذه الأخطاء  (Bug Tracking System)وتصميم نموذج يحدد المراحل التى ستمر بها الـ Bug بداية من اكتشافها وحتى التأكد من حلها (Bug Life Cycle).
الـ Bugs  ليست مجرد أخطاء يتم اكتشافها ثم حلها لينتهى الأمر، فالـ Bugs مؤشر مهم على مدى نضج وكفاءة وأداء فريق العمل بأكمله.
كما أن مقارنة سريعة بين أى تقرير لـ  Bugs مستخرج من أىBug Tracking System  بالتقرير المحفوظ فى المتحف القومى الأمريكى فى واشنطن لأول Bug، كافية لتوضح التقدم الهائل فى صناعة البرامج منذ ذلك الوقت وحتى الآن.

عن الكاتب

خبير جودة البرمجيات

كلمات البحث:
محمد حمدى أحمد

رابط دائم:
شارك

أول Bug

التعليق

  • تعرف على

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

  • تابعنا على الفيس بوك

© 2014 جميع الحقوق محفوظة لمؤسسة الاهرام