Exploritory testing is in. Bijna iedere Agile tester beweert het te doen. De ene cursus na de andere, de ene presentatie na de andere, het onderwerp is helemaal van deze tijd. Toch kom ik bijna niemand tegen, die mij kan vertellen wat exploritory testing nu eigenlijk is. En zelf zou ik me ook nog lang niet aan een definitie wagen. Wat ik wel weet, is dat veel "Exploritory testing" hier zeker niet onder valt. Er zijn grote verschillen tussen exploritory testing en het alleen maar loslaten van de waterval testmethode. Dus wat is exploritory testing niet?
Doelloos testen
Testers gaan achter een applicatie zitten en klikken gewoon op de eerste de beste knop. En daarna op een knop. En daarna op een menu-item. Vroeger mocht dat niet, want er was geen vastgelegd testscript. En nu, nu mag het nog steeds niet.
Om je teststijd goed te besteden, is het verstandig om een doel voor ogen te hebben. Je hebt vaak niet alle tijd van de wereld. En bij de invoering van Exploritory testing is het belang van het risico op een bug en de mogelijk schade van een bug niet opeens onbelangrijk geworden. Daarom is het nog steeds verstandig om het belangrijkste het eerst te testen. Een rijtje met testdoelen kan daarbij helpen.
De formulering hoeft niet SMART te zijn, dus volledig op een manier te begrijpen. Je mag als tester best wat meer vrijheid nemen. Als je doel is een invulformulier te testen, mag je best op basis van ervaring bepalen of je het formulier hiervoor een, twee, vijf of tien keer invoert. Als je maar wel beseft dat "Kijken of de applicatie goed werkt" wel een erg ruime doelomschrijving is.
Geen testvoorbereiding uitvoeren
Waar Scrum en Agile vaak verwart worden met "Geen documentatie schrijven", wordt Exploritory testing vaak verwart met "Geen testvoorbereiding". Hoe vreemd het misschien ook klinkt, je bereidt je testen niet minder keren voor. In tegendeel, je bereidt je testen vaak veel meer keren voor dan bij de watervalmethode. Niet alleen voor je eerste testuitvoering. Maar ook tussen verschillende rondes van testuitvoering door.
Testvoorbereiding kan misschien bestaan uit alleen maar het bepalen van doelen. Het kan ook bestaan uit het lezen van een document. Of het opstellen van een minimale set aan gewenste testcases. Het hoeft alleen niet meer te bestaan uit volledig uitgewerkte testscript voor elke test die je uit wil voeren. Maar testvoorbereiding blijft ervoor zorgen dat je je testen beter uitvoert, dus waarom zou je het laten?
Daarnaast kan je tijdens het exploritory testing iets tegenkomen wat je verder wil onderzoeken. Wat je dieper wil testen of anders wil testen. Een onverwachtse bug. Een foutje in een tekst. Dat dit mogelijk is, is een van de grootste krachten van exploritory testing. Maar dit kan wel betekenen, dat je hier even over na moet denken. En net als in het begin van het testen even de tijd moet nemen een doel vast te stellen en te bepalen wat de beste manier is om te testen. Juist omdat bij exploritory testing leren erg centraal staat, leer je steeds beter hoe je de applicatie het beste kan testen. Maar dat vraagt dus elke keer ook weer om nieuwe testvoorbereiding.
Testen afbreken voor je doel bereikt is
Je bent een invulformulier aan het testen. Plotseling zie je dat de e-mail, het resultaat van het invulformulier, er in Outlook niet mooi uitziet. Meteen ga je de mail bekijken in andere e-mailprogramma's. Is die daar wel goed? Maar terwijl je dat doet, zie je dat het adres van de organisatie in de e-mail fout is. Dat staat in de instellingen van de applicatie. Dus ga je daarheen om het te testen. Je leert steeds meer van de applicatie. Je bepaalt steeds beter wat je wil testen. Alleen vergeet je testen af te ronden. En je probeert nu op een heleboel zaken tegelijkertijd te letten. Wat vaak inhoudt, dat de kans op fouten missen steeds groter wordt.
Een van de moeilijkste zaken is de focus houden. Je hebt een testdoel, blijf dan alleen met dat testdoel bezig, tot je het doel bereikt is. Zie je iets anders, schrijf het op. Maar besteed er geen verdere tijd aan. Dat zorgt ervoor dat je je testen afrond en daarnaast dat je je aandacht zeer goed kan focussen op een onderwerp. En dat komt de kwaliteit van je testen weer ten goede.
maandag 23 mei 2016
zondag 15 mei 2016
Onderhoudbaar maken van automatisch testen
Je hebt je automatische testen. En dan wijzigt er iets. Plotseling vallen er heel veel van je testen om. Dat wordt aanpassen. Dat wordt veel werk. Kan je ervoor zorgen dat het onderhouden van je automatische testen minder tijd kost? Het blijft altijd tijd kosten, maar ik heb gemerkt dat er trucjes zijn om de tijd te verminderen. Zowel zonder als met programmeerkennis.
Naamgeving
Hoe eenvoudig ook, aanpassen gaat een stuk eenvoudiger als je aan de hand van de naamgeving kan raden wat de inhoud is. Geef je bestanden en/of procedures altijd een naam, die de test of de testsuite beschrijft. Zo geef ik vaak de testsuite in Selenium een beschrijving van het scherm dat ik wil testen. En vervolgens de testen een korte beschrijving van de test. Bij voorkeur laat ik de naam van de testsuite terugkomen in de testcase. Zo zal ik een testsuite "Zoeken" noemen, omdat ik hier het scherm wil testen waar de zoekgegevens ingevoerd worden. En vervolgens noem ik de testcase "ZoekenPostcode", omdat in deze test ik wil nagaan of het zoeken op postcode goed werkt.
Houdt je naamgeving ook zo consistent mogelijk, zodat er automatisch een groepering ontstaat. Als je de testen "ZoekenPostcode", "NaamZoeken" en "SearchPlace" noemt, maak je het jezelf moeilijk. Begin de naam, als dit kan, met de groep waar het bestand en/of test een onderdeel van is. En geef daarna een omschrijving.
Door de naamgeving goed te kiezen, kan je raden wat de inhoud is. En hierdoor weet je of, bij een aanpassing in de applicatie, je dit onderdeel moet aanpassen of niet. Als je daarnaast al een soort van groepering hebt, kan je ook eenvoudig raden of er een hele groep aangepast moet worden. Bijvoorbeeld als je het zoekscherm hebt aangepast, zal je zeker moeten kijken naar alles wat begint met "Zoeken".
Groeperen en becommentariëren
Bijna elk testautomatiseringsprogramma heeft de mogelijkheid om commentaar toe te voegen. Wanneer je dit consistent doet, kan je ook binnen een stukje automatiseringscode eenvoudig onderdelen herkennen. Ook dit maakt het weer eenvoudiger om te wijzigen stukken code te vinden. Zeker als je dit combineert met een goede groepering
Zelf groepeer ik zoveel mogelijk de volgende opdrachten bij elkaar: invoeropdrachten, schermwisselopdrachten en controleopdrachten. Alle opdrachten, die gegevens invoeren staan in een groep. Als dit teveel is, dan splits ik dit eventueel per component. Zo kan het invoeren van de zoekbox een groep zijn. Daarbinnen kan de datumcombobox weer veel handelingen vragen (selecteer jaar, selecteer maand, selecteer dag), waardoor dit een aparte groep kan worden.
Buttons die zorgen voor het openen van een dialoog of wisselen naar een ander scherm, zet ik in een aparte groep met schermwisselopdrachten. Deze groep bevat zowel het klikken op de button, het wachten op het nieuwe scherm als eventuele controle of het scherm geopend is.
Als laatste groepeer ik de controleopdrachten. Na invoer en/of schermwissel ga je de werkelijke test uitvoeren m.b.v. controles. Ook deze komen weer samen in een groep.
Deze groepen kan je vervolgens herkennen/groeperen door commentaar toe te voegen. Zelf doe ik dit bij voorkeur met een beschrijvend zelfstandig naamwoord gevolgd door "invoeren" of "controleren". Bijvoorbeeld "Zoekscherm invoeren" of "Kassabon controleren". Schermwissels hebben bij mij meestal het commentaar "Ga naar .....".
Door consistent te groeperen en commentaar toe te voegen, worden je testen goed leesbaar. Maar vooral leer je de onderdelen herkennen die terug komen. Als we weer uitgaan van een aanpassing in het zoekscherm, dan weet je dat elk onderdeel met het commentaar "Zoekscherm invoeren" hoogstwaarschijnlijk even gecontroleerd moet worden.
Search and replace
Een van de meest voorkomende aanpassingen is een element dat gewijzigd is. Eerst heette de button "btnSearch", maar nu heet het "btnSearch1". Er is namelijk een tweede toegevoegd.
Maak voor dit soort aanpassingen gebruik van Search and replace mogelijkheden. Dit kan binnen het automatiseringtool zijn, dat je gebruikt. Maar als je testtool geen mogelijkheid biedt, bijvoorbeeld omdat je Selenium IDE gebruikt, kan je ook een Search and Replace tool via internet downloaden en installeren. Belangrijkste is, dat je meerdere bestanden tegelijkertijd kan aanpassen.
Houdt er wel rekening mee dat je hierna al je testen moet controleren. Het is namelijk zeer goed mogelijk, dat je per ongeluk op een verkeerde plek iets hebt vervangen. Maar ondanks dit risico is deze manier van aanpassen vaak sneller dan alles handmatig opzoeken.
Herbruikbare functies
Als je kan programmeren en je programmeert zelf je testen, dan kan je je werk nog eenvoudiger maken. Door de groepering die je hopelijk hebt toegepast, komen automatisch groepen naar voren die vaak terugkomen. Hier kan je vervolgens functies van maken, die je vervolgens binnen je testen aan kan roepen. Ook hierbij is het verstandig de juiste naamgeving aan te houden.
Wanneer je veelgebruikte groepen in een functie weet te vatten, kan je deze binnen meerdere testen gebruiken. Bij een aanpassing is een aanpassing in deze functie vervolgens voldoende. Dat scheelt dan vervolgens weer een heleboel werk.
Naamgeving
Hoe eenvoudig ook, aanpassen gaat een stuk eenvoudiger als je aan de hand van de naamgeving kan raden wat de inhoud is. Geef je bestanden en/of procedures altijd een naam, die de test of de testsuite beschrijft. Zo geef ik vaak de testsuite in Selenium een beschrijving van het scherm dat ik wil testen. En vervolgens de testen een korte beschrijving van de test. Bij voorkeur laat ik de naam van de testsuite terugkomen in de testcase. Zo zal ik een testsuite "Zoeken" noemen, omdat ik hier het scherm wil testen waar de zoekgegevens ingevoerd worden. En vervolgens noem ik de testcase "ZoekenPostcode", omdat in deze test ik wil nagaan of het zoeken op postcode goed werkt.
Houdt je naamgeving ook zo consistent mogelijk, zodat er automatisch een groepering ontstaat. Als je de testen "ZoekenPostcode", "NaamZoeken" en "SearchPlace" noemt, maak je het jezelf moeilijk. Begin de naam, als dit kan, met de groep waar het bestand en/of test een onderdeel van is. En geef daarna een omschrijving.
Door de naamgeving goed te kiezen, kan je raden wat de inhoud is. En hierdoor weet je of, bij een aanpassing in de applicatie, je dit onderdeel moet aanpassen of niet. Als je daarnaast al een soort van groepering hebt, kan je ook eenvoudig raden of er een hele groep aangepast moet worden. Bijvoorbeeld als je het zoekscherm hebt aangepast, zal je zeker moeten kijken naar alles wat begint met "Zoeken".
Groeperen en becommentariëren
Bijna elk testautomatiseringsprogramma heeft de mogelijkheid om commentaar toe te voegen. Wanneer je dit consistent doet, kan je ook binnen een stukje automatiseringscode eenvoudig onderdelen herkennen. Ook dit maakt het weer eenvoudiger om te wijzigen stukken code te vinden. Zeker als je dit combineert met een goede groepering
Zelf groepeer ik zoveel mogelijk de volgende opdrachten bij elkaar: invoeropdrachten, schermwisselopdrachten en controleopdrachten. Alle opdrachten, die gegevens invoeren staan in een groep. Als dit teveel is, dan splits ik dit eventueel per component. Zo kan het invoeren van de zoekbox een groep zijn. Daarbinnen kan de datumcombobox weer veel handelingen vragen (selecteer jaar, selecteer maand, selecteer dag), waardoor dit een aparte groep kan worden.
Buttons die zorgen voor het openen van een dialoog of wisselen naar een ander scherm, zet ik in een aparte groep met schermwisselopdrachten. Deze groep bevat zowel het klikken op de button, het wachten op het nieuwe scherm als eventuele controle of het scherm geopend is.
Als laatste groepeer ik de controleopdrachten. Na invoer en/of schermwissel ga je de werkelijke test uitvoeren m.b.v. controles. Ook deze komen weer samen in een groep.
Deze groepen kan je vervolgens herkennen/groeperen door commentaar toe te voegen. Zelf doe ik dit bij voorkeur met een beschrijvend zelfstandig naamwoord gevolgd door "invoeren" of "controleren". Bijvoorbeeld "Zoekscherm invoeren" of "Kassabon controleren". Schermwissels hebben bij mij meestal het commentaar "Ga naar .....".
Door consistent te groeperen en commentaar toe te voegen, worden je testen goed leesbaar. Maar vooral leer je de onderdelen herkennen die terug komen. Als we weer uitgaan van een aanpassing in het zoekscherm, dan weet je dat elk onderdeel met het commentaar "Zoekscherm invoeren" hoogstwaarschijnlijk even gecontroleerd moet worden.
Search and replace
Een van de meest voorkomende aanpassingen is een element dat gewijzigd is. Eerst heette de button "btnSearch", maar nu heet het "btnSearch1". Er is namelijk een tweede toegevoegd.
Maak voor dit soort aanpassingen gebruik van Search and replace mogelijkheden. Dit kan binnen het automatiseringtool zijn, dat je gebruikt. Maar als je testtool geen mogelijkheid biedt, bijvoorbeeld omdat je Selenium IDE gebruikt, kan je ook een Search and Replace tool via internet downloaden en installeren. Belangrijkste is, dat je meerdere bestanden tegelijkertijd kan aanpassen.
Houdt er wel rekening mee dat je hierna al je testen moet controleren. Het is namelijk zeer goed mogelijk, dat je per ongeluk op een verkeerde plek iets hebt vervangen. Maar ondanks dit risico is deze manier van aanpassen vaak sneller dan alles handmatig opzoeken.
Herbruikbare functies
Als je kan programmeren en je programmeert zelf je testen, dan kan je je werk nog eenvoudiger maken. Door de groepering die je hopelijk hebt toegepast, komen automatisch groepen naar voren die vaak terugkomen. Hier kan je vervolgens functies van maken, die je vervolgens binnen je testen aan kan roepen. Ook hierbij is het verstandig de juiste naamgeving aan te houden.
Wanneer je veelgebruikte groepen in een functie weet te vatten, kan je deze binnen meerdere testen gebruiken. Bij een aanpassing is een aanpassing in deze functie vervolgens voldoende. Dat scheelt dan vervolgens weer een heleboel werk.
maandag 9 mei 2016
De valkuilen van open en eerlijk communiceren
Ieder Agile teamlid, en zeker ook een tester, heeft wel eens een onderwerp dat besproken moet worden. Met een of met meerdere personen. En misschien heb jij het dan ook wel eens gehoord: "Je moet open en eerlijk met elkaar praten." Ik ben geen blinde voorstander van open en eerlijk communiceren. Ik heb op deze wijze heel veel zaken goed opgelost zien worden. Maar ik heb ook gezien hoe deze manier van communiceren de problemen alleen maar groter maakten.
"Open en eerlijk zijn" is, net als andere communicatiekeuzes, een mogelijkheid om een probleem op te lossen. En net als elke mogelijkheid is het soms wel en soms niet de juiste keuze. Het voordeel is, als het lukt, dat mensen elkaar meer begrijpen en dat oplossingen meer gedragen worden. Maar als het niet lukt, zijn de nadelen veel groter. En meestal, is mijn ervaring, komt dit doordat "open en eerlijk communiceren" op zo'n wijze gebruikt wordt, dat mensen, bewust of onbewust, de mond gesnoerd wordt of er binnen het gesprek tegenstanders ontstaan.
Onvoldoende vertrouwen
Om een goed open en eerlijk gesprek te hebben, moet er tussen alle gesprekspartners vertrouwen aanwezig zijn. Men moet het vertrouwen hebben dat niemand van de aanwezigen tot doel heeft de ander als zondebok aan te wijzen of bij de ander zijn of haar geschiktheid voor zijn of haar werk in twijfel te trekken. Aan de andere kant moet men het vertrouwen hebben dat wat gezegd wordt, later niet gebruikt wordt om een persoon negatief beoordelen. Dit laatste heeft misschien iets meer toelichting nodig. Stel dat je tijdens het gesprek wil inbrengen dat de communicatie tussen scrummaster en teamleden niet goed verloopt. Als je dit aan wilt kaarten, moet je het vertrouwen hebben, dat de scrummaster niet na het gesprek boos naar je toe komt. Of dat je teamleden je links laten liggen, omdat je de kant van de scrummaster hebt gekozen.
Als je vertrouwenskwesties binnen de groep negeert en toch onderwerpen ter sprake brengt, zal er zeker geen open sfeer heersen. Er zal snel sprake zijn van emotie, omdat mensen zich aangevallen voelen. Dit maakt dan misschien weer, dat mensen zeer voorzichtig gaan communiceren, om de ander niet op de tenen te trappen Of mensen houden hun mening helemaal voor zich. Dit om een negatieve reactie van een ander te voorkomen of om niet zelf in de problemen te komen na het gesprek.
Wat veel mensen vergeten, is dat vertrouwen niet af te dwingen is. "We gaan nu open en eerlijk communiceren. Het is niet het doel iemand te beoordelen of te veroordelen," Soortgelijke uitspraken gaan vaak vooraf aan open en eerlijke gesprekken. Hoe goed bedoelt, zo'n zin kan het vertrouwen niet spontaan herstellen. Voordat je een open en eerlijk gesprek kan voeren, zal je eerst het onderlinge vertrouwen tussen de mensen moeten herstellen. En deze zaken een-op-een laten uitpraten. Zonder vertrouwen krijg je echt geen open en eerlijk gesprek.
Onderwerpen die uitsluiten
"We gaan deze keer open en eerlijk bespreken waarom de kwaliteit van het product de laatste tijd zoveel slechter is geworden" Misschien lijkt hier in eerste instantie niet zoveel mis mee. Maar stel dat er iemand in de groep is, die niet vindt dat de kwaliteit slechter is geworden? Hoe denk je dat die persoon aan het gesprek zal deelnemen?
Als je "geluk" hebt, zal deze persoon zwijgen. Maar het is de vraag of je daar blij mee moet zijn. Een open en eerlijk gesprek, waar niet iedereen een actieven bijdrage aan geeft, zorgt nu niet echt tot een oplossing waar de hele groep achter staat.
Stel dat deze persoon toch zijn of haar mening geeft, dan heb je pas echt een probleem. Je open en eerlijke gesprek heeft dan vaak meteen twee kampen. Aan de ene kant de groep die dwarsligt en/of de waarheid niet onder ogen wil zien en/of..., vul je eigen antwoord maar in. Aan de andere kant de groep die niet wil luisteren en/of sterk bevooroordeeld is en/of.......
In een open en eerlijk gesprek kan je meestal geen onderwerpen bespreken die als feiten geformuleerde uitspraken bevatten. Of je moet er wel heel, maar dan ook heel, erg zeker van zijn dat iedereen in het gesprek het met deze feiten eens is. Slimmer is om een onderwerp op een hoger niveau te bespreken. "We gaan het hebben over de kwaliteit van het product" geeft mensen veel meer vrijheid. Iedereen kan nu alles zeggen over de kwaliteit, of ze deze nu beter of slechter vinden.
Watervallen aan informatie
"Dit gaat fout. En dit. En dat, En daar gaat dat fout." Er zijn weinig mensen die het leuk vinden om zulke opsommingen te horen. Maar de andere kant "Dit gaan we doen. En dan dat. En vervolgens dat. En natuurlijk dan dat." wordt zeker ook niet gewaardeerd. Mensen voelen zich vaak overvallen door de grote stortvloed aan informatie. Ze kunnen emotioneel worden, doordat ze zich plotseling beschuldigd voelen van een heel rijtje fouten. Ze kunnen de openheid van het gesprek in twijfel gaan trekken, omdat diegene die spreekt alles al uitgedacht lijkt te hebben. Of ze kunnen je gewoon niet bijbenen. Hoe dan ook, opsommingen van problemen of acties is misschien wel open en eerlijk, maar komen het gesprek niet ten goede.
Slimmer is het om deze opsommingen op te splitsen. Wat is naar de mening van de spreker de ergste fout die gemaakt is? Wat is naar de mening van de spreker de eerste stap die gezet moet worden? Laten we die dan eerst open en eerlijk bespreken, voor we de opsomming verder behandelen. En zorg er ook voor dat iedereen zijn of haar ergste fout of eerste stap heeft kunnen noemen, voordat de opsomming van een persoon volledig behandeld is. Dit geeft binnen de groep het gevoel dat iedereen inbreng mag geven, in plaats van slechts een persoon.
Oneerlijke groepsverdeling
Een oneerlijke groepsverdeling kan een open en eerlijk gesprek zwaar blokkeren. Stel dat twee of meer personen in de groep vinden, dat er anders getest moet worden. En stel dat er maar een persoon in de groep dit niet vindt. De andere personen vinden dan steun bij elkaar, zien elkaars mening bevestigd in de ander. De enkeling kan dan al snel gezien worden als dwarsligger of iemand die de waarheid niet onder ogen wil zien. De enkeling zelf zal zich zeker niet snel serieus genomen voelen of het gevoel hebben onder druk te worden gezet.
Dit gebeurt zeker niet altijd, maar oneerlijke groepsverdelingen zijn en blijven een risico, Als je een onderwerp wil bespreken en je weet ongeveer de meningen, probeer dan de situatie te voorkomen. Zorg ervoor dat elk "kamp" minimaal twee personen bevat. En als dit niet lukt, zorg dan voor een onafhankelijke scheidsrechter. Een persoon die over de situatie geen mening heeft en ook niet hoeft te hebben. Die vooral erop kan letten dat alle "kampen" aan het woord komen en dat naar iedereen geluisterd wordt.
Dan maar nooit meer open en eerlijk zijn?
Als open en eerlijk communiceren zoveel valkuilen heeft, moet je het dan niet gewoon laten? Wat mij betreft zeker niet. Je moet niet van iedereen verwachten dat ze altijd open en eerlijk zijn. Een open en eerlijk gesprek moet je voorbereiden. Een open en eerlijk gesprek moet een goede gespreksleider hebben. Je moet vooral een sfeer neerzetten, waarin mensen open en eerlijk kunnen zijn. Dit kan dan wel degelijk zaken bespreekbaar, die anders alleen in de achterkamertjes besproken worden. Want bepaalde zaken wil je alleen bespreken in een veilige omgeving. Open en eerlijk communiceren kan deze veilige omgeving zijn, mits je niet denkt dat deze vorm van communicatie in een vingerknip ontstaat.
"Open en eerlijk zijn" is, net als andere communicatiekeuzes, een mogelijkheid om een probleem op te lossen. En net als elke mogelijkheid is het soms wel en soms niet de juiste keuze. Het voordeel is, als het lukt, dat mensen elkaar meer begrijpen en dat oplossingen meer gedragen worden. Maar als het niet lukt, zijn de nadelen veel groter. En meestal, is mijn ervaring, komt dit doordat "open en eerlijk communiceren" op zo'n wijze gebruikt wordt, dat mensen, bewust of onbewust, de mond gesnoerd wordt of er binnen het gesprek tegenstanders ontstaan.
Onvoldoende vertrouwen
Om een goed open en eerlijk gesprek te hebben, moet er tussen alle gesprekspartners vertrouwen aanwezig zijn. Men moet het vertrouwen hebben dat niemand van de aanwezigen tot doel heeft de ander als zondebok aan te wijzen of bij de ander zijn of haar geschiktheid voor zijn of haar werk in twijfel te trekken. Aan de andere kant moet men het vertrouwen hebben dat wat gezegd wordt, later niet gebruikt wordt om een persoon negatief beoordelen. Dit laatste heeft misschien iets meer toelichting nodig. Stel dat je tijdens het gesprek wil inbrengen dat de communicatie tussen scrummaster en teamleden niet goed verloopt. Als je dit aan wilt kaarten, moet je het vertrouwen hebben, dat de scrummaster niet na het gesprek boos naar je toe komt. Of dat je teamleden je links laten liggen, omdat je de kant van de scrummaster hebt gekozen.
Als je vertrouwenskwesties binnen de groep negeert en toch onderwerpen ter sprake brengt, zal er zeker geen open sfeer heersen. Er zal snel sprake zijn van emotie, omdat mensen zich aangevallen voelen. Dit maakt dan misschien weer, dat mensen zeer voorzichtig gaan communiceren, om de ander niet op de tenen te trappen Of mensen houden hun mening helemaal voor zich. Dit om een negatieve reactie van een ander te voorkomen of om niet zelf in de problemen te komen na het gesprek.
Wat veel mensen vergeten, is dat vertrouwen niet af te dwingen is. "We gaan nu open en eerlijk communiceren. Het is niet het doel iemand te beoordelen of te veroordelen," Soortgelijke uitspraken gaan vaak vooraf aan open en eerlijke gesprekken. Hoe goed bedoelt, zo'n zin kan het vertrouwen niet spontaan herstellen. Voordat je een open en eerlijk gesprek kan voeren, zal je eerst het onderlinge vertrouwen tussen de mensen moeten herstellen. En deze zaken een-op-een laten uitpraten. Zonder vertrouwen krijg je echt geen open en eerlijk gesprek.
Onderwerpen die uitsluiten
"We gaan deze keer open en eerlijk bespreken waarom de kwaliteit van het product de laatste tijd zoveel slechter is geworden" Misschien lijkt hier in eerste instantie niet zoveel mis mee. Maar stel dat er iemand in de groep is, die niet vindt dat de kwaliteit slechter is geworden? Hoe denk je dat die persoon aan het gesprek zal deelnemen?
Als je "geluk" hebt, zal deze persoon zwijgen. Maar het is de vraag of je daar blij mee moet zijn. Een open en eerlijk gesprek, waar niet iedereen een actieven bijdrage aan geeft, zorgt nu niet echt tot een oplossing waar de hele groep achter staat.
Stel dat deze persoon toch zijn of haar mening geeft, dan heb je pas echt een probleem. Je open en eerlijke gesprek heeft dan vaak meteen twee kampen. Aan de ene kant de groep die dwarsligt en/of de waarheid niet onder ogen wil zien en/of..., vul je eigen antwoord maar in. Aan de andere kant de groep die niet wil luisteren en/of sterk bevooroordeeld is en/of.......
In een open en eerlijk gesprek kan je meestal geen onderwerpen bespreken die als feiten geformuleerde uitspraken bevatten. Of je moet er wel heel, maar dan ook heel, erg zeker van zijn dat iedereen in het gesprek het met deze feiten eens is. Slimmer is om een onderwerp op een hoger niveau te bespreken. "We gaan het hebben over de kwaliteit van het product" geeft mensen veel meer vrijheid. Iedereen kan nu alles zeggen over de kwaliteit, of ze deze nu beter of slechter vinden.
Watervallen aan informatie
"Dit gaat fout. En dit. En dat, En daar gaat dat fout." Er zijn weinig mensen die het leuk vinden om zulke opsommingen te horen. Maar de andere kant "Dit gaan we doen. En dan dat. En vervolgens dat. En natuurlijk dan dat." wordt zeker ook niet gewaardeerd. Mensen voelen zich vaak overvallen door de grote stortvloed aan informatie. Ze kunnen emotioneel worden, doordat ze zich plotseling beschuldigd voelen van een heel rijtje fouten. Ze kunnen de openheid van het gesprek in twijfel gaan trekken, omdat diegene die spreekt alles al uitgedacht lijkt te hebben. Of ze kunnen je gewoon niet bijbenen. Hoe dan ook, opsommingen van problemen of acties is misschien wel open en eerlijk, maar komen het gesprek niet ten goede.
Slimmer is het om deze opsommingen op te splitsen. Wat is naar de mening van de spreker de ergste fout die gemaakt is? Wat is naar de mening van de spreker de eerste stap die gezet moet worden? Laten we die dan eerst open en eerlijk bespreken, voor we de opsomming verder behandelen. En zorg er ook voor dat iedereen zijn of haar ergste fout of eerste stap heeft kunnen noemen, voordat de opsomming van een persoon volledig behandeld is. Dit geeft binnen de groep het gevoel dat iedereen inbreng mag geven, in plaats van slechts een persoon.
Oneerlijke groepsverdeling
Een oneerlijke groepsverdeling kan een open en eerlijk gesprek zwaar blokkeren. Stel dat twee of meer personen in de groep vinden, dat er anders getest moet worden. En stel dat er maar een persoon in de groep dit niet vindt. De andere personen vinden dan steun bij elkaar, zien elkaars mening bevestigd in de ander. De enkeling kan dan al snel gezien worden als dwarsligger of iemand die de waarheid niet onder ogen wil zien. De enkeling zelf zal zich zeker niet snel serieus genomen voelen of het gevoel hebben onder druk te worden gezet.
Dit gebeurt zeker niet altijd, maar oneerlijke groepsverdelingen zijn en blijven een risico, Als je een onderwerp wil bespreken en je weet ongeveer de meningen, probeer dan de situatie te voorkomen. Zorg ervoor dat elk "kamp" minimaal twee personen bevat. En als dit niet lukt, zorg dan voor een onafhankelijke scheidsrechter. Een persoon die over de situatie geen mening heeft en ook niet hoeft te hebben. Die vooral erop kan letten dat alle "kampen" aan het woord komen en dat naar iedereen geluisterd wordt.
Dan maar nooit meer open en eerlijk zijn?
Als open en eerlijk communiceren zoveel valkuilen heeft, moet je het dan niet gewoon laten? Wat mij betreft zeker niet. Je moet niet van iedereen verwachten dat ze altijd open en eerlijk zijn. Een open en eerlijk gesprek moet je voorbereiden. Een open en eerlijk gesprek moet een goede gespreksleider hebben. Je moet vooral een sfeer neerzetten, waarin mensen open en eerlijk kunnen zijn. Dit kan dan wel degelijk zaken bespreekbaar, die anders alleen in de achterkamertjes besproken worden. Want bepaalde zaken wil je alleen bespreken in een veilige omgeving. Open en eerlijk communiceren kan deze veilige omgeving zijn, mits je niet denkt dat deze vorm van communicatie in een vingerknip ontstaat.
dinsdag 3 mei 2016
Testtechnieken en Agile testen
Testtechnieken en Agile testen lijken vaak tegenstrijdig. Testtechnieken lijken te horen bij de tijd van de waterval, waarbij je veel tijd besteedde aan testvoorbereiding. En niet bij een tijd van Agile testen, waarbij je snel en flexibel moet testen. Toch ervaar ik ze als een krachtig, sterk middel, juist binnen Agile testen.
Het toepassen van een testtechniek kost tijd, dat zal ik niet ontkennen. Maar het heeft zeker een meerwaarde. Testtechnieken geven een houvast bij een test. Ze zijn meestal een vrij snelle methode van testvoorbereiding. En, eenmaal opgesteld, kunnen ze ook nog eens een basis zijn tot waardevolle functionele documentatie.
Testtechnieken tijdens testen
Als je je testtechnieken, zoals Datacombinatietest en Elementaire Vergelijkings Test, goed beheerst, ben je in staat deze elk moment in te zetten. Vaak is het verstandig ze te gebruiken, als er een onderdeel te testen valt waarbij de dekkingsgraad van belang is. Je wil zeker weten dat je voor dit onderdeel voldoende varianten hebt getest. Denk hierbij bijvoorbeeld aan ketentesten, waarbij je zeker wil weten dat je alle mogelijke processtappen een keer getest hebt. Of aan ingewikkelde business rules, die te belangrijk zijn om op de gok te testen.
Wanneer je zo'n onderdeel in de story, of soortgelijke beschrijving, ontdekt, is de manier van werken eigenlijk niet zoveel anders. Je kiest de testtechniek uit, die naar jouw mening het beste bij het onderdeel past. Je past hem toe. En daarna voer je de testcases uit. Het belangrijkste verschil zit hem in het moment van toepassen. Bij waterval paste je deze testtechnieken al vaak ruim van tevoren toe. Nu pas je hem vrij vlak voor het testen toe. Van belang is om de testtechniek pas toe te passen, als de informatie, die je wilt testen correct is. Of er minimale wijzigingen verwacht worden.
Het moment wordt dus niet bepaalt door de gehele status van het proces, zoals bij waterval. In plaats daarvan wordt het moment alleen bepaalt door het moment waarop de informatie, nodig voor de testtechniek, gereed is. Hierna hangt het van verdere afspraken binnen je team af, wanneer je de testvoorbereiding uitvoert. Dit kan aan het begin van de sprint, als je uit ervaring weet dat je aan het eind van de sprint vaak veel werk hebt. Maar dit kan ook gewoon als de taak op het scrumboard de bovenste taak is. Het kan zelfs een onderdeel zijn van een algehele taak "testuitvoering". Wat de beste optie is, is echt organisatie afhankelijk.
Testtechnieken als communicatiemiddel
Testtechnieken hebben vaak als voordeel dat ze door andere teamleden, zoals ontwikkelaars, makkelijk te begrijpen zijn. Zelfs zonder uitleg kan een ontwikkelaar de testtechniek vaak voldoende begrijpen, om de informatie eruit te halen. Zeker bij technieken als de procescyculstest, die veel lijkt op ontwerptechnieken waarmee ontwikkelaars veel te maken hebben. Als je een testtechniek toepast, kan deze daarom ook meteen gebruikt worden om wat ingewikkeldere informatie zo weer te geven, dat iedereen binnen het ontwikkelteam de informatie op dezelfde manier begrijpt. Hierbij moet je vooral denken aan technieken die een schematische weergave geven van de werkelijkheid, niet aan technieken die vooral tot een opsomming van testcases leiden.
Als er een moeilijker onderdeel staat in de story, kan je daarom als tester je team helpen met je testtechnieken. Je kan al in een vroeg stadium, misschien zelfs al bij bijvoorbeeld de backlog refinement, je kennis inzetten om je team te helpen tot een duidelijk en begrijpelijk te bouwen story te komen. Hierdoor gebruik je je vaardigheden als tester ruimer en tevens heb je alvast een start gemaakt met de testvoorbereiding. Wat later weer tijd scheelt.
Testtechnieken als documentatie
Als je je testtechnieken goed toepast, zijn het vaak kleine, compacte, duidelijke schema's, waarin veel belangrijke informatie terugkomt. Door de compactheid is het vaak makkelijk om er aanpassingen in door te voeren, mochten er wijzigingen komen. Zoals al eerder geschreven, zijn ze vaak ook begrijpelijk voor andere teamleden en anders eenvoudig uit te leggen. Door deze combinatie zijn testtechnieken vaak een mooie start voor documentatie.
Documentatie is ook bij Agile projecten vaak een ondergeschoven kindje. Maar ook bij deze projecten ontstaat vaak een kennisgebrek. Omdat je de testtechnieken vaak op wat uitgebreidere of ingewikkeldere delen gaat toepassen, zijn dit regelmatig ook de onderdelen waarvan de kennis niet volledig in de hoofden van het team zit. Dit maakt alleen al het vastleggen van deze technieken in algemene documentatie tot een goede basis voor de documentatie.
Gebruik dus je testtechnieken
Agile testen en testtechnieken gaan goed samen. Blijf dus je testtechnieken leren, breidt je kennis uit en pas ze toe. Ook, nee juist, binnen een Agile project. Maak gebruik van de begrijpelijkheid om zowel voorafgaand als tijdens als na de bouw van een onderdeel de communicatie en kennis binnen het team te verbeteren. Ze zijn niet voor niets uitgevonden, daar verandert Agile niets aan.
Het toepassen van een testtechniek kost tijd, dat zal ik niet ontkennen. Maar het heeft zeker een meerwaarde. Testtechnieken geven een houvast bij een test. Ze zijn meestal een vrij snelle methode van testvoorbereiding. En, eenmaal opgesteld, kunnen ze ook nog eens een basis zijn tot waardevolle functionele documentatie.
Testtechnieken tijdens testen
Als je je testtechnieken, zoals Datacombinatietest en Elementaire Vergelijkings Test, goed beheerst, ben je in staat deze elk moment in te zetten. Vaak is het verstandig ze te gebruiken, als er een onderdeel te testen valt waarbij de dekkingsgraad van belang is. Je wil zeker weten dat je voor dit onderdeel voldoende varianten hebt getest. Denk hierbij bijvoorbeeld aan ketentesten, waarbij je zeker wil weten dat je alle mogelijke processtappen een keer getest hebt. Of aan ingewikkelde business rules, die te belangrijk zijn om op de gok te testen.
Wanneer je zo'n onderdeel in de story, of soortgelijke beschrijving, ontdekt, is de manier van werken eigenlijk niet zoveel anders. Je kiest de testtechniek uit, die naar jouw mening het beste bij het onderdeel past. Je past hem toe. En daarna voer je de testcases uit. Het belangrijkste verschil zit hem in het moment van toepassen. Bij waterval paste je deze testtechnieken al vaak ruim van tevoren toe. Nu pas je hem vrij vlak voor het testen toe. Van belang is om de testtechniek pas toe te passen, als de informatie, die je wilt testen correct is. Of er minimale wijzigingen verwacht worden.
Het moment wordt dus niet bepaalt door de gehele status van het proces, zoals bij waterval. In plaats daarvan wordt het moment alleen bepaalt door het moment waarop de informatie, nodig voor de testtechniek, gereed is. Hierna hangt het van verdere afspraken binnen je team af, wanneer je de testvoorbereiding uitvoert. Dit kan aan het begin van de sprint, als je uit ervaring weet dat je aan het eind van de sprint vaak veel werk hebt. Maar dit kan ook gewoon als de taak op het scrumboard de bovenste taak is. Het kan zelfs een onderdeel zijn van een algehele taak "testuitvoering". Wat de beste optie is, is echt organisatie afhankelijk.
Testtechnieken als communicatiemiddel
Testtechnieken hebben vaak als voordeel dat ze door andere teamleden, zoals ontwikkelaars, makkelijk te begrijpen zijn. Zelfs zonder uitleg kan een ontwikkelaar de testtechniek vaak voldoende begrijpen, om de informatie eruit te halen. Zeker bij technieken als de procescyculstest, die veel lijkt op ontwerptechnieken waarmee ontwikkelaars veel te maken hebben. Als je een testtechniek toepast, kan deze daarom ook meteen gebruikt worden om wat ingewikkeldere informatie zo weer te geven, dat iedereen binnen het ontwikkelteam de informatie op dezelfde manier begrijpt. Hierbij moet je vooral denken aan technieken die een schematische weergave geven van de werkelijkheid, niet aan technieken die vooral tot een opsomming van testcases leiden.
Als er een moeilijker onderdeel staat in de story, kan je daarom als tester je team helpen met je testtechnieken. Je kan al in een vroeg stadium, misschien zelfs al bij bijvoorbeeld de backlog refinement, je kennis inzetten om je team te helpen tot een duidelijk en begrijpelijk te bouwen story te komen. Hierdoor gebruik je je vaardigheden als tester ruimer en tevens heb je alvast een start gemaakt met de testvoorbereiding. Wat later weer tijd scheelt.
Testtechnieken als documentatie
Als je je testtechnieken goed toepast, zijn het vaak kleine, compacte, duidelijke schema's, waarin veel belangrijke informatie terugkomt. Door de compactheid is het vaak makkelijk om er aanpassingen in door te voeren, mochten er wijzigingen komen. Zoals al eerder geschreven, zijn ze vaak ook begrijpelijk voor andere teamleden en anders eenvoudig uit te leggen. Door deze combinatie zijn testtechnieken vaak een mooie start voor documentatie.
Documentatie is ook bij Agile projecten vaak een ondergeschoven kindje. Maar ook bij deze projecten ontstaat vaak een kennisgebrek. Omdat je de testtechnieken vaak op wat uitgebreidere of ingewikkeldere delen gaat toepassen, zijn dit regelmatig ook de onderdelen waarvan de kennis niet volledig in de hoofden van het team zit. Dit maakt alleen al het vastleggen van deze technieken in algemene documentatie tot een goede basis voor de documentatie.
Gebruik dus je testtechnieken
Agile testen en testtechnieken gaan goed samen. Blijf dus je testtechnieken leren, breidt je kennis uit en pas ze toe. Ook, nee juist, binnen een Agile project. Maak gebruik van de begrijpelijkheid om zowel voorafgaand als tijdens als na de bouw van een onderdeel de communicatie en kennis binnen het team te verbeteren. Ze zijn niet voor niets uitgevonden, daar verandert Agile niets aan.
Abonneren op:
Posts (Atom)