Software Testing
From dis-Emi-A
The main goal of software testing is to find problems before they reach actual users in a production environment. The challenge of software testing is that a software product has many degrees of freedom: It's hard to anticipate the different ways in which users may interact with an application. Users may close windows that are in the middle of doing some kind processing, or they may open multiple forms and edit them simultaneously. Users may use the mouse to click on buttons or they may use keyboard shortcuts. Impatient users may be tempted to hit the same button over and over again in rapid succession in the same way that we all keep pushing the button for the elevator to come sooner. Users may go back and forth among different forms in a way that developers never anticipated.
Today's applications also usually accommodate many users concurrently, which in turn multiplies the potential for problems. Modern software systems also talk to each other and share information. This integration makes it even harder to develop and test systems, since one has to take into account problems that may come up when one system reaches out to another system but finds it unavailable, or intermittently available, or receives corrupted data. In addition to legitimate users, there are also those people who may try to break into a system. Testing for security flaws thus becomes yet another task on the to-do list. One way that software development teams deal with the mounting complexity of creating software is to break functionality into modules, often using thid-party libraries and frameworks. However, this too has its hazards. What happens when a hard to diagnose problem resides deep inside some third-party component?
With all of these parameters to consider, testing presents a tremendous problem of human resources: The testing staff simply does not have the time to fully test the software -- whatever that means. We can only do so much given the amount of time and the number of people available. The testing process presented here is focused on designing and organizing the testing effort to optimize coverage regardless of the time allotments and production pressures.
This material is taking primarily the view of a dedicated test designer, though the material is equally useful for a programmer, whether writing test code or designing the primary code.
Contents |
Introductory Topics
- Goals of testing
- What the testing process should be striving to do, and what it should not, or cannot, be doing
- The role of the test designer
- The definition of this position and what role they play inside a complete development process
- Understanding Requirements
- The structure and reading of software requirements
- Understanding Code
- The structure and reading of software code
- Test Prioritization
- How to choose what to test and how to allot time to those items. This forms the basis of the Test Plan
Test Design
- Test Plan
- The organization of all assets into a single living document
- Equivalence Classes
- Classification and splitting of input and output
- Test Suite Construction
- How to build the test suite for a particular feature or module
- Test Suite Prioritization
- What to focus on within an individual test case
Specialized Testing
- Compatibility Testing
- An extension to testing which has a specific test suite checked against many system configurations.
- Stress Testing
- Refers to both the execution of test cases in extreme system conditions, or the highly repeated execution of specific test cases.
- Failure Mode Testing
- An additionally layer of testing from the view of failure modes; originating in the manufacturing sector
- Usability Testing
- A form of interface evaluation used to improve the quality of the human-computer interaction
- Security Testing
- Specialized testing from the view of system security.
References
- Testing artifacts
- Items produced and used during testing
- Web Contest Test Suite Example
- An example of a test suite for a simple web contest form
