تم إتقان اختبار ضمان الجودة - برنامج تعليمي لتدفق المستخدم

نظرًا لأن المنتجات والخدمات تنتشر بشكل أسرع وأسرع ، يجب أن يتكيف ضمان الجودة (QA) مع البيئة المتطورة ، وأحيانًا يحقق نفس المستوى من التغطية في فترة زمنية أقصر. كيف نتجنب خطأ الكمية على الجودة ؟ كيف نغطي المزيد ونزيد الكفاءة ونبقى فعالين في عملنا؟

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

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

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

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

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

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

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

الذهاب مع التدفق

دون مزيد من التأخير ، دعنا نتعمق في إنشاء تدفق مستخدم لموقع مراسلة بسيط.

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

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

الشروط والدول والإجراءات

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

تحليل المتطلبات

هذه هي صفحتنا الرئيسية وهي الدولة. لدينا إجراءان محتملان: التسجيل وتسجيل الدخول.

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

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

لدينا الآن معلومات كافية لبدء تدفق المستخدم. دعونا نلخص ما لدينا. نلاحظ أسفل حالات المنتج. مما يمكننا رؤيته أربع صفحات:

1. الصفحة الرئيسية
2. نافذة تسجيل الدخول
3. نافذة التسجيل
4. لوحة القيادة

نكتب إجراءاتنا في كل صفحة / حالة يمكن "التفاعل" معها:

1. الصفحة الرئيسية
   1. تسجيل الدخول
   2. يسجل
2. نافذة تسجيل الدخول
   1. تسجيل الدخول
   2. يلغي
3. نافذة التسجيل
   1. يحدد لاحقًا (حسب المنتج)
4. لوحة القيادة
   1. خلق
   2. يحرر
   3. حذف

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

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

رسم مخطط التدفق

نستخلص ما ورد أعلاه في XMind لنبدو كما يلي:

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

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

ما ينقص تدفقنا هو تسميات. نعطي المنتج تسمية 0 ، لأن هذا هو جذر التدفق. بعد ذلك ، لكل حالة (زرقاء) ، نضيف تسمية S # ، لكل إجراء (أخضر) ، نضيف تسمية A # ، وأخيرًا ، لكل حالة (سماوي) ، نضيف تسمية C #. يجب أن تكون كل تسمية فريدة. ننتهي مع ما يلي:

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

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

ثم ، نافذة تسجيل الدخول:

ثم ، إجراء تسجيل الدخول:

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

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

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

إنشاء حالات الاختبار من التدفق

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

كل ما نقوم به الآن هو نسخ ولصق ما هو موجود في تدفقنا إلى أي أداة لإدارة حالة الاختبار أو موقع التقاء أو مستند Excel ترغب فيه. ما زلت أستخدم برنامج Excel القديم الجيد والموثوق. احتفظ بسجل لجميع حالات الاختبار الخاصة بي في ملف واحد يسمى "خط الأساس" - وهو أصلي للغاية. بمجرد أن أنتهي من نسخ اللصق ، ينتهي بي الأمر بما يلي:

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

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

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

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

نهج خطة الاختبار المبسط

إذن ماذا عن خطط الاختبار؟ يجب أن تفكر. هذا بسيط. تحتوي خطة الاختبار على أقسام مثل:

1. المقدمة والنطاق
2. عناصر الاختبار
3. الميزات المراد اختبارها
4. الميزات التي لا يجب اختبارها
5. الافتراضات
6. معايير الدخول
7. معايير الخروج
8. WBS
9. المخاطر
10. متطلبات البيئة

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

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

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

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

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

ماذا تعلمنا؟

سيساعدنا تدفق المستخدم بالنهج السابق وخطط الاختبار المبسطة لاستخدام الأدوات المتاحة اليوم على تقليل العمل المتكرر ومساعدة ضمان الجودة على تحقيق وقت استجابة أسرع دون التضحية بالجودة.

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

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