Postoje stvari u životu koje jednostavno ne mogu biti drugačije. Zbog njihove prirode, a ne zbog nedostatka obrazovanja, vještina, znanja, iskustva.
Pouzdati se u programera da će pisati kvalitetne testove softvera kojeg je napisao iz različitih perspektiva je kao povjeriti lisici čuvanje kokošinjca. Ne zato što je programer nesposoban, nedovoljno obrazovan, zato što nema širinu pogleda i slično, nego zbog prirode njegovog posla i onoga kako on gleda na svijet.
U svijetu sociologije, to može imati dva naziva, odnosno naziva se s dva termina koja su usko vezana. Jedan je nenamjerno ili perceptivno sljepilo koje ni na koji način nije povezano s oštećenjem vida, nego o tome na šta se obraća pažnja. Drugi je kognitivno zarobljavanje ili kognitivno tuneliranje, a što je podkategorija nenamjernog sljepila, kod kojeg je posmatrač previše fokusiran na jednu malu, usku stvar tako da ne može gotovo ni na koji način da uoči stvari okolo fokusa. Ovo se može popraviti raznim vježbama, ali i iskustvom. No, prema sprovedenim eksperimentima, nikada se ne može ukloniti u potpunosti. Čovjekov mozak jednostavno radi na takav način. Primjer je kod vožnje automobila. Početnik ne vidi gotovo ništa na ulici, osim ono malo asfalta ispred vozila, dok iskusan vozač uočava na hiljade detalja okolo. Početnik često puta biva i kažnjen jer nije uočio neki saobraćajni znak. Jednostavno ga nije vidio! To je nenamjerno, perceptivno sljepilo uz kognitivno zarobljavanje, jer je svjesno stavljen fokus samo i jedino na put ispred vozila.
Da bi se pomoglo programerima da pišu kvalitetne testove, a što će rezultirati kvalitetnim softverom neophodno ih je razumjeti. U nastavku je nekoliko osobina programera:
- Roditeljski odnos
Programeri imaju veoma izražen roditeljski odnos prema kôdu kojeg pišu. Za primjera radi, sportski trener može da ima vema često “brutalan” odnos spram našeg djeteta. Svjesni smo da je to za djetetovo dobro iz mnogo perspektiva, ali zbog našeg roditeljskog odnosa to nam teško pada. Majke češće djeluju emotivnije nego očevi, te je nerijedak slučaj da dođe do svađe ili tuče na treningu.
Drugi primjer je odnos nadređenog u vojsci tokom služenja vojnog roka. Vježbe, naredbe, kazne znaju biti veoma brutalne. Sreća je pa se tu u blizini ne nalaze roditelji ili bližnji, inače bi moglo doći do veoma nezgodnih obračuna.
- Fokus na pozitivnim stvarima
Programeri, ma koliko se trudili da razmišljaju o tzv. negativnim slučajevima, gotovo nikada (može se donekle postići jedino godinama i godinama iskustva) ne mogu biti dovoljno objektivni, pa da pišu tako “teške” i “brutalne” testove koji pokušavaju da sruše njihov kôd. Uglavnom se fokusiraju na pozitivnim slučajevima i za njih pišu razne scenarije.
- Pojednostavljenje komplikovanih i kompleksnih stvari
Također, zbog priroda posla kojim se bave (konstruktivni, a ne destruktivni), programeri veoma često pokušavaju da siplificiraju, tj. pojednostave veoma komplekse i komplikovane stvari. Naprave mnoštvo malih testova zaboravljajući da to sve posmatraju kao cjelinu koju treba “opteretiti” tokom testiranja.
- Nemogućnost hvatanja malih detalja u velikoj slici
Praveći fokus na cjelovitost aplikacije, šta ona treba da radi i šta joj je konačni cilj, gotovo uvijek programeri zaboravljaju sitne detalje. Detalje koje, ako bismo aplikaciju dali dvogodišnjaku da se malo igra s njom, šta bi joj napravio.
S druge strane, to je omiljena stvar profesionalnih testera. Oni jednostavno mogu da namirišu bug!
- Korisnička perspektiva
Veoma veliki broj programera, čak i onih iskusnih, ne može da se postavi u ulogu kranjeg korisnika i uvijek pokušava da ga ismijava i krivi, kako je nesposoban, neuk i slično. Veoma česta je pojava da programeri smatraju kako svi korisnici njihovog softvera moraju da budu tehnička lica, da veoma dobro poznaju rad na računaru ili drugom elektromskom uređaju. Da poznaju inžinjersku perspektivu, logiku i slično.
- Ponavljajuće “standardne” grešake (bugs)
Uz pomoć savremenih programskih okvira (frameworks) i programerskih alata (IDE) smanjena je mogućnost ponavljanja standardnih, ponavljajućih grešaka, kao što su razne provjere (validations).
Nakon što ih (programere) jednom razumijemo, treba im pomoći da budu bolji. U nastavku su neki od trikova ili načina kako to uraditi:
- Razgovarati s programerom prije pisanja kôda. Najbolje je imati veoma precizno objašnjene kriterije prihvatljivosti s dugačkom listom šta se ne želi. Pogledati članak Dobra priča.
- Razgovarati s programerom tokom pisanja kôda i skrenuti mu pažnju da ne zaboravi na negativne scenarije. Zapisati ih ako je moguće, kako ih ne bi zaboravio.
- Tokom pisanja scenarija za testiranje obavezno uključiti programera u recenziju (review), kako bi programer dobio novu perspektivu onoga što piše i predvidio scenarije koji mogu da sruše njegov kôd.
- Prilikom pisanja testova od strane programera, tzv. Unit Tests, raditi to u tzv. Pair programming. Nikada ne izostavljati Code Review, posebno za testove.
- Imati napisane Definicije gotovog i Definicije uspješnog. Time će se programer uvijek moći podsjetiti da li je zaboravio.
- Savjetovati programera i pomoći mu da se “vrati testovima” kada jednom počne da radi na novom zadatku. Vjerovatno će se sjetiti još nekih scenarija u međuvremenu. Tako naš mozak radi i treba mu omogućiti tu slobodu, a ne prisiljavati ga da se sjeti svega u jednom trenutku.
Da bismo bili bolji, ne samo programeri, nego ljudi uopšteno, dobro je da se upoznamo barem s osnovama kako naš, čovječiji, mozak radi.
0Hits: 0