Uvod v delo s preizkuševalci programske opreme
Kaj je prva stvar, ki vam pade na pamet, ko razmišljate o opravilu za testiranje programske opreme? Delo brez kodiranja? Ali poklic, ki je zelo enostaven, saj vam ponuja možnosti, da najdete napake pri delu drugih (iskanje napak, ko je v drugih najlažja naloga za vse nas)? Ali menite, da je to poklic, ki se ukvarja s preverjanjem pravilnosti izdelka? Vse te misli so pravilne in so vsakodnevne dejavnosti za delo testerjev programske opreme. Vendar pa testiranje programske opreme ni omejeno na te dejavnosti.
Razumevanje aplikacije
Aplikacija je lahko iz katerega koli področja - zdravstveno varstvo, zavarovanje, finance itd. Učenje domene aplikacij je zelo pomembno za vsako programsko delo, da med testiranjem aplikacije odpre vrata razmišljanju z različnih zornih kotov in različnih vidikov uporabnikov. Odkrivanje in potrditev očitnih in ne tako očitnih poti uporabe je vedno prvo pričakovanje od tega. Če poglobljeno znanje o aplikaciji pomaga hkrati, lahko izdelek učinkovito ovrednoti, hkrati pa lahko preizkuševalec postane prednost projektu, kjer velja za enega od glavnih virov znanja v zvezi z vedenjem izdelka.
Medtem ko je učenje domen in funkcionalnosti stalen proces, je za vsak drug pomemben dejavnik znanje o postopku testiranja.
Postopek testiranja
Postopek testiranja se lahko razlikuje od podjetja do podjetja ali celo od enega do drugega projekta. Danes imamo različne modele za razvoj programske opreme, kot so V model, Prototyping model ali popolnoma drugačno metodologijo, kot je Agile pristop k razvoju programske opreme. S spremembo razvojnega modela se spreminja tudi pristop testiranja, ki ga je treba upoštevati. Delo v modelu V bo imelo dobro opredeljene procese, medtem ko se pričakuje, da se bo to delo v agilni metodologiji preizkušalo v vedno spreminjajočih se pogojih.
Naloga še ni gladka s sprejemljivim domenskim znanjem in razumevanjem procesa testiranja, naslednji izziv, ki ga prinaša življenje, je učenje različnih orodij.
Orodja
Orodja vključujejo orodja za upravljanje preizkusov, orodja za beleženje napak, orodja za upravljanje podatkovnih baz in tako naprej.
Z različno programsko opremo za beleženje napak, ki je kakovost in orodja, nekaj odprtokodnega in nekaj licenčnega, je vedno prednost imeti znanje o več orodjih. Pomaga mu pri lažjem prehodu projektov ali skupin po različnih orodjih. Z ustreznim poznavanjem področja, postopkov in orodij je življenje v programu Tester programske opreme več, zaradi česar so njegovi delavniki zahtevni in navdušujoči. Sodelovanje znotraj skupin je eden pomembnih dejavnikov za uspeh katerega koli projekta, za učinkovito sodelovanje pa ima komunikacija zelo pomembno vlogo.
Priporočeni tečaji
- Izpolnite celostni tečaj J2EE
- Spletno usposabljanje za programiranje R
- Pojdi na tečaj programiranja
- Trening za spletno certificiranje v programu Haskell
Komuniciranje
Komunikacija ima zelo pomembno vlogo pri njeni kvaliteti, saj od začetnih faz razvoja programske opreme člani skupine za testiranje (kot najboljša praksa) sodelujejo pri razpravi o zahtevah, sprašujejo poslovne analitike v primeru kakršnih koli poizvedb ali vrzeli v zahtevi. Izobraženec z učinkovitimi komunikacijskimi znanji lahko učinkovito komunicira o tveganjih, lahko učinkovito komunicira z razvojno skupino in lahko učinkovito komunicira o rezultatih testov in poročilih o testiranju.
Načrtovanje programov za preizkušanje programske opreme
Kot že ime pove, je načrtovanje preizkusov tista faza, v kateri se izvaja priprava na testiranje. Priprava na tester bo vključevala različne vrste dejavnosti, ki jih izvaja za učinkovito uporabo. To bo pomagalo pri preverjanju veljavnosti aplikacije in učinkovitem odkrivanju napak v aplikaciji. Za začetek načrtovanja se preizkusi skozi zahteve za razumevanje pričakovanj.
1. Zahteve
Zahteve bi lahko postavile preizkusne skupine v obliki žičnih okvirov, knjižnih plošč, listov excel. Namen vseh teh dokumentov je predstaviti zahteve stranke na učinkovit in razumljiv način. Dokument z žičnim okvirom ni nič drugega kot dokument, ki je lahko v obliki PowerPoint predstavitve, ki prikazuje zahteve stranke. V istih vrsticah zgodbice običajno prikazujejo zahtevani videz / zaslon. Danes so na trgu na voljo različna orodja, ki jih je mogoče uporabiti za pripravo potrebnih dokumentov. Za izdelavo potrebnih dokumentov je glavna odgovornost poslovnega analitika. Tast naj bi temeljito razumel zahteve. Da bi teste in razvijalci pravilno razumeli zahteve, poslovni analitiki vodijo forum na voljo vsem, da se lahko postavijo in prejmejo vprašanja na katero koli od zahtev. Platforma za razpravo in posredovanje odprtih vprašanj in poizvedb se razlikuje od projekta do projekta. To bi lahko bila veriga e-poštnih sporočil ali konferenčni klic ali celo shramba skupnega pogona, ki se vzdržuje, da bi spremljali vsa odprta vprašanja in njihove odgovore, kot jih je zagotovil poslovni analitik.
Jasna komunikacija in zapis komunikacije imata zelo pomembno vlogo kot dokaz. Majhna predpostavka o zahtevi lahko včasih privede do večje pomanjkljivosti izdelka. Na vsaki stopnji je priporočljivo preveriti lastnosti programske opreme za vzdrževanje čiste komunikacije. Programska oprema za preizkušanje programske opreme Delovna komunikacija je lahko s poslovnimi analitiki ali celo znotraj ekipe. Jasna komunikacija pomaga, da pred načrtovanjem in izvajanjem ne pride do predpostavk. Hkrati je priporočljivo imeti zapis o komunikaciji (po možnosti po e-pošti). Pisna komunikacija o poizvedbah z zahtevami pomaga pri poznejših fazah izvajanja preizkusa, kjer funkcionalnost morda ne bi bila razvita, kot je potrjeno v posneti komunikaciji.
2. Scenarij
Ko so zahteve razumljene, preizkuševalec začne dokumentirati scenarije v dokumentu Test Scenario. Scenarij, kot že ime pove, je tok funkcionalnosti, ki mu uporabnik sledi, da opravi nalogo.
Primeri scenarijev -
- Uporabnik bi se moral uspešno prijaviti.
- Uporabnik bi moral imeti možnost rezervirati vstopnice v sistemu.
- Uporabnik bi moral imeti možnost preklicati vozovnice v sistemu.
- Uporabnik mora imeti možnost ogledati / posodobiti podrobnosti profila.
To so logične naloge, ki jih uporabnik izvaja v sistemu. Te logične naloge, če so združene skupaj, pomagajo pri ugotavljanju vseh možnih scenarijev, ki naj bi jih uporabnik opravil. Ti scenariji so običajno dokumentirani v Excelovih listih ali včasih z uporabo nekaterih orodij. Dokazilo je, da iz takšnih dokumentov izvleče vse take scenarije. Dokument, ki vsebuje takšne scenarije, se imenuje Test Scenario Document (ali nekje kot Dokument scenarija na visoki ravni). Ta dokument služi kot vhodni dokument za pripravo testnih primerov.
3. Primer
Ta primer je bolj podrobna različica delovnega scenarija programske opreme Tester, kjer se scenarij razdeli na podrobnejše korake, ki jih bo uporabnik dejansko izvajal med uporabo aplikacije. Preprost primer, ki temelji na zgoraj omenjenih scenarijih, je:
Scenarij - Uporabnik bi se moral uspešno prijaviti.
Testni primeri:
- Preverite, ali lahko uporabnik vnese pravilno uporabniško ime.
- Preverite, ali lahko uporabnik vnese geslo.
- Po kliku gumba za prijavo po vnosu pravilnega uporabniškega imena in gesla preverite, ali se uporabnik lahko uspešno prijavi.
Tak seznam teh primerov lahko vključuje preverjanje veljavnosti vsakega polja, preverjanje negativnih scenarijev in tako naprej.
Spodaj je nekaj dodatnega primera teh primerov -
- Preverite, da uporabniško ime, ko ni vneseno, sistem sproži ustrezno napako.
- Preverite, da geslo, ko ni vneseno, sistem sproži ustrezno napako.
- Preverite, da uporabniško ime in geslo, ko nista vnesena, sistem sproži ustrezno napako.
- Preverite, da sistem pri vnosu napačnega gesla sproži ustrezno sporočilo o napaki.
- Preverite, če sistem vnese napačno uporabniško ime, sistem vrne ustrezno sporočilo o napaki.
4. Matrica sledljivosti zahteve (RTM)
Matrica sledljivosti zahtev, kot že ime pove, pomaga dokazati preverjanje in vključitev pokritosti zahtev, ki jih ponuja Business, v testne dokumente, kot so scenariji in preskusni primeri.
Kot najboljša praksa je to ločen dokument, ki prikazuje preslikavo številke zahteve s številko scenarijev / primerov, ki vključujejo to zahtevo.
Ta dokument morda ne bodo uporabljali vse vrste projektov, vendar, ko ga uporabljate, močno pomaga pri iskanju scenarijev na visoki ravni, ki ustrezajo zahtevam. Navaja pokritost in se lahko uporablja za preverjanje prisotnosti vsaj enega primera glede na vsako zahtevo. Ustvarjanje in vzdrževanje dokumenta RTM velja za najboljšo prakso, vendar niso vse vrste projektov (kot je Agile) uporabo programske opreme dokazali delovni dokument. Kadar se zahteve zelo pogosto spreminjajo, bi bilo mogoče ohraniti ta dokument. Da bi se izognili temu režiji in hkrati imeli način za sledenje zahtevam, nekateri projekti vključujejo del sledljivosti v delovni primer programske opreme Tester ali v sam scenarij.
Pomemben vidik je, kako najti scenarije / primere za sledenje potrebam in obratno. Dobro dokumentirane zahteve za Prover omogočajo lažjo izdelavo in vzdrževanje teh dokumentov. Dvoumne zahteve, nenehno spreminjajoče se zahteve dokazujejo, da je življenjska doba bolj zahtevna in lahko privede do nedoslednih dokumentov, ki bi jih bilo mogoče izročiti, kar ima za posledico manjkajočo potrditev in s tem pomanjkljivost končnega izdelka.
Doslej je potovanje za preizkuševalce načrtovalo in se pripravljalo na testiranje. Ker je priprava na vojno del vojneJ, velja tudi tukaj. Če so ti dokumenti bolj jedrnati, lažji je dokaznik, da potrdi funkcionalnost in odkrije skoraj vse napake. Naslednja faza potovanja preizkuševalca je Izvedba.
Izvajanje preizkuševalnika programske opreme deluje
To je faza začetka uporabe vseh zgoraj omenjenih dokumentov. Za izdelavo scenarija so bile uporabljene zahteve, scenarij pa je bil uporabljen za njegovo izdelavo primerov. Ta dokument dokumenta je tukaj samoplačniški dokument, da začnete preverjati vlogo. Prover začne preverjati aplikacijo z izvajanjem korakov iz tega dokumenta primera. Za potrditev enega samega scenarija bi lahko uporabili več teh primerov ali celo en testni primer lahko ustreza enemu scenariju preizkusa. Vse je odvisno od zapletenosti scenarijev ali včasih standarda, ki ga sledijo v testni skupini. Torej lahko en dokument testnega primera vsebuje 20-50 testnih primerov ali pa 100-120 primerov. Te številke so samo zaradi razlage, od projekta do projekta se lahko zelo razlikujejo. Rezultat te faze je testna napaka. Število veljavnih napak, odkritih v tej fazi, daje dobro predstavo o stabilnosti aplikacije, kakovosti testiranja, kakovosti izdelave in številnih takih dejavnikov, ki neposredno vplivajo na izdelek. Ta faza je najpomembnejša faza, saj preizkuševalec uspeva zajeti vse preskusne primere (preverjanje skoraj vseh potrebnih uporabniških poti) in hkrati povzročiti čim več veljavnih napak. V tej fazi testiranja prihajajo vsa priprava, komunikacijske spretnosti, poizvedbe, ki jih zahteva posel.
Napake programske opreme tester deluje
Med izvajanjem tega primera se vsako ravnanje, ki ni enako pričakovanemu rezultatu, prikaže kot Popolno. Vsak testni primer vsebuje Opis, Pričakovani rezultat in stolpec dejanskega rezultata. Medtem ko ta dokument za načrtovanje programske opreme za preizkušanje programske opreme vsebuje opis in pričakovane rezultate ter stolpec Prazen dejanskih rezultatov. Med izvajanjem testnih primerov naj bi preizkuševalec napolnil dejanski stolpec z rezultati. Hkrati, če dejanska vrednost ni enaka pričakovanemu rezultatu, se napaka beleži. Branje pomanjkljivosti preprosto ne pomeni, da je o težavi obveščen razvijalca. To je spet formalni postopek, ki se običajno opravi s pomočjo orodja. Trenutno na trgu obstajajo različna orodja, nekatera odprtokodna in nekatera licenčna. Vsako orodje za beleženje napak ima naslednja polja -
- Ime projekta / izdaje
- Povzetek pomanjkljivosti
- Opis pomanjkljivosti podrobnosti
- Porazna resnost
- Prednost pomanjkljivosti
- V fazi je bila ugotovljena napaka
- Dodeljena
- Priloge
Kot lahko vidimo, je namen vseh teh polj najti formalne podrobne podrobnosti o težavi. To pomaga razvijalcem, da prikažejo napako v svojem okolju in jo odpravijo. Spodaj je kratek opis vseh teh polj -
- Ime projekta / izdaje - ime izdaje, kjer je bila napaka odkrita, običajno ima projekt več različic in isti projekt lahko ima več podprojektov. To polje pomaga sprožiti težavo za določeno izdajo.
- Povzetek napake - kratek opis odkrite pomanjkljivosti v eni liniji.
- Opis pomanjkljivosti - to je podroben opis napake, vključevati bi moral podrobnosti, kot je okolje, v katerem je bila napaka odkrita, in uporabljeni testni podatki, dejanski rezultati pričakovani rezultat in vse dodatne informacije, ki zainteresiranim stranem dodajo dragocenejše informacije, da razumejo napaka.
- Resnost pomanjkljivosti - pomeni, kako huda je napaka. Običajno ima vrednosti, podobne kritičnim, visokim, srednjim, nizkim ali številčnim vrednostim, kot so 4, 3, 2, 1.
- Prednost pomanjkljivosti - pomeni, kako nujno je odpraviti napako.
- Fazna napaka je bila odkrita - Ker obstaja veliko faz, ko je mogoče zabeležiti napako, faza preskušanja enote, SIT (testiranje sistemske integracije), UAT (sprejemno testiranje uporabnika) ali celo proizvodna faza.
- Dodeljeno - Ime razvijalca ali razvojnega voditelja.
- Priloge - to je dalo preizkuševalcu možnost, da priloži posnetek zaslona, kjer je prišlo do težave.
Izvedba preizkusa in beleženje napak je faza, s katero se lahko preizkuševalec spoprijema. Nekateri od njih učinkovito komunicirajo z razvijalci. Ali lahko trdimo, da beleženje napake z vsemi potrebnimi informacijami, ki ne zadostujejo, da bi razvijalci razumeli napako?
V nekaterih primerih je potrebna dodatna razlaga / razprava z razvijalci. Obstajajo primeri, ko preizkuševalec naleti na nepričakovano vedenje, za katerega morda ni prepričan, če gre za napako. S temi okoliščinami se običajno soočajo novi, ki so v ekipi novi, ki imajo omejeno znanje o domeni ali imajo dvoumnost glede zahtev. No, testerju tu ne gre očitati, če so strogi roki in se vedno spreminjajo zahteve in v večini primerov dokazujejo domeno, medtem ko dejansko načrtujejo in izvajajo testne primere. Kot lahko vidimo, da pot testerja ni tako lahka, kot jo zaznamo. Zahteva vedno odnos do učenja, dobre komunikacijske spretnosti, dobre sodelovalne spretnosti in pripravljenost, da se prilagodite tako, da se spremenijo področja, orodja in postopki, ki se uporabljajo. Medtem ko smo govorili o potovanju ročnih preizkuševalcev, celotni postopek velja tudi za avtomatične testerje. Avtomatizacija ima na drugi strani pomembne spremembe v procesu, saj se obseg testiranja in načrtovanja izvajanja močno razlikuje.
Glede na to, kakšen je test, kot smo ga obravnavali zgoraj, ali lahko še vedno rečemo, da je delo lastnosti preizkuševalnikov programske opreme lažje kot pri razvijalcu?
Lahko rečemo, da bo bolj kot primerjava vlog razvijalca tester v / s koristnejša razprava o tem, kako sodelovanje dveh lahko pripelje do velikega uspeha izdelka kot celote. Včasih pozabimo, da je naloga preizkuševalca najti težave v aplikaciji in ne navajati napak razvijalcev. Ko pozabimo na samo idejo o svojem poslu, to včasih vodi v nepotrebno razpravo. Vendar je opaziti, da obstajajo enako dobre testne, razvojne ekipe, pri katerih vsi razumejo, da je končni namen, da aplikacija deluje tako, kot se pričakuje. Upajmo, da bodo vsi gledali na pozitivno plat preskušanja kot na vlogo, ki pomaga pri čiščenju izdelka in ne kot na tisto, ki šele najde napake!
Priporočeni članki
To je vodilo za odkrivanje in potrditev očitnih in ne tako očitnih poti uporabe, ki so vedno glavna pričakovanja od dela testerjev programske opreme. To je naslednja zunanja povezava, povezana z delom testerja programske opreme.
- Pokvarjen življenjski cikel pri testiranju programske opreme
- 6 najbolj neverjetnih vprašanj glede intervjuja s programsko opremo
- Poklic pri testiranju programske opreme