Tarkvara testimine

Tarkvara testimine on tarkvaraarenduse protsess, mille käigus püütakse hinnata tarkvara kvaliteeti.
Kitsamas mõttes tähendab tarkvara testimine tarkvara käivitamist/täitmist selles olevate vigade avastamiseks ja tarkvara vastavuse kontrollimist ettenähtud nõuetele. Laiemas mõttes on testimine tarkvara analüüsi protsess, mille käigus "püütakse leida erinevusi olemasolevate ja nõutud tingimuste vahel ning hinnata tarkvara omadusi". Testimine laiemas mõttes on tarkvaratoote planeerimise, ettevalmistuse ja hindamisega seotud elutsükli tegevusi hõlmav protsess.
Tarkvara testimine on paljuski kogemustel põhinev tehniline uurimine. Testides võetakse arvesse konteksti, milles programm töötama peab. Testimise eesmärk on saada programmi käivitades tulemuseks viga.
Testimine annab infot toote kvaliteedi kohta, kuid tarkvara kvaliteet on iga kasutaja jaoks subjektiivne. Seepärast ei saa testimisega kunagi tagada programmi täiuslikkust. Kasutaja kritiseerib või võrdleb programmi seisu või käitumist oma seisukohast lähtuvalt.
Tarkvara testimine püüab anda objektiivse ja erapooletu ülevaate tarkvarast, et äripool saaks aru selle tarkvara arendusega kaasnevatest riskidest. Seda saab nimetada ka protsessiks, kus kontrollitakse tarkvaraprogrammi, rakenduse või toote vastavust projekteerimis- ja arendustegevuse ajal kindlaks määratud tehnilistele nõuetele, et see rakendus või toode toimiks nii, nagu vaja ja oleks rakendatav.
Tarkvara saab testida arendusprotsessi igal hetkel. Mõnikord kasutatakse teste juba arendusprotsessi algusjärgus, kuid sageli toimub suurem osa testimisest pärast nõuete määratlemist ja programmeerimise lõppemist. Testimise meetodid sõltuvad seega tarkvaraarenduse metoodikast.

Ülevaade

Testimine ei tee kunagi täielikult kindlaks kõiki tarkvaratoote vigu, sest kõigi detailide ülekontrollimine on liiga ajamahukas ja kulukas ettevõtmine. Pigem kontrollitakse tarkvara vastavust üldlevinud põhimõtetele ja vaadatakse üle selle veaohtlikumad kohad. Arvesse võetakse spetsifikatsioone, võrdlust sarnaste toodetega, võrdlust toote varasemate versioonidega, kavandatud ja oodatud eesmärke, kasutajate või klientide ootusi, asjakohaseid standardeid, kehtivaid seadusi või muid aluseid.
Igal tarkvaratootel on oma sihtrühm. Näiteks arvutimängude sihtrühm erineb oluliselt pangandustarkvara omast. Seepärast peab organisatsioon tarkvarasse investeerides silmas pidama nii lõppkasutaja (sihtrühma, tarkvara soetaja) kui ka firma osanike vajadusi. Tarkvara testimise käigus püütakse välja selgitada, kas toode vastab kokkulepitud nõuetele ning on kooskõlas kliendi või lõppkasutaja vajadustega.
2002. aastal osutas NIST-is (The National Institute of Standards and Technology, USA riiklik standardite ja tehnoloogia instituut) tehtud uuring, et tarkvaravead lähevad USA majandusele maksma 59,5 miljardit dollarit aastas ja et rohkem kui kolmandiku sellest summast saaks kokku hoida tõhusama testimise abil.

Ajalugu

