Menu

Aantal leden:
650
Aantal jaren testervaring:
8390
Aantal leden:
650
Aantal jaren testervaring:
8390
Word nu lid

TESTER AAN HET WOORD

Tester aan het Woord is het podium waarop bevlogen testers hun ervaring en kennis kunnen delen met de community.


Advies voor vakgenoten
Iedere twee weken laten we een andere tester aan het woord. De onderwerpen? Persoonlijk leiderschap en sociale innovatie. Uiteraard in combinatie met advies en tips voor vakgenoten.

We geven je graag het woord 
Je bent van harte uitgenodigd om ook jouw kennis en ervaring te delen in Tester aan het Woord.

Spelregels 
Schrijf een blog van maximaal 500 woorden over persoonlijk leiderschap en sociale innovatie in het testvak. Stuur je blog naar info@testcommunity.nu 

Let op. Je blog mag geen commerciële oproepen bevatten.

TIP: Vragen verbindt

Een groot deel van mijn dag bestaat uit het stellen van vragen aan collega’s uit verschillende disciplines. Het goed stellen van vragen is echter heel iets anders dan een poging om aan specifieke informatie te komen. Hoewel dit ook nodig is beschouw ik het stellen van vragen als iets meer. Lees meer



 

TIP: Denk aan vandaag, niet aan morgen

Beperk je tot het testen van zaken die nú af zijn, laat je niet afleiden door functionaliteit die nog niet bestaat. Testers die gewend zijn om in een watervalproject te werken en nu testen in een Agile (scrum) project, zullen moeten leren om hun ‘testenergie’ te beperken tot waar het zinvol is. Lees meer



 

TIP: Feedback van je leveranciers

Organiseer twee keer per jaar een sessie met IT-leveranciers. Daar geef je elkaar feedback op het testproces. Dat verbetert niet alleen dit proces, het zorgt ook voor een betere  samenwerking tussen klantorganisatie en IT-leveranciers én tussen de IT-leveranciers onderling. Hou je wel aan de spelregels van zo’n sessie. Lees meer



 

TIP: Toon het belang van goede testbasis

Requirements worden vaak slecht omschreven en overgenomen uit diverse documenten. Vaak zijn ze door verschillende mensen geschreven. Het is verwarrend als daardoor één wens in meerdere requirements voorkomt. Ook het functioneel ontwerp kan vaak beter: het toevoegen van een paar screenprints maakt heel veel duidelijk. Krijg je als tester de kans om, samen met de business/opdrachtgever, goede templates voor de testbasisdocumenten op te stellen, dan bespaart dat tijd en ergernis en het voorkomt miscommunicatie. Bovendien kan je zo nóg eerder defects opsporen. Lees meer


 

TIP: Korte lijn met softwareontwikkelaar

Jouw toegevoegde waarde als tester wordt beter zichtbaar als je informatie oplevert waar je stakeholders echt op zitten te wachten. Ga daarom verder dan de standaard risicoanalyse en vraag je stakeholders wat het voor hen betekent als de software goed getest is. Vraag ze naar hun worst nightmare. En stel de the-bugsyou-don’t-want-to-find-in-production vraag. Door te vragen naar hun beleving, breng je verhalen naar boven over eerdere projecten, over productieverstoringen en de impact als er straks iets misgaat. Je weet dan waarover zij zich werkelijk druk maken. Lees meer


 

TIP: Korte lijn met softwareontwikkelaar

Heb je je wel eens boos gemaakt over een softwareoplevering die te laat kwam? Die bovendien slecht testbaar was en vol fouten zat? En natuurlijk vond de softwareontwikkelaar jou de zeurpiet ... Hij had nog gelijk ook. Blijkbaar had je geen realistische verwachtingen en had je verzuimd met de softwareontwikkelaar af te stemmen wat wel en niet getest kon worden. Hoogste tijd dus om de muur tussen ontwikkelaar en tester te slechten. Samen zijn jullie een sterk team. Lees meer


 

TIP: Persoonlijke groei, valkuilen

