Nors IT sektoriuje be testavimo neapsieina produkto kūrimo procesas, testavimo pamokos aktualios kiekvienoje srityje, kuriant naują produktą, paleidžiant paslaugą. Sena tiesa – geriausiai mokomės iš klaidų. Svarbiausia – laiku jas atrasti.
Pirmoji pamoka: testuoti pradėkite kuo anksčiau
Kiekvieno produkto vystymą sudaro daugybė etapų. Patirtis rodo, kad testavimą būtina pradėti vos žengus pirmuosius žingsnius. Ankstyvas testavimas padeda išvengti vadinamojo „drugelio efekto“ – pirminiame etape pastebėtam netikslumui išspręsti užtenka vos penkių minučių ir, atvirkščiai, jei sistema jau veikia, tai gali pareikalauti ir kelių dienų ar net savaičių. Juolab, kad niekas jau neatsimins tikslių vieno ar kito sprendimo kūrimo aplinkybių.
Be testavimo neapsieina nė vienas šiuolaikinių technologijų sprendimas, todėl jo nesiėmus projekto pradžioje, teks imtis paskutinę dieną. O, kaip žinia, paskutinę dieną prieš produkto paleidimą ir taip bus ką veikti.
Tikrinant paskutinę minutę reikia ne tik daugiau žmogiškųjų ir technologinių išteklių, išauga ir klaidų, vėlavimo tikimybė. Tiek projekto pradžioje, tiek pabaigoje testuojami net patys smulkiausi procesai – tai daryti kur kas efektyviau kiekviename produkto ar paslaugos vystymo etape.
Antroji pamoka: kuo daugiau įvairovės – tuo stipresnis produktas
Testavimas kuriant pažangius sprendimus neišvengiamas, tačiau atskira tuo užsiimanti testuotojų komanda nebūtina. Mano įsitikinimu, dirbant „Agile“ principu, nedidelėje komandoje tik užtestavimą atsakingi specialistai gali įnešti daugiau sumaišties negu naudos. Kai kiekvienas komandos narys įsitraukia į visus procesus, reikia kur kas mažiau derinimų, mažiau laiko sugaištama diskusijoms. Papildoma grandis gali išbalansuoti šią struktūrą, o ir pats testuotojas gali jaustis ne savo rogėse.
Jei programinės įrangos kūrėjai niurzga, kad testavimas yra nemaloni procedūra, reikia siųsti žinutę, jog tai galimybė tobulėti, įvertinti savo įgūdžius ir mokytis iš klaidų. Be to, kai į patikros procesą įsitraukia kiekvienas komandos narys, susidaro kur kas palankesnės sąlygos sukurti geresnį, labiau vartotojų poreikius atliepiantį produktą ar paslaugą. Komandai apie tai reikia kalbėti ne būtinybės, o galimybių terminais.
Taip pat svarbu – kad produkto bandymo procese dalyvautų ir už verslo procesus atsakingi žmonės, mat įvairovės kriterijus galioja kalbant tiek apie profesinę kompetenciją, tiek apie asmenines savybes. Tai padeda vystant produktą – kas pro akis prasprūsta vienam, neliks nepastebėta kitų. Dar geriau, jei sudaromos galimybės kompetencijomis dalintis su tarptautine komanda.
Trečioji pamoka: žvilgtelėkite, kaip problemas sprendžia pasaulio lyderiai
Dažnai dėl įtempto darbų grafiko testavimas paliekamas vėlesniam laikui. Paaiškėjus, kad daugybė smulkmenų neveikia, vėliau tenka dirbti viršvalandžius. Tokios patirties turėjome ir mes, per pusmetį turėję sukurti lizingo sprendimą, leidžiantį automobilį įsigyti per mažiau nei dvi minutes. Prariję karčią piliulę, ėmėme dairytis, ko gali pamokyti pasaulinių kompanijų patirtis. Naudodamiesi gerąja „Facebook“ ir „Google“ praktika, naujuose projektuose automatinius testavimus diegiame jau pirminiuose produkto kūrimo etapuose.
Kita „Google“ ir „Facebook“ pamoka, atrodytų, net prieštarauja situacijai rinkoje – šios ir kitos technologijų milžinės tiesiog neturi atskiros testuotojo rolės. Jos vadovaujasi principu, kad kiekvienas komandos narys yra atsakingas už nepriekaištingą produkto kokybę. Taip atsakomybė už patikrą išlieka, tačiau ji proporcingai paskirstoma visiems komandos nariams – nuo programuotojo iki pardavimų specialisto.
Beje, semiantis patirties, neužtenka žvalgytis į pasaulio technologijų milžinus. Reikia domėtis ir pažangiausiais, nuolat tobulėjančiais testavimo įrankiais. Kai kurie iš jų padeda užbėgti problemoms už akių ir rasti sprendimą dar iki joms iškylant.
Ketvirtoji pamoka: įvertinkite produkto pristatymo laiką
Dažna situacija – besibaigiant darbo savaitei pas programuotojus ateina žmogus iš verslo ar pardavimų skyriaus ir ragina leisti produktą šeštadienį. Jis įsitikinęs, kad savaitgalį sprendimas bus naudojamas mažiau, tad be didelių dramų galima patogiai išspręsti iškilusius nesklandumus.
Nurodymus vykdėme tik pirmą kartą – paleidus bet kokį produktą, programuotojai turi būti budrūs ir pasiruošę iškart spręsti kilusią problemą. Todėl laisvadieniai tam tinkami mažiausiai.
Programinio sprendimo paleidimas nėra lyg šviesos jungiklio spustelėjimas: vos produktas pradeda veikti, programuotojai turi stebėti pirmuosius jo žingsnius, rinkti grįžtamąjį ryšį ir nedelsiant taisyti pastebėtas klaidas. Dirbdami išmokome pamoką, todėl savo produktus įprastai leidžiame savaitės pradžioje. Tuomet turime visą savaitę stebėti, kaip jam sekasi ir tuo pat metu reaguoti į iškilusias problemas neaukodami laisvadienių.
Penktoji pamoka: pasitikėkite automatiniais sprendimais, tačiau ne aklai
Net ir už paties pažangiausių dirbtinio intelekto ar informacinių technologijų sprendimų vis dar slepiasi žmogus ir jo gebėjimai. Nors didžioji testavimo dalis jau automatizuota (štai „Google“ automatizuota net 95 proc. kodo testavimų), paskutinį sprendimą priima programuotojas arba testuotojas. Išlaikyti ryšį su tikrove būtina, ypač, kai vartotojų lūkesčiai paslaugoms ir jų teikėjams auga, įmonės siekia suteikti kuo geresnę patirtį savo klientams.
Kuriant sudėtingas daugiapakopes sistemas nesėkmės neišvengiamos, tačiau svarbu, kad ir jos duotų pridėtinę vertę. Suklysti pirmą kartą nėra nuosprendis – tai reikėtų vertinti kaip pamoką, tam tikrą „reality check“. Tik nuo jos supratimo priklauso, ar analogiškos klaidos bus išvengta ateityje ir, galų gale, kiek sėkmingas bus jūsų sukurtas produktas.