Dr David Gelperin ja dr Bill Hetzel jagasid 1988. aastal tarkvara testimise ajaloo viide arenguetappi, võttes jaotuse aluseks erinevatel perioodidel domineerinud tarkvara testimise mudelid.
–1956 silumine
Sellel perioodil koondus tähelepanu riistvara töökindlusele. Esimestes testimist käsitlevates artiklites kirjutati riistvarakomponentidest. Programmeerimisse suhtuti lihtsalt: programm kirjutati valmis ja seejärel kontrolliti, kas see töötab. Programmi silumisel ja testimisel oli üldjoontes sama tähendus.
1957–1978 demonstreerimine
1957. aastal kirjutas Charles Baker arvustuse Dan McCrackeni raamatule "Digital Computer Programming". Arvustuses tegi ta vahet silumisel (programm peab tõrgeteta töötama) ja testimisel (programm peab lahendama ülesande).
Kirjutatud programmide hulga, keerukuse, kulukuse ja programmeerimisega seotud majanduslike riskide kasvades hakati üha enam tähtsustama testimist, mis tähendas probleemide tuvastamist enne toote lõplikku üleandmist. Nii silumine kui ka testimine hõlmasid sel perioodil vea märkamist, selle asukoha leidmist ja vea parandamist. Olulisim oli programm tööle saada.
1979–1982 hävitamine
Glenford J. Myers juhtis 1979. aastal ilmunud teoses "The Art of Software Testing" esimest korda tähelepanu silumise ja testimise erinevusele. Kuigi tema tähelepanu oli suunatud programmi katki tegemisele (breakage testing) ("Edukas test leiab peidus olnud vea." ), illustreeris see tarkvaraarendajate soovi eraldada fundamentaalsed arendustegevused (nt silumine) töökindluse kontrollimisest (verifitseerimisest). Myers arvas, et kui testija loobub programmi töökindluse demonstreerimisest ning keskendub hoopis vigade otsimisele, siis tõenäoliselt leiabki ta üles rohkem vigu.
1983–1987 hinnangu andmine
1983. aastal avaldati "Guideline for Lifecycle Validation, Verification, and Testing of Computer Software".
1988–... ennetamine

Käsitlusala

Testimise peamine eesmärk on tarkvara vigade ja puuduste avastamine. See ülesanne ei ole lihtne, kuna testimisega pole võimalik kindlaks teha toote nõuetekohast toimimist kõikidel tingimustel, vaid ainult kõrvalekaldeid korralikust töötamisest kindlatel tingimustel.
Tarkvara testimine hõlmab koodi uurimist ja täitmist erinevates keskkondades ning erinevatel tingimustel. Kontrollitakse koodi eesmärgipärast toimimist. Tänapäevases tarkvaraarenduse kultuuris võivad testimisorganisatsioon ja tarkvara arendusmeeskond olla eraldiseisvad üksused. Tarkvara testijatel on mitmeid rolle. Testimisest saadud teabega saab parandada tarkvara väljatöötamise üldist protsessi.

Funktsionaalne ja mittefunktsionaalne testimine

Funktsionaalne testimine tähendab mingi kindla tegevuse või funktsiooni töötamise kontrollimist. Funktsionaalse testimisega kontrollitavad nõuded on tavaliselt kirjas koodi dokumentatsioonis, kuigi mõned testimismetoodikad kasutavad ka testjuhtumeid või kasutajate tagasisidet. Funktsionaalsed testid vastavad küsimustele "Kas kasutaja saab seda teha?" ja "Kas see funktsioon töötab?".
Mittefunktsionaalne testimine ei ole seotud kindlate tegevuste või funktsioonide testimisega, vaid selliste omadustega nagu skaleeritavus, jõudlus, käitumine teatud tingimustel või turvalisus. Mittefunktsionaalsed nõuded peegeldavad toote kvaliteeti ja vastavust kasutaja vajadustele.

Vead ja puudused

Tarkvaratoote puuduste põhjuseks ei ole üksnes programmeerimisvead, vaid neid võivad põhjustada ka näiteks puudulikult kirjeldatud nõuded, mille põhjal tarkvara luuakse. Sageli on kirjeldamata jäetud või puudulikult kirjeldatud tarkvara mittefunktsionaalsed nõuded, näiteks testitavus, skaleeritavus, hallatavus, kasutatavus, jõudlus ja turvalisus.
Tarkvaravead võivad tekkida järgmiselt: programmeerija eksimuse tulemusena tekib viga tarkvara lähtekoodi. Teatud tingimustel läheb sellise koodi käivitamisel süsteem katki või töötab valesti. Kõik programmeerimisvead ei pruugi mõjutada tarkvara toimimist, näiteks võib viga sisaldav tarkvara töötada laitmatult, kui vigast koodilõiku programmis tegelikult ei kasutatagi. Viga võib avalduda, kui käivitamise keskkond (näiteks riistvaraplatvorm või tarkvara, millega programm suhtleb) või tööks kasutatavad andmed muutuvad ja seetõttu vigast koodi kasutama hakatakse. Üks viga võib avalduda mitmel eri moel.

