Introduktion til defekt
Hver gang en software ikke fungerer som forventet, siges den at have en defekt. Så hvad er egentlig en mangel? Det kan betragtes som en afvigelse eller variation fra de originale funktionelle krav. Når en tester udfører en testsag og ser en modsigelse fra det forventede resultat, findes der en mangel. Det skal styres, indtil det er løst. Alle dens detaljer skal gemmes og spores, indtil de er i overensstemmelse med de forventede funktionskrav.
Hvad er defektstyringsprocessen?
Denne proces involverer at detektere og rette dem.
- Forebyggelse
- Leverbar baseline
- Opdagelse
- Løsning
- Procesforbedring
Lad os gennemgå processen i detaljer.
1. Forebyggelse
For at fjerne alle mangler er den bedste måde at forhindre dem i at komme. Dette hjælper med at spare penge og er meget omkostningseffektiv. For at nå dette trin er det meget vigtigt, at alle mangler skal blive fanget i de tidlige stadier af testen. Hovedmålet her kan være at minimere den påvirkning, en mangel har. Dette kan gøres ved at følge trin:
- Identificer kritisk risiko: De kritiske områder i systemet skal identificeres på forhånd, så påvirkningen er mindre eller slet ikke der, når testen udføres.
- Estimering af forventet indvirkning: Når risikoen først er identificeret, skal der samles en skøn over, hvordan virkningen kan påvirke økonomisk, hvis den faktiske risiko slipper til produktion.
- Minimering af forventet indvirkning: En liste over risici findes ved denne analyse. De øverste risici ville være skadelige, og disse bør være dem, der skal minimeres eller fjernes. De, der ikke kan fjernes fuldstændigt, reducerer sandsynligheden for forekomst af denne defekt.
2. Leverbar baseline
En basislinje er, når en foruddefineret milepæl nås. Når dette trin er nået, sikres det, at når produktet flytter fra et trin til et andet. Idet produktet fortsætter med at bevæge sig fra et trin til et andet, går alle eksisterende defekter også videre med produktets udvikling. Milepælen har en frist, og hvis fejlen er rettet, inden den når denne frist, er det ikke en mangel. Når kodningen og enhedstesten er udført, siges koden at være baselined og flyttet til systemtest. Når problemet er fundet i systemtest, hæves defekten. Den baselined leverbare er den, hvor alle leverancer er afsluttet, og alle mulige fejl er rettet.
3. Opdagelse
Manglen siges at blive opdaget, når den bringes til alles opmærksomhed. Udviklingsholdet efter analysen accepteres af udviklingsholdet, der skal rettes. Her skal det kontrolleres, før de bliver en blokerer. Når testteamet finder fejlen, er det testernes ansvar at informere udviklingsholdet og sørge for, at fejlen er anerkendt. Når bekræftelsen er modtaget, kan de fortsætte med defekten for at validere den og give en rettelse for den.
4. Opløsning
Når fejlen er rapporteret, skal udviklingsteamet bevæge sig mod dens opløsning. De skal analysere og derefter prioritere at løse den fundne fejl. Prioritet af defekter kan indstilles, hvis påvirkningen er mere. Manglerne med højere prioritet løses først, og dem med lavere prioritet løses senere. Udvikleren skal rette det og derefter informere testeren om rettelsen. De kan forstå årsagen til defekten, når denne aktivitet udføres. Alle defekter, der genereres, skal kategoriseres systematisk. De kritiske skal rettes straks. De defekter, der har høj prioritet, skal også rettes, da de påvirker produktets vigtigste funktionaliteter. Manglen skal have et minimum afvigelse fra dets krav. Sådanne typer skal være mellemstore. Den defekt, der kan have mindre implikationer, skal markeres som lav.
5. Forbedring af processen
Alle fejl skal rettes. Selvom de måske har deres prioriteter, skal det sikres, at alle rettes uanset hvilke prioriteter, der er sat. For at forbedre processen er det vigtigt, at alle mangler betragtes som kritiske. Den mindste af manglerne kan hjælpe med at forbedre kvaliteten og forhindre forekomsten af defekten. Efter alt dette er en anden ledelsesrapportering også en vigtig del. Alle individuelle mangler skal rapporteres, og alle oplysninger om disse skal gives til den øverste ledelse. Dette giver også indsigt i områder, hvor processen kan forbedres.
Fordele
- Defektstyring sikrer, at de fejl, der findes, faktisk bliver rettet. Det hjælper med at spore det til lukning med udviklere og testere, der arbejder sammen.
- Når de er løst, er det sikret, at alle fejl i systemet fjernes. Det sikrer, at der leveres et produkt af høj kvalitet. Det sparer både tid og penge. Effektivitet og økonomi er begge godt vedligeholdt.
- Afkastet på investeringerne kan forbedres ved at reducere udviklingsomkostningerne. Dette betyder, at man ved at prioritere problemerne kan identificere gentagne problemer let. Holdets produktivitet øges som et resultat af dette.
- De problemer, der først er løst, kan hjælpe med at bestemme et mønster eller forstå bugens tendenser. De er mere relatable for fremtiden. Almindelige problemer kan identificeres og rettes så tidligt som muligt.
- Kommunikationsgabet kan reduceres, da testerne og udviklerne kan arbejde sammen for at løse de fundne problemer.
Konklusion
Hele processen hjælper med at løse manglerne og levere et kvalitetsprodukt. Det kan aldrig garanteres, at der ikke findes nogen fejl, men denne proces hjælper med at strømline den komplette proces og reducere antallet af fejl. Ved at følge hele processen kan det sikres, at der ikke er en flaskehals, når produktet flyttes til produktion. Som et resultat spares penge, og der leveres et kvalitetsprodukt.
Anbefalede artikler
Dette er en guide til Hvad er mangel. Her diskuterer vi de top 5 processer sammen med fordelene. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -
- Hvad er genetisk algoritme?
- Hvad er Google Cloud Platform
- Hvad er funktionel testning? (Typer)
- Spørgsmål til manuel test af interview | Top 10