Testimi i softuerit

[parapamje|TestingCup – Kampionati Polake në Testimin e Softuerëve, [Katovica|Katowice, Maj 2016]]
**Testimi i softuerit** është procesi i vlerësimit të një sistem softuerik për të kontrolluar nëse ai plotëson kërkesat e specifikuara dhe i përmbush qëllimet e synuara.

Përmes testimit të softuerit, ofrohet informacion i pavarur dhe objektiv në lidhje me cilësinë e produktit softuerik dhe rreziqet e mundshme të dështimit të tij, në shërbim të përdoruesve, sponsorëve apo çdo pale tjetër të interesuar. 

Megjithëse testimi i softuerit mund të verifikojë saktësinë e tij për raste specifike, ai nuk mund të garantojë saktësinë për të gjitha skenarët   e mundshëm  dhe nuk është në gjendje të zbulojë të gjitha gabimet e ekzistuara.

Për të matur saktësinë e një softueri nëpërmjet një *orakulli* (burimi referencë), testimi përdor parime dhe mekanizma të caktuara për identifikimin e problemeve. Shembuj të orakujve përfshijnë: specifikimet, kontratat, [1] produkte të krahasueshme, versionet e mëparshme të të njëjtit produkt, përfundimet në lidhje me qëllimin e synuar ose të pritur, pritjet e përdoruesit apo klientit, standardet përkatëse dhe ligjet në fuqi.

Testimi i softuerit edhe proces qe mund te jete funksional apo jofunskional.

Testimi i softuerit mund të jetë dinamik ose statik në natyrë. Në formën e tij dinamike, ai përfshin ekzekutimin e softuerit për të krahasuar rezultatet aktuale me ato të pritura. Ndërsa në formën statike, ai përfshin rishikimin e kodit burimor dhe të dokumentacionit përkatës pa ekzekutuar programin.

Testimi i softuerit përdoret shpesh për t'iu përgjigjur pyetjes: A bën softueri atë që duhet të bëjë dhe atë që duhet të bëjë?

Informacioni i nxjerrë nga testimi i softuerëve mund të përdoret për të përmirësuar procesin me të cilin zhvillohet softueri.  

Një qasje e zakonshme dhe e rekomanduar për testimin e automatizuar është ajo e "piramidës së testimit". Sipas saj, shumica e testeve duhet të jenë teste njësie, të cilat formojnë bazën e gjerë. Mbi to ndërtohet një grup më i ngushtë testesh integrimi, ndërsa në majë vendosen vetëm disa teste end‑to‑end (e2e). 

## Ekonomi 
Një studim i NIST-së nga viti 2002 tregoi se gabimet në softuer shkaktonin humbje vjetore

prej 59.5 miliardë dollarë për ekonominë e Shteteve të Bashkuara. Sipas studimit, më

shumë se një e treta e këtyre humbjeve mund të parandalohej me një qasje më efektive

ndaj testimit të softuerit.

Testimi i softuerëve me kontratë për shkak të kostove është shumë i zakonshëm, me Kinën, Filipinet dhe Indinë si destinacionet e preferuara. 