Ühilduvus

Tihti põhjustavad tarkvaratõrkeid ühilduvusprobleemid, mis tähendab tarkvara sobimatust mõne muu programmiga, näiteks operatsioonisüsteemi või veebibrauseriga. Samuti võib tekitada probleeme muutunud käivituskeskkond, näiteks kui eelnevalt töölaual töötanud programm muudetakse veebibrauseris töötavaks veebirakenduseks.
Mitteühilduvus võib olla tingitud sellest, et tarkvara on testitud ainult ühe OSi versiooniga, tavaliselt kõige uuema väljalaskega. Nii võib juhtuda, et tarkvara ei toimi varasema või hilisema riist- või tarkvaraga või ta ei ühildu täielikult mõne teise OSiga. Selliseid riske on võimalik maandada, jagades OSi funktsioonid moodulitesse või teekidesse.

Lähteandmete kombineerimine ja eeltingimused

Üks tarkvara testimise põhiprobleeme on algandmete ja eeltingimuste kombinatsioonide paljusus, mille täismahus testimine võib isegi lihtsa tarkvara puhul olla liiga keeruline või kulukas.
Sellest tulenevalt ei pruugi testid harva avalduvaid vigu üles leida ja testimisest hoolimata võib vigade arv tarkvaratootes olla suur.
Mittefunktsionaalsed kvaliteedinäitajad (kuidas peab tegema, mitte mida peab tegema) ei pruugi olla kõigile üheselt mõistetavad, näiteks kasutatavus, skaleeritavus, jõudlus, ühilduvus ja veakindlus.

Staatiline ja dünaamiline testimine

Tarkvara testimise meetodeid on palju.
Staatilisel testimisel tarkvara ei käivitata, vaid analüüsitakse tarkvara lähtekoodi, vaadatakse läbi dokumentatsiooni või kontrollitakse koodi vastavust dokumentatsioonile. Staatiline testimine tuvastab tarkvara puudused (inglise keeles defect) varakult. Dünaamiline testimine tähendab koodi käivitamist ja selle toimimise jälgimist. Dünaamiline testimine tuvastab peamiselt tõrkeid (inglise keeles failure).
Staatilise testimise võib praktikas mõnikord välja jätta (mida ka tihti paraku tehakse), dünaamiline testimine leiab aset igal programmi käivitatamisel. Dünaamiline testimine võib alata enne programmi täielikku valmimist, et kontrollida eelkõige koodi osasid (mooduleid või alamprogramme). Tavaliselt tehakse seda siluri (debugger) abil. Näiteks arvutustabeli programme testitakse nende olemuse tõttu suurel määral interaktiivselt, valemite või teksti muutmisel kuvatakse tulemused kohe.

Tarkvara testijate meeskond

Tarkvara testimist viivad läbi tarkvara testijad. 1980. aastani kasutati mõistet "tarkvaratestija" üldiselt, kuid hiljem muutus see tegevus eraldi elukutseks. Aja jooksul muutunud eesmärkide tõttu on tarkvara testimises tekkinud erinevaid rolle: testimise juht, peatestija, testide projekteerija, testija, testide automatiseerimise arendaja ja testimise administraator.

Tarkvara kvaliteedi tagamine

Tarkvara testimist võib vaadelda tarkvara kvaliteedi tagamise (inglise keeles Software Quality Assurance ehk SQA) olulise osana. Tarkvara menetluse spetsialistid ja audiitorid jälgivad arendustegevust ja muudavad arendusprotsesse vastavalt vajadustele minimeerimaks tarnitavas tarkvaras esinevaid puudusi nii, et nende hulk mahuks aktsepteeritava määra sisse. "Aktsepteeritav määr" sõltub tarkvara otstarbest, näiteks arvutimängus olevad vead on ohutumad lennujuhtimissüsteemi vigadest.
Kuigi testimine on tihedalt seotud kvaliteedi tagamisega, on testimisosakonnad tihti eraldi üksused. Mõnes ettevõttes ei pruugi üldse olla SQA osakonda.
Tarkvara testimine on protsess, mille eesmärk on avastada puudused tarkvaras ja võrrelda arvutiprogrammi tulemusi loodetud tulemustega. Kvaliteedi tagamise (quality assurance) eesmärk on korraldada arendustegevust ja selle põhimõtteid, et vältida defektide teket juba arendusprotsessi alguses.

