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

العادة السيئة الأولى: اختبار أشياء لا تفهمها

لقد مررنا جميعا بهذه التجربة: قام المطوّر بأبحاث كافية لإصلاح الكود لكنه لم يُضِف أي تفاصيل في الـ user story حول كيفية عمل الكود أو التغييرات التي أُجريَت. يقول لك المطوّر: شَغّلْ هذا الطلب على هذا الخادم وإذا تلقّيت هذه الاستجابة فهذا يعني أن المشكلة قد تم إصلاحها.

إليكم المشكلة في هذا السيناريو: كيف تعرف أن المطوّر مُحِق؟ إذا لم تُحَل المشكلة وكان هنالك عطل في بيئة العمل الفعلية، فسيعود إليك مديرك بأسئلة. من الصعب أن يكون ردّك: طلب مني المطوّر القيام بهذا ونجح الأمر. لذا نقلتُ الـ user story إلى Done.

العادة الجيّدة: اطرح الأسئلة. اطلب من المطوّر أن يشرح لك كيفية عمل الميزة (feature) والتغييرات التي أُجريَت عليها. استمر في طرح أسئلة توضيحية حتى تفهم ما يحدث تمامًا. بهذا، قد تُثير نقاطًا لم يفكّر فيها المطوّر مما يُشجّعه على تحسين عمله.

العادة السيئة الثانية: اختبار ما تخبرك به الـ User Story فقط

غالبًا ما تكون لدينا معايير القبول (Acceptance Criteria) التي تُحدّد بدقّة كيفية عمل الميزة أو الإصلاح الجديد وغالبًا ما يكتبها الـ product owner وأحيانًا المطوّر. تُعدّ معايير القبول مفيدة وهي بالتأكيد أفضل من عدم وجودها على الإطلاق ولكنها غالبًا ما تحتوي فقط على سيناريوهات الـ Happy Path.

العادة الجيّدة: التفكير خارج الصندوق. من مهاراتنا كمختبري برمجيات القدرة على التفكير في الأخطاء المحتملة وعلينا تطبيق هذه المهارة في كل user story نختبرها.

قبل الموافقة على معايير القبول، اسأل نفسك: هل يمكنني التفكير في أي شيء آخر لاختباره هنا؟ هل هناك أي شيء فاتني؟ سيساعدك هذا غالبًا في العثور على أخطاء في مناطق لم يفكّر فيها أحد.

العادة السيئة الثالثة: افتراض أن السلوك الغريب هو السلوك الصحيح

في كثير من الأحيان وعند اختبار ميزة جديدة، نواجه سلوكًا غير منطقي. ربما تحديث صفحة غريب أو انتقال إلى مكان لم نتوقعه. أو ربما يظهر زر في مكان لم نتوقعه. من السهل عند الاختبار قبل الموعد النهائي أن نركّز كثيرًا على النتيجة النهائية للـ user story مما يُبعِد السلوك الغريب عن أذهاننا. قد نقول لأنفسنا: سأسأل المطوّر عن ذلك عند الانتهاء (ثم ننسى) أو نقول: حسنًا، أنا متأكّد من أن المطوّر يعرف ما يفعله ومن المفترض أن يفعل ذلك.

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

العادة السيئة الرابعة: مطاردة الأشياء في جحر الأرنب

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

أتذكّر أنني سألتُ زميلةً لي في فريق الاختبار عن الخطأ المُفضّل الذي لاحظته خلال مسيرتها المهنية فأخبرتني بحماسٍ عن خطأٍ يتطلّب الضغط على زر عدة مرات والتنقّل بين صفحتين ثمّ التمرير السريع (scrolling) كل ذلك في مُتصفّح واحد.

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

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

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

العادة السيئة الخامسة: أتمتة الاختبارات من أجل الأتمتة فقط

يكتشف مختبرو البرمجيات الذين تعلّموا الأتمتة أن أتمتة الاختبارات أمر ممتع. هناك شعورٌ بالحماس عند التغلّب على التحدّيات التقنية ومشاهدة الاختبارات تعمل.

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

