Blog

Provjera zrelosti testnog okruženja

Rijetko koja disciplina u razvoju softvera je toliko bitna, a da se tako olako ignorira i preskače. Zašto je važna provjera zrelosti testnog okruženja doznajte u ovom blogu.
Objavljeno 01.06.2015.

Zagonetka na početku:

  • svi se hvale da ga upražnjavaju
  • svi se hvale da ga imaju dovoljno
  • svi se hvale da su odlični u tome
  • svi se hvale da ne trebaju pomoćne alate
  • svi se hvale da je “primajuća” strana sretna i zadovoljna.

O čemu se radi? O testiranju, naravno. Rijetko koja disciplina u razvoju softvera je toliko bitna, a da se tako olako ignorira i preskače. Uzmimo, recimo, analizu poslovnih zahtjeva. Čisto sumnjam da će naručitelj posla samo reći: “E, cure i dečki, treba nam internet bankarstvo, dajte napravite nešto. Hvala.” S druge strane, prečesto čujem riječi: “E, cure i dečki, dajte malo stisnite i dovršite implementaciju pa da idemo dalje, testiranje ćemo napraviti kasnije. Hvala.” Zašto je tome tako? Nažalost, vrijednost koju testiranje isporučuje nije vidljiva na prvi pogled. Ako nešto radi ono što treba, radi zato što je dobro isprogramirano, a ne zato što je napisan test.

Čisto mehanički gledano, da poznajemo poslovnu domenu do najsitnijih detalja, da su zahtjevi potpuno jasni, da je razvojno okruženje idealno, da je izvedbena strana savršena i bez ijednog buga, testiranje ne bi ni bilo potrebno: sve bi radilo iz prve i baš ono što treba, za jednog ili deset tisuća korisnika istovremeno, 24/7/365. Ali svijet razvoja softvera nije takav. Niti je poslovna domena poznata, niti je infrastruktura bezgrešna. Fantastične stvari koje aplikacije rade kad su pod povećanim opterećenjem ne trebamo ni spominjati. I baš zato nam je potrebno testiranje, da u takav nepredvidljiv svijet uvedemo određenu količinu sigurnosti i predvidljivosti, da se ne čudimo kasnije kad se 2 (slovima: dva) korisnika istovremeno prijave u aplikaciju i time uzrokuju zaglavljivanje cijelog sustava jer se odjednom potrošila sva memorija. Priznajem da malo dramatiziram, iako je ova priča o dva korisnika, vjerovali ili ne, istinita (vidio svojim očima, op. a.). Svijest o potrebi za kvalitetnim i strukturiranim testiranjem raste iz godine u godinu, čemu smo i mi iz CROZ-a dijelom zaslužni, što kroz objavljivanje ovakvih članaka, što kroz pokrivanje testiranja na QED-u, a naravno i kroz prakticiranje testiranja na svojim projektima.

čengija 3

Pet razina zrelosti testiranja, kako ih postavlja TMMi Foundation

Zar nam stvarno treba testiranje?

Testiranje je, baš svi će se složiti, kompleksna disciplina koju možemo promatrati iz više kutova i koju možemo početi primjenjivati na različite načine. Ponekad nam je dovoljno odraditi završno korisničko testiranje i spremni smo za produkciju, no ponekad je nužno proći kroz sve razine, od unit testova na izvornom kodu do testiranja ponašanja cjelokupnog sustava u slučaju ispada dijela infrastrukture. Koji ćemo pristup imati jako ovisi o samom sustavu koji testiramo. Ako se radi o internoj aplikaciji za prijavu godišnjeg odmora, onda je možda dovoljno isprobati radi li sve na testnoj okolini i spremni smo za produkciju. Uostalom, ako nešto pođe krivo i zapis o mom godišnjem se izgubi, pa dobro, nema veze, prijavit ću ga ponovo. Ako se s druge strane radi o famoznom internet bankarstvu, onda vjerojatno želimo testirati i izvorni kod (razne izračune, provođenje transakcija i tako dalje) i sigurnost (recimo na OWASP Top 10), ali i ponašanje sustava u slučaju nedostupnosti nekog ključnog dijela infrastrukture. Tu je, naravno, i regresijsko testiranje – nakon puštanja u rad novih funkcionalnosti želimo znati rade li one stare kao i prije. Nije svako testiranje prikladno, ili bolje rečeno isplativo u svakoj situaciji, no prepoznavanje pravog trenutka je vještina koja se uči i brusi kroz vrijeme. Kako testiranje često predstavlja pa čak i 30–40 % ukupnog troška projekta, dobrom organizacijom i planiranjem aktivnosti ne samo da podižemo kvalitetu isporučenog softvera i sustava u cjelini nego i smanjujemo cijenu projekta.