Testimismeetodid

Tarkvara testimise meetodid jagatakse traditsiooniliselt valge ja musta kasti testideks. Esimesel juhul uuritakse koodi ja testid tehakse programmi teksti alusel. Teisel juhul ei süveneta programmi teksti, vaid testitakse programmi funktsionaalsust.

Musta kasti meetod

Musta kasti (black-box) testimine kohtleb tarkvara kui "musta kasti", teadmata midagi selle sisemisest teostusest. Musta kasti testimismeetodite hulka kuuluvad: samaväärsuste jaotamine, piirväärtuste analüüs, paarikaupa testimine, "hägune" testimine, mudelipõhine testimine, uurimuslik testimine ja spetsifikatsioonidel põhinev testimine.

Spetsifikatsioonidel põhinev testimine

Spetsifikatsioonidel põhineva testimise eesmärk on testida tarkvara funktsionaalsust vastavalt kehtivatele nõuetele. Seega testija sisestab andmed testobjekti ja näeb ainult väljundit. Selline testimistase nõuab tavaliselt põhjalikke testjuhtumeid, mis antakse testijale. Testija saab siis lihtsalt kontrollida, kas antud sisendi puhul väljundi väärtus (või käitumine) "on" või "ei ole" sama nagu eeldatav väärtus, mis on määratud testjuhtumis. Spetsifikatsioonil põhinev testimine on vajalik, kuid see ei ole piisav, et vältida teatud riske.

Eelised ja puudused

Musta kasti testija ei näe koodi ja ta eeldab, et koodis on kindlasti vead. Kasutades põhimõtet: "Küsige ja te saate", leiavad musta kasti testijad vigu seal, kus programmeerijad neid otsidagi ei oska. Teiselt poolt on musta kasti testimist kirjeldatud kui "pimeda labürindi läbimist ilma taskulambita", sest testija ei tea, kuidas on testitav tarkvara tegelikult üles ehitatud. Seepärast on olukordi, kus musta kasti testija kirjutab mitmeid testjuhtumeid, et kontrollida mõnd lihtsat asja, mida koodi teades saaks kontrollida ainult ühe testiga, ja mõni osa mustast kastist jääb üldse testimata.
Musta kasti testimise eeliseks on "koodist mõjutamata arvamus", kuid puuduseks "pimedas kompamine".

Halli kasti meetod

Halli kasti (grey-box) testimisel on programmi sisemine ehitus osaliselt teada, nt selle andmestruktuurid ja algoritmid, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. Sisendandmetega manipuleerimine ja väljundivormindamine ei ole halli kasti testimine, sest sisend ja väljund on väljaspool "musta kasti" ehk testitavat süsteemi. Selline eristamine on eriti oluline integratsioonitestimises, kui kontrollitakse liideste põhjal, kas nt kahe erineva arendaja kirjutatud moodulid ühilduvad. Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja väljaspool testitavat süsteemi andmeid muuta. Halli kasti testimine võib hõlmata ka pöördprojekteerimist leidmaks näiteks piirväärtusi või tõrketeateid.

Testimise tasemed

Teste rühmitatakse tihti selle järgi, millises tarkvaraarenduse staadiumis neid lisatakse, või nende spetsiifilisuse järgi. Tarkvaratehnika IEEE juhendmaterjalis "Guide to the Software Engineering Body of Knowledge" (SWEBOK) kirjeldatakse tarkvara testimise tasemeid. Need tasemed on ühiktestimine, integratsioonitestimine ja süsteemitestimine. Kindlat protsessi mudelit ei kirjeldata. Teisi testimise tasemeid liigitatakse testimise eesmärgi järgi.

Integratsioonitestimine

Integratsioonitestimisel kontrollitakse komponentidevaheliste liideste vastavust tarkvara disainile ning kõigi komponentide ühilduvust üksteisega. Tarkvara komponente võib integreerida järk-järgult või ühekorraga (big bang). Tavaliselt eelistatakse viimast, sest nii saab liideste vigu kiiremini leida ja parandada.
Integratsioonitestimine paljastab defektid liidestes ja vastastikustes toimetes integreeritud komponentide (moodulite) vahel. Integreeritakse ja testitakse järjest suuremaid tarkvara komponentide kogumeid, mis vastavad arhitektuurilise disaini elementidele, kuni kogu tarkvara töötab ühtse süsteemina.

