Develop test scenarios
Decided to share a scheme of development of test cases enjoyed myself. Do not pretend to completeness and uniqueness, now I am completely satisfied with this approach. Maybe someone will be able to extract from it something useful for themselves. Actually, the process of developing test scenarios consists of four steps:
- Determining the requirements for software
- Grouping requirements by priority
- Use-definition of cases
- Development of test scenarios based on specific use-cases
1. Determining the requirements for software
For the start of the test you need to know and understand the requirements for the developed product. Sources of requirements are:
- Specification
- Specifications (Software Requirements Specification, Design Specification, etc.)
- Project Team
- Customer
- End-users
The use of specific sources depends on their availability and organization of the process.
2. Grouping requirements by priority
Once requirements are defined, it makes sense to group them by priority. There are three priority levels:
- The main requirements
- Important Requirements
- Additional Requirements
Make it useful for the following reasons:
- In case of shortage of resources for testing, you first need to check the main and important requirements. For example, for beta-testing versions of the additional requirements can be ignored.
- As a rule, the implementation of the requirements and begins with the principal. Ie testing in the first place will do the principal and essential requirements. Thus begin to develop test scripts must be with the main requirements. Since they will need to check first.
3. Use-definition cases
For convenience, the development of test scripts is helpful to first identify all possible scenarios. You can do this by using the claim. Ie take the call and analyze scenarios for what it can "generate". It is also often indicated in the specifications of use cases, though not all possible. Development of test-based cases use-cases – one of the easiest methods. It does not need to know what threats exist to the quality of software, what are the classes of defects, etc. On the other hand, this method is quite effective, because it is based on a scenario to end users.
When defining use cases is useful to be guided by the following ideas:
- The documentation indicates not all use-cases. For example, does not specify general requirements are obvious.
- It is useful to think of how to work with the product end-users.
- It is desirable to know all the business-cases, ie, the tasks to be solved by the developed product.
- It is also sometimes helpful to look at similar products from other manufacturers.
Steps for determining the requirements and use-cases not necessarily have to be formalized. Enough to develop test-cases take a piece of paper and pencil and jot down a list of requirements and use-cases, which will be written in these test-cases.
4. Development of test scenarios based on specific use-cases
Once identified use-case, you can begin to develop test scripts. Develop test-cases done in three steps:
- Isolation of the boundary values and equivalence classes.
- The list of checks on the basis of classes and boundary values.
- Drawing up a list of checklist test-cases to enter into it the results of the tests.
Developed scenarios in checklist conveniently grouped according to use-cases that they test. In addition, when working with test scripts is useful to adhere to the following recommendations:
- Drill test-cases. No need to detail every step of the paint. It’s too expensive. Takes a lot of time writing. More or less enough detail to fix what you need to check (but qualified testers to be higher.) In other words, test-case detail should not be excessive.
- For the convenience of parallel operations for each component or type of testing makes sense to create a checklist. It will not cause problems when editing the same document by multiple people. In addition, such checklist will be to assess the state of each component separately. Also, with such an organization would be easier to fix checklist every part of the tester works.
- Form of the test-cases can be any: excel-table word document, etc. The main form of storage to be comfortable and not create unnecessary problems.
The result is a link: Requirement > Use-case > Test-case. The next in the chain may be defective. If, for each link in the chain store ID requirement will be to monitor the current state requirements (eg degree are tested and the number of defects in the implementation).
Since this scheme is tied to the use-cases, then it is best suited for functional tests. For other types of testing may have to come up with something else.
See Also