Menu

Methoden en technieken om defecten te voorkomen

defect prevention methods

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Effectieve aanpak van defectpreventie en de kritische meningen:

Kwaliteitsborging is de term die vaak wordt gebruikt om de testteams in IT-projecten aan te spreken.

Afgezien van technische aspecten, zijn kwaliteitsborgingsactiviteiten niet alleen gericht op het opsporen van defecten (dat wil zeggen het vinden van defecten nadat ze zich hebben voorgedaan. Dit is gewoon testen of kwaliteitscontrole), maar omvatten ook defectpreventie (ervoor zorgen dat de defecten überhaupt niet voorkomen defecten worden verwijderd / verminderd voordat ze in het softwareproduct terechtkomen).

Methoden om defecten te voorkomen

Een eenvoudig equivalent van een vergelijking kan zijn:

QA = QC (defect identificatie) + defect preventie

Hoewel dit vrij eenvoudig klinkt, is er minder nadruk of richting beschikbaar op hoe of wat defectpreventietaken precies zijn.

De waarheid is dat defecten die tijdens de testfase of erger na de release zijn gevonden, duurder zijn om te vinden en op te lossen en dat ze het vertrouwen in het merk kunnen verliezen. Dus hoe eerder de preventiemaatregelen worden genomen, hoe beter. Bovendien helpt defectpreventie bedrijven ook om het hoogste CMMI-niveau (Capability Maturity Model Integration) te bereiken.

Laten we in dit artikel de defectpreventie eens nader bekijken.

Wat je leert:

Defectpreventie

Defectpreventie is een cruciale stap of activiteit in elk softwareontwikkelingsproces en zoals te zien is in het onderstaande diagram is dit vrijwel de helft van onze testtaken:

Defectpreventie

In het kort zijn de volgende verantwoordelijkheden voor defectpreventie voor testers in elk van de onderstaande fasen:

# 1) Beoordeling van vereiste specificaties:

Nadat u de vereisten van de klant heeft begrepen, stelt u de kern van uw vereiste voor.

Een beoordeling is belangrijk bij deze stap - het eerste beoordelingsniveau zou binnen het team moeten zijn, gevolgd door een ander niveau van externe beoordeling (door een ontwikkelaar, BA of klant) om ervoor te zorgen dat alle perspectieven synchroon lopen.

# 2) Ontwerpbeoordeling:

De ontwerpfase kan worden beschouwd als een soort strategiefase en als u deze doorloopt, zorgt u ervoor dat het QA-team de voor- en nadelen van elke strategie begrijpt.

Dit soort kritische walkthrough helpt eventuele problemen met de genoemde strategieën op te sporen en op te lossen voordat u verder gaat. Dit kan worden beschouwd als een haalbaarheidsstudie voor de strategie (of strategieën).

# 3) Code recensie:

basis c ++ interviewvragen

Er is niet veel voor testers om direct bij deze fase betrokken te raken, maar de review gaat ook hier door. Ontwikkelaars voeren code-inspecties, walkthroughs en beoordelingen uit voordat ze de applicatie integreren en integreren.

Methoden en technieken om defecten te voorkomen

Enkele traditionele en veelgebruikte methoden die al geruime tijd in gebruik zijn om defecten te voorkomen, worden hieronder vermeld;

# 1) Beoordeling en inspectie: Deze methode omvat de beoordeling door een individueel teamlid (autocontrole), peer reviews en inspectie van alle werkproducten.

​ Raadpleeg onze voor meer informatie over hoe dit wordt uitgevoerd Test documentatie beoordelingen artikel.

# 2) Doorloop: Dit lijkt min of meer op een recensie, maar het heeft vooral te maken met het vergelijken van het systeem met het prototype, wat een beter idee geeft met betrekking tot de juistheid en / of de look-and-feel van het systeem.

# 3) Defectregistratie en documentatie: Deze methode biedt enkele belangrijke informatie, argumenten / parameters die kunnen worden gebruikt om het analyseren van defecten te ondersteunen.

# 4) Analyse van hoofdoorzaken: Oorzaakanalyse omvat twee belangrijke benaderingen:

I) Pareto-analyse:

