| Software Testing: | | | | Requirements speciÞcation; |
| What is Software Testing? | | | | Design speciÞcation; |
| There are many published definitions of software | | | | Users guide; |
| testing, however, all of these definitionsboil down | | | | Operations guide; |
| to essentially the same thing: software testing is | | | | Installation guide. |
| the process of executing software in a controlled | | | | Features to be tested |
| manner, in order to answer the question "Does | | | | Identify all software features and combinations of |
| the software behave as specified?". | | | | software features to be tested. Identify the test |
| Software testing is often used in association with | | | | designspeciÞcation associated with each feature |
| the terms verification and validation. | | | | and each combination of features. |
| Verification is the checking or testing of items, | | | | Features not to be tested |
| including software, for conformance | | | | Identify all features and signiÞcant combinations |
| andconsistency with an associated specification. | | | | of features that will not be tested and the |
| Software testing is just one kind of verification, | | | | reasons. |
| which also uses techniques such as reviews, | | | | What does it take to build the best Test |
| analysis, inspections and walkthroughs. Validation is | | | | Organization. |
| the process of checking that what has been | | | | Attitude |
| specified is what the user actually wanted. | | | | Conviction |
| · Validation: Are we doing the right job? | | | | Killing instinct to dig out and deliver |
| · Verification: Are we doing the job right? | | | | Culture |
| The term bug is often used to refer to a problem | | | | Work towards passion and not money |
| or fault in a computer. There are softwarebugs | | | | Work towards technology, sharing and learning |
| and hardware bugs. The term originated in the | | | | Power of Ethics |
| United States, at the time whenpioneering | | | | What we do: |
| computers were built out of valves, when a | | | | Building silicon with xyz architecture.putting on |
| series of previously inexplicablefaults were | | | | e-linux, building an image and then putting on top |
| eventually traced to moths flying about inside the | | | | of it. |
| computer. | | | | Wireless network support followed by release. |
| Software testing should not be confused with | | | | Some fun time: |
| debugging. Debugging is the process ofanalyzing | | | | 1. Reporting all passes and sending the report |
| and locating bugs when software does not | | | | without actually executing the tests. The product |
| behave as expected. Although theidentification of | | | | getting backfired from the customer premises. |
| some bugs will be obvious from playing with the | | | | The industry does not spare mistakes, and this |
| software, a methodicalapproach to software | | | | one can be worst. |
| testing is a much more thorough means of | | | | 2. |
| identifying bugs. | | | | Templates: |
| Debugging is therefore an activity which supports | | | | Test Plan/ Test Case |
| testing, but cannot replace testing. | | | | Priority and Severity states and trade-offs |
| However, no amount of testing can be | | | | between them: Mapping to our jargon Blocker and |
| guaranteed to discover all bugs. | | | | Crasher. |
| Other activities which are often associated with | | | | Release Blockers: Last Severity 1 but 1st priority |
| software testing are static analysis anddynamic | | | | BLOCKER (from our perspective): |
| analysis. Static analysis investigates the source | | | | Examples of Extreme Cases: |
| code of software, looking forproblems and | | | | Has anyone come across a Microsoft Product |
| gathering metrics without actually executing the | | | | which specifies "Win" instead of "Windows, but |
| code. Dynamic analysislooks at the behaviour of | | | | you won't be able to find it. Why, because as a |
| software while it is executing, to provide | | | | Tester you might be logging it as a last severity, |
| information such as | | | | but for the Vendor/Microsoft it becomes priority |
| 4.2 Outline | | | | 1/BLOCKER. |
| A test plan shall have the following structure:a) | | | | Test Blockers: Is a typical case in which you log |
| Test plan identiÞer;b) Introduction;c) Test | | | | the crash bug(Blocker), but it is taken as a last |
| items;d) Features to be tested;e) Features not to | | | | priority by the management. Why??? |
| be tested;f) Approach;g) Item pass/fail criteria;h) | | | | In one of the instances, a vendor had released a |
| Suspension criteria and resumption requirements;i) | | | | version of OS, which specified that after installing |
| Test deliverables;j) Testing tasks;k) Environmental | | | | the OS on a new machine, pull out the cable to |
| needs;l) Responsibilities;m) StafÞng and training | | | | the HDD and the OS will crash and would be |
| needs;n) Schedule;o) Risks and contingencies;p) | | | | completely un-recoverable and would be required |
| Approvals. | | | | to re-install the entire OS again. Still the vendor |
| The sections shall be ordered in the sp | | | | released, Why? Because the vendor would not |
| Test items | | | | expect the end user to do it. |
| Identify the test items including their version | | | | Examples of Extreme Cases: S 1 but last priority: |
| revision level. Also specify characteristics of their | | | | Crash |
| transmittalmedia that impact hardware | | | | Effective Execution and Reporting: |
| requirements or indicate the need for logical or | | | | Importance of Logs |
| physical transformations beforetesting can begin | | | | Importance of logging with respect to not logging. |
| (e.g., programs must be transferred from tape to | | | | Automation: What takes it to implement. |
| disk). | | | | The Road Ahead: |
| Supply references to the following test item | | | | Notepad to write java files to code generating |
| documentation, if it exists: | | | | wizards. Importance of testing. |