Programmatūras testēšana

Programmatūras testēšana ir aktivitāšu kopums, kuru uzdevums ir identificēt problēmas programmatūrā, novērtēt tās kvalitātes pakāpi, kā arī sniegt informāciju par programmatūru un riskiem, kas saistīti ar programmatūras laišanu tirgū. Tas palīdz nodrošināt lietotāju apmierinātību ar programmatūru.^[1] Testēšanai rezultātā ir jādemonstrē sistēmas drošums vai uzticamība — sistēmas spēja izpildīt lietotāja prasības bez kļūmēm vai funkcionēšanas traucējumiem konkrētajos darbināšanas nosacījumos jeb scenārijos. Šos scenārijus svarīgi identificēt jau izstrādes laikā, lai zinātu darbības, kuras jāveic sistēmu kvalitātes pārbaudei. No tā, kādus testus izpildīs, būs atkarīga testēšanas aktivitāšu spēja atklāt pēc iespējas vairāk kļūdu.^[2]

Programmatūras testēšanu var klasificēt dažādos veidos, ņemot vērā atšķirīgus kritērijus un mērķus, uz kuriem attiecīgais iedalījums tiek izmantots. Klasiski visbiežāk izmantotais iedalījums ir 13 kategoriju sistēma, kas balstās uz koda pieejamību un informācijas par programmas uzvedību. Šāda sistēma tradicionāli tiek lietota testēšanas akadēmiskajā disciplīnā, taču tā ne vienmēr ņem vērā reālos projektu aspektus, piemēram, saistību ar programmatūras izstrādes procesiem un ekonomiskiem apsvērumiem.^[3]

Tālāk uzskaitītie testēšanas veidi:^[1]

Manuālā testēšana nozīmē, ka testēšanu veic manuāli — cilvēki vada ievaddatus programmatūrā un veic nepieciešamās darbības ar programmatūru līdzīgi kā to darīs lietotāji. Automatizētā testēšana nozīmē, ka testpiemēri tiek izpildīti un novērtēti automatizēti.

Funkcionālā testēšana nozīmē, ka tiek pārbaudīta programmatūras funkcionalitāte — darbības, ko tā veic, piemēram, ļauj veikt pārskaitījumus internetbankā, nopirkt preci internetveikalā vai parāda dokumentu un ļauj to izdrukāt. Šāda veida testēšana fokusējas uz to, vai programmatūra darbojas pareizi un atbilst tās definētajām prasībām un specifikācijām, kas apraksta tās funkcijas.

Nefunkcionālā testēšanā tiek pārbaudīti tādi programmatūras raksturlielumi, kas ir svarīgi tās lietošanā, bet tiešā veidā neietekmē tās funkcionālos rezultātus. Šāda veida testēšana sniedz informāciju par programmatūras sniegumu, lietojamību un citiem aspektiem, kas var ietekmēt tās veiktspēju un kvalitāti.

Nefunkcionālās testēšanas piemēri ietver:

• Lietojamības testēšana — vērtē programmatūras lietošanas ergonomiskumu un lietotāju draudzīgumu, lai nodrošinātu, ka lietotāji var viegli un efektīvi izmantot programmatūru.
• Veiktspējas testēšana — pārbauda, līdz kādai maksimālajai noslodzei programmatūra spēj nodrošināt savu darbību. Šajā testēšanas veidā tiek novērtēta programmatūras veiktspēja un reakcijas laiks dažādos apstākļos, piemēram, kad tā tiek izmantota lielā lietotāju skaita vai liela datu apjoma apstākļos.

Dinamiskā testēšana nozīmē programmatūras testēšanu, to darbinot, kamēr statiskā testēšana ir programmatūras pārbaude, to nedarbinot.

Statiskās testēšanas piemēri ir dažādi procesi, kuros tiek analizēta programmatūra un novērtēta tās kvalitāte un atbilstība specifikācijām. Piemēri ietver pārvaldības apskates, tehniskās apskates, koda inspekcijas, caurskates un auditus. Pārvaldības apskates rezultātā tiek sekots līdzi darbu progresam, to izpildes atbilstībai plāniem un laika grafikiem ar mērķi novērtēt pārvaldības pieeju efektivitāti un to atbilstību noteiktajiem mērķiem. Tehnisko apskatu laikā tiek vērtēta programmatūra kā produkts, vai tajā nav neatbilstības ar pielietojamajiem standartiem un noteiktajām specifikācijām. Tajās vērtē, piemēram, programmatūras specifikācijas un prasības, dokumentāciju, testēšanas un lietotāja dokumentāciju, programmatūras versijas sagatavošanas procedūras, instalācijas procedūras u.c.

