Neli viiest QA taotlejast soovib õppida automatiseeritud testidega töötamist. Kõik ettevõtted ei suuda selliseid käsitsi testijate soove tööajal täita. Wrike pidas töötajatele automatiseerimiskooli ja realiseeris selle soovi paljude jaoks. Osalesin selles koolis just QA üliõpilasena.
Õppisin Seleeniga töötama ja toetan nüüd iseseisvalt teatud arvu automaatteste praktiliselt ilma välise abita. Ja meie ühise kogemuse tulemuste ja oma isiklike järelduste põhjal püüan tuletada kõige ideaalsema automatiseerimiskooli valemi.
Wrike’i kogemus kooli organiseerimisel
Kui selgus vajadus automaatikakooli järele, langes selle organiseerimine automaatika tehnilise juhi Stas Davõdovi kätte. Kes muu kui tema oskab selgitada, miks nad selle algatusega välja tulid, kas saavutasid tulemusi ja kas nad kahetsevad kulutatud aega? Anname talle sõna:
— 2016. aastal kirjutasime autotestidele uue raamistiku ja tegime selle nii, et testide kirjutamine muutus lihtsaks: tekkisid tavalised sammud, struktuur muutus palju arusaadavamaks. Tulime välja ideega: peame kaasama kõik, kes soovivad uusi teste kirjutada, ja et oleks lihtsam aru saada, lõime loengusarja. Panime ühiselt välja teemade plaani, iga tulevane õppejõud võttis endale ühe ja koostas selle kohta ettekande.
— Milliseid raskusi õpilastel oli?
— Peamiselt muidugi arhitektuur. Meie testide ülesehituse kohta oli palju küsimusi. Tagasisides kirjutati sel teemal palju ja pidime pidama lisaloenguid, et täpsemalt selgitada.
— Kas kool tasus end ära?
- Jah, kindlasti. Tänu temale tegeles testide kirjutamisega palju inimesi ja keskmiselt hakkasid kõik haiglas paremini aru saama, mis on autotestid, kuidas neid kirjutatakse ja kuidas neid käivitatakse. Vähenenud on ka automaatikainseneride koormus: nüüd saame testide analüüsimisel kordades vähem abipalve, kuna testijad ja arendajad on sellega peaaegu kõikides olukordades ise hakkama saanud. Noh, osakonnal on mitmeid sisemisi eeliseid: saime ettekannete ja loengute kogemusi, tänu millele on mõned automaatikainsenerid jõudnud juba konverentsidel ettekandeid teha ning saanud ka võimsa video- ja esitluskomplekti uutele tulijatele.
Enda nimel lisan, et meie osakondade vaheline suhtlus on lihtsustatud lausa naeruväärselt lihtsale tasemele. Näiteks nüüd ei pea ma praktiliselt mõtlema, milliseid juhtumeid ja millisel aatomitasemel automatiseerida. Sellest tulenevalt kannavad kõik huvilised täiel määral hoolt testi katvuse eest, mis pidevalt kasvab. Keegi ei nõua teistelt võimatut.
Üldiselt on mõju meeskondade tööle kindlasti positiivne. Võib-olla mõtlevad ka seda artiklit lugevad kolleegid midagi sarnast teha? Siis on nõuanne lihtne: see on seda väärt, kui automaattestid on teie jaoks prioriteetsed. Järgmisena räägime keerulisemast küsimusest: kuidas seda kõike võimalikult õigesti korraldada, et kõikide osapoolte kulud oleksid minimaalsed ja väljund maksimaalne.
Korraldamise näpunäited
Kool oli kasulik, kuid, nagu Stas tunnistas, oli raskusi, mille tõttu tuli korraldada lisaloenguid. Ja just hiljutise õpilasena, kes võrdles ennast teadmatuses ja ennast praegu, sõnastasin järgmised sammud, et luua minu arvates ideaalne viis, kuidas õpetada testijaid automaatteste mõistma.
Samm 0. Loo sõnaraamat
Muidugi pole seda sammu vaja mitte ainult kvaliteedikontrolli jaoks. Siiski tahan selle selgeks teha: automatiseerimise koodibaasi tuleb hoida loetaval kujul. Programmeerimiskeeled - mitte vähem oluline keeled, ja sellest saate alustada sukeldumist.
Siin on ülesandevaate ekraanipilt koos elementide nimedega. Kujutagem ette, et testite taskvaadet musta kasti ja pole kunagi elus seleeni näinud. Mida see kood teeb?
(Spoiler – ülesanne kustutatakse administraatori nimel puhkuse kaudu ja siis näeme, et voos on selle kohta kirje.)
Ainuüksi see samm lähendab QAA ja QA keeled. Automatiseerimismeeskondadel on töötulemusi lihtsam selgitada; käsitsi testijad peavad juhtumite loomisel vähem vaeva nägema: neid saab muuta vähem üksikasjalikuks. Sellegipoolest saavad kõik üksteisest aru. Saime võidud kätte juba enne tegeliku treeningu algust.
Samm 1. Korda fraase
Jätkame paralleeli keelega. Lapsena rääkima õppides ei lähtu me etümoloogiast ja semantikast. Kordame "ema", "osta mänguasi", kuid ärge laskuge kohe nende sõnade proto-indoeuroopa juurtesse. Nii on see siin: pole mõtet sukelduda autotestide tehniliste omaduste sügavustesse, proovimata kirjutada midagi toimivat.
See kõlab veidi vastuoluliselt, kuid see töötab.
Esimeses tunnis tasub anda alus, kuidas autoteste otse kirjutada. Aitame seadistada arenduskeskkonda (minu puhul Intellij IDEA), selgitame minimaalseid keelereegleid, mis on vajalikud olemasolevasse klassi mõne muu meetodi kirjutamiseks olemasolevate sammude abil. Kirjutame nendega ühe-kaks kontrolltööd ja anname neile kodutöö, mille vormistaksin nii: meistri küljest hargnes haru, aga sealt on mitu testi maha võetud. Alles on jäänud vaid nende kirjeldused. Palume testijatel need testid taastada (muidugi mitte näitamise erinevuse kaudu).
Selle tulemusel saab see, kes kuulas ja tegi kõike,:
- õppida töötama arenduskeskkonna liidesega: harude, kiirklahvide loomine, commits ja pushs;
- valdama keele ja klasside ülesehituse põhitõdesid: kuhu sisestada süste ja kuhu importida, miks on vaja annotatsioone ja milliseid sümboleid seal peale sammude leidub;
- mõista tegevuse erinevust, oota ja kontrolli, kus mida kasutada;
- märkage erinevust automaattestide ja käsitsi kontrollimise vahel: automaattestides saate liidese kaudu toimingute tegemise asemel tõmmata ühte või teist töötlejat. Näiteks saatke kommentaar otse taustaprogrammi, selle asemel, et avada tegumivaade, valida sisend, tippida tekst ja klõpsata nupul Saada;
- sõnastada küsimused, millele vastatakse järgmises etapis.
Viimane punkt on väga oluline. Neid vastuseid saab hõlpsasti ette anda, kuid oluline on õpetamise põhimõte, et vastuseid ilma sõnastatud küsimusteta ei mäletata ja neid ei kasutata, kui neid lõpuks vaja läheb.
Oleks ideaalne, kui praegu määraks QA meeskonna automaatikainsener talle ülesandeks kirjutada paar lahingutesti ja lubaks tal oma harule alluda.
Mida mitte kinkida:
- põhjalikumad teadmised arenduskeskkonna funktsionaalsusest ja programmeerimiskeelest endast, mida läheb vaja vaid harudega iseseisvalt töötades. Seda ei mäletata, peate seda kaks või kolm korda selgitama, aga me hindame automaatikainseneride aega, eks? Näited: konfliktide lahendamine, failide lisamine giti, klasside loomine nullist, töö sõltuvustega;
- kõik, mis on seotud xpathiga. Tõsiselt. Sellest tuleb rääkida eraldi, üks kord ja väga kontsentreeritult.
2. samm. Grammatikaga lähemalt tutvumine
Meenutagem ülesandevaate ekraanipilti sammust nr 0. Meil on samm nimega checkCommentWithTextExists. Meie testija saab juba aru, mida see samm teeb ja me saame vaadata sammu sisse ja seda veidi lagundada.
Ja sees on meil järgmine:
onCommentBlock(userName).comment(expectedText).should(displayed());Kus onCommentBlock on
onCommonStreamPanel().commentBlock(userName);Nüüd õpime ütlema, et mitte "osta mänguasi", vaid "ostke mänguasi Detsky Miri poest, mis asub ülevalt kolmandal riiulil sinises kapis". Tuleb selgitada, et osutame elemendile järjestikku, suurematest elementidest (voog -> plokk teatud isiku kommentaaridega -> selle ploki see osa, kus asub määratud tekst).
Ei, veel pole aeg xpathist rääkida. Lihtsalt mainige lühidalt, et kõik need juhised on nende poolt kirjeldatud ja pärimine käib nende kaudu. Kuid me peame rääkima kõigist nendest sobitajatest ja ettekandjatest; nad on seotud konkreetselt selle sammuga ja on vajalikud toimuva mõistmiseks. Kuid ärge koormake üle: teie õpilane saab hiljem iseseisvalt uurida keerukamaid väiteid. Tõenäoliselt peaks piisama, peaks, ootama, kuvatud();, eksisteerima();, not();
Kodutöö on ilmne: haru, millest on eemaldatud mitme sammu sisu, mis on vajalik teatud arvu testide jaoks. Laske testijatel need taastada ja tee jooks uuesti roheliseks.
Lisaks, kui testimismeeskonnal pole mitte ainult uusi funktsioone, vaid ka mõned veaparandused, võite paluda tal nende vigade jaoks kohe testid kirjutada ja need vabastada. Tõenäoliselt on kõik elemendid juba kirjeldatud, puudu võib olla vaid paar sammu. Sellest saab ideaalne treening.
3. samm. Täielik keelekümblus
Võimalikult täielik testija jaoks, kes jätkab oma otseste tööülesannete täitmist. Lõpuks peame rääkima xpathist.
Esiteks teeme selgeks, et kõik need onCommentBlock ja kommentaarid on nende poolt kirjeldatud.
Kokku:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Loo järjekord on väga oluline. Esiteks võtame mis tahes olemasoleva xpath ja näitame, kuidas elementide vahekaart sisaldab ühte ja ainult ühte elementi. Järgmisena räägime struktuurist: millal peate kasutama WebElementi ja millal peate looma uue elemendi jaoks eraldi faili. See võimaldab teil pärimist paremini mõista.
Tuleb selgesõnaliselt öelda, et üks element on kogu ülesandevaade, see sisaldab alamelementi - kogu voogu, mis sisaldab alamelementi - eraldi kommentaari jne. Alamelemendid on emaelementide sees nii lehel kui ka automaattesti raamistiku struktuuris.
Siinkohal peaks publik olema kindlalt aru saanud, kuidas nad päritakse ja mida saab onCommentBlockis punkti järel sisestada. Siinkohal selgitame kõiki operaatoreid: /, //, ., [] ja nii edasi. Lisame koormasse kasutusalaseid teadmisi @class ja muud vajalikud asjad.
Õpilased peaksid mõistma, kuidas xpath sel viisil tõlkida. Konsolideerida – see on õige, kodutöö. Kustutame elementide kirjeldused, laseme taastada testide töö.
Miks just see tee?
Me ei tohiks inimest keeruliste teadmistega üle koormata, vaid peame kõike korraga selgitama ja see on raske dilemma. See tee võimaldab meil kõigepealt panna kuulajad küsimusi esitama ja millestki aru saamata ning neile järgmisel hetkel vastama. Kui rääkida kogu arhitektuurist, siis sammude ehk xpath teema analüüsimise ajaks on sellest olulisemad osad oma arusaamatuse tõttu juba ununenud.
Küll aga saavad mõned teist ilmselt jagada oma kogemusi selle kohta, kuidas protsessi veelgi optimeerida. Hea meelega loen sarnaseid ettepanekuid kommentaarides!
Allikas: www.habr.com