هر سیستم سازمانی‌ای که داشته باشید، روزی مجبور به توسعه دادن اون برای پوشش نیازهای شرکت می‌شوید. اینجاست که پای برنامه‌نویس‌ها به میدان باز میشه و در آخر درخواست‌ها به قابلیت‌ها تبدیل میشه. وقتی کار این گروه تموم شد و قبل از اینکه توسعه جدید رو جلوی دست کاربر بگذارید باید فرد دیگه‌ای رو وارد بازی کنید. به این فرد آزمونگر (Tester) می‌گویند. تستر معمولن مهارت فنی برنامه‌نویس رو نداره، بیشتر با دید تحقیر بهش نگاه میشه و حتا نقشش از این میان حذف میشه. اما برنامه‌نویسی و آزمایش دو مهارت کاملن متفاوت هستند.
هدف از تست کردن اینه که تایید بشه توسعه و تغییر به وجود اومده با نیاز مطرح شده همخوانی داره و تاثیر منفی بر روی بخش‌های در حال کار سیستم نداره. تست ما رو از مشکلات احتمالی در آینده آگاه میکنه.
برای اینکه اطمینان از کیفیت خروجی به دست بیاد، آزمونگر بایست مثل کاربر فکر کنه. به برنامه باید مثل یک جعبه سیاه نگاه بشه و به همون صورتی آزمایش بشه که قراره در محیط واقعی ازش استفاده بشه. در واقع تستر نباید شبیه برنامه‌نویس فکر کنه. اگه شما چیزی رو خودتون درست کرده باشید و بخواهید امتحانش کنید، تنها بخشی رو بررسی می‌کنید که احتمال وجود مشکل در اون بیشتره. اما آزمونگر به زیرساخت، طراحی و اجرا کاری نداره و فشار بررسی خودش رو روی همه‌ی بخش‌ها قرار میده.
تست تضمین کیفیت یا تست عملکرد از مسئولیت‌های تیم آزمونگرها است. اما خیلی از شرکت‌ها کمبود منابع دارند و برنامه‌نویس‌ها مجبورند مرحله‌ی تست رو هم پیش ببرند. در صورتیکه شما هم با چنین وضعیتی مواجهید، این موارد رو در ذهن داشته باشید:
- برنامه‌نویس‌ها نباید کار خودشون رو آزمایش کنند. کار هر فرد رو به فرد دیگه بدهید تا تست بشه.
- سناریوی آزمایش رو با توجه به روش استفاده بنویسید و نه بر اساس ویژگی‌های فنی سیستم.
- یک کاربر حرفه‌ای (و اگه نبود، یک کاربر عادی) پیدا کنید. این فرد به خوبی میتونه یا سیستم کار کنه و مشکلات توسعه جدید رو پیدا کنه.
در نهایت اینکه همیشه خوب نیست بدونیم پشت پرده چی میگذاره، مخصوصن موقعِ تستِ سیستم.
