Il sito è pronto per andare online? Una checklist di collaudo per l'azienda

«Il sito è pronto?» di solito riceve una risposta soggettiva: sembra a posto. Il collaudo serve a sostituire quella sensazione con un elenco di prove fatte, ognuna con un esito e un responsabile, e con una distinzione netta fra i difetti che impediscono la pubblicazione e quelli che si correggono dopo. Serve all’azienda quanto al fornitore, perché chiude il progetto senza code infinite di segnalazioni.

Non è una revisione grafica. Non si discute se il colore piace: si verifica che i percorsi funzionino, che i contenuti dicano il vero e che le richieste arrivino a destinazione.

Provate percorsi, non pagine

Aprire tutte le pagine una per una dà una falsa sicurezza: le pagine si vedono, i percorsi si rompono. Un percorso è una sequenza che un visitatore reale compie davvero.

• Cerco il vostro nome, arrivo in home, cerco un servizio, leggo la scheda, chiedo informazioni.
• Arrivo su una pagina interna da un collegamento ricevuto, senza passare dalla home: capisco dove sono e come proseguire?
• Voglio il numero di telefono da smartphone: quanti tocchi servono per trovarlo e comporlo?
• Sono un cliente e cerco l’assistenza o l’area riservata.

Ogni percorso va provato su almeno un telefono vero e su un computer, non solo restringendo la finestra del browser. Il telefono ha la tastiera che copre metà schermo, il dito largo come dieci pixel e una rete che a volte non c’è: tre cose che non si vedono su un monitor da ufficio. Provate anche con una connessione lenta e con il telefono ruotato.

Il verbale di collaudo

Uno strumento povero e sufficiente: una tabella con una riga per prova. Evita la discussione più frequente di fine progetto, «questo l’avevamo detto» contro «non era nel perimetro». Alcune righe di esempio.

Le colonne che contano sono le ultime due. Un collaudo senza un nome accanto a ogni riga non viene fatto: viene rimandato finché qualcuno decide di pubblicare lo stesso.

Contenuti, collegamenti e destinazioni delle richieste

La parte meno tecnica è quella che genera più figuracce, perché riguarda ciò che l’azienda dichiara di sé.

• Testi di prova rimasti in pagina, immagini generiche al posto delle vostre, nomi di persone che non lavorano più con voi.
• Recapiti, orari e dati societari: vanno letti da chi li conosce, non da chi ha impaginato.
• Documenti scaricabili: che siano l’ultima versione e che non contengano listini o dati che non volete pubblici.
• Collegamenti interni ed esterni: quelli verso siti di terzi vanno riprovati, perché un sito esterno può aver cambiato indirizzo mentre lavoravate.
• Destinazioni delle richieste: ogni modulo può scrivere a una casella diversa. Provateli tutti, uno per uno, controllando anche la posta indesiderata.
• Testi legali e informative: non sono contenuto di riempimento e non si copiano da un altro sito.

Le chiavi di casa: accessi, backup, ripristino

Prima della pubblicazione conviene chiarire chi possiede che cosa. Adesso costa poco; fra tre anni, con un fornitore diverso, può bloccare un intero progetto.

• Il dominio intestato all’azienda, con l’accesso al pannello di gestione in mano vostra.
• Gli accessi al sito, allo spazio dove è ospitato e agli strumenti di misurazione, esistenti anche a nome di una persona interna e non solo del fornitore.
• Se sono previste copie di sicurezza: dove sono, ogni quanto si fanno, quanto indietro arrivano e — la domanda che nessuno fa — chi ne ha già provato un ripristino.

Un backup mai ripristinato è un’ipotesi, non una garanzia. La prova si fa una volta, su una copia di lavoro, prima di averne bisogno.

Bloccante o rinviabile

Non tutti i difetti impediscono la pubblicazione, e trattarli tutti come urgenti fa slittare la data senza motivo. Tre livelli bastano.

1. Bloccante: il sito dice il falso, una richiesta non arriva, una pagina importante non si apre, un dato riservato è visibile, un percorso di contatto o di acquisto si interrompe. Non si pubblica.
2. Da correggere subito dopo: difetti visibili che non impediscono di usare il sito, come una didascalia sbagliata, un’immagine di qualità scarsa, una spaziatura fuori posto su un modello di telefono.
3. Da valutare: richieste emerse durante il collaudo che in realtà sono contenuti o funzioni nuove. Vanno scritte e discusse, non infilate nel lancio.

La terza voce è quella che salva il progetto. Gran parte dei ritardi nasce da richieste nuove presentate come difetti.

Quando non si pubblica, e quando si pubblica lo stesso

Quello che questa guida non copre

Qui si tratta l’accettazione di un sito prima della pubblicazione. Il collaudo di un processo gestionale — dati migrati, permessi, procedure che sostituiscono un modo di lavorare — segue regole diverse e richiede prove sui dati reali, non su un ambiente di prova. Anche i controlli di accessibilità e la raccolta dei requisiti prima di partire sono trattati altrove.