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

الخطأ الأول: سوء فهم أهداف أتمتة الاختبارات

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

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

يؤدّي هذا إلى العواقب السلبية المُحتَمَلة التالية:

• إهدار الميزانية: يمكنك إهدار عشرات أو مئات الساعات على مُنتَج لن يجلِب أي فائدة وغالبًا ما يستغرق وقتًا إضافيًا للصيانة.
• فقدان الثقة في الاختبارات المؤتمتة: عند التحقق من شيء خاطئ، غالبًا ما تقوم الاختبارات المؤتمتة بتعطيل أو إغفال العيوب. قد يُشكّك فريق التطوير والعميل في نتائج الأتمتة.
• تغطية اختبار غير صحيحة (Incorrect Test Coverage): قد يؤدّي الاختيار الخاطئ لنطاقات الاختبار (test scopes) إلى أتمتة سيناريوهات غير حرجة وغير مفيدة بل قد يتم حذفها من نطاق الإصدار (release scope). في مثل هذه الاختبارات، لايوجد هنالك أي فائدة للأتمتة.

كيف نتجنّب مثل هذه المشاكل؟

• حدّدْ الأهداف الرئيسية للأتمتة قبل البدْء. قد يشمل ذلك تقليل وقت الـ regression testing وأتمتة سيناريوهات الاختبار اليدوي المستهلِكة للوقت والسيناريوهات الحرجة وما إلى ذلك.
• ناقِشْ مع الفريق وتأكّد من أن الأتمتة ستساعد في تقليل تكاليف الاختبار اليدوي لمثل هذه المهام.
• تأكّدْ من أن منتجك قابل للأتمتة من الناحية الفنية.

الخطأ الثاني: الفشل في القيام بـ Proof of Concept (PoC) قبل البَدْء في الأتمتة

تُهمِل العديد من الفرق المُنغمِسة في فكرة الأتمتة مرحلةً حاسمةً وهي الـ PoC. تمثل هذه المرحلة تجربة صغيرة تساعد في تحديد مدى جدوى استراتيجية وأدوات أتمتة الاختبارات المُختارَة لمشروع مُعيّن.

قد يؤدّي إهمال مرحلة الـ PoC إلى اختيار الفريق لأدوات أو أساليب أتمتة اختبار غير مناسبة ممّا يُسبّب العديد من المشاكل ويزيد تكلفة المشروع بشكل كبير. تُمكّن مرحلة الـ PoC الفريق من تقييم المخاطر مُبكّرًا وتحديد المشكلات المحتمَلَة وتحديد ما إذا كانت الأدوات والأساليب المُختارَة تُلبّي المتطلبات وما إذا كان من المُمكِن أتمتة اختبارات المُنتَج باستخدام الأدوات المُتاحة في السوق.

ما هي العواقب السلبيّة التي يؤدي إليها هذا:

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

التوصيات:

• قبل البَدْء في الـ PoC، حدّدْ بوضوح ما تريد الحصول عليه من الأتمتة وما هي المتطلبات الرئيسية للأدوات.
• حدّد الإطار الزمني: يجب ألا يكون الـ PoC طويلاً جدًا. الغرض منه هو إجراء تقييم سريع وليس تطبيقًا كاملاً.
• حلّلْ النتائج: بعد الـ PoC، حلّلْ النتائج بعناية مع مراعاة الجوانب الفنيّة والجوانب المتعلّقة بالـ business.

الـ PoC ليس مجرّد إجراء شكلي بل خطوة مهمة توفر الوقت والمال والجهد. لا تُهمِلْ هذه المرحلة إذا كنت ترغب في نجاح مشروع أتمتة الاختبارات وتحقيق النتائج المَرْجوّة.

الخطأ الثالث: الأتمتة في وقت مبكّر جدًا

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

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

العواقب السلبيّة المُحتَمَلة:

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

التوصيات حول كيفية منع ذلك:

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

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

الخطأ الرابع: سيناريوهات الاختبار المعقّدة للغاية

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

