Sa evolucijom softvera i svakodnevnim iteracijama novih tehnologija, kao QA inženjer, osoba koja razume biznis potrebe, i spaja ih sa tehničkim znanjem, potrebno je ostati u toku sa najnovijim trendovima i konstantno napredovati i učiti nove veštine kojima ćete doprinositi svom timu i razvoju softvera.
Jedno od sve više traženijih tehničkih veština koja se traže na poslu od ozbiljnih QA profesionalaca, jeste i poznavanje osnovnih principa DevOps metodologija i pratećih alata.
To najpre podrazumeva razumevanje načina na koji kod dolazi do testnog okruženja i kasnije do produkcije, pa se neretko dešava da se od QA inženjera očekuje da u tom procesu igra i jednu od glavnih uloga čak i Release Managera, kao i sposobnost da sam podesi svoje testno okruženje, i odradi deploy koda na takvo okruženje, istestira feature odnosno promenu, a zatim i uništi to okruženje, kad više nije potrebno za korišćenje, a sve sa ciljem efikasnijeg testiranja i upravljanja memorijskim i kompanijskim resursima. Posebno je potrebno napomenuti da svako okruženje koje dugoročno postoji, poput popularnih Staging, pre-production itd, na kojima se obavlja testiranje pre produkcije, sa sobom povlači ozbiljno održavanje takvog okruženja i konfiguracija, a takođe i materijalne troškove, jer se ono nalazi uglavnom na Cloud serverima i mašinama, čije korišćenje uglavnom kompaniju košta značajno.
To je suštinski jedan tehnološki trade-off koji inženjerski tim mora da učini nakon što se utvrde potrebe testiranja, odnosno odgovor na pitanje – da li ovu promenu/feature želim da testiram u izolaciji u odnosu na neke promene i konfiguracije koje postoje već odavno ili mi je pak bitnije da razumem kako ova promena utiče na sistem i konfiguraciju koja već duže postoji.
Pa tako ovaj proces od QA inženjera zahteva razumevanje najpre tehnologije source code repositorijuma (github, bitbucket), zatim načine na koji možemo da taj kod stavimo na neko okruženje (deployment) korišćenjem CI/CD alata poput GitHub actions-a, Jenkinsa itd., kako da napravimo da testovi ne zavise od okruženja na kojima se obavljaju, već samo od biznis logike korišćenjem alata za kontejnerizaciju poput Dockera i Kubernetesa, pa sve do poznavanja infrastrukturnih alata, poput AWS-a, Terraforma (infrastucture-as-service alata) i mnogih drugih kojima možete da sami podižete i uništavate vaše testno okruženje, bez preterane pomoći ostalih članova tima.
Ukoliko ste sposobni da sami uradite sve ove akcije, bićete jako cenjen član svog tima, pogotovo ako govorimo o tradicionalnom Scrum timu koji je i dalje zastupljen i gde se u teoriji očekuje da je svaki član tima sposoban da odradi bilo koji zadatak (za QA čak i pisanje i menjanje samog koda).
Znanje ovih tehnologija, kao i mnogih drugih, dostupno vam je na našem naprednom kursu na QA Akademiji.
Ukoliko želite da podignete svoje znanje o ovim temama na viši nivo, ne oklevajte da nam se javite!
Tu smo da vas naučimo!