1. 1 CSc 191 - Senior Project Software Testing

2. 2 Preface “The amount of required study of testing techniques is trivial – a few hours over the course of four years… Over the next decade, we don’t expect to meet many computer science graduates who learned anything useful about testing… Many of the revisions that we made… for this edition were with the college student … in mind“ Testing Computer Software, 2 nd Edition, Cem Kaner, Jack Falk and Hung Quoc Nguyen.

3. 3 The Test Plan A document that describes the scope, approach, resources, and schedule of intended testing activities. It identifies: –For each Use Case, the features to be tested –Test items = SW components –Testing tasks and schedule –Personnel to do the tasks –Risks associated with this plan

4. 4 Product or Tool? The Test Plan as a Product –Structure, format, and level of detail are determined not only by what’s best for the effectiveness of the testing effort but also what a customer or regulating agency wants. The Test Plan as a Tool –Only if it helps you manage your testing and finding of bugs… otherwise, it is a diversion of resources.

5. 5 Structure of the Test Plan - 3 Specified in the Test Document: –Test Plan –Test Design Specification Details of the test approach for each Use Case and identifies the associated test cases –Test Procedure Specification Sequence of actions necessary for execution of a test –Test Case Specification Inputs, execution steps, predicted results

6. 6 Structure of the Test Plan - 4 Schedule –Identify test milestones –organized by Use Case –Define any additional test milestones –Estimate time for each testing task –Specify periods of use for each testing resource (facilities, tools and team members), as appropriate

7. 7 What Kind of Testing? Test running code, from the outside, working and stressing it in all the many ways that your customers/users might. This approach complements the programmer’s approach, that is, these tests are comprehensive in a way that the programmer’s are not.

8. 8 How to Begin List what the product can do –Use Case features; organized in a way that is convenient for testing Testing, for example: –“Business Rules” –Menu “choices” –“Entry to” and “Exit from”, options –Data entry screens, dialog boxes, and message boxes –Error handling (if it makes sense to treat this separately)

9. 9 Test Design Specification Explain how each Use Case will be tested: –Begin with an Identifier –Explain what is being tested –Approach What techniques will you use? How will use analyze the results? Are there conditions which dictate the type of tests (e.g. Boundaries…) –List each Use Case Feature and its test cases –Indicate Pass – Fail criteria

10. 10 Each Test Case Identifier (what feature is being tested) The following (with explanation): –All software components involved –Actual input values –Expected output values (Postconditions) –Special setups, testing actions, or output analysis needed –Dependencies / Preconditions (are there prerequisite Features that should have been tested first?)

11. 11 Test Procedure What to consider? For example: How will you log the results What setups are needed to begin How do you begin execution Any actions needed during the procedure execution How do you “measure” the results How to shut down if unknown events occur How do you restart after you shut down How do you restore the environment to its original state What you do if it all goes wrong!

12. 12 Remember What Programmer’s Don’t Test Time related bugs Unanticipated error conditions Special data conditions Invalid of onscreen information User interface inconsistency User interface everything-else Interaction with background tasks Configuration/compatibility failures Ability to cope with volume, load, and HW faults “Testing” the design prototype might cover some of these.

13. 13 A Closing Thought “Many testers generate too much paper. Remember your primary task - finding bugs and getting them fixed - not designing or filling out forms.” Testing Computer Software, 2nd Edition Cem Kaner, Jack Falk and Hung Quoc Nguyen Be clear as to why you are doing what you are doing… test documentation is a means to an end, not the end!