Što je ispitivanje prihvaćenosti korisnika (UAT): cjelovit vodič

what is user acceptance testing

Saznajte što je ispitivanje prihvaćenosti korisnika (UAT), zajedno s njegovom definicijom, vrstama, koracima i primjerima:

Moje pravilo broj jedan kada pokušavam razumjeti novi koncept glasi: ime će uvijek biti relevantno i uglavnom doslovno značenje (u tehničkom kontekstu).

Otkrivanje što je to dat će vam početno razumijevanje i pomoći mi da započnem.

html intervju pitanja i odgovori pdf

=> Kliknite ovdje za cjelovitu seriju vodiča o planu ispitivanja

Stavimo ovaj koncept na test.

=> Pročitajte sve vodiče u našoj seriji Ispitivanje prihvaćanja.

Što ćete naučiti:

• Što je ispitivanje prihvaćenosti korisnika?
  • Kada se izvodi?
  • Tko izvodi UAT?
  • Potreba za testiranjem prihvaćanja korisnika
  • Postupak ispitivanja prihvaćanja korisnika
  • Upravljanje UAT-om
  • Planiranje UAT ispitivanja
  • Dizajn ispitivanja prihvaćanja korisnika
  • Izvršenje testa
  • Alati i metodologije
  • UAT u okretnom okruženju
  • UAT tim - uloge i odgovornosti
• 7 izazova UAT-a i plana ublažavanja
• Testiranje sustava protiv testiranja prihvaćanja korisnika
• Zaključak
  • Preporučena literatura

Što je ispitivanje prihvaćenosti korisnika?

Znamo što je ispitivanje, prihvaćanje znači odobrenje ili sporazum. Korisnik u kontekstu softverskog proizvoda je ili potrošač softvera ili osoba koja je zatražila da se on izradi za njega (klijenta).

Dakle, slijedeći moje pravilo - definicija će biti:

Testiranje prihvaćanja korisnika (UAT), također poznato kao beta ili testiranje krajnjeg korisnika, definirano je kao testiranje softvera od strane korisnika ili klijenta kako bi se utvrdilo može li se prihvatiti ili ne. Ovo je završno ispitivanje provedeno nakon završetka funkcionalnog, sistemskog i regresijskog ispitivanja.

Glavna svrha ovog testiranja je provjera valjanosti softvera prema poslovnim zahtjevima. Ovu provjeru valjanosti provode krajnji korisnici koji su upoznati s poslovnim zahtjevima.

UAT, alfa i beta testiranje su različite vrste ispitivanja prihvatljivosti.

Kako je test prihvaćanja korisnika posljednje testiranje koje se provodi prije pokretanja softvera, očito je ovo zadnja šansa za kupca da testira softver i izmeri je li prikladan za tu svrhu.

Kada se izvodi?

To je obično posljednji korak prije puštanja proizvoda u promet ili prije nego što se prihvati isporuka proizvoda. To se izvodi nakon što se sam proizvod temeljito ispita (tj nakon testiranja sustava ).

Tko izvodi UAT?

Korisnici ili klijenti - To može biti netko tko kupuje proizvod (u slučaju komercijalnog softvera) ili netko tko je softver proizveo po mjeri putem davatelja usluga softvera ili krajnji korisnik ako im je softver dostupan ispred vremena i kada se traže njihove povratne informacije.

Tim se može sastojati od beta testera ili bi kupac trebao interno odabrati članove UAT-a iz svake grupe organizacije kako bi se svaka korisnička uloga mogla testirati u skladu s tim.

Potreba za testiranjem prihvaćanja korisnika

Programeri i funkcionalni testeri tehnički su ljudi koji validiraju softver protiv funkcionalne specifikacije . Zahtjeve tumače prema svom znanju i razvijaju / testiraju softver (ovdje je važnost znanja iz domene).

Ovaj je softver potpun u skladu s funkcionalnim specifikacijama, ali postoje neki poslovni zahtjevi i procesi koji su poznati samo krajnjim korisnicima ili se propuštaju u komunikaciji ili se pogrešno tumače.

Ovo testiranje igra važnu ulogu u provjeri valjanosti ispunjavanja svih poslovnih zahtjeva ili ne prije puštanja softvera u upotrebu na tržištu. Korištenje podataka uživo i slučajevi stvarne upotrebe čine ovo testiranje važnim dijelom ciklusa izdavanja.

