Trifolium Repens de nieuwe testbasis voor agile en waterval testen

Presentatie over: "Trifolium Repens de nieuwe testbasis voor agile en waterval testen"— Transcript van de presentatie:

1 Trifolium Repens de nieuwe testbasis voor agile en waterval testen
Najaarsevenement TestNet 2015 ing. Rudi Niemeijer @rudiniemeijer #trifolium De afgelopen jaren heeft het testvak vooral geinvesteerd in de discussie of de iteratieve ontwikkelmethode betere resultaten oplevert dan de sequentiele ontwikkelmethode. We hebben voor het gemak maar even laten liggen dat we zelf ook nog het één en ander uit te zoeken hadden en zijn met alle enthusiasme op het nieuwe agile testen gedoken. Voor zij die ondanks het ‘nieuwe testen’ nog steeds het idee hebben dat je met het testen toch ook wel een beetje geluk moet hebben, heb ik een paar interessante ontwikkelingen. Testconsultancy Groep

2 Trifolium Repens de nieuwe testbasis voor agile en waterval testen
Najaarsevenement TestNet 2015 ing. Rudi Niemeijer @rudiniemeijer #trifolium De afgelopen jaren heeft het testvak vooral geinvesteerd in de discussie of de iteratieve ontwikkelmethode betere resultaten oplevert dan de sequentiele ontwikkelmethode. We hebben voor het gemak maar even laten liggen dat we zelf ook nog het één en ander uit te zoeken hadden en zijn met alle enthusiasme op het nieuwe agile testen gedoken. Voor zij die ondanks het ‘nieuwe testen’ nog steeds het idee hebben dat je met het testen toch ook wel een beetje geluk moet hebben, heb ik een paar interessante ontwikkelingen. Testconsultancy Groep

3 Trifolium Repens 20 jaar elektronicus informaticus testadviseur workshopdocent testmanager procesontwerper 2009 U spreekt met de Keuringsdienst van Waarde 2010 Valhelm verplicht! 2011 In de wolken! 2012 Testen van iPhone en iPad Apps Mijn naam is Rudi Niemeijer, sinds 1998 testadviseur van het Groningse testadviesbedrijf Testconsultancy Groep. Ik ben afgestudeerd elektronicus en informaticus en heb er de afgelopen jaren een gewoonte van gemaakt om mijn ervaringen in de vorm van een presentatie te delen. U 2009 hebt u me over sinaasappelen horen vertellen, die stonden voor samenwerkingsvormen. In 2010 moest de valhelm op, met verschillende management- en adviestechnieken. Webservices en Internet of Things kwam in 2011 naar voren en in 2012 mijn ervaringen met het testen van iOS devices ging op aan het gebruik van kwaliteitsmodellen en formuleren van acceptatiecriteria. Vandaag kijken we naar de testbasis, en manieren hoe we het beste uit iteratief en sequentieel kunnen halen. Ik ga eerst met u naar de problemen kijken waar we als testers nog steeds tegenaan lopen en dan met u de oplossing bespreken. Aan het eind van mijn presentatie is alle ruimte voor het stellen van vragen. 2013 Leidraad Test en Acceptatie (boek) Visualisatie op whiteboards Testconsultancy Groep

4 @rudiniemeijer #noordertest

5 bug tracking methodology bug #1 Grace Hopper, 1945
@rudiniemeijer #noordertest

6 Iteratief versus sequentieel
Ontwerper Tester Test-expertise Go testing! Iteratief versus sequentieel Bouwer Effectiever testen? @rudiniemeijer #noordertest

7 DOC testbasis tester software bevinding bevinding bevinding bevinding
Trifolium Repens bevinding bevinding bevinding bevinding bevinding bevinding #import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } Lorum Ipsum Bewaar Annuleer DOC Een veelgebruikte definitie van ‘testen’ is het vergelijken van de gewenste met de werkelijke situatie met als doel het rapporteren van verschillen. In veel gevallen betekent dat, dat één of andere vorm van ‘waarheid’ wordt vergeleken met ‘software’, waaruit ‘bevindingen’ ontstaan. Het oplossen van het verschil tussen gewenste situatie en werkelijke situatie hoort niet tot de definitie van testen, hoewel bij sommige testen ‘bugs’ wel direct worden hersteld. Deze werkwijze heeft ons lang van de straat gehouden: hele testcarrières zijn op dit model gestoeld. Ze vormen maar een stukje van de puzzel testbasis tester software Testconsultancy Groep

