استراتيجية أتمتة الاختبار
استراتيجية أتمتة الاختبار (Test Automation Strategy) مجموعة قرارات مكتوبة وموجزة تحدد كيف يؤتمت الفريق اختباراته: الغرض من الأتمتة وما تغطيه، والأدوات التي يستخدمها، ومن يملك الاختبارات، وأين تعمل، وبأي بيانات، وكيف تُبلَّغ نتائجها، وكيف تُصان الحزمة. ويصفها مسرد ISTQB بأنها خطة عالية المستوى لتحقيق الأهداف بعيدة المدى لأتمتة الاختبار ضمن قيود معيّنة. ومن سطور استراتيجية فريق يبني تطبيقاً لتوصيل الطعام: «يختبر المطورون قواعد التسعير باختبارات الوحدة؛ وتعمل ست رحلات في المتصفح كل ليلة، ويُفرز أي تشغيل فاشل قبل الساعة 10:00».
اتخذ درسا «ما الذي تؤتمته وما الذي لا تؤتمته» و«هرم أتمتة الاختبار» القرارات فحصاً فحصاً. أما الاستراتيجية فتحوّل هذه القرارات إلى قواعد للفريق كله، وكثيراً ما تكون قسماً من استراتيجية الاختبار (Test Strategy) أو وثيقة قصيرة بجانبها.
لماذا يهم
من دون استراتيجية تنمو الأتمتة بالمصادفة: نصوص برمجية للمتصفح لا تعمل إلا على حاسوب مختبِرة واحدة، واختبارات API بأداة ثانية، ونتائج ليلية لا يقرؤها أحد، واختبارات تتشارك حساباً واحداً فيُفسد بعضها بعضاً، وحزمة تُهجَر بعد أول إعادة تصميم لأن أحداً لم يخطط لصيانتها. ويذكر منهج CTFL v4.0 المخاطر المقابلة لأتمتة الاختبار، ومنها التوقعات غير الواقعية، والاستهانة بالجهد اللازم لصيانة النصوص البرمجية للاختبار، والاعتماد على مورّد أو على مشروع مفتوح المصدر قد يُهجَر.
أما للمختبِر فالاستراتيجية تحسم الأسئلة اليومية قبل أن تتحول إلى خلافات: أين يوضع فحص جديد، وبأي أداة، وماذا يحدث حين يفشل تشغيل، ومن يصلح اختباراً معطوباً. وهي أيضاً ما يتيح لك أن تُثبت أن الأتمتة تقلل المخاطر وزمن التغذية الراجعة، لا أن النصوص البرمجية موجودة فحسب.
سبعة قرارات تُتخذ بالترتيب
تجيب الاستراتيجية عن سبعة أسئلة: ما الغرض من الأتمتة وما الذي تغطيه (الأهداف والنطاق)، وبماذا (الأدوات)، ومن يتولاها (الملكية)، وأين (البيئات)، وبأي بيانات (بيانات الاختبار)، وكيف تصل النتائج إلى الناس (التقارير)، وكيف تبقى الحزمة سليمة (الصيانة).
اتخذ القرارات بهذا الترتيب تقريباً، لأن كل إجابة تعتمد على ما قبلها: فالنطاق يحدد الأدوات المناسبة، ولغة الأداة تحدد من يستطيع كتابة الاختبارات ومراجعتها، والأدوات ومستويات الاختبار تحدد البيئات، والبيئات تحدد كيف تُنشأ البيانات، وقواعد التقارير والصيانة تحتاج إلى مالك لكل اختبار. واجعل النتيجة صفحة أو صفحتين يستطيع عضو جديد في الفريق أن يعمل بهما.
كل قرار يُبنى على القرارات التي فوقه
- 1الأهداف والنطاقهدف يمكن التحقق منه لاحقاً؛ وأي الفحوص تُؤتمت وعلى أي مستوى، وما الذي يبقى يدوياً
الانحدار في يوم واحد بدلاً من 4؛ و6 رحلات من البداية إلى النهاية
- 2الأدواتملاءمة للمنتج ولغة المطورين وCI، بعد تجربتها في إثبات مفهوم
Playwright مع TypeScript؛ والنتائج بصيغة JUnit XML
- 3الملكيةمن يكتب كل نوع من الاختبارات ويراجعه ويصونه، ومن يتصرف حين يفشل التشغيل
المطورون: اختبارات الوحدة؛ والمختبِرون: حزمتا API ومن البداية إلى النهاية
- 4البيئاتأين تعمل كل حزمة، وكيف تُستبدل الأطراف الخارجية ببدائل أو ببيئة تجريبية
بيئة جديدة لكل طلب دمج؛ وStaging في التشغيل الليلي
- 5بيانات الاختبارينشئ كل اختبار بياناته الاصطناعية بنفسه، بقيم فريدة
العميل والمطعم والطلب تُنشأ عبر API
- 6التقاريرمتى تعمل الحزم، وما الذي تمنعه نتيجة الفشل، ومن يفرزها ومتى
مجموعة طلب الدمج تمنع الدمج؛ ونتيجة الليل تُفرز قبل 10:00
- 7الصيانةوقت للصيانة في كل سبرنت، وقاعدة للاختبارات المتذبذبة، وحذف الاختبارات، ومراجعة الاستراتيجية
يُصلَح الاختبار المتذبذب أو يُحجَر خلال يومَي عمل
بجانب كل طبقة: القرار في استراتيجية الصفحة الواحدة لتطبيق توصيل الطعام في هذا الدرس.
الأهداف والنطاق والأدوات
اكتب الهدف بصيغة يمكن التحقق منها لاحقاً: «يستغرق انحدار الإصدار يوماً واحداً بدلاً من أربعة» أو «يحصل طلب الدمج (Pull Request) على نتيجة خلال 15 دقيقة». ثم حدّد النطاق، بدءاً بأعلى مخاطر المنتج، بقاعدة التكرار والحتمية والاستقرار وبمستويات الهرم: أي أنواع الفحوص تُؤتمت وعلى أي مستوى، وما الذي يبقى يدوياً عن قصد، مثل الاختبار الاستكشافي والحكم على قابلية الاستخدام. واذكر أيضاً ما هو خارج النطاق، مثل مزوّد دفع لا يُختبر إلا عند حدوده مع النظام.
اختر الأدوات لملاءمتها لا لشهرتها، وقبل الالتزام بها جرّب الأداة المرشحة في إثبات مفهوم (Proof of Concept)، أي تجربة أولية قصيرة محددة الزمن على مسارين حقيقيين، أحدهما بسيط والآخر صعب:
- الملاءمة للمنتج: المنصات والمتصفحات والواجهات (واجهة الويب، والهاتف المحمول، وAPI) التي يجب اختبارها.
- الملاءمة للأشخاص: لغة المطورين أنفسهم تتيح لهم مراجعة الاختبارات وإصلاحها.
- الملاءمة لخط CI: تعمل دون واجهة رسومية (headless) في CI وتكتب نتائج تقرؤها منصة CI، مثل JUnit XML.
- المستقبل: صيانة نشطة أو دعم من المورّد، وتكلفة الترخيص، وطريق للخروج إن هُجرت الأداة.
جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار
الملكية والبيئات وبيانات الاختبار
تحدد الملكية من يكتب كل نوع من الاختبارات ومن يراجعه ومن يصونه، ومن يتصرف حين يفشل التشغيل. ومن التقسيمات الشائعة: يملك المطورون اختبارات الوحدة والمكوّنات ويكتبونها مع الشيفرة؛ ويصمم المختبِرون أو مهندسو الأتمتة اختبارات API واختبارات البداية إلى النهاية ويراجعها المطورون؛ وتخضع شيفرة الاختبارات كلها لمراجعة الشيفرة نفسها التي تخضع لها شيفرة المنتج. واجعل لكل جزء من الحزمة مالكاً مسمّى، حتى لا يكون شخص واحد هو الوحيد الذي يفهمه.
البيئات والبيانات تحدد إن كان يمكن الوثوق بنتيجة الفشل: فالاختبار الذي يفشل لأن اختباراً آخر غيّر بياناته يعلّم الفريق أن يتجاهل نتائج الفشل.
- البيئات: اختبارات الوحدة لا تحتاج إلى بيئة؛ واختبارات API واختبارات البداية إلى النهاية تعمل حيثما أمكن في بيئة تُنشأ لتشغيل خط CI، وتبقى بيئة Staging مشتركة للتكاملات الحقيقية.
- الأطراف الخارجية: تُستبدل خدمات الدفع والرسائل النصية ببدائل (Stubs) أو ببيئة المزوّد التجريبية (Sandbox) في المراحل المبكرة، ويُفحص التكامل الحقيقي في مرحلة لاحقة صغيرة.
- الإعدادات والأسرار: تأتي العناوين من إعدادات كل بيئة، والأسرار من مخزن الأسرار في منصة CI، ولا تأتي أبداً من شيفرة الاختبار.
- بيانات الاختبار: يُنشئ كل اختبار ما يحتاجه عبر API أو نص تهيئة البيانات (Seed Script) بقيم فريدة حتى لا تتصادم التشغيلات المتوازية؛ والبيانات اصطناعية ولا تُنسخ من الإنتاج أبداً؛ ويُتحكَّم في الساعة والقيم العشوائية حيث تعتمد النتيجة عليها.
جرّبها: مصنع بيانات الاختبار جرّبها: مولّد استجابات API وهمية
التقارير والصيانة
تبدأ التقارير بتحديد متى تعمل كل حزمة وماذا تفعل نتيجتها: مجموعة سريعة عند كل طلب دمج تمنع الدمج إذا فشلت، والحزمة الكاملة كل ليلة (بجدول Cron في إعدادات CI، مثل 0 2 * * * للتشغيل في الساعة 02:00 كل يوم؛ وتحقّق من المنطقة الزمنية التي يستخدمها)، وملخص قبل كل إصدار. وسمِّ من يقرأ كل نتيجة ومتى. وتقرير الفشل الجيد يتيح الفرز في دقائق: اسم الاختبار، والخطوة الفاشلة، والنتيجتان المتوقعة والفعلية، والبناء، والبيئة، ولقطة شاشة أو أثر تنفيذ (Trace) أو سجل لاختبارات المتصفح. ومع الوقت أبلغ عن الاتجاهات لا عن عدد الاختبارات: مدة التشغيل، ونسبة الاختبارات المتذبذبة (Flaky)، وحالات الفشل بحسب السبب (عيب في المنتج، أو عيب في الاختبار، أو مشكلة في البيئة).
الصيانة تُخطَّط ولا تُترك لوقت الفراغ. وتنص الاستراتيجية على قواعدها:
- وقت للصيانة في كل سبرنت، وتحديث الاختبارات في طلب الدمج نفسه الذي يحمل تغيير المنتج.
- الاختبار المتذبذب يُصلَح أو يُنقل إلى الحجر (Quarantine)، أي تشغيل منفصل لا يمنع الدمج، كما يوصي مقال مارتن فاولر عن عدم الحتمية في الاختبارات. وحدّد كم يبقى الاختبار هناك وكم اختباراً يتسع له الحجر، ولا تُعِد تشغيل حزمة فاشلة مرة بعد مرة حتى تنجح.
- تُحذف الاختبارات التي لم تعد تحمي شيئاً، وتأتي ترقيات إطار العمل والمتصفح في تغيير مستقل.
- تُراجَع الاستراتيجية نفسها وفق جدول، كل ربع سنة مثلاً، وحين يتغيّر المنتج أو الفريق.
مثال تطبيقي: صفحة واحدة لتطبيق توصيل طعام
يبني خمسة مطورين ومختبِران تطبيق ويب لتوصيل الطعام وواجهته البرمجية REST، ويصدرون نسخة كل أسبوعين. والانحدار اليوم 300 حالة اختبار يدوية تستغرق أربعة أيام، إضافة إلى 40 نصاً برمجياً للمتصفح سجّلتها مختبِرة واحدة وتشغّلها على حاسوبها. وهذه استراتيجيتهم في صفحة واحدة.
كل سطر فيها يسمّي مستوى أو شخصاً أو مكاناً أو وقتاً، فيستطيع العضو الجديد أن يعمل به، والهدف قابل للقياس، فتستطيع المراجعة الفصلية أن تتحقق منه.
استراتيجية الأتمتة: تطبيق ويب لتوصيل الطعام وواجهته البرمجية REST (تُراجَع كل ربع سنة)
الأهداف: انحدار الإصدار في يوم واحد بدلاً من 4 أيام؛ نتيجة طلب الدمج خلال 15 دقيقة.
النطاق:
اختبارات الوحدة: قواعد التسعير ورسوم التوصيل والعروض الترويجية.
واجهة API: الطلبات والمدفوعات وقوائم المطاعم والإلغاء.
من البداية إلى النهاية، 6 رحلات: التسجيل، والطلب بالبطاقة، والدفع عند الاستلام،
والإلغاء، وقبول المطعم للطلب، وتسليم المندوب.
يدوي عن قصد: جلسات استكشافية، ومراجعة التخطيط بالعربية والإنجليزية.
النصوص البرمجية الـ 40 المسجّلة تُستبدل ولا تُنقل كما هي.
الأدوات: Playwright مع TypeScript (لغة المطورين) لاختبارات API والمتصفح؛
النتائج بصيغة JUnit XML في CI. اختيرت بعد إثبات مفهوم مدته 3 أيام.
الملكية: المطورون لاختبارات الوحدة. المختبِرون لحزمتي API ومن البداية إلى النهاية،
ويراجعها المطورون. مالك مسمّى لكل مجال من مجالات الميزات.
البيئات: عند طلب الدمج تعمل اختبارات الوحدة وAPI في بيئة جديدة، مع بدائل (Stubs)
للدفع والرسائل النصية. ليلاً: كل الحزم، ومنها الرحلات الست، على Staging
مع البيئة التجريبية لمزوّد الدفع.
بيانات الاختبار: ينشئ كل اختبار عميله ومطعمه وطلبه عبر API بأسماء فريدة.
بيانات اصطناعية فقط. الساعة مثبّتة في اختبارات العروض الترويجية.
التقارير: مجموعة طلب الدمج تمنع الدمج إذا فشلت. يفرز مالك المجال نتيجة الليل
قبل الساعة 10:00. شهرياً: المدة، ونسبة التذبذب، وحالات الفشل بحسب السبب.
الصيانة: تتغير الاختبارات في طلب الدمج نفسه مع الشيفرة. يُصلَح الاختبار المتذبذب
أو يُحجَر خلال يومَي عمل، و5 اختبارات في الحجر كحد أقصى.
وقت للصيانة مخطَّط في كل سبرنت.أخطاء شائعة
- البدء بأداة («نستخدم Selenium») بدلاً من الهدف والنطاق اللذين يجب أن تخدمهما.
- كتابة وثيقة طويلة مرة واحدة وعدم مراجعتها أبداً.
- جعل شخص واحد مالكاً للحزمة كلها، فتتوقف الصيانة حين يغيب.
- تشغيل الاختبارات على بيئات وحسابات مشتركة، ثم لوم «الاختبارات المتذبذبة» على تصادم البيانات.
- قياس النجاح بعدد الاختبارات المؤتمتة بدلاً من زمن التغذية الراجعة ونسبة التذبذب والعيوب المتسرّبة.
- عدم تخطيط وقت للصيانة، فتتآكل الحزمة بعد أول إعادة تصميم.
من منظور ضمان الجودة
غالباً ما يساهم المختبِر في الاستراتيجية بدلاً من أن يكتبها وحده: فأنت تقدّم المخاطر ونطاق الانحدار وما يجب أن يبقى يدوياً، ويقدّم المطورون ومهندسو الأتمتة معرفتهم بالأدوات وخط CI. وفي جلسات تحسين القصص (Refinement) راجع كل قصة في ضوئها: أي مستوى، وأي مالك، وأي بيانات، وهل تدعم البيئة الفحص.
احتفظ بأدلة على نجاحها: مدة التشغيل، ونسبة التذبذب، وساعات الصيانة، والعيوب المتسرّبة. وفي كل مراجعة اقترح تغييرات محددة، مثل نقل رحلة بطيئة إلى طبقة API أو إضافة بديل (Stub)، بدلاً من المطالبة بـ«مزيد من الأتمتة».
تمرين عملي
راجِع مسودة استراتيجية للأتمتة
تطبيق ويب لحجز مواعيد عيادة يتيح للمرضى حجز المواعيد، ولموظفي الاستقبال إدارة جداول الأطباء، ويرسل تذكيرات برسائل نصية؛ ويصدر نسخة كل أسبوعين، ويستغرق الانحدار اليدوي ثلاثة أيام. راجع مسودة الاستراتيجية التالية التي كتبها قائد فريق الجودة في ضوء القرارات السبعة، ثم أعد كتابتها بحيث يصبح كل قرار محدداً.
تطبيق حجز مواعيد العيادة: استراتيجية الأتمتة (مسودة)
1. سنؤتمت كل اختبارات الانحدار.
2. الأداة: Selenium، لأنها الأشهر.
3. أحمد يكتب كل الاختبارات المؤتمتة ويصونها.
4. تعمل الاختبارات على خادم QA المشترك بحساب المريض التجريبي.
5. تُرسَل النتائج بالبريد الإلكتروني بعد كل تشغيل.- اربط كل سطر في المسودة بالقرار أو القرارات التي يغطيها، ودوّن القرارات التي لا سطر لها.
- اسأل عن كل سطر: هل يستطيع عضو جديد أن يعمل به، وما الذي قد يسوء؟
- أعد كتابة كل قرار ضعيف أو مفقود بحيث يسمّي مستوى أو شخصاً أو مكاناً أو وقتاً.
إظهار الإجابة النموذجية
الأهداف والنطاق (السطر 1): «كل اختبارات الانحدار» ليست هدفاً ولا نطاقاً. الأفضل: «الهدف: انحدار الإصدار في يوم واحد بدلاً من ثلاثة. قواعد الحجز (لا حجز مزدوج، والمواعيد داخل ساعات العمل) في اختبارات الوحدة وAPI؛ وأربع رحلات من البداية إلى النهاية: الحجز، وتغيير الموعد، والإلغاء، وحجب الاستقبال لموعد. يدوي عن قصد: الجلسات الاستكشافية ومراجعة التخطيط العربي».
الأدوات (السطر 2): الشهرة ليست معياراً. اختر بعد إثبات مفهوم على الحجز وتقويم الاستقبال، وفق لغة المطورين، والتشغيل دون واجهة رسومية في CI، ونتائج تقرؤها منصة CI.
الملكية (السطر 3): شخص واحد لكل شيء يعني أن الصيانة تتوقف حين يغيب. يملك المطورون اختبارات الوحدة، ويملك المختبِرون اختبارات API واختبارات البداية إلى النهاية ويراجعها المطورون، ولكل مجال مالك مسمّى.
البيئات والبيانات (السطر 4): الخادم المشترك والمريض المشترك يجعلان الاختبارات تتصادم. استخدم بيئة جديدة لكل طلب دمج، ودع كل اختبار ينشئ مريضه وطبيبه عبر API، واستبدل مزوّد الرسائل النصية ببديل (Stub)، وثبّت الساعة في اختبارات التذكير.
التقارير (السطر 5) والصيانة (مفقودة): بريد إلكتروني لا يتصرف أحد بناءً عليه ليس تقريراً. مجموعة طلب الدمج تمنع الدمج؛ ويفرز مالك المجال نتيجة الليل قبل الساعة 10:00؛ ويُصلَح الاختبار المتذبذب أو يُحجَر خلال يومَي عمل؛ ويُخطَّط وقت للصيانة في كل سبرنت؛ وتُراجَع الاستراتيجية كل ربع سنة.
أسئلة شائعة
هل استراتيجية الأتمتة هي نفسها استراتيجية الاختبار؟
لا. استراتيجية الاختبار تغطي الاختبار كله، اليدوي والمؤتمت: المستويات والأنواع والتقنيات والبيئات والمخاطر والتقارير. أما استراتيجية الأتمتة فهي الجزء الخاص بالأتمتة، وكثيراً ما تكون قسماً منها. ويجب أن تتفقا؛ فمثلاً نهج المخاطر في استراتيجية الاختبار هو ما يحدد ما تحميه الفحوص المؤتمتة أولاً.
من يكتب استراتيجية الأتمتة؟
عادةً يكتب مسودتها قائد الاختبار أو مهندس الأتمتة، ويتفق عليها الفريق كله، لأن المطورين يملكون جزءاً من الاختبارات ومن خط CI. ويقدّم المختبِرون المخاطر ونطاق الانحدار وما يجب أن يبقى يدوياً. والاستراتيجية التي لم يتفق عليها الفريق لا يتبعها أحد.
ما الطول المناسب لها؟
أقصر ما يمكن مع بقائها محددة؛ وصفحة أو صفحتان تكفيان عادةً لفريق منتج. ويجب أن يسمّي كل قرار مستوى أو شخصاً أو مكاناً أو وقتاً. أما التفاصيل مثل بنية المجلدات وأعراف كتابة الشيفرة وقواعد المحددات (Locators) فمكانها توثيق إطار العمل نفسه، وتتناولها الدروس اللاحقة.
متى يجب أن تتغير الاستراتيجية؟
راجعها وفق جدول، كل ربع سنة مثلاً، وحين يتغير شيء كبير: منصة جديدة مثل تطبيق للهاتف المحمول، أو فريق جديد، أو نظام CI جديد، أو هدف تُظهر الأرقام أنه لا يتحقق. وسجّل ما تغيّر ولماذا.
المراجع
- Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Eradicating Non-Determinism in Tests (Martin Fowler)لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
تدرّب بأدوات متقن
قيّم الميزات حسب الاحتمالية والأثر، ثم ولّد خطة اختبار مبنية على المخاطر ومرتّبة حسب الأولوية.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
مصنع متكامل لبيانات الاختبار الاصطناعية: مستخدمون وعملاء وشركات وعناوين وأرقام وتواريخ وسلاسل نصية بصيغة JSON أو CSV أو SQL أو XML.
ولّد استجابات API وهمية كاملة (الحالة والترويسات وجسم JSON) لحالات النجاح والقوائم والتفاصيل والأخطاء والنتائج الفارغة.
أنشئ تعابير cron بصرياً وعاين أوقات التشغيل التالية.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.