Mnoge tvrtke koje su pretrpjele velike gubitke zbog problema nakon objave znaju važnost uspješnog testa prihvaćanja korisnika. Cijena popravljanja nedostataka nakon puštanja višestruko je veća od otklanjanja nedostataka prije.

Je li UAT stvarno potreban?

Nakon izvođenja opterećenja sustava, integracijskog i regresijskog ispitivanja zapitalo bi se o potrebi ovog testiranja. Zapravo, ovo je najvažnija faza projekta jer je ovo vrijeme u kojem će korisnici koji će zapravo koristiti sustav provjeriti valjanost sustava prema njegovoj namjeni.

UAT je test faza koja u velikoj mjeri ovisi o perspektivi krajnjih korisnika i domenskom znanju odjela koji predstavlja krajnje korisnike.

Zapravo, zaista bi bilo korisno za poslovne timove ako bi bili uključeni u projekt prilično rano, kako bi mogli pružiti svoje stavove i doprinose koji bi pomogli učinkovitom korištenju sustava u stvarnom svijetu.

Postupak ispitivanja prihvaćanja korisnika

Najlakši način da se taj proces shvati jest da se o njemu misli kao o projektu autonomnog testiranja - što znači da će imati plan, dizajn i faze izvođenja.

Sljedeći su preduvjeti prije početka faze planiranja:

# 1) Skupite ključne kriterije prihvaćanja

Jednostavno rečeno, kriteriji prihvaćanja su popis stvari koje će se procijeniti prije prihvaćanja proizvoda.

To bi mogle biti dvije vrste:

(i) Funkcionalnost aplikacije ili poslovno povezano

Idealno bi bilo da se provjere sve ključne poslovne funkcije, ali zbog različitih razloga, uključujući vrijeme, nije praktično sve to raditi. Stoga, sastanak ili dva s klijentom ili korisnicima koji će biti uključeni u ovo testiranje mogu nam dati ideju o tome koliko će testiranja biti uključeno i koji će se aspekti testirati.

(ii) Ugovorni - Nećemo ulaziti u ovo, a sudjelovanje QA tima u svemu tome gotovo je ništa. Početni ugovor koji se sastavi i prije početka SDLC-a se pregledava i postiže se sporazum jesu li svi aspekti ugovora isporučeni ili ne.

Usredotočit ćemo se samo na funkcionalnost aplikacije.

# 2) Definirajte opseg sudjelovanja u osiguranju kvalitete.

Uloga QA tima jedna je od sljedećih:

(i) Nema uključenosti - Ovo je vrlo rijetko.

(ii) pomoć u ovom ispitivanju - Najčešće. U ovom slučaju, naše sudjelovanje moglo bi biti osposobljavanje korisnika UAT-a kako se koristiti aplikacijom i biti u pripravnosti tijekom ovog testiranja kako bismo bili sigurni da možemo pomoći korisnicima u slučaju bilo kakvih poteškoća. Ili u nekim slučajevima, osim što smo u stanju pripravnosti i pomažemo, možda ćemo podijeliti njihove odgovore i zabilježiti rezultate ili zapisnike pogrešaka itd., Dok korisnici izvode stvarno testiranje.

(iii) Izvršite UAT i predstavite rezultate - Ako je to slučaj, korisnici će usmjeriti područja AUT-a koja žele procijeniti, a samu ocjenu provodi QA tim. Nakon završetka, rezultati se prezentiraju klijentima / korisnicima i oni će donijeti odluku jesu li rezultati koji su im na raspolaganju dovoljni ili ne i u skladu s njihovim očekivanjima kako bi prihvatili AUT. Nikada nije odluka QA tima.

Ovisno o konkretnom slučaju, odlučujemo koji je pristup najbolji.

Primarni ciljevi i očekivanja:

Obično UAT poduzima stručnjak za predmetno pitanje (SME) i / ili poslovni korisnik, koji bi mogao biti vlasnik ili kupac testiranog sustava. Slično fazi testiranja sustava, faza UAT također obuhvaća vjerske faze prije nego što se privede kraju.

Ključne aktivnosti svake faze UAT-a definirane su u nastavku:

Upravljanje UAT-om

