Pragmaatiliselt oodatakse tarkvaratootelt usaldusväärsust, st et tarkvara funktsioneerib soovitud viisil etteantud tingimustel. Funktsioneerimise viis ja opereerimise tingimused on vaja püstitada toote arenduse esimestel etappidel ning täpsustada kogu arendustsükli käigus. Praktikas on võimatu testida kõikvõimalike sisendparameetrite kombinatsioonidega ning võrrelda tarkvara väljundit oodatava väljundiga. Seega on väga oluline valida efektiivne komplekt testandmeid kombineerituna testimise tüüpidega. Tänapäeval on kasutusel ka automaattestid. Kõiki teste, näiteks kasutuskõlblikkuse teste, ei ole võimalik automatiseerida.

Testimise olemuseks on kontrolltegevused, et näidata kõikide tarkvarale esitatud nõuete täidetust. Samuti peab testimisel veenduma, et kõik parandamiseks esitatud defektid ka parandatud saavad ning parandused ei põhjustaks omakorda uusi vigu.

Kuna tarkvaratoote kvaliteet oleneb suures osas läbiviidavate testide tüübist, tuleb neid hoolikalt valida ja toote tellijaga kokku leppida. Osa testimist teeb programmeerija, osa testimist testijad ning lõpuks rakendatakse ka kliente-tellijaid. Järgnevalt lühike ülevaade erinevatest testimise tüüpidest.

