Test Management Tutorial: An Ultimate Guide To Test Management

Dit is een Test Management Tutorial voor het testen van Software. Het omvat Testmanagementfases, Tools en testmanagement Vs organisatiestructuur:

testmanagement is het proces van het beheren van alle testgerelateerde activiteiten, documenten en ander gerelateerd werk. Organisatiestructuren verwijzen naar een hiërarchie van teams of medewerkers die aan bepaalde projecten werken.

denkt u dat de organisatiestructuur van invloed is op het testmanagement?

als uw antwoord nee is, zullen we zien waarom? Zo ja, laten we eens kijken hoe het beïnvloedt. Om de relatie tussen deze twee te vinden, moeten we deze onderwerpen duidelijk begrijpen en vervolgens de relatie tussen testmanagement en organisatiestructuur verkennen.

Inleiding tot testmanagement

testmanagement betekent het beheren van het gehele proces van softwaretesten voor een bepaald project. Het testmanagementproces wordt toegepast op de gehele levenscyclus van de softwareontwikkeling. Vandaar, idealiter, zodra het softwareontwikkelingsproces begint het testmanagementproces moet ook beginnen.

Testmanager had de volgende verantwoordelijkheden-

• de testmanager moet zorgen voor consistentie en kwaliteit van deze werkproducten.
• werk samen met testanalist en technische testanalist om de juiste template te selecteren en aan te passen.
• werk samen met testanalist en technisch testanalist om normen voor deze producten vast te stellen, zoals niveaus van gedetailleerde graad.
• bekijk de werkproducten met behulp van geschikte technieken.

Test Management Componenten

Test Management is verdeeld in 5 delen voor een beter begrip:

1. Test Documentatie
2. Test Schatting
3. Test Metrics
4. Meting van de Test Vooruitgang
5. Gegevens voor de Monitoring van de Testen Levenscyclus

#1) Test Documentatie

Er zijn drie soorten Testen Documentatie die hieronder worden vermeld:

• Test Beleid
• Test Strategie
• Master Test Plan

#1) Test Beleid:

• geeft een samenvatting van de waarde die de organisatie ontleent aan testen.
• definieert testbeleid.
• beschrijft hoe de effectiviteit van tests moet worden beoordeeld.
• schetst het testproces.
• aangeven hoe de organisatie het testproces zal verbeteren?

#2) teststrategie:

• beschrijft de Algemene testmethoden, die worden gebruikt om Project-en productrisico ‘ s te beheren.
• Analytische Strategieën: Zoals Risicogebaseerde Tests.
• Modelgebaseerde Strategie: Zoals een operationeel profiel waarbij het testteam een model ontwikkelt op basis van actuele en geaccepteerde situaties van omgeving, input en omstandigheden.
• methodologische strategie: kwaliteitskenmerken waarbij het testteam gebruik maakt van een reeks testomstandigheden, een checklist of een verzameling algemene, logische tests.
• Process of Standard-Compliant techniques: volgt een set van het proces zoals SCRUM / Agile.
• reactieve strategieën: gebruik van defectgebaseerde aanvallen zoals verkennende tests.
• Adviesstrategie: Zoals door de gebruiker gerichte tests waarbij het testteam vertrouwt op de input van een of meer belanghebbenden om testvoorwaarden te bepalen, zoals uitbestede compatibiliteitstesten.
• beschrijft ook:
  • Integratieprocedures
  • Testspecificatietechnieken
  • onafhankelijkheid van testen
  • verplichte en facultatieve normen
  • testomgeving
  • Tools
  • herbruikbaarheid van softwareproducten
  • hertest en regressie.

#3) Master Test Plan:

• het omvat alle testtaken die moeten worden uitgevoerd.
• wordt besproken hoe testen de teststrategie en het testbeleid zullen implementeren.
• als iets niet wordt beschreven, moet in het testplan worden beschreven waarom en het mitigatieplan daarvoor.
• de inhoud van het testplan is:
  • te testen Items
  • te testen kwaliteitskenmerken.
  • Schema
  • Uitvoering cyclus
  • Gebrek variabelen
  • Test items in het bereik
  • Exit criteria
  • Project risico ‘ s
  • Algemeen bestuur van het testen van de inspanningen,
  • Rollen en verantwoordelijkheden
  • Input en output

#2) Test Schatting

