Minu kätte on jõudnud ahjusoe A&A, mille peatoimetaja vastutusrikast ja auväärset positsiooni paluti täita meie kvaliteedijuhil Maili Markvardtil. See A&A number keskendub tarkvara testimisele ja selle erinevatele aspektidele ning seetõttu pean õigeks Maili artiklid ka meie blogis avaldada. On ju testimine meie igapäevane leib ja teema ise viimasel ajal väga aktuaalne, olukorras kus raha on vähe, et tegeleda PR-i ja kahjutule tõrjumisega peale katastroofi selle asemel, et veenduda enne süsteemide käikulaskmist, et seal sees ei oleks peidus mainet kõvasti kahjustavat pommi.
Mida mul veel muud üle jääb kui soovida mõnusat lugemist ja loodetavasti saame arendada aktiivset arutelu testimisest ja tarkvara kvaliteedist üldse Eesti IT maastikul, lahata müüte ja väärarusaamu ning üritame leida just selle õige koha kes peaks tarkvara kvaliteedi eest vastutama - tellija või täitja. Nüüd aga ASA esimene mõtteavaldus testimisest ja selle olulisusest.
Sander Vallaots
ASA Quality Services OÜ
tegevjuht
Meie igapäevane testimine
Maili Markvardt
Võin täiesti kindla veendumusega öelda, et igaüks meist tegeleb igapäevaelus testimisega, paljud küll alateadlikult, paljud aga kas suuremal või vähemal määral süstemaatiliselt ning eesmärgipäraselt. Milles meie igapäevane testimine väljendub ja kas see sarnaneb kuidagi tarkvara testimisele?
Selge nagu seebivesi
Kord pärast ühte ettekannet testimisest ja Eesti Testijate Liidust (ETL) küsis üks kuulajatest, endine õpetaja: „Kas te ETLis tegelete ka inimeste võimete ja oskuste testimisega. Esmalt see küsimus üllatas mind, sest ma polnud testimisele ja ETLi tegevusele päris sedamoodi mõelnud. Vastasin „Ei, aga…“ ning selgitasin, et Eesti Testijate Liit püüab aidata kaasa ainult professionaalsete testijate teadmiste ja oskuste hindamisele, võimaldades Eestis sooritada kodumaist ISTQB Certified tester Foundation Level eksamit. See on muide kõige tuntum testimise alane sertifikaat maailmas – 2010. aasta augustiks on üle maailma selliseid sertifikaate välja antud juba üle 145 000. Kui hästi järele mõelda, siis tõesti on üks levinumaid testimise liike igapäevaelus inimeste oskuste ja võimete testimine“.
Meid kõiki on siiamaani loendamatul arvul kordadel testitud – eksamite, kontrolltööde ja tahvli ees õpetaja küsimustele vastamise käigus. Selliseid „teste“ tehti eesmärgiga hinnata meie teadmisi ja oskusi mingil kindlal skaalal. Seega selgitamaks kas me oleme piisavalt „küpsed“, et meile omistada teaduskraad ja lõpudiplom. Niisiis võimaldab testimine, ka tarkvara testimine, hinnata objekte mingil ettemääratud skaalal. Tarkvara puhul on selleks skaalaks enamasti eelnevalt kokku lepitud nõuded, millele vastavust on testimise abil suhteliselt objektiivselt võimalik hinnata.
Kuidas hinnata kirjeldamatut?
Küllap need, kelle töökohustuste hulka kuulub muuhulgas ka töötajate palkamine ja kandidaatide intervjueerimine, teavad, milliseid „teste“ ning kuidas teha. Miks taolisi teste tehakse? Ühest küljest nõustuvad kõik tööandjad, et kindlasti on oluline leida heade oskustega ja kogemustega töötaja. Selle väljaselgitamiseks, kas inimene oskab või ei oska, küsitakse konksuga küsimusi ning antakse „koduülesandeid“, millele eeldatakse teatud vastuseid (peaaegu nagu eksamil). Selle info alusel on võimalik otsustada, kas kandidaat sobib oma professionaalsete omaduste poolest pakutavale töökohale.
Teisest küljest on märksa keerukam välja selgitada potentsiaalse töötaja neid omadusi, mis pole objektiivselt ning lihtsalt ülesannete ja küsimuste-vastustega mõõdetavad. Näiteks kui hea meeskonnamängija on kandidaat ja kui hästi sobib ta minu meeskonda? Kuidas ta käitub kriisisituatsioonis? Milline on tema motivatsioon ja töössesuhtumine? Siin võib kandidaat rääkida endast paljutki (sh ebaõiget) ja seda seejuures ise siiralt uskuda. Kuid teha „testi“, mis annaks võimaluse objektiivselt ja üheselt otsustada, on märksa raskem. Käitumist pingeolukorras on võimalik mingil määral testida, küsides tööintervjuul väga ründaval viisil otsekoheseid ja kiuslikke küsimusi, ning jälgida, kas inimene säilitab külma närvi või satub paanikasse. Seda nimetatakse stressi-intervjuuks ja selle kohta võite küsida oma asutuse personalijuhilt või lühidalt lugeda näiteks Kulno Türk’i materjalidest .
Fakt on see, et selliste simulatsioonide käigus on võimalik saada osalist infot, mis võimaldab meil luua kandidaadist ligikaudse pildi. Täpsemalt öeldes saame stressiintervjuu käigus kinnitust teatud omaduste osas – käitumine stressisituatsioonis, kriitikataluvus ning emotsionaalsus. Näiteks kui projektijuhi või kvaliteedikonsultandi kandidaadil hakkavad pärast paari ründavat küsimust käed värisema, siis pole ilmselt tegemist õige inimesega sellele positsioonile. Kuna nende rollide igapäevatöös on konfliktid tavapärased, siis rolli täitvalt inimeselt ootame oskust selliste situatsioonidega edukalt toime tulla. Jättes kõrvale inimlikud emotsioonid ja eelarvamused, võib nüüd öelda, et test oli edukas – teame, et seda inimest nimetatud kohale palgata ei sobi. See on kokkuvõttes väga hea testimise tulemus nii värbaja kui ka kandidaadi huvides – pääseme hilisemast pettumusest, kui töötaja oma kohuseid täita ei suuda. Kui inimese iseloomu sobimatust mingi ülesande täitmiseks on keeruline ja aeganõudev, vahel ka võimatu parandada, siis õnneks saab tarkvara testimise käigus leitud vigu enamasti parandada. Seega säästab iga leitud ja parandatud tarkvaraviga nii tegijaid kui kasutajaid võimalikust järgnevast meelehärmist.
Kõik mudelid on valed, aga mõned mudelid on kasulikud
Paraku võivad olla puudulikud intervjueerijate testimis-oskused ja/või on töölesoovija hea teeskleja. Seega ei pruugi kõik olulised jooned nii lühiajalisel testimisel veel ilmneda, sest limiteeritud aja jooksul pole võimalik „läbi mängida“ kõikvõimalikke olukordi. Ka tarkvara testimisel kehtib üldjuhul põhimõte, et mida erinevamaid ning ebastandardsemaid stsenaariume tarkvaras testitakse, seda parem on testimine ja seda tõenäolisemalt avalduvad vead.
Kui tööintervjuul ühtegi kriitilist viga leida ei õnnestu ning ka muudes tingimustes kokkuleppele jõutakse, siis testimine jätkub. Järgmiseks on õnnelikul uuel töötajal vajalik läbida pikaajalisem testimine – katseaeg. Katseajal on inimene juba reaalses töösituatsioonis ning täidab reaalseid ülesandeid. Kahjuks aga on katseaja järgselt töötajast loobumine seotud tööandja jaoks juba lisakuludega – töötaja otsingut tuleb taas otsast alustada, otsingute perioodiks tuleb ümber korraldada töökorraldus, uue töötaja leidmisel tuleb uut inimest taas õpetada ning toetada.
Analoogia vea parandamiseks vajalike kulutuste suuruse ja vea leidmise aja seosel on olemas ka tarkvaraarenduses. Spetsifikatsioonis leitud viga parandatakse nn paberil ja see ei jõua kunagi koodi. Oleme sellega kokku hoidnud vähemalt koodi valesti kirjutamisele kuluva aja. Arendaja poolt tehtud viga on tal enesel töö käigus teadvustada ja parandada märksa lihtsam, kui saada tagasisidet testijalt: testija peab viga otsima, raporteerima, vajadusel täpsustama, ning alles seejärel saab arendaja asuda vea põhjust välja selgitama. Seega on igati mõistlik, et arendajad testivad esmalt oma töötulemit ise nii palju kui oskavad ning alles seejärel antakse see testijate kätte. Lõppkasutajate käest tulnud tagasiside töötlemine ning arendajale arusaadavaks ülesandeks vormistamine on aga hoopis aega nõudev protsess. Seetõttu üritatakse mitmetasemelise arendustiimi ja testijate poolse testimisega lõppkasutajateni jõudvat vigade arvu kõigi vahenditega minimeerida. Niisiis, mida varem elus või tarkvaraarenduses testitulemuste abil negatiivsele tulemusele jõuad, seda parem, sest seda odavam on viga parandada või otsast peale alustada.
Maailmas on ainult üks kindel asi - muutused
Elus võtab negatiivsele tulemusele jõudmine tihti pikemalt aega, kui oodata oskame. Näiteks aasta, paar, või paarkümmend. Seda näiteks juhul, kui räägime elukaaslase või abikaasa „testimisest“. Inimene, kes esialgu tundus hea tüdruk- või poiss-sõber, kellega pidudel käia, ei pruugi osutuda näiteks heaks lapsevanemaks. Või inimene, kes on hea lapsevanem, keskendubki vaid lastele, jättes hooletusse oma kaasa ja enese vahelise ühendava sideme. Kui lapsed on suureks kasvanud, ei jää ilmselt alles ainsatki siduvat lüli huvide ega sõprade näol.
Milles on probleem antud juhul? Esialgsed „testid“ ju läbiti edukalt, et niikaugele üldse jõuti? Võti seisneb selles, et aja jooksul muutub nii testitav objekt (subjekt), kui ka ootused selle suhtes. Esimesel juhul, kui heast peokaaslasest ei saa head lapsevanemat, muutuvad teise poole ootused. Teisel juhul, kui kaob ühendav lüli, on muutunud objektid (subjektid), aga erinevates suundades, ega vasta enam esialgsetele ootustele.
Tarkvaramaailmas juhtub täpselt sama. Selleks ajaks, kui tarkvara valmis sai, on äripoolel valmistehtud „õuna“ asemel hoopis „apelsini“ vaja. Või siis oli neil tegelikult kogu aeg „apelsini“ vaja, aga nad ei teadnud seda ise või ei suutnud seda piisavalt hästi väljendada. Samuti on tarkvara puhul tüüpiline regressioon ehk „eile see töötas veel“, aga täna tehti parandus või täiendus, mis mõjutas juba olemasolevat ebasoovitavas suunas. Tarkvara puhul ongi oluline osata piisavalt hästi nõudeid koguda ja esitada. Kuidas vajadusel oma testimist äriolukorrale vastavalt piisavalt agiilselt korraldada, tutvustab värskes A&A väljaandes Valli artikkel. Regressioonivigadele kiirelt jaole saamisest testimise automatiseerimise abil tutvustab Raimond. Uuest suunast testimise efektiivsemaks muutmisel mudelipõhise testimise abil tutvustab minu selleteemaline artikkel.
Testimine – universaalne vahend tagasiside saamiseks
Lisaks tarkvara testijatele on professionaalseid testijad, kes konstruktiivse lõhkumisega oma igapäevast leiba teenivad, olemas ka muudel elualadel. Näiteks lennukeid testivad elukutselised katsepiloodid, kes võtavad uue või parandatud omadustega lennuki (prototüübi) enne, kui see tunnistatakse tootmiskõlbulikuks. Miks katselende tehakse? Esiteks selleks, et veenduda, et lennuk suudab täita oma tavapärast otstarvet. Veelgi enam aga selleks, et selgitada välja täpne piirangute hulk, milles antud lennukit on ohutu käitada.
Lennuki testimisel tehakse selgeks, missugune on lennuki minimaalne kiirus ja kaldenurk, ilma et lennuk alla kukuks; milline on maksimaalne ohutu kiirus, et konstruktsioon ei laguneks jne. Lennuki testijal pole tihti ees konkreetset „spetsifikatsiooni“, millele lennuk peab vastama, vaid testide käigus ta uurib, mida lennuk suudab ja talub. Niisiis tuleb lennukeid testida ka olukorras, kus testijal pole teada täpseid nõudeid, kuid ta võib lennukit uurida oma kogemusest, leidlikkusest ja uudishimust lähtuvalt. Tarkvaras on sellise testimise vasteks uuriv testimine ning sellest, räägib lähemalt Ervini artikkel.
Lisaks päris uute mudelite katsetamisele testitakse ka konkreetset lennuki eksemplari kokkupanemise järgselt, et välistada võimalikud koostevead ehk praak. Olenevalt lennukist ja tema otstarbest võtab see protseduur mitusada kuni mitutuhat lennutundi. Näiteks nn do-it-yourself-tüüpi kerglennukikomplektist kokku pandud lennuki registreerimiseks peab sertifitseeritud katsepiloot sellega lendama umbes sadakond lennutundi. Seejärel kuulutatakse lennuk lennukõlbulikuks, sest on olemas piisav kindlus, et lennuk ei kujuta endas ohtu ei temaga lendajatele, ega läheduses viibijatele. Tarkvaramaailmas on selle analoogiks kasutusse vastuvõtmise test (operational acceptance test), mis viiakse läbi vahetult pärast tarkvara paigaldamist toodangukeskkonda eesmärgiga leida paigaldamisel tekkinud juhuslikke vigu või vigu, mida pole võimalik enne toodangut avastada (näiteks testkeskkonna piiratud võimaluste tõttu).
Kui võrrelda mõne Airbus A380 katsetusi do-it-yourself lennuki testimisega, siis esimese katselendudeks kulus ilmselt märgatavalt rohkem tunde. Nii on ka tarkvara arenduses -testimise mahukus sõltub testitava objekti keerukusest ning olulisusest. Siinkohal ei taha ma kindlasti väita, et mõni lennuk oleks teisest väheolulisem – kõigist nendest sõltub inimeste elu, kuid Airbus A380 on kindlasti keerukam ja nõuab rohkem teste kui pisilennuk. Tarkvara testimisel on fakt see, teismelistele mõeldud mobiilimängu testitakse ilmselt vähema põhjalikkusega kui südamestimulaatori kontrollerit. Sellist lähenemist nimetatakse riskipõhiseks testimiseks, kus testimise ulatus ning meetodid tulenevad otseselt riskidest ehk sellest, milliseid tagajärgi võimalik viga endaga kaasa tuua võib. Riskipõhist testimist kirjeldab uues A&As täpsemalt Raivo artikkel.
Mis maksab rohkem – testimine või testimata jätmine?
Eelpoolkirjeldatud testide käigus panevad katsepiloodid mängu oma elu, et teistel oleks edaspidi ohutu lennata. Näiteks sai 2009. aasta kevadel surma lennukitootja Cessna katsepiloot , kuna lennukit ei õnnestunud testi käigus esile kutsutud pöörisest välja tuua ning ka piloodi päästmiseks disainitud langevarjusüsteem ei toiminud ootuspäraselt. Kahjuks ilmnes see alles reaalse testimise käigus. Seetõttu võib nimetatud juhtumit käsitleda kui õnnestunud testi, sest leiti viga. Inimlikus ja majanduslikus mõttes oli siiski tegemist katastroofiga. Õnneks tarkvara testijad oma elu igapäevaselt ohtu ei pane, kuid kindlasti ühendab katsepiloote ja tarkvara testijaid keskendumine läbikukkumisele, et arendaja ja lõpptarbija saaksid nautida edu. Seetõttu on testija oma töökohustusi täites professionaalne kahtleja ja igapäeva standardeid arvestades võiks öelda isegi, et paranoik.
Katsepilootideks, muide, palgatakse ainult kõige kogenumaid piloote . Küllap on selleks ka oma kindlad nõuded vastavalt sellele, kas testida on vaja pisikesi eralennukeid või ülisalajasi sõjaväelennukeid. Miks just kõige kogenenumaid? Selge see, et kogenud piloot oskab ka halvas olukorras õigesti reageerida ning suurema tõenäosusega lennuki niivõrd-kuivõrd tervelt maa peale tuua. Ka piloodi enda päästmine on kahtlemata majanduslikult üsna hästi põhjendatud. Siin saab paralleele tõmmata ka tarkvara testimisega. Tihti on testija ametikoht IT organisatsiooni lävepakuks, millest siis vaikselt karjääriredelit mööda üles ronima hakatakse. See on suhteliselt odav, kuid riskantne lähenemine, kuna väheste IT kogemustega inimene ei suuda anda nii kvaliteetset tagasisidet, kui inimene, kes on võimalikud vead juba ise läbi teinud. Niisiis saavad parimad testijad analüütikutest, arendajatest ja arhitektidest, kuna oma varasema kogemuse tõttu oskavad nad tihti vigu juba ette näha ning vältida nende tekkimist.
Tarkvara testimisel on kuluefektiivsus kindlasti oluline ning see sõltub suuresti vastusest küsimusele „kui palju testimist on piisavalt?“. Rusikareegel ütleb, et testimisel tuleb leida tasakaal testimise ja vigade ennetamisele kulude ning vigade tagajärgede likvideerimise kulude vahel. On selge, et kui infosüsteemis oleva turvaaugu tõttu lekivad konfidentsiaalsed isikuandmed, siis võib tarkvara tellijat (ning miks mitte ka arendajat?) oodata kulukas ning mainele laastavalt mõjuv kohtuasi. Seetõttu tuleb sellise vea toodangusse jõudmist kõigi meetmetega vältida, kas siis ennetades vea tekkimist või vea leidmisel selle parandamisega. Vastupidine näide oleks aga internetipoe kohta, kus võib-olla üks miljonist kasutajast 3 aasta jooksul lahkub poest konkurendi poodi, sest ei leia õiget toodet tema jaoks piisavalt kiiresti. Selline „kaotus“ on poe omanikule ilmselt vähem kulukas kui põhjalik kasutuskõlblikkuse test ning sellele järgnev poe ümberdisainimine.
Lennuki testimise põhjalikkusest sõltub temaga reisijate elu ning tema väljatöötajate hea maine. Tarkvaraga on täpselt samamoodi – tarkvara viletsa kvaliteedi läbi on midagi kaotada nii lõppkasutajatel kui ka omanikul ja väljatöötajal. Testimine on seega vahend hingerahu ja kindluse saavutamiseks ning riskide vähendamiseks talutavuse piirideni. Objekti, sealhulgas tarkvara, pole mõtet testida, kui tema võimaliku tõrkumise puhul pole midagi kaotada. Kui aga kaalul on inimelud, keskkond, suured summad raha või midagi muud olulist, siis aitab testimisest saadav info õigel ajal võtta vastu õigeid otsuseid.
Kelle viga?
Tuletame meelde lennujuhtimistarkvara viga , mille käigus kaotas Los Angeles’i lennujuhtimiskeskus kontakti 400 lähialas viibiva lennukiga. Esmalt võib jääda mulje, et vea, mis intsidendi põhjustas, tingis süsteemi käitajate ebapädev käitumine. Tarkvarasüsteemi ei taaskäivitatud piisavalt tihti, nagu ette nähtud juhendis. Põhjuseid täpsemalt uurides selgus aga, et kaose tinginud viga oli tarkvara tootja jaoks teadaolev viga, kuid ta ei suutnud adekvaatselt hinnata selle mõju lennujuhtimiskeskuse tööle. Teisisõnu, testijad olid teinud oma töö vea leidmisel, kuid puudulikuks oli jäänud kommunikatsioon teadaolevate vigade kohta ning tarkvara ostja poolne mõjuanalüüs. Kui selline viga jäi tähelepanuta, tekib küsimus, kas ostja teostas piisavad vastuvõtutestid ja kas tal oli selleks üldse piisav kompetents?
Siin jõuame tõdemuseni, et testimine üksi ei suuda tarkvara kuidagi paremaks muuta. Laiemalt võttes tegeleb tarkvara kvaliteedi tõstmisega valdkond, mida nimetatakse kvaliteedijuhtimiseks , kuid keskendume fookuse hoidmise nimel siiski testimisega vahetult seotud aspektidele. Niisiis on tarkvara paremaks muutmiseks vajalik esmalt vigade parandamine, sest kunagi ei saa anda 100% kindlust, et tarkvara kasutatakse täpselt kindlaksmääratud tingimustes ja keskkonnas. Teiseks aga on oluline vigadest ja nende mõjust arusaamine. Kas tegu on kosmeetilise vea või äritegevust takistava veaga? Selliste otsuste tegemiseks on hädavajalik põhjalikult tunda tegevusvaldkonda, mida konkreetne tarkvara toetab. Kes aga tunneks oma äri paremini kui tarkvara tellija ise?
Tarkvara eduka juurutuse üks saladustest on kahtlemata tellija kaasamine ning harimine tarkvaraarenduse ala. Tihti ei oska või ei viitsi tellijad küsida „õigeid“ küsimusi, vaid eeldavad, et tarkvaraarendaja on ekspert ka nende äris või vähemasti oskab lugeda mõtteid. Hea tellija, kui tarkvaraarendaja oleks ekspert Sinu äris, siis oleks ta ilmselt juba Sinu konkurent.
Tarkvaraarendajad aga eeldavad, et nad teavad valdkonnast isegi piisavalt palju, või siis ei oska ega viitsi tellijat tema mugavustsoonist välja tirida. Hea tarkvaraarendaja, kuna Sinu tellija igapäevatööks ei ole tarkvaraprojektide läbiviimine, siis on loomulik, et ta vajab selgitamist ja õpetamist, kuidas seda edukalt teha. Arendusprojekt, sealhulgas ka selle testimine, nõuab mõlema osapoole pühendumist maksimaalse tulemuse nimel. Võib öelda, et arendusprojekti käigus arendatakse küll tarkvara, kuid arenevad nii tellija kui täitja.
Otsus või hasartmäng?
Tulles tarkvara testimise juurest tagasi teiste objektide testimise juurde - kas Sina vaatasid uue auto ostu planeerides, mitu „tärni“ Su tulevane auto EURO NCAP testides sai? Mis järeldusi Sa sellest tegid või oleksid võinud teha – kas jätsid auto vahetamata, leides, et vana on veel küllalt hea ja turvaline? Valisid kallima auto, mis on ühtlasi ka turvalisem? Ignoreerisid tulemusi, lootes, et Sinuga midagi ei juhtu? Kõik need on otsused, mida võiks auto ostmisel kaaluda, kuid lõpliku valiku tegemiseks peab otsustaja käsutuses olema piisavalt usaldusväärne info.
Autode testimisel simuleeritakse erinevaid ohu- ja õnnetussituatsioone, et uurida, kui turvalised on autod sellistes olukordades nii autos viibijatele kui ka teistele kokkupõrke osapooltele (nt jalakäijad). Milles väljendub turvatestimine tarkvara juures, seda kirjeldab põhjalikumalt Maidu artikkel. Euro NCAP on aga sõltumatu organisatsioon, mille huviks on anda objektiivne hinnang Euroopas enimmüüdud autode turvalisuse kohta nii autojuhtidele kui autotootjatele, ta teenib korraga mõlema osapoole huve.
Autojuhi kui autotööstuse tarbija jaoks on oluline, et temal enesel ja teistel autos viibijatel oleks turvaline olla, ehkki tal enesel ei pruugi olla piisavalt kompetentsi, et ise osata turvalisust hinnata. Eks ka tarkvara tellijale on oluline, et keegi annaks kindluse tarkvara nõuetele vastavuse osas. Kindluse saamiseks on erinevaid võimalusi. Tihti piirdutakse arendusfirma kinnitusega kvaliteedi kohta, kuid sõltumatu hinnangu saamiseks kasutatakse ka kolmanda osapoole poolt teostatavat testimist või auditit. Seda eriti juhul, kus tellijal enesel pole piisavalt oskusi või aega, et põhjalikult testida.
Autotootjate jaoks on testitulemused aga hindamatu tagasiside, kuidas oma tooted paremaks ning ostjaskonnale ihaldusväärsemaks muuta. Niisiis on testimine ja sellest saadav info väga oluline sisend paremaks saamisel ka tarkvaramaailmas. Testijad leiavad vead enne kui kliendid või kasutajad, ning aitavad sellega teha arendajatel paremat tarkvara, saavutada paremat mainet ja suuremat usaldusväärsust.
Kolme lausega…
Testimine on protsess, mis konverteerib testitava objektiga seotud riskid infoks nende riskide kohta. Testitakse ainult neid objekte, mille tõrkumisest midagi olulist sõltub, näiteks lennukeid, autosid ja tarkvara. Saadud info on ühest küljest tagasiside, mis aitab saada paremaks, teisest küljest aga oluline sisend, mille alusel võtta vastu läbimõeldud otsuseid. Head otsused ja soov saada paremaks koos kübekese õnnega on suhteliselt kindel tee oma eesmärkide saavutamise poole.
NB. Kui leidsid ülalolevast tekstist mõne vea, siis võid selle raporteerida maili@asaquality.ee või kirjutada otse kommentaaridesse.
Viiteid jutu seest ja muidu kasulikku lugemist:
http://www.testijateliit.ee/ – Eesti Testijate Liit – testimisest huvitatud eraisikute organisatsioon, mille missiooniks teadvustada testimise kui distsipliini olemust ning aidata kaasa erialase oskusteabe levitamisele ja kompetentside arendamisele
http://infutik.mtk.ut.ee/www/kodu/jvju/personali-juhtimine-05.pdf - Personali juhtimine
http://www.justkitplanes.com/ - ehita endale ise lennuk ~300 000 Eesti krooni eest
http://www.airport-data.com/forums/topic1123.html - Cessna: ebaõnnestunud katselend või õnnestunud test?
http://www.slideshare.net/shakeeiil/software-failure-air-traffic-control-system - Lennujuhtimise ajaloo halvim õudusunenägu
http://www.asaquality.ee/teenused/kvaliteedijuhtimine - kvaliteet juhtub, kui oled kõik eelnevalt teinud õigesti
http://www.euroncap.com/home.aspx - Euro NCAP on organisatsioon, mis pakub nii juhtidele kui autotootjatele sõltumatut hinnangut Euroopas enimmüüdud automarkide turvalisuse kohta
Kommentaare ei ole:
Postita kommentaar