TestToTester

Why “For those who think Test Automation is easy, saves time, converts manual tests, etc,”? page element

Me: Why did you add the new page element “For those who think Test Automation is easy, saves time, converts manual tests, etc,”? in your blog?

Me: I have been asked questions like

# I am planning to change my job, which tool shall I learn?
# Will only manual testing experience fetch me a job?
# Shall I learn some scripting language? Will it improve my chances of getting a job?
# What will I say if the interviewer asks “Haven’t you done any automation”?
# Why don’t you automate the program? I have previously seen a test group do that, they run the tests and next day morning they have the results?
# How hard is it to automate? All you have to record it right?
# Let’s build a test framework; it will surely reduce testing time?
# You should not be stuck with manual testing, you should start automating?

And many more, so I felt the papers by legendary test gurus could help us understand “Test Automation” better.

Second reason why I added the new page element would be

When I was answering to a discussion at Test republic, I quoted “During regression testing, if you currently run the same test cases over and over again, go ahead and automate, atleast it shall save time. But, during regression if you hunt for new bugs, note observations, verify the fix doesnot do something it was not supposed to do, then stick to manual (exploratory) testing. Iam sure this would be more challenging and will have better learning.”

Observe the first 2 lines - I made an assumption that automating repeated tests is easy; I also made an assumption that running automated tests will take less time.

Why did I make such an assumption? Well, in one of my previous projects we had written a script in python for build acceptance test. But then the script was not dynamic because we only intend to verify the program at a very high level, to qualify the build for testing.

So, I assumed the same would work here, well it might, but did I consider the other risks? No, did I evaluate the product before suggesting automation? No, did I have enough information before suggesting? No,

I feel this is exactly what is happening in most of the places. We feel we could automate some thing because it worked some where else. The papers listed gave me an insight on the pitfalls, traps I was not aware of, and I hope it helps other testers the same way.

Me: The papers you have posted have been available for public from a very long time (one of them 10 years back); so, how will it help if you post it on your blog?

Me: Good question, the second reason I have quoted happened last week, Pradeep forwarded me the links, which in turn helped me understand Test Automation better. I am trying to do the same.

Me: Well, all the best I hope more people read this learn and understand Test Automation

Me: Thanks:-), I hope more people read this, learn, think, understand Test Automation from legendary tester’s experiences, rather than blindly fall for advertisements.

Disclaimer: All the blogs shared by me are my ideas, my thought, my understanding of the subject and does not represent any of my employer’s ideas, thought, plans or strategies.

Bugs… with a human touch

“Dealing with yesterday’s bugs keeps part of our attention away from today’s bugs” – This statement from http://blogs.msdn.com/james_whittaker/archive/2008/08/11/if-microsoft-is-so-good-at-testing-why-does-your-software-suck.aspx by james whittaker grabbed my attention since I previously remember similar words from one of my manger before.

In today’s software projects I feel bugs are treated humanlike. Last week my colleague asked me “What is the life of a bug?” To which my answer was - the bug is born when you find one in the program under test, the bug is issued a birth-certificate when it’s logged in the bug tracker.

A developer who listened to our conversation expressed to torture it (bug). To which my reply was – the bug might die of a heart attack, or might have a slow death or might live in the dark stomaching your torture, until a day when he breaks loose, forms an army of his own or even better becomes a gladiator and takes down your empire.

My previous manager used to address bugs as – “yesterdays”, “todays” and so on. When bugs were categorized to set priorities, he used to question us “why are you finding yesterday’s bugs?” To which – I had no reply since, yesterday I was not in the project, and I was assigned to the project today.

Today when I read the above statement from James, I wonder are bugs bugs or we have newborns, infants, teenagers, adults, married, divorced, old age, sick, happy, ……, today’s, yesterday’s, tomorrow’s, bugs.

I thought harder what yesterday bug could mean

:-) Does it mean bug in previous version of the program which broke the prison?
:-) Does it mean bug reported by customer when he was just born?
:-) Does it mean bug found after formal release of the product?
:-) Does it mean bug reported by client in previous phase?
:-) Does it mean bug found today which was not unearthed yesterday, but was supposed to be found yesterday?
:-) Does it mean bug in previous version which today is well settled with family and leading a happy life with humans?
:-) Does it mean bug was caught yesterday, but let loose after counseling to wear the seat belt?
:-) Does it mean bug found today is the daughter of yesterday’s bug?

After making the above points I re looked at the quote “Dealing with yesterday’s bugs keeps part of our attention away from today’s bugs” and I felt may be I got carried away what if my mission was “Find today’s bugs”. Well, how do I do it?

Guys please help…

Disclaimer: All the blogs shared by me are my ideas, my thought, my understanding of the subject and does not represent any of my employer’s ideas, thought, plans or strategies.

Test with me @

Tweets