RAAMLEPING NR 3-9/2313-1
Testimisteenus
Tervise ja Heaolu Infosüsteemide Keskus, registrikoodiga 70009770, aadressiga Uus-
Tatari 25, Tallinn 10134, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi
tellija) ja
Osaühing ASA Quality Services, registrikoodiga 11045744, aadressiga Ehitajate tee 108,
Tallinn 12915, keda esindab juhatuse liige Kert Suvi (edaspidi täitja).
edaspidi nimetatud ka eraldi pool või koos pooled, sõlmisid raamlepingu (edaspidi nimetatud
raamleping ning koos hankelepinguga ka leping) alljärgnevas:
1. Lepingu ese ja eesmärk
1.1. Tellija poolt korraldatud riigihanke “Testimisteenus” (riigihanke viitenumber 220288)
alusel sõlmitud raamlepingu eesmärk on kokku leppida, kuidas toimub raamlepingu
kehtivuse ajal raamlepingu esemeks olevate tööde tellimiseks hankelepingute
sõlmimine tellija ning raamlepingu partnerite vahel.
1.2. Raamlepingu esemeks on tellija poolt hallatavate infosüsteemide ja nende liideste
manuaalse ja automatiseeritud testimise teenust tervise-, sotsiaalkaitse- ja
töövaldkonna arendustööde vastuvõtutestimiseks (edaspidi nimetatud ka töö), mida
täitja kohustub teostama lähtudes raamlepingu alusel sõlmitud hankelepingus kokku
lepitud tingimustest. Teostatavad tööd on toodud tehnilises kirjelduses.
1.3. Raamleping ei kohusta tellijat töid tellima.
1.4. Leping jõustub sõlmimise hetkel ja kehtib 24 kuud. Lepingu alusel sõlmitavad
hankelepingud peavad olema sõlmitud raamlepingu kehtivuse ajal, kuid võivad kehtida
kauem.
2. Üldtingimused
2.1. Raamlepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja
riigihanke alusdokumendid ning täitja riigihankes esitatud pakkumus ja
pooltevahelised kirjalikud teated, mida raamlepingu lisadena eraldi ei allkirjastata.
2.2. Täpsed tööde teostamise tingimused lepitakse kokku hankelepingutes.
Välisrahastusega projektide raames sõlmitavates hankelepingutes lepitakse vajadusel
kokku vastava rahastuse eritingimused.
2.3. Kui hankelepingu tingimus erineb raamlepingu tingimusest, loetakse ülimuslikuks
hankelepingu tingimus.
2.4. Kui hankelepingu alusel teostatavaid töid rahastatakse välisvahenditest, on täitjal
kohustus järgida hankelepingus teatavaks tehtud välisvahendite kasutamisest
tulenevaid nõudeid, sh kasutada programmi tingimustes nõutud sümboolikat.
2.5. Pooled teevad raamlepingu ja selle alusel sõlmitud hankelepingute täitmiseks ja
nende eesmärkide saavutamiseks koostööd. Pooled kohustuvad tegema kõik
vajalikud pingutused, et täita hankeleping õigeaegselt ja vastavalt kokkulepetele.
2.6. Täitja kohustub teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele
ja praktikale. Tellija eeldab, et täitja on oma valdkonna professionaal, kes saab aru
ning võtab teadlikult enda kanda hankelepingu funktsionaalsete ja
mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest
tulenevalt laieneb täitjale ka selliste tööde tegemise kohustus, mida ei ole
hankelepingus kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad
hankelepinguga seotud tööde hulka. Nimetatud tööde tegemine ei kuulu eraldi
tasustamisele ning täitja teostab kirjeldatud tööd hankelepingu täitmise raames.
2.7. Kui tööde teostamisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse
hankelepingu eesmärkidest tellija seisukohalt.
2.8. Poolel on õigus teha teisele poolele ettepanekuid hankelepingute täitmise kvaliteedi
tõstmiseks. Kui pool on esitanud teisele poolele hankelepingu täitmisega seotud
küsimuses päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast
tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul, v.a juhul kui
pöördumine nõuab täiendavat analüüsi või info süstematiseerimist.
2.9. Pooltel on kohustus osa võtta töökoosolekutest töö käigus tekkinud probleemide
lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt.
Töökoosolekutel osalemist tellija ei tasusta, v.a juhul, kui hankelepingus on kokku
lepitud teisiti.
2.10. Tööde teostamise keel on eesti keel, muuhulgas on see ka hankelepingute
sõlmimise, töökoosolekute jm suhtluse ning tööde dokumenteerimise keel.
2.11. Nõuded dokumentatsioonile ja kasutusjuhenditele tulenevad tehnilisest
kirjeldusest.
2.12. Pooled võivad kokkuleppel kaasata tööde kvaliteedi või tööde vastuvõtmise
hindamiseks mõlema poole poolt aktsepteeritud sõltumatu eksperdi või audiitori. Kui
tellija hinnang tööde kvaliteedile või tööde vastuvõtmisele osutub ekspertiisi tulemusel
põhjendamatuks, hüvitab tellija ekspertiisikulud. Kui ekspertiis kinnitab tellija
hinnangut kvaliteedile või tööde vastuvõtmisele, jäävad ekspertiisikulud täitja kanda.
3. Poolte õigused ja kohustused
3.1. Täitja kohustub:
3.1.1. teostama tööd hankelepingus kokkulepitud tingimustel ja ulatuses, sh tagama
tööde õigeaegse alustamise, teostamise, valmimise ja tellijale üleandmise;
3.1.2. tagama hankelepingu täitmiseks vajalike ressursside olemasolu, tööde
teostajate kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate
väga hea tundmise, omama tööde teostamiseks sobivaid keskkondi, koos kõige
sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid, või kasutama tellija
olemasolevaid jagatud keskkondi;
3.1.3. tegema koostööd kolmandate osapooltega pidades silmas tellija vajadusi (nt
äritellijaga, tellija arenduspartneritega jne);
3.1.4. teavitama viivitamatult tellijat tööde teostamist takistavatest asjaoludest, mis
segavad hankelepingu nõuetekohast täitmist;
3.1.5. juhinduma tellija suunistest ja eeskirjadest lepingu eesmärkide saavutamisel,
pöördudes selleks vajadusel tellija poole;
3.1.6. kasutama tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on täitjale
kättesaadavaks tehtud;
3.1.7. töötunni põhiselt tellitavate tööde puhul esitama tellijale tööde teostamise
ajaaruandeid (iga meeskonnaliige isiklikult);
3.1.8. teavitama kirjalikku taasesitamist võimaldavas vormis oma mistahes huvist, mis
võib põhjustada lepingu täitmisel huvide konflikti tekkimist.
3.2. Täitjal on õigus:
3.2.1. saada tööde teostamise eest hankelepingus kokkulepitud ulatuses ja korras
tasu;
3.2.2. kasutada tööde teostamisel alltöövõtjaid, kooskõlastades selle eelnevalt
kirjalikult tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees
täitja.
3.3. Tellija kohustub:
3.3.1. tasuma vastu võetud tööde eest kokkulepitud ulatuses ja korras;
3.3.2. tagama tööde teostamiseks täitjale ligipääsu vajalikule teabele ja
keskkondadele;
3.3.3. tagama tööde teostamiseks oluliste tellija hallatavate keskkondade olemasolu
ja toimimise.
3.4. Tellijal on õigus:
3.4.1. kontrollida igal ajal lepingu täitmist ja anda täitjale selleks kohustuslikke
suuniseid;
3.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud
nõuetekohaseid töid kokku lepitud tähtajaks ja täitja poolne rikkumine ei ole
objektiivselt põhjendatud;
3.4.3. kaasata lepingu täitmiseks tellija poolel kolmandaid osapooli, nt teisi riigiasutusi
töö eest maksja rollis. Kolmanda osapoole kaasamine tellija poolt ei ole käsitletav
raamlepingu muutmisena riigihangete seaduse mõttes.
4. Raamlepingu hind
4.1. Raamlepingu kehtivuse ajal on ühe töötunni maksimaalne hind käibemaksuta
vastavalt pakkumusele 39,00 (kolmkümmend üheksa) eurot. Täitjal ei ole lubatud
nimetatud hinda tõsta.
4.2. Raamlepingu maht on maksimaalselt 420 000 (nelisada kakskümmend tuhat) eurot
ilma käibemaksuta, mis summeeritakse kõikide täitjatega sõlmitud hankelepingute
alusel.
4.3. Täitjal on õigus esitada e-arve pärast tööde üleandmise-vastuvõtmise aktiga (edaspidi
akt) vastu võtmist, kui hankelepingus ei ole kokku lepitud teisiti. Arvel tuleb märkida
riigihanke nimetus, raamlepingu number, minikonkursi number, kui see on võimalik
ning kontaktisiku andmed.1
4.4. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates arve
laekumisest.
4.5. Tellijal on õigus kaasata lepingusse kolmas osapool maksja rollis, mis märgitakse
hankelepingus.
1 Välisriigi pakkujad võivad esitada arve pdf-vormingus aadressil
[email protected], kui e-arve esitamine ei
ole võimalik.
5. Täitja meeskond
5.1. Hankelepingu täitmisel osalevad minikonkursil pakkumuses esitatud
meeskonnaliikmed, v.a juhul, kui täitjast mittesõltuval asjaolul ei ole seda võimalik teha
ja meeskonnaliige on asendatud tellija kirjalikku taasesitamist võimaldaval nõusolekul
uue, hanke tingimustele vastava meeskonnaliikmega.
5.2. Täitja asendab tellija nõudmisel ja määratud tähtajaks meeskonnaliikme, kui isik
osutub tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks
ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine
kahjustab pidevalt lepingu täitmist. Täitja kannab kõik asendusega kaasnevad kulud.
5.3. Täitja võib tellija kirjalikku taasesitamist võimaldaval nõusolekul kaasata täiendavaid
meeskonnaliikmeid, kui riigihankes pakkumusega esitatud meeskonnaliikmed on
tellitud tööde täitmisega hõivatud. Täiendavad meeskonnaliikmed peavad vastama
hanke tingimustele.
5.4. Täitja garanteerib riigihankes isikuliselt mitte välja toodud meeskonnaliikmete
olemasolu ja vastavuse riigihankes nõutud kvalifikatsioonile/varasemale
töökogemusele ning esitab tööde teostajad nimeliselt hankelepingu sõlmimisel.
6. Tööde tellimine
Kohaldatakse juhul, kui raamleping sõlmitakse kahe partneriga (ning eemaldatakse
alltoodud ühe partneriga töö tellimise punktid):
6.1. Tööde teostamise aluseks on sõlmitud hankeleping.
6.2. Tellija korraldab minikonkursse kahe raamlepingu partneri olemasolul vastavalt
tegelikule vajadusele ning raamlepingu partnerid peavad olema valmis võimalike
ajaliste pauside tekkimiseks tööde tellimise vahel.
6.3. Lepingu sõlmimiseks esitab tellija raamlepingu partneritele kirjalikku taasesitamist
võimaldavas vormis ettepaneku pakkumuse esitamiseks (korraldab minikonkursi) ja
annab mõistliku aja pakkumuse esitamiseks, arvestades tööde keerukust ja
pakkumuse esitamiseks vajalikku aega. Pakkumusega koos tuleb esitada ka
testiplaan ja pakkuja meeskonnaliikmete CV juhul, kui seda ei ole esitatud
raamlepingu sõlmimiseks korraldatud hankes.
6.4. Sõlmitava hankelepingu tehnilises kirjelduses määrab tellija tööde sisu ja üle antavad
tulemid (tööde loetelu), võimalusel tööde mahu, ajalised ja eelarvelised piirangud,
etapid jm olulised tingimused.
6.5. Minikonkursi läbiviimisel valib tellija majanduslikult soodsaima pakkumuse järgnevalt:
6.5.1. Hankeleping, mille eeldatav maksumus on väiksem kui 35 000 eurot km-ta ja/või
kestvus kuni 3 kuud:
6.5.1.1. Madalaim kogumaksumus 100%;
6.5.2. Hankeleping, mille eeldatav maksumus on rohkem kui 35 000 eurot km-ta ja/või
ajaline kestvus kauem kui 3 kuud:
6.5.2.1. Kogumaksumuse osakaal vahemikus: 30 – 50%;
6.5.2.2. Proovitöö, mis võtab hinnanguliselt aega 1-5 päeva: osakaal vahemikus:
50 - 70%.
6.6. Tellijal on õigus küsida vajadusel täiendavaid kinnitusi ja andmeid tööde osutamiseks
vajalike eelduste olemasolu kohta.
6.7. Pakkumuse esitamisel tuleb järgida kõiki minikonkursi nõudeid ja tingimusi. Tellija
ootab täitjalt võimekust leida lahendusi etteantud piirangute kontekstis.
6.8. Tellija avab pakkumused pärast minikonkursi kutses määratud tähtaega ja hindab
kõiki nõuetele vastavaid pakkumusi, milles ei esine sisulisi kõrvalekaldumisi
minikonkursi tingimustest, teatavaks tehtud hindamiskriteeriumite ja -metoodika
alusel. Tellija ei hinda pakkumusi, mis ei vasta minikonkursi tingimustele.
6.9. Kui pakkumus ei vasta minikonkursi tingimustele, lükatakse see tagasi.
6.10. Tellijal on õigus enne hankelepingu sõlmimist tunnistada minikonkurss omal
algatusel põhjendatud vajadusel kehtetuks, teavitades sellest raamlepingu partnereid.
6.11. Tellijal on õigus pakkumus tagasi lükata ja otsustada hankelepingut mitte
sõlmida või vastavalt raamlepingule minikonkurss kehtetuks tunnistada, kui:
6.11.1. pakkumus(ed) ei vasta tingimustele;
6.11.2. pakkumus(ed) ületavad eeldatavat maksumust;
6.11.3. tellija ei saa välisvahenditega seotud hankelepingu sõlmimiseks heakskiitu
täistaotlusele.
6.12. Tellija sõlmib hankelepingu tööde teostamiseks eduka pakkujaga vastavalt
minikonkursi tingimustele ning teavitab minikonkursi tulemusest raamlepingu
partnereid. Täitja kohustub hankelepingu allkirjastama esimesel võimalusel,
soovituslikult 3 tööpäeva jooksul hankelepingu allkirjastamiseks saatmisest.
7. Tööde üleandmine ja vastuvõtmine
7.1. Hankelepingus määratakse vajadusel tööde üleandmise ja vastuvõtmise
eritingimused, nõuded testimisele, tööde teostamise etapid, kord, tähtajad, sh
testimise tähtajad või muud tööde teostamiseks vajalikud kokkulepped.
7.2. Täitja annab tööd üle hiljemalt hankelepingus kokkulepitud tähtaegadel ja tingimustel.
Koos töödega antakse üle nõuetekohane dokumentatsioon, intellektuaalomandi
õigused ja muu hankelepingus kokkulepitu.
7.3. Tööde tulemused ja vajadusel tööde teostamise käik dokumenteeritakse ning
hallatakse tellija dokumendihalduskeskkonnas ja/ või koodihalduskeskkonnas (näiteks
wiki, gitlab, SVN).
7.4. Täitja annab tööd üle omalt poolt allkirjastatud aktiga.
7.5. Pärast töö üleandmist, on tellijal õigus töö omalt poolt mõistliku aja jooksul üle vaadata
ja veenduda selle hankelepingu tingimustele vastavuses. Seejärel allkirjastab tellija
akti.
7.6. Tööd loetakse nõuetekohaselt teostatuks, kui tööd vastavad hankelepingule ja tööd
on aktiga tellija poolt vastu võetud.
7.7. Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi
pisivigasid, mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei
vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellijal
määrab mõistliku tähtaja pisivigade parandamiseks.
7.8. Tellijal on õigus keelduda tööde vastuvõtmisest kui tööd ei vasta esitatud nõuetele või
töödes esineb muid vigu.
7.9. Kui tellija esitab vastuväited töödele, peab täitja tööd parandama tellija poolt määratud
mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud
avastatud vigu, võib tellija tööd ise parandada või lasta seda teha kolmandatel isikutel
ja nõuda täitjalt selleks tehtud mõistlike kulutuste hüvitamist.
7.10. Pärast töö lõpetamist ja selle nõuetekohast üleandmist kohustub täitja hävitama
tema valduses oleva konfidentsiaalse teabe.
8. Intellektuaalne omand
8.1. Täitja kinnitab raamlepingu ja selle alusel sõlmitud hankelepingute allkirjastamisega,
et talle kuuluvad tööde teostamiseks vajalikud autoriõigused, litsentsid ja muud
intellektuaalse omandi õigused, mis on vajalikud raamlepingu ja hankelepingute
järgsete tööde teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole
õigusi ega nõudeid kolmandatel isikutel.
8.2. Tasu intellektuaalse omandi õiguste loovutamise ja litsentsi andmise eest sisaldub
hankelepingu täitmise hinnas.
8.3. Täitja loovutab tellijale tööde teostamise käigus loodud kõik mistahes vormis tööde
osad, mis puutuvad tööde teostamisse, kõik autori varalised õigused ning annab
lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu
autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta tööde üleandmise
hetkest, loobudes sellega hankelepingu alusel üle antud originaalteoste osas õiguste
kasutamisest.
8.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas
järgnevas ulatuses:
8.4.1. tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil;
8.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes
muudatusi ning neid täiendada;
8.4.3. tellijal või tellija tellimusel kolmandatel isikutel on õigus teostatud töid muuta või
töödele lisada tellija või kolmandate isikute poolt loodud töid;
8.4.4. tööde üleandmisega tellijale kinnitab täitja, et tööd on üldsusele avaldamiseks
valmis.
8.5. Täitja tagab tellijale kõik vajalikud õigused hankelepingu täitmise käigus loodava töö
kontrollimiseks ka ajal, mil tööd on vastuvõtutestimiseks üle antud, kuid ei ole veel
tellija poolt aktiga vastu võetud.
8.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste)
olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal
hankelepingu lõppedes üle võtta täitja teostatud töö ja dokumentatsiooni.
8.7. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete töödega seotud
intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma
töötajate või koostööpartneritega, v.a. juhul, kui tarkvara või tarkvara osa litsentside
soetamise kohustus oli tellijal või kolmandal osapoolel. Juhul, kui eeltoodust tekib
tellijale rahaline või muu kohustus või juhul, kui tellija on kohustatud lõpetama
hankelepingu alusel teostatud ja vastuvõetud tööde kasutamise, on tellijal õigus nõuda
täitjalt sellega kaasneva rahalise või muu kohustuse täitmist ja/või samaväärse töö
loomist ilma täiendavat tasu nõudmata võimalikult lühikese aja jooksul, hoidudes
mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja kasutamises tellija
poolt.
8.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et
kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest
omandist tulenevaid õigusi hankelepingu alusel üle antavate intellektuaalse omandi
objektide suhtes, kannab täitja.
8.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks
pärast töö vastuvõtmist.
9. Garantii
9.1. Täitja annab hankelepingu alusel teostatud töödele garantii 12 kuud. Garantii hakkab
kehtima hetkest, millal tellija on töö vastu võtnud.
9.2. Garantiiga on hõlmatud kõik garantii tähtaja jooksul töös ilmnevad vead ja
mittevastavused, mis ei ole tekkinud tellija või kolmandate osapoolte tegevuse
tagajärjel. Garantiiga on hõlmatud ka kõigi tööde muudatused ja modifikatsioonid, mis
on tehtud täitja poolt ja mis ei ole oluliselt muutnud varasemalt tehtud tööd.
9.3. Täitja kõrvaldab garantii kehtivuse ajal töödes avaldunud vead ja mittevastavused
tasuta, sealhulgas uuendab või asendab kõik seonduvad dokumendid.
9.4. Kui täitja tõendab, et kõrvaldatud viga ei olnud garantiiga hõlmatud, hüvitab tellija täitja
kantud otsesed kulud seoses nimetatud vea kõrvaldamisega. Kulude hüvitamisel
võetakse aluseks hankelepingus, mille raames teostatud töödes on viga ilmnenud,
fikseeritud tööde teostamise ühe töötunni hind.
9.5. Tellija tagab täitjale kaasabi garantiikohustuse alla käivate vigade kõrvaldamisel tellija
võimekuse ja võimaluste piires.
9.6. Kui täitja ei suuda vigasid kokkulepitud tähtajaks kõrvaldada, võib tellija nimetatud ise
kõrvaldada või korraldada nende kõrvaldamise kolmanda isiku kaasabil, teavitades
sellest täitjale. Tellijal on õigus täitjalt nõuda kõigi kulutuste hüvitamist, mis tekkisid
seoses eelkirjeldatud viisil vea kõrvaldamisega, kui tegemist oli garantiiga hõlmatud
veaga.
10. Vastutus
10.1. Pool vastutab oma lepingulise kohustuse rikkumise eest, välja arvatud juhul, kui
rikkumine on vabandatav vääramatu jõu või muu objektiivse asjaolu tõttu. Nimetatud
asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib.
10.2. Pool vastutab oma lepingulise kohustuse rikkumise eest, mis tuleneb
hankelepingu täitmisse kaasatud isikute tegevusest.
10.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole
kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Kui
tellija viivitab omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne
täitmine ei võimalda täitjal omapoolseid kohustusi tähtaegselt täita, pikendatakse
tööde üleandmise tähtaega vastava aja võrra. Nimetatud asjaolu esinemist peab
tõendama pool, kes sellele tugineda soovib.
10.4. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või
lepingust tulenevaid õiguskaitsevahendeid vastavalt võlaõigusseadusele.
10.5. Poolte rahaline koguvastutus on piiratud raamlepingu kogumaksumusega, kuid
nimetatud piirang ei kehti süülise rikkumise, intellektuaalomandiõiguse või
andmekaitsealaste kohustuste rikkumisel.
10.6. Tasu maksmisega viivitamisel on täitjal õigus nõuda viivist võlaõigusseaduses
sätestatud määras konkreetse töö eest maksmisele kuuluvast tasust iga tasumisega
viivitatud kalendripäeva eest. Viivise maksimaalne määr on 25% konkreetse töö eest
tasumisele kuuluvast kogusummast. Täitja esitab viivise nõude tellijale allkirjastatult
vähemalt kirjalikku taasesitamist võimaldavas vormis.
10.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda,
kus üle antud tööd ei vasta osaliselt või täielikult lepingu tingimustele või esineb muid
täitja poolseid lepingu rikkumisi.
10.8. Kui täitja rikub lepingulist kohustust, on tellijal õigus nõuda leppetrahvi tasumist,
mille suuruseks on 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte
rohkem kui 25% hankelepingu kogumaksumusest. Kui tööde teostamine on kokku
lepitud etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest.
10.9. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue
10 000 eurot iga rikkumise eest. Täitja poolse olulise hankelepingu rikkumise korral ei
pea tellija määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud
täiendavat tähtaega ning tellijal on muu hulgas õigus hankeleping üles öelda või
hankelepingust taganeda.
10.10. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses sätestatule
muuhulgas:
10.10.1. mõjuva põhjuseta hankelepingu sõlmimata jätmine või täitmisele mitte
asumine;
10.10.2. valeinfo esitamine;
10.10.3. hankelepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid,
intellektuaalse omandi õigused) puudumine;
10.10.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste
rikkumine;
10.10.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga,
kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija
eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta;
10.10.6. konfidentsiaalsuskohustuse rikkumine;
10.10.7. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata
jätmist;
10.10.8. tähtaegselt tööde teostamata jätmist selliselt, et tehnilises kirjelduses
sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse
tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada hankelepingu
rahastamiseks ettenähtud vahendeid;
10.10.9. lepingujärgsete kohustuste üleandmine kolmandale isikule ilma tellija
digiallkirjastatud nõusolekuta.
10.11. Töö vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu
rikkumise eest.
10.12. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte
hiljem kui 3 kuu jooksul alates päevast, mil tellija sai teadlikuks leppetrahvi nõude
aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta täitjat selle
maksmise kohustusest enne vastava kohtuotsuse jõustumist.
10.13. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt
vastava nõude esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti.
10.14. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest
tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi
tasumise kohustust.
11. Konfidentsiaalsuskohustus
11.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele
isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud
teiselt poolelt raamlepingu alusel sõlmitud hankelepingute alusel tehtavate tööde
teostamise käigus või muul viisil või juhuslikult.
11.2. Täitja peab võtma kasutusele isikuandmete ja tellija infosüsteemide kaitseks
organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas
kehtivatest õigusaktidest. Täitja ei tohi töödelda reaalseid ja isikustatud andmeid.
11.3. Pooled sõlmivad vajadusel isikuandmete töötlemise olukordade
reguleerimiseks iga hankelepinguga Isikuandmete töötlemise lepingu, juhindudes
isikuandmete kaitse üldmääruse2 artiklis 28 kirjeldatust.
11.4. Konfidentsiaalse informatsiooni all mõistavad pooled igasugust informatsiooni
(sh ärisaladusi, isikuandmeid, lepingute andmeid, infosüsteeme, turvasüsteemide
kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid
tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses tööde teostamisega ja
mille sattumine kolmandate isikute kätte võib pooltele põhjustada turvariske või
majanduslikku kahju või kolmandate isikute (eelkõige tellija klientide) eraelu
puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust.
11.5. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille
avalikustamise kohustus tuleneb õigusaktidest või mille avalikustamiseks pooled on
andnud nõusoleku.
11.6. Täitjal puudub volitus tegeleda raamlepingu osas avalike suhetega ning anda
teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele,
välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul.
11.7. Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele
isikutele, kes on tellitud tööde täitmisega otseselt seotud. Täitja kohustub tagama, et
isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse
kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja
tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub täitjal.
11.8. Pooled ei kasuta raamlepingu täitmisel neile teatavaks saanud konfidentsiaalset
informatsiooni oma huvides ega muul eesmärgil, kui tellitud tööde teostamiseks.
11.9. Konfidentsiaalsuskohustus jääb kehtima tähtajatult, ka raamlepingu ja
raamlepingu alusel sõlmitud hankelepingute lõpetamise või lõppemise järgselt.
11.10. Täitja on teadlik, et raamleping ning raamlepingu alusel sõlmitud hankelepingud
ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel
alustel määratud asutusesiseseks kasutamiseks või märgitud täitja poolt
ärisaladuseks.
11.11. Konfidentsiaalsuskohustuse rikkumise korral kohustub täitja hüvitama kõik
kahjud, mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid,
sõltumata sellest, kas rikkumine pandi toime hankelepingu kehtivuse ajal või
lepinguliste kohustuste lõppemise järgselt.
12. Raamlepingu kehtivus, muutmine ja lõpetamine
12.1. Raamleping jõustub sõlmimise hetkel ja kehtib 24 kuud või raamlepingu
lõpetamiseni või raamlepingu mahu täitumisel. Hankelepingud tuleb sõlmida
raamlepingu kehtivuse ajal, kuid võivad kehtida kauem.
12.2. Raamlepingut muudetakse pooltevahelise kirjaliku kokkuleppega
raamlepinguga samas vormis.
12.3. Raamlepingu mingi sätte muutmine või tühistamine poolte kokkuleppel ei too
kaasa ülejäänud raamlepingu punktide muutumist või tühistamist.
2 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679.
12.4. Tellija võib raamlepingu igal ajal ühepoolselt üles öelda, teatades täitjale 60
päeva ette. Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks selle alusel
varem sõlmitud hankelepinguid.
12.5. Tellijal on õigus raamleping ühepoolselt etteteatamistähtaega järgimata üles
öelda, kui täitja on oluliselt raamlepingut rikkunud või juhul, kui täitja
12.5.1. suhtes on algatatud pankrotimenetlus;
12.5.2. pankrot on välja kuulutatud;
12.5.3. täitja varad arestitakse;
12.5.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see
muudab hankelepingu nõuetekohase täitmise vähetõenäoliseks.
12.6. Täitja võib raamlepingu igal ajal ühepoolselt üles öelda, teatades tellijale
vähemalt 90 päeva ette. Raamlepingu ülesütlemine ei muuda automaatselt kehtetuks
selle alusel varem sõlmitud hankelepinguid.
12.7. Lepingu lõppemisel mistahes alusel ja põhjusel on täitja kohustatud tellijale üle
andma kogu tööga seotud informatsiooni ja dokumentatsioon (nii digitaalselt kui
paberkandjal, samuti informatsiooni, mida ei ole salvestatud eelnimetatud
infokandjatele). Üleantav info ja dokumentatsioon peab olema süstematiseeritud.
Täitja on kohustatud andma ammendavad selgitused eelkirjeldatud informatsiooni
haldamise ja kasutamise kohta, tehes seda tellija nõudmisel kirjalikult
13. Teadete edastamine ja kontaktisikud
13.1. Teadete edastamine toimub üldjuhul e-posti teel. Juhul, kui teate edastamisel
on olulised õiguslikud tagajärjed, peab teade olema edastatud digiallkirjastatult poole
allkirjaõigusliku isiku poolt. Informatiivset teadet võib edastada ka telefoni teel.
Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi.
13.2. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja
vastu või kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud
aadressil ja postitamisest on möödunud 5 kalendripäeva. E-posti teel, sh digitaalselt
allkirjastatud dokumentide, saatmise korral loetakse teade kättesaaduks kohale
jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal.
13.3. Tellija kontaktisik(ud) on: Bret Rand, üldtelefon +372 7943900, e-post:
[email protected] või tema asendaja.
13.4. Täitja kontaktisik(ud) on: juhatuse liige Kert Suvi, telefon 5245087, e-post:
[email protected] või tema asendaja.
13.5. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja
juhiseid oma pädevuse piires, kontrollida teostatud töö kvaliteeti, anda töö üle ja võtta
töö vastu ning allkirjastada akt.
13.6. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult.
14. Lõppsätted
14.1. Raamlepingu alusel sõlmitud hankelepingutele kohalduvad raamlepingu
tingimused, olenemata raamlepingu kehtivusest.
14.2. Täitjal ei ole õigust raamlepingut või sellest tulenevaid kohustusi kolmandatele
isikutele üle anda, välja arvatud tellija digiallkirjastatud nõusolekul riigihangete
seaduses ette nähtud alustel. Kolmas isik on mistahes füüsiline või juriidiline isik, kes
ei ole selle raamlepingu pooleks.
14.3. Raamlepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste
teel lahendada, antakse lahendamiseks Harju Maakohtule.
14.4. Raamlepingule kohaldub Eesti õigus. Kuivõrd tegemist on segatüüpi lepinguga,
siis lisaks üldistele lepingulistele õiguskaitsevahenditele tuleb arvestada ka seadusest
tulenevaid õiguskaitsevahendeid, mida kasutatakse vastavalt rikkumise olemusele
kas VÕS peatükk 35 või 36 alusel.
14.5. Raamlepinguga reguleerimata küsimustes või olukorras, kus mõni lepingu säte
on vastuolus seadusega, lähtutakse Eesti Vabariigis kehtivast seadusandlusest
15. Lisad
15.1. Lisa 1 – Tehniline kirjeldus;
15.2. Lisa 2 – Hankeleping;
15.3. Lisa 3 – Üleandmise-vastuvõtmise akt;
Tellija: Täitja:
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
Katrin Reinhold Kert Suvi
Lisa 1
Tehniline kirjeldus
SISUKORD
1 Sissejuhatus .................................................................................................................. 3
1.1 Tellija tegutsemisvaldkond ...................................................................................... 3
1.2 Hangitav teenus ...................................................................................................... 3
2 Tarkvara testimisteenus ................................................................................................. 3
2.1 Tarkvara testimisteenuse kirjeldus .......................................................................... 3
2.1.1 Testimisjuhtimine ............................................................................................. 4
2.1.2 Arendaja testitulemite ülevaatus ...................................................................... 4
2.1.3 Nõuete läbivaatamine ...................................................................................... 4
2.1.4 Testianalüüs .................................................................................................... 5
2.1.5 Testidisain ....................................................................................................... 5
2.1.6 Testilugude põhine testimine ........................................................................... 5
2.1.7 Andmeväljade valideerimine ............................................................................ 5
2.1.8 Automaattestimine ........................................................................................... 5
2.1.9 Veaolukordade testimine ................................................................................. 6
2.1.10 Suitsutestimine ................................................................................................ 6
2.1.11 Liidese testimine .............................................................................................. 6
2.1.12 Integratsiooni testimine .................................................................................... 6
2.1.13 Süsteemitestimine ........................................................................................... 7
2.1.14 Funktsionaalsete nõuete testimine ................................................................... 7
2.1.15 Regressioontestimine ...................................................................................... 7
2.1.16 Uurimuslik testimine ......................................................................................... 7
2.1.17 Kasutatavuse testimine .................................................................................... 8
2.1.18 Robustsuse testimine....................................................................................... 8
2.1.19 Jõudlustestimine .............................................................................................. 8
2.1.20 Koormustestimine ............................................................................................ 8
2.1.21 Stressitestimine ............................................................................................... 9
2.1.22 Mitte-funktsionaalsete nõuete testimine ........................................................... 9
2.1.23 Andmemigratsiooni testimine ........................................................................... 9
2.2 Nõuded testimise dokumentatsioonile ja nende vastuvõtukriteeriumid .................... 9
2.2.1 Testiplaan ...................................................................................................... 10
2.2.2 Täiendusettepanekud alusdokumentide (nõuete) osas .................................. 10
2.2.3 Testlood ......................................................................................................... 10
2.2.3.1 Nõuded testiloo sisule ............................................................................. 11
2.2.3.2 Nõuded testloo andmetele ...................................................................... 11
1
Lisa 1
2.2.3.2.1 Nõuded testloo prioriteetidele .............................................................. 11
2.2.4 Testandmed ................................................................................................... 11
2.2.5 Automaattestide skriptid ................................................................................. 12
2.2.6 Vigade raporteerimine.................................................................................... 12
2.2.6.1 Nõuded vigade raporteerimise formaat ................................................... 12
2.2.6.2 Nõuded vigade prioriteedid ..................................................................... 12
2.2.7 Testiraport ..................................................................................................... 12
2.2.7.1 Põhjalik testiraport .................................................................................. 13
2.2.7.2 Perioodiline põhjalik testiraport ............................................................... 13
2.2.7.3 Lõplik testiraport ..................................................................................... 13
2.3 Tarkvara testimises kasutatavad tööriistad ........................................................... 13
3 Töökorraldus ................................................................................................................ 13
3.1 Üldine ................................................................................................................... 13
3.2 Täitja poolt teostatavad tööd .................................... Error! Bookmark not defined.
2
Lisa 1
1 Sissejuhatus
1.1 Tellija tegutsemisvaldkond
Tervise ja Heaolu Infosüsteemide Keskus (TEHIK, edaspidi ka tellija) on 1. jaanuaril 2017.a
tegevust alustanud kompetentsikeskus, mis tegeleb IKT teenuste arendamise ja haldamisega
tervise-, sotsiaalkaitse- ja töövaldkonnas Sotsiaalministeeriumi valitsemisalas, kasutades
muuhulgas agiilseid arendusprotsesse nagu nt. Scrum, DevOps.
TEHIK on asutus, mille üks roll on dubleerivate infosüsteemide ja nende arendamisega seotud
kulude vähendamine Sotsiaalministeeriumi valitsemisalas. TEHIKu põhilised kliendid, kelle
tarbeks IKT teenuste tagamine ja arendamine toimub, on koos ministeeriumiga seitse asutust
– Ravimiamet, Sotsiaalkindlustusamet, Terviseamet, Tööinspektsioon, Astangu
Kutserehabilitatsiooni Keskus ja Tervise Arengu Instituut. Lisaks on TEHIKu klienditeks
kohalikud omavalitsused, kellele tuleb tagada andmevahetus tervise infosüsteemiga jpt.
1.2 Hangitav teenus
Hanke raames ostetakse tellija hallatavate infosüsteemide ja nende liideste manuaalse ja
automatiseeritud testimise teenust tervise-, sotsiaalkaitse- ja töövaldkonna arendustööde
vastuvõtmiseks. Leping sõlmitakse täitjaga kestusega 24 kuud ja lepingu eeldatav maht on
420 000 eurot.
2 Tarkvara testimisteenus
2.1 Tarkvara testimisteenuse kirjeldus
Täitja peab pakkuma järgnevaid teenuseid/ testimisliike:
1) Testimisjuhtimine (test manager) vt. 2.1.1;
2) Arendaja testitulemite läbivaatus (review of developer test results) vt. 2.1.2;
3) Nõuete läbivaatamine (requirements review) vt. 2.1.3;
4) Testianalüüs (test analysis) vt. 2.1.4;
5) Testidisain (test design) vt. 2.1.5;
6) Testilugude põhine testimine (test-based testing) vt. 2.1.6;
7) Andmeväljade valideerimine (validation of the data fields) vt. 2.1.7;
8) Automaattestimine (automatic testing) vt. 2.1.8;
9) Veaolukordade testimine (testing error situations) vt. 2.1.9;
10) Suitsutestimine (smoke test) vt. 2.1.10;
11) Liidese testimine (interface testing) vt. 2.1.11;
12) Integratsiooni testimine (integration testing) vt. 2.1.12;
13) Süsteemitestimine (system testing) vt 2.1.13;
14) Funktsionaalsete nõuete testimine (testing of functional requirements) vt. 2.1.14;
15) Regressioontestimine (regression testing) vt. 2.1.15;
16) Uurimuslik testimine (exploratory testing) vt. 2.1.16;
17) Kasutatavuse testimine (usability testing) vt. 2.1.17;
18) Robustsuse testimine (robustness testing) vt. 2.1.18;
19) Jõudlustestimine (performance testing) vt. 2.1.19;
20) Koormustestimine (load testing) vt. 2.1.20;
21) Stressitestimine (stress testing) vt. 2.1.21;
22) Mitte-funktsionaalsete nõuete testimine (testing of non-functional requirements) vt.
2.1.22;
23) Andmemigratsiooni testimine (data migration testing) vt. 2.1.23;
3
Lisa 1
Konkreetse tellimusega paneb tellija paika iga arendustöö testimise liigid, kuna kõikides
arendustes ei pruugi olla vajadust kaasata kõiki eelnevalt välja toodud testimise tegevusi.
2.1.1 Testimisjuhtimine
Testimisjuhtimise tegevused on arenduste testimisprotsessi planeerimine, hindamine,
jälgimine, kontrollimine, lõpetamine ja lõppkasutajate toetamine UAT testimises (user
acceptance testing).
Testimisjuhtimises tuleb lähtuda järgmistest nõuetest ning täitja:
1) Tagab kvaliteedi tagamise tegevused, mis on vastavuses tellija testimise strateegiaga
või kvaliteedijuhtimise strateegiaga ning jälgib, et erinevate testimise tegevusi tehakse
kvaliteetselt, kui täitjale on nimetatud dokument teatavaks tehtud.
2) Planeerib arenduste testimisprotsessi ehk planeerib erinevaid testimise tegevusi.
3) Hindab arenduste testimisprotsessi ehk hindab erinevaid testimise tegevusi.
4) Jälgib arenduste testimisprotsessi, mis tagab, et erinevad testimise tegevused tehakse
õigeaegselt ja kvaliteetselt.
5) Testimisjuhtimises on vaja arenduste testimisprotsessi kontrollida ehk kontrollida
erinevate testimise tegevusi tehakse kvaliteetselt.
6) Peab toetama lõppkasutajat UAT testimises ehk kliendi (lõppkasutaja) poolne
funktsionaalne testimine kontrollimaks arendatud ja/või muudetud funktsionaalsuse
korrektset toimimist. Eduka läbimise tulemina annab tellija aksepti vastava
funktsionaalsuse vastavuse osas tellitule.
7) Lõpetab arenduste testimisprotsessi tegevusi ehk tellijaga on kokkulepitud testimise
tegevuste lõpetamise kriteeriumid ja millal loetakse testimise tegevused lõpetatuks.
2.1.2 Arendaja testitulemite ülevaatus
Arendaja testitulemite läbivaatusel tuleb täitjal veenduda, et kõik arendaja poolt koostatud
testimisega seotud materjalid vastavad hankedokumentides püstitatud nõuetele. Kõik
kõrvalekaldumised tuleb fikseerida ning edastada tellijale. Täpsustatakse igakordses
tellimuses.
Osades projektides ja teenustes kasutatakse arendusprotsessi DevOps praktikana pidevat
integratsiooni (continous integration). Pidev integratsioon eeldab arendajalt pidevat testimist
(continous testing), mistõttu testide automatiseerimise osakaal kasvab.
Pideva integratsiooni praktika kasutamisel tuleb lähtuda järgmistest nõuetest:
1) Süsteemi arendaja poolt läbiviidud automaattestide unittestide ja funktsionaalsete
testide kaetvuse kontrollimine testkeskkonnas ja/või pre-live keskkonnas.
2) Süsteemi arendaja poolt läbiviidud automaattestimise tulemustega tutvumine,
testimise piisavuse hindamine testkeskkonnas ja/või pre-live keskkonnas.
2.1.3 Nõuete läbivaatamine
Nõuete läbivaatamise eesmärk on teada saada, kas arenduse äri- ja süsteeminõuded on
arendaja poolt piisavalt kirjeldatud ja on testitavad.
Nõuete läbivaatusel tuleb lähtuda järgnevatest nõuetest:
4
Lisa 1
1) Täitja testijuht osaleb tellija koosolekutel, kus analüüsidakse äri- ja süsteeminõudeid
ning täitja testijuht vastutus on kaasa rääkida, et nõudeid on piisavalt detailselt ja
testitavalt kirjeldatud.
2) Täitja testija kontrollib testilugude koostamisel, kas äri- ja süsteeminõuded on piisavalt
detailselt ja testitavalt kirjeldatud. Kui ei ole kirjeldatud, siis tuleb vastav info anda täitja
testijuhile, kes peab info edastama tellijale.
2.1.4 Testianalüüs
Testitingimuste väljaselgitamine, arvestades nõuete arhitektuuri, keskkondi, testistrateegiat,
testiplaani jms. testianalüüsi aluseks oleva informatsiooniga.
2.1.5 Testidisain
Testi disainimisel tuletatakse testitingimustest spetsiifilised testilood.
2.1.6 Testilugude põhine testimine
Testilugude põhist testimist teostatakse tellija ja täitja poolt kokkulepitud keskkonnas.
Testimisel tuleb läbida kõik tellimuses etteantud sammud ning fikseerida kõik
kõrvalkaldumised. Puuduste tuvastamisel tuleb veenduda, et testilugu on kooskõlas nõuete ja
analüüsidokumentidega.
2.1.7 Andmeväljade valideerimine
Andmeväljade valideerimine tehakse veendumaks, et andmeväljade piirangud on korrektsed
ning nõutav (nt tähemärkide arv) oleks tagatud piirmäärani ja korrektsed ekvivalentsklassid
oleksid kaetud.
Andmeväljade valideerimisel tuleb lähtuda järgmistest nõuetest:
1) Kõik tarkvara analüüsis kirjeldatud andmeväljad tuleb valideerida vastavalt tarkvara
analüüsis kirjeldatud nõuetele.
2) Piirväärtuste valideerimise tegevused peavad olema testitud nii korrektsete kui ka
mittekorrektsete andmehulkade ja/või formaatidega.
3) Andmeväljade valideerimisel tuleb teostada ekvivalentsklasside analüüs ning
kasutada andmeid kõikidest ekvivalentsklassidest.
4) Andmeväljade valideerimise jaoks tuleb koostada testilood.
2.1.8 Automaattestimine
Automaattestid koostatakse eesmärgiga kokku hoida testimisele kuluvat aega ja testid peavad
olema taaskasutatavad.
Automaattestide koostamisel ja läbimisel tuleb lähtuda järgmistest nõuetest:
1) Front-end automaattestid tuleb luua Selenium tööriistaga (või samaväärne), kui tellija
ja täitja ei ole kokkuleppinud teisiti.
2) Front-end ja back-endi automaattestid peavad olema automaatselt ja manuaalselt
käivitatavad.
3) Suitsutestimisel tuleb katta funktsionaalsus front-end automaattestidega v.a. teised
testiliikide automaattestid peavad olema backendi tasemel.
4) Väliste süsteemidega liidestumise testimisel tuleb kontrollida kõikide liideste toimimist.
5) Testandmed ei tohi olla automaattestidesse sisse kirjutatud, need tuleb võtta, kas
andmebaasist, testandmete failist või kogust või luuakse testandmed automaatselt
enne automaattesti.
5
Lisa 1
6) Kõik automaattesti skriptide kohta peab testraport kajastama ka skripti läbimise
tulemust.
7) Täitja esitab koos testitulemitega automaattestide kasutamise/seadistamise juhendi.
8) Täitja peab kõik automaattesti skriptid panema tellija GitLab keskkonna vastavasse
Repositooriumisse.
Tellijal on õigus teha täitja koostatud automaattestidele regulaarseid kvaliteedikontrolle (kas
automaattestid on seadistatud korrektselt).
2.1.9 Veaolukordade testimine
Veaolukordade testimise eesmärgiks on veenduda, et arendatud ja/või muudetud
funktsionaalsus annab korrektsed veateated valideerimisreeglite vastu sisestatud andmete
puhul.
Veaolukordade testimisel tuleb lähtuda järgnevast nõudest:
1) Kõik kasutajale kuvatavad veateated peavad olema testidega kaetud.
2.1.10 Suitsutestimine
Suitsutestimise eesmärgiks on kindlaks teha, et komponent või süsteemi põhifunktsionaalsus
töötab. Testilood katavad komponendi või süsteemi põhifunktsionaalsust.
Suitsutestimisel tuleb lähtuda järgnevatest nõuetest:
1) Komponentide või süsteemide testimisel tuleb kontrollida, kas komponentide või
süsteemide põhifunktsionaalsus töötab.
2) Testimine tuleb läbida testilugude põhise testimise (vt. 2.1.6) viisil.
3) Suitsutestid tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest vt.
2.1.8.
2.1.11 Liidese testimine
Liidese testimine on integratsiooni testi tüüp, mille eesmärk on kindlaks teha vead
komponentide või süsteemide liideste töös.
Liidestumise testimisel tuleb lähtuda järgmistest nõuetest:
1) Väliste süsteemidega liidestumise testimisel tuleb kontrollida kõigi liideste toimimist.
2) Testimisel tuleb läbida testilugude põhise testimise (vt. 2.1.6) viisil.
3) Liidese testid tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest vt.
2.1.8.
2.1.12 Integratsiooni testimine
Integratsiooni testimise eesmärk on avastada vigu integreeritud komponentide või süsteemide
omavahelises koostöös.
Integratsiooni testimisel tuleb lähtuda järgmistest nõuetest:
1) Integreeritud komponentide või süsteemide testimisel tuleb kontrollida kõigi
komponentide või süsteemide omavahelises koostööst.
2) Testimisel tuleb läbida testilugude põhise testimise (vt. 2.1.6) viisil.
3) Integratsiooni testid tuleb automatiseerida ja testide automatiseerimisel lähtuda
nõuetest vt. 2.1.8.
6
Lisa 1
2.1.13 Süsteemitestimine
Süsteemi testimise eemärk on kontrollida, kas integreeritud süsteem vastab määratletud
nõuetele.
Süsteemi testimisel tuleb lähtuda järgmistest nõuetest:
1) Süsteemitestimisel tuleb testida funktsionaalseid nõudeid (vt. 2.1.14).
2) Süsteemitestimisel tuleb testida mitte-funktsionaalseid nõudeid (vt. 2.1.22).
3) Süsteemitestid tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest
vt. 2.1.8.
2.1.14 Funktsionaalsete nõuete testimine
Funktsionaalsete nõuete testimise eesmärk on veenduda, et arendatud ja/või muudetud
funktsionaalsus on realiseeritud ja töötab korrektselt.
Funktsionaalsete nõuete testimisel tuleb lähtuda järgmistest nõuetest:
1) Funktsionaalsete nõuete testimisega kontrollida, kas arendatud ja/või muudetud
funktsionaalsus on realiseeritud ja töötab korrektselt.
2) Juhul, kui rakendus suhtleb automaatselt ja/või tänu kasutaja toimingule mõne muu
rakendusega, tuleb süsteemide vaheliste nõuete funktsionaalsete nõuete
kontrollimiseks koostada testlood.
3) Kõik funktsionaalsete nõuete kontrollimiseks loodud testilugude läbimise tulemused
tuleb kanda funktsionaalse testimise tulemuste alla.
4) Testimisel tuleb läbida testilugude põhise testimise (vt. 2.1.6) viisil.
5) Funktsionaalsete nõuete testid tuleb automatiseerida ja testide automatiseerimisel
lähtuda nõuetest vt. 2.1.8.
2.1.15 Regressioontestimine
Regressioontestimise eesmärk on veenduda, et olemasolevad komponendid või süsteem
töötavad pärast muudatuste või uue funktsionaalsuse lisamist endiselt vastavalt nõuetele.
Regressioontestimisel tuleb lähtuda järgmistest nõuetest:
1) Regressioontestidega tuleb veenduda, et kõik varem olemas olnud funktsionaalsused
toimivad samasuguse kvaliteediga kui nad toimisid enne rakenduse edasiarenduse
algust.
2) Regressioontestimisel võib tellija nõuda olemasolevate testilugude kasutamist. Antud
nõue kirjeldatakse tööde tellimuses.
3) Testimisel tuleb läbida testilugude põhise testimise (vt. 2.1.6) viisil.
4) Regressioontestid tuleb automatiseerida ja testide automatiseerimisel lähtuda
nõuetest vt. 2.1.8.
2.1.16 Uurimuslik testimine
Testija ekspertteadmistele tuginev testimine, mille eesmärk on tuvastada võimalikke
probleeme testitavas süsteemis.
Eesmärgid:
1) Teostada testimist tuginedes lahendusega kaasnevale kasutaja dokumentatsioonile.
2) Tuvastada vigu olukordades, mida testilugude põhine testimine ei pruugi tuvastada.
Uurimusliku testimisel tuleb lähtuda järgmistest nõuetest:
7
Lisa 1
1) Uurimuslik testimine tuleb läbida manuaalse testimise viisil.
2.1.17 Kasutatavuse testimine
Kasutatavuse testimise eesmärk on kontrollida püstitatud kasutatavuse nõuete täitmist.
Kasutatavuse testimine võib sisaldada:
1) Eksperdi hinnangut.
2) Grupitöö vormis kasutatavuse testimise läbiviimist.
Kasutatavuse testimise läbiviimise kirjalik vorm kirjeldatakse tellimuses.
Kasutatavuse testimisel tuleb lähtuda järgmistest nõuetest:
1) Kontrollida kasutatavuse testimisega, et püstitatud kasutatavad nõuded on täidetud.
2) Kasutatavuse testimine tuleb läbida manuaalse testimise viisil.
2.1.18 Robustsuse testimine
Robustsuse testimise eesmärk on kontrollida rakenduse käitumist ning töö taastumist
veaolukordades. Robustsuse testid keskendudes olukordadele, kus rakenduse enda mõnda
komponendid ei toimi osaliselt (nt. tagastavad valesid tulemusi) või ei toimi üldse (nt. liidese
kaudu info edastamine on blokeeritud).
Robustsuse testimisel tuleb lähtuda järgmistest nõuetest:
1) Kontrollida robustsuse testimisega rakenduse käitumist ning töö taastumist
veaolukordades.
2) Robustsuse testimine tuleb läbida, kas manuaalsel või automaatsel viisil, kuid
automaattestide puhul tuleb täita nõuded vt. 2.1.8.
2.1.19 Jõudlustestimine
Jõudlustestimise eesmärk on kinnitada tarkvara reaktsiooniaegade vastavust nõuetele
normaalsel kasutamisel (kui nõuetes ei ole kirjeldatatud teisiti, siis normaalne kasutamine
tähendab, et süsteemi koormus on kuni 25% maksimaalsest koormusest).
Jõudlustestimisel tuleb kontrollida süsteemi reaktsiooniaegu keskmise kasutuskoormuse
korral. Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest parameetrist: paralleelsete
kasutajate arv (ingl: simultaneous users), toimingute arv (ingl. number of transactions),
süsteemi lisatav info (ingl. volume).
Jõudlustestimisel tuleb lähtuda järgmisest nõudest:
1) Jõudlustestid tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest vt.
2.1.8.
2.1.20 Koormustestimine
Koormustestimise eesmärk on kontrollida tarkvara käitumist maksimaalse lubatud koormuse
korral (nõuded on kirjeldatud mitte-funktsionaalsete nõuete juures või tellija tellimuskirjas).
Koormustestimisel tuleb kontrollida süsteemi reaktsiooniaegu maksimaalse kasutatavuse
korral. Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest parameetrist: paralleelsete
kasutajate arv (ingl. simultaneous users), toimingute arv (ingl. number of transactions),
süsteemi lisatav info (ingl. volume).
Koormustestimisel tuleb lähtuda järgmisest nõudest:
8
Lisa 1
1) Koormustestid tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest vt.
2.1.8.
2.1.21 Stressitestimine
Stessitestimise eesmärk on kontrollida tarkvara käitumist lubatud maksimaalsest koormusest
suurematel koormustel (nõuded on kirjeldatud mitte-funktsionaalsete nõuete juures või tellija
tellimuskirjas). Stressitestimisel tuleb kontrollida süsteemi reaktsiooniaegu maksimaalse
kasutatavuse ületamise korral. Reaktsiooniaegade mõõtmisel tuleb lähtuda kolmest
parameetrist: paralleelsete kasutajate arv (ingl. simultaneous users), toimingute arv (ingl.
number of transactions), süsteemi lisatav info (ingl. volume).
Stressitestimisel tuleb lähtuda järgmisest nõudest:
1) Stressitestimine tuleb automatiseerida ja testide automatiseerimisel lähtuda nõuetest
vt. 2.1.8.
2.1.22 Mitte-funktsionaalsete nõuete testimine
Mitte-funktsionaalsete nõuete testimise eesmärk on veenduda, et mitte-funktsionaalsed
nõuded on täidetud.
Mitte-funktsionaalsete nõuete testimisel tuleb lähtuda järgmistest nõuetest:
1) Mitte-funktsionaalsete nõuete testimisel veenduda, et mitte-funktsionaalsed nõuded
(https://wiki.sm.ee/pages/viewpage.action?pageId=3834694 ) on täidetud.
2) Kõik mitte-funktsionaalsete nõuete kontrollimiseks loodud testilugude läbimise
tulemused tuleb kanda mitte-funktsionaalse testimise tulemuse alla.
3) Mitte-funktsionaalsete nõuete testimine tuleb läbida, kas manuaalsel või automaatsel
viisil, kuid automaattestide läbimisel tuleb täita nõuded vt. 2.1.8.
2.1.23 Andmemigratsiooni testimine
Andmemigratsioon on andmete transportimise protsess ühest seadmest, andmekandijast või
formaadist teise. Andmemigratsiooni testimise eesmärk on valideerida peale
andmemigratsiooni andmete terviklikkust ja kvaliteeti.
Andmemigratsiooni testimisel tuleb lähtuda järgmisest nõuetest:
1) Peale andmemigratsiooni tuleb valideerida andmete terviklikkust ja kvaliteeti.
2) Andmemigratsiooni testimine tuleb läbida, kas manuaalsel või automaatsel viisil, kuid
automaattestide puhul tuleb täita nõuded vt 2.1.8.
2.2 Nõuded testimise dokumentatsioonile ja nende vastuvõtukriteeriumid
Täitja peab esitama tellijale punktis 2.2 loetletud dokumentatsiooni:
1) Testiplaan (test plan);
2) Täiendusettepanekud alusdokumentide (nõuete) osas (suggestions for supporting
documents (requirements));
3) Testlood (test stories);
a) Nõuded testloo sisule (requirements for the content of the test stories) vt.
2.2.3.1;
i. Nõuded testloo prioriteetidele (Requirements for test story priorities) vt.
2.2.3.2.1;
b) Nõuded testloo andmetele (test data requirements) vt. 2.2.3.2;
4) Testandmed (test data);
9
Lisa 1
5) Automaattestide skriptid (automatic test scripts);
6) Vigade raporteerimine (error reporting);
a) Nõuded vigade raporteerimise formaadile (requirements for error reporting
format) vt. 2.2.6.1;
b) Nõuded vigade prioriteetidele (requirements for error priority) vt. 2.2.6.2;
7) Testiraport (test report)
a) Põhjalik testiraport (comprehensive test report) vt. 2.2.7.1;
b) Perioodiline põhjalik testiraport (periodic comprehensive test report) vt. 2.2.7.2;
c) Lõplik testiraport (final test report) vt. 2.2.7.3.
Täitja tagab, et koostab nõutud dokumentatsiooni ning annab tellijale üle punktis 2.2 nimetatud
dokumentatsiooni pärast tööde teostamist, kui ei ole kokkulepitud teisiti. Tellija jätab endale
õiguse kirjeldada iga infosüsteemi testimise juures üle antavat/ nõutavat dokumentatsiooni
loetelu. Vastavalt tellija soovile viib täitja dokumentatsiooni vajalikud parandused/
täiendusettepanekud sisse.
Tellija võtab tööd vastu, kui täitja on korrektselt tööd teostanud ja tellijale üle andnud tööde
dokumentatsiooni.
2.2.1 Testiplaan
Tulemite kvaliteedi kontrolli planeerimiseks koostatakse testiplaan. Testiplaani mall esitatakse
pakkumuses täitja poolt eeltäidetuna ning vajadusel tehakse poolte kokkuleppel vajalikud
muudatused, mis lepitakse kokku enne tööde alustamist.
1) Testiplaan peab katma kõiki täitja poolt teostatavaid testimise tegevusi.
2) Täitja kooskõlastab testiplaani tellijaga enne testiplaanis toodud tööde teostamist.
3) Testiplaani hoitakse ajakohasena kogu projekti vältel tellija keskkonnas.
2.2.2 Täiendusettepanekud alusdokumentide (nõuete) osas
Täitja paneb vajadusel kirja täiendusettepanekud alusdokumentide (nõuete) osas kui leitakse,
et see muudaks alusdokumendid (nõuete osas) arusaadavamaks.
2.2.3 Testlood
Testilugude koostamine ja läbimine toimub tellija ja täitja poolt kokkulepitud töövahendiga
Xray.
Testlugude koostamisel tuleb lähtuda järgmistest nõuetest:
1) Testilugude komplekt tuleb luua tellija keskkonnas. Testilugu esitatakse tellijaga
kokkulepitud vormingus.
2) Testlood peavad olema grupeeritud loogilistesse üksustesse. Testilugude koostamisel
lepib täitja tellijaga kokku testilugude struktuuri sõltuvalt arendatava süsteemi
eripärast.
3) Iga testitava nõude ja/või funktsionaalsuse kohta tuleb koostada vähemalt üks
testilugu.
4) Testilood peavad ära katma kõik võimalikud positiivsed teststsenaariumid. Kõigi
võimalike positiivsete teststsenaariumite arv peab olema kooskõlas sellega, mis on
arenduste analüüsis kirjeldatud.
5) Testlood peavad ära katma negatiivseid situatsioone (veaolukorrad ja kasutaja
mitteootuspärane käitumine).
6) Testilugude koostamisel tuleb lähtuda põhimõttetest, et üks testilugu võib sisaldada
maksimaalselt ühte negatiivset stsenaariumit – mitme negatiivse voo kirjeldamine
ühes testiloos ei ole lubatud.
10
Lisa 1
7) Iga kasutusloo alternatiivvoole tuleb luua eraldi testilugu.
8) Testlood peavad ära katma kõik lõpptulemi testimiseks vajalikud tegevused.
Täpsustatakse igas tellimuses eraldi.
9) Testilugude läbitavus ei tohi olla sõltuvuses testilugude läbimise järjekorrast välja
arvatud juhtudel, kui testlood on grupeeritud teststsenaariumiks.
10) Teststsenaariumiks grupeeritud testilugudel peab olema selgelt kirjas, milline testilugu
eelneb ja järgneb igale teststsenaariumisse kuuluvale testiloole.
2.2.3.1 Nõuded testiloo sisule
1) Kõik testiloo läbimise eeldused peavad olema kirjeldatud testiloo juures.
2) Iga testilugu peab käsitlema terviklikku tegevuste kogumit, mille tulemusel andmebaasi
andmehulk muutub, v.a. juhud, kui kontrollitakse andmeväljade või andmete
valideerimist (vaatamine, kuvamine, pärimine).
3) Testiloos kirjeldatud testisammud peavad olema eraldi läbitavad ning igale
testsammule on antud hinnang edukuse/ mitteedukuse kohta.
4) Kõik analüüsis kirjeldatud veateated peavad olema testilugudes kaetud.
5) Kui testilugu sisaldab andmete sisestamist või menetlemist, siis peab testilugu katma
kõik vajalikud etapid testitulemite saavutamiseks.
6) Loodud/muudetud/täiendatud andmesisestusväljade korral on kirjeldada nende
valideerimisreegleid.
2.2.3.2 Nõuded testloo andmetele
Testlood peavad sisaldama järgmist infot:
1) Testloo grupp;
2) Testloo nimetus;
3) Testloo kirjeldus;
4) Seotud nõue;
5) Testloo prioriteet;
6) Testloo läbimise eeldused (testloo läbimiseks vajalikud õigused ja eelnevad
toimingud);
7) Testloo testandmed;
8) Testisammud;
9) Oodatavad tulemid vastavalt testisammudele.
10) Automaatesti skripti link (kui tegu on automaattestiga).
Kokkuleppel tellijaga on võimalik testloo andmete muutmine.
2.2.3.2.1 Nõuded testloo prioriteetidele
Testloo prioriteedid:
1) Kriitiline – testilugu, mis kirjeldab kõrge riskiga funktsionaalsust.
2) Keskmine – testilugu, mis kirjeldab keskmise riskiga funktsionaalsust.
3) Minimaalne – testilugu, mis kirjeldab madala riskiga funktsionaalsust.
2.2.4 Testandmed
Testandmete loomise eesmärgid:
1) Testimiseks kvaliteetsete andmete loomine vajalikus mahus.
2) Kaitstavate andmete turvalisuse tagamine.
3) Korratav testandmete loomine – st. sama tegevust peab olema võimalik teha
korduvalt.
11
Lisa 1
4) Testandmete loomisel kasutatav lähenemine lepitakse täitja ja tellija poolt kokku enne
tööde teostamist.
Juhul, kui tegemist on jätkuarendustega rakendusele, millel on testandmete genereerimise
töövahend olemas, siis tuleb antud testandmete genereerimise töövahend viia vastavusse
arendustöö raames tehtud andmemudeli muudatustega.
2.2.5 Automaattestide skriptid
Läbitud automaattestide korral peab täitja esitama tellijale automaattestide skriptid.
2.2.6 Vigade raporteerimine
Vigade raporteerimine toimub tellija JIRA keskkonnas.
2.2.6.1 Nõuded vigade raporteerimise formaat
Vigade raporteerimisel tuleb lähtuda formaadist:
1) Keskkond/Operatsiooni süsteem/Brauser – keskkonna nimi ja aadress,
operatsiooni süsteemi nimi ja versioon ning brauseri nimi ja versioon, kus tuvastati
viga.
2) Eeldus – tingimused, mis peavad olema täidetud enne ja testandmed, millega viga
saadi.
3) Sammud – sammud, kuidas korrata tuvastatud viga.
4) Oodatav tulemus – komponendi või süsteemi käitumine, mis põhineb
spetsifikatsioonil.
5) Tegelik tulemus – komponendi või süsteemi käitumine, mis ei ühti oodatava
tulemusega.
6) Lisainfo – vajalik info, mis on vajalik veatuvastamiseks.
2.2.6.2 Nõuded vigade prioriteedid
Vigade raporteerimiseks tuleb kasutada prioriteete, mis on vastava teenuse või projekti SLA’s
kirjas, kui puudub antud info, siis kasutada allolevaid vigade prioriteete. SLA edastab
lepinguline kontaktisik, kui see vastavat testimistööd puudutab.
Vigade raporteerimisel tuleb lähtuda prioriteetidest:
1) Blokeeriv – viga mõjutab kriitilist funktsionaalsust või andmestikku, edasine testimine
on häiritud. Nt. sisse logimine pole võimalik.
2) Kriitiline – viga mõjutab põhifunktsionaalsust, edasine testimine on raskendatud kuid
võimalik kasutada alternatiivvooge. Nt. sisse logimine ID-kaardiga ei ole võimalik, aga
salasõnaga on võimalik.
3) Keskmine – viga mõjutab mittekriitilist funktsionaalsust või andmestikku, edasine
testimine on võimalik kasutades alternatiivvooge. Nt. sisselogimisel ID-kaardiga kui
vajutada Enter, siis ei hakka sisselogima, aga kui valida nupp Logi sisse, siis
hakatakse sisse logima.
4) Minimaalne – viga ei mõjuta funktsionaalsust ja andmestikku ega vaja kasutamiseks
alternatiivvooge. See ei mõjuta tootlikust ega efektiivsust. Nt. sisselogimise lehel on
kirjaviga nuppu nimes Login sisse, kuid peaks olema Logi sisse.
2.2.7 Testiraport
1) Testitulemid esitatakse vastavalt tellija ja täitja poolt kokkulepitud ajakavale.
2) Testiraporti genereerimiseks kasutatakse töövahendit Xray, kuid enne tööde
alustamist lepitakse kokku, millist Xray testiraportit kasutatakse.
12
Lisa 1
3) Testitulemitest peab olema selgelt aru saada, milliseid situatsioone ja milliste
andmetega testiti, milline oli testimise tulem, millised vead tuvastati, milliseid
nõuded/kasutuslood on testilugudega kaetud.
4) Testitulemite dokumentatsioon, lisadokumendid peavad olema selgelt struktreeritud ja
omavahel seostatud.
5) Testiraporti põhjal peab olema võimalik hinnata vigade klasterdumist.
2.2.7.1 Põhjalik testiraport
Põhjalik testiraport, kus on kirjas testimise tulemused koos kirjeldustega (sh veakirjeldused)
kõikide testitud liikide kohta (testimise liigid pannakse paika iga töö tellimuse juures eraldi
tellija poolt).
2.2.7.2 Perioodiline põhjalik testiraport
Regulaarselt kord nädalas kohtumisel (tellija asutuses või kokkuleppel mõnes muus
asukohas) peab täitja testijuht andma tellijale ülevaate testimise seisust. Enne igat kohtumist
peab täitja testijuht esitama kirjaliku ülevaate testimisest tellija keskkonnas ning järgmise
nädala tööde plaanidest ja kui on, siis kirjeldama olemasolevad takistused/riskid/sõltuvused.
2.2.7.3 Lõplik testiraport
Lõplikus testiraportis on toodud välja testiliikide tulemused (aluseks on punkt 2.2.7.1 esitatud
testiraport) koos hinnanguga arendaja töö kvaliteedile ning kas on võimalik arendust
toodangusse paigaldada.
2.3 Tarkvara testimises kasutatavad tööriistad
Täitja peab kasutama tellija Atlassiani tootekomplekti kuuluvaid töövahendeid (JIRA,
Confluence ja Xray) ning täitja peab tagama oma vahenditest Seleniumi tööriista (front-end
testide automatiseerimiseks).
Ülejäänud testimisel kasutatavad tööriistad lepitakse tellija ja täitja vahel kokku tellimuste
esitamisel, arvestades testimise eesmärki ning täitja soovitusi ja kompetentsi ühe või teise
tööriista kasutamisel. Täitja võib kasutada omi tööriistu tarkvara testimisel, kuid tagab et täitja
annab tellijale töö üleandmisel juhendi, kuidas saab üle antud tööd uuesti käivitada tellija
kasutatavates tööriistades, nt. automaattestid jne.
3 Töökorraldus
3.1 Üldine
1) Hankelepingu teostamise keeleks on eesti keel. Kogu informatsioonivahetus, sh.
töökoosolekud, arupärimised, tagasiside andmine jms. toimub eesti keeles. Täitjalt
oodatakse kogu hankelepingu täitmise perioodi vältel operatiivset tagasisidet tellija
küsimustele ja arupärimisetele. Täitja peab tagama, et tema poolt pakutava
meeskonnaga oleks tellijal võimalik suhelda kõrgetasemel eesti keeles ning ootab
nimetatule täitja poolset tagasisidet ja küsimusi samuti eesti keeles.
2) Testimine viiakse läbi tellija testkeskkondades ja pre-live keskkondades, kui ei ole
kokkulepitud teisiti.
3) Töötunnipõhiselt tasustavate tellimuste puhul on täitja meeskond kohustatud esitama
tööaja planeerimise aruandeid vastavalt tellija poolt nimetatud tingimustele:
a) Täitja esitab tööaja planeerimise aruande tellija kasutatavas töövahendis (nt Jira),
kuhu märgib erinevate testiliikide testimise ajakava;
13
Lisa 1
b) Tööaja logimise aruande esitab täitja iga meeskonnaliige isiklikult (iga
meeskonnaliige täidab aruande vormid ise).
c) Tööaja aruannete esitamise sagedus on üks kord nädalas, kui tellija ja täitja ei lepi
kokku teisiti.
d) Nõuded ajaaruande detailsusele (täidetud tööülesannete kirjeldusele) kehtestab
tellija testijuht.
4) Lepingu täitmisega seotud muu (igapäevane) teabevahetus toimub e-kirja, telefoni,
Skype teel või koosoleku vormis.
a) Suhtluskanalid (telefon, Skype, Rocket Chat) – kasutatakse kiireloomuliseks ja
operatiivseks suhtluseks. Skype’i kõneteenuse või telefoni kaudu kokkulepitud
olulised otsused tuleb kinnituseks fikseerida e-kirjaga või arutada ja protokollida
koosolekul.
14