Software testing principles
Software
testing Principles:
1)
an exhaustive examination is not possible
A
comprehensive examination is not possible. Instead, we need the
optimal amount of Tests based on the risk assessment of the
application.
how
do you determine this risk?
What
operation is most likely to cause your operating system to fail?
I'm
sure most of you would have guessed, Open 10 different application
all at the same time.
So
if you were testing this operating system, you would realise that
defects are likely to be found in multi-tasking activities and need
to be thoroughly tested.
2)
Lack Clustering
Defect
Clustering, which means that a small number of modules contain most
of the defects found. This is the application of the Pareto principle
to software testing: approximately 80% of the problems are found in
20% of the modules.
By
experience you can identify such risky modules. But this approach has
its own problems
If
the same tests are repeated again and again, the same test cases will
eventually no longer find any new errors.
3)
Pesticide Paradox
The
repeated use of the same pesticide mixture for the eradication of
insects during agriculture leads over time to the fact that insects
develop resistance to the pesticide, whereby pesticides on insects
become ineffective. The same applies to software testing. If the same
repeated tests are performed, the method is useless to discover new
defects.
To
overcome this, the test cases need to be reviewed and revised
regularly, adding new & different test cases to find more
defects.
The
Tester can not simply rely on existing test techniques. He must
constantly take care to improve the existing methods in order to make
Tests more effective. But even after all the sweat & hard work in
the Test, you can claim that your product is error-free. To drive
this point home, we see this video from the public Start of Windows
98
You
think a company like MICROSOFT would not have tested your system
thoroughly, and would risk their reputation just to see how your
operating system during the public Starts crashing!
4)
examination shows a presence of defects
Therefore,
test principle states that-Test speaks about the presence of defects
and does not talk about the absence of defects. this means that
software testing reduces the likelihood that undetected defects
remain in the software, but even if no defects are found, it is not
proof of correctness.
But
what if, you work extra hard, taking all precautions and making your
software product 99% error free. And the software does not meet the
needs and requirements of customers.
5)
lack of error-fallacy
It
is possible that Software that is 99% error free is still unusable.
This can be the case if the system is thoroughly tested for the
incorrect requirement. Software testing is not only the discovery of
defects, but also the verification that software meets the business
needs. The absence of an error is an error, i.e. finding and
correcting errors does not help if the system structure is unusable
and does not meet the requirements of the user.
To
solve this problem, the next test principle states that early Tests
6)
Early Tests
Early
Test Tests should start as early as possible in the software
development lifecycle. In order to detect any defects in the
requirements or design phase at an early stage. It is much cheaper to
fix a defect in the early stages of testing. But how early should one
start testing? It is recommended that you find the error as soon as
the requirements are defined. Learn more about this principle in a
later training tutorial.
7)
testing depends on context
Testing
is context-sensitive, which basically means that the way you test an
e-commerce Website is different from the way you test a commercial
off-the-shelf application. All developed software are not identical.
You can use a different approach, methods, techniques, and types of
Tests, depending on the type of application. For example, testing
every POS system in a retail store will be different from testing an
ATM machine.
Comments
Post a Comment