8 Trifolium Repens Een kleinere, maar vokaal luidere groep heeft een hele andere testaanpak en is wars van alle vormen van methode, technieken, documentatie en aanpakken. Ze staan voor ‘exploratory’ en ‘the oracle assumption’. Ook zij hebben gelijk, maar vormen niet het hele antwoord. software testing guru Testconsultancy Groep

9 het probleem van de laatste bladzijde
Trifolium Repens Model curve Feitelijke test- bevindingen Overgebleven fouten in de software Aantal bevindingen Alle geplande testen afgerond Het hinderlijke van testen baseren op documentatie, is dat documentatie op een gegeven moment is uitgeput, voor wat betreft het ontwerpen van testgevallen. En vaak is de software dan nog niet uitgeput. En we krijgen dan discussies over de rol van documentatie. Week het probleem van de laatste bladzijde Testconsultancy Groep

10 “we kunnen niet alles testen”
Trifolium Repens “we kunnen niet alles testen” Reactie op fout gevonden tijdens gebruik “maar het werkt niet conform het ontwerp” Discussie met ontwikkelaar over hoe het zou moeten werken “wanneer krijg ik het ontwerp dan” Vraag van een tester tijdens een daily stand-up “maar het werkt conform het ontwerp” Reactie van tester bij het horen van klachten van gebruikers “welke testspecificatietechniek moet ik daar voor gebruiken” Vraag aan een testconsultant naar aanleiding van het testdoel ‘bepaal de gebruikseffectiviteit’ van de software Het probleem waar we mee kampen, is dat het traditionele, veilige model van ‘tegen de specificaties aan testen’ niet goedwerkt: we komen er zo vaak mee in de problemen, dat de wereld om ons heen alternatieven aan het verzinnen is. We worden geconfronteerd met ‘Real Good Testing’, ‘Exploratory Testing’, ‘Model Based Testing’, ‘Rapid Software Testing’, ‘Agile Testen’, ‘Tessten 2.0’ en geen van deze methoden is ontwikkeld omdat het traditionele model zo goed in elkaar zit. Echte oplossingen komen je echter zelden tegen en niet worden positieve aspecten van de ene aanpak, verpakt onder een nieuwe naam, op dezelfde manier toegepast in andere aanpakken. “maak testgevallen met beslistabellen en voer deze uit” Testaanpak die in 9 van de 10 testplannen staat vermeld Testconsultancy Groep

11 de software doet zoveel meer
Trifolium Repens Vak A .. Vak B Lorum Ipsum Bewaar Annuleer ? #import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } Lorum Ipsum Bewaar Annuleer ----- Notulen ( :32) ----- Éen van de problemen waar je tegenaanloopt in het traditionele model van documentatie als testbasis is, dat de documentatie wel heel erg bepalend is voor de kwaliteit van de test. Iets wat niet in de documentatie staat, kan ook niet worden getest. En tekst is een statisch fenomeen: niet-functionele kenmerken van de software kom je slechts zelden in functionele specificaties tegen. De kwaliteit van het testen is daarmee niet zo heel hoog, in vergelijking met de complexiteit en omvang van de hedendaagse softwareontwikkeltrajecten. de software doet zoveel meer Testconsultancy Groep

