توسعه‌دهندگان، مدیران و ذینفعان محصول، اغلب به یک کارکرد تست خودکار یعنی «یافتن باگ» بیشتر از سایر دستاوردهای آن توجه می‌کنند. هرچند که «یافتن باگ» مهم است اما وقتی که تنها این کارکرد تست در نظر ما پررنگ شود و از دیگر مزایای تست‌خودکار غافل شویم، دیگر بعید نیست که از خیر همین تک کاربرد «یافتن باگ» بگذریم و این کار را بسپاریم به دو سه نفر که بنشینند و صبر پیش گیرند و دست به کار تست دستی شوند! خب هدف یافتن باگ است، اینها هم همین کار را می‌کنند؛ نه؟!
اما خودکارسازی تست، دستاوردهایی فراتر از «یافتن باگ» دارد. دستاوردهایی که اگر محقق شوند، همگی پی خواهیم برد که کارکرد «یافتن باگ»، تنها بخشی کوچک از اتمسفر مثبتی است که تست‌خودکار، در تیم/سازمان ایجاد می‌کند. اینجا به صورت خلاصه و فهرست‌وار به برخی از مهمترین دستاوردهای تست‌خودکار اشاره کرده‌ام:
- تعادل کار و زندگی
کلنجار رفتن با سیستم‌هایی که کدهای کثیف و پر باگ دارند می‌تواند توسعه‌دهندگان را زمین‌گیر کند و آنها را تا دیروقت سر کار نگه دارد. چه کسی از داشتن نیروهای خسته و فرسوده که تعادل کار و زندگی‌شان به هم خورده منتفع می‌شود؟ این یک بازی باخت – باخت برای نیرو و سازمان است.
- یادگیری
نوشتن تست‌خودکار، مثل دوباره خواندن یک متن است. اما این بار آهسته‌تر و با تمرکز بیشتر. این بازخوانی هم به یادگیری دامین و درک بهتر آن منجر کمک می‌کند و هم از جنبه فنی باعث می‌شود تا یاد بگیریم که چطور کد تست‌پذیر بنویسیم. یک تیر و دو نشان!
- جلوگیری از کدورت‌ها
شاید شما هم چنین اعتراضی کرده باشید که: «فلانی فیچر تولید کردی یا باگ؟ این چه وضعشه؟» شاید هم مورد خطاب چنین اعتراضی بوده‌اید! به هر حال این ادبیات می‌تواند به ایجاد کدورت و تضعیف روحیه کار تیمی منجر شود. تست‌خودکار که وجود داشته باشد، کمتر پیش می‌آید که چنین چیزی بگویید یا بشنوید!
- شجاعت تغییر
بدون تست‌خودکار، تغییر کابوس است. داشتن یک مجموعه تست‌خودکار قابل اعتماد، مانند سپری فولادی ما در برابر ضربه‌های ناشی از تغییر ایمن می‌کند.
- اعتماد
«بچه‌ها کسی اجازه نداره با Master مرج کنه! قبلش من باید همه کدها رو ریویو کنم!» این یک روش ناکارآمد در تیم‌هایی است که می‌خواهند فقدان تست‌خودکار را با کدریویوی فردی جبران کنند. قانونی که حامل پیام بی‌اعتمادی است. در تیمی که تست‌های خودکار به خوبی نوشته شده‌اند، نظارت بر صحت و کیفیت کد به ابزارها سپرده می‌شود و روابط آدمها با هم در تیرگی ناشی از چنین رفتارهای کنترلی، فرو نمی‌رود.
- حس افتخار
چه کسی دوست دارد عضو تیمی باشد که به دلیل وجود باگ‌‌های بازدارنده، مدام مورد نگاه سرزنش‌گرانه دیگران است؟ به بودن در چنین تیمی می‌شود افتخار کرد؟ به بودن در تیمی که محصول کم نقصی عرضه می‌کند چطور؟
- تست به عنوان مستند
تست خوب، می‌تواند جایگزین بهتری برای مستندات مکتوب باشد. اعضای جدید تیم می‌توانند با مرور سناریوهای تست، بسیار سریعتر از خواندن مستندات یک PDF، بر منطق برنامه، معماری و کامپوننت‌ها مسلط شوند.
- ضرب‌آهنگ پایدار
کدبیس روز به روز بزرگ‌تر می‌شود. یادآوری منطق کدهای قبلی سخت‌تر می‌شود. فیچرها بیشتر می‌شوند و ارتباط کامپوننت‌ها در هم تنیده‌تر می‌شود و پیدا کردن باگ و رفع آنها خسته‌کننده‌تر. در اوایل توسعه، سرعت توسعه خوب است چون کدبیس کوچک است ولی به مرور سرعت توسعه کند و کندتر می‌شود تا جایی که زمزمه‌های دوباره نویسی سیستم به گوش می‌رسد. سرمایه گذاری روی تست‌خودکار می‌تواند رسیدن به چنین نقطه‌ای را برای همیشه به تاخیر بیاندازد و اگر هم روزی تصمیم به بازنویسی سیستم گرفته شود، نه به دلیل سختی دیباگ کردن، بلکه به دلیل تغییرات کسب و کار باشد.
- تخمین درست‌تر زمان فعالیت‌ها
«دو روزه ردیفش می‌کنیم!» اما در بعد از ظهر روز دوم، کار گره خورده و کلی درگیر خواندن کدهای قبلی و رفع‌باگ‌های کهنه شده‌ایم و بعید است که ۲ روز دیگر هم کار را تمام کنیم. تست‌خودکار می‌تواند باعث شود که از اثرات ناخواسته‌ی تغییرات کد مطلع شویم و مطمن شویم که تغییرات ما جایی را خراب نکرده است.
- صرفه‌جویی در هزینه‌های تولید
به عبارت خیلی ساده، تست‌خودکار، به صرفه‌جویی در زمان منجر می‌شود. صرفه‌جویی در زمان، به صرفه‌جویی در هزینه منجر می‌شود. از طرف دیگر، اعضای تیم حال بهتری دارند این حال بهتر یعنی بهره‌وری بیشتر در کار.
