نویسنده: مای محتوا
آموزش آزمایش فروشگاه اینترنتی قبل از انتشار عمومی با چک‌لیست کامل تست محصولات، سبد خرید، پرداخت موفق و ناموفق، موجودی، ارسال، پیامک، امنیت، سرعت، سئو و آنالیتیکس؛ همراه با سناریوهای عملی و برنامه ۷روزه.
فرض کنید طراحی فروشگاه اینترنتی شما تمام شده، محصولات را ثبت کرده‌اید و قرار است از فردا تبلیغات را شروع کنید. ظاهر سایت در نگاه اول مناسب است، اما هنوز مطمئن نیستید اگر مشتری رنگ دیگری انتخاب کند قیمت درست تغییر می‌کند، درگاه پرداخت بدون مشکل کار می‌کند یا بعد از خرید، موجودی کالا کاهش می‌یابد. انتشار عمومی بدون آزمایش این موارد می‌تواند باعث سفارش‌های ناقص، پرداخت‌های نامشخص، فروش کالای ناموجود و نارضایتی نخستین مشتریان شود.
آزمایش فروشگاه اینترنتی قبل از انتشار عمومی یعنی بررسی مسیر واقعی خرید، از ورود کاربر به صفحه محصول تا ثبت سفارش، پرداخت، صدور فاکتور، آماده‌سازی و اطلاع‌رسانی. در کنار این مسیر باید عملکرد موبایل، سرعت، امنیت، سئو و اتصال‌های جانبی نیز کنترل شوند. هدف این نیست که سایتی بدون امکان بروز خطا بسازید؛ هدف آن است که مشکلات مهم را پیش از ورود مشتری واقعی شناسایی و برطرف کنید.
در این مقاله، ۱۳ بخش اصلی آزمایش فروشگاه، سناریوهای خرید موفق و ناموفق، جدول اولویت خطاها، نمونه تست عملی و برنامه پیشنهادی هفت‌روزه را بررسی می‌کنیم. این راهنما برای فروشگاه‌های تازه‌راه‌اندازی‌شده، کسب‌وکارهایی که از شبکه‌های اجتماعی به سایت منتقل می‌شوند و فروشگاه‌هایی که قالب یا درگاه خود را تغییر داده‌اند کاربرد دارد.
یک فروشگاه ممکن است در صفحه اصلی کاملاً آماده به نظر برسد، اما بخش‌های حساس آن فقط هنگام خرید واقعی آزمایش شوند. برای مثال، ممکن است قیمت محصول درست باشد ولی هزینه ارسال پس از تغییر شهر محاسبه نشود. یا سفارش در پنل مدیر ثبت شود اما نتیجه تراکنش ناموفق به اشتباه پرداخت‌شده تشخیص داده شود.
از طرف دیگر، نخستین مشتریان معمولاً شناخت زیادی از برند شما ندارند. اگر در اولین تجربه با لینک خراب، محصول ناموجود یا خطای پرداخت روبه‌رو شوند، ممکن است فرصت ایجاد اعتماد از دست برود. برای همین بهتر است پیش از صرف بودجه تبلیغات، یک مسیر خرید کامل را از دید مشتری آزمایش کنید.
در راهنمای رسمی آماده‌سازی فروشگاه Shopify نیز بر ثبت سفارش آزمایشی و بررسی فرایند پرداخت، پردازش سفارش، موجودی و ارسال تأکید شده است. هرچند مراحل فنی پلتفرم‌های مختلف یکسان نیستند، اصل آزمایش عملی پیش از انتشار برای همه فروشگاه‌ها اهمیت دارد.
برای آنکه آزمایش قابل تکرار و نتیجه آن قابل بررسی باشد، بهتر است محیط مشخصی برای تست داشته باشید. اگر فروشگاه‌ساز یا درگاه شما حالت آزمایشی ارائه می‌کند، از همان روش رسمی استفاده کنید. اگر محیط آزمایشی مستقل ندارید، درباره روش ثبت سفارش تست و پاک‌سازی ایمن داده‌ها با پشتیبانی هماهنگ شوید.
حداقل تجهیزات پیشنهادی شامل یک گوشی اندرویدی، یک گوشی یا مرورگر دیگر در صورت دسترسی، یک رایانه، چند محصول نمونه، یک محصول دارای رنگ یا سایز متفاوت، یک محصول با موجودی محدود و یک نشانی آزمایشی برای محاسبه ارسال است. نیازی نیست برای شروع ده‌ها دستگاه تهیه کنید؛ مهم این است که مسیرهای متفاوت خرید را بررسی کنید.
| بخش آزمایش | سؤال اصلی | درجه اهمیت |
|---|---|---|
| صفحات محصول | مشخصات، قیمت و مدل درست هستند؟ | ضروری |
| موجودی | بیشتر از تعداد واقعی فروخته نمی‌شود؟ | حیاتی |
| سبد خرید | تعداد، تخفیف و مبلغ نهایی صحیح هستند؟ | حیاتی |
| درگاه پرداخت | تراکنش موفق و ناموفق درست تشخیص داده می‌شوند؟ | حیاتی |
| ثبت سفارش | سفارش فقط یک‌بار و با اطلاعات صحیح ثبت می‌شود؟ | حیاتی |
| ارسال | هزینه و محدودیت منطقه درست اعمال می‌شود؟ | ضروری |
| فاکتور و پیامک | اطلاعات سفارش صحیح اطلاع‌رسانی می‌شوند؟ | مهم |
| موبایل و سرعت | خرید روی گوشی بدون مشکل انجام می‌شود؟ | ضروری |
| امنیت و دسترسی | اطلاعات و بخش مدیریت محافظت می‌شوند؟ | حیاتی |
| سئو و ایندکس | صفحات عمومی برای جست‌وجو آماده‌اند؟ | مهم |
| ابزارهای تحلیل | خرید واقعی و آزمایشی درست ثبت می‌شوند؟ | مهم |
نخست از دید یک مشتری ناشناس وارد فروشگاه شوید. دسته‌بندی‌ها را باز کنید، محصولی را پیدا کنید و مشخصات آن را بخوانید. نام، مدل، تصاویر، قیمت، توضیحات، وضعیت موجودی و اقلام همراه باید صحیح و قابل فهم باشند. محصولات آزمایشی با نام‌های موقت، تصویر پیش‌فرض یا توضیح ناقص نباید به‌اشتباه در فروشگاه عمومی باقی بمانند.
برای محصولات دارای تنوع، فقط مدل پیش‌فرض را آزمایش نکنید. همه گزینه‌های مهم رنگ، سایز، ظرفیت و قیمت را تغییر دهید. بررسی کنید انتخاب هر تنوع، تصویر یا قیمت مربوط به همان مدل را نمایش می‌دهد و مشتری نمی‌تواند ترکیب نامعتبر یا ناموجود سفارش دهد.
سناریوی تست: یک کفش با سه سایز تعریف کنید؛ سایز اول موجود، سایز دوم ناموجود و سایز سوم دارای قیمت متفاوت باشد. هنگام تغییر گزینه‌ها، موجودی و قیمت را بررسی کنید. اگر سایز ناموجود همچنان قابل خرید است، فروشگاه آماده انتشار نیست.
برای ساختار درست این بخش، راهنمای مدیریت محصولات متغیر و چندقیمتی و اصول طراحی صفحه محصول حرفه‌ای را مطالعه کنید.
یکی از مهم‌ترین تست‌ها، رفتار موجودی در شرایط واقعی سفارش است. فرض کنید از محصولی پنج عدد دارید و دو عدد سفارش داده می‌شود. بررسی کنید سامانه در زمان تعیین‌شده برای رزرو یا تأیید سفارش، موجودی قابل فروش را درست اصلاح می‌کند. موجودی فیزیکی، موجودی رزروشده و تعداد قابل خرید ممکن است یکسان نباشند.
سپس سفارش را طبق فرایند رسمی لغو کنید و ببینید رزرو کالا در شرایط صحیح آزاد می‌شود یا نه. سفارش ناموفق نباید موجودی را برای همیشه کاهش دهد. همچنین اگر محصولی فقط یک عدد موجودی دارد، سیستم باید از فروش هم‌زمان همان آخرین واحد به چند سفارش جلوگیری کند.
نکته فنی: در برخی سیستم‌ها کالا هنگام شروع فرایند پرداخت موقتاً رزرو می‌شود و در برخی دیگر تخصیص آن در مرحله متفاوتی اتفاق می‌افتد. روش درست به معماری فروشگاه بستگی دارد. آنچه باید آزمایش شود جلوگیری از فروش بیش از موجودی، آزادسازی صحیح رزرو و جلوگیری از کسر دوباره است.
سبد خرید جایی است که مشتری درباره مبلغ نهایی تصمیم می‌گیرد. لازم است بتواند تعداد را افزایش یا کاهش دهد، کالا را حذف کند و قیمت نهایی تغییرات را ببیند. تخفیف و هزینه ارسال نیز باید با شرایط اعلام‌شده هماهنگ باشند.
حداقل این سناریوها را بررسی کنید: افزودن یک کالا، افزودن چند محصول متفاوت، تغییر تعداد، حذف یک قلم، انتخاب محصول دارای تخفیف، وارد کردن کد تخفیف معتبر، وارد کردن کد نامعتبر و تلاش برای سفارش تعداد بیشتر از موجودی. اگر کد تخفیف تاریخ یا حداقل مبلغ خرید دارد، شرایط آن را نیز آزمایش کنید.
مثال فرضی: مشتری محصولی به قیمت ۴۵۰ هزار تومان و کالای دیگری به قیمت ۲۵۰ هزار تومان به سبد اضافه می‌کند. جمع محصولات ۷۰۰ هزار تومان است. اگر تخفیف معتبر ۱۰ درصدی روی هر دو قلم و بدون سقف اعمال شود، مبلغ پس از تخفیف ۶۳۰ هزار تومان خواهد بود. سپس هزینه ارسال طبق قانون تعریف‌شده اضافه می‌شود. این مثال فرض می‌کند تخفیف روی تمام اقلام قابل اجراست؛ در فروشگاه واقعی، محدوده و سقف تخفیف باید دقیق بررسی شود.
اگر مبلغ سبد با قیمت صفحه محصول تفاوت بی‌دلیل دارد، باید علت آن پیش از انتشار مشخص شود. توضیح هزینه‌های نهایی نیز می‌تواند به کاهش تردید مشتری کمک کند. برای مطالعه بیشتر، راهنمای افزایش اعتماد و کاهش رها شدن سبد خرید را ببینید.
ممکن است فروشگاه برای یک شهر ارسال با پیک، برای شهر دیگر ارسال پستی و برای بعضی مناطق محدودیت خدمات داشته باشد. بنابراین محاسبه هزینه ارسال را فقط با یک نشانی آزمایشی بررسی نکنید. چند مقصد با شرایط متفاوت انتخاب و نتیجه را کنترل کنید.
اگر هزینه ارسال به وزن، مبلغ سبد یا تعداد کالا وابسته است، سناریوهایی برای مقادیر مرزی بسازید. برای نمونه، اگر ارسال رایگان فقط برای سبدهای بالای یک مبلغ مشخص فعال می‌شود، سبدی کمی پایین‌تر، دقیقاً برابر و کمی بالاتر از آستانه را امتحان کنید.
در برخی فروشگاه‌ها وزن یا ابعاد محصول ثبت نشده و محاسبه ارسال برای سفارش چندقلمی اشتباه می‌شود. قبل از انتشار، تکلیف کالاهای حجیم، شکستنی یا دارای روش حمل ویژه را روشن کنید. درباره تعیین هزینه و شرایط ارسال، راهنمای مدیریت هزینه ارسال فروشگاه اینترنتی کاربردی است.
عملکرد صحیح درگاه از مهم‌ترین شرط‌های انتشار عمومی است. تست پرداخت فقط به این معنی نیست که یک بار وارد صفحه بانک شوید. باید مطمئن شوید سفارش موفق پس از تأیید معتبر تراکنش ثبت می‌شود، پرداخت ناموفق موفق تلقی نمی‌شود و در صورت قطع ارتباط یا بازگشت ناقص از درگاه، وضعیت سفارش نامشخص و رهاشده باقی نمی‌ماند.
اگر ارائه‌دهنده درگاه محیط آزمایشی یا Sandbox دارد، از روش رسمی همان سرویس برای شبیه‌سازی استفاده کنید. در این محیط معمولاً می‌توان سناریوهای تأیید و رد تراکنش را بدون جابه‌جایی واقعی پول بررسی کرد؛ البته امکانات دقیق هر درگاه متفاوت است.
در صورت نیاز به آزمون با درگاه واقعی، ابتدا با ارائه‌دهنده پرداخت هماهنگ کنید و فقط تراکنش مجاز با مبلغ کنترل‌شده انجام دهید. بازپرداخت یا کارمزد احتمالی را نیز در نظر بگیرید. از اطلاعات کارت واقعی در محیط‌های نامطمئن یا روش‌های غیرمجاز استفاده نکنید.
قاعده حیاتی: صرف ورود کاربر به صفحه تشکر، مدرک قطعی پرداخت نیست. وضعیت باید از پاسخ معتبر و تأییدشده ارائه‌دهنده درگاه مشخص شود. برای شناخت مراحل اتصال و کنترل‌های مرتبط، راهنمای کامل درگاه پرداخت فروشگاه اینترنتی را مطالعه کنید.
پس از پرداخت موفق، بررسی کنید سفارش با شناسه یکتا در پنل ثبت شده و محصولات، تنوع‌ها، تعداد، مبلغ، تخفیف، هزینه ارسال و اطلاعات گیرنده صحیح هستند. سپس مراحل آماده‌سازی، بسته‌بندی و ارسال را طبق امکانات فروشگاه امتحان کنید.
اگر وضعیت سفارش قابل تغییر است، بررسی کنید چه تغییرهایی مجاز هستند و کدام اقدامات به تأیید بیشتری نیاز دارند. مثلاً سفارش لغوشده نباید بدون فرایند معتبر به‌صورت خودکار ارسال شود. اگر امکان بازپرداخت یا مرجوعی وجود دارد، ثبت مالی و موجودی آن باید جداگانه آزموده شود.
در فروشگاه‌های دارای چند مدیر یا کارمند، نقش‌ها را هم بررسی کنید. مسئول بسته‌بندی نباید صرفاً به دلیل نیاز به مشاهده سفارش، دسترسی مدیریت کل، اطلاعات محرمانه یا تنظیمات درگاه دریافت کند. برای سامان‌دهی این بخش، راهنمای مدیریت سفارش آنلاین را ببینید.
اگر پس از سفارش پیامک یا ایمیل ارسال می‌شود، محتوای آن باید با وضعیت واقعی خرید هماهنگ باشد. پیام «پرداخت با موفقیت انجام شد» نباید برای سفارش ناموفق فرستاده شود. همچنین شماره سفارش، مبلغ و راه ارتباط باید درست باشند و اطلاعات حساس غیرضروری در پیام قرار نگیرند.
اگر سایت امکان صدور یا چاپ فاکتور دارد، یک نمونه واقعی‌نما را باز کنید. نام کالا، مدل انتخابی، تعداد، مبلغ، تخفیف و مشخصات لازم فروشنده و خریدار را بررسی کنید. چاپ روی کاغذ A4 یا قالب مورد استفاده مجموعه نیز باید خوانا باشد.
تست پیشنهادی: یک سفارش دارای دو کالا و تخفیف ثبت کنید. فاکتور چاپی را با جزئیات پنل مقایسه کنید و سپس وضعیت پیامک را کنترل کنید. در صورت وجود اتصال پیامک، اعتبار پنل، محدودیت ارسال و مدیریت خطا را نیز بررسی کنید.
فروشگاه ممکن است در نمایشگر بزرگ بسیار منظم باشد، اما در موبایل دکمه خرید زیر بخش دیگری قرار بگیرد، جدول محصولات از صفحه بیرون بزند یا فرم نشانی به‌درستی کار نکند. بنابراین بررسی واکنش‌گرایی را صرفاً به کوچک کردن پنجره مرورگر محدود نکنید.
حداقل یک بار مسیر خرید را روی گوشی واقعی انجام دهید. منوی سایت، جست‌وجو، انتخاب سایز، نمایش قیمت، افزودن به سبد، ورود شماره تماس، انتخاب روش ارسال و بازگشت از درگاه را آزمایش کنید. همچنین روی مرورگرهای اصلی متناسب با مخاطبانتان تست انجام دهید.
به خوانایی متن، فاصله دکمه‌ها، صفحه‌کلید مناسب فیلد شماره تماس و قابلیت استفاده با لمس توجه کنید. اگر فروشگاه از شبکه‌های اجتماعی ورودی می‌گیرد، لینک محصول را در مرورگر داخلی همان برنامه نیز آزمایش کنید؛ زیرا رفتار باز شدن درگاه یا پنجره جدید ممکن است متفاوت باشد.
کندی صفحه محصول، تصویرهای بسیار بزرگ یا اسکریپت‌های غیرضروری می‌توانند تجربه خرید را دشوار کنند. قبل از انتشار، صفحه اصلی، دسته‌بندی، محصول، سبد خرید و مرحله تسویه را جداگانه بررسی کنید. یک نمره خوب در ابزار سرعت کافی نیست؛ باید عملکرد مسیر واقعی خرید هم مناسب باشد.
می‌توانید از PageSpeed Insights برای شناسایی مشکلات استفاده کنید. در ارزیابی تجربه کاربری، معیارهایی مانند LCP، INP و CLS نیز اهمیت دارند. بااین‌حال این اعداد به‌تنهایی فروش بیشتر را تضمین نمی‌کنند. برای بهبود عملکرد می‌توانید حجم تصاویر، کش مناسب صفحات عمومی، تعداد اسکریپت‌ها و منابع مسدودکننده نمایش را بررسی کنید.
احتیاط مهم: کش کردن اشتباه صفحه سبد یا اطلاعات شخصی کاربر می‌تواند باعث نمایش داده نادرست یا حتی افشای اطلاعات شود. بنابراین تنظیم کش باید متناسب با نوع صفحه و وضعیت ورود کاربران انجام شود. برای بررسی اهمیت زیرساخت، نقش سرعت هاست در فروشگاه اینترنتی را بخوانید.
قبل از انتشار باید مطمئن شوید سایت از HTTPS معتبر استفاده می‌کند، رمزها و کلیدهای محرمانه به‌صورت عمومی نمایش داده نمی‌شوند و دسترسی بخش مدیریت محدود است. رمزهای پیش‌فرض، حساب‌های آزمایشی اضافی و دسترسی‌های غیرضروری را اصلاح کنید. برای حساب‌های مدیریتی، رمز قوی و در صورت پشتیبانی احراز هویت دومرحله‌ای در نظر بگیرید.
اگر محیط آزمایشی جداگانه دارید، بهتر است آن را با احراز هویت مناسب محافظت کنید. از کپی کردن اطلاعات واقعی مشتریان به محیط آزمایشی بدون ضرورت و کنترل دسترسی خودداری کنید؛ داده‌های تست بهتر است ساختگی و غیرحساس باشند.
همچنین پیش از اعمال تغییرات نهایی، وجود نسخه پشتیبان قابل بازیابی و روش بازگردانی را بررسی کنید. داشتن فایل پشتیبان بدون آزمایش امکان بازیابی کافی نیست. اگر تست نفوذ یا بررسی امنیتی تخصصی لازم است، آن را با مجوز و در محدوده مشخص به متخصص بسپارید.
یکی از خطاهای مهم هنگام انتشار سایت تازه، باقی ماندن تنظیماتی است که برای محیط آزمایشی فعال شده‌اند. ممکن است در دوره طراحی، دسترسی عمومی یا ایندکس صفحات را محدود کرده باشید. پس از انتشار باید مطمئن شوید صفحات موردنظر برای کاربران و موتورهای جست‌وجو در دسترس هستند.
موارد مهم شامل عنوان مناسب صفحه اصلی و محصولات، توضیحات متا، ساختار آدرس‌ها، لینک‌های داخلی، نقشه سایت، آدرس canonical و پاسخ صحیح صفحات عمومی است. صفحات اصلی و محصولات قابل فروش نباید ناخواسته دارای دستور noindex باشند.
طبق مستندات رسمی Google Search Central درباره noindex، اگر صفحه با فایل robots.txt از خزش منع شده باشد، ربات ممکن است نتواند دستور noindex موجود در آن را مشاهده کند. بنابراین برای محرمانه نگه داشتن محیط آزمایشی، اتکا به robots.txt یا noindex به‌تنهایی راهکار امنیتی کافی نیست و بهتر است از کنترل دسترسی مناسب استفاده شود.
چک نهایی سئو: پس از انتشار، وضعیت دسترسی و ایندکس صفحات مهم را بررسی کنید، نقشه سایت معتبر ارائه دهید و در Google Search Console مالکیت دامنه را تأیید کنید. ثبت نقشه سایت یا Request Indexing به معنی تضمین ایندکس فوری همه صفحات نیست. برای شناخت این ابزار، آموزش سرچ کنسول فروشگاه اینترنتی را بخوانید.
اگر فروشگاه قرار است به ترب، باسلام، پنل پیامکی، نرم‌افزار حسابداری یا سرویس ارسال متصل شود، باید نوع اتصال و نحوه مدیریت خطا مشخص باشد. وجود نام یک سرویس در بخش امکانات به معنی فعال بودن همه قابلیت‌ها یا انتقال لحظه‌ای تمام اطلاعات نیست.
برای اتصال‌های مربوط به محصول، قیمت، موجودی، SKU و آدرس صفحه را بررسی کنید. اگر اتصال سفارش وجود دارد، مطمئن شوید سفارش دوبار ثبت نمی‌شود و خطای ارتباط باعث گم شدن داده‌ها نخواهد شد. در سرویس‌های بیرونی از روش‌های رسمی و مجاز آزمایش استفاده کنید و بدون هماهنگی، درخواست‌های انبوه یا تراکنش ساختگی ایجاد نکنید.
اگر سایت برای نمایش محصولات در ترب آماده می‌شود، می‌توانید راهنمای اتصال فروشگاه به ترب و باسلام را مرور کنید. ثبت‌نام، پذیرش و پردازش محصولات در هر پلتفرم ممکن است زمان جداگانه داشته باشد؛ بنابراین آغاز نمایش محصولات را به‌عنوان نتیجه قطعی روز انتشار فرض نکنید.
قبل از تبلیغات بهتر است بدانید ابزارهای تحلیل سایت چه داده‌هایی را ثبت می‌کنند. برای فروشگاه اینترنتی، رویدادهایی مانند مشاهده محصول، افزودن به سبد، شروع پرداخت و خرید موفق می‌توانند مسیر تصمیم مشتری را نشان دهند. اما این رویدادها الزاماً با نصب ساده یک ابزار تحلیلی به‌طور کامل فعال نمی‌شوند.
طبق راهنمای رسمی رویدادهای پیشنهادی Google Analytics 4، رویدادهایی مانند view_item، add_to_cart، begin_checkout و purchase برای تحلیل فروش اینترنتی استفاده می‌شوند و در صورت نیاز باید مطابق ساختار فروشگاه پیاده‌سازی و بررسی شوند.
بعد از ثبت سفارش آزمایشی، بررسی کنید مبلغ و شناسه سفارش درست ثبت می‌شوند و بازگشت چندباره به صفحه تشکر موجب ثبت چند خرید یکسان نمی‌شود. رویدادهای تست و ترافیک داخلی را نیز در گزارش‌های تحلیلی مشخص یا از تحلیل عملکرد واقعی جدا کنید؛ البته روش فیلتر باید با احتیاط انتخاب شود تا داده مشتریان واقعی به‌اشتباه حذف نشود.
| شماره | سناریو | نتیجه مورد انتظار |
|---|---|---|
| ۱ | باز کردن محصول ساده | عنوان، تصویر، قیمت و موجودی صحیح |
| ۲ | انتخاب مدل ناموجود | جلوگیری از خرید مدل ناموجود |
| ۳ | افزایش تعداد بیش از موجودی | نمایش محدودیت و جلوگیری از ثبت نامعتبر |
| ۴ | استفاده از کد تخفیف معتبر | محاسبه دقیق با رعایت شرایط کد |
| ۵ | استفاده از کد نامعتبر | رد کد با پیام واضح و بدون تغییر نادرست مبلغ |
| ۶ | تغییر شهر یا روش ارسال | محاسبه صحیح هزینه و محدودیت‌ها |
| ۷ | پرداخت موفق آزمایشی | تأیید معتبر و ثبت یک سفارش صحیح |
| ۸ | پرداخت ناموفق | عدم ثبت پرداخت موفق یا ارسال کالا |
| ۹ | تکرار پاسخ پرداخت | عدم ایجاد سفارش یا کسر موجودی تکراری |
| ۱۰ | لغو سفارش | اصلاح وضعیت و رزرو طبق فرایند تعریف‌شده |
| ۱۱ | ثبت سفارش با گوشی | تکمیل خرید بدون خطای چیدمان یا فرم |
| ۱۲ | بررسی پیامک و فاکتور | اطلاعات مطابق سفارش واقعی |
| ۱۳ | باز کردن صفحات عمومی پس از انتشار | دسترسی صحیح و نبود محدودیت ناخواسته |
| ۱۴ | ثبت رویداد خرید در آنالیتیکس | ثبت صحیح و غیرتکراری سفارش موفق |
فرض کنید فروشگاهی با ۲۰ محصول راه‌اندازی کرده‌اید. برای شروع دو محصول انتخاب کنید: یک محصول ساده با قیمت ۳۰۰ هزار تومان و یک محصول متغیر با رنگ‌ها و قیمت‌های متفاوت. موجودی کالای ساده را پنج عدد و موجودی یکی از تنوع‌های محصول دوم را فقط یک عدد قرار دهید. این اطلاعات صرفاً برای سناریوی آزمایشی هستند.
ابتدا کالای ساده را به سبد اضافه کنید، تعداد را تغییر دهید و مبلغ نهایی را بررسی کنید. بعد مدل موجود محصول دوم را انتخاب و یک سفارش موفق را در محیط آزمایشی معتبر ثبت کنید. بررسی کنید سفارش فقط یک شناسه دارد و موجودی مدل انتخاب‌شده مطابق سیاست سیستم رزرو یا کاهش پیدا کرده است.
در مرحله دوم، پرداختی را در محیط آزمایشی به وضعیت ناموفق ببرید و بررسی کنید سفارش اشتباهاً پرداخت‌شده نمی‌شود. سپس سفارش موفق قبلی را لغو کنید و فرایند آزادسازی موجودی و اصلاح گزارش را کنترل کنید. در پایان، فاکتور، پیامک و رویداد تحلیلی را بررسی و نتیجه هر سناریو را ثبت کنید.
اگر همه این آزمایش‌ها موفق باشند، هنوز لازم است سایر بخش‌ها مانند امنیت، موبایل، ارسال و پایداری سایت را بررسی کنید. اما این سناریوی کوچک می‌تواند بخش مهمی از خطاهای عملیاتی اولیه را قبل از شروع فروش آشکار کند.
همه خطاها اهمیت یکسان ندارند. ناهماهنگی جزئی فاصله دو بخش صفحه ممکن است آزاردهنده باشد، اما خطایی که پرداخت ناموفق را موفق اعلام می‌کند باید انتشار را متوقف کند. برای تصمیم‌گیری یک فهرست خطا با شدت، مراحل تکرار، مسئول و وضعیت رفع تهیه کنید.
| سطح خطا | مثال | تصمیم پیشنهادی |
|---|---|---|
| حیاتی | افشای اطلاعات، تأیید اشتباه پرداخت، فروش بیش از موجودی بدون کنترل | توقف انتشار تا رفع و آزمایش مجدد |
| زیاد | خرابی پرداخت در موبایل، محاسبه اشتباه هزینه نهایی، ثبت ناقص سفارش | رفع پیش از پذیرش سفارش عمومی |
| متوسط | اختلال یک بخش غیرحیاتی، مشکل جزئی در نمایش اطلاعات تکمیلی | اصلاح قبل از انتشار در صورت اثر بر تصمیم خرید؛ در غیر این صورت برنامه رفع مشخص |
| کم | فاصله‌گذاری جزئی یا اشکال ظاهری بدون اثر بر خوانایی و خرید | ثبت و اصلاح در نوبت مناسب |
پس از رفع هر خطا، همان سناریو را دوباره اجرا کنید و در صورت ارتباط، بخش‌های مجاور را نیز بررسی کنید. مثلاً تغییر منطق تخفیف ممکن است روی مبلغ فاکتور، هزینه ارسال یا رویداد خرید اثر بگذارد. این بررسی دوباره را آزمون بازگشتی یا Regression Testing می‌نامند.
صفحات اصلی، دسته‌بندی‌ها، مشخصات کالا، قیمت‌ها، تصاویر، تنوع‌ها و موجودی را بررسی کنید. لینک‌های خراب، محتوای آزمایشی و محصولات ناقص را فهرست کنید.
چند سفارش با محصولات متفاوت بسازید. تعداد را تغییر دهید، کد تخفیف را آزمایش کنید و هزینه ارسال را برای مقصدهای گوناگون بررسی کنید. نتیجه مورد انتظار هر مورد را ثبت کنید.
با روش رسمی و مجاز، پرداخت موفق، ناموفق، انصراف و پاسخ تکراری را آزمایش کنید. سفارش‌ها و موجودی را پس از هر حالت بررسی کنید و مطمئن شوید خطای مالی حیاتی وجود ندارد.
وضعیت سفارش، فاکتور، پیامک، ایمیل و فرایند لغو یا بازپرداخت را طبق امکانات سیستم کنترل کنید. دسترسی کارکنان به اطلاعات سفارش را نیز بررسی کنید.
مسیر کامل خرید را روی گوشی و مرورگرهای مهم امتحان کنید. خطاهای چیدمان، تصاویر سنگین، فرم‌های دشوار و عملکرد کند را اصلاح کنید.
HTTPS، دسترسی مدیران، محیط آزمایشی، نسخه پشتیبان، ایندکس، canonical، نقشه سایت و رویدادهای تحلیلی را بررسی کنید. از باقی ماندن محدودیت‌های آزمایشی در محیط عمومی جلوگیری کنید.
تمام خطاهای حیاتی و زیاد را دوباره تست کنید. یک سفارش کامل از ابتدا تا انتهای فرایند انجام دهید و مسئولیت پشتیبانی، ارسال و پیگیری خطاهای روز نخست را مشخص کنید. اگر بخش حساس هنوز مشکل دارد، انتشار را تا رفع آن به تعویق بیندازید.
این برنامه یک زمان‌بندی پیشنهادی است و برای پروژه‌های بزرگ یا دارای اتصال اختصاصی ممکن است زمان بیشتری لازم باشد. کیفیت آزمایش و رفع مشکلات مهم‌تر از پایبندی به عدد هفت روز است.
پس از تأیید آزمون‌ها، انتشار را در ساعتی انجام دهید که امکان نظارت و دسترسی به پشتیبانی فنی وجود دارد. تنظیمات آزمایشی درگاه را فقط با روش صحیح به حالت عملیاتی تغییر دهید و مطمئن شوید صفحات عمومی موردنظر در دسترس هستند. اگر محیط تست از سایت اصلی جداست، کلیدهای آزمایشی و اطلاعات ساختگی نباید به محیط واقعی منتقل شوند.
در ساعات اولیه، سفارش‌های ثبت‌شده، خطاهای پرداخت، اختلاف موجودی، پیامک‌های ناموفق و عملکرد سرور را زیر نظر بگیرید. بهتر است تبلیغات را با بودجه کنترل‌شده آغاز کنید تا قبل از افزایش ناگهانی ترافیک، رفتار واقعی سایت بررسی شود.
اگر مشکل حیاتی مشاهده شد، برنامه مشخصی برای توقف موقت پذیرش سفارش یا بازگرداندن تغییرات داشته باشید. درباره زمان پاسخ‌گویی و مسئول پیگیری نیز از قبل تصمیم بگیرید. سایت منتشرشده به معنای پایان آزمایش نیست؛ پایش پس از انتشار بخشی از راه‌اندازی حرفه‌ای است.
مای‌تارنما یک فروشگاه‌ساز اختصاصی برای ساخت سایت فروشگاهی، شرکتی و شخصی است که امکاناتی مانند مدیریت محصولات، ثبت سفارش، محصولات چندنوعی و چندقیمتی، درگاه پرداخت، فاکتور و چاپ، پیامک سفارش، اتصال دامنه و تنظیم ظاهر سایت را معرفی می‌کند. این قابلیت‌ها به شما امکان می‌دهند بخش‌های اصلی فروشگاه را پیش از شروع تبلیغات بررسی کنید.
در تست رایگان ۱۰روزه مای‌تارنما می‌توانید محصولات نمونه وارد کنید، تنوع‌ها و قیمت‌ها را بررسی کنید، ظاهر فروشگاه را روی موبایل ببینید و درباره شیوه آزمایش سفارش و پرداخت با پشتیبانی هماهنگ شوید. البته فعال بودن درگاه واقعی، محیط آزمایشی پرداخت، اتصال‌های بیرونی یا قابلیت‌های فنی پیشرفته در تمام طرح‌ها را نباید بدون تأیید فرض کرد.
برای آنکه در انتخاب فروشگاه‌ساز فقط به ظاهر توجه نکنید، چک‌لیست بررسی امکانات فروشگاه‌ساز در دوره آزمایشی را نیز مطالعه کنید. بهتر است پیش از خرید، یک محصول واقعی‌نما ثبت کنید و فرایند سفارش را مطابق امکانات فعال همان طرح آزمایش کنید.
بله، این یکی از مهم‌ترین اقدامات پیشنهادی است. سفارش آزمایشی کمک می‌کند سبد، پرداخت، موجودی، فاکتور و ثبت سفارش را بررسی کنید. بهتر است علاوه بر خرید موفق، سناریوی پرداخت ناموفق و لغو سفارش نیز آزمایش شود.
نه همیشه. اگر درگاه حالت آزمایشی معتبر دارد، می‌توانید از همان استفاده کنید. در صورت نیاز به تراکنش واقعی، فقط با روش مجاز و مبلغ کنترل‌شده و با درنظر گرفتن شرایط کارمزد و بازپرداخت اقدام کنید.
در صورت امکان از محیط آزمایشی جدا با احراز هویت یا کنترل دسترسی مناسب استفاده کنید. اتکا به robots.txt یا noindex به‌تنهایی برای محافظت از اطلاعات محرمانه کافی نیست. پس از انتشار نیز تنظیمات ایندکس صفحات اصلی را دوباره کنترل کنید.
باید بررسی کنید امکان خرید نامعتبر وجود ندارد و کاربر وضعیت ناموجود را به‌درستی می‌بیند. در محصول متغیر، ممکن است فقط یک رنگ یا سایز ناموجود باشد؛ بنابراین وضعیت هر ترکیب باید جدا آزمایش شود.
به تعداد محصولات، پیچیدگی پرداخت، ارسال و اتصال‌ها بستگی دارد. یک فروشگاه ساده ممکن است در چند روز بررسی اولیه شود، اما فروشگاه بزرگ یا دارای سیستم اختصاصی به آزمایش بیشتری نیاز دارد. برنامه هفت‌روزه این مقاله پیشنهادی است، نه زمان تضمینی.
خیر. ممکن است ظاهر سایت درست باشد ولی پرداخت، ثبت سفارش یا موجودی مشکل داشته باشد. آزمایش واقعی خرید و بررسی خطاهای حیاتی باید پیش از انتشار انجام شود.
معمولاً لازم نیست برای هر محصول یک سفارش کامل ثبت شود، اما باید انواع مهم کالا و شرایط ویژه را پوشش دهید؛ مانند محصول ساده، متغیر، تخفیف‌دار، کم‌موجودی، حجیم یا دارای ارسال خاص. برای داده‌های محصول نیز بررسی کامل‌تر و نمونه‌برداری هدفمند لازم است.
بله. پس از تغییر قالب، درگاه، قیمت‌گذاری، تنظیمات ارسال یا اتصال‌های جدید، بخش‌های مرتبط را دوباره آزمایش کنید. پایش سفارش و خطا در ساعات نخست انتشار نیز ضروری است.
انتشار یا پذیرش سفارش عمومی را تا رفع مشکل متوقف کنید. خطا را با مراحل تکرار مستند کنید، پس از اصلاح همان سناریو را دوباره اجرا کنید و بخش‌های مرتبط را نیز بررسی کنید.
پاسخ سؤال چگونه فروشگاه اینترنتی را قبل از انتشار عمومی آزمایش کنیم؟ در انجام یک خرید کامل و بررسی همه مراحل آن خلاصه نمی‌شود، اما از همان‌جا شروع می‌شود. صفحات محصول، مدل‌ها، موجودی، سبد، تخفیف، ارسال، درگاه، ثبت سفارش، فاکتور و اطلاع‌رسانی باید به‌صورت عملی بررسی شوند. سپس نوبت کنترل موبایل، سرعت، امنیت، سئو و ابزارهای تحلیل است.
به‌جای انتشار عجولانه و اصلاح خطاهای مهم پس از نارضایتی مشتری، یک چک‌لیست مشخص بسازید و نتیجه هر آزمایش را ثبت کنید. مشکلات حیاتی پرداخت، امنیت و موجودی را پیش از شروع فروش برطرف کنید و در ساعات اولیه انتشار، عملکرد سایت را پایش کنید.
اگر هنوز فروشگاه خود را راه‌اندازی نکرده‌اید یا می‌خواهید پیش از خرید سایت‌ساز امکانات آن را بررسی کنید، می‌توانید از تست رایگان ۱۰روزه مای‌تارنما استفاده کنید. یک فروشگاه حرفه‌ای فقط فروشگاهی با ظاهر مناسب نیست؛ فروشگاهی است که مشتری بتواند با اطمینان در آن خرید کند و سفارش او به‌درستی ثبت و پردازش شود.
برای طراحی سایت اختصاصی کسب‌وکارتان، همین حالا مشاوره رایگان دریافت کنید.
نام و شماره را بگذارید تا با شما تماس بگیریم.
دیگر محتوا های مرتبط را بخوانید
مای‌تارنما قویترین و سادهترین سایتسازاینترنتی برای راه‌اندازی کسب‌وکار آنلاین شماست. با ما می‌توانید در سریعترین زمان ممکن، بدون نیاز به دانش برنامه‌نویسی، سایت فروشگاهی اختصاصی خود را بسازید، محصولاتتان را عرضه کنید و مستقیماً از مشتریان خود سفارش بگیرید. مای‌تارنما ابزارهای کامل مدیریت محصولات، گزارش‌های مالی و سیستم پرداخت ایمن را برای تضمین موفقیت و رشد پایدار فروشگاه شما فراهم میآورد.
