Testimi i softuerit

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.^[6]

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

Testimi i softuerit mund të përfshijë një boshllëk në Kërkesa – heqje nga dizajni i një kërkese.^{[4] : 426}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 .

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.^[7]

Testimi i softuerëve mund të kategorizohet në nivele bazuar në atë se sa nga sistemi i softuerëve është fokusi i një testi.^{[8][9][10][11]}

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 .^[12][13]

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 .^[13]

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.

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ë

 

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ë:^[14][15]

• 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ë

1. ↑ Kaner, Cem. Exploratory Testing (PDF). Quality Assurance Institute Worldwide Annual Software Testing Conference (në anglisht). Orlando, FL.
2. ↑ Pan, Jiantao. "Software Testing" (coursework). Carnegie Mellon University.
3. ↑ Kaner, Cem; Falk, Jack; Nguyen, Hung Quoc (1999). Testing Computer Software (në anglisht) (bot. 2nd). New York: John Wiley and Sons. ISBN 978-0-471-35846-6.
4. 1 2 Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management (në anglisht). Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0. Arkivuar nga origjinali më 25 prill 2012. Marrë më 6 dhjetor 2025.
5. ↑ Vashistha, Avinash; Khan, Imrana (tetor 2009). "Top 50 Emerging Global Outsourcing Cities: A Global Services-Tholons Study". Marrë më 25 tetor 2025.
6. ↑ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno (shtator 2007). Contract Driven Development = Test Driven Development – Writing Test Cases (PDF). ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007 (në anglisht). Dubrovnik, Croatia. Marrë më 8 dhjetor 2017.
7. ↑ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand; Fiva, Arno (shtator 2007). Contract Driven Development = Test Driven Development – Writing Test Cases (PDF). ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007 (në anglisht). Dubrovnik, Croatia. Marrë më 8 dhjetor 2017.
8. ↑ Bourque, Pierre; Fairley, Richard E., red. (2014). "Chapter 5". Guide to the Software Engineering Body of Knowledge. 3.0 (në anglisht). IEEE Computer Society. ISBN 978-0-7695-5166-1. Marrë më 2 janar 2018.
9. ↑ Bourque, P.; Fairley, R.D., red. (2014). "Chapter 4: Software Testing" (PDF). SWEBOK v3.0: Guide to the Software Engineering Body of Knowledge (në anglisht). IEEE. fq. 4–1–4–17. ISBN 978-0-7695-5166-1. Arkivuar nga origjinali (PDF) më 19 qershor 2018. Marrë më 13 korrik 2018.
10. ↑ Dooley, J. (2011). Software Development and Professional Practice (në anglisht). APress. fq. 193–4. ISBN 978-1-4302-3801-0.
11. ↑ Wiegers, K. (2013). Creating a Software Engineering Culture (në anglisht). Addison-Wesley. fq. 211–2. ISBN 978-0-13-348929-3.
12. ↑ Graham, D.; Van Veenendaal, E.; Evans, I. (2008). Foundations of Software Testing (në anglisht). Cengage Learning. fq. 57–58. ISBN 978-1-84480-989-9.
13. 1 2 Oberkampf, W.L.; Roy, C.J. (2010). Verification and Validation in Scientific Computing (në anglisht). Cambridge University Press. fq. 154–5. ISBN 978-1-139-49176-1.
14. ↑ Saleh, K.A. (2009). Software Engineering (në anglisht). J. Ross Publishing. fq. 224–41. ISBN 978-1-932159-94-3.
15. ↑ Everatt, G.D.; McLeod Jr., R. (2007). "Chapter 7: Functional Testing". Software Testing: Testing Across the Entire Software Development Life Cycle (në anglisht). John Wiley & Sons. fq. 99–121. ISBN 978-0-470-14634-7.

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.^[1]

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.

Stampa:Computer science

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 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 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 është testim në nivel sistemi për të siguruar që softueri përmbush pritjet e klientit.^[2][3][4][5]

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

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.^[5]

• 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 ë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 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 ë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 ë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 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ë 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ë 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.

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

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.^[6]

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

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

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

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.

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 (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 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 (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ë.

Organizatat që zhvillojnë softuerë kryejnë testime ndryshe, por ka modele të përbashkëta.^[9]

  Testimi i softuerit përdoret në lidhje me verifikimin dhe validimin :^[12]

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

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.

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.