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