Kai įmonė nusprendžia pereiti nuo krioklio prie judriojo testavimo, į kokias svarbiausias sritis reikėtų atkreipti dėmesį norint efektyviai atlikti judrumą?
Kaip testavimas judriame judesyje palyginamas su krioklio modeliu? Kokias veiklos rūšis testuotojai turi žinoti ir atlikti?
Pirmiausia reikia suprasti, kad judrioje programoje testavimas yra integruotas per visą jo gyvavimo ciklą; nuolat bandant programinę įrangą jos kūrimo metu.
Tradiciniame krioklio modelyje bandymai yra daug pastangų ir paliekami kūrimo pabaigoje, tuo tarpu „Agile“ bandymai yra nedideli, bet dažnesni ir vyksta viso kūrimo metu.
Testavimas viso kūrimo metu taip pat reiškia, kad programinė įranga yra atleistinos būklės viso kūrimo metu, todėl ją galima siųsti, kai tik reikia.
Pagal krioklio modelį mes mokome mąstyti etapais, tokiais kaip projektavimo, kūrimo ir bandymo etapai. Judrus vystymas neturi atskiro bandymo etapo. Kūrėjai daug labiau užsiima testavimu, rašo automatizuotus pakartojamų vienetų testus, kad patvirtintų jų kodą.
Atliekant automatinius vieneto testus, bandymai gali būti atliekami kaip sudedamoji dalis, užtikrinant, kad visos savybės tinkamai veiktų kiekvieną kartą, kai sukuriamas komponavimas. Turėdami tvirtą gero vieneto bandymo aprėpties pagrindą, kūrėjai jausis labiau tikri ir dėl refaktoriaus kodo.
Testavimas Agile reiškia ir ankstyvą pradžią. Tai reiškia, kad kokybės užtikrinimas turėtų būti įtrauktas nuo pat projektavimo etapo, suprantant ypatybes ir istorijas, iš anksto pradedant rengti ir net rašyti testus.
Kitas svarbus aspektas yra „Test Automation“, kad būtų galima nuolat atlikti bandymus kuriant produktą. Tai ne tik automatiniai vieneto testai, bet ir API bei UI automatizuoti testai.
Perėjimas prie „Agile“ yra daugiafunkcinė projekto komandos veikla. Šios bendros pastangos neapsiriboja vien bandymų veikla. Kūrėjai turėtų padėti išbandyti sistemas ir kurti funkcijas, verslo analitikai - patobulinti istoriją.
Kiekvienas komandos narys dirba prie istorijos, kol bus padaryta visa istorija, vadinasi, sukurta ir išbandyta. Dizaineriai, kūrėjai ir testuotojai dirba kartu lygiagrečiai, todėl pasiekia bendrą tikslą ir visi jie turėtų žinoti, ko reikia, kad viskas būtų padaryta.
Pasirodymas komandoje yra pagrindinis taškas, pereinantis nuo krioklio prie judriojo testavimo. Bendrovė gali nuspręsti pakeisti „Agile Testing“, bet žmonės turi palaikyti šį pakeitimą, kad pavyktų.
Nėra judrios bandymų komandos.
Siekite defektų prevencijos, o ne defektų nustatymo.
Anksti dalyvaujant bandytojams projekte, jie gali padėti nustatyti pagrindinius scenarijus, kurių reikia norint išbandyti istoriją. Gana dažnai priimtinumo kriterijai rašomi kaip bendras produkto savininko, kūrėjo ir bandytojo - trijų amigų - darbas.
Tai užtikrina, kad viskas, kas statoma, yra patikrinama ir suprantama visoms suinteresuotosioms šalims. Be to, kadangi daugiau žmonių dalyvauja apibrėžiant priėmimo kriterijus ir „Atlikto apibrėžimą“, klaidas galima ištaisyti anksčiau, o galiausiai tinkamas produktas yra sukurtas teisingai.
Visi dalyvauja ir yra atsakingi už produkto kokybę.
„Agile“ kūrime daugiau dėmesio skiriama pokalbiams ir bendradarbiavimui, siekiant išsiaiškinti reikalavimus, nei tradiciniam požiūriui į specifikacijas ir dokumentus.
Nors reikalavimus tam tikru mastu galima paaiškinti judrioje plėtroje, vis tiek įmanoma, kad reikalavimai būtų dviprasmiški ir neišsamūs, o komandos nariai skirtingai suprastų reikalavimus.
Taigi, ką tai reiškia judriam bandytojui? Dažnas bandytojų rūpestis, pereinantis prie „Agile“ kūrimo, yra tas, kad jie tiksliai nežino, ką bando. Jie neturi išsamios specifikacijos, su kuria galėtų išbandyti, tai kaip jie gali tai patikrinti?
Norėdami pradėti testuoti, nereikia turėti išsamios dokumentacijos. Daug kartų padoriai bandytojai gali naudoti savo sprendimą ir sveiką protą, kad patvirtintų produktą. Domeno žinios tampa nepaprastai svarbios.
Testuotojai turėtų būti tikri, kad dirbtų daugiau iš savo žinių, kaip atrodo gerai. Tai tikrai nėra tik bandomojo scenarijaus vykdymo atvejis, užtikrinant, kad programinė įranga atliktų tai, ką sako specifikacijoje.