Čtyři z pěti žadatelů o QA se chtějí naučit pracovat s automatizovanými testy. Ne všechny firmy dokážou taková přání ručních testerů v pracovní době splnit. Wrike uspořádal školu automatizace pro zaměstnance a tuto touhu mnoha lidí realizoval. Účastnil jsem se této školy právě jako student QA.
Naučil jsem se pracovat se Selenium a nyní nezávisle podporovat určitý počet autotestů prakticky bez cizí pomoci. A na základě výsledků naší společné zkušenosti a svých osobních závěrů se pokusím odvodit samotný vzorec pro nejideálnější školu automatizace.
Wrikeovy zkušenosti s organizací školy
Když se jasně ukázala potřeba automatizační školy, její organizace připadla Stasi Davydovovi, technickému vedoucímu automatizace. Kdo jiný než on může vysvětlit, proč s touto iniciativou přišli, zda dosáhli výsledků a zda litují stráveného času? Dejme mu slovo:
— V roce 2016 jsme napsali nový framework pro autotesty a udělali ho tak, aby bylo snadné psát testy: objevily se normální kroky, struktura se stala mnohem srozumitelnější. Přišli jsme s nápadem: musíme zapojit všechny, kdo chtějí psát nové testy, a aby to bylo srozumitelnější, vytvořili jsme sérii přednášek. Kolektivně jsme vymysleli plán témat, každý z budoucích lektorů si jedno vzal pro sebe a připravil o něm zprávu.
— Jaké potíže měli studenti?
— Hlavně samozřejmě architekturu. Bylo mnoho otázek ohledně struktury našich testů. Ve zpětné vazbě bylo na toto téma napsáno hodně a museli jsme pořádat další přednášky, abychom to vysvětlili podrobněji.
— Vyplatila se škola?
- Ano, určitě. Díky ní se do psaní testů zapojilo hodně lidí a v průměru v nemocnici každý začal lépe chápat, co jsou autotesty, jak se píší a jak se spouštějí. Snížilo se také zatížení automatizačních inženýrů: nyní dostáváme mnohonásobně méně žádostí o pomoc s analýzou testů, protože testeři a vývojáři si s tím začali téměř ve všech situacích poradit sami. Interních výhod pro katedru je hned několik: získali jsme zkušenosti z prezentací a přednášek, díky kterým už někteří automatizační inženýři zvládli prezentace na konferencích, a získali jsme také výkonnou sadu videí a prezentací pro onboarding nováčků.
Za sebe dodám, že komunikace mezi našimi odděleními byla zjednodušena na přímo směšně snadnou úroveň. Například nyní prakticky nemusím přemýšlet o tom, které případy a na jaké úrovni atomicity automatizovat. Díky tomu se všichni zájemci plně starají o testovací pokrytí, které neustále roste. Nikdo od ostatních nepožaduje nemožné.
Obecně je dopad na práci týmů určitě pozitivní. Možná kolegové, kteří čtou tento článek, také uvažují o něčem podobném? Pak bude rada jednoduchá: vyplatí se to, pokud jsou pro vás automatické testy prioritou. Dále si povíme o složitější otázce: jak to vše co nejsprávněji uspořádat, aby náklady všech stran byly minimální a výstup maximální.
Organizační tipy
Škola byla užitečná, ale jak Stas připustil, vyskytly se určité potíže, kvůli kterým bylo nutné zajistit další přednášky. A právě jako nedávný student, který porovnával sebe – nevědomost a sebe – jsem nyní formuloval následující kroky, abych vytvořil, podle mého názoru, ideální způsob, jak naučit testery porozumět automatizovaným testům.
Krok 0. Vytvořte slovník
Tento krok je samozřejmě potřeba nejen pro QA. Chci to však vyjádřit jasně: automatizační kódová základna musí být udržována v čitelné formě. Programovací jazyky - v neposlední řadě jazykya odtud můžete začít s ponorem.
Zde je snímek obrazovky taskview s názvy prvků. Představme si, že testujete taskview jako černou skříňku a nikdy jste v životě neviděli Selenium. Co tento kód dělá?
(Spoiler - úkol je odstraněn prostřednictvím restu jménem administrátora a pak vidíme, že je o tom záznam ve streamu.)
Tento krok sám o sobě sbližuje jazyky QAA a QA. Pro automatizační týmy je snazší vysvětlit výsledky běhu; manuální testeři musí vynaložit méně úsilí na vytváření případů: mohou být méně podrobné. Přesto si všichni rozumí. Výhru jsme obdrželi ještě před zahájením samotného tréninku.
Krok 1. Opakujte fráze
Pokračujme v paralele s jazykem. Když se jako děti učíme mluvit, nevycházíme z etymologie a sémantiky. Opakujeme „máma“, „koupit hračku“, ale nejdeme hned do protoindoevropských kořenů těchto slov. Tak je to tady: nemá smysl ponořit se do samotných hlubin technických vlastností autotestů, aniž bychom se pokusili napsat něco, co funguje.
Zní to trochu neintuitivně, ale funguje to.
V první lekci stojí za to dát základ, jak psát autotesty přímo. Pomáháme s nastavením vývojového prostředí (v mém případě Intellij IDEA), vysvětlujeme minimální jazyková pravidla, která jsou nezbytná pro napsání jiné metody ve stávající třídě pomocí stávajících kroků. Napíšeme s nimi jeden nebo dva testy a zadáme jim domácí úkol, který bych naformátoval takto: větev se oddělila od hlavního, ale několik testů z něj bylo odstraněno. Zůstaly pouze jejich popisy. Žádáme testery, aby tyto testy obnovili (samozřejmě nikoli prostřednictvím show diff).
Výsledkem je, že ten, kdo naslouchal a dělal vše, bude schopen:
- naučit se pracovat s rozhraním vývojového prostředí: vytváření větví, klávesových zkratek, commitů a pushů;
- osvojit si základy struktury jazyka a tříd: kam vkládat injekce a kam importovat, proč jsou potřeba anotace a jaké druhy symbolů se tam nacházejí, kromě kroků;
- pochopit rozdíl mezi akcí, čekáním a kontrolou, kde co použít;
- všimněte si rozdílu mezi autotesty a manuálními kontrolami: v autotestech můžete místo provádění akcí přes rozhraní vytáhnout jeden nebo jiný handler. Například odešlete komentář přímo do backendu namísto otevření zobrazení úloh, výběru vstupu, psaní textu a kliknutí na tlačítko Odeslat;
- formulovat otázky, které budou zodpovězeny v dalším kroku.
Poslední bod je velmi důležitý. Tyto odpovědi lze snadno poskytnout s předstihem, ale důležitým principem výuky je, že odpovědi bez formulovaných otázek se nepamatují a nepoužívají se, když jsou nakonec potřeba.
Ideální by bylo, kdyby mu v tuto chvíli automatizační inženýr z týmu QA zadal úkol napsat pár testů v bitvě a dovolil mu podřídit se své pobočce.
Co nedávat:
- hlubší znalost funkčnosti vývojového prostředí a samotného programovacího jazyka, která bude potřeba pouze při samostatné práci s větvemi. Nebude se to pamatovat, budete to muset vysvětlovat dvakrát nebo třikrát, ale ceníme si času automatizačních inženýrů, že? Příklady: řešení konfliktů, přidávání souborů do git, vytváření tříd od začátku, práce se závislostmi;
- vše, co souvisí s xpath. Vážně. Je třeba o tom mluvit samostatně, jednou a velmi soustředěně.
Krok 2. Bližší pohled na gramatiku
Vzpomeňme na snímek obrazovky taskview z kroku #0. Máme krok nazvaný checkCommentWithTextExists. Náš tester již chápe, co tento krok dělá, a můžeme se podívat dovnitř kroku a trochu ho rozložit.
A uvnitř máme následující:
onCommentBlock(userName).comment(expectedText).should(displayed());Kde je onCommentBlock
onCommonStreamPanel().commentBlock(userName);Nyní se učíme říkat ne „kupte si hračku“, ale „kupte si hračku z obchodu Detsky Mir, který se nachází v modré skříni na třetí polici shora“. Je potřeba vysvětlit, že na prvek ukazujeme postupně, od větších prvků (stream -> blok s komentáři od určité osoby -> ta část tohoto bloku, kde sedí zadaný text).
Ne, stále není čas mluvit o xpath. Stačí krátce zmínit, že všechny tyto pokyny jsou jimi popsány a dědičnost jimi prochází. Ale musíme mluvit o všech těchto dohazovačích a číšnících; vztahují se konkrétně k tomuto kroku a jsou nezbytné pro pochopení toho, co se děje. Ale nepřetěžujte: váš student může později studovat složitější tvrzení sám. S největší pravděpodobností by mělo stačit, měla by, čekatDokud, display();, exist();, not();
Domácí úkol je zřejmý: větev, ve které byl odstraněn obsah několika kroků, které jsou nutné pro určitý počet testů. Ať je testeři obnoví a běh bude opět zelený.
Navíc, pokud má testovací tým ve své práci nejen nové funkce, ale také nějaké opravy chyb, můžete ho požádat, aby okamžitě napsal testy na tyto chyby a uvolnil je. S největší pravděpodobností již byly všechny prvky popsány, může chybět pouze několik kroků. Bude to perfektní cvičení.
Krok 3. Úplné ponoření
Co nejúplnější pro testera, který bude pokračovat v plnění svých přímých povinností. Nakonec si musíme promluvit o xpath.
Nejprve si ujasněme, že všechny tyto onCommentBlock a komentáře jsou jimi popsány.
Celkem:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Pořadí příběhu je velmi důležité. Nejprve vezmeme libovolnou existující cestu xpath a ukážeme, jak karta prvků obsahuje pouze jeden prvek. Dále si povíme o struktuře: když potřebujete použít WebElement a když potřebujete vytvořit samostatný soubor pro nový prvek. To vám umožní lépe porozumět dědičnosti.
Musí být výslovně uvedeno, že jeden prvek je celý taskview, obsahuje podřízený prvek - celý stream, který obsahuje podřízený prvek - samostatný komentář atd. Podřízené prvky jsou uvnitř nadřazených prvků na stránce i ve struktuře rámce autotestu.
V tuto chvíli by publikum mělo pevně chápat, jak se dědí a co lze zadat za tečkou u onCommentBlock. V tomto okamžiku vysvětlíme všechny operátory: /, //, ., [] a tak dále. Do zátěže přidáváme znalosti o použití @class a další potřebné věci.
Studenti by měli pochopit, jak překládat xpath tímto způsobem. Upevnit - to je pravda, domácí úkol. Smažeme popisy prvků, ať obnoví práci testů.
Proč právě tato cesta?
Člověka bychom neměli přetěžovat komplexními znalostmi, ale musíme vše vysvětlit najednou, a to je těžké dilema. Tato cesta nám umožní nejprve přimět posluchače klást otázky a něčemu nerozumět a v příštím okamžiku na ně odpovědět. Pokud mluvíte o celé architektuře, pak v době, kdy se rozebere téma kroků nebo xpath, budou její nejdůležitější části již zapomenuty pro svou nesrozumitelnost.
Někteří z vás se však pravděpodobně budou moci podělit o své zkušenosti s tím, jak lze proces ještě více optimalizovat. Podobné návrhy si rád přečtu v komentářích!
Zdroj: www.habr.com