1. Unit-V testing strategies and tactics.
A Strategic approach to Software Testing
Strategic Issues
Testing Strategy for Conventional Software and Object-Oriented Software….
Validation Testing
System Testing
Validation and Verification
Testing Tactics:
Black Box and White Box Testing
Basis Path Testing
Control Structure Testing
Object-Oriented Software Testing Methods
Prof.Deshmukh Santosh S. (MCA SIT)

2. Prof.Deshmukh Santosh S. (MCA SIT)
Testing Strategies:
Software testing fundamentals define the overriding objectives for software testing.
Test case design focuses on a set of techniques for the creation of test cases that meet overall testing objectives.
A strategy for software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software.
The strategy provides a road map that describes the steps to be conducted as part of testing, when these steps are planned and then undertaken, and how much effort, time, and resources will be required.
Any testing strategy must incorporate test planning, test case design,
test execution, and resultant data collection and evaluation.
A software testing strategy should be flexible enough to promote a customized testing approach.
Prof.Deshmukh Santosh S. (MCA SIT)

3. Prof.Deshmukh Santosh S. (MCA SIT)
Testing is a set of activities that can be planned in advance and conducted systematically.
A template for software testing-a set of steps into which we can place specific test case design techniques and testing methods-should be defined for the software process.
All provide the software developer with a template for testing and all have the following generic characteristics:
Testing begins at the component level2 and works "outward" toward the integration of the entire computer-based system.
Different testing techniques are appropriate at different points in time.
Testing is conducted by the developer of the software and (for large projects) an independent test group.
Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.
Prof.Deshmukh Santosh S. (MCA SIT)

4. Prof.Deshmukh Santosh S. (MCA SIT)
A strategy for software testing must accommodate low-level tests that are necessary to verify that a small source code segment has been correctly implemented as well as high-level tests that validate major system functions against customer requirements.
A strategy must provide guidance for the practitioner and a set of milestones for the manager.
Verification and Validation :
Verification refers to the set of activities that ensure that software correctly implements a specific function.
Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"
Prof.Deshmukh Santosh S. (MCA SIT)

5. Prof.Deshmukh Santosh S. (MCA SIT)
A Software Testing Strategy :
The software engineering process may be viewed as the spiral illustrated in Figure.
Initially, system engineering defines the role of software and leads to software requirements analysis, where the information domain, function, behavior, performance, constraints, and validation criteria for software are established.
A strategy for software testing may also be viewed in the context of the spiral..
Unit testing begins at the vortex of the spiral and concentrates on each unit (i.e., component) of the software as implemented in source code.
Testing progresses by moving outward along the spiral to integration testing, where the focus is on design and the construction of the software architecture.
Prof.Deshmukh Santosh S. (MCA SIT)

6. Prof.Deshmukh Santosh S. (MCA SIT)
Taking another turn outward on the spiral, we encounter validation testing, where requirements established as part of software requirements analysis are validated against the software that has been constructed.
we arrive at system testing, where the software and other system
elements are tested as a whole.
To test computer software, we spiral out along streamlines that broaden the scope of testing with each turn.
Prof.Deshmukh Santosh S. (MCA SIT)

7. Prof.Deshmukh Santosh S. (MCA SIT)
Strategic Issues :
we explore a systematic strategy for software testing. But even the best strategy will fail if a series of overriding issues are not addressed.
Specify product requirements in a quantifiable manner long before testing commences :
Although the overriding objective of testing is to find errors, a good testing strategy also assesses other quality characteristics such as portability, maintainability, and usability.
State testing objectives explicitly:
The specific objectives of testing should be stated in measurable terms. For example, test effectiveness, test coverage, mean time to failure, the cost to find and fix defects.
Understand the users of the software and develop a profile for each user category:
Use-cases that describe the interaction scenario for each class of user can reduce overall testing effort by focusing testing on actual use of the product.
Prof.Deshmukh Santosh S. (MCA SIT)

8. Prof.Deshmukh Santosh S. (MCA SIT)
Develop a testing plan that emphasizes “rapid cycle testing” :
The feedback generated from these rapid cycle tests can be used to control quality levels and the corresponding test strategies.
Build “robust” software that is designed to test itself :
Software should be designed in a manner that uses antbugging techniques.
software should be capable of diagnosing certain classes of errors.
Use effective formal technical reviews as a filter prior to testing.
Formal technical reviews can be as effective as testing in uncovering errors.
Reviews can reduce the amount of testing effort that is required to produce high-quality software.
Prof.Deshmukh Santosh S. (MCA SIT)

9. Prof.Deshmukh Santosh S. (MCA SIT)
Conduct formal technical reviews to assess the test strategy and test cases themselves :
Formal technical reviews can uncover inconsistencies, omissions, and outright errors in the testing approach. This saves time and also improves product quality.
Develop a continuous improvement approach for the testing process :
The test strategy should be measured. The metrics collected during testing should be used as part of a statistical process control approach for software testing.
Prof.Deshmukh Santosh S. (MCA SIT)

