اختبار البرمجيات (Software Testing): دليل شامل للمفهوم والأنواع…

لماذا أصبح اختبار البرمجيات ضرورة في عالم التقنية؟

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

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

لكن خلف كل تطبيق ناجح، هناك مجموعة من العمليات والأنشطة التي تهدف إلى التأكد من جودة المنتج قبل وصوله إلى المستخدم النهائي. ومن أهم هذه الأنشطة اختبار البرمجيات (Software Testing)، الذي يمثل عنصراً أساسياً في دورة حياة تطوير البرمجيات (SDLC).

لا يقتصر اختبار البرمجيات على البحث عن الأخطاء البرمجية (Bugs)، بل يشمل تقييم الوظائف، والأداء، والأمان، وسهولة الاستخدام، والتوافق مع البيئات المختلفة، بالإضافة إلى توفير معلومات تساعد فرق التطوير وأصحاب القرار على فهم مستوى جودة النظام والمخاطر المرتبطة به.

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

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

في هذا الدليل من موقع testing-arabic.com، سنستعرض مفهوم اختبار البرمجيات بشكل شامل، ونوضح أهدافه وأهميته، والفرق بين Verification وValidation، وأبرز أنواع الاختبارات ومستوياتها، مع أمثلة عملية تساعدك على فهم كيفية تطبيق هذه المفاهيم في مشاريع البرمجيات الحقيقية.

ما هو اختبار البرمجيات (Software Testing)؟

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

ويشمل الاختبار تنفيذ حالات وسيناريوهات مختلفة، ومقارنة النتائج الفعلية بالنتائج المتوقعة، بالإضافة إلى تحليل سلوك النظام في الظروف الطبيعية والاستثنائية.

بعبارة أبسط، يمكن تعريف اختبار البرمجيات بأنه:

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

هل اختبار البرمجيات يعني البحث عن الأخطاء فقط؟

رغم أن اكتشاف العيوب يُعد من أهم أهداف الاختبار، إلا أن دوره أوسع من ذلك بكثير.

فالمختبر لا يسأل فقط: «أين الخطأ؟»، بل يحاول أيضاً الإجابة عن أسئلة مهمة، مثل:

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

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

كيف يعمل اختبار البرمجيات؟ من المتطلبات إلى النتيجة

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

+--------------------------------------+
|       Software Requirements          |
|          متطلبات البرمجيات           |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|        Test Planning & Design        |
|       تخطيط وتصميم الاختبارات        |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|          Test Execution              |
|           تنفيذ الاختبارات            |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|       Compare Expected vs Actual     |
|     مقارنة النتائج المتوقعة والفعلية  |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|       Defect Reporting & Analysis    |
|        تسجيل العيوب وتحليلها          |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|       Retesting & Regression         |
|      إعادة الاختبار واختبار التراجع   |
+--------------------------------------+
                  |
                  v
+--------------------------------------+
|       Test Summary & Quality Info    |
|      ملخص الاختبار ومعلومات الجودة    |
+--------------------------------------+

شرح مراحل عملية الاختبار

1. فهم المتطلبات: يراجع المختبر ما يجب أن يفعله النظام، ويحدد القواعد والشروط والسيناريوهات المهمة.

2. تخطيط الاختبار: يتم تحديد نطاق الاختبار، والأولويات، والبيئة، والموارد، وأنواع الاختبارات المناسبة.

3. تصميم حالات الاختبار: تُكتب حالات اختبار تغطي المسارات الأساسية والبديلة والاستثنائية.

4. تنفيذ الاختبارات: يتم تشغيل الحالات يدوياً أو باستخدام أدوات الأتمتة، وتسجيل النتائج.

5. مقارنة النتائج: تُقارن النتيجة الفعلية بالنتيجة المتوقعة وفق المتطلبات.

6. تسجيل العيوب: عند وجود اختلاف جوهري، يتم توثيق العيب وإرساله للفريق المعني.

