چطور یک آزمایش بتا برای اپلیکیشن‌مان اجرا کنیم

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

بتا عرضه نرم نیست. یک آزمایش ساختاریافته است با شروع، پایان و یک سؤال مشخص برای پاسخ.

بتا کجا جا می‌گیرد

اعتبارسنجی می‌پرسد آیا مشکل ارزش حل کردن دارد. بتا سؤال باریک‌تری می‌پرسد: آیا این نسخه از محصول این مشکل را برای آدم‌های واقعی در شرایط واقعی حل می‌کند؟ راه‌اندازی بعد از آن می‌آید، وقتی پاسخ تا حد زیادی بله است.

پیش از دعوت از کسی، خودتان اول آزمایش کنید — چطور اپ را پیش از عرضه تست کنیم این را پوشش می‌دهد. تست‌کننده‌ها نباید اولین کسانی باشند که کشف می‌کنند ثبت‌نام خراب است.

گام ۱: بنویسید بتا باید به چه سؤالی جواب دهد

دو یا سه سؤال انتخاب کنید. بقیه برنامه از آن‌ها پیروی می‌کند.

مثال ساختگی: یک اپ برنامه‌ریزی شیفت برای کافه‌های کوچک دو هدف دارد: «آیا یک مدیر می‌تواند بدون کمک، برنامه یک هفته را در اولین جلسه منتشر کند؟» و «آیا کارکنان در هفته دوم خودشان اپ را باز می‌کنند؟»

گام ۲: نوع بتا را انتخاب کنید

برای یک محصول اول، معمولاً یک بتای بسته با چند دور انتخاب درستی است.

گام ۳: تست‌کننده‌های مناسب را جذب کنید

بهترین تست‌کننده‌ها همین حالا مشکل را دارند، با کاربر هدف شما مطابقت دارند، و در بازه بتا وقت دارند اپ را امتحان کنند. جاهایی که می‌توانید پیدایشان کنید:

• فهرست انتظار یا فهرست ایمیل‌تان — چطور پیش از عرضه مخاطب بسازیم را ببینید.
• کسانی که هنگام اعتبارسنجی با آن‌ها مصاحبه کرده‌اید.
• جامعه‌های تخصصی که کاربران شما در آن جمع می‌شوند، با رعایت قوانین آن‌ها درباره تبلیغ.
• دعوت مستقیم از افرادی در شبکه‌تان که با پروفایل مطابقت دارند.

چند سؤال غربالگری بپرسید تا ترکیبی متنوع انتخاب کنید: نقششان، الان چطور مشکل را حل می‌کنند، با چه دستگاهی استفاده می‌کنند، و مشکل چه‌قدر پیش می‌آید. کسانی را دعوت کنید که پاسخ‌هایشان با کاربر هدف شما می‌خواند، و بتا را پر از بنیان‌گذاران دیگر نکنید، مگر اینکه خودشان کاربر هدف باشند.

الگوی دعوت

سلام [نام] — وقتی ثبت‌نام کردی از [مشکل] گفتی. دارم یک بتای خصوصی کوچک از [محصول] را باز می‌کنم که [نتیجه] را می‌دهد. از [شروع] تا [پایان] اجرا می‌شود. از تست‌کننده‌ها می‌خواهم حداقل هفته‌ای یک بار برای [کار واقعی] از آن استفاده کنند و هر جمعه یک گزارش کوتاه بدهند. در عوض، دسترسی رایگان در طول بتا و [قیمت بنیان‌گذار / دوره رایگان تمدیدشده] را می‌گیرند. علاقه‌مندی؟

زمان موردنیاز را صادقانه بگویید. افرادی که می‌دانند برای چه ثبت‌نام کرده‌اند، بازخورد بهتری می‌دهند.

گام ۴: کیت بتا را آماده کنید

پیش از رفتن اولین دعوت، این‌ها باید آماده باشند:

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

گام ۵: آن را در دورها اجرا کنید

