I love Christmas, and I love Christmas films. One of my favourites is “Elf” with Will Ferrell. I know that the world and his wife have seen it, but for those of you that haven’t: The plot revolves around Will Ferrell’s character Buddy coming to terms with the fact that he is not an Elf, but is a human adopted by his Elfish father, played brilliantly by Bob Newhart, and goes on a journey in New York at Christmas time to find his biological dad.

Prior to him discovering he is human, Buddy’s apparent incompetence in the toy-making department sees him transferred from there to the testing department, where the “special” elves go. And this I always felt was a good analogy to how the relationship between testers and developers is seen in the IT Industry.

I am a former software tester. Like most people and their careers, I fell into it; I first got into testing just after I had graduated from university with a degree in computer science. I went to a university where the attitude was that you should try to get on a graduate scheme with one of the “top” companies, and work there until retirement. If you weren’t interested in that, well, good luck with getting any support from the university to helping you find a job. And I always viewed graduation schemes as finishing schools for people who had gone through the motions of education rather than actually loving what they do, and I knew I wasn’t one of those people.

So after my graduation I was left floundering trying to get a job. So I posted my CV on all manner of recruitment sites. After a time I got a phone call for a job as a software tester. I didn’t apply for the job, but the company felt I was a suitable candidate because I lived near the office and I had a degree in Computer Science. I deemed testing a suitable career because I wanted to get into IT anyway I could because I had been out of university for three months and was starting to get worried about ever getting a job, especially as it looked like the world was about to collapse from the credit crunch.

And so I entered the world of IT as a tester, and very quickly I came to realise how being a software tester was seen in IT (ie really, really poorly.) This view of software testers jarred with me because of two reasons

Testers get a poor deal: Rarely, if ever would you meet a former tester who would refer to himself as a “failed tester”, yet the delusion that all testers who used to be developers are “failed developers” is all too a current delusion that permeates the IT industry.

Above is a genuine Google search!

The actual job of testing is also challenging;  as a tester, you have to take someones work and find faults with it. You can imagine that this can be pretty galling; a developer is, like a tester, a hard working professional who takes pride in his work. And to have someone else find fault with it is going to damage the ego, especially as in all likelihood the tester could not do the developers job! But the crux of the matter here is that the developer could not do the testers job either.

One thing I do know about good testers is that they want to find bugs. They want to find faults. And devs, perhaps under time pressures, tend to think “I’ll come back and tidy that up later” and never do. And if you were to ask what the code coverage was for the unit tests, it would probably be a depressingly small number. At a previous place where I worked, the code coverage by unit tests was less than 20%, and that on average is classed as “not bad”! Imagine if testers had test coverage of 20%, and defended it as “not bad”, you’d be looking for a new job! The fact is developers don’t like testing, so it’s important for testers to pick up that slack as best they can.

Testers also get blamed for bugs in production. Again, the all too familiar delusion that testers are responsible for all bugs is as unpopular among testers as it is false. So when someone next asks the testers why they let a bug into production, there are two responses here that challenge that delusion: • Why did the developers write that bug in the first place? • I didn’t find that bug because I was too busy trying to find bugs that didn’t exist in the first place!

If you ever meet a tester who knows where the bugs are, he’s either written the bug himself without anyone knowing, or is some kind of genius.

Another delusion in testing is that automated testing is the silver bullet. It isn’t. Not by a long shot. If an automated testing process was set up when the product was first developed and serious effort is put into writing automated tests, then maybe you have a chance of creating a mature framework in which to provide automated testing. If however a product has been around for a few years, and you are yet to start automating your tests, it will be so much harder to get a good set of automated tests that provide good coverage. The irony here being is that you are too busy doing regression testing in a mature product to worry about writing an automated test framework that would speed up regression testing and perhaps find more (not all mind) bugs!

Also, whilst senior management are keen to spend thousands on core based licenses for SQL Server Enterprise for their new data warehouse, you’ll find the budget becomes frustratingly scarce where testing tools are required. Fortunately there are plenty of free products that integrate well with automated builds and IDE’s. If you have yet to work on automated testing, pick an area that is easy to work on and does not change much. Say you have a landing page that rarely changes; try to create framework with Selenium that tests that area. Or, if you have an ETL process through the database using SSIS packages, use DBFIT to ensure that the mappings are correct. DBFit provides the system integration tests that are so lacking.

So if you have yet to implement an automated testing framework, do these things: • Identify where the most bugs historically are (UI or other) • Find a free tool that integrates with your environment • Write 2-3 tests, working out of hours (hey, you’ve got to show commitment) • Get them on the build, or running nightly.

So for that last one, you may have to go speak to your build manager. If they’re not an idiot, they’ll help you out.

Getting an automated testing framework up and running will also assist in removing another delusion; testers are not technical. Well, in some cases this is true; how technical do you have to be to click a few buttons to get some items in a basket (another delusion, not my opinion)?! But most automated frameworks, the really useful ones anyway, will require coding to some degree. Sure, if coding was your strong point you’d probably be a dev and you’d suck at writing unit tests, but you’re a tester and writing code probably isn’t your favourite thing. But it’s nothing that some trial and error really can’t help solve, or perhaps asking a dev to help out a bit when you get stuck.

The final delusion I want to talk about is that it doesn’t matter what the tester knows. Devs work at the code level; they need to know how their solutions hang together and how they interact. They need to know the schema design of the databases, and if all the references are correct in the their solutions. In short, devs spend far too much time devving and not enough time at the business level. This is where the testers come in. When a business rule needs to be understood, testers need to be the go to guys in a team to get clarification. BA’s are too busy defining wok items for the next sprint. The testers need to understand everything that is now and everything that came before it.

Coming back full circle to where we started, like Buddy seeing through the fake beard and the stuffing of the fake Santa, you’ll see that the industry wide opinion of testers is nothing but fallacies…

As a failed tester, I know the challenges that testers face on a day to day basis. I also know that it can be a challenge to break an entire industry out of some delusions and see the good that testers do.