When an integrated system is tested, all its specified functions and external interfaces are tested on the software. Every functionality of the system specified in the functions is tested according to its external specifications. An external specification is a precise description of the software behavior from the viewpoint of the outside world (eg. user) has defined function testing as the process of attempting to detect discrepancies between the functional specifications of a software and its actual behavior.
Thus, the objective of function test is to measure the quality of the functional (business) components of the system. Tests verify that the system behaves correctly from the user/business perspective and functions according to the requirements, models, or any other design paradigm used to specify the application. The function test must determine if each component or business event:
- Performs in accordance to the specifications,
- Responds correctly to all conditions that may present themselves by incoming events/data,
- Moves data correctly from one business event to the next (including data stores), and
- Is initiated in the order required to meet the business objectives of the system.
Function testing can be performed after unit and integration testing, or whenever the development team thinks that the system has sufficient functionality to execute some tests. The test cases are executed such that the execution of a given test against the software will exercise external functionality of certain parts. To keep a record of function testing, a function coverage metric is used. Function coverage can be measured with a function coverage matrix. It keeps track of those functions that exhibited the greatest number of errors. This information is valuable because it tells us that these functions probably contain the preponderance of errors that have not been detected yet.
An effective function test cycle must have a defined set of processes and deliverables. The primary processes/deliverable for requirements based function test are discussed.
During planning, the test leader with assistance from the test team defines the scope, schedule, and deliverable for the function test cycle. He/She delivers a test plan (document) and a test schedule (work plan)-these often undergo several revisions during the testing cycle.
Functional decomposition of a system (or partitioning) is the breakdown of a system into its functional components or functional areas. Another group in the organization may take responsibility for the functional decomposition (or model) of the system, but the testing organization should still review this deliverable for completeness before accepting it into the test organization. If the functional decomposition or partitions have not been defined or are deemed insufficient, then the testing organization will have to take responsibility for creating and maintaining the partitions.
The testing organization needs specified requirements in the form of proper documents to proceed with the function test. These requirements need to be itemized under an appropriate functional partition.
Test Case Design
A tester designs and implements a test case to validate that the product performs in accordance with the requirements. These test cases need to be itemized under an appropriate functional partition and mapped/traced to the requirements being tested.
Traceability Matrix Formation
Test cases need to be traced/mapped back to the appropriate requirement. A function coverage matrix is prepared. This matrix is a table, listing specific functions to be tested, the priority for testing each function, and test cases that contain tests for each function. Once all the aspects of a function have been tested by one or more test cases, then the test design activity for that function can be considered complete. This approach gives a more accurate picture of the application when coverage analysis is done.
Test Case Execution
As in all phases of testing, an appropriate set of test cases need to be executed and the results of those test cases recorded. The test cases which are to be executed should be defined within the context of the test plan and the current state of the application being tested. If the current state of the application does not support the testing of one or more functions, then this testing should be deferred until it justifies the expenditure of testing resources.