هل تعتقد أنك توفر المال؟ يكلف المختبرون السيئون 10 أضعاف تكلفة وقت التوقف عن العمل!

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

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

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

لقد رأيت فرقًا تدفع مرتين مقابل نفس عمل الاختبار. إنهم يستأجرون مختبرًا رخيصًا، ويشعرون بالرضا تجاه السعر، ثم يواجهون أخطاء بعد الإطلاق. يقضي فريق المنتج ساعات إضافية في إجراء الإصلاحات. الدعم يحصل على المزيد من التذاكر. يفقد المستخدمون الثقة. بدأ "السعر المنخفض" يبدو باهظ الثمن. هذا هو الجزء الذي أريد أن يراه الناس. المختبر ليس مجرد شخص ينقر على الصفحة. أبحث عن شخص يمكنه التفكير كمستخدم، وتحديد نقاط الضعف، وشرح المشكلات بكلمات واضحة. إذا كان التقرير غامضا، فإن الفريق يضيع الوقت. إذا أخطأ الاختبار مسارات المستخدم الشائعة، فسيظل المنتج ينكسر في المكان الأكثر ضررًا. ما يهمني هو التكلفة بعد قرار التوظيف، وليس التكلفة الموجودة على الفاتورة فقط. عندما أقوم بمراجعة المختبرين، أنظر إلى بعض الأشياء. 1. نماذج من تقارير الأخطاء أطلب مثالاً حقيقيًا للعمل السابق. يخبرني تقرير مفيد عن العطل ومكان العطل والجهاز أو المتصفح الذي تم استخدامه والخطوات التي أدت إلى حدوث المشكلة. والتقرير الضعيف يقول فقط: "لا يعمل". هذه الفجوة الصغيرة مهمة. عندما يكون التقرير واضحًا، يمكن للمهندسين حل المشكلة بشكل أسرع. عندما يكون التقرير ضعيفًا، فإنهم يقضون وقتًا في التخمين. 2. اختبار التفكير أريد مُختبِرًا يطرح أسئلة جيدة. ماذا يحدث إذا أدخل المستخدم رمزًا خاطئًا؟ ماذا لو تم تحميل الصفحة ببطء؟ ماذا لو تم الطلب من هاتف ذو شاشة صغيرة؟ هذه الأسئلة توفر المال. إنهم يلتقطون نوع الأخطاء التي لا ترغب فرق المبيعات وفرق الدعم في معالجتها لاحقًا. 3. ملاءمة المنتج قد لا يكون المُختبِر الذي يعمل بشكل جيد على صفحة مقصودة بسيطة هو الخيار الصحيح لتدفق الدفع أو تطبيق الهاتف المحمول أو منتج SaaS كبير. لقد رأيت ذات مرة متجرًا صغيرًا عبر الإنترنت يستأجر أداة اختبار منخفضة التكلفة لإجراء اختبار الدفع. مرر المُختبر خلال التدفق مرتين وقال إن العملية تبدو جيدة. بعد أسبوع من الإطلاق، اكتشف المستخدمون فشل رمز الخصم في أحد متصفحات الأجهزة المحمولة. كان على الفريق الرد على الشكاوى ومعالجة المبالغ المستردة وتصحيح المشكلة تحت الضغط. وجد مختبر ثانٍ نفس النوع من المشكلة في مشروع آخر. هذه المرة، قامت بالتحقق من نوع المتصفح وحجم الجهاز ومنطق القسيمة معًا. لقد وجدت الخطأ قبل أن يفعله العملاء. أنقذ الفريق ساعات من التنظيف. وهذا هو الفرق الذي أهتم به. 4. أسلوب الاتصال يمكن للمختبر العثور على خطأ ويضيع الوقت إذا كان من الصعب قراءة الرسالة. أحتاج إلى ملاحظات قصيرة وواضحة ومفيدة. أحتاج إلى خطوات يمكنني اتباعها. أحتاج إلى لقطة شاشة أو تسجيل شاشة عندما يكون من الصعب شرح المشكلة. أريد أيضًا أن يخبرني بمدى خطورة المشكلة، ليس بطريقة درامية، ولكن بطريقة مفيدة. إذا فشل الخروج، فهذا ليس نفس الخطأ المطبعي في التذييل. المختبر الأقوى يعرف الفجوة. 5. العمل التجريبي أحب النسخة التجريبية القصيرة مدفوعة الأجر. أعطي مهمة صغيرة وأشاهد النتيجة. أرى كيف يتعامل المختبر مع الحالات البسيطة وحالات الحافة والتقرير النهائي. أرى أيضًا مدى سرعة ردود الشخص ومدى توافق التفاصيل مع المنتج. تجربة قصيرة تخبرني بأكثر من مجرد صفحة ملف شخصي طويلة. أستخدم هذا النهج لأن الاختبارات منخفضة الجودة لا تبقى رخيصة. وعادة ما يخلق ثلاث تكاليف إضافية. التكلفة الأولى هي إعادة العمل. التكلفة الثانية هي الوقت الضائع. التكلفة الثالثة هي إحباط المستخدم. هذه التكاليف ليست مرئية دائمًا في اليوم الأول. فهي تظهر بعد الإصدار، عندما يكون الفريق متعبًا ويكون المنتج معروضًا بالفعل أمام العملاء. أفضل أن أدفع مقابل الرعاية والتفكير الواضح والعادات الصلبة. لا أحتاج إلى كلمات براقة. أحتاج إلى مختبر يتحقق من المسار الذي يسلكه المستخدمون بالفعل. أحتاج إلى من يلاحظ الاستراحة الصغيرة التي تتحول إلى مشكلة كبيرة. هكذا أرى الأمر. إذا أنفقت مبلغًا أكبر قليلًا على مُختبِر دقيق، فغالبًا ما أنفق مبلغًا أقل لإصلاح الأخطاء لاحقًا. إذا اخترت السعر فقط، فقد أقوم بالتوفير في الفاتورة الأولى وخسارة المزيد بعد الإطلاق. أفضّل أن أدفع مقابل الجودة الآن بدلاً من دفع ثمن الأخطاء مرارًا وتكرارًا.

