I’ve heard many customers say to me “It ain’t real until it’s in CICS“.

Just before Christmas CICS continued its ongoing mission to support every major business programming language since the beginning of time by announcing that PHP has arrived on CICS.

Why am I writing about this on a test blog? Well, I did some of the preliminary system testing and two guys in my team did a cracking job of the rest. So this is another thing that we (as a wider team) are all proud of.

Go ahead and play, but please direct any problems to the other guys in my team

Just been having a chat with a new grad who is working in one of our System Test teams.
We were talking about load, stress and performance testing and I was trying to articulate the reasons behind having a workload with peaks and troughs during the day (in the same way that a customer would) rather than our usual approach to load which is run at a constant high level for a long period. However, I was struggling with a justification as to why this might be a good idea and how it would find a different class of defects.

Then I remembered the ‘Top Gear’ episode when Hammond was trying to drive a Formula 1 car around a track. Apparently F1 cars are designed to go flat out – all the time – and are pretty good at this. What Hammond discovered to his horror was that when you don’t drive them flat out then you can get into all kinds of trouble.  Cornering was a particular problem. Flat out the tyres are warm and stick to the track, the brakes responsive and the down force of the car helps it round. Anything less than flat out and as Hammond found you are all over the place.

So in this case if your system is the car and you only use Lewis Hamilton to test it then there are a lot of defects that will get missed. Fortunately few people drive F1 cars slowly on the road, but this would be a severe problem if the system under test was something like a mini.

So moral of the day, remember for every Lewis Hamilton tester you have you need at least one Hammond.

Two to three years ago I bought a GPS equipped PDA phone. At the time, I justified the extra cost (to myself) as it could do a great deal more than just navigate me from A to B… Until a couple of months ago, it’s been used almost exclusively to run navigation software. By today’s standards, it is quite a bulky device and a little low specification, nevertheless – and much to Ben’s amusement – I’ve been making a lot more use of it recently. So what changed?

Well quite a lot, mobile data has come down in price – my mobile network provider supplied an unlimited data pack to my line for a few extra pounds a month, and there has been a great deal of progress in software designed for mobile devices; for example, many Google applications are now available > http://www.google.com/mobile/ < In addition, a much greater awareness of mobile devices has meant that many more web sites are readable with lower screen resolutions, or have mobile-aware content variations. Naturally I’ve tested this site and on my device it’s readable

So as well as navigating me from A to B, I can check email, review products and even compare prices while out shopping. The integrated GPS means I can perform location specific searches, so no matter where I am, I can find the products or services that I might need (no need to worry about Pickled Onions ever again). I’m already thinking about cool new applications I’d like to see, many of which could be great fun to test.

Over the holidays I got asked, “what makes a good software tester?”. As well as recounting the traditional traits of sheer good looks, athleticism and sophisticated banter, this actually got me thinking back to what we are here to do. Crudely speaking, we are here to find defects. [Note that I don't state "find and fix defects" - as that's a topic for another discussion].

To do this well requires a broad range of character traits – just like our customers have a broad range of approaches to using our software. So when asked if I’d want a tester who takes a very rigorous approach, or one with a much more ad-hoc attitude to testing – I’d happily take both.