Software Testing Lecture 7 PDF

Course: Software Testing Lecture 7 Prepared by: Lecturer. Huda Moftah Bohalfhay Faculty of Information Technology  Outline  Static and Dynamic Testing  Examining the Specification  Test-to-Pass and Test-to-Fail  Test case ...

Course: Software Testing Lecture 7 Prepared by: Lecturer. Huda Moftah Bohalfhay Faculty of Information Technology  Outline  Static and Dynamic Testing  Examining the Specification  Test-to-Pass and Test-to-Fail  Test case  Static and Dynamic Testing  Two other terms used to describe how software is tested are static testing and dynamic testing.  Static testing refers to testing something that is not running and reviewing it (like documentation).  Dynamic testing refers to examining and reviewing something that's running (like software).  1- Examining the Specification  A development team creates a product specification from the requirements document to define what the software will become.  Typically, the product specification is a written document using words and pictures to describe the intended product. An excerpt from the Windows Calculator (see the Next figure)  It may seem like overkill to create a meticulous document for such simple software. Why not just let a programmer write a calculator program on his own? The problem is that you would have no idea what you would eventually get.  The programmer's idea of what it should look like, what functionality it should have, and how the user would use it could be completely different from yours. The only way to assure that the end product is what the customer required and to properly plan the test effort is to thoroughly describe the product in a specification.  The other advantage of having a detailed spec, and the basis of this explanation, is that as a tester you will also have a document as a testable item. You can use it to find bugs before the first line of code is written.  Static Black-Box Testing: Testing the Specification  Testing the specification is static black-box testing.  The specification is a document, not an executing program, so it's considered static.  Performing a High-Level Review of the Specification  Pretend to Be the Customer  Research Existing Standards and Guidelines  Review and Test Similar Software  Low-Level Specification Test Techniques  Complete, Accurate, Unambiguous, Consistent, etc.  Dynamic Black-Box Testing  Testing the Software with Testing software without having an insight into the details of underlying code is dynamic black-box testing.  it's black-box because you're testing it without knowing exactly how it works with blinders on.  To do this effectively requires some definition of what the software does namely, a requirements document or product specification. You don't need to be told what happens inside the software "box" you just need to know that inputting A outputs B or that performing operation C results in D.  Dynamic Black-Box Testing  Once you know the ins and outs of the software you're about to test, your next step is to start defining the test cases.  A test case is “A group of instructions for each test to be run on the system”.  That includes:  The specific inputs that you'll try  The procedures/scenarios that you'll follow when you test the software  The result that you get (either pass or fail)  Test-to-Pass and Test-to-Fail  Test-To-Pass:  You assure yourself that the software does what it's specified to do in ordinary circumstances  (You really assure only that the software minimally works, don't push its capabilities, don't see what you can do to break it, and apply the simplest and most straightforward test cases).  You may be thinking that if your goal is to find bugs, why would you test-to-pass? Wouldn't you want to find bugs by any means possible? The answer is no, not initially  Test-to-Pass and Test-to-Fail  Test-To-Fail :  You really assure only that the software shouldn’t work when it shouldn’t.  It is time to put on your sneaky, conniving, devious hat and attempt to find bugs by trying things that should force them out.  Designing and running test cases with the sole purpose of breaking the software.  Test-To-Fail is also called error-forcing  Test-to-Pass and Test-to-Fail  When designing and running your test cases, always run the test-to-pass cases first. It's important to see if the software fundamentally works before you throw the kitchen sink at it. You might be surprised how many bugs you find just using the software normally. Test case sections:  TestCase Name  Purpose  Pre-requisites  Action to perform (steps)  Expected results  Actual results (pass / fail)  Notes  Post-requisites  Test Execution Steps.. 1. Follow instructions - Never deviate from the test case instructions -Do exactly what the instruction say 2. Observe the results - observe the outcome of each test step - compare the observed outcome to the expected outcome 3. Indicate if Pass/Fail - Pass: the actual result matchs EXACTLY the expected results - Fail: the actual result DID NOT EXACTLY match the expected results OR - the tester could not execute the actions 4. If FAIL, Create BUG REPORT - a detailed report on any problems encountered during executionthe test case 5. Retain all results - keep a log of the test case results in case you need to refer back to them 6. Sign and date test execution - take ownership of the work you have completed