Skip to main content

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, 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.


  1. Nice. I was also initially finding it difficult to get a job in IT after completing my masters in computer security. Then one of my friends suggested testing and to be honest that had changed my life completely in a good way. I have had very similar experiences to what you have shared here!

  2. Looks like the writer has put a lot of hard work into this.

  3. My wife and i were quite peaceful when my son managed to finish up his basic research through the precious recommendations he was given out of the web pages. It is now and again perplexing just to always be giving away instructions which other folks have been making money from. We really remember we need you to give thanks to for this. The illustrations you have made, the straightforward blog navigation, the friendships your site help engender - it's got most unbelievable, and it's really leading our son in addition to us feel that this situation is cool, and that's extraordinarily important. Thanks for the whole thing!
    outsource seo services


Post a Comment

Popular posts from this blog

Advantages of using Test Management tools

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager...
In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools.
Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block. 
One of the more popular tools is that of Microsoft Test Manager, it's big…

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 

By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

        public static void AfterTestRun()
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))

        private s…