Kas yra judrus testavimas?
„AGILE TESTING“ yra testavimo praktika, kurioje laikomasi judrios programinės įrangos kūrimo taisyklių ir principų. Skirtingai nuo „Waterfall“ metodo, „Agile Testing“ gali prasidėti projekto pradžioje, nuolat integruojant kūrimą ir testavimą. „Agile Testing“ metodika nėra nuosekli (ta prasme, kad ji vykdoma tik po kodavimo fazės), bet yra tęstinė.
Šiame straipsnyje aptarsime
- Vikrus bandymų planas.
- Agile testavimo strategijos.
- Vikrus testavimo kvadrantas.
- Kokybės užtikrinimo iššūkiai - judrus programinės įrangos kūrimas.
- Automatizavimo rizika judriuose procesuose.
Vikrus bandymų planas
Vikrus bandymų planas apima toje versijoje atliekamų bandymų tipus, pvz., Bandymų duomenų reikalavimus, infrastruktūrą, bandymų aplinką ir bandymų rezultatus. Skirtingai nuo krioklio modelio, judriame modelyje kiekvienam leidimui yra rašomas ir atnaujinamas bandymų planas. Tipiški testavimo planai judrioje apima:
- Testavimo apimtis
- Naujos testuojamos funkcijos
- Testavimo lygis arba tipai, atsižvelgiant į funkcijų sudėtingumą
- Apkrovos ir našumo testavimas
- Infrastruktūros svarstymas
- Švelninimo arba rizikos planas
- Resursų panaudojimas
- Rezultatai ir etapai
Judrios testavimo strategijos
Agile testavimo gyvavimo ciklas apima keturis etapus
a) 0 kartojimas
Pirmojo etapo arba 0 pakartojimo metu atliekate pradines sąrankos užduotis. Tai apima žmonių identifikavimą bandymams atlikti, diegti testavimo įrankius, planuoti išteklius (tinkamumo naudoti bandymų laboratorija) ir kt. Šie veiksmai nustatyti norint pasiekti „Iteration 0“
a) Verslo projekto nustatymas
b) Nustatykite ribines sąlygas ir projekto apimtį
c) Apibūdinkite pagrindinius reikalavimus ir naudojimo atvejus, kurie paskatins dizaino kompromisus
d) Apibūdinkite vieną ar daugiau architektų kandidatų
e) Rizikos nustatymas
f) Sąnaudų įvertinimas ir parengiamas preliminarus projektas
b) statybos kartojimai
Antrasis judriojo bandymo metodikos etapas yra konstrukcijos kartojimai, didžioji dalis bandymų atliekama būtent šiame etape. Ši fazė stebima kaip iteracijų rinkinys, norint sukurti tirpalo prieaugį. Norėdami tai padaryti, kiekvienoje iteracijoje komanda įgyvendina daugybę praktikų iš XP, „Scrum“, „Agile“ modeliavimo ir judrių duomenų ir pan.
Vykdydami statybų kartojimą, judri komanda vadovaujasi prioritetinių reikalavimų praktika: Kiekvienoje iteracijoje jie paima svarbiausius reikalavimus, likusius iš darbo elementų kamino, ir juos įgyvendina.
Statybos iteracija skirstoma į du, patvirtinamuosius ir tiriamuosius. Patvirtinantis bandymas sutelktas į patikrinimą, ar sistema vykdo suinteresuotųjų subjektų ketinimus, aprašytus komandai iki šiol, ir ar juos atlieka komanda. Tyrimo metu nustatoma problema, kurią patvirtinanti grupė praleido arba ignoravo. Tiriamuoju testavimu testuotojas nustato galimas problemas pateikdamas defektų istorijas. Tiriamieji bandymai nagrinėja tokius įprastus klausimus kaip integracijos testavimas, apkrovos / streso testai ir saugumo testai.
Vėlgi, norint patvirtinti, yra du aspektai - kūrėjo testavimas ir judrus priėmimo testavimas . Abi jos yra automatizuotos, kad būtų galima atlikti nuolatinį regresijos bandymą viso gyvenimo ciklo metu. Patvirtinamasis bandymas yra judrus bandymo atitikmuo specifikacijai.
Vikrus priėmimo testavimas yra tradicinių funkcinių ir tradicinių priėmimo testų, kaip kūrėjų komandos, derinys. Suinteresuotosios šalys tai daro kartu. Nors kūrėjų testavimas yra tradicinio vieneto testavimo ir tradicinių paslaugų integravimo testų derinys. Kūrėjų bandymai patikrina ir programos kodą, ir duomenų bazės schemą.
(c) Išleisti pabaigos žaidimą arba pereinamąjį etapą
„Išleidimo, pabaigos žaidimo“ tikslas - sėkmingai įdiegti savo sistemą gamyboje. Šiame etape vykdoma veikla yra galutinių vartotojų, pagalbos žmonių ir operatyvių žmonių mokymas. Tai taip pat apima produkto išleidimo rinkodarą, atsarginę kopiją ir atkūrimą, sistemos ir vartotojo dokumentų užbaigimą.
Paskutinis judrios metodikos testavimo etapas apima visišką sistemos ir priėmimo testavimą. Kad baigtumėte paskutinį bandymo etapą be jokių kliūčių, turėtumėte griežčiau išbandyti gaminį, kol jis atliekamas statybų kartojimuose. Baigiamojo žaidimo metu bandytojai dirbs su jo defektų istorijomis.
d) gamyba
Po išleidimo etapo produktas pereis į gamybos etapą.
Vikrūs bandymo kvadrantai
Vikrūs testavimo kvadrantai atskiria visą procesą keturiais kvadrantais ir padeda suprasti, kaip atliekami judrūs bandymai.
a) „ Agile I kvadrantas“ - šiame kvadrante pagrindinis dėmesys skiriamas vidinio kodo kokybei. Jį sudaro bandomieji atvejai, kurie yra pagrįsti technologijomis ir įgyvendinami komandai paremti
1. Vieneto testai
2. Komponentiniai bandymai
b) „ Agile II kvadrantas“ - jame yra bandomųjų atvejų, kuriuos lemia verslas ir kurie yra pritaikyti komandai palaikyti. Šis kvadratas orientuotas į reikalavimus. Šiame etape atliekamas bandymas yra
1. Galimų scenarijų ir darbo eigos pavyzdžių testavimas
2. Vartotojo patirties, tokios kaip prototipai, testavimas
3. Porų testavimas
c) III judrusis kvadratas - šis kvadratas teikia grįžtamąjį ryšį pirmam ir antram kvadrantams. Testo atvejai gali būti naudojami kaip pagrindas atliekant automatikos bandymus. Šiame kvadrate atliekama daug kartų pakartojimų, kurie kelia pasitikėjimą produktu. Šiame kvadrate atliktų bandymų rūšis yra
1. Naudojimo testavimas
2. Tiriamasis testavimas
3. Porų testavimas su klientais
4. Bendradarbiavimas
5. Vartotojo priėmimo testavimas
d) IV judrusis kvadrantas - šis kvadratas koncentruojasi į nefunkcinius reikalavimus, tokius kaip našumas, saugumas, stabilumas ir kt. Šio kvadranto pagalba pateikiama nefunkcinių savybių ir laukiamos vertės.
1. Nefunkciniai testai, tokie kaip stresas ir našumo testai
2. Saugumo tikrinimas autentifikavimo ir įsilaužimo atžvilgiu
3. Infrastruktūros bandymai
4. Duomenų perkėlimo testavimas
5. Mastelio tikrinimas
6. Apkrovos testavimas
Kokybės užtikrinimo iššūkiai - judrus programinės įrangos kūrimas
a) Klaidų tikimybė yra judresnė, nes dokumentams teikiama mažiau prioriteto, galiausiai QA komandai daromas didesnis spaudimas
b) Naujos funkcijos pristatomos greitai, o tai sumažina bandymų grupėms skirtą laiką, kad būtų galima nustatyti, ar naujausios funkcijos atitinka reikalavimą, ir ar tai tikrai tinka verslo kostiumams
c) Bandytojams dažnai tenka vaidinti pusiau kūrėją
d) Bandymų vykdymo ciklai yra labai suglaudinti
e) Labai mažiau laiko parengti testų planą
f) Regresijos bandymams laikas bus minimalus
g) jų vaidmens keitimas iš kokybės vartų sargo į kokybės partnerį
h) Reikalavimų pakeitimai ir atnaujinimai yra būdingi judriam metodui, kurie tampa didžiausiu QA iššūkiu
Automatizavimo rizika judriuose procesuose
- Automatizuota vartotojo sąsaja suteikia aukštą pasitikėjimo lygį, tačiau jos yra lėtai vykdomos, trapios prižiūrėti ir brangios kurti. Automatika gali žymiai nepagerinti testų našumo, nebent testuotojai žino, kaip atlikti bandymus
- Nepatikimi testai kelia didžiausią susirūpinimą atliekant automatinius bandymus. Nepavykusių bandymų taisymas ir problemų, susijusių su trapiais bandymais, sprendimas turėtų būti pagrindinis prioritetas, kad būtų išvengta klaidingų teigiamų rezultatų
- Jei automatinis testas pradedamas rankiniu būdu, o ne naudojant nuolatinį integravimą (CI), yra rizika, kad jie nėra reguliariai vykdomi, todėl gali nepavykti atlikti bandymų
- Automatiniai bandymai nepakeičia tiriamojo rankinio bandymo. Norint gauti laukiamą produkto kokybę, reikalingi įvairūs bandymų tipai ir lygiai
- Daugelis komerciškai prieinamų automatikos įrankių teikia paprastas funkcijas, pvz., Automatinių rankinių bandymų atvejų fiksavimą ir atkūrimą. Toks įrankis skatina atlikti bandymus per vartotojo sąsają ir lemia trapius ir sunkiai prižiūrimus testus. Be to, bandymų atvejų saugojimas ne versijų valdymo sistemoje sukuria nereikalingą sudėtingumą
- Siekiant sutaupyti laiko, daug kartų automatikos bandymų planas yra blogai suplanuotas arba neplanuotas, todėl bandymas nepavyksta
- Testo nustatymo ir nugriovimo procedūros paprastai praleidžiamos atliekant bandymo automatizavimą, o atliekant rankinį bandymą, bandymo nustatymo ir nugriovimo procedūros skamba sklandžiai
- Produktyvumo metrika, pvz., Per dieną sukurtų ar įvykdytų bandymų atvejų skaičius, gali būti labai klaidinanti ir gali paskatinti daug investuoti į nenaudingų bandymų atlikimą.
- Judrios automatikos komandos nariai turi būti veiksmingi konsultantai: prieinami, bendradarbiaujantys ir išradingi, nes ši sistema greitai suges
- Automatika gali pasiūlyti ir pristatyti bandymo sprendimus, kuriems reikalinga per daug nuolatinės priežiūros, palyginti su pateikta verte
- Automatizuotam testavimui gali trūkti patirties, kaip sukurti ir pateikti veiksmingus sprendimus
- Automatizuotas testavimas gali būti toks sėkmingas, kad jiems išspręsti svarbių problemų nebelieka, taigi jie pereina prie nesvarbių problemų.
Išvada
Greita programinės įrangos testavimo metodika apima testavimą kuo anksčiau programinės įrangos kūrimo gyvavimo ciklo metu. Tai reikalauja didelio klientų įsitraukimo ir testavimo kodo, kai tik jis tampa prieinamas. Kodas turėtų būti pakankamai stabilus, kad jį būtų galima išbandyti sistemoje. Galima atlikti išsamų regresijos bandymą, kad įsitikintumėte, jog klaidos ištaisytos ir patikrintos. Daugiausia, komandų bendravimas padaro judrų modelio testavimą !!!
