الوحدة 4 · عملية الاختبار (STLC)

تحليل الاختبار

بقلم فريق ضمان الجودة في متقن سوفت · · 17 دقيقة · مبتدئ

تحليل الاختبار (Test Analysis) هو نشاط الاختبار الذي يجيب عن سؤال «ماذا نختبر؟». يدرس المختبِر أساس الاختبار (Test basis) — قصص المستخدم ومعايير القبول وقواعد العمل والتصاميم وعقود الواجهات البرمجية — ويحوّله إلى شروط اختبار (Test conditions). ويعرّف ISTQB شرط الاختبار بأنه جانب قابل للاختبار من مكوّن أو نظام يُحدَّد أساساً للاختبار. ويُربط كل شرط بمصدره ويُعطى أولوية.

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

لماذا يهم

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

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

ماذا نختبر، لا كيف نختبر

في عملية الاختبار وفق ISTQB يأتي تحليل الاختبار بعد تخطيط الاختبار وقبل تصميم الاختبار. فخطة الاختبار التي تناولها الدرس السابق تحدد النطاق والنهج ومستويات المخاطر، والتحليل يقرر بالضبط ما يجب اختباره داخل هذا النطاق. ثم يجيب تصميم الاختبار، موضوع الدرس التالي، عن سؤال «كيف نختبر؟» بتحويل كل شرط إلى حالات اختبار.

هذه أنشطة منطقية لا مراحل صارمة. ويسمي نموذج STLC هذا العمل «تحليل المتطلبات»، وكثير من الفرق تبدؤه حالما تصبح القصة جاهزة للتنقيح (Refinement).

  • المدخلات: أساس الاختبار للميزات داخل النطاق، مع المخاطر والنهج من خطة الاختبار.
  • المخرجات: شروط اختبار مرتّبة حسب الأولوية ومربوطة بمصادرها. ومعايير القبول الجيدة يمكن أن تكون شروط اختبار مباشرةً.
  • المخرجات أيضاً: تقارير عيوب عن أساس الاختبار نفسه، حين لا يُصلَح العيب في الحال.
  • ليس بعد: الخطوات والبيانات المحددة والشاشات المتوقعة؛ فهذه من عمل تصميم الاختبار.
يحوّل تحليل الاختبار أساسَ الاختبار إلى شروط اختبار مرتّبة حسب الأولوية تجيب عن «ماذا نختبر؟»، ويعيد العيوب المكتشفة في الأساس إلى مالك المنتج. نموذج مفاهيمي
  1. 1أساس الاختبارالنطاق ومستويات المخاطر من خطة الاختبارقصص المستخدم ومعايير القبول وقواعد العمل والتصاميم وعقود الواجهات البرمجية
  2. 2تقييم الأساسالغموض والإغفال والتناقض والصياغة غير القابلة للاختبار

    فرع: عيب في الأساس ← سؤال أو تقرير عيب إلى مالك المنتج

  3. 3تحديد شروط الاختبارجانب واحد قابل للاختبار في كل شرط، مع معرّف ومصدر
  4. 4الترتيب حسب المخاطرالاحتمالية × التأثير ← عالية أو متوسطة أو منخفضة، مع السبب
  5. 5شروط اختبار مرتّبة حسب الأولويةالإجابة عن «ماذا نختبر؟»المُخرَج

عودة إلى الخطوة 1 كل إجابة تحدّث الأساس، فأعد تحليل ما تغيّر

بعد ذلك:إلى تصميم الاختبار: كيف نختبر كل شرط

صورة مبسطة: تتداخل الخطوات عملياً، ويتكرر التحليل مع كل قصة ومع كل تغيير في الأساس.

قيّم أساس الاختبار وأبلغ عن عيوبه

اقرأ أساس الاختبار بعين ناقدة قبل أن تشتق منه شيئاً، فمنهج ISTQB يطلب من المختبِرين تقييمه بحثاً عن العيوب وعن قابلية الاختبار. فالمتطلب مُخرَج عمل مثل الكود: أخطاء كاتبه (Errors) تصبح عيوباً في المتطلب، وإن لم يكتشفها أحد فقد تنتهي إخفاقاتٍ في المنتج.

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

  • الغموض: «خصم ⁦10%⁩ على طلبك»، على المنتجات فقط أم على رسوم التوصيل أيضاً؟
  • الإغفال: تغطي القصة الرمز المنتهي، ولا تذكر الرمز غير الموجود أو المكتوب خطأً.
  • التناقض: معيار يسمح برمز واحد لكل طلب، وقاعدة تسعير تسمح لعضو برنامج الولاء بإضافة رمز ثانٍ.
  • الصياغة غير القابلة للاختبار: «يظهر بوضوح» و«سريع» و«سهل الاستخدام» و«حسب الاقتضاء»، فلا شيء تقارن النتيجة به.

جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي

حدّد شروط الاختبار