Slično testiranju sustava, za UAT se provodi učinkovito upravljanje kako bi se osigurala postojanje kvalitetnih vrata zajedno s definiranim kriterijima za ulaz i izlaz (navedeni u nastavku **).

** Imajte na umu da je to samo smjernica. To bi se moglo izmijeniti na temelju potreba i zahtjeva projekta.

Planiranje UAT ispitivanja

Proces je gotovo isti kao i kod redoviti plan ispitivanja u fazi sustava.

Najčešći pristup koji se slijedi u većini projekata je zajedničko planiranje faza testiranja sustava i UAT-a. Za više informacija o planu ispitivanja UAT-a, zajedno s uzorkom, pogledajte odjeljke UAT-a u priloženom dokumentu plana ispitivanja.

Plan ispitivanja prihvaćanja korisnika

(Ovo je isto što biste pronašli i na našoj web stranici za QA seriju treninga).

Kliknite na donju sliku i pomaknite se prema dolje da biste pronašli uzorak dokumenta testa u različitim formatima. U tom predlošku provjerite odjeljak UAT.

Datumi, okruženje, akteri (tko), komunikacijski protokoli, uloge i odgovornosti, predlošci, rezultati i njihov postupak analize, kriteriji za ulazak-izlazak - sve ovo i sve ostalo što je relevantno naći će se u planu testiranja UAT-a.

Bez obzira sudjeluje li QA tim, djelomično ili uopće ne sudjeluje u ovom testu, naš je posao planirati ovu fazu i osigurati da se sve uzme u obzir.

=> Ovdje je uzorak dokumenta korisničkog plana ispitivanja prihvaćanja

Dizajn ispitivanja prihvaćanja korisnika

U ovom se koraku koriste prikupljeni kriteriji prihvaćanja od korisnika. Uzorci mogu izgledati kao što je prikazano dolje.

(To su izvatci iz CSTE CBOK . Ovo je jedna od najboljih dostupnih referenci o ovom ispitivanju.)

Predložak ispitivanja prihvaćanja korisnika:

Na temelju kriterija, mi (QA tim) im dajemo korisnicima popis UAT test slučajeva. Ovi se testni slučajevi ne razlikuju od naših uobičajenih testnih slučajeva sustava. Oni su samo podskup dok testiramo sve aplikacije, za razliku od ključnih funkcija.

Uz njih, podaci, predlošci za bilježenje rezultata ispitivanja, administrativni postupci, mehanizam evidentiranja kvarova itd. Moraju biti na mjestu prije nego što prijeđemo na sljedeću fazu.

Izvršenje testa

Obično, kada je to moguće, ovo se testiranje događa u nekakvoj postavci u konferencijskoj ili ratnoj sobi gdje korisnici, premijeri i predstavnici QA tima sjede zajedno dan-dva i rade na svim slučajevima ispitivanja prihvaćanja.

Ili u slučaju da QA tim provodi testove, pokrećemo test slučajeve na AUT.

Jednom kada se izvrše svi testovi i dobiju rezultati, Odluka o prihvaćanju je izrađena. To se također naziva Odluka Idi / Ne-kreni . Ako su korisnici zadovoljni, riječ je o kretanju ili pak o zabrani.

Donošenje odluke o prihvaćanju obično je kraj ove faze.

Alati i metodologije

Tipično je vrsta softverskih alata koji se koriste tijekom ove faze testiranja slična je alatima koji se koriste tijekom izvođenja funkcionalnog testiranja.

Alati:

Budući da ova faza uključuje provjeru valjanosti cjelovitih tijekova aplikacije, možda će biti teško imati jedan alat za potpuno automatiziranje ove provjere valjanosti. Međutim, donekle bismo mogli iskoristiti automatizirane skripte razvijene tijekom testiranja sustava.

Slično testiranju sustava, korisnici bi također koristili alate za upravljanje testovima i upravljanje nedostacima kao što su QC, JIRA itd. Ovi alati mogu se konfigurirati za kumuliranje podataka za fazu prihvaćanja korisnika.

Metodologije:

Iako su uobičajene metodologije poput specifičnih poslovnih korisnika koji izvode UAT proizvoda i dalje relevantne, u istinski globalnom svijetu kakav je danas, ispitivanje prihvaćanja korisnika ponekad mora uključivati ​​različite kupce iz različitih zemalja na temelju proizvoda.

