Chickenwings Test Consultancy

Testing is dead because

2011-12-16T11:42:00.000-08:00

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)

2011-11-22T11:11:00.001-08:00

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)

2011-11-22T11:00:00.001-08:00

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)

2011-11-22T10:48:00.001-08:00

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)

Testnetwerk Noord - Testers uit het Noorden.

2011-10-28T10:59:00.000-07:00

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...

2011-09-19T11:41:00.000-07:00

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:

De bovenkant is erg zwak en het puntje kan je makkelijk afbreken als je niet uitkijk.
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.
Het inktpatroon wat er in zit is wel erg dun en kort, je zit binnen no-time zonder inkt.
Als je op het houdertje gaat staan, gaat dit stuk (met dank aan een collega)
De punt komt erg snel los en blijft dan wat 'lossig' zitten
Meenemen in het vliegtuig zou ik niet durven, lijkt teveel op een mes
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?

Design is mooi, een (kippen)veer pen in een houder, net als vroeger, maar dan modern vorm gegeven.
Hij schrijft eigenlijk wel lekker (vergelijkend warenonderzoek gedaan)
Het logo staat er ook mooi op gedrukt en valt goed op.
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.

2011-07-16T12:03:00.000-07:00

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

2011-06-05T12:07:00.000-07:00

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.

Questioning a simple overview screen.

2011-06-05T03:59:00.000-07:00

New organization, new tester
I have the privilege to coach a new tester in his new job at the current company I'm working for. I know that teaching and coaching other people will sharpen your own mind too, so that's a great benefit. The tester expressed also that he is glad that he can ask me questions about his work and is very keen on learning the trade. With about a year of experience in scripted testing and re-testing defects in big organizations he is now plunged into a small IT department where we started working in an agile way with the scrum method. No pre-written test scripts there. Exploratory testing and using a critical mindset for testing is very important in this environment. New for him, but also for me, as I still am learning everyday about testing as I don't consider myself as "all knowing". Coaching this tester makes me aware though I know a lot about testing already and can really help other testers getting the best out of them. So, on to the actual blog, maybe you could use this in your daily practice.

Testing an overview screen
One change in the product under test was a new overview screen for customers. This screen was made at almost the last day of the sprint (iteration) and was a bit of a surprise because it was not planned. The developers did this in between other functionality. Easy job, no problems, so easy we don't have to test it. The screen was shown to the product owner and he looked at it and said it was OK. Ready.
Ready? Huh? Really?

The tester was relaxed after that and said he had nothing to do anymore for the rest of the day. The demo was given and the sprint was ready, the software is ready for release on Monday.

I asked the tester to show me the screen that had not been tested. In this screen you would see a row of software products, license numbers and the start and end date of the license. It looked something like this: (made an example in Excel)

He had some time left at this Friday afternoon, so he could at least check the screen I thought. The software would be in production after the weekend, so if there is a problem in it, we would be still on time before going to production. So note this: Testing does not always stop after a successful demo.

We looked at the screen and the tester mentioned that he had asked the developer what to test in this screen. Developers did say nothing was testable in this screen. So when he showed me the screen he was staring at it. "It looks OK to me. I don't know what to test here."

Questions to ask
So I spoke my thoughts out loud:

I see a number of columns with data, where is this data coming from?
Can we check if this data is correct by looking at the source?
Why is the name of the software the same for every product in this screen?
How is this screen sorted?
There are 15 rows on the screen, but it says it should show the list by 20 items, are there more items?
How would the screen present 21 items or even more?
The column "License" showed telephone numbers (with an icon), why does it say "License"?
There is a search box at the top, does it work? How does it work?
What if we added items or changed items in the source database or product. Is it shown on this screen after a change?

These were initial thoughts that were reasonably easy for me to think of. For the tester it was a bit of a surprise that he could look at this screen this way. He discussed it with the developers, did some tests, changing the items and got the answers to these questions. The licenses were shown as a phone number because of the Skype software that was presuming these were phone numbers. Changes to the data and more than 20 items worked OK, et cetera.

