التنفيذ اليدوي للاختبارات
التنفيذ اليدوي للاختبار (Manual Test Execution) هو أن تشغّل حالة الاختبار بنفسك: تنفّذ خطواتها بالبيانات المحددة، وتلاحظ ما يفعله النظام، وتقارن هذه النتيجة الفعلية (Actual Result) بالنتيجة المتوقعة (Expected Result) المكتوبة في الحالة، ثم تسجّل ما حدث. وفي منهج ISTQB للمستوى التأسيسي (الإصدار 4.0) يشمل تنفيذ الاختبار تشغيل الاختبارات وفق جدول التنفيذ، ومقارنة النتائج الفعلية بالمتوقعة، وتسجيل النتائج، وتحليل حالات الشذوذ (Anomalies): كل ما يخالف المتوقع.
مثال ذلك حالة اختبار تقول: طبّق رمز الخصم المنتهي OLD5، وتوقّع الرسالة «This code has expired» مع بقاء المجموع الفرعي 240.00 ريالاً. وتنفيذها يعني فحص تلك الرسالة بنصها وذلك المبلغ بعينه، وتدوين البناء (Build) الذي اختبرته، وكتابة ما رأيته فعلاً إن اختلفا.
لماذا يهم
التنفيذ هو المرحلة التي يرى فيها الفريق كيف يتصرف المنتج فعلاً، وكل ما سبقه لا يؤتي ثماره إلا إذا كانت النتائج جديرة بالثقة. فالخطوة التي تُعلَّم «ناجحة» بعد نظرة سريعة قد تُوصل مبلغاً خاطئاً أو رسالة مضللة إلى العملاء، والنتيجة «فاشلة» بلا تفاصيل قد تكلّف المطور ساعات من التخمين.
وبالنسبة إلى المختبِر، ينتج التشغيل الدقيق أدلة يبني عليها الآخرون قراراتهم: قرار الإصدار، وتقرير العيب، وإعادة الاختبار بعد الإصلاح. فالنتائج التي تذكر ما شُغّل، وعلى أي بناء، وبأي بيانات، وما الذي حدث، يمكن الوثوق بها وتكرارها؛ أما النتائج المكتوبة من الذاكرة فلا.
تنفيذ حالة اختبار واحدة خطوة بخطوة
تصلك حالة الاختبار ضمن تشغيل اختبار (Test Run)، أي تنفيذ واحد لمجموعة اختبارات على بناء محدد. اقرأ الحالة كاملة قبل أن تبدأ، واسأل عن أي غموض الآن لا في منتصف التنفيذ.
ثم اعمل عليها بإيقاع ثابت:
- افحص الشروط المسبقة ودوّن السياق: البناء، والبيئة، والمتصفح أو الجهاز، والحساب والبيانات. وإذا تعذّر تحقيق شرط مسبق فلا ترتجل؛ سجّل سبب عدم تشغيل الاختبار.
- نفّذ خطوة واحدة كما هي مكتوبة تماماً وبالبيانات المحددة. وإذا اضطررت إلى الخروج عنها، كأن يكون اسم حقل قد تغيّر، فسجّل ذلك.
- لاحظ النتيجة كاملة: الشاشة والرسائل والمبالغ والصفحة التالية، وأي بريد إلكتروني يُفترض أن تُطلقه الخطوة.
- قارن النتيجة الفعلية بالمتوقعة. فإن تطابقتا فانتقل إلى الخطوة التالية، وإن اختلفتا فالتقط ما رأيته قبل أي شيء آخر.
- بعد آخر خطوة سجّل النتيجة ونظّف البيانات التي غيّرتها الحالة، ليبدأ الاختبار التالي من حالة معروفة.
- 1اقرأ حالة الاختبار كاملةالهدف والشروط المسبقة والبيانات والنتائج المتوقعة؛ واسأل عن أي غموض
- 2افحص الشروط المسبقةدوّن البناء والبيئة والجهاز والحساب والبيانات
فرع: تعذّر تحقيق شرط مسبق: لا تشغّل الاختبار، وسجّل السببتنبيه
- 3نفّذ الخطوة التاليةكما هي مكتوبة تماماً وبالبيانات المحددة
- 4لاحظ النتيجة الفعليةالشاشة كلها: الرسائل والمبالغ والصفحة التالية ورسائل البريد
- 5قارن بالنتيجة المتوقعةالنص بالضبط والقيم والحالة الناتجة
يتكرر: تطابق: عُد إلى الخطوة 3 لتنفيذ الخطوة التالية في الحالة
فرع: اختلاف: التقط النتيجة الفعلية والدليل، ثم ابحث عن السببفشل
- 6سجّل النتيجةالنتيجة والنتائج الفعلية والبناء والبيانات والوقت والأدلة ومعرّفات العيوب
- 7اختم وتابعنظّف البيانات، وأبلغ عمّا لاحظته خارج النص المكتوب
صورة مبسطة: بعد الاختلاف تابع الخطوات اللاحقة فقط إذا بقي لها معنى دون الخطوة الفاشلة.
مقارنة النتيجة المتوقعة بالنتيجة الفعلية
النتيجة المتوقعة هي السلوك الذي يتنبأ به أساس الاختبار (Test Basis)، وتُكتب في الحالة قبل التنفيذ؛ وكل ما يخبرك بالسلوك الصحيح، كالمتطلب أو معيار القبول أو إصدار سابق، هو مرجع اختبار (Test Oracle). أما النتيجة الفعلية فهي ما يفعله النظام حقاً. ويجب أن تكون المقارنة دقيقة: «This code is not valid» ليست «This code has expired»، و216.00 ليست 240.00.
قارن كل جزء تذكره النتيجة المتوقعة: النص والقيم وحالة البيانات والشاشة التالية. والاختلاف شذوذ (Anomaly) وليس حكماً بعد. فقبل أن تسمّيه عيباً تأكّد أنك نفّذت الخطوة بشكل صحيح بالبيانات والبناء الصحيحين، وأن النتيجة المتوقعة تتفق مع أساس الاختبار. ولا تعدّل النتيجة المتوقعة أبداً لتطابق النظام؛ فإن كانت حالة الاختبار خاطئة فسجّل ذلك واطلب تصحيحها.
وفي الرسائل الطويلة أو استجابات JSON (البيانات المنظمة التي تعيدها كثير من الواجهات البرمجية) الصق النص المتوقع والنص الفعلي في أداة فروق (Diff): فهي تُبرز كل اختلاف بدقة أكبر من العين.
تسجيل ما حدث
ينتج كل تشغيل ما يسمّيه ISTQB سجل الاختبار (Test Log)، أي سجلاً زمنياً بالتفاصيل المهمة لتنفيذ الاختبارات، يُحفظ عادةً في أداة لإدارة الاختبار أو في جدول مشترك. املأه أثناء الاختبار، ليستطيع غيرك أن يفهم تشغيلك ويكرره ويعيد اختباره دون أن يسألك.
- أي اختبار: معرّف حالة الاختبار وإصدارها.
- السياق: البناء، والبيئة، والمتصفح أو الجهاز، وبيانات الاختبار أو الحسابات، والمختبِر، والتاريخ والوقت.
- النتيجة: «ناجح» (Passed) عندما تطابق كل نتيجة فعلية نتيجتها المتوقعة، و«فاشل» (Failed) عندما لا تطابقها نتيجة واحدة على الأقل. أما الحالات الأخرى مثل «محجوب» (Blocked) فيتناولها درس «حزم الاختبارات وتشغيلات الاختبار».
- النتيجة الفعلية كاملة لكل خطوة لم تطابق المتوقع، لا مجرد كلمة «فاشل».
- الأدلة والروابط: مراجع لقطات الشاشة أو السجلات، ومعرّف أي تقرير عيب رُفع.
ابقَ يقظاً خارج النص المكتوب
تخبرك حالة الاختبار بما تفحصه، لا بكل ما يمكن أن يسوء. فبينما تركّز على نتيجة متوقعة واحدة قد تظهر مشكلات أخرى على الشاشة نفسها: مجموع لا يتطابق، أو تخطيط مكسور، أو استجابة بطيئة، أو خطأ في وحدة تحكم المتصفح (Console)، أو تسمية بلغة خاطئة. اتبع النص المكتوب، لكن أبقِ عينيك مفتوحتين.
وعندما تلاحظ شيئاً خارج النتائج المتوقعة فلا تترك الحالة. دوّنه فوراً مع الوقت وما كنت تفعله، وأكمل الحالة، ثم جرّبه مجدداً وأبلغ عنه مستقلاً. وهو لا يغيّر نتيجة الحالة، لأنها تصف نتائجها المتوقعة وحدها. وإذا كشف فجوة في حالات الاختبار فاقترح حالة جديدة أو نتيجة متوقعة إضافية.
ومشكلات حالة الاختبار نفسها ملاحظات أيضاً: خطوات لم تعد تطابق الشاشات، أو بيانات قديمة، أو نتيجة متوقعة تناقض المتطلب. سجّلها لتُصحَّح الحالة قبل التشغيل التالي.
مثال تطبيقي: تشغيل TC-07 على البناء 4.2.0
تشغّل المختبِرة سارة الحالة TC-07 على بيئة Staging. تطابق الخطوات 1 و3 و4 المتوقع. وفي الخطوة 2 يُرفض الرمز، لكن الرسالة تختلف عن النص المتوقع المأخوذ من معيار القبول. فتتأكد أنها كتبت OLD5 بشكل صحيح وأن الرمز مُعدّ منتهياً، وتلتقط صورة للشاشة، وتكمل الخطوات، وتسجّل الحالة «فاشلة».
وتلاحظ أيضاً أن سطر ضريبة القيمة المضافة عرض 0.00 ريال بعد رفض الرمز حتى أعادت تحميل الصفحة. ولا توجد خطوة في TC-07 تفحص الضريبة، فتدوّن الملاحظة، وتعيد إنتاجها بعد انتهاء الحالة، وتبلّغ عنها عيباً مستقلاً مقترحةً حالة اختبار جديدة.
TC-07 رفض رمز الخصم المنتهي (version 2)
Run: build 4.2.0, staging, Chrome desktop, 2026-10-06 10:42, tester Sara
Data: account cust-basic-01, cart CART-3 (240.00 SAR), code OLD5 (expired)
Step 1 Expected: تعرض السلة 3 عناصر والمجموع الفرعي 240.00 SAR
Actual: كما هو متوقع [passed]
Step 2 Expected: الرسالة "This code has expired" ولا يظهر سطر خصم
Actual: الرسالة "This code is not valid" ولا يظهر سطر خصم
Evidence: tc07-step2.png [failed]
Step 3 Expected: يبقى المجموع الفرعي 240.00 SAR
Actual: 240.00 SAR [passed]
Step 4 Expected: بعد إعادة التحميل لا يكون أي رمز مطبَّقاً
Actual: كما هو متوقع [passed]
Status: failed (step 2), defect DEF-412 raised
Observed: بعد الخطوة 2 ظهر سطر الضريبة 0.00 SAR حتى إعادة التحميل، مرتين؛
لا تفحصه TC-07: أُبلغ عنه في DEF-413 مع اقتراح حالة اختبار جديدةأخطاء شائعة
- اعتبار الخطوة ناجحة بعد نظرة سريعة، دون فحص نص الرسالة بالضبط والمبالغ والحالة الناتجة.
- تسجيل «فاشل» بلا نتيجة فعلية ولا بناء ولا بيانات، فلا يستطيع أحد إعادة إنتاج المشكلة أو إعادة اختبار الإصلاح.
- تغيير الخطوات أو البيانات أثناء التنفيذ، أو تعديل النتيجة المتوقعة بصمت لتطابق النظام، دون تسجيل ذلك.
- ملء النتائج من الذاكرة في نهاية اليوم بدلاً من تسجيلها أثناء التنفيذ.
- الإبلاغ عن كل اختلاف على أنه عيب في المنتج قبل فحص البيانات والبناء ومطابقة حالة الاختبار لأساس الاختبار.
- تجاهل مشكلة واضحة لأنها «ليست في حالة الاختبار الخاصة بي».
من منظور ضمان الجودة
في الفريق الحقيقي تنفّذ عادةً الحالات المسندة إليك ضمن تشغيل اختبار في أداة لإدارة الاختبار، بترتيب جدول التنفيذ. وقبل البدء تأكّد من البناء ومن نجاح اختبار الدخان. وتواصل مبكراً: أخبر المطور فور رؤيتك إخفاقاً يعطّل حالات أخرى، واسأل مالك المنتج عندما تبدو نتيجة متوقعة خاطئة بدلاً من أن تقرر وحدك.
سجّل أولاً بأول، وشارك ملاحظاتك عمّا رأيته خارج النص المكتوب وعن حالات الاختبار التي تحتاج إلى تحديث في الاجتماع اليومي (Stand-up) أو مع قائد الاختبار. وتنفّذ بعض الفرق الحالات في أزواج، مختبِر مع مطور أو مع مختبِر آخر؛ ويذكر ISTQB جلسات الاختبار الثنائي (Pair Testing) شكلاً من أشكال تنفيذ الاختبار.
تمرين عملي
سجّل تنفيذ حالة اختبار للملف الشخصي
أدناه حالة الاختبار TC-21 وما رأيته عندما شغّلتها. ويقول معيار القبول: «بعد الحفظ يظهر اسم العرض الجديد في كل أنحاء التطبيق فوراً».
اكتب سجل التنفيذ: نتيجة كل خطوة، والنتيجة الإجمالية، والنتائج الفعلية، وما تفحصه قبل الإبلاغ، وما تفعله بما لاحظته خارج النص المكتوب.
TC-21 تغيير اسم العرض (version 1)
Pre: تسجيل الدخول بالحساب cust-basic-02، واسم العرض "Lina Test"
Step 1 افتح Profile.
Expected: يعرض حقل الاسم "Lina Test"
Step 2 استبدل الاسم بـ "Lina Q." ثم اختر Save.
Expected: الرسالة "Profile updated"؛ ويعرض حقل الاسم "Lina Q."
Step 3 أعد تحميل الصفحة.
Expected: ما زال حقل الاسم يعرض "Lina Q."
Step 4 افتح قائمة الترويسة.
Expected: نص التحية "Hello, Lina Q."
ما رأيته (build 3.9.1, staging, Chrome desktop):
Step 1 حقل الاسم يعرض "Lina Test"
Step 2 الرسالة "Profile updated"؛ حقل الاسم يعرض "Lina Q."؛
اختفت صورة الملف الشخصي ولم تعد إلا بعد إعادة التحميل
Step 3 حقل الاسم يعرض "Lina Q."
Step 4 نص التحية "Hello, Lina Test"- قارن كل ملاحظة بنتيجتها المتوقعة، وعلّم كل خطوة «ناجحة» أو «فاشلة».
- حدّد النتيجة الإجمالية، واكتب ما تفحصه قبل الإبلاغ عن الاختلاف.
- اكتب السجل مع سياق التشغيل، وقرّر ما تفعله بالملاحظة التي خارج النص المكتوب.
إظهار الإجابة النموذجية
الخطوات 1 و2 و3 ناجحة. والخطوة 4 فاشلة: المتوقع «Hello, Lina Q.» والفعلي «Hello, Lina Test». والنتيجة الإجمالية «فاشل».
قبل الإبلاغ كرّر الخطوة 4 مرة واحدة، وتأكّد من البناء (3.9.1) والحساب (cust-basic-02). ومعيار القبول يشترط ظهور الاسم الجديد في كل مكان فوراً، فالنتيجة المتوقعة مستندة إلى أساس الاختبار: أبلغ عن الإخفاق، بعنوان مثل «تحية الترويسة تُبقي اسم العرض القديم بعد تحديث الملف الشخصي».
سجّل: TC-21 الإصدار 1، والبناء 3.9.1، وبيئة Staging، وChrome على سطح المكتب، والحساب، واسمك والتاريخ والوقت، والنتيجة «فاشل»، ونص التحية الفعلي، ولقطة شاشة للترويسة، ومعرّف العيب.
اختفاء صورة الملف الشخصي خارج النتائج المتوقعة لـTC-21، فلا يغيّر نتيجتها. دوّنه مع الوقت، وحاول إعادة إنتاجه بعد انتهاء الحالة، وأبلغ عنه مستقلاً إن تكرر، واقترح «تبقى صورة الملف الشخصي ظاهرة» نتيجةً متوقعة إضافية للخطوة 2.
أسئلة شائعة
هل أتوقف عند أول خطوة فاشلة؟
ليس بالضرورة. فإذا كانت الخطوات الباقية لا تعتمد على الخطوة الفاشلة فتابع وسجّل نتيجة كل منها، لأنها قد تكشف المزيد. وإذا كانت تعتمد عليها فتوقف وسجّل الخطوات الباقية على أنها لم تُنفَّذ. اتبع العرف المعتمد في فريقك، واذكر في السجل ما فعلته.
هل الاختبار الفاشل اختبار سيئ؟
لا. «ناجح» و«فاشل» يصفان نتيجة المقارنة، لا جودة الاختبار أو المختبِر: يفشل الاختبار عندما لا تطابق نتيجته الفعلية نتيجته المتوقعة. والاختبار الفاشل الذي يكشف عيباً حقيقياً أدّى مهمته تماماً. أما ما يجعل الاختبار سيئاً فهو نتيجة متوقعة خاطئة أو خطوة لا يستطيع أحد اتباعها.
ماذا لو ظننت أن النتيجة المتوقعة في حالة الاختبار خاطئة؟
قارنها بأساس الاختبار، كالمتطلب أو معيار القبول، واسأل مالك المنتج أو كاتب الحالة. وسجّل ما رأيته فعلاً وأن النتيجة المتوقعة موضع سؤال. ولا تعدّل النتيجة المتوقعة بنفسك أثناء التنفيذ؛ فإن كانت خاطئة تُصحَّح حالة الاختبار وتُراجَع من جديد، ثم يُعاد تشغيل الاختبار.
ما الفرق بين هذا والاختبار الاستكشافي؟
التنفيذ اليدوي الموصوف هنا يتبع حالات اختبار صُمّمت مسبقاً وكُتبت نتائجها المتوقعة قبل التشغيل. أما في الاختبار الاستكشافي فتصمّم الاختبارات وتنفّذها وتقيّمها في الوقت نفسه بينما تتعرّف إلى المنتج، وغالباً بإرشاد ميثاق اختبار (Test Charter). والانتباه إلى المشكلات خارج النص المكتوب جرعة صغيرة من الاستكشاف داخل الاختبار المكتوب مسبقاً؛ أما الجلسة الاستكشافية الكاملة فتقنية مختلفة لها دروسها.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesنموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationنماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
تدرّب بأدوات متقن
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.
أنشئ عنوان بريد مؤقتاً واقرأ الرسائل الواردة في الصفحة نفسها. يُحرَّر العنوان تلقائياً عند التوقف عن استخدامه.
للتعمّق أكثر
- كيف تكتب حالات الاختبار (Test Cases)الحقول التي تحتاجها كل حالة اختبار
- دورة حياة اختبار البرمجيات (STLC)المرحلة 5 — تنفيذ الاختبار وإدارة العيوب
- الاختبار الاستكشافيمراجع الحكم: كيف تتعرّف على المشكلة
- كيف تكتب تقرير خطأ (Bug Report)كيف تكتب تقرير خطأ يستطيع المطورون التصرف بناءً عليه: الحقول المهمة، ونموذج جاهز للنسخ، ومثال كامل، والفرق بين الخطورة والأولوية، والأخطاء الواجب تجنبها.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.