Upravljanje procesom testiranja

Šta učimo ovog semestra

Petnaest sedmica: svaka ima tri časa teorije i tri časa praktične nastave. Danas: poglavlje 14 (Sedmica 14, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001.

Šta učimo ovog semestra

Literatura

1. J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
2. Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
3. G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
4. A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.

Priča za početak

U nedjelju, 22. aprila 2018., britanska banka TSB završila je projekat koji je pripreman godinama: podaci o klijentima preseljeni su sa starog računarskog sistema, koji je banka do tada iznajmljivala od druge banke, na novu platformu koju je napravila njena nova vlasnica, španska banka Sabadell. Sami podaci prešli su bez gubitka. Ali kad su klijenti u ponedjeljak pokušali ući u svoj račun, nova platforma je odmah počela padati. Ljudi se nisu mogli prijaviti, neki su vidjeli tuđe račune i tuđe iznose, plaćanja nisu prolazila, a poslovnice nisu mogle pomoći jer ni njihov sistem nije radio. Problemi su pogodili sve poslovnice i značajan dio od 5,2 miliona klijenata, a banka se potpuno vratila u normalan rad tek u decembru 2018. Primila je preko 222 000 pritužbi, isplatila desetine miliona funti odštete, a direktor je podnio ostavku.

Četiri godine kasnije, u decembru 2022., britanski regulatori kaznili su TSB sa 48,65 miliona funti zbog propusta u upravljanju rizikom i nadzoru nad projektom. Nezavisni izvještaj koji je banka naručila ocijenio je da ni nova platforma ni firma koja ju je vodila nisu bile spremne za rad sa svim klijentima, a da su rizici i rezultati testiranja nedovoljno provjereni prije odluke da se krene. Problem, dakle, nije bio samo u nekom testu koji je falio. Bio je u upravljanju: šta se testira, koliko, ko odlučuje da je dovoljno, i na osnovu čega. To je tema ovog poglavlja.

Zašto ovo poglavlje

U poglavljima 1 do 13 naučili smo kako se testira: tehnike, alati, nivoi. Sada se pitamo kako se testiranje vodi: kako se planira, kako se bira šta je najvažnije kad nema vremena za sve, kako se prati napredak i kako se, na kraju, donosi odluka da li izdanje ide korisnicima. Prvo test plan i rizik. Zatim procjena, metrike i izvještaj. Na kraju kontinuirana integracija: kako da se svi testovi iz ove knjige sami pokrenu pri svakoj izmjeni koda, alatom GitHub Actions.

Riječi ovog poglavlja (1/3)

• Test strategija – opšti pristup testiranju u organizaciji ili projektu: nivoi, vrste, alati, ko šta radi.
• Test plan – dokument za konkretno izdanje: šta se testira, kako, ko, kada, s kojim kriterijima.
• Ulazni i izlazni kriterij – uslov da testiranje počne, odnosno da se smatra završenim.
• Rizik – mogući problem; mjeri se kao vjerovatnoća × uticaj.
• Testiranje zasnovano na riziku – više testova i ranije za ono što ima veći rizik.
• Procjena – unaprijed izračunato koliko će testiranje trajati i koliko ljudi treba.

Riječi ovog poglavlja (2/3)

• Metrika – izmjeren broj o testiranju ili kvalitetu: broj izvršenih testova, broj defekata, pokrivenost.
• DRE (Defect Removal Efficiency) – udio defekata nađenih prije isporuke u svim nađenim defektima.
• Izvještaj o testiranju – sažetak stanja testiranja i kvaliteta za one koji odlučuju.
• Kontinuirana integracija (CI) – svaka izmjena koda se odmah spoji s ostatkom i automatski provjeri testovima.
• Kontinuirana isporuka (CD) – izmjena koja prođe sve provjere može se u bilo kom trenutku pustiti korisnicima.
• GitHub Actions – usluga GitHuba koja pri svakom push pokreće zadate korake (testove, analizu, isporuku).

Riječi ovog poglavlja (3/3)

• Regresiono testiranje – ponovno izvršavanje testova da se provjeri da izmjena nije pokvarila ono što je radilo.

Ciljevi poglavlja

Nakon poglavlja možete:

razlikovati test strategiju i test plan; napisati kratak test plan za izdanje DeliveryApp; postaviti ulazne i izlazne kriterije; procijeniti rizik kao vjerovatnoća × uticaj i iz njega odrediti prioritete; procijeniti trajanje testiranja metodom tri tačke; izabrati korisne metrike i izbjeći opasne; izračunati DRE; napisati izvještaj o stanju testiranja i preporuku za odluku o izdanju; objasniti kontinuiranu integraciju i isporuku; napisati GitHub Actions fajl koji pokreće ruff, pytest s pokrivenošću i Playwright testove; izabrati testove za regresiju.

Plan poglavlja – Sedmica 14: tri časa teorije i tri časa praktične nastave

14.1 Strategija i plan

Testiranje bez plana liči na putovanje bez mape: možete stići, ali ne znate kad, koliko ste potrošili, ni šta ste propustili. Dva dokumenta daju mapu:

Test strategija je opšti pristup, isti za mnoga izdanja. Za DeliveryApp bi mogla reći: pravila se testiraju jediničnim testovima (pytest), API testovima TestClienta, web stranica Playwrightom; svaki push pokreće automatske testove; pokrivenost grana mora biti bar 90 %; prije svakog izdanja radi se istraživačko testiranje od dva sata.

Test plan je za jedno izdanje: šta je novo, šta je rizično, šta se testira, ko, do kada. Standard ISO/IEC/IEEE 29119-3 predlaže sadržaj; skraćena verzija za DeliveryApp:

14.1 Strategija i plan

14.1 Strategija i plan

Plan nije ugovor koji se ne smije mijenjati. Kad se nešto promijeni (okruženje kasni, otkriven je novi rizik), plan se ažurira, a promjena se zapiše.

Ukratko – 14.1 Strategija i plan

• Test strategija je opšti pristup za mnoga izdanja, a test plan je plan jednog izdanja.
• Plan kaže šta se testira i šta ne, kako, gdje, kada, ko, i koji su rizici.
• Ulazni kriteriji kažu kada testiranje može početi, a izlazni kada je završeno.
• Plan se ažurira kad se okolnosti promijene, a promjena se zapisuje.

14.2 Ulazni i izlazni kriteriji

Najvažniji redovi plana su kriteriji. Bez njih „gotovo” znači „ponestalo je vremena”.

Ulazni kriteriji sprečavaju gubljenje vremena: nema smisla početi sistemsko testiranje ako se server ne pokreće ili ako polovina jediničnih testova pada.

Izlazni kriteriji su mjerljivi uslovi za kraj. Dobri izlazni kriteriji su:

• mjerljivi: „pokrivenost grana ≥ 90 %”, a ne „dovoljno testirano”;
• vezani za rizik: „svi testovi za rizike ≥ 12 prolaze”, a ne „95 % svih testova prolazi” (5 % koji pada mogu biti baš plaćanja);
• vezani za defekte po ozbiljnosti: „nema otvorenih kritičnih ni visokih”, uz dogovor šta se radi s nižim;
• dogovoreni unaprijed, s vlasnikom proizvoda, a ne izmišljeni posljednji dan.

14.2 Ulazni i izlazni kriteriji

Izlazni kriterij nije automatska odluka. Ako kriterij nije ispunjen, tim predlaže, a odgovorni odlučuju, uz otvoreno izrečen rizik: „Izdanje ide sa dva otvorena defekta srednje ozbiljnosti, D-7 i D-9; uticaj je…; plan popravke je…”. Kod TSB-a, prema kasnijim nalazima, odluka da se krene donesena je bez dovoljno provjerenih informacija o tome koliko je sistem spreman. Izlazni kriteriji i pošten izvještaj su upravo alati protiv toga.

Ukratko – 14.2 Ulazni i izlazni kriteriji

• Ulazni kriteriji sprečavaju da testiranje počne nad nespremnim sistemom.
• Izlazni kriteriji moraju biti mjerljivi, vezani za rizik i ozbiljnost defekata i dogovoreni unaprijed.
• Kriterij „95 % testova prolazi” je opasan ako 5 % koji pada pokriva najvažnije funkcije.
• Kad kriterij nije ispunjen, odluku donose odgovorni, uz otvoreno izrečen rizik.

14.3 Testiranje zasnovano na riziku

Vremena nikad nema za sve (princip iz poglavlja 1: iscrpno testiranje je nemoguće). Šta testirati prvo i najviše? Odgovor daje rizik:

Obje veličine se procjenjuju na skali od 1 do 5. Vjerovatnoća pita: koliko je vjerovatno da tu ima greške? (Novo i složeno je vjerovatnije od starog i jednostavnog.) Uticaj pita: koliko je loše ako greška stigne do korisnika? (Novac i sigurnost su gori od izgleda.)

14.3 Testiranje zasnovano na riziku

14.3 Testiranje zasnovano na riziku

Iz tabele slijedi redoslijed i dubina: plaćanje se testira prvo i najtemeljnije, slika profila posljednja i najlakše. Ako ponestane vremena, nije testirano ono što najmanje boli.

Procjenu ne radi tester sam. Vjerovatnoću najbolje znaju programeri („ovaj dio smo prepravljali tri puta”), a uticaj vlasnik proizvoda i korisnici („ako narudžba ne stigne, gubimo kupca”). Najbolje je procijeniti zajedno, na kratkom sastanku.

Ukratko – 14.3 Testiranje zasnovano na riziku

• Rizik je vjerovatnoća greške pomnožena s uticajem greške, obje na skali od 1 do 5.
• Testiranje zasnovano na riziku testira prvo i najdublje ono s najvećim rizikom.
• U DeliveryApp najveći rizik ima plaćanje (15), a najmanji slika profila (2).
• Rizik procjenjuju zajedno programeri, vlasnik proizvoda i testeri.

Provjeri se

1. Koja je razlika između test strategije i test plana? Strategija je opšti pristup za mnoga izdanja; plan je za jedno izdanje, s predmetom, rasporedom, ulogama i kriterijima.
2. Zašto je „95 % testova prolazi” loš izlazni kriterij? Jer 5 % koji pada može biti baš najrizičniji dio, npr. plaćanje.
3. Koliki je rizik dijela s vjerovatnoćom 2 i uticajem 5? 10.

Odgovori: tipka R ili klik na zamućeno polje.

14.4 Procjena

„Koliko će trajati testiranje?” je pitanje koje vođa testiranja čuje prvo. Tačan odgovor ne postoji, ali postoje metode koje daju razuman odgovor:

• iskustvo i analogija: prošlo izdanje slične veličine trajalo je 8 dana;
• raščlanjivanje: podijeliti posao na male zadatke (pisanje testova za napojnicu, izvršavanje, regresija…) i procijeniti svaki;
• procjena u tri tačke: za svaki zadatak tri broja: optimistično (O), najvjerovatnije (M) i pesimistično (P), pa

Primjer: pisanje Playwright testova za ekran napojnice: O = 4 sata, M = 6 sati, P = 14 sati (ako se ekran bude mijenjao). E = (4 + 24 + 14) / 6 = 7 sati. Pesimistična vrijednost „vuče” procjenu naviše, i to je dobro: stvarni posao češće kasni nego što žuri.

• grupna procjena (npr. planning poker): svaki član tima tajno da procjenu, pa se razlike objasne i ponovi. Velika razlika obično znači da neko zna nešto što drugi ne znaju.

14.4 Procjena

Ukratko – 14.4 Procjena

• Procjena trajanja testiranja koristi iskustvo, analogiju, raščlanjivanje na zadatke i grupnu procjenu.
• Procjena u tri tačke računa (O + 4M + P) / 6 i uzima u obzir lošiji scenarij.
• Velike razlike u grupnoj procjeni otkrivaju znanje koje drugi nemaju.
• Skraćivanje testiranja je odluka o riziku i mora se izreći otvoreno.

14.5 Metrike

Šta mjeriti tokom testiranja? Korisne metrike odgovaraju na pitanja onih koji odlučuju:

14.5 Metrike

Slika 14.2 pokazuje tipičan grafikon napretka. Linija „izvršeno” zaostaje za planom u danima 5 i 6 (testno okruženje nije radilo), a linija „prošlo” pokazuje da se kvalitet popravlja kako se defekti zatvaraju.

14.5 Metrike

DRE (Defect Removal Efficiency, učinkovitost otklanjanja defekata) mjeri koliko defekata je nađeno prije isporuke:

Primjer (izmišljeni projekat): prije isporuke nađeno 45 defekata, a korisnici su u prvom mjesecu prijavili još 5. DRE = 45 / (45 + 5) = 90 %. Jedan od deset defekata „pobjegao” je korisnicima. Ako je taj jedan bio u plaćanju, 90 % nije uteha: DRE se zato gleda i po ozbiljnosti.

Opasne metrike, koje se lako pretvore u „igru brojeva”:

14.5 Metrike

• broj napisanih testova po osobi: nagrađuje mnogo slabih testova;
• broj nađenih defekata po testeru: nagrađuje prijavljivanje sitnica i svađu s programerima;
• 100 % pokrivenosti kao cilj: poglavlje 6, D-01 preživi 100 %.

Pravilo: metrika služi da se postavi pitanje, a ne da se dodijeli nagrada ili kazna.

Ukratko – 14.5 Metrike

• Korisne metrike odgovaraju na pitanja o napretku, kvalitetu, netestiranim dijelovima i popravkama.
• DRE je udio defekata nađenih prije isporuke; u primjeru je 90 %.
• Metrike se gledaju po ozbiljnosti i riziku, ne samo kao ukupni broj.
• Metrike koje nagrađuju pojedince lako postanu igra brojeva i kvare rad tima.

14.6 Izvještaj i odluka o izdanju

Izvještaj o testiranju je za ljude koji odlučuju, a nemaju vremena čitati 120 test slučajeva. Dobar izvještaj ima jednu stranu i odgovara na pet pitanja:

1. Šta je testirano, a šta nije? (u odnosu na plan i rizike)
2. Kakvo je stanje? (metrike iz 14.5, s trendom)
3. Koji su otvoreni problemi? (defekti po ozbiljnosti, s kratkim opisom uticaja)
4. Koji su preostali rizici? (šta može poći naopako i koliko je vjerovatno)
5. Šta preporučujemo? (izdati, izdati uz uslove, ne izdati)

Primjer završnog izvještaja (izmišljen):

14.6 Izvještaj i odluka o izdanju

Primijetite: izvještaj ne kaže „sve je u redu” niti „ništa ne valja”. Kaže šta znamo i šta ne znamo, i daje opcije. Odluka je na vlasniku proizvoda, ali je informisana.

14.6 Izvještaj i odluka o izdanju

Ukratko – 14.6 Izvještaj i odluka o izdanju

• Izvještaj o testiranju je za one koji odlučuju i treba stati na jednu stranu.
• Odgovara šta je testirano i šta nije, kakvo je stanje, koji su otvoreni problemi, preostali rizici i preporuka.
• Dobar izvještaj kaže šta znamo i šta ne znamo i nudi opcije.
• Odluku o izdanju donosi vlasnik proizvoda, ali na osnovu poštenih informacija.

Provjeri se

1. Kolika je procjena u tri tačke za O = 2, M = 4, P = 12 dana? (2 + 16 + 12) / 6 = 5 dana.
2. Koliki je DRE ako je prije isporuke nađeno 80, a poslije 20 defekata? 80 / 100 = 80 %.
3. Koja su tri moguća ishoda preporuke u izvještaju? Izdati, izdati uz uslove, ne izdati.

Odgovori: tipka R ili klik na zamućeno polje.

14.7 CI i CD

U knjizi imamo stotine automatskih testova. Ali test koji niko ne pokrene ne pomaže. Kontinuirana integracija (CI) znači: svaka izmjena koda se odmah spoji s ostatkom i automatski provjeri, na serveru, bez da se iko sjeti da pokrene testove.

Slika iz života: kontrola na traci u fabrici. Ne čeka se kraj smjene da se pregleda 1000 proizvoda; svaki proizvod prolazi kroz istu kontrolu odmah, i traka stane čim nešto ne valja.

Tok u DeliveryApp (slika 14.3):

14.7 CI i CD

1. programer pošalje izmjenu (push) ili otvori pull request (zahtjev da se izmjena spoji u glavnu granu);
2. GitHub Actions pokrene ruff (poglavlje 7);
3. zatim pytest sa svim testovima i provjerom pokrivenosti (poglavlja 4–12);
4. zatim provjeru da prva verzija pada (testovi zaista hvataju greške);
5. zatim Playwright testove web stranice (poglavlje 13);
6. tek ako sve prođe, izmjena se smije spojiti u glavnu granu;
7. kontinuirana isporuka (CD): spojena izmjena automatski ide u predprodukciju, a odatle, kad se odluči, u produkciju.

14.7 CI i CD

Prednosti su ogromne: greška se otkrije minutama poslije nastanka, dok se programer još sjeća šta je mijenjao; niko ne može „zaboraviti” pokrenuti testove; i glavna grana je uvijek u ispravnom stanju.

Isporuka u produkciju se danas često radi postepeno, da se rizik smanji i poslije testiranja:

• kanarinac (canary release): nova verzija prvo ide maloj grupi korisnika (npr. 5 %); ako su greške i vremena odziva u redu, ide svima;
• zastavice funkcija (feature flags): nova funkcija je u kodu, ali uključena samo za neke korisnike, i može se isključiti bez novog izdanja;
• plan povratka (rollback): unaprijed isproban način da se vrati prethodna verzija.

Ovo se ponekad zove „pomjeranje udesno” (shift right): testiranje se nastavlja i u produkciji, nadzorom i postepenim uvođenjem. Velika migracija „sve odjednom”, kao kod TSB-a, nema tu zaštitu.

Ukratko – 14.7 CI i CD

• Kontinuirana integracija automatski provjerava svaku izmjenu koda odmah poslije slanja.
• Izmjena se spaja u glavnu granu tek kad prođu sve provjere.
• Kontinuirana isporuka znači da je spojena izmjena uvijek spremna za korisnike.
• Kanarinac, zastavice funkcija i plan povratka smanjuju rizik i poslije izdanja.

14.8 GitHub Actions za DeliveryApp

GitHub Actions čita fajlove iz foldera .github/workflows/ u repozitoriju i pokreće korake iz njih. Fajl za DeliveryApp je u primjeri/ci/.github/workflows/testovi.yml (kopira se u korijen repozitorija). Pisan je u formatu YAML: uvlačenje razmacima određuje šta pripada čemu.

14.8 GitHub Actions za DeliveryApp

name: testovi

on:
  push:
    branches: [main]
  pull_request:

jobs:
  pravila-i-api:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ["3.12", "3.13"]
    defaults:
      run:
        working-directory: primjeri/deliveryapp
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python }}
      - name: Instalacija
        run: pip install pytest coverage ruff fastapi httpx2 pytest-bdd uvicorn
      - name: Statička analiza (ruff)
        run: ruff check --isolated --exclude deliveryapp_v0.py,narucivanje_v0.py .
      - name: Testovi s pokrivenošću
        run: |
          coverage run --branch -m pytest -q tests tests_bdd tests_sistem
          coverage report -m --include="deliveryapp.py,napojnica.py,narucivanje.py,vrste_narudzbi.py,radno_vrijeme.py,api.py" --fail-under=90
      - name: Prva verzija mora pasti (provjera da testovi zaista nešto hvataju)
        run: |
          if DeliveryApp=v0 pytest -q tests/test_granice.py; then
            echo "Testovi nisu uhvatili greške prve verzije!"; exit 1
          fi

