Testimi i softuerit

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.  Boshllëqet e kërkesave shpesh mund të jenë kërkesa jo-funksionale, siç janë testueshmëria, shkallëzueshmëria, mirëmbajtja, performanca dhe siguria .

 Mbulimi i kodit 
Një kufizim themelor i testimit të softuerit qëndron në pamundësinë për të testuar të gjitha kombinimet e mundshme të të dhënave hyrëse dhe të gjitha gjendjet fillestare (parakushtet) — madje edhe për një produkt relativisht të thjeshtë. Për shkak të kësaj, defektet që shfaqen vetëm në kushte të pazakonta ose të rralla janë veçanërisht të vështira për t'u zbuluar gjatë procesit rutinë të testimit.

Për më tepër, dimensionet jo‑funksionale të cilësisë së softuerit — siç janë përdorshmëria, shkallëzueshmëria, performanca, përputhshmëria dhe besueshmëria — shpesh kanë një natyrë subjektive. Ajo që për një përdorues ose stakeholder përfaqëson një nivel të mjaftueshëm të cilësisë, mund të mos konsiderohet i tillë nga një tjetër.

Edhe pse testimi për çdo të dhënë të mundshme nuk është i realizueshëm, testimi mund të përdorë kombinatorikën për të maksimizuar mbulimin duke minimizuar testet. 

Testimi mund të kategorizohet në shumë mënyra. 

 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 pasiv nënkupton verifikimin e sjelljes së një sistemi pa kryer ndërveprim direkt me produktin softuerik. Ndryshe nga testimi aktiv, testuesit nuk furnizojnë të dhëna testimi, por mbikqyrin regjistrat dhe gjurmët e sistemit. Ata analizojnë këto të dhëna për të identifikuar modele dhe sjellje specifike, në bazë të të cilave nxirren përfundime. Kjo qasje lidhet ngushtë me verifikimin jashtë linje të kohës së ekzekutimit dhe me analizën e regjistrave të sistemit.

 Eksplorues 
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.

Zgjedhja e llojit të strategjisë së testimit varet nga mënyra se si përcaktohen testet që do të kryhen në artikullin në testim (IUT). Nëse testet përcaktohen dhe planifikohen plotësisht përpara se të fillojë ekzekutimi, kemi të bëjmë me testim të paracaktuar. Nëse, nga ana tjetër, çdo input që do të aplikohet në IUT mund të përcaktohet në mënyrë dinamike bazuar në rezultatet e testeve të mëparshme, strategjia quhet testim adaptiv.

Testimi i softuerit shpesh kategorizohet në dy qasje themelore: testimi i kutisë së bardhë dhe testimi i kutisë së zezë. Këto terma përshkruajnë perspektivën nga e cila testuesi i afrohet hartimit të rasteve testuese. Gjithashtu, ekziston një qasje e tretë, hibride, e quajtur testimi i kutisë gri, e cila kombinon elemente nga të dyja metodat e mësipërme dhe mund të zbatohet në kuadrin e metodologjive të testimit të softuerit. 

 Testimi i kutisë së bardhë 

alt=White Box Testing Diagram|parapamje|Diagrami i testimit të kutisë së bardhë
Testimi i kutisë së bardhë (i njohur edhe si testimi i kutisë së qartë, testimi i kutisë së qelqit, testimi i kutisë së tejdukshme ose testimi strukturor) është një metodë testimi që verifikon strukturën ose funksionimin e brendshëm të një programi, ndryshe nga testimi i funksionalitetit të ekspozuar ndaj përdoruesit përfundimtar.  

Në këtë qasje, njohuria e brendshme e sistemit (përfshirë kodin burimor) dhe aftësitë e programimit përdoren për hartimin e rasteve testuese. Testuesi zgjedh të dhënat hyrëse për të mbuluar shtigje të ndryshme ekzekutimi nëpër kod dhe përcakton rezultatet e pritura.  Kjo metodë është analoge me testimin e nyjeve në një qark elektronik, të njohur si testimi brenda qarkut (TIK).

