Testimi & QA

Si sigurohemi që programi punon para se ta përdorin të tjerët — testet, bug-et, automatizimi dhe puna e testuesit. · 153 terma

Acceptance testing (UAT)

Testimi i pranimit

UAT është prova përfundimtare nga klienti ose përdoruesit e vërtetë: „a e zgjidh kjo problemin tonë?“. Po kalon, produkti pranohet; përndryshe kthehet për ndryshime.

Kontrollo që faqja përdoret nga të gjithë: navigim vetëm me tastierë, lexues ekrani, kontrast ngjyrash, alt-e, label-e. Mjetet automatike (axe, Lighthouse, WAVE) gjejnë rreth 30–40% të problemeve; pjesa tjetër kërkon testim me dorë.

Add a test for every bug

Një test për çdo bug të rregulluar

Kur rregullon një bug, shkruaj fillimisht një test që e riprodhon (dështon), pastaj rregulloje (testi kalon). Kështu ai bug s'kthehet kurrë pa u vënë re.

AI tools for testers

Mjetet AI për testuesit

AI-ja ndihmon testuesit: gjeneron raste testimi nga kërkesat, shkruan teste Playwright, sugjeron të dhëna testi dhe „rregullon vetë“ lokatorët kur ndryshon faqja. Por njeriu vendos çfarë ka rëndësi të testohet.

API mocking & service virtualization

Imitimi i API-ve

Kur API-ja e vërtetë s'është gati ose është e paqëndrueshme, testet përdorin një server të rremë (WireMock, MSW, Mockoon) që kthen përgjigje të paracaktuara — edhe gabime dhe vonesa, për të testuar rastet e vështira.

API testing

Testimi i API-ve

Testimi i API-ve dërgon kërkesa direkt te backend-i (pa ndërfaqe) dhe kontrollon kodin e statusit, JSON-in, kohën e përgjigjes dhe gabimet. Më i shpejtë dhe më i qëndrueshëm se testet e ndërfaqes.

Appium, Espresso & XCUITest

Appium automatizon aplikacione Android dhe iOS me një API të vetme (si Selenium për telefonat). Espresso (Android) dhe XCUITest (iOS) janë mjetet vendase, më të shpejta; Detox dhe Maestro janë të njohura për React Native.

Arrange-Act-Assert (AAA)

Përgatit, Vepro, Kontrollo

Struktura më e qartë e një testi: Arrange (përgatit të dhënat), Act (ekzekuto veprimin), Assert (kontrollo rezultatin). Te BDD quhet Given–When–Then. Një test i mirë teston një gjë të vetme.

Assertion libraries & matchers

Libraritë e pohimeve

Pohimet kontrollojnë rezultatin: expect(x).toBe(5), assert x == 5, assertThat(x).isEqualTo(5). Libraritë si Chai, AssertJ dhe FluentAssertions japin „matchers“ të lexueshëm dhe mesazhe gabimi të qarta.

Automated accessibility tests (axe)

Testet automatike të aksesueshmërisë

axe-core mund të ekzekutohet brenda testeve (jest-axe, @axe-core/playwright, pa11y) dhe të bëjë që testi të dështojë kur mungojnë alt-et, label-et ose kontrasti është i dobët. Kap problemet e zakonshme para se të arrijnë te përdoruesit.

Automated security checks in CI

Kontrollet automatike të sigurisë në CI

Shto në pipeline: skanim të varësive (npm audit, Dependabot), skanim të sekreteve (gitleaks), analizë statike (Semgrep, CodeQL) dhe një skanim bazë me OWASP ZAP. Kapin shumë probleme pa punë shtesë manuale.

Automating API tests in code

Automatizimi i testeve të API-ve me kod

Testet e API-ve në kod ekzekutohen në CI me çdo ndryshim: REST Assured (Java), Supertest (Node), pytest + requests/httpx (Python), ose request API i Playwright-it — i njëjti mjet për UI dhe API.

BDD (behaviour-driven development)

Zhvillimi i drejtuar nga sjellja

BDD i shkruan testet si skenarë të kuptueshëm edhe nga njerëz jo-teknikë: „Duke qenë se jam i hyrë, kur shtoj një produkt në shportë, atëherë shporta ka 1 produkt“. Ndihmon biznesin, QA-në dhe zhvilluesit të flasin të njëjtën gjuhë.

Beta testing (TestFlight, Play Console)

Testimi beta me përdorues

Para publikimit, një grup përdoruesish të vërtetë e provon versionin e ri përmes TestFlight (iOS) ose testimit të mbyllur në Google Play, dhe dërgon komente dhe raporte rrëzimesh.

Black-box vs white-box testing

Testimi kuti e zezë dhe kuti e bardhë

Te testimi „kuti e zezë“ s'e sheh kodin — teston vetëm hyrjet dhe daljet, si një përdorues. Te „kuti e bardhë“ e njeh kodin dhe teston çdo degë e kusht. „Kuti gri“ është diçka në mes.

