Scrum programmatūras testēšanā
Scrum programmatūras testēšanā ir sarežģītu programmatūras lietojumu veidošanas metodika. Tas nodrošina vienkāršus risinājumus sarežģītu uzdevumu izpildei. Scrum palīdz izstrādes komandai koncentrēties uz visiem programmatūras produktu izstrādes aspektiem, piemēram, kvalitāti, veiktspēju, lietojamību un tā tālāk. Tas nodrošina pārredzamību, pārbaudi un pielāgošanu programmatūras izstrādes laikā, lai izvairītos no sarežģītības.
Scrum testēšana
Scrum testēšana ir pārbaude, kas tiek veikta scrum metodoloģijā, lai pārbaudītu, vai tiek izpildītas programmatūras lietojumprogrammu prasības. Tas ietver tādu nefunkcionālu parametru pārbaudi kā drošība, lietojamība, veiktspēja utt. Šajā procesā testerim nav aktīvas lomas, tāpēc to parasti veic izstrādātāji ar Unit Test. Dažreiz atkarībā no projekta rakstura un sarežģītības ir nepieciešamas īpašas testa grupas.
Šajā apmācībā jūs uzzināsiet
- Kas ir Scrum?
- Scrum metodoloģijas galvenās iezīmes
- Lomas Scrum
- Scrum artefakti
- Ceremonijas (procesi) Scrum
- Testētāja loma Scrum
- Pārbaudes aktivitātes Scrum
- Testa ziņošana
Scrum metodoloģijas galvenās iezīmes
Svarīgākās Scrum-
- Scrum ir īss fiksēts izlaišanas ciklu grafiks ar pielāgojamu darbības jomu, kas pazīstams kā sprints, lai risinātu strauji mainīgās attīstības vajadzības. Katrā laidienā varētu būt vairāki sprinti. Katram Scrum projektam varētu būt vairāki izlaišanas cikli.
- Atkārtota sanāksmju, notikumu un pavērsienu secība
- Jaunu prasību, kas pazīstamas kā stāsti , testēšana un ieviešana , lai pārliecinātos, ka pēc katra sprinta daži darbi tiek izlaisti gatavi
Scrum pamatā ir šādi 3 pīlāri -
Apskatīsim pa vienam
1. Lomas Scrum
Scrum testēšanā ir trīs galvenās lomas - produktu īpašnieks, Scrum Master un izstrādes komanda. Izpētīsim tos detalizēti
|
Produkta īpašnieks |
Scrum Master |
Komanda |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Scrum artefakti
Pārbaudes process ietver
- Lietotāju stāsti: tie ir īss pārbaudāmās sistēmas funkciju skaidrojums. Piemērs apdrošināšanas pakalpojumu sniedzējam ir šāds: "Prēmiju var maksāt, izmantojot tiešsaistes sistēmu."
- Produkta neizpilde: tā ir lietotāju stāstu kolekcija, kas uzņemta detālam produktam. Produkta īpašnieks sagatavo un uztur produkta uzkrājumu. Produkta īpašnieks to piešķir prioritātei, un ikviens to var papildināt ar produkta īpašnieka apstiprinājumu.
- Izlaiduma neizpilde: laidiens ir laika posms, kurā tiek pabeigts atkārtojumu skaits. Produkta īpašnieks saskaņo ar scrum master, lai izlemtu, kuri stāsti būtu jāizplata. Stāsti izlaides žurnālā ir paredzēti, lai tos pabeigtu izlaidumā.
- Sprints: Tas ir noteikts laika posms, lai pabeigtu lietotāju stāstus, ko izlemj produkta īpašnieks un izstrādātāju komanda, parasti 2–4 nedēļas.
- Sprinta atpalicība: tas ir lietotāju stāstu kopums, kas jāpabeidz sprintā. Sprinta atpalicības laikā darbs nekad netiek piešķirts, un komanda pierakstās darbam pati. Tas pieder komandai un to pārvalda, bet aptuvenais atlikušais darbs tiek atjaunināts katru dienu. Tas ir uzdevumu saraksts, kas jāveic programmā Sprint
- Bloķēšanas saraksts: Tas ir bloku un nepieņemto lēmumu saraksts, kas pieder scrum master un tiek atjaunināts katru dienu
- Izdegšanas diagramma: izdegšanas diagramma attēlo pabeigtā un kopējā procesa laikā paveikto darbu kopējo progresu. Tas grafika formātā attēlo nepabeigtos stāstus un funkcijas
3. Ceremonijas (procesi) Scrum
- Sprinta plānošana: Sprints sākas ar to, ka komanda importē stāstus no izlaišanas uzkrājuma sprinta uzkrājumā; to rīko scrum master. Testētāji lēš pūles, lai pārbaudītu dažādus stāstus Sprint Backlog.
- Daily Scrum: to rīko scrum master, tas ilgst apmēram 15 minūtes. Daily Scrum laikā dalībnieki pārrunās iepriekšējā dienā paveikto darbu, nākamās dienas plānotos darbus un sprinta laikā sastopamos jautājumus. Ikdienas stand-up sanāksmes laikā tiek sekots komandas progresam.
- Sprinta apskats / retrospektīva: to rīko arī scrum master, tas ilgst apmēram 2-4 stundas un apspriež, ko komanda ir paveikusi pēdējā sprintā un kādas mācības tika apgūtas.
Testētāja loma Scrum
Testera loma Scrum procesā nav aktīva . Parasti testēšanu veic izstrādātājs ar Unit Test. Kaut arī produkta īpašnieks bieži piedalās testēšanas procesā katra sprinta laikā. Dažos Scrum projektos ir īpašas testēšanas grupas atkarībā no projekta rakstura un sarežģītības .
Nākamais jautājums ir tāds, ko testeris dara, izmantojot pārbaudi? Sekojošā piezīme atbildēs
Pārbaudes aktivitātes Scrum
Testētāji dažādos Scrum-
Sprinta plānošana
- Plānojot sprintu, testētājam jāizvēlas lietotāja stāsts no produkta uzkrājuma, kas jāpārbauda.
- Kā testētājam viņam / viņai jāizlemj, cik stundas (piepūles novērtējums) jāveic, lai pabeigtu katra izvēlētā lietotāja stāsta testēšanu.
- Kā testētājam viņam / viņai jāzina, kādi ir sprinta mērķi.
- Kā testētājs veiciniet prioritāšu noteikšanas procesu
Sprints
- Atbalstiet izstrādātājus vienību testēšanā
- Pēc pabeigšanas pārbaudiet lietotāja stāstu. Testa izpilde tiek veikta laboratorijā, kur gan testētājs, gan izstrādātājs strādā roku rokā. Defekti tiek reģistrēti defektu pārvaldības rīkā, kurus katru dienu izseko. Defektus var piešķirt un analizēt detalizētas sanāksmes laikā. Defekti tiek atkārtoti pārbaudīti, tiklīdz tie ir novērsti un izvietoti testēšanai
- Kā testeris viņš / viņa apmeklē visas ikdienas sanāksmes, lai izteiktos
- Kā testeris viņš / viņa var atnest jebkuru neizpildīto lietu, kuru nevar pabeigt pašreizējā sprintā, un likt uz nākamo sprintu
- Testeris ir atbildīgs par automatizācijas skriptu izstrādi. Viņš plāno automatizācijas testēšanu ar nepārtrauktas integrācijas (KI) sistēmu. Automatizācija saņem nozīmi īso piegādes termiņu dēļ. Testēšanas automatizāciju var veikt, izmantojot dažādus tirgū pieejamos atvērtā koda vai maksas rīkus. Tas izrādās efektīvs, nodrošinot, ka tika pārbaudīts viss pārbaudāmais. Pietiekamu testa pārklājumu var panākt, cieši sazinoties ar komandu.
- Pārskatiet KI automatizācijas rezultātus un nosūtiet ziņojumus ieinteresētajām personām
- Nefunkcionālas pārbaudes veikšana apstiprinātiem lietotāju stāstiem
- Koordinējiet ar klientu un produkta īpašnieku, lai noteiktu pieņemšanas kritērijus pieņemšanas testiem
- Sprinta beigās testeris dažos gadījumos veic arī pieņemšanas testēšanu (UAT) un apstiprina pašreizējā sprinta testēšanas pilnīgumu
Sprinta retrospekcija
- Būdams testeris, viņš noskaidros, kas notika nepareizi un kas notika kārtējā sprintā
- Kā testētājs viņš identificē gūto mācību un labāko praksi
Testa ziņošana
Scrum Test metrikas pārskati nodrošina pārredzamību un redzamību ieinteresētajām personām par projektu. Parādītā metrika komandai ļauj analizēt savu progresu un plānot savu nākotnes stratēģiju produkta uzlabošanai. Ir divi rādītāji, kurus bieži izmanto, lai ziņotu.
Iedegt diagrammu: katru dienu Scrum Master reģistrē aptuveno atlikušo darbu sprintam. Tas nav nekas cits kā Burn Down diagramma. To atjaunina katru dienu.
Dedzināšanas diagramma sniedz ātru pārskatu par projekta gaitu, šajā diagrammā ir informācija, piemēram, kopējais projekta apjoms, kas jāpabeidz, katra paveikto darbu skaits utt.
Ātruma vēstures grafiks: Ātruma vēstures grafiks paredz komandas ātrumu, kas sasniegts katrā sprintā. Tas ir joslu diagramma, kas parāda, kā laika gaitā komandu rezultāti ir mainījušies.
Papildu metrika, kas var būt noderīga, ir ierakstīšanas grafiks, budžeta ierakstīšana, tēmas procentuālā pabeigšana, pabeigtie stāsti - atlikušie stāsti un tā tālāk.
Vai jums ir kādi padomi vai pieredze, ar ko dalīties Scrum testēšanā? Vai atstājiet komentāru zemāk-