10. Prof.Deshmukh Santosh S. (MCA SIT)
Testing Strategy for Conventional Software :
The last high-order testing step falls outside the boundary of software engineering and into the broader context of computer system engineering.
Software, once validated, must be combined with other system elements (e.g., hardware, people, databases).
System testing verifies that all elements mesh properly and that overall system function/performance is achieved.
Validation Testing :
Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements.
A test plan outlines the classes of tests to be conducted and a test procedure defines specific test cases that will be used to demonstrate conformity with requirements.
Prof.Deshmukh Santosh S. (MCA SIT)

11. Prof.Deshmukh Santosh S. (MCA SIT)
Validation Testing
Validation testing is the process of evaluating a system or component during / end of the development process to determine whether it satisfies specified requirements or not.
Validation activities can divided into such as ….
Low level Testing
Unit testing
Integration testing
High level testing
System testing
Acceptance testing
Scenario testing
Ad hoc testing
Automation testing
Prof.Deshmukh Santosh S. (MCA SIT)

12. Prof.Deshmukh Santosh S. (MCA SIT)
Validation methods are decomposed into following methods…
Black box methods for function-based tests
Equivalence partitioning
Boundary value analysis
State transition testing
White box methods for internals-based testing :
Statement coverage
Decision (branch) coverage
Path coverage
Function coverage
Mutation testing
Prof.Deshmukh Santosh S. (MCA SIT)

13. Prof.Deshmukh Santosh S. (MCA SIT)
System Testing :
Once the entire system has been built then it has to be tested against the “System Specification” to check if it delivers the required features.
System testing verifies the entire product, after integrating all software & hardware components & validates it according to original project requirements.
A testing group performs testing before the product is made available to customer.
It also verifies the software operation from the perspective of the end user with different configuration/setup.
It can begin whenever the product has sufficient functionality to execute some of the tests or after Unit & Integration testing are complete.
Prof.Deshmukh Santosh S. (MCA SIT)

14. Prof.Deshmukh Santosh S. (MCA SIT)
System testing is a series of different tests whose primary purpose is to fully exercise the computer-based system.
System Testing
Functional System Testing Non-functional system testing
Usability Testing
Recovery Testing
Installation Testing
Security Testing
Performance Testing
Stress Testing
Configuration Testing
Reliability Testing
Scalability Testing
Requirements based testing
Specification based testing
Black box Testing
Security Testing
Prof.Deshmukh Santosh S. (MCA SIT)

15. Prof.Deshmukh Santosh S. (MCA SIT)
Functional System Testing :
Functional testing used whenever a product’s functionality & features are test. It is conducted for functional requirements.
It is the process of validation an application or web-site to verify that each feature compiles with its specifications & correctly performs all its required functions.
This can involve testing of the product’s user interface, APIs, database management, security etc.
Non-Functional System Testing :
This testing involves testing the product’s quality factors such as reliability, scalability & so on….
It is conducted for non-functionality requirement .
This testing requires the expected results to be documented in qualitative & quantities terms.
Prof.Deshmukh Santosh S. (MCA SIT)

16. Prof.Deshmukh Santosh S. (MCA SIT)
Types of Non-functional System Testing :
Usability Testing :
It verifies “ user-friendly” or “user-understandability” of the product.
It is also identifies operations of functions that may be difficult for users.
Primary goal is to verify that users of the application are able to interact properly with the application.
This requires examination of layout of application’s interface, navigation paths & other elements such as localization such as installation program.
Usability testing is done to determine how simple it is to understand usage of application & how easy it is to execute an application process.
Prof.Deshmukh Santosh S. (MCA SIT)

17. Prof.Deshmukh Santosh S. (MCA SIT)
Verification and Validation :
Verification refers to the set of activities that ensure that software correctly implements a specific function.
Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"
Prof.Deshmukh Santosh S. (MCA SIT)

18. Prof.Deshmukh Santosh S. (MCA SIT)
Testing Tactics:
White-Box testing :
The white box approach focuses on the inner structure of the software to be tested.
Tester must have knowledge of that structure , using white box testing methods, the software engineer can drive test cases that..
Guarantee that all independent paths within a module exercised at least once.
Exercise all logical decisions.
Executes all loops at their boundaries & operational bounds.
Exercise internal data structures to maintain their validity.
White box testing is classified into “Static” & “ Structural” testing.
Prof.Deshmukh Santosh S. (MCA SIT)

19. Prof.Deshmukh Santosh S. (MCA SIT)
White box testing
static testing
Structural testing
Unit /code functional
testing
Code Complexity
Code Coverage
Cyclomatic
Complexity
Statement Coverage
Path Coverage
Condition Coverage
Function Coverage
desk checking
Code Walkthrough
Code Inspection
Prof.Deshmukh Santosh S. (MCA SIT)

20. Prof.Deshmukh Santosh S. (MCA SIT)
Black-Box testing :
Black box testing focuses on the functional requirements of the software.
It enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.
Black-box testing, also called behavioral testing, focuses on the functional requirements of the software.
Using the black box approach, a tester considers the software-under-test to be an opaque box.
There is no knowledge of its inner structure.
The tester only has knowledge of what it does.
Prof.Deshmukh Santosh S. (MCA SIT)