اختبارات الـ E2E تختبر النظام ككل من خلال محاكاة تصرّفات مستخدم حقيقي. ورغم أهميّتها، إلا أنها أيضًا الأكثر تكلفة واستهلاكًا للوقت. أيضًا قد يُغفِل تعقيد السيناريوهات والإفراط في استخدام اختبارات الـ E2E الحاجة إلى أنواع أخرى من الاختبارات مثل اختبارات الوحدة أو التكامل (unit or integration tests).

العواقب السلبيّة المُحتَمَلة:

• وقت تنفيذ طويل: يؤدي عدد كبير من اختبارات الـ E2E الطويلة إلى زيادة وقت تنفيذها ممّا قد يؤدي إلى إبطاء التطوير (development).
• مزيد من الـ false positives: تميل اختبارات الـ E2E إلى أن تكون أقل استقرارًا بسبب العديد من التبعيّات الخارجية (external dependencies) ممّا يؤدّي إلى نتائج false positives متكرّرة.
• تكاليف الدّعم المرتفعة: نظرًا لتعقيدها وطولها، تتطلّب اختبارات الـ E2E جهدًا كبيرًا لإنشائها وصيانتها.

التوصيات:

• هَرَم الاختبار (Testing Pyramid): اتبعْ مبدأ هَرَم الاختبارات المؤتمتة ويشمل قاعدة واسعة من اختبارات الوحدة السريعة (unit tests) وفوقها اختبارات تكامل (integration tests) أقل واختبارات E2E أقل في الأعلى.
• اختصِرْ وحسّنْ: فكّرْ في تقسيم سيناريوهات الـ E2E الطويلة إلى سيناريوهات قصيرة أو دمْج عدّة اختبارات مع بعض.
• استخدمْ التنفيذ المتوازي (Parallel Execution): إذا كان لديك العديد من اختبارات E2E ففكّرْ في تشغيلها بالتوازي لتسريع عملية الاختبار.

على الرغم من أهمية اختبارات الـ E2E في الاستراتيجية، لا ينبغي الاعتماد عليها كأداة رئيسية. فالمزيج الأمثل من مستويات الاختبار المختلفة (testing levels) سيساعد في إنشاء أتمتة فعّالة ومستدامة (compelling and sustainable automation).

الخطأ الخامس: عدم وجود مقاييس وتقارير (Metrics and Reporting)

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

تساعدك المقاييس والتقارير على تتبّع حالة الاختبار ونتائجه وتقديم ملاحظات حول مواطن الخلل التي تحتاج إلى اهتمام فهي تكشف عن الأنماط (patterns) المرتبطة بالأعطال المتكرّرة (frequent failures) وتساعد الفريق على اتخاذ قرارات مدروسة بشأن تحسين الكود أو الاختبارات.

العواقب السلبيّة المُحتَمَلة:

• عدم القدرة على تحديد مناطق المشاكل (Problem Areas): بدون مقاييس، من الصعب تحديد أجزاء التطبيق الأكثر عُرْضَة للخطر أو التي تتعطّل بشكل متكرّر.
• صعوبة تحديد عائد الاستثمار: إن الافتقار إلى التقارير يجعل من الصعب إثبات فعاليّة وعائد تنفيذ الأتمتة.
• تدهور جودة المنتج: بدون فهم كيفية ومكان حدوث الأخطاء في أغلب الأحيان، تكون فُرَص الفريق في القضاء عليها أقل.

التوصيات:

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

يمكن أن تُشكّل المقاييس الصحيحة ونظام إعداد التقارير الفعّال حجر الأساس في أتمتة عالية الجودة وفعّالة. فهي تُزوّد ​​الفريق بالملاحظات التي يحتاجها وتُركّز جهوده على أهمّ مجالات التحسين.

الخلاصة

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

* المصدر والصورة: https://www.softwaretestingmagazine.com/knowledge/top-5-mistakes-in-automated-testing