Jul 27, 2011

Excuse #3 - Isn't it QA's job to test my code?

Sorry for the delay in publishing this one guys, had been busy, but finally - the 3rd excuse of the "Testing: Why Bother?" series is finally up.

So... We are going to address an excuse that is a bit less commonly asked out loud, but I think many of us programmers secretly think it without even knowing.

I assume you stumbled at least once before across arguments like:
  • "Well... I could write a test for this, but QA has to perform some heavy testing on this feature anyhow, so why bother?"
  • "I don't have the environment I need to run a test for this right now, and QA have their own testing environment, it would be much more cost-effective to just leave the job of testing this to them"
  • "Our QA guys are not doing anything right now anyhow... We are on a lot of pressure and have tons of new features to implement before deadline - why not speed up things a bit by skipping the testing part and leaving it to QA?"
Well, I must admit these are all thoughts that ran through my head at least once or twice.
Here are some of my key points on what I've come to learn from my experience with other programmers and even myself cutting corners about testing the code because we're on a hurry and "QA are going to test it anyhow":

The Longer you wait testing the code - the harder it is to fix it

There are different types of ways collaborating between development and QA teams.
I've seen many kinds of ways, but I think they generally fall into the following 2 categories:

  1. Dev and QA teams are working separately, on separate iterations. For example: the dev team are working for 2 weeks on the current release candidate, releasing it to QA, and start working on the next iteration. When QA guys find a bug with the last released version, they report it to the dev guys, and the latter have to decide if they are going to fix it for the upcoming version or not.
    When there's a release candidate QA feels is stable enough - it's being released to customer.
  2. There is only one team, made of both QA and dev personnel. Each iteration, the dev guys are working on a small feature, and as soon as they are done with it, 
Now, of course the 2nd option is more "agile", and I personally prefer it, but that's not the issue here. What I want to say - is that if you wait until the QA guys kick in until you get feedback on your feature and know if it works well. This time arrives at least after you decide you're done with the current feature in the better scenario (#2), or might even wait until the end of the iteration (#1), which might be weeks away.

That's awful. Because when the bug will be opened, you already forgot about what you did, how the code exactly work, and you are already keen on finishing the development of the next feature in the list.

If instead you have written a unit test for the feature during (or before) implementing it, you would have a much easier time fixing the bugs that were found.

Every bug might be hiding a long list of more complex ones!
When you release your product with a kind of a "blocker" bug, like a bug in installation or a crash in the beginning of the application, you are blocking the ability of QA to reach the really interesting bugs of your application.

This means that until you fix your installation bug, QA can pretty much go to the beach and catch some sun! So much for efficiency and maximizing productivity. 

If you make sure to heavily test those critical part of the application that will block the ability to use it at all, you avoid these evil scenarios.

Help The QA team focus on what they're good at
Related to the previous point...

As I see it, QA are very important even if you have 100% code coverage in your unit tests. They help you find the nasty bug that you would have never thought of testing automatically, like "your application crashes when I'm running it on Windows 2008 R2 SP1 when the USB dongle was plugged in before you disable the video camera", and additionally - they provide a more user oriented point of view developers sometimes lack.

If you keep the QA team busy with recreating bugs of basic functionality you could have easily found with a simple unit test, you are not taking full advantage of their services.

Collaborate with QA for gain of both sides
This is an important tip, especially if you feel that the pressure on development while QA have some slack.

Something you CAN do, is use QA for assistance while writing your code. You can pair with them while writing the unit tests, and even the code itself. This way - development gains the QA point of view of what their code should do and what to test for, and the QA gains the better understanding of the code and the ability to spot weaknesses in it.

Also, QA usually have a list of tests they run for each build before declaring it a stable product. When you write along with the QA guys automation for some of these tests, and include it in the test suite that runs after every build, you save them the effort and increase confidence of both sides with the stability of the product.

To sum things up
Leaving all the testing to QA will NOT save you time. It will either cause you to delay your deadlines, or simply cause you to release low quality products.

More posts in the series are coming, and some new content!
You should subscribe to this blog and follow me on twitter.


  1. nice post dude!! +1

  2. Very true.
    One of my former managers told me that the worst thing for product quality was introducing QA, because it made the programmers lazy.
    To a great extent I agree, only now I understand that the real blame was on the process, not on the persons.
    The same, BTW, goes to designers and architects - they may make lazy developers and testers, if they let them deal with coding and testing only, keeping the understanding the business behind it to themselves.

  3. Most of the QA teams in organizations suck. We laid off 10 QA folks in our org.
    Developers are not lazy. QA just clicks a few screens. Developers do far more than that.

  4. )wonderful information, I had come to know about your blog from my friend nandu , hyderabad,i have read atleast 7 posts of yours by now, and let me tell you, your website gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a ton once again, Regards, QA online trainingamong the QA in Hyderabad. Classroom Training in Hyderabad India

  5. Nice blog and thank you for the information. Awicon Technologies automation is a strong proponent of eco-friendly home automation systems which includes door locks, theater and security systems in Hyderabad.
    Home Automation in Hyderabad

  6. Thanks for Information Quality Assurance is the systematic process to check whether the product developed from the company is perfect and meeting the requirements specified for the product. This Quality Assurance was introduced in World War II when the weapons used were inspected and tested after manufacturing, but now the situation have changed and every company is following the advanced technologies for quality and most of the companies will have a separate department for the Quality testing.QA Online Training

  7. Nice article and explanation is good,Thank you for sharing your experience on oracle Scan.you have clearly explained about the process thus it is very much interesting and i got more information from your blog.
    Oracle Fusion SCM Training in Hyderabad

  8. nice post keep on posting thanks for sharing this kind of blogs if like to read more visit it https://snowflakemasters.in/

  9. Very much informative blog post.

  10. The new XMLTV electronic program guide is compatible with a wide range of IPTV providers, including both free and paid services. This makes it easy for users to find a provider that fits their needs and preferences. Additionally, the guide can be customized to fit the user's specific provider, ensuring that all program information is accurate and up-to-date.