Functional Decomposition Methodology

The The Functional Test Decomposition Methodology or The Functional Test Decomposition Framework (FD Framework) is an effective QA testing process framework designed by Srikkanth Danthala, a QA Test Specialist from SCL Technology Solutions, based in Toronto, Canada. The purpose of implimenting the "Functional Decomposition Test Framework" or the "FD Framework” into a projected Testing effort, is to address the most common challenges and Issues of both Test Planning and Test Execution phases of the Software Test Life cycle.
Introduction to the Functional Test Decomposition Framework
The Functional Decomposition Methodology (FD Methodology) framework, originally designed by Srikkanth Danthala,a QA Test Specialist from SCL Technology Solutions, a division of Sribha Consultants Ltd since 2003, has been defined through the idea and workflow of the WBS (Work Breakdown Structure) technique in Project Management. The FD Methodology addresses many common challenges and Issues encountered in almost all Test Planning, Test Execution and Test Automation phases in a Testing Life Cycle.
The functional decomposition method is initiated by identifying the main Functional Areas of the application/system under Test; the functional areas are then decomposed into functional components and functional components into functionalities, subsequently test scenarios are analyzed, and the number of test cases to be written for each of the functionalities identified is finalized. Initially the FD framework is build separately by each QA team member to address individual functional areas, after all functional areas are completed, they are combined together to complete the FD framework
This approach will help the Test Manager to escalate accurate estimates to the Project Management Team for the time required, resources needed and work effort estimated to complete the test case creation effort. This will also help the Testing Team to prioritize the Test Case execution as per the Business input.
The Objective of the Functional Test Decomposition Framework
Complete Test Coverage
The implementation of FD framework requires in-depth analysis of the each and every functional area and functional component of the application/system under test, every component and functionality needs to be addressed and incorporated into the FD framework. The FD structure makes it evident if any of the functional areas/functional components/functionalities are been missed, this ensures complete test coverage
Accurate Estimates
As shown in the figure below, the FD decomposition ultimately ends up at the test case level, which enables the QA team to analyze and escalate to the project management more accurate estimates for the number of test cases that are planned to be created for the Test effort and, a more accurate estimate on work effort and the amount of resources required based upon the time allocated
Identify Redundancy and avoid Duplication of Test effort
The FD framework lays out all the functional components and functionalities associated in the application/system under test; this enables the Testing team to analyze the redundant functional components and functionalities. This will help the Testing team to avoid duplication of work effort in terms of creating test cases or developing automation test scripts for validating the same functionality. FD methodology proposes the reuse of Test cases and automation test scripts to validate redundant functionalities; any single modifications incorporated or enhancements made will address multiple dependent functional components.
Ease to Incorporate frequent change requests
Change requests are very frequent in any Software development life cycle, the FD framework establishes traceability of the Functionality with the Functional components and the Functional Areas, which enable the Testing team to easily incorporate the new functionality and also identify test cases which need to be enhanced to address the validation of the change request.
Prioritization of Test Execution
Functional areas/functional components/functionalities can be prioritized as “Critical, High, Medium and Low” based on Business input. A process of Risk based testing approach (See Section 3.2) can be followed during test execution to validate the most important functionality first, this helps to avoid risk in a business perspective in a event of a time constraint.
Structured Test Automation Framework
The FD framework can be incorporated into any industry standard test management tool; this will enable the testing team to establish traceability of test cases, business requirements, functional requirements and defects with its respective functional areas, functional components and functionalities.
Test Management and Traceability
If Test Automation is scoped in the Testing Phase, the Testing team would be able to use the same FD framework for structuring the Test Automation effort; FD Methodology emphasizes on building decomposed Automation test scripts, compiled modules and integrate them into single master scripts, so that they can be easily managed during developing, execution and as well as the reporting phases of Test Automation. Also, at any given point of time it would be easy to incorporate script enhancements and additions. For validating redundant functionalities, automation test scripts can be reused.
Success Factors
Training
As this approach is not yet industry popular, a significant amount of training is necessary to the QA Team members to work in compliance with the Methodology. If is very important that the QA Analysts and QA Testers understand the decomposition process, as the FD structure is build separately for each functional area separately and then integrated together to complete the framework.
Understanding of the Application Functionality & System
As this approach is not yet industry popular, a significant amount of training is necessary to the QA Team members to work in compliance with the Methodology. If is very important that the QA Analysts and QA Testers understand the decomposition process, as the FD structure is build separately for each functional area separately and then integrated together to complete the framework.
Business Support
In order to property categorize the Business/Functional Areas of the application under Test and also to correctly prioritize the Test Case Execution, the testing team would need to communicate very closely with the Business Team. It’s important that the Business team provides the required support during the Test Planning stage.
Other frameworks
Refinements and variations
*Unified Process - The generic Unified Process, and ...
*Open Unified Process (OpenUP) - An open source software development process, created as part of the Eclipse Process Framework (EPF) project.
Competing frameworks and methodologies
The referenced methodologies and / or frameworks below do not necessarily compete with RUP on all fronts, but do so to differing degrees
* Cleanroom Software Engineering
* Dynamic Systems Development Method (DSDM)
* ICONIX Process is a lightweight, agile subset of the RUP practices
* Extreme Programming
* Microsoft Solutions Framework (MSF)
* Oracle Unified Method (OUM)
* Tenstep Project Management
* OpenUP is an OpenSource lightweight agile version of RUP supported by IBM Rational, Number Six Software and others
* Personal Software Process (PSP)
* Scrum

Main Menu

See Also

Main Menu