7. إعادة الاختبار واختبار التراجع: بعد الإصلاح، يتم التحقق من المشكلة الأصلية، ثم التأكد من عدم تأثر الوظائف الأخرى.

8. تلخيص النتائج: يتم تقديم صورة عن الاختبارات المنفذة، والعيوب، والمخاطر، ومستوى الجاهزية.

الأهداف الأساسية لاختبار البرمجيات (Software Testing Objectives)

يمتلك اختبار البرمجيات مجموعة من الأهداف التي تتكامل لتقديم منتج أكثر موثوقية وملاءمة للمستخدمين.

1. اكتشاف العيوب البرمجية (Defect Detection)

الهدف الأول هو الكشف عن السلوكيات غير الصحيحة أو النتائج التي لا تتوافق مع المتطلبات.

مثال: إذا كان سعر المنتج 100 دينار، ونسبة الخصم 20%، فإن السعر المتوقع بعد الخصم هو 80 ديناراً. إذا عرض النظام السعر 90 ديناراً، فهناك عيب في احتساب الخصم.

2. التحقق من توافق النظام مع المتطلبات

يجب أن ينفذ النظام الوظائف والقواعد التي تم الاتفاق عليها.

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

3. تقليل المخاطر

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

4. توفير معلومات لاتخاذ القرار

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

5. تحسين تجربة المستخدم

قد يعمل النظام تقنياً، لكنه يكون صعب الاستخدام أو مربكاً. يساعد الاختبار، خصوصاً اختبار قابلية الاستخدام، على اكتشاف هذه المشكلات.

6. دعم التحسين المستمر

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

Verification vs Validation: ما الفرق بين التحقق وإثبات الصلاحية؟

من أكثر المفاهيم أهمية في مجال اختبار البرمجيات وضمان الجودة التمييز بين Verification وValidation.

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

أولاً: Verification — التحقق

يركز Verification على السؤال:

هل نقوم ببناء المنتج بطريقة صحيحة؟

Are we building the product right?

أي أننا نتحقق من أن المنتج يتم تطويره وفق المتطلبات والتصميم والمواصفات والمعايير المحددة.

وقد تشمل أنشطة Verification:

مراجعة المتطلبات.
مراجعة التصميم.
مراجعة الكود.
مراجعة حالات الاختبار.
التحقق من تطبيق المعايير الفنية.
فحص اتساق المواصفات مع التنفيذ.

مثال عملي:

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

ثانياً: Validation — إثبات الصلاحية

يركز Validation على السؤال:

هل نقوم ببناء المنتج الصحيح؟

Are we building the right product?

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

مثال عملي:

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

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

مخطط يوضح الفرق بين Verification وValidation

                  +----------------------+
                  |   Software Quality   |
                  |       جودة المنتج    |
                  +----------------------+
                             |
             +---------------+---------------+
             |                               |
             v                               v
+--------------------------+    +--------------------------+
|       Verification       |    |        Validation        |
|          التحقق          |    |       إثبات الصلاحية     |
+--------------------------+    +--------------------------+
| هل نبني المنتج بطريقة    |    | هل نبني المنتج الصحيح    |
| صحيحة؟                   |    | الذي يحتاجه المستخدم؟   |
+--------------------------+    +--------------------------+
| مراجعة المتطلبات         |    | اختبار الاستخدام         |
| مراجعة التصميم والكود    |    | اختبار القبول            |
| فحص المواصفات            |    | تقييم ملاءمة المنتج      |
+--------------------------+    +--------------------------+

مقارنة مختصرة

العنصر	Verification	Validation
السؤال	هل نبني المنتج بطريقة صحيحة؟	هل نبني المنتج الصحيح؟
التركيز	المواصفات والتصميم والتنفيذ	احتياجات المستخدم والأعمال
أمثلة	مراجعة الكود والمتطلبات	UAT واختبار الاستخدام
الهدف	تقليل أخطاء البناء	التأكد من ملاءمة المنتج

