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.