قد نغفل أيضًا عن ميزات رئيسية. على سبيل المثال إذا كانت لدينا ميزة بحث جديدة تُجري البحث حسب نطاق تاريخي، فقد يقضي مهندس الأتمتة وقته كله في محاولة تحديد التواريخ باستخدام برنامج الـ Selenium ولن يلاحظ أبدًا إمكانية إدخال تاريخ بَدْء بعد تاريخ الانتهاء.

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

العادة السيئة السادسة: إنشاء اختبارات معقّدة وغير دقيقة

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

العادة الجيّدة: تذكّر أن الهدف من الأتمتة هو تسهيل عملك مما يتيح لك إجراء المزيد من الاختبارات الاستكشافية (exploratory tests).

يجب أن تكون الاختبارات المؤتمتة بسيطة بحيث يتحقق كل اختبار من شيء واحد فقط. ألقِ نظرة على اختبارات واجهة المستخدم لديك وتحقق مما إذا كان من الممكن أتمتتها باستخدام اختبارات واجهة برمجة التطبيقات (API). تُعد اختبارات واجهة برمجة التطبيقات (API) أسرع وأكثر موثوقيّة من اختبارات واجهة المستخدم لأنها لا تعتمد على استجابات المتصفح. عند الحاجة إلى اختبار واجهة مستخدم، تأكّد من استخدام فترات انتظار صريحة (explicit waits) بدلاً من فترات انتظار ضمنيّة (implicit waits) لتقليل التذبذب في نتائج الاختبارات.

العادة السيئة السابعة: قبول تجربة مستخدم سيئة

أحيانًا عندما نعمل على موعد نهائي (deadline) ولدينا العديد من الـ stories لاختبارها، نركّز فقط على وظيفة الميزة (feature). إذا نجحت الميزة ولم تكن بها أي أخطاء، نعتبرها مُنجَزة وننتقل إلى المرحلة التالية. لكن من المهم تذكّر المستخدمين النهائيين. إذا لم يفهم المستخدم ما يجب فعله على الصفحة أو وجد نفسه مضطرًا للنقر عدة مرات لإنجاز شيء ما، فسيشعر بالإحباط ولن يرغب في استخدام المنتج.

رأيتُ مثالاً على ذلك مؤخرًا عندما طُلِب مني ملْء استبيان. تطلّبت الأسئلة إجابات طويلة لكن حقول الاستبيان كانت صغيرة جدًا لدرجة أنني لم أستطع رؤية سوى سطر واحد في كل مرة مما صعّب عليّ كتابة ومراجعة مُدخلاتي. أنا متأكّد من أن مختبري البرمجيات الذين اختبروا المُنتَج تأكدوا من إمكانية كتابة الحقل وحفظ المُدخلات لكنهم لم يُدركوا صعوبة الاستخدام.

العادة الجيّدة: فكّر دائمًا في المستخدمين النهائيين عند اختبار تطبيقك. استفسر من مالك المُنتَج (product owner) عن سير العمل المتوقع (workflow) وجرّبه. اسأل نفسك ما رأيك في سلوك المُنتَج لو كنت المستخدم النهائي وليس المُختبِر. إذا كان هذا السلوك سيُزعجك، فادعم تغييره.

ختامًا تذكّر لماذا أنت تختبر

في عملنا اليومي كمختبري برمجيات، من السهل أن يتشتّت انتباهنا بالمواعيد النهائية (deadlines) والتحدّيات التقنية (technical challenges). نحن بارعون في التركيز على أدق تفاصيل البرمجيات ولذلك نتميّز باكتشاف الأخطاء البرمجية. لكن يجب ألا نغفل أبدًا عن هدف شركتنا: ابتكار برمجيات يستخدمها الناس. هنا يجب أن تكون النتيجة النهائية لجميع مهامّنا ضمان قدرة المستخدم على استخدام منتجنا بسلاسة وأمان وسهولة.

* المصدر: https://simpleprogrammer.com/qa-engineer-habits

** الصورة من موقع: https://www.repeato.app/all-you-need-to-know-about-software-test-engineering