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