أهمية اختبار البرمجيات للشركات والمشاريع الرقمية

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

1. تحسين رضا العملاء (Customer Satisfaction)

يتوقع المستخدم أن يعمل التطبيق بصورة مستقرة، وأن ينفذ طلباته دون أخطاء متكررة.

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

يساعد الاختبار الوظيفي والتكامل واختبار قابلية الاستخدام على اكتشاف مثل هذه المشكلات.

2. تقليل تكاليف إصلاح العيوب (Cost Optimization)

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

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

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

3. حماية سمعة العلامة التجارية

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

4. حماية البيانات وتعزيز الأمان (Security Assurance)

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

مثال: إذا استطاع مستخدم الوصول إلى تفاصيل طلب عميل آخر بمجرد تغيير معرف الطلب في الرابط، فقد يشير ذلك إلى خلل في التحكم بالوصول، ويحتاج إلى معالجة أمنية مناسبة.

5. رفع كفاءة العمليات

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

6. تحسين العائد على الاستثمار (ROI)

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

مستويات اختبار البرمجيات (Levels of Software Testing)

تُقسم مستويات الاختبار عادةً إلى أربع فئات رئيسية، تبدأ من اختبار المكونات الصغيرة، وتصل إلى تقييم النظام من منظور المستخدم والأعمال.

+------------------------------------------+
|          Levels of Software Testing      |
|            مستويات اختبار البرمجيات      |
+------------------------------------------+
                     |
                     v
+------------------+-----------------------+
|                  |                       |
v                  v                       v
+------------+ +-------------+ +----------------+
| Unit       | | Integration | | System         |
| Testing    | | Testing     | | Testing        |
| اختبار     | | اختبار      | | اختبار         |
| الوحدة     | | التكامل     | | النظام         |
+------------+ +-------------+ +----------------+
                                      |
                                      v
                              +----------------+
                              | Acceptance     |
                              | Testing        |
                              | اختبار القبول  |
                              +----------------+

1. اختبار الوحدة (Unit Testing)

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

غالباً ما ينفذه المطورون باستخدام أطر اختبار مخصصة للغة البرمجة.

مثال: دالة حساب الخصم

لنفترض أن لدينا دالة تحسب السعر النهائي بعد الخصم.

إذا كان السعر 100 دينار ونسبة الخصم 20%، فالنتيجة المتوقعة هي 80 ديناراً.

المدخلات	النتيجة المتوقعة
100، 20%	80
200، 10%	180
50، 0%	50
100، 100%	0 وفق قواعد النظام
سعر سالب	رفض القيمة أو التعامل معها وفق العقد البرمجي

مزايا Unit Testing:

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

لكن نجاح اختبار الوحدة لا يعني بالضرورة أن النظام بأكمله يعمل بصورة صحيحة، لأن المكونات قد تفشل عند دمجها معاً.

2. اختبار التكامل (Integration Testing)

يركز اختبار التكامل على التحقق من أن المكونات أو الخدمات المختلفة تعمل معاً بصورة صحيحة، وأن تبادل البيانات بينها يتم وفق الاتفاقات المحددة.

قد يشمل التكامل:

واجهة المستخدم مع API.
خدمة تسجيل الدخول مع قاعدة البيانات.
المتجر مع بوابة الدفع.
نظام الحجز مع خدمة إرسال الرسائل.

مثال: تكامل المتجر مع بوابة الدفع

عند الضغط على زر الدفع، قد تحدث الخطوات التالية:

+----------------------+
| User clicks Pay      |
| المستخدم يضغط دفع    |
+----------------------+
           |
           v
+----------------------+
| Validate Cart        |
| التحقق من السلة      |
+----------------------+
           |
           v
+----------------------+
| Create Payment       |
| إنشاء عملية الدفع    |
+----------------------+
           |
           v
