Kas yra klaida?
Klaida yra kodavimo gedimo pasekmė / rezultatas.
Programinės įrangos testavimo defektas
Defektas Software Testing yra variantas arba nuokrypis programinės įrangos iš galutinio vartotojo reikalavimus ar originalių verslo reikalavimus. Programinės įrangos defektas yra kodavimo klaida, dėl kurios neteisingi ar netikėti programinės įrangos, neatitinkančios tikrųjų reikalavimų, rezultatai. Testuotojai, vykdydami bandymo atvejus, gali susidurti su tokiais defektais.
Šie du terminai turi labai ploną skirtumų liniją. Pramonėje abu yra gedimai, kuriuos reikia ištaisyti, todėl kai kurios testavimo komandos naudojasi mainais.
Testuotojai, vykdydami bandymo atvejus, gali susidurti su tokiais bandymų rezultatais, kurie prieštarauja laukiamiems rezultatams. Šis testo rezultatų pokytis vadinamas programinės įrangos defektu. Šiuos defektus ar variantus įvairiose organizacijose nurodo skirtingi pavadinimai, pvz., Problemos, problemos, klaidos ar incidentai.
Šioje pamokoje sužinosite
- Pranešimas apie klaidą
- Defektų valdymo procesas
- Atradimas
- Skirstymas į kategorijas
- Rezoliucija
- Patikrinimas
- Uždarymas
- Ataskaitos
- Svarbi defektų metrika
Programinės įrangos testavimo klaidų ataskaita
Re ataskaita Software Testing yra išsamus dokumentas apie klaidas rasti programinės įrangos taikymo. Klaidų ataskaitoje pateikiama kiekviena išsami informacija apie klaidas, pvz., Aprašymas, data, kada rasta klaida, bandytojo, kuris rado, vardas, kūrėjo, kuris ją ištaisė, vardas ir kt. Klaidų ataskaita padeda ateityje nustatyti panašias klaidas, kad jos būtų galima išvengti.
Pranešant apie klaidą kūrėjui, jūsų klaidų ataskaitoje turėtų būti ši informacija
- Defect_ID - unikalus defekto identifikavimo numeris.
- Defekto aprašymas - išsamus defekto aprašymas, įskaitant informaciją apie modulį, kuriame buvo rastas defektas.
- Versija - programos, kurioje rastas defektas, versija.
- Žingsniai - išsamūs žingsniai kartu su ekrano kopijomis, kuriomis kūrėjas gali atkurti defektus.
- Data pakelta - data, kai defektas iškeliamas
- Nuoroda - kur jūs pateikite nuorodą į tokius dokumentus kaip. reikalavimai, dizainas, architektūra ar net klaidos ekrano kopijos, padėsiančios suprasti defektą
- Aptiktas pagal - defektą iškėlusio bandytojo vardas / ID
- Statusas - defekto būsena, apie tai vėliau
- Fixed by - kūrėjo, kuris jį pataisė, vardas / ID
- Data uždaryta - data, kai defektas yra uždarytas
- Sunkumas , apibūdinantis defekto poveikį programai
- Prioritetas , susijęs su trūkumų šalinimo skubumu. Rimtumo prioritetas gali būti didelis / vidutinis / mažas, atsižvelgiant į smūgio skubumą, pagal kurį defektas turėtų būti atitinkamai pašalintas
Spustelėkite čia, jei vaizdo įrašas nepasiekiamas
Ištekliai
Atsisiųskite defektų ataskaitų šablono pavyzdį
Apsvarstykite šiuos dalykus kaip „Test Manager“
Bandydama „Guru99 Banking“ projektą, jūsų komanda rado klaidų.
Po savaitės kūrėjas atsakys -
Kitą savaitę bandytojas atsako
Kaip ir minėtu atveju, jei defektų perdavimas vyksta žodžiu, netrukus viskas tampa labai sudėtinga. Norint kontroliuoti ir efektyviai valdyti klaidas, reikia defektų gyvavimo ciklo.
Kas yra defektų valdymo procesas?
Defektų valdymas yra sistemingas procesas, skirtas nustatyti ir pašalinti klaidas. Defektų valdymo cikle yra šie etapai: 1) defektų atradimas, 2) defektų kategorija 3) defektų šalinimas kūrėjų 4) testuotojų patikrinimas, 5) defektų uždarymas 6) defektų ataskaitos projekto pabaigoje
Ši tema padės jums sužinoti, kaip pritaikyti defektų valdymo procesą projekto „Guru99 Bank“ svetainėje. Norėdami valdyti defektus, galite atlikti toliau nurodytus veiksmus.
Atradimas
Atradimo etape projekto komandos turi atrasti kuo daugiau defektų , kol galutinis klientas gali juos aptikti. Defektas yra sakoma, kad bus atrasta ir pakeitimas statuso priimta , kai ji pripažino ir patvirtino kūrėjams
Pagal pirmiau pateiktą scenarijų bandytojai aptiko 84 trūkumus svetainėje „Guru99“.
Pažvelkime į šį scenarijų; jūsų bandymų komanda aptiko keletą problemų „Guru99“ banko svetainėje. Jie laiko juos defektais ir pranešė kūrėjų komandai, tačiau yra konfliktas -
Tokiu atveju, kaip bandymų vadovas, ką darysi?
A) Sutarkite su bandymų grupe, kad tai yra trūkumas
B) Testų vadovas imasi teisėjo vaidmens, kad nuspręstų, ar problema yra trūkumas, ar ne
C) sutinka su plėtros komanda, kuri nėra defektas ištaisyti netikslius
Tokiu atveju konfliktui išspręsti turėtų būti taikomas sprendimo procesas. Jūs sprendžiate teisėjo vaidmenį sprendžiant, ar svetainės problema yra trūkumas, ar ne.
Skirstymas į kategorijas
Defektų skirstymas į kategorijas padeda programinės įrangos kūrėjams nustatyti prioritetus savo užduotims. Tai reiškia, kad toks prioritetas padeda kūrėjams pirmiausia pašalinti tuos trūkumus, kurie yra labai svarbūs.
Defektus paprastai skirsto bandymų tvarkyklė -
Atlikime nedidelį pratimą, kaip parodyta žemiau esančiame „Nuvilkite ir nuleiskite defektų prioritetą“
- Kritinis
- Aukštas
- Vidutinis
- Žemas
| 1) Svetainės veikimas yra per lėtas |
|
| 2) Tinklalapio prisijungimo funkcija neveikia tinkamai |
|
| 3) Svetainės GUI neteisingai rodoma mobiliuosiuose įrenginiuose |
|
| 4) Svetainė negalėjo prisiminti vartotojo prisijungimo sesijos |
|
| 5) Kai kurios nuorodos neveikia |
|
Čia yra rekomenduojami atsakymai
| Nr. | apibūdinimas | Prioritetas | Paaiškinimas |
|---|---|---|---|
| 1 | Svetainės našumas yra per lėtas | Aukštas | Našumo klaida gali sukelti didžiulius nepatogumus vartotojui. |
| 2 | Tinklalapio prisijungimo funkcija neveikia tinkamai | Kritinis | Prisijungimas yra viena iš pagrindinių banko svetainės funkcijų, jei ši funkcija neveikia, tai yra rimtos klaidos |
| 3 | Svetainės GUI neteisingai rodoma mobiliuosiuose įrenginiuose | Vidutinis | Defektas paveikia vartotoją, kuris naudojasi „Smartphone“ svetainei peržiūrėti. |
| 4 | Svetainė negalėjo prisiminti vartotojo prisijungimo sesijos | Aukštas | Tai rimta problema, nes vartotojas galės prisijungti, bet negalės atlikti jokių kitų operacijų |
| 5 | Kai kurios nuorodos neveikia | Žemas | Tai lengva išspręsti kūrėjų vaikinams ir vartotojas vis tiek gali pasiekti svetainę be šių nuorodų |
Defektų sprendimas
Defektų sprendimas programinės įrangos bandymuose yra žingsnis po žingsnio, siekiant pašalinti defektus. Defektų sprendimo procesas prasideda nuo defektų priskyrimo kūrėjams, tada kūrėjai planuoja defektą ištaisyti pagal prioritetą, tada defektai pašalinami ir galiausiai kūrėjai išsiunčia sprendimo ataskaitą bandymų vadybininkui. Šis procesas padeda lengvai ištaisyti ir nustatyti defektus.
Norėdami pašalinti defektą, galite atlikti šiuos veiksmus.
- Užduotis : paskirtas kūrėjui ar kitam technikui taisyti ir pakeitė būseną į Atsakymas .
- Tvarkaraščio taisymas : šiame etape atsakomybę prisiima kūrėjo pusė. Jie sukurs šių defektų šalinimo tvarkaraštį, priklausantį nuo defekto prioriteto.
- Ištaisykite defektą : Kol kūrėjų komanda taiso defektus, „Test Manager“ stebi defekto šalinimo procesą, palyginti su aukščiau pateiktu tvarkaraščiu.
- Pranešti apie rezoliuciją : gaukite kūrėjų rezoliucijos ataskaitą, kai trūkumai bus pašalinti.
Patikrinimas
Kūrėjų komandai ištaisius ir pranešus apie defektą, bandymų komanda patikrina , ar defektai iš tikrųjų buvo pašalinti.
Pavyzdžiui, pagal pirmiau pateiktą scenarijų, kai kūrėjų komanda pranešė, kad jie jau ištaisė 61 defektą, jūsų komanda dar kartą bandys patikrinti, ar šie defektai iš tikrųjų buvo pašalinti.
Uždarymas
Kai defektas buvo išspręsta ir patikrinti, defektas pasikeitė statusą uždarytas . Jei ne, turite išsiųsti pranešimą programinei įrangai, kad vėl patikrintumėte defektą.
Pranešimas apie defektus
Defektų ataskaitų teikimas programinės įrangos testavime yra procesas, kurio metu testų vadovai parengia ir siunčia defektų ataskaitą valdymo komandai, kad ši pateiktų atsiliepimus apie defektų valdymo procesą ir defektų būklę. Tada valdymo komanda patikrina defektų ataskaitą ir, jei reikia, siunčia atsiliepimus arba teikia tolesnę pagalbą. Pranešimas apie defektus padeda geriau bendrauti, sekti ir išsamiai paaiškinti trūkumus.
Valdyba turi teisę žinoti apie defekto būklę. Jie turi suprasti defektų valdymo procesą, kad galėtų jus paremti šiame projekte. Todėl turite pranešti jiems apie esamą defekto situaciją, kad gautumėte atsiliepimų.
Svarbi defektų metrika
Atgal į aukščiau pateiktą scenarijų. Kūrėjas ir bandymų grupės apžvelgė praneštus defektus. Čia yra tos diskusijos rezultatas
Kaip išmatuoti ir įvertinti testo vykdymo kokybę?
Tai yra klausimas, kurį nori žinoti kiekvienas bandymų vadovas. Yra 2 parametrai, kuriuos galite laikyti šiais
Pagal pirmiau pateiktą scenarijų galite apskaičiuoti defektų atmetimo koeficientą (DRR) 20/84 = 0,238 (23,8%).
Kitas pavyzdys, tariamai, „Guru99“ banko svetainėje yra iš viso 64 defektai, tačiau jūsų bandymų komanda aptiko tik 44 defektus, ty jie praleido 20 defektų. Todėl galite apskaičiuoti defekto nuotėkio santykį (DLR) 20/64 = 0,312 (31,2%).
Išvada: bandymo vykdymo kokybė vertinama pagal šiuos du parametrus
Mažesnė DRR ir DLR vertė, tuo geresnė bandymo vykdymo kokybė. Koks santykio diapazonas yra priimtinas ? Šis diapazonas gali būti apibrėžtas ir priimtas pagal projekto tikslą arba galite nurodyti panašių projektų metriką.
Šiame projekte rekomenduojama priimtino santykio vertė yra 5 ~ 10%. Tai reiškia, kad bandymo vykdymo kokybė yra prasta. Turėtumėte rasti atsakomųjų priemonių, kad sumažintumėte šiuos santykius, pvz
- Pagerinti nario testavimo įgūdžius.
- Skirkite daugiau laiko vykdymo testavimui, ypač bandymo vykdymo rezultatų peržiūrai.
