Syntel CQA Forum Test Techniques and Levels CQADoc No 211 Test Techniques
This section describes techniques andstrategies for testing. Techniques coverdifferent ways testing can be accomplished. These are combined together with eachother and with the levels of testingdescribed in the next section to create testplans that meet the needs of each uniqueproject.
1.1 Preparation1.1.1 Formal Testing
Testing performed with a plan, documentedset of test cases, etc that outline themethodology and test objectives. Testdocumentation can be developed fromrequirements, design, equivalencepartitioning, domain coverage, errorguessing, etc. The level of formality andthoroughness of test cases will dependupon the needs of the project. Someprojects can have rather informal ‘formaltest cases’, while others will require ahighly refined test process. Some projectswill require light testing of nominal pathswhile others will need rigorous testing of exceptional cases.
1.1.2 Informal Testing
Ad hoc testing performed without adocumented set of objectives or plans.Informal testing relies on the intuition andskills of the individual performing thetesting. Experienced engineers can beproductive in this mode by mentallyperforming test cases for the scenariosbeing exercised.
1.2 Execution1.2.1 Manual Testing
Manual testing involves direct humaninteraction to exercise softwarefunctionality and note behavior anddeviations from expected behavior.
1.2.2 Automated Testing
Testing that relies on a tool, built-in testharness, test framework, or other automaticmechanism to exercise softwarefunctionality, record output, and possiblydetect deviations. The test cases performedby automated testing are usually defined assoftware code or script that drives theautomatic execution.
1.3 Approach1.3.1 Structural Testing
Structural testing depends upon knowledgeof the internal structure of the software.Structural testing is also referred to aswhite-box testing.
Data-flow coverage tests paths from thedefinition of a variable to its use.
Statement coverage requires that everystatement in the code under test has beenexecuted.
Branch coverage requires that every pointof entry and exit in the program has beenexecuted at least once, and every decisionin the program has taken all possibleoutcomes at least one.
Condition coverage is branch coverage withthe additional requirement that “everycondition in a decision in the program hastaken all possible outcomes at least once.”
Multiple condition coverage requires that allpossible combinations of the possibleoutcomes of each condition have beentested.
Modified condition coverage requires thateach condition has been testedindependently.
1.3.2 Functional Testing
Functional testing compares the behavior of the test item to its specification withoutknowledge of the item’s internal structure.Functional testing is also referred to asblack box testing.
Requirements coverage requires at leastone test case for each specifiedrequirement. A traceability matrix can beused to insure that requirements coveragehas been satisfied.
Input Domain Coverage
Input domain coverage executes a functionwith a sufficient set of input values from thefunction’s input domain (the set of values itcan take as input parameters). The notionof a sufficient set is not completelydefinable, and complete coverage of theinput domain is typically impossible. Therefore the input domain is broken intosubsets, or
s, suchthat all values within a subset are likely toreveal the same defects. Any one valuewithin an equivalence class can be used torepresent the whole equivalence class. Inaddition to a generic representative, each