Inspekcijas mērķis ir atrast kļūdas programmatūrā, pārbaudot, vai programmatūra atbilst tās specifikācijām un prasībām, vai tā atbilst noteiktajiem kvalitātes raksturlielumiem un vai tajā nav problēmu saistībā ar pirmkodu un algoritmiem. Šāda veida testēšanas pieeja palīdz nodrošināt, ka programmatūra darbojas pareizi un atbilst visiem noteiktajiem standartiem un kvalitātes prasībām.

Melnās kastes testēšana, kas arī tiek dēvēta par funkcionālo testēšanu,^[3] ir viena no testēšanas pieejām, kurā programmas iekšējā uzbūve un specifika tiek "aizmirsta". Šīs metodes mērķis ir atklāt, vai programma darbojas saskaņā ar specifikācijām, neņemot vērā tās iekšējo struktūru. Testa piemēri tiek izstrādāti, balstoties uz programmas specifikāciju, kas kalpo kā galvenais informācijas avots šajā testēšanas veidā. Lai izvairītos no milzīga testa piemēru skaita, bieži tiek izmantotas testa piemēru ekvivalences klases. Šajā pieejā testa piemēri, kas nav principiāli atšķirīgi, tiek apvienoti vienā klasē. Testēšanas procesā tiek centies pārbaudīt programmu, izmantojot vismaz vienu testa piemēru no katras ekvivalences klases.^[4]

Viena no populārākajām melnās kastes testēšanas metodēm ir programmatūras ievaddatu sadalīšana ekvivalences klasēs vai grupās, kā arī pieņemot, ka viena grupa esošie dati izraisīs līdzīgus programmatūras rezultātus un uzvedību. Citā metode — speciālo un robežvērtību testēšana — izmantojot specifikāciju, konstatē, kuras ievadu vērtības var izraisīt izņēmuma situācijas vai robežvērtības, piemēram, ja ievadlaukā var ievadīt vērtības no 1 līdz 10, tad robežvērtības būtu 1 un 10.^[1]

Baltās kastes testēšana, kas arī tiek dēvēta par strukturālo testēšanu,^[3] ir viena no testēšanas pieejām, kurā tiek analizēta programmas iekšējā struktūra un testa dati tiek veidoti, balstoties uz šīm zināšanām. Šāda veida testēšanā nav tiešas atsauces uz specifikāciju, tāpēc var rasties situācijas, kad programma ir kārtīgi notestēta, bet tajā var būt neizpildītas vai nerealizētas funkcijas. Pastāv dažādi kritēriji, pēc kuriem tiek novērtēts programmas pārklājums, un tos var iedalīt dažādās klasēs atkarībā no to sarežģītības. Piemēram, viens no vieglāk nodrošināmajiem kritērijiem ir komandu pārklājums, bet visgrūtākais var būt loģisko izteiksmju pārklājuma kritērijs. Konstatēt pārklājumu var būt izaicinošs uzdevums, taču šo procesu var atvieglot ar dažādiem testēšanas rīkiem.^[4]

Baltās kastes testēšanas metodes izmanto informāciju par programmatūras pirmkodu, tās struktūru un arhitektūru. Piemēram, vienībtestēšanas līmenī testu komplekts tiek plānots tā, lai pārbaudītu visas programmatūras pirmkodā esošās rindiņas, izvēļu zarus un nosacījumus. Pārklājuma kritērijs mēra, cik liels procents no pirmkoda ir izpildīts testēšanas laikā.^[1]

Pelēkās kastes testēšanā izmanto gan baltās, gan melnās kastes testēšanas principus. Piemēram, plāno testpiemērus, izmantojot gan specifikāciju, cenšoties noklāt visas prasības, gan arī cenšas izdarbināt visas pirmkoda rindiņas.^[1]

