practical software testing qa process flow
Popoln pregled poteka postopka preskušanja programske opreme za zagotavljanje kakovosti:
Opomba - Ponovno objavljamo to uporabno objavo s posodobljeno vsebino.
Naloga strokovnjaka za preizkušanje programske opreme ni lahka. Napolnjena je z izzivi, kar je prav tako enako zahtevno. Preizkuševalci naj bi bili pozorni in navdušeni v vsaki fazi življenjskega cikla aplikacije.
Čeprav obstajajo izzivi, obstaja tudi ogromno priložnosti za podrobno učenje in raziskovanje različnih vidikov preskušanja metodologij, procesov in seveda programske opreme.
Vloga testnega inženirja se začne že zelo zgodaj. Že od konceptualizacije projekta se preizkuševalci vključijo v razgovore z lastnikom izdelka, vodjo projekta in različnimi deležniki.
Ta vadnica o 'Procesu testiranja programske opreme' vam ponuja popoln pregled različnih faz v STLC, skupaj z izzivi in najboljšimi praksami za lažje razumevanje teh izzivov.
Kaj se boste naučili:
- Zahteva za izdajo - popoln pregled
- Postopek preverjanja kakovosti na resničnem projektu - metoda slapa
- Koraki v zahtevah za sprostitev
- Zaključek
- Priporočeno branje
Zahteva za izdajo - popoln pregled
Že od zahteve do sprostitve je vsaka faza jasno razložena. Oglejmo si jih podrobno.
# 1) Zahteva
Projekt ne more začeti brez jasne zahteve. To je najpomembnejša faza, ko je treba ideje zapisati v dobro razumljiv in oblikovan dokument. Če ste del projekta, v katerem sodelujete v fazi zbiranja zahtev, se imejte srečni.
kopirajte DVD na trdi disk brezplačno -
Se sprašujete, zakaj? To je zato, ker ste priča projektu, ki izdeluje iz nič. Čeprav smo ponosni na to, da smo že od samega začetka, to vključuje tudi nekatere odgovornosti in izzive.
Izzivi
Ne moremo si predstavljati vseh zahtev, da bi se zbrali v enem samem zasedanju. Bodite dovolj potrpežljivi.
Zgodilo se bo veliko razprav, od katerih so nekatere morda preprosto nepomembne za vaš projekt, vendar lahko tudi takrat vsebujejo nekatere ključne informacije za vaš projekt. Včasih lahko hitrost pogovorov preseže vaše zmožnosti dojemanja ali pa preprosto ne bi bili pozorni na lastnika izdelka.
Spodnja slika prikazuje ključne korake pri zbiranju zahtev:
Vsak zgrešen podatek močno vpliva na splošno razumevanje in preizkušanje projekta. Da bi to odpravili, je tu nekaj najboljših praks, ki jih je treba upoštevati v tej fazi.
Najboljše prakse
- Bodite odprti in bodite pozorni na vsako besedo lastnika izdelka.
- Ne samo poslušajte, počistite svoj dvom, pa naj bo še tako majhen.
- Vedno uporabljajte zvezke za hitro vodenje zapiskov. Uporabljajte prenosnik, le če lahko resnično tipkate s primerno hitrostjo.
- Ponovite stavke in jih razjasnite pri naročilu, za katerega menite, da ste ga razumeli.
- Narišite blokovne diagrame, besedilo povezav itd., Da bodo zahteve kasneje jasnejše.
- Če so ekipe na različnih lokacijah, poskusite narediti posnetek WebEx ali podobno. Vedno vam bo pomagalo, če boste po koncu razprav dvomili.
Čeprav za vsako fazo ni ločene stene kot take, se zahteve spreminjajo tudi zelo pozno v razvoju. Torej, ideja je, da zajamemo večino zahteve in to pravilno dokumentiramo.
Ko je dokumentiran z vsemi potrebnimi točkami, porazdelite in razpravljajte o vseh zainteresiranih straneh, tako da bodo morebitni predlogi ali spremembe ujeti zgodaj in preden bodo nadaljevali, bodo vsi na isti strani.
# 2) Testna strategija
Preizkuševalci naj bi prišli s preskusno strategijo, ki ne zadostuje le za boljše preizkušanje programske opreme, temveč bi morala vsem deležnikom vliti zaupanje v kakovost izdelka.
Izzivi
Najpomembnejši vidik te faze je oblikovanje strategije, ki bi ob delu morala zagotoviti programski izdelek, ki je brez napak, vzdržen in ga končni uporabniki sprejmejo.
Testne strategije so nekaj, česar ne boste spreminjali vsak drugi dan. V nekaterih primerih se morate o svojih testnih strategijah pogovoriti tudi s strankami. Torej bi bilo treba ta del obravnavati zelo pomembno.
Najboljše prakse
- Tu je nekaj najboljših praks, ki vam lahko po olajšanju in olajšanju preskusov nudijo olajšanje.
- Še enkrat preglejte dokument z zahtevami. Označite točke uvoza glede na okolje ciljne programske opreme.
- Naredite seznam okolij, v katerih bo programska oprema dejansko nameščena.
- Okolja lahko razumemo kot vrsto operacijskih sistemov ali mobilnih naprav.
- Če je operacijski sistem Windows, navedite vse različice okna, v katerem boste preizkušali svojo programsko opremo. Če različice viz. Windows 7, Windows 10 ali Windows Server (s) še vedno niso opredeljeni v dokumentu z zahtevami, zato je skrajni čas, da o njih razpravljamo.
- Podobno dobite ciljne brskalnike z razpravljanimi in dokumentiranimi različicami, če je AUT spletni sistem.
- Naredite seznam vse programske opreme drugih proizvajalcev, ki jo bo aplikacija potrebovala (če je potrebna / podprta). Ti lahko vključujejo Adobe Acrobat, Microsoft Office, katere koli dodatke itd.
Tu je ideja ohraniti vse potrebne in potrebne platforme, naprave in programsko opremo, ki jih bo morala naša aplikacija delovati pred nami, da bo mogoče oblikovati celovito strategijo.
Spodnja slika vam bo pomagala razumeti oris testne strategije, če delate na agilnem projektu:
# 3) Načrtovanje preskusov
Ko so preizkuševalci oboroženi z vsemi informacijami o AUT, se v fazi načrtovanja izvaja strategija.
Tako kot testna strategija je tudi načrtovanje testov ključna faza.
Izzivi
Ker je uspeh (ali neuspeh) AUT v veliki meri odvisen od tega, kako so bili testi izvedeni, ta faza postane pomemben vidik celotnega življenjskega cikla preskusa. Zakaj? Ker je del testiranja opredeljen v tej fazi.
Za premagovanje nekaterih izzivov so te najboljše prakse res lahko koristne.
Najboljše prakse
- Vedno imejte v mislih, da pri preizkušanju aplikacije ne pustite kamna.
- Čas je, da oblikujemo testno strategijo.
- Ustvarite matriko okolja, tako da bo programska oprema preizkušena na vseh platformah.
- Tako kot Windows 10 + Internet Explorer 11+ Windows Office 2010+.
- Tako kot Android 4.2.2+ in brskalnik Chrome.
- Če vaša aplikacija deluje z več bazami podatkov (če je dokumentirana), shranite baze podatkov (MySQL, Oracle, SQLServer) v matriko preskusov tako, da so preveč integrirane z nekaterimi testi.
- Skladno s tem konfigurirajte preskusne naprave in jih poimenujte kot SetUp1, SetUp2 itd.
- SetUp1 bo imel Windows 7+ IE 10+ Office 2007+.
- SetUp2 ima lahko Windows 10+ IE Edge + Office 2013+.
- V SetUp3 je morda nameščen telefon Android z nameščeno datoteko .apk.
- Čestitamo! Vaša testna nastavitev je pripravljena in vključili ste tudi vse možne kombinacije platform, na katerih bo delovala vaša aplikacija.
# 4) Testiranje
Končno je vaša različica aplikacije končana in pripravljeni ste najti napake! Zdaj je čas, da se lotimo načrtovanja testov in poiščemo čim več napak. Če delate v gibčnem okolju, bo vmes nekaj faz, nato pa preprosto sledite tem scrum metodam.
Spodnji diagram prikazuje kategorizacijo različnih vrst testiranja:
Izzivi
Testiranje je okoren postopek, ki je sam po sebi nagnjen k napakam! Med preizkušanjem aplikacije se najde veliko izzivov. Spodaj je nekaj najboljših praks za reševanje.
Najboljše prakse
Razvedriti! Poskušate najti napake v kodi. Paziti morate na splošno delovanje programske opreme.
- Vedno je priporočljivo, da na aplikacijo pogledate sveže, BREZ PRESKUSNIH PRIMEROV.
- Sledite navigacijski poti vaše programske opreme (AUT).
- Spoznajte AUT.
- Zdaj preberite testne primere (Vsi) katerega koli modula (morda po vaši izbiri).
- Zdaj pojdite na AUT in ugotovitve povežite s tistimi, omenjenimi v pričakovanem odseku testnih primerov.
- Ideja tega je preizkusiti vsako omenjeno funkcijo na vsaki podprti platformi.
- Zapišite si vsako odstopanje, ne glede na to, kako nepomembno je.
- Zapišite si korake, kako doseči kakršno koli odstopanje, naredite posnetke zaslona, zajemite dnevnike napak, dnevnike strežnikov in vso drugo podporno dokumentacijo, ki lahko dokaže obstoj napak.
- Ne oklevajte in vprašajte. Čeprav imate dokument z zahtevami, bodo časi, ko boste v dvomih.
- Preden se obrnete na lastnika izdelka, se v dvomih obrnite na razvijalce (če sedijo poleg vas ali so dosegljivi). Razumevanje pogleda razvijalca na delovanje programske opreme. Razumejte jih. Če menite, da ta izvedba ni v skladu z zahtevo, o tem obvestite vodjo testa.
# 5) Pred izpustom
Preden koli izdelek damo na trg, je treba zagotoviti kakovost izdelka. Programska oprema je razvita enkrat, vendar jo dejansko preizkušate, dokler je ne zamenjate ali odstranite.
Izzivi
Programsko opremo je treba natančno preizkusiti za številne njene parametre.
Parametri ne smejo biti omejeni na:
- Funkcionalnost / vedenjsko.
- Izvedba.
- Razširljivost.
- Združljiv z omenjenimi platformami.
Izziv je tudi napovedati stopnjo uspešnosti aplikacije, ki je odvisna od številnih ponovitev opravljenega testiranja.
Najboljše prakse
- Prepričajte se, da so preizkušene vse funkcije na vseh platformah.
- Poudarite področja, ki niso testirana, ali tista, ki potrebujejo več truda.
- Pred sprostitvijo hranite matrico vseh rezultatov testa. Testna matrika bo dala splošno sliko stabilnosti izdelka. Prav tako bo vodstvu pomagalo, da bo sprejelo klic na datume izdaje.
- Skupini posredujte svoje prispevke / predloge o svojih izkušnjah med preskušanjem izdelka.
- Vaš prispevek, ki se šteje za končnega uporabnika, bo v veliki meri koristil programski opremi.
- Zaradi časovne stiske ali kakršne koli druge take situacije nekaj testiranj zamudimo ali pa se v to ne spustimo globoko. Ne oklevajte in sporočite svojemu upravitelju status testiranja.
- Predložite zdravstveno izkaznico zainteresiranim stranem. Zdravstvene izkaznice bi morale imeti številne zabeležene, odprte, zaprte, občasne napake s svojo resnostjo in prednostjo.
- Pripravite dokument o izdaji in ga delite s skupino.
- Delo na pripravljenem dokumentu o sprostitvi.
- Izboljšajte področja, ki jih predlaga vodstvo / ekipa.
Spodnja slika prikazuje zemljevid življenjskega cikla izdaje programske opreme:
# 6) Sprostite
Končno pride čas, ko moramo izdelek dostaviti predvidenim uporabnikom. Vsi kot ekipa smo trdo delali, da smo izdelek odjavili in programski opremi pomagali svojim uporabnikom.
Izzivi
Inženirji za testiranje programske opreme so v prvi vrsti odgovorni za izdajo katere koli programske opreme. Ta dejavnost zahteva procesno usmerjen potek dela. Tu je nekaj najboljših praks, ki so vključene v tej fazi.
Najboljše prakse
- Vedno si zapomnite, da dokumenta o izdaji ne delate na datum AKTUALNEGA SPROŠČANJA.
- Vedno načrtujte izdajo pred dejanskim datumom izdaje.
- Dokument standardizirajte v skladu s politikami podjetja.
- Vaš dokument o izdaji mora poskušati ugotoviti pozitivna pričakovanja od programske opreme.
- V dokumentu jasno omenite vse zahteve glede programske in strojne opreme, značilne za njihove različice.
- Vključite vse odprte napake in njihovo resnost.
- Ne skrivajte večjih prizadetih površin zaradi odprtih napak. Dajte jim mesto v dokumentu o izdaji.
- Pridobite dokument za pregled in digitalni podpis (lahko se razlikuje glede na politiko podjetja).
- Bodite samozavestni in priložite dokument o izdaji skupaj s programsko opremo.
Postopek preverjanja kakovosti na resničnem projektu - metoda slapa
Od bralca sem dobil zanimivo vprašanje, Kako se testiranje izvaja v podjetju, tj. V praktičnem okolju?
Tisti, ki se preprosto spustijo s fakultete in začnejo iskati zaposlitev, imajo to radovednost - kakšno bi bilo dejansko delovno okolje v podjetju?
Tu sem se osredotočil na dejanski delovni proces Testiranje programske opreme v podjetjih .
Vsakič, ko dobimo nov projekt, je začetni sestanek o seznanitvi s projektom. Na tem sestanku v bistvu razpravljamo o tem, kdo je stranka? koliko traja projekt in kdaj je izvedba? Kdo vse je vključen v projekt, tj. Vodja, tehnološki voditelji, vodje za zagotavljanje kakovosti, razvijalci, preizkuševalci itd.?
Iz SRS (specifikacija programske zahteve) je razvit projektni načrt. Odgovornost preizkuševalcev je, da na podlagi tega SRS in projektnega načrta ustvarijo načrt preskusa programske opreme. Razvijalci začnejo kodirati že od zasnove. Projektno delo je razdeljeno na različne module in ti projektni moduli so razdeljeni med razvijalce.
Medtem je tester odgovoren za izdelavo testnega scenarija in pisanje testnih primerov v skladu z dodeljenimi moduli. Trudimo se zajeti skoraj vse funkcionalne testne primere iz SRS. Podatke je mogoče ročno vzdrževati v nekaterih predlogah za preskus primerov excel ali orodjih za sledenje napakam.
Ko razvijalci končajo posamezne module, se ti moduli dodelijo preizkuševalcem. Na teh modulih se opravi preskus dima in če ta preizkus ne uspe, se moduli dodelijo ustreznim razvijalcem za popravek.
Pri opravljenih modulih se ročno testiranje opravi iz pisnih testnih primerov. Če najdete kakršno koli napako, ki je dodeljena razvijalcu modula in se prijavi v orodje za sledenje napakam . Pri odpravljanju napak tester opravi preverjanje napak in regresijsko testiranje vseh povezanih modulov. Če napaka opravi preverjanje, je označena kot preverjena in označena kot zaprta. V nasprotnem primeru se zgoraj omenjeni cikel napak ponovi. (V drugem prispevku bom opisal življenjski cikel hroščev)
Na posameznih modulih se izvajajo različni testi in integracija modulov. Ti testi vključujejo testiranje združljivosti, tj. Testiranje aplikacij na različni strojni opremi, različicah OS, programskih platformah, različnih brskalnikih itd.
Preskus obremenitve in obremenitve se izvaja tudi v skladu s SRS. Nazadnje se sistemsko testiranje izvede z ustvarjanjem navideznega odjemalskega okolja. Ko se izvedejo vsi testni primeri, se pripravi poročilo o preskusu in se sprejme odločitev o sprostitvi izdelka!
Koraki v zahtevah za sprostitev
Spodaj so podrobnosti o vsakem koraku testiranja, ki se izvaja v vsaki kakovosti programske opreme in življenjskem ciklu testiranja, ki ga določa Standardi IEEE in ISO.
# 1) Pregled SRS : Pregled zahtev za programsko opremo.
# 2) Cilji so nastavljeni za glavne izdaje.
# 3) Ciljni datum načrtovanih za objave.
# 4) Podroben projektni načrt je zgrajena. To vključuje odločitev o projektnih specifikacijah.
# 5) Razvijte testni načrt temelji na tehničnih specifikacijah.
# 6) Načrt preizkusa: To vključuje cilje, metodologijo, sprejeto med preskušanjem, značilnosti, ki jih je treba preizkusiti in ne preizkušati, merila tveganja, časovni razpored testiranja, podporo za več platform in dodelitev virov za testiranje.
# 7) Specifikacije testa: Ta dokument vključuje tehnične podrobnosti (zahteve za programsko opremo), ki so potrebne pred preskušanjem.
# 8) Pisanje testnih primerov
- Dim ( BVT ) testni primeri
- Sanitetni primeri
- Primeri regresijskih testov
- Negativni testni primeri
- Razširjeni testni primeri
# 9) Razvoj: Moduli se razvijajo posebej.
# 10) Vezava namestitvenih programov: Monterji so zgrajeni okoli posameznega izdelka.
Vprašanja in odgovori za php intervju za 5-letne izkušnje
#eleven) Postopek gradnje : Zgradba vključuje namestitvene programe razpoložljivih izdelkov - več platform.
# 12) Testiranje: Smoke Test (BVT): osnovni test aplikacije za odločitev o nadaljnjem testiranju.
- Testiranje novih funkcij
- Med brskalnikom in preskušanje med različnimi platformami
- Testiranje izjemnih situacij in testiranje uhajanja pomnilnika.
# 13) Povzetek poročila o preskusu
- Poročilo o napaki in druga poročila so ustvarjena
# 14) Zamrzovanje kode
- Trenutno ni dodanih nobenih novih funkcij.
# 15) Testiranje: Preskus gradnje in regresije.
# 16) Odločitev o sprostitvi izdelka.
# 17) Scenarij po izdaji za nadaljnje cilje.
To je bil povzetek dejanskega postopka testiranja v okolju podjetja.
Zaključek
Naloga preizkuševalca programske opreme je polna izzivov, a hkrati prijetna. To je za nekoga, ki je enako strasten, motiviran in poln navdušenja. Iskanje napak pri nekom ni vedno lahko delo! To zahteva veliko spretnosti in bikovsko oko za napake.
Poleg vseh lastnosti bi moral biti tester tudi procesno usmerjen. Tako kot vse druge panoge se tudi pri projektih v IT preveč dela fazno, kjer ima vsaka faza nekaj natančno opredeljenih ciljev. In vsak cilj ima natančno opredeljen kriterij sprejemljivosti. Preizkusni inženir mora na svojih ramenih nositi veliko obremenitev kakovosti programske opreme.
Med delom v kateri koli fazi programske opreme naj bi preizkuševalci sledili najboljšim praksam in se morali prilagoditi procesu, ki je vključen v posamezne faze. Upoštevanje najboljših praks in dobro oblikovanega postopka ne pomaga le olajšati dela preizkuševalcev, temveč tudi pri zagotavljanju kakovosti programske opreme.
Ste bili del katere od zgornjih faz? Spodaj lahko delite svoje izkušnje.
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Tečaj preizkušanja programske opreme: kateremu inštitutu za preizkušanje programske opreme naj se pridružim?
- Testiranje programske opreme QA Assistant Job
- Izbira preizkušanja programske opreme kot vaše kariere
- Preizkušanje programske opreme Tehnična vsebina Writer Freelancer Job
- Nekaj zanimivih vprašanj za preskušanje programske opreme
- Povratne informacije in pregledi tečaja za preizkušanje programske opreme
- Kako izboljšati postopek izdaje preizkusov za uspešno izdelavo programske opreme brez napak