Tarkvara kvaliteedi tagamine hõlmab arvutitarkvara disaini ja juurutamise testimist ning selle vastavust minimaalsele kvaliteedistandardile. Kvaliteedi tagamise protsessi keskmes on testimine, mis on meetod, mille abil analüüsitakse iga arendustsükli etappi, et leida defekte, näiteks rikkeid või turvaprobleeme. Tarkvara kvaliteedi tagamise protsessi kõige tuntum osa on tarkvara ja koodi testimine; kuid see hõlmab ka muid inseneritsükli aspekte. Muud tarkvaratehnika aspektid, mis kuuluvad kvaliteedianalüüsi, hõlmavad projekteerimise ja juurutamise etappe.
Tarkvara kvaliteedi tagamise üldine kontseptsioon nõuab, et see algaks tarkvara planeerimise etapist. Halvasti planeeritud tarkvara võib olla keeruline või võimatu kirjutada viisil, mis vastaks seda ette kujutanud organisatsiooni ootustele. Kvaliteedijuhtimine projekteerimisetapis hõlmab projekti spetsifikatsioonide või eesmärkide tagajärgede uurimist, aga ka organisatsiooni plaanide saavutamist oma eesmärkide saavutamiseks. Kvaliteedianalüüsi eeliseks disainifaasis on see, et see leiab ja kõrvaldab vead varakult, mitte arendustsükli hilisemas etapis, kui disainiprobleemide parandamine on palju kulukam.
Tarkvara testimise insener, tuntud ka kui tarkvara kvaliteedianalüütik, on esmane isik, kes vastutab testimisprotsessi läbiviimise eest. See inimene koostab ja viib ellu testiplaanid, mis aitavad organisatsioonil oma tarkvara kvaliteeti parandada. Ideaalis ei tohiks programmeerija kunagi oma toodet testida, mis tähendab, et projekti raames on programmeerija ja testimisinsener kaks erinevat inimest.
Testiplaanid on kvaliteedi tagamise süsteemi, eriti tarkvara testimise etapi, kriitilise tähtsusega osa. Testiplaanide eesmärk on määrata kindlaks tingimused, mis tähistavad tarkvara õnnestumist või ebaõnnestumist. Tüüpiline testimisplaan sisaldab põhjalikku nimekirja programmidest ja alamprogrammidest või protseduuridest, mida tuleb testida, samuti testimisega seotud tehnikaid. Testiplaani teine kriitiline funktsioon on vastuvõetamatud defektide määramine. Testiplaanid koostatakse tavaliselt enne projekti tegeliku tarkvarakoodi väljatöötamist.
Kui testiinsenerid kirjutavad testplaanide rakendamiseks programme, nimetatakse neid testskriptideks. Testskriptid on tarkvara kvaliteedi tagamise protsessi oluline osa. Nende eesmärk on automatiseerida programmi olemasoleva koodi testimist, et leida defekte. Lisaks kasutavad testiinsenerid võimalike probleemide otsimiseks tavaliselt kaubanduslikult loodud testimistööriistu. Testiplaanid viiakse ellu tarkvaraarenduse kodeerimisetapis.
Tarkvara kvaliteedi tagamise protsessi tegelikus testimisetapis on mitmeid olulisi samme. Nende hulka kuuluvad ühikutestimine, mis hindab tarkvarakoodi erinevate osade terviklikkust, aga ka veasüstid, mille eesmärk on uurida, kuidas programmid ekslikele andmetele reageerivad. Täiendavad sammud hõlmavad koormustesti või stressitesti, mis näeb, kuidas programm töötab intensiivse kasutuse korral, ja sissetungimis- või turvatesti, et testida programmi vastupidavust volitamata juurdepääsule. Tarkvaraprojekti suhtes tehakse tavaliselt ka kasutatavuse testimine, et kontrollida, kas saadud programmi on teistele lihtne kasutada.
Tarkvarakoodi testimisega tegelevad spetsialistid jagunevad üldiselt kahte rühma, millest ühte nimetatakse musta kasti testijateks ja teist valge kasti või klaaskasti testijateks. Musta kasti testimine on pealiskaudsem protsess, mis algab tarkvara kodeerimisetapis ja ei uuri ühtegi aluseks olevat arvutikoodi. See uurib tarkvara kasutatavust, kosmeetilist järjepidevust ning vigade ja talitlushäirete esinemist.
Valge kasti testimine on protsess, mis algab tarkvara kvaliteedi tagamise protsessi alguses, projekteerimisetapis. See hõlmab võimalike probleemide ennustamist enne koodi tegelikku kirjutamist, samuti testiplaanide ja täiustatud testiskriptide kirjutamist. Erinevalt musta kasti testimisest hõlmab valge kasti testimine ka aluseks oleva arvutikoodi uurimist.
Kvaliteedi tagamine kehtib ka tarkvara juurutamise faasi kohta, mil tarkvara on peaaegu valmimisjärgus ja installitakse arvutisüsteemidesse hindamiseks. Seda etappi nimetatakse sageli alfa-testimiseks ja see toimub siis, kui peaaegu valmis toode paigaldatakse ja seda testivad arendaja töötajad. Kui tarkvara esitletakse potentsiaalsetele klientidele väljaspool ettevõtet, nimetatakse seda beetatestimiseks. Kui pärast tarkvara väljaandmist ilmnevad vead ja vaja on välja töötada plaaster, kasutatakse regressioonitesti, et tagada, et uuendused ei tekitaks uusi vigu.