محصول، ماشین تعامل بین کاربر و تجارت شماست و از اونجا که تجربه‌ی کاربری نقش اساسی در توفیق هر کسب و کاری داره، مراقبت از محصول و بهبود دائمی اون، مسئله‌ایه که نباید به هیچ وجه ازش غافل شد.
کنترل کیفیت بخش حیاتی‌ای توی هر کسب و کار مبتنی بر تکنولوژیه (یا هر کسب و کار دیگه‌ای) که مهم‌ترین وظیفه‌ش کمک به بقیه‌ی اجزای ماشین محصول برای تضمین سلامت تجربه‌ی مشتریه و اصلی‌ترین هدفش اینه که همیشه دو قدم جلوتر باشه و سنگ‌هایی که توی مسیر مشتری هستن رو از توی راه برداره تا تعامل با محصول برای مشتری لذت‌بخش‌تر و آسون‌تر بشه: فارغ از این که این سنگ‌ها، سوءعملکردهای حیاتی هستن یا صرفا به‌هم‌ریختگی‌های بصری که تجربه‌ی تلخی رو رقم می‌زنن.
بنا به همین، کار کارشناس کنترل کیفی محصول، معمولا به سه بخش کلی تقسیم می‌شه که توی مراحل مختلف توسعه‌ی محصول معنا پیدا می‌کنن، که به‌طور خلاصه از این قرار هستن:
اول کنترل کیفی فرآیندهای در حال توسعه، دوم، کنترل کیفی روزانه و روتین فرآیندهای بحرانی (Critical Path) محصول و در نهایت ارزیابی متریک‌های کمی(Quantitative) که می‌تونن نشون‌دهنده‌ی کیفیت تجربه‌ی کاربر باشن.
توی لایه‌ی اول، کارشناس کنترل کیفیت، وظیفه داره فرآیندها یا فیچرهای طراحی‌شده یا در حال توسعه رو طبق Use-Case هایی که تیم محصول براشون آماده کرده، تست کنه و برای هر یوز-کیس تست‌کیس مرتبطش رو بنویسه. این پروسه باعث آسودگی خیال تمام تیم محصول می‌شه و همه می‌دونن که یه نفر یا یه تیم همه چیز رو به دقت تست می‌کنه و پروسه‌ی گزارش خرابی رو با Evidence کافی و مستندشده انجام می‌ده تا فرآیند باگ‌ریپورت و باگ‌فیکس هر چه سریعتر و راحت‌تر انجام بشن.
لایه‌ی دوم کنترل کیفیت تست روزانه و روتین محصوله که طبق تست‌کیس‌هایی که در لایه‌ی اول آماده شده اتفاق می‌افته. کارشناس کنترل کیفیت، به صورت روتین، عملکرد فرآیندهای بحرانی محصول رو روی همه‌ی پلت‌فرم‌ها به صورت دستی (Manual Test) ارزیابی می‌کنه و سوءعملکردها رو به تیم فنی گزارش می‌کنه. نکته‌ای که توی تست دستی باید مورد توجه قرار بگیره اینه که کارشناس کنترل کیفیت، باید به دقت تمام رفتارهایی که احتمال می‌ده کاربر واقعی انجام بده رو شبیه‌سازی کنه تا چیزی از قلم نیفته و همه‌ی سناریوهای محتمل ارزیابی بشن. به همین دلیل فرآیند تست دستی بسته به مقیاس محصول می‌تونه خیلی زمان‌بر و یا کم‌دقت بشه. برای حل این مشکل، معمولا تیم‌های محصول به صورت جوخه‌ای یا چپتری از هم جدا می‌شن و هر تیم بنابه نیازش فرآیند تست دستی رو به صورت درون‌تیمی بازتعریف می‌کنه تا کنترل کیفی محصول به شکل بهینه و کم‌خطا اتفاق بیفته.
چیز دیگه‌ای که می‌تونه توی این لایه به فرآیند کنترل کیفی محصول کمک کنه، استفاده از Automated Test برای سرویس‌های بک‌اند و فرانت‌انده. با استفاده از فریم‌ورکی که سرویس‌ها رو به صورت تکراری و مداوم تست می‌کنه، خیلی از سوءعملکردهای سیستمی می‌تونن تو لایه‌ی کد شناسایی بشن و قبل از تاثیرگذاری توی رابط کاربری، رفع بشن. استفاده از Automated Test می‌تونه مشکلاتی مثل زمان‌بر بودن فرآیند تست و ضریب خطای انسانی رو به شدت کاهش بده و در کنار Manual Test فرآیند کنترل کیفی نسبتا کامل و مورداطمینانی برای محصول شکل بده.
لایه‌ی سوم، لایه‌ایه که ممکنه خیلی از کسب‌وکارها توی فرآیند کنترل کیفیت تعریفش نکنن و مستقیما به متدهای تعریف هدف دسته‌جمعی مثل OKR ارتباط پیدا می‌کنه. سوای سوءعملکردها و باگ‌های سیستمی که مستقیما تجربه‌ی کاربر رو دچار اختلال می‌کنن، غیربهینه بودن و ابهام‌آمیز بودن بعضی از یوزر استوری‌ها یا یوز-کیس‌ها هم می‌تونن باعث تلخ شدن تجربه‌ی کاربر بشن. تشخیص این نقص‌ها و بهبودشون البته بر عهده‌ی تیم محصول و طراحی تجربه‌ی کاربریه اما خیلی وقت‌ها توی بستری مثل بستر OKR تیم‌های مختلف می‌تونن به طور هم‌زمان روی Shared OKR ها کار کنن.
به عنوان مثال، سناریوی بن‌بستی که توی یکی از فرآیندهای محصول وجود داره رو هم می‌شه به عنوان باگ تعریف کرد و هم به عنوان Bad UX و با این که هر تیم محصول بسته به فرآیندهای داخل‌تیمی خودش، ممکنه همچین مسائلی رو به یک تیم یا تیم دیگه محول کنه، در هر صورت کنترل کیفیت نقش مهمی توی پیدا کردن این سناروهای مخرب داره. به عنوان مثال متریکی مثل Bounce Rate که برای خیلی از کسب‌وکارها، خصوصا ای-کامرس‌ها معیار مهمیه، می‌تونه Key-Result مهمی برای تیم کنترل کیفیت باشه چرا که رفع سوعملکردها مطمئنا می‌تونه نرخ پرش رو کاهش بده.
حالا سناریویی رو در نظر بگیرین که نرخ پرش به خاطر وجود سناریوی مبهمی یا بن‌بست ناخواسته‌ای بالاست و این تیم کنترل کیفیته که اولین بار این آنومالی رو توی سیستم پیدا می‌کنه. اینجاست که همکاری کنترل کیفیت با تیم طراحی تجربه‌ی کاربری می‌تونه تاثیر ویژه‌ای روی تجربه‌ی کاربر بسازه. به عبارت دیگه، با این که بهبود تجربه‌ی کاربر، وظیفه‌ی مستقیم تیم کنترل کیفیت نیست و از طریق فالو کردن متریک‌های مرتبط و برگزاری تست‌های کمی و کیفی توی تیم طراحی تجربه‌ی کاربری به دست می‌آد، خیلی جاها دخیل شدن تیم کنترل کیفیت از طریق Shared OKR ها می‌تونه از خسارت‌های ناشی از یه فرآیند معیوب که عمدتا به دلیل بایاس بودن طراح با فلوها به وجود می‌آد، جلوگیری کنه و لزوم برگزاری تست‌های پرهزینه و پیچیده رو به حداقل برسونه.
به طور کلی فرآیند کنترل کیفیت محصول طراحی شده تا تیم محصول بتونه با اعتماد به نفس به پروسه‌ی توسعه و بهینه‌سازی فکر کنه و تا حد زیادی مطمئن باشه که داده‌هایی که استخراج و تحلیل می‌کنه، نتیجه‌ی سوءعملکرد اجزای ماشین محصول نیستن. کنترل کیفیت در بهترین حالت خودش، کیفیت تجربه‌ی کاربر رو تضمین می‌کنه و سعیش بر اینه که با حذف عیب و نقص‌ها، چرخه‌ی دیزاین و فیدبک رو تا حد ممکن بهینه و پویا نگه داره.
نویسنده: سهیل بهروزی
