Scrum bez plana testiranja je kao Proof of Concept (POC) na steroidima. Šta to znači? Hajde da istražimo.
Danas, mnogi uspešni projekti započinju sa POC fazom. To je manja procena ideje koja prvo verifikuje izabranu tehnologiju i funkcije. Potencijalni uticaj na krajnje korisnike se pažljivo procenjuje. Kada se dokaže vrednost investicije, kompletan tim se angažuje na razvoju i isporuci proizvoda sa svim planiranim funkcionalnostima.
Ovo je idealna situacija za Scrum tim. Tim može brzo razviti prototip, dodajući nove, značajne funkcionalnosti svakim sprintom. Krajnji korisnici mogu pratiti brz napredak u realnom vremenu. Ideja se razvija od nule u periodu od samo nekoliko sprintova. Takav pristup ostavlja snažan utisak, što je i cilj POC-a, ali postoji jedna velika mana: minimalno testiranje ili potpuno odsustvo istog. Sama pomisao na proces testiranja izgleda kao šala.
Testiranje nije omiljena aktivnost unutar Scrum tima. Razvoj bez testiranja je privlačna ideja, jer se čini da testovi usporavaju proces. Upravo to, implicitno, svaka test aktivnost i radi. Ko želi nepotrebno usporavanje kada je najvažnije impresionirati krajnjeg korisnika?
Problem nastaje kada tim nastavi sa istim pristupom i nakon završetka POC faze. To je ono što ja zovem „POC na steroidima“ – sistem koji raste po veličini i broju funkcija, ali se i dalje ponaša kao POC. Pretvara se da je kompletan proizvod, ali krije nedostatke i neistražene delove, čekajući ozbiljan pad.
Kako vreme prolazi, tim sve teže održava stabilna izdanja, jer rešavanje problema postaje sve složenije.
Evo nekoliko tehnika koje su se pokazale efikasnim u sličnim situacijama. Smatram ih najboljim praksama za implementaciju solidnog procesa testiranja, bez usporavanja napretka razvoja – jer to je ono što svi želimo kao Scrum tim.
Podelite „bol“
Kada se suočimo sa nepotrebnim teškoćama, najbolje je početi tako što ćemo „podeliti bol“.
Ovim mislim na kreiranje plana koji zahteva male dodatne aktivnosti od programera, koje će vremenom značajno doprineti zajedničkom cilju, postepeno, ali dosledno.
#1. Razvijajte unit testove za svaki novi deo koda
Ako uspete da ubedite vaš Scrum tim da u definiciju „Završeno“ (Definition of Done) doda razvoj unit testova za svaki novi kod kreiran tokom sprinta, to će biti veliko postignuće na duže staze.
Razlozi su očigledni:
To će naterati programere da razmišljaju o različitim nestandardnim putevima izvršavanja koda.
- Takvi unit testovi se mogu uključiti u automatizovane DevOps procese i izvršavati prilikom svakog postavljanja koda u razvojno ili testno okruženje. Takođe, metrike iz ovih procesa se lako mogu izvući i koristiti za prikazivanje procenta pokrivenosti koda test slučajevima direktno vezanim za izvorni kod krajnjim korisnicima.
Najvažnije je početi što pre. Što se kasnije počne sa razvojem unit testova, biće teže programerima da ih dodaju tokom sprinta.
- Biće potreban znatan napor da se razviju unit testovi za već postojeći kod. Neke delove koda je možda kreirao drugi programer i trenutnom programeru nije jasno kako bi taj kod trebalo da funkcioniše. U nekim slučajevima, dodavanje unit testa izmenjenom kodu može trajati duže od razvoja same izmene, što niko sigurno nije planirao tokom planiranja sprinta.
#2. Stvorite rutinu izvršavanja svih unit testova u razvojnom okruženju
Čak i pre kreiranja zahteva za spajanje novog koda u glavnu (Master) granu, standardna aktivnost bi trebalo da bude testiranje i funkcionalnog i unit test koda u razvojnom okruženju. Ovo osigurava:
- Da unit test kod zaista radi (na kraju krajeva, i on je kod koji mora biti verifikovan). Ovaj korak se često preskače. Pretpostavlja se da ako je unit test uključen u DevOps proces, da će se izvršiti i testirati negde, podrazumevano. Međutim, to samo prebacuje problem na viši nivo sprint aktivnosti, gde tim obično ima manje vremena i više stresa da završi svaku priču.
- Da programer testira osnovnu funkcionalnost novog funkcionalnog koda. Naravno, od ovog testa se ne očekuje potpuna verifikacija poslovne logike, ali barem će potvrditi da se kod ponaša kako je programer zamislio (zanemarujući, za sada, mogućnost da poslovna logika nije ispravno shvaćena tokom razvoja).
#3. Očekujte izvršavanje unit testova nakon spajanja koda u glavnu granu
Jedno je imati funkcionalan kod u lokalnoj grani (gde niko osim vlasnika grane ne razvija nove funkcije), a sasvim drugo je imati isti kod koji radi nakon spajanja u glavnu granu.
Glavna grana sadrži izmene drugih članova Scrum tima. Čak i ako su konflikti rešeni i sve izgleda u redu, kod nakon spajanja i rešavanja konflikata je i dalje neproveren i rizično je slati ga dalje bez provere da li sve radi kako treba.
Zato je efikasno ponovno izvršavanje unit testova – već urađenih u razvojnom okruženju – u okruženju koje je izgrađeno od verzije koda iz glavne grane.
Za programere, ovo bi mogao biti još jedan korak u procesu, ali nije veliki napor, jer u ovom slučaju ne treba ništa novo izmišljati – samo ponovo izvršiti ono što je već jednom urađeno.
Ovaj korak se može preskočiti u jednom slučaju:
- Ako su automatizovani unit testovi u DevOps procesu toliko sveobuhvatni da pokrivaju celo ručno testiranje.
Iako je postizanje takvog stanja moguće, retko sam to video u praksi. Za programere bi verovatno trebalo previše vremena da kreiraju tako detaljne automatizovane testove. Za vlasnika proizvoda bi možda bilo neprihvatljivo da tim toliko vremena posveti ovoj aktivnosti, jer bi to uticalo na broj isporučenih priča u sprintu.
Međutim, prioritet sadržaja sprinta nikada ne bi trebalo da bude izgovor za izbegavanje unit testova. Ako se ovo zanemari, tim će se vratiti u stanje u kojem kodu nedostaje pokrivenost unit testovima, a onda će biti prekasno da se to nadoknadi. (Opet, veći napor za dodavanje unit testova od same izmene koda.)
Zato preporučujem ponovno izvršavanje unit testova na verziji koda iz glavne grane bez oklevanja. To je mali napor u poređenju sa vrednošću koju pruža.
Ovim se vrši finalna provera spremnosti glavne grane za testiranje i objavljivanje. Pomaže u pronalaženju većine tehničkih grešaka, omogućavajući sledećoj fazi da se fokusira isključivo na verifikaciju poslovne funkcionalnosti.
Priprema za funkcionalno testiranje
Sve prethodne aktivnosti testiranja dovode do zaključka: glavni kod grane je bez tehničkih grešaka i funkcioniše bez problema za sve funkcionalne tokove.
Ovu fazu može lako da pokrije samo jedna osoba, koja ne mora ni da ima tehničko znanje.
U stvari, mnogo je bolje ako ovo obavlja neko ko nije povezan sa programerima, već neko ko razume kako krajnji korisnici očekuju da se kod ponaša. Postoje dve glavne aktivnosti koje treba završiti:
#1. Funkcionalno testiranje novih priča u sprintu
Svaki sprint bi idealno trebalo da donese novu funkcionalnost. Važno je osigurati da novi softver funkcioniše onako kako se očekuje, tako da krajnji korisnici budu zadovoljni. Tužno je kada se dugo očekivana funkcionalnost objavi, a onda se ispostavi da ne radi kako treba.
Zato je pravilno testiranje nove funkcionalnosti ključno. Dobra praksa je da se unapred prikupe važni test slučajevi od relevantnih strana (vlasnika proizvoda ili krajnjih korisnika) i da se napravi lista svih potrebnih test slučajeva za sadržaj u okviru sprinta.
Ovo može delovati komplikovano na prvi pogled, ali iz mog iskustva, sasvim je izvodljivo da to obavlja jedna osoba. Sprintovi su obično kratki (dve nedelje), tako da nikada nema previše novog sadržaja, jer sprint uključuje i tehničke zadatke, dokumentaciju, dizajn itd.
Test slučajevi se zatim izvršavaju radi verifikacije željene funkcionalnosti. Ako dođe do problema, obaveštava se relevantni programer (onaj koji je radio na tom delu koda) kako bi se problem brzo rešio.
Na ovaj način, programeri provode minimalno vreme na funkcionalnom testiranju i mogu se fokusirati na aktivnosti koje im se najviše dopadaju.
#2. Izvršavanje regresionih testova
Drugi deo funkcionalnog testiranja je osiguravanje da sve što je do sada funkcionisalo, i dalje funkcioniše i nakon sledećeg objavljivanja. Za to služe regresioni testovi.
Test slučajevi za regresione testove je najbolje redovno održavati i pregledavati pre svakog objavljivanja. Trebalo bi da budu jednostavni, a da pokriju većinu osnovne funkcionalnosti i važne tokove kroz ceo sistem.
Obično svaki sistem ima procese koji se dotiču mnogo različitih oblasti, i oni su najbolji kandidati za regresione testove.
U nekim slučajevima, regresioni testovi mogu pokriti i nove funkcije u sprintu, na primer, ako nova priča u sprintu menja određeni deo postojećeg toka.
U većini slučajeva, nije komplikovano izvršiti regresione testove zajedno sa testiranjem novih funkcija, posebno ako se to radi redovno pre svakog objavljivanja, a period objavljivanja nije suviše kratak.
Insistirajte na testovima osiguranja kvaliteta pre svakog objavljivanja
Test osiguranja kvaliteta (QA) je poslednji korak pre objavljivanja i često se preskače. Posebno ako se Scrum tim pritiska na isporuku novog sadržaja.
Čak će i poslovni korisnici reći da su više zainteresovani za nove funkcije, nego za očuvanje postojećih ili smanjenje grešaka. Ali, vremenom će ovo biti glavni razlog zbog kojeg će razvojni tim morati da uspori, a onda ni poslovni korisnici neće dobiti ono što žele.
QA test bi trebalo da sprovode ljudi izvan Scrum tima, idealno sami poslovni korisnici, u okruženju koje je što bliže budućoj proizvodnoj verziji. Alternativno, vlasnik proizvoda može zameniti krajnje korisnike.
U svakom slučaju, ovo bi trebalo da bude čist, funkcionalni test iz perspektive krajnjeg korisnika, bez uplitanja razvojnog Scrum tima. Ovo pruža poslednju priliku da se pogleda proizvod, način na koji ga niko iz Scrum tima nije očekivao, i ostavlja vreme za ispravke.
Može se otkriti da Scrum tim nije dobro razumeo očekivanja, i u tom slučaju, barem se može napraviti plan za dalju akciju, pre nego što se objavi proizvod. Bolje je otkriti grešku pre objavljivanja, nego nakon što se objavi.
Šta dalje?
Primenom ovih praksi u svakodnevnom Scrum radu možete dobiti stabilnije i predvidljivije objavljivanje sprintova. Nećete gubiti vreme na pripremu za objavljivanje ili terati tim da radi ono što ne voli ili ne zna kako efikasno da radi.
Ali, svakako ne morate tu stati.
Uključivanje testova performansi je bitna tema. Često se zanemaruju ili smatraju nepotrebnim. Međutim, kako se može očekivati da proizvodni sistem evoluira ako se performanse ne proveravaju redovno?
Sledeći nivo podrazumeva uvođenje automatizovanih testova.
Već sam pomenuo jednu grupu automatizovanih testova (unit testovi). Možete razviti kompletne „end-to-end“ regresione testove koji su potpuno automatizovani i koji se izvršavaju nakon svakog postavljanja u testno okruženje. Ovo bi još više oslobodilo razvojni tim, ali za razvoj i održavanje takvih testova potreban je poseban tim. To je stalan posao, jer kada god se promeni kod, neki automatizovani testovi mogu postati nevažeći, pa ih treba ažurirati. To je napor koji malo ko želi da plati, ali bi koristi za razvojni tim bile velike.
Ovo su teme koje su izvan opsega ovog članka. Pronalaženje pravog rasporeda i vremena za svaki tip testa – tako da možete to da uradite u okviru sprinta – je sledeći korak. O tome ćemo detaljnije drugi put!