Buone pratiche
Nomi, scenari, note, una descrizione e un ambiente di test dedicato: ciò che fa durare i test.
Un test viene letto più spesso di quanto venga scritto
Una registrazione vi dà un test funzionante in pochi minuti.Qualche minuto in più in GUI Test Studio lo trasforma in un test che tutto il team può leggere: nella timeline, nel report di affidabilità e nelle segnalazioni di bug che produce.
Tutto ciò che segue compare nel report.Un report che dice “Verifica pulsante Salva non superata in Pagamento” dice a uno sviluppatore cosa si è rotto prima che apra qualsiasi cosa.
Dare un nome a ciò che conta
Ogni passaggio riceve un nome da solo, come “Clic” o “Asserzione visiva”.Date a quelli importanti un nome vostro: selezionate il blocco e premete F2.
| Invece di | Chiamatelo |
|---|---|
| Asserzione visiva | Verifica pulsante Nuovo ticket |
| Asserzione testuale | Verifica messaggio ordine confermato |
| Testo digitato | Digita nome cliente |
| Clic | Clic su Convalida |
Raggruppare i passaggi in scenari
Selezionate i passaggi di una parte del percorso e premete Ctrl+G: “Accesso”, “Aggiungi al carrello”, “Paga”.Un test lungo diventa pochi capitoli colorati, il report dice in quale si è fermata un'esecuzione, e uno scenario come “Accesso” può essere riutilizzato in altri test.
Approfondite in Scenari: riutilizzare gruppi di passaggi.
Lasciare note
Un marcatore è una nota sulla timeline (M).Usatelo per ciò che la prossima persona non può indovinare: perché un controllo è permissivo, di quali dati ha bisogno il passaggio, cosa fare quando fallisce.
Descrivere il test
Aprite Impostazioni, Impostazioni progetto e scrivete la descrizione: cosa copre il test, lo stato da cui parte, i dati di cui ha bisogno.
“Pagamento con una carta salvata.Partenza: disconnessi, sulla pagina iniziale, utente di test qa-01 con il carrello vuoto.Richiede il gateway di pagamento di test.”
Usare un ambiente di test dedicato
I test sono stabili solo quanto ciò su cui girano.Eseguiteli su una macchina e su dati riservati ai test, non sul computer su cui lavorate.
Un ambiente dedicato
- Una macchina di test o una macchina virtuale con dimensione dello schermo e ridimensionamento fissi
- Una copia di test della vostra app, con dati reimpostati prima di ogni esecuzione
- Account di test che nessun altro usa
- Nessuna notifica, aggiornamento o finestra a comparsa durante un'esecuzione
Uno condiviso o personale
- Il vostro desktop, dove finestre e impostazioni cambiano ogni giorno
- Dati di produzione che altre persone modificano
- Un account condiviso il cui carrello o la cui cronologia cambiano continuamente
- Una macchina che va in sospensione, si blocca o installa aggiornamenti a metà esecuzione
Mantenere i test piccoli e indipendenti
Un test, un percorso.Dieci test brevi vi dicono esattamente cosa si è rotto; un test lungo vi dice solo che qualcosa si è rotto, e tutto ciò che segue il suo primo errore resta non controllato.
Ogni test dovrebbe preparare da sé il proprio stato di partenza, con un passaggio Esegui app o Esegui script Python all'inizio, e non dipendere mai dal fatto che un altro test sia stato eseguito prima.
Una lista di controllo prima di condividere un test
- Il test ha una descrizione: cosa copre e da dove parte
- I suoi passaggi sono raggruppati in scenari con un nome
- Ogni controllo ha un nome che uno sviluppatore capirebbe
- I valori che cambiano (date, totali, numeri d'ordine) sono controllati per tipo, non per valore
- Parte da uno stato noto, da solo
- È stato superato due volte di seguito sulla macchina di test
Ancora bloccati?Diteci cosa stavate cercando di fare e rispondiamo entro un giorno lavorativo.Ask our team