تیستن جامعه مهندسین تست نرمافزار ایران
نوشته های مرتبط
چکیده: استفاده از تکنیک‌های طراحی تست یک رسم و قاعده پدیرفته شده برای تولید Test Caseهاست. اما اینکه در چه شرایطی از چه تکنیکی استفاده کنیم، موضوعیست که پاسخ اشتباه به آن می‌تواند هزینه‌های گزافی به شما، تیم تست، شرکت متبوع و مشتری تحمیل کند.
در این مقاله می‌خواهیم مشخص کنیم، برای طراحی تست باید از چه تکنیک‌هایی استفاده کرد.
قبل از هر چیز لازم است دو واژه “طراحی تست” و “تکنیک” را تشریح کنیم.
- طراحی تست چیست؟
اول از همه باید بدانیم که طراحی تست یا همان Test Design یکی از مراحل موجود در فرآیند تست است، که شخصا معتقدم بعد از Test Planning و Test Monitoring & Control که از وظایف مدیر تست است، سومین مرحله مهم در فرآیند تست محسوب می‌شود. چرا که در این نقطه است که Test Caseها استخراج می‌شوند، و عمده کیفیت(نه تمام کیفیت) تست به کیفیت Test Caseهای خروجی از این مرحله وابستگی مستقیم دارد. البته این مرحله از فرآیند، خروجی‌های دیگری نیز دارد، اما شاید هیچ یک به اهمیت Test Caseها و شناسایی داده‌های قابل درج در Test Caseها نباشند.
طراحی تست به معنی تعیین چگونگی انجام تست‌هاست. من معمولا برای آشنایی چند مثال دم دستی دارم، که از آنها استفاده می‌کنم. فرض کنید قرار است لاگین کردن را تست کنیم. اگر قرار به چنین تستی باشد باید چگونه این کار را انجام دهیم؟ پاسخ‌های این سوال، همان Test Caseهای ما هستند. ما می‌توانیم چند Test Case فرضی زیر را برای پاسخ به این سوال در نظر بگیریم:
- لاگین موفق با ورود صحیح همه اطلاعات مشتمل بر Username، Password و …
- لاگین ناموفق با ثبت صرفا User Name نادرست(باقی اطلاعات باید به درستی درج شوند)
- لاگین ناموفق با ثبت صرفا Password نادرست(باقی اطلاعات باید به درستی درج شوند)
- لاگین ناموفق با ثبت صرفا Captcha نادرست(باقی اطلاعات باید به درستی درج شوند)
- لاگین ناموفق به دلیل Inactive بودن کاربر(باقی اطلاعات باید به درستی درج شوند)
- لاگین ناموفق به دلیل اقدام به لاگین از IP نامعتبر(باقی اطلاعات باید به درستی درج شوند)
اکنون با شش Test Case طرف هستیم، که یک مورد چگونگی لاگین موفق را ترسیم کرده و پنج مورد دیگر چگونگی لاگین ناموفق را بیان می‌کنند.
البته خود Test Case دارای مراحلیست که در اینجا به منظور تقریب ذهنی، صرفا عنوان Test Case را با کمی توضیحِ مندرج در پرانتز ارائه کرده‌ایم.
- تکنیک چیست؟
فارق از اینکه مفهوم تکنیک در تست مطرح می‌شود، یا جای دیگر، تکنیک یک معنی واحد در همه حوزه‌ها دارد، که ترجیح می‌دهم یک تعریف ساده از آن ارائه دهم. تکنیک یعنی: “شیوه خاصی در انجام یک کار برای رسیدن به یک هدف معین، آنچنانکه هزینه انجام کار را کاسته و بازده آنرا افزایش دهد”.
مثلا یک فوتبالیست، با هدف رساندن توپ به نزدیک دروازه به جای درگیر شدن فیزیکی با بازیکن حریف که هم ممکن است خطا باشد، و هم اینکه توپ را از دست بدهد، با یک دریبل که تکنیک فردی محسوب می‌شود، در کسری از ثانیه بدون درگیری فیزیکی با بازیکن حریف او را جا می‌گذارد.
یا مثلا در یک مبارزه تن به تن با دشمن به جای اینکه سلاح سرد را بی هدف بالای سر بچرخانیم، و مرتب با آن حملات بی نظمی را انجام می‌دهیم، می‌توانیم با هنرهای رزمی حتی بدون سلاح طرف مقابل را از پا دربیاوریم. این یعنی انجام مبارزه با هدف نابودی دشمن با کمترین هزینه و بیشترین بازده.
یک نمونه دیگر؛ مثلا در حساب دیفرانسیل شما می‌توانید برای پهنه عظیمی از توابع ریاضی که نیاز به حدگیری(Limit) از آنها دارید، از قاعده هوپیتال(لوپیتال) استفاده کنید. این تکنیک به شما کمک می‌کند، در کمترین زمان و حصول بیشترین بازده، به سرعت پاسخ Limit f(x) را بیابید.
اما همین تکنیک‌ها محدودیت‌هایی هم دارند! یعنی هر جایی نمی‌توان از آنها استفاده کرد.
مثلا در فوتبال یک تکنیک برای دریبل مدافع حریف، لایی انداختن به اوست. حالا اگر مدافعی داشته باشیم، که لایی او همیشه بست هاست، باید چه کنیم؟ آیا باید توپ را تقدیم وی کنیم، یا از تکنیک دیگری برای جا گذاشتن او استفاده کنیم؟
یا مثلا در توابع ریاضی که پیشتر در مورد آن صحبت کردیم، گاهی اوقات نمی‌توانید از قاعده هوپیتال برای حدگیری استفاده کنید. در برخی از توابع وقتی از این قاعده برای حدگیری استفاده می‌کنید، خروجی این تکنیک تابعی پیچیده‌تر است، که شما را به خاطر استفاده از تکنیک هوپیتال، پشیمان می‌کند.
استفاده از تکنیک و درک محدودیت‌های آن در انجام هر کاری چه ورزشی، چه ریاضی، و چه هر زمینه دیگری به منظور حصول نتایج با کیفیت ضروریست. اگر در انجام امور از تکنیک‌های مشخص و البته به جا، در آن حوزه بهره نگیرید، یکی یا چند مورد مورد مضر، از لیست زیر بروز می‌کند:
- از دست دادن زمان
- نرسیدن به هدف
- رسیدن به هدف به صورت ناقص
- رسیدن به هدف با صرف هزینه زیاد
تست نرمافزار هم از این قاعده مستثنی نیست. شما در طراحی تست نرمافزار هم، نیازمند بهره‌گیری از تکنیک‌های مختلف هستید.
- تکنیک طراحی تست چیست؟
مرحله طراحی تست خروجی‌های متفاوتی دارد، اما مهمترین آنها Test Case و نوع داده‌هاییست که برای تزریق به این Test Caseها شناسایی می‌شوند. برای طراحی Test Caseهای با کیفیت که شما را به صورت کامل و در کمترین زمان به هدف نائل کنند، تکنیک‌هایی وجود دارد.
- تکنیک طراحی تست را به جا استفاده کنیم!
حدود ۴۰ تکنیک برای طراحی تست وجود دارد، که معمولا برای اثربخشی بهتر با هم ترکیب می‌شوند. حدود ۱۵ تکنیک از مجموع ۴۰ تکنیک، موارد عمومی هستند، که تقریبا در همه سیستم‌ها کاربرد دارند. مابقی معمولا یا برای شرایط بسیار خاص به کار می‌آیند و یا برای طراحی تست‌هایی که در زمان اجرای عملیات‌های ماشینی استفاده می‌شود کاربرد دارد. مثلا برخی از این تکنیک‌ها توسط کامپایلر استفاده می‌شود، که صحت منطقی بودن کد را تائید می‌کنند.
معمولا ما با همان حدود ۱۵ تکنیک کار داریم. این تکنیک‌ها درست مانند موضوع دریبل زدن، در جای خاصی به کار می‌آیند. گاهی اوقات می‌بینم که دانش‌پژوهان اصرار دارند در یک کلاس خاص که موضوع تدریس آن آموزش یک تکنیک است ثبت نام کنند. گاهی اوقات بعد از درک شرایطی که در آن قرار گرفته‌اند، مجبورم تا ۴۵ دقیقه با آنها صحبت کنم، و این عزیزان را روشن کنم، که این تکنیک در شرایط فعلی به کارشان نمی‌آید.
قبل از اینکه Test Caseهای خود را به کمک یک یا چند تکنیک طراحی کنید، ابتدا باید شرایطی که در آن قرار گرفته‌اید را به انضمام محدودیت‌های حاکم بر وضعیت پروژه و محصول آنالیز کنید، تا بتوانید تکنیک‌های مورد نیاز خود را مشخص کنید. هر چند این مسئولیت و تعیین تکنیک‌های مورد استفاده برای طراحی تست از وظایف مدیر تست یا شخصی با این جایگاه است، اما در بسیاری از تیم‌ها که به درست یا غلط مدیر تست وجود ندارد، از روی ناچاری این وظیفه به تسترها محول می‌شود.
به هر حال چه این کار توسط تستر انجام شود، و چه مدیر تست، از قواعد یکسانی بهره می‌گیرد.
سوالاتی که باید برای تحلیل شرایط خود روی آنها تمرکز کرده، و به آنها پاسخ دهید، شامل موارد ذیل است. پاسخ به این سوالات شما را به سمت تکنیک‌های خاصی سوق می‌دهد:
- آیا مشتری نظر خاصی درباره استفاده از یک تکنیک خاص برای طراحی تست‌ها داشته است؟
- نوع تستی که قرار است انجام دهید چیست؟(مثلا Functional، Non-Functional، Structural و …)
- مدت زمان مجاز شما برای طراحی تست کوتاه است یا بلند؟
- مدت زمان مجاز شما برای اجرای تست کوتاه است یا بلند؟
- اگر مدت زمان مجاز شما برای تست زیاد باشد، آیا شرکت متبوعتان هم تحمل صرف چنین مقدار زمانی را دارد؟
- میزان حساسیت و Criticality سیستم(که منجر به افزایش یا کاهش دقت در طراحی و اجرای تست می‌شود) زیاد است یا کم؟
- آیا اسنادِ به روزی که بتوان از آنها به عنوان مرجعی برای طراحی انواع تست استفاده کرد وجود دارد؟(مانند سند معماری، یا سند تحلیلی و یا …)
- آیا به جز اسناد دارای منابع دیگری مانند دانش ضمنی افراد مختلف هستید یا خیر؟ سطح اطلاعاتی که می‌توانید کسب کنید چقدر است؟
- میزان توانی که نیروهای شما علاوه بر باقی مشغله‌ها می‌توانند روی طراحی تست بگذارند زیاد است یا کم؟
- آیا تسترهای مستقل مسئولیت تست را دارند، یا Developerها مشغول به این کار می‌شوند؟
- میزان تبحری که نیروهای شما در به کارگیری تک تک تکنیک‌ها دارند چقدر است؟
و البته در شرایط خاصتر، ممکن است سوالات بیشتری هم مطرح شود.
- دو مثال متضاد
- مثال ۱: فرض کنید شما در یک تیم Agile(بماند که اکثر تیم‌های مدعی Agile، فقط اسما Agile هستند) مسئولیت تست را به عهده دارید. با مشخص شدن همین موضوع که تیم شما Agile است، تعدادی از سوالات بالا پاسخ می‌گیرد. ۱- تیم شما از منظر Documentation فقیر، اما از جهت ارتباطات درون تیمی قویست. ۲- شما زمان زیادی برای طراحی و اجرای تست‌ها ندارید. این پاسخ‌های به ما می‌گوید، منطقا امکان استفاده از تکنیک‌های Black Box که وابستگی زیای به Document دارند مقدور نیست. ایضا استفاده از تکنیک‌های زمانبر، مانند بهره‌گیری از تکنیک‌های Model Based مقدور نیست. بهتر است شما سراغ تکنیک‌های Experience یا همان تکنیک‌های تجربی بروید. ولی بدانید دقت این تکنیک‌ها، پایین، اما سرعت طراحی توسط آنها و اجرای Test Caseهای طراحی شده با آنها بالاست. بعلاوه نیازمند بهره‌گیری از اسناد، به منظور طراحی تست نیز نمی‌باشند.
- مثال ۲: فرض کنید شما تستر یک سیستم با Criticality بالا مثلا سیستم مدیریت Railway(این سیستم یک سیستم Safety Critical است) هستید. چنین سیستمی به دلیل حساسیت بالایی که دارد، الزاما باید دارای اسناد دقیق و گوناگونی باشد. این سیستم باید مشمول دقیقترین تست‌ها شود. بنابراین ناچارید برای آن زمان باز کرده و بودجه مناسبی اختصاص دهید. ایضا، معقول نیست که در مدیریت پروژه یا تولید از شیوه‌های Agile استفاده کنید. بنابراین استفاده از تکنیک‌های موجود در Categoryهای Black Box و White Box پیشنهاد مناسبیت. البته این موضوع منافی استفاده از تکنیک‌های Experience نیست. شما می‌توانید برای این سیستم، اسناد Use Caseها را به عنوان Test Basis در نظر گرفته و با رویکرد Path Based از تکنیک Use Case Testing که نوعی تکنیک Model Based است بهره بگیرید. طراحی و اجرای تست‌ها در این حالت زمان زیادی را صرف می‌کند.
همانطور که می‌بینید، در مثال اول ما به ناچار، ملزم به عدم استفاده از تکنیک‌هایی بودیم، که در مثال دوم بر الزام بهره‌گیری از آنها تاکید شده بود.
- سخن آخر
این مقاله به ما گوشزد می‌کند:
- اگر یک تکنیک بلد هستید، اصرار نکنید که آنرا در همه جا استفاده کنید. این کار می‌تواند ضرر سنگینی به شما، تیم تست، شرکت متبوع و مشتری‌تان وارد کند.
- قبل از اینکه از تکنیک خاصی بهره بگیرید، ابتدا شرایط و محدودیت‌های پروژه و محصول را بررسی کنید، و به سوالات مطروحه در بخش ۴ به درستی پاسخ دهید.
- بعد از پاسخگویی به سوالات، تکنیک‌های خود را انتخاب کنید. اما قبل از انتخاب تکنیک، لازم است تکنیک‌های تست و محدودیت‌های هر یک را به خوبی بشناسید. اگر چنین شناختی داشتید، آنگاه می‌توانید بر اساس پاسخی که به سوالات داده‌اید، تکنیک یا تکنیک‌های خود را انتخاب نمایید. الزامی بر استفاده از یک تکنیک وجود ندارد، و شما می‌توانید چند تکنیک را در کنار هم استفاده کنید، و یا مانند یک فوتبالیست که از ممکن است از دریبل ترکیبی استفاده کند، شما هم قادرید به منظور افزایش بهره‌وری چندین تکنیک را تلفیق کنید.
