Menu

Testmanagement-zelfstudie: een ultieme gids voor testmanagement

  • Hoofd
  • Andere
  • Testmanagement-zelfstudie: een ultieme gids voor testmanagement

test management tutorial

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Dit is een zelfstudie over testbeheer voor softwaretests. Het omvat testbeheerfasen, tools en testbeheer versus organisatiestructuur:

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

Denk je dat de organisatiestructuur van invloed is op testmanagement?

Als je antwoord nee is, zullen we zien waarom? Zo ja, laten we eens kijken hoe dit van invloed is. Om de relatie tussen deze twee te vinden, moeten we deze onderwerpen duidelijk begrijpen en vervolgens de relatie tussen testmanagement en organisatiestructuur onderzoeken.

Testbeheer

Wat je leert:

Inleiding tot testmanagement

Testmanagement betekent het beheer van het volledige proces van softwaretests voor een bepaald project. Het testmanagementproces wordt toegepast op de hele levenscyclus van softwareontwikkeling. Daarom, idealiter, zodra het softwareontwikkelingsproces begint, zou het testbeheerproces ook moeten starten.

Test Manager had de volgende verantwoordelijkheden:

  • De testmanager moet zorgen voor consistentie en kwaliteit van deze werkproducten.
  • Werk samen met testanalist en technisch testanalist om de juiste sjabloon te selecteren en aan te passen.
  • Werk samen met testanalist en technisch testanalist om normen voor deze producten vast te stellen, zoals gedetailleerde niveaus.
  • Beoordeel de werkproducten met behulp van de juiste technieken.

Test Management Componenten

Testbeheer is onderverdeeld in 5 delen voor een beter begrip:

  1. Test documentatie
  2. Test schatting
  3. Teststatistieken
  4. Meting van de voortgang van de test
  5. Metrische gegevens voor het bewaken van de testlevenscyclus

# 1) Testdocumentatie

Er zijn drie soorten testdocumentatie die hieronder worden vermeld:

  • Testbeleid
  • Teststrategie
  • Master testplan

# 1) Testbeleid:

  • Vat de waarde samen die de organisatie aan testen ontleent.
  • Definieert testbeleid.
  • Beschrijft hoe u de effectiviteit van testen kunt evalueren.
  • Schetst het testproces.
  • Specificeer hoe de organisatie het testproces zal verbeteren?

# 2) Teststrategie:

  • Beschrijft de algemene testmethodologieën die worden gebruikt om project- en productrisico's te beheren.
  • Analytische strategieën: Zoals op risico gebaseerde tests.
  • Modelgebaseerde strategie: Zoals een operationeel profiel waarbij het testteam een ​​model ontwikkelt op basis van actuele en geaccepteerde situaties van omgeving, input en condities.
  • Methodologische strategie: Kwaliteitskenmerken waarbij het testteam een ​​set testcondities, checklist of verzameling algemene, logische tests gebruikt.
  • Proces- of normconforme technieken: Volgt een reeks van het proces zoals SCRUM / Agile.
  • Reactieve strategieën: Gebruik van op defecten gebaseerde AANVALLEN ZOALS EXPLORATORISCHE TESTEN.
  • Consultatieve strategie: Zoals gebruikersgestuurd testen waarbij het testteam vertrouwt op de input van een of meer belanghebbenden om testvoorwaarden te bepalen, zoals Outsourced Compatibility Testing.
  • Beschrijft ook:
    • Integratieprocedures
    • Testspecificatietechnieken
    • Onafhankelijkheid van testen
    • Verplichte en optionele normen
    • Test omgeving
    • Gereedschap
    • Herbruikbaarheid van softwareproducten
    • Opnieuw testen en regressie.

# 3) Master testplan:

  • Het omvat alle testtaken die moeten worden uitgevoerd.
  • Het bespreekt hoe testen de teststrategie en het beleid zullen implementeren.
  • Als iets niet wordt beschreven, moet het testplan beschrijven waarom en het mitigatieplan daarvoor.
  • Inhoud van het testplan is:
    • Items om te testen
    • Kwaliteitskenmerken die moeten worden getest.
    • Schema
    • Uitvoeringscyclus
    • Defecte variabelen
    • Test items binnen bereik
    • Exit criteria
    • Project risico's
    • Algehele governance van testinspanningen,
    • Rollen en verantwoordelijkheden
    • Input en output

# 2) Testschatting

