Introduzione
In molti progetti con cui ho lavorato, le persone non personalizzavano TestRail e si accontentavano delle impostazioni predefinite. Pertanto, in questo articolo cercherò di descrivere un esempio di impostazioni personalizzate che possono aiutarti ad aumentare l'efficacia del tuo lavoro. Prendiamo come esempio un progetto di sviluppo di un'app mobile.
Una piccola nota. In questo articolo non verrà descritta la funzionalità di base di TestRail (ci sono molte guide su questo) né ci saranno espressioni di marketing colorate che spiegano perché dovresti scegliere proprio questo fornitore per creare un repository di test.
Piano di attuazione (cosa sarà realizzato)
Requisiti generali
Il caso deve essere in grado di essere eseguito da chiunque
I casi devono mantenere la loro attualità il più a lungo possibile
I casi devono coprire in modo accurato le funzionalità dell'app mobile nella misura in cui ciò non contraddica i primi due punti
Separazione in TestCase e TestScenario
Generazione rapida di TestRun di vari tipi
Smoke
Regress
Test di impatto, ecc.
Ottimizzazione del supporto ai casi
Abbandono di screenshot fissi e passaggio a "dati movibili"
Requisiti
Per modificare i campi è necessaria l'autenticazione da amministratore
Scelta del tipo di progetto
È possibile scegliere tra tre tipi di progetto:
Selezioneremo il tipo predefinito. In questo verranno resi disponibili tutti i casi contemporaneamente. Utilizzeremo un filtro intelligente e gestiremo dinamicamente tutti i casi insieme.
Aggiunta di campi per visualizzare l'elenco dei test case
Aggiungeremo un campo per visualizzare la priorità dei test case:
È possibile aggiungere anche altri campi.
Impostazione dei campi e dei tag del test case
Apriamo il menu di configurazione:
Ci serviranno i seguenti campi:
Campo «Summary» (intestazione del test case)
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, è preferibile concordare in anticipo le linee guida per la scrittura del summary.
TestScenario:
Esempio: TestScenario — Scenari principali di utilizzo dell'app mobile
TestCase:
Esempio: MainScreen — Sezione di accesso — Inserimento del login
In summary, we see a classic understanding of the case: “what, where, when.” Visually, we also differentiate between high-level test scenarios and low-level test cases in the most appropriate format for automation.
The tag 'StartScreen' (the screen from which the TestScenario begins, with many test cases potentially impacting adjacent screens)
What might it be needed for: we will remove from the text of the cases the standard steps that lead the user to the current test case screen. (standard steps to create a specific testing situation) All standard steps for all test cases will be documented in one file. I will write more about it separately.
We create a new field:
We fill in the components of the new field:
In this case, we are creating a drop-down selection field. We input the values for this field:
Note that the ids of the values do not start at one and are not consecutive. Why is this done? The fact is that if we have test cases recorded with a given id,
and afterward, we need to create a third screen between the two existing ones,
Dovremo riscrivere l'id, e poiché i tag dei casi di test esistenti sono già collegati a esso, verranno semplicemente rimossi. Questo sarà molto sgradevole.
Il tag "Screen" (denominazione dello schermo coinvolto nel TestCase)
A cosa può servire: uno degli ancoraggi per il test d'impatto. Ad esempio, gli sviluppatori hanno creato una nuova funzionalità interessante. Dobbiamo testarla, ma per farlo dobbiamo capire cosa questa funzionalità potrebbe avere impattato. Di default possiamo basarci sul paradigma che diversi schermi (Activity) dell'applicazione hanno classi diverse e quindi costituiscono componenti differenti dell'app. Certamente, in questo caso è necessario un approccio personalizzato.
Esempio: home_screen, MapScreen, PayScreen, ecc.
Il campo "MovableData" (riferimento a un proxy DB con dati di test modificabili)
Successivamente cercheremo di risolvere il problema del supporto alla pertinenza dei dati nei casi di test:
Collegamenti ai layout aggiornati (è molto meglio che fare screenshot obsoleti)
Passaggi standard fino allo schermo con la situazione di test
Query SQL
Collegamenti a dati esterni e altre informazioni
Invece di scrivere i dati di test all'interno di ogni caso di test, creeremo un file esterno e collegheremo questo file a tutti i casi di test. Quando sarà necessario aggiornare questi dati, non dovremo passare in rassegna tutti i casi di test e modificarli; potremo semplicemente cambiare i 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'indicazione di doverci andare per i dati di test.
Tutti questi dati saranno confezionati in un unico file esterno, accessibile a chiunque nel progetto. Ad esempio, possiamo utilizzare Google Sheet o Excel e impostare la ricerca all'interno del file. Perché proprio questi fornitori? Perché ci basiamo sulla paradosso che chiunque nel team dovrebbe essere in grado di aprire e completare un caso di test senza dover installare preventivamente strumenti vari.
Per Google Sheet è possibile utilizzare query SQL. Esempio:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"Per Excel è possibile impostare macro convenienti per ricerche istantanee. (filtraggio) Esempio .
L'idea in sé non è nuova e viene descritta nel primo libro del tester “Testing dot com”. (autore Roman Savin) Stiamo semplicemente 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 in ogni nuovo caso di test ci sia già il collegamento:
Se la posizione del file esterno cambia (prevediamo qualsiasi imprevisto), è possibile modificare comodamente uno o più campi in tutti i casi di test contemporaneamente:
Campo “Descriptions” (descrizione o idea del caso di test, istruzioni standard)
A cosa può servire: in questo campo di testo inseriremo una breve descrizione del caso di test e istruzioni standard.
Esempio: Tutti i dati di test (modelli attuali, utilizzo degli strumenti e altri dati) di questo caso di test sono indicati tramite collegamenti {…} e si trovano nel file MovableData. Il collegamento a MovableData è nel campo corrispondente in alto.
Tag «Component» (componente dell'applicazione mobile)
A cosa può servire: per il test d'impatto. Se un'app mobile può essere suddivisa in componenti (che influenzano il meno possibile l'uno sull'altro), le modifiche in un componente possono essere verificate (con alcuni rischi) all'interno dello stesso componente, riducendo la necessità di eseguire regressioni complete. Se si ha notizia che un componente possa influenzarne un altro, si compila una matrice di test d'impatto.
Esempi di componenti: GooglePay, Ordine, Utenti, Mappa, Autenticazione, ecc.
Tag "TAG" (Altri tag per il filtro)
Tagging dei casi di test con etichette per un filtro arbitrario.
Molto utile per:
la rapida creazione di TestRun per vari tipi di attività: smoke, regressione, ecc.
se i test saranno automatizzati o sono già automatizzati
qualsiasi altro tag
Esempio: Smoke, Automatizzato, WhiteLabel, DaEliminare, ecc.
Impostazione dell'ordine di visualizzazione dei campi nel caso di test
Abbiamo creato molti nuovi campi, è arrivato il momento di disporli in modo conveniente:
Creazione di TestRun
Ora creeremo un nuovo test run con i casi aggiornati per eseguire test smoke in tre clic:
Altri consigli utili
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 rimanere molto sorpresi dalla comparsa di nuovi campi insoliti. Potrebbero verificarsi svenimenti locali.
2. I casi con un gran numero di campi sono più facili da copiare da un gruppo simile che crearne di nuovi:
3. È possibile utilizzare gli account in modo condiviso. Ad esempio: un account da amministratore e diversi account utente.
Conclusione
Gli esempi sopra descritti sono stati implementati in diversi progetti e hanno dimostrato la loro efficacia. Spero che possano migliorare la vostra comprensione di questo strumento e aiutare a creare test efficaci e comodi. Sarei molto grato se poteste descrivere nella sezione commenti la vostra esperienza nell'uso di TestRail e fornire consigli utili.
Link:
Libro:
Grazie mille per l'attenzione!
Fonte: habr.com
