Fire av fem QA-søkere ønsker å lære å jobbe med automatiserte tester. Ikke alle bedrifter kan oppfylle slike ønsker til manuelle testere i arbeidstiden. Wrike holdt en automasjonsskole for ansatte og realiserte dette ønsket for mange. Jeg deltok på denne skolen nettopp som QA-elev.
Jeg lærte å jobbe med Selenium og støtter nå uavhengig et visst antall autotester med praktisk talt ingen ekstern hjelp. Og basert på resultatene av vår felles erfaring og mine personlige konklusjoner, vil jeg prøve å utlede selve formelen for den mest ideelle automatiseringsskolen.
Wrikes erfaring med å organisere en skole
Da behovet for en automasjonsskole ble klart, falt organisasjonen til Stas Davydov, den tekniske lederen for automatisering. Hvem andre enn han kan forklare hvorfor de kom med dette tiltaket, om de oppnådde resultater og om de angrer på tiden som ble brukt? La oss gi ham ordet:
— I 2016 skrev vi et nytt rammeverk for autotester og gjorde det slik at det ble enkelt å skrive tester: vanlige trinn dukket opp, strukturen ble mye mer forståelig. Vi kom på en idé: Vi må involvere alle som ønsker å skrive nye prøver, og for å gjøre det lettere å forstå laget vi en serie forelesninger. Vi kom sammen med en plan med emner, hver av de fremtidige foreleserne tok en for seg selv og utarbeidet en rapport om den.
— Hvilke vansker hadde elevene?
— Hovedsakelig, selvfølgelig, arkitektur. Det var mange spørsmål om strukturen på testene våre. I tilbakemeldinger ble det skrevet mye om dette temaet og vi måtte holde flere forelesninger for å forklare mer detaljert.
— Har skolen lønnet seg?
- Ja, definitivt. Takket være henne var mange mennesker involvert i å skrive tester, og i gjennomsnitt på sykehuset begynte alle å bedre forstå hva autotester er, hvordan de er skrevet og hvordan de lanseres. Belastningen på automasjonsingeniører har også gått ned: Vi mottar nå mange ganger færre forespørsler om hjelp til å analysere tester, siden testere og utviklere har begynt å takle dette selv i nesten alle situasjoner. Vel, det er flere interne fordeler for avdelingen: vi fikk erfaring med presentasjoner og forelesninger, takket være at noen automatiseringsingeniører allerede har klart å lage presentasjoner på konferanser, og også mottatt et kraftig sett med videoer og presentasjoner for onboarding av nykommere.
På egne vegne vil jeg legge til at kommunikasjonen mellom våre avdelinger er forenklet til et rett og slett latterlig enkelt nivå. For eksempel, nå trenger jeg praktisk talt ikke tenke på hvilke saker og på hvilket atomitetsnivå som skal automatiseres. Som et resultat tar alle interesserte seg fulle av testdekningen, som stadig vokser. Ingen krever det umulige av andre.
Generelt er innvirkningen på teamarbeidet definitivt positiv. Kanskje også kolleger som leser denne artikkelen tenker på å gjøre noe lignende? Da vil rådene være enkle: det er verdt det hvis automatiserte tester er en prioritet for deg. Deretter skal vi snakke om et mer komplekst spørsmål: hvordan organisere alt dette så riktig som mulig, slik at kostnadene til alle parter er minimale og produksjonen er maksimal.
Tips for organisering
Skolen var nyttig, men, som Stas innrømmet, var det noen vanskeligheter, på grunn av hvilke det var nødvendig å arrangere flere forelesninger. Og det var som en nylig student som sammenlignet meg selv – i uvitenhet og meg selv – nå at jeg formulerte følgende trinn for å lage, etter min mening, den ideelle måten å lære testere å forstå automatiserte tester.
Trinn 0. Lag en ordbok
Selvfølgelig er dette trinnet ikke bare nødvendig for QA. Imidlertid vil jeg gjøre det eksplisitt: automatiseringskodebasen må holdes i en lesbar form. Programmeringsspråk – ikke minst språk, og fra dette kan du begynne dykket ditt.
Her er et skjermbilde av en oppgavevisning med navnene på elementene. La oss forestille oss at du tester taskview som en svart boks og aldri har sett Selen i livet ditt. Hva gjør denne koden?
(Spoiler - oppgaven slettes via hvile på vegne av admin, og så ser vi at det er registrert dette i strømmen.)
Dette trinnet alene bringer QAA- og QA-språkene nærmere hverandre. Det er lettere for automatiseringsteam å forklare resultatene av en kjøring; manuelle testere må bruke mindre krefter på å lage saker: de kan gjøres mindre detaljerte. Likevel forstår alle hverandre. Vi fikk gevinsten allerede før selve treningen startet.
Trinn 1. Gjenta setninger
La oss fortsette parallellen med språket. Når vi lærer å snakke som barn, tar vi ikke utgangspunkt i etymologi og semantikk. Vi gjentar "mamma", "kjøp et leketøy", men går ikke umiddelbart inn i de proto-indoeuropeiske røttene til disse ordene. Så det er her: det er ingen vits i å dykke ned i selve dypet av de tekniske egenskapene til autotester uten å prøve å skrive noe som fungerer.
Det høres litt motintuitivt ut, men det fungerer.
I den første leksjonen er det verdt å gi et grunnlag for hvordan man skriver autotester direkte. Vi hjelper til med å sette opp utviklingsmiljøet (i mitt tilfelle Intellij IDEA), forklarer minimumsspråkreglene som er nødvendige for å skrive en annen metode i en eksisterende klasse ved å bruke de eksisterende trinnene. Vi skriver en eller to tester med dem og gir dem lekser, som jeg vil formatere slik: en gren forgrenet seg fra mesteren, men flere tester er fjernet fra den. Bare beskrivelsene deres gjenstår. Vi ber testere om å gjenopprette disse testene (ikke gjennom show diff, selvfølgelig).
Som et resultat vil den som lyttet og gjorde alt kunne:
- lære å jobbe med utviklingsmiljøgrensesnittet: opprette grener, hurtigtaster, forplikter og pusher;
- mestre det grunnleggende om strukturen til språket og klassene: hvor du skal sette inn injeksjoner og hvor du skal importere, hvorfor merknader er nødvendig, og hva slags symboler finnes der, i tillegg til trinn;
- forstå forskjellen mellom handling, vent og sjekk, hvor du skal bruke hva;
- legg merke til forskjellen mellom autotester og manuelle kontroller: i autotester kan du trekke en eller annen behandler i stedet for å utføre handlinger gjennom grensesnittet. Send for eksempel en kommentar direkte til backend i stedet for å åpne en oppgavevisning, velge input, skrive inn tekst og klikke på Send-knappen;
- formulere spørsmål som vil bli besvart i neste trinn.
Det siste punktet er veldig viktig. Disse svarene kan enkelt gis på forhånd, men det er et viktig undervisningsprinsipp at svar uten formulerte spørsmål ikke huskes og ikke brukes når det endelig trengs.
Det ville være ideelt om på dette tidspunktet en automasjonsingeniør fra QA-teamet tildelte ham en oppgave med å skrive et par tester i kamp og tillot ham å underforplikte seg til grenen sin.
Hva du ikke skal gi:
- mer inngående kjennskap til funksjonaliteten til utviklingsmiljøet og selve programmeringsspråket, som kun vil være nødvendig når man arbeider med grener selvstendig. Det vil ikke bli husket, du må forklare det to eller tre ganger, men vi setter pris på tiden til automasjonsingeniører, ikke sant? Eksempler: løse konflikter, legge til filer i git, lage klasser fra bunnen av, arbeide med avhengigheter;
- alt relatert til xpath. Alvor. Du må snakke om det separat, en gang og veldig konsentrert.
Trinn 2. Ta en nærmere titt på grammatikken
La oss huske skjermbildet for oppgavevisning fra trinn #0. Vi har et trinn som heter checkCommentWithTextExists. Testeren vår forstår allerede hva dette trinnet gjør, og vi kan se inn i trinnet og bryte det ned litt.
Og inne har vi følgende:
onCommentBlock(userName).comment(expectedText).should(displayed());Hvor onCommentBlock er
onCommonStreamPanel().commentBlock(userName);Nå lærer vi å ikke si "kjøp et leketøy", men "kjøp et leketøy fra Detsky Mir-butikken, som ligger i det blå skapet på den tredje hyllen fra toppen." Det er nødvendig å forklare at vi peker på et element sekvensielt, fra større elementer (stream -> blokk med kommentarer fra en bestemt person -> den delen av denne blokken der den angitte teksten sitter).
Nei, det er fortsatt ikke på tide å snakke om xpath. Bare nevne kort at alle disse instruksjonene er beskrevet av dem og arv går gjennom dem. Men vi må snakke om alle disse matcherne og servitørene; de forholder seg spesifikt til dette trinnet og er nødvendige for å forstå hva som skjer. Men ikke overbelast: studenten din kan studere mer komplekse påstander på egen hånd senere. Mest sannsynlig bør, vente til, vises();, eksistere();, ikke(); være tilstrekkelig.
Leksene er åpenbare: en gren der innholdet i flere trinn som er nødvendige for et visst antall tester er fjernet. La testerne gjenopprette dem og få løpeturen til å bli grønn igjen.
I tillegg, hvis testteamet ikke bare har nye funksjoner i arbeidet sitt, men også noen feilrettinger, kan du be ham om å umiddelbart skrive tester for disse feilene og slippe dem. Mest sannsynlig er alle elementene allerede beskrevet; bare et par trinn kan mangle. Dette vil være den perfekte treningen.
Trinn 3. Full nedsenking
Så komplett som mulig for en tester som skal fortsette å utføre sine direkte oppgaver. Til slutt må vi snakke om xpath.
Først, la oss gjøre det klart at alle disse onCommentBlock og kommentarer er beskrevet av dem.
totalt:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Rekkefølgen på historien er veldig viktig. Først tar vi en hvilken som helst eksisterende xpath og viser hvordan elementfanen inneholder ett og bare ett element. Deretter skal vi snakke om strukturen: når du trenger å bruke WebElement, og når du trenger å lage en egen fil for et nytt element. Dette vil tillate deg å bedre forstå arv.
Det må eksplisitt angis at et enkelt element er hele oppgavevisningen, det inneholder et underordnet element - hele strømmen, som inneholder et underordnet element - en egen kommentar osv. Underordnede elementer er inne i overordnede elementer både på siden og i strukturen til autotestrammeverket.
På dette tidspunktet skal publikum ha forstått hvordan de er arvet og hva som kan legges inn etter prikken på onCommentBlock. På dette tidspunktet forklarer vi alle operatorene: /, //, ., [] og så videre. Vi legger kunnskap om bruk inn i lasset @class og andre nødvendige ting.
Studentene bør forstå hvordan de kan oversette xpath på denne måten. For å konsolidere - det er riktig, lekser. Vi sletter beskrivelsene av elementene, lar dem gjenopprette arbeidet med testene.
Hvorfor akkurat denne veien?
Vi bør ikke overbelaste en person med kompleks kunnskap, men vi må forklare alt på en gang, og dette er et vanskelig dilemma. Denne veien vil tillate oss å først få lytterne til å stille spørsmål og ikke forstå noe og svare på dem i neste øyeblikk. Hvis du snakker om hele arkitekturen, vil de viktigste delene av den allerede være glemt på grunn av deres uforståelighet når temaet trinn eller xpath blir analysert.
Men noen av dere vil sannsynligvis kunne dele deres erfaringer om hvordan prosessen kan optimaliseres enda mer. Jeg vil gjerne lese lignende forslag i kommentarene!
Kilde: www.habr.com