Essential Software Testing Tools Blog

With a couple of developers out on holiday last week I had a less senior developer come to me and ask if it is okay to release a build to the software test team without going though the formal build process. So the release would be a build compiled on his local machine with no formal release identifier and no release notes. His argument was that this would enable him to release to the test team earlier.

On the face of it this was quite a compelling argument because we were behind schedule on this project and the test team needed this release urgently for regression testing. I was tempted to take the bait and speed things up.

Experience has taught me though, that you’ve got to be slightly deluded if you think taking an informal release is going to speed things up over the long term.

Firstly, you open yourself up to lots of little issue to manage as you start to work with the release. What build number should you use when you raise a bug? Where should another developer get this build from when trying to recreate a bug? Whilst these issues may seem small on the surface they can take up an inordinate amount of accumulated time for your team to resolve. Each one small in isolation but over a period of days and weeks it soon builds up to a significant amount of time. Usually more time than it would have taken for the developer to create a formal release in the first place.

Secondly, and more importantly, once you’ve started down this road its very difficult to get back to the days where you had a well defined and adhered to build delivery process. Once you’ve started down this road every time things are slightly behind schedule the development team will assume that it is acceptable to repeat the informal release process. One informal release in the process can cause a problem but 2, 3 or more informal release is certainly going to get you unstuck.

So the first piece of advice is, what ever you do don’t accept an informal release from the development to test. No arguments, no discussion or any consideration. Just don’t take an informal release. The second piece of advice is that working with teams where the build process is automated makes even the idea of informal releases redundant.

I learnt a very important lesson very early in my software testing career.

Every now and again I do something which, with hindsight, seems like a really stupid thing to do. Take this example. I was purchasing an e-book on line where the payment page had an orange square box with the text “Click here to purchase” written on it.

I spent just over a minute trying to figure out where to click to make the payment. And yes that does seem stupid with hindsight considering there was an orange box with the text “Click here to purchase” displayed. So why did I find this so difficult?

Well firstly, like most people on the Internet, I scan hundreds of pages a day of web text, so I do just that …. i scan rather than read in detail. I wasn’t looking for the text “click here”, I was looking for a button to click.

Secondly, the orange square box with text in it didn’t react to the cursor changing shape when you put the mouse cursor over it. The designer had missed a fundamental principal of the Internet; the cursor shape should change to indicate the item can be clicked.

Thirdly, the orange box was embedded with lots of other images surrounding it, making it difficult to pick out from the crowd. In short this item, that they wanted me to click in order to make the purchase, was so far removed from any other ‘click here’ standard on the Internet that I completely missed it.

So how does this relate to one of the first software testing lessons I learnt. Well my reasoning is as follows.

Sometimes a software test I do may seem stupid on the face of it. However there are a lot of other ’stupid’ people out there with a similar level of intellect to me. So if I’m making the mistake you can guarantee that a lot more people are making exactly the same mistake.

This would tend to suggest that it doesn’t matter how stupid you think you’ve been when testing a piece of software, if you made the mistake you can guarantee that there will be hundreds if not thousands of people out there that will make that exact same mistake. So don’t let it go. Get someone to fix it!