Complexiteit
Wat bedoelde je precies met deze opmerking? Waarom zijn de testresultaten van Kerry “blokkerend” en dezelfde testresultaten van Adam “goed”? Kun je wat meer uitleggen over de context van je resultaten?
Binnen TestMonitor hebben we meer dan 22 jaar ervaring in complexe testtrajecten. En vanuit die ervaring is de software en methode ontwikkeld. Wij geloven namelijk dat inzicht in kwaliteit de sleutel is tot succesvolle IT. Met TestMonitor krijg je inzicht in de kwaliteit van software, kun je zelf eenvoudig software testen, met en door eindgebruikers. En daarom zetten wij twee vragen centraal: Werkt het? En kun je ermee werken?
In onze filosofie is iedere gebruiker een tester en als je die de juiste werkwijze geeft, zul je versteld staan hoeveel kwaliteit zij eenvoudig inzichtelijk kunnen maken. En of die gebruiker nu de directeur is, een medewerker van de service-afdeling, of een professionele tester, met de juiste structuur en tools kan iedereen testen.
Binnen TestMonitor hebben we dan ook slimme filteropties en specifieke functionaliteiten gebouwd om de massa aan testresultaten goed te kunnen managen en analyseren. Als 5 personen ieder 10 testgevallen gaan testen, heb je bij afronding 50 testresultaten. Deze resultaten ga je analyseren om vervolgens issues aan te maken, welke gerelateerd zijn aan specifieke testresultaten. Het onderstaande plaatje laat zien dat de massa aan testresultaten uiteindelijk zal leiden tot issues.
Elk issue wordt gekoppeld aan een eigenaar, die ervoor zorgdraagt dat het issue ook daadwerkelijk wordt opgelost. En als de issues dan zijn opgelost, zullen de gekoppelde testgevallen of testruns opnieuw getest worden om vast te stellen dat het issue daadwerkelijk is opgelost. Een eenvoudige en simpele kwaliteitscyclus.
Om te voorkomen dat er nog ergens issue lijsten “zwerven” die 1 minuut voor 12 toch nog ontwikkeld of geïmplementeerd moeten worden, is onze stelregel: zitten de issues niet in TestMonitor, dan doen ze niet mee. Kortom: in TestMonitor staat altijd de waarheid! Het voordeel van een dergelijke aanpak is dat alle issues vanuit één centrale plek worden geanalyseerd en bewaakt. Daardoor kunnen wij in TestMonitor eenvoudige testtrajecten managen met enkele testers, maar ook hele complexe testtrajecten met 500 gebruikers verdeeld over verschillende landen.
Uit eerder onderzoek is gebleken dat binnen een gemiddeld ERP testtraject al snel tussen de 500 - 700 issues afgehandeld moeten worden. Veelal door meerdere stakeholders: de eigen organisatie, de implementatiepartner, de consultants, etc. En deze issues zijn niet tot stand gekomen door 500 testresultaten, maar een veelvoud daarvan. Uit TestMonitor hebben we vastgesteld dat dit gemiddeld een factor 8 is. Dus in een project waar 500 issues aangemaakt zijn, zijn 4000 testresultaten geregistreerd door verschillende testers. In deze 4000 resultaten zitten dus alle testresultaten door elkaar: de geslaagde en niet-geslaagde.
Samengevat zitten alle testontwerpen, testresultaten en issues allemaal in TestMonitor, waarin ze gemanaged en geanalyseerd kunnen worden. Toch ontdekte we dat buiten TestMonitor om nog veel gecommuniceerd werd over bepaalde resultaten en issues. Deze communicatie ging of mondeling of met behulp van e-mail. Stel je eens voor dat over die 500 issues verschillende e-mails worden verstuurd over de status of over de impact of over onduidelijkheden vanuit de eigenaar. Je krijgt al snel een chaos aan e-mailcommunicatie die niet meer onder controle is.
Om dit probleem op te lossen hebben we een compleet communicatie platform in TestMonitor gebouwd, waarbij de mogelijkheid wordt geboden om opmerkingen te plaatsen bij issues, maar ook bij testresultaten. Met de notificatie functionaliteit worden alle betrokkenen geïnformeerd.
Opmerkingen in issues
In TestMonitor hebben we een project onderzocht om te achterhalen hoe krachtig het communicatieplatform binnen TestMonitor is. Binnen dit project waren in totaal 790 issues geregistreerd. Binnen deze issues waren in totaal 6150 opmerkingen geplaatst, gemaakt door 73 verschillende personen. Stel je eens voor hoeveel e-mail chaos dit zou opleveren en hoeveel inefficiëntie in communicatie en productiviteit. Nog maar te zwijgen over het vasthouden en kunnen nalezen van al deze informatie bij een betreffend issue. Bijzonder detail is dat bij één specifiek blokkerend issue >100 opmerkingen zijn geplaatst.
Iedereen met de juiste rechten kan opmerkingen plaatsen bij elk issue, maar je kunt nog meer:
- Antwoorden op een opmerking
Klik op de antwoord-knop en jouw opmerking wordt embedded in de hoofdopmerking. Hierdoor ontstaat direct een conversatie-structuur.
- Duimpje omhoog
Het kan zijn dat je niet de behoefte hebt om te reageren, maar je wel met de opmerking eens bent. Een eenvoudig “duimpje omhoog” zorgt ervoor dat degene die de opmerking heeft geplaatst zicht heeft hoeveel personen het een relevante opmerkingen vonden.
- @ mention
Met de @ mention kun je direct personen die in het project zitten notificeren. De persoon krijgt dan automatisch een notificatie, waardoor deze hierop extra geattendeerd wordt.
- # link
Met de # link kun je bestaande issues in het project koppelen in je opmerking. Hoe vaak gebeurt het niet in een project dat issue I1 en issue I63 nagenoeg hetzelfde zijn. Met een # llink en @ mention kun je dus direct de eigenaar van de issues attenderen en in de opmerking ook een relatie leggen met # link tussen deze issues.
Opmerkingen in testresultaten
Hoe vaak kom je als testmanager niet in een situatie, waarbij twee testers met dezelfde achtergrond, dezelfde test uitvoeren en totaal verschillende testresultaten hebben. Dat hoeft natuurlijk niet automatisch fout te zijn, maar soms wil je snel dat bijvoorbeeld tester Harold zijn testresultaat even heroverweegt. Zeker als hier dan extra context bij kan worden gegeven.
Voorheen werd er een e-mail gestuurd met de vraag of het testresultaat opnieuw beoordeeld kon worden. Die e-mail komt vervolgens op de grote hoop van e-mails met als gevolg dat de tester waarschijnlijk even andere prioriteiten heeft en de testmanager met een “open eind” zit. Eén “open eind” is nog wel te managen, maar met een grote hoeveelheid wordt dit al bijzonder onoverzichtelijk en complex.
Ook hiervoor hebben we de functionaliteit van de communicatiecyclus gebouwd. Het is nu mogelijk in TestMonitor om bij het analyseren van de testresultaten snel een opmerking plaatsen, welke direct bij de betrokkenen worden afgeleverd. En met de @ mention functionaliteit kun je zelfs meerdere mensen koppelen aan de “discussie”.
De tester krijgt een notificatie in TestMonitor en in bijvoorbeeld Slack of e-mail, afhankelijk van je persoonlijke voorkeuren.
In combinatie met de “markeren als gelezen” functionaliteit, heb je dus grip op de “open eindjes” door alleen die testresultaten te markeren die ook volledig zijn afgerond. Stel je dan ook nog een filter in, waarbij alleen de niet-gelezen testresultaten worden getoond, dan heb je pas echt grip op je kwaliteitscyclus.
Start testing with TestMonitor
If you need assistance or if you have any questions regarding TestMonitor, feel free to contact us at any time. We are here to help.
Stay in touch! Follow TestMonitor on Twitter and LinkedIn.