TestRail — Anpassade inställningar för projekt

Introduktion

I många projekt som jag har arbetat med har människor inte anpassat TestRail efter sina behov och har istället använt standardinställningarna. Därför kommer jag i denna artikel att försöka beskriva exempel på anpassade inställningar som kan hjälpa dig att öka effektiviteten i ditt arbete. Låt oss för detta exempel ta ett projekt för utveckling av en mobilapplikation.

En liten varning. Denna artikel innehåller inte en beskrivning av TestRails grundläggande funktionalitet (det finns många guider för det) eller säljande fraser som målar upp varför man bör välja just denna leverantör för att skapa en databas med tester.

Planering (vad som kommer att genomföras)

1. Allmänna krav

   1. Fallet måste kunna utföras av vem som helst

   2. Testfallen måste förbli aktuella så länge som möjligt

   3. Testfallen måste så noggrant som möjligt täcka funktionaliteten hos mobilapplikationen i den utsträckning som inte strider mot de två första punkterna

2. Separering av TestCase och TestScenario

3. Snabb generering av TestRun av olika typer

   1. Smoke

   2. Regress

   3. Impact-testning etc.

4. Optimering av stöd för testfall

   1. Överge 'döda' hårdkodade skärmdumpar och övergå till 'rörliga data'

Krav

För att redigera fälten behöver du administratörsåtkomst

Val av projekttyp

Tre projektyper kan väljas:

Vi väljer standardtyp. I den kommer alla testfall att vara tillgängliga samtidigt. Vi kommer att använda smart filtrering och dynamiskt hantera alla testfall på en gång.

Lägga till fält för att visa listan över testfall

Låt oss lägga till ett fält för att visa prioriteringen av testfallen:

Det går också att lägga till andra fält.

Inställning av fält och taggar för testfall

Vi öppnar inställningsmenyn:

Vi kommer att behöva följande fält:

Fältet "Sammanfattning" (huvudrubrik för testfall)

Detta fält finns redan, vi systematiserar bara dess användning. Vi kommer att dela upp fallen i TestCase och TestScenario. För att göra den långa listan av testfall mer läsbar är det bättre att i förväg komma överens om regler för hur sammanfattningen ska skrivas.

TestScenario:

Exempel: TestScenario — Huvudsakligt användningsscenario för mobilapplikationen

TestCase:

Exempel: MainScreen — Inloggningsdelen — Ange användarnamn

Sammanfattningsvis ser vi att sammanfattningen av fallet utgör den klassiska förståelsen: “vad, var, när”. Vi delar också upp de övergripande testscenarierna och de detaljerade testfallen på det mest lämpliga sättet för automatisering.

Taggen «StartScreen» (skärmen varifrån TestScenario börjar, samt många testfall kan beröra närliggande skärmar)

För vilket syfte det kan behövas: vi kommer att ta bort generiska steg från texten i testfallen som leder användaren till skärmen för det aktuella testfallet. (generiska steg för att skapa en specifik testsituation) Alla generiska steg för alla testfall kommer att skrivas i en fil. Mer om detta kommer jag att skriva separat.

Skapa ett nytt fält:

Fyll i komponenterna för det nya fältet:

I det här fallet skapar vi ett urvalsfält från en lista med värden. Vi anger värdena för detta fält:

Observera att id-värdena inte börjar med ett och inte är i följd. Varför är det på det här sättet? Det beror på att om vi har registrerade testfall med inmatad id,

och efter det behöver vi skapa en tredje skärm mellan de två redan befintliga,

då måste vi skriva om id, och eftersom de redan är kopplade till de befintliga testfallens taggar, kommer de helt enkelt att försvinna. Det skulle vara mycket obehagligt.

Taggen «Screen» (namnet på skärmen som berör TestCase)

För vilket syfte det kan behövas: en av ankarna för påverkanstestning. Till exempel, om utvecklarna har gjort en ny cool funktion. Vi behöver testa den, men för detta måste vi förstå vad exakt denna funktion kan ha påverkat. Som standard kan vi utgå ifrån paraddigmen att olika skärmar (Activity) i applikationen har olika klasser och därmed utgör olika komponenter i applikationen. Självklart krävs det ett individuellt tillvägagångssätt i detta fall.

Exempel: home_screen, MapScreen, PayScreen osv.

Fältet «MovableData» (länk till en proxydatabas med änderliga testdata)