## Histori 
Glenford J. Myers e prezantoi për herë të parë ndarjen e debugging-ut nga testimi në vitin 1979.  Megjithëse qëndrimi i tij ishte i përqendruar tek testimi për zbulimin e defekteve (duke theksuar se *“një rast testimi i suksesshëm është ai që zbulon një gabim ende të pazbuluar” , ai në fakt ilustroi synimin e komunitetit të inxhinierisë së softuerit për të dalluar aktivitetet themelore të zhvillimit, si debugging-u, nga veprimtaritë e verifikimit.  

Në praktikë, testimi i softuerit shpesh përfshin trajtimin e *gabimeve* të softuerit – pra, të defekteve në kod që shkaktojnë rezultate të padëshiruara. Këto gabime zakonisht ngadalësojnë progresin e testimit dhe kërkojnë ndërhyrjen e programuesit për ti identifikuar dhe korrigjuar përmes debugging-ut.

Jo të gjitha defektet shkaktojnë një dështim. Për shembull, një defekt në kodin e vdekur nuk do të konsiderohet dështim.

Një defekt mund të mos shfaqë menjëherë dështim, por të çojë në pasojat e tij më vonë kur ndryshojnë kushtet e mjedisit ku operon sistemi. Këto ndryshime mund të përfshijnë kalimin në harduer të ri, modifikime në rrjedhat e të dhënave ose ndërveprime me softuerë të tjerë të përditësuar ose të rinj. 

## Synimet 
Testimi i softuerëve zakonisht udhëhiqet nga qëllimet.

### Gjetja e defekteve 
Në kuadrin e testimit të softuerit, një pjesë e rëndësishme është trajtimi i gabimeve  pra, i atyre defekteve në kod që çojnë në rezultate të padëshiruara ose të pasakta.  Këto gabime jo vetëm që pengojnë ecjen normale të testimit, por shpesh kërkojnë ndërhyrjen e programuesit për të identifikuar burimin e problemit (debugging) dhe për të bërë korrigjimet e nevojshme.

Një defekt që nuk shkakton dështim në një moment të caktuar mund të çojë në dështim më vonë për shkak të ndryshimeve mjedisore. Shembuj të ndryshimit të mjedisit përfshijnë funksionimin në harduer të ri kompjuterik, ndryshimet në të dhëna dhe bashkëveprimin me softuerë të ndryshëm. 

Një defekt i vetëm mund të shkaktojë simptoma të shumëfishta të dështimit.

### Sigurimi që kërkesat janë përmbushur 
Testimi i softuerit mund të përfshijë një boshllëk në Kërkesa – heqje nga dizajni i një kërkese. 

### Testimi i automatizuar 
### Nivelet 
Testimi i softuerëve mund të kategorizohet në nivele bazuar në atë se sa nga sistemi i softuerëve është fokusi i një testi.    

#### Testimi i njësisë 
#### Testimi i integrimit 
#### Testimi i sistemit 
### Testimi statik, dinamik dhe pasiv 
Ekzistojnë shumë qasje ndaj testimit të softuerëve. Rishikimet, hapat përpara ose inspektimet quhen testime statike, ndërsa ekzekutimi i kodit të programuar me një grup të caktuar rastesh testimi quhet testim dinamik .  

Testimi statik zhvillohet shpesh në mënyrë implicite, përmes korrigjimeve të thjeshta, si dhe kur mjetet e programimit ose redaktorët e tekstit kontrollojnë strukturën e kodit burimor, ose kur kompiluesit (ose parapërpunuesit) analizojnë sintaksën dhe rrjedhën e të dhënave nëpërmjet analizës statike të programit.  

Testimi dinamik, nga ana tjetër, kryhet kur programi ekzekutohet. Ky lloj testimi mund të fillojë edhe para se programi të jetë 100% i plotë, me qëllim që të vlerësohen seksione të veçanta të kodit ose modulet dhe funksionet diskrete.  Teknika tipike për këtë qasje përfshijnë përdorimin e stub-ave / driver-ave ose ekzekutimin e programit përmes një mjedisi debuggeri. 

Testimi statik përfshin verifikimin, ndërsa testimi dinamik përfshin edhe validimin .  

* Testimi i API-t – testimi i aplikacionit duke përdorur API publike dhe private (ndërfaqe programimi aplikacionesh)
* Mbulimi i kodit – krijimi i testeve për të përmbushur disa kritere të mbulimit të kodit (për shembull, projektuesi i testeve mund të krijojë teste për të bërë që të gjitha deklaratat në program të ekzekutohen të paktën një herë)
* Metodat e injektimit të defekteve - futja e qëllimshme e defekteve për të vlerësuar efikasitetin e strategjive të testimit
* Metodat e testimit të mutacionit
* Metodat e testimit statik

Mjetet e mbulimit të kodit mund të vlerësojnë plotësinë e një grupi testesh – të krijuar me çdo metodë, duke përfshirë edhe testimin e kutisë së zezë. Ato mund t'i ndihmojnë ekipin e softuerit të identifikojë pjesët e sistemit që rrallë ose kurrë nuk janë testuar dhe të sigurojnë që pikat më kritike funksionale të jenë të mbuluara nga testet.  

Mbulimi i kodit, si një metrikë e softuerit, zakonisht raportohet në formë përqindje për aspektet si: 

:* *Mbulimi i funksioneve*, i cili raporton mbi funksionet e ekzekutuara
:* *Mbulimi i deklaratës*, i cili raporton numrin e rreshtave të ekzekutuara për të përfunduar testin.
:* *Mbulimi i vendimit*, i cili raporton nëse dega e Vërtetë dhe e Gabuar e një testi të caktuar është ekzekutuar.

Arritja e 100% mbulimit të deklaratave garanton që çdo rresht kod në një program është ekzekutuar të paktën një herë gjatë testimit, duke mbuluar të gjitha degëzimet e mundshme në rrjedhën e kontrollit. Megjithëse ky tregues ndihmon në sigurimin e kompletësisë së ekzekutimit, ai nuk garanton korrektësinë e softuerit, pasi i njëjti kod mund të prodhojë rezultate të pasakta për disa vlera hyrëse të caktuara, edhe nëse është ekzekutuar plotësisht. 

#### Testimi i kutisë së zezë 
parapamje|Diagrami i kutisë së zezë
Testimi i kutisë së zezë, i njohur gjithashtu si testim funksional, është një qasje testimi ku rastet testuese hartohen bazuar vetëm në specifikimet dhe kërkesat e softuerit, pa pasur njohuri të brendshme për implementimin e kodit. Testuesi nuk sheh kodin burimor dhe fokusohet vetëm në sjelljen e daljes në përgjigje të hyrjeve të dhëna. 

Metodat kryesore të kësaj qasjeje përfshijnë:  

* Ndarjen e ekuivalencës dhe analizën e vlerës kufitare.  
* Testimin e të gjitha çifteve.  
* Tabelat e tranzicionit të gjendjes dhe tabelat e vendimeve.  
* Testimin fuzz dhe testimin e bazuar në model.  
* Testimin e rasteve të përdorimit, testimin eksplorues dhe testimin e bazuar në specifikime. 

Testimi i bazuar në specifikimeka si qëllim verifikimin e funksionalitetit të softuerit sipas kërkesave përkatëse. Ky nivel testimi zakonisht kërkon nga testuesit që të hartojnë raste të hollësishme testimi, të cilat më pas shërbejnë për të verifikuar nëse për një të dhënë hyrëse, rezultati (ose sjellja) dalëse përputhet me vlerën e pritur të përcaktuar në rastin testues.

Rastet e testimit ndërtohen rreth specifikimeve dhe kërkesave – pra, atë që duhet të kryejë aplikacioni. Qasja përdor përshkrime të jashtme të softuerit, duke përfshirë specifikimet, kërkesat dhe modelet e dizajnit, për të nxjerrë raste testimi. Këto teste mund të jenë funksionale ose jofunksionale, edhe pjesa më e madhe e tyre ka natyrë funksionale.

Testimi i bazuar në specifikime është i nevojshëm për të siguruar funksionalitet të saktë, por vetëm ai nuk mjafton për të mbrojtur softuerin nga situata komplekse ose me rrezik të lartë. 

Testimi i kutisë së zezë mund të përdoret për çdo nivel testimi, megjithëse zakonisht jo në nivel njësie. 

**Testimi i ndërfaqes së komponentëve**

Testimi i ndërfaqes së komponentëve është një variant i testimit të kutisë së zezë, i cili fokusohet në vlerat e të dhënave që kalojnë përmes veprimeve të ndërveprimit midis komponentëve të një nënsistemi. Kjo praktikë testimi mund të përdoret për të kontrolluar trajtimin e të dhënave të transferuara midis njësive ose komponentëve të ndryshëm, pa arritur në nivelin e një testimi të plotë të integrimit midis tyre. 

Të dhënat e kaluara mund të konsiderohen si "njësi të dhënash" (paketa mesazhesh), dhe gjatë testimit mund të verifikohen diapazoni dhe llojet e tyre për të dhënat e gjeneruara nga një njësi, përpara se ato të kalojnë në njësinë tjetër. Një mundësi për këtë lloj testimi është ruajtja e një skedari regjistrues (log) të veçantë për të dhënat e transferuara, i cili shpesh përfshin edhe vulën kohore për të lejuar analizën e mijëra rasteve të të dhënave të kaluara midis njësive gjatë periudhave ditore ose javore.

Testet mund të përfshijnë kontrollin e trajtimit të vlerave ekstreme të të dhënave, ndërsa variablat e tjerë të ndërfaqes kalojnë si vlera normale. Vlerat e pazakonta të të dhënave në një ndërfaqe mund të ndihmojnë në sqarimin e sjelljeve të papritura ose të çuditshme në njësinë tjetër.

##### Testimi vizual 
Testimi vizual ka si qëllim t'i mundësojë zhvilluesve të analizojnë atë çfarë ndodhi në momentin e dështimit të një softueri, duke i paraqitur të dhënat në një format të përpunueshëm dhe të lehtësisht të kuptueshëm. Nëpërmjet paraqitjes së qartë dhe të organizuar të informacionit, ky lloj testimi lejon që zhvilluesit të identifikojnë shpejt dhe me saktësi faktortët kryesorë që shkaktuan problemin. 

Testimi vizual bazohet në parimin se paraqitja vizuale e një problemi (ose e një dështimi testimi) ofron një kuptim shumë më të thellë dhe më të qartë sesa thjesht përshkrimi i tij me fjalë. Për këtë arsye, ky lloj testimi kërkon regjistrimin e plotë të procesit të testimit — duke kapur në video të gjitha aktivitetet që ndodhin në sistemin e testimit. Regjistrimet video plotësohen më pas me pamje në kohë reale të testuesit përmes një kamere interneti (në formatin “figurë brenda figurës”) dhe me komente audio nga mikrofonat.

Testimi vizual sjell disa përparësi të rëndësishme. Cilësia e komunikimit përmirësohet ndjeshëm, sepse testuesit mund t'ia tregojnë zhvilluesve problemin (dhe ngjarjet që e shkaktuan) në mënyrë vizuale, në vend që ta përshkruajnë atë vetëm me fjalë. Në shumë raste, nevoja për të replikuar dështimet e testimit zhduket plotësisht. Kjo i ofron zhvilluesit të gjitha provat e nevojshme për dështimin, duke i lejuar të përqendrohet menjëherë në shkakun rrënjësor të defektit dhe mënyrën se si duhet të korrigjohet.

Testimi ad hoc dhe testimi eksplorues janë dy qasje testimi që bazohen më shumë në kreativitetin dhe përvojën e testuesit sesa në plane të para‑përcaktuara. Ato janë veçanërisht të dobishme për zbulimin e shpejtë të defekteve të rëndësishme, duke kërkuar kohë përgatitore shumë të shkurtër. 

Në testimin ad hoc, testuesi fillon nga metoda bazë të dokumentuara, por pastaj improvizon dhe ndryshon ato në kohë reale, duke bërë që ekzaminimi i rregullimeve të defekteve të bëhet më i thellë dhe më rigoroz. Megjithatë, kufizimi kryesor i kësaj metode është mungesa e përsëritshmërisë nëse procedurat nuk dokumentohen me kujdes. 

#### Testimi i kutisë gri 
Në zhvillimin e softuerit, matrica e gjurmuarjes (TM)  është një dokument, zakonisht në formë tabele, i përdorur për të ndihmuar në përcaktimin e plotësisë së një marrëdhënieje duke korreluar çdo dy dokumente bazë me njëra‑tjetrën përmes një krahasimi me marrëdhënie shumë‑me‑shumë. Ajo shpesh përdoret për të lidhur kërkesat e nivelit të lartë (që shpesh përbëhen nga kërkesat e marketingut) dhe kërkesat e detajuara të produktit me pjesët përkatëse të projektimit të nivelit të lartë, projektimit të detajuar, planit të testimit dhe rasteve testuese.

Testimi me kuti gri është një qasje hibride ku testuesi përdor njohuri të pjesshme të strukturave të brendshme të sistemit (si algoritmet ose strukturat e të dhënave) për të hartuar teste, por i kryen ato në nivelin e ndërfaqes së përdoruesit – pra, si në testimin e kutisë së zezë. Testuesit shpesh kanë qasje si në kodin burimor ashtu edhe në versionin e përpiluar ekzekutues. 

Kjo metodë mund të përfshijë edhe inxhinieri të kundërt (përmes analizës dinamike) për të identifikuar, për shembull, vlerat kufitare ose mesazhet e gabimit. Megjithatë, manipulimi i thjeshtë i të dhënave hyrëse-dalëse nuk konsiderohet testim me kuti gri, pasi ato janë tashmë pjesë e dukurive të dukshme të "kutisë së zezë". Ky dallim është veçanërisht i rëndësishëm në testimin e integrimit midis moduleve të ndërtuara nga zhvillues të ndryshëm, ku vetëm ndërfaqet e ekspozuara janë objekt testimi.

Testimi i kutisë gri është një qasje testimi ku testuesi përdor njohuri bazë të mënyrës së funksionimit të sistemit për të hartuar teste më të mençura, duke e vlerësuar atë nga jashtë. Zakonisht, testuesi mund të krijojë një mjedis testimi të izoluar ku kryen veprime si mbushjen e një baze të dhënash me të dhëna fillestare. Gjatë testimit, ai mund të vëzhgojë gjendjen e sistemit pas çdo veprimi – për shembull, duke ekzekutuar komanda SQL dhe duke kontrolluar nëse ndryshimet e pritura shfaqen siç duhet në bazën e të dhënave. Kjo metodë fokusohet në skenarë testimi të mençur për aspekte të tilla si trajtimi i llojeve të të dhënave dhe i përjashtimeve, duke u mbështetur në informacion të kufizuar për brendësinë e sistemit. 

Me konceptin e testimit të kutisë gri, ky "dallim arbitrar" midis testimit të kutisë së zezë dhe të bardhë është zbehur disi.    

Testimi i pranimit mund të kryhet si pjesë e procesit të kalimit të përgjegjësisë midis dy fazave të zhvillimit. &#x5B; '''' &#x5D;

Testet shpesh grupohen në këto nivele sipas vendit ku kryhen në procesin e zhvillimit të softuerit, ose sipas nivelit të specifikës së testit. 

* Disa mesazhe mund të jenë të papërkthyera.
* Softueri shpesh lokalizohet duke përkthyer një listë vargjesh jashtë kontekstit, dhe përkthyesi mund të zgjedhë përkthimin e gabuar për një varg burimor të paqartë.
* Terminologjia teknike mund të bëhet e paqëndrueshme nëse projekti përkthehet nga disa persona pa koordinim të duhur ose nëse përkthyesi është i pakujdesshëm.
* Përkthimet fjalë për fjalë mund të tingëllojnë të papërshtatshme, artificiale ose shumë teknike në gjuhën e synuar.
* Mesazhet e papërkthyera në gjuhën origjinale mund të jenë të koduara në kodin burimor dhe, si të tilla, të papërkthyeshme.
* Disa mesazhe mund të krijohen automatikisht gjatë kohës së ekzekutimit dhe vargu që rezulton mund të jetë jo gramatikor, funksionalisht i pasaktë, mashtrues ose konfuz.
* Softueri mund të përdorë një shkurtore tastiere që nuk ka funksion në paraqitjen e tastierës së gjuhës burimore, por përdoret për të shtypur karaktere në paraqitjen e gjuhës së synuar.
* Softueri mund të mos ketë mbështetje për kodimin e karaktereve të gjuhës së synuar.
* Shkronjat dhe madhësitë e shkronjave që janë të përshtatshme në gjuhën burimore mund të jenë të papërshtatshme në gjuhën e synuar; për shembull, karakteret CJK mund të bëhen të palexueshme nëse shkronja është shumë e vogël.
* Një varg në gjuhën e synuar mund të jetë më i gjatë nga sa mund të trajtojë softueri. Kjo mund ta bëjë vargun pjesërisht të padukshëm për përdoruesin ose të shkaktojë bllokim ose keqfunksionim të softuerit.
* Softuerit mund t'i mungojë mbështetja e duhur për leximin ose shkrimin e tekstit dypalësh .
* Softueri mund të shfaqë imazhe me tekst që nuk është lokalizuar.
* Sistemet operative të lokalizuara mund të kenë skedarë konfigurimi të sistemit dhe variabla mjedisi me emërtime të ndryshme, si dhe formate të ndryshme për datën dhe monedhën .

Një matricë gjurmuese është një dokument tabelor që përdoret në menaxhimin e kërkesave për të pasqyruar marrëdhëniet ndërmjet komponentëve të ndryshëm të një projekti softuerik. Ajo lidh në mënyrë sistematike kërkesat e biznesit me specifikimet teknike dhe me rastet testuese përkatëse. Kjo strukturë lejon verifikimin e plotësisë, duke siguruar që çdo kërkesë të gjurmohet nëpër dizajn dhe testim dhe që asnjë specifikim të mos anashkalohet gjatë zhvillimit.

Bazuar në kërkesat dhe parashikimet e organizatës për zhvillimin e softuerit, procesi i testimit gjatë kësaj faze mund të përfshijë një sërë praktikash, si:

*    Shqyrtimi statik i kodit burimor.

*   Analiza e rrjedhës së të dhënave dhe e metrikave të kodit.

*   Rishikime të kodit nga kolegët (peer review).
*  Testimi i njësive (unit testing) dhe matja e mbulimit të kodit.
*   Verifikimi i gjurmueshmërisë së kërkesave.  
*    Zbatimi i metodave të tjera të testimit të softuerit të përshtatshme për fazën.

### Testimi A/B 
Shumica e sistemeve softuerike kanë procedura instalimi që duhen kryer përpara se të mund të përdoren për qëllimin e tyre kryesor. Testimi i këtyre procedurave për të arritur një sistem softuerik të instaluar dhe të përdorshëm quhet testim instalimi. Këto procedura mund të përfshijnë përmirësime të plota ose të pjesshme, si dhe procese instalimi/çinstalimi.

Gjatë këtij testimi merren parasysh faktorë të tillë si:

- Përdoruesi duhet të zgjedhë një sërë opsionesh.

- Filet dhe bibliotekat e varura duhet të alokohen, të ngarkohen ose të lokalizohen.

- Konfigurimet e nevojshme të hardware-it duhet të jenë të pranishme.

- Sistemet softuerike mund të kërkojnë lidhje për t'u lidhur me sisteme të tjera softuerike.

Testimi A/B*është një teknikë eksperimentimi ku dy variante (versioni aktual dhe ai i propozuar) i nënshtrohen një vlerësimi të kontrolluar për të matur se cila prej tyre është më efektive. Përmes udhëzimit të një pjese të përdoruesve në secilën variant dhe mbledhjes së të dhënave për sjelljen e tyre, mund të nxirret një përfundim i bazuar në prova se cila ndryshim e përmbush më mirë qëllimin e synuar.

### Testimi i njëkohshëm 
Testimi i njëkohshëm ose i njëkohshëm vlerëson sjelljen dhe performancën e softuerëve dhe sistemeve që përdorin llogaritjen e njëkohshme, për

### Testimi i konformitetit ose testimi i tipit 
Në testimin e softuerëve, testimi i konformitetit verifikon nëse një produkt funksionon sipas standardeve të tij të specifikuara. Për shembull, kompiluesit testohen gjerësisht për të përcaktuar nëse ata përmbushin standardin e njohur për atë gjuhë.

### Testimi i krahasimit të rezultateve 
Metoda e testimit të pamjes grafike, e njohur edhe si testim i artë master ose testim i çastit,  konsiston në krijimin e një pamjeje referencë (të pritur) të daljes së sistemit – qoftë tekstuale ose vizuale – dhe më pas krahasimin e saj me daljet aktuale. Ndryshe nga shumica e qasjeve të tjera, kjo teknikë nuk mund të zbulojë automatikisht dështimet; kërkon ndërhyrjen e një njeriu për të vlerësuar vizualisht nëse ekzistojnë mospërputhje midis dy imazheve.

### Testimi i pronës 
Në zhvillimin e softuerit, matrica e gjurmuarjes (TM)  është një dokument, zakonisht në formë tabele, i përdorur për të ndihmuar në përcaktimin e plotësisë së një marrëdhënieje duke korreluar çdo dy dokumente bazë me njëra‑tjetrën përmes një krahasimi me marrëdhënie shumë‑me‑shumë. Ajo shpesh përdoret për të lidhur kërkesat e nivelit të lartë (që shpesh përbëhen nga kërkesat e marketingut) dhe kërkesat e detajuara të produktit me pjesët përkatëse të projektimit të nivelit të lartë, projektimit të detajuar, planit të testimit dhe rasteve testuese.

Testimi i vetiveështë një teknikë testimi ku verifikohet një "veti" e përgjithshme për shumë të dhëna hyrëse të rastësishme, në vend që të testohen dalje specifike. Për shembull, çdo rezultat i një funksioni renditjeje duhet të jetë një listë në rritje monotone me të njëjtat elementë si hyrja.

Bibliotekat e testimit të vetive u mundësojnë përdoruesve të kontrollojnë mënyrën se si gjenerohen të dhënat e rastësishme për testim. Kjo kontroll i lejon atyre të sigurojnë që të mbulojnë raste të veçanta, të dhëna të veçanta ose modele specifike që janë thelbësore për testimin e plotë të aspekteve të caktuara të implementimit në shqyrtim.

Testimi i vetive njihet ndonjëherë edhe si "testim gjenerues" ose "testim QuickCheck" që kur u prezantua dhe u bë popullor nga biblioteka Haskell QuickCheck . 

### Testimi metamorfik 
Testimi metamorfik (MT) është një teknikë testimi të bazuar në vetitë e softuerit, e cila ofron një zgjidhje ndaj dy sfidave kryesore në testim: problemit të orakullit të testimit dhe problemit të gjenerimit të rasteve testuese. 

Problemi i orakullit të testimit i referohet vështirësisë për të përcaktuar paraprakisht rezultatet e sakta të pritshme për çdo hyrje testuese, ose për të vlerësuar nëse rezultatet e fituara janë korrekte. 

Testimi metamorfik i kalon këtë pengesë duke u fokusuar jo në verifikimin e një rezultati të vetëm të saktë, por në kontrollimin e marrëdhënieve të pritshme (vetive metamorfike) midis rezultateve të testeve të ndryshme. Për shembull, nëse një hyrje ndryshohet në një mënyrë të njohur, dalja e softuerit duhet të ndryshojë në një mënyrë të parashikueshme përkatëse. Duke testuar këto marrëdhënie të detyrueshme, teknikja bën të mundur zbulimin e defekteve pa pasur nevojë për një orakull të njohur paraprakisht.

### Testimi i VCR-së 
Testimi VCR (i njohur edhe si testim riprodhimi ose testim regjistrim/riluajtje) është një teknikë testimi që synon të rrisë besueshmërinë dhe shpejtësinë e testeve të regresionit kur ato përfshijnë një komponent të jashtëm që është i ngadaltë ose jo i besueshëm në komunikim — shpesh një API e palës së tretë që ndodhet jashtë kontrollit të testuesit. Metoda konsiston në regjistrimin (krijimin e një "kasetë") të të gjitha ndërveprimeve me komponentin e jashtëm gjatë një ekzekutimi testues, për t’i ripërdorur më pas këto ndërveprime të regjistruara në vend të komunikimit të drejtpërdrejtë me sistemin e jashtëm gjatë ekzekutimeve të mëvonshme të testit.

Teknika u bë e popullarizuar në zhvillimin e uebit nga biblioteka Ruby vcr .

### Testimi i Kontratës 
Testimi i kontratës (kontraktual) është një metodologji testimi që fokusohet në pikën e integrimit midis dy shërbimeve softuerike. Qëllimi i tij kryesor është të verifikojë nëse komunikimi dhe këmbimi i të dhënave ndërmjet këtyre shërbimeve përputhet me një grup parashikimesh të përcaktuara që quhen "kontratë". Kjo kontratë përcakton pritjet për format dhe strukturën e kërkesave dhe përgjigjeve.

Kjo metodë veçanërisht përdoret gjerësisht në:

Sistemet e shpërndara

Arkitekturat e orientuara drejt shërbimeve (SOA)

Arkitekturat me mikroshërbime

Në këto kontekste, testimi i kontratës ndihmon në garantimin e qëndrueshmërisë dhe besueshmërisë së bashkëpunimit ndërmjet shërbimeve të pavarura, duke parandaluar dështime në integrim kur ndryshojnë komponentë individualë.

## Punë ekipore 
Në një organizatë, testuesit mund të jenë në një ekip të veçantë nga pjesa tjetër e ekipit të zhvillimit të softuerëve ose mund të jenë të integruar në një ekip të vetëm. Testimi i softuerëve mund të kryhet edhe nga testues softuerësh jo të dedikuar.

Në vitet 1980, termi *testues softuerësh* filloi të përdoret për të treguar një profesion të veçantë.

Rolet dhe titujt e shquar në testimin e softuerëve përfshijnë:  *menaxher testesh*, *udhëheqës testesh*, *analist testesh*, *projektues testesh*, *testues*, *zhvillues automatizimi* dhe *administrator testesh* . 

### Proceset 
Organizatat që zhvillojnë softuerë kryejnë testime ndryshe, por ka modele të përbashkëta. 

#### Zhvillimi i ujëvarës 
Në zhvillimin e softuerit, një matricë gjurmuese (TM) është një dokument tabelor që ndihmon në verifikimin e plotësisë së marrëdhënieve ndërmjet dokumenteve të ndryshme të projektit, duke korreluar elementë të dy dokumenteve bazë përmes një lidhjeje shumë-me-shumë. Ajo shërben për të lidhur në mënyrë sistematike kërkesat e nivelit të lartë (p.sh., ato të marketingut) dhe kërkesat e detajuara të produktit me komponentët përkatës të projektimit, planit të testimit dhe rasteve testuese.

Në modelin e zhvillimit waterfall, testimi zakonisht kryhet pasi të jetë përfunduar shkrimi i kodit, por para se produkti të dorëzohet klientit. Kjo qasje shpesh çon në atë që faza e testimit të përdoret si një tbuffer projekti për të kompensuar vonesat e grumbulluara gjatë zhvillimit, duke reduktuar kështu kohën reale të dedikuar për testimin cilësor. 

Disa argumentojnë se procesi waterfall lejon që testimi të fillojë kur fillon projekti i zhvillimit dhe të jetë një proces i vazhdueshëm derisa të përfundojë projekti. 

#### Zhvillim i shkathët 
Zhvillimi i softuerëve agile zakonisht përfshin testimin ndërsa kodi është duke u shkruar dhe organizimin e ekipeve me programues dhe testues dhe me anëtarë të ekipit që kryejnë si programim ashtu edhe testim.

Edhe në organizatat që i ndajnë ekipet sipas funksioneve të programimit dhe testimit, shumë prej tyre shpesh i kanë programuesit që kryejnë testime njësie . 

#### Procesi i mostrës 
* Analiza e kërkesave: Testimi duhet të fillojë që në fazën e kërkesave të ciklit jetësor të zhvillimit të softuerit. Gjatë fazës së projektimit, testuesit përcaktojnë se cilat aspekte të projektimit janë të testueshme dhe me cilat parametra funksionojnë këto teste. Planifikimi i testimit: Përgatitet strategjia e testimit, plani i testimit dhe krijohen burimet e nevojshme (testware). Meqenëse gjatë testimit kryhen shumë aktivitete, një plan i qartë është i domosdoshëm.  Zhvillimi i testeve: Krijohen procedurat e testimit, skenarët testues, rastet e testimit, grupet e të dhënave testuese dhe skriptet e testimit për përdorim në softuerët e testimit.  Ekzekutimi i testit: Testuesit ekzekutojnë softuerin bazuar në planet dhe dokumentet e testimit, dhe pastaj raportojnë çdo gabim të gjetur ekipit të zhvillimit. Kjo fazë mund të jetë veçanërisht komplekse kur kryhen teste pa njohuri të thella programimi.  Raportimi i testimit: Pas përfundimit të testimit, testuesit gjenerojnë metrika dhe raporte përfundimtare për përpjekjen e tyre testuese dhe nëse softueri i testuar është gati për publikim.  Analiza e rezultateve të testimit (ose analiza e defekteve): Kryhet nga ekipi i zhvillimit, zakonisht së bashku me klientin, për të vendosur se cilat defekte duhet të caktohen, rregullohen, refuzohen (p.sh., nëse softueri tashmë funksionon siç duhet) ose të shtyren për trajtim të mëvonshëm.  Ritestimi i defekteve: Pasi një defekt është trajtuar nga ekipi i zhvillimit, ai ritestohet nga ekipi i testimit.  Testimi i regresionit: Është e zakonshme të ndërtohet një suita e vogël testimi për çdo integrim të softuerit të ri, të modifikuar ose të rregulluar, për të siguruar që versioni më i ri nuk ka dëmtuar funksionalitet ekzistues dhe se produkti në tërësi vazhdon të funksionojë siç pritet.  Mbyllja e testit: Kur testimi plotëson kriteret e daljes, aktivitete si kapja e rezultateve kyçe, dokumentimi i mësimeve të nxjerra, ruajtja e regjistrave, raporteve dhe dokumenteve të projektit arkivohen dhe përdoren si referencë për projektet e ardhshme.

## Cilësia 
Në zhvillimin e softuerit, një komplet testimi (anglisht: test suite) është një koleksion i organizuar i rasteve testuese që përdoren për të vlerësuar një program softuerik, me qëllim që të tregohet se ai përputhet me një sërë sjelljesh ose veçorish të përcaktuara.

Një komplet i tillë përfshin zakonisht udhëzime të hollësishme dhe qëllime për çdo grup testesh, si dhe informacione rreth konfigurimit të nevojshëm të sistemit për ekzekutimin e tyre. Përveç kësaj, ai mund të përmbajë gjendje fillestare (parakushte), sekuenca hapash që duhen ndjekur dhe përshkrime për skenarët testues në vijim.

### Verifikimi dhe validimi i softuerit 
 
Testimi i softuerit përdoret në lidhje me verifikimin dhe validimin : 

* Verifikimi: A e kemi ndërtuar siç duhet softuerin? (domethënë, a i zbaton ai kërkesat).
* Validimi: A e kemi ndërtuar softuerin e duhur? (domethënë, a e kënaqin rezultatet klientin).

Termat verifikim dhe validim përdoren zakonisht në mënyrë të ndërsjellë në industri; është gjithashtu e zakonshme që këto dy terma të përcaktohen me përkufizime kontradiktore. Sipas *Fjalorit Standard IEEE të Terminologjisë së Inxhinierisë së Softuerëve* : 

: Verifikimi është procesi i vlerësimit të një sistemi ose komponenti për të kontrolluar nëse rezultatet e prodhuara në një fazë të caktuar zhvillimi i përgjigjen kushteve të përcaktuara në fillim të asaj faze. Validimi është procesi i vlerësimit së një sistemi ose komponenti gjatë ose në përfundim të zhvillimit për të përcaktuar nëse ai i plotëson kërkesat e përcaktuara për të.

Dhe, sipas standardit ISO 9000:

: Verifikimi është konfirmim me anë të ekzaminimit dhe nëpërmjet ofrimit të provave objektive që kërkesat e specifikuara janë përmbushur.
: Validimi është konfirmim me anë të ekzaminimit dhe nëpërmjet ofrimit të provave objektive se kërkesat për një përdorim ose aplikim specifik të synuar janë përmbushur.

Kontradikta shkaktohet nga përdorimi i koncepteve të kërkesave dhe kërkesave të specifikuara, por me kuptime të ndryshme.

Sipas standardeve IEEE, kërkesat e specifikuara në përkufizimin e validimit i referohen grupit të problemeve, nevojave dhe dëshirave të palëve të interesuara, të cilat softueri duhet t'i adresojë. Këto kërkesa dokumentohen në Specifikimin e Kërkesave të Softuerit (SRS).

Nga ana tjetër, produktet e përmendura në përkufizimin e verifikimit përfshijnë artefaktet dalëse të çdo faze të procesit të zhillimit të softuerit. Këto produkte janë specifikime të ndërmjetme si:

- Specifikimi i Dizajnit Arkitektonik

- Specifikimi i Detajuar i Dizajnit

- dhe dokumente të tjera të ngjashme.

SRS-ja është një specifikim, por në kuadrin e këtyre standardeve ajo shërben si referencë kryesore për validim, ndërsa specifikimet e tjera verifikohen kundrejt asaj që i paraprin. SRS-ja në vetvete nuk mund të verifikohet në të njëjtin kuptim, pasi ajo përfaqëson kërkesat fillestare nga palët e interesuara – megjithatë, ajo mund dhe duhet të validohet për të siguruar se i përfaqëson saktësisht nevojat e tyre.

Sipas standardit ISO 9000, kërkesat e specifikuara përbëjnë atë grup specifikimesh që duhet të verifikohen. Siç është sqaruar më parë, një specifikim është rezultat i një faze të caktuar të zhvillimit të softuerit, i cili merr si hyrje një specifikim tjetër. Një specifikim konsiderohet i verifikuar me sukses kur ai zbaton saktë specifikimin hyrës që i paraprin. Kështu, të gjitha specifikimet mund të verifikohen, përveç Specifikimit të Kërkesave të Softuerit (SRS), i cili është specifikimi fillestar (megjithatë, ai mund të validohet). Për shembull: Specifikimi i Projektimit duhet të verifikohet kundrejt SRS-së; dhe artefaktet e fazës së Ndërtimit duhet të verifikohen kundrejt Specifikimit të Projektimit.

Pra, kur këto fjalë përcaktohen me terma të zakonshëm, kontradikta e dukshme zhduket.

Si Specifikimi i Kërkesave të Softuerit (SRS) ashtu edhe softueri i përfunduar duhet të kalojnë procesin e validimit. Validimi i SRS‑së mund të kryhet në mënyrë statike përmes konsultimeve me palët e interesuara. Megjithatë, ndërtimi i një implementimi të pjesshëm ose prototipi i softuerit, i ndjekur nga marrja e reagimeve pozitive përmes testimit dinamik, mund të forcojë besimin se SRS‑ja është formuluar saktë. Nga ana tjetër, softueri si produkt përfundimtar dhe funksional – jo artefaktet ose dokumentet e tij, përfshirë kodin burimor – duhet të validohet në mënyrë dinamike me palët përfundimtare, duke e vënë atë në funksion dhe duke u dhënë atyre mundësinë ta provojnë drejtpërdrejt.

Disa pohues mund të thonë se, për Specifikimin e Kërkesave të Softuerit (SRS), të dhënat hyrëse në thelb janë fjalët e palëve të interesuara. Prandaj, ata besojnë se validimi i SRS-së është i njëjtë me verifikimin e saj. Kjo qasje nuk rekomandohet, sepse vetëm shton paqartësi. Është më e dobishme të kuptohet verifikimi si një proces që vlerëson nëse një dokument teknik përputhet me një dokument hyrës formal dhe të përcaktuar qartë.

Në shumë kompani, testimi i softuerit është një komponent i procesit të Sigurimit të Cilësisë së Softuerit (SQA).  Në kuadrin e SQA‑së, pjesëtarët e procesit dhe auditorët nuk vëzhgojnë vetëm produktet e gatshme (si dokumentacioni, kodi apo vetë sistemi), por vlerësojnë dhe përmirësojnë vetë procesin e zhvillimit të softuerit. Qëllimi i tyre kryesor është të reduktojë numrin e defekteve që arrijnë tek versioni përfundimtar i softuerit – pra, të ulin atë që quhet “shkallë defektesh”.

Pragu i pranueshëm i defekteve ndryshon sipas natyrës së softuerit: për shembull, një softuer simulimi për lojëra fluturimi mund të tolerojë më shumë gabime sesa softueri i kontrollit të një avioni real. Pavarësisht nga lidhja e ngushtë me SQA‑në, në shumë organizata departamentet e testimit funksionojnë si njësi të pavarura dhe mund të mos ketë fare një funksion të dedikuar SQA‑je.

Testimi i softuerit është një veprimtari vlerësuese që shqyrton një produkt softuerik për të ofruar informacione objektive mbi cilësinë e tij për palët e interesuara. Në anën tjetër, Sigurimi i Cilësisë (QA) përfaqëson zbatimin e politikave dhe proceseve të parandalimit, me qëllim që të penguar defektet që të arrijnë tek klientët.

### Masat 
Masat e cilësisë përfshijnë tema të tilla si korrektësia, plotësia, siguria dhe kërkesat ISO/IEC 9126, të tilla si aftësia, besueshmëria, efikasiteti, lëvizshmëria, mirëmbajtja, përputhshmëria dhe përdorshmëria .

Ekzistojnë një numër metrikash ose masash të përdorura shpesh për softuerët, të cilat përdoren për të ndihmuar në përcaktimin e gjendjes së softuerit ose të përshtatshmërisë së testimit.

### Artefakte 
Një proces testimi i softuerit mund të prodhojë disa artefakte . Artefaktet aktuale të prodhuara janë një faktor i modelit të zhvillimit të softuerit të përdorur, nevojave të palëve të interesuara dhe organizatës.

#### Plani i testimit 
Automatizimi i testimit përfaqëson përdorimin e një softueri (të ndarë nga softueri që po testohet) për të kontrolluar ekzekutimin e testeve dhe për të krahasuar rezultatet aktuale me ato të parashikuara. [18] Automatizimi i testimit lejon testimin e sistemit në fokus (SUT) pa ndërhyrje manuale, gjë që mund të çojë në ekzekutim më të shpejtë të testeve dhe në kryerje më të shpeshtë të tyre. Ky automatizim është një aspekt kyç i testimit të vazhdueshëm dhe shpesh përdoret në integrimin dhe dorëzimin e vazhdueshëm (CI/CD). [19]

Një plan testimi është një dokument i detajuar që përshkruan qasjen, objektivat dhe strukturën e aktiviteteve të testimit që do të kryhen. Ai mund të përfshijë përbërës të tillë si objektivat specifike të testimit dhe fushëveprimi i tij, proceset dhe procedurat që do të zbatohen, kërkesat për personelin dhe burimet e nevojshme, si dhe planet e emergjencës për situata të paparashikuara.  Ky plan mund të hartohet si një plan i vetëm i integruar, që mbulon të gjitha llojet e testimit (siç është testimi i pranimit ose i sistemit) dhe të gjitha konsideratat e planifikimit, ose si një plan master testimi, i cili shërben si një pasqyrë e përgjithshme dhe mund të referojë disa plane të detajuara testimi.  Në kontekste më të gjera, një plan testimi mund të jetë pjesë përbërëse e një strategjie të gjerë testimi. Kjo strategji dokumenton qasjet themelore dhe filozofinë e testimit dhe mund të paraqitet vetë si një plan master testimi ose si një dokument tërësisht i pavarur.

Testimi njësi, i njohur edhe si testimi i komponentëve ose i moduleve, është një formë e testimit të softuerit ku kodi burimor i izoluar vlerësohet për të verifikuar sjelljen e pritshme. 

#### Rasti i testimit 
Testimi i integrimit është një metodë testimi ku komponentë, module ose shërbime të shumta softuerike vlerësohen si një tërësi për të verifikuar nëse ato funksionojnë siç pritet kur kombinohen. Fokusi vihet në vlerësimin e ndërveprimeve dhe shkëmbimit të të dhënave midis pjesëve të integruara, dhe jo në testimin e veçantë të secilit komponent.

Përbërja dhe Struktura e një Rasti Testimi
Një rast testimi tipik përfshin një seri elementësh të standardizuar për të përcaktuar dhe dokumentuar procesin e testimit. Në formën e tij më bazë, ai specifikon një input dhe një rezultat të pritur [1], duke mundësuar vlerësimin e saktësisë së sistemit. Megjithatë, në praktikë, një rast testimi shpesh dokumentohet në më shumë detaje, duke përfshirë:

* Identifikim unik dhe referencia kërkesash nga dokumentacioni i projektit.
* Parakushtet e nevojshme për ekzekutim dhe ngjarjet që e nisin testin.
* Një sekuencë hapash (veprimesh) që duhen ndjekur.
* Të dhënat hyrëse specifike dhe rezultatin aktual të marrë.
* Krahasimin midis rezultatit aktual dhe atij të pritur.

Përshkrimi mund të variojë nga një deklaratë e shkurtër ("për kushtin x, rezultati duhet të jetë y") deri tek skenarë të detajuar me hapa të shumëfishtë. Për efikasitet, hapat proceduralë mund të ndahen në një procedurë testimi të veçantë që mund të ripërdoret për raste të ndryshme testimi.

Elementë Opsionalë dhe Informacione Shtesë

Përveç elementëve bazë, dokumentimi i rasteve të testimit mund të përfshijë fusha shtesë për menaxhim dhe qartësi më të mirë, siç janë:

* ID-ja unike e rastit, numri i hapit të testimit dhe thellësia e tij.
* Kërkesat dhe kategoritë përkatëse të testimit.
* Emri i autorit dhe tregues nëse testi është i automatizueshëm apo është automatizuar tashmë.
* Për raste më komplekse: gjendje paraprake, hapë shtesë dhe përshkrime të hollësishme.

Ruajtja dhe Menaxhimi i të Dhënave

Rastet e testimit dhe rezultatet e tyre mund të administrohen në formate dhe sisteme të ndryshme:

* Dokumente tekstuale, fleta pune elektronike (spreadsheets) ose baza të dhënash specializuese.
* Depo të centralizuara që lejojnë gjurmimin e historikut të ekzekutimeve, duke përfshirë konfigurimet e sistemit, data-kohën e testimit dhe emrin e përgjegjësit që e kryente testin.
* Tabela të veçanta për arkivimin sistematik të rezultateve historike, duke mundësuar analizën e tendencave dhe ri-përdorimin e të dhënave.

#### Skripti i testimit 
Një skript testimi është një sekuencë udhëzimesh ose kod programi që imiton veprimet që një përdorues real do të kryente në një sistem. Koncepti u zhvillua fillimisht nga produktet e krijuara nga mjetet e automatizuara të testimit të regresionit. Një rast testimi shërben si bazë për ndërtimin e skripteve të tilla, qoftë përmes një mjeti të specializuar ose me kod të shkruar manualisht.

#### Suita e testimit 
#### Pajisje testimi ose të dhëna testimi 
Për të testuar plotësisht një veçori specifike, zakonisht përdoren disa bashkësi të dhënash, secila e krijuar për të vlerësuar të njëjtin funksionalitet. Këto të dhëna, së bashku me parametrat përkatës të mjedisit, organizohen dhe ruhen në skedarë të dedikuar si aktive testimi. Ruajtja e tyre e sistematizuar lejon ripërdorim efikas dhe gjithashtu mund të ofrohet klientit së bashku me produktin përfundimtar ose si pjesë e dokumentacionit të projektit. Për këtë qëllim, ekzistojnë metoda dhe mjete të specializuara për gjenerimin e të dhënave testuese.

Në zhvillimin e softuerit, matrica e gjurmuarjes (TM)  është një dokument, zakonisht në formë tabele, i përdorur për të ndihmuar në përcaktimin e plotësisë së një marrëdhënieje duke korreluar çdo dy dokumente bazë me njëra‑tjetrën përmes një krahasimi me marrëdhënie shumë‑me‑shumë. Ajo shpesh përdoret për të lidhur kërkesat e nivelit të lartë (që shpesh përbëhen nga kërkesat e marketingut) dhe kërkesat e detajuara të produktit me pjesët përkatëse të projektimit të nivelit të lartë, projektimit të detajuar, planit të testimit dhe rasteve testuese.

Softueri, mjetet, mostrat e hyrjes dhe daljes së të dhënave dhe konfigurimet, të gjitha se bashku quhen si një sistem testimi .

#### Testimi i ekzekutimit 
Një testim përbëhet nga një grup i organizuar rastesh ose suita testuese që ekzekutohen për të vlerësuar një sistem. Gjatë ekzekutimit, krahasohen vazhdimisht rezultatet e marra me ato të parashikuara. Pas përfundimit, gjenerohet një raport i detajuar që përmbledh të gjitha aktivitetet e kryera dhe gjetjet e testimit.

### Certifikime 
Në zhvillimin e softuerit, një komplet testimi (anglisht: test suite, i njohur më rrallë si validation suite) është një koleksion rastesh testimi që synohen të përdoren për testimin e një programi softuerik, për të treguar se ai posedon një grup të caktuar sjelljesh.   

Një komplet testimi shpesh përmban udhëzime ose qëllime të hollësishme për secilën koleksion rastesh testimi, si dhe informacione mbi konfigurimin e sistemit që duhet përdorur gjatë testimit. Një grup rastesh testimi mund të përfshijë gjithashtu gjendje ose hapa paraprakë, si dhe përshkrime të testeve në vijim.

Në industri, ofrohen programe formalizimi të njohurive (si certifikimet ISTQB, CSTE) për ata që punojnë në testimin e softuerit. Megjithë këtë, një pjesë e konsiderueshme e profesionistëve të fushës e quan këtë parakohë, duke argumentuar se testimi është një praktikë shumë e varur nga konteksti dhe me theks në aftësi gjykuese, gjë që certifikimet formale nuk e kapin thellësisht. Kjo pikëpadje bën pjesë në debatin më të gjerë se sa të standardizuar mund dhe duhet të bëhet profesioni i testimit.

## Kontradikta 
Disa nga kontroversat më krysore në fushën e testimit të softuerit janë:

Qasjet Agile dhe Tradicionale në Testim  Testimi në metodologjitë Agile kërkon nga testuesit aftësi për të punuar në mjedise dinamike me ndryshime të vazhdueshme, duke priorituar përshtatshmërinë ndaj kërkesave në evolucion. Nga ana tjetër, qasjet tradicionale (si Waterfall) synojnë arritjen e një "pjekurie" të procesit testues, me faza të përcaktuara qartë. Megjithëse testimi Agile është bërë gjithnjë e më popullor në sektorin tregtar që nga vitet 2000, organizatat qeveritare dhe ushtarake përdorin gjithashtu këtë metodologji, ndonëse shpesh në kombinim me modele më tradicionale.  Testimi Manual dhe i Automatizuar   Disa studiues argumentojnë se automatizimi i testimit duhet të përdoret me masë, pasi kostoja e tij mund të tejkalojë vlerën e sjellë në projekte të vogla ose me kompleksitet të ulët. Automatizimi mund të shihet si një mjet për të formalizuar dhe ruajtur kërkesat. Në përgjithësi, kthimi i investimit në automatizim rritet me shkallën dhe kompleksitetin e sistemit. Ekspertiza dhe mjetet e zhvilluara mund të ripërdoren në projekte të shumta, duke shpërndarë koston fillestare.  Debati rreth Standardit ISO 29119  Në komunitetin e testimit të softuerit, ekziston një debat i gjërë rreth standardit ISO 29119. Një pjesë e konsiderueshme e praktikuesve, veçanërisht ata që ndjekin qasjen e testimit të bazuar në kontekst, kanë shprehur rezistencë ndaj këtij standardi. Disa organizata profesionale kanë bërë thirrje për tërheqjen e tij. Kritikët argumentojnë se fusha e testimit mund të mos jetë gati për një standardizim të tillë, duke theksuar se certifikimet ekzistuese nuk matin në mënyrë adekuate aftësitë praktike dhe njohuritë e testuesve, dhe as nuk garantojnë kompetencën e tyre reale në punë.   Studimet mbi Koston e Rregullimit të Defekteve   Ekzistojnë mendime të ndryshme rreth vlefshmërisë së studimeve që matin koston e rregullimit të defekteve në varësi të fazës së zbulimit të tyre. Për shembull, disa studime klasike sugjerojnë se rregullimi i një defekti bëhet eksponencialisht më i kushtueshëm sa më vonë të zbulohet, por zbatueshmëria e këtyre modeleve në projekte të ndryshme softuerike vazhdimisht diskutohet në literaturë.Të dhënat në bazë të të cilave është ndërtuar kjo tabelë janë jashtëzakonisht të kufizuara. Në analizën e tij, Laurent Bossavit vëren:

Lakorja e ashtëquajtur “projekte më të vogla” në fakt rrjedh vetëm nga dy ekipe studentësh të vitit të parë – një madhësi mostre aq e vogël saqë çdo përgjithësim në drejtim të “projekteve më të vogla në përgjithësi” është krejtësisht e pajustifikuar.

Studimi i GTE nuk i sqaron burimet e të dhënave, duke thënë vetëm se ato vijnë nga dy projekte, “një i madh dhe një i vogël”. Punimi i cituar për projektin “Safeguard” të Bell Labs e mohon qartë se ka mbledhur të dhëna të hollësishme të tipit që sugjerojnë pikat e paraqitura nga Boehm.

Nga ana tjetër, studimi i IBM-së (punimi i Fagan) përmban pohime që duken në kundërshtim me grafikun e Boehm, pa asnjë rezultat numerik që korrespondon qartë me pikat e tij të të dhënave.

Boehm vetë nuk citon asnjë punim për të dhënat nga TRW, me përjashtim të një reference të vetme në librin “Making Software” (2010), ku ai i referohet artikullit origjinal të vitit 1976. Ekziston, në fakt, një studim i gjerë i kryer në TRW në periudhën përkatëse, i cili mund të ishte cituar nga Boehm, por ai studim nuk përmban llojin e të dhënave që do të mund të mbështesnin pretendimet e tij. 

## Shih edhe 
## Referime 
 

## Lexime të mëtejshme 
*  

## Lidhje të jashtme 
 

* "Softuer që e bën softuerin më të mirë" Economist.com
*