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