Toote kvaliteet sõltub eelkõige toote valmistamise protsessi (tarkvara korral seega tarkvara arendusprotsessi) kvaliteedist ning toote arendajate-valmistajate (analüütikute, arhitektide, programmeerijate, projektijuhtide jt) teadmistest, oskustest ning motivatsioonist. Seega üheks tarkvara kvaliteedi tõstmise viisiks on parendada protsesse, koolitada inimesi jms. Teiseks viisiks on testida lõpptulemust – so käivitada koodi.

Testimine on kasutusel mitmetes inimtegevuse valdkondades: teaduses testitakse vaatluste ja eksperimentidega hüpoteese ning teooriaid, õppe läbiviimisel testitakse tudengeid, tootmises testitakse toodangut.

Tarkvara ja süsteemi ehk toote testimine on otseselt seotud toote kvaliteediga. Toode on kvaliteetne, kui ta rahuldab oma tööga vajadusi, millised motiveerisid toodet looma. Seega on vajalik vastavate testide läbiviimine tegemaks kindlaks, kas toode vastab täielikult kliendi nõuetele. Lisaks sellele näitavad testid vigade puudumist tootest. Siiski, absoluutse kindluse, et toode ei sisalda vigu, saavutamine ei ole reaalsuses võimalik – matemaatiliselt on võimalik näidata koodi „tõesust” ainult lihtsamatel juhtudel. 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.

• 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. Mooduleid testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega. Tüüpiliselt on siin tegemist nn „valge kast” testimisega, so 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, so testijat, kes ise ei arendanud testitavaid mooduleid. Näide integratsioonitestist on igaöine kompileerimine, et kontrollida arendatava toote käivitatavust;
• süsteemtesti 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”. Testülesanded koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib. Testijaid peab olema nii tellija kui täitja poolel;
• regressioontestimist kasutatakse, kui peale testimist on koodi viidud muudatusi. Testitakse muudetud mooduleid ja nendega seotud mooduleid, vajadusel viiakse läbi ka integratsiooni- ja süsteemitestid;
• kasutatavustestid testivad süsteemi kasutusmugavust jm kasutaja vaatenurgast;
• 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;
• valideerimise eesmärk on kinnitada, et tarkvara töö tulemid väljatöötatud kujul sobivad määratud kasutamiseks;
• verifitseerimise eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele;
• vastuvõtutest ehk aktsepteerimistest on kliendi poolt läbiviidav test valminud tulemuste hindamiseks ja vastuvõtmiseks. Aktsepteerimistesti 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 (ingl. k walk-through) – erinevalt eelnevalt käsitletud testi tüüpidest koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt.

Eelnimetatud tehnikaid tuleb kombineerida toote testitava omadusega. 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õue/ded püstitati ning püstitati viisil, mis võimaldab toote nõudele vastavust ka kontrollida ehk mõõta. Loetleme allpoolt olulisemad nõuded:

• funktsionaalsus – toote omadus väljendamaks funktsionaalsuse sobivust seatud ülesannete täitmiseks;
• turvalisus – toote omadus piirata äriloogikale/andmetele ligipääsu autoriseerimata tegutsejate 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.

Testimise käigus leitud vead tuleb dokumenteerida. Dokumenteerimine ei tähenda tingimata paberdokumendi vormistamist – võib kasutada spetsiaalseid CASE-vahendeid, nt Mantis ja Bugzilla.

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 (ingl. k code-walkthroghs);
• auditid, mida üldjuhul viivad läbi sõltumatud, välise organisatsiooni esindajad. Hinnatakse mh 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).