Michael Bolton dolazi na ChangeCon: “Testiranje nije provjera, već istraživanje”

U vremenima kada nastaje sve više proizvoda i usluga koje rade s našim privatnim i poslovnim podacima, vrijeme je i da se ti proizvodi i usluge dovedu pred sud – testera. Odgovornosti tvrtki koje ih razvijaju, danas su mnogo veće, ne samo u pitanju performansi nego i sigurnosti.

Na sreću, tvrtke danas mogu birati od nekolicine poznatih metoda testiranja, a meni je drago što imam priliku razgovarati i sa svjetskim stručnjakom u razvoju jedne od njih. Michael Bolton već 20 godina istražuje, mentorira i razvija nove načine i pristupe u svijetu testiranja, a uskoro će nam se pridružiti i u Zagrebu. Michael stiže na Change, softversku konferenciju usmjerenu enterprise rješenjima. Ususret otvaranju 20. listopada, i njegovoj radionici koja je hvaljena diljem svijeta (na koju se još stignete prijaviti!) donosim vam par testerskih mudrosti iz njegovog dugogodišnjeg iskustva.

Testiranje “nije provjeravanje radi li proizvod, već istraživanje o njemu”

Proizvodi nekada ne moraju ispasti onako kako smo ih zamislili i može se dogoditi da rade stvari koje ne želimo. Primjerice, i Google je nedavno imao problema s bugom zbog kojega su web stranice mogle znati točnu lokaciju korisnika Chromecasta i Google Smart Home zvučnika. Ipak, otkrivanje tih problema može biti izazovno iz nekoliko razloga, priča mi Michael:

Živimo u složenom, nestabilnom, tehnološkom i društvenom svijetu. Ono što se događa unutar računala uglavnom je nevidljivo. Različiti ljudi cijene različite stvari; značajka za jednu osobu može predstavljati problem nekome drugome. Može nam se učiniti da proizvod radi nešto divno, a da to zapravo ne radi, ili možda radi nešto gadno što ne možemo vidjeti. Uostalom, može raditi i nešto odlično bez da to uopće primijetimo.

Kao i sa svaki razvojem proizvoda, na takve stvari treba računati i znati se pripremiti za njih:

Ako želimo razvijati proizvode koji znače i koji ljudima donose neku vrijednost, moramo biti svjesni mogućnosti da nam se mogu dogoditi greške u tom pothvatu.

No, to ne znači da trebamo stvari uzeti zdravo za gotovo. Dapače, tvrtke koje pružaju usluge i razvijaju proizvode – kojima će se ljudi služiti, imaju obvezu učiniti sve u njihovoj moći da spriječe takve greške. Zato i postoje testeri. Oni kroz proces testiranja upoznaju novi proizvod. Upoznavanje je važno, jer kao i za bilo koju novu stvar (ili biće) – iako smo svjesni toga što smo radili u procesu razvoja, rijetko odmah znamo, crno-na-bijelo, i što smo dobili. Nije zato čudno da i najkompleksniji sustavi poput raketa, unatoč visokim troškovima, zahtijevaju pomno testiranje:

Mi testiramo kako bismo naučili o proizvodu. Provjeravamo ga zbog problema koje smo očekivali; istražujemo ga, eksperimentiramo s njim i istražujemo ga kako bismo otkrili probleme koje možda nismo očekivali – te da bi prepoznali vrijednost koja možda nije bila prepoznata dok smo ga razvijali. Poanta testiranja nije u pravljenju trilijun trivijalnih provjera i dokazivanja da proizvod funkcionira. U testiranju se zapravo radi o brzom učenju; učenju o proizvodu i učenju o tome kako testirati proizvod te kako kritički i skeptično razmišljati.

Kako Michael zaključuje, proizvod se testira kako bi se steklo iskustvo o njemu i da se iz tog iskustva uči:

To zahtijeva vještinu, ali nam pomaže i razvijati naše vještine.

Važno je znati: Tko pronalazi, a tko rješava problem?

