UAT چیست و چرا تاریخ ورود به UAT را جدا ثبت کنیم

برنامه‌نویس چهارشنبه می‌گوید «نسخه تمام شد». مدیر محصول همان روز به مشتری خبر می‌دهد. دو هفته بعد هنوز چیزی لایو نشده: محیط تست آماده نبود، نمایندهٔ مشتری سفر بود، و وقتی بالاخره تست کرد، سه مورد پیدا شد که «این که چیزی نیست که خواسته بودیم». در جلسهٔ بعد همه از تأخیر حرف می‌زنند، ولی کسی نمی‌داند تأخیر دقیقاً کجا بود.

این فاصلهٔ بین «توسعه تمام شد» و «نسخه لایو شد» همان جایی است که آزمون پذیرش کاربر می‌نشیند، و در اغلب تیم‌هایی که دیده‌ام، کاملاً نامرئی است؛ چون فقط یک تاریخ ثبت می‌شود: سررسید. این مقاله توضیح می‌دهد UAT چیست، چه چیزی نیست، و چرا ورود به آن باید تاریخ برنامه‌ای و واقعی خودش را داشته باشد.

این مقاله بخشی از مجموعهٔ راهنمای جامع برنامه‌ریزی اسپرینت است؛ آنجا کل مسیر از تعهد تیم تا لایو شدن نسخه را گفته‌ام و اینجا روی یکی از ایستگاه‌های آن مسیر تمرکز می‌کنم.

UAT دقیقاً چیست و چه نیست

آزمون پذیرش کاربر (User Acceptance Testing یا UAT) مرحله‌ای است که در آن کاربران واقعی یا نمایندگان کسب‌وکار، نسخهٔ آماده را در محیطی شبیه محیط اصلی امتحان می‌کنند تا به یک سؤال جواب دهند: آیا این همان چیزی است که لازم داشتیم؟

این سؤال با سؤال تست فنی فرق دارد. تستر تیم می‌پرسد «آیا درست کار می‌کند؟»؛ کاربر در UAT می‌پرسد «آیا به درد کار من می‌خورد؟». نرم‌افزاری می‌تواند همهٔ تست‌های فنی را بگذراند و باز هم در UAT رد شود، چون مثلاً گزارشی که ساخته شده ستون‌هایی دارد که حسابدار هیچ‌وقت لازمشان ندارد و ستونی را که هر روز لازم دارد ندارد.

و چند چیز که UAT نیست:

• اولین باری که کسی نرم‌افزار را تست می‌کند. اگر کاربر در UAT به خطاهای پایه برمی‌خورد، تست فنی کارش را نکرده و وقت گران‌ترین آدم‌ها هدر رفته است.
• جای مطرح کردن نیازهای تازه. «حالا که دیدم، کاش یک دکمهٔ خروجی اکسل هم داشت» درخواست تازه است، نه ایراد UAT. باید کارت جدا بشود و برای نسخهٔ بعد برنامه‌ریزی شود.
• یک تشریفات امضایی. اگر نمایندهٔ مشتری بدون باز کردن نرم‌افزار تأییدش کند، UAT انجام نشده؛ فقط تاریخش ثبت شده.

چهار نقطه در عمر یک نسخه

وقتی به نسخه‌ای نگاه می‌کنم، چهار لحظه را از هم جدا می‌کنم و برای هر کدام دو تاریخ می‌خواهم: برنامه‌ای و واقعی.

1. شروع توسعه: روزی که تیم واقعاً روی کارت‌های این نسخه کار را شروع می‌کند.
2. پایان توسعه: روزی که همهٔ کارت‌ها از تست فنی گذشته‌اند و نسخه از دید تیم آماده است.
3. ورود به UAT: روزی که نسخه روی محیط پذیرش نصب شده و کاربران تست را شروع کرده‌اند؛ نه روزی که «قرار بود» شروع کنند.
4. لایو شدن: روزی که نسخه روی محیط اصلی است و کاربران واقعی از آن استفاده می‌کنند.

بیشتر تیم‌ها اولی و آخری را دارند، گاهی دومی را. سومی تقریباً همیشه گم است، و درست همان است که بیشترین اطلاعات را دارد.

چرا ورود به UAT باید تاریخ جداگانه داشته باشد

«تمام شد» دو معنا دارد

برای برنامه‌نویس «تمام شد» یعنی کد نوشته و تست شده است. برای مشتری یعنی «می‌توانم از آن استفاده کنم». بین این دو معنا معمولاً چند روز تا چند هفته فاصله است. وقتی ورود به UAT تاریخ خودش را دارد، این فاصله یک عدد می‌شود که می‌توان درباره‌اش حرف زد، نه یک حس مبهم که «همیشه کارها طول می‌کشد».

