So, why is SOA and SOA using cloud computing so different that we need a different approach to testing? As I've been stating here on this blog, many of the same patterns around testing a distributed computing system, such as a SOA, are applicable here. We are not asking you to test that differently; only to consider a few new issues. There are some clear testing differences to note when cloud computing comes into the mix.
First, we don't own nor control the cloud computing-based systems, thus we have to deal with what they provide us, including the limitations, and typically can't change it. Thus, we can't do some types of testing such as finding the saturation points of the cloud computing platform to determine the upward limitations on scaling, or attempt to determine how to crash the cloud computing system. That type of testing may get you a nasty e-mail. Or, white box testing the underlying platform or services, meaning viewing the code, is also, not supported by most cloud computing providers, but clearly something you can do if you own and control the systems under test.
Second, the patterns of usage are going to be different, including how one system interacts with another, from enterprise to cloud. Traditionally, we test systems that are on-premise, and almost never test a system that we cannot see nor touch. This includes issues with Internet connectivity.
Third, we are testing systems that are contractually obligated to provide computing service to our architecture, and thus we need a way to validate that those services are being provided now, and into the future. Thus, testing takes on a legal aspect, since if you find that the service is not being delivered in the manner outlined in the contract, you can take action.
Finally, cloud computing is relatively new. As such, IT is a bit suspicious about the lack of control. Rigorous and well-defined testing, will eliminate many of those fears. We must be hyper diligent to reduce the chances of failure, and work around the fear of what's new.
Leave a comment