Kas ir veiklā testēšana?
AGILE TESTING ir testēšanas prakse, kas atbilst veiklas programmatūras izstrādes noteikumiem un principiem. Atšķirībā no Ūdenskrituma metodes, Agile Testing var sākties projekta sākumā, nepārtraukti integrējot attīstību un testēšanu. Agile Testing metodika nav secīga (tādā nozīmē, ka tā tiek izpildīta tikai pēc kodēšanas fāzes), bet ir nepārtraukta.
Šajā rakstā mēs to apspriedīsim
- Veikls testa plāns.
- Veiklu testēšanas stratēģijas.
- Veikls testēšanas kvadrants.
- QA problēmas ar veiklu programmatūras izstrādi.
- Automatizācijas risks veiklā procesā.
Veikls testa plāns
Veikls testa plāns ietver testēšanas veidus, kas veikti šajā atkārtojumā, piemēram, testa datu prasības, infrastruktūra, testa vide un testa rezultāti. Atšķirībā no ūdenskrituma modeļa, veiklā modelī katram izlaidumam tiek rakstīts un atjaunināts testa plāns. Tipiski testa plāni ātrā darbībā ietver
- Pārbaudes joma
- Jaunas funkcionalitātes, kuras tiek pārbaudītas
- Testēšanas līmenis vai veidi, pamatojoties uz funkciju sarežģītību
- Slodzes un veiktspējas pārbaude
- Infrastruktūras apsvērumi
- Riska mazināšanas vai risku plāns
- Resursu piesaiste
- Rezultāti un pagrieziena punkti
Veiklu testēšanas stratēģijas
Agile testēšanas dzīves cikls aptver četrus posmus
a) 0 atkārtojums
Pirmajā posmā vai 0 atkārtojumā veicat sākotnējos iestatīšanas uzdevumus. Tas ietver cilvēku identificēšanu testēšanai, testēšanas rīku instalēšanu, resursu plānošanu (lietojamības testēšanas laboratorija) utt. Lai sasniegtu Iteration 0, ir iestatītas šādas darbības
a) Biznesa pamatojuma noteikšana projektam
b) Nosakiet robežnosacījumus un projekta apjomu
c) izklāstiet galvenās prasības un lietošanas gadījumus, kas veicinās dizaina kompromisus
d) iezīmējiet vienu vai vairākas kandidātu arhitektūras
e) riska identificēšana
f) izmaksu aprēķins un sagatavo provizorisku projektu
b) būvniecības atkārtojumi
Agile testēšanas metodikas otrais posms ir Construction Iterations, lielākā daļa testēšanas notiek tieši šajā posmā. Šī fāze tiek novērota kā atkārtojumu kopums, lai izveidotu šķīduma pieaugumu. Lai to izdarītu, katrā atkārtojumā komanda ievieš hibrīdu praksi no XP, Scrum, Agile modelēšanas un veikliem datiem utt.
Būvniecības iterācijā veiklā komanda ievēro prioritāro prasību praksi: Katrā iterācijā viņi uzņem vissvarīgākās prasības, kas palikušas no darba priekšmetu kaudzes, un tās ievieš.
Celtniecības atkārtojumu klasificē divās daļās: apstiprinošā pārbaude un izmeklēšanas pārbaude. Apstiprinošā pārbaude koncentrējas uz pārbaudi, vai sistēma izpilda ieinteresēto personu nodomus, kas līdz šim aprakstīti komandai, un to veic komanda. Kaut arī izmeklēšanas testēšana atklāj problēmu, kuru apstiprinātāja grupa ir izlaidusi vai ignorējusi. Izmeklēšanas testēšanas laikā testeris defektu stāstu veidā nosaka iespējamās problēmas. Izmeklēšanas pārbaude risina tādus izplatītus jautājumus kā integrācijas testēšana, slodzes / stresa testēšana un drošības pārbaude.
Atkārtoti, apstiprinošajai pārbaudei ir divi aspekti: izstrādātāja testēšana un veiklās pieņemšanas pārbaude . Abas no tām ir automatizētas, lai nodrošinātu nepārtrauktu regresijas testēšanu visā dzīves ciklā. Apstiprinošā pārbaude ir veikls testēšanas ekvivalents specifikācijai.
Veiklā pieņemšanas pārbaude ir tradicionālās funkcionālās pārbaudes un tradicionālās pieņemšanas pārbaudes kā attīstības komandas kombinācija, un ieinteresētās puses to dara kopā. Kaut arī izstrādātāja testēšana ir tradicionālo vienību testēšanas un tradicionālo pakalpojumu integrēšanas testu kombinācija. Izstrādātāja pārbaude pārbauda gan lietojumprogrammas kodu, gan datu bāzes shēmu.
(c) izlaides beigu spēles vai pārejas fāze
“Atbrīvošanas, beigu spēles” mērķis ir veiksmīgi izvietot sistēmu ražošanā. Šajā posmā darbības ir tiešo lietotāju, atbalsta cilvēku un operatīvo cilvēku apmācība. Tas ietver arī produkta izlaišanas mārketingu, dublēšanu un atjaunošanu, sistēmas un lietotāja dokumentācijas pabeigšanu.
Pēdējā veiklās metodoloģijas testēšanas stadija ietver pilnīgu sistēmas testēšanu un pieņemšanas testēšanu. Lai pabeigtu pēdējo testēšanas posmu bez šķēršļiem, jums rūpīgāk jāpārbauda produkts, kamēr tas ir būvniecības atkārtojumos. Beigu spēles laikā testētāji strādās pie tās defektu stāstiem.
d) ražošana
Pēc izlaišanas posma produkts pāriet uz ražošanas posmu.
Veiklie testēšanas kvadranti
Veiklie testēšanas kvadrāti atdala visu procesu četros kvadrantos un palīdz saprast, kā tiek veikta veiklā testēšana.
a) Agile I kvadrants - šajā kvadrantā galvenā uzmanība tiek pievērsta iekšējam koda kvalitātei, un tas sastāv no testa gadījumiem, kas ir balstīti uz tehnoloģijām un tiek ieviesti, lai atbalstītu komandu, un tajā ietilpst
1. Vienības testi
2. Komponentu testi
b) Agile II kvadrants - tajā ir ietverti pārbaudes gadījumi, kas balstīti uz uzņēmējdarbību un tiek ieviesti, lai atbalstītu komandu. Šis kvadrants koncentrējas uz prasībām. Šajā posmā veiktais tests ir
1. Iespējamo scenāriju un darbplūsmu piemēru pārbaude
2. Lietotāja pieredzes, piemēram, prototipu, pārbaude
3. Pāru pārbaude
c) Veikls III kvadrants - šis kvadrants sniedz atgriezenisko saiti pirmajam un otrajam kvadrantam. Pārbaudes gadījumus var izmantot par pamatu automatizācijas testēšanas veikšanai. Šajā kvadrantā tiek veiktas daudzas atkārtojuma pārskatīšanas kārtas, kas vairo pārliecību par produktu. Šajā kvadrantā veiktais testēšanas veids ir
1. Lietojamības pārbaude
2. Izpētes testēšana
3. Pāru testēšana ar klientiem
4. Sadarbības testēšana
5. Lietotāju pieņemšanas pārbaude
d) IV veiklais kvadrants - šis kvadrants koncentrējas uz nefunkcionālām prasībām, piemēram, veiktspēju, drošību, stabilitāti utt. Ar šī kvadranta palīdzību tiek veikts pieteikums, lai sniegtu nefunkcionālās īpašības un paredzamo vērtību.
1. Nefunkcionāli testi, piemēram, stresa un veiktspējas pārbaude
2. Drošības pārbaude attiecībā uz autentifikāciju un uzlaušanu
3. Infrastruktūras testēšana
4. Datu migrācijas pārbaude
5. Mērogojamības pārbaude
6. Slodzes pārbaude
QA problēmas ar veiklu programmatūras izstrādi
a) Kļūdu iespējamība ir kustīgāka, jo dokumentācijai tiek piešķirta mazāka prioritāte, un tas galu galā rada lielāku spiedienu uz QA komandu
b) Ātri tiek ieviestas jaunas funkcijas, kas samazina testu komandām pieejamo laiku, lai noteiktu, vai jaunākās funkcijas atbilst prasībām, un vai tas patiešām attiecas uz biznesa uzvalkiem
c) Testētājiem bieži tiek prasīts spēlēt daļēji attīstītu lomu
d) Testa izpildes cikli ir ļoti saspiesti
e) Ļoti mazāks laiks testa plāna sagatavošanai
f) Lai veiktu regresijas testus, tiem būs minimāls laiks
g) Izmaiņas viņu lomā no kvalitātes vārtsargu līdz kvalitātes partneriem
h) Prasību izmaiņas un atjauninājumi ir raksturīgi veiklai metodei, kas kļūst par lielāko QA izaicinājumu
Automatizācijas risks veiklā procesā
- Automatizētā lietotāja saskarne nodrošina augstu uzticamības līmeni, taču to izpilde ir lēna, uzturama trausla un to izveide ir dārga. Automatizācija var būtiski neuzlabot testa produktivitāti, ja vien testētāji nezina, kā testēt
- Neuzticami testi rada lielas bažas automatizētajā testēšanā. Neveiksmīgu testu novēršanai un ar trausliem testiem saistītu problēmu risināšanai vajadzētu būt galvenajai prioritātei, lai izvairītos no viltus pozitīviem rezultātiem
- Ja automatizēto testu sāk manuāli, nevis izmantojot CI (nepārtraukta integrācija), pastāv risks, ka tie netiek regulāri veikti, un tāpēc tas var izraisīt testu neizdošanos
- Automatizētie testi neaizstāj izpētes manuālo testēšanu. Lai iegūtu paredzamo produkta kvalitāti, ir nepieciešams testēšanas veidu un līmeņu sajaukums
- Daudzi komerciāli pieejamie automatizācijas rīki nodrošina vienkāršas funkcijas, piemēram, manuālu testa gadījumu sagūstīšanas un atkārtošanas automatizēšanu. Šāds rīks veicina testēšanu, izmantojot lietotāja interfeisu, un tas noved pie dabiski trausliem un grūti uzturamiem testiem. Arī testa gadījumu glabāšana ārpus versiju kontroles sistēmas rada nevajadzīgu sarežģītību
- Lai ietaupītu laiku, daudzkārt automatizācijas testa plāns ir slikti plānots vai neplānots, kā rezultātā tests neizdodas
- Pārbaudes iestatīšanas un nojaukšanas procedūras parasti tiek izlaistas testa automatizācijas laikā, savukārt, veicot manuālu testēšanu, testa iestatīšanas un nojaukšanas procedūras izklausās nevainojami
- Produktivitātes rādītāji, piemēram, vairāki testa gadījumi, kas izveidoti vai izpildīti dienā, var būt ļoti maldinoši, un tas var novest pie lieliem ieguldījumiem bezjēdzīgu testu veikšanā
- Veiklās automatizācijas komandas locekļiem jābūt efektīviem konsultantiem: pretimnākošiem, kooperatīviem un atjautīgiem, vai arī šī sistēma ātri neizdosies
- Automatizācija var piedāvāt un piegādāt testēšanas risinājumus, kas prasa pārāk daudz pastāvīgas apkopes, salīdzinot ar sniegto vērtību
- Automatizētajai testēšanai var trūkt kompetences efektīvu risinājumu izveidei un nodrošināšanai
- Automatizētā testēšana var būt tik veiksmīga, ka to risināšanai pietrūkst svarīgu problēmu, tādējādi pievēršoties nesvarīgām problēmām.
Secinājums
Veiklā metodoloģija programmatūras testēšanā ietver testēšanu pēc iespējas agrāk programmatūras izstrādes dzīves ciklā. Tas prasa augstu klientu iesaisti un testēšanas kodu, tiklīdz tas kļūst pieejams. Kodam jābūt pietiekami stabilam, lai to nogādātu sistēmas testēšanā. Lai pārliecinātos, ka kļūdas ir novērstas un pārbaudītas, var veikt plašu regresijas testēšanu. Galvenokārt komunikācija starp komandām padara veiklu modeļa testēšanu veiksmīgu !!!