Pareto-analyse is een formele en eenvoudige techniek die helpt bij het prioriteren van de volgorde van probleemoplossing voor maximale impact. Het stelt dat 80% van het probleem veroorzaakt wordt door 20% redenen.

Daarom worden de eenmaal geïdentificeerde problemen geprioriteerd op basis van frequentie en wordt een gedetailleerde op statistieken gebaseerde analyse uitgevoerd om uit te vinden welke 20% van de redenen worden toegeschreven aan de 80% problemen. Door simpelweg te focussen op die 20% redenen en deze te elimineren, worden resultaten gegarandeerd terwijl de omvang van het werk wordt geoptimaliseerd.

II) Visgraatanalyse:

Ook gekend als Ishikawa-analyse deze methode is een meer visuele analyse van de hoofdoorzaak. Er zijn geen statistieken bij betrokken, aangezien deze methode is gebaseerd op teambreed brainstormen. Het volgende diagram helpt dit beter te begrijpen.

De opgave wordt eerst aan de rechterkant geschreven en op de horizontale lijn die er doorheen gaat, worden de verschillende oorzaken opgesomd. De tak met de meeste oorzaak-subclausule botten (of lijnen / takken) is het probleem dat het ernstigst is en dat moet worden weggewerkt. Deze techniek wordt ook wel eens genoemd oorzaak en gevolg analyse ​

Fishbone-analyse

TMM-niveau en defectenafhandeling door testorganisatie

# 1) TMM (Testing Maturity Model) is gebaseerd op CMM, d.w.z. Capability Maturity Model.

#twee) Bij defectpreventie zijn veel personeelsleden betrokken en hun gezamenlijke inspanningen in verschillende stadia, wat de reden is waarom het een prominente rol speelt in TMM-niveau 5. bijvoorbeeld; Als een defect vaak voorkomt in een testcase of procedure, kan de organisatie een groep personeelsleden toewijzen om het defect te analyseren en het plan te ontwikkelen met acties voor veranderingen in het proces met het probleem.

# 3) Enkele voordelen van het defectpreventieprogramma zijn:

  • Het personeel wordt gemotiveerd en is bewuster
  • Klantentevredenheid
  • Verhoogde betrouwbaarheid, beheersbaarheid en voorspelbaarheid
  • Verbeterde continue procesverbetering

Teamrollen en verantwoordelijkheden

Bij het proces van defectpreventie zijn drie kritische groepen betrokken:

c ++ voorbeeld van een reguliere expressie

Rol van de manager:

  • Voor het succes van elk defectpreventieprogramma moet het management sterk ondersteunend zijn.
  • De ondersteuning kan in de vorm zijn van middelen, training en tools die nodig zijn om het plan succesvol uit te voeren.
  • Het management moet het juiste beleid bepalen en indien nodig enkele culturele veranderingen aanbrengen.
  • Managers worden geacht discussies te bevorderen, de lijst met veelvoorkomende defecten te verspreiden en veranderingen in het proces te bevorderen.

Rol van tester:

  • Testers houden de defectdatabase bij, inclusief het verzamelen van defectgegevens.
  • Foutgegevens moeten regelmatig worden bijgewerkt en informatie over defecten moet te allen tijde actueel worden gehouden.
  • Om de implementatie van verandering te plannen

Rol van de klant:

  • De klant speelt een relatief kleine of beperkte rol, maar hun toewijding aan kwaliteit is cruciaal.

Gevolgtrekking

Defect Preventie speelt een belangrijke en cruciale rol in het softwareontwikkelingsproces. Het helpt de kwaliteit van het softwareproduct op een 'eerder en goedkopere' manier te beheren met behulp van de hierboven genoemde technieken.

Het zorgt ervoor dat de problemen vroegtijdig worden opgelost zonder de applicatie te halen. Het beschouwt het vinden van de hoofdoorzaak als het belangrijkste middel om problemen te identificeren en uiteindelijk te verwijderen.

Het handhaven van de kwaliteit van de software is de verantwoordelijkheid van het kernmanagement en het hele team, inclusief projectleider, klant en elk teamlid.

Wat zijn uw methoden om defecten te voorkomen? Deel uw opmerkingen, vragen en gedachten hieronder.

Aanbevolen literatuur

^