The only thing not really explainable was the search box. It only searches in the license numbers. Would that be enough for a customer that searches for some software he bought? As it was Friday afternoon we did the "Most people are gone and it is time to get home for a nice weekend" stopping heuristic and went home.

Conclusion
The reason to write this article is to emphasize that if a product doesn't look like there is anything to test, there will be certainly something to test just by asking questions about what you see and make them test ideas to use for a test. Even to check if it really is working as expected.

Does it really work and was it really that easy to program this?
Huh? Some things don't look normal to me? Write down these questions.
Asked the questions to developers or designers. So? It works, but does it really work as expected for the user?

Especially the last point makes an issue out of the search box at the top of the screen. We will ask that on Monday. More questions can be raised, but everybody seemed very happy with this overview and no one did really expect troubles. So a quick test would be enough, just enough to confirm the assumption of working software. This was the first time we saw a new overview screen, so at least we had to do these quick tests.

It is also a measurement for risk: If we found a number of issues in this screen, the next time we would test harder and try to raise more questions. But for now it seemed that it was working properly so the next time we will give it a relative lower risk for testing this. It is also building trust in the team. But as I always say: Trust but verify.

Weekend
Now the urge to quick test this screen is fulfilled and a weekend starts, this screen will be released on Monday and we don't think it will raise a lot of questions for the customer (except maybe the search box).

Het Testnet voorjaarsevenement - Deel 4

2011-05-25T10:13:00.000-07:00

Dit is deel 3 van mijn verhaal over het testnet voorjaarsevenement 2011.
Vind hier: Deel 1, deel 2, deel 3

Eten en de markt
Natuurlijk was er weer een een prima diner neergezet door de organisatie, en kwam niemand wat tekort. De testmarkt met de standjes was voller dan ooit en ik moest écht zoeken naar een stand van een specifieke organisatie. Veel veelzijdigheid en concurrentie dus. Vooral de stand van VX Company viel erg op. Mooi hoor!

Daarnaast waren er weer diverse prijzen te “winnen” door je visitekaartje in te leveren of een potje virtueel te voetballen. En natuurlijk niet te vergeten het traditionele gratis kaartje voor Eurostar.

Boekpresentatie van EclipseIT
Er was een boeklancering van het bedrijf EclipseIT – Het Q-mysterie van Ard Kramer en Hans de Rooij. Eclipse IT heeft ook nog een leuk filmpje gemaakt hierover. Bekijk deze hier: http://www.youtube.com/watch?v=Y1CoDaSgguM&feature=youtu.be

Weer veel mensen ontmoet
Ik heb nog een paar handen geschud van mede – tweeters en daardoor besef je toch dat sociale media nu toch bij de gewone wereld hoort en een zeer krachtig medium is. Het feit dat je elkaar al ‘kent’ voordat je elkaar ontmoet is een zeer aparte ervaring. Niet dat dit vóór de sociale media revolutie al niet gebeurde, maar dit wordt aardig versterkt door de nieuwe technologie.

Met andere woorden
In de ochtend had ik mij toch een beetje verveeld, of was ik gewoon te laat naar bed gegaan? Maar na de eerste presentaties kwamen voor mij toch een aantal hoogtepunten. Met de verrassende presentatie van Joris Meerts (van ritueel naar rationeel handelen) en de zeer interessante presentatie van de mensen van Bartosz. En natuurlijk niet te vergeten een heerlijk betoog van Michael Bolton, had ik alweer genoeg om over na te denken. En het feit dat ik de iPad van QualityHouse heb gewonnen maakt dit helemaal een geweldig evenement voor mij :-)

