سؤال

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

  1. باستخدام الماوس، افتح قائمة الملف
  2. اختر "فتح ملف..." في قائمة الملفات
  3. في مربع حوار فتح الملف الذي يظهر، انتقل إلى x وانقر نقرًا مزدوجًا فوق المستند المسمى y

أو

  1. أظهر مربع حوار فتح الملف
  2. افتح الملف Y

أدرك الآن أن إحدى الإجابات ستكون على الأرجح "يعتمد الأمر على ما تحاول اختباره" ولكني أحاول الإجابة على سؤال أوسع هنا:إذا كانت خطوات الاختبار محددة جدًا، فهل نجازف أ) بجعل عملية الاختبار شاقة ومملة، والأهم من ذلك ب) هل نخاطر بفقدان شيء ما لأننا كتبنا مسارًا محددًا للغاية لتحقيق الهدف.وبدلاً من ذلك، إذا قمنا بتوسيع نطاقها، فهل نعتمد كثيرًا على أهواء المُختبر في ذلك الوقت ونفقد الاختبار الحاسم للمسارات الأكثر شيوعًا للعملاء/العملاء؟

هل كانت مفيدة؟

المحلول

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

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

إذا كانت هناك طرق متعددة لتحقيق الهدف، فأنت بحاجة إلى وصف كل مسار للوصول إلى هناك.

نصائح أخرى

أنا لست مختبرًا ولكن في رأيي من الضروري توثيق "مسار واجهة المستخدم" الذي يجب أن يسلكه الاختبار لتجنب أي ارتباك.

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

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

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

  • الأشخاص الذين يجرون الاختبارات غير قادرين على طرح الأسئلة عليك
  • الأشخاص الذين يقومون بإجراء الاختبارات ليسوا على دراية بمنتجك

يمكنك تجنب بعض التفاصيل إذا لم تكن هذه صحيحة.ومع ذلك، فإنه لا يزال يعتمد :)

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

ما تصفه أعلاه هو مجرد مجموعة من الاختبارات.

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

دعونا نميز بين خطة الاختبار وأجنحة الاختبار :)

مجموعة الاختبار عبارة عن مجموعة من الاختبارات نفسها

خطة الاختبار هي [جزء من] مجموعة الاختبار + الموارد المتاحة (الأشخاص، الأجهزة، الوقت، ...).

من المقبول أن يتم وصف كلا الخيارين (التفصيلي و"التقريبي") في وثائق الاختبار الخاصة بك، ما عليك سوى إجراء اختبارات تفصيلية و"تقريبية" على مستندات مختلفة وتحديد أولويات هذه المستندات.

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

جانب جيد:يمكنك تحديد كيفية اختبار المنتج

الجانب السيئ:أنت بحاجة إلى وثائق "مكررة".

من الجيد تمامًا أن تريد خطوات دقيقة ومفصلة ومتكررة عندما يجد شخص ما مشكلة.ولكن إذا قمت بكتابة خطط الاختبار الخاصة بك بهذه الطريقة، فسوف تخاطر بالمشاكل التالية:

1) العمى غير المقصود - لقد شاهدت أشخاصًا ينفذون نصًا تفصيليًا للاختبار الإجرائي، ويسيرون بإخلاص ويسجلون كل خطوة بدقة، ويفتقدون تمامًا الخطأ الصارخ الذي أمامهم.لأنه "لم يكن في النص".لقد كان اهتمامهم مركزًا جدًا على كل خطوات الاختبار الصعبة تلك لدرجة أنهم لم يتمكنوا حرفيًا من رؤية المشكلات التي أمامهم.

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

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

4) سينتهي بك الأمر بالكثير من التكرار، وسيكون من الصعب معرفة الهدف من الاختبار دون قراءة كل شيء.لن يكون من السهل إجراء فحص سريع للاختبارات لمعرفة حالات الاستخدام التي ربما فاتتك.

اجعل خطط الاختبار الخاصة بك واسعة النطاق واسمح للأشخاص الذين يقومون بالاختبار بممارسة حكمهم.إذا كانت لديك معلومات حول سيناريوهات استخدام محددة يجب اختبارها، أو حول كيفية عمل مجموعة المستخدمين المستهدفة، فقم بإعطاء هذه المعلومات للمختبرين أيضًا جنبًا إلى جنب مع خطط الاختبار - ربما في شكل شخصيات مستخدمين، وربما فقط في شكل حالات الاستخدام.إذا كنت بحاجة إلى تحديد أشياء محددة، ففكر في استخدام قائمة مرجعية.(لمزيد من المعلومات، راجع العرض التقديمي الممتاز الذي قدمه جيم كانرwww.kaner.com/pdfs/ValueOfChecklists.pdf).

وبدلاً من ذلك، اكتب خطط الاختبار الخاصة بك كمواثيق استكشافية قصيرة.يمكنك، على سبيل المثال، تقديم إرشادات مثل:"سيستخدم مستخدمو مركز الاتصال محطات العمل دون توصيل الماوس.استكشف عملية رفع تذكرة نيابة عن العميل، مع التأكد من إمكانية إكمال جميع الأنشطة باستخدام اختصارات لوحة المفاتيح فقط." من المرجح أن يؤدي ذلك إلى اكتشاف المختبرين للعيوب بدلاً من القول "انتقل إلى الحقل 1.أدخل "شكوى بشأن جودة الخط".علامة التبويب في الحقل 2.حدد "مكالمة هاتفية" من القائمة المنسدلة.علامة التبويب في ....الميدان 68."

هناك إيجابيات وسلبيات للتعامل مع المختبر الخاص بك كما لو أنهم ليس لديهم معرفة بالنظام أو أجهزة الكمبيوتر بشكل عام.

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

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

يمكن أن يكون من الاقتصاد الزائف التفكير في أنه أسرع إذا قمت بالإصدار السريع، إذا انتهى بك الأمر إلى قضاء وقت إضافي في شرح النظام للشخص المسؤول عن ضمان الجودة

لدي مقال أتعمق فيه أكثر حول هذا الموضوع: كتابة خطة اختبار النظام

في هذه المقالة، أفضّل النهج الأكثر تفصيلاً.لكنني قمت بتطوير "نقطة وسط" بين هذين النهجين مؤخرًا (تسمى أ ميزة خطة الاختبار)، لكنني لست في مرحلة حيث أنها ناضجة بما يكفي للمشاركة بعد

-- إل إم

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top