Menu

Defectbeheerproces: hoe u een defect effectief kunt beheren

  • Hoofd
  • Andere
  • Defectbeheerproces: hoe u een defect effectief kunt beheren

defect management process

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Inleiding tot het proces voor defectbeheer:

Door het meer gerichte proces en door het testen, komt er minder software met fouten op de markt.

Defectpreventie is veel efficiënter en effectiever in het verminderen van het aantal defecten en is ook zeer kosteneffectief om de defecten te herstellen die tijdens het vroege stadium van het softwareproces zijn gevonden. De meeste organisaties voeren uit Detectie van defecten ​ Verwijdering van defecten en toen Procesverbetering die gezamenlijk bekend staat als een Defectenbeheerproces ​

Defectenbeheerproces

wat zijn goede websites om anime te kijken

Wat je leert:

Doelen van Defect Management Process (DMP)

Hieronder staan ​​de verschillende doelen van dit proces:

  • Voorkom het defect
  • Vroegtijdige opsporing
  • Minimaliseer de impact
  • Oplossing van het defect
  • Procesverbetering

Voordat we het proces voor defectbeheer gaan onderzoeken, moeten we eerst dit begrijpen wat is eigenlijk een defect of bug?

Defect Management Life Cycle

Wanneer een systeem een ​​andere output geeft dan de werkelijke zakelijke behoefte, d.w.z. wanneer er een afwijking is van de werkelijke of oorspronkelijke zakelijke behoefte, kunnen we zeggen dat er een defect is in het systeem / de software.

Wanneer het testteam de testcases uitvoert, komen ze een situatie tegen waarin het daadwerkelijke testresultaat afwijkt van het verwachte resultaat. Deze variatie wordt een Defect ​

Kortom, een softwarefout is een voorwaarde die niet voldoet aan de softwarevereiste. Het defect is een fout of een fout die een onverwacht of onjuist gedrag in het systeem veroorzaakt.

Om de projecten op de juiste manier af te handelen, moet u weten hoe u met de ontwikkeling en release moet omgaan, maar daarnaast moet u ook weten hoe u met defecten om moet gaan.

Stelt u zich eens voor, wat gebeurt er als het testteam de defecten mondeling meldt en het ontwikkelteam ook de status van het defect mondeling bijwerkt? Het proces zal ingewikkelder zijn omdat deze defecten alle defecten omvatten, zoals feitelijk verholpen en werken zoals verwacht, opgelost maar nog steeds niet werken, afgewezen, uitgesteld en het proces gaat door.

In het bovenstaande geval, naarmate het aantal defecten toeneemt en de communicatie mondeling plaatsvindt, zal de situatie binnenkort het ergst worden. Om het defect effectief te beheersen en af ​​te handelen, hebt u de juiste Defect Life Cycle nodig.

Defect Life Cycle zorgt ervoor dat het proces uniform en gestandaardiseerd is. Een defect bereikt verschillende toestanden in de levenscyclus. Nadat een defect is gevonden, doorloopt het verschillende stadia tijdens zijn levensduur en is het algemeen bekend als Defecte levenscyclus ​

Over het algemeen begint de levenscyclus van een defect vanaf het stadium waarin het defect wordt gevonden of gemeld door het testteam en eindigt wanneer een defect wordt verholpen door ervoor te zorgen dat het niet reproduceerbaar is of door een ontwikkelingsteam wordt afgewezen. Het aantal toestanden dat een defect doormaakt, verschilt van project tot project.

Verder lezen:

Wat is de levenscyclus van defecten / bugs bij het testen van software? Zelfstudie over de levenscyclus van een defect

Notitie: Onderstaande cyclus verschilt enigszins van organisatie tot organisatie.

De onderstaande defectlevenscyclus omvat alle mogelijke statussen:

