A Lone Tester at a DevOps Conference

I recently had the chance to go to Velocity Conf in Amsterdam, which one might describe as a DevOps conference. I love going to conferences of all types, restricting the self to discipline specific events is counter intuitive to me, as each discipline involved in building and supporting something isn't isolated. Even if some organisations try and keep it that way, reality barges its way in. Gotta speak to each other some day.

So, I was in an awesome city, anticipating an enlightening few days. Velocity is big. I sometimes forget how big business some conferences are, most testing events I attend are usually in the hundreds of attendees. With big conferences comes the trappings of big business. For my part, I swapped product and testability ideas with Datadog, Pager Duty and others for swag. My going rate for consultancy appears to be tshirts, stickers and hats.

So, lets get to it:

3 Takeaways

• Inclusiveness - there was a huge focus on effective teams, organisational dynamics and splitting the monolith. The key was going beyond diversity and into the realms of inclusion. As in, an organisations workforce can be as diverse by the numbers, if people aren't included in discussions and decisions, then that organisation is falling short. Still a long way to go, and if diversity is treated as numbers game, we will struggle to realise the benefits of true diversity. Inclusivity is exemplified in the talk from Paula Kennedy from Pivotal and her role there(1). 
• Web Performance - Velocity has a heavy client side performance focus, which has always interested me, so I tried to catch a number of these talks. There are two main areas which got my testing senses tingling:
• Progressive Web Apps(2) - specifically service workers(3) and background sync(4). Imagine if there was a process within your web app which behaves like a proxy managing your on and offline experience, downloading content when data is available, for consumption when its not. I can think of a million interesting tests there. Fascinating challenge, with some new tooling too(5). Twitter on Android is a progressive web app. Give it a try.
• HTTP2 Server Push(6) - along a similar vein, imagine if you could speculatively send resources to client without waiting for a request? What improvements could you make to the initial and next page load time and experience? How much might you push which is not needed though? Or mistimed? How far can you anticipate needs? How would one test this(7)? As with progressive web apps, a testing challenge I would relish.
• Containerisation - I have had my own development environment for many years now. I've invested time into learning how to build the applications I test locally. The ability to observe and control is vast, the technical awareness gained from the process is contextual gold. The development environment I use now is a number of docker containers to run each of the applications I need. The next step I wish to investigate is cluster management using technology such as Kubernetes(8), with supporting monitoring tooling such as Prometheus(9), perhaps even augmenting my development environment beyond single containers (having multiple webservers and caches for example), as needed to extend my testing as early as possible. 

3 Ponderables

• Behind the Times - testers (some but not all) can tend to be behind the times. Either worrying about what agile or devops means, or scrabbling around trying to find test approaches and tooling for a new technology which has landed from seemingly nowhere, but in reality has probably been around for a while. We always seem to be busy doing something else. With a broader scope for the events we attend, perhaps we might be in the vanguard one day, rather than the baggage train?
• Echo Chambers - don't get all offended. I love the testing events I attend. I help to run one. However, the danger of the echo chamber is clear and present. Similar ideas being presented to an agreeable audience is something we should guard against, testing is not a bubble, nor should it be. Velocity provided an excellent reminder that its a big wide world of ideas out there ready to be embraced, testing is part of that.
• Hanging out with Dev and Ops in my Organisation - one of the coolest parts was that about 20 people from my organisation came to Velocity. We stayed in same hotel, went for dinner, a few drinks and had a good time. More names to faces, already getting involved with infrastructure testing off the back of it. Winning. And I even got a day to have a look around Amsterdam after. 

At the conference there was some surprise that a tester might attend from some other attendees I talked to. One even asked if testers were still a 'thing.' That might tell a separate story. Of course I don't know I was the only person there who identified as a tester, but I'm willing to guess you wouldn't have needed many fingers upon which to count us.

I often hear testers say 'well, that {conference topic} is not part of my role' or 'I don't know what I can contribute.' My answer is wherever you can add value, as testing happens throughout the lifetime of a given system or product. So lets reach out, go somewhere a little different.

References

Main Conference (Slides and Videos)

(1) http://conferences.oreilly.com/velocity/devops-web-performance-eu/public/schedule/proceedings

Progressive Web Apps

(2) https://developers.google.com/web/progressive-web-apps/
(3) https://developers.google.com/web/tools/service-worker-libraries/
(4) https://developers.google.com/web/updates/2015/12/background-sync/
(5) https://developers.google.com/web/tools/lighthouse/

HTTP2 Server Push

(6) https://http2.github.io/faq/
(7) https://canipush.com/

Kubernetes and Prometheus

(8) http://kubernetes.io/docs/whatisk8s/
(9) https://coreos.com/blog/coreos-and-prometheus-improve-cluster-monitoring.html