Budući test je način da se definišu zadaci za razvojne timove pre nego što na njima počne rad, sa ciljem da se posao uradi brže.
Neretko je proces razvoja tako uređen da programeri uzmu neki posao da urade, pa ga prebace testerima kada smatraju da je gotov. Testeri provere da li urađeno zadovoljava specifikaciju i potrebe . Ukoliko se nađu neki propusti ili defekti, posao se vraća nazad programerima na ispravku i tako u krug, dok se svi zahevi ne zadovolje. Često se desi da programeri uzmu da rade sledeću stvar sa svoje liste dok im se sa testa ne vrati ili potvrdan odgovor da je sve u redu ili zahtev da se vrate i isprave nešto.
Ovakav proces nastaje zbog odvajanja testiranja od razvoja. Mnogi timovi smatraju da programeri ne bi trebalo da troše vreme na testiranje i da je bolje da taj posao rade ljudi kojima je testiranje specijalnost.
Procesni problemi koji nastaju ovim odvajanje mogu biti razni, od zagušenja na strani testera kada ima prevelik broj zahteva za proveru, preko čekanja na rezultate testa, do gubitka fokusa u radu na novom zadatku zato što se stari vratio sa testa sa zahtevima za ispravke.
Jedan od najčešćih razloga zašto se zadaci vraćaju na ispravku je nedovoljno razumevanje i neprecizna specifikacija zadatka, sa pratećim posledicama. Kada programeri dobiju neprecizno definisan zadatak ili ga ne razumeju kao što ga vide dizajner, tester, vođa projekta, klijent i ostali, oni će ga uraditi, poslati dalje, ali s velikom verovatnoćom da im se isti vrati. Tada se posao svede na prosto “prebacivanje preko zida” uz smanjeno angažovanje oko kvaliteta i ispravnosti toga što se radi. “Neka ide, vratiće mi ga ako ne valja”.
Zadatak iz test kolone se vraća na doradu
Budući test je tehnika gde se trudimo da imamo što bolje zajedničko razumevanje predstojećeg zadatka i zahteva koje treba da ispunimo pre nego što počnemo da ga pravimo. Umesto da se razgovor između programera i testera vodi tek kada je posao gotov, tako što se dobacuju sa zadatkom napred-nazad, oni razgovor vode pre nego što isti dođe na realizaciju. Potrebno je da se na jednom mestu sastanu razvojni tim, testeri, vođa projekta, dizajneri i svi drugi koji imaju pravo da vrate zadatak nazad na doradu i kroz razgovor dolaze do zapisanog odgovora na prosto pitanje: “Da je ovo danas gotovo, ovako bih testirao da li radi kako treba.”
U pitanju je prost role-play gde se prebacujemo u zamišljenu budućnost gde je zadatak gotov, a na nama je da testiramo da li sve radi kako treba. Deluje trivijalno, ali ovakav razgovor i rezultat istog imaju niz prednosti:
Svi se stavljaju u poziciju testera, ne samo testeri . Komentari programera, dizajnera, vođa projekta itd ulaze u listu zahteva,
Okvir zadatka se preciznije definiše, tako da programeri ne hodaju kroz minsko polje nedefinisanih zahteva,
Bolje se pretresu i popišu granični slučajevi, obrada grešaka, validacije i slične situacije gde softver treba da bude defanzivan,
Pošto u razgovoru učestvuju svi koji mogu urađeno da vrate nazad, svi dobiju šire i dublje razumevanje onoga što treba da se uradi - obim posla, granični slučajevi, tehnički izazovi itd,
Ovaj razgovor je idealno mesto da se prođe kroz listu stvari koje učesnicima često promaknu. Npr, nama često promakne da popričamo kako neka stvar izgleda na dark temi, pa se onda tome moramo vraćati posle.
Rezultat ove diskusije je detaljna specifikacija zahteva sa uslovima koje rešenje treba da zadovolji da bi se posao smatrao gotovim. Ova lista je stalan podsetnik šta treba da se uradi i tim uvek može da joj se vrati i proveri da li je pokriveno sve što je dogvoreno.
Primer
U trenutku pisanja ovog članka ActiveCollab razvojni timovi ovakav način pripreme zadataka koriste već 7 godina. Tokom tog vremena smo zapisali, razradili i napravili na hiljade zadataka. Format zapisa se vrlo malo menjao, jer smo se držali suštine.
Primer desno je sveže pretresena i procenjena stavka. 👉
Skrenuo bih pažnju na dve stvari. Iako je način na koji su zahtevi zapisani bitan, podjednako je bitno kako je do njih došlo. Ovaj zadatak nije samo delegiran timu, već su zajedno na definisanju radili programeri, dizajner i product owner (nemamo testere kao zasebnu rolu). Zapis je došao kao rezultat diskusije. Tim se složio da je ovo potreban i dovoljan nivo detalja da bi se ovaj zadatak mogao raditi.
Sam zadatak je razrađivan sa timom koji godinama radi na proizvodi. Sa ljudima koji dobro poznaju proizvod i način rada sa vrlo malo zapisanih reči postižemo dobro razumevanje onoga što treba da se uradi.
Imamo i duže i kraće zadatke od ovoga, sa dodatnim beleškama, nizovima primera, zapisanim nedoumicama koje treba ispitati itd. Ovo desno je dosta blizu tipičnog zadatka kada nam je jasno i šta treba da napravimo i kako ćemo to da uradimo.
Preporuke
Zapisujte stvari kao da su se već desile. Zahteve zapisujte kao da se budućnost gde je zadatak gotov već desila. Opcija postoji, korisnik može da uradi ovo, ako klikne ovde desiće se ono, u slučaju greške prikazuje se takva i takva poruka.
Držite se opisa posla iz korisničke perspektive. Korisnike ne zanimaju kontroleri, adapteri, JSON i REST, već opcije koje mogu da koriste, dijalozi koji ih pitaju za dalje korake, promene koje njihove akcije prave nad podacima. Tehničke detalje slobodno zapišite, samo to uradite u drugom bloku opisa zadataka, ne među zahtevima.
Trudite se da zahtevi budu kratki i jasni. Sažetost pomaže da se zahtevi brže i lakše čitaju, pa je lakše vratiti im se. Ovde pomaže prethodna preporuka. Zapišite kako nešto radi, iz korisničke perspektive. Razlozi zašto pravimo to što pravimo, tehnička razrada i slično su korisni, ali je bolje držati ih odvojene od zahteva u opisu zadatka.
Razbijajte zahteve na liste i podliste. Ukoliko se više zahteva odnosi na jednu stvar, grupišite povezane stvari kao podlistu ispod osnovnog zahteva. Dobra praksa je da slučajeve i primere koji su nabrojivi grupišete kao podlistu. Dva nivoa listi su u redu. Tri mogu da prođu u izuzetnim slučajevima, ali nategnuto. Četvrti nivo je gotovo siguran znak da zadatak treba da usitnite.
Izbegavajte prevelike zadatke. Ovo je opšta preporuka, a lista zahteva može da pomogne da vidite da je obim posla prevelik. Zadaci koji imaju 10 i više zahteva su preobimni i trebalo bi da se usitniti.
Prilagodite detaljnost zapisa iskustvu tima. Iako se trudimo da pravimo niz manjih zadataka, sa kratkim i jasnim zahtevima, kod manje iskusnih timova možemo napraviti izuzetak i zapisivati dosta više detalja. To je privremena praksa, u službi rasta tima, sa ciljem da jednog dana pređemo na sažetiji zapis.
Neka više ljudi ponovi zahteve pre nego što pređete na sledeći zadatak. Možda deluje kao nepotreban korak, ali dobro je da neko od programera ponovi zahteve koji su zapisani. Ne bi trebalo samo da se pročita zapisano, već da osoba ponovi zahteve svojim rečima, kako ih je razumela. Ovo je trenutka kada često isplivaju neka dodatna pitanja, može da se primeti da se nismo razumeli oko detalja itd. Sve to vodi ka bolje definisanim zahtevima na kraju.
U redu da je da se neke stvari previde. Nije lako predvideti sve slučajeve koje treba sa pokrijemo. Moguće je da se neke stvari potkradu i da saznamo za njih tek kads razvoj krene, a u nekim slučajevima tokom prezentovanja ili čak i u produkciji. Napravite novi zadatak za dopravku i popričajte da vidite kako se problem provukao i možete li sličan problem da uhvatite ranije sledeći put.
Princip je isti čak i kada nema testera u procesa. U tom slučaju članovi mogu postaviti blago izmeđenjeno pitanje: "Da je ovog gotovo i da smo mi testeri, ovako bismo probali da znamo radi li kako treba.” Ne postoji razlog zašto programer ne bi mogao da testira softver. Svi imaju sposobnost da razumeju i probaju ono što su napravili.
Zaključak
Testiranje i kvalitet su izuzetno obimne teme, kojima se pristupa na niz načina. Baš zbog te složenosti i različitih pristupa nije lako predstaviti jednu konkretnu praksu, bez da se potegne niz pitanja i da se podignu obrve tu i tamo. Svako ko je došao dovde u čitanju ovog članka (hvala!) na budući test najverovatnije gleda iz perspektive svojih trenutnih procesa i iskustva i vidi niz razloga zašto ova praksa kod njih može ili ne može da se primeni.
Sa svim tim na umu, voleo bih da ponovo bacimo pogled na ovu praksu u svom osnovnom obliku. U pitanju je prebacivanje razgovora o tome kako ćemo nešto testirati priča pre nego što se to napravi i da to bude otvoren razgovor imenu svih uključenih strana. Rezultat jeste nekakva lista zahteva u poprilično slobodnom formatu, ali ono što praksu čini korisnom nije samo rezultat, već način do kog se do istog dolazi.
Budući test je deo slagalice koji može da se iskoristi za bolju organizaciju razvoja. Sam po sebi ne može puno da uradi ako drugi elementi nisu na mestu.
Programeri treba da budu fokusirani na razvoj kvalitetnog softvera i da znaju da je kvalitet pre svega njihova odgovornost, ne nešto što će pokriti korak iza njih. Testeri, dizajneri, vođe projekta i ostali treba da razumeju da razgovor o nečemu što tek treba da se napravi može biti od velike koristi i odvoje vreme za isti. Zapisivanje, ponavljanje i diskutovanje treba da se ponavljaju dok ne postanu prirodna stvar. Čak i uz sve to, desiće se situacije kada će se neke stvari prevideti, uz svu dobru volju. Te situacije ne treba uzimati kao opravdanje da se od same prakse odustane, već kao prilike za učenje kako da nam se slične stvari ne potkradu sledeći put.
Priču o budućem testu objavljujem sada, kao usamljen deo slagalice, uz nadu da ću s vremenom imati prilike da obradim i druge teme koje će pružiti širu i smisleniju sliku.