Skip to content

Projekt 1

Jump to bottom
mkovac21 edited this page Jun 9, 2024 · 29 revisions

Plan testiranja

1. Uvod

SVRHA

Svrha plana testiranja je osigurati da svi aspekti softvera budu testirani temeljito i sustavno, kako bi se identificirali i ispravili nedostaci prije nego što softver bude pušten u proizvodnju. Uz to, plan testiranja služi kao vodič za cjelokupni proces testiranja i pomaže u koordinaciji aktivnosti testiranja.

Ključni razlozi za izradu testnog plana:

  1. Jasna definicija ciljeva: Plan testiranja definira ciljeve testiranja, što omogućava svim članovima tima da razumiju što se želi postići testiranjem.
  2. Standardizacija procesa: Plan testiranja postavlja standardizirani proces koji svi se treba slijediti, čime se osigurava konzistentnost u testiranju.
  3. Identifikacija resursa: Identificira potrebne resurse, uključujući alate i okruženja potrebne za provođenje testiranja.
  4. Praćenje napretka: Pomaže u praćenju napretka testiranja i omogućava rano otkrivanje problema koji bi mogli ometati proces.
  5. Smanjenje rizika: Pomaže u identifikaciji i smanjenju rizika povezanih s kvalitetom softvera.

Okvirna struktura testnog plana je sljedeća:

  1. Uvod: Opis svrhe, opsega i ciljeva testiranja.
  2. Opseg testiranja: Definicija onoga što će biti testirano i što neće biti testirano.
  3. Dionici: Navedeni glavni pojedinci zainteresirani za rezultate testiranja.
  4. Pristup: Opisani koraci provedbe i raspored samog testiranja.
  5. Okruženje i alati: Navedeno i opisani koji će se alati i u kojem okruženju koristiti u provedbi testiranja.
  6. Metrike i kriterij uspjeha: Definirane metrike za praćenje napretka i kriteriji za uspjeh i neuspjeh testiranja softvera.
  7. Izvještavanje: Definiran način i frekvencija izvještavanja.
  8. Testni tim: Navedene osobe koje će direktno biti uključene u proces testiranja.
  9. Testovi: Popis testnih scenarija koje treba provesti.

Tokom faze testiranja, dokument testnog plana će se koristiti na sljedeće načine:

  1. Vodič za testne aktivnosti: Testni plan služi kao vodič za sve testne aktivnosti, osiguravajući da se slijedi strukturiran i konzistentan pristup.
  2. Praćenje napretka: Plan se koristi za praćenje napretka testiranja u odnosu na raspored i ciljeve definirane u dokumentu.
  3. Upravljanje rizicima: Pomaže u praćenju identificiranih rizika i osigurava da se poduzimaju potrebne mjere za njihovo ublažavanje.
  4. Izvještavanje: Koristi se za dokumentiranje rezultata testiranja i komunikaciju tih rezultata zainteresiranim stranama.

OPSEG

Izvršavanjem ovoga projekta biti će testirane određeni funkcionalni i nefunkcionalni zahtjevi. Funkcionalni zahtjevi koji će biti testirani su:

  • FZ-11 Upravljanje opremom i resursima
  • FZ-12 Grafički prikaz statistički podataka
  • FZ-13 Dohvaćanje zaboravljene lozinke

Pored navedenih funkcionalnih zahtjeva, biti će testirani i sljedeći nefunkcionalni zahtjevi:

  • NFZ-1 Sustav će imati formalan i minimalističan stil grafičkog sučelja
  • NFZ-2 Sustav će biti dostupan 24 sata, 365 dana u godini
  • NFZ-3 Sustav će samo korisnicima zabilježenima u bazi podataka vrtića omogućiti prijavljivanje u sustav
  • NFZ-4 Vrijeme odgovora sustava
  • NFZ-5 Performanse baze podataka

