أحد أهم العناصر الذي إذا لم نهتم به في البرمجيات هو اختبار البرمجيات (Software Testing). لا يمكنكم تخيل مدى الإهمال الذي يواجهه هذا الموضوع، وأحيانًا يقول البعض إنه لا فائدة منه. ما هو دور الاختبار طالما أنني كتبت الشيفرة البرمجية وكل شيء يعمل على ما يرام؟ لا يمكنك ملاحظة المشكلة وإدراك مدى أهمية اختبار البرمجيات إلا مع مرور الوقت والخبرة العملية في المشاريع، حيث تجد مشروعًا بسيطًا يحتوي على كمية كبيرة جدًا من الأخطاء البرمجية (bugs) غير المتوقعة. أنت كمطور انتهيت من التطوير، ولكن تظهر كمية مشاكل لا يمكن تخيلها مما كتبته. لا يمكنك تحدي هذه المشاكل ومواجهتها إلا إذا كنت تقوم باختبار برمجيات صحيح.
ما هو اختبار البرمجيات؟
لنبدأ بفهم معنى اختبار البرمجيات. ببساطة، هو أن الشيفرة البرمجية التي سأكتبها كمطور، سواء كانت ميزة جديدة أو حلاً لمشكلة، تحتاج إلى مراجعة بعد انتهائي منها. هذه المراجعة نوعان:
- اختبار الصندوق الأبيض (White-box testing): في هذا النوع، يقوم شخص بمراجعة الشيفرة البرمجية من الداخل. أي أنك تكتب شيفرة برمجية لاختبار شيفرتك.
- اختبار الصندوق الأسود (Black-box testing): هنا، يتم الاختبار دون معرفة مسبقة بما يحدث في الداخل، حيث يتم تقمص دور المستخدم العادي. الأهم في النهاية هو أن الميزة التي بنيتها تعمل كما هو متوقع وتعطي النتائج الصحيحة. يبحث المختبِر عن الحالات التي قد يتعامل بها المستخدم وتؤدي إلى تعطل الميزة، وكأنه يحاول إيجاد طرق لإفسادها بهدف إغلاق هذه الثغرات وجعل الميزة تعمل بشكل جيد.
مثال عملي: نموذج تسجيل الدخول
لنفترض أنني أنشأت نموذج تسجيل دخول تقليدي للمستخدم يحتوي على:
- اسم مستخدم (Username)
- كلمة مرور (Password)
- زر تسجيل الدخول (Login)
كمطور، قد يبدو أن كل شيء على ما يرام. لكنك قد لا تدرك أن المستخدم قد يُدخل رموزًا غريبة في حقل اسم المستخدم قد تُفسد قاعدة البيانات، أو أنه قد يقوم بنسخ ولصق كلمة المرور بطريقة قد تسبب مشاكل.
هنا يأتي دور شخص يعمل في مجال اختبار البرمجيات، والذي يُطلق عليه عادةً “مهندس ضمان الجودة” (QA Engineer). دوره الأساسي هو اختبار هذا النموذج وإعطاء ملاحظات مثل: “صحيح أنك طورت النموذج وهو يعمل في المسار السعيد (Happy Path) - أي السيناريو المثالي - ولكن ماذا لو أدخل المستخدم مدخلات غير صالحة؟”.
قد تكون الرسالة التي تظهرها للمستخدم خطيرة، فمثلاً، إذا قلت له: “هذا المستخدم غير موجود في قاعدة البيانات”، فإنك بذلك تُعلِم المخترق (hacker) المحتمل أن هذا المستخدم غير موجود، أو على العكس، أنه موجود، فيحاول اختراق كلمة المرور. بدلاً من ذلك، قد يقترح عليك عرض رسالة محايدة مثل: “اسم المستخدم أو كلمة المرور غير صالحة”.
نحن كمطورين قد لا نتمكن من التعامل مع هذه الحالات لأننا نكون مشغولين بجعل الميزة تعمل (functional). وهنا يأتي دور مهندس ضمان الجودة لتوجيهنا والتركيز على المشاكل المحتملة.
عقلية الاختبار لدى المطور
مع الوقت والخبرة، أصبحت عندما أعمل على ميزة جديدة، أحاول توقع السيناريوهات أو “حالات الاستخدام” (Use Cases) التي سيختبرها مهندس الجودة وأحاول سد هذه الثغرات مسبقًا. فمثلاً، في نموذج تسجيل الدخول الذي ذكرته، أصبحت أضيف افتراضيًا الشروط والتحققات (validations) في الشيفرة البرمجية لمنع إدخال بيانات غير صحيحة أو عرض رسائل غير مناسبة.
هذا الأمر يمثل تحديًا صعبًا، خاصة إذا كنت تعمل بشكل مستقل (freelance) ولا يوجد من يراجع عملك. عادةً، الشيفرة التي تكتبها وتشغلها تبدو أنها تعمل، لكن المشاكل لا تظهر إلا بعد إطلاق المنتج (Production)، فتجد أن مستخدمًا يتعامل مع الموقع وفجأة انهار شيء ما، أو ظهرت له رسائل خطأ حمراء كثيرة، أو توقفت الشاشة عن الاستجابة أثناء عملية الدفع. تحدث كوارث.
لذلك، حاول دائمًا كمهندس برمجيات أن تكتسب وعيًا بأن الاختبار عبارة عن حالات استخدام. انظر إلى المسارات المتوقعة لشيفرتك أو الميزة التي تبنيها، وتأثيرها على الأجزاء الأخرى من النظام. هل يمكن أن تسبب أخطاء برمجية؟ أحيانًا، قد تضيف ميزة صغيرة فتجد أنها عطّلت ميزات أخرى كانت تعمل بشكل سليم. على سبيل المثال، أردت بناء ميزة بحث، فتسبب ذلك في إفساد عرض القائمة الرئيسية. لذا، يجب أن أتخيل كيف يعمل البحث وأختبر القائمة مرة أخرى بعد إضافة البحث.
الأفضل دائمًا، حتى لو كنت تعمل كمستقل، هو محاولة إيجاد شخص آخر يقوم بعملية الاختبار. في بعض الأحيان، وهو ما أفعله، أطلب من العميل تجربة النظام كمستخدم حقيقي وإخباري بالنتائج.
أهمية اختبار الوحدة (Unit Testing)
هناك موضوع مهم جدًا يجب أن تهتم به كمطور ومهندس برمجيات، وهو اختبار الوحدة (Unit Testing). للأسف، يعتبره بعض المطورين مجرد صداع وإزعاج.
ببساطة، اختبار الوحدة يعني أن الوظيفة (function) التي كتبتها لتنفيذ شيء معين، تقوم بكتابة وظيفة أخرى لها تختبر جميع حالات الاستخدام والمسارات المحتملة. فلو كانت هذه الوظيفة خاصة بتسجيل الدخول، سأقوم بإنشاء وظائف اختبار لكل حالة:
- اختبار تسجيل الدخول الناجح.
- اختبار تسجيل الدخول ببيانات غير صالحة.
- اختبار تسجيل الدخول ببيانات وهمية.
- اختبار تسجيل الدخول ببيانات قد تعطل الواجهة الأمامية.
كل حالة استخدام تمثل “اختبار وحدة”. خصوصًا المطورون المبتدئون قد يقولون: “لماذا أضيع وقتي؟ أكتب الشيفرة التي تعمل ثم أكتب شيفرة أخرى لاختبارها، هذا كلام لا معنى له”. أريد أن أقول لك إن هذا يساعدك على المدى البعيد في تجنب مشاكل كثيرة جدًا، خاصة في الميزات التي تبنيها والتي قد تؤثر على أشياء أخرى.
عندما تجتاز جميع اختبارات الوحدة بنجاح، فهذا يعني أن ميزة تسجيل الدخول تعمل بشكل صحيح. إذا قمت بإضافة ميزة جديدة ولاحظت أن بعض اختبارات الوحدة القديمة فشلت، ستعرف تلقائيًا أن الميزة الجديدة هي التي تسببت في المشكلة، مما يساعدك في تصحيح الأخطاء (debugging) قبل أن تصل المشكلة إلى العميل وتسبب كوارث.
التخصص في مجال اختبار البرمجيات
إذا كنت مهتمًا بالدخول في مجال اختبار البرمجيات، بعيدًا عن كونك مطورًا، فإن هناك شهادة مثل ISTQB، وهي شهادة من مؤسسة تمنحك معيارًا في الاختبار. تعلمك عن:
- اختبار الصندوق الأسود (Black-box Testing)
- اختبار الصندوق الأبيض (White-box Testing)
- الاختبار الآلي (Automation Testing)
- الاختبار اليدوي (Manual Testing)
يمكنك دراسة موادهم المتاحة بكثرة عبر الإنترنت والحصول على الاعتماد من مراكزهم المعتمدة. وبالطبع، يجب أن تفهم كيفية التعامل مع أدوات مثل Jira لتوثيق الأخطاء البرمجية بوضوح، وكيفية استخدام أدوات الاختبار.
مجال اختبار البرمجيات مجال واعد وسيظل مطلوبًا طالما أن هناك تطويرًا للبرمجيات. إنه مجال تقني وصعب. قد يقول البعض إن تطوير البرمجيات هو الأهم، ولكن لا يمكنك تخيل أهمية الاختبار؛ فكلا المجالين لهما نفس الأهمية.
نصيحة أخيرة
اهتم بموضوع اختبار البرمجيات إذا كنت مطورًا. اجعل عقليتك تفترض دائمًا أن ما بنيته لا يغطي كل حالات الاستخدام، وارجع دائمًا لتجربته. اهتم بتعلم اختبار الوحدة، فهو مطلوب اليوم في الشركات وأصبح جزءًا أساسيًا من خط أنابيب CI/CD، حيث يجب أن تجتاز الشيفرة البرمجية اختبارات الوحدة قبل رفعها. الشركات المرموقة التي توظف المطورين المتميزين تشترط أن تكون لديك خبرة في كتابة اختبارات الوحدة بشكل صحيح.