acceptance testing documentation with real time scenarios
Dokumentacija o sprejemnosti (del II):
Prejšnja vadnica | NASLEDNJA Vadnica
Ta vadnica je nadaljevanje prejšnje vaje, kjer smo razpravljali o tem, kaj je sprejemno testiranje, kdaj ga je treba opraviti, kdo ga izvaja, njegov pomen, vrste, postopek, vpliv na različne ekipe itd.
primer funkcionalne zahteve je _________
Dokumenti igrajo zelo pomembno vlogo pri preverjanju sprejemljivosti in vsa vprašanja v zvezi z dokumentom imajo zelo negativen vpliv. Če se ne izvede ustrezen pregled, lahko to celo privede do okvare izdelka.
=> Kliknite tukaj za celotno serijo vadnic o načrtu preizkusov
V tej vadnici bomo izvedeli več o različni dokumentaciji, vključeni v preskus sprejemljivosti, tj. Načrt sprejemnega preizkusa, kontrolni seznam za pregled načrta preizkusa, predloga preskusa sprejemljivosti, primeri, ki temeljijo na scenarijih v realnem času, kako podrobno prepoznati in napisati sprejemne teste itd .
Kaj se boste naučili:
- Načrt sprejemnega preizkusa
- Predloga načrta sprejemnega preskusa
- Pregled načrta sprejemnega preizkusa
- Preskusi sprejemljivosti
- Pregled sprejemnih testov
- Zaključek
- Priporočeno branje
Načrt sprejemnega preizkusa
Tako kot kateri koli drug testni načrt tudi testni načrt vključuje nekatere komponente, kot so obseg, pristop, testno okolje, viri, odgovornosti, reference sprejemnih testov, merila za vstop, merila za izhod, orodja itd.
Edina stvar, ki načrt za sprejemni test razlikuje od običajnega testnega načrta, so dejavniki, ki vodijo do poslovne odločitve. Načrt sprejemnega preizkusa je ena ključnih dokumentov, ki vsebuje smernice za izvedbo preskusov sprejemljivosti za določen projekt.
Načrt sprejemnega preizkusa je treba pregledati in odobriti pred izvedbo sprejemnega preizkusa. Vse nadaljnje spremembe morajo biti ponovno pregledane in odobrene ter morajo biti v teku.
Pregled načrta sprejemnega preizkusa običajno opravijo upravitelji / poslovni analitiki / kupci.
Ključne točke, ki jih je treba upoštevati pri oblikovanju načrta sprejemnega preizkusa:
- Mora biti Podrobno in natančno. Vključevati mora le tisto, kar je potrebno za testiranje in katere informacije so potrebne skupini za izvedbo testiranja.
- Mora biti Jasno in jedrnato . Brez dvoumnosti. Če sploh obstaja nekaj, kar bi lahko privedlo do zmede, potem to podrobneje obrazložite, vendar naj bo kratko in učinkovito.
- Vsaka komponenta v dokumentu zapisati ob upoštevanju le poslovnih zahtev.
- Zanesljivo in prilagodljivo - Posodabljati bi ga bilo treba v prihodnjih izdajah.
- Dosledno - V prihodnosti ne bi smel imeti več sprememb.
- Upoštevajte predlogo organizacije ali stranke.
Predloga načrta sprejemnega preskusa
Tu si bomo ogledali skupno predlogo za Načrt sprejemnega preizkusa, ki jo je mogoče nadalje prilagoditi v skladu s projektnimi zahtevami.
Naslov
Cilj
Zgodovina revizij / dnevnik sprememb
< Ta naj bo v obliki tabele s spodnjimi informacijami:
- Datum - Datum spremembe dokumenta.
- Spremenjeno z - Kdo je spremenil vsebino dokumenta.
- Namen - Zakaj je bil dokument spremenjen.
- Različica - Trenutna različica dokumenta po spremembah (za posamezno izdajo je 1.0, 1.1, 1.2, 1.3,…. Naslednja izdaja se bo začela od 2, 2.1, 2.2, 2.3,…, seznam se nadaljuje).
- Odobril - Kdo je odobril opravljene spremembe (implicitno pomeni, da je bil dokument pregledan in odobren).
Prva vrstica v tej tabeli bi morala biti podrobnosti o dokumentu. Nato sledi podrobnostim o izvedenih spremembah.>
Kazalo
Reference
Obseg
Uvod
Preizkusni predmeti
Lastnosti, ki jih je treba preizkusiti
Lastnosti, ki jih ni treba preizkusiti
Pristop
Podrobnosti o testnem okolju
Merila za vstop
Preizkusi - če ni napisanih ločenih sprejemnih preizkusov
Vsak test mora vključevati:
- Test #.
- Opis preizkušenega ( Primer : Preverite, ali lahko uporabnik uspešno ustvari račun).
- Poslovna zahteva, na katero se preskuša ta preskus ( Matrica sledljivosti ) - Zelo pomembno.
- Predpogoji:
- Stanje izdelka pred začetkom testiranja (uporabnik bi moral biti uspešno registriran, vendar ne bi smel aktivirati računa, uporabnik bi moral do izdelka dostopati pred vsaj 30 dnevi itd.)
- Kateri koli pogoji strežnika - Če strežnik nekaj časa ne deluje.
- Preskusni koraki: Podroben oštevilčen tok ( Primer: glej spodaj
- Odprite aplikacijo.
- Poskus prijave z veljavnimi poverilnicami z izbranim potrditvenim poljem).
- pričakovani rezultati : Kakšno je pričakovano vedenje koraka>
Sprejemni testi - če so napisani ločeni sprejemni testi
Merila izstopa
Viri
Vloge in odgovornosti
Orodja
Dejavniki poslovnega odločanja
Postopek odjave
Kontaktna točka
Načrt sprejemnega preizkusa se šteje za Glavni testni načrt za fazo .
Pregled načrta sprejemnega preizkusa
Ko je načrt pripravljen, ga je treba pregledati glede popolnosti, nejasnosti, jasnosti, kakovosti itd. Brez dvoma je treba za ustrezne informacije temeljito pregledati celotno vsebino načrta za sprejemni test, vendar ga je treba preveriti glede na nekaj drugih točk, recimo tudi točke kontrolnega seznama.
Tukaj kategoriziramo vsebino in si oglejte točke kontrolnega seznama.
| Kategorija | Točke kontrolnega seznama |
|---|---|
| Preskusi sprejemljivosti | Ali so testi oštevilčeni Ali so predpogoji oštevilčeni Ali je testne korake jasno razumeti Ali so testni koraki končani Ali je pričakovani rezultat popoln Ali je v testih odprto vprašanje (če obstaja, nadaljnje ukrepanje in dokončanje) Ali je sklic na sprejemne teste (če je napisan ločeno) veljaven in obstoječ Ali je sledljivost pravilna Ali je kakšna poslovna zahteva izpuščena za kritje za test |
| Naslov | Ali se naslov ujema z naslovom projekta, kot je povsod naveden? Ali naslov sledi projektnim konvencijam o poimenovanju |
| Zgodovina revizij, kazalo | Ali se vsaki različici različice sledi skladno z načrtom? Ali je bila vsaka sprememba različice ustrezno pregledana in omenjena Ali je pravilnik o različicah pravilen Ali se kazalo ujema z dejansko vsebino načrta Ali je številka strani za vsako vsebino pravilna Ali se številka strani posodobi, če so spremembe v načrtu spremenile številko strani vsebine |
| Reference | Ali so reference obstoječe in veljavne Ali se ujemajo z obsegom Ali so popolni in se upoštevajo za identifikacijo testov |
| Preizkusni elementi, lastnosti, ki jih je treba preizkusiti, lastnosti, ki jih ni treba preizkusiti | Ali so oštevilčeni Ali spada vsaka funkcija / modul / podmodul v obseg Ali lahko načrtovani urnik zajema vse opredeljene testne postavke znotraj? |
| Vstopna merila, izstopna merila | Ali so oštevilčeni Ali so vsa merila podrobno omenjena |
| Podrobnosti o testnem okolju | Ali ima vse omenjene zahtevane konfiguracije Ali je treba upoštevati različico posamezne ali najnovejše konfiguracije? Ali obstajajo VM-ji, okolje obstaja (če ne, navedite možen datum njegove razpoložljivosti) Ali je omenjena metoda izmenjave poverilnic za določen dostop do okolja |
| Viri, vloge in odgovornosti | Ali so odgovornosti za vsako vlogo oštevilčene Ali je mogoče odgovornosti doseči Ali je opredeljeni vir sposoben obvladovati omenjene odgovornosti |
| Orodja | Ali so omenjena vsa orodja Ali so vsa orodja oštevilčena Ali so vsa orodja različna Ali katero koli orodje potrebuje licenco ali obstoječo licenco, veljavno v fazi Ali so navodila za uporabo orodja pravilna in zadostna |
| Dejavniki poslovnega odločanja | Vse omenjene dejavnike Ali so vsi dejavniki oštevilčeni |
| Postopek odjave | Ali je postopek veljaven Ali je postopek sprejemljiv Ali je postopek jasno razumljiv |
| Kontaktna točka | Ali je vir opredeljen kot kontaktna točka, ki je na voljo v organizaciji med fazo? Ali je opredeljeni vir sposoben obvladati fazo |
Vsak testni načrt, ki ustreza zgornjemu dokumentu s kontrolnim seznamom, bo močan dokument tudi za notranje revizije.
Preskusi sprejemljivosti
Sprejemni testi so bili prej znani kot funkcionalni testi. Da bi bilo ime primernejše za fazo sprejemnega testiranja in služilo svojemu namenu, je bilo preimenovano v Preskusi sprejemljivosti. Včasih ga imenujemo tudi Testi strank.
Sprejemni testi vedno izhajajo iz uporabniških zgodb, meril sprejemljivosti in primerov uporabe. To so sistemski testi črne skrinjice in predstavljajo samo tiste poslovne teste, ki jih je treba preveriti. Ti naj bodo namenjeni predvsem vedenju, uporabi in pretokom izdelkov.
Zasnovani sprejemni preskusi se lahko upoštevajo tudi v fazi preskusa sistema v regresijskih ciklih, da se pridobi zaupanje v izdelek, preden se preda v fazo preskusa sprejemljivosti.
Ključne točke, ki si jih je treba zapomniti pred pisanjem sprejemnih testov:
- Vse referenčne dokumente imejte na mestu: Specifikacija programske zahteve, dokument o poslovnih zahtevah, primeri uporabe, uporabniške zgodbe, podatkovna matrika (v primeru logike) itd.
- Osredotočite se samo na poslovne zahteve (preverljive poslovne zahteve).
- Najprej odpravite vse dvome in vprašanja glede poslovnih zahtev.
- Prepričajte se, da vsaj v trenutni izdaji ni sprememb.
Splošna in preprosta predloga za pisanje sprejemnih testov:
To predlogo lahko znova prilagodite glede na potrebe projekta in vključite več informacij.
Zdaj pa si oglejmo nekaj pogostih scenarijev in si oglejmo, kako lahko na njih zapišemo scenarije preizkusa sprejemljivosti.
Primer 1: Ravnanje z uporabniškim računom
V tem primeru lahko uporabniki ustvarijo, si ogledajo, posodobijo in deaktivirajo svoj račun. Na splošno gre za CRUD operacijo (Ustvari, preberi, posodobi in izbriši). Tako bomo neposredno preučili 4 glavne scenarije.
Skupaj s tem imamo pri pregledovanju in posodabljanju v realnem času obdelave uporabniških računov veliko področij.
Nadaljevanje s pisnimi sprejemnimi testi:
Test 1: Registracija / prijava / ustvarjanje računa, preverite, ali je uporabnik sposoben:
- Ustvari račun.
- Aktivirajte račun.
- Aktivirajte račun samo enkrat (tukaj je treba aktivacijsko povezavo preizkusiti 2ndČeprav gre za negativno preskušanje, je to ena glavnih točk preverjanja, ki jo je treba upoštevati).
Test 2: Za dostop do podatkov o računu in ogled teh podatkov preverite, ali je uporabnik sposoben:
- Prijavite se v račun.
- Oglejte si različne odseke v profilu (če je odsek Profil kategoriziran, morajo biti vidne vse kategorije).
- Preverite, ali so podatki, prikazani v profilu, pravilni glede na uporabnikov vnos.
Test 3: Če želite posodobiti podatke o računu, preverite, ali lahko uporabnik:
- Posodobi podatke o računu (profil):
- Posodobite vsako kategorijo profila.
- Preverite, ali so informacije o posodobitvi pravilno prikazane v profilu.
- Preverite, ali uporabnik ne more posodobiti informacij v profilu (v nekaterih aplikacijah imena, priimka, uporabniškega imena itd. Ne bo dovoljeno posodabljati. Čeprav je to negativno testiranje, je to ena glavnih točk preverjanja ki jih je treba upoštevati).
- Prekličite tok posodobitve (čeprav je to negativno preskušanje, je to tudi ena glavnih točk preverjanja, ki jo je treba upoštevati).
Test 4: Če je dovoljena deaktivacija računa, preverite, ali je uporabnik sposoben:
- Deaktivirajte račun.
- Preklic poteka deaktivacije (čeprav je to negativno preskušanje, je to ena glavnih točk preverjanja, ki jo je treba upoštevati).
- Dostop do računa po preklicu deaktiviranja.
Test 5: Če so za e-poštni naslov ali telefonske številke potrebna preverjanja, preverite, ali je uporabnik sposoben:
orodja za testiranje avtomatizacije spletnih aplikacij
- Posodobite e-poštni naslov na drugega veljavnega.
- Preveri ”posodobljen e-poštni naslov.
- Preverite, ali je posodobljen in »preverjen« e-poštni naslov obravnavan še naprej - Pošljite nekaj e-poštnih sporočil iz aplikacije in preverite, ali je prispel na posodobljeni e-poštni naslov. Stari ne bi smel prejemati e-poštnih sporočil.
- Dodajte novo telefonsko številko.
- S klicem preverite dodano telefonsko številko.
- Preverite dodano telefonsko številko s sporočilom SMS.
- Preverite, ali se dodana in »preverjena« telefonska številka odraža v računu.
- Posodobite telefonsko številko.
- Preverite posodobljeno telefonsko številko s klicem.
- Preveri ”posodobljeno telefonsko številko prek SMS-a.
- Preverite, ali se v računu odraža posodobljena in »preverjena« telefonska številka.
Primer 2: Nakup izdelka
Nakup izdelka ima običajno splošen tok.
Nekaj splošnih scenarijev, na katere gledajo končni uporabniki, je navedenih tukaj:
Predpogoj: Uporabnik mora biti prijavljen v aplikacijo.
Test 1: Podrobnosti o izdelku, preverite, ali lahko uporabnik:
- Oglejte si stran s podrobnostmi o izdelku.
- Oglejte si vse pododdelke na strani s podrobnostmi o izdelku (Opis, funkcija, informacije o blagovni znamki itd.).
- Na strani s podrobnostmi o izdelku izberite Količina izdelka, Barva, Velikost itd.
- Pomaknite se do strani kategorije, podkategorije na strani Podrobnosti o izdelku (če je na voljo na strani Podrobnosti o izdelku).
- Pojdite na stran s podrobnostmi o drugem izdelku (če je na voljo ustrezen razdelek o izdelkih).
- Oglejte si komentarje in ocene izdelka.
- Razvrsti komentarje izdelka na podlagi ocen.
- Oglejte si splošno oceno izdelka.
- Dodajte komentar o izdelku.
- Posodobite njegov komentar na izdelek.
- Izbrišite njegov komentar o izdelku (če je na voljo).
Test 2: Dodajte v košarico, preverite, ali je uporabnik:
- Izdelek lahko dodate v košarico:
- Na strani s podrobnostmi o izdelku.
- Na strani s seznamom izdelkov.
- V košarico lahko dodate potrebno količino (1 do največje meje).
- Izdelka ni mogoče dodati v košarico, če ni na zalogi.
Test 3: Na strani z vozičkom preverite, ali je uporabnik sposoben:
- Oglejte si izdelek v košarici s podrobnostmi o ceni za dodano količino.
- Posodobi količino (1 do največje meje).
- Odstranite izdelek iz košarice.
- Vrnite se nazaj do nakupovanja.
- Nadaljujte do blagajne.
- Ogled prazne košarice, ko ni dodan noben izdelek,
Test 4: Na strani s podatki o računu preverite, ali je uporabnik sposoben:
- Nadaljujte z obstoječimi podrobnostmi o pošiljanju.
- Posodobite naslov za dostavo.
- Dodajte nov naslov za dostavo.
- Nadaljujte z obstoječo telefonsko številko.
- Posodobite telefonsko številko za naročilo.
- Dodajte novo telefonsko številko za naročilo.
- Pojdite nazaj na stran košarice.
- Pojdite na stran Plačilo.
Test 5: Na strani za plačila preverite, ali je uporabnik sposoben:
- Preverite pravilnost zneska za obračun.
- Naročilo obdelajte z vsemi razpoložljivimi možnostmi (ena možnost za vsako ločeno naročilo).
- Uspešno obdelajte transakcijo. Pojdite na stran za potrditev naročila.
- Neuspeh transakcije (čeprav je to negativno testiranje, bi ga bilo treba obravnavati kot glavni scenarij).
- Uporabite kupone:
- Veljavni kuponi - uspeh. Tu preverite spremembo zneska za obračun.
- Neveljavni kuponi - neuspeh
- Kuponi so potekli - Neuspeh.
- Pojdite nazaj na stran s podatki o računu.
Pregled sprejemnih testov
Pregled sprejemnih testov je pomembna naloga, saj mora biti pravilen in natančen glede na poslovne zahteve. Ker jih lahko izvajajo stranke in / ali končni uporabniki, je nujno, da so popolni, nedvoumni, pravilni in dovolj podrobni, da jih lahko kdo razume in izvede.
Pregled sprejemnih preskusov morajo opraviti poslovni analitiki, kupci, morebitne komentarje o pregledih pa je treba vključiti v visoko prioriteto.
Na ravni posameznega preizkusa je treba opraviti pregled glede na naslednje:
- Ali test zajema poslovne zahteve ali ne.
- Ali so predpogoji jasni?
- Ali so testni koraki lahko razumljivi in podrobni?
- Ali je pričakovani rezultat pravilen in jasen?
- Ali je preslikana na poslovne zahteve glede sledljivosti?
- Je test dovolj popoln, da pokrije določen pretok ali uporabo?
- Ali je določen preskus obvezen kot del sprejemnega preskusa.
- Ali obstaja kakšna točka preverjanja, ki ni potrebna za sprejemni preizkus?
- Ali je povsem funkcionalen ali je v njem zajet kateri koli GUI (bi moral biti samo funkcionalen).
- Ali so potrebni posebni vhodni podatki? Če je odgovor da, ali je naveden za podrobnosti?
Celoten pregled sklopa sprejemnih testov mora zajemati:
- Dvosmerna sledljivost: Poslovne zahteve za teste IN preskusi za poslovne zahteve.
- Ali so zajete vse poslovne zahteve?
- Ali vse poslovne zahteve zajema en ali več testov?
- Ali so poslovna pravila zajeta?
- Ali je obravnavan poseben primer?
- Koliko testov je napisanih za vsako zahtevo ali pravilo?
- Ali je mogoče teste združiti in razvrstiti glede na pretoke.
- Ali so testi pravilno zaporedni, da je izvedba učinkovita?
Zaključek
Na kratko, kot smo že omenili, imajo dokumenti zelo drastično vlogo pri preverjanju sprejemljivosti.
Zato bi moral biti vsak pisni preizkus sprejema dobro strukturiran in v toku z njegovo uporabo, tako da bi preizkuševalce sprejemljivosti zanimalo, kaj preizkušajo in kako to počnejo. To pa bi samodejno prineslo uspeh.
=> Obiščite tukaj za celotno serijo vadnic o načrtu preizkusov
Prejšnja vadnica | NASLEDNJA Vadnica
Ostanite z nami in si oglejte prihajajočo vadnico o preskusu sprejemljivosti, če želite izvedeti več o poročilih o preizkusu sprejemljivosti, skupaj z nekaterimi splošnimi predlogami. Sporočite nam tudi, če imate kakršna koli vprašanja.
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Pozitivno testiranje: pomen in zasluge, razloženi z resničnimi testnimi scenariji
- Prenos eBook knjige za preizkušanje
- Izšel TimeShiftX za poenostavitev preskusa časovnega zamika
- Kaj je sprejemno testiranje (popoln vodnik)
- Vzorčna predloga za poročilo o preizkusu sprejemljivosti s primeri
- Ste strokovnjak za ročno ali avtomatizirano testiranje? Delo s krajšim delovnim časom za nas!
- Testiranje obremenitve z vadnicami HP LoadRunner