WebInclusivedi Giuseppe Stumbo

QA e test: verificare i flussi prima del rilascio

Dopo una modifica, una persona riesce ancora a prenotare, inviare un modulo o acquistare? Verifico funzionalità e accessibilità dei flussi concordati sulla build prevista. Documento difetti, correzioni e regressioni per aiutare il tuo team a decidere il rilascio.

Il servizio in breve

Per chi è utile, cosa ricevi e cosa preparare per il primo confronto.

Quando serve
Per team QA, sviluppo e responsabili di rilascio, prima di una release o dopo modifiche e correzioni.
Cosa faccio
Eseguo scenari funzionali sui task concordati, controlli di accessibilità pertinenti alla release, retest dei difetti e prove di regressione negli ambienti definiti.
Cosa ricevi
Bug report riproducibili, esiti di test e retest, difetti aperti e rischi residui per decidere il rilascio.
Cosa serve da parte tua
Build stabile identificabile, accessi e dati di prova, risultati attesi, elenco delle modifiche e un referente tecnico.
Perimetro
La QA funzionale verifica il risultato atteso di un'operazione; l'audit di accessibilità valuta i requisiti applicabili; il test di usabilità con utenti osserva l'esperienza di partecipanti coinvolti. Queste attività hanno obiettivi e risultati distinti. La QA copre gli scenari concordati e non comprende automaticamente un audit completo o sessioni con utenti.
Come proseguiamo
Invia build, modifiche e scadenza: definiamo gli scenari da provare. Il tuo team decide il rilascio; dopo i fix concordiamo retest e controlli di regressione.

Cosa ricevi dal QA e dai test

Ricevi una traccia del lavoro sulla build verificata: scenari, bug report, esiti delle prove e rischi residui. Concordiamo prima flussi, ambienti, cicli di retest e lingua dei report, includendo mercati e lingue delle interfacce da provare.

  • Copertura

    Piano di test e scenari riutilizzabili

    Scenari per i flussi concordati, con passaggi, risultati attesi e ambienti di prova. Il team può ripeterli sulle release successive.

    • Versione o build, browser, dispositivi e tecnologie assistive previsti.
    • Flussi, casi di errore, criteri di accettazione e limiti della copertura.

  • Difetti

    Bug report riproducibili

    Segnalazioni utilizzabili negli strumenti del team per assegnare, correggere e verificare ogni difetto.

    • Passaggi, risultato atteso e osservato, ambiente ed evidenze.
    • Impatto sull’utente, severità e priorità di intervento.
    Bozza di bug report QA — esempio fittizio
    Stato e identificativo
    QA-DEMO-001. Segnalazione simulata da validare: nessuna prova reale eseguita e nessun fix verificato.
    Build e ambiente di esempio
    Build DEMO-02, Windows 11, Firefox e NVDA. Nel report reale si indicano le versioni esatte di sistema, browser e tecnologia assistiva.
    Precondizioni e passaggi
    Aprire il carrello dimostrativo con «Tazza blu» e «Tazza verde». Raggiungere con Tab i due pulsanti di rimozione e ascoltarne il nome.
    Comportamento simulato
    Entrambi i pulsanti vengono annunciati come «Rimuovi», senza identificare l’articolo.
    Risultato atteso
    Ogni pulsante espone un nome che identifica azione e articolo, per esempio «Rimuovi Tazza blu dal carrello».
    Impatto e priorità proposta
    Chi usa lo screen reader non distingue con certezza quale articolo verrà rimosso. Severità proposta: alta; priorità da concordare nel triage.
    Evidenze da raccogliere
    Versioni esatte dell’ambiente, nomi accessibili rilevati e riferimento ai due controlli. Allegare evidenze della riproduzione: in questa bozza non sono disponibili.
    Retest e regressione da eseguire
    Verificare i nomi dopo il fix e rimuovere ciascun articolo separatamente. Controllare che venga rimosso l’articolo corretto e che focus, totale e aggiornamento del carrello restino utilizzabili. Esito: non eseguito.

  • Esiti

    Riepilogo delle prove, retest e rischi residui

    Esiti riferiti alla build verificata, a supporto della decisione di rilascio del team.

    • Prove superate, fallite e non eseguite, con eventuali impedimenti.
    • Nei cicli concordati: fix verificati, difetti riaperti e risultati dei test di regressione.
    • Issue ancora aperte e rischi residui nel perimetro esaminato.

Sapere cosa funziona dopo una modifica

Prima di rilasciare, vuoi capire quali prove sono state eseguite e quali problemi restano. Partiamo dalla versione del prodotto, dagli ambienti supportati e dai percorsi più importanti per le persone.