21. Prof.Deshmukh Santosh S. (MCA SIT)
Black-box testing attempts to find errors in the following categories:
Incorrect or missing functions,
Interface errors
Errors in data structures or external data base access,
Behavior or performance errors, and
Initialization and termination errors.
Prof.Deshmukh Santosh S. (MCA SIT)

22. Prof.Deshmukh Santosh S. (MCA SIT)
Basis Path Testing :
Basis path testing is a white-box testing technique first proposed by Tom McCabe.
The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths.
Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.
1) Flow Graph Notation :
Before the basis path method can be introduced, a simple notation for the representation of control flow, called a flow graph.
The flow graph represents logical control flow using the notation illustrated in Figure.
Prof.Deshmukh Santosh S. (MCA SIT)

23. Prof.Deshmukh Santosh S. (MCA SIT)
To illustrate the use of a flow graph, we consider the procedural design representation.
In fig. each circle, called a flow graph node, represents one or more procedural statements.
A sequence of process boxes and a decision diamond can map into a single node.
The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows.
An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the symbol for the if-then-else construct).
Areas bounded by edges and nodes are called regions.
Prof.Deshmukh Santosh S. (MCA SIT)

24. Prof.Deshmukh Santosh S. (MCA SIT)
Transform Flowchart into Flow Graph
Prof.Deshmukh Santosh S. (MCA SIT)

25. Prof.Deshmukh Santosh S. (MCA SIT)
Flow Graph Notation
While
Sequence
If-then-else
Until
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

26. Prof.Deshmukh Santosh S. (MCA SIT)
Another Example 1 9 2 4 3 5 6 7 8
What is V(G)?
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

27. Prof.Deshmukh Santosh S. (MCA SIT)
2) Cyclomatic Complexity :
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.
When used in the context of the basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program.
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.
Cyclomatic complexity has a foundation in graph theory and provides us with an extremely useful software metric.
Complexity is computed in one of three ways:
Prof.Deshmukh Santosh S. (MCA SIT)

28. Cyclomatic Complexity
Set of independent paths through the graph (basis set)
V(G) = E – N + 2
E is the number of flow graph edges
N is the number of nodes
V(G) = P + 1
P is the number of predicate nodes
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

29. Prof.Deshmukh Santosh S. (MCA SIT)
Example
i = 0;
while (i<n-1) do
j = i + 1;
while (j<n) do
if A[i]<A[j] then
swap(A[i], A[j]);
end do;
i=i+1;
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

30. Prof.Deshmukh Santosh S. (MCA SIT)
Flow Graph 1 2 3 7 4 5 6
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

31. Prof.Deshmukh Santosh S. (MCA SIT)
Computing V(G)
V(G) = 9 – = 4
V(G) = = 4
Basis Set
1, 7
1, 2, 6, 1, 7
1, 2, 3, 4, 5, 2, 6, 1, 7
1, 2, 3, 5, 2, 6, 1, 7
Prof.Deshmukh Santosh S. (MCA SIT)
Prof.Deshmukh Santosh S. (MCA SIT)

32. Prof.Deshmukh Santosh S. (MCA SIT)
The number of regions of the flow graph correspond to the cyclomatic complexity.
Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V(G) = E N + 2
where E is the number of flow graph edges,
N is the number of flow graph nodes.
Cyclomatic complexity, V(G), for a flow graph, G, is also defined as
V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph G.
Prof.Deshmukh Santosh S. (MCA SIT)

33. Prof.Deshmukh Santosh S. (MCA SIT)
3) Deriving Test Cases :
The basis path testing method can be applied to a procedural design or to source code.
In this section, we present basis path testing as a series of steps. The procedure average, depicted in PDL.
The following steps can be applied to derive the basis set:
Using the design or code as a foundation, draw a corresponding flow graph.
A flow graph is created using the symbols and construction rules presented in Section.
Determine the cyclomatic complexity of the resultant flow graph.
The cyclomatic complexity, V(G), is determined by applying the algorithms.
Prof.Deshmukh Santosh S. (MCA SIT)

34. Prof.Deshmukh Santosh S. (MCA SIT)
V(G) can be determined without developing a flow graph by counting all conditional statements in the
PDL.
Determine a basis set of linearly independent paths.
The value of V(G) provides the number of linearly independent paths through the program control structure.
Prepare test cases that will force execution of each path in the basis set.
Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is tested.
Prof.Deshmukh Santosh S. (MCA SIT)

35. Prof.Deshmukh Santosh S. (MCA SIT)
4) Graph Matrices :
To develop a software tool that assists in basis path testing, a data structure, called a graph matrix.
A graph matrix is a square matrix whose size (i.e., number of rows and columns) is equal to the number of nodes on the flow graph.
Each row and column corresponds to an identified node, and matrix entries correspond to connections (an edge) between nodes.
To this point, the graph matrix is nothing more than a tabular representation of a flow graph.
However, by adding a link weight to each matrix entry, the graph matrix can become a powerful tool for evaluating program control structure during testing.
Prof.Deshmukh Santosh S. (MCA SIT)