Algemene Punten:

• Is een management-activiteiten
• Het is gebaseerd op ervaring.
• het biedt een specifieke en gedetailleerde catalogus van kosten, middelen, taken en mensen.
• eenmaal opgesteld, moet de schatting samen met de motivering aan het management worden verstrekt.
• de uiteindelijke schatting is het best mogelijke evenwicht tussen organisatorische en projectdoelstellingen.
• de schatting is gebaseerd op de informatie die beschikbaar was op het moment dat zij werd opgesteld.
• om accuraat te blijven, moeten schattingen worden bijgewerkt om nieuwe en gewijzigde informatie weer te geven.

factoren die de schatting van de Test beïnvloeden:

• Vereiste niveau van Kwaliteit
• Grootte van het systeem
• Historische gegevens
• Proces factoren, zoals strategie, ontwikkeling en levenscyclus
• Materiële factoren zoals test milieu, automatisering, gereedschappen, en gegevens
• Mensen factor
• Complexiteit van proces
• Training en KT(kennisoverdracht)
• Assimilatie en de ontwikkeling van nieuwe tools en technologie, processen of technieken.
• de eis van een hogere graad van de gedetailleerde testspecificatie.
• tijdstip van aankomst van het onderdeel
• testgegevens.

gissingen:

• work breakdown structure
• Team Estimation session
• Tester-Ontwikkelaar ratio
• Organisatiegeschiedenis
• Functiepuntanalyse, LOC.

de schatting van de Test wordt verderop in de tutorial verder uitgelegd.

# 3) testwaarden

• wat wordt gemeten, wordt als gedaan beschouwd?
• wat Meet niet, is makkelijk genegeerd te worden?
• er moet een beperkte reeks nuttige maatstaven worden gedefinieerd.
• alleen die maatstaven dienen te worden gedefinieerd waarvan de interpretatie door iedereen is overeengekomen.
• rapportage en samenvoeging van metrics moeten geautomatiseerd worden.
• de beheerder dient de informatie metrisch te valideren.

Projectmetrie : % van pass, fail uitgevoerd etc.

Productmetrisch:

• eigenschappen van het product
• Defectdichtheid

Procesmetriek: meet het vermogen om te testen zoals % van het defect.

mensen: vermogen van het individu.

Meting Van De Testvoortgang:

• het aantal testomstandigheden / gevallen, gepland vs uitgevoerd.
• totaal defect ingedeeld naar ernst, prioriteit, huidige toestand en effect subsysteem.
• het aantal vereiste, geaccepteerde, gebouwde en geteste wijzigingen.
• geplande vs. werkelijke kosten.
• gepland versus werkelijke duur
• gepland versus werkelijke testmijlpaal.
• Productkwaliteitsrisicostatus
• % verlies van Testinspanning, kosten of tijd.

#4) meting van de Testvoortgang

productrisico ‘s:

• % van gedekte risico’ s.
• % van het risico voor fail-test
• % van het risico dat door de individuele persoon is vastgesteld.

defecten:

• het aantal geconstateerde gebreken versus het aantal ingediende gebreken.
• gemiddelde defecte aankomstsnelheid
• defecten in de specifieke testonderdelen.
• detectie van RCA (Root Cause Analysis)
• het defect is het vrijkomen van de Test.
• defecte fase
• prioriteit en ernst
• rapport Rejects vs Duplicate
• tijd die nodig is om
• het aantal nieuwe defecten op te lossen als gevolg van de vaststelling van oude defecten.

Test:

• totaal aantal testgevallen, falen, loper, geblokkeerd
• het totale aantal gevallen van regressietests.

dekking:

• vereiste en Ontwerpdekking
• risicodekking
• Omgevingsconfiguratiedekking
• codedekking

#5) Metrics For Monitoring The test Lifecycle

Monitor Test Plan

• aantal risico ‘ s en vereisten
• Defectdetectie
• Plan vs werkelijke inspanningen.

Monitor testontwerp

• het aantal tijdens het ontwerp geconstateerde defecten.

Monitor Test analyse

• aantal voorwaarden
• aantal defecten in de analyse

implementatie Monitor Test

• % van omgevingsconfiguratie
• % van de TestCASE geautomatiseerd.

Monitor Uitvoering

• % van Geslaagd, Mislukt, Geen run, het Geblokkeerd zijn van test cases
• % Test de gevallen die onder
• Geplande en Werkelijke gebreken opgelost
• % van Plan versus Werkelijke dekking

Monitor Sluiting

• % Test cases passeren, ail
• % Test cases gecontroleerd in de herbruikbare categorie
• % van de testcases geautomatiseerd.
• het aantal opgeloste/niet opgeloste defecten.
• % van het Testwerkproduct

de testmonitorings – en controlefase die hieronder wordt besproken, legt dit onderwerp verder uit.

fasen van het Testbeheer

tijdens het Testbeheerproces moet rekening worden gehouden met de volgende punten. Met andere woorden, de volgende zijn de verschillende fasen van het Testmanagementproces:

1. risicoanalyse
2. schatting van de Test
3. Planning van de Test
4. organisatie van de Test
5. Monitoring en controle van de Test
6. Issues management
7. testrapport

u kunt zien dat de eerste vier fasen meer gaan over planning en de overige drie over uitvoering. Daarom kunnen we het volledige testmanagementproces in twee delen verdelen, d.w.z. Planning en uitvoering.

laten we de verschillende fasen van het testmanagement in detail verkennen.

# 1) risicoanalyse

deze fase omvat het vinden van de risicofactoren en mogelijke oplossingen. Als de risicoanalyse grondig wordt uitgevoerd, kunnen we toekomstige mislukkingen voorkomen of op zijn minst een soort oplossing beschikbaar zou kunnen zijn.

risico is iets dat al dan niet kan gebeuren. Maar als het gebeurt, wat zal dan de impact zijn? Het kan een slechte invloed hebben op de kwaliteit van de software, de reputatie van het bedrijf en nog veel meer.

risicofactoren moeten worden vastgesteld om deze slechte impact te voorkomen. Risicoanalyse moet worden gedaan voor het vinden van risicofactoren. Er zijn twee soorten risico ‘ s, d.w.z. Projectrisico ’s en productrisico’ s. Projectrisico ’s zijn de risico’ s die gerelateerd zijn aan het werkproces en productrisico ’s zijn risico’ s die gerelateerd zijn aan het ontwikkelde product.

# 2) schatting van de Test

schatting van de Test gaat over de voorspelling van de tijd die nodig is voor elke testactiviteit/fase. Omdat dit een schatting is, kan het niet accuraat zijn. Voor een betere test schatting kunnen we de eerdere projecten van ons bedrijf bestuderen of we kunnen overleggen met de teamleden die verantwoordelijk zullen zijn voor die werk-of testfase.

# 3) Testplanning

Testplanning zelf is een lang proces. Het omvat het definiëren van testdoelstellingen, testscope, teststrategie, tijdsplanning, middelen, communicatiebenadering, enz. De eisen voor het bepalen van de testdoelstellingen en het toepassingsgebied moeten zeer duidelijk zijn. Het testplan is voor testers, gebruikers en de leden van het projectteam.

het testplan beschrijft de rol van testen in het project. Het testplan bevat ook de rollen en verantwoordelijkheden, lijst van functies die zullen worden getest en niet zullen worden getest, testomgeving, lijst van tools en veronderstellingen indien van toepassing.

# 4) testorganisatie

tijdens de testplanningsfase hebben we alle mogelijke dingen over testen gepland.

daarom hebben we ervaren teamleden nodig om dit plan uit te voeren of om het plan succesvol te maken. Test organisatie is alles over het bouwen van de perfecte test team voor een succesvol project.

# 5) Monitoring en controle van de Test

tijdens de uitvoering van de testwerkzaamheden of tijdens de uitvoering van het testplan moet al deze voortgang van de werkzaamheden worden gemonitord. Men moet bijhouden van al dit testen werk. Als test monitoring wordt gedaan, dan zal het testteam en de test manager feedback krijgen over hoe de voortgang van het testen is?

met behulp van deze feedback kan de testmanager de teamleden begeleiden om de kwaliteit van verder testwerk te verbeteren. Met behulp van testmonitoring krijgt het projectteam inzicht in de testresultaten. Het helpt ook om te weten over de dekking van de test.