+----------------------+
| Payment Gateway      |
| بوابة الدفع          |
+----------------------+
           |
           v
+----------------------+
| Update Order Status  |
| تحديث حالة الطلب     |
+----------------------+
           |
           v
+----------------------+
| Send Confirmation    |
| إرسال التأكيد        |
+----------------------+

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

هنا يساعد Integration Testing على اكتشاف خلل تبادل البيانات أو معالجة الاستجابة.

3. اختبار النظام (System Testing)

يهدف اختبار النظام إلى تقييم التطبيق كاملاً بعد دمج مكوناته، والتحقق من تحقيق المتطلبات الوظيفية وغير الوظيفية.

مثال: اختبار تطبيق حجز الرحلات

يمكن أن يتضمن سيناريو اختبار النظام:

تسجيل الدخول.
البحث عن رحلة.
اختيار الوجهة والتاريخ.
تحديد عدد المسافرين.
اختيار المقاعد.
إدخال بيانات المسافر.
إتمام الدفع.
استلام تأكيد الحجز.

هذا السيناريو يختبر تدفقاً متكاملاً عبر عدة مكونات، وليس وظيفة منفردة.

وقد يشمل اختبار النظام أيضاً الأداء، والتوافق، وسهولة الاستخدام، والتعامل مع الأخطاء، ومتطلبات الأمان ذات الصلة.

4. اختبار القبول (Acceptance Testing)

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

مثال: نظام إدارة الموظفين

قد تتضمن معايير القبول أن مدير القسم يستطيع:

إضافة موظف جديد.
تعديل بيانات الموظف.
اعتماد طلب إجازة.
استخراج تقرير شهري.

يتم التحقق من أن هذه الوظائف تعمل وفق قواعد العمل وأن النظام يحقق الهدف المطلوب قبل اعتماده أو إطلاقه.

ما هو UAT؟

يشير User Acceptance Testing (UAT) إلى اختبار قبول المستخدم، وهو نوع من اختبارات القبول يركز على التحقق من ملاءمة النظام لاحتياجات المستخدمين وسيناريوهات العمل الفعلية.

أنواع اختبار البرمجيات حسب معرفة المختبر بالكود

من التصنيفات المهمة في Software Testing تقسيم الاختبارات بناءً على مقدار المعرفة التي يمتلكها المختبر عن البنية الداخلية للنظام.

                 +---------------------------+
                 |     Software Testing     |
                 |      أنواع الاختبار       |
                 +---------------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
          v                   v                   v
+----------------+  +----------------+  +----------------+
| Black Box      |  | Gray Box       |  | White Box      |
| الصندوق الأسود |  | الصندوق الرمادي|  | الصندوق الأبيض |
+----------------+  +----------------+  +----------------+
| دون معرفة      |  | معرفة جزئية    |  | معرفة كاملة    |
| بالكود الداخلي |  | بالبنية        |  | بالكود والبنية |
+----------------+  +----------------+  +----------------+

1. اختبار الصندوق الأسود (Black Box Testing)

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

يتعامل المختبر مع التطبيق كما يتعامل معه المستخدم، ويقارن النتائج الفعلية بالنتائج المتوقعة.

مثال: اختبار تسجيل الدخول

يمكن للمختبر التحقق من:

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

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

2. اختبار الصندوق الأبيض (White Box Testing)

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

قد يشمل ذلك:

فحص شروط if/else.
اختبار الحلقات.
تقييم تغطية الكود.
التحقق من تنفيذ المسارات المختلفة.
اختبار التعامل مع الاستثناءات.

مثال: دالة تحديد أهلية الخصم

لنفترض أن النظام يمنح خصماً للعملاء وفق الشروط التالية:

IF customer is premium
    Apply premium discount
ELSE IF cart total > threshold
    Apply cart discount
ELSE
    No discount

