Function (Integration) test is usually the first test phase that a test organization is responsible for during any given release. Requirements based Function Test is one approach to Function (Integration) test - it is a powerful and effective testing approach, which will significantly reduce the number of undetected defects (faults) being released into production. The premise is that a well-formulated set of functional requirements give the Test Designers (see .Testing and The Role of a Test Designer Tester.) a definitive bases for test case design.
What is Function Test? "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, storyboards, 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 be presented by incoming events / data, moves data correctly from one business event to the next (including data stores), and that business events are initiated in the order required to meet the business objectives of the system.
What is a Requirement?
A requirement is a capability or function that must be delivered by a system component or components. A functional requirement is a specific business need or behavior as seen by an external user of the system.
Test Cycle for Requirements based Function Test
An effective test cycle must have a defined set of processes and deliverables. The primary processes / deliverables for requirements based Function test are: Test Planning, Partitioning / Functional Decomposition, Requirements Definition / Verification, Test Case Design, Traceability (Traceability Matrix), Test Case Execution, Defect Management, and Coverage Analysis. Which processes and deliverables apply to any given testing situation are dependent on available resources (people, source materials, time, etc.) and the mandate of the test organization.
During planning the Test Lead with assistance from the test team defines the scope, schedule, and deliverables for the function test cycle. The Test Lead delivers a Test Plan (document) and a Test Schedule (work plan) - these often undergo several revisions during the testing cycle.
Partitioning - Functional Decomposition
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. There are several commercial, shareware, and freeware products available that aid in the functional decomposition of a system and the formal delivery of the functional partitions.
Requirements Definition / Verification
Requirements definition is often the weakest deliverable in the software development process. Many development shops go directly from software concept to functional specification or worse from software concept to code without any preliminary software design deliverables. The Testing Organization needs these requirements to proceed with Function test, so if the development team is not going to deliver the requirements for verification by the testing team then the Test Team must create its own set of testable requirements. These requirements need to be itemized under the appropriate functional partition.
Test Case Design
The Test Designer / Tester designs and implements test cases to validate the product performs in accordance to the requirements (see .Testing and The Role of a Test Designer Tester.). These Test Cases need to be itemized under the appropriate functional partition and mapped / traced to the requirements being tested.
Traceability (Traceability Matrix)
Test Cases need to be traced / mapped back to the appropriate requirement. Once all aspects of a requirement have been tested by one or more test cases then the test design activity for that requirement can be considered complete. A common misconception made during this process is that all test cases that exercise a particular requirement should be mapped to that requirement - only those test cases that are specifically created to test a requirement should be traced to that requirement. This approach gives a much more accurate picture of the application when coverage analysis is done - failure of a test case does not mean failure of all the requirements exercised (as opposed to tested by) the test case.
Test Case Execution
As in all phases of testing the appropriate set of test cases need to be executed and the results of those test cases recorded. Which test cases 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 requirements then this testing should be deferred until it does justify the expenditure of testing resources.
As in all phases of testing any defects (see .Testing and The Role of a Test Designer Tester.) detected during test execution need to be both recorded and managed by the testing organization. During Function test each defect should be traced to a specific requirement or requirements that are not performing to specification.
During Function test a periodic progress report should be delivered by the test organization to the project team. The bases for this report will be a coverage analysis of the requirements against test cases and outstanding defects. The objective of this analysis is to determine the percentage of the requirements that are: deemed to be untested, performing to specification (executed successfully), and not performing to specification (defects).
There are several commercial, shareware, and freeware products available that can be used to expedite the creation of all these deliverables while streamlining the testing process.
Managing Function Test
Function (Integration) testing can be an overwhelming task for an inexperienced testing organization. To assure success at the test organization and project level the scope of the testing effort needs to be rigorously defined and followed. The definition of the scope needs to be understood by the test organization and the project team - if the scope of the testing effort needs to be redefined then this must be communicated. A realistic work plan with clear deliverables and dependencies needs to be drafted and updated when any event occurs that impacts the work plan in a positive or negative fashion. The key to success is to manage the expectations of the testing team and the project team while clearly communicating the current status of the testing effort on on-going bases.
David W Johnson, A Senior Computer Systems Analyst with over 20 years of experience in Information Technology across several industries having played key roles in business needs analysis, software design, software development, testing, training, implementation, organizational assessments, and support of business solutions. Developed specific expertise over the past 10 years on implementing "Testware" including - test strategies, test planning, test automation, and test management solutions. Experienced in deploying immediate solutions Worldwide, that improve software quality, test efficiency, and test effectiveness. This has led to a unique combination of technical skills, business knowledge, and the ability to apply the "right solution" to meet customer needs. Contact David at DavidWJohnson@Eastlink.ca
All articles are copyrighted and owned by Dev Bistro or their respective owners, all rights reserved. No material may be reproduced electronically or in print without written permission.