Introduktion
I mange projekter, jeg har arbejdet med, har folk ikke tilpasset TestRail til deres behov og har klaret sig med de standardindstillinger, der findes. Derfor vil jeg i denne artikel forsøge at beskrive et eksempel på individuelle indstillinger, der kan hjælpe dig med at øge din arbejdeffektivitet. Som eksempel vil vi tage et projekt til udvikling af en mobilapp.
Lille disclaimer. Denne artikel indeholder ikke en beskrivelse af den grundlæggende funktionalitet i TestRail (der findes mange vejledninger til dette) eller salgsfremmende udtryk, der farverigt beskriver, hvorfor du skal vælge netop denne leverandør til at oprette et repository til testene.
Projektplan (hvad der vil blive implementeret)
Generelle krav
Kassen skal kunne gennemføres af enhver person
Kasserne skal opretholde relevans så længe som muligt
Kasserne skal dække funktionaliteten af mobilappen så grundigt som muligt, så længe det ikke strider mod de to førstnævnte punkter
Opdeling i TestCase og TestScenario
Hurtig oprettelse af TestRun af forskellige typer
Smoke
Regress
Impact testning osv.
Optimering af støtte til kasserne
Ophør med "døde" hårdkodede screenshots og overgang til "movable data"
Krav
For at redigere felterne skal du have administratoradgang
Valg af projekttype
Du kan vælge tre projekttyper:
Vi vælger standardtypen. Her vil alle kasser være tilgængelige samtidig. Vi vil bruge smart filtrering og dynamisk styre alle kasser samtidigt.
Tilføjelse af felter til visning af listen over testkasser
Vi tilføjer et felt til at vise prioriteten af testkasser:
Du kan også tilføje andre felter.
Konfiguration af felter og tags i testkassen
Åbn indstillingsmenuen:
Vi får brug for følgende felter:
Feltet "Summary" (overskrift for testkassen)
Dette felt eksisterer allerede, vi systematiserer blot dets anvendelse. Vi vil opdele kasserne i TestCase og TestScenario. For bedre læsbarhed af en stor liste af kasser er det en god idé at blive enige om reglerne for skrivning af overskrifter.
TestScenario:
Eksempel: TestScenario — Hovedbrugsscenarie for mobilappen
TestCase:
Eksempel: MainScreen — Logindel — Indtastning af brugernavn
Samlet set ser vi i oversigten over kassen den klassiske forståelse: “hvad, hvor, hvornår”. Vi adskiller også visuelt de overordnede testsituationer og de detaljerede testkasser i den mest hensigtsmæssige form for automatisering.
Tag "StartScreen" (the screen from which the TestScenario begins; many test cases may also touch neighboring screens)
Purpose: we will remove standard steps from the text of the test cases that lead the user to the current test case screen. (standard steps for creating a particular test situation) All standard steps for all test cases will be documented in one file. I will write more about it separately.
Creating a new field:
Filling in the components of the new field:
In this case, we are creating a selection field from a list of values. We enter the values for this field:
Note that the value IDs do not start from one and do not go consecutively. Why is that? The reason is that if we have test cases written with a specific ID,
and then we need to create a third screen between two existing ones,
we will have to rewrite the IDs, and since existing test case tags are already tied to these IDs, they will simply be deleted. This would be very unpleasant.
Tag "Screen" (the name of the screen addressed by TestCase)
Purpose: one of the anchors for impact testing. For example, developers have created a new cool feature. We need to test it, but for that, we need to understand what this feature could have affected. By default, we can rely on the paradigm that different screens (Activity) of the application have different classes and therefore form different components of the application. Of course, in this case, an individual approach is needed.
Example: home_screen, MapScreen, PayScreen, etc.
Field "MovableData" (link to a proxy database with modifiable test data)
Next, we will try to solve the problem of maintaining the relevance of data in test cases:
Links to up-to-date layouts (this is much better than making dead screenshots)
Standard steps to the screen with the test situation
SQL queries
Links to external data and other information
I stedet for at skrive testdata direkte ind i hver test case, vil vi oprette én ekstern fil, og alle test cases vil referere til denne. Ved opdatering af disse data behøver vi ikke at gennemgå alle test cases og ændre dem, men kan blot ændre dataene ét sted. Hvis nogen uden forberedelse åbner testcasen, vil de se et link til filen i testen og en besked om, at de skal henvende sig til den for testdata.
Alle disse data vil vi pakke ind i én ekstern fil, som vil være tilgængelig for alle interesserede i projektet. For eksempel kan vi bruge Google Sheet eller Excel og oprette en søgefunktion i filen. Hvorfor lige disse leverandører? Det er fordi, vi baserer os på paradigmet om, at enhver i teamet skal kunne åbne og gennemføre en test case uden at skulle installere forskellige værktøjer på forhånd.
For Google Sheet man kan bruge SQL-forespørgsler. Eksempel:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")For Excel man kan oprette praktiske makroer til øjeblikkelig søgning. (filtrering) Eksempel .
Selve ideen er ikke ny og er beskrevet i den første bog af testeren "Testning dot com". (forfatter Savin Roman) Vi integrerer blot de metoder, som Roman Savin foreslår, i TestRail. For dette formål opretter vi et felt med et link til den oprettede fil:
vi udfylder standardværdien for linket, så hver ny test case allerede har et link:
Hvis placeringen af den eksterne fil ændres (vi forudser enhver force majeure), kan man nemt ændre et eller flere felter i alle test cases på én gang:
Feltet "Descriptions" (beskrivelse eller idé til test case, typiske instruktioner)
Hvad det kan være nyttigt til: I dette tekstfelt vil vi placere en kort beskrivelse af test casen og typiske instruktioner.
Eksempel: Alle testdata (aktuelle skabeloner, brug af værktøjer og andre data) fra denne test case er angivet med links {…} og findes i filen MovableData. Linket til MovableData er i det relevante felt ovenfor.
Tagget "Component" (komponent af mobilapplikationen)
Hvad det kan bruges til: til impact-testning. Hvis en mobilapplikation kan opdeles i komponenter (der påvirker hinanden så lidt som muligt), er det tilstrækkeligt at teste ændringer i en komponent (med nogle risici) inden for den samme komponent, og der vil være færre grunde til at udføre omfattende regressionstest af alt. Hvis der er information om, at en komponent kan påvirke en anden, oprettes der en matrice for impact-testning.
Eksempler på komponenter: GooglePay, Ordre, Brugere, Kort, Autorisation osv.
Tag «TAG» (andre tags til filtrering)
Tagging af test cases med etiketter for vilkårlig filtrering.
Særdeles nyttigt til:
hurtigt at oprette TestRun til forskellige standardopgaver: smoke, regression osv.
vil testene blive automatiseret eller er allerede automatiseret
enhver anden tag
Eksempel: Smoke, Automated, WhiteLabel, ForDelete osv.
Vi konfigurerer rækkefølgen for visning af felter i test casen
Vi har oprettet mange nye felter, nu er det tid til at arrangere dem i en praktisk rækkefølge:
Oprettelse af TestRun
Vi vil nu oprette et nyt test run med de relevante cases til udførelse af smoke testning på tre klik:
Andre nyttige tips
Hvis der er flere projekter i TestRail, skal du ikke glemme at oprette nye felter kun til dit projekt, ellers vil kolleger fra nabogrupper blive meget overraskede over forekomsten af nye, usædvanlige felter. Lokale svimmelhedsproblemer kan opstå.
2. Cases med mange felter er lettere at kopiere fra en lignende gruppe end at oprette nye:
3. Du kan bruge konti fælles. For eksempel: en administrativ, flere brugerkonti.
Konklusion
De førnævnte eksempler er implementeret i flere projekter og har vist sig effektive. Jeg håber, de vil hjælpe med at forbedre din forståelse af dette værktøj og hjælpe med at skabe effektive og bekvemme "testlagre". Jeg vil være meget taknemmelig, hvis du i kommentarerne beskriver din erfaring med at bruge TestRail og nyttige tips.
Links:
Bog:
Tusind tak for opmærksomheden!
Kilde: habr.com