يمكن تصميم اختبارات تغطي كل فرع من فروع القرار، والتأكد من أن الشروط لا تتعارض أو تؤدي إلى نتائج غير مقصودة.

3. اختبار الصندوق الرمادي (Gray Box Testing)

يجمع اختبار الصندوق الرمادي بين خصائص الصندوق الأسود والصندوق الأبيض.

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

مثال: اختبار صلاحيات الوصول

إذا كان المختبر يعرف أن النظام يستخدم معرف المستخدم لتحديد السجلات التي يمكن الوصول إليها، فقد يصمم اختبارات للتحقق من أن تغيير هذا المعرف لا يسمح بالوصول إلى بيانات مستخدم آخر.

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

الاختبار الوظيفي وغير الوظيفي (Functional vs Non-Functional Testing)

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

الاختبار الوظيفي (Functional Testing)

يركز على ما الذي يجب أن يفعله النظام.

أمثلة:

تسجيل الدخول.
إنشاء حساب.
إضافة منتج إلى السلة.
احتساب السعر.
إرسال نموذج.
إنشاء تقرير.
تنفيذ عملية تحويل.

الاختبار غير الوظيفي (Non-Functional Testing)

يركز على كيفية عمل النظام، وليس فقط على الوظيفة التي ينفذها.

أمثلة:

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

مثال توضيحي

قد تكون وظيفة حجز الموعد تعمل بصورة صحيحة، لكن إذا استغرق فتح صفحة الحجز 20 ثانية، فقد تكون تجربة المستخدم غير مقبولة.

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

اختبار التراجع (Regression Testing)

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

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

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

مثال: إضافة كوبون خصم إلى متجر إلكتروني

بعد إضافة ميزة الكوبون، لا يكفي اختبار أن الكوبون يعمل فقط، بل يجب التحقق أيضاً من الوظائف المرتبطة:

+--------------------------+
| New Feature: Coupon      |
| ميزة جديدة: كوبون خصم    |
+--------------------------+
             |
             v
+--------------------------+
| Test Coupon Calculation  |
| اختبار احتساب الخصم      |
+--------------------------+
             |
             v
+--------------------------+
| Regression Test          |
| اختبار الوظائف المتأثرة  |
+--------------------------+
             |
      +------+------+------+
      |      |      |      |
      v      v      v      v
   Cart   Tax    Payment  Invoice
   السلة  الضريبة الدفع   الفاتورة

قد يؤدي تعديل بسيط في منطق الحساب إلى التأثير في الضريبة أو الشحن أو الدفع أو الفاتورة.

Retesting vs Regression Testing

Retesting	Regression Testing
إعادة اختبار عيب محدد بعد إصلاحه.	التحقق من عدم تأثر الوظائف القديمة بالتغيير.
يركز على المشكلة الأصلية.	يركز على الآثار الجانبية المحتملة.
مثال: إعادة اختبار تسجيل الدخول بعد إصلاح كلمة المرور.	اختبار تسجيل الدخول والخروج واستعادة كلمة المرور بعد تعديل نظام المصادقة.

أنواع إضافية مهمة من اختبار البرمجيات

1. اختبار الدخان (Smoke Testing)

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

مثال:

بعد نشر نسخة جديدة من متجر إلكتروني على بيئة الاختبار، يمكن تنفيذ فحوصات سريعة:

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

إذا فشلت الوظائف الأساسية، فقد يكون من غير المجدي بدء مئات الاختبارات التفصيلية قبل معالجة المشكلة.

2. اختبار الصحة (Sanity Testing)

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

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

3. اختبار الأداء (Performance Testing)

يقيّم سلوك النظام من حيث السرعة والاستجابة واستهلاك الموارد تحت ظروف مختلفة.

من أنواعه:

Load Testing: اختبار النظام تحت حمل متوقع.
Stress Testing: اختبار النظام تحت حمل يتجاوز الحدود المتوقعة.
Endurance Testing: تقييم الأداء خلال فترة زمنية ممتدة.
Scalability Testing: تقييم قدرة النظام على التعامل مع زيادة الحمل والموارد.