Stroomdiagram van de levenscyclus van een defect

  • Telkens wanneer het testteam een ​​defect in de applicatie ontdekt, brengen ze het defect aan de orde met de status ' NIEUW ​
  • Wanneer een nieuw defect wordt beoordeeld door een QA-lead en als het defect geldig is, dan is de status van het defect ' Open ”En het is klaar om te worden toegewezen aan het ontwikkelingsteam.
  • Wanneer een QA-lead het defect toewijst aan de corresponderende ontwikkelaar, wordt de status van het defect gemarkeerd als ' Toegewezen ​Een ontwikkelaar moet in dit stadium beginnen met het analyseren en oplossen van het defect.
  • Wanneer de ontwikkelaar van mening is dat het defect niet echt of geldig is, wijst de ontwikkelaar het defect af. De status van het defect is gemarkeerd als ' Afgekeurd ”En terug toegewezen aan het testteam.
  • Als het geregistreerde defect tweemaal wordt herhaald of als beide gerapporteerde defecten vergelijkbare resultaten en stappen hebben om te reproduceren, wordt één defectstatus gewijzigd in ' Duplicaat ​
  • Als er problemen of hindernissen zijn in de huidige release om een ​​bepaald defect te verhelpen, dan wordt het defect in de komende releases opgenomen in plaats van in de huidige release en wordt het gemarkeerd als ' Uitgesteld 'Of' Uitgesteld ​
  • Wanneer een ontwikkelaar het defect niet kan reproduceren door de stappen die door het testteam worden genoemd in 'Stappen om te reproduceren', kan de ontwikkelaar het defect markeren als ' Niet reproduceerbaar' ​In deze fase moet het testteam gedetailleerde reproductiestappen aan een ontwikkelaar verstrekken.
  • Als de ontwikkelaar niet duidelijk is over de reproductiestappen die door een QA worden geleverd om het defect te reproduceren, kan hij / zij dit markeren als ' Meer informatie nodig ​In dit geval moet het testteam de vereiste details aan het ontwikkelteam verstrekken.
  • Als een defect al bekend is en momenteel aanwezig is in de productieomgeving, wordt het defect gemarkeerd als ' Bekend defect ​
  • Wanneer een ontwikkelaar de nodige wijzigingen aanbrengt, wordt het defect gemarkeerd als ' Gemaakt ​
  • De ontwikkelaar geeft het defect nu ter verificatie door aan het testteam, dus de ontwikkelaar wijzigt de status als ' Klaar om opnieuw te testen ​
  • Als het defect geen verdere problemen heeft en het correct is geverifieerd, markeert de tester het defect als ' Gesloten ​
  • Bij het opnieuw testen van het defect als de tester ontdekte dat het defect nog steeds reproduceerbaar of gedeeltelijk verholpen is, wordt het defect gemarkeerd als ' Heropend ​Nu moet de ontwikkelaar dit defect opnieuw onderzoeken.

Een goed geplande en gecontroleerde Defect Life Cycle geeft het totale aantal defecten aan dat in een release of in alle releases is aangetroffen. Dit gestandaardiseerde proces geeft een duidelijk beeld van hoe de code is geschreven, hoe goed het testen is uitgevoerd, hoe het defect of de software is vrijgegeven, etc. Dit zal het aantal defecten in de productie verminderen door de defecten in het testen op te sporen. fase zelf.

Defectenbeheerproces

Defectenbeheerproces

Het proces voor het beheer van defecten wordt hieronder in detail uitgelegd.

# 1) Defectpreventie:

Defectpreventie is de beste methode om de defecten in de vroege testfase te elimineren in plaats van de defecten in de latere fase op te sporen en vervolgens te repareren. Deze methode is ook kostenbesparend omdat de kosten die nodig zijn voor het herstellen van de defecten die in de vroege stadia van het testen worden gevonden, erg laag zijn.

Het is echter niet mogelijk om alle defecten te verwijderen, maar u kunt in ieder geval de impact van het defect en de kosten minimaliseren om hetzelfde te repareren.

De belangrijkste stappen bij Defect Prevention zijn als volgt:

  • Identificeer kritieke risico's : Identificeer de kritieke risico's in het systeem die meer invloed zullen hebben als ze zich voordoen tijdens het testen of in de latere fase.
  • Schat verwachte impact : Bereken voor elk kritiek risico hoeveel de financiële impact zou zijn als het risico daadwerkelijk zou optreden.
  • Minimaliseer de verwachte impact : Zodra u alle kritieke risico's hebt geïdentificeerd, neemt u de grootste risico's die schadelijk kunnen zijn voor het systeem als u ze tegenkomt, en probeert u het risico te minimaliseren of te elimineren. Voor risico's die niet kunnen worden uitgesloten, verkleint het de kans op voorkomen en de financiële impact ervan.

# 2) Te leveren basislijn:

Wanneer een deliverable (systeem, product of document) zijn vooraf gedefinieerde mijlpaal bereikt, kun je zeggen dat een deliverable een baseline is. In dit proces gaat het product of het te leveren product van de ene fase naar de andere en naarmate het product van de ene fase naar de andere gaat, worden de bestaande defecten in het systeem ook overgedragen naar de volgende mijlpaal of fase.

Bijvoorbeeld​ overweeg een scenario van coderen, testen van eenheden en vervolgens systeemtesten. Als een ontwikkelaar codering en unit-tests uitvoert, worden systeemtests uitgevoerd door het testteam. Hier is coderen en unit testen een mijlpaal en systeemtesten is een andere mijlpaal.

Dus als de ontwikkelaar tijdens het testen van de unit enkele problemen vindt, wordt dit niet als een defect genoemd, omdat deze problemen worden geïdentificeerd voordat de mijlpaaldeadline is bereikt. Nadat de codering en het testen van de eenheden zijn voltooid, overhandigt de ontwikkelaar de code voor systeemtests en kunt u zeggen dat de code is 'Baseline' en klaar voor de volgende mijlpaal, hier, in dit geval, is het 'systeemtesten'.

