Introduzione
In molti dei progetti su cui ho lavorato, le persone non configuravano TestRail secondo le proprie esigenze e si accontentavano delle impostazioni predefinite. Pertanto, in questo articolo cercherò di descrivere un esempio di impostazioni personalizzate che possono aiutarti a migliorare l'efficienza del tuo lavoro. Per esempio, consideriamo un progetto di sviluppo di un'applicazione mobile.
Una breve avvertenza. In questo articolo non viene descritta la funzionalità di base di TestRail (ci sono moltissimi guide su questo) né frasi promozionali che descrivono in modo accattivante il perché scegliere proprio questo vendor per creare un repository di test.
Piano di giustificazione (cosa sarà realizzato)
Requisiti generali
Il caso deve poter essere eseguito da qualsiasi persona
I casi devono mantenere la loro rilevanza il più a lungo possibile
I casi devono coprire il più possibile le funzionalità dell'app mobile, nella misura in cui ciò non contrasti con i primi due punti
Divisione in TestCase e TestScenario
Creazione rapida di TestRun di vari tipi
Smoke
Regress
Test di Impatto ecc.
Ottimizzazione del supporto ai casi
Abbandono degli screenshot 'statici' hardcoded e passaggio ai 'movable data'
Requisiti
Per modificare i campi avrai bisogno di accesso amministrativo
Scelta del tipo di progetto
Puoi scegliere tra tre tipi di progetto:
Sceglieremo il tipo di default. In esso saranno disponibili tutti i casi contemporaneamente. Useremo una filtrazione intelligente e gestiremo dinamicamente tutti i casi contemporaneamente.
Aggiunta di campi per la visualizzazione dell'elenco dei test case
Aggiungiamo un campo per visualizzare la priorità dei test case:
È possibile aggiungere anche altri campi.
Configurazione dei campi e dei tag del test case
Apriamo il menu di configurazione:
Avremo bisogno dei seguenti campi:
Campo «Summary» (intestazione del caso di test)
Questo campo esiste già, stiamo solo sistematizzando il suo utilizzo. Divideremo i casi in TestCase e TestScenario. Per una migliore leggibilità di un lungo elenco di casi, è meglio concordare in anticipo le linee guida per la redazione del summary.
TestScenario:
Esempio: TestScenario — Scenari principali di utilizzo dell'app mobile
TestCase:
Esempio: MainScreen — Sezione di autenticazione — Inserimento del nome utente
In sintesi, vediamo nel summary del caso la comprensione classica: 'cosa, dove, quando'. Inoltre, visivamente separiamo gli scenari di test di alto livello dai test case di basso livello nel formato più adatto per l'automazione.
Tag «StartScreen» (schermata da cui inizia il TestScenario, inoltre molti casi di test possono toccare schermate adiacenti)
A cosa può servire: rimuoveremo dal testo dei test case i passaggi standard che portano l'utente allo schermo dell'attuale test case. (passaggi standard per creare una situazione di test specifica) Tutti i passaggi standard per tutti i test case saranno riportati in un unico file. Di questo ne parlerò più nel dettaglio separatamente.
Creiamo un nuovo campo:
Compiliamo i componenti del nuovo campo:
In questo caso stiamo creando un campo di selezione da un elenco di valori. Inseriamo i valori di questo campo:
Si prega di notare che gli id dei valori non iniziano da uno e non sono consecutivi. Perché è stato fatto in questo modo? Il motivo è che se avessimo registrato test case con id inseriti,
e dopo di ciò dovessimo creare un terzo schermo tra i due esistenti,
dovremmo riscrivere gli id, e poiché a loro sono già legati i tag dei test case esistenti, questi verrebbero semplicemente eliminati. Sarebbe molto sgradevole.
Tag «Screen» (nome dello schermo che coinvolge il TestCase)
A cosa può servire: uno dei punti di ancoraggio per il test di impatto. Ad esempio, i programmatori hanno creato una nuova funzionalità potente. Dobbiamo testarla, ma per farlo dobbiamo capire quale sia questa funzionalità che potrebbe essere stata influenzata. Di default possiamo partire dal paradigma che diversi schermi (Activity) nell'app hanno classi diverse e quindi compongono componenti diversi dell'app. Ovviamente in questo caso è necessario un approccio individuale.
Esempio: home_screen, MapScreen, PayScreen, ecc.
Campo «MovableData» (link al proxy del database con dati di test modificabili)
In seguito cercheremo di risolvere il problema del supporto all'aggiornamento dei dati nei test case:
Riferimenti a modelli aggiornati (questo è molto meglio che creare screenshot morti)
Passaggi standard fino allo schermo con la situazione di test
Richieste SQL
Riferimenti a dati esterni e altri dati
Invece di inserire i dati di test all'interno di ogni caso di test, creeremo un file esterno e collegaremo tutti i casi di test ad esso. Quando aggiorneremo questi dati, non sarà necessario esaminare ogni caso di test e modificarli, ma sarà possibile cambiare questi dati in un unico luogo. Se qualcuno non preparato apre un caso di test, vedrà nel corpo del caso di test un collegamento al file e un suggerimento che deve andare lì per i dati di test.
Tutti questi dati li confezioneremo in un unico file esterno, che sarà accessibile a chiunque desideri nel progetto. Ad esempio, è possibile utilizzare Google Sheet o Excel e configurare una ricerca all'interno del file. Perché proprio questi fornitori? Il fatto è che ci basiamo sulla paradigma che chiunque nel team deve essere in grado di aprire e completare un caso di test senza dover installare strumenti preventivi.
Per Google Sheet è possibile utilizzare query SQL. Esempio:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"Per Excel è possibile configurare macro pratiche per la ricerca immediata. (filtrazioni) Esempio .
In effetti, l'idea non è nuova ed è descritta nel primo libro del tester "Testing dot com". (autore Roman Savin) Noi stiamo solo integrando in TestRail le metodologie proposte da Roman Savin. A tal fine, creeremo un campo con un collegamento al file creato:
compiliamo il valore predefinito del collegamento, in modo che ogni nuovo caso di test abbia già il collegamento:
Se la posizione del file esterno cambia (prevediamo qualsiasi imprevisto) è possibile modificare facilmente uno o più campi in tutti i casi di test contemporaneamente:
Campo "Descriptions" (descrizione o idea del caso di test, istruzioni tipiche)
A cosa potrebbe servire: In questo campo di testo inseriremo una breve descrizione del caso di test e istruzioni tipiche.
Esempio: Tutti i dati di test (modelli attuali, utilizzo degli strumenti e altre informazioni) di questo caso di test sono contrassegnati da collegamenti {...} e si trovano nel file MovableData. Il collegamento a MovableData nel campo corrispondente in alto.
Tag «Component» (componente dell'app mobile)
A cosa può servire: per i test di impatto. Se l'applicazione mobile può essere suddivisa in componenti (che si influenzano il meno possibile l'uno con l'altro), allora sarà sufficiente testare le modifiche in un componente (con alcuni rischi) all'interno di quel componente stesso, riducendo il motivo per condurre regressioni globali per tutto. Se ci sono informazioni che un componente può influenzare un altro, viene compilata una matrice di test di impatto.
Esempi di componenti: GooglePay, Ordine, Utenti, Mappa, Autorizzazione, ecc.
Tag «TAG» (Altri tag per la filtrazione)
Etichettatura del caso di test con etichette per un filtraggio arbitrario.
Molto utile per:
la rapida creazione di TestRun per vari compiti tipici: smoke, regressione, ecc.
se i test saranno automatizzati o già automatizzati
qualsiasi altro tag
Esempio: Smoke, Automated, WhiteLabel, ForDelete, ecc.
Impostiamo l'ordine di visualizzazione dei campi nel caso di test
Abbiamo creato molti nuovi campi, è giunto il momento di disporli in un ordine comodo:
Creazione di TestRun
Ora creeremo un nuovo test run con i casi aggiornati per effettuare test di smoke in tre clic:
Altri utili consigli
Se in TestRail ci sono più progetti, non dimenticate di creare nuovi campi solo per il vostro progetto, altrimenti i colleghi dei team vicini potrebbero sorprendersi per l'emergere di nuovi campi insoliti. Possono verificarsi svenimenti locali.
2. I casi con un numero elevato di campi sono più facili da copiare da un gruppo di tipo simile piuttosto che crearne di nuovi:
3. È possibile utilizzare gli account in modo condiviso. Ad esempio: un account amministrativo, diversi account utente.
Conclusione
Gli esempi sopra descritti sono stati implementati in diversi progetti e hanno dimostrato la loro efficacia. Spero che possano aiutare a migliorare la vostra comprensione di questo strumento e a creare test efficienti e comodi "depositi di test". Vi sarei molto grato se nei commenti descriveste la vostra esperienza con TestRail e suggerimenti utili.
Link:
Libro:
Grazie mille per l'attenzione!
Fonte: habr.com