مثال: منصة تعليم إلكتروني

إذا كانت المنصة تستقبل عادة 1,000 مستخدم متزامن، لكنها تتوقع 10,000 مستخدم أثناء إعلان النتائج، فيمكن استخدام اختبار الأداء لتقييم استجابة النظام وتحديد نقاط الاختناق قبل الحدث.

4. اختبار الأمان (Security Testing)

يهدف إلى الكشف عن نقاط الضعف المتعلقة بحماية النظام وبياناته وصلاحيات الوصول إليه.

قد يشمل:

اختبار المصادقة.
اختبار التحكم في الصلاحيات.
التحقق من حماية الجلسات.
فحص التعامل مع المدخلات.
التحقق من عدم تسريب المعلومات الحساسة.

مثال: التأكد من أن الموظف العادي لا يستطيع الوصول إلى صفحة تعديل رواتب جميع الموظفين.

5. اختبار قابلية الاستخدام (Usability Testing)

يركز على مدى سهولة استخدام النظام وفهمه من قبل المستخدمين المستهدفين.

قد ينجح التطبيق تقنياً، لكنه يكون صعباً أو مربكاً.

مثال: تطبيق حكومي يطلب من المستخدم تعبئة نموذج طويل دون توضيح الحقول المطلوبة أو الأخطاء في الإدخال، مما يزيد الوقت اللازم لإنجاز المعاملة.

6. اختبار التوافق (Compatibility Testing)

يهدف إلى التحقق من عمل التطبيق ضمن البيئات المدعومة، مثل:

أنظمة التشغيل.
المتصفحات.
أحجام الشاشات.
الأجهزة المحمولة.
إصدارات البرامج.
إعدادات اللغة والمنطقة الزمنية.

7. الاختبار الاستكشافي (Exploratory Testing)

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

لا يعني ذلك الاختبار العشوائي، بل يعتمد على هدف واضح ونطاق محدد وتوثيق مناسب للنتائج.

اختبار البرمجيات اليدوي مقابل الآلي (Manual vs Automation Testing)

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

الاختبار اليدوي (Manual Testing)

ينفذ المختبر خطوات الاختبار بنفسه، ويتفاعل مع التطبيق ويراقب النتائج.

يكون مفيداً خصوصاً في:

الاختبار الاستكشافي.
تقييم قابلية الاستخدام.
اختبار الميزات الجديدة.
السيناريوهات التي تتطلب حكماً بشرياً.
الحالات التي تتغير باستمرار.

الاختبار الآلي (Automation Testing)

يتم استخدام أدوات وبرمجيات لتنفيذ الاختبارات والتحقق من النتائج بصورة آلية.

قد يكون مناسباً لـ:

اختبارات التراجع المتكررة.
اختبارات الوحدة.
الاختبارات ذات الخطوات الثابتة.
تنفيذ عدد كبير من الحالات.
التحقق المستمر ضمن CI/CD.

مخطط مبسط

             +------------------------+
             |   Test Automation     |
             |    أتمتة الاختبار      |
             +------------------------+
                         |
             +-----------+-----------+
             |                       |
             v                       v
+---------------------+  +---------------------+
| Repetitive Tests    |  | Stable Test Cases   |
| اختبارات متكررة     |  | حالات مستقرة       |
+---------------------+  +---------------------+
             |                       |
             +-----------+-----------+
                         |
                         v
             +------------------------+
             | Faster Feedback        |
             | تغذية راجعة أسرع       |
             +------------------------+

ملاحظة مهمة: الأتمتة ليست بديلاً كاملاً عن الاختبار اليدوي. فالاختبار اليدوي مناسب لمهام تتطلب الاستكشاف والحكم البشري، بينما الأتمتة مفيدة في الحالات المتكررة والمستقرة.