Süsteemitestimine

Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust.

Süsteemi integratsiooni testimine

Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.

Alfatestimine

Alfatestimine on simuleeritud või tegelik testimine arendaja juures, seda teostavad potentsiaalsed kasutajad/kliendid või iseseisev testimismeeskond. Alfatestimist rakendatakse arendaja organisatsioonis vastvalminud tarkvara vastuvõtmiseks. Pärast alfatestimist läheb tarkvara edasi beetatestimisele.

Beetatestimine

Kui alfatestid õnnestuvad, saadetakse valmistarkvara beetatestimisse. Tarkvara versioone, mida nimetatakse beetaversioonideks, antakse vähestele inimestele väljaspool programmeerimise meeskonda. Need inimesed kasutavad vastvalminud tarkvaratoodet ja annavad kasutuskogemuse kohta arendajatele tagasisidet. Mõnikord tehakse beetaversioonid täiesti avalikuks, et saada tagasisisidet võimalikult paljudelt inimestelt.

Mittefunktsionaalne testimine

Erimeetodite olemasolul saab testida tarkvara mittefunktsionaalseid aspekte. Erinevalt talitluslikust (funktsionaalsest) testimisest, mis kontrollib tarkvara toimimist (ehk seda, kas tarkvara käitumine on kooskõlas dokumenteeritud ja dokumenteerimata nõuetega), kontrollitakse mittefunktsionaalse testimisega näiteks seda, kas tarkvara töötab korralikult ka siis, kui ta saab vigaseid või ootamatuid sisendeid. Mittefunktsionaalne testimine on näiteks hägune testimine, mis on sihiliku vigade süstimise vorm. Mittefunktsionaalsel testimisel, eriti tarkvara puhul, vaadatakse, kas vigaste või ootamatute sisendandmete puhul on sisendandmete kontroll ja vigade töötlemine piisavalt robustne. Mittefunktsionaalse testimise läbiviimiseks on nii mitmeid avatud lähtekoodiga ja vabavaralisi tööriistu kui ka kommertstarkvara.

Jõudlustestimine ja koormustestimine

Jõudlustest kontrollib tarkvara töökiirust määratud hulga andmete või kasutajatega, kuid sellega mõõdetakse ka teisi süsteemi parameetreid, näiteks skaleeritavust, töökindlust ja ressurssikasutust. Koormustestimisega kontrollitakse tarkvara suutlikkust töötada püsivalt kindlal koormusel. Mittefunktsionaalset koormustestimist nimetatakse tihti vastupidavuse testimiseks.
Jõudlustestimise ja koormustestimise all mõistetakse tihti sama asja.

Stabiilsuse testimine

Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord vastupidavuse testimiseks.

Kasutatavuse testimine

Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista.

Turvalisuse testimine

Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid. Sel juhul peab süsteem vastu pidama häkkimisele ja küberrünnakule.

Destruktiivne testimine

Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas, et testida selle robustsust.

Traditsiooniline koskmudel

Tarkvara testimisele on omane tava, et seda teeb iseseisev testijate rühm pärast programmi funktsionaalse poole valmimist ja enne tarkvara kliendile edastamist. Sedasi toimimine lõpeb tihti sellega, et testimisele mõeldud aega kasutatakse puhvrina juhuks, kui projektis tekib viivitusi, kuid sel juhul väheneb testimisele pühendatud aeg.
Teine viis on testimist alustada projekti alguses ja seda jätkata projekti lõppemiseni.

Väle või ekstreemne arendusmudel

Mõned uued arendusmudelid, näiteks väle või ekstreemne programmeerimine, kasutavad testimisepõhist arendust. Selles protsessis kirjutavad arendajad kõigepealt ühiktestid (ekstreemses mudelis tihti paarisprogrammeerimisega). Alguses testid loomulikult ebaõnnestuvad. Kui koodi kirjutatakse juurde, siis läbitakse järjest rohkem teste. Testide komplekte uuendatakse töö käigus, kui leitakse uusi kasutusjuhtumeid ja vigade tekkimise võimalusi, ning need integreeritakse juba arendatud regressioonitestidega. Ühiktestid hoitakse ülejäänud lähtekoodiga koos ja tavaliselt põimitakse ehitamisprotsessiga (interaktiivsed testid tehakse eraldi käsitsi).