Testimi i kutisë së bardhë mund të zbatohet në të tre nivelet e testimit të softuerit — njësinë, integrimin dhe sistemin — por më së shpeshti kryhet në nivelin e njësisë.  Ai mund të mbulojë shtigjet ekzekutuese brenda një njësie të vetme, shtigjet ndërvepruese midis njësive gjatë testimit të integrimit, si dhe shtigjet midis nënsistemeve gjatë testimit në nivel sistemi. Megjithë aftësinë e kësaj metode për të zbuluar një gamë të gjerë të gabimeve, ajo mund të mos kapë pjesë të pazbatuara të specifikimit ose kërkesa që mungojnë nga dokumentacioni.

Teknikat e përdorura në testimin e kutisë së bardhë përfshijnë:  

 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 instalimit 

 Testimi i përputhshmërisë 
Një nga shkaqet e zakonshme të dështimit të një softueri është mungesa e përputhshmërisë me mjedise të tjera operative, sisteme operative të ndryshme ose versione të ndryshme të tyre, apo me platforma të reja për të cilat ai nuk ishte konceptuar fillimisht. Për shembull, një aplikacion i krijuar për desktop mund të ketë vështirësi kur përpiqet të funksionojë si një aplikacion në internet përmes një shfletuesi.

Një skenar tipik është mungesa e përputhshmërisë së prapambetur, e cila ndodh kur zhvilluesit testohen vetëm në versionin më të fundit të një sistemi ose platforme, duke injoruar se shumë përdorues mund të përdorin ende versione më të vjetra. Si rezultat, softueri mund të mos funksionojë në konfigurime të mëparshme ose në harduer më të vjetër që versionet e dikurshme e mbështesnin.

Një qasje për të parandaluar probleme të tilla është abstraktimi i funksionaliteteve që varen nga sistemi operativ ose platforma, duke i izoluar ato në module ose biblioteka të veçanta. Kjo lejon një menaxhim më të fleksibël të ndryshimeve dhe përputhshmërinë me mjedise të shumëllojshme.

 Testimi i tymit dhe gjendjes së shëndetit mendor 
Testimi i njësisë, i njohur edhe si testimi i komponentëve ose i moduleve, është një formë e testimit të softuerit nëpërmjet së cilës testohet kodi burimor i izoluar për të vërtetuar sjelljen e pritshme. 
Testimi i shëndetit mendor përcakton nëse është e arsyeshme të vazhdohet me testime të mëtejshme.

Testimi i tymit konsiston në përpjekje minimale për të vënë në punë softuerin, i projektuar për të përcaktuar nëse ka ndonjë problem bazë që do ta pengojë atë të funksionojë fare. Teste të tilla mund të përdoren si test verifikimi i ndërtimit .

 Testimi i regresionit 
Testimi i integrimit është një formë e testimit të softuerit ku komponentë, module ose shërbime të shumta softuerike vlerësohen si një tërësi për të verifikuar funksionimin e tyre të pritur kur kombinohen. Theksi vihet në vlerësimin e ndërveprimeve dhe të shkëmbimit të të dhënave ndërmjet pjesëve të integruara, dhe jo në testimin e veçantë të secilit komponent.
Testimi i regresionit është një proces testimi i cili synon të identifikojë defekte ose prishje në funksionalitetin ekzistues pasi të jetë bërë një ndryshim në kodin e softuerit. Ai kërkon të zbulojë regresione – pra, situata kur veçori që kanë funksionuar më parë në mënyrë korrekte ndalojnë së funksionuari siç pritej.

Regresionet zakonisht lindin si pasojë e padëshiruar e modifikimeve në program, kur kodi i ri ose i modifikuar ndërvepret në mënyrë të papritur me kodin ekzistues. Për shkak të nevojës për të kontrolluar me kujdes shumë detaje në veçoritë e përcaktuara tashmë, testimi i regresionit përfaqëson shpesh pjesën më të madhe të përpjekjes testuese në zhvillimin komercial të softuerit . Madje edhe kur zhvillohen veçori të reja, përdoren shpesh raste testimi ekzistuese për të verifikuar se funksionaliteti bazë i mëparshëm mbetet i paprekur.

Metodat kryesore të testimit të regresionit përfshijnë ri‑ekzekutimin e grupeve ekzistuese të rasteve testuese për të kontrolluar nëse ndryshimet e reja janë sjellë defekte të rinj ose kanë "prishur" funksionalitet ekzistues.

