UAT Studioby Salvion
دليل

كتابة حالات اختبار يفهمها مختبِرو الأعمال

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

لـ مديري الاختبار والمستشارين والمستخدمين الرئيسيينقالب UAT مجاني في Excel
لماذا

لماذا يحتاج مختبِرو الأعمال إلى حالات اختبار مختلفة

يُجري اختبارَ النظام أشخاصٌ بنوا النظام أو يعرفونه جيدًا. أما اختبار قبول المستخدم فيُجريه أشخاص يستخدمونه: يعرفون العمل، لا الإعدادات. لا يعرفون أي حقل جديد، ولا أي تدفق يعمل في الخلفية، ولا ما قصده المطوّر.

لذا يجب أن تناسب حالة اختبار UAT شخصًا:

  • يعرف عملية الأعمال عن ظهر قلب، لكنه لا يعرف الشاشات الجديدة؛
  • لديه بضع ساعات بين أعمال أخرى، لا أسبوع كامل؛
  • لا ينبغي أن يضطر أبدًا إلى التخمين ما إذا كانت خطوة قد نجحت أم فشلت؛
  • سيتوقف وينتظر عندما تكون خطوة غير واضحة، ويضيّع الوقت.

كل ساعة تُقضى في كتابة حالات اختبار واضحة توفّر ساعات كثيرة في أيام الاختبار: أسئلة أقل، ومشكلات أقل يتبيّن أنها سوء فهم، ونتائج يمكنك الوثوق بها عند قرار go/no-go.

المصادر

من قصص المستخدمين والعمليات

تأتي حالات الاختبار من مصدرين، وتحتاج إلى كليهما.

قصص المستخدمين ومعايير قبولها

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

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

عمليات الأعمال، من البداية إلى النهاية

تُقسَّم قصص المستخدمين إلى أجزاء صغيرة من أجل المطوّرين. أما الأعمال فتعمل في عمليات تمتد عبر قصص كثيرة: lead to cash، وquote to order، وإدارة الحالات من البريد الإلكتروني حتى الحل. قد تنجح قصة بمفردها بينما تنكسر العملية عند التسليم بين فريقين.

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

في UAT Studioاقرأ قصص المستخدمين من Jira أو Azure DevOps في بطاقة User stories، وحدّد Only stories without test cases لرؤية الثغرات. مع وحدة AI test design، يقترح الذكاء الاصطناعي حالات اختبار من قصصك أو من وصف لعملية، وكذلك على النموذج الخاص بشركتك. لا يصبح أي شيء حالة اختبار حتى توافق عليه. وبدون الوحدة، يوفّر Prepare with your own AI موجّهًا (prompt) لتلصقه في الذكاء الاصطناعي لشركتك؛ والخطوات المعلَّمة بـ [CHECK] افتراضات يجب التحقق منها.

النطاق

هدف واحد لكل حالة اختبار

تختبر حالة الاختبار سيناريو أعمال واحدًا، بهدف واحد. ويقول عنوانها ما يحققه المختبِر، بكلمات الأعمال:

  • تحويل عميل محتمل لديه حساب موجود
  • الموافقة على عرض سعر بخصم يتجاوز 20%
  • توجيه بريد إلكتروني من عميل معروف إلى قائمة الانتظار الصحيحة

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

ما حجم حالة الاختبار الواحدة؟

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

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

الخطوات

خطوات بنتيجة متوقعة

لكل خطوة جزءان: إجراء (ما يفعله المختبِر) ونتيجة متوقعة (ما ينبغي أن يحدث). النتيجة المتوقعة هي ما يجعل الخطوة قابلة للاختبار. بدونها، يقرّر المختبِر ما هو جيد بما يكفي، ويقرّر مختبِران بشكل مختلف.

اكتب الإجراء

  • إجراء واحد لكل خطوة. افتح العميل المحتمل وانقر Convert مقبول؛ أما خمس نقرات في خطوة واحدة فلا.
  • ابدأ بفعل: افتح، انقر، املأ، اختر، احفظ.
  • استخدم التسميات كما تظهر على الشاشة، بخط عريض أو بين علامتي اقتباس.
  • قل ماذا، لا كيف يعمل النظام من الداخل. احفظ عرض السعر، لا شغّل تدفق الموافقة.

اكتب النتيجة المتوقعة

  • قل ما يراه المختبِر: رسالة، أو قيمة في حقل، أو سجلًا جديدًا، أو حالة.
  • كن محدّدًا. الفرصة في المرحلة Qualification، لا إنه يعمل.
  • اذكر ما لا ينبغي أن يحدث عندما يكون ذلك مهمًا: لا يُنشأ حساب ثانٍ.
  • للأمور التي يفعلها النظام بنفسه، قل أين ينظر المختبِر: تظهر الحالة في قائمة الانتظار Benelux Support خلال دقيقة.
البيانات والأشخاص

بيانات الاختبار والأدوار

بيانات الاختبار

