تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: تست تجربی یکی از محبوبترین دسته تکنیک‌های تست نرم‌افزار است، که غالبا با بی نظمی پیش می‌رود، آنچنانکه می‌توان آنرا مانند یک لامپ رشته‌ای تصور کرد، که انرژی زیادی مصرف می‌کند، اما بازده بسیار پایینی دارد. در این مقاله می‌خواهیم بیان کنیم که چگونه این لامپ رشته‌ای را با کمترین تغییرات به یک لامپ بسیار پربازده تغییر دهیم. ابزار این کار می‌تواند ابزارهای Test Management و یا یک شیت ساده اکسل باشد.
تست تجربی یا Experience Testing یکی از سه گزینه برای دسته‌بندی تکنیک‌های تست نرم‌افزار است، که خود شامل چندین تکنیک برای اجرای تست می‌باشد. معمول اوقات تسترهای تجربی به دلیل شناختی که از ابعاد مختلف پروژه و محصول خود دارند، با استفاده از تکنیک Error Guessing، تست را انجام می‌دهند. در این روش تستر بر اساس جمیع تجربیات و دانش خود، یک نقطه ریسکی که مستعد ایراد است را نشان کرده و سپس با Test Case غیر مکتوبی که به صورت سریع در ذهن خود طراحی می‌نماید، شروع به آزمودن سیستم برای استخراج ایراد فرضی می‌نماید. این روش تقریبا در اکثر شرکت‌های ایرانی و غیرایرانی جهت طراحی تست‌های سریع انجام می‌شود.
طبیعیست که تسترها به مرور زمان تجربه بیشتری پیدا می‌کنند، و تست‌های بهتر و عمیقتری طراحی می‌کنند. اما به دلیل اینکه تست‌ها مکتوب نمی‌شود، معمولا شش ایراد عمده بروز می‌کند:
- اگر تستر تجربی به هر دلیلی امکان ادامه فعالیت خود را نداشته باشد، حجم زیادی از دانش تست در شرکت به سادگی از دست می‌رود.
- همیشه نیروهای تازه کار باید مدتی را در سردرگمی طی کنند، و علاوه بر آن دوباره چرخ را اختراع کنند. یعنی آنها نیز باید با صرف زمان و هزینه زیاد، در نهایت پس از چند سال به نقطه‌ای برسند که تسترهای با تجربه‌تر در آن نقطه هستند.
- کیفیت تست‌های انجام شده میان یک فرد با تجربه و کم تجربه تفاوت فاحشی با هم خواهند داشت، و این نشات گرفته از میزان تجربه این افراد است.
- درجه اطمینان به این سبک تست معمولا پایین است، چون همه چیز در لحظۀ تست به هوش و حواس تستر باز می‌گردد. مثلا چه می‌شود اگر تستر یک بخش را برای تست کردن فراموش کند؟
- مدیران سطح بالا نمی‌توانند تصور درستی از نقاط ریسکی سیستم به دست آورند، تا برنامه‌ای برای کاهش ریسک آن بچینند. و معمولا بر مبنای گزارشات پراکنده تسترها، یک تصور حدودی دارند.
- در شرایط فورس عملیاتی نقاطی که باید به دلیل ریسکی بودن روی آن تمرکز کرد، کاملا به غریزه تستر وابسته است، که می‌تواند گاهی اوقات اشتباه از آب در آید.
البته این روش مزایای مهمی نیز دارد از جمله:
- ارزان بودن
- سریع بودن
- انعطاف در اجرا به دلیل پیروی نکردن از قواعد خاص
مزایای این روش واقعا قابل چشمپوشی نیست. البته ایرادات آن نیز بسیار آزار دهنده است.
اما آیا می‌توان این ایرادات را تا حدی مرتفع نمود، تا این روش تبدیل به یک روش کم ریسک شود.
بی نظمی، لحظه‌ای بودن، و فرد محور بودن در تست مبتنی بر تجربه مانند یک لامپ رشته‌ایست، که انرژی زیادی مصرف می‌کند، اما بازده بسیار پایینی دارد. در این مقاله می‌خواهیم بیان کنیم چگونه این لامپ رشته‌ای را با تغییرات کمی به یک لامپ پربازده تبدیل کنیم. ما سعی داریم روشی را آموزش دهیم که این دست از تکنیک‌های Test Design را تا حد زیادی بهبود می‌دهد. هر چند ماهیت Experience آنرا نیز تغییر داده و به سمت Black Box سوق خواهد داد، اما چنین عناوینی برای ما اهمیت ندارد، بلکه نتیجه عملیات برای ما تعیین کننده است. روش مندرج در اینجا مقداری از ارزان بودن، و سریع بودن این روش می‌کاهد، اما به دو دلیل این موضوع قابل چشمپوشیست:
- میزان تغییر در روال تجربی سابق تقریبا ناچیز است، آنچنانکه کاهش سرعت و افزایش هزینه چشمگیری را در پی نخواهد داشت.
- با گذشت چند ماه این روش ثمر می‌دهد.
ایجاد لیست جاری تست با مکتوب‌سازیِ خلاصه
اولین موضوع این است که باید تست‌ها را به شیوه‌ای خلاصه، در یک لیست مکتوب نمود. ما به این لیست، “لیست جاری” می‌گوییم. لیست جاری در حقیقت مجموع تست‌هاییست که اکنون در حال اجرای آنها هستید.
برای مکتوب‌سازی تست‌ها به صورت موجز، باید ۶ بخش متنی با عناوین و اهداف زیر داشت:
- عنوان: یک متن یکتا که مبین امکان و عملیات انجام شده یا اصطلاحا Functionality ما باشد. این متن، عنوان تست ما نیز هست.
- آدرس ورودی: چگونه به فرم یا صفحه محل تست برسیم. در صورتیکه قرار است چند آدرس ورود را در یک خط بنویسید. هر آدرس را با یک علامت مشخص مانند $ یا – از دیگران جدا کنید.(ترجیحا اگر از مسیرهای ورود مختلفی استفاده می‌کنید برای هر مسیر یک سطر در نظر بگیرید. این حالت در جدولی که پیرو این مطلب ارائه می‌گردد، به تصویر در آمده است)
- تگ‌ها: بخشی که کلیدواژه‌های مرتبط با تست در آن ارائه شده است و تگ‌های مختلف با $ یا – از هم جدا می‌شوند.
- شرح: در صورتیکه قرار است شرح را در یک خط بنویسید، سه بخش b ،a و c را با یک علامت مشخص مانند $ یا – از هم جدا کنید.
- پیشنیاز: چه چیزهایی باید قبل از اجرای تست فراهم شود.
- روال: یک توضیح خلاصه از کاری که قرار اسا انجام شود، داده‌هایی که باید درج شود، و نتیجه‌ای که گرفته خواهد شد. بهتر است داده‌ها نیز نوشته شوند. برای نوشتن داده‌ها عنوان فیلد را بنویسید و نوشتن مقدار فیلد خودداری کنید. مثلا اگر عنوان فلید نام است فقط بنویسید “نام”. لزومی به نوشتن مقدار آن یعنی مثلا “ابوالفضل خواجه دیزجی” وجود ندارد. برای فیلدها از نماد @ استفاده نمایید.
- پسنیاز: اقداماتی که باید پس از اجرای تست انجام شود.
- نارسایی‌ها: به صورت عامیانه لیست انواع باگ‌هایی که ممکن است برای این تست مشاهده کنید. البته معمولا این ستون حداکثر شامل یک باگ است. هر نارسایی را با یک علامت مشخص مانند $ یا – از دیگران جدا کنید.
- توصیه: در این قسمت می‌توانید توصیه‌های مختلف خود را برای اجرای تست بنویسید. در صورتیکه قرار است چند توصیه را در یک خط بنویسید. هر توصیه را با یک علامت مشخص مانند $ یا – از دیگران جدا کنید. در صورتیکه توصیه ای وجود ندارد در این قسمت بنویسید”ندارد”.
یک نمونه مثالی را که ویژه یک فروشگاه الکترونیکیست در پایین ببینید:
لیست جاری می‌تواند شامل صدها سطر به همین ترتیب باشد. خیلی خودتان را در زمان نوشتن شرح اذیت نکنید. اگر خواستید، قالب ویژه خود را برای نوشتن انتخاب کنید. فقط به یک نکته دقت کنید که هر سطر از لیست، صرفا برای تست کردن یک Business Rule باشد، و نه بیشتر از آن. البته ممکن است یک Business Rule در چند سطر(مثلا به دلیل ادرس ورودی متفاوت) برای تست ذکر شود. ضمنا سعی کنید آنچه که می‌نویسید برای دیگر تسترها قابل درک باشد. برای این منظور از افرادیکه به عنوان تستر مشغول هستند، و ایضا با بخش تست شده توسط شما آشنایی ندارند بخواهید، یک بار از روی سطرهای مکتوب شما در جدول، عملیات تست را انجام دهند. اگر آنها موفق به انجام این امر بشوند، بدین معنیست که سند شما گویاست.
ایجاد لیست تجمیعی
شما دائما در حال تست هستید، و این عملیات را به صورت اسپرینت به اسپرینت، ریلیز به ریلیز، Iteration به Iteration، دائم و یا به صورت بی نظم، در قالب لیست جاری انجام می‌دهید. به هر حال یک چیز مشخص است، و آن این است که شما باید یک لیست جاری داشته باشید. یک کار فوق العاده مهم این است که هر تستی را که انجام می‌دهید فراموش نکنید. برای این کار باید هر تستی که انجام می‌شود در یک “لیست تجمیعی” ثبت شود. لیست تجمیعی مانند لیست جاریست که البته مقداری توسعه یافته است. در این لیست ستون‌های دیگری بدین شرح اضافه می‌شوند:
- تعداد اجرا: مبین این است که تست مشروح در آن سطر، تا کنون چند بار انجام شده است. هر باری که این تست انجام شود(حتی زمانیکه به دلیل Failهای متوالی، به صورت پینگ پنگی بین کدنویس و تستر تبادل می‌شود)، به عدد موجود در این ستون، برای آن تست خاص، یک واحد افزوده می‌شود.
- تعداد Fail: هر بار که تست Fail می‌شود، به عدد موجود در این ستون، برای آن تست خاص، یک واحد افزوده می‌شود.
- درصد Fail: تعداد Fail تقسیم بر تعداد اجرا ضرب در ۱۰۰
- منسوخ شده: در صورتیکه تستی به دلیل تغییر Business یا نغییر دیگری که امکان اجرای تست را منتفی کند، قابل اجرا نباشد، آنگاه این ستون، برای آن تست خاص علامت می‌خورد. به این ترتیب تاریخچه اجرای تمام تست‌ها(حتی موارد منسوخ شده) حفظ می‌شود.
اما شیوه ثبت بدین شکل است:
- اگر تستی که در لیست جاری انجام داده‌اید، تا قبل از این انجام نشده بود، فورا آنرا به لیست تجمیعی منتقل کنید. این یک تست جدید است. منظور از تست جدید تستی نیست که قبلا با داده‌های دیگر تست شده است، و اکنون صرفا داده تستی آن تغییر کرده است. بلکه تست جدید، تستیست که دارای مراحل متفاوتی می‌باشد، و رسما یک تست جدید محسوب شود. تعداد اجرا(برابر با یک)، تعداد Fail(برابر با صفر یا یک) و درصد Fail(برابر با صفر یا صد) را نیز برای این تست ثبت نمایید.
- اگر تستی که در لیست جاری انجام داده‌اید، قبلا هم انجام شده بود و برای آن سطری در لیست تجمیعی داشتید، صرفا باید یک به روز رسانی روی تعداد اجرا، تعداد Fail و درصد Fail انجام شود. اگر توصیه جدیدی نیز در اجرای جدید مد نظر است باید به ستون توصیه برای آن تست افزوده شود.
تصویر لیست تجمیعی به این ترتیب خواهد بود.
شیوه پیاده‌سازی
ابزار این کار می‌تواند ابزارهای Test Management و یا یک شیت ساده اکسل باشد.
اگر قرار باشد این کار با ابزار انجام شود، آن ابزار باید بتواند به طریقی چنین فیلدهایی را فراهم آورده، و قابلیت به رزورسانی تعدد اجرا و محاسبه درصد را داشته باشد. در چنین شرایطی حتما استفاده از ابزار پیشنهاد می‌شود.
اما اگر قرار باشد، این کار در یک شیت اکسل انجام شود، باید هر کسی شیت مخصوص خود را داشته باشد، و آنرا به صورت Read Only در جایی که در اختیار دیگر تسترها یا توسعه دهندگان باشد، بارگذاری نماید. البته تجمیع تمام این لیست‌ها برای مدیر تست کار مشکلی خواهد بود.
مزایای انکارناپذیر
مزایای این رویکرد غیرقابل انکار است:
- انتقال تجربه تست با کمترین هزینه به نیروهای تازه وارد.
- یک آنالیز سریع روی نقاط ریسکی که بر اثر درصد Fail و تعداد اجرا سنجیده می‌شود. هر چقدر حاصلضرب “تعداد اجرا” در “درصد Fail” عدد بزرگتری باشد، ریسک Fail شدن آن تست بیشتر خواهد شد. این اطلاعات برای مدیر تست که قصد برنامه‌ریزی روی تست را دارد، بسیار حائز اهمیت است.
- اگر در زمان تست تجربی، این روش به صورت مجدانه اجرایی شود، با گذشت ۶ ماه تا حداکثر یک سال، شما تقریبا اکثر تست‌های متوسط تا مهم را در لیست تجمیعی خود گرد آورده‌اید. این یعنی شما خوراک اولیه برای اتوماسیون تست را دارید.
