Bisogna fare uno screenshot di ogni passo di test QA?

Un registro QA ha due lettori: il revisore che approva oggi e la persona che indaga su una regressione mesi dopo. Entrambi devono vedere cosa è stato testato, con quali dati e cosa è successo. Nessuno dei due ha bisogno di uno screenshot di ogni clic.

Questo articolo spiega come strutturare un registro di test manuale e dove gli screenshot aggiungono prove, con il flusso di lavoro di Temposhot su Mac.

Gli esempi usano un unico caso di test: TC-142, un reset della password su un sito di staging. Il test ha 4 passi; un registro con solo i checkpoint ne contiene 5 pagine. Registrare ogni clic dello stesso test ha prodotto 11 pagine.

Definisci un obiettivo per test

Ogni caso di test dovrebbe verificare un solo comportamento. "L'utente può reimpostare la password con un link valido ricevuto via email" è un obiettivo. "Le impostazioni dell'account funzionano" è un piano di test, non un caso di test.

Scrivi l'obiettivo come una frase che può essere vera o falsa. Lo screenshot finale mostra quale delle due.

Separa gli obiettivi che nascondono due test

Un obiettivo con "e" spesso nasconde due test. "L'utente può reimpostare la password e cambiare l'indirizzo email" fallisce nel suo complesso quando si rompe solo una parte, e il registro non mostra quale. Dividilo in due casi, ciascuno con il proprio ID e il proprio registro.

Un obiettivo circoscritto mantiene anche il registro breve. TC-142 termina quando l'utente accede con la nuova password. Verificare che la vecchia password non funzioni più è un caso separato, TC-143, con il proprio stato iniziale.

Scrivi l'obiettivo dal punto di vista dell'utente

Un obiettivo scritto dal punto di vista dell'utente nomina un risultato che l'utente può vedere. "L'utente può reimpostare la password con un link valido ricevuto via email" termina su una schermata: la dashboard dopo l'accesso. Un obiettivo come "L'endpoint di reset restituisce 200" termina in un log, e un registro di screenshot è il formato sbagliato per questo.

Quando un caso combina entrambi, mantieni come obiettivo il risultato visibile e allega le righe di log come testo. Gli screenshot dimostrano il risultato visibile all'utente, e il testo dimostra il comportamento del sistema che lo produce.

Registra prerequisiti e dati di test

Elenca ciò che deve esistere prima del primo passo, così chiunque può ripetere il test:

Voce	Esempio
ID del caso di test	TC-142
Build o versione	Il numero di build testato
Ambiente	URL di staging, versione di macOS, browser e versione
Account	Ruolo e nome dell'account di test, mai un cliente reale
Dati di test	L'ordine, il file o il record usato dal test
Precondizioni	Feature flag attivo, carrello vuoto, utente disconnesso

Usa dati sintetici. I registri di test vengono condivisi ampiamente e conservati a lungo.

Verifica le precondizioni nella prima pagina

Una precondizione solo scritta non può essere controllata in seguito. La prima pagina del registro dovrebbe mostrare lo stato iniziale a schermo, per esempio la pagina di accesso disconnessa con l'URL di staging visibile. Un revisore può così confermare l'ambiente senza doverlo chiedere.

Una casella di posta di test vuota è importante per TC-142. Se nella casella è presente un'email di reset più vecchia, il tester può aprire il link sbagliato, e il registro mostra un superamento per un link che non era oggetto del test.

Usa dati di test chiaramente falsi

I dati sintetici devono sembrare falsi a prima vista. Nomi come "QA Reset 01" e indirizzi su un dominio di test rendono chiaro a qualsiasi lettore successivo che non è coinvolta alcuna persona reale. Nomi falsi ma realistici, come nome e cognome plausibili, portano a chiedersi se il registro contenga dati di clienti.

I dati di test ovvi riducono anche il lavoro di redazione. Un registro senza dati personali non richiede Blur, quindi il piano gratuito è sufficiente, e le pagine mostrano lo schermo intero senza aree coperte.

Scrivi i passi con i checkpoint attesi

Ogni passo ha un'azione e, dove dovrebbe accadere qualcosa di osservabile, un risultato atteso.

1. Apri la pagina di accesso. Atteso: link Forgot password visibile.
2. Seleziona Forgot password e inserisci l'email di test. Atteso: messaggio di conferma.
3. Apri il link di reset dalla casella di posta di test. Atteso: modulo per la nuova password.
4. Inserisci una nuova password valida e invia. Atteso: accesso effettuato, dashboard visualizzata.

I passi senza un risultato atteso sono di preparazione. I passi con un risultato atteso sono checkpoint, e i checkpoint sono il punto in cui vanno gli screenshot.

