Agile Test Strategy Template – قسمت اول

در محیط چابک یا agile، جایی که ما روی اسپرینت ها کار میکنیم، هر اسپرینت روی یک نیازمندی کوچک یا داستان کاربر تمرکز دارد بنابراین طبیعی است که ما مستندسازی وسیع نداشته باشیم چه از نظر تعداد و چه از نظر حجم مستندات. ممکن است ما نیازی به داشتن طرح های تست یا test plan وسیع و گسترده ای برای هر اسپرینت نداشته باشیم به خاطر محدودیت زمانی که وجود دارد اما نیازمند یک استراتژی تست چابک سطح بالا به عنوان یک راهنما برای اعضای تیم چابک، هستیم.

هدف استراتژی تست چابک این است که بهترین تمرینات یا practices و یک سری ساختار را در اختیار تیم قرار دهد تا آن را دنبال کنند. البته به یاد داشته باشید که چابک بدون ساختار نیست. در این مقاله یک نگاه مختصری به استراتژی تست چابک می کنیم.

یک استراتژی تست معمولا یک بیانیه ای دارد که مرتبط با اهداف و موضوعات کسب و کار های بزرگ امروزه می باشد. رایج ترین بیانیه در استراتژی تست می تواند این باشد که:

تحویل مداوم محصولی که نیازمندی های مشتری را پاسخ گو باشد

با استفاده از

فراهم کردن بازخوردهای سریع

و

پیشگیری از نقض به جای تشخیص نقض

انجام میگیرد

در استراتژی تست چابک، مفهومی به عنوان تضمین کیفیت یا QA وجود دارد که همه باید در مورد آن اطلاعاتی داشته باشند

  • QA یا تضمین کیفیت مجموعه فعالیت هایی است که تضمین می کند محصول نیازمندی های مشتری را برآورده کرده است به صورت اصولی و قابل اعتماد
  • در اسکرام QA وظیفه ی همه ی افراد می باشد نه فقط تست کننده ها. QA همه ی فعالیت هایی است که ما برای تضمین درستی کیفیت محصول در طول توسعه انجام می دهیم.

test level

شکل ۱ – مراحل تست

آزمون واحد

  • چرا: تضمین اینکه کد درست نوشته شده است یا مرحله توسعه به درستی انجام شده است
  • چه کسی: توسعه دهنده ها یا معماران فنی
  • چه چیزی: هر کد جدیدی به اضافه refactor کردن کدها و کدهای جاوا اسکریپت
  • چه زمانی: همان لحظه که کدی نوشته شد
  • کجا: توی خود پروژه و همچنین هنگام build پروژه به صورت خودکار
  • چگونه: با فریمورک های تست واحد و به صورت خودکار

 

تست سرویس یا API

  • چرا: تضمین ارتباط درست بین کامپوننت ها
  • چه کسی: توسعه دهنده ها یا معماران فنی
  • چه چیزی: وب سرویس جدید، کامپوننت ها، کنترلر ها و غیره
  • چه زمانی: هروقت API جدیدی نوشته و آماده شد
  • کجا: توی خود پروژه و همچنین هنگام build پروژه به صورت خودکار
  • چگونه: با Soap UI، Rest Client و به صورت خودکار

 

تست پذیرش یا Acceptance Testing

  • چرا: تضمین برآورده شدن نیاز مندی های مشتری
  • چه کسی: توسعه دهنده ها یا اعضای تضمین کیفیت محصول
  • چه چیزی: بررسی تست های پذیرش روی داستان های کاربر، بررسی ویژگی ها یا features
  • چه زمانی: هروقت ویژگی ای آماده و تست شده باشد
  • کجا: محیط تست خودکار
  • چگونه: به صورت خودکار (cucumber)

 

