Complexity Means More Testing

As applications complexity goes up, test times go up

Complex portfolios have multiple interrelationships among applications. If a change is contained within an application, then the domain that needs to be tested is only that application. But this is seldom the case.  Mostly, the change impact extends into a complex, interrelated network of applications, and then it is imperative that the tester tests some, if not all, aspects of the entire network of applications. Naturally, testing will be more costly and time consuming in this case.  

The basic rule of thumb in the industry is that as applications complexity goes up, test times go up, because there is more stuff to test against.  

There is this story about a particular web commerce operation of a major service provider that does the rounds during many discussions on how complexity in applications can make testing a never ending process. When this service provider started from scratch as a new business on the web, they could roll out new business functionality every three to four weeks. After a year and a half, it had built up enough system complexity that it was taking five to seven weeks to roll out new functionality. The additional time was almost completely attributable to longer testing times due to a more complex environment.  

And as the story goes, the problem was finally resolved by completely scrapping the existing system and building a new one that had reduced complexity and unnecessary diversity through standardization, consolidation and rationalization/simplification.  The service provider also ensured that testing was a part of the application development life cycle and not something that was done at the end for validation sake.