Automation/Requirements Document/Process/Certification cannot find bugs

Product being tested --- Breath analyser to detect alchohol!!!

Objective of product --- Analyze the air to identify if the person blowing air has had alchohol or not.

What the product did not do --- Analyze if the person being tested has actually blown his air or not.

And the test case --- Get Drunk. totally drunk. get analyzed by the breath analyzer, but don't blow air into the equipment.

And the test case result --- Failed. Since the breath analyzer does not detect if you actually blew air into the equipment or not.

And what's the bug? --- Expected behavior is that the system should detect if the person is blowing air into the equipment or not. Actual behavior is that it does not detect this.

And you won't find this test case in the requirements document; not in boundary value analysis or equivalence method or some such method; no testing certification can help you detect this flaw; no 6 sigma process or CMMi process can help you find this test; and no automation suite can help you prevent it.

In spite of all of the above, this bug has been around in breath analysing equipment for a long long long time. That proves the theory that there are more fake testers than me around :). Anyway, the point I was trying to make was that testing is best left to humans and not to automated suites, or processes, or methodologies. The best tester is still the man, and not the machine!!!

SOPA, wikipedia and black days...

SOPA --- This term is doing the round these days and a lot has been written about it already. Today, wikipedia have termed it a black day for themselves.

I interviewed myself today; the objective was to execute only 1 test case to test implementation of the SOPA act when it gets implemented and try to break it in the 1st try. My test case is listed below:-

Test Case --- Search for a wiki page that has blacklisted material and has been in existence for a few years; confirm that the material is blacklisted on the wiki; Do a google search and visit Google cache and check if that information is available. My guess is that it will be available; (I had posted a blog post 2 years back, deleted it a year and a half back and this post is still visible in Google Cache)

Does that mean that there will be a Google Black Day too with Google users protesting to protect their data, if SOPA were to be implemented? :)

Corporate Lies and Timesheets

All testers have filled timesheets; most people fill out timesheets stating that we work 8 hrs in a day. That is today's biggest lie from the corporates. We all know that it is never ever possible to work exactly for 8 hours 0 mins and 0 seconds; obviously, it would be for sometime more than that or less than that. When questioned, the project manager would cleverly counter that claim stating that he did not work for 8 hours, but that he did 8 hours worth of work on that day; The argument claims that he might have taken sometime more or less, but then the work that he did was work that's worth 8 hours. That becomes the 2nd biggest lie.

If he had the ability to do 8 hrs of work in less than that time, then how could it be 8 hours worth of work? To answer this, the senior project manager would claim the development of components that reduce his working time and improve productivity. And then he would bring in the magic word "automation" to claim that they were able to automate that much amount of time to reduce productivity.

That's the 3rd biggest lie; most automation that's been developed would be screen capture components. The 3rd question is if it reduces the working hours, then why does it not improve billing time and gives the client reduced billing time? To answer that, the client would most probably say that they will reduce billing time, but the tool that's being used is created for intelectual usage and the company has to pay for that tool usage.

And the conversation goes on... The conversation, which started with a focus on quality, ends due to money. In the end, money wins and quality loses!!!

The new year bug. Are you aware of it?

Happy new year everyone. But do you realize that the high severity bug and the workaround in the new year?


Here's the Requirement --- That the people of the world have a time period that they can gather together to celebrate the completion of 1 full cycle of the earth around the sun.

Expected Behavior - That the sun completes 1 full rotation around the earth at 12 PM on Dec 31.

Actual Behavior --- It takes some more time for the sun to complete 1 cycle; that's why we have the leap year.

End result --- All of us accept this bug; we have changed our lifestyle to have the leap year so that we have a life around this bug; and life does not stop, it goes on.

Most high severity bugs are like this; but what we fail to realize is that there's a workaround every bug. You just need to tamper around the design to make the bug extra-special (like Feb 29) and change life. Not every bug needs fixing; they just need workarounds.

But don't get misguided by me; most often, this would be a failed argument when you have vice-presidents and directors on the other side of the table.

And my Lesson Learnt --- Every bug has a workaround; it depends on how you try to make it sellable as a special feature so that the world accepts the workaround. Else, you better fix it :)!!! Happy new year and happy "testing times" to all of you in 2012!!!

Testing team --- Thank you for the family time that you sacrificed for us!!!

Have you ever heard anything like that? It's a very nice thought that every member of the management should thank the test team for the extra time that they spend at the workplace whenever they have to spend the time.

Doesn't matter if you are the program manager, project manager or whoever... Please take some time to thank the test teams for all the extra hours that they spent in ensuring quality!!! Might have been hours poured over a requirement document clarifying a requirement, might have been hours investigating usage of automation, might have been hours spent when called into work during the son's birthday or wedding anniversary, and it can even be a few hours lost by testing the wrong build... truth is that all of us spend extra time at the work place; not for personal whims and fancies, but to ensure product quality!!! Please take a few mins extra to thank the testing team members for spending the extra time in the project... That small bug they raised in extra time might have saved your product from disaster, indirectly saving your job!!!

Blocking a Release - Happy or Sad ?

Test teams block a production release. You are the tester who found that bug.

Is it a good feeling to block the release? Or do you cry your lungs out for not getting out a release in time for your customers?

Do you get some sadistic happiness since your work blocked someone's release? Or do you feel sad that someone's work could not get out?

Do you feel happy that the entire org are finally appreciative of your work? Or do you feel bad for your development colleagues who slogged to meet this date and could not meet deadlines?

Do you feel happy that you did not deliver a half-baked product to your customers? Or do you feel bad that you could not have done it earlier?

Do you feel happy that your bosses praise you? Or do you feel bad for your dev counterpart who gets yelled at?

End of the day... blocking a release, results in  feelings... some happy, some sad!!! Yes, even a tester feels sad that a release could not get out in time.... (after  all, blocking a release means "no launch party", right? :)"

But when a launch or release happens in time? Life becomes happy for all... at least till the next launch :) !!!

A tester all life... 7 Questions and no answers!!!

Question 1 - If you ever say the words, "I want to be a tester all my life" to your management, what do you think would happen?

Question 2 - Would they be happy with your above decision because you have long term career focus?

Question 3 - Would they treat you as a visionary because you have a very clear idea of what you want to do in life?

Questions 4 & 5 - Or, would they term you a loser since you have no ambition to grow up the career chain? And advise you on becoming a test architect or manager?

And if you don't have a blog, you are not participative in newsgroups and online forums, you don't market yourself, you are "uncertified", you don't read blogs and magazines, you refuse to use test tools because you don't trust those tools...  and you are a tester for the last 12 years, and an expert one at that.....

Question 6 - Would your management recognise your potential?

Question 7 - Or are you branded as a resource who's not grown up the ladder and gets you replaced?

Well, as the title says, there are only questions... no answers. Only "test cases"... no "expected behavior". At least I don't have them. If you do, please share.....