قصص المستخدم
قصة المستخدم (User Story) وصف قصير لميزة من وجهة نظر الشخص الذي يحتاجها. وصيغتها المعتادة ثلاثة أجزاء: «بصفتي [الدور]، أريد [الهدف]، لكي [الفائدة]». مثال: «بصفتي عميلاً ينتظر توصيل طلبه، أريد رسالة نصية (SMS) عندما يخرج طلبي للتوصيل، لكي أكون حاضراً لاستلامه». وتكتب فرق رشيقة (Agile) كثيرة معظم عناصر قائمة المهام في صورة قصص، وهي عند المختبِر جزء رئيسي من أساس الاختبار (Test basis).
لكن الجملة وحدها ليست المتطلب كله. فالقصة تكتمل بالحوار بين منظور الأعمال والتطوير والاختبار، وبمعايير القبول (Acceptance criteria) التي تحدد كيف سيعرف الفريق أن القصة أُنجزت. يتناول هذا الدرس الصيغة، والعناصر الثلاثة (3 Cs)، وصفات INVEST، وكيف تُجزّأ القصة الكبيرة جداً، وما يفعله المختبِر بالقصة في جلسة تنقيح قائمة المهام (Backlog refinement).
لماذا يهم
القصة قصيرة عمداً، فما تتركه يُحسم في الحوارات. وحين يغيب المختبِر عنها تظهر الثغرات متأخرة: أثناء الاختبار، في صورة عيوب أو خلافات حول ما كانت القصة تعنيه. وللقصة الكبيرة جداً تكلفة أخرى: تُنجز في الأيام الأخيرة من الدورة (Iteration)، فيُضغط اختبارها أو يُرحَّل إلى الدورة التالية.
والقصص أبكر نقطة يؤثر فيها المختبِر. فسؤال «كيف سنعرف أن هذا يعمل؟» والقصة ما زالت بطاقة هو الاختبار الساكن (Static testing) في أرخص صوره: الفائدة الغامضة أو القاعدة الناقصة تكلّف سؤالاً واحداً الآن، وتكلّف لاحقاً قصة يُعاد فتحها وميزة يُعاد العمل عليها. كما أن القصص الصغيرة القابلة للاختبار تسهّل تصميم الاختبار: فلكلٍّ منها معايير قبول واضحة، وبيانات اختبار معروفة، ولحظة واضحة تُعدّ فيها منجزة.
صيغة القصة والعناصر الثلاثة (3 Cs)
يصف منهج ISTQB للمستوى التأسيسي الصيغة الأكثر شيوعاً: «بصفتي [الدور]، أريد [الهدف]، لكي [الفائدة]» (As a [role], I want [goal], so that [benefit])، تليها معايير القبول. ويستخدم المنهج أيضاً العناصر الثلاثة التي وصفها رون جيفريز (Ron Jeffries)، وهي معاً تكوّن القصة: البطاقة (Card)، والحوار (Conversation)، والتأكيد (Confirmation). والبطاقة هي الوسيط الذي يحمل القصة، سواء كانت بطاقة ورقية أو عنصراً في لوحة إلكترونية أو أداة تتبّع، وعليها الجملة الواحدة بدورها وهدفها وفائدتها. ولكل جزء ما يقدّمه للمختبِر:
- البطاقة، الدور: من يستخدم الميزة. يحدد لك أي مستخدم وأي صلاحيات تختبر بها.
- البطاقة، الهدف: ما يريد المستخدم تحقيقه، لا شكل الشاشة. ويصبح المسار الرئيسي الذي تختبره.
- البطاقة، الفائدة: لماذا يريد المستخدم ذلك، لتحكم هل تلبّي الميزة الحاجة. وفي المثال أدناه: هل الرسالة التي تُرسل لحظة خروج الطلب من المستودع تصل مبكرة بما يكفي ليصل العميل إلى بيته؟
- الحوار: النقاش الذي يُتَّفق فيه على التفاصيل، شفهياً أو كتابةً. والبطاقة قصيرة عمداً، والقرارات التي لا تُكتب فيها تضيع قبل أن تصل القصة إلى الاختبار.
- التأكيد: معايير القبول التي تحدد متى تكون القصة منجزة. وهي نقطة البداية لحالات الاختبار، ويشرح الدرس التالي كيف تُكتب.
STORY-214 رسالة التوصيل
بصفتي عميلاً ينتظر توصيل طلبه،
أريد رسالة SMS عندما يخرج طلبي للتوصيل،
لكي أكون حاضراً لاستلامه.
الحوار (قرارات كُتبت في القصة بعد جلسة التنقيح)
- تُرسل الرسالة إلى رقم الجوال المسجّل في الطلب، لا رقم الحساب.
- تُرسل بلغة الطلب (العربية أو الإنجليزية).
- إذا ضُبطت الحالة مرتين، تُرسل رسالة واحدة فقط.
التأكيد (معايير القبول)
AC1 عند تغيّر حالة الطلب إلى «خرج للتوصيل» تُرسل رسالة واحدة
إلى رقم الجوال المسجّل في الطلب خلال دقيقتين.
AC2 تتضمن الرسالة رقم الطلب ونافذة وقت التوصيل.
AC3 الطلبات التي تُستلم من المتجر لا تُرسل لها رسالة توصيل.| جزء القصة | في قصة رسالة التوصيل | ما يقدّمه للمختبِر |
|---|---|---|
| الدورالبطاقة · «بصفتي…» | عميل ينتظر توصيل طلبه | أي مستخدم وأي صلاحيات تختبر بها |
| الهدفالبطاقة · «أريد…» | رسالة SMS عندما يخرج الطلب للتوصيل | المسار الرئيسي الذي تختبره، لا تصميم الشاشة |
| الفائدةالبطاقة · «لكي…» | أن يكون حاضراً لاستلام الطلب | هل تلبّي الميزة الحاجة: هل تصل الرسالة مبكرة بما يكفي للوصول إلى البيت؟ |
| الحوارالعنصر الثاني | رقم الجوال المسجّل في الطلب، ولغة الطلب، ورسالة واحدة فقط | قرارات تُكتب في القصة قبل الاختبار |
| التأكيدالعنصر الثالث | معايير القبول من AC1 إلى AC3 | متى تكون القصة منجزة: نقطة البداية لحالات الاختبار |
INVEST: ستة أسئلة لقصة جيدة
INVEST اختصار وضعه بيل ويك (Bill Wake) ويستخدمه منهج ISTQB أيضاً، ويصف ست صفات للقصة الجيدة. استخدم الحروف أسئلةً في جلسة التنقيح، لا نموذجاً يُملأ. ولكل صفة منها أثرها في الاختبار.
وصفة «قابلة للاختبار» هي الصفة التي يملك المختبِر أفضل موقع للحكم عليها. ويذكر المنهج أن أصحاب المصلحة إذا لم يعرفوا كيف تُختبر القصة، فقد تكون القصة غير واضحة، أو لا تعكس شيئاً ذا قيمة لهم، أو أنهم يحتاجون فقط إلى مساعدة في الاختبار. ومعرفة السبب من بين هذه تستحق الجهد قبل بناء القصة.
- مستقلة (Independent): هل يمكن بناؤها واختبارها وإصدارها دون انتظار قصة أخرى؟ فالاعتماديات تحدد ترتيب الاختبار وبيانات الاختبار التي تحتاجها.
- قابلة للتفاوض (Negotiable): تذكر حاجة لا تصميماً ثابتاً. والتفاصيل يُتفق عليها في الحوار، فاسأل قبل أن تفترض.
- ذات قيمة (Valuable): يحصل منها مستخدم أو عميل على شيء. و«القصة» التي لا تقدّم شيئاً بمفردها، كجدول في قاعدة البيانات، لا يمكن اختبارها من جهة المستخدم.
- قابلة للتقدير (Estimable): يستطيع الفريق تقدير حجمها، بما في ذلك الاختبار. وإذا لم يعرف أحد كيف ستُختبر، فغالباً لا يمكن تقديرها أيضاً.
- صغيرة (Small): تتسع بسهولة لدورة واحدة مع اختبارها. والقصص الكبيرة تدفع الاختبار إلى الأيام الأخيرة.
- قابلة للاختبار (Testable): هناك طريقة للحكم بأنها منجزة. وكلمات مثل «سريع» و«سهل» و«أفضل» تحتاج إلى معنى قابل للقياس قبل بدء العمل.
تجزئة القصة الكبيرة جداً
القصة الأكبر من أن تُنجز في دورة واحدة تُسمّى غالباً ملحمة (Epic). جزّئها بحيث تبقى كل قصة أصغر شريحةً عمودية (Vertical slice): تمر بكل طبقة تحتاجها الميزة، من الشاشة إلى الواجهة البرمجية (API) إلى قاعدة البيانات، وتعطي المستخدم شيئاً يستطيع تجربته.
خذ الملحمة: «بصفتي عميلاً، أريد إرجاع المنتجات عبر الإنترنت، لكي أستردّ مالي دون الاتصال بالدعم». إذا جُزّئت حسب الطبقات صارت جدولاً للإرجاع وواجهة API للإرجاع وشاشة للإرجاع: لا يستطيع أي مستخدم تجربة أيٍّ منها، ولا يمكن اختبار شيء من البداية إلى النهاية حتى تكتمل الثلاث، فتظهر عيوب التكامل في النهاية. وإذا جُزّئت شرائح، فالقصة الأولى «إرجاع طلب مُسلَّم كاملاً واسترداد المبلغ إلى وسيلة الدفع الأصلية»: صغيرة لكنها كاملة، فيمكن اختبارها فور إنجازها، وتلتقي الطبقات في القصة الأولى. ومن الطرق المفيدة للتجزئة:
التجزئة حسب الطبقاتتجنّبها
قاعدة البيانات وواجهة API والشاشة قصصاً منفصلة
- هل يستطيع مستخدم تجربة القصة الأولى؟:
- لا
- الاختبار من البداية إلى النهاية:
- فقط بعد اكتمال القصص الثلاث
- متى تظهر عيوب التكامل:
- في النهاية، حين تلتقي الطبقات
- جدول الإرجاع في قاعدة البيانات
- واجهة API للإرجاع
- شاشة الإرجاع
التجزئة إلى شرائح عموديةفضّلها
كل قصة تمر من الشاشة إلى قاعدة البيانات
- هل يستطيع مستخدم تجربة القصة الأولى؟:
- نعم: يمكن إرجاع طلب كامل
- الاختبار من البداية إلى النهاية:
- كل قصة، فور إنجازها
- متى تظهر عيوب التكامل:
- في القصة الأولى
- إرجاع طلب مُسلَّم كاملاً واسترداد المبلغ إلى وسيلة الدفع الأصلية
- إرجاع منتجات مختارة من الطلب
- رفض الإرجاع المتأخر وإرجاع بطاقات الهدايا، مع ذكر السبب
- حسب خطوات سير العمل: سلّم أبسط مسار كامل أولاً وأضف الخطوات الأخرى لاحقاً، فمثلاً طلب الإرجاع الآن وحجز استلام المندوب في قصة لاحقة.
- حسب قاعدة العمل: قاعدة واحدة، أو صورة واحدة من القاعدة، في كل قصة، فمثلاً الطلب الكامل أولاً، ثم المنتجات المختارة، ثم رفض الإرجاع المتأخر وإرجاع بطاقات الهدايا.
- حسب المسار: المسار الناجح الرئيسي أولاً، ثم كل مسار خطأ أو استثناء في قصة خاصة به بمعايير قبول خاصة به، مخطَّطٌ لها لا مؤجلة إلى «لاحقاً إن سمح الوقت».
- حسب البيانات أو القناة: وسيلة دفع واحدة أو نوع ملف واحد أو منصة واحدة أولاً، والبقية في قصص لاحقة.
- حسب العملية: الإنشاء والعرض والتعديل والحذف قصصاً منفصلة حين تكون كل منها مفيدة بمفردها.
- الاستقصاء (Spike): حين لا يستطيع الفريق التقدير لوجود مجهول، كواجهة API خارجية، يُجري بحثاً قصيراً محدد المدة (Time-boxed) للعثور على الجواب، ثم تُكتب القصة الحقيقية بعده. والاستقصاء ينتج معرفة، لا ميزة تُختبر.
مثال تطبيقي: المختبِر في جلسة التنقيح
يعرض مالك المنتج (Product Owner) ملحمة الإرجاع في جلسة التنقيح. وقبل الجلسة قرأها المختبِر مع قاعدة الإرجاع BR-03 من درس قواعد العمل (الإرجاع خلال 14 يوماً من التسليم، ولا إرجاع لبطاقات الهدايا أبداً) ومع ملاحظات واجهة API لشركة الشحن. وفي الجلسة يفحص الملحمة وفق INVEST ويطرح النقاط المذكورة أدناه.
ثم يتفق الفريق على التجزئة المعروضة بعد القائمة. ويتحقق المختبِر من أن كل قصة جديدة يمكن اختبارها بمفردها، وأن RET-3 تحتفظ بنتيجة «في غير ذلك» من القاعدة BR-03، وأن بيانات الاختبار معروفة: طلبات سُلّمت قبل 14 و15 يوماً، وطلب يحتوي على بطاقة هدية. وتُكتب الإجابات في القصص، وتحصل كل قصة على معايير قبول قبل أن تُعدّ جاهزة.
- ليست صغيرة ولا قابلة للتقدير: تخفي الملحمة اختيار المنتجات، والاسترداد الجزئي، ووسيلتين للاسترداد، واستلام المندوب، وحالات الرفض.
- غير قابلة للاختبار كما كُتبت: «أستردّ مالي» لا تقول كم ولا متى. هل تُستردّ رسوم التوصيل؟
- غير مستقلة: الاستلام يعتمد على واجهة API لشركة الشحن لم يستخدمها أحد في الفريق.
- أسئلة مفتوحة: من أي لحظة تبدأ الأيام الأربعة عشر، وبأي منطقة زمنية؟ هل يستطيع العميل إلغاء الإرجاع؟ ماذا يرى العميل أثناء انتظار الاسترداد؟
الملحمة: الإرجاع عبر الإنترنت
RET-1 إرجاع طلب مُسلَّم كاملاً؛ الاسترداد إلى وسيلة الدفع الأصلية
RET-2 إرجاع منتجات مختارة من الطلب؛ استرداد قيمتها فقط
RET-3 رفض الإرجاع بعد 14 يوماً أو لبطاقات الهدايا، مع عرض السبب
RET-4 استقصاء (Spike) لمدة يومين: هل تحجز واجهة API لشركة الشحن الاستلام؟
تُكتب RET-5 بناءً على الجواب
RET-5 حجز استلام المندوب لطلب الإرجاع
RET-6 الاسترداد إلى المحفظة داخل التطبيق بدلاً من البطاقة
قرارات كُتبت في القصص:
- تُستردّ رسوم التوصيل فقط عند إرجاع الطلب كاملاً.
- تبدأ الأيام الأربعة عشر من مسح التسليم، بتوقيت السعودية (UTC+3).جرّبها: مولّد معايير القبول جرّبها: قصة المستخدم ← حالات اختبار
أخطاء شائعة
- التعامل مع البطاقة ذات الجملة الواحدة كأنها المتطلب كله، أو ترك قرارات جلسة التنقيح في رؤوس الناس ومحادثات الدردشة، فتغيب حين تصل القصة إلى الاختبار.
- قبول فائدة غامضة أو غائبة («لكي يعمل بشكل أفضل»): فبدونها لا يستطيع أحد الحكم هل تلبّي الميزة المسلَّمة الحاجة.
- تسمية المهام التقنية قصصَ مستخدم («بصفتي مطوراً، أريد جدولاً للإرجاع»): فهي لا تقدّم شيئاً يجربه المستخدم، ولا يمكن اختبارها من جهته.
- التجزئة حسب الطبقة أو حسب النشاط، كقصة «للبناء» وأخرى «للاختبار»، بدلاً من شرائح عمودية يمكن اختبار كل منها من البداية إلى النهاية.
- أن يتحول «المسار السعيد (Happy path) أولاً» إلى «المسار السعيد فقط»: تُفصل مسارات الأخطاء وحالات الرفض والاحتياجات غير الوظيفية في قصص لاحقة لا يُخطَّط لها أبداً.
- الانتظار حتى تصل القصة إلى الاختبار للقول إنها غير قابلة للاختبار، بدلاً من طرح ذلك في جلسة التنقيح حين يكون التغيير ما زال رخيصاً.
من منظور ضمان الجودة
في معظم الفرق الرشيقة يملك مالك المنتج القصص، لكن منهج ISTQB للمستوى التأسيسي يصف كتابتها تعاونياً، بحضور منظور الأعمال والتطوير والاختبار معاً؛ وكما رأيت في درس Agile للمختبِرين، تسمّي فرق كثيرة هذا اللقاء «الأصدقاء الثلاثة» (Three amigos). وإسهام المختبِر محدد: اقرأ القصة وما يرتبط بها من قواعد وتصاميم وعقود قبل الجلسة؛ واحضر بأسئلة وأمثلة ملموسة؛ وافحص صفات INVEST بصوت مسموع، وخاصة «قابلة للاختبار» و«صغيرة»؛ واقترح تجزئة على حدود يمكن اختبار كل جزء منها بمفرده.
بعد الجلسة تأكد أن كل قرار مكتوب في القصة لا متروك في محادثة، وأن القصة تستوفي تعريف الجاهزية (Definition of Ready) لدى الفريق قبل دخولها الدورة. سجّل بيانات الاختبار والبيئات التي تحتاجها القصة، واربطها بقواعد العمل ثم بحالات الاختبار لاحقاً، وصُغ مسودة شروط الاختبار (Test conditions) من معايير القبول. وإذا وصلت قصة إلى الاختبار وفيها ثغرات رغم ذلك، فسجّلها على القصة نفسها، لتتحسن جلسة التنقيح التالية.
تمرين عملي
راجع قصة وجزّئها قبل جلسة التنقيح
تختبر تطبيق توصيل لمتجر بقالة (سوبرماركت)، وجلسة التنقيح غداً. وقد كتب مالك المنتج القصة أدناه. افحصها وفق INVEST، وأعد كتابة البطاقة، وجزّئها إلى شرائح عمودية، وجهّز الأسئلة التي ستطرحها في الجلسة.
بصفتي مستخدماً، أريد إنشاء قوائم تسوق ومشاركتها مع عائلتي
والحصول على اقتراحات من طلباتي السابقة، لكي يكون التسوق أفضل.- حدّد الدور والهدف والفائدة، واذكر نقطة الضعف في كل منها.
- مرّ على حروف INVEST الستة وسجّل كل مشكلة تجدها.
- جزّئ القصة إلى شرائح عمودية يمكن اختبار كل منها بمفردها.
- اكتب أربعة أسئلة على الأقل لمالك المنتج.
إظهار الإجابة النموذجية
الدور والهدف والفائدة: «مستخدم» عام جداً؛ فالدور هو الشخص الذي يخطط لمشتريات الأسرة، والمشاركة تضيف دوراً ثانياً هو فرد العائلة الذي يستقبل القائمة. والهدف يجمع ثلاث ميزات بحرف العطف «و». والفائدة «يكون التسوق أفضل» لا يمكن التحقق منها؛ والصيغة القابلة للاستخدام: «لكي أطلب كل ما أحتاجه دفعة واحدة».
INVEST: ليست صغيرة (ثلاث ميزات)؛ وليست قابلة للتقدير (لا أحد يعرف بعد هل تكفي الطلبات السابقة بيانات لاقتراحات مفيدة)؛ وليست قابلة للاختبار («أفضل» بلا معنى يُفحص، ولا معايير قبول)؛ ومستقلة جزئياً فقط (المشاركة تحتاج إلى القوائم، والاقتراحات تحتاج إلى سجل الطلبات). أما «ذات قيمة» و«قابلة للتفاوض» فمقبولتان بعد إعادة كتابة الفائدة.
تجزئة ممكنة: (1) بصفتي متسوقاً للأسرة، أريد إنشاء قائمة وإضافة منتجات من الكتالوج، لكي أخطط لطلبي التالي. (2) بصفتي متسوقاً للأسرة، أريد تحويل القائمة إلى سلة بخطوة واحدة، لكي أطلب أسرع. (3) بصفتي متسوقاً للأسرة، أريد مشاركة قائمة مع فرد من العائلة له حساب، لكي يضيف ما يحتاجه. (4) استقصاء (Spike) محدد المدة: هل تنتج الطلبات السابقة اقتراحات مفيدة؟ وتُكتب قصة الاقتراحات بناءً على جوابه. والقصة 1 تأتي أولاً لأن القصتين الأخريين تحتاجان إلى قائمة؛ وبعدها لا تعتمد القصة 2 على القصة 3 ولا العكس، ويمكن بناء كل منهما واختبارها وإصدارها بمفردها.
الأسئلة: هل هناك حد أقصى لعدد القوائم، أو لعدد المنتجات في القائمة؟ ماذا يحدث لمنتج في القائمة إذا نفد من المخزون أو تغيّر سعره؟ هل يستطيع فرد العائلة حذف القائمة، أم الإضافة إليها فقط؟ ماذا يحدث للقائمة المشتركة إذا أغلق مالكها حسابه؟ هل تظهر أسماء المنتجات بالعربية والإنجليزية معاً؟
أسئلة شائعة
من يكتب قصص المستخدم: مالك المنتج أم المختبِر؟
يملكها مالك المنتج ويرتّبها عادةً، وإن كان أي فرد في الفريق يستطيع صياغة مسودة لها. ويصف منهج ISTQB للمستوى التأسيسي كتابتها تعاونياً بمنظور الأعمال والتطوير والاختبار. ونادراً ما يكتب المختبِر البطاقة، لكنه كثيراً ما يشكّل الحوار ومعايير القبول.
هل قصة المستخدم متطلب؟
نعم، فهي صيغة مختصرة لمتطلب المستخدم أو أصحاب المصلحة. لكن الجملة وحدها لا تكفي للاختبار: فأساس الاختبار هو القصة مع معايير قبولها، والقرارات المسجلة من الحوار، وما يرتبط بها من قواعد عمل وتصاميم وعقود API.
هل يجب أن تستخدم كل قصة قالب «بصفتي… أريد… لكي…»؟
لا. إنه الصيغة الأكثر شيوعاً لا قاعدة ملزمة، ودليل سكرم (Scrum Guide) لا يشترط قصص المستخدم أصلاً. المهم أن يذكر العنصر لمن هو، وما الذي يحتاجه ولماذا، وكيف سيتأكد الفريق من إنجازه.
ما الحجم المناسب للقصة؟
صغيرة بما يكفي ليبنيها الفريق ويختبرها وفق تعريف الإنجاز (Definition of Done) خلال دورة واحدة، ويُفضَّل قبل نهايتها بوقت كافٍ حتى لا يتكدس الاختبار في آخرها. وعلامة عملية: إذا لم تستطع سرد معايير قبولها وبيانات اختبارها في بضع دقائق، فهي على الأرجح ما زالت كبيرة.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Certified Tester Foundation Level Agile Tester (CTFL-AT)امتداد ISTQB للمستوى التأسيسي حول الاختبار داخل فرق Agile؛ وهو في طور الإيقاف (امتحانات الإنجليزية متاحة حتى 6 مايو 2027) لصالح CTFL v4.0 وCTAL-AT.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
تدرّب بأدوات متقن
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
حوّل قصة مستخدم (As a / I want / So that) إلى حالات اختبار منظّمة باستخدام القوالب والقواعد الاستدلالية.
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
اكتشف العبارات الغامضة أو المبهمة أو المتناقضة في المتطلبات واحصل على أسئلة توضيحية من الذكاء الاصطناعي من متقن.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.