Test Levels & Techniques


Published on

Published in: Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Test Levels & Techniques

  1. 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. 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. 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. 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. 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. 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. 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. 8. Integration Testing - Overview
  9. 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. 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. 11. System Testing - Overview
  12. 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. 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. 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. 15. V-Model Unit Integration System UAT LLD HLD SRS Business scenario
  16. 16. Software Testing
  17. 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. 18. White Box Testing
  19. 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. 20. White Box Testing - Internal
  21. 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. 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. 23. Black Box Testing
  24. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 35. Illustrates various techniques used throughout the test stages