Aistė is an experienced tester and test lead who is the most interested in making testing and test automation good enough for continuous delivery. She enjoys sharing her experience and learning from others. Hence she is an active organizer and promoter of Bugs’a’loud testers community events. When not testing software or hanging out with other testers, Aistė plays board games, enjoys food in different restaurants or her own kitchen, and travels – the more exotic, the better!
Ant abiejų rankų pirštų nesuskaičiuočiau, kiek kartų esu girdėjusi „norėčiau išmokti automatizuoti testus“, tačiau taip niekada ir „nebuvo progos”, „nesugalvojau, nuo ko pradėti”ir t.t. Kartais trūksta tik šiek tiek pagalbos, pavyzdžiui, kad kažkas parodytų patį procesą bei iš anksto įspėtų apie dažniausiai pasitaikančias klaidas ir iššūkius, pasidalintų patarimais. Taip prieš beveik dvejus metus gimė Visma Lietuva vidiniai testavimo automatizavimo mokymai, kurie peraugo į išorinius, tad dabar jau mokome ne tik „saviškius”.
Ko mokomės kursuose? Ir kodėl nei vieni mokymai nebūna vienodi?
Mokymus paprastai pradedame aptardami ką gali testų automatizavimas ir ko ne (1 pav.), taip pat apžvelgiame šiek tiek teorijos. Vis tik didžiąją dalį mokymų laiko praleidžiame programuodami – iš pradžių UI testus su Selenium. Selenium pavyzdžių pradedantiesiems internete – šimtai, tačiau visai kas kita, kai kažkas parodo, kur galima pasipraktikuoti CSS selektorius (psst – https://flukeout.github.io/), paaiškina page-object pattern, o parašius testus pasiūlo užduoti sau keletą klausimų, tokių kaip:
- Testas dabar pass’ina – o ar jis tikrai fail’ins, esant problemai?
- Testas dabar pass’ina – bet ar taip bus nepriklausomai nuo duomenų, testų leidimo tvarkos ir t.t.?
Toliau mokomės automatizuoti REST API testus – pavyzdžiui, naudodami RestSharp biblioteką bei SpecFlow įrankį, kuris testus padaro žymiai labiau skaitomus:
Išmokę automatizuoti API, aptariame API testavimo privalumus, apribojimus ir iššūkius, ir galiausiai visus mokymų metu parašytus testus paleidome automatiniam vykdymui su Continuous Integration įrankiu TeamCity.
Visgi pagrindinė pamoka, kurią išmokau mokydama kitus – vienodų mokymų nebūna. Kiekviena grupė skirtinga ir mokymai efektyviausi tada, kai juos pritaikai būtent tai grupei. Dėl šios priežasties pasiruošimą mokymams pradedu nuo lūkesčių ir turimos patirties išsiaiškinimo. Pirmieji išoriniai mokymai buvo netgi labai smarkiai adaptuoti – grupė norėjo mokytis automatizuoti PHP, o ne C# kalba, jiems nebuvo aktualus API automatizavimas, tačiau jie norėjo daugiau gilintis į Continuous Integration įrankio TeamCity konfigūravimą. Kitos grupės kol kas mokėsi pagal originalią programą, tačiau kiekvienas dalyvis atėjo su skirtinga patirtimi, tad net vienos grupės viduje reikėjo nepamiršti kiekvienam akcentuoti vis skirtingus aspektus.
Spoiler: testų optimizavimas ir dar n+1 dalykų, ką turėtum žinoti
Tačiau nepriklausomai nuo to, kokia kalba ar kokiais įrankiais automatizuoji testus, anksčiau ar vėliau susiduri su tais pačiais klausimais ir problemomis. Pavyzdžiui kaip nuspręsti, kuriuos testus automatizuoti ir kuriame testų automatizavimo piramidės lygyje. Arba kaip pasiekti, kad testai būtų… na tiesiog… geri?
Mokymuose netrūksta smulkių patarimų, kaip testus rašyti paprasčiau, efektyviau, išvengti potencialių problemų, nagrinėjame atsakymus į šiuos klausimus:
- Kaip susitvarkyti su lėtais testais
- Kaip padaryti, kad galėtume pasitikėti testų rezultatais
Trumpai aptarkime pirmą punktą – testų optimizavimą. Jo esmė – peržiūrėti visus testus ir atsakyti sau į tokius klausimus, kaip:
- Ar tikrai prieš kiekvieną testą reikia iš naujo prisijungti?
- Ar tikrai šioje vietoje reikalinga navigacija per UI?
- Ar tikrai kas kartą reikia susikurti / išvalyti testinius duomenis / nustatymus (pre-conditions)?
- Gal yra būdas tai padaryti greičiau?
- Gal yra būdas tai padaryti atskirai nuo testų?
- Gal čia nereikia UI testo, gal tai gali būti API arba netgi Unit testas?
- O gal apskritai šito testo nereikia (tai jau padengia kitas)?
Apskritai siekiant greitai besisukančių testų, reikia turėti tikslą – per kiek laiko norėtume iš savo testų gauti feedback’ą? Tad pirmas žingsnis galėtų būti apriboti testų leidimui skirtą laiką (time-box) ir daryti viską, kad testai į tą laiką tilptų. Testų optimizavimas – tik vienas iš keleto dalykų, ką galima šiuo klausimu nuveikti. Daugiau informacijos apie mūsų turimus mokymus rasite čia!
