Wednesday 3 March 2010

Does manual testing really lose its value as Companies encouraging more and more automation?


A colleague the other day asked me for my views on the automation/manual debate and asked the following question:


Does manual testing really lose its value as Companies encouraging more and more automation?

I thought this is a very interesting question and decided to blog my response.

I should start by saying I am not split into either camp on the automation vs. manual testing debate. I can see the benefit of both depending on circumstances you are in. If you have an old legacy project in which you are 100% sure nothing will change then automation could be the answer. If you involved in a system in which changes could be made and you want to CHECK that the functionality or the business rule that is in place is still giving the exact same result with no deviation then automation could work.

My thoughts on the question that I was asked (and the title of this article) are completely the opposite. Automation requires no sapience or thinking to be executed, so once the automated checks have been written (which does require sapience) you can run and forget.

The problem is that the world in which we work in is all about changing, adapting and making things better (normally) especially in an agile environment where change is embraced.

I should state that my definition of manual testing is not of following pre scripted tests but of being a test explorer, searching in all the nooks and crannies, trying to discover new and intriguing things about the software. If it is pre scripted then automate it, do not waste good tester intelligence and skill on running a check list, your testers deserve better.

So I would ask the following questions on any company who want to encourage more automation at the expense of manual testing.

  • Is it cost effective to write lots of automated checks compared to carrying out manual exploratory testing?
  • Which method would in the same time period give the most test coverage?
  • Which would be the most easy to adapt to major changes?
  • Which would uncover the most problems or issues?

I feel there is some value in using automation at unit level and build level, continuous integration with acceptance checks is a useful tool for the software tester since it lets them have a early look at changes with some confidence that what they have been given will at least have a chance of working. Sure beats the good old days of rejecting x releases in day because of a typo in an install script or a missing dll from the build.

You hopefully can see that I am not against using automation; however there appears to be a view in the testing world that automation can replace manual testing or make its value less. This view does worry me since if the corporate suits think they can get more value and better quality using automation then the message about the art software testing is not being broadcast well enough.

Manual and automation can co-exist very well together; however:

  • manual testing can exist without automation
  • but automation cannot exist without manual testing.

There is an interesting podcast with Jon Bach and Michael Bolton with their viewpoints on the difference between checking and testing available here:

http://www.quardev.com/blog/2010-02-02-1123487836

3 comments:

  1. Hi John,
    Good post! I have been pondering on a similar blog post - On the lines of automated testing doesn't exist..i.e you can't automate thinking can you?

    I have also found that 'Tool assisted' manual testing to be extremely beneficial however...

    ReplyDelete
  2. Thank you for the comment.

    I do love that term 'Tool assisted' manual testing. I think I may use that in an internal workshop I am running on Exploratory Testing. I will credit you of course :o)

    ReplyDelete
  3. Unfortunately I don't think I can take the credit. I think Cem Kaner has talked about computer-assisted testing for a while, and I'm pretty sure James Bach has aswell.

    ReplyDelete