1. TESTING STRATEGIES - Prasad Mahale
UNIT-IV
TESTING STRATEGIES
- Prasad Mahale

2. A STRATEGIC APPROACH TO SOFTWARE TESTING
To perform effective testing, you should conduct effective technical reviews. By doing this, many errors will be eliminated before testing commences.
Testing begins at the component level and works “outward” toward the integration of the entire computer-based system.

3. Different testing techniques are appropriate for different software engineering approaches and 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.

5. Software testing is a process, to evaluate the functionality of a software application with an intent to find whether the developed software met the specified requirements or not and to identify the defects to ensure that the product is defect free in order to produce the quality product.

6. A STRATEGIC APPROACH TO SOFTWARE TESTING
Verification and Validation
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
SQA activities:
Technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, documentation review, database review, algorithm analysis, development testing, usability testing, qualification testing, acceptance testing, and installation testing.

7. Difference between Verification and Validation
Verification is the process to find whether the software meets the specified requirements for particular phase.
The validation process is checked whether the software meets requirements and expectation of the customer.
It estimates an intermediate product.
It estimates the final product.
The objectives of verification is to check whether software is constructed according to requirement and design specification.
The objectives of the validation is to check whether the specifications are correct and satisfy the business need.
It describes whether the outputs are as per the inputs or not.
It explains whether they are accepted by the user or not.
Verification is done before the validation.
It is done after the verification.
Plans, requirement, specification, code are evaluated during the verifications.
Actual product or software is tested under validation.
It manually checks the files and document.
It is a computer software or developed program based checking of files and document.

8. A STRATEGIC APPROACH TO SOFTWARE TESTING
Software Testing Strategy—The Big Picture

9. A STRATEGIC APPROACH TO SOFTWARE TESTING
Criteria for completion of testing
One question arises : “when we done testing- how do we know that we’ve tested enough”.
Response is “You're never done testing; the burdon only shifts from you ”.
Need more rigorous criteria for determining for sufficient testing.
It is possible to develop meaningful answer for guidelines.

10. STRATEGIC ISSUES
software testing strategy will succeed when software testers:
Specify product requirements in a proven manner long before testing commences. (portability, maintainability & usability)
State testing objectives explicitly. (test effectiveness, coverage, time to failure, find and fix defects, test work hour)
Understand the users of the software and develop a profile for each user category. (that describe the interaction scenario)

11. Develop a testing plan that emphasizes “rapid cycle testing.”
Build “robust” software that is designed to test itself.
Use effectives technical reviews as a filter prior to testing.
Conduct technical reviews to assess the test strategy and test cases themselves. (Review)
Develop a continuous improvement approach for the testing process.

12. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
Unit Testing
Unit testing focus on the smallest unit of software design, i.e module or software component.
Test strategy conducted on each module interface to access the flow of input and output.
The local data structure is accessible to verify integrity during execution.
Boundary conditions are tested.
In which all error handling paths are tested.
An Independent path is tested.

13. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
Unit Testing
Unit-test considerations

17. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
Unit-test procedures

18. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE

19. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
Integration Testing
1. Top-down

20. Top-down integration testing is an integration testing technique used in order to simulate the behavior of the lower-level modules that are not yet integrated.
Stubs are the modules that act as temporary replacement for a called module and give the same output as that of the actual product.
The replacement for the 'called' modules is known as 'Stubs' and is also used when the software needs to interact with an external system.
Stub - Flow Diagram:

21. TEST STRATEGIES FOR CONVENTIONAL SOFTWARE
2. Bottom-up integration

22. The order of Integration by Bottom-down approach will be:
            
Each component at lower hierarchy is tested individually and then the components that rely upon these components are tested.
Bottom Up Integration - Flow Diagram
The order of Integration by Bottom-down approach will be:
4,2
5,2
6,3
7,3
2,1
3,1

23. Regression testing
Each time a new model is added as part of integration testing, the software testing.
This is the reexecution of subset of some subset of test that already conducted to ensure that changes never unintended changes.
By reexecuting a subset of all test cases or using automated capture/playback tools.
Additional test that focus on software function that are likely to be affected by change.