Rendi ogni risultato atteso osservabile

"Funziona correttamente" non è un risultato atteso, perché nessuno screenshot può mostrarlo. Un risultato atteso nomina qualcosa di visibile: il testo di un messaggio, un campo, un valore, un titolo di pagina. "Messaggio di conferma: Controlla la tua email per un link di reset" può essere confrontato con lo schermo parola per parola.

Se un risultato atteso non si può vedere a schermo, per esempio il tempo di consegna di un'email, registralo come testo nella descrizione della pagina. Lo screenshot mostra allora lo schermo, e la descrizione riporta il valore.

Mantieni stabili i numeri dei passi

I numeri dei passi nel caso di test e i titoli delle pagine nel registro devono corrispondere. Se il caso viene modificato in seguito e viene inserito un passo, assegna al nuovo passo un suffisso come 2a invece di rinumerare. I vecchi registri continuano così a puntare ai passi giusti, e una ricerca di regressione per "passo 4" trova la stessa azione in ogni build.

I titoli si modificano nel Page Inspector sotto Page title. Riscrivi ogni titolo provvisorio in modo che inizi con l'ID del caso e del passo, poi aggiungi le righe Atteso ed Effettivo sotto Description.

Separa i passi di preparazione dai checkpoint

TC-142 include una preparazione che il registro non mostra: aprire la casella di posta di test, copiare l'indirizzo email, attendere l'email. Lasciarli fuori mantiene il registro a 5 pagine. Se un'azione di preparazione fallisce, diventa un risultato Blocked con una pagina propria, non una lacuna silenziosa.

Un test pratico: se un passo non ha una riga "Atteso" nel caso, non riceve una pagina. Se ne ha una, riceve esattamente una pagina.

Bisogna fare uno screenshot di ogni passo di test QA?

No. Acquisisci questi momenti:

• Stato iniziale: dimostra che le precondizioni sono state soddisfatte.
• Ogni checkpoint: mostra il risultato atteso o inatteso.
• Risultato finale: mostra se l'obiettivo è stato raggiunto o meno.
• Qualsiasi errore: la schermata nel momento in cui si è discostata, più il passo precedente.

Gli screenshot dei semplici clic di navigazione aggiungono pagine senza aggiungere prove. Rendono il registro più lento da rivedere.

Con Temposhot puoi acquisire solo i checkpoint. Apri Action Capture (Command+3), seleziona Configure e imposta Mouse click capture in modo che acquisisca solo i clic con un tasto modificatore, oppure non acquisisca mai i clic. Poi premi Shift+Command+2 (la scorciatoia di acquisizione manuale) in ogni checkpoint. Seleziona Start Action Capture, scegli Specific Window, esegui il test e seleziona Finish capture. Il Document si apre con una pagina per checkpoint.

Se per un test che fallisce vuoi ogni passo, reimposta i clic del mouse su ogni clic. Ogni clic accettato salva la finestra appena prima del clic. La guida Action Capture elenca le modalità di acquisizione.

Confronta le due modalità di registrazione

Le due modalità rispondono a domande diverse. Un registro con solo checkpoint risponde a "ogni checkpoint ha mostrato il risultato atteso?". Un registro con ogni clic risponde a "cosa ha fatto esattamente il tester?", che conta di più quando un test fallisce.

Il piano gratuito ha un limite di 5 passi per ogni esecuzione di Action Capture. Un registro TC-142 con solo checkpoint rientra esattamente in una singola esecuzione gratuita: lo stato iniziale più 4 checkpoint. Un'esecuzione con ogni clic si ferma dopo 5 passi e conserva quelli; Temposhot Pro rimuove il limite.

Configura un'esecuzione con solo checkpoint

Configure Action Capture salva le impostazioni sul Mac, quindi la configurazione dei checkpoint resta attiva per la sessione di test successiva. Ripristinala prima di registrare un tutorial o una segnalazione di bug.

Mark clicked area si applica anche ai passi aggiunti con la scorciatoia manuale. In un registro di checkpoint il marcatore punta dove si trovava il puntatore per caso, il che può indurre in errore il revisore, quindi resta disattivato.

Esegui TC-142 con la scorciatoia

1. Acquisisci lo stato iniziale

   Dopo il conto alla rovescia, premi Shift+Command+2 nella pagina di accesso disconnessa. Questa è la pagina 1.

2. Acquisisci ogni checkpoint

   Esegui ogni passo. Quando il risultato atteso deve essere visibile a schermo, premi di nuovo la scorciatoia. Le pagine da 2 a 5 sono i 4 checkpoint.