كيف نخطط لاختبار البرمجيات داخل المشروع؟

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

الخطوة الأولى: تحليل المتطلبات (Requirements Analysis)

يجب أن تكون المتطلبات واضحة وقابلة للاختبار.

مثال غير واضح:

يجب أن تكون كلمة المرور قوية.

مثال أكثر قابلية للاختبار:

يجب أن تتكون كلمة المرور من 8 أحرف على الأقل، وفق قواعد الأمان المحددة للمشروع.

كلما كانت المتطلبات واضحة، أصبح تصميم حالات الاختبار أكثر دقة.

الخطوة الثانية: تحديد سيناريوهات الاختبار

يتم تحويل المتطلبات إلى سيناريوهات تغطي المسارات الأساسية والبديلة والاستثنائية.

مثال: استعادة كلمة المرور

إدخال بريد إلكتروني مسجل.
إدخال بريد إلكتروني غير مسجل.
ترك الحقل فارغاً.
إدخال بريد بصيغة غير صحيحة.
استخدام رابط منتهي الصلاحية.
إدخال كلمة مرور جديدة لا تحقق الشروط.
محاولة إعادة استخدام رابط سبق استخدامه.

الخطوة الثالثة: كتابة حالات الاختبار (Test Cases)

تتضمن حالة الاختبار عادة:

معرف الحالة.
عنوان الاختبار.
المتطلبات المسبقة.
خطوات التنفيذ.
بيانات الاختبار.
النتيجة المتوقعة.
النتيجة الفعلية.
حالة التنفيذ.

مثال على Test Case

Test Case ID: TC-LOGIN-001

العنوان: تسجيل الدخول باستخدام بيانات صحيحة.

المتطلبات المسبقة: وجود حساب فعال.

الخطوات:

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

النتيجة المتوقعة: يتم تسجيل الدخول بنجاح والانتقال إلى الصفحة الرئيسية أو الصفحة المحددة بعد الدخول.

الخطوة الرابعة: تنفيذ الاختبارات وتسجيل النتائج

بعد تجهيز الحالات، يتم تنفيذها على البيئة المناسبة وتوثيق النتائج.

الحالة	المعنى
Passed	نجحت الحالة
Failed	فشلت الحالة
Blocked	تعذر تنفيذها بسبب عائق
Not Run	لم يتم تنفيذها بعد

ما هو العيب البرمجي (Bug) وكيف نوثقه؟

العيب البرمجي هو سلوك أو نتيجة غير صحيحة أو غير متوقعة مقارنة بالمتطلبات أو السلوك المتفق عليه.

مثال: خطأ في حساب الخصم

العنوان: احتساب خصم غير صحيح عند استخدام كوبون بنسبة 20%.

الخطوات لإعادة الإنتاج:

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

النتيجة المتوقعة: يصبح السعر 80 ديناراً قبل إضافة أي رسوم أخرى، وفق قواعد النظام.

النتيجة الفعلية: يعرض النظام السعر 90 ديناراً.

الأثر: احتساب خاطئ للسعر النهائي، وقد يؤثر على ثقة المستخدم وصحة المعاملات.

Severity vs Priority

Severity (شدة العيب): مدى تأثير المشكلة على النظام أو المستخدمين.

Priority (أولوية الإصلاح): مدى استعجال معالجة المشكلة وفق احتياجات المشروع والأعمال.

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

دور اختبار البرمجيات ضمن دورة حياة التطوير (SDLC)

دورة حياة تطوير البرمجيات هي إطار ينظم مراحل بناء النظام، بدءاً من تحليل الفكرة والمتطلبات، وصولاً إلى التطوير والاختبار والإطلاق والصيانة.

يمكن أن تساهم أنشطة الاختبار في مراحل متعددة:

+-----------------------+
| Requirements          |
| تحليل المتطلبات       |
+-----------------------+
           |
           v