Thellësia e testimit rregullohet sipas:

 Fazës së publikimit – në fillim të ciklit testet mund të jenë më sipërfaqësore, kurse para lëshimit bëhen më të plota.
 Rrezikut të sjellë nga veçoritë e reja – ndryshimet e konsideruara të rrezikshme testohen më gjerësisht, ndërsa ato me rrezik të ulët mund të vlerësohen përmes testeve pozitive bazë.

 Testimi i pranimit 
Testimi i pranimit është testim në nivel sistemi për të siguruar që softueri përmbush pritjet e klientit.    

Testimi i pranimit mund të kryhet si pjesë e procesit të kalimit të përgjegjësisë midis dy fazave të zhvillimit. [ nevojitet citim ]

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. 

 Testimi i pranimit të përdoruesit (UAT)
 Testimi i pranimit operacional (OAT)
 Testimi i pranimit kontraktual dhe rregullator
 Testimi alfa dhe beta

Ndonjëherë, UAT kryhet nga klienti, në mjedisin e tij dhe në harduerin e tij.

Testimi i Gatishmërisë Operacionale (OAT) është një formë testimi jo‑funksional që vlerëson nëse një sistem është gati për të punuar në mjedisin e tij operativ real (prodhimit). Ai bëhet si pjesë e proceseve të menaxhimit të cilësisë, zakonisht në fazat para‑publikimit. Qëllimi kryesor është të verifikohet se sistemi mund të integrohet dhe të mbështetet në mjedisin e prodhimit pa shkaktuar probleme operative. Nga ky këndvështrim, OAT njihet edhe si Testim i Gatishmërisë Operacionale (ORT) ose Testim i Gatishmërisë dhe Sigurimit të Operacioneve (OR&A). Testimi funksional brenda OAT‑së kufizohet në ato verifikime që janë të nevojshme për të konfirmuar karakteristikat jo‑funksionale të sistemit.

Gjithashtu, testimi i softuerit ka për qëllim të garantojë që, përveç funksionalitetit të pritshëm, sistemi nuk shkakton dëme ose ndërprerje në mjedisin e tij operativ dhe nuk i pengon proceset e tjera të vazhdojnë punën e tyre normale. 

Testimi i pranimit kontraktual kryhet sipas kritereve të përcaktuara në marrëveshjen kontraktuale, ndërsa testimi i pranimit rregullator bazohet në rregullat dhe standardet e caktuara nga autoritetet përkatëse për këtë lloj produkti softuerik. Të dyja këto forma testimi mund të kryhen nga përdoruesit përfundimtarë ose nga testues të pavarur. Në rastin e testimit rregullator, procesi nganjëherë mund të përfshijë edhe auditim direkt nga agjencitë rregullatore, të cilat verifikojnë rezultatet e marra. 

 Testimi alfa 
Testimi alfa është një fazë testimi ku softueri vlerësohet nga përdorues të brendshëm të cilësuar ose nga një ekip i pavarur, zakonisht në ambientin e zhvilluesit. Ky proces shërben si një formë e testimit të brendshëm të pranimit, përpara se softueri të lëshohet për testimin beta me përdorues të jashtëm.

 Testimi Beta 
Testimi beta ndjek pas fazës së testimit alfa dhe paraqet një fazë testimi ku softueri (i quajtur version beta) bëhet i përdorshëm nga një grup i kufizuar përdoruesish të jashtëm, të quajtur testues beta. Qëllimi është të mblidhen reagime dhe të identifikohen defekte të mbetura përpara se produkti të lëshohet zyrtarisht. Ndonjëherë versionet beta mund të bëhen të hapura për publikun e gjerë për të mbledhur sa më shumë reagime dhe për të ofruar vlerë fillestare përdoruesve, ndonjëherë për një periudhë të zgjatur ose të pacaktuar (i ashtuquajturi beta i përhershëm). 

 Testimi funksional kundrejt jo-funksional 
Testimi funksional është një proces që verifikon nëse një sistem ose nënsistem i tij kryen saktësisht një veprim ose funksion të caktuar. Këto funksione zakonisht janë të përshkruara në dokumentacionin e kërkesave, por në disa qasje zhvillimi mund të rrjedhin edhe nga rastet e përdorimit ose historitë e përdoruesve. Në thelb, testet funksionale përgjigjen pyetjeve si: "A mund ta kryejë përdoruesi këtë veprim?" ose "A e përmbush kjo veçori funksionalitetin e pritur?".

