Purpose (Dis)Solved

This is Manual Locker 🙂 . He takes 2 to 3 seconds to lock and almost the same time to unlock. Once you pull him to left you can clearly see that he has locked the door and you feel very secure. Purpose Solved

And this is hi-fi one click automation locker 🙂 this guy needs just one click to lock. But do you ever feel secure after using this lock? At least I am not. I always test this lock first by locking it with doors kept open and try to open it from outside to make sure the lock works 😀

The same is true with manual and automation testing. How many of us feel comfortable after the so called automation scripts run and say the script passed?

What other benefits does  automation lock provides than manual lock? I don’t think anything great in this context.

Both the locks solve the same purpose with no added benefits by automation. Yes, it may save 1 to 2 seconds, but considering the resources and time invested to design and manufacture the automation lock, was it worth investing? I doubt

Not convinced? Read further to know what happens if automation lock fails miserably. One sad day my friend got stuck inside bathroom for close to one hour when the critical spring inside the lock broke. So there was no option other than breaking the lock to release him :D. Purpose dissolved

Ok, now take a look at the amount of resource wasted. Also wondering how much time  wasted to design such a fancy lock. At the same time the manual lock is very simple, uses less resource, simple design and solves the desired purpose neatly.

This is how automation testing done at most places, if your manual testing solves the purpose what is the need for automation testing?

Phew! Here are the reasons to do such fancy automation

  1. Attract the client by projecting automation
  2. Attract testers by show-casing automation projects (testers are blindly believing it)
  3. Resource utilization, if there is not much testing due to delay in development put them in automation
  4. “Succumbing to The Golden Elephant Syndrome: James Bach calls one of the terrible pathologies of testing. A white elephant may be a big, useless thing, but if it’s made of gold and costs a lot of money, it’s tempting to some people to try to use it anyway. Expensive tools can cause a lot of trouble if they are badly designed and unreliable. If such a tool were cheap, we wouldn’t hesitate to throw it away. But if it’s expensive, the person who bought it doesn’t want to look like a fool-and thus becomes a bigger fool “ – this is an extract from Perfect Software:And Other Illusions about Testing

Think again!

Instead, why don’t we allow the testers to explore, question the product, so they might uncover some critical bugs, which client might discover later. Such exploration might bring in new ideas, suggestions and enhancements to the product that might help to better your competitors. Encourage testers to improve their critical thinking and analytical skill .Conduct bug battles and encourage them to write articles, blogs at least within the organization.

From my experience everywhere regression automation is a fancy way to attract clients. For instance if you goal is to reach the top floor you may take elevator instead of staircase, so you reach quicker. But at most place goal is to walk but most try to use elevator to solve the purpose.

Think Again!

I can’t conclude any automation article without referring Jonathan Kohl’s  “Test automation shouldn’t be a goal; test automation helps you achieve goals” . Read More Here

If you really want to achieve something out of automation read below articles first



Note : Read this relevant and a wonderful post by Umesh Gobinath about User experience and usability here



24 thoughts on “Purpose (Dis)Solved

  1. Hi D.S,
    Nice post & a wonderful Analogy indeed , its seems you eat ,sleep & walk Testing, that’s great :))

    Keep it up!


    1. Jassi,
      Thanks for your comments, If you look few of my posts like this one and Be Prepared , Focus on Defousing, I Hesitate to Hesitate are my personal experiences that helped me to learn a lot and became a better individuals,not just tester. So I am happy sharing them,I am a tester so just used them as analogy to testing.
      I disagree eat testing, I don’t test I taste while eating, I am a Proud Foodie 😀 . I enjoy walking and sleeping too, so testing there as well 🙂 .Other than those I test everything.
      –Dhanasekar S

  2. Hi Dhanasekar,

    what a great example you have used to describe the pitfall of automation 🙂
    all of the reference you have mentioned about test automation are also great.

    thanks for this utilitarian post, keep rocking!!


    1. Thank You Selim for your comments. These words by Kohl ” “Test automation shouldn’t be a goal; test automation helps you achieve goals””made me to realize how automation should be used. If we keep that in mind I think we would build practically feasible automation solutions. Here are some more of my articles, that has reference to great automation articles.
      https://testingideas.wordpress.com/2008/08/09/getting-started-with-automation-testing/ and https://testingideas.wordpress.com/2008/08/12/what-is-a-framework-in-automation/
      –Dhanasekar S

  3. Good Post Dhanasekar.
    I liked the way you built the comparitive and questioned the usefulness of so called ‘automation’ ….and directed towards some good posts.


  4. Hey,

    Great post. I like the analogy.

    But as a tester I have to critique;-)
    Have another look at that paragraph with the elevator and the stairs. Sentence structure is a bit off making it hard to understand.

    Cheers Oliver

  5. Well said…
    I have seen many managers have big dreams about Automation testing(even proudly saying 100% of our testing is automated).

    You should share this, with may be more data to those “managers” 🙂

    1. @Aravind
      Thanks Aravind for your comments. 100% manual testing it self impossible, I am wondering how 100% automation testing is possible? I know there are people who project 100% automation. I am wondering if that is possible why there are still manual testers? :). Automation can only test expected output against a predefined conditions,so it checking it does not test anything.It can check if some condition is true to some extent. Testing needs sapient,Checking do not. Checks can be automated but not testing. Yea I know it is tough to awake people who pretend sleeping.Such people should understand this sentence first by Kohl “Test automation shouldn’t be a goal; test automation helps you achieve goals”
      Read this post by Michael Bolton if you are interested to know more about Testing Vs Checking http://www.developsense.com/blog/2009/08/testing-vs-checking/
      –Dhanasekar S

  6. Excellent post. This is a good illustrative analogy that could be shown to those outside of testing that are sold on either buying the golden elephant or perpetuating its uselessness.

    1. @Chris
      Thanks for you appreciation. Yea in most places the management is not much aware of the limitations of the automation tool. I believe testers who has good knowledge should help them in making a wise decision for management. As a tester we are the one providing quality related information to the management to take better decision.I believe it is not just by testing the application, as a tester should provide quality related information through out the project life cycle.
      –Dhanasekar S

  7. Hi Dhanasekar,

    This is an excellent thought. You articulation is wonderful with the relavant images.

    Anything which is done manually will always add value. But sometimes automation is also helpful if planned smartly.

    Nice work and keep up good blogging.

    Prem Phulara

    1. @Prem Phulara
      That’s a nice point anything done manually will add value.Yes,automation will not find any additional problems but manual testing will.So we need to use sapience to decide What?When? and How to automate so we get better returns.
      –Dhanasekar S

  8. What a nice way to drive home your point! Indeed, automation should be resorted to for augmenting the testing effort and never to reduce or replace manual testing.

  9. Nice article 🙂 ….like the way u relate testing to real life …

    one benefit of automation lock is that its smooth to hold.
    manual lock gets hard and rusty and can give a cut (like a reminder for Tetanus shot)
    but manual lock lasts and serves its purpose without training [u kind of figure it out how to lock ]…
    but in case of automation lock the first time user should know that he/she has to press on the button to lock , otherwise it just closes the door doesn’t really lock… [it has happened to me the very first time ;D] …
    i have observed that automation locks are used only at places which has to be locked for a few minutes . never seen automation locks for main doors or bedrooms (at-least in India)…
    so its safer to do automation at less critical areas 🙂

    1. Preethi,
      Your points are very valid,It would be better if we make the manual lock smooth to hold and rust free,that’s what i said in the conclusion instead of putting testers into some useless automation make them better sapient testers and automation should be used in less risk context.
      –Dhanasekar S

    1. Nitin,
      Wow! So happy to see that my post triggered you 🙂 I read through yours that is a real practical way of automating.Please continue sharing such experiences
      –Dhanasekar S

  10. Great)
    – using manual lock you should manually lock door after each “come in iteration”
    – automated lock locks door when you close it instead of you
    – also you can forget lock door manually (=

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s