Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead.

Peter Pan is one of my favourite stories and the title of this post is one of the most iconic phrases to come out of the book.

It's at the beginning of the book when Wendy and Peter are speaking. Peter explains that when the first baby laughed, its laughter fell and broke into a thousand pieces. This big breakup of laughter means that there "ought to be one fairy for every boy and girl". Wendy notices that Peter said should and questions him.
"Ought to be? Isn't there?"
"Every time a child says, 'I don't believe in fairies,' there is a fairy somewhere that falls down dead." Peter replies.

The same can almost be said about testers when a developers don't check their code works. I don't mean a tester will die every time but a small part of their resolve dies everytime. If its not a testers resolve that dies, it may be real people that die. This may sound quite extreme but its not really.

Since the begiing of the Agile movement there has been a great movement to get the quality of software a lot higher. Aside from all the other major benefits of using scrum and XP, people have noticed the quality of software being delivered go up. They have done it by employing things that make the process more effective. Not all of these processes are efficient but they are extremely effective.

Testers resolve only dies when they feel that something could easily have been caught by the developers being effective at their job. Being efficient can lead to bugs because we are trying to develop a feature within a set timeframe which is normally slightly shorter than it should be.  This is not all doom and gloom, there are bugs that testers love to find. Remember the rule for testing that if a test case is good it will find a bug but remember that testers are not there to make sure that you are doing your job properly. They are there to make sure that its fit for purpose!

When developing software always remember that you are killing your testers really slowly  when you are not doing your job properly!

"To die will be an awfully big adventure." Peter Pan 

This is something that every tester, from load tester to functional tester to security tester, loves to do. Make an application fall to it knees because it we managed to find some big hole. Making an application die is an adventure in many many ways. From going through the process of breaking it, to working out the cause of the breakage.


I have just watched Peter Pan for the umpteenth time and it got me thinking about my profession. Treat your testers like you would Peter Pan and they will be a lot more effective in finding those elusive bugs!

Great Expectations

I recently returned from a well deserved holiday with my wife. We went to an area with mountains, mines and sheep (lots of sheep) and while we were there we wanted to get something nice to remember our holiday. The area where we stayed is extremely famous for its mining and thought that a trinket would be an easy find. We were sadly mistaken. We had set our expections and they were not met.

This is something that we all do every day. We have certain expectations that we expect and are expected from us. Working in testing, expections are always high for the quality of work we let through but these expectations come from an age where testers were the gatekeepers. The days where my profession was made up of people trying to get into IT because it was the next big thing.

The main people to have certain unrealistic expectations are our end-users. Or are they just normal expectations? These expectations can mean the difference between a "feature" and a "bug". End-users can spot blatant things that are wrong, like wanting something gorgeous from the mine not just a coaster for my tea. 

Using this analogy in software we would say thats a bug. But when an html editor that doesn't correct really bad html for you when it corrects mildy bad html, is it a bug or just they way it is? I would tend to lean towards the "just they way it is" as long as the editing software didn't crash the browser/computer. That reminds me of a professor at university who had the saying "The rubbish you put into a computer is the rubbish you get out". So trying to make the rubbish that the end-user creates before they do helps create good software.

Out thinking the end-user is something that a tester does naturally...but who is the end-user? Are they customers? They are both internal and external customers and the tester needs keep them both sets happy. External customers are rarely spoken to by the tester. We tend to speak to the Support teams and the Product Owner making sure that they have reasonable expectations. This is because they are very important internal customers to the test team. Spotting the customers of the tester is easy but who are the test team customers of?

I like to think that the test team are the customers of the development team but then in the same breath the development team are customers of the test team. When the developer is the customer of the tester they expect to receive a decent bug report with the error report and a way to recreate the issue. When the tester is the customer of the developer, the tester expects a certain amount of testing to have been completed before it getting to the tester. This is the creation of unit tests and test harnesses to make sure that their code works. If you work in an Agile environment then you should expect that if a developer breaks the build then they need will fix it within a certain time. With Continuous Integration servers when it goes red I expect someone to be looking into the error fairly quickly and then resolve the issue. Maybe I have unrealistic expectations but I like to keep the bar high in that area for the quality of the product.

The approach of treating everyone around you as a customer will hopefully mean that you can set their expectations properly. This will lead to less disappointment and help with the Total Quality Management in the organisation.