25. Smoke testing
This is commonly used when product software is developed.
Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing.
The term ‘Smoke Testing’ is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on.
Benefits
Integration risk is minimized
Error diagnosis and correction are simplified
Progress is easier to assess.

27. TEST STRATEGIES FOR OBJECT-ORIENTED SOFTWARE
Unit Testing in the OO Context
Attribute and operation
X id defined for superclass and inherited by subclass.
It is equivalent of unit testing for conventional testing
2. Integration Testing in the OO Context
thread-based testing
use-based testing
dependent classes
Cluster testing (by examining CRC & object oriented relationship model)

28. TEST STRATEGIES FOR WEBAPPS
The content model for the WebApp is reviewed to uncover errors.
The interface model is reviewed to ensure that all use cases can be accommodated.
The design model for the WebApp is reviewed to uncover navigation errors.
The user interface is tested to uncover errors in presentation and/or navigation mechanics.
Each functional component is unit tested.

29. Navigation throughout the architecture is tested.
7. The WebApp is implemented in a variety of different environmental configurations and is tested for compatibility with each configuration.
8. Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or within its environment.
Performance tests are conducted.
10. The WebApp is tested by a controlled and monitored population of end users.

31. VALIDATION TESTING Validation-Test Criteria
Test that demonstrate conformity with requirements
To ensure that all fun requirements are satisfied
Characteristics are achieved
All content is accurate and properly
Configuration Review
All elements of software configuration have been properly developed, are cataloged (Audit)

33. Alpha and Beta Testing
“test drive” to plan and systematically executed series of tests
Alpha Test :
It is always performed by the developers at the software development site.
Sometimes it is also performed by Independent Testing Team.
Alpha Testing is not open to the market and public
It is always performed in Virtual Environment.
Beta Test:
It is always performed by the customers at their own site
It is not performed by Independent Testing Team.
Beta Testing is always open to the market and public.
It is performed in Real Time Environment

36. SYSTEM TESTING 1. Recovery Testing
Recovery Testing is the failure which is forced into an application to check how well the recover process is performed.
Recovery is ability to restart the operation after integrity of application is lost.
It is a type of non-functional testing.
How fast and better the application can recover after it has gone through any type of crash

37. SYSTEM TESTING 2. Security Testing
That’s done to check whether the application or the product is secured or not.
It checks to see if the application is vulnerable to attacks, if anyone hack the system or login to the application without any authorization.
It is a process to determine that an information system protects data and maintains functionality as intended.

38. SYSTEM TESTING 3. Stress Testing
Stress testing refers to a type of testing that is so harsh, it is expected to push the program to failure
Consequences of the crash, what else fails, what data are corrupted and so forth, are the results of interest for the stress tester.
Is any test that hits the program with boundaries or other extreme values
Under stress testing, various activities to overload the existing resources with excess jobs are carried out in an attempt to break the system down.

39. SYSTEM TESTING 4. Performance Testing
Which is performed, to ascertain how the components of a system are performing, given a particular situation.
The measure, validate or verify quality attributes of the system like responsiveness, Speed, Scalability, Stability under variety of load conditions.

40. SYSTEM TESTING 5. Deployment Testing
Deployment testing is a type of production testing which is  performed after the code is deployed to check whether it is  working fine in production or not . 
a) Check it deploys to right folder. b) Check deploying correctness machine c) Application (that it actually works) d) Check that the changes made our present and test for any bugs. e) Performance Issues (slow, crashes etc)

41. TESTING TACTICS

42. SOFTWARE TESTING FUNDAMENTALS
Testability. “Software testability is simply how easily [a computer program] can be tested.” The following characteristics lead to testable software.
Operability- “The better it works, the more efficiently it can be tested.”

43. Controllability- “The better we can control the software, the more the testing can be automated and optimized.”
Decomposability- “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.”
Simplicity- “The less there is to test, the more quickly we can test it.” (functional simplicity, structural simplicity, code simplicity)

44. Stability- “The fewer the changes, the fewer the disruptions to testing.”
Understandability- “The more information we have, the smarter we will test.”
Test Characteristics
A good test has a high probability of finding an error.
A good test is not redundant.
A good test is not “best of breed”.
A good test should be neither too simple nor too complex.

