Život bez test kolone
Krajslerovi radnici ispituju kvalitet zupčanika
Pre neki dan sam pitao “koliko je česta praksa da programer pošalje zadatak/tiket/stavku dalje testerima kad je gotov i onda mu ih oni vrate ako nešto ne valja?” U suštini, da li se i koliko ovakav pristup razvoju praktikuje:
Iz odgovora se može zaključiti da je ovaj pristup i dalje prilično rasprostranjen. Mi smo takav način rada napustili 2017. godine, pa sam hteo da proverim da li je postojao širi trend ili su načini rada kao naš manje zastupljeni.
Ukratko, mi (ActiveCollab) smo krajem 2017. test kolonu skroz izbacili. Tester koji je tada opsluživao tri razvojna tima se pridružio jednom od timova kao programer i niko više na njega nije gledao kao na testera. Ono sa čime smo zamenili test kolonu je prebacivanje diskusije o tome šta treba da se pravi “levo” u procesu, pre početka rada, uz obavezno pokazivanje urađenog.
Životni ciklus nove ActiveCollab mogućnost krene od prototipa koji dizajn spremi na osnovu potreba i želja korisnika. U par krugova product owner i dizajner dođu do predloga rešenja sa kojim idemo pred programere.
Probali smo da programere uključujemo ranije, ali smo tu imali pomešane rezultate - nekada su smatrali da su prerano uključeni, a nekada je to bilo na vreme. Sada se vodimo osećajem i iskustvom da vidimo kada je dobar trenutak da uključimo programere. Obično gledamo da prototip ne bude 100% gotov, već da je dovoljno dobar za uvodne razgovore sa razvojnim timovima.
Prvo dizajner prezentuje rešenje i potrebe, a onda ulazimo u dalju razradu i parčanje na niz konkretnih koraka. Svaki od tih koraka ima listu zahteva koje treba ispuniti da bi zadatak bio gotov. Te zahteve zapisujemo u formi budućeg testa, kao odgovor na pitanje: “Da je ovo gotovo, ovako bismo potvrdili da radi kako treba.”
Kada ovako definisan zadatak uđe u iteraciju, tim interno odluči kako će tačno tehnički da ga reši. Tokom rada su u kontaktu sa dizajnerom i product ownerom za rešavanje nedoumica i za probu. Gotove zadatke tim prezentuje ostatku firme jednom u dve nedelje i na tim sastancima bude ljudi iz svih delova firme - dizajn, product owner, marketing, podrška… Sugestije za unapređenje i uočeni problemi se ispravljaju odmah.
Ovo funkcioniše zato što se oslanja na par stvari koje smo kao organizacija prihvatili i na koje su se ljudi obavezali:
Razvojni timovi su odgovorni za kvalitet. U radu svakako testiraju ono što prave, dok na tome rade, što pisanjem automatskih testova, što ručnom proverom,
Odgovornosti razvojnih timova za kvalitet ima pozitivnu povratnu spregu. Što bolje se isplanira i uradi posao (obe stvari pod njihovom kontrolom), to će biti manja šansa da im se vrati na doradu. Na taj način su motivisani da traže temeljnost od dizajnera i product ownera, ali i od sebe samih,
Svi ljudi koji mogu da vrate posao programerima na dopravku su uključeni u razgovor gde se taj posao specifikuje pre nego što na njemu krene raditi. Dizajneri i product owner su obavezni, a podrška i marketing su često viđeni na tim sastancima.
ActiveCollab sistem isporuke je automatizovan, sa dosta acceptance, integracionih i unit testova. Svaki zelen mainline je vrlo brzo dostupan u produkciji za probu, kompletno integrisan sa pratećim servisima,
Sami koristimo svoj proizvod. Na ovaj način je cela firma jedan nezvaničan tim testera. Čak i kada se desi da se problemi provuku do produkcije, velika je šansa da ćemo ih uhvatiti pre korisnika,
Svesni smo da se kvalitet ugrađuje u proizvod u procesu dizajna i razvoja, ne kao inspekcijski korak na kraju. Ako kvalitet mora da čeka taj trenutak, tu smo već zakasnili i izložili se dodatnom poslu, komplikacijama i trošku.
Ni jedan proces nije idealan za sve situacije. Postoji niz slučajeva kada je testiranje (inspekcija) zahtevan korak posle razvoja, npr. u slučaju proizvoda koji nude mali prostor za grešku, oblasti koje su visoko regulisane, firmi koje zbog uvedenih standarda moraju imati taj korak itd.
Sa tim na umu otvoreno stojim iza tvrdanje da velikom broju timova i organizacija zasebna kolona za testiranje nije potrebna. Proces bi trebao biti takav da se kvalitetom bavimo u ranijim koracima, u fazi dizajna i razvoja. Nije za svakog, ovakav proces zahteva dosta sinhronog rada, razgovora i discipline, ali je moguć i iz “rovova” mogu da potvrdim da daje dobre rezultate.
Kako se pravi softver i teži što kvalitetnijem rešenju je mozaik napravlje od niza kockica. Neke od praksi sam sam već pokrio u leksikonu: Budući test, Hodajući kostur i Parčanje, a gledaću da ih vremenom bude još.