14.8 GitHub Actions za DeliveryApp

Čitamo dio po dio:

• on: kada se pokreće: pri svakom push u granu main i pri svakom pull requestu.
• jobs: poslovi; ovdje pravila-i-api i web (u fajlu ispod ovog dijela). Posao web ima needs: pravila-i-api, pa se pokreće tek kad prvi uspije.
• runs-on: ubuntu-latest: GitHub za svaki posao da novi, čist računar s Linuxom. Svaki put isto okruženje: nema „kod mene radi”.
• matrix: isti posao se izvrši dva puta, s Pythonom 3.12 i 3.13. Tako se rano vidi da li nova verzija Pythona nešto mijenja.
• steps: koraci redom. uses koristi gotove korake (preuzimanje koda, instalacija Pythona), a run pokreće naredbe kao u terminalu.
• posljednji korak je zanimljiv: on očekuje pad. Ako testovi granica prođu nad prvom verzijom s greškama, nešto nije u redu s testovima (neko ih je oslabio), pa CI pada. Ovo je mala, stalna „mutacijska” provjera iz poglavlja 7.

Svi koraci ovog posla provjereni su lokalno, istim naredbama: ruff javlja „All checks passed!”, pytest daje 339 prolaza, pokrivenost navedenih fajlova je 98 % (prag 90 %), a testovi granica nad prvom verzijom padaju, kako i treba.