3. Termina

   Premi Command+. o seleziona Finish capture. Il Document si apre con 5 pagine.

Checkpoint che scompaiono rapidamente

Alcuni risultati attesi restano visibili solo per pochi secondi, come un messaggio toast dopo l'invio di un modulo. Premi la scorciatoia appena compare il messaggio: il passo salva la schermata in quel momento. Se il messaggio scompare prima della pressione del tasto, ripeti il passo e tieni le mani sui tasti.

Se un risultato compare troppo brevemente per essere catturato, scrivilo nella descrizione e acquisisci la schermata successiva. "Atteso: toast Password updated. Effettivo: toast visto, chiuso dopo circa 3 secondi, dashboard mostrata." Il revisore sa così che il toast è stato osservato e perché non è nella pagina.

Test che attraversano più finestre

TC-142 passa dal browser alla casella di posta di test e viceversa. Quando la casella si apre in un'altra finestra del browser, un target Specific Window continua ad acquisire solo la prima finestra. Scegli Full Screen per un test che usa più finestre, e chiudi tutto ciò che non appartiene al test prima dell'esecuzione.

Cambia modalità quando un checkpoint fallisce

Quando il passo 4 fallisce, un registro di checkpoint mostra il risultato ma non l'input esatto. Esegui di nuovo il test in modalità ogni clic per registrare il percorso fino al fallimento. Allega questa seconda esecuzione alla segnalazione di bug e conserva il primo registro come risultato del test.

Registra i risultati effettivi senza riscrivere la cronologia

Il registro deve mostrare cosa è successo, non cosa avrebbe dovuto succedere. Nell'editor del Document:

• Intitola ogni pagina con l'ID del passo e l'azione, per esempio "TC-142 passo 4: Invia nuova password".
• Nella Page description, scrivi i risultati attesi ed effettivi su righe separate.
• In un checkpoint fallito, disegna un Rectangle (R) attorno al valore sbagliato e aggiungi un'etichetta Text (T) con "Fail".

Non ritagliare il contesto che il revisore deve vedere, come l'URL o l'etichetta della build. Usa Framing solo per rimuovere finestre non pertinenti. Oscura i dati personali con Blur (B, Pro), e non modificare mai un valore per far sembrare corretto un risultato.

Regole di annotazione per le prove

Le annotazioni in Temposhot sono non distruttive: lo screenshot sotto un rettangolo o un'etichetta resta invariato. Questo mantiene intatte le prove, ma chi legge il PDF esportato vede solo la pagina renderizzata. Le regole su ciò che un'annotazione può e non può fare mantengono affidabile l'esportazione.

Scrivi la descrizione in un formato fisso

Un formato fisso su due righe rende le descrizioni facili da scorrere su 5 o 50 pagine. La prima riga è "Atteso:" con il risultato atteso. La seconda riga è "Effettivo:" con ciò che mostra lo screenshot.

Per la pagina 5 di TC-142, la descrizione dice "Atteso: accesso effettuato, dashboard mostrata. Effettivo: banner Reset link expired, mostrato il modulo di accesso." Il revisore può confrontare la riga Effettivo con lo screenshot con un solo sguardo.

Usa questo registro di esecuzione QA

• ID del caso di test, obiettivo, build, ambiente, tester, data.
• Precondizioni e dati di test.
• Passi con risultati attesi.
• Screenshot di inizio, checkpoint, fine ed errori.
• Risultato effettivo per ogni checkpoint.
• Stato: Pass, Fail o Blocked.
• Segnalazione di bug collegata per ogni errore.

Esporta dal Document con Export PDF per allegarlo allo strumento di gestione dei test, oppure esporta le pagine PNG da More export formats per le prove incorporate. Nomina i file con l'ID del caso e la build, per esempio TC-142_build-2026-08-27.pdf. La guida all'esportazione elenca i formati. Per confrontare due screenshot della stessa schermata tra build diverse, lo strumento browser Compare Images evidenzia le differenze in locale.

Impostazioni PDF per un registro di test

Le impostazioni predefinite di Export PDF sono adatte alla maggior parte dei registri: A4, Landscape, pagina di copertina, numeri di passo e di pagina attivi, descrizioni prima dell'immagine. La copertina inizia con il titolo del documento e il numero di passi, quindi un titolo come "TC-142 build 2026-08-27 Fail" mostra il risultato già a pagina uno. Personalizzare le impostazioni PDF richiede Temposhot Pro.

Con Pro, i team che stampano su carta US passano Paper size a Letter. Impostare Image quality su Small file mantiene piccolo un registro di regressione di 50 pagine, abbastanza da rispettare i limiti di dimensione degli allegati degli strumenti.

Imposta lo stato dalle prove

