Testing Infrastructure as Code: A Beginner’s Guide
This post is for testers who are eager to learn more about testing Infrastructure as Code and are looking to deepen their cloud technical testing skills.
Infrastructure as Code Testing
I have worked for over 20 years in various roles as a functional/technical tester/manager. Besides being a business owner, I have been working as a tester within a DevOps team at a client for the past two years, where we are responsible for maintaining AWS stacks, among other tasks. Being a SDET and having a strong interest in technology, I came into contact with AWS CDK and the world of Infrastructure as Code. Our team integrates all code changes into the product and implements a distributed stack that teams can use for integration tests/application tests. We are partly responsible for implementing the infrastructure and currently test through a two-eyes principle to confirm the implementation has been successful before usage. We perform checks post-implementation, resolve infrastructure issues, and conduct a limited set of tests.
What Does It Involve
Imagine you have distributed applications spread across different parts of the infrastructure - multiple servers, containers, lambdas, cloud services, databases, etc. Creating such a distributed infrastructure is a tedious and error-prone process. Making changes is even more challenging. In such situations, most software teams prefer to store their infrastructure as code. This makes the deployment process more predictable and less prone to errors. It provides confidence that if something doesn’t work as expected, you can always roll back. Storing your infrastructure as code gives the entire team more insight and allows for quicker changes. Infrastructure as Code uses descriptive languages and human-readable formats – YAML, JSON, etc. For AWS, think of CloudFormation templates. However, you do need tools like Terraform, Ansible, and AWS CDK to generate these templates, as doing this manually is very complex and error-prone.
When Does Infrastructure as Code Testing Become Important
As the number of integrations and chains grows, this manual process becomes time-consuming. The chance of human errors increases, and it often requires a lot of communication and stakeholder management to resolve issues. And worst of all, it is cumbersome! So, the solution that the tech industry has come up with is to store infrastructure as code.
For Management: Why Is Testing Infrastructure as Code Important
Pillars are complexity, time, and susceptibility to error
Setting up infrastructure with different components is a complex process. Companies spend a significant amount of money to build multiple environments. The testing teams perform their integration tests on this implemented infrastructure. I often hear about connectivity issues from A to B, which can have various causes, such as a dependency on an on-premise application that has an even more complex and time-consuming change management process in place.
However, if the starting point is that you own the infrastructure and implement it without testing, there is a high chance that testing teams will notice bugs due to poor implementation. This wastes the time of all involved teams!
Potential issues include:
- Connectivity issues, e.g., improperly set up rest APIs.
- Security checks that are implemented incorrectly, preventing access to your lambda function and, for example, a server.
- Ports, SSL, etc., that are not set up correctly.
Testing the infrastructure will play a key role in reducing problems related to poor implementations and incorrect configurations. This gives testers confidence that discovered issues are due to the application and not the environment. Since testing the infrastructure and the quality of the implementation saves time for all involved teams, it is economically sensible to execute this step correctly.
In another blog, I provide a summary of popular tools for static code checks, deployment, unit testing for verification and validation, and local “system test” with a mock to see if the infrastructure is set up well as a process.
Experience as a DevOps Tester
I have written this document for myself to gain the knowledge needed to test infrastructure, in my case, AWS CDK with jest and AWS Rspec. I haven’t really used it in practice yet, but I have done a little R&D with it. My feeling is that the niche I am testing now has potential since I see that many organizations are struggling with this. An even greater improvement would be to generate real-live communication charts from that infrastructure. I want to share my experiences in case it benefits others who may also be interested in exchanging ideas.