Prijelaz sa slapa na agilno testiranje

Kada se tvrtka odluči prijeći s vodopada na agilno testiranje, na koja su najvažnija područja treba usredotočiti se za učinkovito agilno testiranje?

Kako se testiranje na agilnoj osnovi uspoređuje s testiranjem modela Waterfall? Koji su skup aktivnosti važni da bi testeri mogli znati i raditi?

Testiranje kroz razvoj

Prvo što treba shvatiti jest da se u agilnom razvoju testiranje integrira tijekom cijelog životnog ciklusa; kontinuirano testirajući softver tijekom njegovog razvoja.

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

Testiranje tijekom razvoja također 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. Agilni razvoj nema zasebnu fazu ispitivanja kao takvu. Programeri su puno više uključeni u testiranje, pišući automatizirane ponovljive jedinične testove kako bi provjerili svoj kôd.



Sudjelovanje programera u testiranju

Pomoću automatiziranih jediničnih testova testiranje se može provesti kao dio izrade, osiguravajući da sve značajke 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 već u fazi dizajniranja, razumijevajući značajke i priče te započeti pripremu, pa čak i pisanje testova unaprijed.

Sljedeći važan aspekt je automatizacija ispitivanja koja omogućuje kontinuirano provođenje testova tijekom 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 značajki, a poslovni analitičari u pročišćavanju priče.

Svaki član tima radi na priči dok cijela priča ne bude gotova, što znači da je razvijena i testirana. Dizajneri, programeri i ispitivači paralelno rade zajedno pa postižu zajednički cilj i svi bi trebali znati što je potrebno da bi se stvari učinile.

Nastup u timu glavna je ključna točka prelaska s vodopada na agilno testiranje. Tvrtka se može odlučiti za promjenjivo 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 sudjelovanje testera u projektu, oni mogu pomoći u identificiranju ključnih scenarija potrebnih za testiranje priče. Kriteriji prihvaćanja često se pišu kao zajednički napor vlasnika proizvoda, programera i ispitivača - Tri Amigosa.

To osigurava da sve zainteresirane strane mogu testirati i razumjeti sve što se gradi. Također, kako je više ljudi uključeno u definiranje kriterija prihvaćanja i 'Definicije gotovog', pogreš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 suradnji radi pojašnjenja 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 što to znači za agilnog testera? Zajednička briga testera koji prelaze na Agile razvoj je ta da ne znaju točno za što testiraju. Nemaju detaljne specifikacije za testiranje, pa kako ih uopće mogu testirati?

Da biste započeli s testiranjem, ne morate imati detaljnu dokumentaciju. Često pristojni testeri mogu upotrijebiti svoju prosudbu i zdrav razum kako bi provjerili valjanost proizvoda. Znanje domene postaje presudno važno.

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