For software development, cloud computing has opened the all-new horizons with all the benefits it has to offer. The game is not limited to building a state of the art software, but how it's delivered must be the best in class process. DevOps was born out of this whole effort to increase the effectiveness of deployments and reducing the time to market.
Hearing about "Cloud transformation" or "moving to the cloud" from technology leaders have become a norm now.
The Testing we know
The approach to testing is continuously adding new components, tools and methods, Starting from inspection to peer code review, functional to non-functional and then automation on DB or API levels. The challenge further grows when the deployment process itself becomes part of an "application" which requires testing. Specifically, when we talk about Cloud applications and how they are deployed in Cloud utilizing the benefits of cloud computing like containers, dockers, and elasticity adding more complexity to our test planning.
Taking testing to the next level
As an orthodox tester, one may convince himself that at the end what matters is the functional testing, however, the speed by which these whole applications are being built and deployed, functional testing will give results but very late in the game. It's necessary to adopt the "Shift-Left" approach such that testing becomes an integral part of the deployment process. Fail fast, fix and re-deploy, that is the expectation now.
What is a native cloud application?
Cloud computing has transformed the way we use to work with the traditional infrastructure. With the power of on-the-go allocation of resources, and paying only for the processing which is used has given new horizons to engineers for building and deploying the applications. The docker was born out of this process. Applications which are build using the benefits of cloud computing like containers, dockers, and microservices are termed as a native-cloud application. As it's defined by Wiki "Native Cloud Application (NCA) refers to a type of computer software that natively utilizes services and infrastructure provided by cloud computing".
Challenges in Testing Native Cloud Application
Understanding of the "Native Cloud Application" and what it means is essential for building test strategies. Remember, applications which were once built on on-prem and now moved to cloud do not become native-cloud applications. So the testing approach for cloud-hosted application will be the same as of on-prem hosted application as the real elasticity has not been used for building those applications. Following are the few challenges which you may face when devising the test strategy for native-cloud applications
- No Space for Manual Testing
The native-cloud applications are heavily dependent on the pipelines for deployments which encapsulates the whole process of adding new code to the application thus leaving minimum or no way run the manual tests. For a native-cloud application, each and every test must be automation, integrated with a centralized testing framework which is further linked to the CI/CD pipeline.
- Handling Spikes
In the traditional infrastructure where the resources are allocated as per the application's max load, the native-cloud applications are not built on the same principles. If we do, we will lose one of the most important advantages which cloud computing has to offer, that is scalability. Example, for an application we know that in a specific day and at a specific time, the application will be hit maximum users and to contain that situation, we ensure to the hardware allocation is as such. But will not be the case when on a regular basis, the application is hit by 1/4th of its peak load. Therefore, we do not need to have a full-scale server running all the time to support that one instant, we build the application to spin the resources on the go.
That is where we identify the need to test whether the application or microservices are consuming the processing as per need or they are stagnant because of some hard-coded values.
- World-Wide Data Centers
Not much talked about aspect of testing for Cloud native as its applicable for both cloud and native-cloud application, we would still like to mention it here. Applications, especially running microservices should be tested from user to data-center perspective. That means the user from specific regions should be connected to their nearest cloud data-center unless that data-center is down. When testing, part of the strategy can be focused on how are we running the test to ensure that is happening.
- InterCommunication of Microservices
For a micro-service heavy native-cloud application, the API producer/consumer contract should be considered as a priority in devising the test strategy for native-cloud applications. When the applications are built on micro-services, the only way they can talk to each other is through APIs since they are independent of the platforms. Like in a single application, one micro-service can be written in C# which is talking to another micro-service written in Java. So to ensure that nodes are exposed in a way that they are not compromising the security, yet does not create any barrier in the producer/consumer relationship.
- Chaos Monkey
Chaos Monkey was introduced by NetFlix when they first moved to DevOps. The idea is to check the redundancy with the unplanned server failures. That is, to shut random servers or services down and see how well the redundant server kicks in. This testing strategy was built to ensure the system uptime up to 99.99% in case of any failure. If the application is large enough and built on multiple micro-services hosted on a different location, this is one of the test styles to ensure everything is intact during the unknown service failure.
- Blue/Green Testing
The blue/Green environment set-up has to be created to handle the speed of deployment. That means with each code commit the pipeline will trigger all the associated tests and any one of them fails, the build will not go through. Blue/Green environments allow us to keep a single instance to the application which is normally a customer facing instance "bug-free". On the deployment, if there are no test failures, the application is ready to be used. The blue environment is switched to green and the green environment becomes blue for future development. This allows us to quickly failback to the original state if there any issue with the current environment.
Conclusion
There is no magic wand invented as of now to do the trick when it comes to testing of the native-cloud application. The native-cloud applications are so diverse in their nature, such that "one size fits all" approach cannot be adopted in any way. Every native-cloud application will have its custom testing strategy based on its design, tools, and architecture. It leaves a lot of open apertures to explore the “buzz words” when we know them today.
Interested to know about our expertise?
Testing is crucial for creating reliable and efficient applications while ensuring superior customer experience. Coditude's independent software testing offerings include Automation Testing, Data Testing, Unit Testing, Performance Testing, Beta Testing, User Interface Testing, Integration Testing, Manual Testing, and Accessibility Testing. Drop a note to start conversation and get expert advice from our Testing Engineer.