DIONICI

  • Administratori vrtića i odgojitelji - oslanjaju se na rezultate testiranja kako bi osigurali da softver ispravno funkcionira, što izravno utječe na njihovu sposobnost obavljanja svakodnevnih zadataka.
  • Roditelji - očekuju pouzdanu i sigurnu komunikaciju, a bilo kakvi nedostaci u testiranju mogu rezultirati nepravovremenim ili netočnim informacijama o njihovoj djeci.
  • Zaposlenici IT odjela - koriste rezultate testiranja za identifikaciju i rješavanje tehničkih problema, što utječe na opću stabilnost i performanse sustava.
  • Ravnatelj vrtića - treba točne podatke za donošenje strateških odluka, a kvalitetno testiranje osigurava integritet tih podataka.

2. Pristup

KORACI PROVEDBE

  1. Analiza zahtjeva

    • Prvi korak u provedbi testiranja je detaljna analiza zahtjeva softvera. Ovaj korak uključuje pregled funkcionalnih i nefunkcionalnih zahtjeva kako bi se osiguralo da su svi aspekti sustava razumljivi i dokumentirani.

  2. Izrada testne strategije

    • Razvoj opće strategije testiranja koja uključuje definiciju metodologija, alata i resursa potrebnih za testiranje. Strategija obuhvaća vrste testiranja koje će se koristiti (npr. funkcionalno, integracijsko, regresijsko, performansno).

  3. Izrada testnog plana

    • Kreiranje detaljnog testnog plana koji uključuje ciljeve testiranja, opseg, raspored, resurse, kriterije za prihvaćanje i rizike. Plan također definira odgovornosti članova tima i načine komunikacije.

  4. Dizajn testnih slučajeva

    • Razvoj detaljnih testnih slučajeva koji pokrivaju sve definirane zahtjeve. Testni slučajevi opisuju specifične korake koje treba poduzeti, ulazne podatke i očekivane rezultate.

  5. Priprema testnog okruženja

    • Postavljanje i konfiguracija testnog okruženja koje oponaša stvarne uvjete u kojima će softver raditi. Ovo uključuje instalaciju potrebnog hardvera, softvera i alata za testiranje.

  6. Izvršenje testiranja

    • Provođenje testiranja prema planu i dizajniranim testnim slučajevima. Tijekom ovog koraka, testeri izvršavaju testne slučajeve, bilježe rezultate i uspoređuju ih s očekivanim rezultatima.

  7. Izvještavanje o defektima

    • Dokumentiranje svih otkrivenih defekata ili problema. Svaki defekt treba detaljno opisati, uključujući korake za reprodukciju, očekivani i stvarni rezultat, te ozbiljnost problema.

  8. Ponovno testiranje i regresijsko testiranje

    • Nakon što su defekti ispravljeni, provodi se ponovno testiranje kako bi se osiguralo da su problemi riješeni. Regresijsko testiranje se provodi kako bi se osiguralo da nove promjene nisu uvele nove greške u već testirane dijelove softvera.

  9. Evaluacija i završno izvještavanje

    • Evaluacija rezultata testiranja u odnosu na definirane kriterije prihvaćanja. Izrada završnog izvještaja koji sažima aktivnosti testiranja, otkrivene defekte i opće stanje softvera.

  10. Održavanje testne dokumentacije

    • Redovno ažuriranje testne dokumentacije kako bi se odrazile sve promjene u softveru i novootkriveni defekti. Dokumentacija treba biti ažurirana tijekom cijelog životnog ciklusa softvera.

