Software Testing 101


Published on

A presentation to explain the goals and methods of testing to a variety of colleagues who help with testing on certain projects...

Published in: Technology
  • Be the first to comment

Software Testing 101

  1. 1. Or… how to find and kill bugs!
  2. 2. Software Testing is NOT: <ul><li>Just clicking around! </li></ul><ul><li>To prove that the program is error free </li></ul><ul><li>To establish with confidence that the software performs its functions correctly and does its job fully </li></ul><ul><li>Designer/Developer bashing </li></ul><ul><li>Ever completely finished… </li></ul>
  3. 3. Software Testing IS… the task of locating, clearly defining and correcting errors. <ul><li>Without a proper definition of testing, the leader might describe a successful test run as one which proves the program is error free and describe an unsuccessful test as one which found errors. As is the case with the testers themselves, this mind-set is actually counter-productive to the testing process. </li></ul>
  4. 4. Eight Basic Testing Principles <ul><li>Define the expected output or result. </li></ul><ul><li>Don't test your own programs. </li></ul><ul><li>Inspect the results of each test completely. </li></ul><ul><li>Include test cases for invalid or unexpected conditions. </li></ul><ul><li>Test the program to see if it does what it is not supposed to do as well as what it is supposed to do. </li></ul><ul><li>Avoid disposable test cases unless the program itself is disposable. </li></ul><ul><li>Do not plan tests assuming that no errors will be found. </li></ul><ul><li>The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module. </li></ul>List courtesy of: http ://
  5. 5. Positive and Negative Testing <ul><li>To satisfy its definition, testing must accomplish the following goals: </li></ul><ul><li>1. POSITIVE TESTING: Do ‘normal’ user actions, and find cases where the program does not do what it is supposed to do. </li></ul><ul><li>2. NEGATIVE TESTING: Do ‘abnormal’ actions to find cases where the program does things it is not supposed to do. </li></ul>
  6. 6. Basic Test Plans <ul><li>Outline provided in test plan template… trying to standardize this information! </li></ul><ul><li>This meets the “defining expected results” principle, which is #1 for a reason. </li></ul><ul><li>Start writing these test plans BEFORE coding is done. </li></ul><ul><li>You are the people most familiar with these products – you know how they should work. </li></ul><ul><li>Test plans also help capture the current state and can just be modified when future changes are made. </li></ul><ul><li>Test plans MUST include negative cases (principle #4). </li></ul><ul><li>Make them as re-usable as possible (principle #6). </li></ul>
  7. 7. Example 1: <ul><li>Detailed test plan, with notes and data entries – note the expected results and reasons for failure, and that normal testing includes positive and negative cases. </li></ul>
  8. 8. Example 2: <ul><li>Sometimes you need a less detailed plan that highlights positive tests. This can be more of an outline, with specific areas where there are a lot of issues stepped out more clearly. </li></ul>
  9. 9. Bugs Everywhere! <ul><li>FACT: Some test cases must fail, or you are not testing correctly! (principle #7) </li></ul><ul><li>A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. </li></ul><ul><li>ANYTHING that does not work as expected is a bug – from capitalizations to run-time errors. </li></ul><ul><li>It is NOT up to the tester to decide how important a bug is, so every one must be documented. </li></ul><ul><li>Some bugs will be rejected (never fixed) so don’t get too attached to them… </li></ul><ul><li>But do fight for the ones that you think are showstoppers. </li></ul>
  10. 10. What happens when I meet a bug? <ul><li>FREEZE! Take a screen shot </li></ul><ul><li>if possible, and immediately </li></ul><ul><li>recollect any information you </li></ul><ul><li>just entered. </li></ul><ul><li>You should be writing or </li></ul><ul><li>repeating test plan steps, so make </li></ul><ul><li>sure you are in the right spot and steps up to that point are noted. </li></ul><ul><li>If the program crashes, restart it. If not, try IMMEDIATELY to make the bug happen again and document the steps clearly. </li></ul><ul><li>Try to a reasonable length to replicate the bug, if you can’t then still track it but tag it “not replicable”. </li></ul><ul><li>Note the bug on the test plan and track it… </li></ul>
  11. 11. Tracking Bugs <ul><li>If some test cases must fail, then keeping track of the bugs is essential! </li></ul><ul><li>We are working on a system to keep track of all bugs, for now we will be using Pivotal Tracker. </li></ul><ul><li>After this meeting, I’ll send you a blank test plan and invitation to use this software. </li></ul><ul><li>Quick walkthrough… </li></ul>