Testing is dead because

Testing is dead because:

• we know how the user thinks
• we know how the sales people think
• we know how the support people think
• functionality that is written down is perfect
• designs are fully understandable
• designs are not ambiguous
• a user will follow the manual strictly
• a user will do no strange things with the software
• a user will not make mistakes using the software
• interfaces to others systems are always the same and standardized
• there are no risks with introducing this product into the world
• the program will never crash because we made it crash proof
• the customer will believe us because we've got blue eyes
• calculations are never wrong in computers
• there is nothing that influences our software externally
• memory is cheap and we can use as much as we want
• storage is cheap and we can use as much as we want
• there is no limit to storage
• access rights for users don't change
• graphics are completely reliable because calculations made are reliable
• the user will understand our menu and will not be confused
• a hacker will not try to harm the software
• we will not be DOS attacked
• user will not give their password to strangers for a bar of chocolate
• up scaling the software after a period of use is just adding some resources
• big amounts of data in the database will not cause problems
• lots of users logging into the system will not cause problems
• lots of users working in our software at the same time will not cause performance loss
• everybody has a fiber connection to the internet
• adobe flash works on all machines
• the user will have plug-ins in their browsers for all kinds of stuff we put in our software
• the software will run on any platform
• changing the software is done in a jiffy
• changing the software will not change functionality
• adding functionality will not cause other functionality to fail
• our FAQ is more than enough to help users with their problems they created
• a developer is never tired and always on the edge of clear thinking
• developers are super-humans and make no mistakes
• embedded software will not react strange when hardware is dropped into water
• embedded software is easily updated without clearing the complete device
• planes can fly because the software is reliable
• because of the agile approach it is bug free software
• because we really thought a lot about it there is no way this will fail
• communication within the development team is perfect
• communication between development and the business is perfect
• nobody will complain on great software
• the business goals are perfectly implemented because we know those goals
• nothing strange happens when electricity will fail
• data imported in the software is always consistent and clear
• translations to other languages is perfect, we understand all languages
• ..... (I could continue, but this will make my point I guess)

Yeah, sure. Don't believe the rumours. Have fun testing!
I certainly will.

Some learned lessons from the Agile Testing Days (part 3)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics. This is part 3 of this blog.

Understand business goals and research alternatives. (Gojko Adzic (@gojkoadzic) - “Product Management using Effect Maps”)
Why is a feature really wanted by the business? This is something all members of a team should be aware of. This is because of awareness of the goal. The goal is a business goal and technology is a way to reach such a business goal. For example increasing the registered users by a million. With a mindmap technique (effect mapping) you could search for all alternatives for reaching that goal. Discuss all alternatives, draw this mindmap and get fresh ideas about this. Maybe the feature requested was not the fastest or the right way to get to the goal. Maybe an advertisement campaign could do the same for less money. Always research the alternatives and a good way is using a effect mapping.

Understand the "Why?

Some learned lessons that I could take right with me in my briefcase: Lisa Crispin(@lisacrispin) & Janet Gregory(@janetgregoryca): “Appendix A: Lessons Learned since Agile Testing Was Published”

• Try to understand the business value of a feature that is asked to be implemented (also mentioned by Gojko Adzic with effect mapping talk)
• Test automation: Needed, but maybe developers can do a better job scripting than you as a tester.
• People should be allowed to make mistakes, from mistakes you learn more than when everything went ok.
• Learn continuously in your job: opportunities enough. (also mentioned by Huib Schoots)

The next part of this posting come from some discussions and my own thoughts from a informal discussion in the evening on one of the Agile testing days. (it was called PATS)

Yes, there was beer too, and pizza later :-)

What makes a great tester is not possible to define, but you can help people learn and improve and become great testers.
What makes a great tester: Well, skills are not important, those can be learned, but it is very difficult to describe the “great tester”. When you think about it and discuss, you would almost try to describe the “greatest employee” or “the perfect human”. I’ve got more ideas about this, but that would be a different blog post. You could help employees really develop themselves (so this is also not only for testers) to create an environment where people can make mistakes. Or even set a goal for people to fail. Celebrate failures: you have learned something! (at least you would expect the latter).
Another good point is to give people the time (for example 2 or more hours a week ) to do something for themselves instead of expecting them to do that in their own time.

