Collaudo sito web: checklist e verbale prima del lancio

Registra indirizzo dell'ambiente, data della prova, versione del rilascio e referente. Specifica quali parti funzionano come in produzione e quali sono simulate: una conferma del modulo in anteprima può essere dimostrativa, senza inviare nulla. Un esito positivo in quell'ambiente non prova la ricezione sul sito pubblico.

Scegli i percorsi da verificare in base agli obiettivi del progetto. Per un sito aziendale: homepage verso servizio e richiesta; progetto verso servizio pertinente; accesso diretto alla pagina contatti; pagina non esistente verso un percorso utile. Aggiungi lingue, ricerca o prenotazioni soltanto se previste.

Copia questi campi in un foglio condiviso: identificativo della prova; URL iniziale; versione; dispositivo e browser; passi eseguiti; risultato atteso; risultato osservato; evidenza; stato; responsabile; data del nuovo controllo. Usa tre stati distinti: superato, fallito, non verificato. Un campo vuoto non significa che tutto funzioni.

Esempio ipotetico, prova P01: da telefono aprire la pagina servizio, selezionare «Richiedi una proposta» e inviare i dati di test concordati. Atteso: conferma leggibile e richiesta ricevuta dal referente. Osservato: conferma presente, ricezione non riscontrata. Stato: non verificato per la ricezione; il percorso non è ancora approvato. Il referente controlla la destinazione, mentre chi sviluppa verifica l'invio. Si ripete la prova dopo il riscontro o la correzione.

Conserva prove sufficienti a riprodurre il problema, evitando password e dati personali nelle schermate condivise. Concorda destinatari e riconoscibilità dei test prima di inviare richieste a sistemi reali.

Percorri i collegamenti principali e controlla che aprano la destinazione promessa. Confronta prezzi, condizioni, contatti e servizi con i materiali approvati dal titolare. Segnaposto e promesse non confermate vanno risolti prima dell'approvazione editoriale.

Su telefono verifica che testi, menu, pulsanti e messaggi del modulo restino utilizzabili. Prova anche la navigazione con tastiera: osserva dove si trova il focus e se puoi raggiungere e attivare i controlli. Annota dispositivo e browser effettivamente provati; una singola prova non dimostra compatibilità universale o piena accessibilità.

Esegui almeno i casi concordati di richiesta completa e campo obbligatorio mancante. Verifica che il messaggio spieghi l'esito e, in caso di errore, cosa correggere. Il tutorial W3C sulle notifiche distingue errori e conferme: il visitatore deve poter capire se il compito è stato completato.

Fai verificare anche un errore di invio in un ambiente controllato da chi gestisce lo sviluppo. Non interrompere un servizio pubblico per simulare il guasto. Registra il comportamento previsto e quello osservato, compresa la possibilità di riprovare senza confondere un tentativo fallito con una richiesta ricevuta.

Chiedi al referente tecnico di verificare disponibilità degli URL pubblici, canonical, sitemap e direttive di indicizzazione sulle pagine destinate alla ricerca. Google documenta che noindex impedisce l'indicizzazione e deve poter essere letto dal crawler: bloccare la scansione con robots.txt non equivale a gestire correttamente noindex.

L'ambiente di anteprima e il sito pubblico possono avere impostazioni diverse. Ripeti i controlli sulla destinazione pubblica dopo il rilascio. Una risposta HTTP 200 o una sitemap corretta non garantiscono l'indicizzazione; lo stato Google si controlla separatamente in Search Console. Se stai sostituendo URL esistenti, serve anche un piano di migrazione e redirect.

Nel verbale scrivi versione verificata, percorsi superati, problemi aperti, responsabili e decisione. Concorda prima quali problemi impediscono il lancio. Per esempio, se il sito deve acquisire richieste e il percorso principale fallisce, rinviare quel rilascio è una scelta operativa ragionevole. Un dettaglio grafico può avere una priorità diversa, da decidere e registrare esplicitamente.

Prima della pubblicazione identifica chi interviene in caso di problema e quale versione può essere ripristinata. Nel passaggio di consegne registra chi controlla dominio, hosting e strumenti collegati, come riceve gli accessi in modo sicuro e quali attività successive sono comprese. Non inserire credenziali nel verbale.

Per definire un progetto con ConversionWorks, porta i percorsi commerciali prioritari, le integrazioni necessarie e i vincoli di lancio. Potremo chiarire quali prove e attività di consegna includere nel perimetro, senza confondere il collaudo tecnico con una promessa di clienti o posizionamenti.