معايير القبول
معايير القبول (Acceptance Criteria) هي الشروط التي يجب أن يستوفيها تنفيذ قصة المستخدم ليقبله أصحاب المصلحة. ويضيف منهج ISTQB للمستوى التأسيسي النظرة الأهم للمختبِر: يمكن عدّ معايير القبول شروطَ الاختبار (Test Conditions) التي ينبغي أن تغطيها الاختبارات. وهي في العادة ثمرة «الحوار» (Conversation)، ثاني العناصر الثلاثة التي تعرّفت إليها في درس قصص المستخدم، وحين تُدوَّن تصبح العنصر الثالث: «التأكيد» (Confirmation).
خذ هذه القصة: «بصفتي عضواً في المكتبة، أريد أن أجدّد عبر الإنترنت كتاباً استعرته، لكي أحتفظ به مدة أطول دون زيارة المكتبة». القصة تذكر الحاجة، لكنها لا تقول كم تطول المدة، ولا كم مرة يجوز التجديد، ولا ماذا يحدث إذا كان شخص آخر ينتظر الكتاب. ومعايير مثل «يؤخّر التجديد تاريخ الاستحقاق 14 يوماً» و«لا يمكن تجديد كتاب حجزه عضو آخر» تجيب عن هذه الأسئلة، ويمكن فحص كل منها بحكم واضح بالنجاح أو الفشل.
لماذا يهم
يعدّد المنهج وظائف معايير القبول: تحديد نطاق القصة، والوصول إلى توافق بين أصحاب المصلحة، ووصف السيناريوهات الإيجابية والسلبية معاً، والعمل أساساً لاختبار قبول القصة، وإتاحة تخطيط وتقدير دقيقين. ومن دونها يملأ كل شخص الفراغات بافتراضاته، وكثيراً ما لا يظهر الاختلاف إلا في مراجعة السبرنت (Sprint Review) حين يجب إعادة العمل.
وبالنسبة إلى المختبِر، معايير القبول هي المصدر الأول للنتائج المتوقعة. فالنتيجة المتوقعة التي تخترعها بنفسك تخمينٌ لما أرادته جهة الأعمال، أما المأخوذة من معيار متفق عليه فيستطيع أي شخص أن يحكم بها. ومراجعة المعايير قبل التطوير هي أيضاً أرخص صور الاختبار الساكن: فالمعيار الغامض أو المتناقض الذي يُصحَّح أثناء التنقيح (Refinement) لا يتحول أبداً إلى عيب في الشيفرة.
معايير بصيغة القواعد ومعايير بصيغة السيناريوهات
يذكر منهج ISTQB صيغتين شائعتين. المعايير الموجّهة بالقواعد (Rule-oriented) قائمة تحقق نقطية، أو جدول يربط المدخلات بالمخرجات. والمعايير الموجّهة بالسيناريوهات (Scenario-oriented) أمثلة محددة بصيغة Given/When/Then المستخدمة في التطوير الموجَّه بالسلوك (BDD). ويجوز للفريق أن يعتمد صيغة خاصة به بدلاً منهما، ما دامت المعايير محددة جيداً وخالية من الغموض.
والصيغتان تتكاملان. فالقواعد تعرض السياسة باختصار ويسهل فحصها بحثاً عن النقص، والسيناريوهات تُظهر السياسة وهي تعمل على بيانات حقيقية فتزيل الشك في معنى القاعدة. وكثير من الفرق يكتب القواعد أولاً ثم يضيف سيناريو لكل قاعدة تحتمل قراءتين. بل إن لغة Gherkin التي تستخدمها أداة Cucumber فيها الكلمة المفتاحية Rule لتجميع السيناريوهات التي توضّح قاعدة عمل واحدة.
- قائمة القواعد تناسب الحدود والصلاحيات وقواعد فحص المدخلات والحسابات، مثل «تجديدان على الأكثر لكل إعارة».
- جدول المدخلات والمخرجات يناسب القاعدة ذات الشروط المتعددة، حين تحتاج كل تركيبة إلى إجابة.
- السيناريوهات تناسب السلوك الذي يعتمد على الحالة أو على ترتيب الأحداث، والأمثلة التي ينوي الفريق أتمتتها.
LIB-42 تجديد كتاب مُعار عبر الإنترنت
بصفتي عضواً في المكتبة، أريد أن أجدّد عبر الإنترنت كتاباً استعرته،
لكي أحتفظ به مدة أطول دون زيارة المكتبة.
معايير القبول (بصيغة القواعد)
AC1 يؤخّر التجديد تاريخ الاستحقاق 14 يوماً، محسوبة من تاريخ الاستحقاق
الحالي، لا من يوم التجديد.
AC2 يمكن تجديد الإعارة مرتين على الأكثر. وتعرض صفحة «إعاراتي» التجديدات المتبقية.
AC3 لا يمكن تجديد كتاب حجزه عضو آخر: تظهر الرسالة «محجوز لعضو آخر»
ويبقى تاريخ الاستحقاق دون تغيير.
AC4 لا يمكن تجديد إعارة متأخرة عبر الإنترنت: تظهر الرسالة
«الإعارات المتأخرة تُجدَّد من مكتب الإعارة فقط».تشريح سيناريو Given/When/Then
السيناريو مثال واحد على سلوك واحد. فالكلمة Given تصف السياق: حالة النظام وبياناته قبل أن يحدث أي شيء. وWhen تصف الحدث أو الإجراء قيد الاختبار. وThen تصف النتيجة المتوقعة. أما And وBut فتُكملان الكلمة التي قبلهما، فإذا جاءت And بعد Given أضافت سياقاً، وإذا جاءت بعد Then أضافت نتيجة أخرى.
وعادتان تحافظان على فائدة السيناريوهات. استخدم خطوة When واحدة في كل سيناريو؛ فالحاجة إلى خطوة ثانية تعني في الغالب أنك تصف سلوكاً ثانياً وينبغي تقسيم السيناريو. واجعل كل Then نتيجة قابلة للملاحظة: فمرجع Gherkin من Cucumber يطلب شيئاً يخرج من النظام، مثل تقرير أو واجهة المستخدم أو رسالة، لا سلوكاً مدفوناً داخله مثل سجل في قاعدة البيانات.
اكتب السياق حقائقَ لا نقرات. فعبارة «Given سارة استعارت نجوم الصحراء وتاريخ استحقاقه 10 مارس 2026» تبقى صحيحة حين يُعاد تصميم الشاشات، أما «Given سارة تفتح صفحة إعاراتي وتنقر الصف الأول» فلا تبقى، وتُخفي أيّ البيانات هو المهم. وحين يحتاج سلوك واحد إلى عدة مجموعات من البيانات، يُشغَّل Scenario Outline مرة لكل صف في جدول Examples الخاص به، كما في حد التجديد أدناه.
الاختبار T1 من القصة LIB-42 مكتوباً سيناريو
الجزء 1:Scenario: Renewing moves the due date 14 days later الجزء 2:Given Sara has borrowed "Desert Stars", due on 10 March 2026 الجزء 3:And nobody has reserved the book And Sara has not renewed this loan before الجزء 4:When Sara renews the loan on 5 March 2026 الجزء 5:Then the due date shown on My loans is 24 March 2026 الجزء 6:And My loans shows 1 renewal left
- 2–3السياق ← الشروط المسبقة لحالة الاختبار وبياناتها
- 4الإجراء ← خطوة الاختبار ومُدخلها
- 5–6النتائج الظاهرة ← النتائج المتوقعة
- 1عنوان السيناريويسمّي سلوكاً واحداً: القاعدة AC1 التي يوضّحها هذا المثال.
- 2Given: السياقالحالة قبل الإجراء، مكتوبةً حقائقَ ببيانات محددة: مَن، وأي كتاب، وأي تاريخ استحقاق.
- 3And: سياق إضافييستبعد الحجز والتجديدات السابقة، فلا يستطيع المعيار AC3 ولا حدّ التجديد أن يغيّر النتيجة.
- 4When: إجراء واحدالحدث الوحيد قيد الاختبار. التجديد يوم 5 مارس يعطي 24 مارس إذا حُسبت الأيام من تاريخ الاستحقاق، و19 مارس إذا حُسبت من اليوم.
- 5Then: النتيجة القابلة للملاحظةما يراه العضو في الصفحة هو ما يحسم النجاح أو الفشل، لا سجل في قاعدة البيانات.
- 6And: نتيجة ثانيةنتيجة ظاهرة أخرى للإجراء نفسه: التجديدات المتبقية التي يطلب المعيار AC2 عرضها في صفحة «إعاراتي»، ولهذا يُربط T1 بالمعيارين AC1 وAC2.
Scenario Outline: يمكن تجديد الإعارة مرتين على الأكثر
Given إعارة «نجوم الصحراء» لسارة جُدِّدت <before> مرات
And لم يحجز أحد الكتاب
When تجدّد سارة الإعارة
Then يكون التجديد <result>
Examples:
| before | result |
| 0 | مقبولاً |
| 1 | مقبولاً |
| 2 | مرفوضاً |معايير القبول الجيدة والضعيفة
المعيار الجيد يجعل مالك المنتج (Product Owner) والمطوّر والمختبِر يصلون إلى الحكم نفسه على النتيجة نفسها. وهذه الفحوص تكشف معظم المعايير الضعيفة، والأزواج أدناه تُظهر طرق الإصلاح المعتادة.
- قابل للاختبار: له نتيجة قابلة للملاحظة وحكم واضح بالنجاح أو الفشل. وعبارة «التجديد سهل» تفتقر إلى الاثنين.
- محدد: الأرقام والحدود والرسائل والأدوار مذكورة صراحةً لا ضمناً.
- يصف السلوك: ما يراه المستخدم ويتعامل معه، لا الجدول أو الحقل أو الواجهة البرمجية التي يغيّرها المطوّر.
- مكتمل: يغطي حالات الرفض، بما فيها ما يراه المستخدم حين لا يُسمح بالإجراء.
- مركّز: قاعدة واحدة في كل معيار، فيشير فشل الاختبار إلى قاعدة واحدة بعينها.
- ضمن القصة: الشرط الذي يحتاج إلى ميزة أخرى ينتمي إلى قصة أخرى.
ضعيف: يجب أن يكون التجديد سريعاً.
قابل للاختبار: يظهر تاريخ الاستحقاق الجديد خلال ثانيتين من اختيار «تجديد»
(القيمة يؤكدها مالك المنتج).
ضعيف: يستطيع العضو تجديد كتاب.
قابل للاختبار: كل تجديد يضيف 14 يوماً إلى تاريخ الاستحقاق الحالي.
قابل للاختبار: يمكن تجديد الإعارة مرتين على الأكثر.
ضعيف: تُعالَج الأخطاء بالشكل المناسب.
قابل للاختبار: لا يمكن تجديد كتاب محجوز، وتظهر الرسالة «محجوز لعضو آخر».
ضعيف: تزداد قيمة العمود renew_count.
قابل للاختبار: ينقص عدد التجديدات المتبقية في صفحة «إعاراتي» بمقدار 1.من المعايير إلى الاختبارات: مدخل إلى ATDD
التطوير الموجَّه باختبارات القبول (ATDD) نهج يبدأ بالاختبار: تُنشأ حالات الاختبار قبل تنفيذ القصة، ويكتبها أشخاص من وجهات نظر مختلفة، مثل العملاء والمطوّرين والمختبِرين. ويبدأ بورشة مواصفات (Specification Workshop) يحلّل فيها الفريق القصة، ويكتب ما ينقص من معاييرها، ويعالج ما فيها من نقص وغموض وعيوب. وبعض الفرق تسمّي هذا الاجتماع «الأصدقاء الثلاثة» (Three Amigos).
ثم تُشتق حالات الاختبار من المعايير. وهي أمثلة على الطريقة التي ينبغي أن يعمل بها البرنامج، ولهذا يستخدم ATDD كلمتي «الأمثلة» و«الاختبارات» بمعنى يكاد يكون واحداً. ويقترح المنهج ترتيباً: الحالات الإيجابية أولاً، ثم السلبية، ثم الخصائص غير الوظيفية مثل كفاءة الأداء أو قابلية الاستخدام. وينبغي أن تغطي الاختبارات كل خصائص القصة دون أن تتجاوزها، وألّا يصف اختباران الخاصية نفسها. ويمكن تنفيذ الاختبارات يدوياً أو آلياً: فإذا كُتبت بصيغة يستطيع إطار أتمتة تشغيلها، أمكن أتمتتها أثناء بناء الميزة فتصبح متطلبات قابلة للتنفيذ.
- تصبح Given الشروطَ المسبقة لحالة الاختبار وبياناتِ الاختبار.
- تصبح When خطوةَ الاختبار ومُدخلها.
- تصبح Then النتيجةَ المتوقعة، مكتوبةً قبل تشغيل الاختبار.
- يُربط كل اختبار بالمعيار الذي يفحصه، فتستطيع أن تُبلغ عن المعايير المغطاة.
مثال تطبيقي: اختبارات قصة التجديد
في ورشة المواصفات للقصة LIB-42 يقرأ المختبِر كل معيار بالفحوص السابقة ويقترح بيانات الاختبار. فالمعيار AC1 يقول صراحةً إن الأيام الأربعة عشر تُحسب من تاريخ الاستحقاق، لكن المطوّر قد يحسبها من اليوم مع ذلك، لذا يختار المختبِر بيانات تفرّق بين القراءتين: إعارة تستحق في 10 مارس وجُدِّدت في 5 مارس يجب أن تنتقل إلى 24 مارس، أما الحساب من يوم التجديد فيعطي 19 مارس.
وتتبع الاختبارات ترتيب المنهج: الحالتان الإيجابيتان T1 وT2 أولاً، ثم الحالات السلبية من T3 إلى T5. وكل Given يستبعد حالات الرفض التي لا يتناولها الاختبار، مثل الحجز أو التأخر، حتى لا تحسم النتيجةَ إلا قاعدة واحدة. وكل اختبار مربوط بمعياره، وكل نتيجة متوقعة اتُّفق عليها قبل كتابة أي شيفرة.
- السؤال المفتوح Q1: لا يذكر AC2 ما يراه العضو حين يبلغ الحد، فلا يستطيع T3 أن يحدد الرسالة بعد. القرار لمالك المنتج، والمختبِر يسجّل السؤال على القصة.
- السؤال المفتوح Q2: قد تكون الإعارة متأخرة ومحجوزة في الوقت نفسه. فأي رسالة تظهر؟ تصبح الإجابة معياراً جديداً واختباراً جديداً.
اختبارات LIB-42 (الإيجابية أولاً ثم السلبية)
T1 AC1, AC2 Given: الاستحقاق 10 مارس 2026، لا تجديدات سابقة، غير محجوز
When: التجديد يوم 5 مارس 2026
Then: الاستحقاق 24 مارس 2026؛ التجديدات المتبقية: 1
T2 AC1, AC2 Given: الاستحقاق 24 مارس 2026، جُدِّد مرة واحدة، غير محجوز
When: التجديد يوم 20 مارس 2026
Then: الاستحقاق 7 أبريل 2026؛ التجديدات المتبقية: 0
T3 AC2 Given: جُدِّد مرتين، غير متأخر، غير محجوز
When: التجديد
Then: مرفوض؛ تاريخ الاستحقاق دون تغيير (الرسالة: انظر Q1)
T4 AC3 Given: لا تجديدات سابقة، غير متأخر، محجوز لعضو آخر
When: التجديد
Then: «محجوز لعضو آخر»؛ تاريخ الاستحقاق دون تغيير
T5 AC4 Given: الاستحقاق 10 مارس 2026، واليوم 12 مارس 2026، لا تجديدات، غير محجوز
When: التجديد
Then: «الإعارات المتأخرة تُجدَّد من مكتب الإعارة فقط»جرّبها: قصة المستخدم ← حالات اختبار جرّبها: المتطلبات ← حالات اختبار
أخطاء شائعة
- استخدام كلمات لا يمكن قياسها مثل «سريع» و«سهل» و«بالشكل المناسب» و«سهل الاستخدام». اطلب الرقم أو النتيجة القابلة للملاحظة بدلاً منها.
- كتابة المسار السعيد وحده. فكل حد وصلاحية وحالة رفض تحتاج إلى معيار يذكر ما يراه المستخدم.
- وصف النقرات والشاشات بدلاً من السلوك، فتنكسر السيناريوهات مع كل إعادة تصميم وتُخفي أيّ البيانات هو المهم.
- وضع عدة سلوكيات في سيناريو واحد بسلسلة من خطوات When وThen، فإذا فشل لم يعرف أحد أي قاعدة انكسرت.
- التعامل مع المعايير كنص ثابت يتسلّمه المختبِر. فهي يُتفق عليها في الحوار، والمختبِر الذي يكتفي بقراءتها يفوته أرخص وقت لاكتشاف العيوب.
- تغيير معيار أثناء السبرنت دون إبلاغ الفريق، فتُبنى الشيفرة والاختبارات على نسختين مختلفتين.
من منظور ضمان الجودة
إسهامك الأكبر يحدث قبل وجود أي شيفرة. ففي التنقيح أو ورشة المواصفات اقرأ كل معيار واسأل: «كيف سأختبر هذا؟» و«ماذا يحدث لو…؟». اقترح أمثلة محددة وبيانات اختبار، ونبّه إلى الكلمات الغامضة، واقترح معايير الرفض الناقصة. مالك المنتج هو من يقرر قواعد العمل، ومهمتك أن تتأكد من أن القرار مكتوب بصيغة يستطيع الجميع فحصها.
سجّل المعايير المتفق عليها على القصة نفسها، مع الأسئلة المفتوحة وصاحب كل سؤال وموعده. واربط كل اختبار بالمعيار الذي يفحصه، ودوّن أيّها مؤتمت. وإذا تغيّر معيار أثناء السبرنت فحدّث اختباراته في التغيير نفسه. وفي مراجعة السبرنت اعرض الأدلة معياراً معياراً، فيكون القبول فحصاً لا جدالاً.
تمرين عملي
أصلح معايير قصة تغيير عنوان التوصيل
في تطبيق للبقالة هذه القصة ومسودة معاييرها. حدّد ما يُضعف كل معيار، وأعد كتابة المعايير قواعدَ قابلة للاختبار، ثم اكتب سيناريوهين بصيغة Given/When/Then وقائمة الاختبارات التي ستشتقها.
وحيث تنقص قيمة، اقترح قيمة وعلّمها سؤالاً لمالك المنتج بدلاً من أن تقررها بنفسك.
GRO-17 تغيير عنوان التوصيل لطلب
بصفتي عميلاً، أريد تغيير عنوان التوصيل بعد تقديم الطلب،
لكي يصلني الطلب حيث سأكون.
AC1 يستطيع العميل تغيير العنوان بسهولة.
AC2 ينبغي أن يكون التغيير ممكناً إلى أن يتقدّم الطلب كثيراً.
AC3 تُعالَج العناوين غير الصالحة بالشكل المناسب.
AC4 يجب أن يكون التحديث سريعاً.- ضع علامة على كل كلمة أو عبارة يمكن أن يفهمها قارئان بطريقتين مختلفتين.
- أعد كتابة المعايير قائمةَ قواعد، بقاعدة واحدة في كل معيار، مع حالات الرفض.
- اكتب سيناريو إيجابياً وآخر سلبياً بصيغة Given/When/Then ببيانات محددة.
- اكتب الاختبارات التي ستشتقها: الإيجابية أولاً ثم السلبية، وكل منها مربوط بمعيار.
إظهار الإجابة النموذجية
مواضع الضعف: «بسهولة» بلا نتيجة قابلة للملاحظة وتكرّر القصة فقط؛ و«ينبغي» تترك السؤال مفتوحاً: هل القاعدة إلزامية؟ و«يتقدّم كثيراً» لا تسمّي حالة للطلب؛ و«غير الصالحة» و«بالشكل المناسب» لا تقولان أيّ العناوين ولا ماذا يرى العميل؛ و«سريعاً» بلا رقم.
القواعد، مع تعليم القيم المقترحة أسئلةً. AC1: ما دامت حالة الطلب «قيد التجهيز» يستطيع العميل استبدال عنوان التوصيل من صفحة الطلب، ثم يعرض الطلب العنوان الجديد. AC2: ابتداءً من الحالة «خرج للتوصيل» لا يظهر خيار التغيير، ويُرفض التغيير المرسل عبر الواجهة البرمجية (سؤال: هل «قيد التجهيز» هي نقطة التوقف الصحيحة؟). AC3: يُرفض العنوان الواقع خارج نطاق التوصيل مع الرسالة «لا نوصل إلى هذا العنوان»، ويبقى العنوان القديم (سؤال: ما العناوين الأخرى التي تُعدّ غير صالحة، مثل عنوان بلا رقم مبنى؟). AC4: يظهر العنوان الجديد على الطلب خلال ثانيتين من الحفظ (سؤال: أكّد القيمة، أو غطِّها بمعيار أداء عام للفريق).
السيناريو الإيجابي: Given الطلب 5531 حالته «قيد التجهيز» وعنوانه 12 شارع النخيل؛ When يغيّر العميل العنوان إلى 40 طريق الحدائق؛ Then تعرض صفحة الطلب 40 طريق الحدائق. السيناريو السلبي: Given الطلب 5531 حالته «خرج للتوصيل»؛ When يفتح العميل صفحة الطلب؛ Then لا يظهر أي خيار لتغيير العنوان.
الاختبارات: T1 التغيير والحالة «قيد التجهيز» (AC1)؛ T2 إخفاء الخيار في الحالة «خرج للتوصيل» (AC2)؛ T3 رفض التغيير عبر الواجهة البرمجية في الحالة «خرج للتوصيل» (AC2)؛ T4 رفض عنوان خارج النطاق مع الرسالة وبقاء العنوان القديم (AC3)؛ T5 حد الثانيتين بعد تأكيده (AC4)، وهو الأخير لأنه غير وظيفي. وسؤال آخر للورشة: إذا وقع العنوان الجديد في منطقة رسوم توصيلها مختلفة، فماذا يحدث للرسوم؟
أسئلة شائعة
هل يجب أن تُكتب معايير القبول بصيغة Given/When/Then؟
لا. يذكر منهج ISTQB الصيغة الموجّهة بالقواعد والصيغة الموجّهة بالسيناريوهات بوصفهما الأكثر شيوعاً، ويقبل صيغة خاصة ما دامت المعايير محددة جيداً وخالية من الغموض. ولا تلزم صياغة Gherkin إلا إذا كانت أداة BDD مثل Cucumber ستشغّل السيناريوهات.
من يكتب معايير القبول؟
في العادة يكتب مسودتها مالك المنتج أو محلل الأعمال، ثم يصقلها الفريق في الحوار. فجهة الأعمال تقرر القواعد، والمطوّرون يتحققون من إمكانية التنفيذ، والمختبِر يجعل كل معيار قابلاً للاختبار ويضيف الحالات السلبية. وفي ATDD تُستكمل معاً في ورشة المواصفات.
ما الفرق بين معايير القبول وحالات الاختبار؟
المعيار يذكر شرطاً يجب أن تستوفيه القصة، وحالة الاختبار فحص محدد له بشروط مسبقة ومدخلات ونتيجة متوقعة. والمعيار الواحد يحتاج في العادة إلى عدة حالات اختبار، مثل حالته الإيجابية وحالات الرفض وحدوده.
ما الفرق بين ATDD وBDD وTDD؟
الثلاثة تكتب الاختبارات قبل الشيفرة. يعمل TDD على مستوى الشيفرة: يكتب المطوّر اختبار وحدة يفشل، ثم الشيفرة التي تجعله ينجح، ثم يعيد هيكلة الشيفرة (Refactoring). ويشتق ATDD اختبارات القبول من معايير القبول مع الفريق كله قبل تنفيذ القصة. ويعبّر BDD عن السلوك المطلوب بأمثلة Given/When/Then بلغة طبيعية يقرؤها أصحاب المصلحة، وكثيراً ما تُشغَّل بأداة مثل Cucumber.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- Gherkin Reference — Cucumberصياغة Gherkin للمواصفات القابلة للتنفيذ: Feature وRule وScenario، وخطوات Given/When/Then، وBackground وScenario Outline وExamples.
- Behaviour-Driven Development — Cucumberالتطوير الموجّه بالسلوك (BDD) كثلاث ممارسات — الاكتشاف والصياغة والأتمتة — قائمة على أمثلة محددة يتفق عليها أهل الأعمال والفريق التقني.
تدرّب بأدوات متقن
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
حوّل قصة مستخدم (As a / I want / So that) إلى حالات اختبار منظّمة باستخدام القوالب والقواعد الاستدلالية.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
راجع معايير القبول من حيث قابلية الاختبار والاكتمال والغموض، مع اقتراحات صياغة معاد كتابتها من الذكاء الاصطناعي من متقن.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.