Algemene punten:

  • Is een managementactiviteit
  • Het is gebaseerd op ervaring.
  • Het biedt een specifieke en gedetailleerde catalogus van kosten, middelen, taken en mensen.
  • Een eenmaal opgemaakte schatting moet samen met de verantwoording aan het management worden bezorgd.
  • De uiteindelijke schatting vertegenwoordigt de best mogelijke balans tussen organisatie- en projectdoelen.
  • De schatting is gebaseerd op informatie die op dat moment beschikbaar was en werd opgesteld.
  • Om nauwkeurig te blijven, moeten schattingen worden bijgewerkt om nieuwe en gewijzigde informatie weer te geven.

Factoren die de testschatting beïnvloeden:

  • Vereist kwaliteitsniveau
  • Grootte van het systeem
  • Historische gegevens
  • Procesfactoren zoals strategie, ontwikkeling en levenscyclus
  • Materiële factoren zoals testomgeving, automatisering, tools en data
  • Mensen factor
  • Complexiteit van proces
  • Training en KT (Knowledge Transfer)
  • Assimilatie en ontwikkeling van nieuwe tools en technologie, processen of technieken.
  • De eis van een hogere graad van de gedetailleerde testspecificatie.
  • Timing van aankomst van componenten
  • Testgegevens.

Raden:

  • Work breakdown structure
  • Teamschattingssessie
  • Tester - Developer-ratio
  • Organisatie geschiedenis
  • Functiepuntanalyse, LOC.

Testschatting wordt later in de tutorial verder uitgelegd.

# 3) Teststatistieken

  • Wat wordt gemeten, wordt als voltooid beschouwd?
  • Wat meet niet, wordt gemakkelijk genegeerd?
  • Er moet een beperkte reeks bruikbare statistieken worden gedefinieerd.
  • Alleen die statistieken moeten worden gedefinieerd waarvan de interpretatie door iedereen is overeengekomen.
  • Het rapporteren en samenvoegen van statistieken moet worden geautomatiseerd.
  • De manager moet de informatie valideren in metrisch.

Projectstatistiek: % geslaagd, mislukt uitgevoerd etc.

Productstatistiek:

  • Kenmerken van het product
  • Defectdichtheid

Processtatistiek: Meet het vermogen om te testen als% van het defect.

Mensen: Vermogen van het individu.

Voortgangsstatistiek testen:

  • Het aantal testcondities / cases, gepland versus uitgevoerd.
  • Totaal defect gecategoriseerd naar ernst, prioriteit, huidige toestand en effect-subsysteem.
  • Het aantal vereiste, geaccepteerde, build en geteste wijzigingen.
  • Geplande versus werkelijke kosten.
  • Geplande versus werkelijke duur
  • Geplande versus werkelijke testmijlpaal.
  • Productkwaliteit Risicostatus
  • % verlies van testinspanning, kosten of tijd.

# 4) Meting van de voortgang van de test

Productrisico's:

  • % gedekt risico.
  • % van risico voor mislukkingstest
  • % Risico geïdentificeerd door het individu.

Gebreken:

  • Het aantal gevonden defecten versus het aantal ingediende defecten.
  • Gemiddelde aankomsttijd van storingen
  • Gebreken in de betreffende testitems.
  • Detectie van RCA (Root Cause Analysis)
  • Het defect is Test releases.
  • Defect in fase
  • Prioriteit en ernst
  • Rapport afwijzingen versus dupliceren
  • Het kostte tijd om op te lossen
  • Het aantal nieuwe defecten dat is geïntroduceerd door het herstellen van oude defecten.

Test:

  • Totaal aantal van de test geslaagd, mislukt, deelnemer, geblokkeerd
  • Het totale aantal regressietestgevallen.

Dekking:

  • Vereiste en ontwerpdekking
  • Risicodekking
  • Omgevingsconfiguratiedekking
  • Code dekking

# 5) Metrieken voor het bewaken van de testlevenscyclus

Monitor het testplan

  • Aantal risico's en vereisten
  • Opsporing van defecten
  • Plan versus daadwerkelijke inspanningen.

Monitor testontwerp

  • Het aantal defecten dat tijdens het ontwerp is gevonden.

Monitor testanalyse

  • Aantal voorwaarden
  • Aantal defecten in analyse

Monitor de implementatie van de test

  • % van omgevingsconfiguratie
  • % van de testcase geautomatiseerd.

Controleer de uitvoering

  • % geslaagd, mislukt, niet uitgevoerd, geblokkeerde testgevallen
  • % Gedekte testcases
  • Geplande versus werkelijke defecten opgelost
  • % van plan versus werkelijke dekking

Monitor sluiting

  • % van de testcases slagen, ail
  • % van testcases gecontroleerd in de categorie herbruikbaar
  • % geautomatiseerde testcases.
  • Het aantal opgeloste / niet opgeloste defecten.
  • % van testwerkproduct

In de hieronder besproken testbewakings- en controlefase wordt dit onderwerp nader toegelicht.

Testmanagementfasen

