The fine folks at the Ministry of Testing keep promoting my blog posts, so the least I can do is give them a link and a shout out. I’m looking forward to talking about “Testing without Testers” at Test Bash Philadelphia (preview here) and about my role on the team.
This morning, I passively listened to The Bach Bros talk in a webinar about roles and what they mean, as I was curious to get their take. The punch line of the talk was the introduction of “Role grams” – which are shapes that describe who does what, what they’re doing, and who owns it. Nothing earth-shattering, but a workable model.
For the last 14 months, I’ve been a manager on an engineering team responsible for deployment and quality. As I’ve put it before, I am responsible for everything that happens between the time code is checked in (or slightly before, as I also added a few git hooks) to the time it is deployed to our production servers. Given that context, my role is a big blob of stuff. One could say that my “role” is Director of quality and infrastructure, and within that role, I take on activities of tools, engineering productivity, builds, quality, and testing. Certainly, you could say that each of those are roles I take on as part of my job – that model just doesn’t work as well for me. My role – the part I play as an actor on my product team, is one where I need to look at the entire ecosystem of check-in, CI, build, test, and release as one thing. I look at all of that as a system – how quickly and efficiently can I move a developer check-in to something that shows customer value. I have to view the system to know which parts are bottlenecks, and which parts need speeding up, or slowing down in order to increase overall system efficiency.
Here’s a low-tech view of my role. 
I’m not locked in my box – in fact, since I’m the “quality guy” (label, not role) on my team, I spend most of my time working across the team on improving the testing done by other engineers on the team. I also have a small team of dedicated testers (these people have a testing “role”), who focus almost entirely on exploratory testing driven by trends in customer feedback and areas where I think we need additional breadth coverage in order to reduce risk.
It’s an evolving role, but one I enjoy, and one that I think will become much more common in the coming years.