تحویل فروشگاه اینترنتی فقط به معنی بازشدن صفحهٔ اصلی نیست. پیش از شروع فروش باید معلوم باشد خریدار چگونه محصول را پیدا می‌کند، سفارش چگونه ثبت می‌شود، خطای پرداخت چه رفتاری دارد و مدیر چگونه کار روزانه را انجام می‌دهد. یک چک‌لیست روشن کمک می‌کند طراح و سفارش‌دهنده دربارهٔ نتیجهٔ قابل تحویل صحبت کنند، نه فقط ظاهر صفحه‌ها.
دامنهٔ تحویل را به خروجی‌های قابل مشاهده تبدیل کنید
عبارت «فروشگاه کامل» برای بررسی کافی نیست. فهرست کنید چه نوع محصول، روش پرداخت، شیوهٔ ارسال یا دانلود و نقش کاربری در پروژه وجود دارد. اگر فروشگاه کالای فیزیکی دارد، نشانی و هزینهٔ ارسال مهم‌اند؛ اگر فایل می‌فروشد، دسترسی پس از خرید و پیام پایان مهلت دانلود اهمیت پیدا می‌کند.
برای هر قابلیت یک نتیجه بنویسید. مثلاً «کاربر بعد از پرداخت موفق، سفارش پرداخت‌شده را در حساب خود می‌بیند». این جمله قابل آزمایش است. «پرداخت حرفه‌ای» چنین امکانی نمی‌دهد. موارد خارج از محدوده، مثل تولید محتوا یا ورود همهٔ محصولات، نیز باید روشن باشند تا در جلسهٔ تحویل به انتظار ناگفته تبدیل نشوند.
جدول آزمون پذیرش؛ نمونهٔ قابل استفاده
| سناریو | نتیجهٔ مورد انتظار | شاهد تحویل |
|---|---|---|
| جست‌وجوی محصول موجود | محصول مناسب و اطلاعات روشن نمایش داده شود. | عبارت جست‌وجو و تصویر نتیجه |
| پرداخت موفق آزمایشی | وضعیت سفارش و دسترسی خرید درست ثبت شود. | شناسهٔ سفارش آزمایشی |
| انصراف یا شکست پرداخت | سفارش به‌اشتباه پرداخت‌شده نشود. | وضعیت سفارش و پیام نمایش‌داده‌شده |
| محصول ناموجود | رفتار مطابق تنظیم توافق‌شده باشد. | آزمون افزودن به سبد و ثبت سفارش |
| فرم ناقص | خطای روشن کنار فیلد مربوط دیده شود. | تصویر خطا و امکان اصلاح |
نتیجهٔ هر ردیف را با وضعیت قبول، نیازمند اصلاح یا خارج از محدوده ثبت کنید. برای مورد ناقص، مسئول و موعد پیگیری بنویسید. بهتر است از محیط آزمایشی یا روش تست ارائه‌شدهٔ سرویس‌ها استفاده شود؛ آزمون نباید برای مشتری واقعی سفارش و پیام ناخواسته ایجاد کند.
مسیر خرید را با چند وضعیت متفاوت بررسی کنید
یک بار مثل مشتری تازه و یک بار مثل کاربر واردشده مسیر را طی کنید. سبد خالی، کد تخفیف نامعتبر، نشانی ناقص و بازگشت از درگاه را ببینید. اگر خریدار صفحه را دوباره باز کند یا روی دکمه دو بار بزند، نتیجه باید قابل فهم باشد. صرف ثبت یک خرید موفق، همهٔ حالت‌ها را پوشش نمی‌دهد.
نام فیلدها و توضیح خطا نیز جزو تحویل‌اند. راهنمای فرم‌های W3C توضیح می‌دهد که کنترل‌های فرم به برچسب مناسب نیاز دارند. در بررسی عملی، کاربر باید بداند هر کادر چه می‌خواهد و هنگام خطا چه چیزی را اصلاح کند؛ رنگ قرمزِ بدون توضیح کافی نیست.
مدیریت روزانه و دسترسی‌ها را تحویل بگیرید
- ایجاد و ویرایش محصول، قیمت و وضعیت موجودی را تمرین کنید.
- روش یافتن سفارش و پاسخ‌گویی به مشتری را یاد بگیرید.
- مالکیت و دسترسی حساب‌های دامنه، میزبانی و سرویس‌های متصل را روشن کنید.
- حساب‌های شخصی، مدیریتی و آزمایشی را از هم جدا کنید.
- روش تغییر رمز و بازیابی دسترسی را ثبت کنید.
- فهرست هزینه‌ها و موعد تمدید سرویس‌های مورد استفاده را داشته باشید.
رمزها را داخل فایل عمومی صورت‌جلسه یا پیام گروهی قرار ندهید. در سند تحویل می‌توان مسئول حساب و روش انتقال امن دسترسی را ثبت کرد. اگر فروشگاه بر بستر فروشگاه‌ساز ارائه می‌شود، محدودهٔ دسترسی به داده و فایل‌ها را از شرایط همان خدمت بررسی کنید؛ همهٔ بسترها یک نوع دسترسی نمی‌دهند.
پشتیبان‌گیری و پشتیبانی را با نمونهٔ واقعی بررسی کنید
وجود عبارت «بکاپ خودکار» کافی نیست. مشخص کنید چه چیزی پشتیبان‌گیری می‌شود، نسخه کجا قرار می‌گیرد و چه کسی بازیابی را انجام می‌دهد. یک بازیابی آزمایشی در محیط مناسب نشان می‌دهد دادهٔ لازم واقعاً قابل استفاده است. تاریخ آخرین آزمون را ثبت کنید.
برای پشتیبانی، راه ثبت درخواست، اطلاعات لازم برای گزارش خطا و حدود خدمت را روشن کنید. نمونهٔ گزارش خوب شامل زمان، مسیر صفحه، مراحل تکرار و شناسهٔ سفارش آزمایشی است. فرستادن «سایت کار نمی‌کند» بدون جزئیات، تشخیص مشکل را کند می‌کند.
فایل Word مرتبط چه کاربردی دارد؟
نمونهٔ قرارداد ساخت فروشگاه اینترنتی با فروشگاه‌ساز یک فایل Word برای مشاهده و ویرایش ساختار توافق است. در گزیدهٔ محصول، موضوع‌هایی مانند ایجاد فروشگاه، میزبانی، پشتیبانی و موارد مالی آمده است. این فایل خودِ فروشگاه، افزونه یا چک‌لیست آزمون خودکار نیست.
فایل نمونه شامل نام‌ها و شرایط یک الگوی مشخص است؛ آن‌ها را عیناً به پروژهٔ تازه منتقل نکنید. شرایط فنی و تجاری باید با خدمت واقعی هماهنگ شوند و متن نهایی توافق در صورت نیاز بررسی حقوقی شود. جدول آزمون این مقاله می‌تواند به‌عنوان یادداشت اجرایی تحویل، متناسب با پروژه تکمیل شود.
برای بحث کلی دامنهٔ همکاری، راهنمای قرارداد طراحی سایت و برای نحوهٔ ثبت نتیجه، راهنمای گزارش‌نویسی اداری را ببینید.
پرسش‌های متداول
اگر ظاهر سایت تأیید شده، تست خرید لازم است؟
بله. ظاهر و عملکرد دو بخش متفاوت تحویل هستند؛ ثبت سفارش و مدیریت خطا باید جدا بررسی شوند.
همهٔ موارد جدول برای هر فروشگاه ضروری‌اند؟
چک‌لیست را با قابلیت‌های واقعی تطبیق دهید. مثلاً فروشگاه فایل به بررسی دانلود نیاز دارد، اما نشانی ارسال ممکن است موضوع آن نباشد.
آیا فایل قرارداد همهٔ نیازهای تحویل را پوشش می‌دهد؟
نباید چنین فرضی کرد. دامنهٔ کار، آزمون‌ها و شرایط پشتیبانی پروژهٔ خود را جدا مشخص و با متن توافق هماهنگ کنید.