voor grote projecten wordt de testmonitoring uitgevoerd met behulp van een geautomatiseerde tool, omdat het verzamelen van gegevens gemakkelijker zal zijn. Voor kleine projecten zal één persoon alle gegevens of documenten verzamelen die verband houden met de voortgang van de test. Voor het verzamelen van informatie over de voortgang van de test kunnen we gebruik maken van de IEEE 829 test log template. Dit ging allemaal over Test Monitoring.

eens kijken wat testcontrole is? Het projectwerk zal niet altijd volgens plan verlopen. Er kunnen verschillen zijn tussen het plan en het eigenlijke werk. Om deze verschillen te minimaliseren of te verwijderen, moeten we een aantal veranderingen doen en dat is hoe we het testwerk controleren.

#6) Issues Management

Issues kunnen elk probleem zijn dat optreedt tijdens het softwareontwikkelings-en testproces. Het kan de kleinste reden zijn waardoor we niet in staat zijn om een kwaliteitsproduct te ontwikkelen/leveren. Sommige kwesties zijn een show-stopper, dat wil zeggen dat zonder het oplossen van die kwestie we niet in staat zullen zijn om verder te gaan met het verdere proces.

Issue management is alles over hoe we omgaan met deze problemen/problemen. We kunnen het ook Incident management noemen. Issue management vereist een betere planning voor het proces van het oplossen van problemen. Beter probleembeheer hangt af van de vaardigheid en ervaring van de testmanager.

hoe komen deze problemen voor?

er kunnen verschillende redenen zijn om een probleem op te lossen. Sommige kwesties zijn gerelateerd aan strategie en sommige zijn gerelateerd aan de definitie, HR, planning, enz.

Strategievraagstukken:

voorbeelden:

• het project heeft geen geld meer.
• slechte projectcommunicatie.
• het projectbeheerproces voldoet niet aan de gestelde normen.

Definitiekwesties: kwesties die verband houden met vereisten.

voorbeelden: onduidelijke vereisten. Er kunnen veel problemen worden geïntroduceerd vanwege onduidelijke eisen.

Scheduling Issues: Dit is het meest voorkomende type issue. Werknemers moeten moeite hebben om de deadline te halen.

HR-kwesties:

voorbeelden:

• er is een gebrek aan vaardigheid in het team.
• verkeerde employee mapping voor werk.

er kunnen veel meer soorten problemen zijn en we kunnen ze hier niet allemaal noemen. Dus issue management gaat over logging, tracking en het oplossen van problemen.

# 7) testrapport

testrapport helpt de testdekking, de kwaliteit van het ontwikkelde product en de vereiste procesverbeteringen te identificeren. We kunnen beslissen ‘ hoeveel testen er nodig is?’

als er voldoende testen zijn gedaan, kunnen we dit testrapport voorleggen aan de stakeholders of klanten. Zodat ze ook de kwaliteit van het product leren kennen en een idee hebben van hoeveel testen er op het product wordt uitgevoerd.

Test Management Tools

Test management wordt gecompliceerd naarmate we verder gaan in ons softwareontwikkelingsproces en dat is een van de belangrijkste redenen waarom er tegenwoordig zoveel test management tools beschikbaar zijn.

deze instrumenten zullen helpen in de laatste vier fasen van het testbeheerproces (testorganisatie, Testmonitoring & controle, Issues management en testrapport). Aangezien deze hulpmiddelen helpen voor de belangrijke fasen van testmanagement, moeten zij eerst in het project worden overwogen.

hieronder zijn de meest populaire Test Management Tools:

1. qTest
2. PractiTest
3. Zephyr
4. Test Collab
5. TestFLO voor JIRA
6. XQual
7. Xray – Cutting Edge Test Management
8. TestRail
9. QACoverage
10. Eisen en Test Management voor Jira (RTM)
11. SPIRATEST door Inflectra
12. Kualitee
13. aqua
14. Testpad
15. JunoOne

=> Klik hier voor de gedetailleerde beoordelingen van TOP Test Management Tools

Organisatorische Structuren

Laten we zien dat de verschillende organisatorische structuren.

er kunnen bepaalde regels zijn voor organisatiestructuren of er kunnen ideale structuren zijn, maar ongeacht dat kan elke organisatie zijn structuur hebben. Er zijn zoveel organisatiestructuren en elk daarvan heeft zijn voor-en nadelen.

hier zullen we enkele van hen bespreken.

Ten eerste zullen we de eenvoudigste organisatiestructuur zien die wordt gebruikt voor kleine projecten.