Ogni stato richiede prove diverse. Un revisore che vede uno stato senza le pagine corrispondenti deve rimandare indietro il registro.

Organizza i registri per caso e build

Un registro si ritrova in seguito per ID del caso e build, raramente per sola data. Mantieni una cartella per caso con una sottocartella per build, così una ricerca di regressione confronta lo stesso caso tra build diverse.

I file immagine dei Document prendono il nome dai titoli delle pagine. Titoli che iniziano con l'ID del passo producono quindi nomi di file che si ordinano per passo e corrispondono tra una build e l'altra.

Confronta un checkpoint tra build

Quando TC-142 supera il test con la build del 2026-09-03 dopo essere fallito il 2026-08-27, apri entrambi i file PNG del passo 4 in Compare Images. La vista a cursore o quella di differenza di pixel mostrano se è cambiato solo il banner o se si è spostato anche il layout. Conserva entrambi i registri: quello fallito documenta la regressione.

Verifica le prove e approva

Un revisore deve confermare tre cose senza eseguire il test: le precondizioni sono state soddisfatte, ogni checkpoint mostra il risultato dichiarato e lo stato finale corrisponde agli screenshot. Se un revisore deve indovinare, il registro necessita di un altro checkpoint.

Temposhot conserva i Document in locale e non offre flussi di approvazione. Allega i file esportati allo strumento di gestione dei test o al ticket in cui si tracciano le approvazioni.

Il controllo del revisore, in ordine

Un revisore può controllare un registro di 5 pagine in pochi minuti leggendolo in un ordine fisso. Prima confronta il titolo di copertina e la pagina 1 con le precondizioni: build, URL e stato disconnesso. Poi leggi ogni pagina di checkpoint e confronta la riga "Effettivo" con lo screenshot.

Terzo, verifica che lo stato in copertina corrisponda alle pagine. Un registro marcato Pass con un banner di errore rosso nella pagina 5 torna al tester. Anche un registro marcato Fail senza una segnalazione di bug collegata torna indietro.

Blocked non è Fail

Un test è Blocked quando non può raggiungere un checkpoint per un motivo esterno al comportamento in test. In TC-142, un'interruzione dello staging che impedisce l'arrivo dell'email di reset blocca il passo 3. Il registro mostra lo stato iniziale e l'ultima schermata raggiungibile, con il motivo nella descrizione.

Marcare un test bloccato come Fail alza il tasso di fallimento e invia un bug alla squadra sbagliata. Marcarlo come Pass nasconde la lacuna. Mantieni Blocked come stato a sé e ripeti il caso quando il blocco è risolto.

Dal checkpoint fallito al retest

Un fallimento segue un percorso fisso. Il registro originale resta invariato in ogni fase.

Flusso da tastiera per una sessione di test

Un tester che esegue 10 o 20 casi in una sessione beneficia di restare sulla tastiera. Le scorciatoie seguenti coprono la registrazione e il primo passo di modifica.

Conservazione dei registri sul Mac

I Document restano sul Mac che li ha registrati, e le sessioni grezze restano in Capture History fino al limite di conservazione. Il limite predefinito è 30 sessioni, regolabile da 1 a 500 in Settings > History. Un ciclo di test intenso può superare 30 sessioni in pochi giorni, quindi esporta ogni registro nello strumento di gestione dei test quando il caso è completato.

Domande frequenti

Gli screenshot bastano come prova di test?

Per i test manuali dell'interfaccia sono una parte centrale. Aggiungi log, output della console o dati di rete come testo quando il fallimento non è visibile a schermo. Vedi prove tramite screenshot.

Anche i test automatizzati devono produrre screenshot?

Le suite automatizzate di solito acquisiscono screenshot al fallimento. Per confrontare automaticamente gli screenshot tra build, vedi test di regressione visiva.

Come segnalo un fallimento trovato durante il QA?

Scrivi una segnalazione di bug separata collegata al caso di test. Vedi come documentare un bug con screenshot passo passo.

Quante pagine dovrebbe avere un registro di test?

Una per lo stato iniziale, una per ogni checkpoint e una per ogni fallimento. TC-142 ha 4 checkpoint, quindi un registro superato ha 5 pagine.

Una pagina di checkpoint può mostrare il puntatore?

Sì. Attiva Show cursor in shortcut captures in Configure Action Capture. Lascialo disattivato quando la posizione del puntatore non ha significato per il risultato.

Trasforma i tuoi clic in una guida passo passo chiara

Action Capture registra i checkpoint con una scorciatoia o ogni clic, a seconda dell'esecuzione. Scarica Temposhot e allega il tuo prossimo registro di test come PDF ordinato.