Testimi jo-funksional vlerëson karakteristikat cilësore të një sistemi softuerik, të tilla si shkallëzueshmëria, performanca, besueshmëria dhe siguria – aspekte që nuk lidhen drejtpërdrejt me funksionet specifike të përdoruesit. Qëllimi i këtij testimi është të identifikojë pikën e thyerjes (kufirin) ku sistemi fillon të silllet në mënyrë të paqëndrueshme ose dështon nën ngarkesa ekstreme ose kushte të caktuara kufizuese. Kërkesat jo‑funksionale pasqyrojnë përvojën e përdoruesit dhe përshtatshmërinë e produktit për qëllimin e synuar.

 Testimi i vazhdueshëm 
Testimi i vazhdueshëm është një praktikë ku ekzekutohen vazhdimisht teste të automatizuara brenda procesit të dorëzimit të softuerit, për të marrë reagime të shpejta lidhur me rreziqet e mundshme të biznesit që sjell një version i ri.  Ky lloj testimi verifikon jo vetëm kërkesat funksionale, por edhe ato jo‑funksionale, duke mbuluar një spektër të gjerë – nga vlerësimi i historive të përdoruesit deri te kontrolli i përputhshmërisë me qëllimet e përgjithshme të organizatës. 

Testimi shkatërrues është një qasje testimi e cila qëllon të shkaktojë dështime në softuer ose nënsisteme, me synim të verifikimit se si përballen me të dhëna hyrëse të pavlefshme, të papritura ose ekstreme. Ky proces ndihmon në vlerësimin e fuqisë së mekanizmave të validimit dhe të trajtimit të gabimeve. 

Një teknikë e zakonshme në këtë lloj testimi është injektimi i defekteve (të njohur edhe si fuzz testing ose fuzzing), ku sistemi bombardohet me inpute të rastësishme, të çrregullta ose të papritura për të zbuluar pikët e dobëta.

Për kryerjen e testeve të tilla, ekzistojnë mjete komerciale të specializuara, si dhe shumë mjete me burim të hapur dhe falas që ofrojnë mundësi të gjera për testim shkatërrues.

**Testimi i sistemit**, i njohur edhe si testimi skaj-më-skaj (E2E), është testimi i kryer mbi një sistem të plotë softuerik.

 Testimi i performancës së softuerit 
Testimi eksplorativ është një qasje ndaj testimit të softuerit, e përshkruar shkurtimisht si "të nxënë, të projektuar dhe të ekzekutuar teste njëkohësisht". Cem Kaner, i cili e konceptoi termin në vitin 1984,  e përcakton testimin eksplorativ si "një stil të testimit të softuerit që thekson lirinë dhe përgjegjësinë personale të testuesit për të optimizuar vazhdimisht cilësinë e punës së tij/saj, duke i trajtuar të nxënën lidhur me testet, projektimin e testeve, ekzekutimin e tyre dhe interpretimin e rezultateve si veprimtari reciprokisht mbështetëse, të cilat zhvillohen paralelisht gjatë gjithë projektit". 

Testimi i performancës ka si qëllim të masë se si sjelllet një sistem ose njësi e tij në kushte të caktuara pune, duke vlerësuar veçanërisht kohën e reagimit dhe qëndrueshmërinë e tij. Përveç kësaj, ai mund të përdoret për të analizuar dhe vërtetuar karakteristika të tjera cilësore, si aftësia për t’u shkallëzuar, besueshmëria dhe efikasiteti në shfrytëzimin e burimeve.

Testimi i ngarkesës vlerëson aftësinë e një sistemi për të funksionuar nën një sasi të caktuar përdoruesish apo të dhënash, duke testuar shkallëzueshmërinë e tij. Kur ky aktivitet kryen vlerësimin e qëndrueshmërisë së sistemit gjatë një periudhe të gjatë, ai quhet testim i qëndrueshmërisë (ose stabiliteti).

Lloje të tjera të lidhura të testimit të performancës përfshijnë:

 Testimi i vëllimit, i cili kontrollon sjelljen e sistemit kur komponentë të caktuar (si skedarët ose bazat e të dhënave) rriten në madhësi.
 Testimi i stresit, që vlerëson besueshmërinë e sistemit kur i nënshtrohet ngarkesave të papritura ose ekstreme.
 Testimi i stabilitetit, që vëzhgon funksionimin e vazhdueshëm të softuerit brenda një periudhe të gjatë, zakonisht në ose mbi kufijtë e pritshëm të përdorimit.

