Testing is the art of thinking.
Testing is the fun process of finding bugs.
Here is the main Testing 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
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
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.
80% of the contribution comes from 20% of the 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
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.
But recent surveys show that 80% think that they are among these 20% of contributors.
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.
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
Any non-trivial program that contains a significant number of low-severity
non-critical bugs has evidence for the existence of a critical number at which the
limit of these bugs makes this application unusable.[ersasoft]
Given infinite time, a thousand monkeys with typewriters would eventually write
all possible test cases.
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.
The Seven Basic Principles of the Context-Driven School
© 2005 Alex Samurin geocities.com/xtremetesting/ © 2009 eXtremeSoftwareTesting.com
Extreme Software Testing Main Page