Als de problemen nu tijdens het testen worden geïdentificeerd, wordt dit het defect genoemd, zoals het wordt geïdentificeerd na het voltooien van de eerdere mijlpaal, d.w.z. codering en unit-testen.

Kortom, de deliverables zijn baseline wanneer de veranderingen in de deliverables zijn afgerond en alle mogelijke defecten zijn geïdentificeerd en opgelost. Daarna gaat hetzelfde resultaat door naar de volgende groep die eraan zal werken.

# 3) Opsporen van defecten:

Het is bijna onmogelijk om alle defecten uit het systeem te verwijderen en een systeem defectvrij te maken. Maar u kunt de defecten vroegtijdig identificeren voordat ze duurder worden voor het project. We kunnen zeggen dat het ontdekte defect betekent dat het formeel onder de aandacht van het ontwikkelteam wordt gebracht en na analyse daarvan accepteerde het defectontwikkelingsteam het ook als een defect.

De stappen die betrokken zijn bij het opsporen van defecten zijn als volgt:

  • Zoek een defect : Identificeer defecten voordat ze een groot probleem voor het systeem worden.
  • Rapporteer defect : Zodra het testteam een ​​defect ontdekt, is het hun verantwoordelijkheid om het ontwikkelingsteam ervan bewust te maken dat er een probleem is geïdentificeerd dat moet worden geanalyseerd en opgelost.
  • Erken defect : Zodra het testteam het defect aan het ontwikkelingsteam heeft toegewezen, is het de verantwoordelijkheid van het ontwikkelingsteam om het defect te erkennen en door te gaan met het repareren ervan als het een geldig defect is.

# 4) Foutoplossing:

In het bovenstaande proces heeft het testteam het defect geïdentificeerd en gerapporteerd aan het ontwikkelteam. Nu moet het ontwikkelingsteam doorgaan met het oplossen van het defect.

De stappen die betrokken zijn bij het oplossen van defecten zijn als volgt:

  • Geef prioriteit aan het risico : Ontwikkelingsteam analyseert het defect en geeft prioriteit aan het verhelpen van het defect. Als een defect meer impact heeft op het systeem, dan geven ze het verhelpen van het defect een hoge prioriteit.
  • Los het defect op : Op basis van de prioriteit herstelt het ontwikkelingsteam het defect, defecten met een hogere prioriteit worden eerst opgelost en defecten met een lagere prioriteit worden aan het einde opgelost.
  • Rapporteer de resolutie : Het is de verantwoordelijkheid van het ontwikkelteam om ervoor te zorgen dat het testteam op de hoogte is wanneer de defecten worden verholpen en hoe het defect is verholpen, d.w.z. door een van de configuratiebestanden te wijzigen of een aantal codewijzigingen aan te brengen. Dit is nuttig voor het testteam om de oorzaak van het defect te begrijpen.

# 5) Procesverbetering:

Hoewel in het defectoplossingsproces de defecten prioriteit krijgen en worden opgelost, betekent dit vanuit procesperspectief niet dat defecten met een lagere prioriteit niet belangrijk zijn en niet veel invloed hebben op het systeem. Vanuit het oogpunt van procesverbetering zijn alle geïdentificeerde defecten hetzelfde als een kritiek defect.

Zelfs deze kleine defecten bieden de mogelijkheid om te leren hoe u het proces kunt verbeteren en het optreden van defecten die in de toekomst van invloed kunnen zijn op systeemstoringen, kan voorkomen. Identificatie van een defect met een lagere impact op het systeem is misschien niet zo erg, maar het optreden van een dergelijk defect in het systeem zelf is een groot probleem.

Voor procesverbetering moet iedereen in het project terugkijken en controleren waar het defect vandaan kwam. Op basis daarvan kunt u wijzigingen aanbrengen in het validatieproces, het basisdocument, het beoordelingsproces, waardoor de defecten vroeg in het proces kunnen worden opgemerkt die minder duur zijn.

Gevolgtrekking

Het defectbeheerproces moet worden gevolgd tijdens het algehele softwareontwikkelingsproces en niet alleen voor specifieke test- of ontwikkelingsactiviteiten.

Als een defect wordt gevonden in de testfase, kan de vraag worden gesteld dat als het defect in deze fase wordt opgemerkt, hoe zit het met de andere defecten die in het systeem aanwezig zijn en die systeemfalen kunnen veroorzaken als het zich voordoet en nog niet is ontdekt.

Dus alle processen, zoals beoordelingsproces, statisch testen, inspectie, enz., Moeten worden versterkt en iedereen in het project moet het proces serieus nemen en bijdragen waar nodig. Het senior management in de organisatie moet ook het defectmanagementproces begrijpen en ondersteunen.

Testbenaderingen, beoordelingsproces enz. Moeten worden gekozen op basis van het projectdoel of het organisatorische proces.

voeg een element toe aan een array

Ik hoop dat dit informatieve artikel over Defect Management Process een enorme hulp voor je is.

Aanbevolen literatuur

^