We still got a lot of work to do concerning risks and communication with the business about risks.
I’ve seen it myself, but mostly I get positive reactions from the business when I start to talk with them about risks, but this could be different. “We want 0% risk when we ship this.” We should ask the business for an acceptable risk level, but first I guess we should explain more about it.
Also I see a difference in perception about risks in the testing world. Are risks part of a test report and release advise or should they be used before starting testing or even developing. I would say, discuss those risks before starting developing stuff, maybe it is an idea to discuss product risks together with the effect map of Gojko Adzic. Well, this is one subject I will surely put more thoughts in.

I just liked this slide so much I had to put it in: "Where would you bite first?" (Gojko Adzic)

Anyway
I learned a lot at this great conference (and will do more the coming weeks). I met a lot of testers and (!) developers and discussed testing. At one of the presentations it was asked how many testers there were in the public. About 2/3rd of the people raised their hands. So this was also a bit of a mixed conference. So the ‘other’ group was there too :-), which made it more interesting.

Furthermore it was not a massive conference such as Eurostar, it felt like a small group of people even. (don’t know how many people attended). The ‘market’ as you see with lots of events was small (about 10 companies at the most) and relaxed. Just like the conference itself. I enjoyed it and I think I will be there next year too. Maybe I’ll see you there? Follow the Agile Testing days on Twitter.

Finally a 'thank you' for the organizers of this event
Thank you organizers (Díaz & Hilterscheid) for organizing this great event. It was good to be there. I had a nice talk with one of the organizers (José Díaz) about the conference. But also the Agile Testing Days app that was introduced for Android as well as for Apple devices. It had some flaws, but it worked good enough for me. Well, testers will be the first ones to complain of course :-)

José Diaz introducing the speakers.

Some learned lessons from the Agile Testing Days (part 2)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics.

Now to learned lessons from the sessions

We are getting more and more inventive with tools that help us testing. (Geoff Bache & Emily Bache (@emilybache): “Specification by Example using GUI tests – how could that work?”)
There are ways for automation of tests for which you do not have to program and you don’t need the software under test. You can still prepare automation for the new features. By discussing the specifications with examples beforehand you can prepare an automated tool up-front. When the software is ready, the testcases will be there and preparing the tests is a quick and simple job. This is one example of inventive ways to do automation. If you are interested in more details, please check out this site: http://texttest.carmen.se/index.php?page=main

A way to deal with the information overflow and too much to learn. (Rob Lambert (@Rob_Lambert): “Do agile teams have wider awareness fields?”)
We can learn everything we think there is to know and still have a lot to learn. Because we really can’t learn everything. There is a lot of information out there and we will have to filter that information to our own needs. We will have to make choices. A good way to do that could be by making a diagram for yourself of things you know, you can influence and things you don’t know yet (and can’t do). Furthermore you could use a kind of “fish diagram” to plan the things you want to learn.

Slide from the presentation (Rob Lambert)

Rob Lambert's slides can be found here

Don’t think in ‘we’ and ‘them’. I will be aware of this kind of things from now (I hope) (Linda Rising: “Who do You Trust? Beware of Your Brain”)
Automatically, if we speak of the other group such as: Them developers, them designers, them project managers, you will influence yourself, you brain, so that working together with ‘them’ could get difficult. At least you will have automatically build a kind of wall between you and them. For the group you are in and working together within a specific named group (testers for example), this could be a positive thing. But closing out other groups (unaware you are doing that, we all do that) could cause problems and rivalry. Organizations and groups within organizations should be aware of a common goal what binds all people together. The video is not out (yet?), but you can find another good talk from Linda here.

There is always room to improve. (Huib Schoots (@huibschoots) - “So you think you can test?”)
I guess I think I’m a great tester, I am testing now for about 15 years. But what does that mean really? Did I do the same trick over and over again during the 15 years of testing? Because then the experience will be only 1 year of experience… Repeated 15 times. I don’t think I fall in this category, but there are so many ways to improve yourself as a tester and improve your skills. If I check the list that Huib Schoots showed us I can see I’m still missing out on some wonderful experiences. But where to find the time? Someone from the audience said that for a professional would use 20% of his private time for his job. At least I do that, I guess more than that. But there is always room to improve. You can find a blog posting about this from Huib here.

Another lesson here: Being passionate is contagious. That one I had learned already.

Next posting later this week.

Follow me on Twitter to get updated or add yourself to my Newsletter.
You could also check out my Testevents website! (There is a testevents newsletter too there)

