Delusions of Testing

So I've got in touch with my old QA friend, Richard Lee and we spoke about guest blogging on each others blogs...

Richard is an IT Professional for a FinTech based company in London. His activities vary from Release Manager, Build Manager, Database Administrator. Working in a Microsoft workshop, his expertise lies in MSBuild/Workflow/Powershell/SSAS/SSIS/SSRS/SQL, basically whatever isn’t anyone elses’ problem is Richard's problem!

When not solving other peoples problems he can be found blogging at redphoenix.me, and jogging to and from home, where he lives with his heavily pregnant wife.

Hello, my name is Richard, and I am a former tester. Like most people and their careers, I fell into testing; I first got into testing about 6 years ago, after I had graduated. I went to a university where the attitude was that you should try to get on a graduate scheme with one of the big companies. If you weren’t interested in that, well, good luck with getting any support from the university to helping you find a job. So after my graduation I posted my CV on all manner of recruitment sites and after a time I got a phone call for a job. I didn’t apply for the job, but I was deemed 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. It was at this company that I met Gareth, the owner of this here blog. And though we both now no longer work in the same company we have kept in touch, and funnily enough started our blogs at roughly the same time completely independent of one another. 

You may notice that I referred to myself as a former tester. And whilst factually accurate, it is not the truth. The truth of the matter is that I am a failed tester. I wasn’t cut out for it. I was OK, but I lacked the skills required to be a good tester. I’m not going to list what makes a good tester because, a) I don’t know and b) if I knew I’d probably still be a tester now. 

Testers get a poor deal though: 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. 

The actual job of testing is also challenging; basically, as a tester, you have to take someone else’s work and find faults with it. You can imagine that this can be pretty galling; a dev is, like a tester, a hard working professional who takes pride in his work. And to have someone else who, in all likelihood could not do any better, find fault with it is going to damage the ego. But the crux of the matter here is that the dev could not do the testers job either. I said earlier that I don’t know what makes a good tester, but 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. 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 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 you 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 amongst 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!

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, then 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 can be 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, and if you were to show how these can run to a database dev, they would be only too happy to support you, unless they’re a jerk.

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

So for that last one, you may have to go speak to your build manager. If they’re not a jerk, 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. 

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. And the change has to come from you.