123 Street Avenue, City Town, 99999

(123) 555-6789

email@address.com

 

You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.

Vikot's river of random thoughts

Razvoj softvera bez bugova, Quality Assurance da ili ne?

Viktor Marohnic

Ako ste ikadA radili ili naručivali projekte od različitih programerskih timova onda ste vjerovatno primjetili i razlike u kvaliteti isporučenog projekta. Ponekad ste vjerovatno bili i frustrirani činjenicom da vam developer isporuči nešto što ima očite greške već kod prve upotrebe i to ne samo funkcionalne greške, nego se program jednostavno sruši prilikom korištenja u vama najnormalnijem scenariju. Pitate se kako je moguće da netko isporuči takav komad softwarea ili koda i ne ostane bez posla.
Ovo gore navedeno je nešto s čime se svi u softwerskoj industriji susreću svakodnevno i pokušavaju riješiti na razne načine. Od uvođenja Quality Assurance (QA) timova, do raznih metodologija razvoja projekata, pisanja automatiziranih testova, raznih programskih jezika koji navodno smanjuju greške kod pisanja koda itd, itd. Sve je to u redu, ali čak i nakon što smo sve to napravili opet smo završili sa očitim greškama u produkciji.
Ono čime se ja često volim hvaliti, je da sam u svoje vrijeme dok sam programirao, te radio razne aplikacije, isporučivao projekte bez grešaka. Moj je kod, jednom kad je bio isporučen, klijentu radio točno to što je bilo zadano i nije se rušio. Naravno, to je malo idealizirano, bilo je tu i tamo propusta, ali sigurno mogu tvrditi da je moj kod u često slučajeva radio prilično pouzdano. Ono što je mene uvijek frustriralo je zašto je to tako teško postići i unutar većih timova kada je veći broj developera uključen. Dakle, probali smo kao što rekoh sve živo i neživo, a jedna od stvari na koje smo najviše bili ponosni je bio naš Quality Assurance tim koji je osiguravao da sve ono što izađe ispod developerskih prstića prođe detaljno testiranje prije nego se isporuči klijentu.


No međutim, nedavno smo se u ShoutEm-u odlučili smo za prilično radikalan zaokret.
 

Prije nego objasnim što smo napravili, ući ću malo u psihologiju developera. Dakle vrlo često mi developeri patimo od slijedećih sindroma:

  • Ne zanima nas domena za koju se radi software. Developer je geek, zanimaju ga programski jezici, razvojni alati, gadgeti, a kad si fokusiran na takve stvari, teško se izvući iz tog konteksta i sagledati stvari iz perspektive korisnika koji samo želi kupiti deterđent ili svinjski but kroz vašu aplikaciju. 
  • Trošiti vrijeme na testiranje softwarea smatramo ne produktivnim. Umjesto da testiramo radije uživamo pisajući još koda. Puno bolje utrošeno vrijeme nego prolaziti po stoti put kroz isti use case i ispravljati greške.
  • Svjesno isporučujemo kod za koji znamo da sadrži moguće greške. Kao prvo, ta mala promjena u kodu sigurno nije mogla ništa bitno skršiti, ipak mi znamo što radimo, godine iskustva su tu. Kao drugo, postoji QA koji će provjeriti sve iza nas, isporučiti ćemo kod koji smo napisali i čekati da nam se klijent ili QA tim javi kroz koji dan i prijavi greške.

E sad, kako je moguće da sam ja dok sam se bavio samo programiranjem i to mi je bio primarni posao, ipak isporučivao kod koji nije sadržavao očite greške? Što je to što me tjeralo da svaki put kad promijenim i jednu liniju koda, testiram deset mogućih use caseova sve dok nisam siguran da stvar radi? Što me je tjeralo da nakon odrađenih osam sati ostanem još osam sati za stolom i testiram i ispravljam greške iza sebe, sve dok stvar ne radi kako treba? Kako je moguće da ja, koji nisam bio najbolji developer među kolegama, na kraju ipak isporučim za klasu kvalitetniju aplikaciju?

Odgovor je. Bilo me je strah osramotiti se pred klijentom, odnosno zbog tog direktnog kontakta sa klijentom sam imao jako dobru motivaciju za isporučivanje koda bez grešaka.