14.8 GitHub Actions za DeliveryApp

Posao web instalira Playwright s Chromiumom (playwright install --with-deps chromium), pokreće pytest tests_web sa snimcima ekrana i tragovima, i ako test padne, sačuva folder test-results/ kao artefakt koji se može preuzeti sa stranice GitHub Actions i otvoriti s playwright show-trace (poglavlje 13).

Posljednji korak je u postavkama repozitorija na GitHubu: zaštita grane (branch protection) za main, uz pravilo da pull request smije biti spojen samo ako su prošli poslovi pravila-i-api i web. Tada ni najžurniji programer ne može zaobići testove.

Ukratko – 14.8 GitHub Actions za DeliveryApp

• GitHub Actions pokreće korake iz YAML fajlova u folderu .github/workflows/ pri svakom push i pull requestu.
• Svaki posao dobija novi, čist računar, pa je okruženje uvijek isto.
• Matrica pokreće isti posao s više verzija Pythona.
• Korak koji očekuje pad prve verzije stalno provjerava da testovi i dalje hvataju greške.
• Zaštita grane ne dozvoljava spajanje izmjene dok testovi ne prođu.

14.9 Regresija: šta pokrenuti kad

Regresiono testiranje provjerava da izmjena nije pokvarila nešto što je radilo. Slika iz života iz AGENTS.md: popravili ste česmu u kuhinji, pa provjerite da niste poplavili kupatilo.

