New · Specialised Track

DevOps QA — testing in a continuous-delivery world

The NZ-localised guide to testing when releases ship many times a day.

In a DevOps shop the old model — a test phase, a sign-off, a quarterly release — is gone. Code goes to production continuously, runs in containers on Kubernetes, hides behind feature flags, and rolls out a few users at a time. The quality question changes from “did the test phase pass?” to “is this release safe to keep promoting, right now, based on what production is telling us?” This track teaches you to test in that world.

This track covers

Containers & Kubernetes Feature Flags Progressive Delivery Canary & Blue-Green Observability Gates

Builds on what you know

The CI/CD basics — pipelines, quality gates, running tests on every commit — are covered in Senior Automation · CI/CD Integration. This track consolidates those foundations and extends them into how you actually test releases that deploy continuously to production.

Who this is for

Testers, Test Leads, and SDETs working in teams that practise continuous delivery in NZ — or moving into one. Assumes ISTQB Foundation Level and comfort with a CI/CD pipeline. No prior Kubernetes experience required; the concepts are taught from first principles.

The 4 lessons

From the container to the canary

Why this track

Testing moves out of a phase and into the pipeline

For most of testing’s history, quality had a place in time: a test phase between development and release. DevOps removed that place. When Te Whatu Ora or a bank deploys many times a day, there is no week to test and no gate a person stands at. Testing has to happen inside the pipeline, and the pipeline has to be trustworthy enough to ship without a human in the loop on every change.

That does not make testing smaller — it makes it different. The system under test is now a container image, not a build on a shared server. A feature can be deployed to production and still switched off, so “released” and “deployed” stop meaning the same thing. A change reaches one percent of users before it reaches everyone, and the decision to promote it is made by comparing live metrics, not by reading a test report. Each of those shifts is a new place a tester adds value — and a new place a defect can hide.

This track teaches those three shifts in the NZ context. By the end you will be able to test a containerised application and its Kubernetes deployment, build a test strategy around feature flags, and validate a canary or blue-green release using the same observability signals that drive an automated rollback — and write the evidence that shows the release was safe to promote.

Related

Other specialised tracks