Vandaag had ik een interessant gesprek met een collega die twijfelde of dit wel de juiste opdracht voor hem was, omdat niet alles even soepel ging. Het was een mooi gesprek en we hadden het over valkuilen en persoonlijke groei. Als je bewust bezig bent met groei, dan zal je vermoedelijk ook je collega’s wel eens om feedback vragen. En dan probeer je hopelijk iets verder te gaan dan het vissen naar complimentjes. Wat hebben ze te melden? Krijg je bijvoorbeeld wel eens te horen ‘pick your battles!’? Lees meer


 

TIP: Eerst ‘wat’, dan ‘hoe’

Op basis van acceptatiecriteria bepaal je wát er getest moet worden. Deze criteria kan je koppelen aan kwaliteitsattributen. En dat bepaalt in grote lijnen wat voor type tests er uitgevoerd moeten worden. Op dat moment kun je nadenken over hóe je wilt testen. Testautomatisering is een optie, die je moet overwegen. Inderdaad ‘moet’, want handmatig testen kan inefficiënt of zelfs onmogelijk zijn. Lees meer


 

TIP: Internationaal testmanagement: creëer testidentiteit

Als testdirector kreeg ik de opdracht om een internationaal testteam, verdeeld over twee continenten en tien landen tot een geheel te smeden. Het ging om een testprogramma waarbij tien NAVO landen vijf jaar lang hebben samengewerkt aan een tactical command and control information system. Ik laat je zien welke aspecten hebben bijgedragen aan het succes van het team. Lees meer


 

TIP: Testautomatisering: quick & dirty

Test-automatisering is een investering, bij veel projecten zelfs een grote investering. Vaak duurt het te lang voor je resultaat ziet. Of de stekker gaat eruit nog voor de eerste testcases uitgevoerd kunnen worden. Start het testautomatiseringsproject zodanig dat snel – binnen enkele weken! – inzichtelijk wordt of de gekozen weg succesvol zal zijn. En om snel de toegevoegde waarde te laten zien: begin klein! Ik geef je daar drie voorbeelden van. Uit  mijn eigen praktijk, bij opdrachtgevers in de high-tech industrie. Ze werken vanzelfsprekend ook in andere sectoren. Lees meer


 

TIP: Mensen zijn belangrijker dan tools

Individuals and interactions over procedures and tools’. Zo luidt het eerste statement in het Agile Manifesto. Kortom, mensen zijn belangrijker dan tools. In de transitie van Waterval naar Scrum wordt de menselijke factor vaak vergeten, en dat is de reden dat zo veel projecten sneuvelen. Ga daarom vooraf na of je wel het goede team hebt: qua skills, qua klik. Meten is weten. Lees meer




 


TIP: Betrek collega’s, maak ze pro-actief

Het is heel waardevol om vanaf de start helder en breed te communiceren met de teamleden en acceptanten, afhankelijk van de rol en opdracht. Bij de start van het project kun je dit inhoud geven door kennismakingsgesprekken te voeren. Zo krijg je helder wat iemands verantwoordelijkheden zijn. Ook kun je afspraken maken over wederzijdse verwachtingen. Lees meer




 

TIP: Ketentesten? Hoebedoellu?

In testtrajecten, zeker bij externe leveranciers, wordt ketentesten snel een ondergeschoven kindje. Met ketentesten bedoelen we de connectiviteitstest (de aansluiting van een interface), de interfacetest (komen de gegevens correct over?), de systeemintegratietest (meerdere systemen voeren samen functies uit) of de End-to-End-test (ondersteunen alle systemen samen de processen goed?). Lees meer




 

TIP: Risk poker: tijdwinst en weloverwogen keuzes

Om de testaanpak te bepalen van een userstory, kunnen we gebruikmaken van testtechnieken. Die helpen ons in het behalen van een bepaalde testdekking, die we nodig hebben om te voldoen aan de acceptatiecriteria. Maar niet elke userstory heeft dezelfde coverage nodig. Een gedifferentieerde testaanpak is aan te bevelen om een goede balans te vinden in het testwerk. Om dit te realiseren kunnen we risk poker toepassen, de tegenhanger van het in SCRUM teams veel gebruikte planning poker. Lees meer



 

