Introduksjon til defekt
Hver gang en programvare ikke fungerer som forventet, sies den å ha en mangel. Så hva er egentlig en mangel? Det kan tenkes som et avvik eller variasjon fra de opprinnelige funksjonskravene. Når en tester utfører en prøvesak og ser en motsetning fra det forventede resultatet, blir det funnet en mangel. Den må styres til den er løst. Alle detaljer skal lagres og spores til de er i samsvar med de forventede funksjonskravene.
Hva er defektstyringsprosess?
Denne prosessen innebærer å oppdage og fikse dem.
- Forebygging
- Leverbar grunnlinje
- Oppdagelse
- Vedtak
- Prosessforbedring
La oss gå gjennom prosessen i detalj.
1. Forebygging
For å eliminere alle feil er den beste måten å forhindre at de kommer. Dette hjelper med å spare penger og er veldig kostnadseffektivt. For å nå dette stadiet er det veldig viktig at alle feil blir fanget i de tidlige stadiene av testing. Hovedmålet her kan være å minimere virkningen som en mangel har. Dette kan gjøres ved å følge trinnene:
- Identifiser kritisk risiko: De kritiske områdene i systemet må identifiseres på forhånd slik at påvirkningen blir mindre eller ikke i det hele tatt når testing utføres.
- Estimering av forventet innvirkning: Når risikoen er identifisert, bør det samles en estimering av hvordan virkningen kan påvirke økonomisk dersom den faktiske risikoen slipper til produksjonen.
- Minimere forventet innvirkning: En liste over risikoer vil bli funnet ved denne analysen. Den øverste risikoen vil være skadelig, og det bør være de som må minimeres eller elimineres. De som ikke kan fjernes helt, vil redusere sannsynligheten for forekomst av denne defekten.
2. Leverbar baseline
En grunnlinje er når en forhåndsdefinert milepæl er nådd. Når dette trinnet er nådd, er det sørget for at når produktet går fra et trinn til et annet. Når produktet fortsetter å bevege seg fra et trinn til et annet, går alle eksisterende feil videre med fremdriften til produktet. Milepælen har en frist, og hvis feilen er løst før du når denne fristen, er det ikke en mangel. Når kodingen og enhetstesten er utført, sies koden å være basellinert og flyttet til systemtesting. Når problemet er funnet i systemtesting, blir feilen reist. Den basale leveransen er den der alle leveranser er ferdigstilt, og alle mulige feil er løst.
3. Oppdagelse
Mangelen sies å bli oppdaget når den blir gjort oppmerksom på alles. Utviklingsteamet etter analysen blir akseptert av utviklingsteamet som skal fikses. Her må det sjekkes før de blir en blokkering. Når testteamet har funnet feilen, er det testerens ansvar å informere utviklingsteamet og sørge for at feilen erkjennes. Når bekreftelsen er mottatt, kan de fortsette med mangelen for å validere den og gi en løsning for den.
4. Oppløsning
Når feilen er rapportert, må utviklingsteamet gå mot oppløsningen. De må analysere og deretter prioritere å fikse feilen som er funnet. Prioriteten til defekten kan settes hvis påvirkningen er mer. Manglene med høyere prioritet løses først, og de med lavere prioritet løses senere. Utvikleren må fikse det og deretter informere testeren om fiksen. De kan forstå årsaken til feilen når denne aktiviteten utføres. Alle feil som blir generert, må kategoriseres systematisk. De kritiske må løses umiddelbart. Manglene som har høy prioritet, må også fikses da de påvirker produktets viktigste funksjonalitet. Mangelen skal ha et minimalt avvik fra kravet. Slike typer må være middels. Mangelen som kan ha mindre implikasjoner, skal merkes som lav.
5. Forbedring av prosessen
Alle mangler skal fikses. Selv om de kanskje har sine prioriteringer, bør det sørges for at alle fikses uavhengig av prioriteringene. For å forbedre prosessen er det viktig at alle mangler blir ansett som kritiske. Den minste av manglene kan bidra til å forbedre kvaliteten og forhindre forekomsten av feilen. Etter alt dette er også en annen ledelsesrapportering en viktig del. Alle individuelle feil må rapporteres, og all informasjon om disse skal gis til toppledelsen. Dette gir også innsikt i områder der prosessen kan forbedres.
Fordeler
- Defektstyring sikrer at feilene som blir funnet faktisk blir løst. Det hjelper med å spore det for å avslutte med utviklerne og testerne som jobber sammen.
- Når de er løst, er det sikret at alle feil i systemet fjernes. Det sikrer at et høykvalitets produkt blir levert. Det sparer både tid og penger. Effektivitet og økonomi er begge godt vedlikeholdt.
- Avkastningen på investeringen kan forbedres ved å redusere kostnadene for utvikling. Dette betyr at ved å prioritere problemene kan repeterende problemer lett identifiseres. Lagets produktivitet økes som et resultat av dette.
- Problemene når den er løst kan være med på å bestemme et mønster eller forstå trender i feilen. De er mer relatable for fremtiden. Vanlige problemer kan identifiseres og fikses så tidlig som mulig.
- Kommunikasjonsgapet kan reduseres ettersom testerne og utviklerne kan samarbeide for å løse de funnet problemene.
Konklusjon
Hele prosessen hjelper til med å løse manglene og levere et kvalitetsprodukt. Det kan aldri garanteres at ingen feil oppdages, men denne prosessen hjelper til med å effektivisere hele prosessen og redusere antall feil. Ved å følge hele prosessen kan det sikres at det ikke blir en flaskehals når produktet flyttes til produksjon. Som et resultat blir pengene spart og et kvalitetsprodukt levert.
Anbefalte artikler
Dette er en guide til Hva er mangel. Her diskuterer vi de 5 beste prosessene sammen med fordelene. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Hva er genetisk algoritme?
- Hva er Google Cloud Platform
- Hva er funksjonstesting? (typer)
- Manual Testing Interview Questions | Topp 10