Tijdens het testmanagementproces moet men rekening houden met de volgende punten. Met andere woorden, de volgende zijn de verschillende fasen van het testmanagementproces:

  1. Risico analyse
  2. Test schatting
  3. Testplanning
  4. Testorganisatie
  5. Test Monitoring en controle
  6. Beheer van problemen
  7. Test rapport

Je merkt dat de eerste vier fasen meer over planning gaan en de overige drie over uitvoering. Daarom kunnen we het complete testmanagementproces opdelen in twee delen, namelijk Planning en Uitvoering.

Laten we de verschillende testmanagementfasen in detail bekijken.

# 1) Risicoanalyse

Deze fase omvat het achterhalen van de risicofactoren en mogelijke oplossingen. Als de risicoanalyse grondig wordt uitgevoerd, kunnen we toekomstige storingen voorkomen of is er in ieder geval een oplossing beschikbaar.

Risico is iets dat wel of niet kan gebeuren. Maar als het gebeurt, wat zal dan de impact zijn? Het kan de kwaliteit van software, de reputatie van het bedrijf en nog veel meer nadelig beïnvloeden.

Risicofactoren moeten worden ontdekt om deze slechte impact te voorkomen. Risicoanalyse moet worden uitgevoerd om risicofactoren te achterhalen. Er zijn twee soorten risico's, namelijk projectrisico's en productrisico's. Projectrisico's zijn de risico's die verband houden met het werkproces en Productrisico's zijn risico's die gerelateerd zijn aan het ontwikkelde product.

# 2) Testschatting

Testschatting gaat over het voorspellen van de tijd die nodig is voor elke testactiviteit / -fase. Aangezien dit een schatting is, kan deze niet nauwkeurig zijn. Voor een betere testschatting kunnen we de afgelopen 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 langdurig proces. Het omvat het definiëren van testdoelstellingen, testscope, teststrategie, tijdplanning, middelen, communicatieaanpak, etc. Vereisten moeten heel duidelijk zijn voor het definiëren van testdoelstellingen en scope. Het testplan is bedoeld voor testers, gebruikers en de projectteamleden.

Het testplan beschrijft de rol van testen in het project. Het testplan bevat ook de rollen en verantwoordelijkheden, lijst met functies die wel en niet getest gaan worden, testomgeving, lijst met tools en eventuele aannames.

# 4) Testorganisatie

Tijdens de testplanningsfase hebben we alle mogelijke zaken rondom testen gepland.

Daarom hebben we bekwame teamleden nodig om dit plan uit te voeren of om het plan succesvol te maken. Bij testorganisatie draait alles om het bouwen van het perfecte testteam voor een succesvol project.

# 5) Bewaking en controle van testen

Tijdens het testen of terwijl de testers het testplan uitvoeren, moet de voortgang van al deze werkzaamheden worden bewaakt. Men moet al dit testwerk bijhouden. Als er testmonitoring is gedaan, krijgen het testteam en de testmanager feedback over de voortgang van het testen.

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 zicht op de testresultaten. Het helpt ook om de testdekking te kennen.

Voor grote projecten wordt de testmonitoring gedaan met behulp van een geautomatiseerde tool, omdat het verzamelen van gegevens gemakkelijker wordt. Voor kleine projecten verzamelt één persoon alle gegevens of documenten die betrekking hebben op de voortgang van de test. Voor het verzamelen van informatie over de voortgang van de test kunnen we de hulp inroepen van de IEEE 829-testlogsjabloon. Dit ging allemaal over Test Monitoring.

Laten we eens kijken wat Testcontrole is? Projectwerk zal niet altijd verlopen zoals gepland. Er kunnen enkele verschillen zijn tussen het plan en het daadwerkelijke werk. Om deze verschillen te minimaliseren of weg te nemen, moeten we enkele wijzigingen aanbrengen en zo beheersen we het testwerk.

# 6) Beheer van problemen

Problemen kunnen elk probleem zijn dat optreedt tijdens het softwareontwikkelings- en testproces. Het kan de kleinste reden zijn waardoor we geen kwaliteitsproduct kunnen ontwikkelen / leveren. Sommige problemen zijn een showstopper, d.w.z. zonder dat probleem op te lossen, kunnen we niet doorgaan met het verdere proces.

Issue management heeft alles te maken met hoe we deze issues / problemen aanpakken. We kunnen het ook wel Incident management noemen. Issue management vereist een betere planning voor het proces van het oplossen van issues. Beter issue management hangt af van de vaardigheid en ervaring van de testmanager.

Hoe treden deze problemen op?

Er kunnen verschillende redenen zijn waarom een ​​probleem optreedt. Sommige kwesties houden verband met strategie en andere met de definitie, HR, planning, enz.

