Prijelaz sa vodopada na agilno testiranje

Kada se kompanija odluči za prelazak sa vodopada na agilno testiranje, koja su najvažnija područja na koja se treba koncentrirati za efikasno agilno testiranje?

Kako se testiranje na okretan način uspoređuje s testiranjem modela Waterfall? Koji skup aktivnosti je važno da testeri znaju i rade?



Testiranje tokom razvoja

Prvo što treba shvatiti je da se u agilnom razvoju testiranje integrira kroz životni ciklus; kontinuirano testiranje softvera tokom njegovog razvoja.


U tradicionalnom modelu vodopada, testiranje je velik napor i ostavlja se pred kraj razvoja, dok je u agilnom testiranje malo, ali češće i događa se tokom cijelog razvoja.

Testiranje tokom razvoja takođe znači da je softver u razvojnom stanju tijekom cijelog razvoja, tako da se može isporučiti kad god je to prikladno.


U modelu Waterfall naučeni smo razmišljati u fazama, poput faze dizajna, faze razvoja i faze testiranja. Agilan razvoj nema zasebnu fazu testiranja kao takav. Programeri su mnogo više uključeni u testiranje, pišući automatizirane ponovljive jedinične testove kako bi provjerili svoj kod.



Učešće programera u testiranju

Pomoću automatiziranih jediničnih testova, testiranje se može obaviti kao dio izrade, osiguravajući da sve funkcije rade ispravno svaki put kada se izrađuje izrada. Uz solidnu osnovu dobrog pokrivanja jediničnim testom, programeri će se osjećati sigurnije i u refaktoriranje koda.

Testiranje na agilnom načinu znači i rano započinjanje. To znači da bi QA morao biti uključen odmah od faze dizajniranja, razumijevajući značajke i priče i započeti pripremu, pa čak i pisanje testova unaprijed.

Sljedeći važan aspekt je Test Automation (Automatska automatizacija) kako bi se testovi mogli kontinuirano izvoditi tokom razvoja proizvoda. Ovo nisu samo automatizirani testovi, već i API i UI automatizirani testovi.




Integrirani i višefunkcionalni timovi

Prijelaz na Agile je višefunkcionalna aktivnost projektnog tima. Ovaj zajednički napor nije ograničen na aktivnosti ispitivanja. Programeri bi trebali pomoći u testiranju okvira i stvaranju karakteristika, a poslovni analitičari bi trebali poboljšati priču.

Svaki član tima radi na priči dok se ne završi cijela priča, što znači da je razvijena i testirana. Dizajneri, programeri i testeri paralelno rade zajedno, tako da postižu zajednički cilj i svi bi trebali znati šta je potrebno da se stvari urade.

Nastup u timu glavna je ključna tačka prelaska sa vodopada na agilno testiranje. Kompanija se može odlučiti za prelazak na agilno testiranje, ali ljudi moraju podržati ovu promjenu da bi uspjeli.

U agilnom ne postoji testni tim.




Kvalitetni način razmišljanja, pristup cijelog tima

Težite prevenciji kvara, a ne otkrivanju kvara.

Uz rano učešće testera u projektu, oni mogu pomoći u identificiranju ključnih scenarija potrebnih za testiranje priče. Kriteriji prihvatanja često se pišu kao zajednički napor vlasnika proizvoda, programera i ispitivača - Tri Amigosa.

Ovo osigurava da sve ono što se gradi može biti testirano i razumljivo svim dionicima. Također, kako je više ljudi uključeno u definiranje kriterija prihvatljivosti i „Definicije gotovog“, greške se mogu ispraviti ranije i na kraju se pravi proizvod izgradi ispravno.

Svi su uključeni i odgovorni za kvalitetu proizvoda.




Manje dokumentacije, više suradnje

U Agile razvoju veći je naglasak na razgovoru i saradnji radi razjašnjavanja zahtjeva više od tradicionalnog pristupa specifikacijama i dokumentaciji.

Iako se zahtjevi mogu donekle razjasniti u agilnom razvoju, još uvijek je moguće da zahtjevi budu dvosmisleni i nepotpuni, a članovi tima da različito razumiju zahtjeve.

Pa šta ovo znači za agilnog testera? Zajednička briga testera koji prelaze na Agile razvoj je ta što ne znaju tačno za što testiraju. Nemaju detaljne specifikacije za testiranje, pa kako ih uopće mogu testirati?

Za početak testiranja ne trebate imati detaljnu dokumentaciju. Mnogo puta pristojni testeri mogu koristiti svoju prosudbu i zdrav razum za validaciju proizvoda. Znanje domene postaje presudno važno.


Ispitivači bi trebali biti sigurni da rade više na osnovu vlastitog znanja o tome kako dobro izgleda. To sigurno nije samo slučaj praćenja test skripte, osiguravajući da softver radi ono što piše u specifikaciji.