دورها به شما اجازه می‌دهند مشکلات را پیش از رسیدن کاربران بیشتر رفع کنید.

در دور ۱، از دو یا سه تست‌کننده بخواهید وقتی برای اولین بار اپ را امتحان می‌کنند صفحه‌شان را به اشتراک بگذارند. ساکت بمانید و ببینید کجا مکث می‌کنند. این اغلب مفیدترین ساعت کل بتا است.

گام ۶: بازخورد را طبق یک ریتم جمع کنید

پیام‌های بی‌ساختار مثل «بازخوردی دارید؟» جواب‌های مبهم می‌گیرند. به جای آن از یک گزارش کوتاه و منظم استفاده کنید:

گزارش هفتگی (سؤال‌های ساختگی نمونه)

۱. این هفته برای چه کاری از [محصول] استفاده کردید؟ ۲. چه چیزی آزاردهنده یا گیج‌کننده بود؟ ۳. آیا چیزی کم بود که مانع تمام کردن یک کار شد؟ ۴. اگر دیگر نمی‌توانستید از آن استفاده کنید، چه احساسی داشتید؟ (خیلی ناامید / تا حدی / اصلاً) ۵. چیز دیگری؟

آنچه مردم می‌گویند را با آنچه انجام می‌دهند ترکیب کنید. کسی که می‌گوید عالی است ولی هرگز وارد نمی‌شود هم چیزی به شما می‌گوید.

گام ۷: آنچه می‌رسد را اولویت‌بندی کنید

هر بازخورد را در یک فهرست بگذارید و هفتگی مرتبش کنید.

در میانه بتا از افزودن امکانات بزرگ خودداری کنید. هر امکان جدید تشخیص اینکه هسته محصول کار می‌کند را سخت‌تر می‌کند.

گام ۸: حلقه را ببندید

تست‌کننده‌ها وقتی ببینند بازخورد استفاده می‌شود، بازخورد بیشتری می‌دهند.

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

گام ۹: تصمیم بگیرید آماده‌اید یا نه

پیش از شروع بتا معیارهای خروج را بنویسید، و در پایان صادقانه بررسی‌شان کنید. یک الگو:

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

اگر بیشتر خانه‌ها تیک خورده‌اند، به صیقل دادن آنبوردینگ و عرضه عمومی بروید. اگر استفاده برگشتی کم است، آن یک سؤال محصول است، نه فهرست باگ — پیش از عرضه به مصاحبه‌ها برگردید.

اجرای بتا با Mythex

اگر با Mythex می‌سازید، چند قابلیت به خوبی با بتا جور می‌شوند:

• لینک‌های پیش‌نمایش برای دور ۱. دکمه Share لینکی به پیش‌نمایش زنده شما می‌سازد که برای افرادی بدون حساب Mythex کار می‌کند، پس یک تست‌کننده زودهنگام می‌تواند کار ناتمام را پیش از منتشر کردن امتحان کند. برای هر گروه یک لینک بسازید و وقتی تمام شد پاکش کنید — مستندات پیش‌نمایش توضیح می‌دهد لینک‌ها چطور پروژه را بیدار می‌کنند و از اعتبار استفاده می‌کنند.
• برای دورهای طولانی‌تر منتشر کنید. یک اپ منتشرشده در آدرس خودش اجرا می‌شود، که برای تست‌کننده‌هایی که چند هفته از آن استفاده می‌کنند مناسب است.
• آزمایش اپ پیش از هر دور. در گفتگو /test را تایپ کنید تا عامل پیش‌نمایش شما را کلیک‌کنان امتحان کند و جریان‌های خراب را گزارش دهد؛ بررسی مفیدی پیش از دعوت هر کسی (مستندات آزمایش اپ).
• نقطه‌های بازیابی (Checkpoints). اگر یک رفع در میانه بتا چیزی را خراب کرد، به یک نقطه بازیابی قبلی برگردید.

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

پرسش‌ها