ما أتمتة الاختبار؟

لماذا يهم

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

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

مما يتكوّن الاختبار المؤتمت

للاختبار المؤتمت أجزاء حالة الاختبار اليدوية الجيدة نفسها، لكنها مكتوبة شيفرةً. فهو يهيّئ الشروط المسبقة (Arrange)، وينفّذ الخطوات (Act)، ويؤكّد بمقارنة النتائج الفعلية بالنتائج المتوقعة (Assert)، ثم ينظّف ما أحدثه ليبدأ الاختبار التالي من حالة معروفة. والتأكيد (Assertion) هو قلب الاختبار: فبلا نتيجة متوقعة دقيقة لا يثبت النص البرمجي إلا أن شيئاً لم ينهَر. ويسمّي بعض الممارسين الاختبار المؤتمت «فحصاً» (Check) للتشديد على أنه لا يتحقق إلا مما قرّره أحدٌ مسبقاً.

أدناه حالة تسجيل الدخول نفسها مكتوبةً اختبارَ متصفح بأداة Playwright، ولاختبارات Selenium WebDriver وCypress الشكل نفسه. ولا تحتاج الآن إلى فهم كل كلمة مفتاحية: اقرأ التعليقات والخطوات والتأكيد. والسطر مثل page.getByLabel('Email') محدِّد (Locator)، أي طريقة يجد بها الاختبار عنصراً في الصفحة، وهنا عبر تسميته الظاهرة. والنص البرمجي ليس إلا جزءاً واحداً مما يسمّيه منهج ISTQB المتقدم لهندسة أتمتة الاختبار «حل أتمتة الاختبار» (Test Automation Solution): النصوص البرمجية مع كل ما يلزم لتشغيلها والإبلاغ عن نتائجها. وكل جزء منه قابل للتعطّل:

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

import { test, expect } from '@playwright/test';
import { testUser } from './test-data';

test('registered user can sign in', async ({ page }) => {
  // Arrange: start on the sign-in page with a known test account
  await page.goto('/login'); // resolved against baseURL in playwright.config.ts

  // Act: the steps of the manual test case
  await page.getByLabel('Email').fill(testUser.email);
  await page.getByLabel('Password').fill(testUser.password);
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Assert: the expected result, decided before the test ran
  await expect(page.getByRole('heading', { name: 'My account' })).toBeVisible();

  // Clean up: nothing to undo, signing in changes no data
});

جرّبها: مختبِر REST API جرّبها: مولّد طلبات REST

ما تقدّمه الأتمتة للفريق

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

• تغذية راجعة سريعة عن الانحدار: تعمل الحزمة عند كل تغيير، فيُبلَّغ عن الانحدار والمطوّر ما زال يتذكر الشيفرة.
• مقارنة دقيقة ومتكررة: كل حقل في الاستجابة وكل إجمالي حتى آخر هللة، في كل تشغيل؛ أما الإنسان الذي يعيد الحالة للمرة العشرين فيبدأ بالقراءة السريعة.
• التوسّع (Scale): الخطوات نفسها على مئات صفوف البيانات، وفي عدة متصفحات، وكل ليلة.
• بوابة جودة: يستطيع الفحص المؤتمت في خط التكامل إيقاف بناء معطوب عند كل تغيير، قبل أن يصل إلى بيئة Staging، ودون انتظار أحد.
• توثيق حي: اختبار اسمه «الطلبات بقيمة ⁦300.00⁩ ريال فأكثر توصيلها مجاني» يذكر قاعدة ويُظهر في كل تشغيل أنها ما زالت صحيحة.
• وقت المختبِر: الساعات التي كانت تذهب في إعادة تنفيذ الحالات المكتوبة تذهب إلى الاختبار الاستكشافي وإلى تصميم اختبارات الميزات الجديدة.

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

ما الذي يسوء بعد أن توجد النصوص البرمجية

مخاطر درس الأدوات الداعمة للاختبار تخص قرار الأتمتة: توقعات غير واقعية، وجهد مقدَّر بأقل من حقيقته، وأداة غير مناسبة. وبعد أن توجد الحزمة تظهر مجموعة ثانية، ومعظمها يأتي من النصوص البرمجية نفسها:

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

شيفرة الأتمتة برمجيات وتحتاج إلى صيانة

حزمة الاختبارات برنامج يختبر برنامجاً آخر. لها متطلبات (حالات الاختبار التي تنفّذها)، وتصميم، واعتماديات، وعيوب خاصة بها: نتيجة متوقعة خاطئة، أو انتظار ناقص، أو اختبار لا ينجح إلا بعد تشغيل اختبار آخر. وهي تعيش ما يعيشه المنتج، فتتغير كلما تغيّر.

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

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

مثال تطبيقي: إعادة تصميم واحدة و⁦37⁩ اختباراً أحمر

لدى فريق ⁦120⁩ اختباراً للمتصفح. قسّم المصممون صفحة تسجيل الدخول إلى خطوتين، البريد الإلكتروني وزر «Continue» أولاً ثم كلمة المرور، وغيّروا اسم الزر من «Sign in» إلى «Log in». فأظهر التشغيل الليلي ⁦37⁩ فشلاً. فرز المختبِر النتائج قبل أن يعيد أحدٌ تشغيل أي شيء: حالات الفشل هي بالضبط الاختبارات الـ⁦37⁩ التي تسجّل الدخول، وكلها تتوقف عند خطوة تسجيل الدخول، ولكل ملف من ملفاتها نسخته الخاصة من أسطر تسجيل الدخول. المنتج يعمل؛ والاختبارات هي المتقادمة.

كان ترقيع ⁦37⁩ ملفاً سيستغرق معظم يوم ويتكرر عند إعادة التصميم التالية، فنقل الفريق الخطوات إلى دالة مساعدة واحدة تُعدَّل وتُراجَع مرة واحدة. وبعد الإصلاح نجح ⁦36⁩ اختباراً، وظل واحد يفشل في خطوة لاحقة: خيار «Remember me» لم يعد يُبقي المستخدم مسجّلاً بعد إعادة تشغيل المتصفح. أعاد المختبِر إنتاج المشكلة يدوياً وأبلغ عن عيب في المنتج، وهذا بالضبط ما وُجدت الحزمة من أجله.

// Before: these three lines were copied into 37 test files
//   await page.getByLabel('Email').fill(testUser.email);
//   await page.getByLabel('Password').fill(testUser.password);
//   await page.getByRole('button', { name: 'Sign in' }).click();

// After: one helper (sign-in.ts) that every test calls; the next redesign means one edit
import type { Page } from '@playwright/test';
import type { TestUser } from './test-data';

export async function signIn(page: Page, user: TestUser) {
  // Step 1: email, then "Continue". Step 2: password, then the renamed button.
  await page.getByLabel('Email').fill(user.email);
  await page.getByRole('button', { name: 'Continue' }).click();
  await page.getByLabel('Password').fill(user.password);
  await page.getByRole('button', { name: 'Log in' }).click();
}

// In each test: await signIn(page, testUser);

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
• Best Practices — PlaywrightMicrosoft (Playwright)اختبر السلوك الذي يراه المستخدم، واجعل الاختبارات معزولة، وفضّل المحدِّدات المتينة والتأكيدات التي تنتظر، واستخدم التتبّع لتصحيح الأخطاء.