12 .. “comprehensive documentation over working software”
Trifolium Repens “comprehensive documentation over working software” Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla sodales a eros vitae tincidunt. Sed sollicitudin tortor non metus fringilla, nec feugiat velit fermentum. Phasellus viverra ornare faucibus. Ut vel efficitur elit. Morbi aliquet leo ut gravida sollicitudin. Pellentesque a malesuada tortor, sed porttitor odio. Curabitur elit magna, ultrices id est a, tincidunt cursus dui. Praesent viverra urna vitae est sollicitudin, ac commodo est tristique. Pellentesque quis efficitur ante. Mauris vitae augue tristique, laoreet tellus ut, gravida tortor. Fusce dui dui, efficitur sed odio in, facilisis congue dolor. Nunc sodales consequat urna vitae faucibus. Sed dolor ligula, sollicitudin a neque et, tempor facilisis leo. Cras sagittis magna metus, id gravida lorem rhoncus non. Cras at tempus nisi. Cras rutrum vel lectus sit amet cursus. Aenean malesuada, leo quis fermentum sodales, ante augue ullamcorper odio, tincidunt aliquet felis augue at velit. Etiam sit amet volutpat libero, ut auctor velit. Curabitur lacinia leo et urna eleifend placerat. Nam vel tortor vel turpis pharetra interdum. Fusce eu erat consequat, facilisis massa eget, consectetur ante. Duis tempus eu ante vitae rhoncus. Nulla facilisi. Aenean a aliquam massa, in sodales orci. Quisque pulvinar placerat porttitor. Proin tristique facilisis metus, vel efficitur quam auctor a. Maecenas vel egestas turpis, sit amet accumsan urna. Praesent id lectus at purus gravida dapibus. Curabitur eget tincidunt dui, non tempor lacus. Aenean tincidunt, orci vitae facilisis commodo, nisl odio luctus tellus, nec blandit lacus sapien et orci. Donec ac mauris vel nibh aliquam bibendum sed sed est. Fusce dolor metus, ultrices id ex id, sodales consequat augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer tellus libero, placerat vel faucibus et, ultricies sed felis. Aenean mattis pharetra turpis a placerat. Maecenas sit amet risus eu neque lacinia sodales tincidunt nec sapien. Sed metus leo, rhoncus eget bibendum eu, interdum sit amet dui Lorum Ipsum Bewaar Annuleer .. Lorum Ipsum Bewaar Annuleer ----- Notulen ( :32) ----- De andere kant van de medaille van testen aan de hand van documentatie is, dat degene die de documentatie opstelt, van te voren niet weet hoe de software feitelijk gaat worden. Hij of zij probeert daar vaak een zo goed mogelijke invulling voor te bedenken. Het gevolg is soms vaak hele dikke, complexe en zo goed als onbruikbare documenten. Overigens is dat niet alleen voorbehouden voor specificaties van software: sommige testmethoden hebben er ook een handje van: als je maar zoveel mogelijk woorden gebruikt, is er altijd wel ééntje die blijft plakken. De afstand tot de werkende software is soms wel heel groot en het is begrijpbaar, dat hele ontwikkelmethodieken zich tegen deze lijvige documentatie afzet. Testconsultancy Groep

13 gebruik breekt de software
Trifolium Repens Lorum Ipsum Bewaar Annuleer ----- Notulen ( :32) ----- Het gebruik van software is ook zoiets waar we als testers al lang mee wikken. Laten we het gebruik in de acceptatietest stoppen, lijkt wel de oplossing. Maar dat is niet een goede oplossing. Software is bedoeld om gebruikt te worden en het blootstellen aan eindgebruikers is niet iets wat onderschat moet worden. 'Productie is de beste test' betekent vooral, crowdsourcing op testgebied. Honderden gebruikers kunnen delen van de software bereiken die voor testprofessionals verborgen is gebleven. Het resultaat is onaanvaardbare softwarefouten, in de eerste dagen van het gebruik. gebruik breekt de software Testconsultancy Groep

14 Functionals versus non-functionals?
@rudiniemeijer #noordertest

