چکیده: جداول تصمیمگیری یا Decision Tableها برای تعامل بین ترکیبات مختلف شرایط استفاده میشوند. این جداول روش روشنی برای اعتبارسنجی تمامی ترکیبات شرط ها ارائه میدهند، تا بدین ترتیب اطمینان حاصل شود که تمامی شرایط ممکن، روابط و محدودیتها توسط نرم افزار تحت تست کنترل میشوند. اگر میخواهید مطمئن شوید که Test caseهای شما تمامی نتایج ممکن را پوشش میدهند، این مقاله را مطالعه کنید تا نحوه استفاده از جداول تصمیمگیری را بیاموزید.
فرض کنید به شما به عنوان یک تستر، یک سناریو میدهند و از شما میخواهند که Test Caseهای مورد نیاز سناریو را طراحی کنید، و مشتری فرآیند لاگین به برنامه خود را اینگونه شرح میدهد:
- کاربر شناسه کاربری خود را وارد میکند.
- سپس رمز ورود خود را درج میکند.
- اگر کاربر سه بار رمز را نادرست وارد کند، حساب قفل میشود.
شما با توجه به دانش خود در خصوص تکنیکهای تست Specification Based یا مبتنی بر مشخصات، بهترین روش طراحی Test Case برای این سناریو را چه میپندارید؟
بهتر است در چنین شرایطی استفاده از جداول تصمیمگیری را در تست خود لحاظ کنید. جداول تصمیمگیری به شما اجازه میدهند تا یک نمایش ساده، مختصر و البته گرافیکی از تعاملات احتمالی خلق کنید و اطلاعاتی را که برای ایجاد یک مجموعه Test Case موثر و کارا نیاز دارید را فراهم نمایید.
طراحی یک جدول تصمیمگیری
جداول تصمیمگیری برای نمایش تعامل بین ترکیبات مختلف شرایط(Condition) استفاده میشوند. این جداول روش روشنی را برای تست تمامی ترکیبات شرطها ارائه می دهند، تا بدین ترتیب اطمینان حاصل شود که تمامی شرایط ممکن، روابط و محدودیتها، توسط نرم افزار کنترل میشوند.
در ادامه، مثال لاگین کاربر که در بالا عنوان شد، برای اینکه نیازمندیها شفاف شوند شما باید اطلاعات ارائه شده در Use Case را دریافت کرده و به صورت تصویری نمایش دهید:
همانطور که ملاحظه میکنید برای این موضوع که تحت تست قرار دارد، چهار شرط بالقوه وجود دارد:
- شناسه معتبر است – بله یا خیر؟
- گذر واژه معتبر است – بله یا خیر؟
- سه بار گذر واژه نامعتبر وارد شده است – بله یا خیر؟
- دسترسی به سیستم مجاز است – بله یا خیر؟
برای تست هر یک از این تعاملات، جدول کامل تصمیم شامل شانزده ستون است:
اما طراحی این شانزده Test Case تنها مرحله اول است. یک لایه تکمیلی دیگر از بررسی تحلیلی لازم است تا به آنچه که به عنوان جدول تصمیم ریزش کرده(Collapsed Decision Table) شناخته می شود برسیم.
پالایش Test Caseها
زمانی که تلاش می کنید تا تمامی شرایط ترکیبی ممکن را تست کنید، جداول تصمیمگیری میتوانند بسیار بزرگ شوند. روش کاهش هوشمندانه تعداد ترکیبات از هر احتمال(به گونهای که) تنها باید آنهایی باقی بمانند که احتمال وقوع آنها منطقا وجود دارد. در این صورت به جداول خود تست Collapsed Decision Table گفته میشود.
در این تکنیک، ترکیبات کاهش مییابند و محدود می شوند به آنهایی که خروجیهای مختلفی تولید میکنند. این کار با حذف مجموعهای از شرایط اتفاق میافتد که مستقیما در تولید نتیجه دخیل نبوده و در حقیقت اصلا برای Test Result مهم نیستند. ما تستهای تکراری (redundant) یا تست هایی که ترکیب شرایط آن عملا ممکن نیست برای را حذف می کنیم.
با افزودن این لایه تکمیلیِ تحلیلی در پلن تست، تستر میتواند تستی موثرتر و کارآمدتر داشته باشد.
همانطور که در شکل قبلی دیدید شانزده ترکیب را شناسایی کردیم، اکنون میتوانیم با حذف شرایط تکراری و شرایط غیر ممکن آنها را کاهش دهیم.
اولین چیزی که توجه ما را جلب میکند، این است که چندین شرط وجود دارد که در آنها شناسه به صورت معتبر وارد نشده است. تبعا انتظار میرود با تمامی آنها به روش مشابه رفتار شود، زیرا سیستم همواره با ورود شناسه نامعتبر به طور مشابه برخورد میکند بدون توجه به اینکه رمز عبور وارد شده است یا خیر و یا چند بار شناسه نامعتبر وارد شده است.
شرایط فوق الذکر را در جدول تصمیمگیری خود با رنگ زرد نشان دادیم:
سپس، متوجه یک شرط غیرممکن میشویم که میتواند حذف شود: زمانی که گذر واژه صحیح وارد شد، احتمال نامعتبر بودن گذر واژه سوم وجود ندارد. در جدول، این ستون با رنگ آبی نشان داده شده است:
در اینجا یک شرط زائد دیگر هم وجود دارد. وقتی گذرواژه معتبر است و این سومین تلاش نیست، فقط یک Test Case برای پوشش آن شرط لازم است. در جدول رنگ این ستونها را سبز کرده ایم.
درنهایت، زمانی است که کاربر گذر واژه خود را برای بار سوم درست وارد میکند، در این سناریو هم تنها به یک Test Case نیاز است. این مورد آخر در جدول به رنگ بنفش نمایش داده شده است.
در نتیجه، همانطور که در شکل زیر مشخص است؛ ما برای این سناریو تنها به پنج Test Caseدر جدول تصمیمگیری ریزش کرده نیاز داریم.
این روش همچنین یک جدول تمیز، مرتب و گویا را تولید میکند که میتوانیم با مدیران و ذینفعان آن را به اشتراک بگذاریم تا به توضیح این مساله کمک کند که دلیل انتخاب این Test Caseها چیست و اینکه چطور تعداد Test Caseها کاهش مییابد تا تستی موثرتر و کارآمدتر ارائه شود.
یک خروجی نمونه را در شکل مشاهده می کنید. در این تصویر برای Conditionها(شرطهایی) که مثبت یا منفی بودنشان تغییر در نتیجه ایجاد نمیکند، علامت خط تیره(“-“) قرار دادیم:
در مثالی که مورد بررسی قرار گرفت، ما توانستیم تعداد Test Case ها را از ۱۶ مورد به ۵ مورد کاهش دهیم. تقریباً ۷۰ درصد کاهش! ین امر در شرایط واقعی نیز امکان پذیر است.
استفاده از جداول تصمیمگیری به طور عملی
در اوایل سال جاری، سناریوی پیچیدهای به من ارائه شد که ده شرط با یکدیگر تعامل داشتند. چالش من این بود که با هوشمندی آن صد Test Case را به تعداد معقول تری گلچین کنم کاهش دهم.
اولین کاری که من انجام دادم، ایجاد یک جدول تصمیمگیری کامل (Full Decision Table) بود ، درست مانند آنچه که ما در مثال بالا مرور کردیم. پس از آن، با توجه به نیازمندیها، ما توانستیم نیمی از ترکیبات Test Caseای را بلافاصله حذف کنیم زیرا آنها با کاربری که قبلاً در سیستم وارد شده بود سروکار داشتند و ما مجبور نبودیم شرایطی که پاسخ به این سوال “خیر” بود را در نظر بگیریم. بنابر این بلافاصله ۵۰ درصد ترکیب ها با کمی تجزیه و تحلیل کاهش یافت.
بعد از کار با شرکای تجاری و برنامه نویسان برای تعریف نیازمندیها و تفکر بیشتر درباره هرچه که میتوانم از شر آن خلاص شویم، توانستم Test Planای برای برنامه ایجاد کنم که فقط بیست و دو Test Case داشت، و این یعنی ۷۸ درصد کاهش.
جداول تصمیمگیری یک روش قدرتمند طراحی تست Specification Basedاست که میتواند برای انواع سناریوها مورد استفاده قرار گیرد. نمایش گرافیکی نیز مزیت بزرگی برای کار با سهامداران و اعضای غیر فنی تیم پروژه میباشد زیرا نمونهای گویاست که به راحتی توسط همه قابلفهم است.
گام بعدی را بر دارید و از مفاهیم توصیف شده برای کاهش ترکیبات احتمالی مختلف استفاده کنید، و جدول تصمیمگیری ریزش کرده خود را ایجاد کنید. به راحتی میتوان به مدیریت نشان داد که این روش تست تا چه حد موثر و کارآمد است.
استفاده از جداول تصمیمگیری همیشه آسان نیست، اما براساس تجربهام، نتایج حاصل از کار با این روش این موضوع را به من فهماند که این روش همیشه ارزش تلاش را دارد. این تکنیک را امتحان کنید تا فرایند طراحی تست شما کارآمدتر، موثرتر و درک پذیرتر باشد.