Ogni defect report identifica build, ambiente, passi di riproduzione, risultato atteso e osservato. Il retest (confirmation testing) verifica che il difetto sia corretto; i test di regressione verificano eventuali effetti indesiderati delle modifiche sui flussi concordati. Issue aperte e rischi residui restano documentati per la decisione di rilascio. Lavoro anche con team statunitensi e internazionali, concordando i mercati di destinazione e i requisiti del prodotto.

  • Un pulsante che appare ma non riceve mai il focus da tastiera.
  • Un messaggio di conferma che compare solo visivamente, senza essere annunciato.
  • Un errore di validazione che non indica quale campo correggere.
  • Un passaggio che si completa con il mouse ma si blocca con tastiera o screen reader.

  1. Navigazione

    Menu, skip link, landmark e ordine del focus.

  2. Contenuti

    Titoli, link, tabelle e stati dinamici leggibili.

  3. Moduli

    Campi, istruzioni, validazioni e messaggi d'errore.

  4. Transazioni

    Checkout, conferme, ricevute e passaggi post-invio.

Controlli legati alla release

Costruisco le prove intorno alle operazioni del prodotto e ai loro casi di errore. Funzionalità, comportamento mobile e tecnologie assistive si controllano negli scenari concordati.

  • Core

    Test funzionali e di regressione

    I test si costruiscono sui flussi che contano per il business, con scenari riutilizzabili e verifiche mirate sul comportamento reale.

    • Controlli sui task più critici e sui relativi casi di errore.
    • Scenari end-to-end e test di accettazione quando il rischio lo richiede.
    • Supporto a test case, scenari e Gherkin BDD.

  • Mobile

    Mobile QA iOS e Android, responsive e cross-browser

    Qualità su device reali, compatibilità tra browser, adattamento del layout e comportamento coerente su smartphone e tablet.

    • Mobile QA su iOS e Android.
    • Test responsive e cross-browser.
    • Sessioni su device reali e ambienti rappresentativi.

  • Assistive

    Screen reader, tastiera e validazione post-fix

    Le verifiche con tastiera e tecnologie assistive osservano il prodotto nel suo uso reale, non solo come checklist di conformità.

    • Test con screen reader e navigazione assistiva.
    • Documentazione dei difetti allineata al resto del QA.
    • Validazione post-fix e supporto pre-release.

Dal bug report alla verifica della correzione

Una segnalazione è utile quando il team può riprodurre il problema, assegnarlo e sapere come verificarne la soluzione. Ogni passaggio resta collegato alle prove e ai criteri di accettazione.

  1. Scenari

    Mappare i task critici

    Scegliamo le operazioni che le persone devono poter completare: navigare, cercare, accedere, acquistare, compilare moduli e usare i componenti dinamici.

    • Focus sui task più rilevanti per utenti e business.
    • Verifiche pensate per individuare problemi prima della produzione.
    • Maggiore aderenza al comportamento reale del prodotto.

  2. Difetti

    Scrivere bug riproducibili

    Scrivo il bug in modo che chi lo prende in carico possa ripetere i passaggi: risultato atteso e osservato, ambiente, impatto e priorità sono nello stesso report.

    • Segnalazioni più utili per sviluppo e stakeholder.
    • Minore ambiguità nella validazione dei fix.
    • Tracciamento del fix fino al retest definitivo.

  3. Rilascio

    Inserire i controlli nel workflow

    Porto defect report e backlog negli strumenti che il team usa già, come Jira e Confluence. Nei processi Agile o Scrum concordiamo anche i quality gate: controlli e criteri da valutare prima del rilascio.

    • Inserimento più naturale nei processi già attivi.
    • Migliore allineamento tra QA funzionale e accessibilità.
    • Supporto concreto ai quality gate pre-release.

Domande frequenti

Come preparo le prove, documento i difetti e verifico le correzioni insieme al team.

Le barriere di accessibilità sono bug?

Sì. Quando impediscono o rendono difficile completare un task, vanno gestite come difetti di qualità del prodotto: riproducibili, assegnabili e ritestabili.

Quanto dura una sessione di test?

Dipende da flussi, piattaforme, configurazioni e verifiche delle correzioni richieste. La stima viene definita dopo aver concordato il perimetro e gli ambienti di prova.

Quali strumenti usi per i test?

Combino strumenti automatici (axe, Lighthouse, WAVE, Pa11y) con verifiche manuali: tastiera, screen reader e device reali.

Prepariamo i controlli per la tua release

Indica la versione, le piattaforme supportate e la data prevista per il rilascio. Se ci sono percorsi che ti preoccupano, partiamo da quelli.