Testing Laws

Testing is the art of thinking.

Testing is the fun process of finding bugs.

Here is the main Testing Laws:

Murphy's Laws

**********************

Any non-trivial program contains at least one bug

There's always one more bug.

Every program has at least one bug. Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a bug.

Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.

In any program, any error which can creep in will eventually do so.

Not until the program has been in production for at least six months will the most harmful error be discovered.

Murphy's law says: The information item that indicates the irrelevance of the contained information is visible only after you've retrieved the whole information.

Adapted by Christoph Franzen

A variation: If you try to find bugs in an application using a testing tool, you'll find bugs in the testing tool that keep you from testing your application.

And the hardcore version: If you have successfully gotten a new version of the testing tool with all bugs fixed, you discover your application is due for shipment, and you don't have any more time to test your application.

Alternative hardcore version: If you have successfully gotten a new version of the testing tool with all bugs fixed, you discover your application is incompatible with the testing tool -- which you could not know in advance since the bugs in the testing tool kept you from using it.

Pareto Principle 80% of the contribution comes from 20% of the contributors.
***
But recent surveys show that 80% think that they are among these 20% of contributors.

Murphy's Laws of Computing
When computing, whatever happens, behave as though you meant it to happen.
When you get to the point where you really understand your computer, it's probably obsolete.
The first place to look for information is in the section of the manual where you least expect to find it.
When the going gets tough, upgrade.
For every action, there is an equal and opposite malfunction.
He who laughs last probably made a back-up.
A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.
The number one cause of computer problems is computer solutions.
A computer program will always do what you tell it to do, but rarely what you want to do.
C. Northcote Parkinson's Laws
Work expands so as to fill the time available for its completion.
It is better to be a has-been than a never-was.
Delay is the deadliest form of denial.

Weinberg's Laws

**********************

If you can't think of three things that might go wrong with you plans, then there's something wrong with your thinking

More Software Testing Laws

Not all test that passed for the first time will necessary passed for the second one.

What will passed in the mind of developers can fail in the real world.

A computer lets you make more mistakes faster than any other invention in human history.

If you can�t test the software that you build, you shouldn�t build it�

Testing never ends it just stops.

There are always circumstances under which software will fail

Software Testing Principles
From:The Art of Software Testing Glenford J. Myers , 1979

A necessary part of a test case is a definition of the expected output or result.

A programmer should avoid attempting to test his or her own program.

A programming organization should not test its own programs.

Thoroughly inspect the results of each test.

Test cases must be written for invalid and unexpected, as well as valid and expected, input conditions.

Examining a program to see if it does not do what it is supposed to do is only half of the battle. The other half is seeing whether the program does what it is not supposed to do.

Avoid throw-away test cases unless the program is truly a throw-a way program.

Do not plan a testing effort under the tacit assumption that no errors will be found.

The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section.

Testing is an extremely creative and intellectually challenging task.

Testing is the process of executing a program with the intent of finding errors.

A good test case is one that has a high probability of detecting an as-yet undiscovered error.

A successful test case is one that detects an as-yet undiscovered error.

Some Myths about Software Testing

Testing is only reactive in nature.

Testers have to have full domain expertise.

Anybody can do testing.

Automation should always be utilized.

"Formal" methods are "too much" for our company.

Testing always increases development costs.

There is no need to bring testers in early.

Exploratory testing is always ineffective.

Adding more testers to a project will reduce testing time

Testing can always find all bugs if enough time is given.

Testing does not, by itself, improve software quality.

Everybody can do a test automation

Automation can eliminate or reduce manual testers.

The same testing strategy can be applied for manual software testing and automated software testing
The following 3 myths submitted by Thomas Drake:

Testing is the process of demonstrating that defects are not present in the application that was developed.

Testing is the activity or process which shows or demonstrates that a program or system performs all intended functions correctly.

Testing is the activity of establishing the necessary 'confidence' that a program or system does what it is supposed to do, based on the set of requirements that the user has specified.

Read The Seven Basic Principles of the Context-Driven School

Software Testing Main Page