ما الذي تؤتمته وما الذي لا تؤتمته

لماذا يهم

أتمتة الفحوص الخطأ تكلّف المنتج مرتين: وقت يذهب في كتابة سكربتات وإصلاحها لفحوص نادراً ما تعمل أو تتغير باستمرار، وفحوص مهمة تبقى يدوية لأن الميزانية نفدت. ويذكر منهج ISTQB للمستوى التأسيسي (CTFL v4.0) السببين معاً ضمن مخاطر أتمتة الاختبار: استخدام أداة حيث يكون الاختبار اليدوي أنسب، وسوء تقدير جهد صيانة سكربتات الاختبار.

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

ما الذي يستحق الأتمتة

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

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

جرّبها: مولّد سيناريوهات الانحدار جرّبها: مولّد حالات اختبار من OpenAPI

ما لا تؤتمته، أو لا تؤتمته بعد

هذه الفحوص يؤديها الإنسان عادةً بشكل أفضل. وبعضها «ليس بعد» لا «أبداً»: فالفحص يصبح مرشحاً لاحقاً حين تستقر ميزته، أو حين يصبح للخدمة التي يعتمد عليها بديل (Stub)، أي مكوّن بسيط يحل محل الخدمة الحقيقية ويعيد إجابات ثابتة.

• الاختبار الاستكشافي والمرور الأول على ميزة جديدة، ما دام السلوك المتوقع قيد الاكتشاف. فالسكربت لا يفحص إلا ما توقّعه أحدهم مسبقاً.
• الحكم البشري: هل الصياغة واضحة، وهل تُقرأ الشاشة العربية بشكل طبيعي من اليمين إلى اليسار، وهل المسار مربك. تستطيع الأدوات قياس أجزاء مثل تباين الألوان، لكن الحكم يبقى للإنسان.
• الفحوص لمرة واحدة، مثل التحقق من ترحيل البيانات في نهاية الأسبوع الماضي: نفّذه مرة يدوياً أو باستعلام لا يُحتفظ به.
• الميزات التي تتغير كل سبرنت: شاشة يُعاد تصميمها، أو تجربة A/B، أو نموذج أولي.
• ما لا يتحكم فيه الاختبار: تحدي CAPTCHA الموجود أصلاً لإيقاف الأتمتة، أو رسالة نصية (SMS) حقيقية تصل إلى هاتف حقيقي. اطلب إعداداً خاصاً بالاختبار أو بديلاً (Stub)، وافحص الشيء الحقيقي يدوياً من حين لآخر.

القاعدة: التكرار والحتمية والاستقرار

اطرح ثلاثة أسئلة على كل مرشح بهذا الترتيب، ولا تؤتمت إلا إذا كانت الإجابات الثلاث «نعم».

التكرار (Frequency): كم مرة سيعمل الفحص خلال عمره المفيد؟ اضرب عدد الإصدارات في صفوف البيانات والمتصفحات واللغات: ⁦40⁩ صفاً في ⁦26⁩ إصداراً في السنة تساوي ⁦1,040⁩ تنفيذاً. والفحص الذي يعمل مرة واحدة لا يسترد كلفة بناء اختبار آلي وصيانته؛ وإن كان أكبر من أن يُنفَّذ يدوياً فيكفيه استعلام أو سكربت لا يُحتفظ به.

الحتمية (Determinism): هل يستطيع السكربت أن يقرر النجاح أو الفشل وحده، وهل يعطي المُدخل نفسه النتيجة نفسها في كل تشغيل؟ «الإجمالي ⁦115.00⁩ ريال» نتيجة متوقعة محددة، أما «الصفحة تبدو جيدة» فليست كذلك. والنتيجة التي تعتمد على الساعة، أو على بيانات عشوائية، أو على حساب مشترك، أو على خدمة خارجية حية، ليست قابلة للتكرار بعد: تحكّم في الوقت، ودَع الاختبار ينشئ بياناته بنفسه، أو ضع بديلاً للخدمة، ثم أتمِت. ويشرح مقال مارتن فاولر (Martin Fowler) عن عدم الحتمية ثمن تجاوز هذه الخطوة: حين تفشل الاختبارات بلا سبب، يتعلّم الفريق تجاهل الفشل.

الاستقرار (Stability): هل سيبقى السلوك، والواجهة التي يستخدمها الفحص، على حالهما خلال الأشهر القادمة؟ قواعد العمل تتغير أقل من التخطيطات البصرية. وإن كانت الإجابة «لا» فاختبره يدوياً الآن وأبقِه في قائمة المرشحين.

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

جرّبها: مولّد الاختبار المبني على المخاطر

العائد على الاستثمار في الأتمتة، محسوباً بصدق

