defect severity priority testing with examples
I denne vejledning lærer du, hvad der er Defekt Sværhedsgrad og Prioritet i test, hvordan man indstiller defektprioritet og sværhedsgrader med eksempler for at forstå konceptet tydeligt.
Vi vil også i detaljer dække, hvordan man klassificerer manglerne under forskellige spande og deres relevans i defektlivscyklussen. Vi vil også dække klassificeringens afgørende rolle med et live sæt eksempler.
Arkiveringsfejl er meget integreret del af softwaretestningens livscyklus . Der er adskillige bedste praksis defineret til effektiv fejlrapportering over internettet eller i organisationer.
Hvad du lærer:
- Oversigt over mangelsporing
Oversigt over mangelsporing
Et af de vigtige aspekter af defektets livscyklus på et generisk niveau inkluderer sporing af mangler. Dette er vigtigt, fordi testteamene åbner flere fejl, når de tester et stykke software, der kun ganges, hvis det specifikke system, der testes, er komplekst. I et sådant scenario kan det være en skræmmende opgave at håndtere disse mangler og analysere disse fejl for at skabe lukning.
I tråd med vedligeholdelsesprocesser for mangler, når en tester arkiverer en defekt bortset fra metoden / beskrivelsen for at reproducere det sete problem, skal han også fremlægge nogle kategoriske oplysninger, der kan hjælpe med unøjagtig klassificering af manglen. Dette vil til gengæld hjælpe med effektive sporing / vedligeholdelsesprocesser for defekter og vil også danne grundlaget for hurtigere fejltid.
De to hovedparametre, der danner grundlaget for effektiv fejlsporing og løsning, er:
- Defektprioritet i test
- Defekt sværhedsgrad ved testning
Disse er ofte et forvirrende koncept og bruges næsten udskifteligt blandt ikke kun testhold, men også udviklingsteams. Der er en fin linje mellem de to, og det er vigtigt at forstå, at der faktisk er forskelle mellem de to.
Lad os kort forstå de teoretiske definitioner af de to parametre i det næste afsnit.
Hvad er sværhedsgrad og prioritet?
Prioritet ved den engelske definition bruges i sammenligningen af to ting eller betingelser, hvor den ene skal tildeles mere betydning end den anden (de andre) og skal tackles med / løses først, før du går videre til den næste (de). Derfor skal en prioritets defekt i forbindelse med mangler angive, hvor hurtigt det er nødvendigt at rette det.
Alvorligheden ifølge den engelske definition bruges til at beskrive alvorligheden af en uønsket begivenhed. Derfor, når det kommer til bugs, vil sværhedsgraden af en bug indikere den virkning det har på systemet med hensyn til dets indvirkning.
Hvem definerer disse?
QA klassificerer manglen under passende sværhedsgrad baseret på manglenes kompleksitet og kritiske karakter.
Enhver forretningsinteresse, herunder projektledere, forretningsanalytikere, produktejere, definerer prioriteten for manglerne.
Nedenstående figur viser rollen, der ejer og klassificerer manglenes kritik og sværhedsgrad.
Hvordan vælger du disse niveauer?
Som vi allerede har diskuteret, vurderes sværhedsgraden af testeren, mens prioritetsparameteren hovedsageligt vurderes af Product Manager eller dybest set triage-teamet. Selvom dette er tilfældet, er sværhedsgraden af en defekt bestemt en af de styrende og påvirkende faktorer til prioritering af manglen. Derfor er det vigtigt som tester at vælge den rigtige sværhedsgrad for at undgå forveksling med udviklingsteams.
Forskellen mellem sværhedsgrad og prioritet
Prioritet er forbundet med planlægning, og 'sværhedsgrad' er forbundet med standarder.
'Prioritet' betyder, at der gives noget eller fortjener forudgående opmærksomhed; forrang fastlagt efter rækkefølge af betydning (eller haster).
'Alvorlighed' er tilstanden eller kvaliteten af at være alvorlig; alvorlig indebærer overholdelse af strenge standarder eller høje principper og antyder ofte hårdhed; alvorlig er præget af eller kræver streng overholdelse af strenge standarder eller høje principper, For eksempel, en alvorlig adfærdskodeks.
Ordene prioritet og sværhedsgrad kommer op i bug tracking.
En række kommercielle, softwareværktøjer til sporing af problemer er tilgængelige. Disse værktøjer med detaljeret input fra softwaretestingeniører giver teamet fuldstændige oplysninger, så udviklere kan forstå fejlen, få en idé om dens 'Severity', reproducere den og rette den.
Rettelserne er baseret på projekt 'Prioriteter' og 'Alvorlighed' af fejl.
Problemets 'sværhedsgrad' defineres i overensstemmelse med kundens risikovurdering og registreres i deres valgte sporingsværktøj.
Buggysoftware kan 'alvorligt' påvirke tidsplaner, hvilket igen kan føre til en revurdering og genforhandling af 'prioriteter'.
Hvad er prioritet?
Prioritet, som navnet antyder, handler om at prioritere en mangel baseret på forretningsbehov og sværhedsgraden af manglen. Prioritet betyder vigtigheden eller haster med at rette en defekt.
Under åbning af en defekt tildeler testeren generelt prioriteten, da han ser produktet fra slutbrugerperspektivet. I tråd med disse er der forskellige niveauer:
Generelt kan prioritet af mangler klassificeres som følger:
Prioritet nr. 1) Umiddelbar / kritisk (P1)
Dette skal rettes straks inden for 24 timer. Dette sker normalt i tilfælde, hvor en hel funktionalitet er blokeret, og ingen test kan fortsætte som et resultat af dette. Eller i visse andre tilfælde, hvis der er betydelige lækager i hukommelsen, klassificeres defekten generelt som en prioritet -1, hvilket betyder, at programmet / funktionen er ubrugelig i den aktuelle tilstand.
Enhver defekt, der kræver øjeblikkelig opmærksomhed, som påvirker testprocessen, klassificeres under den umiddelbare kategori
Alle Kritisk sværhedsgrad mangler falder ind under denne kategori (medmindre de prioriteres igen af virksomheder / interessenter)
Prioritet nr. 2) Høj (P2)
Når de kritiske mangler er blevet rettet, er en defekt med denne prioritet den næste kandidat, der skal løses for enhver testaktivitet, der svarer til 'exit' -kriterierne. Normalt når en funktion ikke er anvendelig som den skal på grund af en programdefekt, eller hvis der skal skrives en ny kode eller nogle gange endda fordi et miljøproblem skal håndteres gennem koden, kan en defekt kvalificere sig til en prioritet 2 .
Dette er den mangel eller det problem, der skal løses, inden frigivelsen foretages. Disse mangler skal løses, når de kritiske problemer er løst.
Alle Major alvorlighed defekter falder inden for denne kategori.
Prioritet # 3) Medium (P3)
En mangel med denne prioritet skal være i strid for at blive rettet, da den også kan håndtere funktionalitetsproblemer, der ikke er som forventet. Nogle gange kan selv kosmetiske fejl som at forvente den rigtige fejlmeddelelse under fejlen kvalificere til at være en prioritets 3-defekt.
Denne fejl skal løses, når alle de alvorlige fejl er rettet.
Når de kritiske og højt prioriterede fejl er færdige, kan vi gå efter de mellemstore prioritetsfejl.
Alle Mindre alvorlighed defekter falder inden for denne kategori.
tidskortapp til iPhone og Android
Prioritet # 4) Lav (P4)
En fejl med lav prioritet indikerer, at der bestemt er et problem, men det behøver ikke at blive rettet for at matche 'exit' -kriterierne. Dette skal dog rettes, før GA er færdig. Typisk kunne nogle skrivefejl eller endda kosmetiske fejl som diskuteret tidligere kategoriseres her.
Nogle gange åbnes også defekter med lav prioritet for at antyde nogle forbedringer i det eksisterende design eller en anmodning om at implementere en lille funktion for at forbedre brugeroplevelsen.
Denne fejl kan løses i fremtiden og behøver ikke øjeblikkelig opmærksomhed og Lav sværhedsgrad defekter falder inden for denne kategori.
Som allerede beskrevet diskuterer prioritet, hvor hurtigt defektens leveringstid skal være. Hvis der er flere fejl, afgør prioriteten, hvilken fejl der skal rettes og bekræftes straks versus hvilken fejl, der kan rettes lidt senere.
Hvad er sværhedsgrad?
Alvorlighed definerer, i hvilket omfang en bestemt defekt kan påvirke applikationen eller systemet.
Alvorligheden er en parameter, der betegner implikationen af defekt på systemet - hvor kritisk defekt er, og hvad er indvirkningen af defekten på hele systemets funktionalitet? Sværhedsgraden er en parameter, der er indstillet af testeren, mens han åbner en defekt og hovedsagelig har kontrol over testeren. Igen forskellige organisationer har forskellige værktøjer til at bruge til mangler, men på et generisk niveau er disse følgende sværhedsgrader:
For eksempel, Overvej følgende scenarier
- Hvis brugeren forsøger at handle online, og applikationen ikke indlæses, eller der vises en meddelelse om serveren er utilgængelig.
- Brugeren udfører at tilføje en vare i vognen, antallet af tilføjede mængder er forkert / forkert produkt tilføjes.
- Brugeren foretager betalingen, og efter betalingen forbliver ordren i vognen som reserveret i stedet bekræftet.
- Systemet accepterer ordren, men til sidst annullerer ordren efter en halv time på grund af eventuelle problemer.
- Systemet accepterer kun 'Tilføj til kurv' ved dobbeltklik i stedet for på et enkelt klik.
- Knappen Føj til kurv er stavet som Føj til kurv.
Hvad ville brugeroplevelsen være, hvis nogen af ovenstående scenarier kunne ske?
Generelt kan fejlene klassificeres som følger:
# 1) Kritisk (S1)
En defekt, der fuldstændig hæmmer eller blokerer test af produktet / funktionen, er en kritisk defekt. Et eksempel kan være i tilfælde af UI-test, hvor brugergrænsefladen efter at have gennemgået en guide bare hænger i en rude eller ikke går længere for at udløse funktionen. Eller i nogle andre tilfælde, hvor den udviklede funktion selv mangler i bygningen.
Af en eller anden grund, hvis applikationen går ned, eller den bliver ubrugelig / ikke i stand til at gå videre, kan defekten klassificeres under kritisk sværhedsgrad.
Eventuelle katastrofale systemfejl kan føre brugeren til, at applikationerne ikke kan bruges, kan klassificeres under kritisk sværhedsgrad
For eksempel, I e-mail-udbyderen som Yahoo eller Gmail, efter at have skrevet det korrekte brugernavn og adgangskoden, går systemet ned i stedet for at logge ind, eller kaster fejlmeddelelsen. Denne defekt er klassificeret som kritisk, da denne fejl gør hele applikationen ubrugelig.
Scenariet på punkt 1, der er diskuteret ovenfor, kunne klassificeres som kritisk defekt, da online-applikationen bliver helt ubrugelig.
# 2) Major (S2)
Enhver større funktion implementeret, der ikke lever op til kravene / anvendelsestilfælde og opfører sig anderledes end forventet, kan klassificeres under større alvor.
En større fejl opstår, når funktionaliteten fungerer groft væk fra forventningerne eller ikke gør, hvad den skal gøre. Et eksempel kan være: Sig, at der skal installeres et VLAN på kontakten, og at du bruger en brugergrænsefladeskabelon, der udløser denne funktion. Når denne skabelon til konfiguration af VLAN mislykkes på kontakten, klassificeres den som en alvorlig funktionalitets ulempe.
For eksempel, I e-mail-udbyderen som Yahoo eller Gmail, når du ikke har tilladelse til at tilføje mere end en modtager i CC-sektionen, klassificeres denne defekt som den store fejl, da applikationens hovedfunktionalitet ikke fungerer korrekt.
Hvad der forventes CC-sektionens opførsel i mailen, skal det give brugeren mulighed for at tilføje flere brugere. Så når applikationens hovedfunktionalitet ikke fungerer korrekt, eller når den opfører sig anderledes end forventet, er det en større fejl.
Scenarierne på punkt 2 og 3 diskuteret ovenfor kunne klassificeres som større defekter, da ordren forventes at flytte glat til den næste fase af ordrenes livscyklus, men i virkeligheden varierer den i adfærd.
Enhver defekt, der kan føre til ukorrekt datatilbageholdelse, dataproblemer eller forkert applikationsadfærd, kunne stort set klassificeres under den største sværhedsgrad.
# 3) Mindre / Moderat (S3)
Enhver implementeret funktion, der ikke lever op til kravene / anvendelsestilfælde og opfører sig anderledes end forventet, men virkningen er ubetydelig til en vis grad, eller hvis den ikke har stor indflydelse på applikationen, kan klassificeres under Mindre alvor.
En moderat defekt opstår, når produktet eller applikationen ikke opfylder visse kriterier eller stadig udviser en eller anden unaturlig adfærd, men funktionaliteten som helhed påvirkes ikke. For eksempel i VLAN-skabelonen implementeret ovenfor, ville en moderat eller normal defekt opstå, når skabelonen implementeres med succes på kontakten, men der er ingen indikation, der sendes til brugeren.
For eksempel, I e-mail-tjenesteudbyderen som Yahoo eller Gmail er der mulighed kaldet 'Vilkår og betingelser', og i denne mulighed vil der være flere links angående webstedets vilkår og betingelser, når en blandt de mange links ikke fungerer fint, det kaldes som mindre sværhedsgrad, da det kun påvirker applikationens mindre funktionalitet, og det har ikke stor indflydelse på anvendelighed af applikationen.
Scenariet på punkt 5, der er diskuteret ovenfor, kunne klassificeres som mindre defekt, da der ikke er datatab eller -fejl i systemflowrækkefølgen, men en lille besvær, når det kommer til brugeroplevelse.
Disse typer fejl resulterer i minimalt tab af funktionalitet eller brugeroplevelse.
# 4) Lav (S4)
Kosmetiske defekter, herunder stavefejl eller problemer med tilpasning eller skrifttype, kan klassificeres under lav sværhedsgrad.
En mindre fejl med lav sværhedsgrad opstår, når der næsten ikke er nogen indvirkning på funktionaliteten, men det stadig er en gyldig fejl, der skal rettes. Eksempler på dette kan omfatte stavefejl i fejlmeddelelser, der udskrives til brugerne, eller mangler for at forbedre udseendet og følelsen af en funktion.
For eksempel, I e-mail-udbyderen som Yahoo eller Gmail, ville du have bemærket “Licens-siden”. Hvis der er stavefejl eller fejljustering på siden, er denne defekt klassificeret som Lav.
Scenariet på punkt 6 diskuteret ovenfor kunne klassificeres som lav defekt, da knappen Tilføj vises i forkert omslag. Denne form for fejl vil ikke have nogen indflydelse på systemadfærd eller datapræsentation eller datatab eller datastrøm eller endda brugeroplevelse, men vil være meget kosmetisk.
For at opsummere viser følgende figur den brede defektklassificering baseret på sværhedsgrad og prioritet:
Eksempler
Som allerede nævnt, da forskellige organisationer bruger forskellige slags værktøjer til mangelfølgning og dens relaterede processer, bliver det et fælles sporingssystem mellem forskellige ledelsesniveauer og det tekniske personale.
Da defekt sværhedsgrad er mere inden for funktionaliteten, indstiller testingeniøren sværhedsgraden af defekten. Til tider deltager udviklerne i at påvirke defektens sværhedsgrad, men det afhænger for det meste af testeren, da han vurderer, hvor meget en bestemt funktion kan påvirke den generelle funktion.
På den anden side, når det kommer til indstilling af defektprioritet, selvom oprindeligt defektopretteren prioriterer, defineres det faktisk af Product Manager, da han har et samlet overblik over produktet, og hvor hurtigt en bestemt defekt skal løses . En tester er ikke en ideel person til at indstille defektprioriteten.
Chokerende som dette kan synes, der er to forskellige eksempler på hvorfor:
Eksempel 1) Overvej, at der er en situation, hvor brugeren finder en fejl i navngivningen af selve produktet eller et eller andet problem med UI-dokumentationen. En tester åbner normalt en mindre / kosmetisk defekt og kan være meget enkel at rette, men når det kommer til produktets udseende og brugeroplevelse, kan det medføre alvorlig indvirkning.
Eksempel 2) Der kan være visse betingelser, under hvilke en bestemt defekt opstår, som kan være en ekstremt sjælden eller ingen mulighed for at ramme i kundemiljøet. Selvom funktionalitetsmæssigt kan dette virke som en højprioritetsfejl for en tester i betragtning af dens sjældenhed af forekomst og høje omkostninger at rette - dette vil blive klassificeret som en lavprioritetsfejl.
Derfor er defektprioriteten generelt indstillet af produktchefen i et 'defekt triage' -møde.
Forskellige niveauer
Prioritet og sværhedsgrad har nogle klassifikationer blandt dem, der hjælper med at bestemme, hvordan manglen skal håndteres. Mange forskellige organisationer har det forskellige fejllogningsværktøjer , så niveauerne kan variere.
Lad os se på de forskellige niveauer for både Prioritet og Alvorlighed.
- Høj prioritet, høj sværhedsgrad
- Høj prioritet, lav sværhedsgrad
- Høj sværhedsgrad, lav prioritet
- Lav sværhedsgrad, lav prioritet
Følgende figur viser klassificeringen af kategorierne i et enkelt uddrag.
# 1) Høj sværhedsgrad og høj prioritet
Enhver kritisk / større forretningsfejl bliver automatisk forfremmet til denne kategori.
Eventuelle fejl, som testet ikke kan fortsætte for enhver pris eller medfører, at en alvorlig systemfejl falder ind under denne kategori. For eksempel, ved at klikke på en bestemt knap indlæses ikke selve funktionen. Eller at udføre en bestemt funktion bringer serveren konsekvent ned og forårsager datatab. De røde streger i ovenstående figur angiver denne slags fejl.
For eksempel,
Systemet går ned, efter du har foretaget betalingen, eller når du ikke er i stand til at tilføje varerne til indkøbskurven, er denne fejl markeret som høj alvorlighedsgrad og høj prioritetsfejl.
Et andet eksempel ville være ATM-vendingvalutafunktion, hvor maskinen efter indtastning af det korrekte brugernavn og adgangskode ikke dispenserer penge, men trækker det overførte fra din konto.
# 2) Høj prioritet og lav sværhedsgrad
Eventuelle mindre alvorlighedsfejl, der direkte kan påvirke brugeroplevelsen, promoveres automatisk til denne kategori.
Fejl, der skal løses, men som ikke påvirker applikationen, falder ind under denne kategori.
For eksempel, det forventes, at funktionen viser en bestemt fejl for brugeren med hensyn til dens returkode. I dette tilfælde kaster koden funktionelt en fejl, men meddelelsen skal være mere relevant for den genererede returkode. De blå linjer i figuren angiver denne slags fejl.
For eksempel,
Virksomhedens logo på forsiden er forkert, det anses for at være Høj prioritet og lav sværhedsgrad defekt .
Eksempel 1) På websiden Online shopping, når FrontPage-logoet er stavet forkert, f.eks. I stedet for Flipkart, staves det som Flipkart.
Eksempel 2) I bankens logo er det i stedet for ICICI skrevet som ICCCI.
Med hensyn til funktionalitet påvirker det ikke noget, så vi kan markere som lav sværhedsgrad, men det har en indvirkning på brugeroplevelsen. Denne form for fejl skal rettes højt, selvom de har meget mindre indflydelse på applikationssiden.
# 3) Høj sværhedsgrad og lav prioritet
Enhver defekt, der funktionelt ikke opfylder kravene eller har nogen funktionelle implikationer på systemet, men som sidestilles med bagsædet af interessenterne, når det kommer til forretningskritisk, bliver automatisk forfremmet til denne kategori.
Fejl, der skal løses, men ikke med det samme. Dette kan specifikt forekomme under ad hoc-test. Det betyder, at funktionaliteten i høj grad påvirkes, men kun observeres, når visse usædvanlige inputparametre bruges.
For eksempel, en bestemt funktionalitet kan kun bruges på en senere version af firmwaren, så for at kontrollere dette - testeren nedgraderer faktisk sit system og udfører testen og observerer et alvorligt funktionalitetsproblem, der er gyldigt. I et sådant tilfælde klassificeres manglerne i denne kategori med lyserøde linjer, da det normalt forventes, at slutbrugere har en højere version af firmwaren.
For eksempel,
På et socialt netværkswebsted, hvis en betaversion af en ny funktion frigives med ikke mange aktive brugere, der bruger denne facilitet i dag. Enhver defekt, der findes på denne funktion, kan klassificeres som en lav prioritet, da funktionen tager bagsæde på grund af forretningsklassificering som ikke vigtig.
Selvom denne funktion har en funktionsfejl, da den ikke påvirker slutkunderne direkte, kan en forretningsinteressent klassificere manglen under lav prioritet, selvom den har en alvorlig funktionel indvirkning på applikationen.
Dette er en høj alvorlighedsfejl, men kan prioriteres til lav prioritet, da den kan løses med den næste udgivelse som en anmodning om ændring. Forretningsinteressenter prioriterer også denne funktion som en sjældent anvendt funktion og påvirker ikke andre funktioner, der har direkte indflydelse på brugeroplevelsen. Denne form for fejl kan klassificeres under Høj sværhedsgrad, men lav prioritet kategori.
# 4) Lav sværhedsgrad og lav prioritet
Eventuelle stavefejl / skrifttype / forkert justering i afsnit 3rdeller 4thapplikationens side og ikke på hovedsiden eller forsiden / titlen.
Disse fejl er klassificeret i de grønne linjer som vist i figuren og opstår, når der ikke er nogen funktionalitetspåvirkning, men stadig ikke opfylder standarderne i ringe grad. Generelt klassificeres kosmetiske fejl eller siger dimensioner af en celle i en tabel på brugergrænsefladen her.
For eksempel,
Hvis privatlivspolitikken på hjemmesiden har en stavefejl, indstilles denne fejl som Lav sværhedsgrad og lav prioritet.
Retningslinier
Nedenfor er visse retningslinjer, som hver tester skal forsøge at følge:
- For det første skal du forstå begreberne prioritet og sværhedsgrad. Undgå at forveksle den ene med den anden og bruge dem ombytteligt. I overensstemmelse med dette skal du følge de alvorlighedsretningslinjer, der er offentliggjort af din organisation / dit team, så alle er på samme side.
- Vælg altid sværhedsgraden ud fra problemtypen, da dette vil påvirke dens prioritet. Nogle eksempler er:
- For et problem, der er kritisk, f.eks. Går hele systemet ned, og der kan ikke gøres noget - denne sværhedsgrad bør ikke bruges til at løse programdefekter.
- For et problem, der er stort, f.eks. I tilfælde, hvor funktionen ikke fungerer som forventet - kan denne sværhedsgrad bruges til at løse nye funktioner eller forbedring af det aktuelle arbejde.
Husk, at valg af det rigtige sværhedsgrad vil igen give fejlen, det er den rette prioritet.
- Som tester - forstå hvordan en bestemt funktionalitet snarere borer ned yderligere - forstå hvordan et bestemt scenario eller testtilfælde vil påvirke slutbrugeren. Dette involverer meget samarbejde og interaktion med udviklingsteamet, forretningsanalytikere, arkitekter, testledelse, udviklingsledelse. I dine diskussioner skal du også indregne, hvor lang tid det ville tage at rette manglen på baggrund af dens kompleksitet og tid til at bekræfte denne mangel.
- Langt om længe , det er altid den produktindehaver, der har vetoret for frigivelsen, som manglen skal afhjælpes. Men da defekt-triagesessionerne indeholder forskellige medlemmer for at præsentere deres perspektiv på manglen på et sagsgrundlag, på et sådant tidspunkt, hvis udviklerne og testerne er synkroniserede, hjælper det helt sikkert med at påvirke beslutningen.
Konklusion
Mens man åbner defekter, er det en testers ansvar at tildele fejlen den rette sværhedsgrad. Forkert sværhedsgrad og dermed prioriteret kortlægning kan have meget drastiske konsekvenser for den samlede STLC-proces og produktet som helhed. I flere jobinterviews - der er flere spørgsmål, der stilles om prioritet og sværhedsgrad for at sikre, at du som tester har disse begreber upåklageligt klare i dit sind.
bedste gratis oprydningssoftware til Windows 10
Vi havde også set live eksempler på, hvordan man klassificerer manglen under forskellige spande med alvorlighedsgrad / prioritet. Nu ønsker jeg, at du havde tilstrækkelig afklaring om defektklassificering både i sværhedsgrad / prioritetsspande.
Håber, at denne artikel er en komplet guide til forståelse af defektprioriteten og sværhedsgraden. Fortæl os dine tanker / spørgsmål i kommentarerne nedenfor.
Anbefalet læsning
- Hvad er defektbaseret testteknik?
- Hvad er defekt / bug livscyklus i softwaretest? Vejledning i defekt livscyklus
- Process for defekthåndtering: Sådan håndteres en defekt effektivt
- Sådan reproduceres en ikke-reproducerbar defekt og gør din testindsats det værd
- 7 Principper for softwaretest: Fejlklyngedannelse og Pareto-princip
- Metoder og teknikker til forebyggelse af defekter
- Den nøjagtige forskel mellem verifikation og validering med eksempler
- 3 strategier til håndtering af en blokeringsfejl