شرط الاختبار يسمّي جانباً واحداً قابلاً للاختبار: قاعدة، أو سلوكاً، أو حالة، أو مسار خطأ، أو خاصية جودة. اكتب ما يجب أن يكون صحيحاً لا الخطوات: «يُحسب الخصم قبل ضريبة القيمة المضافة» شرط اختبار، أما «اكتب SAVE10 واضغط تطبيق» فخطوة اختبار مكانها التصميم. وبعض الفرق تكتب الشروط على هيئة أفكار اختبار أو سيناريوهات اختبار من سطر واحد، مع أن السيناريو كثيراً ما يجمع عدة شروط. وتتبّع الأساس بنداً بنداً بطريقة منهجية كي لا تتوقف عند المسار السعيد (Happy path):

  • كل معيار قبول وقاعدة عمل: شرط واحد على الأقل، وغالباً شرط إيجابي وآخر سلبي.
  • كل مدخل وحالة ودور: القيم الصالحة وغير الصالحة، ونجاح العملية وفشلها، ومن يحق له التنفيذ ومن لا يحق له.
  • الاحتياجات الضمنية: رسائل الخطأ، والواجهات العربية من اليمين إلى اليسار، وإمكانية الوصول، والأداء.
  • معرّف ومصدر لكل شرط (AC2 أو BR-9 أو «ضمني»)، كي يمكن تتبّع التغطية لاحقاً.

جرّبها: قصة المستخدم ← سيناريوهات اختبار جرّبها: المتطلبات ← سيناريوهات اختبار

رتّب الشروط حسب المخاطر

لا يستحق كل شرط الجهد نفسه، ويضع ISTQB ترتيب شروط الاختبار حسب الأولوية، مع مستويات مخاطرها، داخل تحليل الاختبار. والبداية البسيطة هي الاحتمالية × التأثير: ما احتمال وجود عيب هنا بالنظر إلى التعقيد والتغييرات الأخيرة، وما مدى ضرر الإخفاق على المستخدمين أو العمل؟ أعطِ كل شرط أولوية عالية أو متوسطة أو منخفضة مع سطر يشرح السبب.

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

جرّبها: مولّد الاختبار المبني على المخاطر

مثال تطبيقي: قصة رمز الخصم

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

الشروط من C1 إلى C5 أولويتها عالية لأنها تحدد المبلغ الذي يدفعه العميل، وهو ما تصنّفه خطة الاختبار مخاطرةً عالية: فالعيب فيها يحمّل العملاء مبلغاً خاطئاً. ولا يمكن تصميم الشروط C4 وC5 وC7 حتى يجيب مالك المنتج، وهذا بالضبط سبب طرح الأسئلة الآن.

US-214  تطبيق رمز خصم عند الدفع
AC1   الرمز الصالح يخفض المجموع الفرعي للطلب بنسبته المئوية.
AC2   الرمز المنتهي يُظهر رسالة خطأ ولا يتغير الإجمالي.
AC3   يمكن استخدام رمز واحد فقط لكل طلب.
AC4   يظهر الخصم بوضوح في ملخص الطلب.
BR-9  يُطبَّق الخصم على المجموع الفرعي قبل ضريبة القيمة المضافة.
      المنتجات المخفّضة أصلاً لا تحصل على خصم إضافي.
      يحق لعضو برنامج الولاء إضافة رمز العضوية إلى رمز الخصم.

أسئلة لمالك المنتج (تعليقات على US-214)
Q1  تناقض · AC3، BR-9
    المعيار الثالث يسمح برمز واحد لكل طلب، وقاعدة التسعير تسمح لعضو الولاء برمز ثانٍ.
Q2  صياغة غير قابلة للاختبار · AC4
    كلمة «بوضوح»: ما الذي يجب أن يظهر في الملخص بالضبط؟
Q3  غموض · AC2
    هل الرمز صالح في يوم انتهائه، وبحسب أي منطقة زمنية؟
Q4  إغفال · BR-9
    ماذا يحدث لسلة تجمع منتجات مخفّضة وأخرى بسعرها العادي؟

شروط الاختبار
C1  AC1  عالية
    الرمز الصالح يخفض المجموع الفرعي بنسبته المئوية.
C2  BR-9  عالية
    يُحسب الخصم قبل ضريبة القيمة المضافة.
C3  AC2  عالية
    يُرفض الرمز المنتهي ولا يتغير الإجمالي.
C4  AC3، BR-9  عالية
    رمز ثانٍ على الطلب نفسه (متوقف حتى تأتي إجابة السؤال الأول).
C5  BR-9  عالية
    المنتجات المخفّضة لا تحصل على خصم، حتى في سلة مختلطة (بانتظار إجابة السؤال الرابع).
C6  ضمني  متوسطة
    الرمز غير الموجود أو المكتوب خطأً يُظهر رسالة خطأ.
C7  AC4  متوسطة
    يعرض الملخص الرمز ومبلغ الخصم (بعد إجابة السؤال الثاني).
C8  ضمني  متوسطة
    حقل الرمز والملخص يعملان في الواجهة العربية.

أخطاء شائعة

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

من منظور ضمان الجودة

