Kako znati da je kôd koji smo napisali ili koji je napisao neki drugi programer upravo odraz one funkcionalosti koju želimo ili koju želi krajnji korisnik?

Zbog nepravilnog planiranja, a što nekada zna biti greška i samih programera, jer se ne bore dovoljno za svoj status i to da budu profesionalci, veoma često timovi ili cijele firme izbjegavaju pisanje testova za testiranje kôda njihovog softvera. Odlučuju se samo za to da imaju QA (Skraćeno od Quality Assurance, a što u osnovi predstavlja inžinjera koji testira softver i brine se o kvaliteti u skladu s zahtjevima prema dokumentaciji) tim i nadaju se da će to biti dovoljno. Nažalost, prakse pokazuju da nekada ne postoji čak ni to!

Nerijetka je praksa u malim firmama (do 10–20 osoba) da programeri čak ne testiraju kôd/komad softvera od kolega kada je u fazi testiranja na “pokretnoj traci”, nego to rade sami sebi! Ovakve prakse u osnovi ne bi smjele postojati nikako i takve firme/timovi bi trebalo da budu postavljeni na stub srama! Neke firme/timovi praktikuju scrum organizaciju takvu da u timu nema QA uloge uopšte, nego da QA “glumi” bilo koji drugi programer, kada jednom vidi da je neki zadatak postavljen u fazu za testiranje. To je gotovo pa osnova svakog scrum tima. Da li je to u praksi dobro ili nije, posebna je priča.

Ako je napisan softver naša desna ruka, onda su testovi za taj softver zasigurno lijeva.

Naravno, osoba može da funkcioniše bez jedne ruke i da bude veoma uspješna, ali izuzetci nikada nisu bili niti će biti pravilo.

Za one koji žele biti profesionalci i plaćeni kao profesionalci donosimo nekoliko informacija u nastavku.

Testovi programera i testovi testera

Da ne bude zabune, valja nam prije svega spomenuti da postoje testovi koje su obavezni pisati programeri, ali i testovi koje pišu testeri. Gdje je granica između toga, šta koji rade, nekada zna biti veoma siva zona. Posebno zbog izraženog “prisiljavanja” na primjeru scrum timova u kojima ne postoji zvanična uloga — tester.

Najbolje je da to možda pojasnimo kroz primjere:

Primjer #1

Kada programer piše kôd, on bi to trebao da radi u veoma bliskoj zavisnosti s zadatkom koji je dobio iz mnogo razloga koje ovdje nećemo posebno spominjati. No, za one koji žele znati kako se ispravno zadatak piše, neka “baci oko” na članak: Dobra priča.

Da bi ispunio kriterije koji se zahtijevaju od komada softvera koji će dostaviti, programer mora znati i biti u mogućnosti napisati odgovarajuće testove da provjeri, da li je ono što je napisao u skladu s kriterijima. Također, kod naknadnih promjena softvera, bilo kakva promjena će direktno biti odražena na testove, tako da će biti u stanju veoma brzo i jednostavno ustanoviti da li je komad ili cijeli softver negdje prekinut.

Ti testovi mogu biti:

• Jedinični (Unit tests) — to su testovi s kojima se testira jedna jedinica. Jedinica ovdje nije broj, nego više mala skupina nečega, kao u vojsci kada se ima neka specijalna jedinica, ili u policijskim službama, jedinica za borbu protiv nečega. O veličinama i oblicima jedinica postoje ogromne rasprave unutar programerskih zajednica.
• Funkcionalni (Functional tests) — također ogromna rasprava unutar programerske zajednice da li ovaj termin podrazumijeva testiranje funkcije (metode u kôdu, posmatrajući je kao black box. Tj. pošaljem joj to i to, očekujem da će vratiti to to, a onda Unit tests se bavi onim što je unutar te funkcije), ili pak podrazumijeva testiranje funkcionalnosti, a što je svakako mnogo širi pojam. Kada govorimo o funkcionalnosti, to u programerskom smislu može biti nekoliko klasa, funkcija, struktura, …
• Integracioni (Integration tests) — možda je bolje da ih nazovemo interakcijski, ali onda bi stvorilo još više problema vjerovatno. Integracioni testovi su oni koji testiraju kako komad softvera koji želimo dostaviti radi u saradnji-interakciji s drugim softverima. Odnosno kako rade u integracionom, cjelovitom okviru, pa otuda naziv integracioni. Tj. sada se testira kako komad softvera (ili pak cijeli) radi s vanjskim servisom, za primjera radi, bazom podataka.

Na internetu (kao i u nekoj literaturi) može se naći još vrsta testova, neki ovu listu proširuju itekako, neki dodaju još jednu ili dvije vrste. Kako god, tri naprijed navedena su sasavim dovoljna za opis onoga što programer treba da uradi (osim, kada, ….)

Primjer #2

Programer je napisao kôd, testirao ga i siguran je da je ispunio zahjeve, odnosno kriterije iz zadatka. Takav, gotov softver (ili jedan njegov komad, ali koji je moguće testirati) dostavlja se Trećem licu. Treće lice prihvata na sebe obavezu da će pokušati da “razvali” i “uništi” komad softvera koji je programer napisao na sve moguće načine koji mu padnu na pamet. To Treće lice kako smo naprijed naveli se u svijetu informatike kratko zove QA ili QA inžinjer ili neki drugi sličan naziv. (Pisali smo i jedan šaljiv članak na temu QA inžinjera).

Da bi softver ispunio kriterije koji su opisani u zadatku (Ponovo navodimo članak Dobra priča), ali i one koji su definisani u nekim drugim kriterijima ili definicijama kao što su: Definicija gotovog ili Definicija sigurnosti, potrebno je napraviti odgovarajuće testove. Ti testovi mogu biti i jesu veoma različiti. Kod programera nabrojana tri su obavezna za gotovo sve vrste softvera, dok iz perspektive testera situacija je drugačija.