Did you miss the Agile Testing Days and you live in The Netherlands, please check this out on the 6th of December VX company does a summary for you.

Some learned lessons from the Agile testing days (part 1)

In the week of the 14th of November I was at the Agile testing days in Potsdam and I’m going through my notes of this event. It is unbelievable how many ideas one can get by visiting presentations, talking to other testers and discussing test topics. I cannot describe everything, but I tried to write a personal note of these days. What did I learn during these days?
So this list is only a part of all the things I’ve learned, but they give some ideas that you maybe could use too.

Port in the Centre of Potsdam City

I’ve been present on the first three days of this four day testevent. This posting in three parts is about the 2nd and 3rd day. The first day I visited the workshop of Michael Bolton: “Critical thinking skills for testers”, which gave me even more to think about. But that workshop is not mentioned below.

In general
Some topics returned a few times which I would like to point out:

• What is a good tester? Do you think you have enough experience to say that for yourself?
• How can you help other testers to improve their testing skills? Making mistakes and learning by doing that is one way.
• The IT world changes a lot at this moment and so is testing. Agile is taking over and is maybe a first step towards a different way of developing software. Testers should keep up with all these new trends, because there are a lot of challenges coming our way!
• Don’t think in groups like: “we testers”, “you developers”. We are all developers and we have the same goal as the organization we’re in. We should know the business goals (why) of the organization when we work on a project.
• The standard way of presenting, bullets with text on Powerpoint is on his way back. I’ve seen Prezi, mindmaps and presentations consisting only out of bad drawn, but effective pictures. Michael Bolton also did an experiment with his presentation I understand. I did not see it myself alas.

Presentation via a mindmap (Stevan Zivanovic)

Next posting later this week.

Follow me on Twitter to get updated or add yourself to my Newsletter.
You could also check out my Testevents website! (There is a testevents newsletter too there)

Did you miss the Agile Testing Days and you live in The Netherlands, please check this out on the 6th of December VX company does a summary for you.

Testnetwerk Noord - Testers uit het Noorden.

Ik was uitgenodigd door de firma SevenStars om naar een avond te komen en hier naar een presentatie te luisteren over testen. Deze presentatie werd gegeven in het kantoor van SevenStars te Zwolle. De presentatie werd gegeven door Pieter de Boer van het bedrijf SeederDeBoer en ging over de toekomst van het testen. (Hierbij nog een bedankje aan SevenStars voor de uitnodiging.)

Toen ik het kantoor van Sevenstars binnenkwam stond er een bord die mij de weg wees naar de juiste plek in het gebouw.

Hmm, Testnetwerk Noord? Dat was ik wel eens eerder tegengekomen. Er was één of twee maanden geleden een testevenement voorbij gekomen met dezelfde naam. Uiteindelijk was deze niet door gegaan. Maar dan nu toch een avond met dit "Testnetwerk Noord".

Er zijn best wel aardig wat testers daar boven in het Noorden. De volgeboekte jaarlijkse NoorderTest evenementen geven hier al een aardige indruk van. En dit zijn dan alleen nog maar testers die bij de overheid werkzaam zijn. Er zijn al diverse malen ideeën ontstaan om Testnet evenementen ook in het Noorden te houden. Het is toch wel ver rijden van Groningen of Friesland naar Utrecht.

Maar goed, dit gaat weer om een andere groep. Een man of 25 heeft naar de presentatie zitten luisteren en door de goede vragen werd de presentatie een min of meer interactieve sessie. Ik ga niet verder in op deze presentatie, gezien dit stuk gaat over mijn indruk van deze groep testers (en de avond). En een blog over de toekomst van testen komt misschien nog...

Ik begreep later van de gesprekken dat men sinds maart dit jaar bezig is en geregeld samen komt om kennis te delen en te netwerken. Men heeft drie regels waaraan je moet voldoen om je bij de groep te volgen:

• Je komt uit het Noorden of werkt daar
• Je ben zelfstandig tester (ZZP, freelancer, eigen test bedrijf)
• Je komt zelf, niet een account manager of zo.

