Узгодьте обсяг і особу, яка вирішує
Почніть із затвердженого брифу, ідентифікатора випуску, цільового середовища та URL-адрес, які замінюються. Назвіть затверджувача з боку клієнта, оператора випуску з боку агенції та заміну для кожного. Узгодьте, коли вони будуть доступні та який канал зв'язку фіксуватиме рішення.
Підготуйте контрольовану тестову поштову скриньку, синтетичні дані форм, дозволені тестові облікові записи та папку доказів з обмеженим доступом. Визначте, які перевірки відбуваються на репетиції, а які потребують живого призначення. Встановіть поріг блокування запуску перед тестуванням: наприклад, відсутні запити, зламаний доступ адміністратора або непояснені розбіжності даних вимагають відмови.
Напишіть невелику сітку спостережуваних результатів
Використовуйте один рядок на тест із стабільним ідентифікатором. Розділяйте рядки, коли потрібні різні люди або докази. Наведені нижче приклади — це критерії для адаптації, а не завершений запис приймання. Додайте до робочої копії стовпці тестувальника, фактичного результату, посилання на докази та рішення затверджувача.
Прокрутіть горизонтально, щоб побачити всі стовпці таблиці.
| Область | Очікуваний результат | Корисні докази |
|---|---|---|
| Форми | Один синтетичний запит надходить до узгодженого призначення один раз; недійсний ввід отримує зрозуміле пояснення. | Посилання на подання та редагована квитанція. |
| Перенаправлення | Кожна узгоджена стара URL-адреса досягає свого призначеного замінника без циклу. | Вихідна URL-адреса, ланцюжок статусів і кінцева URL-адреса. |
| Доступ | Редактор клієнта може публікувати в межах обсягу; обмежене адміністрування залишається недоступним. | Нотатки тестування для конкретних ролей. |
| Заплановані завдання | Призначений хост запускає завдання в узгоджений час і створює очікуваний вивід. | Запис планувальника та посилання на вивід. |
| Дані | Узгоджені записи, завантаження та зв'язки зберігаються після переміщення. | Аркуш порівняння та вибрані функціональні перевірки. |
| Затвердження | Призначений затверджувач фіксує прийняті, відхилені або явно прийняті винятки. | Рішення, пов'язане з протестованим випуском. |
Прослідкуйте форму далі за повідомленням про успіх
Перевірте порожнє подання, недійсний ввід і дійсний синтетичний запит. Використовуйте клавіатуру, щоб досягти полів, зрозуміти їхні підписи, виправити помилки та надіслати. Настанови W3C щодо форм пояснюють, що обов'язкові поля потребують чіткої ідентифікації, а валідація браузера не замінює валідацію на сервері. Включіть обидві до обсягу тестування розробника.
Потім перевірте узгоджений подальший результат разом із його власником. Лише повідомлення про успіх у браузері не доводить отримання в поштовій скриньці чи CRM. Підтвердьте значення полів, призначення та обробку дублікатів. Тримайте персональні дані поза скриншотами. Повторіть відповідне завдання як редактор клієнта та перевірте, що обмежена операція відхиляється.
Перевірте маршрут, а не лише сторінку призначення
Узгодьте список старих і нових URL-адрес, включаючи важливі посилання кампанії та обов'язкові параметри запиту. Зафіксуйте ланцюжок статусів HTTP, а також досягнуту сторінку. MDN розрізняє постійні та тимчасові перенаправлення й документує відмінності в тому, як коди перенаправлення обробляють методи запиту. Тому перенаправлене подання форми потребує власного тесту; відкриття призначення звичайним запитом сторінки недостатньо.
Відхиляйте цикли, неочікувані домени та відсутні призначення. Уникайте розміщення конфіденційних рядків запиту в доказах.
Дайте фоновій роботі та даним власні перевірки
Для кожного запланованого завдання запишіть його призначення, хост, ідентичність виконання, часовий пояс, розклад, очікуваний вивід і особу, яка отримує повідомлення про збої. Під час репетиції перенаправте вихідні повідомлення до контрольованого призначення. Встановіть, коли старий хост припиняє виконувати завдання і коли новий хост стає відповідальним, щоб міграція не залишила двох активних планувальників.
Визначте межу даних і порівняйте узгоджені підсумки записів, вибрані значення полів і завантажені файли. Відкрийте репрезентативні записи через застосунок, щоб перевірити зв'язки та дозволи. Лише підрахунки недостатні: однакові підсумки можуть містити різні записи. Зафіксуйте будь-які навмисно виключені історичні дані та отримайте рішення клієнта.
Приклад: запуск каталогу, який має зачекати
У цьому вигаданому сценарії агенція переносить каталог майстерні та форму запиту. Затверджувач з боку клієнта приймає перевірки контенту та перенаправлень, але синтетичний запит надходить до застарілої поштової скриньки. Нічний імпорт каталогу також залишається ввімкненим на старому хості. Результат — відмова в запуску, обидва збої призначено оператору випуску.
Оператор виправляє одержувача та власність планувальника, потім надає свіжі докази для цих рядків і повторює постраждалі перевірки форми та даних. Затверджувач переглядає той самий ідентифікатор випуску перед зміною рішення. Незначне обрізання зображення може залишитися явним винятком із власником і терміном, якщо клієнт погоджується; мовчання не є прийняттям.
Перевірте рішення та збережіть його межі видимими
Перед закриттям переконайтеся, що кожен обов'язковий рядок має результат, кожен невдалий рядок має вирішення або зафіксований виняток, а рішення затверджувача ідентифікує випуск і час. Якщо збірка або конфігурація змінюються після цього, повторно відкрийте постраждалі перевірки. Зберігайте стислі докази з узгодженим періодом зберігання та тримайте деталі доступу в захищених системах команди.
Цей контрольний список встановлює приймання проєкту в межах зазначеного обсягу. Він не встановлює відповідність вимогам доступності, гарантію безпеки або майбутню доступність. Організуйте фаховий огляд там, де цього потребує проєкт. Далі перенесіть прийнятий випуск, відкриті винятки та названих операторів до запису постійної відповідальності.
Джерела та перевірка
Технічні посилання було перевірено 12 вересня 2026. Приклади є навчальними вправами; документація згаданого програмного забезпечення не встановлює можливості послуг PrivateHostLab.