1.Testing only shows the presence of defects
For example:A pesticide will state that it is used to kill germs but on the go it fails to prove its statement because the germs get addicted to the pesticide .Thus resulting in a paradox.
similarly when a first build is tested it results in bugs to be fixed.The second build is given to the testers stating the goal that previous bugs are fixed.Though the previous bugs are fixed ,this may lead to emergence of new bugs since the code is changed.Here the fixing activity is paradoxical in nature.
Testing shows presence of defects,it never shows the absence of defects
2.Exhaustive testing is impossible
Most difficult problem with exhaustive execution path search is the computational complexity caused by the number of possible input states. The number of individual paths the program can follow is typically overwhelming and it is practically impossible to follow them all.
For example,A small program that takes 128 bytes of effective input can have " n " possible individual tracks that have to be examined.Instead of testing all those n possibilities take some selected values and test the applicationKnow more about exhaustive testing http://www.satisfice.com/articles/good_enough_testing.pdf
3.Early Testing Works
There are two important words which makes this principle more effective.
Injection: when a bug is introduced in a software is injection of a bug.
Detection: when a tester finds the bug is detectionAs the time between the injection of a bug and the detection of the bug increases,the cost of fixing the also increases.so Testing from the initial stages of development will reduce the cost as well as risk.
4.Defect Clustering
Identifying the density of bugs in a particular module is termed as defect clustering.
for exampleAn application has four modules to be tested.If the tester finds the percentage of failure in particular module is more ,then a test engineer reports that a defect clustering has occured in particular module.Once the cluster is identified,there is no use of continuing the test process.Instead the build is given back for fixing.
5.Absence of error Fallacy
Absence of errors is a misbelief
.A test engineer can say that we could not find bugs in this software rather than saying that there are no bugs in this software.Because testing shows only presence of errors.
Thursday, June 19, 2008
SOFTWARE TESTING
1 what is software testing?
definition states “testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements” as such, there are many published definitions of software testing, however all of these definitions boils down to essentially the same thing:software testing is the process of executing software in a controlled manner, in order to answer the question “does the software behave as specified?” on a whole, testing objectives could be summarized as:
• testing is a process of executing a program with the intent of finding an error.
• a good test is one that has a high probability of finding an as yet undiscovered error.
• a successful test is one that uncovers an as yet undiscovered error.
2 why test?•
developers not fallible
• bugs in compilers, languages, dbs, os
• certain bugs easier to find in testing
• don’t want customers to find bugs
• post release debugging is expensive
• good test design is challenging and rewarding
3 principles of testing•
all tests should be traceable to requirements
• tests should be planned ahead of execution
• pareto principle – isolate suspect components for vigorous testing (80% of defects can be traced back to 20% of requirements)
• testing should be done in an outward manner (unit ->system)
4 can testing be replaced?
though there are other approaches possible to create good software like inspection, reviews, design style, static analysis, language checks etc software testing cannot be done away with. Review, inspect, read, walkthrough and test mandatiroly
5 test strategy
test strategy is a statement of the overall approach to testing, identifying what levels of testing are to be applied, and the methods, techniques and tools.
6 .test plan
the next task would be the preparation of a test plan a test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied testing of each item, and describes the test environment.
Different test plans are prepared based on the level of testing.
The objective of each test plan is to provide a plan for verification, by testing the software, that the software produced fulfills the requirements or design statements of the appropriate software specification.
unit test plan: a unit test plan describes the plans for testing individual units / components / modules of the software
integration test plan: an integration test plan describes the plan for testing integrated software components.
system test plan: a system test plan describes the plan for testing the system as a whole.
acceptance test plan: an acceptance test plan describes the plan for acceptance testing of the software.
Normally “acceptance test plan” is prepared by the customer
7 test designonce
the test plan for a level of testing has been written, the next stage is to specify a set of test cases or test paths for each item to be tested at that level.
A number of test cases will be identified for each item to be tested at each level of testing.Each test case will specify how the implementation of a particular requirement or design is to be tested and the criteria for success of each test.•
a unit test specification will detail the test cases for testing individual units of the software•
a integration test specification will detail the test cases for each stage of integration of tested software components•
a system test specification will detail the test cases of system testing of the software•
an acceptance test specification will detail the test cases of acceptance testing of the software it is important to design test cases for both positive and negative testing.
Positive testing checks whether the software is doing what it is supposed to do and negative testing checks whether the software is doing what it is not supposed to do.
8 test execution and reporting
The next stage is performing the necessary testing.
The output of test execution is recorded in a test results file normally called as the test log.
These actual results are then compared with the expected result of the test specification to determine if the test case has been successful or not.
Accordingly a “pass / fail” is marked against the respective test case. If the test case has been a failure, then a re-run of the test case is done and results noted.find attached the file for the flowchart depicting the testing process
.9 when do you stop testing?
before we ask this question, let us try to answer another question
“is complete testing possible?”
obviously the answer is no.
To prove that a program is completely free of bugs is practically impossible and theoretically a mammoth exercise.
Therefore the aim of testing is to provide a suitable, convincing demonstration that the program has been tested enough some of the stop criterias are:
• time runs out (poor criteria !!)
• resources run out
• testing stops when all test cases execute without producing any error
• testing stops when certain number of errorss are found
• testing stops when all statements and all branches are executed and all test cases execute without failure
• testing stops when the result is unproductive (no. Of errors per person per day reduces)
2. useful టిప్స్
• manage testing seriously as development projects are managed
• foster a quality culture that wants to find and prevent problems
• set clear directions and expectations
• delegate responsibility and accountability to good people
• invest in team tooling and support infrastructurte
2.1 common pitfalls
some of the aspects that hinder testing itself could బె
• optimism
• belief that the system works
.negative attitude towards effective testing
• ego
• don’t want to fail
• conflict between testers and developers
• testing is least structured
• testing is expensive
• delivery commitments
some of the pitfalls of manual testing could be
• testing speed cannot match development speed
• each build not fully tested
• test coverage decreases, more bugs left undetected
definition states “testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements” as such, there are many published definitions of software testing, however all of these definitions boils down to essentially the same thing:software testing is the process of executing software in a controlled manner, in order to answer the question “does the software behave as specified?” on a whole, testing objectives could be summarized as:
• testing is a process of executing a program with the intent of finding an error.
• a good test is one that has a high probability of finding an as yet undiscovered error.
• a successful test is one that uncovers an as yet undiscovered error.
2 why test?•
developers not fallible
• bugs in compilers, languages, dbs, os
• certain bugs easier to find in testing
• don’t want customers to find bugs
• post release debugging is expensive
• good test design is challenging and rewarding
3 principles of testing•
all tests should be traceable to requirements
• tests should be planned ahead of execution
• pareto principle – isolate suspect components for vigorous testing (80% of defects can be traced back to 20% of requirements)
• testing should be done in an outward manner (unit ->system)
4 can testing be replaced?
though there are other approaches possible to create good software like inspection, reviews, design style, static analysis, language checks etc software testing cannot be done away with. Review, inspect, read, walkthrough and test mandatiroly
5 test strategy
test strategy is a statement of the overall approach to testing, identifying what levels of testing are to be applied, and the methods, techniques and tools.
6 .test plan
the next task would be the preparation of a test plan a test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied testing of each item, and describes the test environment.
Different test plans are prepared based on the level of testing.
The objective of each test plan is to provide a plan for verification, by testing the software, that the software produced fulfills the requirements or design statements of the appropriate software specification.
unit test plan: a unit test plan describes the plans for testing individual units / components / modules of the software
integration test plan: an integration test plan describes the plan for testing integrated software components.
system test plan: a system test plan describes the plan for testing the system as a whole.
acceptance test plan: an acceptance test plan describes the plan for acceptance testing of the software.
Normally “acceptance test plan” is prepared by the customer
7 test designonce
the test plan for a level of testing has been written, the next stage is to specify a set of test cases or test paths for each item to be tested at that level.
A number of test cases will be identified for each item to be tested at each level of testing.Each test case will specify how the implementation of a particular requirement or design is to be tested and the criteria for success of each test.•
a unit test specification will detail the test cases for testing individual units of the software•
a integration test specification will detail the test cases for each stage of integration of tested software components•
a system test specification will detail the test cases of system testing of the software•
an acceptance test specification will detail the test cases of acceptance testing of the software it is important to design test cases for both positive and negative testing.
Positive testing checks whether the software is doing what it is supposed to do and negative testing checks whether the software is doing what it is not supposed to do.
8 test execution and reporting
The next stage is performing the necessary testing.
The output of test execution is recorded in a test results file normally called as the test log.
These actual results are then compared with the expected result of the test specification to determine if the test case has been successful or not.
Accordingly a “pass / fail” is marked against the respective test case. If the test case has been a failure, then a re-run of the test case is done and results noted.find attached the file for the flowchart depicting the testing process
.9 when do you stop testing?
before we ask this question, let us try to answer another question
“is complete testing possible?”
obviously the answer is no.
To prove that a program is completely free of bugs is practically impossible and theoretically a mammoth exercise.
Therefore the aim of testing is to provide a suitable, convincing demonstration that the program has been tested enough some of the stop criterias are:
• time runs out (poor criteria !!)
• resources run out
• testing stops when all test cases execute without producing any error
• testing stops when certain number of errorss are found
• testing stops when all statements and all branches are executed and all test cases execute without failure
• testing stops when the result is unproductive (no. Of errors per person per day reduces)
2. useful టిప్స్
• manage testing seriously as development projects are managed
• foster a quality culture that wants to find and prevent problems
• set clear directions and expectations
• delegate responsibility and accountability to good people
• invest in team tooling and support infrastructurte
2.1 common pitfalls
some of the aspects that hinder testing itself could బె
• optimism
• belief that the system works
.negative attitude towards effective testing
• ego
• don’t want to fail
• conflict between testers and developers
• testing is least structured
• testing is expensive
• delivery commitments
some of the pitfalls of manual testing could be
• testing speed cannot match development speed
• each build not fully tested
• test coverage decreases, more bugs left undetected
Subscribe to:
Posts (Atom)