Functional testing includes all test techniques and methods that are used to test the observable input/output behavior of a test object. Functional test cases are built using the “black-box” technique described in section 5.1. The functional requirements are the test basis for the planned system behavior.
Functional requirements and functional suitability
Functional requirements13 specify the behavior expected of a system or system component—in other words, they describe “what” the system (or component) is designed to accomplish, and implementing them is the basic prerequisite for a functioning system. Whether and how well a component fulfills its functional requirements is called its “functional suitability”, which is one of the quality characteristics defined in the ISO 25010 standard [ISO 25010].
The following example lists some of the functional requirements for price calculation in the VSR-II system:
Case Study: Functional requirements of the VSR-II DreamCar module
| R 100: | The user can choose a model for configuration from the current catalog |
| R 101: | The deliverable extras will be displayed for the selected model. The customer can select any of these to add to the configuration. |
| R 102: | The price for the current configuration (model plus extras) will be calculated according to the current price list and displayed in real time |
| R 103: | For the currently selected vehicle, only extras that are part of a deliverable configuration will be displayed. Non-deliverable extras for the current configuration will be grayed out. |
Functional test cases
Tests that check functional attributes require at least one test case for each functional requirement. Suitable tests for verifying R102 “calculate total price” (see above) might look like this:
Case Study: Requirement-based functional test cases
| T 102.1: | A vehicle model is selected; the price according to the sales manual is displayed |
| T 102.2: | An extra is selected; the vehicle price is increased by the price of this extra |
| T 102.3: | An extra is deselected; the vehicle price is reduced by the price of this extra |
| T 102.4: | Three extras are selected; these are discounted according to the specifications |
Usually, more than one test case is required to test a functional requirement. In our example, Requirement 102 includes a whole series of price calculation variants that need to be covered by appropriate test cases (102.1—102.4). These cases can be fine-tuned and augmented using other black-box techniques such as equivalence partitioning.
The important thing is that, once the predefined test cases (or a subset thereof as defined in the test specifications) have been run without revealing any faults, the functionality is taken to be correctly implemented.
Functional testing takes place on every test level. For component and integration testing, the test basis comprises the components’ technical specifications, the specification of each component’s interfaces (its API), or white-box information. For system and acceptance testing, the test basis is made up of functional system requirements (as illustrated in the example above).
Use-case and business-process-based testing
If a software system is designed to automate or support a specific business process (as in the example above), use-case or business-process-based testing techniques are also suitable.
Case Study: Testing a business process
VSR-II supports dealers during the sales process, which might take place as follows:
- The customer selects an available model that is of interest
- The customer looks at equipment and pricing options and configures a vehicle accordingly
- The salesperson suggests various financing options
- The customer makes a decision and places an order
Business process analysis
Business process analysis is usually conducted as part of requirements analysis and shows which business processes are relevant, how often they occur and in which context, which people, companies and external systems are involved, and so on. This information forms the test basis, which is then used to create testing scenarios that emulate typical business events. These test scenarios are prioritized according to the typical frequency and relevance of these events, and also according to the risk factor attached to the corresponding processes.
While requirements-based testing is focused on individual system functions (for example, transmitting an order), business process-based testing checks sequential procedures (such as a sale made up of vehicle configuration, agreeing a purchase, and transmitting the order) using sequences of tests.
As well as the basic select, configure, purchase functionality of our sample VSR-II system, user acceptance is also based on how user-friendly a system is. User-friendliness (or usability) is judged by how easy the system is to use, how quickly it “answers”, and how clear the output is that it delivers. In other words, alongside functional criteria, we also have to test and validate non-functional system attributes.
Leave a Reply