Na primjer, web mjesto e-trgovine koristili bi kupci širom svijeta. U ovakvim scenarijima testiranje gužve bilo bi najbolja održiva opcija.

Ispitivanje gužve je metodologija u kojoj ljudi iz cijelog svijeta mogu sudjelovati i potvrditi upotrebu proizvoda te dati prijedloge i preporuke.

Izgrađene su platforme za testiranje gužve koje danas koriste mnoge organizacije. Na platformi je smješteno web mjesto ili proizvod koji se mora testirati na masi, a kupci se mogu nominirati za provjeru valjanosti. Zatim se analiziraju i daju prioriteti dane povratne informacije.

kako testirate web usluge

Metodologija ispitivanja gužve pokazuje se učinkovitijom jer se puls kupaca širom svijeta može lako razumjeti.

UAT u okretnom okruženju

Agilan okoliš je dinamičnije prirode. U agilnom svijetu, poslovni korisnici bit će uključeni tijekom sprinta projekta, a projekt će se poboljšati na temelju njihovih povratnih povratnih informacija.

Na početku projekta, poslovni korisnici bili bi ključni dionici koji bi osigurali zahtjev ažurirajući zaostatak proizvoda. Tijekom završetka svakog sprinta, poslovni korisnici sudjelovali bi u demonstraciji sprinta i bili bi dostupni za pružanje bilo kakvih povratnih informacija.

Štoviše, planirala bi se faza UAT prije završetka sprinta, gdje bi poslovni korisnici vršili validaciju.

Povratne informacije primljene tijekom demonstracije sprinta i sprinta UAT, sakupljaju se i dodaju natrag u zaostatak proizvoda koji se neprestano pregledava i daje im prioritet. Stoga su u agilnom svijetu poslovni korisnici bliži projektu i češće ga ocjenjuju za njegovu upotrebu, za razliku od tradicionalnih projekata vodopada.

UAT tim - uloge i odgovornosti

Tipična organizacija UAT-a imala bi sljedeće uloge i odgovornosti. UAT tim podržao bi voditelj projekta, razvojni i ispitni timovi na temelju njihovih potreba.

7 izazova UAT-a i plana ublažavanja

Nije važno jeste li dio izdanja vrijednog milijardu dolara ili startup tima, trebali biste prevladati sve ove izazove za isporuku uspješnog softvera za krajnjeg korisnika.

# 1) Postupak postavljanja i postavljanja okruženja:

Izvođenje ovog testa u istom okruženju koje koristi tim za funkcionalne testove zasigurno će zanemariti stvarne slučajeve upotrebe. Također, ključne aktivnosti testiranja poput ispitivanja performansi ne mogu se provesti u testnom okruženju s nepotpunim podaci ispitivanja .

Za ovo ispitivanje treba uspostaviti zasebno okruženje nalik proizvodnji.

Jednom kada se UAT okruženje odvoji od testnog, morate učinkovito kontrolirati ciklus oslobađanja. Nekontrolirani ciklus izdanja može dovesti do različitih verzija softvera u testnom i UAT okruženju. Dragocjeno vrijeme ispitivanja prihvaćanja gubi se kada softver nije testiran na najnovijoj verziji.

U međuvremenu, vrijeme potrebno za praćenje problema s netočnom verzijom softvera je veliko.

# 2) Planiranje ispitivanja:

Ovo ispitivanje treba planirati s jasnim planom ispitivanja prihvaćanja u fazi analize zahtjeva i projektiranja.

U strateškom planiranju treba utvrditi niz slučajeva stvarne uporabe za izvršenje. Vrlo je važno definirati ciljeve ispitivanja za ovo ispitivanje jer cjelovito izvršavanje testa nije moguće za velike aplikacije u ovoj fazi testiranja. Testiranje bi se trebalo provesti davanjem prvo prioriteta ključnim poslovnim ciljevima.

Ovo se ispitivanje provodi na kraju ciklusa ispitivanja. Očito je da je to najkritičnije razdoblje za izdavanje softvera. Kašnjenje u bilo kojoj od prethodnih faza razvoja i testiranja pojest će vrijeme UAT-a.

najbolji špijunski uređaj za mobitele