Kvalitātes nodrošināšanas (QA) testēšana ir būtiska programmatūras izstrādes daļa, kas nodrošina, ka programmatūra atbilst vēlamajām prasībām un ka tajā nav defektu. Ir daudz dažādu kvalitātes nodrošināšanas testēšanas veidu, un katram no tiem ir savs mērķis un metodoloģija. Izmantojot dažādos QA testēšanas veidus, programmatūras izstrādātāji var nodrošināt, ka viņu programmatūra ir kvalitatīva, atbilst vēlamajām prasībām un tajā nav defektu.^[5]

Funkcionālā testēšana, iespējams, ir visplašāk izmantotais QA testēšanas veids. Tā ietver atsevišķu programmatūras funkciju testēšanu, lai nodrošinātu, ka tās darbojas, kā paredzēts. Funkcionālā testēšana var būt manuāla vai automatizēta, un parasti tā ietver melnās kastes testēšanu, kad testētājiem nav nekādu zināšanu par kodu, un baltās kastes testēšanu, kad testētājiem ir piekļuve kodam. Funkcionālās testēšanas piemēri ir vienību testēšana, integrācijas testēšana un sistēmas testēšana.^[5] Visbiežāk ar vārdu „testēšana" tiek domāts tieši par funkcionālo testēšanu. Klasiskā situācijā programmatūras izveides mērķis ir veikt kādas iepriekš definētas 16 funkcijas, un testēšana attiecīgi ir šo funkciju implementācijas pārbaude. Šeit ir lietojamas gan strukturālās, gan funkcionālās testēšanas metodes.^[3]

Regresijas testēšana ir bieži izmantots QA testēšanas veids, kas nodrošina programmatūras atkārtotu pārbaudi pēc izmaiņu veikšanas, lai pārliecinātos, ka esošās funkcijas joprojām darbojas kā paredzēts. Šāda veida testēšana ir īpaši svarīga, ja tiek veiktas izmaiņas kritiskās funkcijās vai ja programmatūra tiek atjaunināta ar jaunām versijām. Regresijas testēšanu var veikt manuāli vai arī automatizēti, un tā ir svarīgs solis, lai novērstu nejauši ieviestas kļūdas vai neparedzētas sekas pēc veiktajām izmaiņām. Automatizēta regresijas testēšana piedāvā vairākas priekšrocības, tai skaitā samazina testēšanas laiku un nodrošina lielāku testu pārklājumu, jo testi tiek veikti automātiski.^[5]

Testēšanas process pēc izmaiņu veikšanas ietver problēmu konstatēšanu un nepieciešamības gadījumā izmaiņu veikšanu programmā. Pēc tam ir jāpārliecinās, ka izmaiņas ir ieviestas pareizi un nav negatīvi ietekmējušas esošo funkcionalitāti vai citādas nefunkcionālās īpašības. Šī atkārtotā jeb regresijas testēšana ir bieži definēts testēšanas darba režīms izstrādes projektos. Lielām programmām var būt daudz dažādu savstarpējo atkarību starp funkcijām, klasēm un moduļiem. Ja izmaiņas netiek rūpīgi pārbaudītas, problēmu novēršana varētu būt veikta nepilnīgi vai arī tās varētu radīt jaunas problēmas. Tāpēc regresijas testēšana ir ļoti noderīga, lai nodrošinātu programmatūras stabilitāti un drošību pēc veiktajām izmaiņām.^[3]

Slodzes testēšana ietver programmatūras testēšanu ar lielu slodzi, lai pārliecinātos, ka tā spēj apstrādāt paredzamo datplūsmu. Slodzes testēšana var palīdzēt noteikt šaurās vietas un mērogojamības problēmas, un to bieži izmanto, lai testētu tīmekļa lietojumprogrammas vai programmatūru, kas atkarīga no tīkla datplūsmas. Slodzes testēšanu var veikt manuāli vai automatizēti, izmantojot rīkus, kas simulē lietotāju datplūsmu un uzrauga sistēmas veiktspēju.^[5]

Drošības testēšana ir būtisks un neatņemams process, lai nodrošinātu programmatūras drošību un aizsargātu to pret ļaunprātīgiem uzbrukumiem. Šāda veida testēšana koncentrējas uz sistēmas informācijas aizsardzību un tās atbilstību definētajām drošības prasībām.

