Ötből négy minőségbiztosítási pályázó szeretne megtanulni, hogyan kell automatizált tesztekkel dolgozni. Nem minden cég tudja teljesíteni a kézi tesztelők ilyen kívánságait munkaidőben. Wrike automatizálási iskolát tartott az alkalmazottak számára, és sokak számára megvalósította ezt a vágyat. QA hallgatóként vettem részt ebben az iskolában.
Megtanultam, hogyan kell dolgozni a Seleniummal, és most már önállóan is támogatok bizonyos számú automatikus tesztet, kevés külső segítséggel vagy anélkül. És közös tapasztalataink és személyes következtetéseim alapján megpróbálom levezetni az automatizálás legideálisabb iskolájának képletét.
Írási tapasztalat az iskolaszervezésben
Amikor világossá vált egy automatizálási iskola szükségessége, annak megszervezése Stas Davydovra, az automatizálás műszaki vezetőjére hárult. Nála ki tudná jobban megmagyarázni, miért álltak elő ezzel a kezdeményezéssel, értek-e el eredményeket és sajnálják-e az eltöltött időt? Adjunk neki egy szót:
- 2016-ban új keretrendszert írtunk az autotesztekhez, és úgy alakítottuk ki, hogy egyszerűvé vált a tesztek írása: megjelentek a normál lépések, sokkal érthetőbb lett a szerkezet. Volt egy ötletünk: minden új tesztet megírni vágyót be kell vonni, és a könnyebb érthetőség érdekében előadássorozatot hoztunk létre. Közösen kidolgoztunk egy tématervet, a leendő előadók mindegyike vett magának egyet, és készített róla beszámolót.
Milyen nehézségek merültek fel a diákok számára?
- Alapvetően természetesen az építészet. Sok kérdés merült fel tesztjeink felépítésével kapcsolatban. Sok visszajelzés érkezett erről a témáról, és további előadásokat kellett tartanunk, hogy részletesebben kifejtsük.
Kifizetődött az iskola?
- Igen határozottan. Neki köszönhetően egy csomó ember vonzódott a tesztek írásához, és átlagosan a kórházban mindenki jobban megértette, hogy mi az autoteszt, hogyan írják meg és hogyan indulnak el. Csökkent az automaták terhelése is: ma már sokszor kevesebb segítségkérést kapunk a tesztek elemzéséhez, mivel a tesztelők és a fejlesztők szinte minden helyzetben maguk kezdték megbirkózni ezzel. Nos, néhány belső előny a tanszéknek: prezentációkban és előadásokban szereztünk tapasztalatot, aminek köszönhetően néhány automatának már sikerült előadást tartania a konferenciákon, valamint egy hatékony videó- és prezentációkészletet kaptunk a kezdők számára.
Magamból hozzátenném, hogy a részlegeink közötti kommunikációt egészen nevetségesen könnyű szintre egyszerűsítettük. Például most gyakorlatilag nem kell azon gondolkodnom, hogy mely esetekben és milyen atomerővel adjak az automatizáláshoz. Ennek eredményeként a folyamatosan növekvő tesztlefedettség iránti aggodalomra minden érdeklődő teljes mértékben gondoskodik. Senki nem követeli meg másoktól a lehetetlent.
Általában véve a csapatok munkájára gyakorolt hatás mindenképpen pozitív. Lehet, hogy a cikket olvasó kollégák is gondolkodnak valami hasonlón? Akkor a tanács egyszerű lesz: megéri, ha az automatikus tesztek prioritást élveznek. Ezután beszéljünk egy nehezebb kérdésről: hogyan lehet mindent a lehető leghelyesebben megszervezni, hogy minden fél költségei minimálisak legyenek, és a kimenet maximális legyen.
Szervezési tippek
Az iskola hasznos volt, de, mint Stas elismerte, voltak nehézségek, amelyek miatt további előadásokat kellett rendezni. Egy képzett diákként, aki összehasonlította magát a tudatlanságban és a mostani önmagával, megfogalmaztam a következő lépéseket annak érdekében, hogy megalkossam azt az ideális módszert, amellyel megtaníthatom a tesztelőket az automatizált tesztek kezelésére.
0. lépés: Hozzon létre egy szótárt
Természetesen ez a lépés nem csak a minőségbiztosításhoz szükséges. Szeretném azonban egyértelművé tenni: az automatizálási kódbázist olvasható formában kell tartani. Programozási nyelvek – nem utolsósorban nyelvek, és ettől lehet majd elkezdeni a merülést.
Itt van egy képernyőkép a feladatnézetről az elemek nevével. Képzeljük el, hogy egy feladatnézetet tesztel fekete dobozként, és még soha életében nem látott szelént. Mit csinál ez a kód?
(Spoiler - a feladat a többi részen keresztül törlődik az adminisztrátor nevében, majd látjuk, hogy erről van feljegyzés a streamben.)
Ez a lépés önmagában közelebb hozza egymáshoz a minőségbiztosítási és minőségbiztosítási nyelveket. Az automatizálási mérnökök könnyebben megmagyarázzák a futtatás eredményeit, a kézi tesztelőknek kevesebb erőfeszítést kell fordítaniuk az esetek összeállítására: kevésbé részletezhetők. Mégis megértik egymást. Még a tényleges edzés megkezdése előtt nyertünk.
1. lépés: Ismételje meg a kifejezéseket
Folytassuk a párhuzamot a nyelvvel. Amikor gyermekkorban megtanulunk beszélni, nem indulunk el az etimológiától és a szemantikától. Ismételjük az „anya”, „vegyél játékot”, de nem megyünk azonnal e szavak proto-indoeurópai gyökereibe. Így van ez: nincs értelme belemerülni az autotesztek munkájának műszaki jellemzőinek legmélyére anélkül, hogy megpróbálnánk valami működőképet írni.
Kicsit ellentmondóan hangzik, de működik.
Az első órán érdemes alapot adni az autotesztek közvetlen megírására. Segítünk a fejlesztői környezet (esetemben az Intellij IDEA) beállításában, elmagyarázzuk a nyelv minimális szabályait, amelyek szükségesek ahhoz, hogy a meglévő lépések segítségével még egy metódust írjunk egy meglévő osztályba. Írunk velük egy-két tesztet és adunk házi feladatot, amit a következőképpen rendeznék el: a mestertől elvettek egy ágat, de több tesztet töröltek benne. Csak a leírásuk maradt meg. Megkérjük a tesztelőket, hogy állítsák vissza ezeket a teszteket (természetesen nem a show diff segítségével).
Ennek eredményeként az, aki hallgatott és mindent megtett, képes lesz:
- megtanulják, hogyan kell dolgozni a fejlesztői környezet felületével: elágazások, gyorsbillentyűk, véglegesítések és push-ok létrehozása;
- megtanulják a nyelv és az osztályok felépítésének alapjait: hova kell beszúrni az injekciókat és hova importálni, miért van szükség annotációkra, és általában milyen szimbólumok találhatók ott, kivéve a lépéseket;
- megérteni a különbséget a cselekvés, a várakozás és az ellenőrzés között, hol mit kell használni;
- vegye észre a különbséget az automatikus tesztek és a kézi ellenőrzések között: az automatikus teszteknél a felületen keresztüli műveletek végrehajtása helyett lehúzhatja az egyik vagy másik kezelőt. Például küldjön megjegyzést közvetlenül a háttérrendszerbe ahelyett, hogy megnyit egy feladatnézetet, kiválaszt egy bevitelt, gépel és megnyomja a Küldés gombot;
- megfogalmazza a következő lépésben megválaszolandó kérdéseket.
Az utolsó pont nagyon fontos. Ezeket a válaszokat könnyen meg lehet adni előre, de ez egy fontos tanítási elv: a megfogalmazott kérdések nélküli válaszokat nem emlékezünk meg, és nem alkalmazzuk, amikor végre szükség van rájuk.
Ideális lenne, ha ebben az időben a minőségbiztosítási csapat egy automatája azt a feladatot bízná rá, hogy írjon néhány tesztet a csatatéren, és lehetővé teszi számára, hogy újra elkötelezi magát az ágához.
Mit ne adjunk:
- alaposabb ismerete a fejlesztői környezet és magának a programozási nyelvnek a funkcionalitásával kapcsolatban, amelyre csak akkor lesz szükség, ha önállóan dolgozik az ágakkal. Nem fog emlékezni, kétszer-háromszor el kell magyarázni, de nagyra értékeljük az automaták idejét, igaz? Példák: konfliktusok feloldása, fájlok hozzáadása a git-hez, osztályok létrehozása a semmiből, függőségek kezelése;
- minden, ami az xpath-hoz kapcsolódik. Komolyan. Róla külön kell mesélni, egyszer és nagyon koncentráltan.
2. lépés: A nyelvtan áttekintése
Emlékezzünk a feladatnézet képernyőképére a 0. lépésből. Van egy checkCommentWithTextExists nevű lépésünk. Tesztelőnk már érti, mit csinál ez a lépés, és belenézhetünk a lépésbe, és egy kicsit szétbonthatjuk azt.
Belül pedig a következők vannak:
onCommentBlock(userName).comment(expectedText).should(displayed());Hol van az onCommentBlock
onCommonStreamPanel().commentBlock(userName);Most azt tanuljuk, hogy ne „vegyél játékot”, hanem „vegyél egy játékot a Gyermekvilág áruházból, egy kék szekrényben állva a harmadik polcon felülről”. El kell magyaráznunk, hogy az elemre szekvenciálisan, nagyobb elemekből mutatunk (stream -> blokk egy adott személy megjegyzéseivel -> ennek a blokknak az a része, ahol az adott szöveg található).
Nem, még mindig nincs itt az ideje az xpath-ról beszélni. Csak röviden megemlítve, hogy ezeket a jeleket ők írják le, és az öröklődés rajtuk keresztül megy. De beszélni kell ezekről a mérkőzésekről és vizekről, ezek kifejezetten ehhez a lépéshez kapcsolódnak, és szükségesek ahhoz, hogy megértsük, mi történik. De ne terhelje túl: diákja később bonyolultabb állításokat is képes lesz tanulmányozni. Kell, waitUntil, displayed();, létezik();, not(); valószínűleg elegendő.
A házi feladat nyilvánvaló: egy olyan ág, amely eltávolította a bizonyos számú teszthez szükséges lépések tartalmát. Kérje meg a tesztelőket, hogy állítsák vissza őket, és tegye újra zöldre a futást.
Ezen túlmenően, ha a tesztelő csapat nem csak új funkciókkal rendelkezik, hanem néhány hibajavítást is, akkor megkérheti, hogy azonnal írjon teszteket ezekre a hibákra, és engedje el őket. Valószínűleg az összes elemet már leírták, csak néhány lépés hiányzik. Ez lesz a tökéletes edzés.
3. lépés: Teljes merítés
A lehető legteljesebb egy tesztelő számára, aki továbbra is ellátja közvetlen feladatait. Végül beszélnünk kell az xpath-ról.
Először is tegyük világossá, hogy mindezeket az onCommentBlock-ot és megjegyzéseket ők írják le.
Összesen:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"A történet sorrendje nagyon fontos. Először veszünk egy meglévő xpath-t, és megmutatjuk, hogyan van egy és csak egy elem az elemek lapon. Ezután a szerkezetről beszélünk: mikor kell a WebElement-et használni, és mikor kell külön fájlt létrehozni egy új elemhez. Így jobban megértheti az öröklődést.
Kifejezetten ki kell mondani, hogy egyetlen elem a teljes feladatnézet, tartalmaz egy gyermek elemet - a teljes adatfolyamot, amely egy gyermek elemet tartalmaz - egy külön megjegyzést stb. A gyermekelemek a szülőelemeken belül vannak mind az oldalon, mind az automatikus tesztelési keretrendszer szerkezetében.
Ezen a ponton a közönségnek már alaposan meg kell értenie, hogyan öröklődik, és mit írhat be az onCommentBlock pont után. Ezen a ponton megmagyarázzuk az összes operátort: /, //, ., [] és így tovább. Használatával kapcsolatos ismereteket adunk hozzá @class és egyéb szükséges dolgokat.
A hallgatóknak meg kell érteniük, hogyan kell ily módon lefordítani az xpath-ot. Javítani - helyes, házi feladat. Töröljük az elemek leírását, hagyjuk visszaállítani a tesztek működését.
Miért így?
Nem szabad túlterhelni az embert komplex tudással, hanem mindent egyszerre kell elmagyarázni, és ez nem könnyű dilemma. Ez lehetővé teszi számunkra, hogy a hallgatók először kérdéseket tegyenek fel, és ne értsenek valamit, és a következő pillanatban válaszoljanak rájuk. Ha a teljes architektúráról beszélünk, akkor mire a step vagy xpath témáját elemezzük, a legfontosabb részei már feledésbe merülnek érthetetlenségük miatt.
Néhányan azonban biztosan megoszthatják majd tapasztalataikat arról, hogyan optimalizálhatod még jobban a folyamatot. Szívesen olvasok ilyen javaslatokat!
Forrás: will.com