Idealno je pokrenuti sve testove pri svakoj izmjeni. Za DeliveryApp to i radimo: 339 testova traje oko dvije sekunde, web testovi još nekoliko. Ali u velikim projektima puna regresija traje satima. Tada se testovi dijele u slojeve:

14.9 Regresija: šta pokrenuti kad

Kod izbora testova pomaže analiza uticaja: koji testovi pokrivaju izmijenjeni kod? Alat za pokrivenost (poglavlje 6) to zna, a neki alati automatski biraju samo testove pogođene izmjenom. Ali oprez: izmjena u cijena_dostave utiče i na API, web stranicu i Locust provjeru cijene. Kod sumnje, pokreće se više, ne manje.

Regresiona svita se mora održavati: zastarjeli testovi se brišu ili mijenjaju, nestabilni se popravljaju (poglavlje 12), a za svaki defekt nađen u produkciji dodaje se test koji bi ga uhvatio, da se nikad ne vrati.

Ukratko – 14.9 Regresija: šta pokrenuti kad

• Regresiono testiranje provjerava da izmjena nije pokvarila ono što je radilo.
• U velikim projektima testovi se dijele po slojevima: pri svakom push-u, pri pull requestu, noću i prije izdanja.
• Analiza uticaja bira testove koji pokrivaju izmijenjeni kod, ali kod sumnje se pokreće više.
• Za svaki defekt iz produkcije dodaje se regresioni test.