RASPORED TESTIRANJA

  1. Analiza zahtjeva

    • Datum početka: 1. ožujka 2024.
    • Datum završetka: 5. ožujka 2024.

  2. Izrada testne strategije

    • Datum početka: 6. ožujka 2024.
    • Datum završetka: 9. ožujka 2024.
    • Kontrolna točka: Pregled i odobrenje testne strategije – 10. ožujka 2024.

  3. Izrada testnog plana

    • Datum početka: 10. ožujka 2024.
    • Datum završetka: 15. ožujka 2024.
    • Kontrolna točka: Pregled i odobrenje testnog plana – 16. ožujka 2024.

  4. Dizajn testnih slučajeva

    • Datum početka: 17. ožujka 2024.
    • Datum završetka: 22. ožujka 2024.
    • Kontrolna točka: Pregled testnih slučajeva – 23. ožujka 2024.

  5. Priprema testnog okruženja

    • Datum početka: 24. ožujka 2024.
    • Datum završetka: 26. ožujka 2024.
    • Kontrolna točka: Verifikacija testnog okruženja – 27. ožujka 2024.

  6. Izvršenje testiranja

    • Datum početka: 27. ožujka 2024.
    • Datum završetka: 24. travnja 2024.
    • Kontrolne točke:
      • Prva kontrolna točka: 3. travnja 2024. (Pregled napretka testiranja i početni izvještaj o defektima)
      • Druga kontrolna točka: 17. travnja 2024. (Pregled napretka i drugi izvještaj o defektima)

  7. Izvještavanje o defektima

    • Neprekidan proces tijekom faze izvršenja testiranja.

  8. Ponovno testiranje i regresijsko testiranje

    • Datum početka: 25. travnja 2024.
    • Datum završetka: 7. svibnja 2024.
    • Pregled rezultata ponovnog i regresijskog testiranja – 8. svibnja 2024.

  9. Evaluacija i završno izvještavanje

    • Datum početka: 8. svibnja 2024.
    • Datum završetka: 10. svibnja 2024.
    • Kontrolna točka: Pregled završnog izvještaja – 11. svibnja 2024.

  10. Održavanje testne dokumentacije

    • Neprekidan proces tijekom cijelog životnog ciklusa softvera.

Ukupni vremenski okvir:
Datum početka testiranja: 1. ožujka 2024.
Datum završetka testiranja: 11. svibnja 2024.

TESTO OKRUŽENJE

Za testiranje softvera za praćenje rada dječjeg vrtića, potrebno je osigurati odgovarajuće testno okruženje koje uključuje potrebni hardver, softver, konfiguracije i postavke sustava. Okruženje je specifično prilagođeno za rad u Visual Studio (WPF, XAML) te korištenje raznih alata i tehnologija za testiranje i analizu koda, koji će biti detaljno opisani u sljedećem odjeljku.

Potrebni hardver

  1. Razvojna i testna računala
    • Procesor: Intel Core i5 ili jači
    • RAM: Minimalno 16 GB
    • Diskovni prostor: Minimalno 500 GB SSD
    • Grafička kartica: Integrirana ili osnovna diskretna grafička kartica dovoljna za WPF aplikacije
    • Mrežna kartica: Ethernet ili Wi-Fi

Potrebni softver

  1. Operacijski sustav

    • Windows 10 ili noviji

  2. Razvojno okruženje

    • Visual Studio 2022
    • WPF (Windows Presentation Foundation)
    • XAML (eXtensible Application Markup Language)

  3. Sustav za kontrolu verzija

    • Git
    • GitHub repository za upravljanje kodom i suradnju tima

Konfiguracije i postavke sustava

  1. Visual Studio konfiguracija

    • Instalirati potrebne ekstenzije: SpecFlow, SonarLint, Fine Code Coverage, GitHub Copilot
    • Konfigurirati projekat za korištenje BDD pristupa s Gherkin jezikom

  2. SonarLint konfiguracija

    • Postaviti SonarLint za automatsko skeniranje koda i prijavljivanje problema u stvarnom vremenu tijekom razvoja

  3. Fine Code Coverage konfiguracija

    • Omogućiti Fine Code Coverage ekstenziju za generiranje izvještaja o pokrivenosti jediničnih testova

  4. Code Metrics

    • Koristiti ugrađene alate u Visual Studio za praćenje metrika koda poput složenosti, održivosti i povezanosti

  5. GitHub Copilot

    • Aktivirati i koristiti GitHub Copilot kao pomoć pri pisanju koda i predlaganju novih funkcionalnosti

Mrežna konfiguracija

  1. Pristup GitHub repozitoriju

    • Postaviti pravila za commit-ove i pull request-ove kako bi se osigurala kvaliteta koda

  2. Integracija kontinuirane integracije (CI)

    • Postaviti CI/CD pipeline na GitHubu za automatsko pokretanje testova i analiza koda nakon svakog commit-a

