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