Nepravilno planiranje ispitivanja, u najgorim slučajevima, dovodi do preklapanja između testiranja sustava i UAT-a. Zbog manje vremena i pritiska da se poštuju rokovi, softver se postavlja u ovo okruženje čak i ako funkcionalno testiranje nije završeno. Ključni ciljevi ovog testiranja ne mogu se postići u takvim situacijama.

UAT test plan treba pripremiti i priopćiti timu prije početka ovog testa. To će im pomoći u planiranju testova, pisanju test slučajeva i test skripti i stvaranju UAT okruženja.

# 3) Rukovanje novim poslovnim zahtjevima kao incidenti / nedostaci:

Nejasnoće u zahtjevima zahvaćaju se u fazi UAT-a. UAT testeri pronalaze probleme koji nastaju zbog dvosmislenih zahtjeva (promatrajući kompletno korisničko sučelje koje nije bilo dostupno tijekom faze prikupljanja zahtjeva) i prijavljuju ga kao kvar.

Kupac očekuje da će se oni popraviti u trenutnom izdanju, ne uzimajući u obzir vrijeme za zahtjeve za promjenom. Ako vodstvo projekta ne donese pravodobnu odluku o ovim promjenama u posljednjem trenutku, to bi moglo dovesti do neuspjeha izdanja.

# 4) Nekvalificirani testeri ili testeri bez poslovnog znanja:

Kad nema stalnog tima, tvrtka odabire osoblje UAT-a iz različitih internih odjela.

Čak i ako je osoblje dobro upoznato s poslovnim potrebama ili ako nije osposobljeno za nove zahtjeve koji se razvijaju, ne mogu izvršiti učinkovit UAT. Također, netehnički poslovni tim mogao bi se suočiti s mnogim tehničkim poteškoćama u izvršavanju testnih slučajeva.

U međuvremenu, dodjeljivanje testera na kraju UAT ciklusa ne dodaje nikakvu vrijednost projektu. Malo vremena za obuku osoblja UAT-a može značajno povećati šanse za uspjeh UAT-a.

# 5) Nepravilni komunikacijski kanal:

Komunikacija između daljinskog razvoja, testiranja i UAT tima je teža. Komunikacija e-poštom često je vrlo teška kada imate inozemni tehnološki tim. Mala nejasnoća u izvješćima o incidentima može odgoditi njegovo popravljanje za jedan dan.

Pravilno planiranje i učinkovita komunikacija presudni su za učinkovitu timsku suradnju. Projektni timovi trebali bi koristiti internetski alat za bilježenje nedostataka i pitanja. To će vam pomoći ravnomjerno rasporediti radno opterećenje i izbjeći prijavljivanje dupliciranih problema.

# 6) Zatražiti od funkcionalnog testnog tima da izvrši ovo testiranje:

Nema gore situacije od traženja funkcionalnog ispitnog tima da izvrši UAT.

Kupci prebacuju svoju odgovornost na testni tim zbog nedostatka resursa. Cjelokupna svrha ovog testiranja u takvim se slučajevima ugrožava. Kad softver počne raditi, krajnji će korisnici brzo uočiti probleme koje funkcionalni testeri ne smatraju stvarnim scenarijima.

Rješenje za ovo je dodijeliti ovo testiranje predanim i vještim testerima koji imaju poslovno znanje.

# 7) Igra krivnje

Ponekad poslovni korisnici samo pokušavaju pronaći razloge za odbijanje softvera. Moglo bi biti njihovo samozatajno pokazati da su superiorni ili okriviti razvojni i ispitni tim da bi dobili poštovanje u poslovnom timu. To je vrlo rijetko, ali događa se u timovima s unutarnjom politikom.

Vrlo je teško nositi se s takvim situacijama. Međutim, izgradnja pozitivnog odnosa s poslovnim timom definitivno bi pomogla izbjeći igru ​​krivnje.

Nadam se da će vam ove smjernice sigurno pomoći da izvršite uspješan plan prihvaćanja korisnika prevladavanjem različitih izazova. Pravilno planiranje, komunikacija, izvršavanje i motivirani tim ključevi su uspješnog testiranja prihvaćanja korisnika.

Testiranje sustava protiv testiranja prihvaćanja korisnika

Uključenost testnog tima započinje prilično rano u projektu odmah od faze analize zahtjeva.