تست سیستم یا تست رگرسیون

  • چرا: تضمین درست کار کردن کل سیستم
  • چه کسی: صاحب محصول، تحلیلگر فنی، تیم تضمین کیفیت محصول
  • چه چیزی: تست سناریوها، تست امنیت سیستم، تست عملکرد سیستم
  • چه زمانی: هروقت تست پذیرش تکمیل شد
  • کجا: محیط تست
  • چگونه: تست اکتشافی خودکار(Automated Exploratory Testing)

کدی ممکن نیست نوشته شود برای یک داستان کاربر تا زمانی که

برای آن تست پذیرش تعریف کرده باشیم

تا همه تست های پذیرش پاس نشود

هیچ داستان کاربری تکمیل شده در نظر گرفته نمی شود

Product Backlog

خیلی از مواقع که پروژه ها با شکست مواجه می شوند به خاطر عدم آگاهی کامل از نیازمندی های محصول و یا درک های متفاوت اعضای تیم از نیازمندی ها می باشد. داستان های کاربر باید ساده، مختصر و بدون ابهام باشد. به عنوان یک راهنمای خوب، دنبال کردن مدل INVEST برای نوشتن داستان های کاربر بهترین روش است.

یک داستان کاربری معمولا باید ویژگی های زیر را داشته باشد:

  • Independent: مستقل باشد
  • Negotiable: قابل مذاکره باشد یعنی یک قرارداد خاصی برای ویژگی ها وجود نداشته باشد قراردادی که مورد قبول همه باشد
  • Valuable: ارزشمند باشد
  • Estimable: تخمین پذیر باشد
  • Small: کوچک باشد
  • Testable: تست پذیر باشد

 

غالب زیر برای نوشتن داستان های کاربر استفاده می شود:

As a [role]

I want [feature]

So that [benefit]

به این صورت که مثلا به عنوان کاربر مدیر میخواهم فلان کار را انجام دهم چونکه فلان مزیتی را به وجود می آورد. هیچ وقت بخش سوم را فراموش نکنید چون خیلی مهم هست یعنی بخش [benefit] چون با دیدن این بخش هرکسی متوجه می شود که چه ارزشی در این داستان کاربر به محصول افزوده خواهد شد.

ملاک پذیرش یا Acceptance Criteria

هر داستان کاربری باید شامل ملاک پذیرش باشد. این عنصر یعنی ملاک پذیرش به عنوان مهمترین عنصر برای تشویق ارتباط بین اعضای مختلف تیم می باشد همانطور که BDD اصرار زیادی روی ارتباط بین اعضای تیم دارد. ملاک پذیرش باید همان زمانی که داستان کاربر نوشته می شود مشخص شود. این را در نظر داشته باشید که ملاک پذیرش باید تست پذیر باشد.

هر ملاک پذیرش دارای یک یا چندین تست پذیرش است که به شکل زیر نوشته می شود( غالب Gherkin)

Scenario 1: Title

Given [context]

And [some more context]

When [event]

Then [outcome]

And [another outcome]…

عنوان سناریو را می نویسیم و بعد می گیم با این داده ای که داریم زمانی که فلان رویدادی رخ می دهد فلان خروجی خواهد داشت اگر خروجی به غیر از خروجی مورد نظر داده شود تست پذیرش شکست خورده و باید تغییراتی را اعمال کنیم تا تست پاس شود.

 

برای دنبال کردن مقالات و آموزش تست در تلگرام، عضو کانال زیر شوید:

ُSoftware Testing

مشترک خبرنامه شوید

  • RSS
  • Delicious
  • Digg
  • Facebook
  • Twitter
  • Linkedin
  • Youtube

نقش مدیر تضمین کیفیت

نقش مدیر تضمین کیفیت در چابک چیست؟ آیا ما واقعا ...

چگونه وارد کار تست ن

مثل همه ی کارها، کار تست نرم افزار و انتخاب ...

ابزارهای مفید برای ت

امروزه افراد زیادی هستند که از موبایل خود برای وبگردی ...

BDD Best Practice

معرفی BDD BDD یا توسعه رفتار محور یک متدولوژی است برای ...

Agile Test Strategy

در محیط چابک یا agile، جایی که ما روی اسپرینت ...