ما هو الاختبار المخصص؟ أنواع مع الأمثلة

ما هو الاختبار المخصص؟

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

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

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

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

يوضح لك الفيديو التالي كيفية إجراء اختبار مخصص.

انقر اضغط هنا إذا لم يكن من الممكن الوصول إلى الفيديو

متى يتم إجراء الاختبارات المخصصة؟

معرفة الوقت الأمثل لإجراء اختبارات مخصصة (Ad Hoc Testing) تُحدث فرقًا كبيرًا في جودة برنامجك. على مر السنين، تعلمتُ أن التوقيت عاملٌ أساسي في هذا النهج المرن والعفوي للاختبار. يُعدّ الاختبار المخصص مثاليًا عندما تحتاج إلى التحقق بسرعة من المشكلات التي قد تغفلها حالات الاختبار المنظمة. دعونا نستكشف الحالات الرئيسية التي يكون فيها الاختبار المخصص ذا قيمة كبيرة:

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

أنواع الاختبارات المخصصة

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

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

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

مزايا الاختبار المخصص

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

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

عيوب الاختبارات المخصصة

يُصاحب الاختبارات المخصصة عدة قيود قد تؤثر على جودة الاختبار ونتائج المنتج. دعوني أوضح هذه القيود بوضوح من واقع خبرتي في مجال الاختبار.

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

أفضل الممارسات للاختبار المخصص الفعال

لتحقيق أقصى استفادة من اختبار Ad Hoc على الرغم من طبيعته غير الرسمية، ضع في اعتبارك هذه الممارسات التي تسد الفجوة بين الاستكشاف غير المنظم والكشف عن العيوب الموثوقة tracملِك:

1) المعرفة الجيدة بالأعمال

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

2) اختبار وحدات المفاتيح

ينبغي تحديد وحدات العمل الرئيسية واستهدافها بالاختبارات المخصصة. يجب اختبار الوحدات الحيوية للعمل أولاً للتأكد من جودة النظام.

3) تسجيل العيوب

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

تشبه خلل يجب أن تكون النتائج بمثابة درس مستفادة ويجب أن تنعكس في نظامنا التالي بينما نخطط لحالات الاختبار.

4) قم بالاقتران

كما رأينا في Buddy أو من خلال الاختبار الثنائي، يمكن للتعاون أن يؤدي إلى إيجاد وجهات نظر متنوعة وتحسين اكتشاف العيوب.

أمثلة على الاختبارات المخصصة

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

• اختبار الضغط لميزة تسجيل الدخول: يقوم أحد المختبرين بتسجيل الدخول والخروج بشكل متكرر باستخدام بيانات اعتماد مختلفة، بعضها غير صحيحة، لمعرفة ما إذا كان النظام يتعطل أو يتفاعل بشكل غريب.
• إدخال المستخدم غير المعتاد: إدخال رموز، أو سلاسل نصية طويلة جدًا، أو تنسيقات ملفات غير متوقعة للتحقق من استجابة النظام. يساعد ذلك في معرفة مدى كفاءة عملية التحقق من صحة المدخلات.
• النقرات العشوائية والتنقل: يقوم المُختبِر بالنقر على التطبيق بشكل عشوائي - القفزping بين الصفحات، تشغيل الأزرار خارج التسلسل - لاكتشاف السلوكيات غير المتوقعة.
• فوضى تحميل الملفات: تحميل أنواع الملفات غير المدعومة أو الملفات التالفة لاختبار قوة ميزة التحميل.
• اختبار المقاطعة: مقاطعة عملية ما (مثل إغلاق علامة تبويب أثناء الحفظ أو قطع اتصال الإنترنت) لمعرفة كيفية استعادة النظام.

التحليل المقارن مع الاختبار الاستكشافي

على الرغم من الخلط المتكرر بينهما، فإن الاختبارات المخصصة والاستكشافية تُظهر معايير تشغيلية متميزة:

مميز	الاختبار المخصص	اختبار استكشافي
توثيق	بعد التنفيذ فقط	تسجيل مستمر
التخطيط	بدون سلوفان	ميثاق خفيف قائم على
هيكل الجلسة	غير منظم تماما	التكرارات المحددة بالوقت
إعادة إنتاج العيوب	33% إمكانية إعادة الإنتاج	78% إمكانية إعادة الإنتاج
تكامل الأتمتة	تطبيق محدود	42% دمج الأدوات

الأسئلة الشائعة