زمان UAT دست تیم توسعه نیست

توسعه را تیم کنترل می‌کند؛ UAT را آدم‌هایی که معمولاً کار اصلی دیگری دارند. نمایندهٔ واحد مالی آخر ماه وقت ندارد، مدیر فروش هفتهٔ نمایشگاه در دسترس نیست. اگر فقط یک سررسید کلی داشته باشید، تأخیرِ ناشی از در دسترس نبودن کاربر با تأخیرِ تیم توسعه قاطی می‌شود و تیم برای چیزی سرزنش می‌شود که دستش نبوده. تاریخ جداگانه این دو را از هم جدا می‌کند.

آدم‌های طرف کسب‌وکار باید از قبل برنامه بریزند

اگر تاریخ برنامه‌ای ورود به UAT از اول اسپرینت معلوم باشد، می‌شود همان روز به کاربران گفت: «از ۱۸ تا ۲۰ آبان، روزی دو ساعت برای تست لازم داریم.» این جمله در تقویم آدم‌ها جا باز می‌کند. «هر وقت آماده شد خبرتان می‌کنیم» جا باز نمی‌کند.

یک مثال فرضی

فرض کنید نسخهٔ v2.4 یک سامانهٔ داخلی این‌طور پیش رفته است:

اگر فقط تاریخ لایو را داشتید، می‌گفتید «نسخه ۶ روز دیر شد» و احتمالاً نگاه‌ها به سمت تیم توسعه می‌رفت. ولی جدول چیز دیگری می‌گوید: توسعه ۲ روز عقب افتاد، و ۴ روز دیگر بین پایان توسعه و ورود به UAT گم شد. حالا سؤال درست معلوم است: آن ۴ روز چه شد؟ محیط آماده نبود؟ کاربر در دسترس نبود؟ جواب هر کدام یک اقدام مشخص دارد. در مقالهٔ تاریخ برنامه‌ای در برابر تاریخ واقعی همین منطق را برای کارت‌ها هم باز کرده‌ام.

چک‌لیست ورود به UAT

نسخه‌ای را وارد UAT نکنید مگر اینکه این موارد سر جایشان باشند:

• معیار پذیرش روی هر کارت نوشته شده باشد. کاربر باید بداند هر قابلیت را با چه معیاری بسنجد. اگر کارت فقط عنوان دارد، UAT به بحث سلیقه‌ای تبدیل می‌شود؛ در مقالهٔ نوشتن کارت خوب نمونهٔ معیار پذیرش را آورده‌ام.
• محیط پذیرش آماده و جدا از محیط توسعه باشد، با داده‌هایی که به داده‌های واقعی شبیه‌اند. تست گزارش فروش با سه ردیف دادهٔ آزمایشی چیزی را ثابت نمی‌کند.
• فهرست سناریوها آماده باشد: چه کارهایی را باید امتحان کنند، به چه ترتیبی.
• تست‌کننده‌ها اسم داشته باشند و بازهٔ زمانی‌شان در تقویمشان ثبت شده باشد.
• فهرست مشکلات شناخته‌شده را به کاربران بدهید تا وقتشان را روی گزارش چیزهایی که می‌دانید نگذارند.
• مسیر گزارش ایراد روشن باشد: کجا بنویسند، با چه جزئیاتی.

در طول UAT: بازخورد را چطور جمع کنیم

بدترین حالت این است که بازخوردها در پیام‌رسان، تماس تلفنی و راهروی شرکت پخش شوند. دو هفته بعد هیچ‌کس نمی‌داند کدام ایراد رفع شد و کدام فراموش شد. هر ایراد باید روی کارت مربوط یا یک کارت تازه ثبت شود، با توضیح و تصویر؛ چرا این‌قدر روی آن تأکید دارم را در مقالهٔ گفت‌وگو کنار کار نوشته‌ام.

هر بازخورد را در یکی از سه دسته بگذارید:

این دسته‌بندی را با نمایندهٔ کسب‌وکار انجام دهید، نه به‌تنهایی. اختلاف نظر دربارهٔ اینکه چیزی «ایراد» است یا «درخواست تازه» طبیعی است؛ مهم این است که آشکار حل شود، نه اینکه هر چیز تازه بی‌صدا وارد همین نسخه شود و تاریخ لایو را عقب بیندازد.