• Moodultestimise korral testitakse konkreetset tarkvaramoodulit - ühte alamsüsteemi kogu süsteemist. Testimist viib üldjuhul läbi moodulit realiseeriv arendaja. Moodulit tuleb kindlasti testida enne, kui moodul integreeritakse ülejäänud süsteemi. Mooduli testimisel tuleb jälgida, et moodul vastaks analüüsis püstitatud nõuetele. Mooduli testimise eesmärgiks on siiski vigade leidmine, mitte kasutajanõuetele vastavuse tõestamine. Näiteks kas moodulisse lisatud funktsioonid töötavad korrektselt ning tagastavad õigeid vastuseid. Mooduleid testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega. Tüüpiliselt on siin tegemist nn „valge kast" testimisega, st testija tunneb testitava tarkvara sisemist ülesehitust ja tööloogikat.
• Integratsioontestimise korral testitakse moodulitevahelist koostööd - kontrollitakse, kas kokku pandud moodulid töötavad omavahel ja kas iseseisvalt vigadeta töötanud moodulid koos vigasid ei genereeri. Testijana kasutatakse üldjuhul sõltumatut testijat, st testijat, kes ise ei arendanud testitavaid mooduleid. Näide integratsioonitestist on igaöine kompileerimine, et kontrollida arendatava toote käivitatavust.
• Süsteemtestimise korral testitakse süsteemi kui terviku töötamist. Süsteemi testimisel musta kasti meetodil vaadeldakse süsteemi kasutajale nähtavaid osi (kasutajaliidest), süvenemata koodi (siit nimetus „must kast"). Testjuhtumid koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib. Testijaid peab olema nii tellija kui täitja poolel. Seda laadi testimist nimetatakse ka funktsionaalsuse testimiseks.
• Regressioontestimine on igat tüüpi tarkvara testimine, mida kasutatakse peale koodi/süsteemi viidud muudatusi. Näiteks uue funktsionaalsuse lisamisel, konfiguratsiooni muutmisel, paikamisel. Regressioontestimise eesmärk on veenduda, et muudatused ja veaparandused pole tekitanud süsteemi uusi vigu. Testitakse muudetud mooduleid (moodultestimine) ja nendega seotud mooduleid ning kogu süsteemi funktsionaalsust (funktsionaalsuse testimine). Peamiseks meetodiks on juba kasutatud testide taaskäivitamine veendumaks, et süsteem toimib, vanad vead ei avaldu uuesti ja ei ole tekkinud uusi. Regressioontestimist on kasulik automatiseerida üldise töökoormuse vähendamiseks.
• Jõudlus- ja koormustestid on ette nähtud süsteemi tehniliste nõuetele vastavuse läbiproovimiseks. Jõudlustesti on võimalik läbi viia mitmel moel - iga komponendi jõudlust eraldi mõõtes või suure hulga testandmetega süsteemi tavakasutamist katsetades. Jõudlustesti eesmärk on tuvastada kriitilisemad kohad, kus võib tekkida ülekoormus ja kulutada aeg nende kohtade optimeerimiseks. Kui tavaliselt mõeldakse testandmed korralikult läbi ning valitakse sisendid eesmärgist lähtudes, siis selle testimisel puhul on võimalik testida ka juhusliku, arvuti poolt genereeritud suure andmehulgaga.
• Valideerimise eesmärk on kinnitada, et tarkvara töö tulemid väljatöötatud kujul sobivad määratud kasutamiseks. "Kas me teeme õiget tarkvarasüsteemi?"
• Verifitseerimise eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele. "Kas me teeme tarkvarasüsteemi õigesti?"
• Kasutatavuse testid hindavad süsteemi kasutusmugavust kasutaja vaatenurgast: Kasutatavuse testi eesmärk on avastada vigu ja kohti, mida paremaks võiks teha, selleks jälgitakse inimesi toodet kasutamas. Kindlasti ei saa kasutatavuse testimiseks pidada seda, kui kliendile näidatakse tulevase toote prototüüpi / pilti ja küsitakse, kas on arusaadav. Testimiseks peab inimene täitma konkreetseid ülesandeid ja sel teel selguvad tarkvarasüsteemis või ka veebilehel halvasti arusaadavad kohad. Kasutatavuse testimiseks sobivad nö "inimesed tänavalt", kes süsteemi esimest korda näevad. Aga ka eksperdid, kes oskavad kogemustest ja teooriatest lähtuvalt leida kasutusmugavuses nõrku kohti.
• Vastuvõtutest ehk aktsepteerimistest on kliendi poolt läbiviidav test valminud toote hindamiseks ja vastuvõtmiseks. Vastuvõtutesti testijuhtumid kirjeldavad üheselt projekti üleandmise ja vastuvõtmise kriteeriumid ning testijuhtumid peavad olema konkreetsed ja mõõdetavad ning nendes lepivad tellija ja teostaja projekti realiseerimise eel kokku;
• Koodi läbivaatus - erinevalt eelnevalt käsitletud testi tüüpidest, koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt. Läbivaatus eeldab küsimustiku olemasolu, mille alusel koodi hinnata ning sealt vigu otsida, mis tavatingimustes testides ei pruugi avalduda. Läbivaatajad peavad olema väga kompetentsed ka näiteks kasutatava keele osas. Mida otsitakse? Näiteks algväärtustamata muutujaid, ebasobivalt valitud andmetüüpe, muutujate või massiiviindeksite väljumist lubatud piiridest, tehete järjekorda, erinevate muutujatüüpide kokkusobivust jne.

Eelnimetatud tehnikaid tuleb kombineerida. Testitavaid omadusi on terve hulk, silmas tuleb pidada seda, et testimiseks on vaja, et toote nõuete püstitamise etapis vastava omaduse kohta ka nõuded püstitati ning püstitati viisil, mis võimaldab toote nõuetele vastavust kontrollida ehk mõõta. Loetleme allpoolt olulisemad nõuded tarkvara omadustele:

• funktsionaalsus - toote omadus väljendamaks tema sobivust seatud ülesannete täitmiseks, st tarkvaraga saab teha seda, mida klient vajab;
• turvalisus - toote omadus piirata äriloogikale/andmetele ligipääsu autoriseerimata isikute poolt;
• tõrkekindlus - toote omadus väljendamaks võimet tagada teatud jõudluse ja funktsionaalsuse tase veaolukorra tekke või liidese väärkasutamise puhul;
• taastuvus - toote omadus väljendamaks võimet taastada normaalne töörežiim ja jõudlus peale veaolukorra tekkimist;
• taastatavus - toote omadus väljendamaks keerukust ja vajaminevat töö hulka ning aega süsteemi põhifunktsionaalsuse taastamiseks avariiolukorra puhul;
• efektiivsus, jõudlus - toote omadus väljendamaks reageerimisele ja andmete töötlemisele kuluvat aega koormuse all;
• kasutatavus
  • mõistetavus - toote omadus väljendamaks vajaminevat aja hulka, mille jooksul kasutajad mõistavad süsteemi loogilist kontseptsiooni ja rakendatavust;
  • õpitavus - toote omadus väljendamaks vajaminevat aja hulka, mille jooksul kasutajad suudavad süsteemi kasutama õppida (näiteks andmete sisestamine/väljastamine jne);
  • kohaldatavus - toote omadus väljendamaks süsteemi paindlikust ja lõppkasutaja poolt enda jaoks sobivaks muutmise keerukust;
  • atraktiivsus - toote omadus väljendamaks lõppkasutajate rahulolu toote poolt pakutavate teenuste, esitluse ja käitumisega;
• stabiilsus - toote omadus väljendamaks muudatustejärgsete ootamatute nähtuste tekkimise riski suurust;
• taaskasutatavus - toote omadus väljendamaks toote osade taaskasutamise võimalusi teistes tarkvaraprojektides;
• porditavus - toote omadus väljendamaks aja- ja töökulu toote kohaldamisel teistesse keskkondadesse, platvormidele.

Erinevate testi tüüpide ja arendusetappide vastavust illustreerib alljärgnev joonis. Pidevad nooled näitavad tarkvaratoote arendusprotsessi sammude ajalist kulgu, punktiirjooned seoseid testi tüüpide ja arendusetappide vahel: nt moodultest kontrollib valminud mooduli vastavust mooduli spetsifikatsiooniga, milline sünnib detailse projekteerimise sammus; süsteemitest vastab tarkvara nõuete püstitamise sammule ning vastab küsimusele, kas valminud süsteem tervikuna täidab püstitatud nõudeid. Vastuvõtutest vastab küsimusele, kas tarkvaratoode vastab kliendi vajadustele, ehk kas toode on küps kasutuselevõtuks ja/või müüki paiskamiseks.

Joonis 1-7. Tarkvaratoote testimise V-mudel. Mudel on osaliselt inspireeritud koskmudelist

Testimise käigus leitud vead tuleb dokumenteerida. Dokumenteerimine ei tähenda tingimata paberdokumendi vormistamist, pigem kasutatakse spetsiaalseid CASE-vahendeid, nt Mantis ja Bugzilla, mis abiks ka vearaportite edastamisel programmeerijatele.

Toote kvaliteediga on - lisaks testimisele - seotud ka ülevaatused. Ülevaatus on tegevus, milline viiakse tavaliselt läbi rühmatööna. Ülevaatuste käigus arutatakse ja hinnatakse tarkvaratoote projekti staatust, riske, tehakse otsustusi ressursside juhtimise ning toote nõuete-lahenduste vallast. Otsused peaks protokollima, määrates isikud, kes vastutavad otsuste tähtajalise elluviimise eest.

Ülevaatuste eriliigid on:

• tehnilised koosolekud, millistel osalevad toote arhitektid, analüütikud, projektid, kliendid. Analüüsitakse ja tehakse toote ülesehitust puudutavaid otsuseid;
• koodi läbivaatused;
• auditid, mida üldjuhul viivad läbi sõltumatud, välise organisatsiooni esindajad. Hinnatakse muuhulgas toote ja/või arendusprotsessi vastavust nõuetele, standarditele, formaalsetele protseduuridele, lepingutele jm. Maailmas tuntuim IT-audiitorite organisatsioon on ISACA (http://www.isaca.org), kelle poolt sertifitseeritud audiitorid kannavad CISA-tiitlit (Certified Information System Auditor - sertifitseeritud infosüsteemide audiitor).