Upload
trinhque
View
224
Download
3
Embed Size (px)
Citation preview
VILNIAUS GEDIMINO TECHNIKOS UNIVERSITETAS
FUNDAMENTINIŲ MOKSLŲ FAKULTETAS INFORMACINIŲ TECHNOLOGIJŲ KATEDRA
Romualda Glodenytė
TESTŲ KŪRIMO PROCESO OPTIMIZAVIMAS OPTIMIZATION OF TEST DESIGN PROCESS
Baigiamasis magistro darbas
Informacinių technologijų studijų programa, valstybinis kodas: 62407T104 Duomenų gavybos technologijų specializacija
Informatikos inžinerijos mokslo kryptis
Vilnius, 2010
2
VILNIAUS GEDIMINO TECHNIKOS UNIVERSITETAS
FUNDAMENTINIŲ MOKSLŲ FAKULTETAS INFORMACINIŲ TECHNOLOGIJŲ KATEDRA
TVIRTINU Katedros vedėjas ______________________ (Parašas)
Genadijus Kulvietis (Vardas, pavardė) ______________________ (Data)
Romualda Glodenytė
TESTŲ KŪRIMO PROCESO OPTIMIZAVIMAS OPTIMIZATION OF TEST DESIGN PROCESS
Baigiamasis magistro darbas
Informacinių technologijų studijų programa, valstybinis kodas: 62407T104 Duomenų gavybos technologijų specializacija
Informatikos inžinerijos mokslo kryptis
Vadovas prof.habil.dr. G.Kulvietis ______________ ___________ (Moksl. laipsnis, vardas, pavardė) (Parašas) (Data)
Konsultantas doc. dr. Angelė Kaulakienė _________ _________ (Moksl. laipsnis, vardas, pavardė) (Parašas) (Data)
Konsultantas ______________________ _________ _________ (Moksl. laipsnis, vardas, pavardė) (Parašas) (Data)
Vilnius, 2010
3
Vilniaus Gedimino technikos universitetas Fundamentinių mokslų fakultetas Informacinių technologijų katedra
IBSN ISSN Egz. sk. 2 Data
Informacinių technologijų studijų programos baigiamasis magistro darbas
Pavadinimas: Testų kūrimo proceso optimizavimas
Autorius: Romualda Glodenytė Vadovas: prof.habil.dr. G.Kulvietis
Kalba
×
Anotacija
Baigiamajame magistro darbe nagrinėjamas visas testavimo procesas, jo valdymas,
problemų sprendimas ir tobulinimas. Smulkiau išdėstomas testų kūrimo proceso
optimizavimas. Atrenkami labiausiai atitinkantys įmonės poreikius optimizavimo metodai,
jie aptariami detaliau bei aprašomas jų pritaikymas praktikoje. Pateikiami pavyzdžiai bei
jų analizė ir praktinė vertė.
Darbo tikslas – išnagrinėti testų kūrimo proceso optimizavimo metodus bei juos
pritaikyti praktinėje įmonės veikloje.
Darbą sudaro 8 dalys: įvadas, testavimo procesų analizė, testavimo procesų
planavimas ir valdymas, testavimo proceso problemos ir tobulinimas, testų kūrimo
proceso optimizavimas, išvados, literatūros sąrašas bei priedai.
Darbo apimtis – 50 p. su 2 priedais, 7 paveikslai, 5 lentelės, 19 bibliografinių
šaltinių.
Reikšminiai žodžiai: testavimas, testo kūrimas, procesas, defektas, optimizavimas,
dokumentacija, sprendimų lentelė.
Lietuvių
Anglų
4
Vilnius Gediminas Technical University Faculty of Fundamental Sciences Information Technology Department
IBSN ISSN Number of copies 2 Date
Information Technologies study programme master thesis
Title: Optimization of test design process
Author: Romualda Glodenytė Academic supervisor: prof.habil.dr. G.Kulvietis
Language
×
Annotation
The master thesis deals with all testing process, its management, issue solving and
improvement. Test design optimization is explained in details. Most attractive process
optimization methods are selected for the company. Methods are analyzed in greater
details and adjustment is explained. Examples, its analysis and practical value are
displayed in thesis.
The aim – to analyze optimization methods of test design process and adjust it in
company’s practical work.
Structure: introduction, testing process analysis, testing process planning and
management, testing process problems and improvement, test design process optimization,
conclusions, list of references, appendixes.
Work size – 50 pages with 2 appendixes, 7 pictures, 5 tables, 19 bibliographical
sources.
Keywords: testing, test design, process, defect, optimization, documentation, decision
table
Lithuanian
English
5
Turinys
Įvadas ................................................................................................................................................... 8
1. Testavimo procesų analizė ............................................................................................................. 10
1. 1. Įvadas ..................................................................................................................................... 10
1. 2. Testavimo lygiai..................................................................................................................... 10
1. 3. Testavimo strategijų analizė .................................................................................................. 12
1. 4. Išvados ................................................................................................................................... 21
2. Testavimo procesų planavimas ir valdymas .................................................................................. 22
2. 1. Įvadas ..................................................................................................................................... 22
2. 2. Pagrindiniai testavimo modeliai ............................................................................................ 22
2. 3. Testavimo planavimas, kūrimas bei valdymas ...................................................................... 23
2. 4. Testavimo specifikacija ir pagrindai ...................................................................................... 24
2. 5. Testavimo vykdymas ............................................................................................................. 25
2. 6. Išvados ................................................................................................................................... 26
3. Testavimo proceso problemos ir tobulinimas ................................................................................ 27
3. 1. Įvadas ..................................................................................................................................... 27
3. 2. Testavimo problemos ............................................................................................................. 27
3. 3. Testavimo proceso tobulinimas ............................................................................................. 28
3. 4. Išvados ................................................................................................................................... 29
4. Testų kūrimo proceso optimizavimas ............................................................................................ 30
4. 1. Įvadas ..................................................................................................................................... 30
4. 2. Proceso optimizavimas pasitelkiant Excel programą ............................................................ 30
4. 3. Proceso optimizavimas pasitelkiant šablonus ........................................................................ 34
4. 4. Proceso optimizavimas pasitelkiant sprendimų lentelę ......................................................... 36
4. 5. Išvados ................................................................................................................................... 42
Išvados ............................................................................................................................................... 43
Literatūros sąrašas .............................................................................................................................. 44
Priedai ................................................................................................................................................ 46
6
Paveikslai
1 pav. Taikomosios programos testavimo strategija
2 pav. Kitų programinės įrangos sluoksnių testavimo strategija
3 pav. Kelių kategorijų testavimo strategija
4 pav. Sekų duomenų rinkiniai Excel programoje
5 pav. Lentelių duomenų rinkiniai Excel programoje
6 pav. Dokumentų generavimo duomenų rinkiniai Excel programoje
7 pav. Duomenys Excel programoje
Lentelės
1 lentelė. Taisyklės bei dokumentai
2 lentelė. Atrinkti duomenys bei jų atributai
3 lentelė. Sprendimų lentelė 1 dalis
4 lentelė. Sprendimų lentelė 2 dalis
5 lentelė. Sekų optimizavimas
7
Santrumpų žodynas Santrumpa Paaiškinimas
CRM Ryšių su klientais valdymas (angl. Customer relationship management)
eCRM Elektroninis CRM (angl. electronical CRM)
cCRM Bendradarbiavimo CRM (angl. community CRM)
mCRM Mobilusis CRM (angl. mobile CRM)
proc. Procentai
e. verslas Elektroninis verslas
Excel Elektroninė Microsoft Office programų paketo skaičiuoklė
T Taip (santrumpa lentelėje)
N Ne (santrumpa lentelėje)
Inc. Korporacija, kompanijos tipas, juridinis asmuo (angl. Incorporated)
PRM Santykių su partneriais valdymas (angl. partner relationship
management)
SRM Santykių su tiekėjais valdymas (angl. supplier relationship management)
8
Įvadas
Temos aktualumas
Bet kokios programinės įrangos kūrimas neįsivaizduojamas be testavimo. Šis darbas
neturėtų būti nuvertintas, nes iš tiesų apie penkiasdešimt procentų visos įrangos kainos sudaro
būtent testavimo procesas, o nuo jo kokybiško atlikimo neretai priklauso ir viso projekto sėkmė.
Kuo anksčiau surandami visi defektai, klaidos ir svarstomos problemos, tuo kokybiškesnis visas
testavimas.
Vis daugiau įmonių pripažįsta, kad investavus į testavimą pasiekiama geresnių rezultatų.
Nuolat tobulinant testavimo procesą, sutaupoma tiek įmonės, tiek kliento lėšų. Programinė įranga
nuolat tobulėja, todėl testavimo procesas tampa vis įvairesnis, priklausomai nuo to, kokiai
auditorijai yra skirtas produktas. Iš tiesų, nei viena įmonė nepaleidžia produkto į rinką ar neatiduoda
klientui jo netestavusi. Taigi tik po viso testavimo proceso ciklo gaunamas norimas įvertinimas.
Testavimo svarbą galima būtų perteikti tokiu pavyzdžiu: pirminiuose lygmenyse rastos
klaidos taisymas kainuoja 1 litą, paskutiniuose lygmenyse – 10 litų, o atidavus produktą klientui,
jau net 100 litų. Taigi teisingai suplanavusi testavimo procesą ir laiku radusi klaidą, įmonė gali
uždirbti kur kas daugiau pinigų, o klientas gautų kokybiškesnį produktą.
Tam, kad testavimas vyktų sklandžiai, pirmiausia turi būti parašyti suprantami ir visą
funkcionalumą apimantys testai. Testų rašymas yra ne mažiau svarbi proceso dalis nei pats
testavimas. Todėl norint tobulinti testavimo kokybę, reikėtų pradėti nuo testų rašymo kokybės
užtikrinimo. Kokybė turi neatsiejamą ryšį tarp laiko ir funkcionalumo. Todėl testų kūrimo
optimizavimas gali duoti kur kas daugiau naudos nei manoma.
Darbo tikslas
Darbo tikslas – išnagrinėti testų kūrimo proceso optimizavimo metodus bei juos pritaikyti
praktinėje įmonės veikloje.
Darbo uždaviniai
Keliami uždaviniai:
• išanalizuoti testavimo procesą;
• atrinkti optimizavimo metodus;
9
• pritaikyti metodus praktikoje;
• rasti geriausius optimizavimo principus;
• įvertinti gautus rezultatus bei pateikti išvadas.
Mokslinis naujumas
Praktiškai visos programinės įrangos kūrimo įmonės nebeatsieja viso proceso nuo
testavimo, todėl jos nuolat ieško, kaip testavimą tobulinti. Kuo didesnis testavimo funkcionalumas,
tuo didesnė tikimybė palikti, praleisti dalį netestuotą, kas vėliau gali turėti neigiamų pasekmių tiek
užsakovui, tiek klientui. Kadangi kiekviena įmonė yra individuali ir būtų sunku surasti dvi
vienodais testavimo principais besiremiančias firmas, todėl ir testavimo bei testų kūrimo
optimizavimas yra gana individualus bei įvedantis naujovių šioje srityje.
Praktinė darbo vertė
Testų kūrimo optimizavimas, kaip jau minėta, gana individualus kiekvienoje įmonėje,
todėl metodų pritaikymas realioje darbo aplinkoje gali duoti tik naudos, nes metodų taikymas
įmonės testavimo procese kartojasi tik savo struktūra ar pagrindinėmis funkcijomis, o reikšminė
dalis yra unikali. Išnagrinėti metodai bei panaudotas optimizavimas yra tobulinamas ir toliau
taikomas įmonės „Exigen Service Lietuva“ praktikoje.
Aprobacija
Pranešimas „CRM – Ryšių su klientais valdymas“ buvo pristatytas 12-ojoje Lietuvos
jaunųjų mokslininkų konferencijoje „Mokslas – Lietuvos ateitis“ (Vilnius, Vilniaus Gedimino
technikos universitetas, 2009 m. balandžio 6 d.). Straipsnis yra įtrauktas į konferencijos straipsnių
rinkinį. Straipsnis pateiktas priede.
10
1. Testavimo procesų analizė
1. 1. Įvadas
Testavimo apimtis labai priklauso nuo projekto dydžio bei sudėtingumo, nuo biudžeto,
laiko, komandos narių skaičiaus ir turimų įgūdžių. Taigi natūraliai visam testavimui turėtų būti
pritaikyta tam tikra strategija, o pats ciklas padalintas į lygius, kad būtų lengviau randami defektai ir
bet kokios svarstomos problemos. Padalinus testavimą į lygius, pati programinė įranga įgauna kur
kas daugiau praktinės naudos tolesniam panaudojimui.
1. 2. Testavimo lygiai
Kiekvienas testavimo lygis yra priskiriamas tam tikrai reikalavimų grupei, aplinkai arba
funkcinėms ar techninėms specifikacijoms. Dažniausiai išskiriami 5 testavimo lygiai:
• atskirų elementų testavimas;
• integracinis testavimas;
• sisteminis testavimas;
• pristatymo testavimas;
• regresinis testavimas.
Atskirų elementų testavimas
Atskirų elementų, dar vadinamieji žemo lygio, testai apima atskirų sistemos komponentų
testavimą. Tai mažiausios testuojamos programinės įrangos dalys. Nuo tada, kai pradedama kurti
sistema, atliekami bloko ar atskiro elemento, programos ir modulio testai. Šių koncepcijų
atskyrimas priklauso nuo sandaros ir vartojamos programavimo kalbos. Dažniausiai šie testai yra
atliekami pačių programuotojų.
Atskirų elementų testai yra parašomi po kodo kompiliavimo. Vienas gana ryškus šio
testavimo minusas – testai yra parašomi, kad derėtų su programuotojo pateiktu įgyvendinimu, kas
nėra būtina specifikacija. Kad būtų išvengta šios kliūties, yra naudojamas vadinamasis „draugiškas
testavimas“: suderinti kodo rašymui ir testavimui sudaroma komanda, kur vieni programuotojai rašo
kodą, o kiti jį testuoja. Komandinis darbas bent šiuo atveju visuomet duoda kur kas daugiau naudos
nei naudojant vieno darbuotojo metodą (vieno darbuotojo metodas – kai tas pats žmogus ar žmonių
grupė atlieka visus veiksmus). Toks testavimas tampa kur kas objektyvesnis, daugiau žmonių gali
11
išmėginti skirtingas darbo specifikas, modeliuojami programos specifikacijos reikalavimai bei
sudaroma kur kas mažesnė tikimybė praleisti klaidas. Be to, taip išvengiama neteisingo programos
kodo įgyvendinimo, atsižvelgiant į specifikacijas ir reikalavimus.
Integracinis testavimas
Po elementariausių sistemos dalių, kurios atitinka jų techninius reikalavimus, nustatymo,
didesnės dalys testuojamos integraciniais testais. Tokiais testais tikrinamas duomenų pralaidumas ir
sąsaja tarp programų ir sistemos dalių lygių. Čia moduliai yra koduojami ne to paties žmogaus ar
tos pačios grupės. Paprastai testuojamos sąsajos tarp paskirų elementų. Šie testai atliekami
programuotojų aplinkoje pačių programuotojų arba paskirtų testuotojų. Testai yra parašomi tik kai
detali specifikacija yra užbaigta ir jie tęsiasi per visą projekto eigą. Svarbiausia testų paskirtis –
surasti nesuderinamas atskirų elementų kombinacijas. Šie testai, kaip ir atskirų elementų testai,
priskiriami žemo lygio testavimui.
Sisteminis testavimas
Kai žemo lygio testai jau būna atlikti ir rasti defektai ištaisyti, atliekami sistemos testai,
kad būtų galima nustatyti, ar sistema atitinka funkcines ir technines specifikacijas. Tai jau yra
aukšto lygio testai, kurie apima visų užbaigtų produktų testavimą. Sisteminis testavimas tai visa
apimančių komponentų sąveikos testų vykdymas. Tokiam testavimui dažniausiai yra skiriama
daugiausiai resursų, nes būtent šio testavimo metu randama nesutapčių tarp reikalavimų,
specifikacijų ir kodo įgyvendinimo.
Sisteminio testavimo jau nebeatlieka programuotojai. Tam suburiama testuotojų komanda.
Testavimas gali būti pradėtas tuomet, kai turima dokumentacija yra užbaigta ir pagal ją gali būti
parašyti testai. Tam, kad būtų sudarytos tinkamos sąlygos sisteminiam testavimui, sukuriama
taikomoji programa, imituojanti galutinį produktą.
Pristatymo testavimas
Kai sisteminis testavimas yra baigtas, sistema yra pateikiama klientui, kad šis ją priimtų.
Taigi pristatymo testai dar yra vadinami priėmimo testais. Šie testai atliekami testavimo grupės ir
klientų. Taigi po pristatymo testų atlikimo galima priimti naujus projekto sprendimus, nes klientas
pats gali testuoti taikomąją programą. Svarbu paminėti, kad tokio tipo testavimas atliekamas ir
realioje aplinkoje, todėl paprastai šio testavimo metu randami tik nedideli defektai.
12
Neretai pristatymo testavimo fazė yra pradedama dar nepasibaigus sisteminiam testavimui.
Juk pats testavimo procesas yra identiškas, o ir klientas, matydamas realų produktą, gali pateikti
naujus reikalavimus ar taisyti dokumentaciją, taigi testuotojui tarsi vėl reikėtų grįžti į sisteminio
testavimo fazę.
Regresinis testavimas
Taip jau yra, kad tik keli procentai visų užsakovų žino, ko tiksliai nori, ir po pristatymo
testavimo nieko nekeičia bei baigia projektą. Tačiau dauguma daro pakeitimus, ar po kiek laiko
įdiegia naujas funkcijas, keičia reikalavimus atsižvelgdami į situaciją ar savo klientų pageidavimus.
Taigi įtraukiant naujas eilutes į kodą ar taisant senąsias, neretai gali išsikraipyti pirmiau įdiegtos
funkcijos, todėl įgyvendinus daugiau naujų reikalavimų reikia atlikti regresinį testavimą. Tai senų
testų, kurių nelemia nauji reikalavimai, paleidimas iš naujo, kitaip tariant, viso (ar didesnės dalies)
kodo pertestavimas.
Kaip jau minėta, pradedant nuo sisteminio testavimo, šie testai yra priskiriami aukšto lygio
testams. Visi šie testai turi būti vertinami kaip individualūs procesai. Patirtis rodo, kad aukšto lygio
testų gero projektavimo svarba yra kur kas didesnė nei žemo lygio testų.
1. 3. Testavimo strategijų analizė
Sėkmingas programinės įrangos testavimas prasideda nuo planavimo. Testavimo
planavimas gali būti prilyginamas šachmatų lentai. Ant lentos yra atitinkamas skaičius šachmatų
figūrų, kurios gali padėti laimėti žaidimą. Svarbiausias iššūkis yra sukurti sėkmingą strategiją ir
reikiamu laiku žaisti tomis figūromis, kurios padėtų pasiekti pergalę ir pateisintų pasirinktą
strategiją. Taigi testuojant yra tam tikras skaičius testavimo „figūrų“, kurias galima pasirinkti
žaidime (testavime) skirtingu laiku ir taip „laimėti“ testavimo žaidimą.
Šachmatų figūrų testavimo strategijos
Per paskutinius 25 programinės įrangos testavimo metus išsirutuliojo keturi skirtingi
testavimo metodai (šachmatų figūros):
• statinis testavimas;
• baltosios dėžės testavimas;
• juodosios dėžės testavimas;
• našumo testavimas.
13
Statinis testavimas
Dalis programinės įrangos defektų yra randama dizaino kūrimo ir plėtros metu. Kadangi
programinės įrangos projektavimas prasideda ir baigiasi dokumentacija, testuoti reikia ne kodą, o
pačią dokumentaciją. Pirminė dokumentacija reikalinga nustatyti, kokia programinė įranga bus
kuriama. Vėliau dokumentacija apima mokymą su programine įranga, jos įdiegimą ir veikimą
(pagalbos vartotojui gidus). Programinės įrangos projektavimo etape yra daugybė dokumentacijos,
kurią būtina ištestuoti. Deja, daugelis užsakovų ar kūrėjų dokumentaciją pradeda rašyti jau per
vėlai. Kuo ilgiau yra delsiama, tuo daugiau klaidų įsivelia. Kuo daugiau pastangų įdedama kuriant
tinkamą ir teisingą dokumentaciją, ypač reikalavimus, dizainą ir specifikacijas, tuo didesnė
galimybė parašyti gerą kodą. Kuomet randami dokumento defektai, būtina atsakingai juos ištaisyti,
nes defektas, likęs dokumente, sukeltų daugybę klaidų vėlesniais kūrimo etapais.
Testuotojai yra geriausia grupė, skirta kūrimo dokumentacijai statiškai ištestuoti, dėl
dviejų priežasčių:
• Pirma, testuotojai yra apmokyti tinkamų dokumento testavimo metodų, neretai turi
geresnius testavimo įgūdžius nei pats kūrėjas.
• Antra, testuotojai atstovauja objektyviai tračiajai šaliai, kuri lengviau randa defektus,
nes dokumento autorius nuolat matydamas tą patį tekstą į jį nebesigilina ir taip gali praleisti net ir
aukšto prioriteto klaidas.
Baltosios dėžės testavimas
Turint pirminį ir vykdomąjį kodus, galimas baltosios dėžės testavimas. Jis tinkamas
vidiniams kūrėjams, kurie rašo naują sistemą ar atnaujina egzistuojančios sistemos pasirinktą darinį.
Kita kūrėjų grupė, kuri paprastai turi priėjimą prie pirminio kodo, yra programinės įrangos, skirtos
pardavimui, kūrėjai. Paprastai standartinė programinė įranga atiduodama užsakovui be pirminio
kodo, nes jis yra programinės įrangos pardavėjo prekinė paslaptis.
Turėdami pirminį kodą, kūrėjai ir jų testavimo komandos nariai turi galimybę peržiūrėti ir
testuoti kiekvieną šio kodo eilutę. Tačiau, net jei prieinamas visas pirminis kodas, nepakanka laiko
ir resursų, kad pavyktų ištestuoti 100 proc. kodo. Kūrėjai ir testuotojai, turėdami visas dalis, vis tiek
turi susikurti tokius testavimo planus, kurie sistemingai ištestuotų kuo daugiau pirminio kodo.
Ši kūrėjų ir testuotojų komanda ko gero yra geriausia grupė, kuri suplanuoja ir atlieka
pirminio kodo baltosios dėžės testavimą. Kūrėjas žino programos specifikacijas ir logiką, ką kodas
turi daryti ir žino kaip įrodyti, kad kodas operacijas atlieka teisingai. Tuo tarpu testuotojas žino
14
baltosios dėžės testavimo metodus, kurie padėtų kūrėjui prižiūrėti kodo efektyvumą, patikrinti kodo
veikimą kaip nurodyta bei padėti rasti silpnąsias vietas, kad naudotojas netyčia „nenulaužtų“ kodo.
Juodosios dėžės testavimas
Juodosios dėžės testavimas naudojamas turint tik vykdomąjį kodą. Ši situacija susidaro
keliose kūrimo proceso vietose, neatsižvelgiant į atliktus projektavimo darbus, kai
suprogramuojama vis daugiau programinės įrangos funkcijų, sujungiami į keletą „blokų“ vis didesni
kodo komponentai.
Tokiam testavimui efektyviausią grupę turėtų sudaryti testuotojai, galutiniai naudotojai
(verslo ekspertai). Testuotojas turi pakankamai kompetencijos testų planavimui ir atlikimui,
galutinis naudotojas žino numatomą programinės įrangos tinkamą verslo elgseną, o kūrėjas supranta
verslo elgseną, kuri įgyvendinta programinėje įrangoje ir kuri gali skirtis nuo to, ko naudotojas
tikisi. Kartu su galutiniu naudotoju ir kūrėju testuotojas atlieka juodosios dėžės testavimą
tikrindamas laukiamus ir esamus veiksmus. Kuomet juodosios dėžės testas nepavyksta, tai yra, kai
esami rezultatai neatitinka laukiamų rezultatų, būtina išsiaiškinti, ar tinkamai atliktas testas, norint
kad būtų gauti būtent tokie rezultatai. Šiuo atveju kūrėjas sprendžia nepavykusį testą kaip
specifikacijos ar įgyvendinimo klaidą.
Juodosios dėžės testavimas dar vadinamas „elgsenos“ testavimu dėl laukiamų ar esamų
rezultatų analizės dominavimo šiame metode.
Našumo testavimas
Našumo testavimas atliekamas bent kartą tam, kad būtų įsitikinta, jog programinė įranga
veikia teisingai. Toks testavimo būdas parodo pokytį nuo teisingo rezultato iki reakcijos laiko ir
našumo. Šis pokytis atsiranda kūrimo proceso pabaigoje, nepaisant atlikto projektavimo. Kadangi
nemažai programinės įrangos pardavėjų reklamuoja tokį našumą, kokio pirkėjas gali tikėtis iš
programinės įrangos, esant įvairioms darbo sąlygoms, tai standartinės programinės įrangos
produktai yra neabejotini pretendentai našumo testavimui atlikti.
Užtenka tik patyrusių testuotojų komandos, kuri yra geriausia grupė našumo testų
planavimui ir atlikimui. Testuotojas yra vienintelis kūrėjų komandos narys, kuris turi užtektinai
supratimo ir kompetencijos ir gali teisingai atlikti našumo testus. Našumo testavimas yra gana
sudėtingas ir reikalauja nemažai testavimo įgūdžių, kurių paprastai turi tik specializuotų testuotojų
komanda. Šiam testavimui atlikti turi būti sukurta speciali testavimo aplinka su reikalingomis
našumo testavimo priemonėmis. Našumo testo metu sekamas operacijų atlikimo sparta, jų skaičius
15
bei trukmė. Kai našumo testas nepavyksta (operacijos veikia per lėtai, per mažai operacijų atlikta
per tam tikrą laiką), testuotojas tarpininkui ir kūrėjų komandai turi pateikti rezultatus, kad būtų
nustatyti ir priimti veiksmai, padėsiantys ištaisyti svarstomas problemas.
Kai našumo testų rezultatai parodo, kad programa nebus tokia greita, kaip reikalaujama,
paprastai kūrėjai pirmiausiai investuoja į spartesnę techninę įrangą, didesnę atminties talpyklą,
didina tinklo pralaidumą ar imasi panašių veiksmų. Neretai našumo testavimas dar vadinamas
įkėlimo testavimu, nes geriausias būdas atlikti našumo testavimą yra stengtis įkelti daugiau
operacijų į sistemą, tarsi ji jau būtų paleista masiniam vartojimui.
Dviejų dimensijų testavimo strategijos šachmatų lenta
Apačioje pagal horizontalią ašį (x ašį) išdėstytos plėtros fazių metodologijos fazės. Šios
fazės pradedamos nuo kairės pusės ir paeiliui išrašomos fazės nuo pradžios taško iki galutinio
įdiegimo. Kiekviena kolona atitinka vieną plėtros fazę.
Kairėje pusėje į vertikalią ašį (y ašį) surašomi programinės įrangos lygmenys, reikalingi
tipinėms programinės įrangos taikomosioms programoms teisingai valdyti. Apačioje pateikiama
pagrindinė programinė įranga – operacinė sistema, kuri tiesiogiai sujungta su technine įranga,
žemiausiu lygmeniu. Kylant ašimi į viršų, yra saugumo lygmuo, kuris suteikia galimybę prieiti prie
sluoksnių, kurie bus minimi toliau. Taigi kitas sluoksnis yra duomenų išteklių sluoksnis, kuris
aprūpina aplanką ar duomenų bazės valdymą duomenimis, paremtais pastoviomis ar
besikeičiančiomis visuomenės informavimo priemonėmis. Kitas lygmuo sudaro sujungimo
galimybes, kai pasitelkiamas tinklas tarp užduočių ir duomenų mainų su programinės įrangos
komponentais, kurie laikomi skirtinguose standžiuosiuose diskuose. Šie įvairių kompiuterių
sujungti standieji diskai gali būti laikomi tiek vienoje patalpoje, tiek įvairiuose kambariuose,
pastatuose, miestuose ar net įvairiose šalyse ar žemynuose. Galiausiai viršutinis sluoksnis
vertikalioje ašyje vaizduoja taikomąją programą, kuri yra svarbiausia testavimo plane vykdant
plėtros fazes. Visi kiti iki šio sluoksnio išvardyti lygmenys sustiprina požymius, kad testavimo
planavimas pritaikomas tik taikomajai programai visoms plėtros fazėms, gali būti nepakankamas.
Taigi kol kas programinės įrangos testavimas gali pasirodyti paprastas pasirinkimas tarp
daugybės išbandytų technologijų, kurios testuotojui gali prireikti. Tačiau šių technologijų strategijų
pritaikymas gali būti kur kas sudėtingesnis nei atrodo iš pirmo žvilgsnio. Sėkmingo testavimo
raktas yra įdiegti tinkamą testavimo strategiją taikomajai programai visoms plėtros fazėms ir
kiekvienam paminėtam sluoksniui, iki pasiekiant taikomąją programą, prieš pradedant galutinai
testuoti. Teisinga testavimo strategija apima išmoningas testavimo technologijų kombinacijas.
16
1 pav. Taikomosios programos testavimo strategija (Vertimas iš [5])
Pirmiausiai koncentruojamasi į viršutinę eilutę – taikomąją programą. 1 pav. parodo
optimalias „šachmatų figūrų“ vietas testavimo plane. Parengiamajame tyrime bei analizėje
(kairiausia kolona) yra pavaizduotas tik didinamasis stiklas, kuris identifikuoja statinį testavimo
būdą šioje fazėje. Šiame gyvavimo etape taikomoji programa egzistuoja dar tik dokumentacijoje:
reikalavimuose, specifikacijose, duomenų struktūrose ir t. t. Programinis kodas dar nėra parašytas.
Taigi vienintelis plėtros įrankis gali būti testuojamas remiantis šia dokumentacija. Toks testavimas
šioje plėtros fazėje yra susijęs su šiomis dviem svarstomomis problemomis:
1) identifikuoja nepabaigtą, neteisingą ar konfliktišką informaciją, atsižvelgiant į
kiekvieną šaltinį atskirai ir apskritai į visą dokumentaciją, kuri nurodo visus
taikomosios programos aspektus, kas turi būti plėtojama;
2) patvirtina, kad dokumentacijoje aprašyti objektai gali būti testuojami, kai jie
paverčiami kodu programinėje įrangoje.
Antrosios fazės, parengiamosios konstrukcijos (antroji kolona iš kairės) langelyje yra
pavaizduotas didinamasis stiklas, baltoji dėžė ir juodoji dėžė. Šioje plėtros fazėje yra didelis
17
pasirinkimas ką testuoti: aplinkos nuostatų dokumentaciją, programos kodą. Neskaitant pradinio
kodo, kuris testuojamas statiniu būdu, su baltąja dėže yra testuojamas ir naujausias parašytas kodas
bei, pasitelkiant juodosios dėžės testavimo būdą, testuojama įvesties ir išvesties kodo elgsena.
Galutinės konstrukcijos fazei (trečioji kolona iš kairės) yra pavaizduotas didinamasis
stiklas, juodoji dėžė bei plaktukas. Šioje fazėje turi būti testuojami naujausios vartotojo bei
apmokymų instrukcijos, instaliavimo vedlys, operacinės sistemos vadovas. Baltosios dėžės
testavimas tampa nebereikalingas, nes visi kodo komponentai jau būna „supakuoti“ arba integruoti
jungiant ar kompiliuojant. Taigi visas paketas sudėtingesnių kodo įvesties ir išvesties komponentų
turi būti galutinai ištestuotas pasitelkiant juodosios dėžės testavimo būdą. Paskutinis šios fazės
etapas yra patikrinimas, kad taikomoji programa bus instaliuota teisingai ir veiks korektiškai
atsižvelgiant į visą dokumentaciją.
Plaktukas simbolizuoja dvi skirtingas testavimo atlikimo strategijas: pagrindinę atlikimo
liniją ir apkrovą. Tradiciškai atliekant pagrindinę liniją laiko atsakymas vienai transakcijai ar
veiklos linijai tuščioje sistemoje yra patikrinamas su atlikimo reikalavimais pasitelkiant juodosios
dėžės testavimo pratęsimą. Šis atlikimo strategijos testavimas yra tarsi žadintuvo skambutis visiems
programuotojams, kai žinoma, kad lėta transakcija tuščioje sistemoje nė kiek nepagreitės ar sulėtės
pridėjus daugiau tokių transakcijų. Kai tik tokios strategijos rezultatai matomi ir atitinka
reikalavimus, galima iš to spręsti, kad transakcijos yra suplanuotos ir įvykdytos teisingai.
Pristatymo kolonoje (priešpaskutinė kolona iš dešinės) pavaizduotas kryžiukas, kuris
nurodo, kad paprastai šioje fazėje testavimas būtų nenaudingas, nes taikomoji programa yra
nebepasiekiama programuotojų komandai. Kitais žodžiais galima būtų pasakyti, jei jau programa
yra paruošta įdiegimui, vadinasi testavimas yra pabaigtas sėkmingai.
Galiausiai paskutiniame stulpelyje yra pavaizduoti didinamasis stiklas ir plaktukas.
Statinio testavimo strategija visuomet yra naudinga vos įdiegus programinę įrangą. Ji užtikrina, kad
programa veikia teisingai ir yra suderinta su visais būtinais įrankiais. Taip pat vėl testuojama
dokumentacija ir kitos dalys, kad būtų užtikrintas išbaigtumas ir tikslumas. Pirmosiomis savaitėmis
po įdiegimo, pasitelkiant valdančiąją programą, yra tikrinamas programinės įrangos veikimas su
realiais duomenimis. Bet kokios realaus veikimo nesutaptys su dokumentacija ar testuota taikomąja
programa tampa svarstoma problema, kurią galima išspręsti greitai pašalinant nesklandumus arba
pataisant pačią įrangą ir įdiegiant pakeitimus.
Įdiegus galutinį produktą, visa testavimo strategija keičiasi mažai, palyginti su pradiniu
testavimu. Taikomoji programa yra testuojama atsižvelgiant į dokumentaciją ar raštiškus užsakovo
pakeitimus. Jokie reikalavimai, specifikacijos ar pirminis kodas nėra atiduodamas užsakovui,
nebent jie būna įtraukti į sutartį. Taigi įdiegus programą, testuojamos tos dalys, kurios tampa
18
pasiekiamos. Taigi jei pirminis kodas negali būti matomas, paprasčiausias testavimo variantas yra
pasitelkti juodosios dėžės testavimo strategiją.
Kitos versijos testavimas
Pakeitimai, pataisymai, patikslinimai ir nauji reikalavimai (pageidavimai) yra
neišvengiama programinės įrangos plėtros ciklo dalis. Kiekviena versija turi būti pertestuota tuo
pačiu principu kaip ir sukurta pati pirmoji programinės įrangos versija, pirminis produktas.
Kiekvieni nauji reikalavimai lemia dokumentaciją, todėl kiekvieną kartą būtina ją papildyti ar
pataisyti, kad testuojant nekiltų nesusipratimų. Dažniausiai visi kritiniai ir svarbiausi
funkcionalumai, projekto sprendimai jau būna padaryti ir pakeitimų testavimas įgauna mažesnę
svarbą, negu taisant sugadintą pirminę versiją. Jeigu testavimo planas bei strategija buvo parinkti
teisingai, tai paprastai pirmajai versijai suprojektuotas juodosios dėžės funkcionalumas yra
tinkamas daukartiniam naudojimui. Toks testavimas, kai naudojami tie patys testai keletą kartų
naujesnėms versijoms, vadinamas regresiniu testavimu. Paprastai svarbiausias tokių testų uždavinys
yra patikrinti, kad įdiegus pakeitimus ar atnaujinimus, nėra sugadinamas senasis, pirminis ar tiesiog
prieš tai buvusios versijos funkcionalumas.
2 pav. Kitų programinės įrangos sluoksnių testavimo strategija (Vertimas iš [5])
19
Papildyta „šachmatų lenta“ yra pavaizduota 2 pav. Viršutinė taikomosios programos eilutė
jau yra visiškai baigta. Likusios keturios eilutės nusako programinės įrangos sluoksnių palaikymą
kaip pirmosios eilutės bandomosios strategijos kopijas. Dešinėje kiekvienos eilutės pusėje už
lentelės ribų esantis klaustukas nurodo būtinumą patvirtinti ar modifikuoti bandomosios testavimo
strategijos kopiją su kiekvienu sluoksniu.
Jeigu visi sluoksniai yra sėkmingai pritaikyti taikomajai programai ir daug kartų yra
naudojami be iškylančių svarstomų problemų, tuomet programinės įrangos sluoksnių palaikymas
yra nusakomas kaip patikimas ir tik tikslinis testavimo planas yra reikalingas, kad galima būtų
užtikrinti tą patikimumą. Jei bet kuris sluoksnis programuotojams pasirodo naujas, tuomet būtinas ir
naujas testavimo planas šiam ir po jo einantiems sluoksniams – versijoms [5: 70-75].
Trijų dimensijų testavimo strategijos šachmatų lenta
Internetas subrendo kaip gyvybinga verslo rinka. Vienas iš svarbiausių augimo rodiklių –
sėkmingos sudėtingesnės elektroninio verslo taikomosios programos. Nors iš pirmo žvilgsnio
atrodytų, kad gan sudėtingoms e. verslo programoms ištestuoti kaskart reikėtų naujų testavimo
įgūdžių, tobulesnių, naujoviškesnių strategijų, tačiau geriau įsigilinus, nesunku pastebėti, kad net
apie 95 proc. sudaro testai, kurie jau daug kartų naudoti įprastoms taikomosioms programoms
testuoti. Paprasčiausias būdas pritaikyti tuos 95 proc. testų yra perkelti testavimo strategijas į trijų
dimensijų šachmatų lentą.
20
3 pav. Kelių kategorijų testavimo strategija (Vertimas iš [5])
Trijų dimensijų lenta, palyginti su dviejų dimensijų lenta, turi tik vieną ryškų skirtumą –
prisideda dar viena ašis – kategorijos (z ašis). Dažniausiai naudojamos 3 kategorijos: asmeninis
(darbo) kompiuteris, tinklas bei serveris 3 pav.
Asmeniniai kompiuteriai – tai darbinė aplinka, kuria naudojasi tiek klientai, tiek
darbuotojai, tiek visi kiti vartotojai. Šie kompiuteriai turi lengvai suprantamą sąsają: klaviatūrą,
pelę, ekraną, mikrofoną bei garsiakalbį. Tokiais asmeniniais kompiuteriais galima laikyti ir
delninuką, išmanųjį telefoną ar paprasčiausią mobilųjį telefoną.
Tinklai – tai tarsi kategorija, kuri leidžia lengvai komunikuoti asmeniniams kompiuteriams
su serveriais ar kitais kompiuteriniais įrenginiais. Šiuolaikiniame pasaulyje susisiekti keliems
įrenginiams nebereikia kabelio ar kitokio fizinio jungiklio. Palydovų padedami keli įrenginiai,
esantys skirtinguose žemynuose, gali komunikuoti be jokių laidų. Prireikus galima pasitelkti grupę
palydovų, kurie užtikrintų stabilų ir spartų ryšį.
Serverio kategorija yra svarbiausia iš visų. Taikomųjų programų serveriai užtikrina
kasdienį verslo funkcionalumą, kaip užsakymas, pirkimas, įvykdymas, sąskaitos pateikimas,
apskaita. Duomenų bazių serveriai organizuoja, talpina, atkuria įvairiausius klientų, kitų serverių,
įrangos įrašus. Saugumo serveriai užtikrina, kad su atitinkamais duomenimis galėtų dirbti tik
21
privilegijuoti vartotojai, kad darbuotojai ar klientai nesugadintų įrašų, kreiptųsi tik atsakingi
asmenys. Taip pat yra telefoniniai serveriai, kurie padeda kasdieniame ryšio tinkle, kaip tam tikrų
žinučių pranešimas, skambučio nukreipimas ir daugelis kitų. Negalima nepaminėti serverių, kurie
prižiūri, kad kompanijos pradžios tinklapis būtų visuomet paruoštas vartojimui ir stabiliai veiktų
internete.
Anksčiau buvo galima rasti ir ketvirtąją kategoriją – universalius pagrindinės įrangos
komplektus (angl. mainframe), kurie dabar jau visiškai pakeisti serveriais. Laikui bėgant, pamatyta,
kad kur kas geriau naudotis serveriais nei statiniu įrenginiu.
Taigi šachmatų lenta buvo išplėsta z ašimi ir papildyta šiomis trejomis kategorijomis. Taip
išsiplėtė ir pati testavimo strategija. Iš esmės kiekviena kategorija turėtų praeiti visus testavimo
lygmenis, kaip jau buvo anksčiau aptarta. Todėl nesunku trijų dimensijų lentą padalinti į kelias
dviejų dimensijų šachmatų lentas. Priklausomai nuo programinės įrangos komponentų kiekvienoje
platformoje, galimi atitinkamos testavimo strategijos klausimai, kurie užtikrintų tinkamą testavimą,
užuot kas kartą pritaikius naują testavimo strategiją [5: 75-77].
1. 4. Išvados
Nesunku pastebėti, kad pritaikius strategiją, testavimas įgauna konkretumo, stabilumo bei
visas procesas tampa kur kas lengviau valdomas. Nors skirtingos strategijos turi skirtingus
struktūrinius elementus, praktiškai kiekvienoje galima rasti tuos pačius testavimo lygmenis, kurie
užtikrina produktyvų testavimą bei suteikia įmonei galimybę rinktis strategiją pagal poreikius.
22
2. Testavimo procesų planavimas ir valdymas
2. 1. Įvadas
Norint teisingai įgyvendinti struktūrizuotą ir lengvai valdomą programinę įrangą, visada
verta naudoti programinės įrangos plėtros modelius. Ir nors modelių įvairovė leidžia rinktis pagal
įmantriausius įgeidžius, rinkoje paprastai įsivyrauja keletas patikrintų ir lengviausią susikalbėjimą
su klientais užtikrinančių įrankių.
2. 2. Pagrindiniai testavimo modeliai
Dažniausiai išskiriami tokie gana nepanašūs, tačiau šiuo metu populiariausiai naudojami
modeliai:
• krioklio modelis (angl. Waterfall-model);
• v modelis (angl. V-model);
• spiralės modelis (angl. Spiral model);
• paslankusis modelis (angl. Agile model).
Visi šie modeliai apibūdina sisteminius būdus, kad būtų galima tinkamai ir tvarkingai
organizuoti projekto darbą. Paprastai fazės ir projektavimo etapai yra iš anksto apibrėžti. Etapas
baigiasi, kai reikiami dokumentai yra parengti ir atitinka nurodytus kokybės kriterijus. Naudojant
šiuos modelius, galima planuoti būsimus išteklius. Projekte plėtros modeliai apibūdina bendras ir
privalomąsias užduotis pagal jų chronologinę tvarką. Kiekvieno modelio gyvavimo cikle yra
didesnis ar mažesnis testavimo etapas.
Krioklio modelis – ko gero pats žinomiausias modelis, dar kartais vadinamas tradicinis
testavimo modelis. Kitas lygmuo yra pradedamas tik tuomet, kai vienas plėtojimo lygmuo yra
galutinai pabaigtas. Grafiškai modelį galima įsivaizduoti, kaip ciklo eigą „iš viršaus žemyn“. Taigi
tik tarp gretimų lygmenų yra grįžtamojo ryšio ciklas, kuris leidžia peržiūrėti ir ankstesnį lygmenį.
Tačiau, modelis nėra tobulas. Esminis šio modelio trūkumas – testavimas yra suprantamas kaip
vienkartinis veiksmas, kuris atliekamas projekto pabaigoje prieš atiduodant programinę įrangą
klientui. Taigi naudojant šį modelį, nėra atsižvelgiama į sistemos pakeitimus. Dėl šių problemų
projektavimas "iš viršaus žemyn" netinka siekiant sukurti taikomąją programinę įrangą, kurią
galima būtų pakartotinai panaudoti.
23
Taigi tobulinant krioklio modelį, buvo sukurtas V modelis, kuris tarsi sustiprina krioklio
modelį, nes jame kūrimo darbai yra atskirti nuo testavimo darbų. Šis modelis dažniausiai
naudojamas praktikoje.
Kitoks įgyvendinimo būdas naudojamas spiraliniame modelyje. Jo esmė - keturių iš eilės
programinės įrangos kūrimo fazių (planavimo ir analizės, projektavimo, realizavimo ir sistemos
įvertinimo) kartojimas. Tačiau tiek ankstesni modeliai, tiek šis turi trūkumų. Kadangi toks testavimas
yra tarsi nesibaigiantis (besisukantis ratu), sunku nuspėti darbų sąnaudas, sunkiau valdyti nuolat
besikeičiančius programų modulius, testavimo planus, projektų dokumentus. Apskritai visuomet
yra sunkiau valdyti bei tvarkyti nuolat besikeičiantį produktą.
Tam, kad besikeičiančio projekto valdymas taptų kuo paprastesnis, paskutiniu metu vis
labiau į rinką įtraukiamas paslankusis modelis. Taikant šį modelį, sumažinama rizika, kad sistema
neatitiks pakitusių veiklos poreikių, nebus įdiegta sutartu laiku ar jos kūrimas viršys numatytas
sąnaudas. Taip pat užsakovas gali pradėti naudoti reikalingiausias sistemos funkcijas neužbaigus
visos sistemos kūrimo projekto. Remiantis analize, net 64 proc. sistemų funkcionalumo
nepanaudojama arba naudojama retai. Taigi šis modelis galėtų padėti išvengti šių klaidų.
2. 3. Testavimo planavimas, kūrimas bei valdymas
Testavimo proceso planavimas prasideda nuo programinės įrangos kūrimo projekto
pradžios. Ankstesni planai, kurie yra sukurti projekto metu, turėtų būti reguliariai tikrinami,
atnaujinami ir tikslinami.
Testavimo tikslai turėtų būti apibrėžti ir dėl jų susitarta iš anksto. Turi būti sutarta, kurie
darbuotojai bus reikalingi, kokios užduotys turėtų būti atliktos ir kiek joms reikės skirti laiko, kokia
įranga ir programos turėtų būti naudojamos. Į panašius klausimus būtina atsakyti planavimo metu ir
rezultatai turėtų būti aprašyti testavimo plane. Reikėtų pateikti ir atlikti specializuotus darbuotojų
apmokymus. Prireikus turėtų būti įdiegtos organizacinės struktūros, kurios prižiūrėtų bei atliktų
atitinkamą testavimo valdymo procesą.
Testavimo valdymas yra priemonė, kuri leidžia vykdyti testavimo veiklos organizavimą
bei priežiūrą ir lyginti su planu, registruoti nukrypimus nuo plano ir imtis bet kokių veiksmų, kurie
padeda įvykdyti testavimo misiją ir tikslus naujoje situacijoje. Testavimo planas turėtų būti nuolat
atnaujinamas, atsižvelgiant į valdančiosios programos ir valdymo grįžtamąjį ryši. Pažangos
stebėjimo rezultatas gali būti pagrįstas gautomis darbuotojų ataskaitomis, taip pat duomenimis,
kuriuos automatiškai generuoja programinė įranga.
Pagrindinė planavimo užduotis yra surasti tinkamą testavimo strategiją. Kadangi išsamus
testavimas faktiškai yra neįmanomas, tokiu atveju prioritetai nustatomi pagal rizikos įvertinimą.
24
Testavimo veikla paskirstoma į atskiras posistemes, atsižvelgiant į tikėtinas rizikos ir nesėkmės
sudėtingumo pasekmes. Testavimo strategijos tikslas – optimalus testų paskirstymas tarp reikalingų,
ar kitaip sakant, teisingų programinės įrangos sistemos dalių.
Testavimo intensyvumas ypač priklauso nuo to, kokie testavimo metodai yra naudojami ir
kokios testavimo apimties yra siekiama. Testavimo apimtį bei užsakovo ar kliento reikalavimų
įvykdymą galima laikyti kaip testų baigtumo kriterijų. Tačiau gana svarbu yra atsižvelgti į riziką,
apibrėžiant kriterijus ir testavimo intensyvumą. Taip pat svarbu planavimo metu kiek įmanoma
tiksliau išnagrinėti laiko aspektus, kadangi programinės įrangos projektai neretai yra atliekami
spaudžiant laikui. Prioritetų nustatymas padeda užtikrinti, kad pirmiausia būtų testuojamos kritinės
programos dalys, jei yra nepakankamai laiko suplanuotiems testams atlikti [16: 2.2.1 skyrius].
2. 4. Testavimo specifikacija ir pagrindai
Pirmiausia būtina peržiūrėti testuojamos sistemos specifikacijas bei bazinės testavimo
funkcijas. Specifikacijos gali būti nekonkrečios ar neaiškios testavimo atvejų kūrimo atžvilgiu.
Taigi reikalavimus reikia pataisyti. Testavimo atvejų projektavimui išankstinių sąlygų ir
reikalavimų nustatymas turėtų būti grindžiamas reikalavimų analize, tikėtina elgsena ir testuojamo
objekto struktūra.
Testavimų strategijos, nustatytos testavimo plane, apibrėžia, kurie testavimo metodai
turėtų būti naudojami. Atitinkami testavimų atvejai, sukuriami naudojant šią techniką, taip pat
turėtų būti pasirinkti remiantis tokiais būdais, kad būtų galima testuojamo objekto sudėtingumo
analize.
Testavimo atvejų specifikacija yra atliekama dviem etapais:
• Pradžioje loginiai testavimo atvejai yra apibrėžiami ir tik tada jie gali būti paversti
konkrečiais testais su tikromis reikšmėmis.
• Priešinga seka taip pat įmanoma, jei testuojamas objektas yra neužtektinai
specifikuotas ir testavimo specifikacija atliekama eksperimentiniu būdu (tiriamasis
testavimas). Konkrečių testavimo atvejų kūrimas priklauso jau kitam etapui – testų
įgyvendinimui.
Baziniai testavimo pagrindai užtikrina logiškų testavimo atvejų pasirinkimą kiekvienai
testavimo technikai. Testavimo atvejai gali būti nustatomi pagal testuojamo objekto specifikacijas,
kai taikoma juodosios dėžės projektavimo metodika, arba analizuojant pirminį kodą, kai taikoma
baltosios dėžės projektavimo metodika. Pradinės sąlygos privalo būti aprašytos kiekvienam
testavimo atvejui. Turi būti pakankamai aišku, kokios aplinkos sąlygos yra reikalingos testavimui.
25
Be to, numatomi rezultatai ir elgsena privalo būti apibrėžti. Testuotojas, norėdamas charakterizuoti
planuojamus rezultatus, turėtų gauti informacijos iš tinkamo šaltinio, paprastai vadinamo testavimo
orakulu. Tai toks mechanizmas, kuris skirtas numatyti lauktiems rezultatams. Sudaromos dvi
galimybės:
• Testuotojas naudoja laukiamus duomenis iš duomenų įvesties pagal atliktus
skaičiavimus arba analizę, kuri paremta testuojamo objekto specifikacijomis.
• Jei yra funkcijos, kurios atlieka priešingos veiksmus, jos gali būti paleistos testuoti
po pagrindinio testavimo, kai rezultatai jau yra patvirtinti.
2. 5. Testavimo vykdymas
Testavimo įgyvendinimas ir vykdymas yra testuotojo arba kito paskirto žmogaus atliekami
veiksmai, kai testavimo sąlygos ir logiški testavimo atvejai virsta konkrečiu testavimo atveju, visos
aplinkos detales palaiko testavimo vykdymo veiksnį. Be to, testavimo atvejai paprastai turi
apibūdinti, kaip testavimas bus atliekamas. Taip pat testavimo planavimo metu turėtų būti
atsižvelgiama į testavimo atvejų svarbą, tai reiškia, kad suskirstoma pagal prioritetus. Testavimo
atvejai taip pat neretai yra surūšiuojami į tam tikras grupes veiksmingesniam testavimui ir
lengvesnei rezultatų apžvalgai.
Kai visos pasiruošimo užduotys jau yra atliktos, testavimas paprastai turėtų būti
pradedamas iškart po programavimo ir testavimo posistemių paskirstymo. Testavimas atliekamas
rankiniu ar automatiniu būdu arba naudojant tam tikras paruoštas priemones, funkcionalumus.
Pirmiausia, testuojamos dalys turėtų būti išsamiai patikrintos. Testavimo objektas turi būti
įgyvendinamas testavimo aplinkoje ir patikrintas jo gebėjimas pradėti ir atlikti pagrindinį, jam
paskirtą procesą. Testavimo vykdymas pradedamas nuo pagrindinio testavimo objekto
funkcionalumo analizės ir jei šio proceso metu surandama gedimų arba nukrypimų nuo laukiamo
rezultato, tokiu atveju yra beprasmiška tęsti testavimo procesą ir būtina ištaisyti pasitaikiusias
klaidas. Taigi ištaisius gedimus ir nukrypimus, kai visas testavimo procesas priimamas kaip
tinkamas, toliau testuojami visi papildomi elementai.
Testavimo atlikimas visuomet turėtų būti visiškai ir tiksliai užregistruojamas. Šis
registravimas apima visą testavimo procesą, tai yra kiekvieną testavimo paleidimą ir šio paleidimo
rezultatus. To reikia vėlesnei analizei. Testavimo atlikimas turi būti suprantamas visiems, netgi
žmonėms, kurie netiesiogiai susiję su testavimo projektu, pavyzdžiui, klientams. Taip pat turi būti
įrodyta, kad suplanuota testavimo strategija buvo sėkmingai įvykdyta. Testavimo ataskaitoje
nurodoma, kuris testuotojas ką testavo, kada, kaip intensyviai ir kokie rezultatai buvo gauti.
26
Testavimo informacija laikoma archyve tam, kad vėliau būtų įmanoma lengvai pakartoti veiksmus
su tomis pačiomis duomenų įvestimis ir sąlygomis.
Jeigu testavimo metu atsiranda skirtumų tarp laukiamų ir realių rezultatų, sprendžiamas
klausimas, ar tai iš tiesų yra svarstoma problema. Jei taip, tokiu atveju ši svarstoma problema turėtų
būti registruojama ir atliekama paviršutiniška galimų priežasčių analizė. Tokia analizė atliekama
norint išsiaiškinti, ar klaida įsivėlė dėl blogo kodo, ar galbūt klaidinga arba neteisinga testavimo
specifikacija, problemos su testavimo infrastruktūra arba testavimo atveju, arba neteisingas atliktas
pats testavimas.
Po problemos ištaisymo išnagrinėjama, ar problema buvo tikrai ištaisyta ir ar nebuvo rasta
naujų problemų, tai yra atliekamas pakartotinas testavimas, kitaip vadinamas regresiniu testavimu.
Jeigu reikalaujama, turėtų būti sukurti nauji testavimo atvejai pakeistam arba pradiniam kodui
nagrinėti. Paprastai yra patariama ištaisyti problemas ir testuoti pataisymus atkirai vienas nuo kito,
siekiant išvengti pokyčių sąveikos. Tačiau praktikoje tai ne visada įmanoma dėl lėšų ar laiko
stygiaus, naujo programavimo įrangos įdiegimo testavimo aplinkoje.
Daugelyje projektų neįmanoma įvykdyti visų specifikuotų testavimo atvejų dėl, kaip jau
minėta, laiko stokos. Todėl turi būti nuspręsta, kuriuos testavimo atvejus reikia testuoti pirmiausiai,
tai yra įsitikinti, kad visos kritinės problemos buvo rastos testavimo metu. Tokiems atvejams
priskiriamas aukščiausias prioritetas. Geriausias rezultatas turėtų būti pasiekiamas netgi tokiu
atveju, kai testavimo procesas sustabdomas per anksti. Tai yra testavimas, kuris apibūdinamas kaip
rizika pagrįstas testavimas. Šis metodas taip pat turėtų užtikrinti, kad svarbios svarstomos
problemos būtų randamos laiku ir skubiai ištaisomos. Ribotų išteklių vienodas paskirstymas visuose
projekto objektuose nėra priimtinas, nes kritinės dalys būtų ištestuotos nepakankamai ir ištekliai
būtų eikvojami be rimtos, pagrįstos priežasties.
2. 6. Išvados
Kartais, turint puikius specialistus, gerą įrangą, užtektinai resursų, tačiau sudarius prastą
projekto įgyvendinimo planą, pasiekti laukiamų rezultatų laiku gali būti labai sunku. Teisingai
suplanavus testavimo eigą: kokybiškai parengus dokumentaciją, tinkamai paskirsčius laiką,
darbuotojus bei resursus, galima pasiekti rezultatų, kurie viršytų lūkesčius. Taigi ne viskas priklauso
tik nuo pačios testavimo kokybės. Visos proceso dalys turi būti suderintos tarpusavyje.
27
3. Testavimo proceso problemos ir tobulinimas
3. 1. Įvadas
Ganėtinai dažnai organizacija susiduria su problema, kad neįmanoma surasti visų defektų
ir svarstomų problemų iki produkto atidavimo klientui. Kita vertus, atsiradus naujiems defektams,
plėtojamas bendradarbiavimas, juolab kad užsakovai beveik visuomet pageidauja pakeitimų ar
naujų funkcijų sistemoje. Taip pat nepaneigiamas sistemos tobulinimas, atsižvelgiant į
pasikartojančias klaidas.
Kadangi programinė įranga vis tobulėja, klientai darosi vis reiklesni, todėl lygiagrečiai turi
tobulėti ir testavimo procesas. Vis labiau plečiantis programų funkcionalumui, būtina ieškoti
produktyvesnių ir greitesnių būdų vykdyti testavimo procesui.
3. 2. Testavimo problemos
Viso testavimo laikotarpiu pagrindinės testavimo problemos priklauso nuo testavimo
lygmens. Pradžioje susiduriama su vienokio tipo bėdomis, vėliau su kitomis. Todėl išskirti
svarbiausias problemas iš viso testavimo ciklo neretai yra per sudėtinga ir jos skirstomos būtent
pagal testavimo lygius.
Pirminis testavimas
Primityvusis arba pirminis testavimas reiškia veiksmą, kai testavimas pradedamas dar
prieš sistemą paleidžiant į gamybos etapą. Paprastai testavimas atliekamas tuo metu laisvo
darbuotojo, nes nereikalauja specifinių žinių. Toks testavimas dažniausiai baigiamas, kai sistema
atiduodama gamybai arba kai neberandama naujų defektų. Deja paprastai sistema atiduodama į
gamybą su keletu likusių defektų ir dėl to atsiranda poreikis brangiam ir užsitęsusiam defektų
taisymui ir pakartotiniam testavimui.
Einamasis laikotarpis
Labiausiai organizacijose paplitęs ir pripažinimo susilaukęs toks testavimo procesas, kuris
atliekamas einamuoju laiku. Testai, pagrįsti specifikacijomis ir reikalavimais, yra suplanuojami bei
paruošiami prieš pradedant testuoti. Taip nesunku atsekti, kas jau buvo testuota ir ką dar reikia
28
tikrinti. Tačiau ir čia neįmanoma apsieiti be probleminės srities. Testavimui vis dar trūksta laiko,
žmonių, išteklių ir kompetencijos. Neretai testavimas į kūrimo ciklą yra įtraukiamas per vėlai, todėl
nepavyksta išvengti brangaus perdirbimo ir pakartotinio testavimo ciklo. Kai testavimas baigiamas,
vis dar nėra aišku, koks yra sistemos kokybės lygis.
Nauja plėtra
Kiekviena įmonė, kad sugebėtų konkuruoti dabartinėje rinkoje, naujiems produktams turi
trumpinti pateikimo į rinką laikotarpį. Nors kūrimo procesų atlikimas vis greitėja, tačiau nėra
įrodymų apie mažėjantį padarytų klaidų per tam tikrą laiko tarpą skaičių. Net jeigu testavimo
procesas dabar susiklosčiusioje situacijoje atrodo pagrįstai patenkinamas, akivaizdu, kad ateityje
taip nebus.
3. 3. Testavimo proceso tobulinimas
Visų minėtų problemų priežastis gali atsirasti iš nekontroliuojamo ar netinkamai tvarkomo
viso testavimo ciklo. Pasak T. Koomeno ir M. Polo, testavimo proceso tobulinimo principas gali
būti apibūdintas taip: „testavimo proceso kokybės, išlaidų ir laiko optimizavimas turi būti
palyginamas su bendromis informacijos paslaugomis“ [7].
Čia kokybė reiškia testavimo proceso, susijusio su testuojamo objekto kokybe, supratimo
laipsnį. Reikia pabrėžti, kad programos kokybė nėra šio apibrėžimo dalis. Iš to išplaukia, kad
kokybiškai geresnio testavimo proceso rezultatas nėra geresnė ir visos testuojamos sistemos
kokybė. Pats testavimas sistemai nesuteikia kokybės. Iš tikrųjų jis gali tik nustatyti turimą kokybę ir
naudojantis gauta informacija leisti ją tobulinti kitiems.
Testavimo procesas nepriklauso pats nuo savęs, palyginti su bendromis informacijos
paslaugomis. Pigesnis ir efektyvesnis testavimas negali būti siekiamas kaip tikslas būtent
įgyvendinti testavimą. Jis turi prisidėti savo svariu indėliu prie geresnio bendrų informacijos
paslaugų našumo.
Patobulinto testavimo proceso tikslas – surasti defektus kaip įmanoma arčiau jų šaltinio,
kad vėliau pavyktų sumažinti tų klaidų taisymo išlaidas, ir kaip įmanoma anksčiau pateikti
informaciją apie visos sistemos kokybę. Visi skaičiavimai ir testų lygiai turi būti atidžiai priderinti
vienas prie kito tam, kad galima būtų nesunkiai, kaip įmanoma anksčiau, pasiekti optimizuotą
bendrąją strategiją pagrindiniams defektams surasti ir ištaisyti.
Testavimas turėtų tapti profesionalesne užduotimi, kuri reikalauja specialių testavimo
įgūdžių ir šiam procesui atlikti turėtų būti paskirtas vadovas, metodų specialistas bei testavimo
29
inžinierius. Viso testavimo pažanga ir kokybė turi būti tinkamai įvertinta ir rezultatai turi būti
naudojami kaip informacija tolesniam testavimo proceso tobulinti.
Testavimo proceso tobulinimo etapai
Testavimo proceso tobulinimas galėtų būti palyginamas su bet kokio kito proceso
mėginimu tobulinti. T. Koomenas ir M. Polas išskiria šiuos testavimo proceso tobulinimo etapus:
1) Tikslo ir srities nustatymo svarba. Testavimo kokybės charakteristikos nustatomos
užduodant klausimus:
• Ar tikslas yra padaryti testavimą greitesnį, pigesnį ar didesnės aprėpties?
• Kurie testavimo procesai yra reikalingiausi testavimo proceso tobulinimui?
• Kaip ilgai tobulinimas gali tęstis ir kiek gali pareikalauti pastangų?
2) Einamojo laikotarpio situacijos nustatymas. Šiame etape nustatomi stipriausi ir
silpniausi einamosios situacijos taškai.
3) Siekiamos situacijos nustatymas. Remiantis einamosios situacijos analize, nustatoma
siekiamoji situacija ir reikalingi veiksmai šio tikslo įgyvendinimui.
4) Pakeitimų įgyvendinimas. Pasiūlyti tobulinimo veiksmai yra įgyvendinami pagal planą
bei situaciją, kai patikrinus yra patvirtinama, jog tikslai buvo pasiekti [7].
Palyginant testavimo procesą su standartu, stipriosios ir silpnosios proceso vietos tampa
labiau matomos. Standartu gali būti vadinama testavimo technologija ar kuris nors tobulinimo
modelis, pasirinktas pagal situaciją.
3. 4. Išvados
Kad ir kokį testavimo modelį pasirinktų įmonė, jis niekuomet nebus tobulas. Taigi
egzistuojant testavimo problemoms, visuomet atsiranda poreikis testavimo procesą tobulinti. Kitaip
tariant, sistema nuolat sukasi ratu, nes pašalinus vienas problemas ir patobulinus įrangą, įdiegiamos
vis įmantresnės naujovės, kurios vėl gali sukelti problemų ir vėlgi sistemą tenka tobulinti. Tačiau
būtent tokiu principu sistemos ir yra tobulinamos. Dažniausiai šis procesas progresuoja būtent
testuotojui taikant įvairius metodus praktikoje ir kuriant iš jų naujus.
30
4. Testų kūrimo proceso optimizavimas
4. 1. Įvadas
Apskritai testo kūrimas atrodytų taip: testų kūrėjas gauna reikalavimus, parašo testus ir
atiduoda testavimui. Taigi testo kūrimo procesas užima tiek laiko, kiek užtrunka specifikacijų
išsiaiškinimas ir pačių testų parašymas. Viskas būtų paprasta, jeigu būtų testuojama tik minimalaus
funkcionalumo programinė įranga ir su galutinai paruoštais ir aiškiais reikalavimais. Tačiau
dažniausiai kuriamos programos turi begales funkcionalumų, kurie priklauso vienas nuo kito, o
dokumentacija yra paruošiama per vėlai ir dar su klaidomis ar nebaigta. Todėl tam, kad
specifikacijos suvokimas, testų paruošimas ir rašymas užimtų kuo mažiau laiko, reikėtų kuo mažiau
specialistų, būtina testų kūrimo procesą optimizuoti. Optimizavus šį procesą, galima kur kas
daugiau resursų skirti pačiam testavimui.
Testų kūrimo proceso optimizavimui yra sukurta gana daug metodų, tačiau vis vien
mažiau nei pačiam testavimui. Testų kūrimas kiekvienoje įmonėje yra gana individualus, todėl
neretai įmonė ne įdiegia kokį nors testų kūrimo būdą, o specialistai darbo eigoje patys kuria
optimizavimo metodus arba pritaiko (dažniausiai dalinai) jau sukurtus. Teoriškai įmanoma
pasirinkti keletą optimizavimo būdų ir nuo pat pirmo testo parašymo juos pritaikyti, tačiau
praktiškai tai niekuomet nedaroma.
4. 2. Proceso optimizavimas pasitelkiant Excel programą
Neretai optimizavimui pasitelkiamos ne tik metodologijos, bet ir programos. Viena jų –
„Microsoft Office Excel“ (toliau – Excel). Ši programa leidžia kurti bei formatuoti elektronines
lenteles ir atlikti įvairaus sudėtingumo skaičiavimus, pavaizduoti duomenis grafiškai. Excel leidžia
viename faile talpinti daug elektroninių lentelių. Taip pat turi galimybę importuoti įvairaus formato
duomenis (pavyzdžiui, iš tekstinių failų arba duomenų bazių) ir pati programa kai kuriais atžvilgiais
yra panaši į duomenų bazę. Taigi ši programa suteikia įvairiapuses galimybes optimizuoti
duomenis, kurie galėtų būti naudojami testuojant.
Testavimo duomenys, saugomi Excel programoje, dar yra vadinami duomenų rinkiniais
(angl. Data set). Tokie duomenų rinkiniai gali būti naudojami daug kartų testuojant, tačiau tik
vienam funkcionalumui. Taip yra dėl labai paprastos priežasties – į vieną failą sukelti visus
funkcionalumus būtų per daug. Paprastai vienas rinkinys yra sudaromas testuoti tik vienai
31
specifikacijų daliai. Duomenys sukeliami į įvairaus tipo lenteles. Dažnai naudojamos programos
funkcijos skaičiavimams ar teisingam duomenų išvedimui.
Gali kilti klausimas – kodėl verta duomenis saugoti tokiose lentelėse, jei testuojamas tik
vienas funkcionalumas? Atsakymas gana paprastas: tokius duomenis galima labai lengvai
modifikuoti, pridėti ar ištrinti, netaisant kiekvieno testo. Nors testuojamas funkcionalumas tik
vienas, tai dar nereiškia, kad jam sukuriamas tik vienas testas. Tam pačiam funkcionalumui
ištestuoti, gali prireikti visos eilės skirtingų duomenų, kad būtų patikrinti visi (ar bent didesnė dalis)
atvejų. Be to, taikant skaičiavimus, tarkime pasikeitus formulei, ją galima greitai pataisyti ir
pritaikyti visiems duomenų rinkiniams, nebereikia kiekvieno skaičiaus taisyti ranka.
Excel praktinis pritaikymas
Testuojama draudimo įmonės taikomoji programa, skirta apdrausti gyvenamosioms
patalpoms bei jose esančiam turtui. Draudimo suma priklauso nuo begalės skirtingų laukų reikšmių.
Taigi šiuo atveju labai tinka naudoti Excel programos suteikiamus funkcionalumus.
Programoje surašomi laukų pavadinimai, jei reikia jie išskiriami spalvomis pagal atributų
funkcionalumus ir į eilutes surašomos reikšmių sekos kiekvienam laukui. Vienas duomenų rinkinys
gali turėti tiek sekų, kiek leidžia pati programa. Dažniausiai viena seka simbolizuoja vieną testą.
Taigi jei tokių sekų būtų 20, pasikeitus lauko pavadinimui, reikėtų redaguoti 20 testų, o šiuo atveju
užtenka redaguoti tik Excel failą. Jei atsirastų nauja seka, kurią reikėtų testuoti, nereikėtų kurti
naujo testo, o užtektų šią seką įrašyti į failą.
4 pav. Sekų duomenų rinkiniai Excel programoje
32
Kitas galimas variantas – duomenų surašymas į lenteles, kur viena lentelė atitinka vieną
testą. Šis variantas patogus, kai testuojamos sumos, nes prie kiekvieno reikiamo lauko įrašoma
suma, o rezultatas lentelės pabaigoje. Tokiam atvejui galėtų tikti ir sekų surašymo variantas, tačiau,
jei egzistuoja daug laukų su sumomis, surašius viską į vieną eilutę, nesimatytų visų reikšmių bei
rezultato, dėl to kiltų nepatogumų testuojant. Abu variantus galima sujungti, taip būtų sudarytas dar
vienas tipas. Žinoma, tai tik keli variantai, kaip galima panaudoti Excel programą testavimui.
5 pav. Lentelių duomenų rinkiniai Excel programoje
Pati forma ar dizainas, kaip išdėliotas tekstas, spalvos ar kaip pabraižyta lentelė, neturi
jokios įtakos testavimui. Žinoma, jei viskas būtų palikta vienos spalvos, neparyškinant jokios teksto
dalies, pavadinimų, būtų sunkiau testuoti. Todėl failo išvaizda pasirenkama tik pagal kūrėjo
vaizduotę. Jis parenka optimaliausią variantą, spalvas ar tekstūrą, taip, kad testuotojui vėliau kiltų
kuo mažiau klausimų ar neaiškumų. Pav. 4 sujungti apibendrinantys langeliai, kas antra eilutė
paryškinta kita spalva, kad testuotojui būtų lengviau matyti tik reikiamos sekos duomenis, lauko
grupės taip pat atskirtos spalvomis. Pav. 5 lentelės kraštai apibrėžti storesne linija, laukai, turintys
įtakos galutinei sumai, išskirti kita spalva, o pagrindiniai scenarijai nuo šalutinių (papildomų) taip
pat atskirti brūkšniu. Pav. 6 pavaizduotos lentelės, kurios nurodo laukus bei jų reikšmes, kurie turi
įtakos dokumento generavimui, tad kadangi iš visų laukų išrenkami tik reikalingi, todėl specialus
33
spalvų skyrimas netaikomas, nors galima būtų atskirti spalvomis teigiamus bei neigiamus scenarijus
(kai dokumentas generuojamas arba ne). Ir visi šie paveikslai yra tik keli iš daugelio pavyzdžių,
kaip gali atrodyti suformuotas duomenų rinkinys.
6 pav. Dokumentų generavimo duomenų rinkiniai Excel programoje
Gana svarbi Excel funkcija – programą galima naudoti, tik duomenų laikymui ir failo
nuorodą įkelti į automatinį testą (automatinis testas – testas, tinkamas atlikti bet kuriame testavimo
etape, parašytas pasitelkus programavimo kalbą ir jį paleidus, etapai atliekami automatiškai,
testuotojui nieko nereikia spausti ir rinkti rankomis, jis mato visą procesą ir galutinį rezultatą). Taigi
tai, kas pradžioje buvo testuojama rankomis, gali būti automatizuota, o automatinis testas visuomet
atliekamas kur kas greičiau nei rankomis. Šiuo atveju optimizuojama ne tik testo kūrimas, bet ir
pats testavimo procesas.
34
7 pav. Duomenys Excel programoje
Atvirkščiai, į Excel gali būti importuojami kitų failų duomenys, kurie taip pat
panaudojami testavimui. Taigi jei reikiama dalis specifikacijos ar reikalavimų yra patalpinta į
tinkamą importavimui failą, testo parašymo laikas kur kas sutrumpėja.
Excel funkcionalumas leidžia įvairiapusiškai panaudoti programą testavimui: formatuoti
bei modifikuoti lenteles ir atlikti įvairius skaičiavimus, kaupti duomenis, pavaizduoti informaciją
grafiškai. Todėl neretai nė vienas testavimo ciklas, nesvarbu kuris etapas, neapsieina be šios
programos. Vienaip ar kitaip Excel programa panaudojama proceso optimizavimui.
4. 3. Proceso optimizavimas pasitelkiant šablonus
Kiekviena įmonė paprastai testus kaupia vienoje vietoje, kur visi testuotojai galėtų juos
pasiekti. Dažniausiai yra sukuriamas testų medis, kuris gali turėti iki kelių tūkstančių atšakų. Tačiau
patys testai privalo būti vieno formato, kad ir kiek jų bebūtų sukurta tam, kad būtų išvengta
nesusipratimų ar klaidų.
Testų formatas
Testų formatas priklauso tik nuo įmonės poreikių ir pasirinkto varianto. Griežto
apibrėžimo tam nėra. Tačiau bet kuriuo pasirinku atveju testai turi būti suskirstyti į kelias esmines
dalis: testo tikslas, aprašas arba būtinosios sąlygos bei laukiami rezultatai.
35
Iš esmės tikslo įtraukimas į testą nėra būtinas, tačiau jį parašyti užima labai mažai resursų,
o jo funkcinė nauda kur kas labiau viršija laiko sąnaudas. Neratai prie tikslo taip pat įtraukiamas ir
testo numeris (jeigu jis nėra nurodomas kartu su pavadinimu).
Paprastai testo aprašas ar būtinosios sąlygos kartu nėra naudojamos. Aprašas dažniausiai
tampa testo sudedamąja dalimi tuomet, kai teste neminimi veiksmų atlikimo etapai. Taigi trumpai
aprašoma, ką reikėtų atlikti ir parašomi laukiami rezultatai. Jeigu testo atlikimas nurodomas
paeiliui, tuomet reiktų pridėti būtinąsias sąlygas, nes reikia paruošti taikomąją programą prieš
atliekant testavimo etapus.
Jeigu testas yra lentelė, tai paprastai išskiriamas atskiras laukas rezultatams, jei
aprašomojo tipo, tai gana dažnai testo rezultatai yra įmaišomi į testavimo etapų aprašą, kai atliekami
keli veiksmai, patikrinamas rezultatas, vėl atliekami veiksmai, vėl tikrinamas gautas rezultatas ir
taip toliau.
Dar viena, gana dažnai pridedama testo dalis – komentarai. Komentarus galima rašyti tiek
testo pabaigoje, tiek pradžioje, ar net testo viduryje pačius komentarus kažkaip išskiriant iš likusio
teksto.
Šablonų tipai
Ir šablonų, ir testų tipai gali būti labai įvairūs. Dažniausiai šablonai net nesiskiria nuo
pačių testų ar nuo kurios nors dalies. Jų paskirtis:
• pavyzdys, pagal kurį kuriami kiti testai;
• paruošta dalis, kurią tereikia įdėti į testą;
• paruoštas pats testas.
Paprastai būna sukuriami keli pavyzdiniai šablonai, nes testų pagrindinės dalys gali skirtis
(ir gana žymiai) priklausomai nuo testuojamo funkcionalumo. Todėl vieno šablono pritaikyti visam
testavimo funkcionalumui praktiškai neįmanoma. Vadinasi, pagrindinės dalys yra aprašomos
atsižvelgiant į reikalavimus. Kadangi šablonas naudojamas tik kaip pavyzdys, jame turėtų būti
ryškiai išskirtos dalys ar atskiri žodžiai, kurie privalo būti keičiami rašant patį testą. Dar
pavyzdiniuose šablonuose gali būti surašomos kelios reikšmės, kurios galėtų būti pavartotos teste.
Tokių šablonų rašymo specifika yra labai įvairi. Taigi pradėtas kurti vienokio tipo
šablonas gali būti modifikuojamas į visiškai kitokį, kol pasiekiamas norimas rezultatas.
Šablonai – paruoštos testų dalys kardinaliai skiriasi nuo pavyzdinių šablonų. Toks
šablonas jau yra dedamas į testą ir nebekeičiamas. Pirmiausia, pakeitimui nesudaroma jokių
galimybių, nes beveik visada šablonas yra ne kopijuojamas, o įkeliamas į testą pasitelkus programos
36
funkcijas. Nors testuotojas mato šablonui identišką testo tekstą, atsidarius testą redagavimo režimu,
matoma tik pati funkcija, kuri įkelia šabloną.
Tokių šablonų į vieną testą galima įkelti neribotą skaičių. Todėl patys šablonai kuriami
atsižvelgiant ne tik į funkcionalumą, bet ir į poreikį tą patį tekstą kartoti keliuose testuose. Todėl
neretai paruoštų šio tipo šablonų galima rasti daugiausiai.
Testas – atsakingiausiai kuriamas šablonas. Dažnai ne vieną kartą keičiamas kelių
testuotojų (testų kūrėjų), norint pasiekti geriausią rezultatą. Tokiame šablone negalima palikti jokių
neaiškumų ar klaidų, nes šablonas yra naudojamas daug kartų ir kartais skirtas tikrinti kelioms
sritims. Todėl paruošus prastą šabloną, nesunku testuojant praleisti klaidas, ar palikti netestuotus
funkcionalumus.
Pavyzdžiui, testuojami skirtingi dokumentai. Juose skiriasi tekstas, jo išdėstymas, šriftas,
spalvos, net dokumentų formatas gali skirtis, tačiau juos jungia pats testuojamas tipas –
dokumentas. Tiek pagrindinis funkcionalumas, tiek stilius privalo būti testuojamas. Nors tokių testų
prioritetas yra vienas mažiausių, testai vis tiek turi būti paleisti. Taigi nesvarbu, kad patys
dokumentai labai skiriasi, vienos įmonės dokumentacija visuomet išlaiko vienodą stilių. Todėl
stiliaus testavimui galima panaudoti šabloną – testą. Testo kūrėjui telieka nurodyti testo numerį ir
minimalų aprašą: koks dokumentas testuojamas, jeigu reikia, nurodoma, kaip dokumentą sukurti ir
t. t.
4. 4. Proceso optimizavimas pasitelkiant sprendimų lentelę
Sprendimų lentelės yra naudojamos duomenims į lentelės tipo modelį surašyti ir taip
surasti visas įmanomas situacijas. Šios situacijos gali specifikuoti tam tikrus veiksmus. Tai tarsi
rinkinys funkcijų „jei – tai – kitu atveju“. Kiekvienas veiksmas yra susijęs, nes nuo padaryto
pradinio etapo gali priklausyti ne tik galutinis rezultatas, bet ir kiti etapai.
Bet kurio tipo sprendimų lentelei sudaryti reikia atlikti kelis nesudėtingus etapus:
• reikšmių identifikavimas. Surandami visi reikalingi duomenys, jų atributai, kurie
bus panaudoti sudarant lentelę;
• išskiriami konkretūs veiksmų atvejai (tai ir yra reikšmių atributai). Būtina nustatyti
visus nepriklausomus ir nesikartojančius veiksmus tam, kad vėliau kiekvienas būtų
panaudotas sudarant visus įmanomus sprendimų variantus;
• apskaičiuojamas maksimalus visų sekų skaičius: kadangi įrašomos viena iš 2-jų
reikšmių į vieną lentelės lauką, taigi šis skaičius ir yra keliamas tokiu laipsniu,
koks yra atributų skaičius, ir rezultatas surašomas į lentelę;
37
• sekų surašymas. Į lentelę iš eilės surašomos visos sekos, kurios paprastai žymimos
tiesiog skaičiais. Sekos numeris yra rašomas lentelės kairėje (arba viršuje pagal
laisvą pasirinkimą). Seka – tai unikali veiksmų eilės tvarka;
• veiksmų priskyrimas sekoms. Kiekvienai sekai yra priskiriamas vienas veiksmas.
Taip sudaroma galutinė lentelė. Paprastai ne visada kiekvienai sekai gali tikti
kiekvienas veiksmas. Todėl sankirtos vietoje, kuri neatitinka testuojamo varianto,
pažymima „X“ arba bet koks kitoks sutartas ženklas;
• lentelės tikrinimas. Tam, kad lentelė būtų sudaryta teisingai, visi atvejai būtų
surašyti, kad neįsiveltų logikos klaidų, būtina lentelę dar sykį peržiūrėti. Geriausia,
jei tai daro kitas žmogus, ne lentelės sudarytojas, tačiau neblogiau išmanantis visą
procesą;
• lentelės optimizavimas. Neretai, sudarius lentelę, kai kurios eilutės ar stulpeliai
kartojasi arba tampa nereikalingi dėl veiksmų neatitikimo sekai (kaip minėta, tokia
sankirtos vieta pažymima „X“). Taigi šios eilutės (stulpeliai) yra išbraukiami iš
lentelės. Taip mažinamas testavimų skaičius, tačiau pats funkcionalumas yra
išlaikomas.
Taigi sudarius tokią lentelę, gaunama variacijų matrica. Vienoje pusėje surašytos sekos,
kitoje – veiksmai. Belieka užpildyti pačią lentelę reikšmėmis. Lentelė pildoma įrašais „Taip“ arba
„Ne“ (trumpiniai lentelėje T ir N raidės). Tai reiškia, kad tam tikras veiksmas arba atitinka taisyklę,
arba neatitinka. Tačiau nereikėtų painioti prieš tai minėtos lentelės optimizavimo dėl veiksmo
neatitikimo sekai su variantu „Ne“. Iš lentelės išbraukiamas variantas, kai tam tikram veiksmui
neįmanoma pritaikyti tam tikros sekos. Štai šiuo atveju iš lentelės ir yra braukiamos eilutės ar
stulpeliai, o sankirtoje įrašyta reikšmė „Ne“ paprasčiausiai atsako į užduotą klausimą, ar šis
veiksmas atitinka taisyklę.
Galiausiai paskutinė nepaminėta lentelės dalis yra rezultatai. Jų išdėstymas lentelėje
priklauso ne tik nuo to, kokiu būdu buvo surašyti veiksmai bei sekos, bet ir nuo to, kokia forma, ar
kokiu tipu, ar kokį funkcionalumą pasitelkiant siekiama gauti rezultatus. Dažniausiai pasitaikantis
variantas, kai rezultatai surašomi lentelės apačioje, jei veiksmai lentelėje yra kairėje pusėje, arba
surašomi lentelės šone (dešinėje), jei veiksmai surašyti viršutinėje lentelės dalyje.
Sprendimų lentelės pritaikymas
Testuojama draudimo įmonės taikomoji programa, skirta apdrausti gyvenamosioms
patalpoms. Tam, kad būtų išvengta svarstomų problemų tolesniuose etapuose, būtina kaip įmanoma
38
daugiau funkcionalumo ištestuoti viename testavimo etape. Taigi šiuo atveju labai tinka naudoti
sprendimų lentelę.
Kaip minėta ankstesniuose skyriuose, pirmiausia būtini galutiniai dokumentuoti
reikalavimai ir specifikacijos, gauti iš kliento ar užsakovo. Pagal tas specifikacijas yra kuriami
testai. Testų rašymas taip pat gali užimti nemažai laiko, ypač, jei specifikacijos turi daug ir gana
sudėtingų taisyklių, kur vienas funkcionalumas priklauso nuo kito. Taigi, kad visi įmanomi atvejai
būtų aprašyti testuose, naudojama sprendimų lentelė.
Paprastai viena sprendimų lentelė leidžia aprašyti vieną seką, kurioje veiksmai gali būti
keičiami vietomis, svarba ar pačių veiksmų skaičiumi. Tačiau kombinuojant sekas galima pamatyti,
kad keletas funkcionalumų gali būti testuojami pasitelkiant vieną lentelę.
Šiame pavyzdyje testuojama, kad po sutarties išsiuntimo būtų sugeneruoti reikiami
dokumentai. Iš specifikacijos išrenkamos norimos testuoti taisyklės.
1 lentelė. Taisyklės bei dokumentai
Taisyklė Generuojamas dokumentas
1. Patalpos draudžiamos pusmečiui nuo gaisro Dokumentas Nr. 1
2. Patalpos su padidinta rizika draudžiamos pusmečiui nuo gaisro (padidinta rizika: patalpos medinės arba anksčiau jose yra kilęs gaisras) Dokumentas Nr. 2
3. Draudžiamas medinis namas ne nuo gaisro Dokumentas Nr. 3
Nors kiekvienam dokumentui testuoti galima sukurti po atskirą sprendimų lentelę, taip
nedaroma, nes visi šie dokumentai yra susiję tarpusavyje. Tarkime, antro dokumento generavimui
testuoti, į lentelę reikėtų surašyti 4 veiksnius: laikotarpis, draudimo priežastis, statybinė medžiaga,
ankstesni įvykiai. Iš jų 3 yra tinkami testuoti dokumentui Nr. 1. Tačiau dar pridėjus patalpų tipą,
galima testuoti ir trečiąjį dokumentą. Taigi tai dar vienas būdas optimizuoti testų rašymą.
Toliau parenkami šioms taisyklėms testuoti reikalingi duomenys bei jų atributai.
2 lentelė. Atrinkti duomenys bei jų atributai
Duomenys Patalpos Draudimo laikotarpis
Ankstesni įvykiai
Draudžiama nuo
Statybinė medžiaga
Atributai
Namas Mėnuo Vandalizmas Vandalizmo Mūras
Butas Puse metų Vagystė Vagystės Medis
- Metai Gaisras Gaisro Kita
Jei visi šie atributai (veiksmai), kurių yra 14, būtų surašomi į sprendimų lentelę, tuomet
visos sekos, kaip jau minėta, būtų apskaičiuojamos skaičių 2 keliant 14-uoju laipsniu. Taigi sekų
skaičius būtų lygus net 16384 atvejams. Tokios lentelės sudaryti nevertėtų, nes tai tolina svarbiausią
39
lentelės funkciją – optimizuoti testų skaičių. Todėl iš atrinktų duomenų su atributais išrenkami
reikiami veiksmai, kurie lems sprendimų lentelės rezultatus, tai yra generuojamus dokumentus:
• patalpos: namas;
• patalpos: butas;
• laikotarpis: pusmetis;
• ankstesni įvykiai: gaisras;
• draudžiama nuo: gaisro;
• tipas: medinis.
Nors gali atrodyti, kad toks atributų atrinkimas atitolina optimizavimą, patyręs testuotojas
iš specifikacijų gali gana greitai atrinki reikiamus atributus. Taigi šiuo atveju dominantis laikotarpis
– draudimas pusei metų, o dominanti draudimo paskirtis – tik gaisras, nes kiti atributai dokumentui
neturi įtakos.
Iš 14 atributų atrenkami 6, kurie surašomi į lentelę. Įrašomas atributas tarsi virsta
klausimu: ar tai yra namas; ar laikotarpis yra pusė metų; ar anksčiau patalpos yra degusios? Ir
atsakymai į šiuos bei panašius klausimus yra surašomi į sprendimų lentelę su reikšmėmis „Taip“
arba „Ne“.
Lentelės pildymas
Lentelė pildoma gana paprastu būdu (sakykime, kad lentelės atributai (veiksmai) yra
surašomi kairėje, o sekos viršuje):
• pirma eilutė užpildoma pasikeičiančiomis reikšmėmis „Taip“ ir „Ne“;
• antra eilutė užpildoma „Taip“ ir „Ne“ reikšmėmis po kiekviena „Taip“ ir po
kiekviena „Ne“ reikšme iš pirmos eilutės. Taigi šiuo atveju jau reikšmių
išsidėstymas eitų tokia seka: „Taip“, „Taip“, „Ne“, „Ne“, t. y. atsakius į pirmąjį
klausimą „Taip“, į antrąjį būtų vėlgi galima atsakyti „Taip“ arba „Ne“;
• trečioji eilutė yra identiška antrosios eilutės logikai: kiekvienai unikaliai prieš tai
buvusiai sekai parašoma po „Taip“ ir po „Ne“ reikšmes. Ir taip tęsiama, kol
reikšmės suvedamos į visas eilutes.
Akivaizdu, kad kiekviena eilutė unikaliu „Taip“ ir „Ne“ reikšmių išsidėstymu
padvigubėja. Taip tęsiama, kol užpildoma visa lentelė reikšmėmis.
Tačiau jau iš pirmųjų atributų matoma, kad patalpos gali būti arba namas, arba butas (kiti
variantai šioje draudimo sutartyje nėra minimi). Todėl jeigu pirmoje eilutėje yra pasirinktas „Taip“,
40
antroje eilutėje lieka tik vienas pasirinkimo variantas „Ne“, nes patalpos negali vienu metu būti ir
namas, ir butas. Lygiai taip pat, kaip ir jos negali būti nei namo, nei buto tipo, nes toks variantas
nėra svarstomas sutartyje. Vadinasi, šiuo atveju visur, kur antrojoje eilutėje pasitaikytų tokia pat
reikšmė kaip pirmojoje, turėtų būti įrašomas „X“, kaip negalima reikšmė. Kaip jau minėta anksčiau,
tokie stulpeliai yra braukiami iš lentelės. Taigi šiuo atveju lentelės sekų skaičiaus apimtis sumažėja
du kartus.
3 lentelė. Sprendimų lentelė 1 dalis
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Patalpos: namas T N T N T N T N T N T N T N T N
Patalpos: butas N T N T N T N T N T N T N T N T
Laikotarpis: pusmetis T T N N T T N N T T N N T T N N
Ankstesni įvykiai: gaisras T T T T N N N N T T T T N N N N
Draudžiama nuo: gaisro T T T T T T T T N N N N N N N N
Tipas: medinis T T T T T T T T T T T T T T T T
Dokumentas Nr. 1 T T N N T T N N N N N N N N N N
Dokumentas Nr. 2 T T N N T T N N N N N N N N N N
Dokumentas Nr. 3 N N N N N N N N T N T N T N T N
4 lentelė. Sprendimų lentelė 2 dalis
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Patalpos: namas T N T N T N T N T N T N T N T N
Patalpos: butas N T N T N T N T N T N T N T N T
Laikotarpis: pusmetis T T N N T T N N T T N N T T N N
Ankstesni įvykiai: gaisras T T T T N N N N T T T T N N N N
Draudžiama nuo: gaisro T T T T T T T T N N N N N N N N
Tipas: medinis N N N N N N N N N N N N N N N N
Dokumentas Nr. 1 T T N N T T N N N N N N N N N N
Dokumentas Nr. 2 T T N N N N N N N N N N N N N N
Dokumentas Nr. 3 N N N N N N N N N N N N N N N N
Lentelės apačioje po antruoju dvigubu brūkšniu rašomi laukiami rezultatai. Šiuo atveju
įrašoma, ar kuris nors dokumentas po atitinkamos veiksmų sekos bus sugeneruotas, ar
nesugeneruotas. Gali kilti klausimas, kam testuoti atvejus, kai nesugeneruojamas nė vienas
dokumentas? Visuomet būtina ištestuoti atvirkščius, dar vadinamus neigiamais, atvejus, kai
41
dokumentai nesugeneruojami pasirinkus veiksmus, kurie neturi įtakos dokumentams. Tai būtų
nemažesnė klaida, kaip dokumento nesugeneravimas, kai to reikia. Juk klientui, gavusiam
dokumentą, gali kilti nepatogumų kai jis nesitiki jo pamatyti.
Kalbant apie šį konkretų atvejį, kai klientas pildo draudimo sutartį, drausdamas namą tik
nuo gaisro ir gauna sutartį, kuriame aprašytos draudimo sąlygos nuo potvynio, gali kilti daug
klausimų. Taip būtų sudaryti nepatogumai abiems pusėms, nes klientas turėtų kreiptis į draudimo
įmonę, ši savo ruožtu turėtų tikrinti dokumentus papildomai, keisti dokumentaciją rankomis. Tačiau
testuojant neigiamus atvejus, klaidos prioritetas būtų mažesnis nei pagrindinio atvejo.
Papildomas lentelės optimizavimas
Taigi, pagal lentelę, turėtų būti parašyti 32 testai, kad būtų patikrinti visi dominančių
dokumentų generavimo atvejai. Tačiau optimizavimas dar nėra baigtas. Žinoma, nebenorint daugiau
leisti laiko resursų šiam etapui, arba jei testų kūrimas yra automatizuotas, šioje vietoje jau galima
pradėti rašyti testus. Tačiau, nesunkiai galima rasti, kaip keletą sekų sujungti į vieną testą.
Šiam pavyzdžiui pateikti interpretuojama, kad visi laukai yra laisvai pasirenkami. Tai
reiškia, kad vietoje „Ne“ reikšmės galima nepasirinkti jokios, kad dokumentų generavimą galima
patikrinti iškart po lauko užpildymo, o ne tik išsaugojus sutartį. Vizualizavimui išrenkamos 2, 18,
26, 30 ir 32 sekos, jos sunumeruojamos atbuline tvarka ir sudaroma nauja lentelė.
5 lentelė. Sekų optimizavimas
32 30 26 18 2
Patalpos: namas N N N N N
Patalpos: butas T T T T T
Laikotarpis: pusmetis N T T T T
Ankstesni įvykiai: gaisras N N T T T
Draudžiama nuo: gaisro N N N T T
Tipas: medinis N N N N T
Dokumentas Nr. 1 N N N T T
Dokumentas Nr. 2 N N N T T
Dokumentas Nr. 3 N N N N N
5-oje lentelėje vaizdžiai matoma, kad „Taip“ reikšmių tolygiai daugėja. Pasirinkus atributo
„Butas“ reikšmę „Taip“, patikrinama, kad nesusigeneravo nei vienas dominantis dokumentas.
Toliau galima pridėti laikotarpio atributą ir vėl tikrinti dokumentų generaciją. Taip galima pereiti
per visas sekas ir patikrinti visus atvejus. Tikrinant 18-ąją seką, jau generuojami 2 dokumentai:
42
Dokumentas Nr. 1 ir Dokumentas Nr. 2. Taigi tikrinant 2-ąją seką, belieka patikrinti, kad
nesugeneruojami papildomi dokumentai, nes tie, kurie turi būti siunčiami, jau sugeneruoti ir
paskutinis veiksmas (patalpų tipo pasirinkimas), neturi lemti dokumentų skaičiaus. Visos šios sekos
surašomos į vieną testą.
Kadangi šis optimizavimo būdas yra gana individualus, priklausantis nuo dokumentų
specifikos, taikomosios programos funkcijų ir daugybės kitų faktorių, todėl sunku nustatyti galutinį
testų skaičių. Tačiau šiame pavyzdyje gana nesunku pastebėti, kad vietoje 32 galimų testų, sujungus
sekas, įmanoma apsiriboti vos 10-imi ar mažiau testavimo atvejų.
4. 5. Išvados
Jei testų kūrimas būtų primityvus specifikacijų perskaitymas ir testų parašymas, toks
testavimo procesas užtruktų keliskart ar net keliasdešimt kartų ilgiau nei reikalautų užsakovas.
Vadinasi, be optimizavimo produktyvus testavimas būtų tiesiog neįmanomas. Kaip nesunku
pastebėti, būdų optimizuoti tiek patį testavimą, tiek testų kūrimą yra begalės, įmonei belieka
išsirinkti pačius tinkamiausius, labiausiai atitinkančius poreikius. Poreikis procesą padaryti
paprastesnį, lengviau ir greičiau atlikti darbus visuomet būdavo ir bus, todėl nenuostabu, kad
atrandama vis daugiau būdų tai padaryti.
43
Išvados
• Atlikus testavimo proceso analizę bei išnagrinėjus jo valdymą, nesunku pastebėti, kad
visos šio proceso dalys yra svarbios ir neatsiejamos viena nuo kitos. Be dokumentacijos
nebūtų testų, be testų nebūtų greito ir rezultatyvaus testavimo, be testavimo produkto vertė
būtų netoli žemiausios ribos dėl daugybės defektų. Todėl visas testavimo procesas negali
būti apribojamas tik pačių klaidų ieškojimu – testavimu, tačiau ir kitos dalys turi būti
adekvačiai vertinamos.
• Norint pasiekti geriausių rezultatų, ne tik verta, bet ir būtina tobulinti visą procesą: nuo
testų planavimo bei kūrimo iki rezultatų regresinio testavimo ir smulkiausių klaidų
taisymo.
• Išanalizavus optimizavimo metodus, galima teigti, kad bet kuris testų kūrimas be
optimizavimo ilgina proceso laiką, bereikalingai naudoja resursus, dažniausiai neapima
viso testuojamo funkcionalumo, todėl praleidžiamos klaidos. Praktiškai tik su minimaliu
funkcionalumu įmanomas testų kūrimas bei testavimas be optimizavimo. Todėl be
testavimo proceso optimizavimo įmonė sunkiai pasiektų norimų rezultatų.
• Atlikus testų kūrimo logikos analizę, parinkti geriausi optimizavimo metodai bei pritaikyti
praktinėje įmonės veikloje. Nors metodai parinkti tik keli, jie leidžia nevaržomai plėsti
galimybes ir metodus vis tobulinti, jau neatsižvelgiant į teorinę dalį, o tik į įmonės
poreikius bei taikomą strategiją.
44
Literatūros sąrašas
1. 10 Key Principles of Agile Software Development. [žiūrėta 2010 05 02] Prieiga per
internetą: http://www.agile-software-development.com/2007/02/10-things-you-need-to-
know-about-agile.html.
2. Andersin J. TPI – a model for Test Process Improvement. Helsinki, 2004.
3. Boughan E. A., Grey P. J. Software Quality Assurance Plan. Massacgusetts Institute of
Technology, 1994.
4. Bringmann E., Kramer A. Model – based Testing of Automotive SYstems. PikeTec
GmbH, 2007.
5. Everett G. D., McLeod Jr. R. Software testing: Testing Across the Entire Software
Development Life Cycle. IEEE Press, 2007.
6. Fewster M., Graham D. Software Test Automation: Effective use of test execution tools.
ACM Press, 2000.
7. Koomen, T., Pol M. Test Process Improvement: A practical step-bystep guide to
structured testing. ACM Press, 1999.
8. Microsoft Office Online. [žiūrėta 2010 05 12] Prieiga per internetą:
http://office.microsoft.com/lt-lt/excel/HA101656321063.aspx.
9. Model – based testing. [žiūrėta 2010 05 02] Prieiga per internetą:
http://www.goldpractices.com/practices/mbt.
10. Model Based Testing. [žiūrėta 2010 05 03] Prieiga per internetą:
http://www.testinggeek.com/index.php/testing-types/execution-method/114-model-based-
testing.
11. Pan J. Software Testing. Carnegie Mellon University, 1999.
12. Pyzdek T. Quality Engineering Handbook. Marcel Dekker Inc., 2003.
13. Pristatyta IT sistemų kūrimo metodika „Agile“. [žiūrėta 2010 05 02] Prieiga per
internetą: http://www.delfi.lt/news/economy/ITbussines/article.php?id=17285377.
14. Rakalovič M. Dokumentų valdymo sistemos integracijos su Cad sistema testavimo
proceso optimizavimas. VGTU, Baigiamasis magistro darbas, 2009.
15. Roggenbach M., Schlingloff H. Levels of testing: Advance topics in Computer Science.
University of Wales Swansea Computer Science Departament, 2006.
16. Spillner A., Linz T., Schaefer H. Software Testing Foundations: A Study Guide for the
Certified Tester Exam. Rocky Nook Inc., 2007.
45
17. Test Plan Template Baseline. [žiūrėta 2010 04 27] Prieiga per internetą:
https://cabig.nci.nih.gov/workspaces/CTMS/Templates/Test%20Plan%20Template_Base
line.doc.
18. Vauthier J. C. Decision tables: A testing technique using IBM Rational Functional
Tester. [žiūrėta 2010 04 28] Prieiga per internetą:
http://www.ibm.com/developerworks/rational/library/jun06/vauthier.
19. Wilde M. Decision Tables: A useful testing techniques and more. 2010.
46
Priedai
1. Straipsnis „CRM – Ryšių su klientais valdymas“.
2. Pažyma iš įmonės „Exigen Services Lietuva“.
1 Priedas
© Vilniaus Gedimino technikos universitetas http://www.vgtu.lt/leidiniai 47
„ M O KSL AS – LIET U VOS AT EIT IS“ . 20 09 , N r . 2 ( 2 ) I n f o r ma t ik a
Mokslinių straipsnių rinkinys ISSN 2029-2341 (print) / ISSN 2029-2252 (online)
CRM – RYŠIŲ SU KLIENTAIS VALDYMAS
Mindaugas Černiauskas, Romualda Glodenytė Magistrantai,
Vilniaus Gedimino technikos universitetas el. p. [email protected]; [email protected]
Anotacija. Straipsnyje apžvelgiamos CRM galimybės, ypatybės, šio produkto efektyvumas, nauda, norint įgyti konkurencinį pranašumą rinkoje. Įvardijami pagrindiniai veiksniai, reikalingi sukurti efektyvią klientų valdymo strategiją. Nagrinėjama gaunama nauda įdiegiant šį produktą į įmonės sistemą. Trumpai aptariamos CRM dalys bei tipai, jų privalumai ir trūkumai.
Reikšminiai žodžiai: ryšių su klientais valdymas – CRM, Operatyvinis, Analitinis, Bendradarbiavimo CRM.
Įvadas
Ryšių su klientais valdymas (angl. customer relationship management, CRM) - tai verslo valdymo ir santykių su klientais sistemos, kurios yra vienas iš sprendimų, leidžiančių pagerinti pardavimo proceso kokybę bei bendradarbiavimą su klientais. CRM sistemos sukuria sąlygas efektyviai valdyti bendravimo su klientais procesus, vykstančius skirtinguose įmonės skyriuose ar nutolusiuose padaliniuose, vykdant įvairias veiklos funkcijas. CRM centre yra klientas, prie kurio poreikių derinama veikla bei kultūra, reikalinga efektyviai rinkodarai, pardavimams ir paslaugų teikimui. CRM prasideda nuo verslo strategijos, kuri lemia pokyčius organizacijoje bei jos darbinėje veikloje ir yra susijusi su informacijos technologija (Customer Relationship Management 2009a, Customer Relationship Management 2009b).
Geresnės galimybės
CRM sudaro geresnes galimybes:
− Per kuo trumpesnį laiką rasti visą informaciją apie reikiamą klientą bei įmonės verslo informaciją su juo;
− Kontroliuoti vadybininkus, tinkamai įvertinti jų darbą;
− Didinti pardavimų spartą bei užtikrinti jų pastovumą;
− Suteikia galimybę vadybininkams dirbti komandinį darbą, kurti, vykdyti, keisti užduotimis;
− Išspręsti darbuotojų kaitos problemą. Vadybininkui palikus kompaniją, visi jo klientai, atliktos užduotys, ateities planai lieka CRM sistemoje;
− Leidžia sutelkti dėmesį į pardavimus.
Norint sukurti efektyvią klientų valdymo strategiją, yra įvardijami šie pagrindiniai veiksniai:
− Kiekvienas klientas yra unikalus, todėl būtina išsamiai išanalizuoti jo poreikius bei savybes, sukaupti bent minimalią informaciją apie klientą: kontaktai, darbo profilis, pagrindinei pageidavimai;
− Esamų ir potencialių veiklos segmentų modeliavimas, kuris padeda suskirstyti klientus pagal prioritetus;
− Nuolaidų ir akcijų kūrimas, labiausiai vertinamiems pirkėjams su tikslu parodyti dėmesį ir pasiūlyti nuolaidų, bei palaikyti nuolatinį ryšį su juo;
− Organizacijos technologijų veiklos reformavimas, siekiant išlaikyti firmos ir jos klientų glaudesnį bendradarbiavimą (Kirvaitis 2008) .
48
Integruoti CRM sprendimai leidžia ne tik lengvai modifikuoti duomenis apie klientus, gauti visą informaciją apie bendravimą su klientais, bet ir analizuoti informaciją. Dirbant tokiais principais, galima aptikti pelningiausius ir rizikingiausius klientus, vystyti pardavimo ciklus bei rinkodaros kampanijas skirtingomis kryptimis.
CRM tipai
Pagal savo pobūdį CRM skirstomas į „operatyvinį”, „analitinį” bei „bendradarbiavimo“ (1 pav.). Šis skirstymas svarbus: nuo jo priklauso, kokios taktikos įmonė laikysis įgyvendindama savo CRM strategiją.
1 pav. CRM tipai
Operatyvinis CRM
Šis tipas apima sritis, kuriose įmonė tiesiogiai kontaktuoja su klientu. Toks kontaktas gali būti ‘įeinantis’ – pavyzdžiui, kliento skambutis į bendrovės kontaktinę liniją – arba „išeinantis“– tarkime, elektroniniu paštu klientui išsiųstas reklaminis pranešimas. Dauguma šiandien rinkoje esančių CRM programinės įrangos produktų patenka būtent į operatyvinio CRM kategoriją. Operatyvinis CRM padaro bendravimą su klientu efektyvesniu, tačiau tai nebūtinai reiškia tobulesnį aptarnavimą (Organizacijų Kompiuterinių Sistemų Laboratorija 2009) .
Analitinis CRM
Dar vadinamas „strateginiu“, leidžia suprasti kliento veiksmus. Analitinio CRM diegimui reikalingi adekvatūs IT sprendimai, leidžiantys surinkti ir apdoroti analizei reikalingos klientų informacijos. Jam taip pat reikalingi nauji verslo procesai, kuriais siekiama patobulinti klientų aptarnavimo praktiką, skatinant jų lojalumą ir didinant pelningumą. Ekspertų ir klientų spaudžiami, dauguma CRM programinės įrangos gamintojų šiandien skuba patys sukurti analitinio CRM produktus arba mėgina įtraukti šias galimybes į savo produktus sudarydami partnerystės susitarimus su analitinės verslo informacijos IT sprendimų tiekėjais (Organizacijų Kompiuterinių Sistemų Laboratorija 2009).
Bendradarbiavimo CRM
Toks CRM sutelkia dėmesį į bendravimą su klientais (asmeninis bendravimas, laiškai, faksas, telefonas, internetas, el. paštas ir t.t.). Ši dalis apima:
− Internetines konferencijas;
− Interneto formų valdymą;
− Automatinį elektroninio pašto valdymą;
− Unifikuotų žinučių valdymas;
− Internetinės bendravimo priemones (Organizacijų Kompiuterinių Sistemų Laboratorija 2009).
Nepriklausomai nuo įmonės pasirinkto CRM iniciatyvos tipo, bendruoju vardikliu išlieka vertingiausių vartotojų skatinimas išlikti lojaliais ir aktyviais įmonės klientais.
CRM dalys
Santykių su klientais valdymas panaudojant elektroninius komunikacijos kanalus – dažniausiai tai internetas (angl. electronical CRM – eCRM). Pavyzdžiui, naudojantis eCRM sistema, prisijungus prie interneto galima patikrinti, kurioje pasaulio vietoje šiuo metu yra jūsų laukiama pašto siunta.
Santykių su partneriais valdymas (angl. partner relationship management, PRM). Leidžia įmonei efektyviau valdyti santykius su savo prekybos partneriais. Pavyzdžiui, PRM sistema gali būti naudojama dinamiškai nustatant marketingo partneriams teikiamų nuolaidų ir premijų dydžius, priklausomai nuo kiekvieno partnerio atsiunčiamų klientų pelningumo.
Bendradarbiavimu besiremiančio CRM modelis (angl. community CRM ,cCRM). Taip kartais žymimos
49
interneto technologijomis paremtos sistemos, leidžiančios klientams tiesiogiai keistis informacija su įmone.
Santykių su tiekėjais valdymas (angl. supplier relationship management, SRM). Taip vadinamos į PRM panašios sistemos, kurių tikslas nukreiptas į įmonės tiekėjus. SRM sistemos padeda įmonėms optimizuoti tiekėjų pasirinkimo procesą, sudarydamos galimybes patogiau ir greičiau įvertinti ir kategorizuoti linkusias bendradarbiauti kompanijas. Taip padidinamas tiekimo grandinės efektyvumas.
„Mobilusis CRM” (angl. mobile CRM, mCRM), kuomet sistema suteikia galimybę įmonės klientams, partneriams ir tiekėjams pateikti duomenis per mobiliuosius telefonus ir kitokius mobiliuoju ryšiu aprūpintus įrenginius (Kamarauskienė 2009).
Apibendrinimas
CRM sistemos daro labai didelę įtaką, norint efektyviai spręsti verslo valdymo problemas. Nors ši sistema palengvina sprendimų priėmimus, tačiau ją įdiegiant, reikalingi pasikeitimai pačiame įmonės valdyme, sutelkiant dėmesį į klientą.
− Įdiegus CRM sistemą, pasiekiama akivaizdi nauda:
− Padidėja darbo efektyvumas;
− Išauga pardavimų sparta;
− Sutaupomi kaštai;
− Investicijos tampa pelningesnės;
− Padidėja klientų skaičius.
Manoma, kad CRM bus vis dažniau naudojama ateityje, nes suteikia galimybę įmonėms įgyti konkurencinį pranašumą rinkoje.
Padėkos
Dėkojame prof. G. Kulviečiui bei Fundamentinių mokslų fakultetui (FMF) už pagalbą rengiant straipsnį.
Literatūra
Customer Relationship Management. [interaktyvus]. 2008.
[žiūrėta 2009a Vasario 23 d.] Prieiga per internetą: <http://www.crm.com>
Customer Relationship Management. [interaktyvus]. 2009. [žiūrėta 2009b Vasario 15 d.] Prieiga per internetą:
<http://crm.manufacturer-supplier.com> Kamarauskienė S. 2005. Kompiuterizuota apskaita.
[interaktyvus]. 2009. Šiaulių Universitetas [žiūrėta 2009 Vasario 16 d.] Prieiga per internetą:
<http://smf.su.lt/kamarauskiene/kompiuterizuota_apskaita/apskaita/turinio_lapas.htm>
Kirvaitis A. 2008. „CRM iššūkis: veidu į klientą“. Iš NK Verslas 2: 12–15.
Organizacijų Kompiuterinių Sistemų Laboratorija. Įmonių informacinių technologijų paskaitų medžiaga: Santykių su vartotojais valdymas. [interaktyvus]. 2009. [žiūrėta 2009 Vasario 16 d.] Prieiga per internetą:
<http://www.oksl.ktu.lt/studijos/T120B120/IIT_12%20paskaita.ppt>
CRM – CUSTOMER RELATIONSHIP MANAGEMENT
M. Černiauskas, R. Glodenytė
Summary
In this article is reviewed CRM possibilities, features and the efficiency of this product, for getting competitive advantage in market. Named main factors, which are needed to create effective clients management strategy. Analyzed implementation benefit of this product to companies system. Also shortly discussed CRM parts and types, it’s advantages and disadvantages.
50
2 Priedas
UAB „Exigen Services Lietuva“ Ulonų g. 2, LT-08245 Vilnius
biuro tel.: +370 5 2754605, faks.: +370 5 2754604 biuro el. paštas: [email protected]
Baigiamojo magistro darbo
praktinis panaudojimas įmonėje
Baigiamasis magistro darbas „Testų kūrimo proceso optimizavimas“, kurį atliko
Romualda Glodenytė, buvo peržiūrėtas ir dalis jo buvo pritaikyta praktinėje mūsų įmonės
veikloje.
Direktorius Tomas Vaičiūnas