يقارن العائد على الاستثمار (ROI) ما توفّره الأتمتة بما تكلّفه خلال الفترة نفسها. ففي فحص الانحدار يكون التوفير القابل للقياس هو وقت التنفيذ اليدوي الذي لم يعد يُصرف، والكلفة هي كل ما يستهلكه الفحص الآلي لا كتابته فقط. وبالصيغة: العائد = (الكلفة اليدوية − كلفة الأتمتة) ÷ كلفة الأتمتة، ونقطة التعادل (Break-even) = ساعات البناء ÷ (الساعات اليدوية لكل تشغيل − ساعات الصيانة لكل تشغيل)، ولا تعادل إذا بلغت الصيانة لكل تشغيل الكلفة اليدوية أو تجاوزتها.

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

Period: one year. Run: one regression cycle, for example one release.

Manual cost      = manual hours per run x runs a person would really do
Automation cost  = build hours              (write, review, test data, setup)
                 + upkeep hours per run x runs
                   upkeep = fixes after product changes, reading failed runs,
                            fixing flaky tests, CI time and licences in hours
ROI              = (manual cost - automation cost) / automation cost
Break-even       = build hours / (manual hours per run - upkeep hours per run)
                   no break-even when upkeep per run >= manual hours per run

جرّبها: حاسبة النسبة المئوية

مثال تطبيقي: ثلاثة فحوص من متجر إلكتروني

متجر إلكتروني يُصدر كل أسبوعين ويشغّل قائمة الانحدار اليدوية قبل كل إصدار: ⁦26⁩ تشغيلاً في السنة. قدّر الفريق ثلاثة مرشحين، والصيانة تشمل الإصلاحات وقراءة التشغيلات الفاشلة.

• الفحص A (قواعد الأسعار وضريبة القيمة المضافة في السلة، ⁦40⁩ صفاً) يجتاز الأسئلة الثلاثة: يدوياً ⁦2.0 × 26 = 52⁩ ساعة في السنة، وآلياً ⁦16 + 0.5 × 26 = 29⁩ ساعة في السنة الأولى، والتعادل عند الإصدار ⁦11⁩ أي بعد نحو خمسة أشهر، والعائد ⁦79 %⁩. أتمِته عبر الواجهة البرمجية. وسيعمل أيضاً مع كل إيداع، وهذه التغذية الراجعة الأسرع فائدة حقيقية لكنها ليست ضمن الساعات الـ⁦52⁩. ومن السنة الثانية، بلا كلفة بناء، يوفّر ⁦39⁩ ساعة سنوياً.
• الفحص B (الشريط الترويجي الذي يُعاد تصميمه كل شهر) يخفق في الاستقرار، والأرقام تؤكد ذلك: الصيانة لكل إصدار ساعة كاملة، أي أربعة أضعاف الفحص اليدوي الذي يستغرق ربع ساعة. يبقى في قائمة فحوص الإصدار اليدوية.
• الفحص C (تسجيل الدخول برمز SMS لمرة واحدة) أخفق في الحتمية لأن الرمز كان يصل إلى هاتف حقيقي. أضاف المطورون بديلاً للرسائل النصية في بيئة الاختبار، معطّلاً في الإنتاج، فأصبح الفحص يجتاز الأسئلة الثلاثة: ⁦25⁩ ساعة يدوياً في السنة مقابل ⁦15⁩ ساعة آلياً، والتعادل بعد ⁦50⁩ نشراً أي نحو ستة أشهر. ومع ذلك يسجّل مختبِر الدخول بهاتف حقيقي بعد كل إصدار إلى الإنتاج، لأن البديل لا يثبت أن تسليم الرسائل الحقيقية يعمل؛ ويبقى هذا الفحص في قائمة فحوص الإصدار اليدوية، وليس جزءاً من الساعات الـ⁦25⁩ التي يحل السكربت محلها.

Release every 2 weeks: 26 manual regression runs a year

A  Cart price and VAT rules, 40 data rows, checked through the API
   Manual       2.0 h x 26                  = 52 h a year
   Automated    16 h build + 0.5 h x 26     = 29 h in year 1
   Break-even   16 / (2.0 - 0.5) = 10.7     -> release 11, about 5 months
   ROI year 1   (52 - 29) / 29              = 79 %

B  Home page promo banner, redesigned every month, checked in the UI
   Manual       0.25 h x 26                 = 6.5 h a year
   Automated    6 h build + 1.0 h x 26      = 32 h in year 1
   Break-even   none: upkeep 1.0 h per run > manual 0.25 h per run

C  Sign-in with an SMS one-time code, using an SMS stub in the test environment;
   today checked by hand after each of ~100 staging deploys a year
   Manual       0.25 h x 100                = 25 h a year
   Automated    10 h build + 0.05 h x 100   = 15 h in year 1
   Break-even   10 / (0.25 - 0.05) = 50     -> deploy 50, about 6 months
   ROI year 1   (25 - 15) / 15              = 67 %

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018شرح واسع الاستشهاد لكيفية الموازنة بين اختبارات الوحدة والتكامل والعقود والواجهة في محفظة الاختبارات الآلية.