TIP: Maak áltijd een functioneel ontwerp

Ik werkte ooit als pensioenanalist bij een pensioenuitvoerder. Het testen stond er nog in de kinderschoenen. IT en pensioenadministratie (gebruiker) opereerden pas sinds kort los van elkaar. Ik was de link tussen deze twee afdelingen. Ouwe-jongens-krentenbrood vierde hoogtij: slechte communicatie, mondelinge afspraken, informele emails. Lees meer




 

TIP: De kracht van het onverwachte

Door een ongebruikelijke invoer, vind je soms opmerkelijke fouten – bugs far beyond imagination. Ik adviseer daarom reguliere testen aan te vullen met exploratory testen. Bij het testen van nieuwe opleveringen – aanpassingen in bestaande programmatuur of nieuwe applicaties – zijn de reguliere testen gebruikelijk. Denk aan het doorlopen van alle mogelijke paden. Aan de regressietest. Aan het controleren van validaties: worden de regels voor de invoer bij bepaalde velden correct nageleefd? En een regressietest moet beoordelen of de nieuwe functionaliteit de oude niet heeft veranderd: kloppen de berekeningen en worden op het juiste moment de juiste formulieren, e-mails en sms’en verstuurd? Lees meer


 

TIP: Laat je niet beperken door de testbasis

Vaak gaan testers er vanuit dat alles beschreven kan worden in documentatie, een volledige beschrijving in functionele specificaties. Dit wordt dan gezien als de testbasis.  Je vergelijkt de testbasis met de software en de verschillen hiertussen zijn bugs. Als alles vergeleken is weet je wat de kwaliteit van een product is. Of niet? Vanuit jarenlange ervaring en gesprekken met andere IT’ers weet ik dat geschreven documentatie (als het er überhaupt is), nooit volledig, eenduidig, tot in de detail beschreven en al verouderd is op het moment van schrijven. Er zijn testers die zich gemotiveerd voelen om de organisatie waar ze in werken te helpen met het schrijven van goede functionele documentatie door technieken te gebruiken zoals UML, Flow diagrammen, Gherkin, et cetera. Lees meer

 


TIP: Niet iedereen is hetzelfde!

Afgelopen weken heb ik een communicatietraining mogen verzorgen voor een middelgroot IT bedrijf over de communicatie met hun opdrachtgevers, hun interne- en externe collega’s. Wat direct weer opviel was dat vele techneuten een hele logische en feitelijke manier van denken hebben. Dat is hun kracht, daarmee kunnen ze makkelijk problemen oplossen, verbanden leggen en technische uitdagingen aangaan. Vanuit die logische gedachten denken zij echter vaak dat iedereen denkt zoals zij denken. Dat is toch logisch?? Zij denken heel logisch, dus zal iedereen wel zo denken. Lees meer

 

 

TIP: Laat je niet op de kast jagen!

Je hebt alle testsoorten die in scope zijn succesvol afgerond. Alle bevindingen die gedetecteerd zijn, zijn opgelost en succesvol gehertest. Als Test-/Quality manager Releases heb je een vrijgave advies afgegeven om het stukje nieuwe functionaliteit / change naar productie te brengen. Gewoon goed werk geleverd vind je zelf en tóch tijdens deployment naar productie gevolgd door wat checks komt aan het licht dat het niet werkt! Gevolg je krijgt te horen: “Is het wel goed getest?”, “Kan het testrapport worden opgestuurd?”, “Welke testen zijn uitgevoerd?” Je vraagt je dan heel terecht af wat er aan de hand is na bijv. weer een release, terwijl het van te voren is getest? Lees meer

 

TIP: Beloon acceptatie testers voor hun inzet