يضيّع المختبِرون في البحث عن البيانات وقتًا أطول مما يضيّعونه في أي جزء آخر من UAT. ضع البيانات في حالة الاختبار حيثما كان ذلك مهمًا: أي عميل، وأي منتج، وأي قائمة أسعار أو دفتر أسعار، وأي مبلغ. جهّز تلك البيانات في بيئة الاختبار قبل يوم الاختبار الأول.

  • استخدم أسماء يتضح أنها بيانات اختبار، مثل Jansen Logistics (test).
  • امنح كل مختبِر سجلاته الخاصة عندما يغيّر البيانات، حتى لا يحرّر شخصان الفرصة نفسها.
  • أضف قيمًا عند الحدود: خصمًا أقل من الحد بقليل وأعلى منه بقليل، وحقلًا إلزاميًا فارغًا.
  • لا تستخدم بيانات شخصية حقيقية للعملاء حيثما أمكنك تجنّب ذلك.

الأدوار

في نظام CRM، يعتمد ما يستطيع المستخدم رؤيته وفعله على دوره: ملف تعريف (profile) ومجموعات أذونات (permission sets) في Salesforce، وأدوار أمان (security roles) ووحدة أعمال (business unit) في Dynamics 365. يُثبت UAT أن كل دور يستطيع أداء عمله، وعمله فقط. لذا تذكر كل حالة اختبار الدور الذي يختبرها، ويسجّل المختبِر الدخول بمستخدم اختبار له ذلك الدور بالضبط.

لا تختبر أبدًا بحساب مسؤول. فالمسؤول يرى كل شيء ويُسمح له بكل شيء، فتبقى المشكلات التي ينبغي أن يكتشفها UAT مخفية.

في UAT Studioلكل خطوة إجراء ونتيجة متوقعة وبيانات اختبار اختيارية. يحصل كل مختبِر على Test role وTest account، يظهران أعلى اختباراته بصيغة Log in as …، ويظهر الدور بجانب اسمه في كل مشكلة يسجّلها.

ما الذي يأتي أولًا

الأولوية والمخاطر

لا يوجد أبدًا وقت كافٍ لاختبار كل شيء بالجودة نفسها. صنّف كل حالة اختبار حتى تُختبر المهمة منها أولًا، وتكتمل حتى عندما ينفد الوقت.

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

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

كن صارمًا مع Must. عندما تكون نصف حالات الاختبار Must، تفقد التسمية معناها: احتفظ بها لما لا تستطيع الأعمال الاستغناء عنه. اتفق على الأولويات مع مالكي العمليات: فهم يقرّرون أيضًا في go/no-go، حيث تُحتسب حالات اختبار Must التي لم تنجح أكثر من غيرها.

في UAT Studioعيّن Priority (Must، Should، Could) وRisk (High، Medium، Low) في المحرّر أو في عمود عند الاستيراد. وتُقرأ أيضًا قيم الأدوات الأخرى: Critical وHigh تصبحان Must، وMedium وNormal تصبحان Should، وLow تصبح Could. يرى المختبِرون حالات اختبار Must الخاصة بهم أولًا، مع المخاطرة العالية أولًا ضمن كل أولوية.

مثال

مثال

حالة الاختبار 12: الموافقة على عرض سعر بخصم يتجاوز 20%

الأولوية Must، والمخاطرة High. قصة المستخدم CRM-118. الدور: مندوب المبيعات (الخطوات 1 إلى 3) ومدير المبيعات (الخطوتان 4 و5).

الخطوةActionالنتيجة المتوقعةبيانات الاختبار
1افتح الفرصة وأنشئ عرض سعر جديدًا.يُفتح عرض سعر مرتبط بالفرصة، مع منتجاتها.الفرصة Jansen Logistics – Support
2اضبط الخصم على 25% واحفظ.يُحفظ عرض السعر. ويظهر بالحالة Needs approval.الخصم 25%
3حاول إرسال عرض السعر إلى العميل.الإرسال غير ممكن. تقول رسالة إن عرض السعر يحتاج إلى موافقة.
4سجّل الدخول بصفة مدير المبيعات وافتح طلب الموافقة.يعرض الطلب عرض السعر والخصم ومندوب المبيعات.مستخدم الاختبار Sales manager Benelux
5وافق على الطلب.يظهر عرض السعر بالحالة Approved، ويتلقى مندوب المبيعات رسالة بريد إلكتروني.

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

تجنّب

الأخطاء الشائعة

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

اطلب من مستخدم رئيسي مراجعتها

قبل أيام الاختبار، اطلب من مستخدم رئيسي من الأعمال قراءة حالات الاختبار وتجربة اثنتين أو ثلاث منها في بيئة الاختبار. سيجد ما لا يستطيع الكاتب رؤيته: خطوة تفترض معرفة مسبقة، أو تسمية تغيّرت، أو عملية تجري بشكل مختلف في بلد آخر.

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

في UAT Studioاستورد حالات الاختبار من Excel أو Azure DevOps أو Jira مع Xray أو Zephyr Scale أو TestRail، أو اكتبها في المحرّر. وتضم مكتبة القوالب، وهي إضافة لكل باقة مدفوعة، سيناريوهات جاهزة لـ Salesforce وDynamics 365 لتعدّلها وفق إعداداتك.

ابدأ

مجاني الاستخدام

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

لكل ما يجب ترتيبه قبل UAT وأثناءه وبعده، اطّلع على قائمة تحقق UAT لإطلاق نظام CRM، المتاحة أيضًا كملف Excel مجاني.

امنح مختبِريك سيناريوهات يستطيعون اتباعها14 يومًا مجانًا، مع حالات الاختبار الخاصة بك.ابدأ تجربة مجانية لمدة 14 يومًا