Testovi koje može da provodi tester su npr:

• Manuelni testovi (Manual tests) — to su testovi koje vrši čovjek. Oni mogu biti takvi da recimo neka osoba klika mišem po vizelnom dijelu aplikacije. Koristi tastaturu ili neki drugi vanjski uređaj. Mogu također biti i testovi s kojima se ručno, manuelno testira neka biblioteka ili servis. Uglavnom su veoma nepopularni, ali zato ih vjerovatno uglavnom obavljaju početnici u firmama, studenti, i gotovo u pravilu ne-tehnička lica. Jedan od primjera ovog testiranja je npr. kod unosa pristupnih podataka u formu za prijavu. Ti podaci mogu da budu kratki, dugački, veoma dugački, brojevi, simboli, i svašta nešto drugo, a što bi moglo dovesti do toga da se aplikacija prekine — pronađe bug.
• Funkcionalni testovi (Functional tests) — za razliku od programerske perspektive, ovdje se tačno zna da funkcionalni testovi predstavljaju testiranje funkcionalnosti. Oni mogu veoma često biti “samo” automatizacija manuelnih testova uz pomoć raznih alata. Pa tako recimo je moguće uz pomoć tih alata napraviti procedure koje će provjeriti neku funkcionalnost na različitim veb pretraživačima (web browsers), tako da to mnogostruko smanjuje vrijeme testiranja. Ako su te procedure napisane na “čudan” način, onda je njihovo prilagođavanje i na najmanju promjenu ponašanja softvera veoma zahtjevan posao i traži dobro znanje i vještine QA inžinjera. Timovi svakao trebaju veoma dobro razmisliti šta im je bolje (u zavisnosti od toga koji softver žele da testiraju), pisati automatizovane testove za koje treba znanje, vještine i vrijeme, ili pak manuelno.
• Testovi performansi (Peformance testing) — Kako se iz imena može zaključiti, s ovim testovima se komad ili cijeli softver pokušava opteretiti na razne načine, a zatim se provjeravaju karakteristike. Da bi nešto zadovoljilo kriterije, ti kriteriji moraju biti unaprijed definisani. Svakako, postoje nekakva nepisana pravila, kao što je brzina učitavanja veb stranice, ali čak i to pravilo ne mora da važi uvijek, kao što je kod aplikacija za bankarstvo. Aplikacija se može učitavati sporije, ako će se krajnjem korisniku obezbijediti vrhunska sigurnost podataka.
• Testovi probijanja ili penetracijski testovi (Penetration tests) — spadaju u grupu testova sigurnosti. Odnosno, testova s kojima se provjerava sigurnost softvera na sigurnosne propuste. Obzirom da se hakeri bave upravo metodama probijanja ili penetracije, otuda je ova vrsta testiranja i dobila to ime. Zaključuje se naravno da je za planiranje, pisanje i izvršavanje ovih testova neophodno osnovno znanje o etičkom hakiranju.
• S kraja na kraj testovi (End-to-End tests) — ovi testovi su nekada isti kao i funkcionalni, a nekada obuhvataju mnogo funkcionalnosti. Kako god, podrazumijevaju kompletan put testiranja od početka do kraja. Ili s kraja na kraj ili s početka do kraja.

Iz navedena dva primjera, perspektive, može se relativno lahko doći do zaključka da neke testove koje obavljaju QA inžinjeri mogu bez problema obavljati programeri. Posebno zbog toga što su ti testovi ustvari napisani u nekom programskom jeziku koristeći neki okvir (framework). Također ima i testova koji su veoma popularani, a koji nismo naveli ni u jednom primjeru. To je tzv. Test ponašanja (Behaviour tests) koji može, a počesto i treba biti napisan iz obje perspektive, i programerske i testerske. Razlika između ove vrste testova i naprijed navedenih je ta što se testovi ponašanja pišu (ili bi barem trebali da se pišu) u jezicima koji su veoma slični ljudskom jeziku. Najpopularniji jezik za testove ponašanja, a koji je veoma nalik ljudskom je svakako Gherkin, o kome smo napisali dva mala šaljiva članka prije. Umotani — Behat i Jeste li znali da kornišoni imaju svoj jezik?

Morate pisati testove — ništa ja ne moram

Često puta iz vjerovatno ili gotovo sigurno dobre želje i manje-više plemenitog cilja menadžeri raznih vrsta ili pak starije kolege na veoma ružan način tjeraju ostatak tima da piše testove, bez da im uopšte obrazlože zašto su testovi važni. Kako se samomotivisati ili pak motivisati druge te komunikacija je važna pisali smo prije. Nije zgorega podsjetiti se. Jer, valja nam svima pronaći šta je to što bi nas motivisalo da pišemo testove, a ne da nas neko na to primorava, jer sve ili gotovo sve uređeno preko volje je manjkavo.

Testovi se mogu posmatrati iz nekoliko uglova, pa se upravo vodeći tom logikom između ostalog dijele i na testove:

• koji se pišu prije nego se napiše programski kôd
• koji se pišu poslije nego se napiše programski kôd

Prema ovoj podjeli se onda imaju testovi tzv. TDD (Test Driven Development) i BDD (Behavior Driven Development). Neki na ovo dodaju još i ATDD (Acceptance Test Driven Development)

Da bismo članak zadržali što kraćim i što konciznijim to ćemo ovdje stati, a TDD, BDD i ATDD objasniti nekada kasnije u zasebnim člancima, svakako kroz primjere i šeme.

Hits: 0