إدارة الاختبار وأدواتها
إدارة الاختبار (Test Management) هي الجزء من الاختبار الذي يخطط للعمل، ويتابع تقدمه، ويوجّهه حين يبتعد الواقع عن الخطة، ثم يُغلقه بتقرير. ويصف منهج ISTQB للمستوى التأسيسي (الإصدار 4.0) دور إدارة الاختبار بأنه يركّز أساساً على ثلاثة أنشطة من عملية الاختبار: تخطيط الاختبار، ومتابعة الاختبار والتحكم فيه، وإتمام الاختبار. أما أداة إدارة الاختبار (Test Management Tool) فهي البرمجية التي تُحفظ فيها سجلات هذه الأنشطة: حالات الاختبار والخطط والتشغيلات والنتائج، مرتبطةً بالمتطلبات والعيوب.
مثال: ثلاثة مختبِرين يختبرون تطبيقاً لحجز مواعيد العيادات يصدر منه إصدار جديد كل شهر. في أداتهم لكل إصدار خطة، ولكل بناء تشغيل، وكل خطوة فاشلة تفتح عيباً مرتبطاً في نظام تتبع المهام، وفي يوم الإصدار يقرأ قائد الفريق تقريراً يعرض لكل قصة مستخدم أحدث نتائج اختباراتها وعيوبها المفتوحة. حدّد درسا التتبع ووثائق ضمان الجودة ما الذي يُسجَّل؛ وهذا الدرس يبيّن أين تُحفظ السجلات وكيف تحوّلها الأداة إلى إجابات.
لماذا يهم
من دون سجل مشترك تنهار إدارة الاختبار بمجرد أن يضم الفريق عدة مختبِرين أو يمرّ الإصدار بعدة بناءات. فتتوزع النتائج على جداول بيانات شخصية، ولا يستطيع أحد أن يقول إلى أي بناء ينتمي «النجاح»، ويستغرق تجميع تقارير الحالة ساعات ثم تصل متقادمة، ويتجادل اجتماع الإصدار حول الأرقام بدلاً من المخاطر.
الأداة لا تُصلح عملية ضعيفة، لكن الأداة المهيأة جيداً تجعل العملية مرئية: يمكن قراءة التقدم والتغطية والعوائق في أي وقت، ويبقى السجل التاريخي بعد مغادرة الأشخاص، ويستطيع المدقق أن يرى من نفّذ ماذا وعلى أي بناء. أما الأداة المهيأة بشكل سيئ فقد تكون أسوأ من جدول البيانات، لأن الحالات المتقادمة والنتائج غير المربوطة تُنتج لوحات معلومات تبدو موثوقة لكنها خاطئة. ومعرفة كيف تحسب الأداة إجاباتها جزء من عمل المختبِر.
أنشطة إدارة الاختبار وما تسجّله الأداة لكل منها
إدارة الاختبار بمصطلحات ISTQB دورٌ لا مسمى وظيفي: يتحمل المسؤولية العامة عن عملية الاختبار، ويركّز على ثلاثة أنشطة تحيط بالتحليل والتصميم والتهيئة والتنفيذ. ويجمع المعيار ISO/IEC/IEEE 29119-2 الأنشطة الثلاثة نفسها تحت عمليات إدارة الاختبار. وفي الفرق الرشيقة (Agile) يتولى الفريق نفسه بعض هذه المهام.
وتخدم الأنشطةَ الثلاثة ممارستان داعمتان. إدارة التهيئة (Configuration Management) تعرّف مواد الاختبار وعناصر الاختبار وتحفظ إصداراتها، فتذكر كل نتيجة البناء والبيئة بالضبط، ويكون لكل حالة اختبار سجل تاريخي؛ والعنصر الذي يُعتمد للاختبار يصبح خط أساس (Baseline) لا يتغير إلا عبر ضبط التغيير. وإدارة العيوب تنقل كل شذوذ مُبلَّغ عنه عبر مسار عمل متفق عليه من اكتشافه حتى إغلاقه. وفيما يلي كل نشاط وما تسجّله الأداة له:
- تخطيط الاختبار: تحديد الأهداف والنطاق والنهج ومعايير الدخول والخروج والموارد والجدول الزمني. في الأداة: خطة لكل إصدار، والحزم والمتطلبات الداخلة في النطاق، والدورات والإسنادات.
- متابعة الاختبار: جمع المعلومات باستمرار لمقارنة التقدم بالخطة والتحقق من معايير الخروج. في الأداة: أعداد حيّة للنتائج، والتغطية لكل متطلب، والعيوب المرتبطة.
- التحكم في الاختبار: التصرف بناءً على ما تُظهره المتابعة. وأمثلة المنهج: إعادة ترتيب أولويات الاختبارات حين يتحول خطر إلى مشكلة واقعة، وإعادة فحص معايير الدخول أو الخروج بعد إعادة العمل، وتعديل الجدول حين تتأخر بيئة الاختبار، وإضافة موارد متى وأينما دعت الحاجة. في الأداة: أولويات معدّلة، واختبارات أُعيد إسنادها، وتشغيل جديد لبناء جديد.
- إتمام الاختبار: عند محطة مثل الإصدار أو نهاية التكرار، توحيد النتائج، وأرشفة مواد الاختبار المفيدة أو تسليمها، وتسجيل الدروس المستفادة، وكتابة تقرير إتمام الاختبار. في الأداة: دورة مغلقة، وتصدير التقرير النهائي، وعيوب مفتوحة تُرحَّل إلى ما بعد الإصدار.
ما تفعله أداة إدارة الاختبار، أيّاً كان المنتج
يذكر المنهج أدوات الإدارة ضمن أنواع الأدوات الداعمة للاختبار: فهي ترفع كفاءة عملية الاختبار بالمساعدة في إدارة دورة حياة تطوير البرمجيات (SDLC) والمتطلبات والاختبارات والعيوب والتهيئة. ويَعُدّ جدول البيانات أيضاً أداة اختبار. وتختلف المنتجات في الأسماء والشاشات، وهذا الدرس لا يوصي بأي منها؛ فابحث عن القدرات لا عن العلامات التجارية.
اختر انطلاقاً من عمليتك لا من قائمة مزايا: اكتب كيف يخطط الفريق وينفّذ ويربط ويبلّغ، وحدّد التقارير التي يحتاجها أصحاب المصلحة فعلاً، وجرّب قائمة قصيرة من الأدوات على إصدار حقيقي واحد. والقدرات التي تبحث عنها:
- مستودع الاختبارات: حالات اختبار لها معرّفات وشروط مسبقة وخطوات ونتائج متوقعة وأولوية ومالك، مجمّعة في حزم، مع خطوات مشتركة ومعاملات وسجل للإصدارات.
- التخطيط والتنفيذ: خطط أو دورات لكل إصدار، وتشغيلات لكل بناء وبيئة، وإسناد إلى المختبِرين، ونتائج خطوة بخطوة مع أدلة مرفقة.
- التكاملات: تبقى المتطلبات والعيوب عادةً في نظام تتبع المهام لدى الفريق وتُربط ولا تُنسخ، وتصل النتائج الآلية من CI، غالباً في تقرير بصيغة JUnit XML، وتُربط بحالات الاختبار.
- التتبع والتقارير: روابط بين المتطلبات والاختبارات والنتائج والعيوب، وتقارير التقدم والتغطية والعيوب المحسوبة منها.
- الإدارة: الأدوار والصلاحيات، وسجل تدقيق يبيّن من غيّر ماذا أو نفّذه، وحقول مخصصة ومسارات مراجعة، والاستيراد والتصدير، وواجهة برمجية (API).
كل طبقة تُبنى من السجلات التي تحتها
- 1التقارير ولوحات المعلوماتالتقدم، والتغطية لكل متطلب، والعيوب حسب الحالة، وتصدير تقرير الإتمام
صدقها بقدر صدق الطبقات تحتها
- 2روابط التتبعالمتطلب وحالة الاختبار والنتيجة والعيب، مربوطة بحقول في كل سجل
تُسجَّل عند كتابة الاختبارات، لا قبيل الإصدار
- 3الخطط والدورات والتشغيلاتخطة لكل إصدار، وتشغيل لكل بناء وبيئة، ونتائج الخطوات مع الأدلة
تشغيل جديد لكل بناء
- 4مستودع الاختباراتحالات الاختبار وحزمها بمعرّفاتها وخطواتها ونتائجها المتوقعة وسجل إصداراتها
يتغير مع المنتج
- 5المصادر المتصلةنظام تتبع المهام (المتطلبات والعيوب)، وخط CI (النتائج الآلية بصيغة JUnit XML)، وإصدارات البناء
تُربط ولا تُنسخ
قدرات عامة: تختلف الأسماء والشاشات بين المنتجات، ولا يُقصد منتج بعينه. ويُتفق على اصطلاحات المعرّفات والحالات والحقول والصلاحيات قبل أول استيراد.
التتبع والتقارير داخل الأداة
في درس تتبّع المتطلبات كانت الروابط في مصفوفة. أما في الأداة فكل رابط حقل في سجل: حالة الاختبار تذكر القصة أو المتطلب الذي تغطيه، والنتيجة تنتمي إلى تشغيل يذكر بناءه وبيئته، والعيب مرتبط بالنتيجة الفاشلة. فتصبح المصفوفة تقريراً تولّده الأداة، محدّثاً لحظة تسجيل أي نتيجة.
كل تقرير استعلامٌ على هذه السجلات، فاعرف القواعد التي يطبّقها التقرير قبل أن تعرضه، واتفق عليها مع الفريق. وقواعد العدّ من درس تقارير التنفيذ ما زالت سارية:
- النطاق: أي إصدار وأي بناء وأي بيئة. فالنجاح على بناء الأسبوع الماضي لا يقول الكثير عن بناء اليوم.
- أحدث نتيجة: إذا شُغّل اختبار عدة مرات داخل النطاق تُحتسب أحدث نتيجة عادةً؛ والفشل الذي يليه نجاح على البناء نفسه سؤال يستحق التحقيق، لا نجاح.
- قاعدة حالة المتطلب: مثلاً، «ناجح» فقط حين تنجح كل الاختبارات المرتبطة داخل النطاق ولا يبقى عيب مرتبط مفتوح بخطورة رئيسي (Major) أو أعلى؛ و«غير مغطى» حين لا يرتبط به شيء.
- الربط: لا تُحتسب النتائج الآلية إلا إذا رُبطت بحالات اختبار؛ والنتائج غير المربوطة غير مرئية في التغطية.
- التصدير: احتفظ بالبيانات التي خلف لوحة المعلومات، بصيغة CSV مثلاً، لتقرير الإتمام وللتدقيق.
مثال تطبيقي: قراءة تقرير تغطية الإصدار
«عيادات سهل» (مثال خيالي) تطبيق لحجز المواعيد. للإصدار 4.2 خمس قصص مستخدم و38 حالة اختبار مرتبطة بها. يُنفَّذ معظمها يدوياً على بيئة Staging، أما اختبارات API فآلية، وتُستورد نتائجها من CI بصيغة JUnit XML وتُربط بحالات الاختبار الخاصة بها. وفي صباح اجتماع قرار الإصدار (Go/No-Go) يصدّر قائد الفريق تقرير التغطية للمرشّح للإصدار:
- نسبة النجاح الظاهرة 97% (33 ناجحاً من 34 منفَّذاً)، ومع ذلك فالقصة BK-101 وحدها جاهزة. اقرأ التقرير قصةً قصة، لا بالمجموع.
- القصة BK-104 بلا اختبارات مرتبطة. فإما أن هناك اختبارات لم تُربط قط (ابحث في المستودع وفي أي نتائج CI غير مربوطة)، وإما أن تذكير SMS لم يُختبر أصلاً. ولا يكشف هذا إلا تغطيةٌ محسوبة من الروابط.
- القصة BK-102 فاشلة والعيب D-311 مفتوح: يقرر اجتماع الفرز ومالك المنتج إما الإصلاح والتأكيد على البناء التالي، وإما الإصدار مع خطر مقبول ومسجَّل.
- القصة BK-103 محجوبة بسبب العيب D-308. والمحجوب يعني أنه لم يُختبر: خطر مجهول، وليس نجاحاً أبداً.
- للقصة BK-105 اختبار واحد لم يُنفَّذ: نفّذه اليوم أو سجّل سبب عدم تنفيذه.
- وإجراءات التحكم تُسجَّل في الأداة أيضاً: إسنادات جديدة وتشغيل للبناء rc4 من الحزمة نفسها، فتبقى نتائج rc3 سجلاً كما هي. ويصبح التصدير النهائي ملحقاً لتقرير إتمام الاختبار.
Requirements coverage: release 4.2, build 4.2.0-rc3, staging
Counting: latest result of each test in this scope
Story status: Passed = every linked test passed and no linked defect
of severity Major or higher is open
Story Summary Tests Pass Fail Blocked Not run Defects Status
BK-101 Book an appointment 12 12 0 0 0 - Passed
BK-102 Free cancellation 8 6 1 0 1 D-311 Failed
BK-103 Reschedule 6 4 0 2 0 D-308 Blocked
BK-104 SMS reminder 0 - - - - - Not covered
BK-105 Staff calendar view 12 11 0 0 1 - In progress
Total 38 33 1 2 2أخطاء شائعة
- تهيئة الأداة قبل أن يتفق الفريق على عمليته: المعرّفات والحالات والحقول والتقارير المطلوبة. فتفرض الأداة مسار عمل لا يتبعه أحد.
- استيراد كل حالات جداول البيانات القديمة دون مراجعة، فيبدأ المستودع ممتلئاً بالمكرر وباختبارات لميزات حُذفت.
- نسخ المتطلبات والعيوب إلى أداة الاختبار بدلاً من الربط بنظام التتبع، فتنشأ نسختان من الحقيقة.
- ترك الاختبارات الآلية دون ربط، فتتجاهل تقارير التغطية معظم الاختبار الذي يُنفَّذ فعلاً.
- عرض لوحة معلومات دون معرفة نطاقها وقاعدة العدّ فيها: نتائج من بناءات أقدم، واختبارات محجوبة مختفية في نسبة النجاح، وإعادة تشغيل تحوّل الفشل إلى نجاح.
- معاملة الأداة على أنها هي إدارة الاختبار. فهي تسجّل الخطط والقرارات، أما تحديد النطاق والأولويات وخطر الإصدار فما زال عمل البشر.
من منظور ضمان الجودة
في فرق كثيرة يكون المختبِر هو المستخدم اليومي للأداة، وغالباً مسؤولها غير الرسمي. اتفقوا على الاصطلاحات مبكراً واكتبوها في صفحة واحدة: أين تُحفظ المتطلبات والعيوب، وصيغة المعرّفات، وما الحالات الموجودة وما معنى كل منها، وكيف تُسمّى الاختبارات الآلية أو توسَم لتُربط بحالات الاختبار، ومن يحق له تعديل حالة معتمدة. وراجعوها في اجتماعات الاستعادة (Retrospectives).
استخدم الأداة للإجابة عن الأسئلة لا لإنتاج الأرقام. قبل اجتماع الحالة، تحقق من نطاق التقرير وقاعدته، واقرأه متطلباً متطلباً، واحمل معك القرارين أو الثلاثة التي يكشفها. وتأكد من إمكانية تصدير السجل التاريخي لما اختُبر وعلى أي بناء: فهو ملك للمنتج لا للمورّد.
تمرين عملي
احسب حالة الإصدار من سجلات الأداة الخام
تطبيق مكتبة على وشك إصدار النسخة 3.1. وتحتفظ أداة الاختبار بالسجلات أدناه للبناء المستهدف 3.1.0-rc2. استنتج حالة كل قصة كما ستحسبها الأداة وفق القاعدة المذكورة، ونسبة النجاح الظاهرة التي ستعرضها لوحة المعلومات.
ثم حدّد ما يخفيه هذا العرض المحسوب، واكتب إجراءات التحكم، وسطراً واحداً عن حالة كل قصة لاجتماع قرار الإصدار.
Library app, release 3.1. Target build: 3.1.0-rc2 on staging.
Rule: a story passes when every linked test passed on rc2 (latest result
counts) and no linked defect of severity Major or higher is open.
Stories: LIB-11 Borrow a book LIB-12 Reserve a book
LIB-13 Renew a loan LIB-14 Pay an overdue fine
Results in the order they were recorded:
# Test Story Build Result Note
1 TC-01 LIB-11 rc1 passed
2 TC-02 LIB-11 rc1 failed D-77 (Major) raised
3 TC-01 LIB-11 rc2 passed
4 TC-02 LIB-11 rc2 passed D-77 fix confirmed
5 TC-03 LIB-12 rc1 passed
6 TC-04 LIB-12 rc2 blocked D-80 (Major) open
7 TC-05 LIB-13 rc2 failed D-81 (Critical) open
8 TC-05 LIB-13 rc2 passed rerun on the same build
9 api/renew-overdue-loan - rc2 failed automated (CI), not mapped- لكل اختبار مرتبط، احتفظ بأحدث نتيجة له على rc2 فقط؛ والاختبار الذي لا نتيجة له على rc2 لم يُنفَّذ.
- طبّق القاعدة على كل قصة، بما في ذلك عيوبها المرتبطة، واحسب نسبة النجاح الظاهرة في لوحة المعلومات.
- اكتب ما يخفيه العرض المحسوب أو يخطئ فيه: النطاق، وإعادات التشغيل، والنتائج غير المربوطة، والقصص بلا اختبارات.
- اكتب إجراءات التحكم وسطراً عن حالة كل قصة لاجتماع قرار الإصدار.
إظهار الإجابة النموذجية
أحدث النتائج على rc2: TC-01 ناجح، وTC-02 ناجح، وTC-04 محجوب، وTC-05 ناجح (إعادة التشغيل)، وTC-03 لم يُنفَّذ (نجاحه كان على rc1). وتعرض لوحة المعلومات 3 ناجحة من 3 منفَّذة، أي نسبة نجاح 100%، مع اختبار محجوب وآخر لم يُنفَّذ. أما الاختبار الآلي الفاشل فغائب عنها لأنه غير مربوط.
حسب القصة: LIB-11 ناجحة، بشرط إغلاق العيب D-77 في نظام التتبع (وإلا فالقاعدة ما زالت ترى عيباً رئيسياً مفتوحاً). LIB-12 غير ناجحة: TC-03 لم يُنفَّذ على rc2، وTC-04 محجوب بسبب D-80. LIB-13 فاشلة: العيب D-81 (حرج، Critical) مفتوح أياً كانت أحدث نتيجة. LIB-14 غير مغطاة: لا اختبارات مرتبطة بها. قصة واحدة من أربع جاهزة، خلف نسبة نجاح 100%.
ما يخفيه عرض الأداة: تقرير نطاقه «كل البناءات» سيحتسب TC-03 ناجحاً؛ وقاعدة «أحدث نتيجة» تحوّل فشل TC-05 ثم نجاحه على البناء نفسه إلى نجاح، وهذا يشير إلى عيب متقطع أو اختبار متذبذب؛ وفشل CI غير مرئي حتى يُربط؛ والقصة LIB-14 لا تُظهر ما يقلق إلا إذا عرض التقرير القصص التي بلا اختبارات.
إجراءات التحكم: تأكد من إغلاق D-77 في نظام التتبع بعد تأكيد إصلاحه؛ ونفّذ TC-03 على rc2؛ واطلب من اجتماع الفرز قراراً بشأن D-80؛ وأعد إنتاج D-81 وحقّق في تقلّب TC-05 قبل الوثوق به؛ واربط api/renew-overdue-loan (اسمه يشير إلى LIB-13، فتأكد من كاتبه)؛ واكتب اختبارات للقصة LIB-14، مثلاً بأداة Requirements → Test Cases، أو سجّل سبب عدم اختبارها؛ واضبط نطاق التقرير على rc2.
الحالة للاجتماع: «LIB-11 جاهزة. LIB-12 لم تُختبر على rc2، ومحجوبة بسبب D-80. LIB-13 فاشلة، والعيب الحرج D-81 مفتوح. LIB-14 غير مختبرة. التوصية: غير جاهز للإصدار؛ ونحتاج إلى قرارات بشأن D-80 وD-81 وتغطية LIB-14».
أسئلة شائعة
هل نحتاج إلى أداة مخصصة لإدارة الاختبار، أم يكفي جدول البيانات؟
قد يكفي جدول البيانات لمختبِر واحد ومنتج صغير، ومنهج ISTQB يَعُدّه أداة اختبار. لكنه يتعثر حين ينفّذ عدة أشخاص في وقت واحد، وحين تحتاج إلى سجل النتائج لكل بناء، وإلى روابط بالمتطلبات والعيوب تبقى محدّثة، وإلى سجل تدقيق. انتقل إلى أداة حين تصبح كلفة تجميع التقارير يدوياً أو خطر ضياع السجل التاريخي أكبر من كلفة الأداة.
هل تكون إدارة الاختبار داخل نظام تتبع المهام أم في أداة منفصلة؟
كلا الإعدادين شائع. وإبقاء المتطلبات والعيوب في نظام التتبع لدى الفريق وربط الاختبارات بها يمنع النسخ، سواء حُفظت الاختبارات في إضافة (Add-on) لذلك النظام أو في أداة منفصلة. قرّر بناءً على التكاملات والتقارير التي تحتاجها، لا على مكان الشاشات.
ما أفضل أداة لإدارة الاختبار؟
لا توجد أداة هي الأفضل للجميع، وهذا الدرس لا يوصي بأي منها. قارن المنتجات بعمليتك، وبالتقارير التي يحتاجها أصحاب المصلحة، وبالتكامل مع نظام التتبع وCI، وبالصلاحيات واحتياجات التدقيق، وبالكلفة والتصدير، ثم قرّر بعد تجربة على إصدار حقيقي. ويحذّر منهج ISTQB التأسيسي، في حديثه عن أدوات أتمتة الاختبار، من مخاطر تنطبق هنا أيضاً: توقعات غير واقعية، وتقدير ناقص لجهد إدخال الأداة وصيانتها، والاعتماد على مورّد قد يوقف الأداة أو يبيعها أو يدعمها دعماً ضعيفاً.
هل إدارة الاختبار من عمل مدير الاختبار وحده؟
لا. يعامل ISTQB إدارة الاختبار على أنها دور تتوقف مهامه على السياق، وفي الفرق الرشيقة يتولى الفريق بعضها. فالمختبِر يتابع التقدم، وينبّه إلى الحاجة إلى التحكم، ويسهم في إتمام الاختبار، سواء حمل المسمى الوظيفي أم لا.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesنموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.
تنسيق XML بشكل أنيق مع مسافة بادئة قابلة للتخصيص، وإعادة تصغيره عند الحاجة.
تحويل مصفوفة من كائنات JSON إلى CSV مع تسطيح المفاتيح المتداخلة.
حوّل ملفات CSV وTSV إلى جداول PDF في متصفحك: اكتشاف الفاصل، تكرار صف الترويسة في كل صفحة، واختيار الوضع الأفقي تلقائيًا للجداول العريضة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.