ما اختبار البرمجيات؟
اختبار البرمجيات مجموعة من الأنشطة تكشف العيوب وتقيّم جودة البرمجيات ومخرجات العمل (Work products) المرتبطة بها، مثل المتطلبات والتصاميم والشيفرة. ويعرّف مسرد ISTQB الاختبارَ بأنه العملية التي تجري ضمن دورة حياة تطوير البرمجيات وتقيّم جودة مكوّن أو نظام ومخرجات العمل المرتبطة به. وما تختبره، سواء كان قصة مستخدم أو واجهة برمجية (API) أو تطبيقاً كاملاً، يُسمّى موضوع الاختبار (Test object).
والاختبار أكثر من تشغيل البرنامج. ففي ميزة جديدة لـ«إعادة تعيين كلمة المرور» يقرأ المختبِر قصة المستخدم أولاً ويسأل: ماذا يجب أن يحدث إذا كان رابط إعادة التعيين قد استُخدم من قبل؟ وبعد ذلك فقط تُصمَّم الاختبارات وتُنفَّذ على بناء الاختبار ويُبلَّغ عن نتائجها. تلك الخطوة الأولى لم تشغّل أي برنامج، ومع ذلك كانت اختباراً أيضاً.
لماذا يهم
تعريف الفريق للاختبار يحدد متى يبدأ وماذا يقدّم. فإذا كان الاختبار يعني تنفيذ البرنامج فقط، بدأ حين يجهز البناء وفاتته العيوب الأرخص إزالةً، وهي الموجودة في المتطلبات والتصاميم والشيفرة. وإذا اختلط الاختبار بالتنقيح (Debugging)، أُغلقت الإصلاحات دون أن يتحقق أحد من أنها تعمل.
وبالنسبة إليك بصفتك مختبِراً، يرسم التعريف حدود عملك. فأهداف الاختبار تخبرك لماذا يوجد اختبار ما وعن أي سؤال يجب أن يجيب تقريرك. والحدّ بين الاختبار والتنقيح يخبرك أين يُسلَّم العمل إلى المطور، وأي اختبارات عليك إجراؤها حين يعود الإصلاح.
أهداف الاختبار: لماذا يوجد الاختبار
هدف الاختبار (Test objective) هو سبب إجرائه. ويسرد منهج ISTQB للمستوى التأسيسي (CTFL v4.0) الأهداف المعتادة أدناه. وتتوقف أهمية كل منها على السياق: مخرَج العمل، ومستوى الاختبار (كاختبار مكوّنات منفردة أو اختبار النظام كله)، والمخاطر، ودورة حياة التطوير، وعوامل العمل مثل سرعة الوصول إلى السوق. فمثلاً في اختبار المكوّنات (Component testing)، ويُسمّى أيضاً اختبار الوحدات، وفيه يختبر المطوّرون جزءاً واحداً من الكود منفرداً، يأتي إظهار الإخفاقات وكشف العيوب مبكراً أولاً عادةً، وفي اختبار القبول بناء الثقة وتزويد قرار الإصدار بالمعلومات.
- تقييم مخرجات العمل، مثل المتطلبات وقصص المستخدمين والتصاميم والشيفرة.
- إظهار الإخفاقات (Failures) وكشف العيوب (Defects).
- ضمان التغطية المطلوبة لموضوع الاختبار، كأن يكون لكل معيار قبول اختبار واحد على الأقل.
- خفض مستوى خطر عدم كفاية جودة البرمجيات.
- التحقق (Verification) مما إذا كانت المتطلبات المحددة قد استُوفيت.
- التحقق من امتثال موضوع الاختبار للمتطلبات التعاقدية والقانونية والتنظيمية.
- تزويد أصحاب المصلحة بالمعلومات ليتخذوا قرارات مستنيرة.
- بناء الثقة بجودة موضوع الاختبار.
- التحقق من الصلاحية (Validation): هل موضوع الاختبار مكتمل ويعمل كما يتوقع أصحاب المصلحة؟
الاختبار الساكن والاختبار الديناميكي
تعرّفت على الشكلين في درس التحقق والتحقق من الصلاحية. فالاختبار الديناميكي (Dynamic testing) يشغّل البرنامج. أما الاختبار الساكن (Static testing) فيفحص مخرَج العمل دون تشغيله، إما بالمراجعة (Review) حيث يقرؤه الناس ويناقشونه، وإما بالتحليل الساكن (Static analysis) حيث تفحصه الأدوات وفق قواعد. ويعدّ ISTQB كليهما اختباراً.
والفرق فيما يكشفه كل منهما. فالاختبار الديناميكي يُظهر الإخفاقات، ثم يجب تتبّعها رجوعاً إلى العيوب التي سبّبتها. أما الاختبار الساكن فيجد العيب نفسه، وغالباً في موضعه بالضبط، ويستطيع فحص مخرجات عمل لا تُشغَّل أبداً، مثل المتطلبات وخطط الاختبار. ولا يغني أحدهما عن الآخر: فالمراجعة لا تقيس سرعة تحميل الصفحة، واكتشاف المتطلب الغامض بقراءته أسهل بكثير من اكتشافه بتشغيل الاختبارات.
- مراجعة: قراءة القصة «تظهر المصروفات المعتمدة في التقرير الشهري» والسؤال «مَن يعتمدها؟ وأي تاريخ يحدد الشهر: تاريخ التقديم أم تاريخ الاعتماد؟» قبل وجود أي شيفرة.
- تحليل ساكن: أداة تنبّه إلى عبارة SQL فيها قوس غير مغلق قبل أن يشغّلها أحد.
- اختبار ديناميكي: تشغيل التقرير الشهري ببيانات معروفة ومقارنة إجماليه بالإجمالي المتوقع.
الاختبار ليس تنقيحاً
الاختبار والتنقيح نشاطان منفصلان. فالاختبار يُظهر أن هناك مشكلة ما، والتنقيح يجد السبب ويزيله. وحين يفشل اختبار ديناميكي، يمرّ التنقيح عادةً بثلاث خطوات: إعادة إنتاج الإخفاق، وتشخيص سببه، وإصلاحه. أما حين يجد الاختبار الساكن عيباً، فلا شيء يحتاج إلى إعادة إنتاج أو تشخيص لأن العيب ظاهر أمامك، فيقتصر التنقيح على الإصلاح.
وبعد الإصلاح يعود الدور إلى الاختبار. فاختبار التأكيد (Confirmation testing)، ويُسمّى أيضاً إعادة الاختبار (Re-testing)، يتحقق من أن الإصلاح حلّ المشكلة الأصلية، وعادةً بإعادة تشغيل الاختبار الفاشل بالبيانات نفسها، ويفضّل المنهج أن يجريه الشخص الذي نفّذ الاختبار الأصلي. ثم يتحقق اختبار الانحدار (Regression testing) من أن التغيير لم يسبّب إخفاقات في مواضع أخرى.
مثال تطبيقي: إجمالي خاطئ في تقرير المصروفات
المتطلب: «يعرض التقرير الشهري إجمالي كل المصروفات المعتمدة في ذلك الشهر». تنفّذ المختبِرة هدى حالة الاختبار TC-REP-014 على البناء 2.7 بثلاثة مصروفات اعتُمدت في سبتمبر 2026. الإجمالي المتوقع 235.75 ريالاً، والتقرير يعرض 195.75. وهذا الفرق إخفاق.
تبلّغ هدى عنه مع البناء والبيانات والإجماليين، ولا تحتاج إلى معرفة أي سطر في الشيفرة خاطئ. ثم يتولى المطور عمر التنقيح: يعيد إنتاج الإخفاق، ويجد مرشّح تاريخ ينتهي عند بداية 30 سبتمبر فيُسقط آخر يوم في الشهر، ويصلحه.
الاختبار الديناميكي: تشغيل الاختبار يكشف إخفاقاً
TC-REP-014 على البناء 2.7، بثلاثة مصروفات اعتُمدت في سبتمبر 2026
- 1تشغيل الاختبارالإجمالي المتوقع: 235.75اختبار
- 2ملاحظة الإخفاقالتقرير يُسقط أحد المصروفات
total 195.75اختبارفشل - 3الإبلاغ عن العيبالبناء والبيانات والإجماليان المتوقع والفعلي، دون تخمين للسبباختبار
- 4إعادة الإنتاجالبيانات نفسها على البناء 2.7: الإجمالي الخاطئ نفسهتنقيح
- 5التشخيصمرشّح التاريخ يتوقف عند بداية 30 سبتمبر
approved_at < '2026-09-30'تنقيح - 6الإصلاحفي البناء 2.8
approved_at < '2026-10-01'تنقيح - 7اختبار التأكيدTC-REP-014 مرة أخرى على البناء 2.8 بالبيانات نفسها
total 235.75اختبارنجاح - 8اختبارات الانحدارالتقرير الربعي وتصدير CSV وشهر من 31 يوماًاختبارنجاح
الاختبار الساكن: المراجعة تجد العيب نفسه
العيب نفسه، قبل أن يُشغَّل التقرير أصلاً
- 9مراجعة الاستعلاممراجعة الشيفرة: لا يُشغَّل شيءاختبار
- 10إيجاد العيبموضعه معروف بالضبط
approved_at < '2026-09-30'اختبار - 11الإصلاحبلا إعادة إنتاج ولا تشخيص
approved_at < '2026-10-01'تنقيح
كل بطاقة موسومة باختبار أو تنقيح. وفي المسار الساكن لا شيء يحتاج إلى إعادة إنتاج أو تشخيص، فيقتصر التنقيح على الإصلاح.
- اختبار التأكيد: تشغيل TC-REP-014 على البناء 2.8 بالبيانات نفسها يعطي 235.75، فيمكن إغلاق العيب.
- اختبارات الانحدار: التقرير الربعي وتصدير CSV، وهما يستخدمان المرشّح نفسه، وشهر من 31 يوماً، كلها تعطي إجماليات صحيحة.
- المسار الساكن: لو قرأ مراجعٌ الاستعلام قبل تشغيله أصلاً لرأى تاريخ النهاية مباشرةً، دون إعادة إنتاج ولا تشخيص.
النسخة النصية
TC-REP-014: إجمالي التقرير الشهري يساوي مجموع المصروفات المعتمدة
البناء 2.7، مصروفات اعتُمدت في سبتمبر 2026:
12 سبتمبر: 120.50
21 سبتمبر: 75.25
30 سبتمبر الساعة 16:40: 40.00
المتوقع: الإجمالي 235.75
الفعلي: الإجمالي 195.75 (فشل)
التنقيح (عمر، المطوّر)
إعادة الإنتاج: البيانات نفسها على البناء 2.7، والإجمالي 195.75
التشخيص: approved_at < '2026-09-30' يُسقط يوم 30 سبتمبر
الإصلاح: approved_at < '2026-10-01' في البناء 2.8
اختبار التأكيد: TC-REP-014 على البناء 2.8 بالبيانات نفسها، الإجمالي 235.75 (ناجح)
اختبار الانحدار: التقرير الربعي، وتصدير CSV، وشهر من 31 يوماً (ناجح)أخطاء شائعة
- الظن بأن الاختبار لا يبدأ إلا حين يتوفر بناء للتشغيل، وإهمال مراجعة المتطلبات والتصاميم والشيفرة.
- الاختبار دون هدف متفق عليه، فلا يعرف أحد هل «الانتهاء» يعني التحقق من المتطلبات، أم تغطية المخاطر، أم ثقة كافية للإصدار.
- تخمين السبب في تقرير العيب («استعلام SQL خاطئ») بدلاً من وصف الإخفاق: الخطوات والبيانات والنتيجتين المتوقعة والفعلية.
- إغلاق العيب لأن المطور وسمه بأنه أُصلح، دون تنفيذ اختبار التأكيد بالبيانات الأصلية.
- الاكتفاء باختبار التأكيد بعد الإصلاح، وإهمال اختبارات الانحدار للمناطق التي قد يمسّها التغيير.
من منظور ضمان الجودة
في الفريق الفعلي تختبر منذ لحظة وجود مخرَج العمل: تراجع القصص قبل دخولها السبرنت، ثم تصمّم الاختبارات وتنفّذها حين تصل البناءات. وقبل دورة الاختبار اسأل مالك المنتج أو قائد الاختبار عن الأهداف الأهم في هذا الإصدار؛ فهي تحدد ما تختبره أولاً وعن أي سؤال يجب أن يجيب تقريرك.
وحين يفشل اختبار، اجعل التنقيح سريعاً بدلاً من أن تتولاه بنفسك: سجّل البناء والبيئة والبيانات والخطوات والنتيجتين المتوقعة والفعلية، وأرفق لقطة شاشة أو سجلاً. وحين يصل الإصلاح، نفّذ اختبار التأكيد بالبيانات نفسها، واسأل المطور عمّا يمسّه التغيير أيضاً لتختار اختبارات الانحدار، وسجّل النتيجتين في العيب.
تمرين عملي
افصل الاختبار عن التنقيح في سجل عيب
المادة سجل نقاش حول عيب في تطبيق لتوصيل الطعام، من البلاغ الأول حتى الإصلاح. افصل الاختبار عن التنقيح، ثم خطّط للاختبار الذي يجب أن يلي الإصلاح.
BUG-311: رسالة تأكيد الطلب تعرض تاريخ توصيل خاطئاً
القاعدة: تاريخ التوصيل = تاريخ الطلب + يومان. المتجر: الرياض (UTC+3).
الاثنين 09:10 سارة (مختبِرة): نفّذتُ TC-ORD-21 على البناء 5.3. طلب في 6 أكتوبر
الساعة 01:30 بتوقيت الرياض. المتوقع «التوصيل: 8 أكتوبر»، والرسالة
تقول «التوصيل: 7 أكتوبر». الطلبات في الساعة 10:00 تعرض التاريخ الصحيح.
أرفقتُ لقطة الشاشة ورقم الطلب.
الاثنين 11:30 عمر (مطوّر): أعدتُ إنتاج المشكلة على جهازي بطلب في الساعة 01:30.
الاثنين 13:05 عمر: وجدتُ السبب. خدمة البريد تأخذ تاريخ الطلب بتوقيت UTC، وفيه
تكون الساعة 01:30 من 6 أكتوبر في الرياض ما زالت في 5 أكتوبر.
الاثنين 13:20 عمر: أُصلح في البناء 5.4؛ صار التاريخ يستخدم المنطقة الزمنية للمتجر.
الحالة: جاهز للاختبار.- صنّف كل مدخلة على أنها اختبار أو تنقيح، واذكر لكل مدخلة تنقيح خطوتها: إعادة الإنتاج أو التشخيص أو الإصلاح.
- اكتب اختبار التأكيد على البناء 5.4: من ينفّذه، وبأي بيانات، وما النتيجة المتوقعة.
- اذكر اختبارَي انحدار على الأقل لتغيير طريقة حساب التاريخ.
- اذكر اختباراً ساكناً واحداً كان يمكن أن يكشف هذا العيب قبل تشغيل أي شيفرة.
- اذكر أهداف الاختبار التي خدمها تنفيذ حالة الاختبار TC-ORD-21.
إظهار الإجابة النموذجية
الاختبار: مدخلة 09:10، حيث نفّذت سارة TC-ORD-21 ولاحظت الإخفاق وأبلغت عنه مع البناء والبيانات والنتيجتين المتوقعة والفعلية. التنقيح: 11:30 إعادة إنتاج، و13:05 تشخيص، و13:20 إصلاح. والحالة «جاهز للاختبار» تعيد العمل إلى الاختبار.
اختبار التأكيد: يُفضَّل أن تنفّذه سارة لأنها نفّذت الاختبار الأصلي، فتشغّل TC-ORD-21 على البناء 5.4 بالطلب نفسه، المقدَّم في 6 أكتوبر الساعة 01:30 بتوقيت الرياض، وتتوقع «التوصيل: 8 أكتوبر». وإذا نجح أمكن إغلاق العيب.
اختبارات الانحدار: طلب في الساعة 10:00؛ وطلبات قبل الساعة 03:00 بتوقيت الرياض وبعدها مباشرةً، وهي منتصف الليل بتوقيت UTC؛ وطلبات قبل منتصف الليل بتوقيت الرياض وبعده مباشرةً، حيث صار يوم المتجر يتغيّر؛ وطلب في الساعة 01:30 في آخر يوم من الشهر؛ وأي موضع آخر يعرض تاريخ التوصيل، مثل صفحة سجل الطلبات.
الاختبار الساكن: مراجعة المتطلب بسؤال «بأي منطقة زمنية يُحسب تاريخ التوصيل؟»، أو مراجعة شيفرة حساب التاريخ، وكانت ستُظهر أنها تستخدم UTC.
الأهداف: إظهار الإخفاقات وكشف العيوب؛ والتحقق من متطلب محدد هو تاريخ التوصيل المعروض للعميل؛ وخفض خطر وصول تواريخ خاطئة إلى العملاء؛ وتزويد أصحاب المصلحة بالمعلومات. ثم يبني اختبار التأكيد واختبارات الانحدار الثقة بالإصلاح.
أسئلة شائعة
هل التنقيح جزء من عمل المختبِر؟
ليس قاعدةً. فالاختبار والتنقيح نشاطان منفصلان، والمطورون يتولون التنقيح في معظم الفرق. ويساعد المختبِر بتضييق ظروف الإخفاق (أي بيانات، وأي متصفح، وأي بناء) والإبلاغ عنها بدقة. وبعض المختبِرين الذين يقرؤون الشيفرة يساعدون في التشخيص أيضاً، لكن هذا العمل يبقى تنقيحاً لا اختباراً.
هل مراجعة الشيفرة اختبار حقاً؟
نعم، بمصطلحات ISTQB. فالمراجعات والتحليل الساكن اختبار ساكن: تقيّم مخرَج العمل دون تشغيله. وهي تجد العيوب مباشرةً، وغالباً أبكر وبإعادة عمل أقل من الاختبار الديناميكي، وهي الطريقة الوحيدة لاختبار مخرجات عمل لا تُشغَّل أبداً مثل المتطلبات.
ما الفرق بين اختبار التأكيد واختبار الانحدار؟
اختبار التأكيد يتحقق من أن الإصلاح حلّ المشكلة الأصلية، عادةً بإعادة تشغيل الاختبارات الفاشلة، وأحياناً باختبارات جديدة للتغيير. واختبار الانحدار يتحقق من أن التغيير لم يُفسد شيئاً كان يعمل من قبل. وبعد الإصلاح تحتاج عادةً إلى الاثنين.
هل لكل المشاريع أهداف الاختبار نفسها؟
لا. يسرد المنهج أهدافاً معتادة، وتتوقف أهميتها على السياق: مخرَج العمل، ومستوى الاختبار، والمخاطر، ودورة الحياة، وعوامل العمل مثل سرعة الوصول إلى السوق. فميزة دفع في سوق خاضع للتنظيم تضع الامتثال والمخاطر أولاً، أما نموذج أولي مبكر فقد يحتاج أساساً إلى معلومات سريعة لأصحاب المصلحة.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsالمعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
فحص جمل SQL بحثاً عن مشكلات الصياغة والأقواس غير المتوازنة والسلاسل النصية غير المغلقة والأنماط الخطرة.
التحقق من صحة صياغة JSON مع تحديد مواقع الأخطاء بدقة واقتراحات مفيدة للإصلاح.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
حوّل التاريخ والوقت بين المناطق الزمنية (الرياض، عمّان، دلهي، UTC، نيويورك، لندن…).
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.