in deze structuur rapporteren zowel de testers als de programmeurs aan de Development Manager.

1. de ontwikkelaar heeft een goede controle over de projectactiviteiten.
2. er zal minder kans zijn op een communicatiekloof tussen de test-en ontwikkelingsteams.
3. ook in vergaderingen is het goed om de deadlines voor de ontwikkelingsmanager te bepalen, aangezien hij/zij volledige kennis heeft van het test-en ontwikkelingswerk.
4. teamwerk zal efficiënt zijn, vanwege minimale lagen.

nadelen van deze structuur zijn::

1. aangezien er geen testmanager is, bestaat de mogelijkheid dat testen later in het project worden overwogen.
2. er is een andere mogelijkheid dat het testen minder belangrijk wordt voor het project. Het kan worden beschouwd als laat in het project.

in het algemeen in kleine organisaties voor kleine projecten, gebeurt het dat het ontwikkelingsteam meer tijd nodig heeft dan vermeld en het testteam te lijden heeft, dat wil zeggen dat het testteam het product tegen de deadline moet testen, zodat het testteam minder tijd krijgt om het product te testen.

in deze structuur moet de ontwikkelaar, om een project met succes te voltooien, er rekening mee houden dat hij niet alleen het project wil voltooien, maar ook kwaliteitssoftware wil ontwikkelen.

de op een na meest gebruikte organisatiestructuur:

Dit is het meest voorkomende type organisatiestructuur. In deze structuur rapporteren de testers aan de testmanagers en de ontwikkelaars aan de Development Manager. Zowel de Test Manager als de Development Manager rapporteren aan de Project Manager.

de testmanager is verantwoordelijk voor alle testgerelateerde activiteiten en het is de verantwoordelijkheid van de Development Manager om de software te laten ontwikkelen. De projectmanager zal zowel de test-als de ontwikkelingsactiviteiten controleren.

voordelen:

• in tegenstelling tot de vorige structuur, hier in deze structuur, zijn er verschillende managers voor het testen en ontwikkeling, dus beide kunnen zich richten op hun werk. Ze zullen toegewijd blijven aan hun werk en er zullen minder afleidingen voor hen zijn.
• in deze structuur kunnen de testactiviteiten niet worden verwaarloosd of kunnen ze niet als laat in het project worden beschouwd. Dit betekent dat zowel testen als ontwikkeling even belangrijk zullen worden.
• als het gaat om het nemen van kritische beslissingen, is het testteam onafhankelijk.

nadelen:

• er is een mogelijkheid van een communicatiekloof als gevolg van meerdere niveaus.

testmanagement Vs organisatiestructuren

organisatiestructuren beïnvloeden direct het testmanagement. Verschillende organisatiestructuren hebben een verschillende impact op het testmanagement, dus het testmanagement varieert afhankelijk van de vaardigheid en ervaring van de testmanager en van de positie van de testmanager in de organisatiestructuur.

we hebben hier twee organisatiestructuren gezien. In de eerste structuur zijn de ontwikkelmanager en de testmanager dezelfde persoon, vandaar dat het testmanagement beïnvloedt. De development manager heeft als doel om software te ontwikkelen, en daarbij moet hij / zij ook kijken naar het testwerk.

Zo kan hij/zij soms partijdige meningen geven. Hij / zij kan gewoon vergeten de kwestie en ga je gang. Op deze manier kan het testmanagement beïnvloeden. Een onafhankelijke testmanager zal meer rechtvaardigheid kunnen bieden en testmanagement zal beter zijn met onafhankelijke testmanagers.

conclusie

we hebben beide onderwerpen, d.w.z. testmanagement en organisatiestructuren, afzonderlijk en samen met de relatie tussen deze twee gezien. We kunnen concluderen dat organisatiestructuren van invloed zijn op testmanagement.

bij vergelijking van beide bovengenoemde structuren zal in de tweede structuur het testmanagement beter worden behandeld dan in de eerste. De reden hiervoor zou een toegewijde testmanager kunnen zijn.

organisatiestructuren verschillen van organisatie tot organisatie. Hoewel er een bepaald proces is voor testmanagement (of teams kunnen testmanagementtools gebruiken), zal testmanagement verschillen vanwege verschillende organisatiestructuren, testmanagers, de vaardigheden en ervaring van testmanager.