15 ? DOC bevat de afgesproken functies is gebruiksvriendelijk
Trifolium Repens Product- kwaliteit Gebruiks- kwaliteit DOC ? Geschiktheid Prestatie Overdraagbaarheid Effectiviteit Efficiëntie Toepasselijkheid bevat de afgesproken functies is gebruiksvriendelijk levert snel resultaat Waar haal je de gewenste situatie vandaan? En hoe test je dat met het traditionele model? ----- Notulen ( :32) ----- Wie werkt er met ISO 12207, en als bron voor de testdoelen? Proceskwaliteit, productkwaliteit, datakwaliteit en gebruikskwaliteit leveren in totaal een waardevolle 64 verschillende testdoelen op, waarvan 'functionele werking' er eentje is. Maar als de functionele specificaties onze enige kennisbron zijn, hoe gaan we dan om met de overige 63 testdoelen? is geschikt voor alle taken en doelen is nauwkeurig efficiënt koppelbaar veilig zuinig Testconsultancy Groep

16 methode A versus methode B
Trifolium Repens 1 2 3 4 5 6 7 8 9 10 functioneel ontwerpen bouwen testspecificatie testuitvoering methode A versus methode B testen testen testen testen testen Daily scrum Daily scrum Daily scrum Daily scrum testen Daily scrum testen ----- Notulen ( :32) ----- Als we kijken naar de twee grote ontwikkelmethoden: sequentieel en iteratief, dan zien we ook veranderingen die niet goed met documentatie kunnen worden opgevangen. testen testen testen testen testen Testconsultancy Groep

17 DOC goede informatiebronnen ----- Notulen (09-10-14 13:32) -----
Trifolium Repens softwareproduct is de inherente representatie van de werking en intuïtieve ‘apps’ zijn goeddeels zelfverklarend kennis en ervaring op specifieke gebieden zoals architectuur, beveiliging, sociale media, user interfaces enzovoorts documentatie of specificaties beschrijven de beoogde werking van het softwareproduct bedrijfs- of zorgprocessen bepalen hoe een softwareproducten wordt gebruikt en welke eigenschappen belangrijk zijn #import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } Lorum Ipsum Bewaar Annuleer DOC ----- Notulen ( :32) ----- Het wordt toch tijd om die Orakel van de eerste dia's erbij te roepen. goede informatiebronnen Testconsultancy Groep

18 DOC documentatie of specificaties als testbasis
eenvoudige te formuleren testaanpak DOC test is zo goed als de documentatie niet heel veel voorkennis nodig: iedereen snapt dit grootste deel testtijd zit in specificeren van testen ook in de vorm van ‘user stories’ en ‘comments’ documentatie is ‘de baas’ over werkende software eenvoudig planbaar en beheersbaar testtraject niet heel geschikt als de documentie nog gemaakt moet worden (er nog niet is) documentatie of specificaties als testbasis

19 bedrijfs- of zorgprocessen als testbasis
geen overbodige testen: alleen het gebruik telt grootste deel testtijd zit in het voorbereiden van de testuitvoering geschikt voor participatie van eindgebruikers tot in lengte van jaren fouten in de (niet eerder gebruikte) softwaredelen weinig documentatie nodig relatief eenvoudig te beschrijven testaanpak stelt hoge eisen aan de tester: zowel zicht op het gebruik als op de mogelijkheden van de software eenvoudig planbaar en beheersbaar testtraject processen willen nog wel eens veranderen bedrijfs- of zorgprocessen als testbasis

20 softwareproduct als testbasis testen zijn slecht herhaalbaar
#import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } Lorum Ipsum Bewaar Annuleer testen zijn slecht herhaalbaar bijna de gehele testtijd is testuitvoering weinig tot geen aansluiting bij de toekomstige bedrijfs- of zorgprocessen bij voldoende tijd hele stabiele software testkwaliteit nogal afhankelijk van competentie tester heel geschikt voor iteratief, agile of scrum ontwikkelen of andere testen met korte doorlooptijd slecht planbaar of beheersbaar testtraject kritiek pad testen zijn nooit af en langdurig testen is niet heel motiverend softwareproduct als testbasis geen testspecificatie vooraf