Piemēram, tā var pārliecināties, vai visi lietotāji var apskatīt sistēmas informāciju, bet tikai atsevišķi lietotāji var veikt izmaiņas, vai arī vai piekļuve informācijai ir iespējama tikai ar īpašu autentifikācijas mehānismu palīdzību. Tomēr, lai drošības testēšana būtu efektīva, metodes ir jābalsta uz jaunākajām zināšanām par dažādām uzlaušanas, nograušanas, darbības traucēšanas un spiegošanas metodēm.^[3] Drošības prasības varētu būt definētas ilgstošam laikam, bet ikvienu testu un drošības atzinumu var ietekmēt jauni un neparedzēti apdraudējumi un uzbrukumi.^[5]

Viena no galvenajām īpatnībām, kas atšķir drošības testēšanu no funkcionālās testēšanas, ir tā, ka drošības testēšanas rezultāti var kļūt nederīgi neparedzamā laikā, jo parādās jaunas metodes un tehnoloģijas, kā pārkāpt aizsardzības mehānismus. Ikreiz, kad ļaundari izstrādā jaunu ielaušanās metodi, tas kļūst par jaunu izaicinājumu drošības testēšanai.^[3]

Lietderības testēšana ietver programmatūras testēšanu no gala lietotāja viedokļa, lai nodrošinātu, ka tā ir viegli lietojama un saprotama. Lietderības testēšana var ietvert lietojamības testēšanu, lietotāja pieņemšanas testēšanu un lietotāja pieredzes testēšanu. Šāda veida testēšana var palīdzēt identificēt lietojamības problēmas un ieteikt uzlabojumus programmatūras dizainā. Ir daudz dažādu kvalitātes nodrošināšanas testēšanas veidu, un katram no tiem ir savs mērķis un metodoloģija.^[5]

Pieejamības testēšana ir daļa no izmantojamības testēšanas. Tā nepieciešama, lai nodrošinātu lietojumprogrammu kvalitāti un atbilstību jaunākajiem izstrādes noteikumiem. Digitālā pieejamība cenšas nodrošināt digitālo produktu un satura pieejamību ikvienam, tostarp cilvēkiem ar dažādiem uztveres traucējumiem.

Ar 2025 gada 28. jūniju stāsies spēkā ES tiesību akts par pieejamību, nosakot, ka ikvienam uzņēmumam Eiropā ir jānodrošina brīva piekļuve digitālajiem produktiem cilvēkiem ar dažādiem traucējumiem.^[6][7]

Vienībtestēšana (angļu: Unit testing) ir viens no veidiem, kā pārbaudīt un apstiprināt programmatūras kodu, nodrošinot, ka katru vienību, kas veido programmu, testē atsevišķi, lai pārliecinātos par to pareizu darbību, saskaņā ar specifikāciju. Šo veidu parasti veic paši izstrādātāji, kuri radījuši šo kodu.^[1]

Vienībtesti ir īpaši noderīgi, lai pārbaudītu vienkāršus kodu fragmentus, bet kļūst grūtāki un laikietilpīgāki, ja kods ir sarežģīts, izmanto sarežģītus algoritmus vai ir liela ievades un izvades datu apstrādes daudzveidība. Tomēr, vienībtestēšana ir ļoti svarīga, jo tā palīdz ātri identificēt un novērst kļūdas, kad tās ir tikai kodētāja atbildības jomā, nevis jau integrētās sistēmas mērogā. Vienībtestēšana ietilpst baltās kastes testēšanas kategorijā. Tas nozīmē, ka testētājs ir informēts par kodu un var iegūt pilnīgu sapratni par to, kas notiek iekšēji, pārbaudot dažādus datu plūsmas posmus un funkcionalitāti, iespējamo ievades un izvades datu atbilstību.^[8]

Vienībtesti var būt divu veidu: automātiski un pašrocīgi. Automātiskos testus programmētāji izveido paši, un tie ir vairāk ieteicami lielākiem projektiem, jo tie palīdz strādāt efektīvāk un atkārtoti, ļaujot identificēt kļūdas jau agrīnā izstrādes posmā. Automātisko testu veidošana var prasīt papildu laiku, bet tas atpūšas, kad tiek izveidoti daudzi modeļi un vienības.

