Feedback geven als software tester
14 juli 2019 

Feedback geven als software tester

Onze omgeving ziet het vinden van fouten in de software als de belangrijkste taak van een tester.

Ik zelf vind dat onze belangrijkste taak is er voor zorgen dat er kwalitatief goede software wordt geleverd die voldoet aan de wensen van de gebruiker. Het vinden van onduidelijkheden in de requirements is wat mij betreft ook een belangrijke taak van een tester.

Terug naar fouten in de software. Als tester moeten wij ons realiseren dat wij altijd bezig zijn een oordeel te vellen over het werk van iemand anders. De manier waarop wij bevindingen melden speelt dan ook een belangrijke rol.

Praktijk voorbeeld 1

Ik heb in het verleden wel eens meegemaakt dat het test team een grote banner in hun kamer had opgehangen met daar op de tekst “ vandaag vinden wij de 1000e fout”.

Dat dat voor een testteam een belangrijke mijlpaal is begrijp ik. Want als er geen fouten gevonden wordt dan vindt onze opdrachtgever dat we te weinig resultaten boeken. Je kunt je echter wel afvragen of zo'n banner de samenwerking met de ontwikkelaars zal bevorderen.

Praktijk voorbeeld 2

In een ander project had de programmamanager bedacht dat het wel iets was om in de hal bij de liften een console neer te zetten met daarop een PC. Iedere morgen werd daar een grafiek op gezet met de status van de gevonden en opgeloste bevindingen. Het was helaas geen rooskleurige grafiek. Het aantal openstaande bevindingen werd steeds hoger. En toen kwam op een dag de Directeur van het bedrijf voorbij. Hij keek naar de grafiek en zei: “Wat voor een bagger systeem hebben we gekocht”.  Nog dezelfde dag werd er gestopt met het dagelijks plaatsen van de actuele grafiek.

Dat soort grafieken lijkt interessant. Maar wat zegt het als 80% van de geregistreerde bugs betrekking hebben op syntactische fouten en geen enkele bug productie blokkerend is.

Praktijk voorbeeld 3

Een ander voorbeeld heeft betrekking op het testen zelf. In een van de projecten waarvoor ik heb gewerkt had een developer het omgedraaid. Op de muur achter hem had hij een banner opgehangen met de vragen: “Heb je wel de juiste data gebruikt? Heb je de juiste systeeminstellingen gebruikt?” Iedere keer als er een tester kwam met een bug, wees hij naar de banner achter hem. Blijkbaar had hij iets te vaak meegemaakt dat testers verkeerde data of systeeminstellingen hadden gebruikt.

Het geven van feedback valt of staat met de manier waarop bugs worden gemeld. En daarbij maakt het niet uit of het om een schriftelijke of mondelinge melding gaat. De communicatie dient constructief en opbouwend te zijn. Het mag zeer zeker niet oordelend zijn richting de developer. De omstandigheden waaronder een developer moet werken zijn vaak bepalend voor de kwaliteit van het geleverde werk. En dat geldt natuurlijk ook voor testers.

Mijn aanpak binnen Scrum

Het werken met Agile / Scrum maakt het makkelijker om op een constructieve manier bugs te melden. De developer zit tenslotte naast of aan een bureau vlak in de buurt.

Ik zelf heb de gewoonte om aan de developer te vragen of ik iets mag laten zien. Ik laat dan zien wat er gebeurt en samen bekijken we wat er aan de hand is:

  • Het kan zijn dat ik bij de uitvoering verkeerde handelingen heb gedaan, verkeerde data heb gebruikt, nog werk met een oude versie, etc. Ik kan dan het e.e.a. aanpassen en de test nogmaals uitvoeren. Een onterechte registratie van een bug is dan voorkomen.
  • Het kan zijn dat we het requirement anders hebben geïnterpreteerd. Samen bespreken we dan met de product owner of business analist hoe het requirement geïnterpreteerd moet worden. Vaak leidt dit tot een verduidelijking van het requirement. En vervolgens voeren we beide de eventuele aanpassingen door.
  • Het kan zijn dat de developer een fout in de code heeft gemaakt. Afhankelijk van het moment waarop de code kan worden aangepast zal er wel / niet een bug op de product backlog worden geplaatst.
Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down