Provjeri se

1. Šta je kontinuirana integracija? Svaka izmjena koda se odmah spaja s ostatkom i automatski provjerava testovima.
2. Zašto CI fajl DeliveryApp ima korak koji očekuje da prva verzija padne? Da stalno provjerava da testovi i dalje hvataju greške, tj. da ih niko nije oslabio.
3. Šta je kanarinac u isporuci? Nova verzija prvo ide maloj grupi korisnika, pa svima ako je sve u redu.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – Test plan i CI za DeliveryApp

Cilj je napisati test plan i procjenu rizika za izdanje 1.1, postaviti GitHub Actions za svoj repozitorij DeliveryApp i napisati završni izvještaj. Radi se u timovima od tri do četiri studenta (vođa testiranja, testeri, „vlasnik proizvoda”).

Korak 1 – Rizik i plan (60 minuta)

1. Za izdanje 1.1 (napojnica, narudžba za preuzimanje, vrijeme dostave) napravite tabelu rizika: dio sistema, vjerovatnoća, uticaj, rizik, obrazloženje. Bar osam redova, uključujući stare dijelove koje izmjene mogu pogoditi.
2. Napišite test plan na jednoj do dvije strane po tabeli iz 14.1, s ulaznim i izlaznim kriterijima.
3. Procijenite trajanje pet najvećih zadataka metodom tri tačke. Svaki član tima prvo procijeni sam, pa uporedite.

