تست جوئل قسمت چهارم: bug tracker
تست چهارم جوئل: آیا بانک اطلاعاتی از اشکالات (bugs) دارید؟
رفع باگ‌های نرم‌افزار که در کار نرم‌افزار اجتناب ناپذیر هستند بخش مهمی از پروسه تولید نرم‌افزار را شامل می‌شود. گام اول در جهت کار رفع باگ‌های نرم‌افزار پیدا کردن باگ‌هاست که از روش‌های مختلفی می‌توان برای آن استفاده کرد. آخرین روش البته باید این باشد که از مشتری بخواهید باگ‌های نرم‌افزار را گزارش کند. باگ‌های عمده را باید بتوان با استفاده از تست اتوماتیک یا تست نرم‌افزار توسط انسان پیدا کرد و بخش دیگری از باگ‌ها هم مثلاً در نسخه بتا نرم‌افزار و پیش از عرضه نهایی پیدا خواهند شد.
گام دوم بعد از پیدا کردن باگ‌ها رفع آن‌ها نیست، ثبت آن‌هاست! جوئل در این مورد این‌طور توضیح می‌دهد:
اگر حتی در یک تیم یک نفره مشغول تولید كد هستید و از بانک منظمی كه تمامی ایرادات برنامه را لیست كند استفاده نمی‌كنید، حتماً كد با كیفیت پایین تحویل خواهید داد. برنامه‌نویسان زیادی فكر می‌كنند كه می‌توانند لیست اشكالات و باگ‌ها را در كله خود نگهدارند. چه مزخرفاتی! من در آن واحد بیشتر از دو یا سه باگ را نمی‌توانم بخاطر بسپارم، و صبح روز بعد، یا با عجله‌ای که زمان تحویل دارید، همه به فراموشی سپرده می‌شوند.
چه اطلاعاتی درباره باگ‌ها را ثبت کنیم؟
جوئل می‌گوید حداقل اطلاعات زیر در مورد هر باگ باید ثبت شود:
- مراحل کامل برای باز تولید اشکال
- رفتاری که انتظار آن می‌رود
- رفتار (ایراد داری) که واقعاً رخ می‌دهد
- فردی که رفع اشکال به او واگذار شده است
- آیا اشکل رفع شده است یا خیر؟
اما با توجه به توضیحی که در مورد تست سوم یعنی build روزانه دادم، خوب است مشخص شود که ایراد در چه نسخه‌ای یا بهتر بگوییم در چه build ای از نرم‌افزار مشاهده شده است.
البته اطلاعات دیگری هم هست که بعداً می‌تواند به باگ ثبت شده اضافه شود مثل اینکه باگ در چه changeset ای از کد برطرف شده است یا زمان لازم برای رفع آن چقدر است تا در برنامه‌ریزی تیم مورد استفاده قرار بگیرد.
به چه روشی اطلاعات باگ‌ها را نگهداری و باگ‌ها را رفع کنیم؟
اگر اهل استفاده از نرم‌افزارهای bug tracker نیستید خیلی راحت می‌توانید یک فایل اکسل درست کنید و ستون‌های ذکر شده را به آن اضافه کنید. اما من استفاده از TFS را توصیه می‌کنم. همین‌طور که در نوشته مربوط به تست اول جوئل گفتم TFS فقط یک نرم‌افزار برای استفاده به صورت source control نیست. بخش مهم‌تر TFS مکانیزه کردن پروسه تولید نرم‌افزار از طریق امکاناتی که برای build و test و برنامه‌ریزی دارد می‌باشد.
روال نسبتاً استاندارد کار برای نگهداری اطلاعات باگ‌ها و کار بر روی آن‌ها در TFS به شرح زیر است:
ابتدا برای نرم‌افزار موجود تعدادی Test Case را در یک Test Plan تعریف می‌کنید. این Test Case ها می‌توانند مربوط به یک تست اتوماتیک یا تست توسط کاربر tester باشد. در مراحل هر Test Case مشخص می‌کنید که نتیجه مورد انتظار چیست. کاربر tester می‌تواند هر مرحله و کلیت تست را fail یا pass کند. در صورت fail کردن می‌تواند یک bug ایجاد کند. از آنجایی که می‌توانید تنظیم کنید کل روال تست ضبط شود، موقع ایجاد باگ حتی فیلمی از دسکتاپ tester هم به باگ ایجاد شده attach می‌شود به همراه کلی اطلاعات دیگر که مشخص کننده این است که مراحل بازتولید اشکال کدام است. لازم است اشاره کنم که تست‌ها می‌توانند از پیش تعریف شده هم نباشند، یعنی یک tester کاملاً به صورت آزمون و خطایی با کار نرم‌افزار کار کند و سعی کند در عملکرد آن ایرادی پیدا کند. به این نوع تست‌ها exploratory test گفته می‌شود. در موردMicrosoft Test Manager به صورت مفصل صحبت خواهم کرد.
بعد از تعریف باگ نوبت به تایید آن می‌رسد، مسئول تایید می‌تواند لیستی از باگ‌های گزارش شده را مشاهده کند و آن‌هایی که به نظرش درست گزارش شدند را تایید کند و برای انجام به برنامه‌نویسان تیم assign کند. البته در برنامه‌ریزی کلان‌تر حتی می‌توان تعیین کرد که رفع باگ مثلاً در چه اسپرینتی انجام شود.
بعد از آن هر برنامه‌نویس وقتی Visual Studio خودش را باز می‌کند در Team Explorer و از بخش My Work می‌تواند کارهایی که به وی assign شده اعم از ایجاد featureهای جدید یا رفع باگ‌ها را مشاهده کند و بعد از انجام کار و هنگام تحویل کد (check in) مشخص کند که کدی که در حال check in هست مثلاً باگ شماره x یا y را حل کرده است.
روالی که توضیح دادم علاوه بر ثبت باگ‌ها، کلیه مراحل مربوط به کشف تا رفع باگ را نیز پوشش می‌دهد.