1.
Static Testing <ul><li>Static testing refers to testing that takes place without Execution - examining and reviewing it. </li></ul><ul><li>Dynamic Testing </li></ul><ul><li>Dynamic testing is what you would normally think of testing - executing and using the software. </li></ul>

2.
Dynamic Testing <ul><li>Techniques used are determined by the type of testing that must be conducted </li></ul><ul><ul><li>Functional </li></ul></ul><ul><ul><li>Structural </li></ul></ul>

3.
Functional Testing <ul><li>Structure of the program is not considered. </li></ul><ul><li>Test cases are decided based on the requirements or specification of the program or module </li></ul><ul><li>Hence it is often called as “Black Box Testing”. </li></ul>

4.
Structural Testing <ul><li>Concerned with testing ,the implementation of the program. </li></ul><ul><li>Focus on the internal structure of the program. </li></ul><ul><li>The intent of structural testing is not to exercise all the different input or output condition but to exercise the different programming structures and data structures in the program. </li></ul>

5.
<ul><li>Phases of software testing: </li></ul><ul><ul><li>Unit Testing </li></ul></ul><ul><ul><li>Integration/Build Testing </li></ul></ul><ul><ul><li>Validation/Functional Testing </li></ul></ul><ul><ul><li>System Testing </li></ul></ul><ul><ul><li>Acceptance Testing </li></ul></ul>Testing Levels

6.
Unit Testing <ul><li>Test each module individually. </li></ul><ul><li>Follows a white box testing (Logic of the program) </li></ul>

7.
Integration testing <ul><li>Integrate two or more module.i.e. communicate between the modules. </li></ul><ul><li>Follow a white box testing (Testing the code) </li></ul>

8.
Integration Testing - Overview

9.
System Testing <ul><li>Confirms that the system as a whole delivers the functionality originally required. </li></ul><ul><li>Follows the black box testing. </li></ul>

10.
System Testing - Goals <ul><li>Incorrect or missing feature </li></ul><ul><li>Performance errors </li></ul><ul><li>Security errors </li></ul><ul><li>User interface errors </li></ul><ul><li>Configuration and compatibility </li></ul><ul><li>Compliance to required standards </li></ul>

11.
System Testing - Overview

12.
System Testing - Overview <ul><li>System Tests: </li></ul><ul><ul><li>Define test procedures and instructions </li></ul></ul><ul><ul><li>Review test plans </li></ul></ul><ul><ul><li>Execute test plans </li></ul></ul><ul><ul><li>Record results </li></ul></ul>

13.
System Testing - Strategy <ul><li>Developing System Tests </li></ul><ul><ul><li>stress tests </li></ul></ul><ul><ul><li>security tests </li></ul></ul><ul><ul><li>recovery tests </li></ul></ul><ul><ul><li>performance tests </li></ul></ul>

14.
User Acceptance Testing (UAT) <ul><li>Building the confidence of the client and users is the role of the acceptance test phase. </li></ul><ul><li>It is depend on the business scenario. </li></ul><ul><li>Those functions required by the customer to demonstrate sufficient functionality and reliability to warrant acceptance. </li></ul>

15.
V-Model Unit Integration System UAT LLD HLD SRS Business scenario

16.
Software Testing

17.
Testing Techniques <ul><li>White Box </li></ul><ul><li>Black Box </li></ul><ul><li>Incremental </li></ul><ul><li>Thread </li></ul>

18.
White Box Testing

19.
White Box Testing - Internal <ul><li>Purpose of Unit Tests: </li></ul><ul><ul><li>Test all loops </li></ul></ul><ul><ul><li>Test Basis paths </li></ul></ul><ul><ul><li>Test conditional statements </li></ul></ul><ul><ul><li>Test data structures </li></ul></ul><ul><ul><li>* develop unit tests after the design portion of the Build Definition Spec. is completed. </li></ul></ul>

20.
White Box Testing - Internal

