UNITIV TESTING STRATEGIES Prasad Mahale A STRATEGIC APPROACH

UNIT-IV TESTING STRATEGIES - Prasad Mahale

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

v Different testing techniques are appropriate for different software engineering approaches and at different points in time. v Testing is conducted by the developer of the software and (for large projects) an independent test group. v Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

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.

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.

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

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

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.

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)

• 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.

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.

TEST STRATEGIES FOR CONVENTIONAL SOFTWARE Ø Unit Testing Unit-test considerations

TEST STRATEGIES FOR CONVENTIONAL SOFTWARE Unit-test procedures

TEST STRATEGIES FOR CONVENTIONAL SOFTWARE

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

• 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:

TEST STRATEGIES FOR CONVENTIONAL SOFTWARE 2. Bottom-up integration

• • 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

Ø 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.

Ø 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.

TEST STRATEGIES FOR OBJECTORIENTED SOFTWARE 1. 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)

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

6. Navigation throughout the architecture is tested. 7. The Web. App 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 Web. App or within its environment. 9. Performance tests are conducted. 10. The Web. App is tested by a controlled and monitored population of end users.

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)

Ø Alpha and Beta Testing • “test drive” to plan and systematically executed series of tests q • • 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. q • • 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

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

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.

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.

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.

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)

TESTING TACTICS

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. ”

ü 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)

ü 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.

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.

ü 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. -

BASIS PATH TESTING 1. Flow Graph Notation

BASIS PATH TESTING 2. Independent Program Paths • Path 1: 1 -11 • Path 3: 1 -2 -3 -6 -8 -9 -10 -1 -11 Path 2: 1 -2 -3 -4 -5 -10 -1 -11 Path 4: 1 -2 -3 -6 -7 -9 -10 -1 -11

BASIS PATH TESTING Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. 1. 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.

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

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.

BASIS PATH TESTING 4. Graph Matrices

BASIS PATH TESTING

Control Structure Testing i. Conditional Testing: - • Logical condition contain in program module E 1<relational operator> E 2 • 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.

Control Structure Testing

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).

Control Structure Testing iii. 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.

Control Structure Testing 1. Simple loop: 2. Nested loop 3. Concatenated loop 4. Unstructured loop

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 the software requirements and specifications. on

a. b. c. d. e. Incorrect or missing function Interface error Error in data structure Behaviour or performance error Initialization or termination error

Graph-based testing methods: -

2. 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

3. 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.

4. 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.

§ 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 #”