Korak 2 – GitHub Actions (75 minuta)

1. U svom GitHub repozitoriju napravite folder .github/workflows/ i kopirajte primjeri/ci/.github/workflows/testovi.yml. Prilagodite putanje (working-directory) svom repozitoriju.
2. Pošaljite izmjenu (git push) i na kartici Actions pratite izvršavanje. Zapišite trajanje svakog posla.
3. Namjerno pokvarite jedno pravilo (npr. >= u > u cijena_dostave, greška D-01) u novoj grani i otvorite pull request. Koji korak pada? Kako to izgleda na stranici pull requesta?
4. U postavkama repozitorija uključite zaštitu grane main tako da se pull request ne može spojiti dok testovi ne prođu. Pokušajte spojiti pokvareni pull request.
5. Namjerno pokvarite jedan web test i preuzmite artefakt playwright-tragovi. Otvorite trag lokalno.

Korak 3 – Izvještaj (45 minuta)

1. Iz rezultata vaših testova (lokalno i u CI-ju) napravite kratke metrike: izvršeno, prošlo, defekti po ozbiljnosti, pokrivenost.
2. Napišite završni izvještaj na jednoj strani po pet pitanja iz 14.6, s preporukom.
3. „Vlasnik proizvoda” u timu pročita izvještaj i donese odluku. Zapišite odluku i obrazloženje.