Koliko je neka organizacija zrela u pogledu testiranja se može relativno brzo i jednostavno izmjeriti. Naime, softverska zajednica se kontinuirano trudi podići razinu kvalitete cjelokupnog proizvodnog procesa, tako da su de facto standardi za razvoj postavljeni u vodiču pod imenom CMMI, Capability Maturity Model Integration. Pandan CMMI-u u domeni testiranja definira TMMi Foundation, strukovna organizacija koja objedinjuje aktivnosti vezane uz testiranje, uključujući i standarde, referentni model i model zrelosti.

Testiranje softvera, metodologija

Snimka stanja i ocjena zrelosti testnog okruženja

Na temelju TMMi-a, ali i vlastitih iskustava smo razvili i svoju uslugu snimke stanja i ocjene zrelosti testnog okruženja (Testing Environment Maturity Assessment), kao jednodnevne radionice na kojoj se vrlo fokusirano i precizno određuje kvaliteta testiranja u proizvodnom procesu, i istovremeno prepoznaje prostor za napredak i usavršavanje.

Radionica se sastoji od pet dijelova, od kojih prva tri uključuju odabrane djelatnike organizacije u kojoj radimo analizu. Naime, kako bi se čim efikasnije iskoristilo vrijeme i čim prije došlo do rezultata, nužno je na jedno mjesto okupiti kompetentnu ekipu koja ima potrebna znanja o internim procesima definiranja i analiziranja poslovnih zahtjeva, razvoja, puštanja u rad i, naravno, testiranja i prihvaćanja isporuka.

U prvom dijelu se u tridesetak minuta postavlja zajednička “referentna točka” i pogled na idealni svijet testiranja. Koliko god bio nedostižan, idealni svijet predstavlja zajednički cilj koji mora biti jasan svima, bez obzira na razinu uključenosti u sami proces. Bitno je definirati što za odabranu organizaciju znači testiranje, prepoznati koji se rječnik koristi i kako je posloženo cjelokupno okruženje koje omogućava odvijanje povezanih aktivnosti. Zatim je važno osvijestiti potrebu za metodološkim pristupom testiranju, za strategijom i praksama, i na samom kraju jasno postaviti temelje za nastavak radionice.

Čengija 2

Drugi dio je najduži i predstavlja pravu radionicu, u tradicionalnom smislu. Ovdje je ključno vrlo aktivno sudjelovanje stručnjaka iz organizacije koju analiziramo. U svojoj osnovi, ideja je jasno i nedvosmisleno prepoznati kako izgleda cjelokupno testno okruženje, što je prema mišljenju “radne skupine” dobro i što treba zadržati, a što nije baš najbolje i treba popraviti. Bitno je razumjeti da nema točnih i netočnih odgovora već da želimo iskreno i pošteno sami sebi razjasniti kakvo nam je okruženje. Detaljno se ulazi u analizu primijenjene metodologije, u sami proces testiranja, organizaciju i okruženje. Na primjer, najčešće se pokaže da su ljudi vješti u testiranju svojih aplikacija, ali da nedostaje formalne naobrazbe, što kasnije negativno utječe na komunikaciju između timova, ili da se nedovoljno pažnje posvećuje automatizaciji, čime se izravno gubi vrijeme koje se moglo bolje iskoristiti na nekom drugom mjestu.

Treći dio je možda i najrazličitiji od uobičajenog pristupa, no jako je dobro prihvaćen gdje god smo ga isprobali. Radi se, naime, o kratkim i vrlo ciljanim, direktnim intervjuima sa svakim od polaznika radionice pojedinačno. Iznenađuje koliko se novih informacije može saznati u tih deset ili petnaest minuta razgovora, a pogotovo je zanimljivo da tijekom intervjua uglavnom isplivaju detalji kojima ljudi nisu zadovoljni, ali im je bilo teško ili neugodno reći u grupi. To je zapravo odlično, jer tek tako možemo steći potpunu sliku o procesu. Tokom četvrtog dijela radionice analiziramo prikupljene podatke i pripremamo izvještaj, kao i završnu prezentaciju koju predstavljamo dan poslije, na petom i posljednjem dijelu. Sve prikupljene informacije se vrednuju i slažu u matricu ovisnih vrijednosti, kako bi se na jednom mjestu moglo vidjeti trenutačno stanje okoline.

Što dalje?

Provjera zrelosti testnog okruženja će dati uvid u proces i organizaciju testiranja, ukazat će na kritične detalje koje treba popraviti kao i na one segmente koje treba zadržati i osnažiti. Rezultati snimke stanja, takozvani “nalazi”, doslovce se mogu iskoristiti kao popis zadataka koje treba ispuniti kako bi se unaprijedilo testiranje, kako u kratkom roku, recimo odmah za sljedeći projekt, tako i dugoročno, za sve buduće aktivnosti.

Tagovi:
Povratak