Ka pak marrëveshje se cilat janë qëllimet specifike të testimit të performancës. Termat testim i ngarkesës, testim i performancës, testim i shkallëzueshmërisë dhe testim i vëllimit shpesh përdoren në mënyrë të ndërsjellë.

Sistemet softuerike në kohë reale kanë kufizime të rrepta kohore. Për të testuar nëse përmbushen kufizimet kohore, përdoret testimi në kohë reale .

 Testimi i përdorshmërisë 
Testimi i përdorshmërisë ka si qëllim të vlerësojë sa të lehtë për t’u kuptuar dhe përdorur është ndërfaqja e një aplikacioni nga përdoruesit përfundimtarë. Ky lloj testimi fokusohet në përvojën e përdoruesit gjatë ndërveprimit me sistemin. Ndryshe nga shumë forma të tjera të testimit, ai nuk mund të automatizohet plotësisht, pasi kërkon vëzhgimin e përdoruesve realë ndërsa ata kryejnë detyra specifike, zakonisht me ndihmën e ekspertëve në dizajnin e ndërfaqes.

Për të vlerësuar në mënyrë sistematike cilësinë e përdorshmërisë, mund të përdoren modele të strukturuara. Dy shembuj të tillë janë:

 Modeli i Stanton, Theofanos dhe Joshi (2015), i cili analizon përvojën e përdoruesit.
 Modeli i Al-Sharafat dhe Qadoumi (2016), i krijuar për vlerësimin nga ekspertë, i cili ndihmon në vlerësimin e përdorshmërisë së aplikacioneve dixhitale.

 Testimi i aksesueshmërisë 
Testimi i aksesueshmërisë bëhet për të siguruar që softueri është i aksesueshëm për personat me aftësi të kufizuara. Disa nga testet e zakonshme të aksesueshmërisë në internet janë

 Sigurimi që kontrasti i ngjyrave midis fontit dhe ngjyrës së sfondit është i përshtatshëm
 Madhësia e shkronjave
 Tekste alternative për përmbajtje multimediale
 Mundësia për të përdorur sistemin duke përdorur tastierën e kompjuterit përveç mausit.

 Standardet e përbashkëta për pajtueshmëri 

 Testimi i sigurisë 
Testimi i sigurisë është thelbësor për softuerët që përpunojnë të dhëna konfidenciale për të parandaluar ndërhyrjen në sistem nga hakerat .

Sipas përkufizimit të Organizatës Ndërkombëtare për Standardizim (ISO), ky lloj testimi është një “vlerësim i mënyrës se si një artikull testimi, së bashku me të dhënat dhe informacionin përkatës, mbrohen nga qasja, leximi ose modifikimi i paautorizuar nga persona apo sisteme, dhe nga mohimi i qasjes për persona ose sisteme të autorizuara".

 Ndërkombëtarizimi dhe lokalizimi 
Ky lloj testimi verifikon aftësinë e një softueri për t'u përshtatur me tregje të ndryshme globale, duke përfshirë përkthimin e ndërfaqes dhe përshtatjen ndaj konventave lokale (si formatet e datave, monedhave dhe rregulloret kulturore). Një hap i rëndësishëm përpara se të fillojë përkthimi aktual është pseudolokalizimi– një proces ku teksti zëvendësohet me një version të simuluar që imiton karakteristikat e një gjuhe të huaj (p.sh., gjatësi të ndryshueshme të fjalëve, karaktere të veçanta). Kjo teknikë ndihmon për të identifikuar herët probleme në dizajn dhe kod që mund të shkaktojnë gabime ose vështirësi gjatë lokalizimit të vërtetë.

Testimi i globalizimit verifikon që softueri është përshtatur për një kulturë të re, siç janë monedhat ose zonat kohore të ndryshme. 

 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
 Testimi i Softuerit me Modele të Mëdha Gjuhësore: Anketa, Peizazhi dhe Vizioni

Kategoria:Faqe me adresa nga Wayback Machine që përdorin stampën e arkivës së rrjetit