04 black box testing

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of 04 black box testing

2. TODAYS AGENDA BLACK BOX TESTING What is Black Box Testing Differences between Black Box Testing and White Box Testing Different techniques of Black Box Testing 2 3. WHAT IS BLACK BOX TESTING Black Box Testing is done without the knowledge of the internals of the system under test 3 4. LOCK AND KEY EXAMPLE OF BLACK BOX TESTING 4 5. CHARACTERISTICS OF BLACK BOX TESTING Done based on requirements Addresses (Should address) stated as well as implied requirements Encompasses the end user perspective Checks for valid and invalid conditions / inputs May or may not know the technology aspects of the product 5 6. DIFFERENCES BETWEEN WHITE BOX AND BLACK BOX TESTING Black Box Testing White Box Testing No access to program code Has access to program code Requires external perspective Requires knowledge of program code Set of techniques applicable to all other phases of testing Typically applies only to unit testing, where code is involved 6 7. PRINCIPLES OF BLACK BOX TESTING It is not possible to exhaustively test a product Choose tests so that We can test as much of the external functionality as possible Uncover as many defects as possible Use as short time as possible 7 Have methodologies that choose tests that have a higher likelihood uncovering new defects 8. TECHNIQUES / METHODOLOGIES OF BLACK BOX TESTING Requirements Based Testing Positive and Negative Testing Boundary Value Analysis Decision Tables Equivalence Partitioning State Based Testing Compatibility Testing User Documentation Testing Domain Testing (leads to ad hoc testing) 8 9. GENERAL FORMAT OF DISCUSSION OF TECHNIQUES Present some reasoning where applicable List out one or two examples Walk through the examples Summarize the process for using the technique 9 10. REQUIREMENTS BASED TESTING Done to ensure all requirements in SRS are tested Difference between implicit and explicit requirements Review requirements first to ensure they are consistent, correct, complete and testable Review enables translation of (some of) implied requirements to stated requirements A reviewed SRS tabulates requirements, along with a requirements id and a priority This is the genesis of a Requirements Traceability Matrix 10 11. REQUIREMENTS TRACEABILITY MATRIX GENERAL FORMAT 11 12. ZOOMING IN ON TESTING PART OF RTM Fig 4.5 Test Condition: Different ways of testing a requirement (different types of mapping) Test Case: Different conditions / scenarios for a given requirement Phase of testing helps scheduling Importance of documenting expected results 12 13. POSITIVE AND NEGATIVE TESTING Positive testing to check that the product does what it is supposed to Behaves correctly when given right inputs Maps to a specific requirement Coverage is defined better Negative Testing to show that the product does not fail when given unexpected inputs Try to break the system No direct mapping to a specific requirement Coverage more challenging 13 14. BOUNDARY VALUE ANALYSIS Most defects come up near boundaries Reasons from a White Box perspective Programmers tentativeness in using the right relational operator (< or