بازگشت به بلاگ
مقاله

۵ ابزار هوش مصنوعی که هزینه تست و QA قبل از لانچ را نصف می‌کنند

foundersproductlaunchstartup-iranai

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

۸ مرداد ۱۴۰۵
10 دقیقه
۲ بازدید
داشبورد گزارش داده روی صفحه لپ‌تاپ در حال تست نرم‌افزار

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


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


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


چرا QA قبل از لانچ سریع‌تر از آنچه فکر می‌کنید هزینه‌بر می‌شود

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


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


ابزار اول: Applitools؛ چشمی که هیچ مغایرت بصری را از دست نمی‌دهد

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


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


ابزار دوم: Testim؛ اتوماسیون تستی که خودش را ترمیم می‌کند

یکی از بزرگ‌ترین دلایلی که تیم‌های کوچک از اتوماسیون تست فرار می‌کنند این است که تست‌های خودکار سنتی با هر تغییر کوچک در رابط کاربری خراب می‌شوند و نگهداری آن‌ها خودش به یک پروژه جداگانه تبدیل می‌شود. Testim این مشکل را با قابلیتی به نام self-healing حل می‌کند: وقتی یک المان صفحه جابه‌جا یا تغییر نام پیدا می‌کند، هوش مصنوعی ابزار به‌جای متوقف کردن تست، الگوی جدید را تشخیص می‌دهد و مسیر تست را خودش به‌روزرسانی می‌کند.


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


ابزار سوم: mabl؛ تست کم‌کد برای تیم‌های بدون QA اختصاصی

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


مزیت دیگر mabl این است که تست‌ها را می‌توان مستقیماً در فرآیند استقرار (deployment) قرار داد، به این معنا که پیش از هر انتشار جدید، مجموعه‌ای از تست‌های حیاتی به‌طور خودکار اجرا می‌شوند و اگر مشکلی پیدا شود، تیم پیش از آن‌که کاربر واقعی متوجه شود از آن باخبر می‌شود. برای استارتاپی که قصد دارد آپدیت‌های محصول را به‌جای یک‌باره، مرحله‌ای و کنترل‌شده منتشر کند، این نوع تست خودکار پیش از هر مرحله انتشار، لایه ایمنی اضافه‌ای فراهم می‌کند که بدون آن ریسک هر آپدیت به‌مراتب بالاتر خواهد بود.


ابزار چهارم: Sentry؛ رصد هوشمند خطا درست بعد از انتشار

هیچ مجموعه تستی، هرچقدر هم دقیق، نمی‌تواند صد درصد رفتار کاربران واقعی را پیش‌بینی کند. به همین دلیل بخشی از استراتژی QA هوشمند باید روی لحظه بعد از لانچ هم متمرکز باشد، نه فقط لحظه قبل از آن. Sentry ابزاری است که خطاهای واقعی رخ‌داده در محیط تولید را به‌صورت زنده جمع‌آوری می‌کند و با استفاده از الگوریتم‌های هوش مصنوعی، خطاهای مشابه را در یک گروه دسته‌بندی می‌کند تا تیم به‌جای غرق شدن در هزاران خط لاگ، دقیقاً بداند کدام مشکل بیشترین کاربر را تحت تأثیر قرار داده است.


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


ابزار پنجم: BrowserStack؛ پوشش صدها دستگاه بدون خرید صدها گوشی

یکی از واقعی‌ترین چالش‌های تست محصول برای بازار ایران، تنوع بالای دستگاه‌ها و نسخه‌های سیستم‌عامل است؛ از گوشی‌های قدیمی‌تر اندروید گرفته تا آخرین نسخه آیفون. خرید فیزیکی همه این دستگاه‌ها برای یک تیم کوچک عملاً غیرممکن است. BrowserStack این مشکل را با فراهم کردن دسترسی ابری به هزاران ترکیب واقعی دستگاه و مرورگر حل می‌کند و با افزودن قابلیت‌های هوش مصنوعی برای تحلیل و اولویت‌بندی خودکار تست‌ها، به تیم کمک می‌کند بداند کدام ترکیب‌ها بیشترین ریسک را دارند.


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


چطور این پنج ابزار را در فرآیند لانچ خودتان بچینیم

نکته مهم این است که هیچ‌کدام از این ابزارها قرار نیست به‌تنهایی همه مشکلات را حل کنند؛ ارزش واقعی زمانی ظاهر می‌شود که آن‌ها را در نقاط مشخصی از فرآیند لانچ قرار دهید. معمولاً پیشنهاد می‌کنیم Applitools و mabl را در مرحله توسعه و پیش از هر merge کد اصلی اجرا کنید، Testim را برای تست رگرسیون کامل چند روز قبل از لانچ به کار بگیرید، BrowserStack را برای پوشش دستگاه‌ها در آخرین هفته پیش از انتشار فعال کنید، و Sentry را از همان لحظه انتشار تا هفته‌های بعد روشن نگه دارید. این ترتیب باعث می‌شود بودجه محدود شما دقیقاً جایی خرج شود که بیشترین بازده را دارد.


اگر پیش‌تر با ما همراه بوده‌اید، احتمالاً مقاله چگونه با هوش مصنوعی هزینه‌های استارتاپ را نصف کنیم را خوانده‌اید؛ همان منطق دقیقاً در حوزه QA هم صدق می‌کند. معمولاً بهترین رویکرد این نیست که منتظر بمانید محصول کامل شود و بعد به فکر تست بیفتید، بلکه باید از همان ابتدای ساخت MVP، لایه‌ای سبک از این ابزارها را فعال نگه دارید. همان‌طور که پیش‌تر در مقاله چرا کمال‌گرایی قبل از لانچ، قاتل MVP است نوشتیم، هدف رسیدن به تست کامل نیست، هدف کاهش ریسک تا سطحی قابل قبول با کمترین هزینه ممکن است.


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


به این مطلب امتیاز بدهیدامتیاز ۰ از ۵

پرسش‌های متداول

آیا این ابزارها می‌توانند به‌طور کامل جای تیم QA انسانی را بگیرند؟+

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

برای یک تیم دو یا سه نفره، شروع از کدام ابزار منطقی‌تر است؟+

معمولاً بهتر است ابتدا با Sentry شروع کنید، چون نصب سریع و ارزان دارد؛ سپس بسته به بودجه، یک ابزار تست پیش از انتشار مثل mabl یا Applitools را اضافه کنید.

آیا این ابزارها برای اپلیکیشن‌های فارسی و راست‌به‌چپ هم درست کار می‌کنند؟+

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

هزینه تقریبی استفاده از این ابزارها برای یک استارتاپ کوچک چقدر است؟+

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

آیا استفاده از این ابزارها نیاز به دانش برنامه‌نویسی دارد؟+

برای mabl و Applitools معمولاً نه، چون رابط کم‌کد یا بدون کد دارند؛ برای Testim و BrowserStack آشنایی حداقلی با مفاهیم تست نرم‌افزار کمک می‌کند.