how test an application without requirements
Tehnično ni zahtev brez zahtev. Predstavljajte si programsko opremo, ki ne naredi ničesar specifičnega, temveč se preprosto razteza koda za vrstico kode. To bo stopnišče, ki ne vodi nikamor.
Vsa programska oprema ima zahteve in je usmerjena na določeno nalogo; natančneje, to je rešitev problema. Torej brez zahtev programska oprema ni mogoča.
Vendar je programska oprema brez dokumentiranih zahtev resničnost, s katero se žal večina od nas pogosteje srečuje nam je všeč. Še huje bi lahko bilo, da je dokumentacija nezadostna, netočna ali strašno zastarela. Na žalost se tudi to zgodi.
Iskreno povedano, resnično ne more nadomestiti dobro dokumentiranega dokumenta o funkcionalnih / sistemskih zahtevah z natančnimi primeri uporabe in lažnimi zasloni. Čeprav moramo priznati, da to postaja redkost v industriji zaradi hitrih razvojnih ciklov in premika paradigme v smeri minimalne ali nikakršne dokumentacije.
Zato je ta članek poskus nekaterih praks, ki smo jih upoštevali, ko smo se znašli v teh situacijah.
Preberite tudi:
program za razbijanje gesel za Windows 7
- Kako preizkusiti specifikacijo zahtev za programsko opremo (SRS)?
- Kako ustvariti matriko sledljivosti zahtev
- Kako pregledati dokument SRS in ustvariti testne scenarije
Najprej si oglejmo nekaj razlogi, zakaj morda ni dokumentacije, za začetek:
- Projekt police se odpira
- Dokumentacija manj format dela- Proces
- Dokumentacija morda obstaja, vendar morda ni podrobna ali popolna
- Neprekinjene izdaje in informacije, povezane s starejšo različico, niso bile arhivirane, kar je povzročilo vrzel v razumevanju, kako obstoječa funkcionalnost reagira z novo
Vse to so ovire, ki jih moramo preizkuševalci pogumno prečkati in uspešno izstopiti. Kako natančno, kajne?
Tu so tri najboljše metode za preizkušanje aplikacije brez zahtev:
1. metoda:
Delajte s čim manj dokumentacije, ki jo dobite v roke. Lahko gre za osnovni preprost zaostanek (pri agilnih projektih), datoteko s pomočjo, e-poštno sporočilo, starejšo različico BRD / FRD ali stare testne primere (te preverite v svojih orodjih ALM in jih boste morda našli) itd.
Raziščite, povprašajte in vedno obstaja dokumentirano preskušanje, tudi če je tanko.
Če se to ne izide, ne popuščajte izkušenj kot uporabnik programske opreme.Na primer, če morate preizkusiti postopek nakazila za bančni račun, nam nihče ne mora povedati, kako to storiti, kajne? Ker kot stranke spletnega bančništva vsi vemo, da za prenos potrebujemo račune s številnimi sredstvi, ki so na voljo.
Strinjali smo se, da ne bodo vse situacije tako enostavne, a spet morda tudi.
2. metoda:
Uporabite starejšo / trenutno različico aplikacije kot referenco za preizkus prihodnje izdaje programskega izdelka. Zdaj priznam, da to zanika pravilo 'Nikoli ne piši testnih primerov, ki uporabljajo aplikacijo kot referenco'. Kadar pa delamo v manj kot popolni situaciji, moramo oblikovati pravila, ki ustrezajo našim potrebam.
Pri tem pomaga ohranjati naslednje vidike v perspektivi:
- Aplikacija lahko vsebuje napake - torej, če vas sistem po registraciji neposredno pripelje na Screen1 (določen hipotetični zaslon zaradi našega primera) - Nikoli ne domnevajte, da je to pravilno vedenje. Tudi če polje zavzema alfanumerične znake in je telefonska številka - vprašanje, ki se prepričajte, da aplikacije ne jemljete kot odobren primer pričakovane funkcionalnosti.
- V zgornjih primerih uporabite svojo presojo in uporabite pomoč aplikacije, da boste začeli hitro, vendar bodite kritični do nje, če dvomite, da deluje.
3. metoda:
Pogovor s člani projektne skupine:
- Ponudite, da se udeležite njihovih sestankov.
- Vprašajte, ali lahko sodelujete v enotah in fazah testiranja integracije.
- V nasprotnem primeru vprašajte, ali lahko skupina za razvijanje deli svoje enote in rezultate preskusov integracije.
- Dogovorite se za čas za prenos znanja ob primernem času.
Zdaj pa uporabimo metode v primeru:
Predpostavimo, da obstaja spletno mesto za nakupovanje, kjer lahko izdelke dodate v nakupovalno košarico. Če bi obstajala dokumentacija, bi nam moral povedati, kako ji dodati elemente, koliko elementov lahko ima v določenem trenutku, kaj se zgodi, ko element, ki ste ga dodali, nenadoma ni na zalogi, kakšno je največje število istih predmetov, ki jih lahko kupite hkrati, itd. Naša situacija je, da trenutno NI NIČ od tega.
Uporabi metodo št. 1:
Poiščite kakršno koli dokumentacijo, ki bi jo lahko. Vprašajte svojo ekipo razvijalcev, ali imajo maketne zaslone / poglejte v orodje ALM ali kaj podobnega. Če kaj najdete, bi bilo to dobro izhodišče. Če pa se pri tej metodi nič ne izkaže, lahko uporabite svoj preskuševalčeva presoja / intuicija.
Vsi vemo, kako delujejo nakupovalni vozički, zato sprejmite svoje predpostavke in poiščite nekaj osnovnih scenarijev, kot so:
- Po brskanju ali iskanju lahko izdelke dodate v nakupovalno košarico
- Ko v nakupovalni voziček dodam predmete, se seznam elementov osveži
- Uporabnik bi moral imeti možnost nadaljevanja nakupovanja tudi po tem, ko je v košarico dodal nekaj izdelkov
- Če dvakrat dodate isti element, se bo število dodanih elementov povečalo
- Elemente je mogoče posodobiti
- Elemente je mogoče odstraniti
- Skupni znesek mora biti enak vsoti vseh dodanih cen
- Davke je treba izračunati na podlagi vnesene poštne številke
- Temu je treba dodati stroške pošiljanja
Lahko nadaljujemo, vendar sem prepričan, da ste dobili sliko.
Uporabi 2. način:
Če je na voljo starejša različica aplikacije, je to lahko v pomoč pri pisanju testnih primerov, saj boste morali napisati natančne korake, kje klikniti, kje vnesti vnos, kaj preveriti itd. Posnetki zaslona / mockups / wire- okvirji - če so na voljo, so lahko tudi odlični nadomestki.
Kot lahko vidite na spodnjem zaslonu, so te stvari očitne - imena polj, gumbi ali drugi prisotni elementi itd. (kliknite sliko za povečavo)
Na tej točki imajo preizkuševalci nekaj vprašanj, kot so:
- Kaj se zgodi, ko v polju znesek dam znak?
- Kdaj dodam preveč elementov?
- Koliko je največje št. elementov, ki jih to lahko sprejme? Itd.
Uporabite 3. način :
Odnesite seznam vprašanj BA, razvijalcu ali celo stranki in poiščite pojasnila. Ko je metoda 3 končana, bi morali biti v veliki meri opremljeni z vsemi informacijami, ki jih potrebujete za pisanje podrobnih testnih primerov in testiranje opravite s toliko zaupanjem, kot bi bilo, ko bi bila na voljo izdelana dokumentacija.
Strinjamo se, da gre za veliko več korakov in veliko več nadaljnjih ukrepov, toda za zagotovitev preskušanja kakovosti so ti koraki neizogibni.
V zaključku, vse ni izgubljeno, če dokumentacija ne obstaja ali je nezadostna. Še vedno obstaja upanje! Prosimo, delite svoje izkušnje v podobnih situacijah.
O avtorju: To koristno objavo je napisal član ekipe STH Swati S.
Kot vedno so vaši komentarji, vprašanja in predlogi zelo dobrodošli.
Priporočeno branje
- Vadnica za destruktivno testiranje in nedestruktivno testiranje
- Kako preizkusiti specifikacijo zahtev za programsko opremo (SRS)?
- Kaj je testiranje opic pri testiranju programske opreme?
- Testiranje aplikacij - v osnove testiranja programske opreme!
- Kaj je testiranje združljivosti programske opreme?
- Najboljša orodja za testiranje programske opreme 2021 [QA Test Automation Tools]
- Mapiranje misli pri testiranju programske opreme - načini, kako narediti testiranje bolj zabavno!
- 20 najboljših praktičnih nasvetov za preskušanje programske opreme, ki jih morate prebrati, preden preizkusite katero koli aplikacijo