تضمین کیفیت نرمافزار، کنترل کیفیت و تست نرمافزار سه مفهوم نزدیک به هم هستند. این سه واژه در جلسهها و آگهیهای شغلی زیاد بهجای هم به کار میروند. این مقاله تفاوت QA، QC و تست را با مثال و جدول مقایسه توضیح میدهد تا نقش هر کدام در تیم روشن شود.
تضمین کیفیت نرمافزار (QA) چیست
تضمین کیفیت (Quality Assurance) مجموعه فعالیتهایی است که از بروز خطا پیشگیری میکند. تمرکز QA بر فرایند است، نه بر یک نسخه خاص از محصول. پرسش اصلی QA این است: آیا روش کار ما به محصول باکیفیت میرسد.
QA در کل چرخه عمر توسعه نرمافزار حضور دارد. از تعریف نیازمندی تا نگهداری محصول، QA قواعد و روشهایی میگذارد که احتمال خطا را کم کند. مسئولیت QA فقط با یک نفر نیست. کل تیم در اجرای آن سهم دارد.
فعالیتهای رایج تضمین کیفیت
- تعریف فرایند توسعه و تست و مستندسازی آن
- تعیین استانداردهای کدنویسی و قالب مستندات
- بازبینی نیازمندیها و طراحی پیش از شروع توسعه
- تعریف معیارهای پذیرش و تعریف «انجامشده»
- انتخاب ابزارها و آموزش تیم
- ممیزی فرایند و بررسی رعایت استانداردها
- جلسههای بازنگری برای یافتن ریشه مشکلات و بهبود فرایند
یک مثال ساده از QA
فرض کنید در چند ریلیز اخیر، باگهای زیادی در محاسبه مالیات دیده شده است. تیم QA ریشه مشکل را بررسی میکند. نتیجه این است که نیازمندیهای مالیاتی مبهم نوشته شدهاند. اقدام QA اصلاح فرایند است: از این به بعد، هر نیازمندی مالی پیش از توسعه با کارشناس مالی بازبینی میشود. این اقدام هیچ باگی را مستقیم پیدا نمیکند، اما جلوی باگهای آینده را میگیرد.
هزینه کیفیت از نگاه QA
مفهوم «هزینه کیفیت» کمک میکند ارزش QA بهتر دیده شود. هزینههای کیفیت معمولاً در چهار گروه دستهبندی میشوند:
| گروه هزینه | توضیح | نمونه در نرمافزار |
|---|---|---|
| پیشگیری | هزینه جلوگیری از بروز خطا | آموزش تیم، بازبینی نیازمندی، تعریف استاندارد |
| ارزیابی | هزینه سنجش کیفیت محصول | اجرای تست، بازبینی کد، نگهداری تستهای خودکار |
| خرابی داخلی | هزینه خطاهایی که پیش از ریلیز پیدا میشوند | رفع باگ، تست مجدد، تأخیر در زمانبندی |
| خرابی خارجی | هزینه خطاهایی که به دست کاربر میرسند | پشتیبانی اضطراری، بازگشت نسخه، از دست رفتن اعتماد |
QA بیشتر روی هزینه پیشگیری سرمایهگذاری میکند. QC و تست بیشتر در گروه ارزیابی قرار میگیرند. هدف هر دو، کم کردن هزینههای خرابی است؛ بهویژه خرابی خارجی که بیشترین اثر را بر کسبوکار دارد.
کنترل کیفیت (QC) چیست
کنترل کیفیت (Quality Control) مجموعه فعالیتهایی است که خطاها را در محصول شناسایی میکند. تمرکز QC بر خروجی است. پرسش اصلی QC این است: آیا این نسخه از محصول الزامات کیفیت را برآورده میکند.
QC معمولاً پس از ساخته شدن بخشی از محصول انجام میشود. خروجی آن فهرست خطاها، نتایج تست و تصمیم درباره قبول یا رد یک نسخه است.
فعالیتهای رایج کنترل کیفیت
- اجرای تستهای دستی و خودکار
- بازبینی کد و مستندات تحویلی
- بررسی نتایج در برابر نیازمندیها
- ثبت و پیگیری باگها
- تهیه گزارش کیفیت برای تصمیم ریلیز
تصدیق و اعتبارسنجی
دو مفهوم دیگر هم به این بحث مربوط است. تصدیق (Verification) میپرسد: آیا محصول را درست میسازیم. یعنی آیا خروجی با مشخصات و طراحی مطابقت دارد. اعتبارسنجی (Validation) میپرسد: آیا محصول درست را میسازیم. یعنی آیا محصول نیاز واقعی کاربر را برطرف میکند. بازبینی مستندات بیشتر تصدیق است. تست پذیرش کاربر نمونه روشن اعتبارسنجی است.
تست نرمافزار کجای این تصویر است
تست نرمافزار یکی از فعالیتهای اصلی کنترل کیفیت است. در تست، نرمافزار اجرا میشود و رفتار واقعی با رفتار مورد انتظار مقایسه میشود. پس میتوان رابطه این سه را به شکل سه لایه دید:
- QA لایه بیرونی است و فرایند کلی کیفیت را تعریف میکند.
- QC درون آن قرار دارد و محصول را در برابر الزامات میسنجد.
- تست درون QC قرار دارد و ابزار اصلی سنجش محصول است.
البته این مرزها در عمل کاملاً سفت نیستند. مثلاً بازبینی نیازمندی توسط تستر هم پیشگیری است و هم شناسایی. تست زودهنگام در قالب رویکرد Shift-Left هم فعالیتی است که بین QA و QC قرار میگیرد. برای مرور کامل مفاهیم تست، راهنمای تست نرمافزار را ببینید.
مقایسه QA، QC و تست در یک جدول
| معیار | تضمین کیفیت (QA) | کنترل کیفیت (QC) | تست نرمافزار |
|---|---|---|---|
| تمرکز | فرایند | محصول | رفتار نرمافزار در اجرا |
| رویکرد | پیشگیرانه | شناساییکننده | شناساییکننده |
| زمان انجام | در کل چرخه توسعه | پس از ساخت هر بخش | پس از آماده شدن بیلد یا کد |
| پرسش اصلی | آیا روش کار درست است | آیا خروجی درست است | آیا این قابلیت طبق انتظار کار میکند |
| خروجی | فرایند، استاندارد و بهبود | گزارش کیفیت و تصمیم قبول یا رد | نتایج تست و گزارش باگ |
| مسئول | کل تیم با هدایت نقش QA | تیم تست و بازبینها | تستر و توسعهدهنده |
| نمونه | تعریف قالب استاندارد تستکیس | بازبینی نسخه پیش از ریلیز | اجرای تست رگرسیون |
نقشها در تیمهای کوچک و بزرگ
در تیمهای کوچک، معمولاً یک نفر هر سه نقش را بر عهده دارد. همان مهندس QA که فرایند را تعریف میکند، تستها را هم اجرا میکند. در این حالت، مهم است که وقت کافی برای کارهای پیشگیرانه هم کنار گذاشته شود.
در سازمانهای بزرگتر، نقشها تفکیک میشوند:
- مدیر کیفیت یا سرپرست QA: استراتژی، فرایند و استانداردهای کیفیت را تعریف میکند.
- مهندس QA: طرح تست، طراحی تست و بهبود فرایند را در سطح تیم محصول پیش میبرد.
- تستر نرمافزار: تستکیسها را اجرا، نتایج را ثبت و باگها را گزارش میکند.
- مهندس اتوماسیون: زیرساخت و اسکریپتهای تست خودکار را میسازد و نگهداری میکند.
اگر به مسیر شغلی در این حوزه علاقه دارید، مقاله نقشه راه QA Engineer را ببینید.
یک مثال عملی: از نیازمندی تا ریلیز
برای روشنتر شدن تفاوتها، یک قابلیت ساده را دنبال کنیم: «ارسال کد تأیید پیامکی هنگام ثبتنام».
نیازمندی
- فعالیت QA: نیازمندی با قالب استاندارد نوشته و بازبینی میشود. معیارهای پذیرش روشن تعریف میشوند؛ مثلاً اعتبار کد دو دقیقه است و حداکثر سه بار ارسال مجدد مجاز است.
تستکیس
- فعالیت QA: قالب تستکیس و سطح جزئیات از قبل در فرایند تیم تعریف شده است.
- فعالیت QC: تستر برای هر معیار پذیرش تستکیس مینویسد. مقادیر مرزی مثل ثانیه ۱۱۹ و ۱۲۱ هم پوشش داده میشوند. روش نوشتن تستکیس خوب در مقاله نوشتن تستکیس حرفهای آمده است.
اجرای تست
- فعالیت QC و تست: تستکیسها در محیط تست اجرا و نتایج ثبت میشوند. تستهای خودکار API هم در پایپلاین اجرا میشوند.
باگ
- فعالیت QC: تستر میبیند که پس از سومین ارسال مجدد، دکمه همچنان فعال است. یک گزارش باگ با مراحل بازتولید ثبت میشود. مسیر این باگ را میتوانید در مقاله چرخه عمر باگ و گزارش باگ دنبال کنید.
- فعالیت QA: در بازنگری اسپرینت، تیم بررسی میکند چرا این مورد در بازبینی کد دیده نشد. شاید چکلیست بازبینی کد نیاز به یک بند جدید داشته باشد.
ریلیز
- فعالیت QC: بر اساس معیارهای ورود و خروج، تصمیم ریلیز گرفته میشود.
- فعالیت QA: معیارهای کیفیت ریلیز ثبت میشوند تا روند کیفیت در ریلیزهای بعدی قابل مقایسه باشد. برای انتخاب این معیارها، مقاله معیارهای تست و گزارش کیفیت را ببینید.
اشتباهات رایج در تفکیک QA و QC
کیفیت فقط کار تیم تست است
این رایجترین اشتباه است. تیم تست میتواند خطا را پیدا کند، اما کیفیت را خودش نمیسازد. کیفیت نتیجه کار مشترک مدیر محصول، طراح، توسعهدهنده و تستر است.
QA یعنی همان تست
وقتی عنوان شغلی QA به معنای «تستر» به کار میرود، بخش پیشگیرانه کیفیت فراموش میشود. تیمی که فقط تست میکند، همان باگها را در هر ریلیز دوباره پیدا میکند. بهبود فرایند است که این چرخه را میشکند.
تست در انتهای پروژه
اگر تست فقط در روزهای آخر انجام شود، QC به یک گلوگاه تبدیل میشود. باگها دیر پیدا میشوند و فشار زمانی کیفیت تصمیمها را پایین میآورد. تست باید از مرحله نیازمندی شروع شود.
نبود مستندات و ردیابی
بدون ارتباط روشن بین نیازمندی و تست، نمیتوان گفت چه چیزی تست شده است. ماتریس ردیابی این شکاف را پر میکند. جزئیات آن را در مقاله ماتریس ردیابی نیازمندی بخوانید.
تمرکز صرف بر تعداد باگ
تعداد باگ پیداشده بهتنهایی معیار خوبی برای کیفیت کار تیم تست نیست. کاهش باگهای فرار کرده به محیط عملیاتی و بهبود روند کیفیت، تصویر دقیقتری میدهد.
مدیریت QA و QC در TestRail
یک ابزار مدیریت تست هر دو بخش QA و QC را پشتیبانی میکند. در بخش QA، قالبهای یکسان تستکیس و فیلدهای سفارشی، استاندارد تیم را در ابزار پیاده میکنند. در بخش QC، تستکیسها در سوئیتها و بخشها سازماندهی و در قالب Test Run و Test Plan اجرا میشوند. نتایج با وضعیتهای Passed، Failed، Blocked و Retest ثبت میشوند و گزارشها وضعیت هر Milestone را نشان میدهند. اتصال به Jira هم باگها را به تستکیس مرتبط وصل میکند. برای استقرار این فرایند در تیم خود، صفحه پیادهسازی و پشتیبانی TestRail را ببینید.
جمعبندی
تضمین کیفیت نرمافزار بر فرایند تمرکز دارد و از خطا پیشگیری میکند. کنترل کیفیت بر محصول تمرکز دارد و خطا را شناسایی میکند. تست نرمافزار ابزار اصلی کنترل کیفیت است و رفتار واقعی محصول را میسنجد. تیمی که هر سه را کنار هم به کار میبرد، هم باگ کمتری میسازد و هم باگها را زودتر پیدا میکند. نتیجه، زنجیرهای شفاف از نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز است.