UAT را هم زمان‌دار کنید. «تا وقتی کاربران وقت کنند» یعنی هرگز. یک بازهٔ مشخص، مثلاً سه روز کاری، و در پایانش یک تصمیم صریح.

خروج از UAT و لایو شدن

پایان UAT یک تصمیم است، نه یک حس. یک نفر مشخص از طرف کسب‌وکار باید بگوید: «با این ایرادهای باقی‌مانده، نسخه را می‌پذیریم.» این تأیید را روی تابلو ثبت کنید، با تاریخ و نام. بعد تاریخ واقعی لایو را ثبت کنید؛ روزی که نسخه واقعاً روی محیط اصلی رفت، نه روزی که تأیید گرفت.

این شبیه همان «تعریف انجام‌شده» (Definition of Done) در اسکرام است، فقط یک لایه بالاتر: تعریف انجام‌شدهٔ هر کارت می‌گوید کار فنی کامل است؛ خروج از UAT می‌گوید کسب‌وکار آن را پذیرفته است. هر دو لازم‌اند.

روی تابلو چطور پیاده‌اش کنیم

ساده‌ترین شکل: ستون‌های تابلو را طوری بچینید که UAT یک ستون مستقل باشد.

بک‌لاگ | آمادهٔ شروع | در حال توسعه | تست فنی | آمادهٔ UAT | در UAT | لایو شد

ستون «آمادهٔ UAT» مهم است: کارت‌هایی که توسعه‌شان تمام شده ولی هنوز به دست کاربر نرسیده‌اند آنجا می‌مانند و اگر تعدادشان زیاد شود، همه می‌بینند. منطقش همان منطق محدودیت کار در جریان است: صفی که دیده نشود، بی‌صدا بزرگ می‌شود.

تاریخ‌ها را هم یک جای ثابت ثبت کنید: یک کارت سنجاق‌شده بالای ستون، یا توضیحات خود نسخه. در بردماگ این کار را خود ستون انجام می‌دهد: هر ستون را می‌شود اسپرینت علامت زد، نام نسخه گذاشت و برای چهار نقطهٔ شروع توسعه، پایان توسعه، ورود به UAT و لایو شدن، تاریخ برنامه‌ای و واقعی به تقویم شمسی ثبت کرد. سربرگ ستون وضعیت نسخه را نشان می‌دهد، با شمارش معکوس مثل «۳ روز تا ورود به UAT» یا تأخیر مثل «۲ روز تأخیر».

اشتباه‌های رایج

• یکی کردن تست فنی و UAT. تستر تیم جای کاربر نیست و کاربر جای تستر نیست.
• ثبت تاریخ برنامه‌ای به‌جای تاریخ واقعی. اگر UAT قرار بود ۱۳ مهر شروع شود و ۱۹ مهر شروع شد، تاریخ واقعی ۱۹ مهر است.
• UAT بی‌پایان. بدون بازهٔ زمانی و بدون کسی که تصمیم نهایی را بگیرد.
• پذیرفتن هر درخواست تازه در وسط UAT. نسخه هیچ‌وقت تمام نمی‌شود.
• بازخورد در پیام‌رسان. نصف ایرادها هیچ‌وقت به کارت نمی‌رسند.

جمع‌بندی

UAT مرحله‌ای است که در آن کسب‌وکار، نه تیم فنی، می‌گوید نسخه به درد می‌خورد یا نه. چون زمانش دست آدم‌هایی بیرون از تیم توسعه است، تأخیرهایش هم جنس دیگری دارند و اگر تاریخ جداگانه نداشته باشد، با تأخیر توسعه قاطی می‌شود. چهار تاریخ ثبت کنید، برای هر کدام برنامه‌ای و واقعی؛ ورود به UAT را با چک‌لیست انجام دهید؛ بازخورد را دسته‌بندی و روی کارت ثبت کنید؛ و خروج از آن را یک تصمیم صریح با نام و تاریخ کنید. دفعهٔ بعد که کسی پرسید «چرا نسخه دیر شد؟»، به‌جای حدس، یک جدول دارید.

منابع و مطالعهٔ بیشتر

• Acceptance testing — Wikipedia — انواع آزمون پذیرش، از جمله بخش آزمون پذیرش کاربر
• Acceptance Testing — Agile Alliance Glossary — نگاه چابک به آزمون پذیرش و رابطه‌اش با معیار پذیرش
• The Scrum Guide — تعریف رسمی Increment و تعریف انجام‌شده در اسکرام
• Deployment Pipeline — Martin Fowler — جایگاه مراحل آزمون، از جمله آزمون پذیرش، در مسیر انتشار نسخه