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 and 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 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.(potentially) related posts:
It’s been a heck of a year.
I joined a new team at MS fourteen months ago, and it’s been the busiest fourteen months of my career. To be fair, I worked more hours during my stint in Xbox One, but the role I’m in now has even more responsibility (more on what that means some other time). Since I haven’t really blogged much since I joined the team, perhaps a recap is in order for context.
I’m working on a yet-unannounced, and possibly-soon-to-be-released product. I was hired as “the quality guy”, but expanded the role over the time I’ve been on the team to take ownership of all of our build and release infrastructure as well. Basically, I’m responsible for everything from the moment code is checked in (including check-in quality gates), until it hits our production servers (at this time, “production” is for beta users only). This includes our CI system, build systems, test infrastructure, deployment, and a bit of manual testing as well. To this end, I’ve ventured back into management, and manage a small handful of full time employees, as well as a larger handful of temporary (vendor) testers. I’m responsible for making sure we have systems and strategies that enable us to get a good product to our customers frequently. I make sure the code is ready, and that the product is well-tested. It’s also my call on whether – and when to push bits to our production environment. It’s a killer job, but one deep in my wheelhouse. I’ve grown in many ways over the last year, and learned even more.
But it’s taken away a bit of who I am. I don’t write much anymore. I speak much less than I used to, and I’ve all but disappeared from twitter (one plus is that I’ve been really happy with the AB podcasts that Brent and I have been delivering). While part of me is growing and learning, another part of me is withering and dying.
So I need to make a change. Not necessarily a change as big as changing jobs or changing companies, but I need to remember that my job is just a job, and it’s not who I am. Like a lot of people, I lose sight of that sometimes, and I need to see if I can get myself back on track – and start by (re) connecting with the community that inspires me and drives me to do even better things.
I remain excited about the product I’m working on, and the team I work with – but perhaps more excited about speaking at Test Bash, getting back to talking with old friends on Twitter, knocking the dust off angryweasel.com, and sharing a bit more with my friends.
Here’s to re-engaging.(potentially) related posts:
Chris McMahon, who has always impressed me with his words and his wit called me out in his blog.
Apropos of my criticism of “Context Driven Approach to Automation in Testing” (I reviewed version 1.04), I ask you to join me in condemning publicly both the tone and the substance of that paper.
Almost exactly a year ago, I reviewed a draft of the paper, and my name is among those listed as reviewing the paper. The feedback I gave was largely editorial (typos and flow), with a few comments about approach that I’ll repeat here:
The first red flag I called out (and will call out again here) is the phrase that describes test automation as something to “automate testing by automating the user”. This is a shallow view of test automation, but other than comment, I didn’t push hard on it. In hindsight, this was a mistake (much of The A Word touches on this topic).
In regards to the scenario the authors chose for scenario automation, I thought the choice was weird, and asked for more…context and provided some food for thought.
I think you can add even more emphasis to how and why you chose to automate scene creation. Too many times, testers choose to automate because they can automate. The thought process (for me) may be, “The scene feature is pretty important, I’m curious what happens if an author has thousands of scenes. Will it cause performance problems, formatting problems, file load problems, or other issues, etc. There’s no way in hell I want to do this manually, so let me write some code to help me run my experiment”. You may also want to discuss alternate implementation ideas – e.g. creating a macro in Notepad++ to create the text then paste it in, or creating a macro in Word for the same, or using for in a windows console (e.g. for /L %f in (1,1,1000) do echo “##”>>output.txt&echo “Scene %f”>>output.txt ). Using tools for creating and manipulating data could be a whole article.
And that led to my real beef with the paper. It talks about using tools to test – which can be a good thing, but it doesn’t really talk about automation in the way successful teams actually use it.
I think it may be important to talk about purposes of automation and where to apply it – or at least one context of that – as I don’t think that’s discussed enough (but I’ve made a note to myself to write a blog on this very subject). At a BFC (big company) like Microsoft, we write a lot of shared / distributed automation – automated tests that we need to run on a lot of different hardware/platform configurations in some sort of lab setting (tools like SauceLabs or BrowserStack are helpful here). Web apps are famous for this [problem].
I also commented:
The other kind of automation (which you cover in your article) is what I sometimes call exploratory automation (or more often, just “Testing”). This is where we get a test idea, and want to write some quick automation to help learn about the product. While we may turn this sort of test into something that’s distributed / shared someday, its primary purpose is to help me answer questions and learn. There’s (another) story in HWTSAM where I described a case of this. I wrote really ugly brute force automation in C (using things like FindWindow and SendMessage(LBUTTON_DOWN…) to simulate opening and closing a connection to a remote host many times (the only thing this app did). It found a nice memory leak that may not have been found otherwise (or at least not as quickly).
All of this feedback fed my uber-point, which was that while the article talked about test automation, the examples really just talked about using somewhat random tools to help the authors explore or test some software. There was nothing about strategy, or about more typical use of test automation. I asked about it in a comment:
I wonder why you don’t use the word “Tools” in the title – e.g. “A CDT approach to tools and automation in testing” or something like that.
…because the paper is about, as I said above, using non-standard tools to help test. Sure, it’s automation in a sense, but nothing in the paper reflects the way test automation is used successfully in thousands of successful products.
All that said, I do not support this paper as a description of good test automation, and I think it’s an inappropriate method for anyone to learn about how to write automation. Chris requested that the authors remove the paper; while I support this, and do believe that the paper can cause more harm than good, there’s so much bad advice on the internet about creating software, that removing this one piece of bad advice will hardly make a dent.
I did not realize my name was listed as a reviewer, and although I did (as admitted above) review this paper, I do not want my name associated with it, and will request that the authors remove my name.(potentially) related posts: