ما الذي يفعله وكيل الاختبار بالذكاء الاصطناعي على نحو مختلف
يشتقّ التغطية من منتجك. من مواصفة، أو مستند متطلبات، أو باستكشاف التطبيق أثناء تشغيله، لا مما تذكّر أحدهم أن يكتبه.
يعبّر عن الخطوات بوصفها نوايا. «افتح صفحة الإعدادات» بدلًا من مسار عبر الـ DOM، ولهذا لا تُعطّله عادةً إعادة التصميم الشكلية.
يُعيد إخفاقًا يستطيع من يتولى الإصلاح الاستفادة منه. ما الذي جرت محاولته، وما الذي حدث، وأين تباعد الاثنان، في صيغة يمكن لوكيل آخر أن يتصرف بناءً عليها.
نمط الإخفاق الأول: إرضاء الفحص
حين يُطلب من الوكيل أن يجعل اختبارًا ينجح، قد يسلك أقصر طريق، وتعديل الفحص أقصر أحيانًا من إصلاح المنتج. ليس في الأمر سوء نية، بل هدف غير محدَّد بدقة كافية.
الاحتراز من ذلك زهيد التكلفة. حدِّد في كل فحص مُخرَجًا ملموسًا قابلًا للملاحظة، واكسِر شيئًا عن عمد لتتأكد أن الفحص قادر على الإخفاق. فالفحص الذي لا يمكن أن يُخفق لا يحمي شيئًا.
نمط الإخفاق الثاني: تغطية واثقة لم يقرأها أحد
سيُنتج الوكيل مئتي حالة اختبار دون تردد. والكمّ يبدو كأنه تقدّم، والتغطية التي لم يراجعها أحد تغطية لا يمكن لأحد الاعتماد عليها، لأنك لا تعرف ما الذي تؤكّده.
اقرأ الخطة لا الشيفرة. احذف المسارات الإدارية، وأضِف قواعد المنتج غير المدوَّنة في أي مكان، وتعامل معها كما تتعامل مع طلب دمج.
ما لا يزال عاجزًا عنه
معرفة قواعد عملك
ما ينبغي أن يحدث عند انطباق خصمين معًا قرارٌ، لا استنتاج.
ابتكار حالة إساءة الاستخدام
سيفحص الصلاحيات، لكنه لن يفكر في سير العمل الذي يمكن لأحدهم التلاعب به.
إصلاح بيئة معطوبة
التذبذب الناتج عن البنية التحتية يبقى تذبذبًا.
مراجعة الخطة بكفاءة
الكلفة المستمرة الأساسية لهذا الأسلوب في العمل هي قراءة تغطية لم تكتبها أنت، ورداءة هذه القراءة هي ما يُنتج نمطَي الإخفاق أعلاه. وثمة طريقة سريعة لذلك.
اقرأ التأكيدات وحدها. تجاوز الخطوات كليًا في المرور الأول، فالخطوات آلية، أما التأكيدات فهي موضع الحكم. وأي تأكيد يصدق على منتج معطوب هو ما ينبغي إصلاحه، ورصده سهل متى قصرت نظرك عليها وحدها.
ثم امسح القائمة بحثًا عمّا ينقصها لا عمّا فيها. فالخطط المولَّدة مكتملة على نحو موثوق فيما يخص نقاط النهاية الموجودة، وصامتة على نحو موثوق عن القواعد التي تسكن رأس أحدهم. وإضافة ثلاث من تلك القواعد أجدى من تصحيح ثلاثين خطوة.
البدء
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل ألّا تثبّت شيئًا محليًا. أما بقية واجهة الـ CLI فتجدها في مستودع CLI.
المُشغِّل أهم من الآلية. فتوجيهه إلى حدث النشر لديك يعني فحص كل تغيير دون أن يقرّر أحد ذلك؛ GitHub App يقوم بذلك من لوحة التحكم، وخطوة GitHub Actions تقوم به من داخل سير عملك.
ما الذي يفعله TestSprite بوصفه وكيلًا
يشتقّ التغطية من مصادرك ومن التطبيق أثناء تشغيله، ويعبّر عن الخطوات بوصفها نوايا كي لا يُعطّلها التغيير الشكلي، ويعمل على التطبيق المنشور، ويُعيد الإخفاق في صورة: ما الذي جرت محاولته، وما الذي حدث، وأين تباعد الاثنان.
يثبّت الإعداد مهارة التحقق داخل وكيل البرمجة الذي تستخدمه أصلًا، فيجري ذلك كله ضمن الحلقة التي تُكتب فيها الشيفرة، لا كخطوة منفصلة يتذكّرها أحدهم.
القيمة في انغلاق الحلقة. فالتغيير يُفحص في مواجهة المنتج أثناء تشغيله، والإخفاق يعود في صيغة يستطيع الوكيل التصرف بناءً عليها، والإصلاح يؤكّده شيء غير الاستدلال الذي أنتجه. ويبقى على عاتقك قراءة الخطة وتحديد معنى الصواب، وهي ساعة في الأسبوع لا وظيفة قائمة بذاتها.
بمَ يختلف هذا عن مولِّد الاختبارات؟
المولِّد يُنتج شيفرة تتولى أنت تشغيلها وصيانتها. أما الوكيل فيشغّلها أيضًا، ويقرأ النتيجة، ويستطيع التكرار عليها، وهذا ما يُغلق الحلقة.
هل يمكنه العمل دون مواصفة؟
نعم، باستكشاف التطبيق أثناء تشغيله، وإن كانت المواصفة أو مستند المتطلبات يُنتجان خطة أولى أفضل.
كم من المراجعة يحتاج؟
اقرأ الخطة قبل التشغيل الأول وبعد أي إعادة توليد كبيرة. وفي ما بين ذلك، راجع الحالات الجديدة كما تراجع الشيفرة.
ما الذي يمنعه من تكبيد تكاليف متصاعدة؟
التشغيلات تستهلك أرصدة، فاضبط التوقعات قبل أي جلسة طويلة. والوكيل الذي بحوزته أداة تحقق سيستخدمها، وهذا هو المقصود، ويستحق أن تُخصَّص له ميزانية.
هل يحلّ محل مهندس QA؟
يحلّ محل النصف المتكرر. أما تعريف الصواب والتفكير العدائي فيظلان عملًا بشريًا، وهما النصف الأثمن على أي حال.
هو يقرّر ما الذي يُفحص. وأنت افحص ما قرّره.
يشتقّ وكيل الاختبار بالذكاء الاصطناعي التغطية، ويعبّر عن الخطوات بوصفها نوايا، ويُعيد إخفاقات صالحة للاستخدام. احترِس من الفحوص التي لا يمكن أن تُخفق ومن التغطية التي لم يقرأها أحد، وأبقِ قواعد العمل وحالات إساءة الاستخدام في أيدٍ بشرية.