Fire ud af fem QA-ansøgere ønsker at lære at arbejde med automatiserede tests. Ikke alle virksomheder kan opfylde sådanne ønsker fra manuelle testere i arbejdstiden. Wrike holdt en automatiseringsskole for medarbejdere og realiserede dette ønske for mange. Jeg deltog i denne skole netop som QA-elev.
Jeg lærte at arbejde med Selenium og understøtter nu selvstændigt et vist antal autotests næsten uden hjælp udefra. Og baseret på resultaterne af vores fælles erfaring og mine personlige konklusioner, vil jeg forsøge at udlede selve formlen for den mest ideelle automatiseringsskole.
Wrikes erfaring med at organisere en skole
Da behovet for en automatiseringsskole blev klart, faldt dens organisation til Stas Davydov, den tekniske leder af automatisering. Hvem andre end han kan forklare, hvorfor de kom med dette initiativ, om de opnåede resultater, og om de fortryder den brugte tid? Lad os give ham ordet:
— I 2016 skrev vi en ny ramme for autotest og gjorde det, så det blev nemt at skrive test: Der dukkede normale trin op, strukturen blev meget mere forståelig. Vi fik en idé: Vi skal involvere alle, der vil skrive nye tests, og for at gøre det lettere at forstå, har vi lavet en række foredrag. Vi kom sammen med en emneplan, hver af de kommende undervisere tog en for sig selv og udarbejdede en rapport om den.
— Hvilke vanskeligheder havde eleverne?
— Hovedsageligt naturligvis arkitektur. Der var mange spørgsmål om opbygningen af vores tests. Som feedback blev der skrevet meget om dette emne, og vi var nødt til at holde yderligere foredrag for at forklare mere detaljeret.
– Har skolen betalt sig?
- Ja helt sikkert. Takket være hende var mange mennesker involveret i at skrive test, og i gennemsnit begyndte alle på hospitalet bedre at forstå, hvad autotest er, hvordan de skrives, og hvordan de lanceres. Belastningen på automationsingeniører er også faldet: Vi modtager nu mange gange færre henvendelser om hjælp til at analysere tests, da testere og udviklere er begyndt at klare dette selv i næsten alle situationer. Nå, der er flere interne fordele for afdelingen: Vi fik erfaring med præsentationer og forelæsninger, takket være hvilke nogle automationsingeniører allerede har formået at lave præsentationer på konferencer, og også modtaget et kraftfuldt sæt videoer og præsentationer til onboarding af nytilkomne.
På egne vegne vil jeg tilføje, at kommunikationen mellem vores afdelinger er blevet forenklet til et rent ud sagt latterligt nemt niveau. For eksempel behøver jeg nu praktisk talt ikke at tænke på, hvilke sager og på hvilket atomicitetsniveau jeg skal automatisere. Det resulterer i, at alle interesserede tager sig fuldt ud af testdækningen, som konstant vokser. Ingen kræver det umulige af andre.
Generelt er indvirkningen på teams arbejde absolut positiv. Måske overvejer kolleger, der læser denne artikel, også at gøre noget lignende? Så vil rådet være enkelt: det er det værd, hvis automatiserede tests er en prioritet for dig. Dernæst vil vi tale om et mere komplekst spørgsmål: hvordan man organiserer alt dette så korrekt som muligt, så omkostningerne for alle parter er minimale, og outputtet er maksimalt.
Tips til organisering
Skolen var nyttig, men som Stas indrømmede, var der nogle vanskeligheder, hvorfor det var nødvendigt at arrangere yderligere forelæsninger. Og det var som en nylig studerende, der sammenlignede mig selv-uvidenhed og mig selv-nu, at jeg formulerede følgende trin for at skabe, efter min mening, den ideelle måde at lære testere at forstå automatiserede tests.
Trin 0. Opret en ordbog
Selvfølgelig er dette trin ikke kun nødvendigt for QA. Jeg vil dog gøre det eksplicit: Automatiseringskodebasen skal opbevares i en læsbar form. Programmeringssprog - ikke mindst Sprog, og herfra kan du begynde dit dyk.
Her er et skærmbillede af en opgavevisning med navnene på elementerne. Lad os forestille os, at du tester taskview som en sort boks og aldrig har set Selen i dit liv. Hvad gør denne kode?
(Spoiler - opgaven slettes via rest på vegne af admin, og så ser vi, at der er en registrering af dette i streamen.)
Alene dette trin bringer QAA- og QA-sprogene tættere sammen. Det er nemmere for automatiseringsteams at forklare resultaterne af en kørsel; manuelle testere skal bruge mindre kræfter på at oprette cases: de kan gøres mindre detaljerede. Alligevel forstår alle hinanden. Vi modtog gevinsterne allerede inden selve træningen begyndte.
Trin 1. Gentag sætninger
Lad os fortsætte parallellen med sproget. Når vi lærer at tale som børn, tager vi ikke udgangspunkt i etymologi og semantik. Vi gentager "mor", "køb et legetøj", men går ikke straks ind i de proto-indoeuropæiske rødder af disse ord. Så det er her: Det nytter ikke noget at dykke ned i selve dybden af de tekniske egenskaber ved autotest uden at prøve at skrive noget, der virker.
Det lyder lidt kontraintuitivt, men det virker.
I den første lektion er det værd at give et grundlag for, hvordan man skriver autotest direkte. Vi hjælper med at opsætte udviklingsmiljøet (i mit tilfælde Intellij IDEA), forklarer de minimum sprogregler, der er nødvendige for at skrive en anden metode i en eksisterende klasse ved hjælp af de eksisterende trin. Vi skriver en eller to prøver med dem og giver dem lektier, som jeg ville formatere sådan her: en gren forgrenet sig fra mesteren, men flere prøver er blevet fjernet fra den. Kun deres beskrivelser er tilbage. Vi beder testere om at gendanne disse tests (ikke gennem show diff, selvfølgelig).
Som et resultat vil den, der lyttede og gjorde alt, være i stand til:
- lære at arbejde med udviklingsmiljøets grænseflade: oprette filialer, genvejstaster, commits og pushes;
- mestre det grundlæggende i strukturen af sproget og klasserne: hvor skal du indsætte injektioner og hvor skal du importere, hvorfor annoteringer er nødvendige, og hvilken slags symboler findes der, udover trin;
- forstå forskellen mellem handling, vent og tjek, hvor du skal bruge hvad;
- bemærk forskellen mellem autotest og manuelle kontroller: i autotest kan du trække en eller anden handler i stedet for at udføre handlinger gennem grænsefladen. Send for eksempel en kommentar direkte til backend i stedet for at åbne en opgavevisning, vælge input, skrive tekst og klikke på knappen Send;
- formulere spørgsmål, som vil blive besvaret i næste trin.
Det sidste punkt er meget vigtigt. Disse svar kan sagtens gives før tid, men det er et vigtigt undervisningsprincip, at svar uden formulerede spørgsmål ikke huskes og ikke bruges, når der endelig er brug for dem.
Det ville være ideelt, hvis en automationsingeniør fra QA-teamet på dette tidspunkt tildelte ham en opgave med at skrive et par tests i kamp og tillod ham at underforpligte sig til sin afdeling.
Hvad skal man ikke give:
- mere indgående kendskab til funktionaliteten i udviklingsmiljøet og selve programmeringssproget, hvilket kun vil være nødvendigt, når man arbejder selvstændigt med brancher. Det vil ikke blive husket, du bliver nødt til at forklare det to eller tre gange, men vi værdsætter automationsingeniørernes tid, ikke? Eksempler: løsning af konflikter, tilføjelse af filer til git, oprettelse af klasser fra bunden, arbejde med afhængigheder;
- alt relateret til xpath. Helt seriøst. Du skal tale om det hver for sig, én gang og meget koncentreret.
Trin 2. At se nærmere på grammatikken
Lad os huske opgavevisningsskærmbilledet fra trin #0. Vi har et trin kaldet checkCommentWithTextExists. Vores tester forstår allerede, hvad dette trin gør, og vi kan se inde i trinnet og nedbryde det lidt.
Og indeni har vi følgende:
onCommentBlock(userName).comment(expectedText).should(displayed());Hvor onCommentBlock er
onCommonStreamPanel().commentBlock(userName);Nu lærer vi ikke at sige "køb et legetøj", men "køb et legetøj fra Detsky Mir-butikken, der ligger i det blå skab på den tredje hylde fra toppen." Det er nødvendigt at forklare, at vi peger på et element sekventielt, fra større elementer (stream -> blok med kommentarer fra en bestemt person -> den del af denne blok, hvor den angivne tekst sidder).
Nej, det er stadig ikke tid til at tale om xpath. Bare nævne kort, at alle disse instruktioner er beskrevet af dem, og arv går gennem dem. Men vi er nødt til at tale om alle disse matchere og tjenere; de relaterer sig specifikt til dette trin og er nødvendige for at forstå, hvad der sker. Men lad være med at overbelaste: Din elev kan studere mere komplekse påstande på egen hånd senere. Mest sandsynligt burde, waitIntil, displayed();, exist();, not(); skulle være tilstrækkeligt.
Hjemmearbejdet er indlysende: en gren, hvor indholdet af flere trin, der er nødvendige for et vist antal tests, er blevet fjernet. Lad testerne gendanne dem og få løbet til at blive grønt igen.
Derudover, hvis testteamet ikke kun har nye funktioner i sit arbejde, men også nogle fejlrettelser, kan du bede ham om straks at skrive test for disse fejl og frigive dem. Mest sandsynligt er alle elementerne allerede blevet beskrevet; kun et par trin mangler muligvis. Dette vil være den perfekte træning.
Trin 3. Fuld nedsænkning
Så komplet som muligt for en tester, der skal fortsætte med at udføre sine direkte opgaver. Til sidst skal vi tale om xpath.
Lad os først gøre det klart, at alle disse påCommentBlock og kommentarer er beskrevet af dem.
Totalt:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Rækkefølgen af historien er meget vigtig. Først tager vi enhver eksisterende xpath og viser, hvordan elementfanebladet indeholder ét og kun ét element. Dernæst vil vi tale om strukturen: når du skal bruge WebElement, og hvornår du skal oprette en separat fil til et nyt element. Dette vil give dig mulighed for bedre at forstå arv.
Det skal udtrykkeligt angives, at et enkelt element er hele opgavevisningen, det indeholder et underordnet element - hele strømmen, som indeholder et underelement - en separat kommentar osv. Underordnede elementer er inde i overordnede elementer både på siden og i strukturen af autotestrammerne.
På dette tidspunkt burde publikum have forstået, hvordan de nedarves, og hvad der kan indtastes efter prikken på onCommentBlock. På dette tidspunkt forklarer vi alle operatorerne: /, //, ., [] og så videre. Vi tilføjer viden om brug i læsset @class og andre nødvendige ting.
Eleverne skal forstå, hvordan man oversætter xpath på denne måde. At konsolidere - det er rigtigt, lektier. Vi sletter beskrivelserne af elementerne, lader dem genoprette testens arbejde.
Hvorfor netop denne vej?
Vi bør ikke overbelaste en person med kompleks viden, men vi skal forklare alt på én gang, og det er et svært dilemma. Denne vej vil give os mulighed for først at få lytterne til at stille spørgsmål og ikke forstå noget og besvare dem i det næste øjeblik. Hvis du taler om hele arkitekturen, så når emnet trin eller xpath analyseres, vil de vigtigste dele af det allerede være glemt på grund af deres uforståelighed.
Nogle af jer vil dog sikkert kunne dele ud af jeres erfaringer med, hvordan processen kan optimeres endnu mere. Jeg vil med glæde læse lignende forslag i kommentarerne!
Kilde: www.habr.com