Dat zijn mooie regels... Maar wacht eens even? Deze groep van (ongeveer) 30 personen, allemaal zelfstandige testers? Ik wist niet eens dat er zoveel zelfstandige testers in Nederland waren! Je leert elke keer weer bij. De mensen in deze groep spraken elkaar allemaal aan bij de voornaam en waren ook zeer geïnteresseerd in het nieuwe gezicht wat er die avond was. Ik heb echt een paar interessante gesprekken gehad.

Wil je meer weten van deze groep?
Men heeft een website (in aanbouw) - Klik hier
En er is een Linkedin Groep - Klik hier

Goed om te weten dat dit soort initiatieven bestaan en de testwereld nog steeds groeiend is in testprofessionals. Wil je ook een keer langskomen op een bijeenkomst? Dan zal je dit via een ander lid moeten aangeven. Dat kan dus ook via mij vanaf nu. Misschien tot ziens dan op een Testnetwerk avond!

Bevindingen op de Chickenwings pen...

En dit is hem dan! De coole Chickenwings Test Consultancy pen:

Maarrrr... Is deze echt zo goed als je zou denken?

Bevindingen
Ik heb hem getest en ik kwam de volgende bevindingen tegen:

1. De bovenkant is erg zwak en het puntje kan je makkelijk afbreken als je niet uitkijk.
2. Er op kauwen is niet echt gezond, het zilverkleurtje komt er wel erg makkelijk af. Het is nog Chinees plastic ook, dus je weet niet wat er in zit.
3. Het inktpatroon wat er in zit is wel erg dun en kort, je zit binnen no-time zonder inkt.
4. Als je op het houdertje gaat staan, gaat dit stuk (met dank aan een collega)
5. De punt komt erg snel los en blijft dan wat 'lossig' zitten
6. Meenemen in het vliegtuig zou ik niet durven, lijkt teveel op een mes
7. Het zou op een veer moeten lijken, maar veel mensen zien dat niet gelijk

