Manage to Test

That’s my new title.

For the last 10 years or so I’ve been a “Quality Assurance Analyst” and a “Quality Assurance Manager.” We all know now, or should, that those roles have nothing to do with quality assurance. I didn’t write feature code as a QA analyst and I didn’t dictate to programmers how to do their jobs (well, of course I did both of those things — with varying levels of success/influence — but it wasn’t part of my job description). As a QA manager I was a “resource” manager; I wasn’t responsible for teams or projects, but rather a group of testers that worked on various projects. The primary responsibility in that job description was to be aware of the availability of the people on my team through forecasting and monitoring so that when new work came up, I could assign someone to do it (and I did everything I could to make this responsibility moot).

So I was a Tester and then a Test(er) Manager. And while I did other things, my focus was always on testing – how to do it better, how to do it earlier, and how to get the most appropriate information possible to the decision makers on projects. I would not, however, characterize my current title as “Test Architect.” I’m not solely focused on testing. I’m also focused on business analysis, and programming, and sales, and support, and management and the SDLC and…well everything we do that has an affect on the quality of our work. While I attempted to have this kind of influence in my former role, I couldn’t. I didn’t have the authority, and often, the support, of others in the organization. Now, I do.

Here are some of the things I’m doing now:

• Leading an Agile transformation
• Helping the business understand internal capabilities and identify needs in the marketplace
• Helping teams coordinate efforts between local and off-shore employees
• Helping dependent project teams work together without hindering and/or blaming each other (it’s nice to finally be able to make a difference in something like this…)
• Modifying the organization structure to better facilitate small, permanent teams of cross-functional developers (analysts, testers, programmers, et. al.)
• Implementing an Executable Specification framework (with the full knowledge that they ultimately function as rejection checks)
• Integrating and aligning Security and Performance teams with project teams

I still have issues with the word “assurance” but I know that I have a lot more influence on Quality – using a variety of definitions – than I’ve ever had before.