Boundary value analysis

Analiza e vlerave kufitare

Gabimet fshihen shpesh në kufij: po lejohet mosha 18–65, testo 17, 18, 19, 64, 65 dhe 66. Kështu kap gabimet „off-by-one“ (< në vend të <=) që janë shumë të zakonshme.

Bug advocacy

Mbrojtja e bug-eve

Një bug i raportuar keq mbetet pa u rregulluar. Shkruaj titull të qartë, hapa të shkurtër, ndikimin te përdoruesi („klientët s'mund të paguajnë me Visa“) dhe provë (video, log). Kështu ekipi e kupton pse ka rëndësi.

Bug bash

„Gjuetia e bug-eve“

Një „bug bash“ është një seancë ku i gjithë ekipi (zhvillues, dizajnerë, produkt) e teston produktin për një orë para publikimit, shpesh me çmime për bug-un më interesant. Argëtuese dhe shumë efektive.

Bug life cycle

Cikli i jetës së një bug-u

Një bug kalon nëpër gjendje: I ri → I hapur/caktuar → Në rregullim → I rregulluar → Në ritestim → I mbyllur (ose I rihapur po ende s'punon). Mund të jetë edhe „S'është bug“ ose „S'do të rregullohet“.

Bug triage

Triazhi i bug-eve

Triazhi është shqyrtimi i rregullt i bug-eve të reja: a është vërtet bug, sa i rëndë, kush e rregullon dhe kur. Pa triazh, lista e bug-eve rritet pa fund dhe gjërat e rëndësishme humbasin.

Building a QA portfolio

Portofoli i një testuesi

Për punën e parë në QA: testo një faqe ose aplikacion publik, shkruaj plan testimi dhe raste, raporto bug-e (bug bounty ose open source), dhe publiko në GitHub një projekt me teste Playwright dhe API të ekzekutuara në GitHub Actions.

Characterization & golden master tests

Testet e karakterizimit

Para se të rifaktorosh kod të vjetër që askush s'e kupton, regjistro rezultatet e tij aktuale për shumë hyrje („golden master“) dhe krahasoji pas çdo ndryshimi. S'thotë nëse kodi është i saktë — vetëm që s'ndryshoi.

Checklist-based testing

Testimi me listë kontrolli

Në vend të rasteve të detajuara, një listë kontrolli e shkurtër („formularët validohen? faqja punon në telefon? mesazhet e gabimit janë të qarta?“) është e shpejtë dhe e mjaftueshme për shumë projekte të vogla.

Code coverage

Mbulimi i kodit

Mbulimi tregon sa përqind e rreshtave ose degëve të kodit ekzekutohen nga testet. 0% është alarm; por 100% s'do të thotë pa bug-e — mund të ekzekutosh kodin pa kontrolluar asgjë. Përdore si udhëzues, jo si qëllim.

Code review as quality control

Rishikimi i kodit si kontroll cilësie

Rishikimi i kodit gjen shumë defekte para se të ekzekutohet ndonjë test — logjikë e gabuar, raste të harruara, rreziqe sigurie. Një listë kontrolli e thjeshtë (testet? gabimet? emrat?) e bën shumë më efektiv.

Compatibility testing

Testimi i përputhshmërisë

Kontrollo që software-i punon në sisteme operative, shfletues, madhësi ekranesh dhe versione të ndryshme — p.sh. Android 10 deri 15, ose Windows dhe macOS. Zgjidh kombinimet që përdorin vërtet klientët (nga analitika).

Component testing

Testimi i komponentëve

Testimi i komponentëve teston një pjesë të ndërfaqes (një buton, një formular) veç e veç, në një shfletues të vërtetë ose të simuluar — më i shpejtë se E2E, më realist se testet njësi. React Testing Library, Vitest dhe Storybook e bëjnë.

Contract testing (Pact)

Testimi i kontratave

Kur frontend-i dhe backend-i (ose dy mikroshërbime) zhvillohen nga ekipe të ndryshme, testet e kontratës kontrollojnë që të dyja palët bien dakord për formën e kërkesave dhe përgjigjeve — pa i ekzekutuar bashkë.

Coverage tools (Istanbul, coverage.py, JaCoCo)

Mjetet e mbulimit

Mjetet e mbulimit masin cilët rreshta u ekzekutuan gjatë testeve dhe krijojnë raporte me ngjyra: Istanbul/c8 (JavaScript), coverage.py (Python), JaCoCo (Java). Codecov dhe Coveralls i shfaqin te pull request-et.

Cross-browser & device testing

Testimi në shumë shfletues dhe pajisje

Faqja mund të punojë në Chrome dhe të prishet në Safari ose në një telefon të vjetër. BrowserStack, Sauce Labs dhe LambdaTest japin qindra shfletues dhe pajisje reale në cloud për testim.

Crowdtesting

Testimi me turmë

Platformat e crowdtesting (Applause, Testlio, uTest) lidhin kompanitë me testues nga e gjithë bota që testojnë në pajisjet dhe vendet e tyre — mënyrë e mirë edhe për të fituar përvojë dhe para si testues fillestar.

Cypress

Cypress ekzekutohet brenda shfletuesit dhe të tregon testin live, me mundësi të kthehesh pas në çdo hap („time travel“). Shumë i lehtë për fillestarë dhe i popullarizuar për aplikacione React dhe Vue.

Data migration testing

Testimi i migrimit të të dhënave

Kur të dhënat kalojnë nga një sistem në tjetrin, kontrollo që numri i rreshtave përputhet, që asnjë fushë s'u prish (sidomos ë, ç, data), dhe që raportet japin të njëjtat totale para dhe pas.

Dogfooding

„Hëngra ushqimin tonë“

„Dogfooding“ do të thotë që ekipi përdor vetë produktin çdo ditë para klientëve — p.sh. punonjësit e Slack-ut punojnë në versionin e ri të Slack-ut. Gjen shumë probleme reale të përdorimit.

End-to-end (E2E) testing

Testimi nga fillimi në fund

Testet E2E e përdorin aplikacionin si një përdorues i vërtetë — hapin shfletuesin, klikojnë, shkruajnë — dhe kontrollojnë gjithë rrjedhën (regjistrim → hyrje → blerje). Japin besim të madh, por janë të ngadalta dhe të brishta.

Entry & exit criteria

Kriteret e fillimit dhe mbarimit

Kriteret e fillimit thonë kur mund të nisë testimi (p.sh. „ndërtimi kalon smoke test-in“); ato të mbarimit kur mund të ndalet („s'ka bug-e kritike, 95% e testeve kalojnë“). Pa to, testimi s'mbaron kurrë — ose mbaron shumë herët.

Environment-specific test configuration

Konfigurimi i testeve për çdo ambient

Të njëjtat teste duhet të ekzekutohen në localhost, staging dhe ndonjëherë prodhim — me URL, llogari dhe të dhëna të ndryshme. Mbaji këto në variabla ambienti (BASE_URL), jo të shkruara në kod.

Error guessing

Hamendësimi i gabimeve

Testuesit me përvojë e dinë ku fshihen bug-et: fusha bosh, emoji te emri, ' te mbiemri (O'Brien), data 29 shkurt, dy klikime të shpejta, butoni „mbrapa“ gjatë pagesës. Bëj një listë me „dyshimet“ e tua të preferuara.

Error, defect, failure

Gabimi, defekti dhe dështimi

Sipas ISTQB: një njeri bën një gabim (error), që krijon një defekt (bug) në kod, që kur ekzekutohet shkakton një dështim (failure) të dukshëm. Jo çdo defekt shkakton dështim — disa s'ekzekutohen kurrë.

Estimating testing effort

Vlerësimi i kohës së testimit

Testimi zë zakonisht 25–40% të kohës së projektit. Vlerëso sipas numrit të funksioneve, rasteve të testimit, platformave dhe rrezikut — dhe lër kohë për ritestimin e bug-eve, që gjithmonë harrohet.

Expected vs actual result

Rezultati i pritur dhe ai real

Çdo test krahason „rezultatin e pritur“ (çfarë duhet të ndodhë sipas kërkesave) me „rezultatin real“ (çfarë ndodhi). Po ndryshojnë, kemi një defekt — ose kërkesa ishte e paqartë.

Exploratory testing

Testimi eksplorues

Te testimi eksplorues, testuesi e përdor aplikacionin lirshëm dhe me kuriozitet, duke provuar gjëra të papritura („çka ndodh po klikoj dy herë shpejt?“). Gjen gabime që asnjë skenar i shkruar s'i parashikoi.

Famous failures that testing could have caught

Dështime të famshme që testimi do t'i kishte kapur

Mars Climate Orbiter u humb sepse një ekip përdori njësi metrike dhe tjetri imperiale; Knight Capital humbi 440 milionë dollarë në 45 minuta nga një publikim i pakontrolluar. Testimi s'është luks — është mbrojtje.

Flaky tests

Testet e paqëndrueshme

Një test „flaky“ herë kalon, herë dështon pa asnjë ndryshim në kod — zakonisht nga kohët e pritjes, rendi i ekzekutimit, rrjeti ose të dhëna të përbashkëta. Janë të rrezikshëm: ekipi mëson t'i injorojë testet.

Frontend performance testing

Testimi i performancës së frontend-it

Lighthouse CI mat performancën e faqes në çdo pull request dhe e bllokon po bie poshtë një kufiri; „performance budgets“ kufizojnë madhësinë e JavaScript-it dhe imazheve. Kështu faqja s'ngadalësohet pa e vënë re.

Functional vs non-functional testing

Testimi funksional dhe jo-funksional

Testimi funksional kontrollon çfarë bën sistemi (a hyn përdoruesi me fjalëkalimin e saktë?). Jo-funksional kontrollon si e bën: shpejtësinë, sigurinë, aksesueshmërinë, përdorshmërinë, sjelljen nën ngarkesë.

Game testing

Testimi i lojërave

Testuesit e lojërave kontrollojnë bug-e grafike, përplasje, balancën e vështirësisë, performancën (FPS) dhe çdo rrugë të mundshme të lojtarit — shpesh duke luajtur të njëjtin nivel qindra herë. „Playtesting“ mat nëse loja është argëtuese.

Gherkin & Cucumber

Gherkin është gjuha e skenarëve BDD (Feature, Scenario, Given, When, Then) në skedarë .feature; Cucumber (dhe SpecFlow, Behave) i lidh këto fjali me kod që i ekzekuton si teste.

Installation & upgrade testing

Testimi i instalimit dhe përditësimit

Kontrollo që aplikacioni instalohet në kompjuter ose telefon të pastër, që përditësimi nga versioni i vjetër i ruan të dhënat e përdoruesit, dhe që çinstalimi s'lë mbeturina. Shumë rrëzime ndodhin pikërisht pas përditësimeve.

Integration test

Testi i integrimit

Testi i integrimit kontrollon që disa pjesë punojnë bashkë — p.sh. API-ja me databazën e vërtetë. Gjen gabime që testet njësi s'i shohin: query të gabuara, konfigurime, formate të ndryshme.

ISTQB certification

Certifikata ISTQB

ISTQB është certifikata ndërkombëtare më e njohur për testuesit. Niveli Foundation (CTFL) mbulon bazat: llojet e testeve, teknikat, ciklin e jetës dhe termat. Shumë kompani në rajon e kërkojnë ose e paguajnë.

k6, JMeter & Locust

Mjete për testime ngarkese: k6 (skripte JavaScript, modern), JMeter (klasik, me ndërfaqe), Locust (Python), Gatling. Simulojnë mijëra përdorues njëkohësisht dhe japin raporte për kohët dhe gabimet.

Learning QA & testing: a roadmap

Si ta mësosh testimin

Rruga e zakonshme: bazat e testimit (ISTQB Foundation) → raste testimi dhe raportim bug-esh → testim manual i një aplikacioni real → SQL dhe API (Postman) → një gjuhë programimi (JavaScript ose Python) → Playwright → CI me GitHub Actions → performancë dhe siguri bazë.

Localization testing

Testimi i lokalizimit

Kontrollo aplikacionin në çdo gjuhë: përkthime që mungojnë, tekste shqip më të gjata që dalin jashtë butonave, ë dhe ç që shfaqen gabim, data dhe numra në formatin e duhur (1.234,50 €).

Locators & selectors in UI tests

Lokatorët në testet e ndërfaqes

Testet duhet të gjejnë elementet në faqe. Lokatorët më të qëndrueshëm janë ata që sheh përdoruesi (roli, teksti, label-i) ose data-testid; XPath dhe klasat CSS prishen sa herë ndryshon dizajni.

Low-code test automation

Automatizimi pa shumë kod

Platforma si Katalon, Testim dhe mabl lejojnë testues pa përvojë programimi të ndërtojnë teste të automatizuara me klikime. Shpejt për fillim; për projekte të mëdha, kodi (Playwright, Selenium) jep më shumë kontroll.

Manual testing

Testimi manual

Në testimin manual, një njeri e përdor aplikacionin dhe ndjek rastet e testimit hap pas hapi. I domosdoshëm për përdorshmëri, dizajn dhe raste të reja; i ngadaltë për kontrolle të përsëritura — ato automatizohen.

Mobile app testing

Testimi i aplikacioneve mobile

Testimi mobile ka sfida të veçanta: shumë pajisje dhe ekrane, rrjet i dobët ose pa rrjet, ndërprerje (telefonata, njoftime), bateria, lejet dhe rrotullimi i ekranit. Kombinon emulatorë me pajisje reale.

Monkey testing & fuzzing

Testimi i majmunit dhe fuzzing

„Monkey testing“ jep hyrje krejt të rastësishme (klikime, tekste) për të parë nëse aplikacioni rrëzohet. Fuzzing-u e bën sistematikisht për kodin — gjeneron miliona hyrje të çuditshme dhe gjen rrëzime dhe dobësi sigurie.

Mutation testing

Testimi me mutacione

Mutation testing ndryshon qëllimisht kodin tënd (p.sh. > bëhet >=) dhe kontrollon nëse testet e kapin. Po testet kalojnë ende, janë të dobëta. Mjete: Stryker (JS), PIT (Java), mutmut (Python).

Naming tests well

Emërtimi i mirë i testeve

Emri i testit duhet të thotë çfarë teston dhe çfarë pritet: „kthen_gabim_kur_emaili_mungon“ ose describe("hyrja") + it("refuzon fjalëkalimin e gabuar"). Kur dështon, e kupton problemin vetëm nga emri.

Nightly test runs

Ekzekutimet e natës

Testet e ngadalta (regresioni i plotë, testet në shumë shfletues, testet e performancës) ekzekutohen çdo natë me një CI të planifikuar, dhe ekipi gjen raportin në mëngjes.

Page Object Model

Modeli i objekteve të faqes

Page Object Model e mbledh çdo faqe në një klasë me metoda (faqjaHyrjes.hyr(email, fjalekalimi)), që testet të mos përsërisin lokatorët. Kur ndryshon faqja, ndryshon vetëm një vend.

Pairwise (combinatorial) testing

Testimi me çifte

Me 5 shfletues × 4 sisteme × 3 gjuhë ka 60 kombinime. Testimi me çifte zgjedh një grup shumë më të vogël që mbulon çdo çift vlerash të paktën një herë — kap shumicën e defekteve me pak teste.

Parallel test execution & sharding

Ekzekutimi paralel i testeve

Kur suita e testeve zgjat 40 minuta, ndaje: ekzekuto testet paralelisht në disa procese ose makina („sharding“). Playwright, pytest-xdist dhe Jest e mbështesin — por testet duhet të jenë të pavarura.

Parameterized tests

Testet e drejtuara nga të dhënat

Kur të njëjtin test e do me shumë vlera, s'e kopjon — e shkruan një herë me një tabelë të dhënash. pytest ka @pytest.mark.parametrize, Jest test.each, JUnit @ParameterizedTest.

Performance testing

Testimi i performancës

Testimi i performancës mat sa shpejt përgjigjet sistemi dhe sa përdorues përballon. Llojet: load (ngarkesa e pritur), stress (deri sa të bjerë), spike (rritje e papritur), soak/endurance (orë të tëra për rrjedhje memorieje).

Playwright

Playwright (nga Microsoft) teston Chromium, Firefox dhe WebKit me një API të vetme, pret automatikisht elementet, ekzekuton paralelisht dhe ka „trace viewer“ për të parë hap pas hapi çfarë ndodhi. Sot zgjedhja e parë për teste të reja E2E.

Positive & negative testing

Testimi pozitiv dhe negativ

Testimi pozitiv („rruga e lumtur“) kontrollon që gjithçka punon me të dhëna të sakta. Testimi negativ provon të dhëna të gabuara (email pa @, numra negativë, fusha bosh) dhe kontrollon që sistemi i refuzon me mirësjellje.

Postman & API clients

Postman dhe klientët e API-ve

Postman, Insomnia, Bruno dhe Hoppscotch të lejojnë të dërgosh kërkesa HTTP me klikime, të ruash koleksione kërkesash dhe të shkruash teste të thjeshta. Newman i ekzekuton koleksionet e Postman-it në CI.

Property-based testing

Testimi i bazuar në veti

Në vend që të shkruash shembuj me dorë, përshkruan një „veti“ që duhet të vlejë gjithmonë („renditja e një liste të renditur s'e ndryshon“) dhe mjeti (Hypothesis, fast-check) gjeneron qindra hyrje të rastësishme për ta provuar.

Pseudo-localization

Pseudo-lokalizimi

Para përkthimit të vërtetë, tekstet zëvendësohen automatikisht me versione më të gjata dhe me shkronja të çuditshme ([Ŝĥƒáq ëđĥë 20 !!!]) — kështu zbulon menjëherë tekste të ngulitura në kod dhe butona që s'nxënë tekste të gjata.

QA & developer collaboration

Bashkëpunimi QA–zhvillues

QA dhe zhvilluesit janë në të njëjtin ekip, jo kundërshtarë. „Tre amigot“ (produkti, zhvillimi, QA) diskutojnë çdo veçori para se të fillojë, raportet e bug-eve janë të sjellshme dhe konkrete, dhe cilësia është përgjegjësi e përbashkët.

QA & staging environments

Ambientet e testimit

Testuesit punojnë në ambiente të veçanta (QA, staging, UAT) që i ngjajnë prodhimit, me të dhëna testi. Problem i zakonshëm: ambienti ndryshon nga prodhimi dhe bug-et shfaqen vetëm te përdoruesit.

QA career path

Karriera në QA

Rruga e zakonshme: testues manual → testues automatizimi (Playwright, Selenium, API) → SDET ose QA Lead → QA Manager ose kalim te zhvillimi, DevOps ose produkti. Në Shqipëri dhe Kosovë, QA është një nga hyrjet më të shpeshta në kompanitë outsourcing.

QA engineer

Inxhinieri i cilësisë (QA)

Inxhinieri QA siguron cilësinë e produktit: planifikon testet, i ekzekuton me dorë ose automatikisht, raporton bug-e dhe punon me zhvilluesit. SDET (Software Development Engineer in Test) shkruan kryesisht teste të automatizuara. Shpesh rrugë e mirë hyrjeje në IT.

QA interview questions

Pyetjet e intervistave për QA

Pyetje të zakonshme: dallimi severity/priority, cikli i jetës së bug-ut, llojet e testeve, „si do ta testoje një stilolaps / ashensor / faqe hyrjeje?“, shkrimi i rasteve të testimit dhe pak SQL e automatizim. Trego mënyrën si mendon.

QA metrics (defect density, escape rate)

Metrikat e QA-së

Metrika të dobishme: sa bug-e arrijnë te përdoruesit („escape rate“), sa shpejt gjenden dhe rregullohen, sa teste flaky ka, sa zgjat suita e testeve. Kujdes: numri i bug-eve të raportuara s'mat cilësinë e një testuesi.

QA vs QC vs testing

QA, QC dhe testimi

QA (sigurimi i cilësisë) është procesi i gjithë ekipit për të parandaluar gabimet; QC (kontrolli i cilësisë) kontrollon produktin e gatshëm; testimi është një nga mjetet e QC-së. Në praktikë, fjalët shpesh ngatërrohen.

Reading load test results

Leximi i rezultateve të testeve të ngarkesës

Shiko tre gjëra: sa kërkesa në sekondë përballon sistemi (throughput), sa zgjat përgjigjja e 95% të kërkesave (p95) dhe përqindjen e gabimeve. Gjej pikën ku koha ose gabimet fillojnë të rriten shpejt — ai është kufiri.

Record & playback tools

Mjetet regjistro-dhe-riprodho

Disa mjete (Playwright codegen, Selenium IDE, Katalon) regjistrojnë klikimet e tua dhe i kthejnë në test. Të shpejta për fillim, por testet e regjistruara zakonisht duhen pastruar që të jenë të qëndrueshme.

Recovery & failover testing

Testimi i rikuperimit

Çfarë ndodh kur bie databaza, ndërpritet rrjeti ose fiket serveri në mes të një pagese? Testimi i rikuperimit e provon qëllimisht dhe kontrollon që sistemi rikthehet pa humbur të dhëna.

Red, green, refactor

E kuqe, e gjelbër, rifaktorim

Cikli i TDD-së: shkruaj një test që dështon (e kuqe), shkruaj kodin më të thjeshtë që e kalon (e gjelbër), pastaj pastroje kodin pa e prishur testin (rifaktorim). Përsërite me hapa të vegjël.

Regression testing

Testimi i regresionit

Regresioni është kur diçka që punonte prishet pas një ndryshimi. Testet e regresionit (zakonisht të automatizuara) ekzekutohen pas çdo ndryshimi që të sigurohesh se s'u prish asgjë e vjetër.

Release testing & go/no-go

Testimi para publikimit

Para një publikimi të madh, QA ekzekuton regresionin e plotë, kontrollon bug-et e hapura dhe jep vendimin „go/no-go“ bashkë me ekipin. Një listë kontrolli e qartë shmang harresat në ditën e publikimit.

Requirements traceability matrix

Matrica e gjurmueshmërisë

Një tabelë që lidh çdo kërkesë me testet që e mbulojnë — që të sigurohesh që asnjë kërkesë s'mbetet pa u testuar dhe të dish cilat teste duhen ndryshuar kur ndryshon një kërkesë.

Resilience testing with chaos

Testimi i qëndrueshmërisë me kaos

Qëllimisht fut defekte (ngadalëso rrjetin, fik një shërbim, mbush diskun) dhe shiko nëse sistemi vazhdon të punojë ose dështon me mirësjellje. Netflix e bëri të famshme me „Chaos Monkey“.

Retries & quarantining flaky tests

Ripërpjekjet dhe karantina e testeve

Ripërpjekja automatike e testeve që dështojnë fsheh problemin — përdore me masë. Më mirë: vëri testet flaky në „karantinë“ (s'bllokojnë merge-in, por raportohen) dhe rregulloji shpejt.

Risk-based testing

Testimi sipas rrezikut

Koha është gjithmonë e kufizuar, prandaj teston më shumë aty ku rreziku është më i madh: pagesat, hyrja, të dhënat personale, pjesët e ndryshuara së fundi — dhe më pak faqen „Rreth nesh“.

Root cause analysis (5 whys)

Analiza e shkakut rrënjësor

Mos rregullo vetëm simptomën — pyet „pse?“ pesë herë: Pse ra faqja? Disku u mbush. Pse? Log-et s'fshiheshin. Pse? … Kështu gjen shkakun e vërtetë dhe parandalon përsëritjen.

Running tests in CI

Ekzekutimi i testeve në CI

Testet vlejnë vetëm po ekzekutohen gjithmonë: në CI, pas çdo push dhe pull request. Ndaji në punë paralele për shpejtësi, ruaj raportet dhe foto ekrani të dështimeve, dhe mos e lejo merge-in kur testet dështojnë.

Schema validation in tests

Validimi i skemës në teste

Në vend që të kontrollosh çdo fushë me dorë, krahaso përgjigjen e API-së me një skemë (JSON Schema, Zod, OpenAPI) — kap menjëherë fusha që mungojnë ose me tip të gabuar.

Screenshots, videos & logs for bugs

Fotot, videot dhe log-et për bug-et

Një video e shkurtër vlen më shumë se njëqind fjalë. Bashkëngjit foto ekrani me shënime, regjistrim ekrani, mesazhet e konsolës dhe ndonjëherë një skedar HAR (të gjitha kërkesat e rrjetit) — por pa fjalëkalime ose token-a.

Security testing for QA

Testimi i sigurisë për QA

QA mund të kapë shumë probleme sigurie pa qenë pentester: provo SQL injection dhe XSS te fushat, kontrollo që një përdorues s'sheh të dhënat e tjetrit (ndrysho ID-në në URL), testo kufizimet e hyrjes dhe skanoje me OWASP ZAP.

Selenium

Selenium është mjeti klasik për automatizimin e shfletuesve, i përdorur prej 20 vitesh me Java, Python, C# dhe JavaScript. Selenium Grid i ekzekuton testet paralelisht në shumë shfletues. Ende shumë i kërkuar te punët QA.

Severity vs priority

Rëndësia dhe përparësia e bug-eve

Severity është sa i rëndë është bug-u teknikisht (rrëzim = kritik, gabim shkrimi = i vogël); priority është sa shpejt duhet rregulluar për biznesin. Një gabim shkrimi në emrin e kompanisë në kryefaqe: severity e ulët, priority e lartë.

Shift-left testing

Testimi i hershëm (shift-left)

„Shift left“ do të thotë të testosh sa më herët — kërkesat, dizajnin dhe kodin ndërsa shkruhet — sepse një bug i gjetur herët kushton shumë më pak. „Shift right“ do të thotë të testosh edhe në prodhim (monitorim, feature flags).

Skills every tester needs

Aftësitë që i duhen çdo testuesi

Kuriozitet („çfarë ndodh po…?“), vëmendje ndaj detajeve, komunikim i qartë, të menduarit si përdorues dhe si sulmues, pak SQL dhe API, dhe sot gjithnjë e më shumë programim për automatizim.

Smoke & sanity testing

Testet e tymit dhe të arsyeshmërisë

Smoke test: kontroll i shpejtë që funksionet kryesore punojnë fare (hapet aplikacioni? funksionon hyrja?). Sanity test: kontroll i shpejtë që një rregullim specifik funksionon. Po dështojnë, s'ka kuptim të testosh më tej.

Snapshot testing

Testimi me fotografi

Snapshot testing ruan rezultatin e parë (p.sh. HTML-në e një komponenti) në një skedar dhe herëve të tjera e krahason me të. I shpejtë për t'u shkruar, por kujdes: njerëzit shpesh i përditësojnë snapshot-et pa i lexuar.

Software testing

Testimi i software-it

Testimi është kontrolli nëse software-i bën atë që duhet — dhe s'bën atë që s'duhet. Gjen gabimet para përdoruesve, të jep guxim të ndryshosh kodin, dhe dokumenton si duhet të sillet sistemi.

State transition testing

Testimi i kalimeve mes gjendjeve

Shumë sisteme kalojnë nëpër gjendje (porosia: e re → e paguar → e dërguar → e kthyer). Testimi i kalimeve kontrollon çdo kalim të lejuar — dhe që ata të palejuar (e dërguar → e re) refuzohen.

Static analysis

Analiza statike e kodit

Analiza statike e kontrollon kodin pa e ekzekutuar: linter-at, kontrolli i tipeve (TypeScript, mypy), SonarQube dhe skanerët e sigurisë gjejnë gabime, kod të dyshimtë dhe dobësi që në editor.

Storybook for UI development & testing

Storybook për testimin e ndërfaqes

Storybook shfaq çdo komponent të ndërfaqes veç e veç në të gjitha gjendjet e tij (bosh, duke u ngarkuar, gabim). Përdoret për zhvillim, dokumentim dhe teste vizuale e ndërveprimi.

System testing

Testimi i sistemit

Testimi i sistemit kontrollon gjithë aplikacionin e plotë në një ambient si ai real, kundrejt kërkesave — funksionalitet, performancë, siguri. Bëhet zakonisht nga ekipi QA para publikimit.

Tagging & selecting tests

Etiketimi dhe zgjedhja e testeve

Etiketo testet (@smoke, @regresion, @i-ngadaltë) që të ekzekutosh vetëm grupin që të duhet: smoke pas çdo publikimi, regresion i plotë natën. pytest përdor markers, Playwright --grep.

Test automation

Automatizimi i testeve

Testet e automatizuara janë programe që testojnë programe: ekzekutohen me një komandë, në sekonda dhe pas çdo ndryshimi. Shkruhen me Playwright, Selenium, pytest, Jest etj. — dhe janë aftësia më e kërkuar te QA.

Test behaviour, not implementation

Testo sjelljen, jo implementimin

Testet e mira kontrollojnë çfarë sheh përdoruesi ose çfarë kthen funksioni — jo si e bën nga brenda. Kështu mund ta rifaktorosh kodin pa prishur testet. „Sa më shumë t'i ngjajnë testet përdorimit real, aq më shumë besim japin.“

Test case

Rasti i testimit

Një rast testimi përshkruan saktësisht: kushtet paraprake, hapat, të dhënat dhe rezultatin e pritur — p.sh. „Hyr me email të saktë dhe fjalëkalim të gabuar → shfaqet mesazhi ‚Fjalëkalim i gabuar‘“.

Test data

Të dhënat e testimit

Testet kanë nevojë për të dhëna: përdorues, produkte, porosi. Përdor të dhëna të rreme por realiste (Faker), llogari testi të veçanta dhe kurrë të dhëna reale të klientëve. Çdo test duhet të krijojë ose rivendosë të dhënat e veta.

Test debt

Borxhi i testeve

Kodi pa teste është „borxh“: sot kursen kohë, por çdo ndryshim i ardhshëm bëhet i rrezikshëm. Për kod të vjetër pa teste, fillo me teste „karakterizimi“ që regjistrojnë sjelljen aktuale para se ta ndryshosh.

Test design techniques

Teknikat e projektimit të testeve

S'mund të testosh çdo vlerë të mundshme, prandaj zgjedh me zgjuarsi: ndarja në klasa ekuivalence (një vlerë për çdo grup), analiza e kufijve (0, 1, 17, 18, 120 për moshën), tabelat e vendimeve për kombinime kushtesh.

Test doubles (mock, stub, fake, spy)

Dublikatat e testeve

Në teste zëvendëson pjesët e vështira me „dublikata“: stub (kthen një vlerë të fiksuar), fake (version i thjeshtë që punon, p.sh. databazë në memorie), spy (regjistron si u thirr), mock (kontrollon që u thirr saktë).

Test fixtures & setup/teardown

Fiksturat e testeve

Fiksturat përgatisin gjithçka që i duhet një testi (të dhëna, lidhje, skedarë) dhe e pastrojnë pas tij. pytest përdor @pytest.fixture, Jest/Vitest beforeEach/afterEach, JUnit @BeforeEach.

Test isolation & independence

Pavarësia e testeve

Çdo test duhet të punojë vetëm dhe në çdo renditje — s'duhet të varet nga një test tjetër që ka krijuar të dhëna. Testet e varura janë burimi kryesor i dështimeve misterioze dhe testeve flaky.

Test maintenance

Mirëmbajtja e testeve

Testet janë kod — duhen mirëmbajtur. Fshi testet që s'kanë më kuptim, rregullo ose karantino ato flaky, shmang përsëritjen me helpers dhe Page Objects. Një suitë testesh e lënë pas dore bëhet barrë, jo ndihmë.

Test management tools (TestRail, Zephyr, Xray)

Mjetet e menaxhimit të testeve

TestRail, Zephyr, Xray dhe Qase ruajnë rastet e testimit, planet dhe rezultatet në një vend, me raporte për progresin dhe lidhje me Jira-n. Shumë kompani outsourcing i përdorin çdo ditë.

Test oracle

Orakulli i testimit

„Orakulli“ është burimi që të thotë cili është rezultati i saktë: kërkesat, një llogaritje me dorë, një version i vjetër i sistemit ose një program tjetër. Pa orakull, s'e di nëse testi kaloi vërtet.

Test plan & test strategy

Plani dhe strategjia e testimit

Plani i testimit përshkruan çfarë testohet, si, nga kush, me çfarë mjetesh dhe kur konsiderohet „gati“. Strategjia është qasja e përgjithshme e kompanisë (sa automatizim, cilat lloje testesh).

Test reporting tools (Allure, HTML reports)

Mjetet e raporteve të testeve

Allure dhe raportet HTML të Playwright-it i shfaqin rezultatet bukur: grafikë, foto ekrani, video dhe historiku i testeve. Formati JUnit XML lejon çdo CI t'i lexojë rezultatet.

Test reports & metrics

Raportet e testimit

Një raport testimi tregon çfarë u testua, sa kaluan e sa dështuan, bug-et e hapura sipas rëndësisë dhe rreziqet që mbeten. Menaxherët e përdorin për të vendosur nëse produkti është gati.

Test runners & watch mode

Ekzekutuesit e testeve

Test runner-i gjen testet, i ekzekuton dhe raporton rezultatet. Në „watch mode“ (vitest, jest --watch, pytest-watch) i riekzekuton vetë sa herë ruan një skedar — feedback i menjëhershëm ndërsa shkruan kod.

Testability

Testueshmëria

Kodi i testueshëm ka funksione të vogla, varësi që mund të zëvendësohen (dependency injection), pak gjendje globale dhe mënyra për të parë çfarë ndodh (log-e, ID të qarta në HTML). Kodi i vështirë për t'u testuar zakonisht është edhe i projektuar keq.