Just My DevOps Learning Diary

Ley
4 min readSep 13, 2020

Hello! Been a while since my last post. Come back this time to share this course I signed up last month provided and delivered by NaradaCode. Previously the course name was DevOps Test Engineer (DTE) Course. Effective August, DevOps Institute changed the name into Continuous Testing Foundation but from content & curriculum perspective both are the same. After the training, we were enrolled to Continuous Testing Foundation exam to earn Certification from DevOps Institute and thanks God I passed the exam. Received the notifications and official certificate via email several days after taking the exam.

There are actually lots and lots of lessons that I got through this course but there are some of them that I’d like to highlights, check them out!

1. Five Tenets of Devops Testing

We received comprehensive explanations about 5 tenets of devops testing. I got to say, this principles really helps when you’d like to know what differentiate devops testing and conventional testing approach in delivering software to users.

Shift Left, Fail Early, Fail Often, and Test Fast

Conduct each test as early as possible in the pipeline. Test fast, fail often and early. It’s not only true from devops principle but also align with Agile principle, how we can iterate development & testing process since the early phase, stop using testing and software delivery model which required all phase needs to be completed prior starting the next phase.

If you read Continuous Delivery book by Jez Humble and David Farley (my favourite holy grail book all the time, been reading this book since I always feel as a newbie in DevOps world) there’s a chapter about the problem of delivering software and one of the principles given is “If It Hurts, Do It More Frequently, and Bring the Pain Forward”. If you think testing is a painful process, don’t do it in the end, continually iterate from the beginning of project. This is also applicable for everything, whether it is testing, integration, or release. Practically any stage of shipping your software into production.

Relevance

Focus on performing high impact tests and results. Ensure that every tests conducted deliver proper ROI, differentiate cosmetics and fundamental part of the software. Otherwise, it will be never released as there is no perfect software. What we can do is minimize risk as much as possible while iterate the improvement.

2. What to Automate & Test Automation Strategy

Where to begin with when seems like you need to automate a lot of things. Remember that the key is ROI, it’s not about 100% test fully automated but analyze several variables first : is it critical/common scenario, does the functionality change often, is it easy to maintain the scripts. Also consider if the cases are automation friendly, don’t be trapped in the prestige of automation. Remember that you automate a test to help you to identify problem and ship good quality software faster. It won’t be helping if you force everything to be automated and end up trapped in too much effort creating and maintaining the scripts while certain tests don’t have high impacts or end up slow down the operation and deliverable due to overwhelm in maintaining the scripts. We also run through variety of methods for creating automated tests :

o Interactive Capture/Replay tests

o Keyword-Driven tests

o Test driven development (TDD)

o Behavior-based tests (BDD)

o Model-Based tests

3. Build Once, Deploy Many

Don’t rebuild many times prior switching to different environment because once something is wrong, it will be much harder to find out the root cause. You’ll have no idea whether it’s the code, the build or certain configuration difference between environment. So build once, and you can deploy many times to multiple environments, when something goes wrong, you’ll immediately able to shortlist several possible root causes (am stating several because you’re not fortune tellers, we always need to validate those root cause hypothesis). We also discuss about critical items which required to take into account prior and post software deployment. As a release manager, I feel the immediate ROI after this course, now I relate better about potential issues on deployment and what potential varibles which cause a rollback happens. I explain better to my team as well if anyone ask how is it possible that we required to perform rollback while the code was ok testing process on other environments.

4. Security, Infrastructure and Many others!

What’s best, through the session we also run and go through various security test and get introduced to other types of test. Moreover, we also exposed to hands-on simulation on a pipeline which alredy accommodated well both functional and non-functional testings (performance and security test as well). From Software Composition Analysis, Static Application Security Testing, Container Security Scanning, Dynamic Application Security Testing, and Interactive Application Security Testing.

What I love the most, the curriculum structure really combine various aspects in Devops from Culture into Tools. This provide perfect balance between technical and non-technical aspects. All the principle taught were also provided with hands-on session and study cases where we learn the implementation of end to end DevOps testing.

So thank you NaradaCode and also DevOps Institute!

--

--

Ley

Mixing Engineering & HR. Currently spending time guarding production through oversee release execution.