Software Testing - Tutorials, QTP, Manual Testing Automation Testing, Load Runner

It is common practice for software to be released with known bugs that are considered non-critical. While software products contain an unknown number of unknown bugs when shipped, measurements during the testing may provide a statistically reliable estimate of the number of likely bugs remaining. Most big software projects maintain a list of "known bugs". This list inform users about bugs that are not fixed in the current release, or not fixed at all, and often a workaround is offered additionally.

There are various reasons for such a list:

* The developers often don't have time to fix all non-severe bugs.
* The bug could be fixed in a new version or patch that is not yet released.
* The changes to the code required to fix the bug would be large, and would bring with them the chance of introducing other bugs into the system.

Given the above, it is often considered impossible to write completely bug-free software of any real complexity. So bugs are categorized by severity, and low-severity non-critical bugs are tolerated, as they do not impact the proper operation of the system, for the majority of users. NASA's SATC managed to reduce number of errors to fewer than 0.1 per 1000 lines of code (SLOC) but this was not felt to be feasible for any real world projects.

One school of thought, popularized by Eric S. Raymond as Linus's Law in his essay The Cathedral and the Bazaar, holds that popular open-source software holds a better chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however: computer security specialist Elias Levy wrote that "it is easy to hide vulnerabilities in complex, little understood and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so."

As per the book "The Art of Software Testing - by Myers" describes the following most important testing principles:
1. (Definition): Testing is the process of executing a program with the intent of finding errors
2. A good test case is one that has a high probability of detecting an as-yet undiscovered error
3. A successful test case is one that detects an as-yet-undiscovered error.

Though testing is not able to prove the correctness of the software, it adds value by providing useful information on the following:

1) Existing (or resurfaced) problems or interesting situations where the software works in unexpected ways

2) The responsiveness/ capacity/ endurance of the software

3) The ease or difficulty with which the software can be manipulated into exposing hidden information/ functionality or vice versa

4) Advance information about the user's reaction

"Testing can never prove the absence of errors -- only their presence." by Steve McConnell in Code Complete: A Practical Handbook of Software Construction

"If you think you can fully test a program without testing its response to every possible input, fine. Give us a list of your test cases. We can write a program that will pass all your tests but still fail spectacularly on an input you missed. If we can do this deliberately, our contention is that we or other programmers can do it accidentally."

- Cem Kaner, Jack Falk, and Hung Quoc Nguyen,

Now, thirty-two years since Glenford Myers called testing to prove correctness the opposite of testing, we're surrounded by testing practices and tools based on proving correctness. The myth of proving correctness is alive and well.

Activities designed to try to prove correctness are the antonym of testing.

So if testing is not validation, what is testing? Testing is investigation; and communicating useful information about quality to decision makers.

"Testing is the process by which we explore and understand the status of the benefits and the risk associated with release of a software system."

- James Bach,

"Testing is done to find information. Critical decisions about the project or the product are made on the basis of that information."

- Cem Kaner, James Bach, Bret Pettichord,

"A software tester’s job is to test software, find bugs, and report them so that they can be fixed. An effective software tester focuses on the software product itself and gathers empirical information regarding what it does and doesn’t do. This is a big job all by itself. The challenge is to provide accurate, comprehensive, and timely information, so managers can make informed decisions."

- Brett Pettichord,

SPONSORED LINKS