Automatiseeritud testimine

Paljud tarkvaraarendajad kasutavad järjest rohkem automatiseeritud testimist, eriti testimispõhise arenduse juures. Testide kirjutamiseks leidub tarkvaralisi raamistikke, mis võimaldavad iga versioonihaldussüsteemi sisse kantud muudatuse järel automaatselt teste läbi viia.

Mõõtmised tarkvara testimises

Tavaliselt peetakse kvaliteetseks sellist tarkvara, milles ei ole vigu, mis on terviklik ja turvaline, aga kvaliteet võib hõlmata ka selliseid tehnilisi nõudeid nagu suutlikkus, töökindlus, porditavus, hooldatavus, ühilduvus ja kasutatavus. Neid on kirjeldatud ISO standardis ISO/IEC 9126.
Tarkvara meetrikaks nimetatakse mõõtühikuid, mida kasutatakse tarkvara seisundi mõõtmiseks või testimise adekvaatsuse määramiseks.

Testimise tulemid

Tarkvara testimise tulemuseks on paremini töötav tarkvara ja suur kogus tarkvaraga seotud materjale.
Testimisplaan
Testi spetsifikatsiooni nimetatakse testimisplaaniks. Tarkvaraarendajatele on hästi teada, millised testimisplaanid täidetakse, ning see teave on juhtkonnale ja arendajatele kättesaadav. See teeb tarkvaraarendajad koodi arendamisel ja lisamuudatuste tegemisel ettevaatlikumaks. Mõnedel ettevõtetel on testimisstrateegia, mis on kõrgema taseme dokument.
Testjuhtum
Testjuhtum on tarkvara testimise dokument, mis koosneb mingit tegevust kirjeldavatest sammudest, eeltingimustest, sisendist, väljundist, oodatud tulemustest ja tegelikust tulemusest. Osad testid on praktilised, näiteks "tingimusel x saadakse tulemus y", teised kasutusjuhendid kirjeldavad detailsemalt sisestusskeemi ja oodatavaid tulemusi. See võib olla rida samme ühe oodatud tulemusega. Mõnikord kasutatakse neid samme eraldiseisvas testimisprotseduuris, et testida mitut testjuhtumit korraga. Testjuhtumi valikulised väljad on identifitseerimisnumber, testi samm või tegevuse järjekorra number, põhjalikkus, seotud nõuded, testi kategooria, autor, märkeruudud, kas test on automatiseeritav ja on automatiseeritud. Suuremad testjuhtumid võivad sisaldada eelnevalt vajalikke tingimusi, samme ja kirjeldusi. Testjuhtum peaks samuti sisaldama kohta tegeliku tulemuse jaoks. Neid samme saab säilitada tekstidokumendis, tabelis, andmebaasis või mõnes muus levinud andmekogus. Andmebaasis on võimalik näha ka varasemaid testitulemusi, nende tegijaid ja seda, mis süsteemiga tulemusi genereeriti. Varasemad tulemused hoitakse tavaliselt eraldi tabelis.
Testskript – protseduur või kood kasutaja tegevuste matkimiseks. Algselt tähendas testskript automatiseeritud regressioonitestimise tööriistade väljundit. Testskripte luuakse testjuhtumite põhjal vastavate tööriistade või programmidega.
Testide komplekt – testjuhtumite kogu nimetatakse testide komplektiks. Testide komplekt sisaldab sageli ka üksikasjalikke juhiseid või eesmärke iga testjuhtumi jaoks. Kindlasti sisaldab see ka osa, kus testija teeb kindlaks süsteemi konfiguratsiooni, mida testimise ajal kasutatakse. Testide komplekt võib sisaldada ka eelnevalt vajalikke tingimusi, samme ja eelolevate testide kirjeldusi.
Testandmed – tavaliselt kasutatakse mitmeid erinevaid väärtusi või andmeid, et testida mingi tarkvara osa funktsionaalsust. Kõik testitavad andmed ja keskkonna muudetavad komponendid salvestatakse eraldi failidesse. Samuti oleks kliendi jaoks kasulik ka toodet või projekti nende andmetega varustada.
Testimisrakendus – tarkvara koos tööriistade ning sisendite, väljundite ja konfiguratsioonide näidistega on testimisrakendus.