21 ervaring als testbasis
unieke inbreng van kennis levert gedegen testonderzoek op testkwaliteit volledig afhankelijk van competentie en ervaring tester ideale aansluiting bij verschillende ISO gebaseerde testvormen ervaringsdeskundigen zijn schaars en moeilijk vindbaar specifieke testen op heel hoog niveau goed beheersbaar maar slecht (in)planbaar heel goed voor te bereiden ervaringsverhalen zijn soms heel vermoeiend specifieke ingevlogen kennis is efficiënter geen specifieke kennis van de te testen applicatie ervaring als testbasis

22 combineren van de mogelijkheden
Trifolium Repens combineren van de mogelijkheden 1 2 3 4 5 6 7 8 9 10 voldoet aan de specificaties is bruikbaar in de praktijk alle functies doen het ----- Notulen ( :32) ----- In de tijd gezien is er iets voor te zeggen om de verschillende mogelijkheden voor de testbasis af te wisselen. Hier een voorbeeldje invulling van specifieke richtlijnen, standaarden en andere afspraken Testconsultancy Groep

23 1 2 3 4 5 6 7 8 9 10 #import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } Lorum Ipsum Bewaar Annuleer DOC toenemende mate van planningsuitdaging en discussie met leverancier

24 Testaanpak gebaseerd op de testbasis
Trifolium Repens Testaanpak gebaseerd op de testbasis Stel testgevallen op aan de hand van de documentatie. Stel de documentatie leidend en wijk zo weinig mogelijk af. Hou de praktische uitvoering van de testen in het oog. Doe een intake op de software. Voer de testen uit. Registreer de bevindingen. Analyseer, welke processen er zijn en welke stappen hierin voorkomen. Bepaal op welke delen van de software de test uitgevoerd moet worden. Stel gedetailleerde testscenario’s op. Voer de testen samen met meerdere eindgebruikers uit. Denk in termen van opiniepeilingen en statistiek. Registreer bevindingen. Bepaal het testdoel in termen van de zichtbare kenmerken van de software. Leg eenduidig vast, onder welke voorwaarden de test als succesvol beschouwd wordt. Documenteer de testen tijdens de testuitvoering. Registreer bevindingen. ----- Notulen ( :32) ----- Het beschrijven van een testaanpak is niet voor iedere testprofessional eenvoudig. Ik zie een hoop testplannen waar het doel van de test nog steeds als 'het testen van software' is verwoord. Iemand die kan aangeven waarom dat raar is? Het doel van een test moet zijn, iets vast te stellen. De mate waarin er verschil zit tussen gewenste en werkelijke situatie bijvoorbeeld. Maar meer specifiek is nog mooier: vaststellen dat iets veilig is om te gebruiken bijvoorbeeld. Of effectief is in het ondersteunen van taken en doelen. Bepaal met de specialist vooraf het deel van de software waarop de testen uitgevoerd gaan worden en het doel van de test. Spreek een vaste inzettijd af. Documenteer de uitgevoerde testen tijdens de testuitvoering. Evalueer de testen achteraf. Registreer samen met de specialist de bevindingen. Testconsultancy Groep

25 complementaire kennisgebieden
Trifolium Repens Software ontwikkelaar veel softwarekennis In staat om in korte cycli de beoogde aanpassingen te realiseren of aan te passen en te bepalen in welke mate de gewenste aanpassingen al zijn doorgevoerd. Beschikt over een heldere lijst van aanpassingen, zoals offerte, ‘user stories’ of ‘backlog’. Ook: testautomatisering mogelijk Beheer of test- organisatie weinig organisatiekennis Kennis van de zorg- of bedrijfsprocessen en bij uitstek in staat om te bepalen of iets ‘bruikbaar’ is veel organisatiekennis Op de hoogte van de wensen, tijd en middelen om de beoogde testen voor te bereiden en uit te voeren. Beschikt vaak over ‘reële testdata en testomgevingen’ Gebruikers-organisatie complementaire kennisgebieden Op de normaliter te onderkennen testniveau’s heersen verschillende kennisgebieden: software ontwikkelaars weten bijvoorbeeld veel van hun software, eindgebruikers weten vaak heel goed wat ze met de software zouden willen en beheer en testorganisaties weten vaak van alles wat. De uitdaging zit er in, om de juiste kennisgebieden te combineren met de passende testbasis en deze in te zetten in een maatwerk-testoplossing weinig softwarekennis Testconsultancy Groep