Dus eigenlijk een waardeloos ding, die Chickenwings pen. :-(

Zo zou ik ook je zelf gemaakte software product zeer makkelijk kunnen afkraken natuurlijk. Want ik ben tester en heb op alles wel wat te melden.

Waarom is deze pen nu eigenlijk zo cool en zijn de bevindingen onterecht?

1. Design is mooi, een (kippen)veer pen in een houder, net als vroeger, maar dan modern vorm gegeven.
2. Hij schrijft eigenlijk wel lekker (vergelijkend warenonderzoek gedaan)
3. Het logo staat er ook mooi op gedrukt en valt goed op.
4. Het is een opvalled verschijnsel op een bureau

Het doel van de pen was om een aardigheidje te hebben voor kennissen, (oud) collega's en zakenrelaties. Het moest apart zijn en toch een beetje op de naam van mijn bedrijf slaan.

Ik heb er niet veel voor betaald, immers het blijft een relatie geschenkje. Niet op kauwen en niet het puntje tussen je keyboard proberen te breken. Hij is niet van metaal, dus dat meenemen in een vliegtuig zal wel meevallen.

Dus waar zat de tester fout met zijn bevindingen?
Het doel is niet om een boek te schrijven met deze pen. De pen belandt bij IT'ers over het algemeen, dus zal het toch niet zo vaak gebruikt worden.

Dus dan kan je wel 100 bevindingen hebben over alles, maar de kwaliteiten die ik zocht, als belangrijkste belanghebbende van dit product, die zitten erin. (goede kwaliteit - geld verhouding)

En dan de koppeling naar software testen
Programmeurs beginnen al te bouwen voordat ze hebben nagedacht, klusjes mannen (en vrouwen) willen ook nog wel eens zonder tekening beginnen met hun klus. Testers beginnen vaak met testen voordat ze het doel van het product kennen. Eerst nadenken, dan pas acteren. Dat scheelt weer een hoop onzin bevindingen waar toch niemand wat mee doet.

Een volwassen IT organisatie verwacht dat de tester met de juiste bevindingen komt. Sterker nog: als er vertrouwen is in de tester dan kan het zijn dat programmeurs jouw beelden overnemen en gaan denken dat wat je meldt (zonder navraag en nadenken) de belangrijke bevindingen zijn. Alles is opgelost, dus nu is het goed!

Twijfel je of een bevinding wel écht de juiste is? Je kunt hem altijd registreren, maar bespreek wel eerst of dit nu wel echt zo belangrijk is.

Interessante weblinks voor testers die verder willen leren.

Het komt toch vaak genoeg voor: Ik zit achter een computer en praat met een andere tester over het testvak. Of met iemand die geïnteresseerd is in testen en er wat meer van af wil weten. Internet is hierbij een goed hulpmiddel om mensen te verwijzen. En in deze tijden al helemaal omdat het internet nu overal verkrijgbaar is. Naast de normale computer op je werk, thuis of in een hotel kan je op tablets zoals de iPad, of je telefoon ook het internet op. Mobiele kennis waar we gebruik van moeten maken.

Nu ik dit een paar keer heb meegemaakt: "Kijk eens hier, kijk eens daar...", dacht ik om een paar links maar eens te vermelden in deze blog.

Ik wil wel wat meer leren over testen, waar kan ik dan het beste terecht?
Daarop is mijn antwoord op dit moment: Ga naar http://www.testingeducation.org/BBST/index.html
Daar vind je een gratis testopleiding die gemaakt is door Cem Kaner en James Bach. Dit zijn twee van "de groten der testaarde". De testopleiding is volledig up-to-date en bevat zoveel informatie en oefeningen dat je door dit te bestuderen en te oefenen een geweldige basis neerzet voor jezelf. Ook ik ben weer begonnen (en nu wat serieuzer dan vorige keer) om deze lessen te volgen. Ik heb aardig wat gelezen over testen, maar het doornemen van deze lezingen heeft mij toch weer nieuwe inzichten gegeven en mijn kennis ververst en verbreed.

Nog meer te leren?
Ga naar testevenementen in je buurt, of als je van reizen houdt, ga naar het buitenland en koppel het aan je vakantie vast. Testevenementen en andere IT evenementen kunnen best wel prijzig zijn, maar er zijn ook veel gratis evenementen te vinden in je buurt. Ga voor een overzicht naar www.testevents.com

Testen oefenen?
Op je werk kan je veel leren, maar vaak wordt je daar beperkt in de tijd, omdat het dagelijkse werk ook door moet gaan. 's Avonds en in het weekend kan je je testvaardigheden ook oefenen. Voor de gedreven tester daarom: Testen oefenen én geld verdienen om je extra te motiveren. Hiervoor kan je naar de website http://www.utest.com/. Hier krijg je geld voor het uitvoeren van testgevallen en het vinden van bugs. Leren en verdienen tegelijk dus! Een vergelijkbare (vrij nieuwe) site is http://99tests.com/. Deze heb ik zelf nog niet bezocht, maar is vergelijkbaar met Utest.

Samen met andere testers over de wereld testen?
Via www.weekendtesting.com kan je samen met andere testers in de wereld een programma of product testen. Na de test worden de diverse aanpakken van de testers doorgesproken en ook geplaatst op de site. 

Een paar voorbeelden.
Dit zijn een paar voorbeelden van websites waar ik tegenwoordig mee begin als ik het over internet heb. Ik kan natuurlijk ook verwijzen naar www.twitter.com en je aanraden om daar testers te gaan volgen. Als iemand een blog schrijft zal hij of zij dat via Twitter vaak bekend maken. Ook kan je daar heel gemakkelijk vragen stellen die je hebt over testen en je krijgt bijna altijd wel antwoord.

Ik verwijs dus niet naar websites die veel informatie bevatten door middel van artikelen of andere gedocumenteerd materiaal. Dit valt mij op als ik dit zo schrijf. Eerder dus naar websites met interactiviteit en de mogelijkheid om heen en weer te communiceren. Boeken en artikelen lezen is ook goed, maar om te motiveren om te leren zijn deze genoemde zaken wat mij betreft een stuk doeltreffender en zal je nog sneller een "top tester" maken.

Geen lange lijsten van links in dit stuk dus. Met bovenstaande kan je al een heel jaartje vullen. Veel test en leerplezier!

Testpromotie tip 18 & 19 met betrekking tot managers

Testpromotie tip 18 en 19: eigenlijk bedoeld voor managers

• Tip 18: Leg de focus op het proces niet het product, er moet iemand op het proces letten, ook het testproces.
• Tip 19: Elke stap in het proces zou een stuk test moeten bevatten, niet alleen op het einde.

Vaak kom ik managers tegen die écht betrokken zijn bij het product. Hij of zij is vaak de initator om een product te maken, heeft het idee gekregen om iets te gaan doen. Een zak geld en een agenda met tijd en een kudde mensen om te beginnen met niets tot er een eindproduct is.

Misschien ga ik hier buiten mijn boekje? Deze twee tips staan vaak buiten de beïnvloeding mogelijkheden van een tester. Maar het gaat zowel over business managers als testmanagers, dus blijft het wel in de goede richting.

Ach, nu ik dit toch al heb meegenomen als test tip in mijn lijst van 29 tips om testen te promoten, toch een uitwerking. En wellicht kan je dit als tester helpen om dit ook vanuit dit perspectief te bekijken en te gebruiken in discussie met je manager en leidinggevenden.

Wat ik hier vertel overigens, is niet nieuw en komt zelfs steeds meer naar voren in bijvoorbeeld agile projectmethodieken. Bij scrum bijvoorbeeld is de projectmanager niet meer iemand die volledig aan het stuur staat, maar begeleidt het team en zorgt dat problemen opgelost worden die de voortgang beletten.

Leg de focus op het proces niet het product, er moet iemand op het proces letten, ook het testproces.

Tijd, geld en flink wat zweet gebruikt om een idee uit te werken? Dan zou je wel gek zijn als je niet goed in de gaten houdt of het product nu ook uiteindelijk wordt wat het zou moeten zijn. Voldoet het product aan de wensen. Maar je hebt waarschijnlijk het werk om het product zo goed mogelijk te beschrijven, te bouwen en te testen allemaal gedelegeerd naar mensen in een project team.

Laat deze mensen hun werk doen en zorg ervoor als manager dat je zelf in de gaten houdt dat het project op de goede volgorde plaatsvindt. Dit is het belangrijkste werk van de manager. Vaak zie je dat er al gebouwd wordt, voordat een product wordt besproken met de technische mensen. Documentatie komt later wel.

Testen doen we op het einde, het liefst een dag voordat we live gaan met het product. Aan u de taak om er voor te zorgen dat mensen eerst nadenken, samen bespreken wat het wordt, terugkoppeling geven aan de eindgebruiker. En dan pas gaan bouwen en er voor zorgen dat in het gehele proces een kwaliteit controle plaatsvindt. Als een team niet op zo´n manier wordt begeleidt, dan ontstaat er al gauw een ad/hoc ontwikkelproces, waar het moeilijk wordt om de kwaliteit te bewaken. Wil je zelf mee testen met een eindproduct? Prima, maar het sturen van het project gaat over de volgorde en de communicatie, doen we de goede dingen op het juiste moment.

Elke stap in het proces zou een stuk test moeten bevatten, niet alleen op het einde.
En dan is de volgende stap: testen in elk onderdeel van het project. Projectplan gemaakt? Heeft iedere discipline mee gekeken of de planning voldoende is? Testen wordt vaak onderschat als activiteit en krijgt aan het begin van een project te weinig tijd voor het werk wat men moet doen. Ontwerpen aan het schrijven? Review sessies doen wonderen. Dit is ook een vorm van testen. (!)

Aan het programmeren? Code reviews en unit testen in deze fase helpt om de kwaliteit hoog te houden en al veel ellende uit het product te halen die anders pas later wordt gevonden. Je zou ook kunnen denken aan een soort van Test Driven Development, waar eerst de tests worden geschreven (automatische tests of handmatig) en daarna pas de code wordt geschreven voor een stuk functionaliteit.

Testen met gebruikers: Deze kunnen ook eerder worden betrokken, zodat "gebruikersfouten" straks minder gaan voorkomen en de acceptatie van de software 'op het einde' een grotere kans heeft van slagen.

Alleen testen uitvoeren is geen vangnet voor kwaliteit.

Als testen wordt ondersteund door de manager, niet alleen door geld en tijd te geven aan testers, maar tevens wordt benadrukt dat een ontwerp van goede kwaliteit moet zijn. Er zou constante terugkoppeling moeten zijn van de inhoud van ontwerpen naar de gebruiker. En als er tijdens het ontwikkelproces een gestructureerde manier van werken is (= iedereen werkt samen volgens vastgestelde afspraken en communiceert op een heldere manier en werkt op de juiste volgorde, ...). Dan wordt het testen in ieder geval meer een vangnet voor het gehele team en hoef je als manager je niet zwaar druk te maken over de kwaliteit van je net nieuwe product. Om dit voor elkaar te brengen hebben we in het ontwikkelteam de manager echt nodig.