Stabiliți domeniul de aplicare și persoana care decide
Începeți cu brief-ul aprobat, identificatorul versiunii, mediul de destinație și URL-urile care sunt înlocuite. Numiți aprobatorul clientului, operatorul de lansare al agenției și un înlocuitor pentru fiecare. Stabiliți când vor fi disponibili și ce canal de comunicare va conține decizia.
Pregătiți o cutie poștală de test controlată, date sintetice de formular, conturi de test permise și un dosar de dovezi cu acces restricționat. Decideți ce verificări au loc în repetiție și care necesită destinația live. Stabiliți un prag de blocare a lansamentului înainte de testare: de exemplu, solicitările lipsă, accesul de administrator întrerupt sau diferențele de date neexplicate necesită refuz.
Scrieți o grilă mică de rezultate observabile
Folosiți un rând per test, cu un identificator stabil. Împărțiți rândurile când sunt necesare persoane sau dovezi diferite. Exemplele de mai jos sunt criterii de adaptat, nu un registru de acceptare completat. Adăugați coloanele de tester, rezultat real, referință de dovezi și decizie a aprobatorului la copia de lucru.
Derulați orizontal pentru toate coloanele tabelului.
| Zonă | Rezultat așteptat | Dovezi utile |
|---|---|---|
| Formulare | O solicitare sintetică ajunge o dată la destinația convenită; datele invalide primesc o explicație utilizabilă. | Referință de trimitere și chitanță redactată. |
| Redirecționări | Fiecare URL vechi convenit ajunge la înlocuitorul său intenționat fără o buclă. | URL sursă, lanț de status și URL final. |
| Acces | Editorul clientului poate publica în domeniul de aplicare; administrarea restricționată rămâne indisponibilă. | Note de test specifice rolului. |
| Joburi programate | Gazda intenționată execută sarcina la ora convenită și produce rezultatul așteptat. | Înregistrare planificator și referință de ieșire. |
| Date | Înregistrările, încărcările și relațiile convenite supraviețuiesc mutării. | Fișă de comparație și verificări funcționale selectate. |
| Aprobare | Aprobatorul desemnat înregistrează excepții acceptate, refuzate sau acceptate explicit. | Decizie legată de versiunea testată. |
Urmăriți un formular dincolo de mesajul său de succes
Testați o trimitere goală, date invalide și o solicitare sintetică validă. Folosiți tastatura pentru a ajunge la câmpuri, pentru a înțelege etichetele acestora, pentru a corecta erorile și pentru a trimite. Ghidul W3C privind formularele explică faptul că intrările obligatorii necesită identificare clară și că validarea browserului nu înlocuiește validarea pe server. Includeți ambele în domeniul de testare al dezvoltatorului.
Apoi verificați rezultatul downstream convenit cu proprietarul acestuia. Un mesaj de succes în browser singur nu dovedește primirea într-o cutie poștală sau CRM. Confirmați valorile câmpurilor, destinația și gestionarea duplicatelor. Păstrați datele personale în afara capturilor de ecran. Repetați o sarcină adecvată ca editor al clientului și verificați că o operațiune restricționată este refuzată.
Verificați ruta, nu doar pagina de destinație
Stabiliți o listă de URL-uri vechi spre noi, inclusiv linkuri importante de campanie și parametri de interogare necesari. Înregistrați lanțul de status HTTP, precum și pagina atinsă. MDN distinge redirecționările permanente de cele temporare și documentează diferențele în modul în care codurile de redirecționare gestionează metodele de cerere. Prin urmare, o trimitere de formular redirecționată necesită propriul test; deschiderea destinației cu o cerere de pagină normală este insuficientă.
Respingeți buclele, domeniile neașteptate și destinațiile lipsă. Evitați plasarea șirurilor de interogare confidențiale în dovezi.
Acordați lucrărilor de fundal și datelor propriile verificări
Pentru fiecare sarcină programată, înregistrați scopul, gazda, identitatea de execuție, fusul orar, programul, rezultatul așteptat și persoana care primește eșecurile. În timpul repetiției, redirecționați mesajele de ieșire către o destinație controlată. Stabiliți când vechea gazdă încetează să execute sarcina și când noua gazdă devine responsabilă, astfel încât o migrare să nu lase doi planificatori activi.
Definiți limita de date și comparați totalurile înregistrărilor convenite, valorile câmpurilor selectate și fișierele încărcate. Deschideți înregistrări reprezentative prin aplicație pentru a verifica relațiile și permisiunile. Numărătorile singure sunt insuficiente: totaluri egale pot conține înregistrări diferite. Înregistrați orice date istorice excluse în mod deliberat și obțineți decizia clientului.
Exemplu: un lansament de catalog care ar trebui să aștepte
În acest scenariu fictiv, o agenție mută catalogul și formularul de solicitare ale unui atelier. Aprobatorul clientului acceptă conținutul și verificările de redirecționare, dar o solicitare sintetică ajunge într-o cutie poștală obsoletă. Importul nocturn al catalogului rămâne, de asemenea, activat pe vechea gazdă. Rezultatul este refuzat pentru lansare, ambele eșecuri fiind atribuite operatorului de lansare.
Operatorul corectează destinatarul și proprietarul planificatorului, apoi furnizează dovezi noi pentru acele rânduri și repetă verificările afectate ale formularului și datelor. Aprobatorul revizuiește același identificator de versiune înainte de a schimba decizia. O decupare minoră a imaginii poate rămâne o excepție explicită cu un responsabil și o dată limită dacă clientul este de acord; tăcerea nu este acceptare.
Verificați decizia și mențineți limitele acesteia vizibile
Înainte de închidere, confirmați că fiecare rând obligatoriu are un rezultat, că fiecare rând eșuat are o soluționare sau o excepție înregistrată și că decizia aprobatorului identifică versiunea și momentul. Dacă build-ul sau configurația se modifică ulterior, redeschideți verificările afectate. Stocați dovezi concise cu o perioadă de păstrare convenită și păstrați detaliile de acces în sistemele securizate ale echipei.
Această listă de verificare stabilește acceptarea proiectului în domeniul de aplicare declarat. Nu stabilește conformitatea cu accesibilitatea, asigurarea securității sau disponibilitatea viitoare. Programați o revizuire specializată acolo unde proiectul o necesită. În continuare, transferați versiunea acceptată, excepțiile deschise și operatorii numiți în registrul de responsabilitate continuă.
Surse și recenzii
Referințele tehnice au fost verificate în septembrie 12, 2026. Exemplele sunt exerciții de planificare; documentația software menționată nu stabilește capabilitățile de serviciu PrivateHostLab.