Murphy's Laws of Software testing

Taken from my facebook wall. Here goes:

1) Bugs can easily be created. They cannot however, be easily destroyed. But they can easily get transferred from one platform to another.

2) There is no such thing as a bug free application. But yes, bugs do come free with every application. :)

3) Bugs do not get reproduced when you demo them to the developer / project manager.

4) But will magically reappear from nowhere when you demo your product to the client / customer.

5) Your most bug-free product version will reside in your developer’s local machine / session. Bugs never happen there.

6) The more the number of developers working on the product, the more bugs there will be to find.

7) Bugs which have been deemed fixed and closed always reoccur in Production.

8) No matter how extensive your test coverage is, you will always miss / overlook one aspect of the product.

9) And that’s where the bug will usually occur in production.

10) No matter how many critical bugs you find, you will be pilloried for the one bug you failed to detect.

11) The PM and delivery manager will always consider the testing team as dead weight.

12) The bug which takes the maximum amount of time to reproduce will always take the least amount of time to fix.

13) The bug which causes the maximum amount of damage always requires the smallest of fixes.

14) Customers / End users usually find more bugs than your testers’ do.

15) Bugs will never be apparent if you keep looking for them, but when you are not, they will pop up from every nook and corner of the application and will hit you in the face.

16) Automation might get things done quicker, but the amount of time it takes to script the tests and run them will make you think of running the tests manually.

17) The most critical and time consuming bug for the developers to fix will always occur at the fag end of the testing cycle or when the product is ready to ship.

18) You will spend a huge amount of time and energy in detecting a bug only to find that it now not reproduced.

19) Even if you do reproduce the goddamn bug and file it, it inadvertently turns up not to be in scope.

20) Even if it is in scope, someone else would have already filed it a long time back.

21) The product / feature for which you have detected the maximum number of bugs will most certainly be de-scoped.

Developers’ ultimate justification for bugs:

“But it does not happen on my local machine!!” :)

"This issue is not in scope."

Murphy’s Ultimate Law of all products:

“It just won’t work!”

Manual or Automation testing?

This is a very interesting topic which has been debated endlessly ever since the evolution of Software Testing and more so in recent times, as Software QA has gained more prominence.

Let me first start by demystifying the myth about Automation testing. Many people have the misconception that Automation gets the work done faster than manual testing, hence it is better. Why break your head testing the same old application when you can run a nice ol' script and get the task done in a jiffy? While Automation definitely has its advantages and can reduce time and improve productivity, it is in no way an effective replacement for manual testing.

Any Software, big or small has to go through one round of manual testing as a minimum (or more as the situation demands). Manual testing requires domain knowledge, thorough technical grounding and good testing instincts with creativity to spot bugs early on as a minimum. Only after the functionality has been ascertained and the application stable can we proceed with automation. There are also certain areas which cannot be effectively tested by Automation.

That said and done, in todays’ testing scenario, given the complex nature and strict timelines needed to deliver top quality applications, we cannot afford to ignore automation at all. We would be doing so at our own peril. Automation can help us perform repetitive and complex tasks faster and safer leading to greater productivity. Automation also helps to reduce the load on manual testing giving testers more time to do some exploratory testing on the product, in turn leading to higher product quality. Automation has been used extensively and effectively in tasks involving high degree of repetition and complexity such as regression testing, cross browser testing, loads and stress testing etc. To put it in Industrial terms, manual testing can be compared to the initial design and testing of any product in a factory such as an automobile where the number of unknown factors are high. Automation can come later and can help in performing tasks repetitive and time consuming tasks faster such as assembly, spray painting etc.

In a nutshell a complete tester / test manager / lead would be one who has a good understanding of automation tools as well as emphasizes the importance of manual testing. Manual testing would be like laying the basic platform for good and robust software of excellent quality and Automation can help us build on that and improve our delivery timelines and overall product quality by leaps and bounds. As the complexity and size of software grows, the more intermingled and important both will become.