مقدمة في مثال رسم الخرائط

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

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

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



كيف يعمل؟


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

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

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

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

يمكن عادةً توضيح كل قاعدة مع العديد من حالات الاختبار . كل حالة اختبار لها ملصق أخضر خاص بها ، والذي يوضع تحت القاعدة المقابلة.

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

يستمر الاجتماع حتى يقتنع الجميع بأن القصة مفهومة تمامًا ، أو ينتهي الوقت المخصص لها.

ردود الفعل الفورية


في عملية مثل هذه المحادثة ، يتم بناء تمثيل مرئي للفهم الحالي للتاريخ بسهولة وسرعة.

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

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

فكر لفترة محدودة


يجب أن تصنع مجموعة من عدة أميغو قصة لائقة ومحترمة في حوالي 25 دقيقة .

إذا كنت غير قادر على تلبية الوقت المخصص ، فيمكنك عدة خيارات:

  • ما زلت تتعلم استخدام هذه الطريقة (هذا أمر طبيعي) ؛
  • قصتك كبيرة جدًا (لم يعد هذا جيدًا بالتأكيد) ؛
  • هناك الكثير من عدم اليقين في قصتك.

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

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

مصلحة


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

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

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

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

تبسيط التسجيل


لذلك ، بدلاً من استخدام البرامج النصية الرسمية لـ Gherkin ، حاول فقط تجميع قائمة من حالات الاختبار باستخدام اصطلاح التسمية.
على سبيل المثال:

  • حيث نسي العميل إيصاله ؛
  • حيث تم شراء المنتج منذ 15 يومًا.

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


إذا كانت النتيجة ("ثم") غير واضحة ، فلن يعمل المثال ، ولكن السؤال سيكون.

معروف غير معروف


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


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

من التجربة ، حتى هذا الجانب من أمثلة الخرائط يمكن أن يحول 3 اجتماعات Amigo من ممل إلى سريع ومنتج.

من يجب أن يشارك؟


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

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

إذن متى تكتب على غيركين؟


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

لكن وصف حالات الاختبار بهذه الطريقة يتطلب طريقة تفكير مختلفة. من الضروري ليس فقط تحديد الحالات التي تقع في المنطقة المعنية ، ووضع قواعد عامة لها.

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

كم مرة تفعل هذا؟


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

لكن لدي فريق موزع!


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

بعض النصائح النهائية


من المهم التمييز بوضوح بين القواعد وحالات الاختبار قبل استخدام تعيين المثال. هناك ممارسة ممتعة لهذا الغرض.

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

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

سوف نتحدث عن ممارسة 3 Amigo لوضع المتطلبات وبناء بطاقات اختبار الحالة في مؤتمر QualityConf . بالإضافة إلى ذلك ، تحتوي قائمة التقارير المقبولة على أساليب عملية أخرى مثيرة للاهتمام للغاية لإنشاء منتج عالي الجودة لتكنولوجيا المعلومات. سيعقد مؤتمر QualityConf لأول مرة كجزء من مهرجان RIT ++ يومي 27 و 28 مايو ، ولديه وقت للانضمام.

Source: https://habr.com/ru/post/ar450844/


All Articles