Rezultat koji se predaje: fajl rezultati-14.md s tabelom rizika, test planom, procjenama u tri tačke, vezom na repozitorij s radnim GitHub Actions fajlom i snimcima ekrana (zeleni i crveni pull request, zaštita grane), i završnim izvještajem s odlukom.

Vježba za studenta 1 – rizik.

Vježba za studenta 1 – rizik. – rješenje

Vježba za studenta 2 – izlazni kriteriji.

Vježba za studenta 2 – izlazni kriteriji. – rješenje

Vježba za studenta 3 – procjena.

Vježba za studenta 3 – procjena. – rješenje

Vježba za studenta 4 – YAML.

Vježba za studenta 4 – YAML. – rješenje

on:
  schedule:
    - cron: "0 2 * * *"      # svaki dan u 02:00 (UTC)

# … u koracima posla:
      - run: |
          playwright install --with-deps chromium firefox webkit
          pytest -q tests_web --browser chromium --browser firefox --browser webkit

Vježba za studenta 5 – metrike.

Vježba za studenta 5 – metrike. – rješenje

Sažetak u pet rečenica

1. TSB je 2018. preselio podatke na novu platformu koja nije bila spremna, pogodio značajan dio od 5,2 miliona klijenata i dobio kaznu od 48,65 miliona funti, a problem je bio u upravljanju rizikom i odlučivanju, ne samo u testovima.
2. Test strategija daje opšti pristup, a test plan za svako izdanje kaže šta se testira, kako, ko, kada, uz mjerljive ulazne i izlazne kriterije vezane za rizik.
3. Rizik je vjerovatnoća × uticaj, pa se u DeliveryApp prvo i najdublje testira plaćanje (15), a procjena u tri tačke, korisne metrike i DRE pomažu da se rad planira i prati.
4. Izvještaj o testiranju na jednoj strani kaže šta je testirano i šta nije, otvorene probleme, preostale rizike i preporuku, da bi odluka o izdanju bila informisana.
5. Kontinuirana integracija u GitHub Actions pokreće ruff, 339 testova s pokrivenošću od 98 %, provjeru da prva verzija pada i Playwright testove pri svakoj izmjeni, a regresija se slaže po slojevima od brzih do noćnih testova.

Pitanja za ponavljanje

1. Šta se desilo s bankom TSB 2018. i zašto je to priča o upravljanju testiranjem?
2. Koja je razlika između test strategije i test plana?
3. Šta sadrži test plan? Navedite bar šest dijelova.
4. Šta su ulazni i izlazni kriteriji? Kakvi moraju biti dobri izlazni kriteriji?
5. Kako se računa rizik i kako se koristi za određivanje prioriteta?
6. Ko procjenjuje vjerovatnoću, a ko uticaj?
7. Objasnite procjenu u tri tačke na primjeru.
8. Navedite korisne metrike testiranja i dvije opasne metrike.
9. Šta je DRE i kako se računa?
10. Na koja pitanja odgovara izvještaj o testiranju?
11. Šta su kontinuirana integracija i kontinuirana isporuka?
12. Objasnite dijelove GitHub Actions fajla za DeliveryApp.
13. Šta su kanarinac, zastavice funkcija i plan povratka?
14. Kako se organizuje regresiono testiranje u velikom projektu?