Michael nas stoga upućuje na glavnu odliku testiranja i testera, a to je faktor istraživanja – za koje se treba pripremiti s mnogo znanja i iskustva. Ipak, upravo taj faktor rasvjetljuje zablude o tome što testeri mogu s otkrivenim, odnosno što ne mogu. Mnoge se tvrtke, odnosno njezini voditelji na pozicijama, znaju zavarati da će im testiranje riješiti probleme, a zapravo kada dođe red da oni delegiraju ta rješavanja – izostaje akcije. Podsjetio me na tu problematiku Michael, spominjući pouku iz 20-godišnjeg iskustva – dva najvažnija pitanja koja predlaže da testeri upute sebi i voditeljima razvoja.

Prvo, kako se svaki tester u procesu testiranja kontinuirano mora pitati ključno pitanje: Je li ovdje postoji problem?

Drugo, svaki se voditelj projekta mora zapitati kakvu aktivnost zahtijeva odnosno ne zahtijeva određeni problem: Je li nam ovo u redu?

Problemi koje identificiramo predstavljaju rizik: za vrijednost proizvoda osobama koje ga koriste; za kvalitetu našeg testiranja; za vremenski rok i uspješan završetak projekta; za učinkovit rad i zadovoljstvo tima. A na kraju i rizik za ciljeve, ugled i vrijednost čitavog poslovanja. Ponekad su testeri u stanju promijeniti stvari da se taj rizik eliminira, no većinu vremena nismo, tako da pitanje “Je li nam ovo u redu?” ide prema van, ljudima koji mogu promijeniti ono što nije u redu.

Ukratko, testeri ne vode projekt i oni ne odlučuju o tome hoće li nešto što je problem biti popravljeno. Ali pitajući se ova dva pitanja, i za testera, i za tim koji radi na proizvodu, bit će lakše raditi s fokusom i usmjeriti se na bitne stvari.

Obilje metoda, ali najvažniji su ljudi

Kako su s razvojem tehnologije softverske aplikacije postale sve složenije i isprepletene s velikim brojem različitih platformi i uređaja koji se trebaju usporedno testirati, važnije je nego ikad razraditi temeljitu metodologiju testiranja kako bi se osiguralo da su proizvodi/sustavi provjereni. Metode testiranja su se kroz godine razvijale prema različitim pristupima i načinima osiguranja da se određena aplikacija u potpunosti ispita. Tako danas imamo nekoliko poznatih metodologija koje obuhvaćaju sve: od testiranja pojedinih modula, integracijskog testiranja cijelog sustava do specijaliziranih oblika testiranja kao što su sigurnost i performanse.

Tvrtke imaju priliku birati iz palete modela: od testiranja značajki koje prati funkcionalnost novododanih značajki; regresijskog testiranja, koje prati funkcioniraju li nove promjene u softveru sa starijim temeljima; do Quality Assurance (QA) testiranja, koje, kako i ime govori, ulaže u kvalitetu pouzdanosti za korisnika, ali i tvrtkinog kredibiliteta.

Naravno, testiranja zahtijevaju mnogo resursa, a nekada je to teško uskladiti s očekivanjima nadređenih. Tako i Michael savjetuje svim testerima da budu dobri menadžeri svog vremena i truda, uz razumno balansiranje slobode, odgovornosti i mudrosti:

Testerima je također bitno i održati dobru kritičku distancu od mindseta ljudi koji rade na projektu, ali, naravno, ostati dovoljno blizak na društvenoj razini. Dobar način kako to ostvariti, za početak, je prepoznavanje, pregovaranje i zajednički angažman s klijentima i misijom testiranja. Kao testerima, naš je zadatak pomoći ljudima da postignu duboko razumijevanje proizvoda koji imaju, kako bi odlučili imaju li proizvod koji žele. Kada se obvežemo za taj zadatak i definiramo svoju predanost, važno je da naši klijenti budu svjesni svega što može kompromitirati naš rad.

U 2009. godini, Michael je počeo bilježiti razlike između provjere i testiranja. U jeziku njegove RST metode, provjera je proces rada i promatranja proizvoda, primjenjivanje pravila odlučivanja na ta promatranja, a zatim izvještavanje o ishodu tih pravila. To jest, platni ček se može pretvoriti u skriptirani proces koji može izvesti čovjek ili stroj. Ipak, dok briljiraju u provjeri, za testiranje, ili automatizam – strojevi nisu rješenje:

