I had a twitter conversation this week about roles this week. I’ll recap it – and expand on my views; but first I’ll tell a story.
Very early on in the Windows 98 project, I was performing some exploratory testing on the explorer shell and found an interesting (and slightly weird bug). At the end of my session, I entered the bug (and several others) into our bug tracking system – but the one issue continued to intrigue me. So, I took some time to look at the bug again and reflect on what could cause this bug to happen. I dug into the source code in the area where the bug occurred, but there was nothing obvious. I couldn’t shake my curiosity, so I looked at the check-in history and read through the code again; this time focusing on code checked in within the last few weeks. My assumption was that this was a newly introduced bug, and that seemed like a reasonable way to narrow my focus.
Less than an hour later, I discovered that a particular windows API was called several times throughout the code base, but on one occasion, was called with the parameters reversed. At this point, I could have hooked up a debugger (or some could say that I should have already hooked up a debugger), but after visual examination of the code, the code of the API, and the documentation, I was positive I found cause of the error. I added the information to the bug report and started to pack my things to go home.
But I didn’t. I couldn’t.
I was bothered by how easy it was to make this particular error and wondered if others had made the same error too. I sat down and wrote a small script which would attempt to discover this error in source code. Another hour or so later, and I had a not-perfect, but pretty-good analyzer for this particular error. I ran it across the code base, and found 19 more errors. I spot checked each one manually, and after verifying they were all errors, added each of them to the bug tracking system.
Finally I was about to go home. But as I was leaving, one of the developers on the team stopped by to ask how I found the bugs I just entered. I told him the story above, and he suggested I add the tool to the check-in suite (along with several other static analysis tools) so that developers could catch this error before checking in. I sat back down, we reviewed the code, made a few tweaks, and I added the tool to the check-in system.
Over the course of several hours, my role changed from testing and investigation of the product, to analysis and debugger, to tool developer, and finally to early detection / prevention. The changes were fluid.
On twitter, a conversation started on detection vs. prevention. Some testers have a stance that those two activities are distinct, and that doing both makes you average (at best) at both. The conversation (although plagued by circular discussion, metaphors and 140 character limits) centered around the point that you can’t do multiple roles simultaneously. While I agree completely that you cannot do multiple roles simultaneously, I believe (and have proven over 20+ years) that it is certainly possible to move fluidly through different roles. Furthermore, I can say anecdotally that people who can move fluidly through different roles tend to have the most impact on their teams.
To this day, I figure out what needs to be done, and I take on the role necessary to solve my team’s most important problems. Even though I have self-identified as a tester for most of my career, I don’t see a hard line between testing and developing (or detecting and preventing). In fact, that may be one of the roots of conversations like this. For years, I’ve considered the line between development and testing to be a very thin grey line. This reflects in my story above, and in many of my writings.
Today, however, I don’t see a line at all. Or – if it’s there, it’s nearly invisible. It’s been a freeing experience for me to consider software creation as an activity where I can make a significant contribution while contributing in whatever areas make sense – at any given moment.
Sure – there are places where develop and then test still exist, and this sort of role fluidity is difficult there (but not impossible). But for those of us shipping frequently and making high quality software for thousands (or millions) of customers, I think locking into roles is a bottleneck.
The key to building a great product is building a great team first. To me, great teams aren’t bound by roles, but they’re driven by moving forward. Roles can help define how people contribute to the team, but people can – and should flow between roles as needed.
Perhaps it is subtle, but I want to point out that Alan does NOT necessarily say “Dev and QAE roles can be efficiently filled by the same person”.
What he says is that the most successful software engineer can fluidly move between roles to meet needs as they arrive. It does not mean when you are working on dev work that you are as efficient as a full-time dev – it means that you have some skills in dev and combined with your other (test) skills this makes you more valuable.
Lol it was very long time ago. When you was testing windows 98 😀
It was an example. I can tell a similar story about Xbox One (and almost every product I’ve worked on).
What about checking v.s. testing? I found peoples in test field tend to talk more about test automation is not testing.
It’s not “checking vs. testing”. Checking is a subset of testing focused on binary results. Please don’t join the bandwagon thinking it’s a completely different thing. Checking can lead to testing (and vice versa), and like fluidity in roles, people move fluidly from checking to testing and back again.