عقلية الاختبار وسيكولوجيته
عقلية الاختبار (Testing Mindset) هي الطريقة التي ينظر بها المختبِر إلى المنتج: بفضول، وبتشاؤم مهني (Professional Pessimism) يفترض وجود عيوب لم يكتشفها أحد بعد، وبعين ناقدة تسائل كل ادعاء، بما فيه ادعاؤه هو. فمن يبني يسأل: «كيف أجعل هذا يعمل؟»، والمختبِر يسأل: «كيف يمكن أن يُخفق هذا، ومن سيتضرر؟».
أما سيكولوجية الاختبار فهي الجانب الإنساني من العمل: الانحيازات التي تجعل الجميع، والمختبِرين منهم، يرون ما يتوقعونه، وطريقة تفاعل الناس مع الأخبار السيئة عن عملهم.
لماذا يهم
يصل العيب إلى المستخدمين حين لا يبحث أحد حيث يوجد، أو حين يجده أحدهم ثم يصير ما وجده موضع جدال أو تجاهل. فالعقلية تحدد أين تبحث، وطريقة نقلك للخبر تحدد هل يتحول ما وجدته إلى إصلاح. والمختبِر الذي تكون نتائجه موضوعية ومنصفة يحظى بالثقة، ويستطيع أن يطرح مخاطرة مزعجة قبل الإصدار دون أن يثير خلافاً.
عقلية المختبِر: الفضول والتشاؤم المهني والعين الناقدة
الهدف الرئيسي للمطوّر هو بناء الحل، لذلك يكون سؤاله الطبيعي أثناء البناء: «كيف أجعل هذا يعمل؟». أما عقلية الاختبار فتسأل: «كيف يمكن أن يُخفق هذا، ولمن، وكيف سنلاحظ ذلك؟». وهما عقليتان لا مسمّيان وظيفيان: فالمطور الذي يراجع شيفرة زميله يستخدم عقلية الاختبار.
في رابط إعادة تعيين كلمة المرور، تتأكد عقلية البناء أن المستخدم يستطيع طلب الرابط وفتحه وتعيين كلمة مرور جديدة. وتفتح عقلية الاختبار الرابط مرتين، وبعد انتهاء صلاحيته، وبعد تغيّر كلمة المرور، ومن بريد مُعاد توجيهه.
- الفضول (Curiosity): أن تسأل «ماذا يحدث لو…؟» حتى لو لم تطرح السؤالَ أيُّ حالة اختبار.
- التشاؤم المهني: أن تتوقع بقاء عيوب، لأن نجاح الاختبارات لا يثبت خلوّ البرنامج منها؛ وهو موجّه إلى البرنامج، لا إلى الأشخاص أبداً.
- العين الناقدة (Critical Eye): عبارة «إنه يعمل» لا تعني إلا «لقد عمل في الحالات التي جرّبناها».
عقلية البناءالغالبة لدى المطورين
«كيف أجعل هذا يعمل؟»
- محور الاهتمام:
- تصميم الحل وبناؤه
- أول اختبارات رابط إعادة التعيين:
- طلب الرابط، وفتحه، وتعيين كلمة مرور جديدة
- الانحياز التأكيدي الذي يجب الحذر منه:
- اختبار المسار الذي بُني بالبيانات التي في الذهن، وقراءة النجاح دليلاً قاطعاً
- ما الذي يقدّمه:
- حلّ يعمل
عقلية الاختبارالغالبة لدى المختبِرين
«كيف يمكن أن يُخفق هذا، ولمن، وكيف سنلاحظ ذلك؟»
- محور الاهتمام:
- ما قد يكون خطأً في الحل، وفي المتطلب الذي يقوم عليه
- أول اختبارات رابط إعادة التعيين:
- فتحه مرتين، وبعد انتهاء صلاحيته، وبعد تغيّر كلمة المرور، ومن بريد مُعاد توجيهه
- الانحياز التأكيدي الذي يجب الحذر منه:
- إعادة اختبار الإصلاح بمدخل التذكرة وحده، أو نسبة إخفاق حدث مرة واحدة إلى «البيئة»
- ما الذي يقدّمه:
- معلومات عن مواضع إخفاقه ومقدار المخاطر المتبقية
عقليتان لا مسمّيان وظيفيان: المطور الذي يراجع شيفرة زميله يستخدم عقلية الاختبار، والمختبِر يحتاج إلى فهم طريقة بناء الشيء.
جرّبها: مولّد الاختبارات الإيجابية جرّبها: مولّد الاختبارات السلبية
الانحياز التأكيدي: نرى ما نتوقعه
الانحياز التأكيدي (Confirmation Bias) هو الميل إلى البحث عن المعلومات التي تؤكد ما نعتقده مسبقاً، وإلى تفسيرها وتذكّرها. فمؤلفو العمل يميلون إلى اختبار المسار الذي بنوه بالبيانات التي كانت في أذهانهم، وإلى قراءة النجاح دليلاً قاطعاً. وهذه طريقة عمل الانتباه، لا إهمال.
والمختبِرون ليسوا محصّنين: فإعادة اختبار إصلاح بمدخل التذكرة وحده، أو تفسير إخفاق حدث مرة واحدة بأنه «من البيئة»، تأكيدٌ لا اختبار. ومما يقاوم ذلك:
- اكتب النتيجة المتوقعة من أساس الاختبار قبل التنفيذ.
- أرفق بكل اختبار تأكيدي اختباراً يحاول إثبات العكس: مدخلاً غير صالح، أو نقرة مزدوجة.
- اسأل: «ما النتيجة التي تثبت أنني مخطئ؟»، واطلب من زميل مراجعة أفكار اختبارك.
استقلالية الاختبار: الفوائد والمآخذ
يعرّف مسرد ISTQB استقلالية الاختبار (Independence of Testing) بأنها فصلٌ للمسؤوليات يشجّع على الاختبار الموضوعي. ويصف منهج CTFL v4.0 درجاتها: أن يختبر العملَ كاتبُه (لا استقلالية)، أو زملاؤه في الفريق نفسه (بعض الاستقلالية)، أو مختبِرون من فريق آخر (عالية)، أو من خارج المؤسسة (عالية جداً). وتجمع معظم المشاريع بين عدة درجات: فمثلاً يختبر المطورون مكوّناتهم، ويختبر فريق الاختبار النظام كاملاً، ويجري ممثلو الأعمال اختبار القبول. والاستقلالية لا تحل محل الإلمام بالعمل: فالمطورون يجدون كثيراً من العيوب في شيفرتهم بكفاءة.
- فائدة: اختلاف الخلفيات والمنظورات والانحيازات يجعل المختبِرين المستقلين يتعرّفون على أنواع مختلفة من الإخفاقات، ويتحدّون الافتراضات التي وُضعت أثناء كتابة المواصفات والتنفيذ.
- مأخذ: قد تؤدي العزلة إلى ضعف التعاون أو إلى مشكلات في التواصل أو إلى علاقة عدائية، وقد يفقد المطورون إحساسهم بالمسؤولية عن الجودة، وقد يُرى المختبِرون عنق زجاجة أو يُلامون على التأخير.
كيف يستقبل الناس الأخبار السيئة، وكيف تنقلها
كثيراً ما يحمل المختبِرون الأخبار السيئة، ولوم حامل الخبر ردّ فعل شائع. فقد يُسمع تقرير العيب انتقاداً للمنتج ولمؤلفه، والانحياز التأكيدي يجعل تقبّل المعلومات غير المرغوب فيها أصعب، وبعض الناس يرون الاختبار نشاطاً هدّاماً. لذلك يطلب منهج ISTQB من المختبِرين أن ينقلوا المعلومات عن العيوب والإخفاقات بطريقة بنّاءة.
وقد تناول درس مهارات المختبِر كتابة التقرير نفسه؛ أما نقله فيتعلق بقارئه. ويختصر دليل Google لمراجعة الشيفرة القاعدة: علّق على الشيفرة، لا على المطور.
- انقل الخبر مبكراً: أبلغ عن الإخفاق الحاجب فور تأكدك منه، لا في اجتماع الإصدار.
- ابدأ من الهدف المشترك: «سيُخصم المبلغ من العملاء مرتين»، لا «شيفرتك تخصم مرتين».
- توقّع ردّ فعل دفاعياً في البداية، وأجب بالأدلة لا بالحدّة؛ وإن لم تكن متأكداً فاسأل بدلاً من إصدار الحكم.
- تحقّق من الفهم في الاتجاهين: اطلب من القارئ أن يعيد صياغة الإخفاق وأثره، وأعد أنت صياغة جوابه قبل أن تردّ.
مثال تطبيقي: إعادة اختبار إصلاح والتعامل مع الاعتراض
أبلغت لينا أن البحث في تطبيق المتجر لا يعيد شيئاً عندما ينتهي الاستعلام بمسافة. فنقل عمر التذكرة إلى حالة «تم الحل» (Resolved) مع تعليق: «تم الإصلاح والاختبار: بحثت عن coffee والنتائج سليمة». لكن هذا الاختبار ما كان ليفشل، لأن coffee دون مسافة كانت تعمل دائماً.
أما لينا فتصمّم اختبار التأكيد (Confirmation Testing) انطلاقاً من العيب والمتطلب. فتجد أن المسافة اللاحقة أُصلحت، لكن المسافة البادئة، كما في اسم منتج ملصوق من محادثة، ما زالت تُخفق. وحين يصفها عمر بأنها حالة حدّية، لا تجادل: بل توافقه على الحقيقة، وتضيف ما لاحظته، وتحيل السؤال المفتوح إلى مالك المنتج.
SEARCH-212 البحث يعيد 0 نتائج عندما ينتهي الاستعلام بمسافة
عمر: تم الإصلاح والاختبار: بحثت عن "coffee" والنتائج سليمة. تم الحل.
لينا، اختبار التأكيد على النسخة 5.2.1، بيئة Staging، الحساب test01
"coffee" 24 نتيجة فحص الانحدار
"coffee " 24 نتيجة الحالة المبلّغ عنها: أُصلحت
" coffee" 0 نتائج جديد: مسافة قبل الكلمة
"coffee beans" 6 نتائج مثل "coffee beans"
" " «أدخل كلمة للبحث»
النتيجة: الإصلاح مؤكد في SEARCH-212؛ وسُجّلت المسافة البادئة في SEARCH-219
عمر: المسافة في البداية حالة حدّية، لا أحد يكتبها.
لينا: صحيح، نادراً ما يكتبها أحد. لكنها تظهر عند لصق اسم منتج من محادثة
أو من بريد إلكتروني. هل نتجاهل المسافات البادئة كما نتجاهل اللاحقة؟
سألت مالك المنتج في SEARCH-219.أخطاء شائعة
- توجيه التشاؤم المهني إلى الأشخاص: الشك في المنتج من صميم العمل، أما الشك في زميل فليس كذلك.
- الاعتقاد بأن الانحياز التأكيدي يصيب المطورين وحدهم، ثم إعادة اختبار الإصلاح بمدخل التذكرة وحده.
- التعبير عن «لم تُكتشف عيوب» بعبارة «لا توجد عيوب».
- القتال من أجل عيب مرفوض حفظاً لماء الوجه بدلاً من إضافة أدلة أو تقبّل القرار.
- فهم الاستقلالية على أنها مسافة: الاختبار في عزلة، ورؤية المطورين خصوماً.
من منظور ضمان الجودة
تكون هذه العقلية أثمن قبل أن توجد الشيفرة: ففي جلسات تهذيب المتطلبات (Refinement)، حيث يناقش الفريق قصص المستخدم القادمة، وفي المراجعات، لا يكلّف سؤال «كيف يمكن أن يُخفق هذا؟» إلا جملة واحدة. وأثناء الاختبار راقب انحيازك أنت: خذ النتائج المتوقعة من أساس الاختبار، وصمّم اختبارات التأكيد انطلاقاً من العيب لا من تعليق الإصلاح.
اتفق مع الفريق على طريقة طرح ما تجده، وعلى درجة الاستقلالية لكل نوع من الاختبار. وحين يلقى ما وجدته مقاومة، افصل الحقيقة عن القرار: أنت توضّح الدليل والمخاطرة، والمسؤولون يقررون الإصلاح أو التأجيل أو القبول، وغالباً في جلسة فرز العيوب (Defect Triage).
تمرين عملي
اكتشف الانحياز وأجب بطريقة بنّاءة
في كل موقف أدناه انحياز أو ردّ فعل بشري من هذا الدرس. سمِّه، ثم اكتب ما ستقوله أو تفعله بدلاً منه.
1. بعد يومين من اختبار ميزة دون العثور على أي عيب، توشك أن تكتب في تقرير الحالة:
«لا عيوب، جاهزة للإصدار».
2. يعود عيب سجّلته بالحالة «مرفوض: تعذّرت إعادة الإنتاج». ومسودة ردّك الأولى:
«إنه يُخفق معي في كل مرة، تحقّق مرة أخرى».
3. لا يرى المختبِرون أي نسخة إلا في نهاية السبرنت. ويكرر المطورون أكثر فأكثر
عبارة «فريق الجودة سيكتشفه» عندما لا يكون للتغيير اختبارات وحدة.
4. في الاجتماع اليومي يقول قائد الفريق: «الاختبار يؤخّر الإصدار مرة أخرى».- حدّد لمن الانحياز أو ردّ الفعل: لك، أم للقارئ، أم للفريق.
- سمِّ الأثر بمصطلحات هذا الدرس.
- اكتب جملة أو إجراءً قابلاً للتحقق يتحدث عن المنتج أو العملية لا عن شخص.
إظهار الإجابة النموذجية
1. انحيازك التأكيدي أنت: نجاح الاختبارات لا يثبت غياب العيوب. اكتب: «لم تُكتشف عيوب في (المناطق المختبَرة). لم يُختبر: (قائمة). المخاطر المتبقية: (سطر واحد)»، بعد أن تضيف بضعة اختبارات تحاول كسر الميزة.
2. ردّ فعل القارئ وردّ فعلك: «تعذّرت إعادة الإنتاج» كثيراً ما تعني اختلافاً في النسخة أو البيانات أو البيئة، والمسودة تردّ على حقيقة بشعور. ردّ بالحقائق: «النسخة 4.1.2 في بيئة Staging، الحساب test07، بيانات الخطوة 2، والتسجيل مرفق. هل نلقي نظرة معاً؟».
3. للفريق: من مآخذ الاستقلالية. فالمختبِرون المعزولون يتحولون إلى شبكة أمان، ويقلّ إحساس المطورين بالمسؤولية عن الجودة. اقترح أن يشارك المختبِرون في جلسات تهذيب المتطلبات ويختبروا كل نسخة عند وصولها، وأن يكتب المطورون اختبارات الوحدة لتغييراتهم.
4. ردّ فعل الفريق: لوم حامل الخبر السيئ، ورؤية المختبِرين عنق زجاجة. قدّم الحقائق لا الدفاع: «اختُبر كل شيء عدا الاسترداد الذي وصل أمس. وهناك عيبان مفتوحان يمنعان الدفع بالبطاقة، وقرار الإصدار معهما يعود إلى مالك المنتج».
أسئلة شائعة
هل التشاؤم المهني يعني أن تكون سلبياً؟
لا. إنه افتراض عملي بشأن المنتج: فيه عيوب لم تجدها بعد، فتواصل البحث حتى تُعرف المخاطر المتبقية. ولا يقول شيئاً عن الأشخاص الذين بنوا المنتج، والمختبِر الجيد يبلّغ عما يعمل بالوضوح نفسه الذي يبلّغ به عما يُخفق.
هل يختبر المطورون شيفرتهم بأنفسهم؟
نعم. فالمطورون يجدون كثيراً من العيوب في شيفرتهم بكفاءة، ومنهج ISTQB ينص على أن الاستقلالية لا تحل محل الإلمام بالعمل. ويُضاف الاختبار المستقل فوق ذلك حيث تستحق العيون المختلفة والانحيازات المختلفة كلفتها، كما في مستوى النظام ومستوى القبول، أو في الميزات عالية المخاطر.
كيف ألاحظ انحيازي التأكيدي؟
ابحث عن العلامات: كتبت النتيجة المتوقعة بعد أن رأيت الشاشة، أو أعدت اختبار الإصلاح بمدخل التذكرة وحده، أو نجحت كل الاختبارات ولم يحاول أيٌّ منها مدخلاً يجب رفضه، أو فسّرت إخفاقاً دون أن تحقق فيه. وزميل يراجع أفكار اختبارك، أو الاختبار الثنائي (Pair Testing)، يكشف ما لا تستطيع رؤيته بنفسك.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- Code Review Developer Guideممارسات Google المنشورة لمراجعة الكود: ما الذي يبحث عنه المراجعون، ومعيار الموافقة على التغيير، وكيفية كتابة تعليقات المراجعة.
- Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)دروس عملية في الإبلاغ عن الأخطاء وتصميم الاختبارات والأتمتة وإدارة الاختبار — مدرسة الاختبار المدفوع بالسياق.
تدرّب بأدوات متقن
ولّد حالات اختبار سلبية لحقول النماذج وواجهات API: قيم فارغة وnull ونوع خاطئ وطول زائد وحقن وصيغة غير صالحة.
ولّد حالات اختبار إيجابية (المسار الطبيعي) تؤكد أن كل متطلب وكل تركيبة مدخلات صالحة تعمل كما ينبغي.
ولّد حالات حدّية (edge cases) للسلاسل النصية والأرقام والتواريخ والملفات والقوائم والتزامن انطلاقاً من تعريف الحقول.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.