لقد رأيت هذه المشكلة عدة مرات: يقوم الفريق بشحن المنتج بسرعة، ثم ينفق في إصلاح الأخطاء أكثر بكثير مما ينفقه في بناء الميزة. المختبر الضعيف لا يفوت الأخطاء فقط. يقوم المختبر الضعيف بإنشاء طلبات دعم إضافية، والمزيد من إعادة العمل، ومستخدمين غاضبين، وفقدان الثقة. لقد عملت ذات مرة مع فريق أطلق صفحة دفع دون تغطية اختبارية مناسبة. بدا شكل البطاقة جيدًا على سطح المكتب، إلا أنه تعطل على متصفح الهاتف المحمول الشائع. ولم تظهر المشكلة في الفحص الداخلي السريع للفريق. حاول المستخدمون الدفع، لكنهم فشلوا، وحاولوا مرة أخرى، وغادر البعض. وكان الإصلاح نفسه بسيطا. التكلفة من حوله لم تكن كذلك. كان على الفريق تصحيح الخطأ والرد على رسائل البريد الإلكتروني للعملاء ومراجعة السجلات وشرح المشكلة للمبيعات. ولهذا السبب أقول إن المختبرين الجيدين يوفرون المال، أما المختبرون السيئون فيستنزفونه بسرعة. إنني أنظر إلى المُختبر الجيد باعتباره شخصًا يفكر كمستخدم ومثل المحقق في نفس الوقت. إنهم لا ينقرون فقط على الأزرار. إنهم يسألون عن الخطأ الذي يمكن أن يحدث، وأين يمكن أن يرتبك المستخدم، وما هو المسار الذي سيتخذه العميل الحقيقي تحت الضغط. يلاحظ المختبر القوي التفاصيل التي غالبًا ما تفوتها الفرق: - نموذج الاشتراك الذي يقبل البيانات السيئة - صفحة الخروج التي تفشل في متصفح واحد - تخطيط الهاتف المحمول الذي يخفي زر المفتاح - تدفق تسجيل الدخول الذي يعمل في التدريج ولكنه ينقطع بعد تغيير بسيط في البيانات - رسالة خطأ لا تخبر المستخدم بأي شيء مفيد هذه ليست مشكلات صغيرة. وهي نقاط التكلفة. عندما أقوم بمراجعة عملية اختبار، أبدأ برحلة المستخدم. وأنا أطرح سؤالاً بسيطًا: أين يتحرك المال، وأين تتشكل الثقة، وأين يمكن أن يبدأ الإحباط؟ وهذا يعني أنني أركز على المسارات الأكثر أهمية: - الاشتراك - تسجيل الدخول - البحث - سلة التسوق - الدفع - استرداد الحساب - الاتصال بالدعم إذا انقطعت هذه التدفقات، فإن الشركة تشعر بذلك على الفور. يقوم المُختبر الجيد بحماية هذه المسارات قبل الإطلاق، ويستمر في مراقبتها بعد الإطلاق. أنا أيضًا أهتم بكيفية كتابة الاختبارات. تعتمد بعض الفرق على قائمة طويلة من الحالات التي تبدو كاملة ولكنها تفتقد المخاطر الحقيقية. وهذا هو المكان الذي ينزلق المال بعيدا. النهج الأفضل هو اختبار الإجراءات عالية المخاطر بخطوات واضحة ونتائج متوقعة واضحة. يعجبني نمط بسيط: 1. تحديد مسار المستخدم الرئيسي 2. قم بإدراج الإجراءات التي يمكن أن تفشل 3. اختبار الاستخدام العادي 4. اختبار الإدخال الغريب 5. الاختبار على الأجهزة والمتصفحات التي يستخدمها العملاء كثيرًا 6. إعادة الاختبار بعد كل إصلاح يبدو هذا أمرًا أساسيًا. إنه يعمل لأنه يبقي الفريق قريبًا من الاستخدام الحقيقي. أشاهد أيضًا كيف يقوم المختبرون بالإبلاغ عن الأخطاء. تقرير ضعيف يخلق ذهابا وإيابا. تقرير قوي يوفر ساعات. يتضمن تقرير الأخطاء المفيد ما يلي: - ما فعلته - ما توقعته - ما حدث - الجهاز أو المتصفح الذي استخدمته - أي خطوات تساعد في إعادة إظهار المشكلة - لقطة شاشة أو مقطع فيديو قصير عند الحاجة، أفضّل اللغة البسيطة. لا ينبغي للمطور أن يخمن ما أعنيه. على سبيل المثال، بدلاً من أن أقول "الصفحة معطلة"، كنت أكتب: "لقد فتحت صفحة الدفع على iPhone Safari، وأدخلت بطاقة صالحة، ثم ضغطت على "الدفع"، ولم يستجب الزر. وظلت الصفحة على نفس الشاشة. وكررت الخطوة ثلاث مرات". هذا النوع من الملاحظات يساعد الفريق على التحرك بسرعة. يعرف المختبرون الجيدون أيضًا متى لا يضيعون الجهد. لقد رأيت فرقًا تقضي ساعات في حل مشكلات صغيرة في العرض بينما تفتقد تدفق استرداد معطل. وهذا هو سوء استخدام الوقت. الاختبار الجيد لا يعني اختبار كل شيء بنفس الوزن. يتعلق الأمر باختبار الأشياء التي تحمل مخاطر. أطلب من الفرق أن تنظر إلى ثلاثة مجالات للتكلفة: - تكلفة الإصلاح - تكلفة الدعم - تكلفة السمعة. اكتشاف خطأ في وقت متأخر يتطلب المزيد من التكاليف لإصلاحه. خطأ تم العثور عليه من قبل المستخدمين يؤدي إلى إنشاء عمل دعم. يمكن أن يستمر الخطأ الذي يؤثر على الثقة في الإضرار بالعلامة التجارية بعد بدء الإصلاح. مثال صغير يجعل هذا واضحا. كان أحد تطبيقات توصيل الطعام يعاني من خلل في المؤقت. يمكن للمستخدمين تقديم طلب، لكن وقت التسليم المقدر أظهر ساعة خاطئة في إعداد منطقة واحدة. لا يزال التطبيق يعمل، لكن العملاء يعتقدون أن الخدمة كانت بطيئة. تم إلغاء بعض. كان على الدعم الإجابة على نفس السؤال مرارًا وتكرارًا. لم تكن القضية دراماتيكية. لا يزال يكلف المال. هذا هو النمط الذي أستمر في رؤيته. الفجوات الصغيرة تصبح نفقات كبيرة عندما يكون الاختبار ضعيفًا. وجهة نظري بسيطة: الاختبار الجيد عادة تجارية، وليس ترفًا. إنه يحمي الإيرادات، ويقلل الضغط داخل الفريق، ويمنح المستخدمين مسارًا أكثر سلاسة. يبدو الاختبار السيئ أرخص في البداية. وفي وقت لاحق، تصبح باهظة الثمن بطرق يصعب التنبؤ بها. إذا كنت أريد نتائج أفضل، فأنا لا أطلب المزيد من الضوضاء. أطلب تركيزًا أفضل وتقارير أكثر وضوحًا واختبارات تتوافق مع سلوك العميل الحقيقي. هذا هو الفرق بين إنفاق المال على الجودة والدفع مقابل الأخطاء بعد وقوعها. هل أنت مهتم بمعرفة المزيد عن اتجاهات الصناعة وحلولها؟ اتصل بـ Fei Zhigang: 13506728162@139.com/WhatsApp +8613506728162.

بوريس بيزر 1995 تقنيات اختبار البرمجيات جيم كانر 2002 الدروس المستفادة في اختبار البرمجيات ليزا كريسبين وجانيت غريغوري 2009 اختبار Agile مايكل بولتون 2015 اختبار البرمجيات السريع جيمس باخ 2018 تكلفة الاختبار السيئ إليزابيث هندريكسون 2020 اكتشفها تقلل المخاطر وتزيد الثقة من خلال الاختبارات الاستكشافية