Nogmaals wil ik Jeroen Rosink nogmaals bedanken om mij even weg te halen van de boekpresentatie van Eclipse IT en mij mee te trekken naar de QualityHouse stand om mijn iPad op te halen. Anders was er iemand anders de gelukkige geweest (ook leuk, maar toch). Als waardering hiervoor heeft hij een mooi boek van de 'oude held' Jerry Weinberg gehad. (of die moet nog binnenkomen op het moment van schrijven denk ik)

Nieuwe Helden

Waar zijn de nieuwe testhelden? Op de podia, of vind je ze eerder op internet, discussiërend via de nieuwe sociale media en via blogs? Schrijft een nieuwe held nog een boek, geeft deze held nog presentaties op testevenementen? Ja, natuurlijk, de nieuwe helden zijn er zeker, dat heeft dit voorjaarsevenement wel laten zien. En bloggen, twitteren, facebook, Linkedin, Yammer... Dat zijn allemaal extra kanalen waardoor men direct naar geïnteresseerden kan communiceren en ook snel antwoord terug kan krijgen. En dan schrijven ze ook nog boeken. Een paar voorbeelden zijn: Het Q-mysterie (Ard Kramer / Hans de Rooij), De held die voor mijn nachtrust zorgt (Gert-Jan de Grood), Testen 2.0 (Anko Tijman / Eric Jimmik). We kunnen vast nog wel meer verwachten op dit vlak.

Niet alleen boeken
Het is de tijd dat je het met het lezen van een boek alleen niet meer redt. De uitgebreide weblogs over testen of zelfs videopresentaties zijn een belangrijke aanvulling op de testliteratuur. En niet alleen nieuwe helden schrijven deze, ook de ‘oude helden’ zijn terug te vinden in dit soort media.Via mijn nieuwsbrief communiceer ik geregeld over interessante weblogs en andere testliteratuur. Via deze link kan je je inschrijven.

Oud en nieuw door elkaar in de huidige tijd. Eigenlijk bestaan er geen oude en nieuwe helden, we doen allemaal ons best om zo goed mogelijk te testen en er zijn testers die ook nog een vorm van idealisme hebben om hun kennis te delen, zodat we niet op eilandjes blijven zitten en deze kennis en inzichten met elkaar kunnen delen. Dit omdat we als testcommunity nog beter willen worden in ons vakgebied.

Andere ideeën?
Zijn de ideeën over testen aan het veranderen? Ik denk het wel. Één eigenschap van een tester is: creativiteit. En we blijven niet stil staan als creatieve individuen, we kijken naar nieuwe mogelijkheden om ons vak te verbeteren. Een veel gehoorde klacht is het gebrek aan- of slechte ontwerpdocumentatie. We vinden nu betere wegen om die documentatie naar boven te halen of te verbeteren. Of zelfs methodes en technieken om zonder documentatie een zo goed mogelijk resultaat te brengen. Het leek de afgelopen jaren wel of we bleven hangen in klagen hierover, maar dat is dus niet zo.

Kan automatisering van testen wel?
Dit is niet behandeld op dit evenement, maar toch even als extra voorbeeld. We zijn als testers lang blijven steken in “Record and Playback” tools lijkt het wel. Maar dat is eigenlijk niet zo. Veel ontwikkelingen gebeuren in de kantoren bij de organisaties zelf, maar door de steeds meer open communicatie komen we erachter dat er veel meers is dan de Record and Playback tooling. Er zijn ondertussen voor veel software oplossingen aparte testtools en we leren hier langzaam maar gestaag mee om te gaan. In juni is er zelfs de eerste Test-automation day in Nederland over de laatste trends in testautomatisering.

Welke nieuwe en oude helden komen ons daar vertellen wat de mogelijkheden zijn?

Bedankt Testnet voor weer een prima evenement!

Dit verhaal is verdeeld in 4 delen: Deel 1, deel 2, deel 3

De presentaties en de foto’s kan je vinden op de Testnet site http://www.testnet.org/
Foto’s zijn met toestemming geplaatst (gemaakt door Rik Marselis)
Sheets uit presentaties zijn met toestemming van de auteurs gepubliceerd.