Paprastai kalbant, programinės įrangos kūrimas yra ilga etapų serija, kuri prasideda nuo reikalavimų rinkimo iki kūrimo ir bandymo iki galutinio išleidimo. Kiekviename etape reikalaujama, kad atitinkami nariai prisidėtų prie galutinio produkto kūrimo. Verslo analitiko darbas yra surinkti iš kliento reikalavimus ir patvirtinti jų įgyvendinamumą su techniniu architektu. Techninis architektas tiria visą aplinką ir atlieka naujo sprendimo patalpinimo joje poveikio analizę. Atsižvelgdami į galimybes, jie gali rekomenduoti pakeisti reikalavimus.
Po ilgų diskusijų ir reikalavimų, prasideda produkto kūrimas. Tada kūrimo komanda susiduria su savo iššūkiais. Kurdami programinę įrangą jie susiduria su nenumatytais įvykiais, dėl kurių gali tekti atnaujinti dizainą arba pakeisti pačius reikalavimus. Tada ateina kitas testavimo etapas, kai produktas išbandomas pagal skirtingus kriterijus. Net ir šis etapas gali grąžinti programinę įrangą į bet kurį iš ankstesnių etapų, atsižvelgiant į rastų defektų pobūdį.
Taigi iš viso to suprantame, kad programinės įrangos kūrimas nėra linijinis procesas. Jis eina pirmyn ir atgal tarp daugelio etapų, kurių reikia norint suteikti galutinę formą. Taigi kyla klausimas, kada idealiai turėtų prasidėti bandymai? Tai mes išsamiai išnagrinėsime kituose skyriuose.
Kodėl svarbus testavimo laikas?
Norint sukurti patikimą ir saugų produktą, būtina atlikti bandymus. Nėra jokių abejonių. Tačiau svarbiausia yra laikas, kada randamas defektas. Šis laikas turi tiesioginės įtakos tiek pardavėjui, tiek klientams. Jei defektas randamas gamyboje, tai iškart pažeidžia klientų pasitikėjimą. Jūsų prekės ženklo reputacija akimirksniu sumenka kliento akyse.
Kita vertus, tyrimais įrodyta, kad kuo vėliau defektas aptinkamas, tuo brangiau jį ištaisyti. Taip yra todėl, kad programinės įrangos sprendimas yra sukurtas remiantis daugybe algoritmų ir logikos. Kiekvienas iš jų turi įtakos kitiems keitimosi duomenimis, priklausomos logikos ir srauto sekos požiūriu. Vienoje vietoje aptiktas defektas gali sugesti ir visos kitos priklausomos programos bei paprogramės. Tai gali sutrikdyti visą kodo eigą. Neteisinga logika generuojant reikšmę, kuri naudojama keliose vietose, gali turėti pakopinį poveikį. Vadinasi, defektą ištaisyti vėliau nei anksčiau tampa eksponentiškai brangu ir sudėtinga.
Taigi, daroma išvada, kad kuo anksčiau atrasite klaidą, tuo ji bus geresnė visais atžvilgiais. Ir tai mus veda prie klausimo: koks yra idealus laikas, kada turėtų prasidėti bandymai? Žinoma, nėra prasmės pradėti bandymų, kol nebus sukurta pakankamai medžiagos. Kita vertus, lygiai taip pat rizikinga jį atidėti, kad jis būtų atrastas vėliau, kai tai darys didesnę įtaką bendram sprendimui.
Testavimo vaidmuo kiekviename vystymosi etape
Norėdami suprasti testavimo vaidmenį kiekviename etape, suskirstykime etapus į tris kūrimo etapus: reikalavimų rinkimas ir projektavimas, kodo kūrimas ir integravimas bei diegimas.
Reikalavimų surinkimas ir projektavimas
Šiame etape testavimas taikomas norint nepagauti klaidų, nes dar nėra sukurto kodo. Dažniausiai tai susiję su prielaidų patikrinimu. Kliento keliami reikalavimai turi būti patvirtinti atsižvelgiant į technines galimybes ir suderinamumą su verslo tikslais. Toks testavimas atliekamas funkciniu lygmeniu, kai tikrinami reikalavimai dėl jų poveikio kitiems susijusiems procesams tiek verslo, tiek techniniu lygiu.
Pavyzdžiui, proceso eigos pakeitimas po to, kai klientas pateikia užsakymą, gali turėti įtakos tolesniems įvykiams, pvz., duomenų bazės atnaujinimui, klientų informavimo procesui ir produkto pristatymui. Verslo analitikas patvirtina darbo eigą funkciniu lygmeniu, o techninis architektas tikrina tokio sprendimo kūrimo galimybes. Kuo anksčiau atskleidžiamos prielaidos, tuo mažesnė jos įtaka tolesniam procesui.
Kodo kūrimas ir vienetų testavimas
Tai etapas, kai bandymai tampa labiau apčiuopiami. Šiame etape sukuriamas funkcionalumo vienetas, kaip atskira programa, ir jį galima išbandyti pagal numatomus rezultatus. Priklausomų programų duomenų ir funkcinių mainų dar nereikia plėtoti, nes operaciją su jomis galima imituoti per užkoduotas reikšmes. Vienetų testavimas skirtas patikrinti, kaip vienas funkcinis vienetas veikia nepriklausomai ir ar jis sukuria laukiamą rezultatą tiek idealiu, tiek neigiamu scenarijumi. Norint efektyviai išbandyti vienetus, protingiau naudoti automatizavimo sistemą. „testRigor“, kaip programinės įrangos testavimo įrankis, yra vienas iš tokių produktų, galinčių atlikti šią užduotį pagal modeliuotus scenarijus.
Ideali testavimo praktika šiame etape yra sukurti bandomuosius atvejus dar prieš užkoduojant programą. Atsakomybė už tai tenka pačiam kūrėjui, kuris turėtų ne tik parašyti kodą, bet ir sąžiningai patvirtinti jo rezultatus.
Integracija ir diegimas
Po vieneto testavimo, kuris patvirtina kiekvieno komponento funkcionalumą, pradedamas integravimo procesas. Šiame etape visi skirtingi komponentai, kurie buvo sukurti ir išbandyti atskirai, sujungiami, o jų veikimas tikrinamas vienas kito atžvilgiu. Nors vieneto testavimas buvo skirtas atskiro komponento testavimui, integravimo testavimas tikrina jų ryšį. Jis patvirtina, ar visuma yra didesnė už jos dalių sumą, ar ne.
Kai integracija veikia nepriekaištingai, jos tinkamumas naudoti patikrinamas pagal klientų lūkesčius. Ši dalis apima programinės įrangos testavimą iš žmogaus perspektyvos. Visi techniniai aspektai naudingi tik tol, kol pagaliau gali patenkinti vartotojų lūkesčius. Šį testavimą galima atlikti vartotojo priėmimo aplinkoje, kuri yra beveik gamybos kopija.
Baigiamasis pareiškimas: kada turėtų prasidėti bandymai?
Suvokus įvairius testavimo etapus, yra pagrįsta paklausti, kada yra idealus laikas pradėti testavimą. Paprastas atsakymas į tai yra kuo greičiau. Prieš pradėdami testuoti savo produktą, savo komandoje turite ugdyti požiūrį į kokybę visais lygmenimis. Testavimas yra ne tik defektų nustatymas, bet visų pirma kritinio požiūrio į kiekvieną plėtros etapą kūrimas. Ar šis reikalavimas yra patikimas, koks patikimas yra kodas, ar jis atlaikys nepalankius scenarijus? Tai klausimai, kuriems pradėti nereikia nustatyto etapo. Šie kriterijai turėtų būti patvirtinti nuo pat pradžios iki diegimo etapo.
Taigi, galutinis atsakymas yra toks, kad bandymai prasideda tuo metu, kai pradedame įsivaizduoti produktą. Kiekvienas reikalavimas turi būti įvykdytas su „O kas, jei? klausimas. Kiekviena prielaida turėtų būti atskleista, o kiekviena funkcija turi būti išbandyta pagal apčiuopiamus rezultatus. Kai ugdysite kritišką mąstymą savo komandoje, visos jūsų bandymo pastangos bus jos apraiška, kuri turės didesnę įtaką produkto kokybei.
