Manual testing is often overlooked in infrastructure as code workflows, especially with powerful tools like Terraform. However, before introducing automated tests, manual testing is essential to fully understand how your infrastructure behaves in real-world conditions.
On Day 17 of my 30-Day Terraform Challenge, I focused on building a structured manual testing process for my webserver cluster (Application Load Balancer + Auto Scaling Group + EC2 instances). This experience reinforced one key idea: you cannot automate what you do not understand.
Why Manual Testing Matters
Manual testing helps answer critical questions:
- Does the infrastructure deploy correctly?
- Does it behave as expected under real conditions?
- Are there hidden misconfigurations that validation tools miss?
While terraform validate and terraform plan ensure correctness at a configuration level, they do not guarantee real-world functionality. Manual testing bridges that gap.
Building a Structured Test Checklist
Instead of randomly clicking around the AWS Console, I created a structured checklist to guide my testing process.
Provisioning Verification
- Run
terraform initand confirm initialization completes successfully - Run
terraform validateand ensure configuration is valid - Run
terraform planand verify expected resources - Run
terraform applyand confirm successful provisioning
Resource Correctness
- Verify resources exist in AWS Console (EC2, ALB, Target Groups)
- Confirm names, tags, and region match configuration
- Ensure security group rules are correctly applied
Functional Verification
- Retrieve ALB DNS using
terraform output - Run
curl http://<alb-dns>and verify response - Confirm all instances pass health checks
- Terminate one instance and verify ASG replaces it
State Consistency
- Run
terraform planafter apply → expect “No changes” - Confirm Terraform state matches actual infrastructure
Regression Check
- Make a small configuration change (e.g., add a tag)
- Ensure only intended changes appear in
terraform plan - Apply and verify the plan is clean afterward
Test Execution: What Worked and What Didn’t
Running the checklist revealed both successes and failures.
Successful Tests
Terraform Initialization
terraform init
Result: PASS
Terraform Apply
terraform apply -auto-approve
Result: PASS
All resources were successfully created (see screenshots).
ALB Functional Test
curl http://my-app-alb-123456.us-east-1.elb.amazonaws.com
Result: PASS
Returned: "Hello World v1" (confirmed via browser)
Auto Scaling Self-Healing
aws ec2 terminate-instances --instance-ids i-xxxx
Result: PASS
A replacement instance was automatically launched.
Failure and Fix
Test: Terraform Plan Consistency
terraform plan
- Expected: No changes
- Actual: 1 resource change detected
- Result: FAIL
Root Cause:
A missing tag in the security group configuration.
Fix:
Added the missing tag in the Terraform code and re-applied:
terraform apply
Retest Result: PASS
This failure highlighted how manual testing uncovers real issues that static validation cannot.
Testing Across Environments
I ran the same tests in both development and production environments.
Key Differences:
- Dev used
t2.micro, production usedt3.medium - Production had stricter security group rules
Unexpected Issue:
The application initially failed in production because HTTP (port 80) was blocked.
Fix:
Updated the security group to allow inbound HTTP traffic.
This demonstrated a common real-world problem: something works in dev but fails in production due to configuration differences.
The Importance of Cleanup
After testing, I destroyed all resources to avoid unnecessary costs.
terraform destroy -auto-approve
Verification
aws ec2 describe-instances --filters "Name=tag:ManagedBy,Values=terraform"
Output:
[]
aws elbv2 describe-load-balancers
Output:
[]
Why Cleanup Matters
Cleaning up sounds simple, but it is often where engineers fail. Terraform may partially destroy resources, leaving orphaned infrastructure behind.
If cleanup is ignored:
- AWS costs can accumulate quickly
- Old resources can interfere with future tests
- Infrastructure drift becomes harder to manage
Lessons from Terraform Import
The terraform import lab introduced a critical concept: bringing existing infrastructure under Terraform management.
What It Solves
- Allows Terraform to manage manually created resources
What It Does NOT Solve
- It does not generate Terraform configuration
- You must manually write
.tffiles
This reinforces that Terraform is not just a tool — it requires discipline and understanding.
Key Challenges and Fixes
| Issue | Root Cause | Fix |
|---|---|---|
| Missing tag | Not defined in config | Added tag block |
| ALB not accessible | Port 80 blocked | Updated security group |
| Plan inconsistency | Config drift | Re-applied configuration |
Final Thoughts
Manual testing is not optional — it is the foundation of reliable infrastructure.
It helps you:
- Understand your system deeply
- Catch real-world failures early
- Build confidence before automation
Every failure discovered during manual testing becomes a future automated test case.
As I move forward in this challenge, the next step is clear: turn these manual checks into automated tests.
Day 17 Summary
- Built a structured manual testing checklist
- Tested both dev and production environments
- Identified and fixed real infrastructure issues
- Practiced strict cleanup discipline
Manual testing isn’t just a step — it’s a mindset.
Top comments (0)