خريطة لأدوات الاختبار حسب العائد الفريد

الوحدة

  • تلتقط دون غيرها: المنطق الخاطئ، خلال مللي ثوانٍ، مع تحديد دقيق لموضع الإخفاق.

  • أرخص تغذية راجعة موجودة. لا شيء يحل محلها.

API

  • تلتقط دون غيرها: السلوك الخاطئ عند حدود الخدمة، بما في ذلك الحالات التي لا تكشفها أي واجهة.

  • أسرع وأدقّ من تحريك متصفح.

من طرف إلى طرف

  • تلتقط دون غيرها: إخفاق المنتج مجمَّعاً بينما يعمل كل جزء منه.

  • الأبطأ، والطبقة الوحيدة التي تجيب عن سؤال المستخدم.

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

أين تقع الفجوة عادةً

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

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

السؤال الذي يتفوّق على جدول المزايا

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

الأداة التي تملكها بالفعل ولا تستخدمها

قبل إضافة أي شيء، يجدر التحقق مما هو مثبَّت بالفعل وعاطل عن العمل، فمعظم المؤسسات تملك من قدرات الاختبار أكثر مما تستخدم.

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

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

أين تُنفَق الساعة القادمة

  1. المسار الذي سيُحرجك تعطّله، مغطّى من طرف إلى طرف.

  2. وواجهة API التي خلفه، مغطّاة بما في ذلك الحالات السلبية.

  3. وآخر ما تعطّل، محوَّلاً إلى فحص دائم.

الطرفية

npm install -g @testsprite/testsprite-cli
testsprite setup

وتغطي لوحة التحكم المجال نفسه لمن لا يريد تثبيتاً محلياً، وتوجد مجموعة الأوامر الكاملة في مستودع CLI.

  • GitHub App هو خطّاف ويب تُعِدّه في لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي ينتجه خط المعالجة لديك أصلاً، فلا يتغير شيء في مستودعك.

  • GitHub Actions يضع الخطوة داخل سير العمل الخاص بك، ويُضبط من الطرفية.

أين يقع TestSprite على الخريطة

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

تُبقي Auto-Authentication الجلسات حيّة طوال الجولة، وتنقل Dynamic Variables القيم بين الاستدعاءات، وتستنتج Dependency Chains ترتيب التنفيذ، وتزيل Auto-Cleanup ما أنشأته الجولة بالضبط. وخطوات المتصفح مقاصد لا محدِّدات، فإعادة التصميم لا تصبغ المجموعة بالأحمر.

تبقى اختبارات الوحدة ملكك وتبقى أرخص تغذية راجعة لديك. ويبقى اختبار العقود والحِمل والفحص الأمني أدوات منفصلة. والفائدة أن الوسط النحيل يمتلئ من دون إضافة عبء تأليف يزاحم إطلاق المنتج.

كم أداة اختبار ينبغي أن نملك؟

أقل عدد يغطي الطبقات التي تحتاجها. فكل أداة إضافية شيء آخر يجب ضبطه وتشغيله وتفسير نتائجه.

هل ما زال هرم الاختبار صحيحاً؟

الشكل خيار افتراضي معقول. لكن النسخة المفيدة منه ليست نسبة عددية، بل سؤال عمّا تلتقطه كل طبقة دون غيرها.

هل ينبغي أن نوحّد الأدوات بين الفرق؟

بالنسبة إلى التقارير والتكامل مع CI، نعم. أما فرض أداة واحدة على كل فريق فينتج عنه عادةً أداة يُحسن فريق واحد استخدامها ويتجنبها الآخرون.

ما الفجوة الأكثر شيوعاً؟

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

كيف نعرف أن الأداة تستحق مكانها؟

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

باختصار

ارسم الخريطة حسب العائد الفريد، لا حسب الفئة.

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