Search icone
Search and publish your papers
Our Guarantee
We guarantee quality.
Find out more!

All you need to know about testing – preparation, process, evaluation and analysis

Or download with : a doc exchange

About the author


About the document

Published date
documents in English
72 pages
1 times
Validated by
0 Comment
Rate this document
  1. Principles of testing
    1. Testing terminology
  2. Why testing is necessary?
    1. Why do software faults occur?
    2. What do software faults cost?
    3. Exhaustive testing
  3. Fundamental test process
    1. What is the fundamental test process?
  4. Psychology of testing
  5. Re-testing and regression testing
    1. What is re-testing?
    2. What is regression testing?
  6. The 'Oracle Assumption'
  7. Testing in the lifecycle
  8. Models for testing
    1. Test design and test execution
  9. The Waterfall Model, pre-Waterfall, and damage to testing
  10. Economics of testing
  11. Big Bang integration
  12. Top-down integration and Stubs
  13. Bottom-up integration and Drivers
  14. Business process-based testing
  15. Conclusion

There is a lot of terminology surrounding testing, but not until recently has there been an industry standard. A new standard (first published in August 1998) seeks to provide a standard set of terms: BS 7925-i Glossary of Testing Terms. Although a British Standard, it is being adopted by the International Standards Organization (ISO) and will hopefully become an ISO standard within two or three years. An error is something that a human does, we all make mistakes and when we do whilst developing software it is known as an error. The result of an error being made is a fault. It is something that is wrong in the software (source code or documentation - specifications, manuals, etc.). Faults are also known as a defects or bugs but in this course we will use the term fault. When a system or piece of software produces an incorrect result or does not perform the correct action this is known as a failure. Failures are caused by faults in the software. Note that software system can contain faults but still never fail (this can occur if the faults are in those parts of the system that are never used). Another term that should be understood is reliability. A system is said to be reliable when it performs correctly for long periods of time. However, the same system used by two different people may appear reliable to one but not to the other. This is because the different people use the system in different ways. The definition of reliability therefore includes the phrase ?under specified conditions'. When reporting on the reliability of a system it is important to explain under what conditions the system will achieve the specified level of reliability. For example, a system may achieve a reliability of no more than one failure per month providing no more than 10 people use the system simultaneously.

[...] We feel that all developers should use static analysis tools, since the information they can give can find faults very early when they are very cheap to fix Dynamic Testing Techniques 4.1 About Testing Techniques The need for testing techniques In Session 1 we explained that testing everything is known as exhaustive testing (defined as exercising every combination of inputs and preconditions) and demonstrated that it is an impractical goal. Therefore, as we cannot test everything we have to select a subset of all possible tests. [...]

[...] Staffing and Training: Needs Staff required and any training they will need such as training on the system to be tested (so they can understand how to use it) training in the business or training in testing techniques or tools Schedule: Milestones for delivery of software into testing, availability of the environment and test deliverables Risks and Contingencies: what could go wrong and what will be done about it to minimize adverse impacts if anything does go wrong Approvals: Names and when approved. [...]

[...] Sometimes the users are tempted to say to the technical staff: know more about computers than we do, so you do the acceptance testing for This is like asking the used car salesman to take a test drive for you! The users bring the business perspective to the testing. They understand how the business actually functions in all of its complexity. They will know of the special cases that always seem to cause problems. They can also help to identify sensible work-around, and they gain a detailed understanding of the system if they are involved in the acceptance testing. [...]

Top sold for management

Strategic management: Celerita Inc. case study

 Business & market   |  Management   |  Case study   |  07/09/2012   |   .doc   |   13 pages

Iggy's Bread of the World: A Case Study

 Business & market   |  Management   |  Case study   |  12/13/2010   |   .doc   |   4 pages

Most rated for management

Risk management when dealing with foreign exchange (forex)

 Business & market   |  Management   |  Thesis   |  04/08/2009   |   .doc   |   77 pages

Operations and Supply Chain Management

 Business & market   |  Management   |  Case study   |  07/16/2014   |   .doc   |   4 pages