Därefter kommer vi att försöka lösa problemet med att upprätthålla datans aktualitet i testfallen:

1. Länkar till aktuella skisser (detta är mycket bättre än att göra döda skärmdumpar)

2. Generiska steg till skärmen med testsituationen

3. SQL-frågor

4. Länkar till externa data och andra uppgifter

Istället för att skriva testdata inom varje testfall kommer vi att skapa en extern fil och länka till den i alla testfall. Vid uppdatering av dessa data kommer vi inte att behöva gå igenom alla testfall och ändra dem, utan bara kunna ändra dessa data på ett ställe. Om någon som inte är förberedd öppnar ett testfall kommer de att se en länk till filen i testfallstexten och en uppmaning att gå dit för testdata.

All denna data kommer vi att packa i en extern fil som kommer att vara tillgänglig för alla intresserade i projektet. Till exempel kan vi använda Google Sheet eller Excel och ställa in sökfunktionen inuti filen. Varför just dessa leverantörer? Anledningen är att vi utgår ifrån paradigm att vem som helst i teamet bör kunna öppna och gå igenom ett testfall utan att behöva installera olika verktyg på förhand.

För Google Sheet kan använda SQL-frågor. Exempel:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

För Excel kan ställa in bekväma makron för omedelbar sökning. (filtrering) Exempel via länken.

Idén är faktiskt inte ny och beskrivs i den första boken om testning “Testing dot com”. (författare Roman Savin) Vi integrerar bara metodikerna föreslagna av Roman Savin i TestRail. För detta kommer vi att skapa ett fält med en länk till den skapade filen:

fyller i standardvärdet för länken, så att det redan finns en länk i varje nytt testfall:

Om platsen för den externa filen ändras (vi förutsätter alla oförutsedda händelser) kan vi enkelt ändra ett eller flera fält i alla testfall direkt:

Fältet “Descriptions” (beskrivning eller idé för testfallet, standardinstruktioner)

Vad det kan behövas för: I detta textfält kommer vi att placera en kort beskrivning av testfallet och standardinstruktioner.

Exempel: All testdata (aktuella mallar, användning av verktyg och andra data) från detta testfall anges med länkar {…} och finns i filen MovableData. Länken till MovableData finns i motsvarande fält ovan.

Taggen «Component» (komponent av mobilapplikationen)

Vad det kan behövas för: för impact-testning. Om mobilapplikationen kan delas in i komponenter (som påverkar varandra så lite som möjligt), så kan ändringar i en komponent tillräckligt (med vissa risker) testas inom den samma komponenten, och det finns färre skäl för att genomföra allmänna regressioner av allt. Om det finns information om att en komponent kan påverka en annan, så skapas en matris för impact-testning.

Exempel på komponenter: GooglePay, Order, Användare, Karta, Auktorisation osv.

Tagg "TAG" (Övriga taggar för filtrering)

Taggning av testfall med etiketter för godtycklig filtrering. 

Mycket användbart för: 

1. snabb skapelse av TestRun för olika typiska uppgifter: smoke, regression osv.

2. kommer tester att automatiseras eller är de redan automatiserade

3. alla andra taggar

Exempel: Smoke, Automated, WhiteLabel, ForDelete osv.

Ställ in ordningen för visning av fält i testfallet

Vi har skapat många nya fält, det är dags att organisera dem i en bekväm ordning:

Skapa TestRun

Nu kommer vi att skapa en ny testkörning med aktuella testfall för att genomföra smoke-testning på tre klick:

Andra användbara tips

1. Om det finns flera projekt i TestRail, glöm inte att skapa nya fält endast för ditt projekt annars kommer kollegor från angränsande team att bli mycket förvånade över att se nya ovanliga fält. Lokala svimningar kan förekomma.

2. Fall med många fält är lättare att kopiera från en liknande grupp än att skapa nya:

3. Du kan använda konton gemensamt. Till exempel: ett administratörskonto, flera användarkonton.

Slutsats

De ovanstående exemplen har implementerats i flera projekt och har visat sin effektivitet. Jag hoppas att de hjälper till att förbättra din förståelse av detta verktyg och att skapa effektiva och bekväma "testlager". Jag skulle vara mycket tacksam om du i kommentarerna beskriver din erfarenhet av att använda TestRail och ger användbara tips.

Länkar:

TestRail återförsäljarens webbplats

Bok: "Testing .COM" (författare Roman Savin)

Tack så mycket för uppmärksamheten!

Källa: habr.com