Kroz životni ciklus projekta izvodi se neka vrsta provjere valjanosti projekta, tj. Statičko ispitivanje , Jedinstveno testiranje, Testiranje sustava, integracijsko testiranje, testiranje od kraja do kraja ili regresijsko testiranje. To nam ostavlja da bolje razumijemo ispitivanje provedeno u fazi UAT i koliko se ono razlikuje od ostalih ispitivanja izvršenih ranije.

Iako vidimo razlike u SIT-u i UAT-u, važno je iskoristiti sinergije, ali i dalje zadržati neovisnost između obje faze što bi omogućilo brže vrijeme za tržište.

Zaključak

# 1) UAT se ne odnosi na stranice, polja ili gumbe. Temeljni pretpostavka čak i prije nego što ovaj test započne jest da su sve osnovne stvari testirane i rade u redu. Ne daj Bože, korisnici smatraju da je programska greška tako osnovna - to je vrlo loša vijest za QA tim. :(

#dva) Ovo testiranje govori o subjektu koji je primarni element u poslu.

Dopustite mi da vam dam primjer: Ako je AUT sustav za prodaju karata, neće se raditi o UAT-u, traženju izbornika koji otvara stranicu itd. Riječ je o kartama i njihovoj rezervaciji, državama koje može poduzeti, putovanju kroz sustav, itd.

Još Primjer, ako je web mjesto auto kuće, tada je fokus na 'automobilu i njegovoj prodaji', a ne na web mjestu. Stoga je osnovna djelatnost ono što je provjereno i potvrđeno i tko je to bolji od vlasnika poduzeća. Zato je ovo testiranje najsmislenije kada je kupac u velikoj mjeri uključen.

# 3) UAT je također oblik testiranja u svojoj osnovi, što znači da postoji dobra šansa za identificiranje nekih bugova i u ovoj fazi . Ponekad se dogodi. Osim činjenice da je QA tim velika eskalacija, UAT-ove greške obično znače sastanak da bi se sjedilo i razgovaralo o tome kako s njima postupati jer nakon ovog testiranja obično nema vremena za popravljanje i ponovno testiranje.

Odluka bi bila:

• Pritisnite datum pokretanja, prvo riješite problem, a zatim idite dalje.
• Ostavite bubu kakva jest.
• Smatrajte to dijelom zahtjeva za promjenom budućih izdanja.

# 4) UAT je klasificiran kao alfa i beta testiranje, ali ta klasifikacija nije toliko važna u kontekstu tipičnih projekata razvoja softvera u uslužnoj industriji.

• Alfa testiranje je kada se UAT izvodi u okruženju proizvođača softvera i značajniji je u kontekstu komercijalnog softvera.
• Beta testiranje je kada se UAT provodi u proizvodnom okruženju ili klijentovom okruženju. To je češće za aplikacije okrenute kupcima. Ovdje su korisnici stvarni kupci poput vas i mene u ovom kontekstu.

# 5) Većinu vremena u redovnom projektu razvoja softvera, UAT se provodi u QA okruženje ako nema scenskog ili UAT okruženja.

Ukratko, najbolji način da saznate je li vaš proizvod prihvatljiv i odgovara svojoj namjeni jest da ga zapravo stavite pred korisnike.

Organizacije ulaze u agilni način isporuke, poslovni korisnici se sve više uključuju, a projekti se poboljšavaju i isporučuju putem petlji povratnih informacija. Sve je gotovo, faza prihvaćanja korisnika smatra se vratom za ulazak u implementaciju i proizvodnju.

Kakvo je vaše iskustvo s UAT-om? Jeste li bili u stanju pripravnosti ili ste testirali svoje korisnike? Jesu li korisnici pronašli neke probleme? Ako da, kako ste se nosili s njima?

=> Ovdje pročitajte i SVE tutorijale iz ove serije

=> Posjetite ovdje za cjelovitu seriju vodiča o planu ispitivanja

Preporučena literatura

• Alfa testiranje i beta testiranje (cjelovit vodič)
• Što je ispitivanje prihvaćenosti (cjelovit vodič)
• Potpuni vodič za testiranje provjere izrade (BVT testiranje)
• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Vrste testiranja softvera: različite vrste ispitivanja s pojedinostima
• Vodič za ispitivanje skladišta podataka ETL-a (cjelovit vodič)
• Vodič za GUI testiranje: Kompletni vodič za testiranje korisničkog sučelja (UI)