Il QA tecnico dice: funziona. Il QA UX chiede: si usa?
Testo i flussi reali e gli edge case dal punto di vista di chi userà il prodotto, prima di ogni release. Così meno bug di esperienza arrivano in produzione e meno ticket tornano indietro.
QA tecnico
Verifica che il codice faccia quello che deve. Risponde a una domanda: il sistema funziona secondo specifica?
- i campi salvano
- le API rispondono
- niente errori 500
QA UX
Verifica che le persone riescano davvero a usarlo. Risponde a un'altra domanda: il flusso si capisce e si completa?
- il messaggio d'errore dice cosa fare
- l'edge case non blocca l'utente
- il percorso si completa senza chiamare il supporto
Trascina e guarda la differenza.
Lo stesso momento di errore, prima e dopo un passaggio di QA UX. Tecnicamente funzionano entrambi.
Un report con severità e priorità. Non un elenco di lamentele.
| Flusso | Cosa succede | Severità | Priorità |
|---|---|---|---|
| Checkout · mobile | il CTA resta sotto la tastiera | Alta | P1 |
| Recupero password | messaggio d'errore generico | Media | P2 |
| Onboarding | step 3 saltabile per sbaglio | Media | P2 |
| Tabella ordini | stato vuoto senza spiegazione | Bassa | P3 |
Cosa include
- test dei flussi UX/UI principali
- functional testing dal punto di vista utente
- report di release con severità e priorità
- checklist UX condivisa con il team
Cosa non include
- security testing
- performance e load testing
- automazione dei test
Il QA UX non sostituisce il QA tecnico. Lo completa sul lato che di solito nessuno presidia: l'esperienza reale.
Mensile, senza retainer infiniti.
UX/UI QA & Functional Testing
QA UX pre-release sui flussi e gli edge case, con report a ogni rilascio.
Retainer UX / QA leggero
Presenza mensile di decisione UX e QA leggero per team che vogliono continuità senza assumere.
Quello che mi chiedono prima di partire.
No. Il QA tecnico verifica che il sistema funzioni secondo specifica. Io presidio l'esperienza: se il flusso si capisce, se gli edge case bloccano l'utente, se i messaggi aiutano. I due lavori convivono.
No. Lavoro sul prodotto come lo vive l'utente: ambiente di staging, flussi reali, dispositivi reali. Il report poi parla la lingua del team dev, con severità e priorità.
Scegliamo una release o una feature in arrivo. La testo, ti consegno il report e la checklist. Alla fine decidi se continuare. Nessun vincolo lungo.
Dipende dal vostro ritmo. Concordiamo all'inizio il perimetro: di solito le release principali e le feature critiche, non ogni singolo deploy.
Proviamo su una release vera.
Attiva un mese pilota sulla prossima release. Vedi il report e decidi se ha senso continuare.