U razvoju softvera danas je uglavnom opšte prihvaćen agilni pristup. Veliki broj kompanija primenjuje ovaj pristup i priliagođava ga svom razvojnom procesu, međutim sam pristup procesu, kao i implementacija na internom nivou, može se razlikovati od kompanije do kompanije. Sami temelji na kojem se oslanja agilni pristup je uglavnom globalno prihvaćen i isti. Agilni proces je dosta kompleksan i u ovom članku se nećemo baviti opisivanju samog agilnog pristupa, već objašnjenju shift left testing pristupa koji se često implementira u agilnom okruženju kao deo agilnog testing pristupa.
Pre nego što se posvetimo shift left testing pristupu, razmotrimo prvo jedan opšte prihvaćen SDLC (Software development lifecycle)
Ovo je prikaz jednog opšteg SDLC-a koji se i dalje primenjuje u kompanijama, obratićemo pažnju gde je implementiran testing proces. Implementiran je tek kada su završeni planing, design i development procesi, posle svega toga tek onda kreće testing proces. Ovakav pristup se i dalje primenjuje u kompanijama, čak ga primenjuju i timovi koji koriste agilni pristup.
Defintivno u agilnom okruženju gde je jedan od glavnih ciljeva kontinuiran release, testing proces kao što je gore naveden će praviti problem. Osnovni problem jeste što je testing proces i dalje postavljen kao standardni testing pristup koji se primenjivao pre agilnog pristupa (standardno testiranje koje se primenjivalo u Waterfall modelu).
Ovakav model testiranja koji je naveden iznad, ima sledeće principe:
- Software tester je odgovoran za kvalitet samog proizvoda
- Software tester je odgovorna osoba koja daje clear za release (kada je zajedno sa regresijom testing proces završen)
- Testing proces počinje uglavnom kada se završi sama implementacija
- Ostali članovi tima (Development, Design …) su slabo uključeni u quality i testing proces osim QA-testing tima
- U testing procesu se očekuje da testing tim pronađe sto više defekta
- Fokus je na pronalaženju defekta, a ne na samoj prevenciji
Ovakav klasičan testing pristup je jako skup, pogotovo u agilnom okruženju. Kasno se kreće sa testiranjem i samim tim kasno stižu povratne informacije od testing tima, na primer, možda se primeti da u specifikaciji nije nešto najbolje pokriveno, ili se postavi pitanje koje nije uzeto u obzir kada su se radili planing design i development faze. To može da dovede do različitih promena u specifikaciji, kao i promena samog zahteva (change request). Doprinosi da se postojeći feature vrati na razvoj i to zahteva dodatno vreme za menjanje specifikacije, sam razvoj, kao i potencijalno nove defekte koji mogu nastati tokom razvoja.
U agilnom okruženju gde se očekuju učestali rilisovi (release), može se steći utisak da testing tim koči proces, samim tim i release, da mu treba dosta vremena kako bi odradio verifikaciju i validaciju. To jeste istina, testing timu treba znatno više vremena kada se cela jedna komponenta preuzima odjednom da se testira, kada se ne testira granularno po manjim taskovima. Testing timu ne da treba više vremena, već se stiče utisak da nikada nema dovoljno vremena za ceo testing proces, često se auto testovi ostavljaju po strani i njima se tek daje značaj kada se završi exploratory testing trenutne implementacije.
Razvijene komponente se često vraćaju kao nedovršene, ili se čeka da se isprave defekti koji su pronađeni tokom testiranja.
I ako neki timovi koriste agilni pristup, često zanemare da testing proces isto treba da bude agilno implementiran.
Kod takvih timova će se veoma brzo primetiti posledica što primenjuju agilni pristup bez agilnog testing procesa. Posledice koje mogu da se primete kada se primenjuje agilni pristup bez agilnog testiranja su uglavnom sledeći:
- Problem u implementaciji, ukoliko postoji kasno se uočava.
- Testing proces je znatno skuplji, često zahteva veći testing tim.
- Rast tenzije u testing timu, osećaj da ne moze sve da se završi u odgovarajućem vremenu.
- Manevrisanje u postizanju testiranja i drugih aktivnosti, kao sto su automatizacija testova, regresija …
- U razvojnom delu (development), proizvodi se veći broj defekta.
- Dolazi do nerazumevanja u onome sto se želi postići, komunikacija nije najjasnija izmedju dev, produkt i testing tima.
- Previše vremena se troši u regresijji i u toku testiranja.
- Zbog većeg broja defekta koji nastaju u toku razvoja, testing tim ne stiže da ih sve “uhvati”.
- Učestaliji problemi na produkciji, i prijavljeni defekti sa produkcije.
- Kako bi testing tim stigao da što više odradi u fazi testiranja mora da odbaci test slučajeve koji su manjeg prioriteta i fokusira se samo na test slučajeve višeg prioriteta, što doprinosi da je implementacija nedovoljno istestirana.
- Nesigurnost tima pri rilisu, da sa novom implementacijom nije nešto poremećeno obzirom da pored regresije ne postoje protektivni mehanizmi.
Gore navedeni su potencijalni problemi koji mogu nastati i koji će se primetiti ukoliko testing proces nije dobro implementiran. To su nuspojave ukoliko se tradicionalni testing pristup primenjuje u agilnom okruženju.
Sada kada smo se upoznali sa tradicionalnim testing procesom i naveli učestale probleme u agilnom okruženju, ako se tradicionalni testing proces primenjuje, da se upoznamo šta je shift left testing.
Shift left testing je implementacija testing procesa, koji sam testing proces gura u levo na nivou software development lifecycle. Smatra se da je deo agilnog testing procesa i njegov cilj jeste da smanji i eliminiše probleme koji su opisani kod standardnog testiranja. Videli smo kod regularnog testing procesa da testing počinje u kasnijoj fazi, uglavnom kada se development završi. Shifting left upravo je što mu sam naziv kaže – omogućava da se testing proces usmeri ulevo, da testing kao proces bude uključen u što ranijoj fazi. Omogućava da testing proces bude uključen od samog starta i pokriva svaki proces, do samog kraja, pa čak i kasnije, kroz monitoring i praćenje korisničkog ponašanja sa novom implementacijom.
Tri osnovna stuba na koje se oslanja shift left testing su:
- Testing proces u što ranijoj fazi sa fokusom na prevenciji, a ne samo detekciji defekta
- Kolaboracija u timu sa pristupom da je kvalitet odgovronost celog tima
- Automatizacija testova i continues testing
Najbitnije kod ovog pristupa jeste da je testing proces uključen u što ranijoj fazi, što smo već napomenuli, kao i da je uključen od samog starta. Da kada programer još radi na samoj implementaciji, da postoje zaštitni testing mehanizmi koji će pomoći da se već u tako ranoj fazi detektuju novonastali problemi. Ako postoje i da se preventivno uklone pre nego što je programiranje uopšte završeno. Jedan od primera je, u toku razvoja pri samom commit-u ili pul requestu, može da se izvrši set auto testova (u tom delu uglavnom unit testova, code quality testova, uglavnom testova koji nisu kompleksni i čija egzekucija može brzo da se izvrši) Stakvim pristupomi 50% testa može paralerno da se izvršava u samoj implementaciji. U takvom slučaju, potencijalni defekt bi se pronašao u veoma ranoj fazi, i preventivno bio ispravljen dok razvoj još traje. Takav pristup doprinosi prevenciji defekta, pošto je razvoj još u toku i mnogo manje košta nego ako se detektuje defekt u kasnijim fazama (na QA, Staging ili Prod okruženju). Auto testovi zajedno sa CI/CD (Continuous testing) igraju ključnu ulogu i veliki akcenat je na pokrivenosti različitih auto testova (unit, integracijski, UI, api, performans, security …)
Postoje različite aktivnosti koje omogućavaju da je testing proces kontinuiran, neke od njih ćemo ovde navesti, ali nećemo za sve dati objašnjenje.
Testing proces u što ranijoj fazi
Osnovna ideja left shifting-a jeste da testiranje kao aktivnost počne u što ranijoj fazi, da bude uključen već sa prvom fazom od samog planinga do release-a, kao i kasnije monitorisanje (monitoring) samog rilisa. Postoje niz testing aktivnosti koje mogu da se primene za svaku fazu i oni mogu da se razlikuju u zavisnosti od tima i samog projekta.
Osnovna filozofija je da je ceo tim uključen za sproveđenje kvaliteta kod proizvoda gde se postavlja pristup da je kvalitet odgovornost celog tima.
Na slici iznad možemo da vidimo sa primenom shift left pristupa, testing je uključen u svakoj fazi. Same aktivnosti mogu da se razlikuju od faze do faze.
Možemo navesti neke osnovne razlike između ovakvog pristupa i tradicinalnog:
- Ceo tim je uključen u kvalitet, i deo je testing procesa
- Testing proces je uključen u svakoj fazi lifecycle-a
- Veoma je veliki akcenat na auto testovima u svim nivoima testova (unit, integracijski, funkcionalni, performans, security, api, UI)
Ovde ćemo u kratkim crtama navesti primer koje načelno aktivnosti mogu biti SDLC:
Planing
U okviru planinga: može se raditi statičko testiranje, da se izvršava statička analiza provere specifikacije. Takođe se u okviru planinga može voditi BDD (behaviour driven development) sesije, te sesije se inače zovu i 3 amigos sesije. U okviru tih sesija se postiće kolaboracija u timu između ljudi koji imaju drugačiji pogled na osnovu svoje stručnosti (BI, QA, Developer)
Glavna ideja navedenih sesija, je da se kroz realne primere user story-a, primeni kolaboracija u definisanju bussines rule-ova (acceptance testova). Kroz ovu sesiju, koja je poznata kao 3 amigosa, tim zajedno modelira story-e, a ne samo produkt. Za tu sesiju često se koristi koncept example mapping, ili feature mapping.
Design
U okviru design-a, ukoliko se primenjuje BDD kao proces u okviru designa se piše acceptance u gherkin formi za story koji je formulisan sa bussines rulleovima kroz planing fazu.
Development
U ovoj fazi auto testovi imaju krucionalnu ulogu. Ukoliko se primenjuje BDD kao proces u ovoj fazi će se paralerno raditi na automatizaciji acceptance testova, to jes specifikacje koja je u predhodnoj fazi formulisana u given when then formi. Ideja je da auto testovi verifikuju acceptance, dok ce se u testing fazi testing tim pozabaviti više exploratory testing-om.
Unit, integration testovi kao deo kontinuiranog testing procesa, mogu da pomognu da se ranije detektuje problem dok jos traje development. Ti testovi mogu biti pisani pre implementacije pratećti TDD (test driven development) formu. Oni su uglavnom integrisani uz CI/CD pipeline, pošto je to hijerhijski najniži nivo testa, njihova egzekucija je dosta brza i idealni su da se izvršavaju pri komitu ili pull request-u.
Zakazana egzekucija regresionih auto testova, uglavnom end to end testova koji su automatizavani za deo regresije, mogu isto dosta da pomognu. Ti testovi mogu skoro svake večeri da se automatski pokreću na nekom razvojnom okruženju i omogućava da imamo učestalu regresiju koji izvršavaju auto testovi i da u ranoj fazi detektuju problem. Pošto najviše ima testova za regresiju oni su idealni da budu zakazani da se automatski pokreću noću (njihovo vreme egzekucije je dugo i može da traje preko 3,4 sata). Ujutru tim kada počne sa radom može da vidi da li su automatski regresioni testovi pronasli nesto i da blagovremeno reaguju.
Code quality, ovo su uglavnom scaning alati koji mogu isto da se izvrše pri komitu ili pul requestu, pomažu pri code review-u, to su uglavanom alati koji skeniraju code i pomazu prii detekciji da li je code pisan u skladu sa standardima da li potecijalno postoji bezbednosni problemi u kodu. Alati koji se koristi su Sonar, Vera code, Codacy …
Testing
S obzirom da je od samog starta razvoja uključen testing proces, u ovoj fazi se razlikuje testing od tradicionalnog. Manji akcenat je da se testira po acceptance-u, pošto je očekivano da je acceptance automatizovan sa bdd-jem (BDD – Behaviour driven development). Veći akcenat je na eksploratory testingu (exploratory testing), za koji ima cilj da pronađe zaostale defekte, izazvane specifičnim slučajevima (često nazivani kao edge cases ).
Deploy: U ovoj fazi je takođe uključen testing, radi se tech release notes, release log, aktivni su CD pipeline-ovi koji aktiviraju testove, razni alert-i i monitoring alati kontrolišu da release prođe u što boljem redu.
Zaključak
Shift left testing ima bitnu ulogu kod agilnih timova, smatra se kao jedna od značajnih aktivnosti, kako bi se omogućio da testing proces bude agilan. Sa fokusom na kolaboraciji celog tima u učestvovanju oko test aktivnosti kao deo procesa u što ranijoj fazi gde je kontiunirano testiranje jako bitno i zbog toga je integrisan kroz CI/CD pipeline. Ako se u agilnom testingu smatra da je kvalitet odgovornost celog tima, onda treba biti uključen od samog poćetka‚ i to je glavna uloga shift left testing pristupa. Shift left testing nam omogućava, da budemo više sigurniji kada puštamo nove funkcionalnosti na produkciju, zbog robusnih auto testova koji pokrivaju različite testing nivoe. Bez navedenih aktivnosti koje primenjuje shift left testing kao proces, je tim agilan samo na papiru, i za to će biti učestali novi bug-ovi pri novim releas-ovima. Iako je danas shift left testing neophodan da bude deo agilnog tima, često se javlja poteškoća pri integraciji i samim tim se stvaraju izazovi. Ako tim nije navikao na ovakav pristup, ili nije uopšte upoznat, neophodno je prvo upoznati ceo tim sa ovakvim pristupom, kroz obuke i prezentacije i promeniti pristup u timu. Nekada je teško uključiti ceo tim da bude deo testing procesa. Zbog toga je potrebno imati definisan plan kako integrisati i objašnjenje kojim će biti definisani problemi koji bi bili rešeni pri implementaciji navedenih aktivnosti. Kada se navedeni proces postavi na stabilnim nogama, benifit će se primetiti već posle par release-a. Kao što smo naveli da auto testovi imaju bitnu aktivnost, zbog toga treba pri kreiranju plana izdvojiti vreme za njih, oni treba da budu deo razvojnog procesa i za njih treba da se isplanira dovojno vremena kako bi se isplementirali.
Shift left ne treba gledati kao neki novi pristup ili novu filozofiju, to je ključan deo agilnog procesa i tako ga treba tretirati, a ne kao opcionu aktivnost.
Nadamo se da vas je tekst upoznao o aktivnostima koje su vezane za shift left testing deo i da ste stekli dovojno jasnu sliku zašto je neophodno da bude deo svakog tima koji koristi agilni pristup. Ukoliko imate neko pitanje ili sugestiju, možete da me kontaktirate preko mail-a: zoran.v.zivanovic@gmail.com
Leave a Reply