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. mindaugas.cerniauskas@gmail.com; rglodenyte@gmail.com

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: vilnius@exigenservices.com

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