Vis sulaukiu klausimų apie testavimą. Dažniausia kaip alternatyvą programavimui. Maždaug "ką manai apie testavimą ir testavimo kursus" arba "ar verta iš pradžių tapti testuotoju, o tada mokytis programuoti" ir kažkas panašaus į "aš nemanau, kad išmokčiau programuoti, bet testuotoju būti galėčiau."
Nežinau iš kur randasi tos mintys apie testavimą, bet pamėginkim šiam poste panagrinėt ar testavimas yra geras ir naudingas reikalas norint patekti į IT, o gal palengvintas žingsnis link programuotojo karjeros.
# Disclaimeris
Prieš pradėdamas, turiu prisipažinti, kad mano patirtis su testuotojais gan ribota. Aš nesu dirbęs įmonėse su žmonėmis kurių pagrindinis darbas rašyti automatinius testus.
Daugiausia apie testavimą žinau iš darbo su kruopščia ir profesionalia testuotoja, kuri galėdavo paimti visą jau veikiantį web application'ą ir, naudodamasi projekto specifikacija, išgaudyti net smulkiausius bug'us arba neatitikimus.
Dirbdamas prie mažesnių projektų visada turėdavau kokį nors QA žingsnelį, bet jis nebūdavo toks formalus kaip aprašytas aukščiau.
Taigi, mano šios temos supratimas gan siauras. Bus labai gerai, jei įjungsit savo BS filtrus ir komentaruose surašysit jei tik kur nusišneku 😃
# Kodėl žmonės svarsto rinktis testavimą
Kelios mintys kodėl žmonės (bent jau rašantys ir klausiantys patarimo) svarsto rinktis testuotojo kelią.
Tikisi, kad testavimas yra mažiau techniškas ir ne toks sudėtingas kaip programavimas. Gali būti, bet nebūtinai tiesa. Priklausomai nuo naudojamų technikų ir įrankių, testavimas gali būti tiek pat sudėtingas kaip originalaus kodo rašymas.
Mažesnė konkurencija. Čia tikriausia dėl to, kad testavimas yra mažiau geidžiama profesija. Dėl konkurencijos nežinau, bet visai realu, kad pirmo testuotojo darbo gavimas nėra toks komplikuotas kaip pirmo programuotojo darbo gavimas.
Paklausi specialybė. Apie šitą per daug nežinau. Panašu, kad skelbimų yra, softo (programinės įrangos) vystyme testuotojai svarbūs, tai darbų irgi turėtų būti.
# Kam reikalingi testai ir testavimas
Paprasčiausiai kalbant, testavimas padeda sumažinti riziką. Programinė įranga (software) įprastai turi daug nežinomųjų, nuo skirtingų naršyklių kodo interpretacijos iki painių integracijų su išoriniais servisais ir dar didelės sunkiai prognozuojamos makalynės.
Pridėkim dar vartotojus, kurie naudos programą ne taip kaip įsivaizdavo programuotojai, kitus programuotojus vis tobulinančius jau parašytą programą ir turim įvairiausių neplanuotų situacijų.
Testuotojai bandys visais įmanomais būdais sulaužyti mūsų parašytą softą. Kas bus, jei banko pavedimo aprašyme vietoj skaičių ir raidžių, vartotojas sugalvos pripiešti 💰🍺🎉? Kas nutiks jei sumos langelyje parašys minusinį skaičių? Kas bus, jei bandys pervesti pinigus į tą pačią sąskaitą iš kurios siunčia?
# Apibrėžti funkcionalumą iki jį įgyvendinant kode
Aprašydami kaip turi veikti kodas, mes iškart gaunam ir testavimo case'us (nežinau kaip lietuviškai, gal testavimo atvejus?), ir planą kokį funkcionalumą turėsim įgyvendinti kodu.
Skyrę laiko apgalvoti ir surašyti papildomus test case'us, mes įgysim gerokai gilesnį suvokimą kaip turi veikti mūsų programa ar atskiras rašomas funkcionalumas.
Testuotojai čia svarbūs, nes jų darbas yra ne tik patikrinti kaip veikia programa, bet ir padėti programuotojams (kartu ir visai komandai) sutaupyti laiko, tuo pat metu kuriant kuo stabiliau veikiančią programinę įrangą.
Kartais šitą daro ir patys programuotojai. Prieš rašydami kodą susirašo testus (arba vis po testą prieš rašant naują gabaliuką) ir tada parašo kodą kuris patenkina testą. Testas - "šita funkcija turi patikrinti ar gautas skaičius yra teigiamas," tada parašo funkciją kuri keikiasi jei gautas skaičius neigiamas, džiaugiasi jei teigiamas (o kas jei gautas ne skaičius?).
Toks programavimo būdas vadinamas TDD - Test Driven Development.
# Patikrini ar programa veikia teisingai
"Tie tingūs ir užknisantys programuotojai palieka visokiausių klaidų, bugų ir šiaip nepadaro savo darbo iki galo" - kada nors koks nors testuotojas.
Testuotojai tiesiog išbando naujai parašytą funkcionalumą pirmiausia įsitikindami ar jis veikia kaip turėtų veikti, antriausia bandydami patikrinti kaip programa elgiasi ne visai standartinėse situacijose.
Kaip jau minėjau: "ar įmanoma persivesti pinigų iš draugo sąskaitos jei pavedimo sumos langalyje (input'e) parašysiu neigiamą skaičių?"
# Patikrinti ar programa ir toliau veikia kaip turėtų
Kartais nutinka taip, kad naujai parašytas kodas ką nors sulaužo anksčiau parašytuose dalykuose.
Taigi čia testuotojai gali periodiškai patikrinti ir įsitikinti, kad nauji pakeitimai nepagadina iki šiol teisingai veikusios programos.
Toks testavimas dar vadinamas regression testing ir įprastai būna automatizuotas, nes yra gan nuobodus, pasikartojantis ir, jei vykdomas rankiniu būdu, daug resursų reikalaujantis procesas.
# Koks būna testavimas
Žiūrint testuotojo akimis, pats paprasčiausias skirstymas galėtų būti į rankinį ir automatinį.
Rankinis testavimas taip vadinamas, nes dauguma veiksmų atliekami paties testuotojo. Bandoma įgyvendinti iš anksto aprašytus testavimo scenarijus (manau geras vertimas terminui test case).
Automatinis testavimas jau įmantresnis reikalas. Rašomas kodas (dažniausia, nors galima kurti automatinius testus ir be kodo), kuris automatiškai patikrina ar programa veikia kaip turėtų.
Automatinis testavimas taip pat gali būti rūšiuojamas pagal tai kas testuojama.
Unit testing - pačių smulkiausių kodo dalių testavimas. Įprastai tai gan paprastos funkcijos, kurios gavusios tokius pat duomenis visada grąžins tą patį rezultatą.
Taip ir tikrinam - funkcijai “padvigubink” gavus skaičių 2, ji visad turi grąžinti 4.
Integration testing - tikrinamas koks nors programos modulis. Nekreipiant dėmesio į specifines funkcijas, tikrinama ar modulio veikimas teisingas.
Tarkim kas bus jei funkcija “atlikPavedimą” gaus skaičių -100 (neigiamas šimtas)?
Šiuose testuose jau veikia daug funkcijų kartu, dažnai pajungiama duomenų bazė. Esu girdėjęs ir apie narsuolius kurie integration testuose leidžia savo programai kreiptis į išorinius servisus (nors pagalvojus, tikrai realu, o gal kartais ir praktiška taip elgtis).
E2E testing - (end-to-end testing) yra toks testavimas kai išbandoma visa programa.
Grįžtant prie bankinio pavedimo temos, E2E testai bandytų prisijungti prie el. bankininkystės, atsidaryti pavedimų puslapį, suvesti reikiamus duomenis ir atlikti pavedimą.
Gražiausia čia tai, kad testai automatiškai atlieka veiksmus, kuriuos atliktų vartotojas (arba mūsų atveju testuotojas). Nebereikia kiekvieną kartą spaudinėti tų pačių mygtukų ir atlikinėti visų kitų veiksmų. Kuo tikriausia magija sutaupanti kalnus laiko.
# Ką veikia testuotojai
Programuotojai prirašytą kodą tiesiog “permeta per tvorą” į testuotojų daržą, kur kodas visaip laužomas, gadinamas ir bandoma išsiaiškint kaip gerai atsilaikys prieš visokiausius sunkumus.
Pirmiausia testuotojai pasitelkę projekto specifikacija paruošia testavimo planą. Tas planas gali būti gan paprastas, gali jo ir nebūti, nes tiesiog išbandoma atlikti dalykus jau aprašytus projekto ar užduoties aprašyme. Rašant automatinius testus, patys testai yra testavimo planas.
Gavę parašytą programą ar jos dalį, testuotojai gali išmėginti anksčiau parašytą planą. Ši darbo dalis atrodo kaip pats tikriausias "testavimas" - sėdi ir tikrina ar veikia teisingai arba rašo automatinius testus.
Didžiausias džiaugsmas nutinka atradus klaidas (bugus). Tada testutojai detaliai aprašo kur bug'ai nutinka ir kaip juos atkartoti.
Pranešimai apie klaidas dažnai turi screenshotus arba įrašytus video kuriuose parodytas veikiantis bug'as.
Aiškus ir lengvai suprantamas klaidos atkartojimas yra bene geriausias dalykas kurį testuotojai gali duoti programuotojams. Kas geriau skamba - "neįmanoma atlikti pavedimo" ar "neįmanoma atlikti pavedimo, jei suma turi daugiau nei 10 skaitmenų?"
Kartais testuotojai gali identifikuoti problemą kode ir galbūt pasiūlyti sprendimą. Manau tokia strategija itin gerai kai testuotojas siekia galiausia patapti programuotoju.
# Ką dar veikia testuotojai
Klaidų ieškojimas nėra vienintelė testuotojų sritis. Jie gali dirbti su produkto žmonėmis, kad aptartų funkcionalumą, su programuotojais, kad sutartų ką ir kaip testuoti, kartais ir su softo vartotojais, kad išsiaiškintų kaip atkartoti bug'ą ir kaip tą informaciją perduoti programuotojams.
Mano galva, produkto komandai testuotojai gali duoti papildomas įžvalgas apie kurias kiti nebūtinai pagalvotų. Galbūt iš anksto aptarti potencialias problematines vietas, kiek lanksti turėtų būti programa (ar pavedimo aprašyme galėsim naudoti emojius), kiek stipriai bandysim sulaužyti parašytą funkcionalumą ir kur yra ta riba kai vietoj bandymo išspręsti visus edge case'us leisim programai tinkamai failinti.
Testuotojams ruošiantiems automatinius testus, dar gali tekti paruošti kažkokį framework'ą kuris tuos testus paleis ir kurį bus galima įdiegti į programos vystymo ir deploymento procesą.
Šitie dalykai dar vadinami CI/CD (continuous integration/continuous delivery). Programuotojams atlikus pakeitimus ir norint juos paleisti į gyvenimą, testai automatiškai paleidžiami kiekvieną kartą paruošus pull requestą (prašymą prijungti naujai parašytą kodą prie jau egzistuojančio), taip pat testai paleidžiami prieš įkeliant naujus pakeitimus į testavimo arba gyvus serverius.
# Kokių sugebėjimų reikia testuotojams
Manau viena svarbiausių testuotojų savybė yra disciplina ir sugebėjimas griežtai laikytis proceso. Kažkas panašaus į lėktuvų pilotų darbą, kur kiekvienas bent kiek reikšmės turintis veiksmas yra griežtai reglamentuotas ir įprastai turi checklistą, kurio būtina laikytis paraidžiui.
Jau sutarėm, kad testavimas yra būdas sumažinti riziką, o testuotojai gali būti ta paskutinė siena prieš atiduodant softą naudotojams. Todėl itin svarbu, kad viskas vyktų kaip galima vienodžiau, pagal taisykles, taip sumažinant klaidų galimybę.
Kitas svarbus bruožas yra atidumas detalėms. Iš mano patirties, programuotojai kartais pražiūri visokiausias smulkmenas. Testuotojų darbas yra jas išgaudyti ir nepraleisti. Čia kaip visokiuose rask Wally arba rask dešimt skirtumų galvosūkiuose.
Kitas itin svarbus reikalas yra bendravimo sugebėjimai. Komunikacija ypatingai svarbi, nes testuotojams reikia kuo aiškiau nupasakoti kas negerai, kaip tai atkartoti ir galbūt koks geriausias būdas šitai ištaisyti.
Svarbu aiškiai rašyti, tinkamai naudoti pagalbines priemones (paveikslėlius, vaizdo įrašus), kad būtų įmanoma kuo lengviau suprasti kame čia bėda.
# Kodėl verta rinktis testavimą
Mano galva testavimas yra įdomi ir svarbi programų kūrimo proceso dalis. Tiek bandant sulaužyti jau parašytą reikalą, tiek planuojant.
Ne veltui testavimo procesas dar vadinamas quality assurance (QA). Kuo sudėtingesnės ir svaresnius veiksmus atlieka programos tuo svarbesnis ir reikšmingesnis tampa testavimas.
Iš dalies galiu galvojantiems, kad testavimas yra mažiau techniška ar paini sritis nei programavimas. Atrodo, kad įmanoma rasti sau tinkantį sudėtingumo lygį, kartu turint galimybę jį palaipsniui didinti.
Įgijant programavimo žinių galima keliauti automatinio testuotojo karjeros link arba bandyti peršokti į programuotojo rolę.
Apibendrinant tai toks mažiau techniškas (?), labiau į žmones (vartotojų patirtį) orientuotas darbas, leidžiantis dalyvauti developmento procese.
# Ar testavimas yra gera alternatyva programavimui
Apie testavimą galvojančius galima skirstyti į dvi grupeles. Vieni tikisi, kad testavimas gali būti būdas patekti į programavimą, antri tiesiog nori būti testuotojai arba tikisi, kad tai galėtų būti jų bilietas į darbą tech (IT) kompanijose.
# Testavimas kaip karjeros kelias
Taip, įdomus ir vertas reikalas iš kurio net nebūtina peršokinėti į programavimą. Tiek toks galvojimas, tiek karjeros kelis yra legit.
Jei nusprendei, kad norit būti testuotojas viskas gerai, belieka išsiaiškinti ką reikia išmokti ir kaip gauti pirmą darbą.
Tačiau reiktų atsiminti kelis dalykus apie patį darbą.
Įprastai dedikuotus testuotojus turi tik didesnės, labiau įsitvirtinusios organizacijos. Tai reiškia, kad darbą funky startupėliuose, freelancinimą, location independence ir panašius dalykus pasiekti gali būti gerokai sunkiau nei programuojant.
Prie šito galim pridėti, kad darbo pasiūlymų testuotojams nėra daug. Taip, konkurencija galbūt mažesnė, bet konkuruojama dėl mažiau darbų.
Ar testuotojo darbą gauti taip pat sunku kaip programuotojo nežinau, nors visiškai tikiu, kad gali tekti gerokai pasistengti.
# Testavimas kaip žingsnis į programavimą
Galbūt. Jei pavyktų darbą gauti greit, kartu mokantis programuoti, tada judant link automatinio testavimo, kol galiausia įsiverži į programavimą.
Nemanau, kad tai būtų paprastesnis ar greitesnis būdas nei “tradicinis” ar “įprastas.”
Testavimas gal ir padeda, nes dirbi tarp kitų programuotojų, aktyviai dalyvauji softo developinime ir įgauni geresnį suvokimą kaip veikia IT kompanijos.
Visiškai sutinku, kad vien būvimas tokioj aplinkoj gali paspartinti kelionę į programavimo darbą.
Iš kitos pusės, sunkiausia dalis norint tapti programuotoju yra aukštokas patekimo barjeras. Reikia išmokti programuoti, surinkti patirties ir žinių įrodymams.
Jei tik situacija leidžia, visai verta skirti daugiau pastangų, laiko ir kantrybės šauti tiesiai link programuotojo darbo.
Kelionė su tarpine testavimo stotele atrodo per lėta, užtrunka ilgai, o svarbiausia, nėra visiškai aišku ar kiek nors palengvina patį kelią į programavimą.
# Mano 2 centai
Rašydamas šį postą suvokiau kiek mažai žinau apie testavimą, ypač apie profesionalią karjerą testavime (ar tai quality assurance).
Esu visiškai įsitikinęs, kad testavimas daug kam gali būti puikus pasirinkimas. Gal net geresnis nei programavimas.
Pagalvojus apie testavimą reiktų išsiaiškinti apie darbą daugiau, gal rasti jau dirbančių testuotojais ir paklausti jų ką mano apie savo darbą ir misiją programų vystyme.
Nepavyko įtikėti, kad testavimas gali būti kelio į programavimą dalis. Nežinau ar verta sugaišto laiko ir pastangų išskaidymo.
Pabaigai noriu paprašyti dirbančių testuotojais. Parašykit, man ir skaitantiems tikrai įdomu sužinoti kaip atrodo jūsų darbas, su kokiais iššūkiais susiduriat, ką kasdien sprendžiat savo darbe ir kas jums patinka/nepatinka jūsų profesijoje 😃 Gal net galėtume susiskambint ir pakalbėt apie tai.
