Alexander Langshall is up… without Loki
This was a tough talk to title… he was not sure how to call it. Cool disclosure: If this talk does not apply to you, wait for it. Tech changes fast and as a tester you never know what your next challenge will be.
Awesome, another former teacher in testing. I have found some of the best testers have been those with a knack for explaining complex problems to others 
An amazing moment of self affirmation for those of us who have serious anxiety about public speaking. You had to be here
So, behind this talk:
- Represents a personal journey
- Three areas described represents a sequential evolution
- The underlying theme: expand the role of testing
Do we need to break down what devops is again? Maybe we want to just consider where we live in it
- Dev + Ops living in harmony
- Dev given sharp tools for infrastructure needs
- Shared responsibility for production infrastructure
- Quicker Deploys (Shout out to Accelerate!)
- Tie all work to higher IT performance
- Higher IT performance == More $$$
OPS want to avoid infra failures. QA wants to avoid bugs. TestOps seems natural. How do we write good code that works well in production. Maybe QA should be sitting next to Ops to partner on this mission?
But the voices!
“TestOps is just a buzzword!” Who cares?
“You are defining something that already exists” Exactly
Shout out to my old partner in crime Ioana Serban: “TestOpsChasing the White Whale”
Hallmarks of TestOps
- Close alignment with oncall teams
- Full ownership of Test Environments
- Treat infrastructure and Infrastructure-as-code as testable artifacts (Deploy IS testing)
Alexander dives a bit into his work history:
- Staging: structurally unlike production, and owned by dev and ops. Had no monitoring, and each service was deployed manually. How is this an effective mock of how things work in prod?
- When there was an awful production release, the team could not test structural level changed until it got to prod. if it broke… they played the rollback game over and over in a firefighting mode. Poor decisions would be made thanks to a combination of pace, stress and poor visibility of how things might work in prod while still in staging.
- Alexander kept prodding throughout this about how helpful a prod like test environment could be. Also worked with the Ops team to get them to understand the QA wants to help
- Preprod finally put in place: structurally like prod, owned by QA, monitored just like prod, using a release train and worked on by both QA and Ops
And boom… a natural formation of a TestOps team. Responsive to tier 1 deploys/changes/outages working directly with Ops and QA. The world has been transformed… from the traditional Director of QA/QA manager/Sr QA/QA structure towards something that better modeled how TestOps engaged with the org. Managing test envs, leading oncall teams, testing infrastructure stories, participating in live site events, and writing app and infrastructure code. What does this job title look like? QA eng, testops eng and Principle QA analyst.
Alexander shares his overall agenda: The more we understand about how our infrastructure works, and common problems, the more bugs we can prevent from getting to the end users
Awesome talk.
Questions:
“what was the growth of the full org if the QA team went from 4-30?” → scaled similarly
“Tell us a bit more about these roles that were created and the differences between them?” → QA Eng is more or less a hybrid. Principle is on the testing strategy and approaches
“Was QA not allowed to look at production before?” → not really. We were expected to work in Staging
“How do you advocate for as much resources (eg memory) as production?” → We try to mirror it structurally, even if we do not have that level of traffic.
Never accept “This will never happen in production”!!!