Primjerice, provjera pravopisa može biti automatizirana, ali uređivanje ne može. Trebate stručnog čovjeka da odluči je li stroj pogodio ono što je autor namjeravao reći. Kao što automatizirano provjeravanje pravopisa živi unutar uredničkog procesa, provjeravanje živi u testiranju. Neiskusno testiranje dovodi do površne, neispravne, i vjerojatno skupe provjere.

Kako radi Rapid Software Testing?

Kad smo kod skupog i površnog, Michael i njegov kolega, James Bach razvili su 2006. metodu Rapid Software Testing koju opisuju kao skup vještina, ali i mindset fokusiran na brži i jeftiniji način testiranja koji svejedno u cijelosti zadovoljava potrebe testiranja proizvoda. Obojica dolaze iz komercijalnog, masovnog tržišta softverskih tvrtki i imali su prilike naslušati se mišljenja ljudi o testiranju. Michael mi priča kako većina toga nije bila u skladu s njihovim iskustvima te su bili zabrinuti da koncept testiranja, početkom 2000., nije bio od pomoći i da bi čak i mogao škoditi razvoju:

Ljudi su opisivali testiranje u kontekstu demonstracije, potvrde, a ne kao istraživačke aktivnosti – cijeli pojam “istraživačkog testiranja” često je bio ismijavan, ako se uopće o njemu i govorilo. Mnogo je ljudi hvalilo besmislene načine mjerenja i vrednovanja testiranja. Testiranje se često tretiralo kao nepotrebna birokracija i papirologija, kao obično precrtavanje obavljenog na temelju definiranih procedura.

Promatrajući industriju, Michael i James su zaključili da ta prekomjerna formalnost dehumanizira i krade vrijeme, kako testerima, tako i poslovanju. Povrh svega toga, takav se stav ispostavio kao slabašan način pronalaženja bugova koji su važni. Svojom RST metodom htjeli su riješiti probleme koje su uočili. Jesu li uspjeli, pitala sam se. A Michaelu sam uputila i pitanje koliko je moguće da u istoj konstrukciji stoji brže, jeftinije – i kvalitetnije? Na što mi je odgovorio da je za početak bitno izbjeći nepotrebne i preuranjene formalizacije.

Konkretno, objašnjava kako je prije bila praksa da većina testera počinje testirati tako što čita specifikacije i ispisuje proceduralne testne slučajeve. Danas postoji moderniji pristup, ističe da mnogi testeri pregledavaju priče korisnika i pišu automatske provjere GUI-a. No, on smatra da je i to prilično ograničen način razmišljanja o testiranju:

Vjerujemo da je zaista važno upoznati se s proizvodom na sve načine – idealno bi bilo dok se dizajnira i oblikuje – prije nego što započne formalni postupak na papiru ili u kodu. To znači blisku suradnju s programerima i dizajnerima te zahtijeva ispitivanje i nijansiranje uvjeta, zagovaranje testabilnosti, a na kraju i pomoć razvojnim programerima da testiraju komponente koje čine proizvod.

Zaključno, testiranje cijelog proizvoda mnogo je brže i jednostavnije kada ste upoznali i testirali sve dijelove proizvoda kroz čitav proces razvoja. Ipak, netko nema mogućnosti niti pristup razvojnom procesu. Upravo je u tom slučaju faktor “istraživanja” ključan, jer, kako Michael navodi, tek se tada trebate dodatno potruditi da potpuno “uronite u proizvod i korisničko iskustvo”.

Bolton vas uči …

Mnogo više od Michaela možete čuti i naučiti na njegovoj trodnevnoj radionici koja se održava u sklopu ChangeCona. Tamo ćete imati priliku riješiti probleme u testiranju, kao i testirati prave softverske aplikacije, a potom ćete i razmijeniti mišljenja o tome što ste naučili iz tih zadataka. Michael će, s polaznicima, identificirati načine na koji ljudi prepoznaju bugove te kako razmišljaju o kvaliteti i riziku:

U praktičnim radionicama najviše se uči iz osobnog iskustva: ljudi upijaju ono što im je potrebno u tom trenutku savladati, kako u razgovorima, tako i u razmišljanju o prezentiranim primjerima.

Prijave za radionicu su još otvorene, a ne zaboravite pratiti i Change konferenciju na Facebooku, Twitteru i LinkedInu kako biste bili informirani o programu i predavačima. Ako već niste, ovdje nabavite svoju ulaznicu.