ALATI I TEHNOLOGIJE

U provedbi testiranja softvera za praćenje rada dječjeg vrtića koristit ćemo niz alata i tehnologija koji će osigurati temeljitost i efikasnost procesa testiranja. Svaki od tih alata ima specifičnu ulogu i doprinosi kvaliteti testiranja na različite načine.

  1. SpecFlow (BDD alat s podrškom za Gherkin jezik)

    • Opis: SpecFlow je alat za Behavior-driven development (BDD) koji koristi Gherkin jezik za pisanje testnih scenarija. Pomaže u stvaranju testova koji su čitljivi i razumljivi i tehničkim i netehničkim članovima tima.
    • Primjena: Koristit će se za testiranje prihvatljivosti kako bi se osiguralo da softver ispunjava sve definirane zahtjeve.

  2. Code Metrics

    • Opis: Code Metrics je ugrađeni alat u Visual Studio koji omogućava izračunavanje metrika koda kao što su složenost, održivost i povezanost. Pruža uvid u kvalitetu i održivost koda.
    • Primjena: Koristit će se za kontinuirano praćenje kvalitete koda tijekom cijelog procesa razvoja i testiranja.

  3. SonarLint

    • Opis: SonarLint je ekstenzija za Visual Studio koja omogućava automatiziranu recenziju koda u stvarnom vremenu. Detektira potencijalne probleme i prijavljuje ih odmah tijekom razvoja.
    • Primjena: Koristit će se za identifikaciju i otklanjanje problema u kodu prije nego što se oni manifestiraju kao greške u softveru.

  4. Fine Code Coverage

    • Opis: Fine Code Coverage je ekstenzija za Visual Studio koja pruža detaljne izvještaje o pokrivenosti jediničnih testova. Prikazuje koje dijelove koda testovi pokrivaju, a koji su neprovjereni.
    • Primjena: Koristit će se za mjerenje i povećanje pokrivenosti koda jediničnim testovima, čime se osigurava da su svi dijelovi koda adekvatno testirani.

  5. GitHub Copilot

    • Opis: GitHub Copilot je alat temeljen na umjetnoj inteligenciji koji pomaže programerima tijekom implementacije nove funkcionalnosti. Predlaže kôd i automatski generira dijelove koda na temelju konteksta.
    • Primjena: Koristit će se kao pomoć prilikom pisanja koda, omogućavajući bržu implementaciju i osiguravajući da se slijede najbolje prakse kodiranja.

  6. GitHub (kontrola verzija i CI/CD)

    • Opis: GitHub se koristi za kontrolu verzija koda i suradnju tima. Omogućava upravljanje verzijama, praćenje promjena i integraciju kontinuirane integracije (CI) i kontinuirane isporuke (CD).
    • Primjena: Koristit će se za upravljanje kodom, pregled promjena i postavljanje CI/CD pipeline-a za automatsko pokretanje testova i analiza nakon svakog commit-a.

METRIKE