Deze tip is vooral van toepassing op development teams binnen internationaal opererende organisaties, met acceptatietesters die 'op afstand' mee-testen in een UAT.  Een bekend probleem hierbij is dat de participatiegraad vaak erg tegenvalt, vooral ook omdat de gebruikers/testers zich op een fysiek andere locatie en vaak in een andere tijdszone bevinden.Een acceptatietest waarbij testers samen in een ruimte komen testen op een specifiek gepland moment, is nog wel goed te sturen. Echter hoe verder weg men zich bevindt, hoe meer grip je hier op verliest, hoe groot hun toewijding ook is. Iedereen heeft het altijd druk-druk-druk en acceptatietesten is dan iets wat extra op hun bord komt, en schiet er dan snel bij in. Lees meer

 

TIP: Uit je comfortzone stappen

De begrippen communicatieve vaardigheden en uit je comfortzone stappen worden tegenwoordig veelvuldig gebruikt. Met name in relatie met werken binnen Scrum. Wanneer ik dan wel eens vraag: hoe doe je dat dan? Krijg ik als antwoord: vooral trainingen volgen en vervolgens moet je het zelf doen. Het eerste is niet zo moeilijk er zijn genoeg trainingen op het gebied van communicatieve vaardigheden, presentatietechnieken of didactische vaardigheden. Maar dan komt het, hoe stap je uit je comfortzone. Heel veel mensen vinden het namelijk eng om voor een groep te gaan staan of om hun mond open te doen in een groep. Dat probleem had ik 25 jaar geleden ook. Lees meer


TIP: Gebruik een 'magisch kwadrant' om impediments op te lossen

Tijdens een van mijn opdrachten waar ik als testcoördinator werkzaam was, leidde ik eens een team van testprofessionals tijdens een verbetertraject.
Een retro sessie had eerder al naar voren gebracht dat ons team te maken had met structurele impediments en na een nachtje erover geslapen te hebben zette ik het onderstaande model op naar voorbeeld van een zogenaamd 'magisch kwadrant'. Lees meer

 


TIP: Wat doe je als er geen of geen volledige testbasis aanwezig is?

Hoe vaak zien we nog dat de tester wordt gevraagd om te testen zonder dat er functionele specificaties (testbasis) aanwezig zijn. En helaas zien we ook nog te vaak dat de tester daarmee gewoon instemt en het systeem gaat testen. Maar is dit eigenlijk wel mogelijk? Als we kijken naar de definitie van testen, is het antwoord snel gegeven
Lees meer

 

TIP: Focus als testmanager op je skills

Er doen zich altijd wel zaken voor die in de ogen van de projectmanager niet kunnen wachten op een standaard rapportage. Ik zie dan vaak dat hij de testmanager bevraagt over de gevolgen voor het project. Dit verscherpt de hiërarchische verhouding, die in het project-organigram toch al scheef lag. De testmanager zit daarmee direct in de verdediging en kan bijna niets meer goed doen.

Lees meer

TIP: Leer van fouten - Jan van Moll 

Natuurlijk, je doet je best om defects te pakken, voordat je het product vrijgeeft. Toch zie je na de release vaak nare fouten. “Hoe kunnen we die nou gemist hebben?”, hoor je dan op verwijtende toon. Het is zaak de fouten snel te herstellen, maar belangrijker nog is te weten wat er écht mis ging. En dan bedoel ik ook écht! Dus niet alleen focussen op het technisch falen, want dat is zelden de oorzaak.

Lees meer

TIP: Vraag: ‘hoe stellen we vast dat …?’

Testers klagen vaak dat de specificaties niet SMART, niet testbaar zijn. Je kunt dat in je reviewcommentaar vermelden. Of van de daken schreeuwen dat ‘testbaarheid verplicht is’. Ik heb meegemaakt dat vervolgens een paragraaf ‘testbaarheid’ in het template voor de specificaties werd opgenomen. Dat hielp, maar niet heus. Wat kan je dan wél doen? Vraag door en begin zo: ‘Hoe stellen we vast dat …?’ In praktijk gaat dat als volgt:

Lees meer