+-----------------------+
| Design                |
| التصميم               |
+-----------------------+
           |
           v
+-----------------------+
| Development           |
| التطوير               |
+-----------------------+
           |
           v
+-----------------------+
| Testing               |
| الاختبار              |
+-----------------------+
           |
           v
+-----------------------+
| Release               |
| الإطلاق               |
+-----------------------+
           |
           v
+-----------------------+
| Maintenance           |
| الصيانة والتحسين      |
+-----------------------+

مرحلة تحليل المتطلبات

يراجع المختبر المتطلبات للتأكد من وضوحها وقابليتها للاختبار، ويحدد الحالات الغامضة أو المتناقضة.

مرحلة التصميم والتطوير

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

مرحلة الاختبار

يتم تنفيذ الاختبارات، وتسجيل العيوب، والتحقق من الإصلاحات، وإجراء اختبارات التراجع.

مرحلة الإطلاق

تُراجع نتائج الاختبار والمخاطر المتبقية ومعايير الجاهزية، ويُتخذ قرار الإطلاق وفق سياسة المشروع.

مرحلة الصيانة

بعد الإطلاق، يتم التعامل مع العيوب الجديدة، والتحديثات، والتغييرات في المتطلبات، وإعادة اختبار الوظائف المتأثرة.

أسئلة شائعة حول اختبار البرمجيات (FAQ)

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

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

ما الفرق بين QA وSoftware Testing؟

يشير Quality Assurance (QA) إلى مجموعة أوسع من الأنشطة التي تهدف إلى تحسين وضمان جودة العمليات والمنتجات. أما Software Testing فهو مجموعة من أنشطة التقييم والفحص التي تركز على اكتشاف العيوب وتوفير معلومات عن جودة النظام.

هل يمكن إطلاق برنامج دون اختبار؟

من الناحية العملية قد يتم إطلاق بعض البرمجيات دون اختبار كافٍ، لكن ذلك يزيد المخاطر المتعلقة بالأعطال والأمان وتجربة المستخدم. يعتمد مستوى الاختبار المطلوب على طبيعة النظام وتأثير الأخطاء المحتملة.

هل الاختبار اليدوي أفضل من الأتمتة؟

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

هل اختبار البرمجيات يضمن خلو النظام من جميع الأخطاء؟

لا. الاختبار يقلل المخاطر ويوفر معلومات عن جودة النظام، لكنه لا يثبت خلو المنتج من جميع العيوب بشكل مطلق.

ما أهم أنواع اختبار البرمجيات للمبتدئين؟

من المفيد البدء بفهم اختبار الوحدة، والتكامل، والنظام، والقبول، ثم الانتقال إلى الاختبار الوظيفي وغير الوظيفي، واختبار التراجع، والاختبار اليدوي والآلي.

الخلاصة

لم يعد اختبار البرمجيات (Software Testing) خطوة ثانوية في عملية تطوير الأنظمة الرقمية، بل أصبح جزءاً أساسياً من بناء منتجات موثوقة وآمنة وقابلة للاستخدام.

ومن خلال فهم مستويات الاختبار، مثل Unit Testing وIntegration Testing وSystem Testing وAcceptance Testing، والتعرف على الاختبارات الوظيفية وغير الوظيفية، تستطيع فرق الجودة والتطوير تقييم النظام من زوايا متعددة.

كما أن التمييز بين Verification وValidation يساعد على فهم الفرق بين بناء المنتج بطريقة صحيحة، وبناء المنتج الصحيح الذي يلبي احتياجات المستخدمين.

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

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

هل تعمل في مجال اختبار البرمجيات أو تخطط لدخول عالم QA؟ شاركنا تجاربك وأسئلتك في التعليقات، وتابع موقع testing-arabic.com للمزيد من المقالات التعليمية والتقنية المتخصصة في اختبار البرمجيات وضمان الجودة.