Za praćenje napretka i učinka testiranja softvera za praćenje rada dječjeg vrtića, koristit ćemo niz metrika koje će nam pomoći da osiguramo kvalitetu i pouzdanost softverskog rješenja. Ove metrike omogućuju praćenje različitih aspekata testiranja, identifikaciju problema te evaluaciju učinkovitosti testnog procesa.

  1. Gustoća grešaka (eng. Defect Density)

    • Opis: Gustoća grešaka mjeri broj grešaka pronađenih u određenoj količini koda (obično po tisuću linija koda - KLOC).
    • Formula: Gustoća grešaka = (Broj grešaka) / (Broj KLOC)
    • Primjena: Koristi se za identifikaciju dijelova koda koji su skloniji greškama i zahtijevaju dodatnu pažnju ili refaktoriranje.

  2. Pokrivenost testovima (eng. Test Coverage)

    • Opis: Pokrivenost testovima mjeri postotak koda koji je pokriven jediničnim testovima. To uključuje pokrivenost granama, linijama koda, funkcijama i putanjama.
    • Formula: Pokrivenost testovima = (Broj testiranih elemenata koda) / (Ukupan broj elemenata koda) * 100%
    • Primjena: Koristi se za osiguravanje da su svi dijelovi koda adekvatno testirani i smanjenje rizika od neočekivanih grešaka.

  3. Stopa prolaska/pada testova (eng. Pass/Fail Rate)

    • Opis: Stopa prolaska/pada testova mjeri postotak testova koji su prošli ili pali tijekom određenog testnog ciklusa.
    • Formula: Stopa prolaska = (Broj prošlih testova) / (Ukupan broj izvršenih testova) * 100%
    • Primjena: Koristi se za praćenje stabilnosti i kvalitete softvera tijekom vremena te identifikaciju regresija.

  4. Prosječno vrijeme za otklanjanje grešaka (eng. Average Time to Fix)

    • Opis: Prosječno vrijeme za otklanjanje grešaka mjeri prosječno vrijeme potrebno za ispravljanje prijavljenih grešaka.
    • Formula: Prosječno vrijeme za otklanjanje grešaka = (Ukupno vrijeme za ispravljanje svih grešaka) / (Broj ispravljenih grešaka)
    • Primjena: Koristi se za praćenje učinkovitosti tima u otklanjanju grešaka i poboljšanje procesa otklanjanja.

  5. Broj otkrivenih grešaka po fazi (eng. Defects per Phase)

    • Opis: Mjeri broj grešaka otkrivenih u različitim fazama razvoja softvera (npr. tijekom dizajna, kodiranja, integracije, testiranja).
    • Primjena: Koristi se za identifikaciju faza u kojima se pojavljuje najviše grešaka, što omogućuje ciljanje poboljšanja u tim fazama.

  6. Stopa ponovljenih grešaka (eng. Defect Reoccurrence Rate)

    • Opis: Mjeri postotak grešaka koje su se ponovno pojavile nakon što su bile ispravljene.
    • Formula: Stopa ponovljenih grešaka = (Broj ponovljenih grešaka) / (Ukupan broj ispravljenih grešaka) * 100%
    • Primjena: Koristi se za praćenje učinkovitosti procesa ispravljanja grešaka i identificiranje potreba za dodatnim testiranjem ili refaktoriranjem.

  7. Vrijeme izvršavanja testova (eng. Test Execution Time)

    • Opis: Mjeri ukupno vrijeme potrebno za izvršavanje svih testova.
    • Primjena: Koristi se za optimizaciju testnog procesa, identifikaciju testova koji traju predugo i poboljšanje učinkovitosti testiranja.

IZVJEŠTAVANJE

