Neljä viidestä QA-hakijasta haluaa oppia työskentelemään automaattisten testien kanssa. Kaikki yritykset eivät pysty täyttämään tällaisia manuaalisten testaajien toiveita työaikana. Wrike piti automaatiokoulun työntekijöille ja toteutti tämän halun monille. Osallistuin tähän kouluun juuri QA-opiskelijana.
Opin työskentelemään Seleenin kanssa ja tuen nyt itsenäisesti tiettyä määrää automaattisia testejä käytännössä ilman ulkopuolista apua. Ja yhteisen kokemuksemme tulosten ja henkilökohtaisten johtopäätösteni perusteella yritän johtaa ihanteellisimman automaatiokoulun kaavan.
Wriken kokemus koulun järjestämisestä
Kun automaatiokoulun tarve tuli selväksi, sen organisointi putosi automaation teknisen johtajan Stas Davydovin tehtäväksi. Kuka muu kuin hän voi selittää, miksi he tekivät tämän aloitteen, saavuttivatko he tuloksia ja katuvatko he käytettyä aikaa? Annetaan hänelle puhe:
— Vuonna 2016 kirjoitimme autotesteille uuden viitekehyksen ja teimme sen niin, että testien kirjoittamisesta tuli helppoa: normaalit askeleet ilmestyivät, rakenteesta tuli paljon ymmärrettävämpi. Saimme idean: meidän on otettava kaikki, jotka haluavat kirjoittaa uusia kokeita, ja jotta se olisi helpompi ymmärtää, loimme luentosarjan. Teimme yhdessä aihesuunnitelman, jokainen tuleva luennoitsija otti sellaisen itselleen ja valmisteli siitä raportin.
– Mitä vaikeuksia opiskelijoilla oli?
– Pääasiassa tietysti arkkitehtuuri. Testimme rakenteesta oli paljon kysymyksiä. Palautteessa tästä aiheesta kirjoitettiin paljon ja jouduimme pitämään lisäluentoja selittääksemme tarkemmin.
– Maksoiko koulu?
- Kyllä ehdottomasti. Hänen ansiostaan monet ihmiset osallistuivat testien kirjoittamiseen, ja keskimäärin sairaalassa kaikki alkoivat ymmärtää paremmin, mitä autotestit ovat, miten ne kirjoitetaan ja miten ne käynnistetään. Myös automaatioinsinöörien kuormitus on vähentynyt: saamme nyt monta kertaa vähemmän avunpyyntöjä testien analysointiin, sillä testaajat ja kehittäjät ovat alkaneet selviytyä tästä itse lähes kaikissa tilanteissa. No, laitoksella on useita sisäisiä etuja: saimme kokemusta esityksistä ja luennoista, joiden ansiosta osa automaatioinsinööreistä on jo onnistunut pitämään esitelmiä konferensseissa ja saanut myös tehokkaan sarjan videoita ja esityksiä uusille tulokkaille.
Omasta puolestani lisään, että osastojemme välinen viestintä on yksinkertaistettu aivan naurettavan helpoksi. Esimerkiksi nyt minun ei käytännössä tarvitse miettiä, mitkä tapaukset ja millä atomiteettitasolla automatisoida. Tämän seurauksena kaikki kiinnostuneet osapuolet huolehtivat jatkuvasti kasvavasta testikattavuudesta. Kukaan ei vaadi muilta mahdotonta.
Yleisesti ottaen vaikutus tiimien työhön on ehdottomasti positiivinen. Ehkä tätä artikkelia lukevat kollegat harkitsevat myös vastaavan tekemistä? Sitten neuvo on yksinkertainen: se kannattaa, jos automaattiset testit ovat sinulle etusijalla. Seuraavaksi puhumme monimutkaisemmasta kysymyksestä: kuinka järjestää tämä kaikki mahdollisimman oikein niin, että kaikkien osapuolten kustannukset ovat minimaaliset ja tuotos maksimaalinen.
Järjestämisvinkkejä
Koulu oli hyödyllinen, mutta kuten Stas myönsi, oli joitain vaikeuksia, joiden vuoksi oli tarpeen järjestää lisäluentoja. Ja juuri äskettäin opiskelijana vertaillessani itseäni tietämättömyydessä ja itseäni nyt muotoilin seuraavat vaiheet luodakseni mielestäni ihanteellisen tavan opettaa testaajia ymmärtämään automatisoituja testejä.
Vaihe 0. Luo sanakirja
Tämä vaihe ei tietenkään ole tarpeen vain laadunvarmistuksen kannalta. Haluan kuitenkin tehdä sen selväksi: automaation koodikanta on säilytettävä luettavassa muodossa. Ohjelmointikielet - ei vähäisimpänä Kieli (kielet, ja tästä voit aloittaa sukelluksesi.
Tässä on kuvakaappaus tehtävänäkymästä, jossa on elementtien nimet. Kuvittele, että testaat TaskView'ta mustana laatikkona etkä ole koskaan nähnyt Seleeniä elämässäsi. Mitä tämä koodi tekee?
(Spoileri - tehtävä poistetaan järjestelmänvalvojan puolesta restin kautta, ja sitten näemme, että tästä on tietue streamissa.)
Pelkästään tämä vaihe tuo QAA- ja QA-kielet lähemmäksi toisiaan. Automaatiotiimien on helpompi selittää ajon tuloksia; manuaalisten testaajien on käytettävä vähemmän vaivaa tapausten luomiseen: niistä voidaan tehdä vähemmän yksityiskohtaisia. Silti kaikki ymmärtävät toisiaan. Saimme voitot jo ennen varsinaisen harjoittelun alkamista.
Vaihe 1. Toista lauseet
Jatketaan rinnastusta kielen kanssa. Kun opimme puhumaan lapsena, emme lähde etymologiasta ja semantiikasta. Toistamme "äiti", "osta lelu", mutta älä mene heti näiden sanojen proto-indoeurooppalaisiin juuriin. Näin se on: ei ole mitään järkeä sukeltaa autotestien teknisten ominaisuuksien syvyyksiin yrittämättä kirjoittaa jotain toimivaa.
Se kuulostaa hieman ristiriitaiselta, mutta se toimii.
Ensimmäisellä oppitunnilla kannattaa antaa perusteet autotestien kirjoittamiseen suoraan. Autamme luomaan kehitysympäristön (minun tapauksessani Intellij IDEA), selitämme vähimmäiskielisäännöt, joita tarvitaan toisen menetelmän kirjoittamiseen olemassa olevaan luokkaan olemassa olevien vaiheiden avulla. Kirjoitamme heidän kanssaan yhden tai kaksi koetta ja annamme kotitehtävän, jonka muotoilisin näin: masterista haarautui haara, mutta siitä on poistettu useita testejä. Vain niiden kuvaukset ovat jäljellä. Pyydämme testaajia palauttamaan nämä testit (ei tietenkään show diff:n kautta).
Tämän seurauksena se, joka kuunteli ja teki kaiken, pystyy:
- oppia työskentelemään kehitysympäristön käyttöliittymän kanssa: luomaan haaroja, pikanäppäimiä, sitoumuksia ja työntöjä;
- hallitsee kielen ja luokkien rakenteen perusteet: minne lisätä injektiot ja mihin tuoda, miksi merkintöjä tarvitaan ja millaisia symboleja sieltä löytyy, vaiheiden lisäksi;
- ymmärrä toiminnan ero, odota ja tarkista, missä käyttää mitä;
- huomaa eron automaattisten ja manuaalisten tarkistusten välillä: automaattisissa testeissä voit vetää yhden tai toisen käsittelijän sen sijaan, että suoritat toimintoja käyttöliittymän kautta. Lähetä esimerkiksi kommentti suoraan taustaohjelmaan sen sijaan, että avaat tehtävänäkymän, valitset syötteen, kirjoitat tekstiä ja napsautat Lähetä-painiketta.
- muotoile kysymyksiä, joihin vastataan seuraavassa vaiheessa.
Viimeinen kohta on erittäin tärkeä. Nämä vastaukset voidaan helposti antaa etukäteen, mutta tärkeä opetusperiaate on, että vastauksia ilman muotoiltuja kysymyksiä ei muisteta eikä niitä käytetä, kun niitä lopulta tarvitaan.
Olisi ihanteellista, jos tällä hetkellä QA-tiimin automaatioinsinööri antaisi hänelle tehtävän kirjoittaa pari testiä taistelussa ja sallisi hänen sitoutua alaansa.
Mitä ei kannata antaa:
- syvällisempää tietoa kehitysympäristön toimivuudesta ja itse ohjelmointikielestä, jota tarvitaan vain itsenäisesti toimittaessa haarojen kanssa. Sitä ei muisteta, sinun täytyy selittää se kahdesti tai kolmesti, mutta arvostamme automaatioinsinöörien aikaa, eikö niin? Esimerkkejä: konfliktien ratkaiseminen, tiedostojen lisääminen gitiin, luokkien luominen tyhjästä, riippuvuuksien käsittely;
- kaikki xpathiin liittyvä. Vakavasti. Siitä pitää puhua erikseen, kerran ja hyvin keskittyneesti.
Vaihe 2. Tarkastellaan kielioppia tarkemmin
Muistakaamme tehtävänäkymän kuvakaappaus vaiheesta 0. Meillä on vaihe nimeltä checkCommentWithTextExists. Testaajamme ymmärtää jo tämän askeleen ja voimme katsoa askeleen sisälle ja hajottaa sitä hieman.
Ja sisällä meillä on seuraavat:
onCommentBlock(userName).comment(expectedText).should(displayed());Missä onCommentBlock on
onCommonStreamPanel().commentBlock(userName);Nyt opimme sanomaan, ettei "osta lelu", vaan "osta lelu Detsky Mir -kaupasta, joka sijaitsee sinisessä kaapissa kolmannella hyllyllä ylhäältä". On tarpeen selittää, että osoitamme elementtiä peräkkäin, suuremmista elementeistä (virta -> lohko tietyn henkilön kommenteilla -> se osa tästä lohkosta, jossa määritetty teksti sijaitsee).
Ei, vielä ei ole aika puhua xpathista. Mainitse vain lyhyesti, että kaikki nämä ohjeet ovat heidän kuvaamiaan ja periytyminen kulkee niiden kautta. Mutta meidän on puhuttava kaikista näistä sovittajista ja tarjoilijoista; ne liittyvät nimenomaan tähän vaiheeseen ja ovat välttämättömiä ymmärtämään, mitä tapahtuu. Mutta älä ylikuormita: opiskelijasi voi tutkia monimutkaisempia väitteitä itse myöhemmin. Todennäköisesti pitäisi, odottaa, displayed();, olemassa();, not(); pitäisi riittää.
Kotitehtävä on ilmeinen: haara, josta on poistettu useiden vaiheiden sisältö, jotka ovat välttämättömiä tietylle määrälle kokeita. Anna testaajien palauttaa ne ja tehdä ajon taas vihreäksi.
Lisäksi, jos testaustiimin töissä ei ole vain uusia ominaisuuksia, vaan myös joitain virheenkorjauksia, voit pyytää häntä välittömästi kirjoittamaan näistä virheistä testejä ja julkaisemaan ne. Todennäköisesti kaikki elementit on jo kuvattu; vain pari vaihetta saattaa puuttua. Tästä tulee täydellinen harjoitus.
Vaihe 3. Täysi upotus
Mahdollisimman täydellinen testaajalle, joka jatkaa suorien tehtäviensä suorittamista. Lopuksi meidän on puhuttava xpathista.
Tehkäämme ensin selväksi, että ne kuvaavat kaikki nämä onCommentBlock- ja kommentit.
Yhteensä:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"Tarinan järjestys on erittäin tärkeä. Ensin otamme minkä tahansa olemassa olevan xpathin ja näytämme, kuinka elementit-välilehti sisältää yhden ja vain yhden elementin. Seuraavaksi puhumme rakenteesta: milloin sinun on käytettävä WebElementiä ja milloin sinun on luotava erillinen tiedosto uudelle elementille. Tämä auttaa sinua ymmärtämään perinnöllistä paremmin.
On nimenomaisesti sanottava, että yksi elementti on koko tehtävänäkymä, se sisältää alielementin - koko streamin, joka sisältää alielementin - erillisen kommentin jne. Lapsielementit ovat yläelementtien sisällä sekä sivulla että automaattisen testauskehyksen rakenteessa.
Tässä vaiheessa yleisön olisi pitänyt ymmärtää tarkasti, miten ne periytyvät ja mitä voidaan syöttää pisteen jälkeen onCommentBlockissa. Tässä vaiheessa selitämme kaikki operaattorit: /, //, ., [] ja niin edelleen. Lisäämme kuormaan käyttöön tietoa @class ja muut tarpeelliset asiat.
Opiskelijoiden tulisi ymmärtää kuinka xpath käännetään tällä tavalla. Vahvistaa - juuri niin, läksyt. Poistamme elementtien kuvaukset, anna niiden palauttaa testien toiminta.
Miksi juuri tämä tie?
Emme saa ylikuormittaa ihmistä monimutkaisilla tiedoilla, vaan meidän on selitettävä kaikki kerralla, ja tämä on vaikea dilemma. Tämä polku antaa meille mahdollisuuden saada kuulijat ensin kysymään kysymyksiä ja olemaan ymmärtämättä jotain ja vastaamaan niihin heti seuraavalla hetkellä. Jos puhutaan koko arkkitehtuurista, niin vaiheiden tai xpath-aiheen analysointiin mennessä sen tärkeimmät osat unohdetaan jo käsittämättömyyden vuoksi.
Jotkut teistä voivat kuitenkin todennäköisesti jakaa kokemuksesi siitä, kuinka prosessia voidaan optimoida vieläkin enemmän. Mielelläni luen samanlaisia ehdotuksia kommenteissa!
Lähde: will.com