Strategische kwesties ​

Voorbeelden:

  • Het project heeft geen geld meer.
  • Slechte projectcommunicatie.
  • Het projectmanagementproces is niet volgens de gestelde normen.

Definitieproblemen : Kwesties die verband houden met vereisten.

Voorbeelden: Onduidelijke vereisten. Vanwege onduidelijke vereisten kunnen veel problemen worden geïntroduceerd.

Planningsproblemen: Dit is het meest voorkomende probleem. Medewerkers hebben moeite om de deadline te halen.

HR-problemen:

Voorbeelden:

  • Er is een gebrek aan vaardigheid in het team.
  • Verkeerde werknemer mapping voor werk.

Er kunnen veel meer soorten problemen zijn en we kunnen ze hier niet allemaal noemen. Issuesmanagement gaat dus over het loggen, volgen en oplossen van problemen.

# 7) Testrapport

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

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

Test Management Tools

Testbeheer wordt ingewikkeld naarmate we verder gaan in ons softwareontwikkelingsproces en dat is een van de belangrijkste redenen waarom er tegenwoordig zoveel testbeheertools beschikbaar zijn.

Deze tools zullen helpen bij de laatste vier fasen van het testmanagementproces (testorganisatie, testbewaking en -controle, probleembeheer en testrapport). Aangezien deze tools helpen bij de belangrijke fasen van testmanagement, moeten ze als eerste in het project worden beschouwd.

Hieronder staan ​​de meest populaire testbeheertools vermeld:

  1. qTest
  2. PractiTest
  3. Zefier
  4. Test Collab
  5. TestFLO voor JIRA
  6. XQual
  7. Xray - Baanbrekend testbeheer
  8. TestRail
  9. QACoverage
  10. Vereisten en testbeheer voor Jira (RTM)
  11. SPIRATEST door Inflectra
  12. Kualitee
  13. aqua
  14. Testpad
  15. JunoOne

​ Klik hier voor gedetailleerde recensies van TOP Test Management Tools

Organisatiestructuren

Laten we eens kijken naar de verschillende organisatiestructuren.

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

Hier zullen we er enkele bespreken.

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

organisatiestructuur

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

  1. De ontwikkelingsmanager heeft een goede controle over de projectactiviteiten.
  2. Er zal minder kans zijn op een communicatiekloof tussen de test- en ontwikkelteams.
  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 onder meer:

  1. Aangezien er geen testmanager is, bestaat de mogelijkheid dat testen laat in het project wordt overwogen.
  2. Er is nog een mogelijkheid dat testen minder belangrijk wordt voor het project. Het kan laat in het project worden overwogen.

Over het algemeen komt het in kleine organisaties voor kleine projecten voor dat het ontwikkelteam meer tijd nodig heeft dan vermeld en het testteam moet lijden, dwz het testteam zal het product voor de deadline moeten testen, zodat het testteam minder tijd krijgt om te testen het product.

In deze structuur moet de ontwikkelingsmanager, om een ​​project met succes af te ronden, in gedachten houden dat zijn doel niet alleen is om het project te voltooien, maar om kwaliteitssoftware te ontwikkelen.

De op een na meest gebruikte organisatiestructuur:

2e organisatiestructuur

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

De Test Manager 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 ontwikkelingsactiviteiten aansturen.

Voordelen:

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

Nadelen:

  • Er is een mogelijkheid van een communicatiekloof vanwege meerdere niveaus.

Testmanagement versus organisatiestructuren

Organisatiestructuren hebben een directe invloed op het testmanagement. Verschillende organisatiestructuren hebben een verschillende impact op testmanagement, daarom varieert testmanagement afhankelijk van de vaardigheid en ervaring van de testmanager en de positie van de testmanager in de organisatiestructuur.

vergelijking van open source requirements management tools

We hebben hier twee organisatiestructuren gezien. In de eerste structuur zijn de ontwikkelingsmanager en de testmanager dezelfde persoon, dus het heeft invloed op het testmanagement. De ontwikkelingsmanager heeft als doel software te ontwikkelen en daarbij moet hij / zij ook kijken naar het testwerk.

Zo kan hij / zij soms bevooroordeelde meningen geven. Hij / zij kan het probleem gewoon over het hoofd zien en doorgaan. Op deze manier kan het testmanagement beïnvloeden. Een onafhankelijke testmanager zal meer rechtvaardigheid kunnen bieden en testmanagement zal beter zijn met onafhankelijke testmanagers.

Gevolgtrekking

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

Bij het vergelijken van beide bovengenoemde structuren, zal in de tweede structuur testmanagement beter worden aangepakt dan 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, vaardigheden en ervaring van de testmanager.

Aanbevolen literatuur

^