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