21.
White Box Testing Techniques <ul><li>Statement coverage – execute all statements at least once. </li></ul><ul><li>Decision coverage - execute each decision direction at least once. </li></ul><ul><li>Condition coverage – execute each decision with all possible outcomes at least once </li></ul>

22.
White Box Testing Techniques <ul><li>Loop Testing: </li></ul><ul><ul><li>Simple Loops </li></ul></ul><ul><ul><li>Nested Loops </li></ul></ul><ul><ul><li>Concatenated Loops </li></ul></ul><ul><ul><li>Unstructured Loops </li></ul></ul>

23.
Black Box Testing

24.
Black Box Testing - External <ul><li>Black Box Testing verifies that the requirements have been met. </li></ul><ul><ul><li>How is functional validity tested </li></ul></ul><ul><ul><li>How is system behavior and performance tested. </li></ul></ul><ul><ul><li>What classes of input will make good test cases? </li></ul></ul><ul><ul><li>Is the system particularly sensitive to certain input values? </li></ul></ul><ul><ul><li>How are the boundaries of a data class isolated? </li></ul></ul><ul><ul><li>What data rates and data volume can the system tolerate? </li></ul></ul><ul><ul><li>What effect will specific combinations of data have on system operation? </li></ul></ul>

25.
Black Box Testing - External <ul><li>Black Box Tests look for: </li></ul><ul><ul><li>incorrect or missing functions </li></ul></ul><ul><ul><li>interface errors </li></ul></ul><ul><ul><li>errors in external database access </li></ul></ul><ul><ul><li>behavior or performance errors </li></ul></ul>

26.
Black Box Testing Techniques <ul><ul><li>* Equivalence Partitioning </li></ul></ul><ul><ul><li>* Boundary Analysis </li></ul></ul><ul><ul><li>* Error Guessing </li></ul></ul>

27.
Equivalence Partitioning <ul><li>A subset of data that is representative of a larger class </li></ul><ul><li>For example, a program which edits credit limits within a given range ($10,000 - $15,000 would have 3 equivalence classes: </li></ul><ul><ul><li>Less than $10,000 (invalid) </li></ul></ul><ul><ul><li>Between $10,000 and $15,000 (valid) </li></ul></ul><ul><ul><li>Greater than $15,000 (invalid) </li></ul></ul>

28.
Boundary Analysis <ul><li>A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function </li></ul>

29.
Boundary Analysis continued... <ul><li>In the same credit limit example, boundary analysis would test: </li></ul><ul><ul><li>Low boundary plus or minus one ($9,999 and $10,001) </li></ul></ul><ul><ul><li>On the boundary ($10,000 and $15,000) </li></ul></ul><ul><ul><li>Upper boundary plus or minus one ($14,999 and $15,001) </li></ul></ul>

30.
Error Guessing <ul><li>Based on the theory that test cases can be developed based on experience of the Test Engineer </li></ul><ul><li>For example, in an example where one of the inputs is the date, a test engineer might try February 29,2000 or 9/9/99 </li></ul>

31.
Incremental Testing <ul><li>A disciplined method of testing the interfaces between unit-tested programs as well as between system components </li></ul><ul><li>Incremental Testing Types </li></ul><ul><li>- Top-down </li></ul><ul><li>- Bottom-up </li></ul>

32.
Top-Down <ul><li>Begins testing from the top of the module hierarchy and works down to the bottom using interim stubs to simulate lower interfacing modules or programs </li></ul>

33.
Bottom-Up <ul><li>Begins testing from the bottom of the hierarchy and works up to the top </li></ul><ul><li>Bottom-up testing requires the development of driver modules which provide the test input, call the module or program being testing, and display test output </li></ul>

34.
<ul><li>A technique, often used during early integration testing </li></ul><ul><li>Demonstrates key functional capabilities by testing a string of units that accomplish a specific function in the application </li></ul>Thread Testing

35.
Illustrates various techniques used throughout the test stages