We all know testing is an essential step in the application development process. But sometimes testing can feel like your team is just throwing bricks against a wall and seeing when the wall breaks. Wouldn’t it make more sense to be measuring the integrity of the wall itself before chucking things at it?
Consider load testing, where you synthesize a bunch of virtual users and throw them at the application. You’re looking to see how well the application deals with the elasticity and scalability demands. If your team is doing load testing without first testing the structural integrity of the application, however, they’re putting the cart before the horse.
Before animating zillions of synthetic users, let’s first examine how the application interacts with one user, with itself, and with other systems in the ecosystem. How is that user’s data being transferred around the application? Is it getting stuck in a coding loop that could lead to problems down the line?
Next, what about security? A key part of structural integrity is application integrity, which revolves around the security and performance of the application source code. Security testing might focus too much on input validation and not enough on solid architectural design and proper control of access to confidential data.
Architecture: This is often the most important piece of a custom application. A study published by Addison-Wesley Professional found over 50 percent of security issues are the result of poor architectural design. That said, I’ve seen outmoded applications that still have a pretty good multi-tier, secure architecture. Give those guys a pat on the back! Even though the application overall is outmoded, the ability to leverage a good security layer in a multi-tier architecture — where every tier does its own validation and is independent of the other — is a crucial advantage. Using CAST’s analysis tools, you can determine the architectural quality, security risk, and adherence to the organization’s standards, and measure improvements to it.
Data access: After the proper architecture is in place, the team needs to ensure data can move around smoothly, and only go or rest where it needs to, and nowhere else. Using CAST’s analysis tools, for example, the development team can link all the places where the application is interacting with the organization’s data storage, such as a database or a persistence layer. Any place where the application is interacting with the organization’s data store in a way which is unexpected or otherwise “off the reservation” can be highlighted. Often, CAST finds that the application is directing data from too many places. For example, an application’s user interface layer should never be accessing the database. It should always go to a dedicated data access layer. And yet I see this error all the time. Now suppose you have a customer table with 20 different routines which are inserting, updating, or deleting data—well, that’s also a problem! The application should have a single component (or routine) that interacts with the customer table, and all other routines use it to centralize the system’s data actions. Unless you can visualize the structural integrity of the application, however, you’ll never know if the team is adhering to that best design practice.
These types of issues might seem minor. But left undiagnosed, they can lead to a poorly performing application that’s taxing system performance and driving up maintenance and other costs. Moreover, load testing done at the later phases of the application development process, before launching an update, or before lighting up a migration (i.e., internal data center to the cloud), won’t find any of these issues unless they are load intolerant.
It will just tell you that the system doesn’t scale at some targeted level, and then it’s up to the team to go figure out why and fix it. If your team tests the structural integrity of the application before the load testing phase, latent performance, architectural, security, and other issues will become visible before the first synthetic user is even generated.