Vienībtestu izstrāde ietver testēšanas gadījumu izveidi, to pārbaudi un labojumu, kā arī sistēmas bāzes noteikumu noteikšanu. Testētāji parasti pārbauda galveno izpildes ceļu, sazarojumus, ciklus un kopējo datu pārskatu. Vienībtestēšanai var izmantot dažādas testēšanas programmatūras veidus dažādām valodām, piemēram, Junit, NUnit, JMockit, EMMA, PHPUnit u. c.

Integrācijas testēšana nozīmē pārbaudīt vienas vai vairāku izveidotu programmatūras komponenšu sasvstarpējās sadarbības pārbaudi. Integrācijas testēšanu veic vai nu izstrādātāji (nelielām komponentēm vai programmatūras daļām) vai testētāji — lielām programmatūras daļām, piemēram, dažādu apakšsistēmu integrācijas testēšanu. Integrācijas testēšanu var veikt dažādos veidos — no lejas uz augšu, no augšas uz leju un pēc sviestmaizes principa — jaukti, t.i., daļu programmatūras testēt no augša uz leju, daļu no lejas uz augšu, vadoties no iespējām un nepieciešamības katrā konkrētajā situācijā.^[1]

Sistēmtestēšana nozīmē, ka tiek veikti testi, kās pārbauda izstrādājamo programmatūru kopumā, pēc iespējas testos iesaistot visas izstrādātās programmatūras komponentes, kā arī pārbaudot sadarbību ar citu ārējo programmatūru, piemēram, pieslēgumus ar valsts nozīmes sistēmām, no kurām saņem vai kam nosūta informāciju. Sistēmtestēšanu parasti veic testētāji, nevis programmētāji.^[1]

Akcepttestēšana ir būtisks posms programmatūras izstrādes beigās, kad tiek pārbaudīta visa sistēma, lai nodrošinātu, vai tā atbilst specifikācijai, ir pietiekama, darbojas un ir gatava ieviešanai un nodošanai. Tās galvenie mērķi ir atrast kļūdas, kas varētu nebūt pamanītas iepriekšējās testēšanas stadijās, pārbaudīt, vai produkts atbilst specifikācijas prasībām, izpētīt, cik labi produkts ir izstrādāts, un pārbaudīt kopējo funkcionalitāti. Akcepttestēšana tiek veikta, izmantojot melnās kastes testēšanas principus, kur nav nepieciešams zināt programmas iekšējo uzbūvi, bet tikai ievadīt datus un salīdzināt tos ar sagaidāmo izvades rezultātu. Akcepttestēšanai ir arī savi mīnusi. Tā parasti tiek izmantota lietotāju puses pārbaudei, un tas nozīmē, ka lietotājam ir jāsaprot, ko produkts spēj darīt, lai varētu to pārbaudīt. Tas var būt sarežģīti un prasīt lielu lietotāja iesaisti un apmācību.^[9]

Akcepttestēšana ir turpmāko sistēmas lietotāju veikta testēšana apstākļos, kas tuvināti produkcijas vides apstākļiem. Tā demonstrē, vai izstrādātā sistēma atbilst izvirzītajām funkcionalitātes un kvalitātes prasībām. Akcepttestēšana ir būtiska, jo tā ļauj pasūtītājam apstiprināt, ka produkts atbilst viņa izvirzītajām prasībām un ir gatavs lietošanai. Akcepttestēšana var ietvert dažādus paveidus, tostarp funkcionālos akcepttestus, produkcijas akcepttestus un lietojamības testus. Lietotājiem akcepttestēšanā ir svarīgi veikt dažādas funkcijas, piemēram, definēt prasības, noteikt akcepta kritērijus, izveidot testu plānu, veikt testus un novērtēt dokumentāciju un testu rezultātus. Arī svarīgi aktīvi piedalīties akcepttestēšanā, definēt prasības, noteikt biznesa riskus, izveidot testu plānus un scenārijus, izpildīt testus un novērtēt testu rezultātus. Akcepttestēšanas plānu un testpiemērus ir jāizveido reizē ar prasībām, lai nodrošinātu pārbaudes precizitāti un saskaņotību ar izstrādāto produktu.^[1]

