The following documentation descriptions are meant only as an introduction to the topic of testing documents. Different organizations refer to these documents by different names and the documents can be much more or less complex depending upon the needs of the organization and the complexity of the application. What is essential is that the following information needs to exist in some capacity in order to ensure that thorough, trackable, and measurable software testing occurs.
What is a Test Strategy?
A Test Strategy is a high-level document that defines the project’s approach to testing. It is developed from the Business Requirements and is created at the same time as the Software/Product Requirements. Some organizations combine the Test Strategy with the Test Plan. The contents of a Test Strategy include the business context and challenges, roles and responsibilities, communications, status reporting, deliverables, defect management, tools and standards to employ, risk management, change management, and metrics to measure.
What Is a Test Plan?
The Test Plan is derived from the Software/Product Requirements and defines what to test and when. It will specify the team or team member to execute the test. There can be multiple Test Plans in a development life cycle. In a waterfall project, there may be a Test Plan for each type of testing, for example. In an Agile project, there may be a Test Plan for each Sprint, again for example.
What are Test Cases?
Test Cases define the functionality to test and all the variations of events that can occur within the functionality. Test Cases reflect how the product/application is supposed to work (test-to-pass), and how it works with unexpected or invalid events (test-to-fail). In a game, test-to-fail test cases could be the main character attempting to walk through a wall. In a data entry screen, a test-to-fail test case could be an attempt to enter an incorrect postal code or no postal code, for example.
Developing Test Cases requires logical thinking, creativity, and attention to detail. It requires the type of thinking that goes along with “How can I break this application? Mwah-ha-ha” while applying structured, industry-reasoned, and accepted approaches to derive the minimal number of test cases to thoroughly test the software.
Test Cases include the following information:
- A unique identifier for tracking purposes
- What is being tested – module, functionality, for example
- Purpose of the Test Case
- Environmental & procedural requirements
- Test case interdependencies
- Input data – valid and invalid input values
- Expected results for each input data
- Pass/Fail – completed by the Tester
- Defect Description – completed by the Tester