Fyra av fem QA-sökande vill lära sig att arbeta med automatiserade tester. Inte alla företag kan uppfylla sådana önskemål från manuella testare under arbetstid. Wrike höll en automationsskola för anställda och förverkligade denna önskan för många. Jag deltog i den här skolan just som QA-elev.
Jag lärde mig att arbeta med Selenium och stödjer nu självständigt ett visst antal autotester med praktiskt taget ingen hjälp utifrån. Och, baserat på resultaten av vår gemensamma erfarenhet och mina personliga slutsatser, kommer jag att försöka härleda själva formeln för den mest idealiska skolan för automation.
Wrikes erfarenhet av att organisera en skola
När behovet av en automationsskola blev tydligt föll dess organisation på Stas Davydov, den tekniska ledaren för automatisering. Vem mer än han kan förklara varför de kom med detta initiativ, om de uppnådde resultat och om de ångrar tiden som lagts ner? Låt oss ge honom ordet:
— 2016 skrev vi ett nytt ramverk för autotester och gjorde det så att det blev enkelt att skriva tester: normala steg dök upp, strukturen blev mycket mer begriplig. Vi kom på en idé: vi måste involvera alla som vill skriva nya prov, och för att göra det lättare att förstå skapade vi en serie föreläsningar. Vi tog gemensamt fram en plan med ämnen, var och en av de framtida föreläsarna tog en för sig och gjorde en rapport om den.
— Vilka svårigheter hade eleverna?
— Främst, förstås, arkitektur. Det var många frågor om strukturen på våra tester. Som feedback skrevs mycket om detta ämne och vi var tvungna att hålla ytterligare föreläsningar för att förklara mer detaljerat.
— Har skolan lönat sig?
- Ja definitivt. Tack vare henne var många människor involverade i att skriva tester, och i genomsnitt på sjukhuset började alla bättre förstå vad autotest är, hur de skrivs och hur de lanseras. Belastningen på automationsingenjörer har också minskat: vi får nu många gånger färre förfrågningar om hjälp med att analysera tester, eftersom testare och utvecklare har börjat klara av detta själva i nästan alla situationer. Tja, det finns flera interna fördelar för institutionen: vi fick erfarenhet av presentationer och föreläsningar, tack vare vilka några automationsingenjörer redan har lyckats göra presentationer på konferenser, och även fått en kraftfull uppsättning videor och presentationer för onboarding av nykomlingar.
För egen räkning vill jag tillägga att kommunikationen mellan våra avdelningar har förenklats till en rent ut sagt löjligt enkel nivå. Till exempel, nu behöver jag praktiskt taget inte tänka på vilka fall och på vilken nivå av atomicitet som ska automatiseras. Det gör att alla intresserade tar hand om testbevakningen, som hela tiden växer. Ingen kräver det omöjliga av andra.
Generellt sett är inverkan på teamarbetet definitivt positiv. Kanske kollegor som läser den här artikeln också funderar på att göra något liknande? Då blir rådet enkelt: det är värt det om automatiserade tester är en prioritet för dig. Därefter kommer vi att prata om en mer komplex fråga: hur man organiserar allt detta så korrekt som möjligt, så att kostnaderna för alla parter är minimala och resultatet är maximalt.
Tips för att organisera
Skolan var användbar, men, som Stas medgav, fanns det vissa svårigheter, på grund av vilka det var nödvändigt att ordna ytterligare föreläsningar. Och det var som en nyligen student som jämförde mig själv – i okunnighet och mig själv – nu som jag formulerade följande steg för att skapa, enligt min mening, det perfekta sättet att lära testare att förstå automatiserade tester.
Steg 0. Skapa en ordbok
Naturligtvis behövs detta steg inte bara för QA. Men jag vill göra det tydligt: automationskodbasen måste hållas i en läsbar form. Programmeringsspråk – inte minst språk, och från detta kan du börja ditt dyk.
Här är en skärmdump av en uppgiftsvy med namnen på elementen. Låt oss föreställa oss att du testar taskview som en svart låda och aldrig har sett Selen i ditt liv. Vad gör den här koden?
(Spoiler - uppgiften raderas via vila på uppdrag av administratören, och då ser vi att det finns ett register över detta i streamen.)
Bara detta steg för QAA- och QA-språken närmare varandra. Det är lättare för automationsteam att förklara resultatet av en körning; manuella testare måste lägga mindre ansträngning på att skapa fall: de kan göras mindre detaljerade. Ändå förstår alla varandra. Vi fick vinsterna redan innan själva träningen började.
Steg 1. Upprepa fraser
Låt oss fortsätta parallellen med språket. När vi lär oss tala som barn utgår vi inte från etymologi och semantik. Vi upprepar "mamma", "köp en leksak", men går inte omedelbart in på de proto-indoeuropeiska rötterna till dessa ord. Så det är här: det är ingen idé att dyka ner i själva djupet av de tekniska funktionerna i autotest utan att försöka skriva något som fungerar.
Det låter lite kontraintuitivt, men det fungerar.
I den första lektionen är det värt att ge en grund för hur man skriver autotester direkt. Vi hjälper till att sätta upp utvecklingsmiljön (i mitt fall Intellij IDEA), förklarar de minsta språkreglerna som är nödvändiga för att skriva en annan metod i en befintlig klass med de befintliga stegen. Vi skriver ett eller två prov med dem och ger dem läxor, som jag skulle formatera så här: en gren avgrenade sig från mästaren, men flera tester har tagits bort från den. Endast deras beskrivningar finns kvar. Vi ber testare att återställa dessa tester (inte genom show diff, naturligtvis).
Som ett resultat kommer den som lyssnade och gjorde allt att kunna:
- lär dig att arbeta med utvecklingsmiljöns gränssnitt: skapa grenar, snabbtangenter, commits och pushar;
- behärska grunderna i strukturen för språket och klasserna: var man ska infoga injektioner och var man ska importera, varför anteckningar behövs och vilken typ av symboler som finns där, förutom steg;
- förstå skillnaden mellan handling, vänta och kontrollera, var man ska använda vad;
- märk skillnaden mellan autotester och manuella kontroller: i autotest kan du dra en eller annan hanterare istället för att utföra åtgärder genom gränssnittet. Skicka till exempel en kommentar direkt till backend istället för att öppna en uppgiftsvy, välja inmatning, skriva text och klicka på knappen Skicka;
- formulera frågor som kommer att besvaras i nästa steg.
Den sista punkten är mycket viktig. Dessa svar kan lätt ges i förväg, men det är en viktig undervisningsprincip att svar utan formulerade frågor inte kommer ihåg och inte används när de slutligen behövs.
Det skulle vara idealiskt om en automationsingenjör från QA-teamet vid denna tidpunkt tilldelade honom en uppgift att skriva ett par tester i strid och lät honom gå vidare till sin gren.
Vad man inte ska ge:
- mer fördjupade kunskaper om funktionaliteten i utvecklingsmiljön och själva programmeringsspråket, vilket endast kommer att behövas när man arbetar med grenar självständigt. Det kommer inte att komma ihåg, du måste förklara det två eller tre gånger, men vi värdesätter automationsingenjörernas tid, eller hur? Exempel: lösa konflikter, lägga till filer i git, skapa klasser från början, arbeta med beroenden;
- allt relaterat till xpath. Allvarligt. Du måste prata om det separat, en gång och mycket koncentrerat.
Steg 2. Ta en närmare titt på grammatiken
Låt oss komma ihåg taskview-skärmdumpen från steg #0. Vi har ett steg som heter checkCommentWithTextExists. Vår testare förstår redan vad det här steget gör och vi kan titta in i steget och bryta ner det lite.
Och inuti har vi följande:
onCommentBlock(userName).comment(expectedText).should(displayed());Där onCommentBlock är
onCommonStreamPanel().commentBlock(userName);Nu lär vi oss att inte säga "köp en leksak", utan "köp en leksak från butiken Detsky Mir, som ligger i det blå skåpet på den tredje hyllan från toppen." Det är nödvändigt att förklara att vi pekar på ett element sekventiellt, från större element (ström -> block med kommentarer från en viss person -> den delen av detta block där den angivna texten sitter).
Nej, det är fortfarande inte dags att prata om xpath. Nämn bara kortfattat att alla dessa instruktioner beskrivs av dem och att arv går igenom dem. Men vi måste prata om alla dessa matchare och servitörer, de relaterar specifikt till detta steg och är nödvändiga för att förstå vad som händer. Men överbelasta inte: din student kan studera mer komplexa påståenden på egen hand senare. Troligtvis borde, waitTills, displayed();, exist();, not(); räcka.
Läxan är uppenbar: en gren där innehållet i flera steg som är nödvändiga för ett visst antal prov har tagits bort. Låt testarna återställa dem och få körningen att bli grön igen.
Dessutom, om testteamet inte bara har nya funktioner i sitt arbete, utan också några buggfixar, kan du be honom att omedelbart skriva tester för dessa buggar och släppa dem. Troligtvis har alla element redan beskrivits, bara ett par steg kan saknas. Det här blir det perfekta träningspasset.
Steg 3. Fullständig nedsänkning
Så komplett som möjligt för en testare som ska fortsätta att utföra sina direkta uppgifter. Slutligen måste vi prata om xpath.
Låt oss först göra det klart att alla dessa onCommentBlock och kommentarer beskrivs av dem.
Totalt:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Ordningen i berättelsen är mycket viktig. Först tar vi en befintlig xpath och visar hur elementfliken innehåller ett och endast ett element. Därefter kommer vi att prata om strukturen: när du behöver använda WebElement och när du behöver skapa en separat fil för ett nytt element. Detta gör att du bättre förstår arv.
Det måste uttryckligen anges att ett enskilt element är hela taskview, det innehåller ett underordnat element - hela strömmen, som innehåller ett underordnat element - en separat kommentar, etc. Underordnade element finns inuti överordnade element både på sidan och i strukturen för autotestramverket.
Vid det här laget borde publiken ha förstått hur de ärvs och vad som kan anges efter pricken på onCommentBlock. Vid det här laget förklarar vi alla operatorer: /, //, ., [] och så vidare. Vi tillför kunskap om användning i lasten @class och andra nödvändiga saker.
Eleverna bör förstå hur man översätter xpath på det här sättet. Att konsolidera - det stämmer, läxor. Vi tar bort beskrivningarna av elementen, låter dem återställa testarbetet.
Varför just denna väg?
Vi bör inte överbelasta en person med komplex kunskap, men vi måste förklara allt på en gång, och detta är ett svårt dilemma. Denna väg kommer att tillåta oss att först få lyssnare att ställa frågor och inte förstå något och svara på dem i nästa ögonblick. Om du pratar om hela arkitekturen, när ämnet steg eller xpath analyseras, kommer de viktigaste delarna av det redan att vara glömda på grund av deras obegriplighet.
Men några av er kommer förmodligen att kunna dela med sig av er erfarenhet av hur processen kan optimeras ännu mer. Jag kommer gärna att läsa liknande förslag i kommentarerna!
Källa: will.com