45. WHITE-BOX TESTING
It is also known as Code-Based Testing or Structural Testing. White box testing is the software testing method in which internal structure is being known to tester who is going to test the software.
When you completely aware of the internal structure of the code then you can run your test cases & check whether the system meet requirements mentioned in the specification document.
White box testing traditionally refers to the use of program source code as a test basis, that is, as the basis for designing tests and test cases.

46. In the White box testing following steps are executed to test the software code:
Basically verify the security holes in the code.
Verify the broken or incomplete paths in the code.
Verify the flow of structure mention in the specification document
Verify the Expected outputs
Verify the all conditional loops in the code to check the complete functionality of the application.
Verify the line by line or Section by Section in the code & cover the 100% testing. -

47. BASIS PATH TESTING
1. Flow Graph Notation

48. BASIS PATH TESTING 2. Independent Program Paths
Path 1: Path 2:
Path 3: Path 4:

49. BASIS PATH TESTING
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.
The number of regions of the flow graph corresponds to the cyclomatic complexity.
2. 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 and N is the number of flow graph nodes.
3. 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.

51. V(G) = 6 regions
V(G) = E-N+2
= 17 edges - 13 nodes + 2
= 6
V(G) = P+1
=5 predicate nodes + 1

54. 3. Deriving Test Cases
Using the design or code as a foundation, draw a corresponding flow graph.
Determine the cyclomatic complexity of the resultant flow graph.
Determine a basis set of linearly independent paths.
Prepare test cases that will force execution of each path in the basis set.

55. BASIS PATH TESTING
4. Graph Matrices

56. BASIS PATH TESTING

57. Control Structure Testing
Conditional Testing:-
Logical condition contain in program module
E1<relational operator> E2
A condition without expression is referred to as Boolean expression.
Condition is error then types of error is Boolean operator error, Boolean variable error, Boolean parenthesis error, arithmetic expression error .

58. Control Structure Testing

59. Control Structure Testing
ii. Data Flow Testing:-
Selects test path of program according to location of definition and use of variable in prg.
DEF (S)= {x|statement of S contains a definition of X}
USE (S)= {X|statement of S contains use of X}
Every DU(Def Use) chain covered at least once.
Data-flow testing uses the control flow graph to explore the unreasonable things that can happen to data (i.e., anomalies).

60. Control Structure Testing
Loop Testing :-
Loop testing a white box testing technique performed to validate the loops. 
Loops Testing reveals loops initialization problems.
By going through the loop once, the uninitialized variables in the loop can be determined.

61. Control Structure Testing
Simple loop:-
Nested loop
Concatenated loop
Unstructured loop

63. Black Box Testing
Main focus in black box testing is on functionality of the system as a whole. The term ‘behavioural testing’ is also used for black box testing
Black box testing occurs throughout the software development and Testing life cycle in Unit, Integration, System, Acceptance and regression testing stages.
This type of testing is based entirely on the software requirements and specifications.

64. Incorrect or missing function
Interface error
Error in data structure
Behaviour or performance error
Initialization or termination error

65. Graph-based testing methods:-

67. Equivalence partitioning
It can be applied at any level of testing and is often a good technique to use first.
The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently).
In equivalence-partitioning technique we need to test only one condition from each partition. This is because we are assuming that all the conditions in one partition will be treated in the same way by the software

70. Boundary value analysis
Boundary value analysis is a test case design technique to test boundary value between partitions (both valid boundary partition and invalid boundary partition).
Minimum and maximum values at inside and outside boundaries. Normally Boundary value analysis is part of stress and negative testing.

72. Orthogonal Array Testing:-
Combinational test technique, as the name suggests, is a technique of combining the data / entities as input parameters for testing, to increase the scope.
This technique is beneficial when we have to test with huge number data having many permutations and combinations.

73. 1 will represent “Is Displayed” value
2 will represent “not displayed” value
3 will represent “error message value”
Factor A will represent “ Headlines” section
Factor B will represent “Details” section
Factor C will represent “references ”section
Factor D will represent “Comment” section.
Experiment no will represent “Test Cases #”