في الفريق الحقيقي يبدأ تحليل الاختبار حين تصبح القصة جاهزة للتنقيح، لا حين يصل البناء. وكثير من الفرق تنجز جزءاً منه في حوار قصير بين مالك المنتج ومطوّر ومختبِر يُسمى أحياناً «الأصدقاء الثلاثة» (Three amigos). أحضر مسودة الشروط والأسئلة: «ماذا يحدث عندما…؟»، و«أي القاعدتين تُطبَّق إذا تعارضتا؟»، و«كيف سنعرف أن العمل انتهى؟».

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

تمرين عملي

حلّل قصة حجز موعد في عيادة

المطلوب

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

المادة
US-57  حجز موعد في العيادة عبر الإنترنت
بصفتي مريضاً، أريد حجز موعد مع طبيب عبر الإنترنت
كي لا أضطر إلى الاتصال بالعيادة.

AC1  يختار المريض طبيباً وتاريخاً وفترة شاغرة مدتها 20 دقيقة.
AC2  يمكن حجز المواعيد قبل 30 يوماً كحد أقصى.
AC3  لا يمكن أن يكون للمريض موعدان في الوقت نفسه.
AC4  يتلقى المريض تأكيداً بسرعة.
AC5  يمكن إلغاء الموعد حتى 24 ساعة قبل بدايته.
الخطوات
  1. حدّد ما هو غامض أو ناقص أو متناقض أو غير قابل للاختبار، وحوّل كل ملاحظة إلى سؤال لمالك المنتج.
  2. اكتب الشروط مع مصادرها: واحداً على الأقل لكل معيار، إضافةً إلى الشروط الضمنية.
  3. أعطِ كل شرط أولوية عالية أو متوسطة أو منخفضة مع سطر يشرح السبب.
إظهار الإجابة النموذجية
الإجابة النموذجية

الأسئلة: كلمة «بسرعة» في AC4 غير قابلة للاختبار: خلال كم دقيقة، وعبر أي قناة، وبأي لغة؟ وفي AC2: هل تُحسب الثلاثون يوماً من اليوم أم من هذه اللحظة، وهل اليوم الثلاثون مشمول؟ وفي AC5: ماذا يحدث خلال آخر 24 ساعة؟ وماذا لو اختار مريضان الفترة نفسها في اللحظة نفسها؟

الشروط: C1 (AC1) يمكن حجز فترة شاغرة؛ C2 (AC1) لا يمكن حجز فترة محجوزة، حتى لو اختارها مريضان معاً؛ C3 (AC2) حد الثلاثين يوماً مُطبَّق؛ C4 (AC3) يُرفض موعد ثانٍ في الوقت نفسه، حتى مع طبيب آخر؛ C5 (AC4) يُرسل تأكيد؛ C6 (AC5) الإلغاء المبكر يحرّر الفترة؛ C7 (AC5) الإلغاء المتأخر يتبع الإجابة التي تتلقاها؛ C8 (ضمني) لا يرى المريض مواعيد غيره ولا يلغيها؛ C9 (ضمني) الصفحات تعمل بالعربية.

الأولويات: عالية للشروط C1 وC2 وC4 وC8، لأن الإخفاق فيها يمنع الحجز أو يحجز الطبيب أو المريض مرتين في الوقت نفسه أو يكشف بيانات المرضى؛ ومتوسطة للباقي، لأن الإخفاق فيها مزعج لكنه لا يسبب شيئاً من ذلك، والشرطان C5 وC7 ينتظران الإجابات أيضاً. راجع نفسك: لكل شرط مصدر، وكل عبارة غامضة أصبحت سؤالاً، ولا تحتوي القائمة بعدُ على خطوات أو تواريخ محددة.

أسئلة شائعة

ما الفرق بين شرط الاختبار وحالة الاختبار؟

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

هل تحليل الاختبار هو نفسه تحليل المتطلبات في STLC؟

إلى حد كبير نعم، لكن الترتيب يختلف. يسمي نموذج STLC مرحلته الأولى «تحليل المتطلبات» ويضعها قبل تخطيط الاختبار، أما عملية الاختبار في ISTQB فتسمي العمل نفسه «تحليل الاختبار» وتضعه بعد التخطيط، وتنبّه إلى أن أنشطتها تُنفَّذ غالباً بشكل تكراري أو متوازٍ. ويغطيه المعيار ⁦ISO/IEC/IEEE 29119-2⁩ في الخطوات الأولى من عملية تصميم الاختبار وتهيئته: تحديد مجموعات الميزات (Feature sets) واشتقاق شروط الاختبار. وعملياً يغذّي كلٌّ من التخطيط والتحليل الآخر، ويتكرر التحليل لكل قصة وإصدار ومستوى اختبار، وكلما تغيّر الأساس.

هل أبلغ عن مشكلة في المتطلب على أنها عيب؟

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

ماذا أفعل إذا لم تكن هناك متطلبات مكتوبة؟

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

المراجع

الأدوات

تدرّب بأدوات متقن

محلّل فجوات المتطلبات بالذكاء الاصطناعي

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

تحليل المتطلبات ذكاء اصطناعي

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة