Functionality Decomposition could hold the key to faster, effective regression testing. Here's how

Frequent software releases are the norm in today’s fast paced world of software development. Testing each and every aspect of new releases with traditional methods may not necessarily be fruitful. While we are constantly on the look out for regression defects, testing features that are not impacted by the changes often becomes redundant. This “test everything” approach, doesn’t yield any bug discoveries and bloats the workload with unnecessary checks, essentially slowing down the entire process.

Functionality Decomposition approach could be the one stop solution to overcome this hurdle. Functionality Decomposition offers a comprehensive approach that helps to effectively optimise the test size per run, which is enabled by focusing on high-impact changes without compromising Test Coverage. This approach helps increase the test effectiveness, identify big ticket items for automation, avoids defect leakages and eliminate significant redundancy in regression testing. The proposed approach is capable of carrying out high impact and targeted regression testing by establishing the cross functional connect between the components or modules. This enables users to manually asses the cross functional impact pertaining to the feature level changes and bug fixes planned for a release.

Following are the steps involved in this approach:

1. Build a Functionality Decomposition Matrix (FDM) across all components / modules by breaking down the features into functionalities, sub-functionalities & micro-sub functionalities (if required) and map the corresponding test cases in the test suite.
2. Build a Cross Functional Mapping document which would be a matrix establishing the cross functional connect between components / modules at a functionality Level (Level 1) and even at a sub-functionality level (Level 2), so that the regression test cases pertaining to the impacted modules alone will be considered for test execution.

The above illustration depicts Functionality Decomposition diagram by breaking down a banking application to functionality and sub-functionalities. The cross functional connect at functionality (Level 1) and sub-functionality Levels (Level 2) are manually established here.

As per the above illustration the banking product has 3 functionalities / modules - Customer Management, Transaction Processing and Credit Score. Customer management and Transaction processing have 2 sub-functionalities each namely Account Management and Payments. The Credit score functionality is having Loans as a sub-functionality.

Following are the Cross Functional Impacts :

• Customer Management is upstream to Transaction Processing
• No cross functional connect exists between Customer Management and Credit Score as well as Transaction Processing and Credit Score.

Hence any changes in Customer Management Functionality will impact only Transaction Processing functionality and it is only required to execute regression test cases pertaining to Transaction processing functionality alone and not required to execute regression test cases pertaining to Credit Score Functionality since it will not yield any defects.

Without the approach of FDM - Level 1, testers would have executed the regression testing for both Transaction Processing and Credit Score Functionalities when there is a code change introduced in the Customer Management functionality which would have ended up running 200 Test cases as part of regression testing. Whereas through the approach of FDM Level 1, we would have executed only 100 test cases as part of regression testing thereby discarding the non-impacted test cases.
This approach at a functionality level leads to an optimized test size per run when compared to regression execution without assessing such cross functional impacts.

Level 2 is a further breakdown of assessing the impact at a sub-functionality levels which leads to further optimization of test size per run

• Account Management Sub-functionality of Customer Management Functionality is up-stream to Account Management Sub-Functionality of Transaction processing.
• Payments Sub-Functionality of Customer Management Functionality is upstream to Payments Sub-Functionality Sub-Functionality of Transaction processing.

Hence for any code change in Account Management sub-functionality of Customer Management functionality, it is required to the execute only regression test cases pertaining to Account Management sub-functionality of Transaction Processing and there is no need to execute the regression test cases pertaining to Payments sub-functionality of Transaction Processing since there is no cross impact between those 2 sub-functionalities and it is not going to yield any defects.

Without the Approach of FDM Level 2, for any code change in Account Management sub-functionality of Customer Management, testers would have executed all 200 test cases in the test suite but by coming up with Level 2 FDM, Testers would have executed only 50 test cases as there is no cross-impact between sub-functionalities and the rest of the test cases will anyways not be yielding any defects. Similarly for any code change in Payments sub-functionality of Customer Management, testers would have executed all 200 test cases in the test suite but by coming up with Level 2 FDM, testers would have executed only 50 test cases. Thus we end up executing a further more optimized test size through level 2 FDM by assessing the cross impact at a sub-functionality level which in-turn will yield in 50% of regression effort savings.

The FDM approach helps in identifying the big ticket items for Automation. Based on the upcoming launches or feature changes, automation testers will be able to prioritize the automation of key functionalities and sub-functionalities based on the re-usability factors which will yield better Return On Investment rather than automating modules which will yield a low ROI due to low re-usability.
FDM approach also helps in determining the pre-requisites upfront in full CD automation and helps in setting the dependencies and in triggering only impacted regression test cases based on the code changes rather than executing the non-impacted Test Cases. This is will help in optimized regression test run.

Benefits:

Below are the benefits on implementing Functionality decomposition approach and the benefits might slightly vary based on the complexity and size of regression test cases applicable in one’s projects.

• One stop solution towards optimized regression test size pertaining to a release. Over 50% of the regression test size can be optimized.
• Improved test effectiveness by performing high impact testing.
• Eliminate redundant testing with no compromise to test coverage.
• Potential scope for head-count reduction if there is an explicit regression team.
• Easy identification of big-ticket items for automation coverage based on future roadmaps
• Helps in identification of overlapping test cases
• Huge scope for regression test coverage expansion (if required to perform P1 to P2 Testing instead of testing non-impacted P0 areas)
• Increased safety net to avoid defect leakages

Disclaimer: The views expressed in this blog are solely those of the author and do not represent the views of Amazon. The information presented in this blog is for informational and educational purposes only. The author provides no guarantees or warranties regarding the accuracy, completeness, or usefulness of any content.

Users acknowledge that any reliance on material in this blog is at their own risk. Amazon does not endorse any third party products, services, or content linked from this blog. Any links or reference to third party sites or products are provided for convenience only. Amazon is not responsible for the content, products, or practices of any third party site.

The author reserves the right to make changes to this blog and its content at any time without notice. This blog may contain the author's personal opinions, which do not necessarily reflect those of Amazon.