فحوص آلية يعتمد عليها فريقك
تحل أتمتة الاختبارات محل الفحص اليدوي المتكرر، بشيفرة تستخدم برمجياتك كما يستخدمها الناس. نحدد الرحلات التي يقوم عليها عملك، ونكتب لها اختبارات شاملة من البداية إلى النهاية، واختبارات لواجهات البرمجة (API) وللمكونات، ونربط الحزمة بمسار التسليم لتعمل مع كل تغيير، ونعدّ تقارير تجعل فهم أي فشل سريعاً.
وهي تناسب الفرق التي تُصدر ببطء لأن كل نسخة تحتاج إلى أيام من اختبارات التراجع اليدوية، والفرق التي تطلق أخطاء لأن أحداً لم يجد وقتاً للاختبار، والفرق التي تفشل حزمتها الحالية عشوائياً فلا يلتفت إليها أحد. ولا تحل الأتمتة محل الاختبار الاستكشافي الذي يجريه شخص، بل تعفيه من تكرار النقرات نفسها ليبحث عن مشكلات جديدة.
خطة اختبار مبنية على المخاطر
نرتب الرحلات بحسب تكلفة فشلها ومدى تكرار تغيّر الشيفرة التي تحتها، ونؤتمت من أعلى القائمة.
الاختبارات الشاملة
تسجّل اختبارات المتصفح والجوال الدخول، وتبحث، وتطلب، وتدفع، وتدير كما يفعل مستخدم حقيقي، في بيئة ذات بيانات اختبار مضبوطة.
اختبارات واجهات البرمجة والعقود
اختبارات أسرع تحت الواجهة تتأكد أن الخدمات تقبل وتعيد ما تتوقعه الأطراف المستخدمة لها، فتكشف التغييرات التي تكسر التوافق قبل أن تتأثر الشاشات.
الدمج في مسار التسليم
تعمل الحزم تلقائياً مع كل تغيير وقبل كل إصدار، وبالتوازي لتبقى النتيجة سريعة، وتمنع النشر حين تفشل رحلة حرجة.
التعامل مع الاختبارات غير المستقرة
نرصد الاختبارات التي تنجح وتفشل دون أي تغيير في الشيفرة، ونعزلها، ونعالج السبب، سواء كان التوقيت أو البيانات المشتركة أو بيئة غير مستقرة.
تقارير فشل واضحة
يصل كل فشل مع لقطة شاشة وفيديو وسجلات والخطوة التي تعطلت، فيرى المطور المشكلة دون إعادة تشغيل الاختبار.
ما تتسلمه منا
- خطة اختبار مرتبة بحسب المخاطر
- حزمة الاختبارات الشاملة
- اختبارات واجهات البرمجة والعقود
- بيانات الاختبار وبيئاته
- مهام مسار التسليم ونقاط التحقق فيه
- تقارير فشل مدعومة بالأدلة
- لوحة لمتابعة الاختبارات غير المستقرة
- دليل لإضافة الاختبارات
طريقة عملنا
- 01
تحديد ما يهم
نرسم رحلات المنتج الرئيسية مع فريقي المنتج والدعم، ونراجع الحوادث السابقة والفحوص اليدوية الحالية، ونتفق على قائمة قصيرة تحمي فيها الأتمتة أكثر من غيرها.
- 02
وضع الأساس
نعدّ إطار العمل واستراتيجية بيانات الاختبار وبيئة مخصصة، ونؤتمت أول رحلة من بدايتها إلى نهايتها ونشغّلها في مسار التسليم قبل أن تكبر الحزمة.
- 03
بناء الحزمة
نضيف الاختبارات رحلةً بعد رحلة بحسب الأولوية، مكتوبة لتكون سهلة القراءة ومستقلة بعضها عن بعض، ولا يُحتسب أي اختبار جديد إلا بعد أن يثبت استقراره في تشغيلات متكررة.
- 04
نقل الممارسة
يتعلم مطوروك كتابة الاختبارات وصيانتها بالأسلوب نفسه، ونتفق على من يتولى معالجة حالات الفشل، وتتابع لوحة زمن التشغيل ونسبة النجاح وعدم الاستقرار من ذلك الحين.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| اختبار الويب | Playwright، Cypress، Vitest، Testing Library |
| اختبار الجوال | Maestro، Detox، Appium، XCUITest |
| اختبار واجهات البرمجة | Postman، Pact، k6، Supertest |
| مسارات التسليم | GitHub Actions، GitLab CI، CircleCI، تقارير Allure |
كل إصدار يحتاج إلى أيام من الفحص اليدوي
تجري اختبارات التراجع يدوياً، ويطول وقتها مع كل ميزة، ومع ذلك تتسرب الأخطاء. ولديك حزمة آلية قديمة، لكنها تفشل بطريقة لا يمكن توقعها حتى صار الناس يعيدون تشغيلها إلى أن تنجح. وأنت تريد فحوصاً سريعة يمكن الاعتماد عليها للرحلات التي تأتي بإيراداتك.
- منتجات تُصدر ببطء شديد
- فرق بلا مختبرين متفرغين
- حزم لا يثق بها أحد
- تطبيقات شهدت حوادث مكلفة
- مسارات الشراء والدفع
- برمجيات مقبلة على إعادة هيكلة كبيرة
أسئلة شائعة
كم اختباراً نحتاج فعلاً؟
أقل مما قد تتوقع. فعدد معتدل من الاختبارات الشاملة يغطي الرحلات المهمة، تدعمه اختبارات أسرع لواجهات البرمجة والمكونات، يحميك أكثر من مئات السيناريوهات الهشة على الواجهة. ولكل اختبار تكلفة تشغيل وصيانة. ونسعى إلى أصغر حزمة كانت ستكشف حوادثك السابقة، ولا نوسّعها إلا حين يظهر خطر جديد.
ما الذي يجعل الاختبارات غير مستقرة، وكيف تعالجونها؟
الاختبار غير المستقر ينجح ويفشل على الشيفرة نفسها. ومن أسبابه الشائعة انتظار وقت ثابت بدلاً من شرط، واختبارات تتشارك البيانات، والاعتماد على خدمات خارجية، وبيئات تحت ضغط. نرصد عدم الاستقرار بتشغيل الاختبارات مراراً، ونعزل المتسبب منها حتى لا يعطّل الإصدارات، ثم نعالج السبب. أما إعادة التشغيل حتى النجاح فلا تفعل سوى إخفاء المشكلة.
هل تحل أتمتة الاختبارات محل المختبرين اليدويين لدينا؟
لا. إنها تحل محل الجزء المتكرر من عملهم. فالاختبارات الآلية تؤكد أن السلوك المعروف ما زال سليماً، ويبقى الناس ضروريين لاستكشاف الميزات الجديدة، والحكم على ما إذا كان الشيء يبدو صحيحاً، والتفكير في حالات لم يدوّنها أحد. والفرق التي تؤتمت اختبارات التراجع تجد عادةً أن قيمة مختبريها تزداد، لأن وقتهم ينتقل من التكرار إلى التحقيق.
هل يمكنكم إضافة اختبارات إلى برمجيات تخلو منها؟
نعم، وهي نقطة بداية شائعة. نبدأ من الخارج باختبارات شاملة للرحلات الحرجة، لأنها لا تتطلب أي تغيير في الشيفرة. وتتيح شبكة الأمان هذه للمطورين بعد ذلك إعادة هيكلة الأجزاء الداخلية وإضافة اختبارات أدنى مستوى تدريجياً. أما محاولة بلوغ تغطية عالية في كل مكان دفعة واحدة فبطيئة، ونادراً ما تكون أفضل استخدام للميزانية.
من يصون الاختبارات بعد انتهاء عملكم؟
مطوروك، ولهذا يُعدّ التسليم جزءاً من العمل. فنكتب الاختبارات بلغة المنتج نفسها وفي مستودعه كلما أمكن، وفق نمط موثق، مع دليل لإضافة المزيد. ونتفق على من يستجيب حين يفشل اختبار. فالحزمة التي لا مسؤول عنها تتدهور سريعاً، أياً كان كاتبها، لذلك يهم هذا الاتفاق بقدر الشيفرة نفسها.