تستادی، پلتفرم برگزاری تست کاربردپذیری و انتقال بازخورد مستقیم کاربران هدف واقعی هر محصول است. با تستادی نقاط قوت و ضعف وبسایت و اپلیکیشنتان را تشخیص داده و هزینه‌ی ناشی از ریزش کاربران را کاهش دهید.
مصاحبه با کیان شلیله- قسمت اول
صحبت‌های کیان شلیله درباره‌ی تستهای کاربردپذیری
با کیان تو کارخونه نوآوری در مورد تستهای کاربردپذیری حرف زدیم.
از برنامه‌نویسی تا تیم رشد
الان مشغول چه کاری هستی؟
- در حال حاضر فریلنسرم و به عنوان راهبر رشد با استارتاپ‌ها کار می‌کنم. قبل از اون راهبر رشد هم‌آوا بودم. در هم‌آوا از کارهای مربوط به محصول و مارکتینگ گرفته تا کارهای فنی و دیتا، همه رو انجام می‌دادیم. کلا مهم‌ترین نکته در «رشد» اینه که مهم نیست کدوم یکی از این‌ها رو خوب انجام می‌دهی، مهم این است که باید همه‌ی این‌ها رو با هم جلو ببری تا کسب و کارت واقعاً رشد کنه.
این کارها رو برای محصول‌های دیگه هم انجام می‌دادید یا خودتون محصول داشتید؟
- هم برای محصول‌های دیگه و هم برای محصول‌هایی که سرآوا، آواتک و هم‌آوا روی اون‌ها سرمایه‌گذاری کرده بود. قبل از ادغام با هم‌آوا تیم ما در نوآوا بود و این کارها رو فقط برای محصولات بقیه‌ی شرکت‌ها انجام می‌دادیم. ولی توی هم‌آوا هر دو تا رو جلو می‌بردیم؛ هم محصول‌های زیرمجموعه‌ی خود هم‌آوا و هم محصول‌هایی بیرونی که باهاشون کار می‌کردیم.
آشنایی با تستهای کاربردپذیری
چطور با تستهای کاربردپذیری آشنا شدی؟
- خیلی اتفاقی. من برنامه‌نویس بودم، میشه گفت از زمان بچگیم. به عنوان برنامه‌نویس وارد سرآوا شدم. از اون‌جایی که راه انداختن Lab تستهای کاربردپذیری مسائل فنی زیادی داره، این کار به من واگذار شد؛ کارهایی مثل این که ابزارها رو راه بندازم، لپ‌تاپ‌ها رو به هم وصل کنم و... در همین حین کاری که توی لب انجام می‌شد، توجهم رو جلب کرد و آروم‌آروم درگیر شدم. اول تو پروسه‌ی انتخاب و دعوت تسترها یا Recruitment، بعد از اون سراغ نوشتن سناریوی تست‌ها رفتم، قدم بعدی به‌عنوان مدیریتور تست وارد شدم و کم‌کم وارد مبحث یوایکس و تست کاربردپذیری و… شدم.
چطور در مورد نحوه‌ی برگزاری تستهای کاربردپذیری اطلاعات جمع کردی؟
- بخش زیادی رو از تجربه‌‌های ندا گلشن و غزل شیشوانی استفاده کردم، اون‌ها قبلاً این کار رو انجام داده بودند. این قضیه تقریبا مربوط به سال 93 میشه و این چیزها اون‌موقع خیلی جدید بود. فقط یکی دو جای دیگه توی ایران تست کاربردپذیری انجام می‌دادند و اون‌ها هم تو اسکیل خیلی بزرگ کار می‌کردند؛ مثلاً لب شیشه‌ای دوطرفه و یک‌طرفه داشتند. کارشون اصلاً تو حدود کار استارتاپی نبود و تستهای خیلی طولانی برگزار می‌کردند که بیشتر حالت فوکس گروپ داشت تا کاربردپذیری. در کل منبع داخلی زیادی براش وجود نداشت. از روی منابع آنلاین تونستیم بفهمیم تستهای کاربردپذیری دقیقا چیه. تجربهای که تو هر تست به دست می‌آوردیم، تو تست بعدی بهمون کمک می‌کرد. یک تست برگزار می‌کردیم، چیزهای جدیدی یاد می‌گرفتیم و تو تست بعدی اون‌ها رو پیاده می‌کردیم.
اولین تستی که گرفتی رو یادت هست؟
- اولین تستی که من توش مشارکت کردم تست کافه بازار بود. اولین تستی هم که خودم برگزار کردم، فکر می‌کنم تست کافه بازار یا دیجی‌کالا بود و تو ساختمون سرآوا تست رو گرفتیم.
تو تست کافه‌بازار چه کارهایی انجام دادی؟
- راه‌انداختن لب و ابزارها و این جور چیزها کلاً با من بود. قبل تست خیلی نقشی نداشتم و به جز راه‌انداختن لب کاری نکردم. لب ما دو تا اتاق بود، یک اتاق تست و یک اتاق مانیتورینگ. من خودم در طول تست، تو اتاق مانیتورینگ بودم و در اصل پل ارتباطی اتاق مانیتورینگ و اتاق تست بودم. وظیفه‌ی اصلیم هم این بود که مشکلات فنی که در طول تست پیش می‌اومد رو برطرف کنم. این‌جوری بود که وارد این فرآیند شدم و تازه این جا بود که فهمیدم منظور از تجربه‌ی کاربری چیه. قبل از این یک چیزایی شنیده بودم ولی تا حالا تست نگرفته بودم. اون‌جا اولین باری بود که دیدم وقتی محصول اشکال داره، قیافه‌ی کاربر چه شکلی میشه. از این‌جا بود که دیگه برام جذاب شد. کم‌کم به بچه‌هایی که کار مانیتورینگ تست رو انجام می‌دادند کمک می‌کردم. گاها سوال‌هایی براشون پیش می‌اومد و من به کمک تجربه‌ی تستهای قبلی راهنمایی‌شون می‌کردم. هم‌زمان شروع کردم در مورد تستهای کاربردپذیری خوندن. این طوری شد که کم‌کم وارد پروسه‌ی انتخاب و دعوت تسترها و نوشتن سناریو هم شدم. بعد از اون چون توی مانیتورینگ بودم و روند کلی تست‌ها رو می‌دونستم، وارد جلسه‌های ریویوی تست شدم؛ اینطوری بود که وارد بازی یوایکس و طراحی محصول و تستهای کاربردپذیری شدم.
تاثیر تستهای کاربردپذیری
به‌عنوان یک برنامه‌نویس، تستهای کاربردپذیری چه تاثیری روی تو داشت؟
- خیلی برام جالب بود. در اصل میشه گفت یک تحول در من ایجاد کرد. یک برنامه‌نویس همیشه یک طرف میز نشسته و اصلا به اون طرف میز و کاربر فکر نمی‌کنه. نکته‌ی جالبش هم این بود که توی همه‌ی جلسات تست، برنامه‌نویس‌ها تو اتاق مانیتورینگ حضور دارند و بعد از مدتی من خودم رو باهاشون مقایسه می‌کردم و می‌فهمیدم دید من هم قبلا مثل این بچه‌ها بوده ولی الان دیگه تغییر کرده. سوال مهم اینه تویی که پشت میز نشستی و روی یک محصول کار میکنی، اصلا میدونی کاربر محصولت کیه؟ چه‌جوری ازش استفاده می‌کنه؟ چه حسی ازش می‌گیره؟ این بود که کم‌کم اومدم اون‌طرف میز و سعی کردم کاربر رو هم در نظر بگیرم، و حین برنامه‌نویسی مدام به این فکر می‌کردم دلیل ساختن این قسمت چیه؟ به کاربر کمک می‌کنه؟ این تجربه‌ایه که خیلی‌ها ندارند؛ کسانی که فقط برنامه‌نویسی می‌کنند یا کسانی که فقط طراحی محصول می‌کنند، هر دو طرف رو نمی‌بینند. این برای من خیلی جالب بود و دلیل اصلی اینکه چرا یک محصول رو می‌سازیم رو متوجه شدم. اینکه برای خودت محصول رو درست نمی‌کنی و برای یک سری کاربر واقعی، یک سری آدم که قراره ازش استفاده کنند می‌سازیش روی من خیلی تاثیر گذاشت. این موضوع رو بعد از آشنایی با تستهای کاربردپذیری و وقتی که وارد مفهوم طراحی محصول شدم یاد گرفتم.
سال 94 که برای اولین‌بار می‌خواستیم روی زورق تست بگیریم، تیم شما تست رو برگزار کرد. تو قبلش گفتی اتفاقی که در اتاق مانیتورینگ می‌افته خیلی جالبه و همه‌تون شوکه و عصبانی می‌شوید و عذاب‌وجدان می‌‌گیرید. و واقعاً هم همه‌ی این‌ها برامون ایجاد شد.
- فکر کنم تست اول زورق بود که یک نفر روی کیبورد مشت کوبید.
و یکی از یوزرها هم فحش داد.
- آره، این هم خیلی جالب بود. یک تجربه‌ی خیلی جالب دیگه هم داشتیم، مربوط به یک وب‌سایتی می‌شد که یک سری از اطلاعات قسمت پایین یک صفحه قرار داده شده بودند و کاربر بعد از سه تا اسکرول صفحه به پایین تازه می‌تونست اون اطلاعات رو ببینه. توی تست کاربر پنج دقیقه داشت توی صفحه‌ها می‌چرخید، صفحه‌های دیگه رو اسکرول می‌کرد تا پایین ولی تا لبه‌ی جایی که این اطلاعات رو گذاشته بودند پایین می‌رفت. مثلاً صفحهی درباره‌ی ما رو تا ته پایین می‌رفت، ولی اون صفحهی خاص رو تا نصفه پایین می‌اومد و دیگه از اون پایین‌تر نمی‌رفت. این طرف بچه‌ها تو اتاق مانیتورینگ داد می‌زدند «برو پایین، برو پایین، تو رو خدا برو پایین». پنج دقیقه این دیالوگ تو اتاق مانیتورینگ تکرار شد. سر تست نسخه‌ی قبلی دیوار هم اتفاق جالبی افتاد. توی وبسایت دیوار از این همبرگر منوها گذاشته بودند. از پنج نفری که تست گرفتیم یک نفر هم روی منو کلیک نکرد. آخرین نفر لحظه‌ی آخر اتفاقی کلیک کرد؛ تا کلیک کرد بچه‌ها تو اتاق مانیتورینگ داد زدند:« آخ‌جون!». قبل از تست فکر می‌کردند این منو هیچ مشکلی نداره و انتظار داشتند همه خیلی راحت ازش استفاده کنند. برای همین چیزهاست که اتفاقاتی که تو اتاق مانیتورینگ می‌افته، تحولی درون آدم‌ها ایجاد می‌کنه و این دقیقا اتفاقیه که برای خود من هم افتاد. فهمیدم چیزی که به نظر تو ممکنه خیلی منطقی و طبق روال باشه و با خودت بگی همه باید روی این کلیک کنند قاعدتا، تو واقعیت اتفاق نمیفته. بعد از تست کاربردپذیری، این تحول رو برنامه‌نویس‌ها و دیزاینرهای یک محصول تجربه می‌کنند. من همیشه اتاق مانیتورینگ رو به اتاق تست ترجیح می‌دم.
اتاق تست خیلی فضای سنگینی داره.
- آره، مخصوصاً وقتی که مدیریتور هم باشی. می‌بینی کاربر عصبانیه، جاهای مختلف کلیک می‌کنه و چیزی که می‌خواد رو پیدا نمی‌کنه، گیج شده و مدام از تو کمک می‌خواد و تو هم نباید چیزی بهش بگی. لبخند می‌زنی و می‌گی معمولاً در این مواقع چه کار میکنی؟ خودت چی فکر میکنی؟
زمان و تعداد مناسب تستهای کاربردپذیری
با توجه به تجربه‌ات، به نظرت بهترین زمان برای تست گرفتن کیه؟
- ما تا به حال از سه‌چهار مرحله‌ی مختلف تست گرفتیم: بعد از لانچ، مثلاً هفته‌ی اول و دوم بعد از لانچ؛ یکی دو هفته قبل از لانچ، روی نسخه‌ای که می‌خواد لانچ بشه ؛ و هم‌چنین روی پروتوتایپ. جذاب‌ترین تست کاربردپذیری که تا حالا گرفتیم این بود که به جای اینکه از محصول یک شرکت تست بگیریم، از محصول رقیبش تست گرفتیم. این کار به کسی که می‌خواد محصول رو طراحی کنه کمک می‌کنه ببینه محصول رقیبش چه حسی به کاربر میده و چه اشکالاتی داره که محصول خودش می‌تونه اون‌ها رو برطرف کنه. در کل از نظر من زمان تست گرفتن خیلی فرق نمی‌کنه. تو این‌سال‌ها خیلی تست گرفتیم، انقدر زیاد که اصلاً عددش هم یادم نمیاد، ولی تو هیچ‌کدوم از تست‌هایی که تا حالا گرفتیم پیش نیومده که بعد از تست نتیجه بگیریم محصول خوب بود و هیچ مشکلی نداشت. بدون استثناء یا لانچ به تاخیر افتاده، یا پروژه تغییر کرده، یا یک سری چیزها به محصول اضافه شده یا دست‌کم اولویت بک‌لاگ عوض شده؛ یعنی اولویت چیزهایی که تیم می‌دونست اشکال داره ولی فکر نمی‌کرد اهمیت داشته باشه بالا برده شد..
"تو هیچ‌کدوم از تست‌هایی که تا حالا گرفتیم پیش نیومده که بعد از تست نتیجه بگیریم محصول خوب بود و هیچ مشکلی نداشت. بدون استثناء یا لانچ به تاخیر افتاده، یا پروژه تغییر کرده، یا یک سری چیزها به محصول اضافه شده"
برای همین به نظر من اصلاً فرقی نمی‌کنه کی تست بگیری، مهم‌ترین نکته اینه که زیاد تست بگیری. یعنی زمان خاصی برای تست گرفتن وجود نداره. یک ماتریسی در مورد اتفاقاتی که توی تست می‌افته وجود دارد که میگه یک سری چیزها رو از قبل می‌دونستی، با تست گرفتن مطمئن می‌شی؛ جواب یک سری سوال‌ها رو که از قبل داشتی پیدا میکنی؛ و یک سری چیزها رو هم تازه متوجه می‌شی و برات سوال به وجود می‌آد. قسمت جذاب تستهای کاربردپذیری همین جاست. تمرکز همه‌ی تستهای کاربردپذیری بیشتر رو این قسمت آخره، چون برای حل بقیه‌ی موردهایی که گفتم راه‌های دیگه‌ای هم وجود داره؛ مثلا می‌تونی برای پیدا کردن جواب سوال‌هات ریسرچ کنی یا از آدم‌های دیگه بپرسی و یا حتی خودت محصول رو تست کنی. اما اینکه یک سری مشکلاتی رو پیدا کنی که قبلا اصلاً بهش فکر نکرده بودی، بخش جذاب تستهای کاربردپذیریه و جالبیش هم اینه که تو تمام مراحل هم می‌تونه به وجود بیاد. چیزی که بین همه جا افتاده اینه که هروقت سوالی داشتی یا جواب چیزی رو نمی‌دونستی تست کاربردپذیری بگیر، ولی به نظر من هر زمانی که تست بگیری، چیز جدیدی رو کشف میکنی. برای همین به نظر من اینکه تعداد زیادی تستهای کوچک بگیری، بهتر از اینه که سالی یک بار یک تست بزرگ لاکچری بگیری.
"اینکه تعداد زیادی تستهای کوچک بگیری، بهتر از اینه که سالی یک بار یک تست بزرگ لاکچری بگیری."
اینکه قبل از ریلیز محصول تست بگیری هم کار خیلی خوبیه. یه حالت دیگه‌ش هم قبل از ری‌دیزاین محصوله؛ از محصول قبلیت تست می‌گیری تا تصمیم بگیری تو ری‌دیزاین چه چیزهایی رو تغییر بدی.
این مورد رو یادت هست تو تست کدوم محصول تجربه کردی؟
- فکر کنم یکی از تستهای اپلیکیشن زورق بود. برای کافه بازار و دیوار هم قبل ری‌دیزاین تست گرفتیم. برای دیوار دو بار تست گرفتیم. یک‌بار قبل از ری‌دیزاین و یک بار هم بعد از ریلیز. یکی از خوبی‌های تست گرفتن بعد از ریلیز اینه که زمان ریلیز تغییر نمی‌کنه. اگر قبل ریلیز تست بگیری، قطعا بک‌لاگت تغییر می‌کنه. معمولا تیم‌ها قبل از ریلیز فکر می‌کنند محصول‌شون درسته و مشکلی نداره، اما تست کاربردپذیری باعث میشه زمان ریلیز حداقل دو سه هفته، یا دو اسپرینت، عقب بیفته. یه خوبی دیگه انجام تست بعد ریلیز اینه که محصول لانچ شده و معمولاً بعد از لانچ، بک‌لاگ‌ها خالی هستند یا چیز خیلی سنگینی ندارند، به همین خاطر این واقعاً زمان خوبی برای تست گرفتنه.
یه نکته‌ای که زیاد بهش اشاره میشه اینه که اول باگ‌های بزرگ محصولت که از قبل میدونی وجود دارند رو رفع کن، بعد تست بگیر. چقدر با این موافقی؟
- کاملا موافقم. فکر می‌کنم سر تست وبسایت زورق و یک تست دیگه هم این اتفاق افتاد و تاریخ تست‌مون رو جابه‌جا کردیم. معمولا بعد از نوشتن سناریوی تست کاربردپذیری، یک گوریلا تست1 از سناریو می‌گیریم تا باگ‌های بحرانی محصول که مانع کار کاربر میشوند رو دربیاریم. چند مورد داشتیم که قبل از شروع تست بهشون گفتیم چند تا باگ رو رفع کنند. اکثرا باگ‌هایی بود که تیم کنترل کیفیت محصول باید قبل از این‌ها پیداشون می‌کرد. این موارد ارتباطی به تجربه‌ی کاربر و تستهای کاربردپذیری نداره. اگه قبل از تست این باگ‌های بحرانی رو برطرف نکنی، همه‌ی کاربرها حین تست گیر می‌افتند و نمی‌توانند تست رو جلو ببرند. در نتیجه تست نتیجه‌ای نخواهد داشت و فقط وقت تلف کردن خواهد بود. برای همین در این موارد یکی دو هفته تست رو عقب می‌انداختیم تا اون باگ رفع بشه و بعد بتونیم طبق سناریو تست رو جلو ببریم و واقعا تجربه‌ی کاربری رو تست کنیم. خیلی‌ها میخوان تست کاربردپذیری رو تیم کنترل کیفیت خودشون بگیره، ولی موضوع اینه که ما دنبال این نیستیم که باگ‌های فنی محصول رو پیدا کنیم. اتفاقاً خیلی از باگ‌های فنی تو تستهای کاربردپذیری پیدا نمی‌شوند. کسی که تو تیم کنترل کیفیت کار تست رو انجام میده، تخصصش پیدا کردن باگه. مثلا کاربر عادی وقتی ایمیلش رو وارد می‌کنه هیچ‌وقت دوتا @ نمی‌گذاره تا ببینه چه اتفاقی می‌افته. ولی کسی که کار تست می‌کنه، این موارد را هم برای تست در نظر می‌گیره. به همین دلیل احتمالش خیلی کمه که این باگ‌ها تو تستهای کاربری پیدا بشوند.
موقع تست باگ‌های جذاب هم کشف کردیم؛ یک تستی بود که برای انجام سناریو کاربر باید به درگاه بانک می‌رفت و پرداخت انجام می‌داد. قبل از ورود به درگاه بانک و در صفحه ورود مشخصات، آخرین فیلد آدرس خریدار بود. کاربرها برای وارد کردن آدرس کیبورد رو فارسی می‌کنند در نتیجه وقتی وارد درگاه بانک می‌شدند، کیبورد فارسی بود. درگاه بانک سامان اون موقع یه باگ عجیب داشت که اگر تو فیلد شماره کارت اعداد رو فارسی وارد می‌کردی، هنگ می‌کرد. این باگ بانک سامان بود و دست ما نبود که حلش کنیم. این جور باگ‌ها چیزی نیست که خودت بتونی پیدا کنی، چون وقتی تیم کنترل کیفیت تست می‌گیره هیچ‌وقت آدرس رو فارسی تایپ نمی‌کنه، همیشه تو این جور فرم‌ها برای تست همه‌ی فیلدهارو abab می‌زنن و رد میشوند. این برای خودم باگ خیلی جذابی بود، چیزی که خودمون نه موقع نوشتن و نه موقع تست سناریو پیداش نکرده بودیم. تو تست اول و دوم که این مشکل به وجود اومد متوجهش شدیم و چون من تجربه فنی داشتم فهمیدم که مشکل می‌تونه از این قسمت باشه. به تسترهای بعدی توضیح دادیم که این‌جا کیبوردت رو انگلیسی کن و بعد اطلاعاتت رو وارد کن.
یادت هست بعد از تست برای رفع کردن این باگ به چه راه‌حلی رسیدین؟
- آره، فیلد ایمیل رو آوردیم پایین که آخرین قسمتی که کاربر وارد می‌کنه ایمیل باشه و در نتیجه تو درگاه بانک کیبورد کاربر انگلیسی باشه. البته اینکه کاربر برای پر کردن فرم چندبار مجبور می‌شد کیبورد رو از فارسی به انگلیسی تغییر بده تجربه‌ی خوبی نبود، ولی سریع‌ترین راهی که داشتیم این بود.
گفتی برای فهمیدن باگ‌های احتمالی سناریوهایی که نوشتیم، گوریلا تست بگیریم. می‌تونی راجع‌به گوریلا تست توضیح بدی؟
- خیلی‌ها به اشتباه فکر می‌کنند گوریلا تست، همون تست کاربردپذیریه اما بی‌نهایت فرق می‌کنه. خروجی‌‌اش اصلاً یه‌چیز دیگه‌ست. واقعاً هر صد تا گوریلا تستی که می‌گیری باید ده تا تست کاربردپذیری بگیری، حتی اگه نشد لااقل یکی رو باید بگیری. گوریلا تست خیلی می‌تونه به بهبود دیزاین کمک کنه. گوریلا تست شاید رو محصول اصلی خیلی کمک نکنه، و احتمالا تست کاربردپذیری گزینه‌ی بهتری باشه. ما تا به حال روی پروتوتایپ هم تست کاربردپذیری گرفتیم. ولی اون‌قدر ارزش نداره، چون کاربر نمی‌تونه واقعاً تجربهای داشته باشه مگر اینکه پروتوتایپ واقعا کامل باشه و بخش‌های مختلفش کار کنه. که این هم هزینه‌ی ساخت بالایی داره. تست کاربردپذیری بیشتر تجربه‌ی کاربری رو می‌سنجه تا اینکه بخواد کاربرپسند بودن رو بسنجه. تستهای کاربردپذیری اصول ثابتی دارند و خیلی راحت میشه با چند تست ساده به نتیجه‌ای که دنبالش هستی برسی. با تست کاربردپذیری می‌تونی ببینی کاربر حین کار با محصول عصبانی شده، یا می‌تونی ببینی وقتی کاربر تو محصول گم شده از یه دکمه خاص استفاده می‌کنه یا نه. این چیزیه که با گوریلا تست امکان سنجشش وجود نداره. چون تو گوریلا تست کاربر اصلاً حسی به محصول نداره، فقط یک دیزاین بهش نشون می‌دی و می‌پرسی: «وقتی این صفحه رو ببینی اولین کاری که میکنی چیه؟ از این دیزاین چی می‌فهمی؟». یعنی تو تست کاربردپذیری فلوی کاربر و حسی که کاربر داره هم وارد میشه. اما حس کاربر وارد گوریلا تست نمیشه و برای همین جنس این دوتا تست کاملا متفاوته و جایگزین هم نیستند. نمی‌تونی بگی من دائم گوریلا تست می‌گیرم، پس نیازی به تست کاربردپذیری ندارم.
"حس کاربر وارد گوریلا تست نمیشه و برای همین جنس این دوتا تست کاملا متفاوته و جایگزین هم نیستند. نمی‌تونی بگی من دائم گوریلا تست می‌گیرم، پس نیازی به تست کاربردپذیری ندارم. "
سناریوی تستهای کاربردپذیری
می‌تونی در مورد سناریوی تستهای کاربردپذیری توضیح بدی؟ من یادمه برای تستهای زورق چیزی که گفتم این بود که فلوی هتل باید روی یک تاریخی تست بشه که بعداً امکان کنسلی داشته باشه. سناریویی که شما نوشتین این بود که «می‌خوای از تاریخ فلان تا فلان بری مسافرت و بودجه‌‌ات انقدره، هتل مورد علاقه‌ات رو رزرو کن»، یعنی سناریو یک پیش‌زمینه‌ای به تستر می‌داد که باعث می‌شد تصور کنه واقعا می‌خواد بره سفر و این‌جوری حس کاربر تا جای ممکن واقعی می‌شد.
- ببین نوشتن سناریوی تست کاربردپذیری چند تا نکته‌ی خیلی مهم داره. یکی اینکه نباید به کاربر بگی چه کاری رو انجام بده. چون اگر به کاربر بگی میره دقیقا همون کار رو انجام میده و در نتیجه یک سری مشکلات به وجود میاد. مثلا اگر به کاربر بگی: «محصولت رو پیدا کن، به علاقه‌مندی‌هات اضافه‌اش کن یا بوکمارکش کن»، کاربر دقیقاً می‌دونه باید دنبال چی بگرده و خیلی راحت پیداش می‌کنه. در صورتی که تو حالت عادی کاربر اصلاً این کار رو انجام نمی‌ده، چون نمی‌دونه فیوریت کردن چیه، بوک‌مارک چیه. به همین دلیل برای اینکه نتیجه‌ی تست واقعی در بیاد باید کاربر رو تو سناریوی واقعی بگذاری. مثلاً من یه مثال از تست دیوار بزنم، توی تست دیوار یکی از چیزهایی که یو‌آی می‌خواست تست بکنه، دقیقاً همین بوک‌مارک بود. ما به کاربر نگفتیم که بوکمارکش کن. کاربر دو تا راه داشت، یکی این بود که بوک‌مارک کنه، یکی دیگه اینکه شیر کنه. با دو تا سناریو این تست رو جلو بردیم، یک سناریو این بود که می‌خوای یک دوربین بخری، سرچ کن دوربینت رو پیدا کن و از دوستت مشورت بگیر، دفعه‌ی بعدی سناریو همین بود با این تفاوت که این بار از همکارت مشورت بگیری، مثلا فردا می‌خوای توی ساعت کاری دوربین رو بهش نشون بدی و نظرش رو بپرسی. همه‌ی تسترها یوآرال صفحه رو کپی می‌کردند و توی تلگرام برای دوستشون می‌فرستادند، به جز یک نفر که یوآرال رو کپی کرد و توی تلگرام برای خودش فرستاد و یک جورهایی میشه گفت بوکمارکش کرد. با این سناریو می‌تونی بفهمی کاربرهات اصلاً فیچر بوک‌مارک وبسایت رو پیدا نمی‌کنند. اما اگر تو تست به کاربر بگی بوکمارکش کن، دنبال علامتی که قبل از این به عنوان بوک‌مارک دیده و براش آشناست می‌گرده، مثلا ستاره یا آیکونی که شبیه برگ و یا گیره یا صفحه‌ای که لبه‌اش برگشته باشه. آدم‌ها با اشتراک گذاری هم کاملا آشنا هستند و اگر توی سناریو بگی «به اشتراک بگذار» آدم‌ها خیلی سریع این فیچر رو پیدا می‌کنند. ولی اگر بهشون بگی این رو برای دوستت بفرست و نظرش رو بپرس، همون کاری رو می‌کنه که واقعا تو حالت عادی انجام میده. برای همین باید کاربر رو تو یک سناریوی واقعی بگذاری.
البته اولش واقعا به نظر میاد این کار عملی نیست و آدم‌ها تو اون جو قرار نمی‌گیرند ولی تجربه نشون داده تسترها خیلی جدی‌اند. فکر می‌کنم تست وبسایت بامیلو بود که از کاربر خواسته بودیم کالایی رو سفارش بده و بعد پس بده. با اینکه پولش رو هم خودمون داده بودیم ولی کاربر خیلی جدی با پشتیبانی بامیلو دعوا می‌کرد که من نمی‌خواهم این محصول رو و اگر بیارین در خونه، تحویل نمی‌گیرم. تسترها خیلی جدی می‌گیرند. یک بار هم سر تست دیوار از کاربر خواسته بودیم گوشیش رو برای فروش بگذاره روی دیوار و در حین تست یک نفر که می‌خواست گوشیش رو بخره بهش زنگ زد و تستر هم واقعا شروع کرد چونه زدن. ما هم این‌جوری بودیم که حالا واقعا نمی‌خواد گوشیت رو بفروشی.
یک نکته‌ی دیگه هم که وجود داره اینه که برای نوشتن سناریوی تست نباید خیلی روی چیزی که تیم اون محصول میگه، تکیه کنی. بلکه باید بگردی ببینی باگ‌های محصول بیشتر کدام قسمت هستند و از اون‌ها تست بگیری. ولی اون هم باز برمی‌گرده به مهارت کسی که سناریوی تست رو می‌نویسه و توانایی‌اش برای پیدا کردن باگ‌ها و متمرکز کردن سناریو روی اون بخش. مثلاً برای تست دیجی‌کالا قرار بود پروسه‌ی خرید رو چک کنیم و برای همین باید از کاربر خواسته می‌شد حین تست کالایی رو بخره. ما تو سناریو از کاربر خواستیم کوله‌ی بچگانه بخر. محصولی رو انتخاب کرده بودیم که وقتی کاربر سرچ می‌کرد کوله‌ی بچگانه، وبسایت لباس بچه می‌آورد و کاربر نمی‌تونست نتیجه‌ی سرچ رو به کوله محدود کنه. در نتیجه تستر برای پیدا کردن کوله بچگانه به مشکل می‌خورد. یک وقت‌‌هایی هست با اینکه سوال مشخصی نداری اما میدونی جایی مشکل داره. این جور مواقع حتی بدون داشتن یک سوال مشخص توی ذهنت، با یک سناریوی خوب می‌تونی مشکل رو پیدا کنی. برای ما علامت سوال این بود که وقتی کاربر به کمک سرچ نمی‌تونه کوله‌ی بچگانه رو پیدا کنه چه کار می‌کنه؟ مثلاً تا صفحهی پنج میره که کوله‌ی بچگانه رو پیدا کنه یا سرچ رو بی‌خیال میشه و میره توی قسمت دسته‌بندی تا از یک راه دیگه جواب سوالش رو پیدا کنه. برای همین حین نوشتن سناریو خیلی اهمیت داره دو تا مورد رو در نظر بگیریم: یکی اینکه سناریو از نظر ساختار محصول واقعا سخت باشه، و یکی دیگه اینکه تو سناریو، تستر رو راهنمایی نکنیم.
ادامه دارد...
1- تست‌هایی غیررسمی که برخلاف سایر تستهای معمول، برای برگزاری نیازی به محیط استاندارد ندارند. به کمک این تست‌ها می‌توان در محیط‌هایی غیررسمی مثل مترو، کافه یا مهمانی از افراد عادی بر روی محصول خود تست بگیرید. این تست‌ها بر روی همه چیز، از طرح مدادی گرفته تا یک وبسایت کاملا آماده، گرفته میشوند.
مطلبی دیگر از این انتشارات
نمونه سناریوهای تستهای کاربردپذیری
مطلبی دیگر از این انتشارات
چگونه به تردیدها در مورد تستهای کاربردپذیری پاسخ دهیم
مطلبی دیگر از این انتشارات
راهنمای نام پکیج اپلیکیشن در روند ثبت تست در تستادی