What causes Technical Debt?

Outdated design: Technical design that does not satisfy the Point-of-Arrival architecture. It means that if an application is built with an outdated or Point-of-Departure architecture which does not align with organizational blueprint, then the application will accumulate technical debt. Though such an application may have a quick time to market, it will require a rewrite of the code in future to meet the latest architecture standards. The more time the application takes to adapt to the latest architecture, the more effort will be required later for the rewrite. The more time the application will be available to the customers, the more difficult it will become to migrate the application and the customers to the new code.

Low code coverage: Code coverage is a measure used to describe the amount of code that gets executed during testing. The product with higher code coverage has less risk of uncovering unknown defects as compared to the application with low code coverage. If during Sprint Execution, the team does not spend time to improve the code coverage, and if the product is implemented with low code coverage, then there is an increased risk of experiencing undetected problems that may lead to poor customer satisfaction and brand damage. Moreover, when more features are added to the product, it is more difficult and time-consuming to rewrite the code and increase code coverage.

Lack of automated regression test suite: Regression testing is a type of testing that ensures that new features or enhancements to the product, or any new interfacing product does not impact the earlier working piece of software or product. These tests include validation of all past functionality that may be affected with the new changes. There are two ways to perform regression testing – manual and automated. In most cases, automated testing is more beneficial than manual testing to conduct regression testing. The reason being that the manual regression testing is very tedious and time-consuming. Moreover, each time there is a need to perform regression testing, any time you make changes to the code – add new features, enhance existing features, or make configuration changes, you will need to spend a large amount of time and effort with manual testing. Test automation makes the regression testing process very efficient. The test scripts can be automated once, and the automated test suite can be reused each time a change is introduced in the system. The test automation also ensures consistent results, reducing the possibility of human error. Though it takes time to automate the test scripts to start with, the benefits of having automated test suites overweigh the time and effort that is originally spent to create them.

Lack of regression test suites accumulate technical debt for the team. If new features are built without spending any time to create the regression test suite or to update the existing regression test suite, then it becomes more time consuming to automate the test scripts in future. The more you wait to create or update the regression test suite, the more features exist without automated tests, and the more time it takes to regression test the product.

( To be continued…)

Learn SCRUM Framework with an effective handbook. “The Basics Of SCRUM”

Click for Preview. Buy Now!

Posted in Scrum

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: