أتمتة الاختبارات بالذكاء الاصطناعي: ماذا يتغير للفريق؟

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

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

كيف تعمل الأتمتة المبرمجة، وأين تكلّفك

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

هذه الدقة هي نقطة الضعف ذاتها:

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

ليس هذا تقصيرًا من الفريق. هذه طبيعة النموذج نفسه: كل اختبار يُبنى يدويًا ويُصان يدويًا.

ما الذي تغيّره أتمتة الاختبارات بالذكاء الاصطناعي

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

الاختبار يبدأ من المتطلب، لا من تسجيل الشاشة

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

الاستكشاف يجد المسارات التي لم يوثّقها أحد

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

الإصلاح الذاتي عند تغير الواجهة

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

التشغيل المتوازي يختصر الانتظار

تعمل الاختبارات جنبًا إلى جنب على عدة متصفحات وأحجام شاشات بدل طابور واحد طويل. ومع التكامل مع CI/CD تعود نتيجة الانحدار الكاملة مع الـ commit نفسه، لا في صباح اليوم التالي.

الفشل يصل ومعه الدليل

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

ما الذي لا يتغير

الذكاء الاصطناعي يغيّر من يكتب الاختبارات ومن يصونها. ولا يغيّر من يملك الجودة.

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

مقارنة مباشرة

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

ما الذي يتغير في عمل الفريق

الفريق لا يفقد دوره. عمله يرتفع مستوى واحدًا.

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

المؤشرات التي تقيسها قبل وبعد

سجّل هذه المؤشرات على مجموعتك الحالية أولًا. بلا خط أساس يصبح كل حديث عن التحسن مجرد رأي.

1. الزمن من الـ commit حتى نتيجة الانحدار الكاملة. الرقم الذي يخبرك هل يواكب الاختبار سرعة التسليم.
2. ساعات الصيانة في كل سبرنت. الساعات التي تذهب لإصلاح اختبارات فشلت دون عيب حقيقي.
3. نسبة الاختبارات المتذبذبة. الاختبارات التي تنجح وتفشل على البناء نفسه دون تغيير في الكود. وهي تعلّم الفريق تجاهل اللون الأحمر.
4. تغطية المتطلبات. نسبة قصص المستخدمين ونقاط API التي لها اختبار معتمد واحد على الأقل.
5. العيوب المتسربة في كل إصدار. عيوب ظهرت في الإنتاج وكان يفترض أن يلتقطها اختبار.
6. زمن تحليل الفشل. من البناء الأحمر حتى تأكيد السبب.

وهنا إطار مفيد: معيار ISO/IEC 25010 يعرّف نموذجًا لجودة المنتجات البرمجية من تسع خصائص، وقابلية الصيانة إحداها. ومجموعة الاختبارات منتج برمجي بحد ذاتها. إن لم تكن قابلة للصيانة بسرعة تغيّر التطبيق، فهي تفشل في خاصية جودة تخصها هي.

البيانات والاستضافة والسيادة

تشغيل الاختبارات يلمس مسارات حقيقية، وأحيانًا نسخًا من بيانات عملاء حقيقيين. ونظام حماية البيانات الشخصية يحكم التعامل مع البيانات الشخصية للأفراد، ولا تُستثنى منه بيئة لمجرد أن اسمها "بيئة اختبار".

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

كيف تثبت الفرق على تطبيقك أنت

لا تقرر بناءً على عرض تقديمي. قرر بناءً على تطبيق من تطبيقاتك.

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

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

ابدأ بمراجعة جاهزية الجودة

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