• Tradicionālais ūdenskrituma izstrādes modelis — Izstrādē ar ūdenskritumu ir izplatīta prakse, ka testēšanu veic neatkarīga testētāju grupa.
• Spējā vai XP izstrādes modelis — Turpretī dažās jaunās programmatūras disciplīnās, piemēram, ekstrēmā programmatūras izstrāde^[10] un spējā programmatūras izstrādes kustībā, tiek ievērots "testu virzīta izstrāde"^[11] modelis. Šajā procesā programmatūras inženieri vispirms raksta vienības testus (bieži vien ekstrēmās programmēšanas metodoloģijā izmanto pāru programmēšanu).

Testēšana nodrošina programmu kvalitāti un pareizu darbību. Tomēr viens no šķēršļiem šādu testēšanas procesu efektīvai organizēšanai ir tas, ka ne visas testēšanas pieejas un metodes ir pilnībā formalizētas un standartizētas. Tas var radīt neskaidrību un atšķirīgas interpretācijas dažādās organizācijās, kurās darbojas testētāji.^[3]

Lai risinātu šo problēmu un panāktu vienotāku pieeju programmatūras testēšanai, tika izveidoti vairāki standarti. Viens no pirmajiem sasniegumiem šajā virzienā bija standarti BS 7925-1:1998 un BS 7925-2:1998. Pirmā standarta mērķis bija definēt vairāk nekā divsimt terminus, kas saistīti ar testēšanu, savukārt otrajā standartā tika formalizētas testēšanas metodes, kas iepriekš bija aprakstītas galvenokārt akadēmiskās literatūras ietvaros.

Tradicionāli, testētāji strādā speciālā struktūrvienībā, ko sauc par testēšanas laboratoriju, kur tiek veikta vienību testēšana. Taču, IT jomā ir izstrādāts speciāls ceļvedis (ISO/IEC TR 13233:1995), kas piemēro standartu ISO/IEC 17025:2001 informācijas tehnoloģiju un telekomunikāciju testēšanas laboratorijām. Šāds ceļvedis palīdz izstrādāt labāku sistēmu testēšanas un akreditācijas procesu informācijas tehnoloģiju nozarē.

Ir dažādi standarti, tādi kā:^[12]

• IEEE 829-2008 — Standarts programmatūras un testēšanas dokumentācijai
• IEEE 1028-2008 — Standarts programmatūras caurskatīšanai un auditam
• IEEE 12207-2008 — Standarts par programmatūras dzīves cikla procesiem
• ISO/IEC 9126-1:2001 — Standarts par programmatūras produkta kvalitāti

Testēšanu kā kvalitātes aktivitāti reglamentē virkne IT nozares standartu. Saskaņā ar standartu ISO/IEC 12207:1995 (jeb 2002. gadā apstiprināto Valsts standartu LVS ISO/IEC 12207:2002 Programmatūras dzīves cikla procesi) tai ir jānotiek kopā ar programmas koda izveidi, kā ari pie produkta nodošanas pasūtītājam. Pielāgojot standartu lietošanai konkrētā organizācijā vai projektā, testēšanu var definēt kā vienu no pamatprocesiem. Detalizēti testēšanas prasības ir atspoguļotas arī standartā J-Std-016-1995, kas pamatā ir orientēts uz ISO/IEC 12207 definētā izstrādes procesa detalizāciju. Tieši J-Std-016 ir daudzās Latvijas IT organizācijās kļuvis par praksē izmantoto standartu dokumentācijas komplekta satura un formas noteikšanai. Lai ari ir sastopamas norādes, ka šis standarts netiks turpmāk attīstīts, to kāda IT organizāciju kopa var attīstīt savos ietvaros, pielāgojot jaunām kvalitātes tendencēm. Testēšanai tas definē trīs savstarpēji saistītus dokumentus: testēšanas plānu, testu aprakstu un testēšanas pārskatu. Jāatzīmē, ka papildus iepriekšminētajiem ir ari standarts 1465- 1998 IEEE (12119:1998 ISO/IEC), kas izvirza specifiskās prasības tieši pakotņu programmatūrai.^[3]