Uvijek mi je bilo iznimno neugodno kad bi mi klijent prijavio bug ili nedaj bože preda mnom pokrenuo aplikaciju i ona bi se srušila. Osjećao bih se u tom trenutku kao da se srozava moj ugled u klijentovim očima. Da bih izbjegao takav događaj radio sam puno više, ostajao puno duže u uredu i testirao, testirao i testirao kod iza sebe, sve dok nisam mogao mirno otići kući i opustiti se. Direktan kontakt sa klijentom mi je stvarao neki višak odgovornosti i to me tjeralo da budem puno detaljniji u testiranju svog koda. I tako sam došao na ideje kako stvoriti taj višak odgovornosti i kod našeg development tima.
Vjerujem da je za isporuku koda bez bugova najvažnija prava motivacija, a sve ostalo su tehnikalije. Procesi, razvojni alati, kod standardi itd, itd, to sve dolazi samo od sebe ako postoji volja.


I tako smo mi ukinuli Quality Assurance tim.


Nismo mi jedini, saznali smo to nakon malo Googleanja. Dapače, postoje tvrtke koje nemaju QA timove i isporučuju odličan software.
 

Koja je poanta? Zašto bi netko izbacio QA iz procesa?
 

Dakle, prije ovoga, oni koji se trenutno sramote sa bugovima i greškama koje izađu u produkciju u ShoutEm timu su bili manageri poput mene, ljudi u prodaji, a najviše od svega ljudi u supportu. Developeri su na neki način bili odsječeni od te prve linije obrane.
Također znajući da postoji QA, developer ima manje motivacije da testira kod iza sebe malo detaljnije, oslanjajući se na QA tim da pronađe i prijavi sve bugove. Ne moram ni govoriti koliko to usporava cijeli razvojni proces. U trenutku kad developer “završi” sa svojim projektom i preda ga QA-u, on kreće raditi nešto novo. Za dan, dva ili tri stižu bugovi i on prekida trenutni task, te se vraća na stari… I tako u krug.
U slučaju gdje nema QA, developer je puno direktnije odgovoran za sve što izađe u produkciju i samim time “strah od sramote” pred klijentima i kolegama je puno veći, a time je i motivacija da se posao napravi kako treba, puno veća.
Bilo bi pretjerano reći da Quality Assurance proizvodi više štete nego koristi, ali nije ni daleko od istine. Nije kod nas baš sve tako crno-bijelo, u našem trenutnom eksperimentu mi i dalje imamo testni tim, ali on se prevenstveno bavi istraživačkim testiranjem otkrivajući teže uočljive probleme i bugove nastale regresijom, a u svakodnevnom development procesu se pokušavamo ponašati kao da QA ne postoji.
Trenutno je proces takav da je development tim sam odgovoran za testiranje koda koji produciraju. Nakon što su provjerili sve, rade i deploy na live server, te dodatno, velik napor ulažemo u automatiziranje testova i Continuous Integration pokušavajući manualni rad kako developera, tako i testera na samom testiranju, što više usmjeriti na kreativnost, a što manje na repetitivnost. Osim toga, jedno vrijeme su svi developeri imali obavezu provesti jedan dan svaka tri tjedna na supportu. Tu su se iz prve ruke susreli sa frustracijama nekih od naših korisnika i uvidjeli koliko još imamo prostora za poboljšanja.
Kao što rekoh nismo jedini koji imaju ovakav pristup. Dapače, postoje još neke tehnike gdje se tzv “stup sramote” još više naglašava, dodjeljuju se bedževi raznih boja ovisno o tome koju razinu štete je deploy napravio. Npr., žuti bedž je za neki user story koji nije toliko bitan, narančasti za bug koji je skršio jedan od češće korištenih featurea ili crveni za bug koji je srušio cijelu aplikaciju. Itd..
Mi za sad još nismo uveli tako nešto. Tim je dovoljno mali i zna se tko je napravio nered i to je za sada dovoljno. Sve ovo gore smo uveli nekako na brzinu, ali prvi rezultati mi se jako sviđaju, te mislim da imamo još puno prostora za poboljšanja.

 

Eto, to je to od mene na ovu temu. Nadam se da će nekome biti zanimljivo naše iskustvo. Volio bih čuti kakva su vaša iskustva, kako se vi borite protiv bugova u produkciji i za što mislite da je najučinkovitije.