Tokom cijele faze testiranja i izvršavanja rabiti će se sljedeći oblici izvještavanja:

  1. Dnevni izvještaji

    • Opis: Svakodnevno izvještavanje pruža ažurirane informacije o napretku testiranja, trenutnom statusu testnih slučajeva, i novootkrivenim greškama. Dnevni izvještaji su kratki i fokusirani na ključne aktivnosti i probleme.
    • Sadržaj:
      • Broj izvršenih testnih slučajeva
      • Broj prošlih/palih testova
      • Novi defekti otkriveni tijekom dana
      • Status kritičnih defekata
      • Planirane aktivnosti za sljedeći dan
    • Distribucija: E-mailom voditeljima projekta i relevantnim zainteresiranim stranama.

  2. Tjedni izvještaji

    • Opis: Tjedni izvještaji pružaju detaljniji pregled napretka testiranja kroz tjedan, identificirajući trendove i ključna problematična područja. Ovi izvještaji omogućuju analizu i planiranje aktivnosti za naredni tjedan.
    • Sadržaj:
      • Sažetak ukupnog broja izvršenih testova
      • Stopa prolaska/pada testova
      • Ukupni broj otkrivenih grešaka, kategoriziranih po ozbiljnosti
      • Gustoća grešaka
      • Pokrivenost testovima
      • Prosječno vrijeme za otklanjanje grešaka
      • Pregled statusa kritičnih defekata
      • Planirane aktivnosti i prioriteti za naredni tjedan
    • Distribucija: E-mailom voditeljima projekta, menadžmentu i ostalim relevantnim zainteresiranim stranama.

  3. Mjesečni izvještaji

    • Opis: Mjesečni izvještaji pružaju sveobuhvatnu analizu napretka testiranja kroz mjesec. Fokusirani su na postignuća, identificiranje dugoročnih trendova i evaluaciju učinkovitosti testiranja.
    • Sadržaj:
      • Sažetak ključnih aktivnosti i postignuća
      • Detaljna analiza metrika testiranja (gustoća grešaka, pokrivenost testovima, itd.)
      • Stopa ponovljenih grešaka
      • Evaluacija učinkovitosti procesa ispravljanja grešaka
      • Pregled svih kritičnih i neriješenih defekata
      • Identifikacija područja za poboljšanje
      • Planovi i strategije za naredni mjesec
    • Distribucija: Prezentacija voditeljima projekta, menadžmentu i ključnim dionicima.

  4. Ad-hoc izvještaji

    • Opis: Ad-hoc izvještaji se generiraju prema potrebi, obično kada se identificiraju kritični defekti ili problemi koji zahtijevaju hitnu pažnju. Također se mogu koristiti za izvještavanje o specifičnim zahtjevima menadžmenta ili drugih zainteresiranih strana.
    • Sadržaj: Prilagođeni sadržaj prema specifičnim zahtjevima i situacijama.
    • Distribucija: E-mailom zainteresiranim stranama.

TESTNI TIM

U procesu testiranja softvera za praćenje rada dječjeg vrtića, definiran je testni tim koji će biti izravno uključen u sve faze testiranja. Zbog specifičnosti projekta, testni tim sastoji se od jedne osobe koja će preuzeti sve ključne uloge i odgovornosti u procesu testiranja.

Ime i prezime: Marta Kovač Uloga: Voditelj testiranja i testni inženjer Odgovornosti:

  1. Planiranje i organizacija testiranja

    • Izrada detaljnog testnog plana koji uključuje strategiju testiranja, resurse, raspored i kriterije prihvaćanja.
    • Definiranje testnih slučajeva i testnih scenarija na temelju zahtjeva projekta.
    • Priprema testnog okruženja

  2. Postavljanje i konfiguracija testnog okruženja, uključujući potrebni hardver i softver.

    • Instalacija i konfiguracija alata za testiranje i analizu koda.
    • Izvršenje testiranja

  3. Provođenje svih faza testiranja, uključujući funkcionalno, integracijsko, regresijsko i prihvatno testiranje.

    • Izvršavanje testnih slučajeva, bilježenje rezultata i uspoređivanje s očekivanim ishodima.
    • Identifikacija, dokumentiranje i prijavljivanje grešaka i problema pronađenih tijekom testiranja.
    • Izvještavanje o napretku

  4. Izrada dnevnih, tjednih i mjesečnih izvještaja o napretku testiranja i otkrivenim greškama.

    • Komunikacija s ostalim članovima projektnog tima o statusu testiranja i ključnim nalazima.
    • Upravljanje defektima

  5. Praćenje prijavljenih defekata kroz cijeli njihov životni ciklus, od prijave do ispravljanja.

    • Suradnja s razvojnim timom na analizi i ispravljanju grešaka.
    • Osiguranje kvalitete

  6. Osiguranje da su svi aspekti softvera temeljito testirani i da ispunjavaju definirane kriterije prihvaćanja.

    • Provođenje evaluacije kvalitete koda koristeći alate kao što su SonarLint i Code Metrics.
    • Kontinuirano poboljšanje

  7. Analiza rezultata testiranja kako bi se identificirala područja za poboljšanje u procesu testiranja.

    • Implementacija najboljih praksi i novih metoda testiranja za poboljšanje kvalitete i učinkovitosti.