• EIA/IEEE J-Std-016-1995 — Software Development Acquirer-Supplier Agreement
• IEEE 1465-1998 (ISO/IEC 12119:1998) — Quality Requirements and Testing

Latvijā kopš 1996. gada ir divi standarti, kas ir tiešā veidā attiecināmi uz testēšanu informācijas tehnoloģiju jomā (pārējās testēšanas jomās to kopskaitā ir vairāki desmiti).^[3]

• LVS 70:1996 — Programmatūras testēšanas dokumentācija
• LVS 73:1996 — Programmatūras vienībtestēšanas dokumentācija

Abi ir atbilstošo IEEE standartu adaptējumi: attiecīgi ANSI/IEEE Std 829-1983 (pašlaik jaunākā versija — 829-1998) un ANSI/IEEE Std 1008-1987. Pirmais definē pieeju tam, kādai ir jābūt testēšanas dokumentācijai programmatūras projektos, savukārt otrais nosaka vienībtestēšanas (programmas funkciju, moduļu pārbaudes) procesu. Mūsdienu programminženierijas metodes ir visai daudzveidīgas, un vairumā gadījumu reālos projektos nav racionāli burtiskā veidā pielietot LVS 73:1996.

Papildus iepriekšminētajiem ir arī standarts LVS 71:1996, kas ari ir atbilstošā IEEE standarta adaptējums. Tas definē testēšanu kā vienu no validēšanas un verificēšanas metodēm. Praksē bieži pasūtītāja un izpildītāja vienošanās par izveidojamo dokumentāciju neparedz testēšanas dokumentāciju, vai arī tā tiek noteikta ļoti konspektīva.

• LVS 71:1996 — Programmatūras verifikācijas un validācijas plāns

Pamatraksts: Programmatūras verifikācija un validācija

Programmu verifikācija un validācija ir divi atšķirīgi procesi, kas saistīti ar programmatūras kvalitātes testēšanu. Verifikācija aptver aktivitātes, kas nodrošina, ka programmatūrā pareizi implementēta konkrēta funkcija. Process, kurš tiek veikts visa produkta dzīves cikla laikā, lai pārliecinātos par dažādu programmas izstrādes starpproduktu atbilstību izvirzītajām prasībām. Verifikācijas procesos parasti ietilpst dažādu dokumentu, plānu, koda, prasību un specifikācijas pārbaudes, analīzes, inspekcijas un apskates. Verifikācija ir sistēmas pārbaude, ko parasti veic tās izstrādāšanas gaitā, lai pārliecinātos, vai izstrādāšanas procesā aplūkojamā posma rezultāti atbilst tā sākumā definētajiem noteikumiem un prasībām.^[2][4] Validācija aptver citas aktivitātes, kas nodrošina, ka izstrādātā programmatūra ir trasējama uz klienta prasībām.

Pamatraksts: Programmatūras kvalitātes nodrošināšana

Kvalitātes nodrošināšana nozīmē, ka procesi organizācijā tiek veikti un pielietoti korekti, atbilstoši nozares labākajai vai rekomendētajai praksei. Nepārtraukti procesu uzlabojumi uzlabo to efektivitāti un lietderīgumu. Kvalitātes nodrošināšanas viens no mērķiem ir augstāku izstrādes un testēšanas brieduma līmeņa sasniegšana.^[1]

s d l Programminženierija Process Programmēšana Programmatūras izstrāde Programmatūras izvietošana Programmatūras projektēšana Programmatūras uzturēšana Programmatūras testēšana Sistēmu analīze Koncepcijas Datu modelēšana Funkcionālā specifikācija Programmēšanas paradigma Programmatūra Programmatūras arheoloģija Programmatūras arhitektūra Programmatūras izstrādes process/metodoloģijas Programmatūras kvalitāte Programmatūras kvalitātes nodrošināšana Programmatūras verifikācija un validācija Orientācija Spējā programmatūras izstrāde Objektorientētā Ontoloģija Pakalpojumu orientētā Saistītās jomas Datorzinātne Datorinženierija Informācijas zinātne Projektu vadība Riska vadība Sistēmu inženierija Commons Kategorija