26 sequentieel en iteratief
4 keer testbasis kwaliteitsmodellen kennisgebieden sequentieel en iteratief

27 Functionele correctheid Functionele compleetheid
FUNCTIONALITEIT ISO Productkwaliteit en Gebruikskwaliteit Acceptatietesten Gebruikersorganisatie Functionele toepasselijkheid (“de mate waarin de software bijdraagt aan het behalen van taken en doelen”) Systeemtesten Beheer of testorganisatie Functionele correctheid (“de mate waarin de software de juiste resultaten beschikbaar stelt”) Ontwikkeltesten Project of bouwers Functionele compleetheid (“de mate waarin [de software] alle gespecificeerde taken ondersteunt”) Relevante deel van de bedrijfs- of zorgprocessen worden gebruikt als testbasis bij het bepalen van taken en doelen Beschikbare procedures, veranderverzoeken en fit-gap analyses worden gebruikt om de resultaten te onderzoeken, gecombineerd met ervaring en inzicht User Stories, een overzicht van te implementeren functies en de software zelf wordt gebruikt om de volledigheid te bepalen. Iedere aanwezige knop en functie ‘moet het doen’ Voorbeeld maatwerk testoplossing @rudiniemeijer #noordertest

28 Groter voorbeeld maatwerk testoplossing
CPB Compati-biliteit BVL Beveiliging PRF Performance FUN Functiona-liteit TPL Toepasse-lijkheid GBG Gebruiks-gemak Acceptatietesten Gebruikersorganisatie Juistheids-test Werkplek-test Taak- en doeltest Systeemtesten Beheer of testorganisatie Privacy- test Respons- test Functietest Bruikbaar- heidstest Ontwikkeltesten Project of bouwers Installatie-test Capaciteits-test Compleet-heidstest Locatietest Groter voorbeeld maatwerk testoplossing @rudiniemeijer #noordertest

29 FUN BVL PERF GBG Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Functiona-liteit BVL Beveiliging PERF Capaciteit en tijd GBG Gebruiks-effectiviteit Sprint 1 “User Interface” Sprint 2 “Database” Sprint 3 “Overzicht en rechten” Sprint 4 “Refactoring en techniek” Sprint 5 “User Interface en beheerfuncties @rudiniemeijer #noordertest

30 @rudiniemeijer #noordertest
testvormen Duidelijke focus door keuze voor bepaalde testvorm testsoorten Heldere testbasis met een duidelijke ‘agile pitch’: alleen documentatie als die écht nodig is Verantwoordelijkheden duidelijk binnen én buiten de testsoorten Duidelijk testdoel ‘Knock out criteria’ inzichtelijk @rudiniemeijer #noordertest

31 sequentieel en iteratief
4 keer testbasis kwaliteitsmodellen kennisgebieden sequentieel en iteratief

32 Trifolium Repens

33 Groningse Tegelwijsheid
Geen geluk zonder druk Groningse Tegelwijsheid testen in balans

34 Dat is meer geluk dan wijsheid Softwarefouten brengen geluk
Lijfspreuk van historische software ontwikkelaars Softwarefouten brengen geluk Als je iets (per ongeluk) stukmaakt, krijg je later veel geluk Guus Geluk Iemand die altijd nóg een extra fout vindt Het geluk komt bij het testen Het geluk kan altijd onverwachts plaatsvinden Wie geluk heeft vindt een fout Lijfspreuk van historische software testers Ik heb nou nooit eens geluk Uitspraak van testers na hun salarisonderhandeling Dat is een geluk bij een ongeluk Beginsel van de eerste wet tot behoud van ellende Geen genuchten zonder zuchten Het testen van software is gewoon heel hard werken

35 Rudi Niemeijer - @rudiniemeijer - niemeijer@testconsultancy.nl
Bedankt! Rudi Niemeijer - @rudiniemeijer - testen van software ontzorgd®