Marta Kovač preuzima sve ključne uloge i odgovornosti unutar testnog tima, osiguravajući temeljitost i učinkovitost procesa testiranja softvera za praćenje rada dječjeg vrtića. Kroz sveobuhvatan pristup planiranju, izvršenju i izvještavanju, Marta će osigurati da softver ispunjava sve postavljene kriterije kvalitete i pouzdanosti.

KRITERIJI USPJEHA

Za uspjeh testiranja softvera za praćenje rada dječjeg vrtića, definirani su jasni kriteriji koji određuju kada se testiranje smatra uspješnim ili neuspješnim. Ovi kriteriji osiguravaju da softver ispunjava sve postavljene zahtjeve kvalitete i pouzdanosti prije nego što bude pušten u proizvodnju.

Kriteriji za uspjeh testiranja:

  1. Prolazak kritičnih testova

    • Svi testovi koji se odnose na kritične funkcionalnosti softvera (npr. prijavljivanje i registriranje korisnika, upisivanje djece, administriranje zaposlenika i djece) moraju proći bez ikakvih grešaka.
    • Kritične funkcionalnosti su one koje su ključne za osnovno funkcioniranje sustava i koje bi, u slučaju kvara, mogle ozbiljno utjecati na rad vrtića.

  2. Prolazak visokog postotka testova

    • Minimalno 95% svih definiranih testnih slučajeva mora uspješno proći.
    • Ovaj kriterij osigurava da je većina funkcionalnosti sustava temeljito testirana i da ispravno radi.

  3. Pokrivenost testovima

    • Pokrivenost koda jediničnim testovima mora biti najmanje 80%.
    • Ovaj kriterij osigurava da su svi ključni dijelovi koda adekvatno testirani i smanjuje rizik od neočekivanih grešaka.

  4. Prihvatljiva razina defekata

    • Ne smije biti otvorenih kritičnih ili visokoprioritetnih defekata u trenutku završetka testiranja.
    • Svi prijavljeni defekti moraju biti riješeni ili označeni kao prihvatljivi rizik uz odobrenje dionika.
    • Manji defekti, koji ne utječu na osnovnu funkcionalnost i mogu se popraviti u kasnijim iteracijama, mogu biti prisutni, ali njihov broj mora biti minimalan i ne smiju ometati korisnike.

  5. Stabilnost sustava

    • Softver mora pokazati stabilnost tijekom kontinuiranog rada i pod opterećenjem koje odgovara stvarnim uvjetima korištenja.
    • Ovaj kriterij osigurava da sustav može pouzdano raditi u produkcijskom okruženju bez rušenja ili značajnih performansnih problema.

Kriteriji za neuspjeh testiranja:

  1. Neuspjeh kritičnih testova

    • Ako bilo koji test koji se odnosi na kritične funkcionalnosti ne uspije, testiranje se smatra neuspješnim.
    • Kritične funkcionalnosti moraju raditi ispravno kako bi se osigurala osnovna funkcionalnost sustava.

  2. Nizak postotak uspješnih testova

    • Ako manje od 95% svih definiranih testnih slučajeva prođe, testiranje se smatra neuspješnim.
    • Ovaj prag osigurava da je sustav dovoljno testiran i pouzdan za korištenje.

  3. Niska pokrivenost testovima

    • Ako pokrivenost koda jediničnim testovima padne ispod 80%, testiranje se smatra neuspješnim.
    • Dovoljna pokrivenost testovima je ključna za smanjenje rizika od skrivenih grešaka.

  4. Prisustvo kritičnih defekata

    • Ako su u sustavu prisutni otvoreni kritični ili visokoprioritetni defekti, testiranje se smatra neuspješnim.
    • Defekti koji ozbiljno utječu na funkcionalnost ili sigurnost sustava moraju biti riješeni prije puštanja u produkciju.

  5. Nestabilnost sustava

    • Ako sustav pokazuje nestabilnost ili značajne performansne probleme tijekom testiranja, testiranje se smatra neuspješnim.
    • Stabilnost je ključna za osiguranje pouzdanosti i kontinuiranog rada sustava.
Clone this wiki locally