One of the questions that I have been contemplating as of late is “where does testing fit into the overall organization?” I was given a chance to contemplate this recently because of a chance at SideReel. Our Director of Engineering decided to take on another role at another start-up, so we had a period of transition and I now have a new director. This new director asked me this question directly, and we had an interesting discussion because of it.
Unlike our previous director (a guy I like and respect a lot, so do not take this the wrong way), our new director comes from a strong operations and systems administration background. I say that because he was able to verbally describe something I’ve tried to explain to various organizations for years. Testing is nebulous. There are a lot of things that we do that are, for the most part, invisible to those who chase metrics and measurable hard deliverables. He also appreciates the fact that, like systems administrators, no one really notices you when the systems work well, they only know when things are broken, and then you are public enemy number one. This has been a pet peeve of mine for a number of years, and I’m still trying to come to grips with the best way and approach to raise visibility of testing and what we do. Cost containment is good, but raising the visibility on our value is, I think, ultimately better.
As a Lone Tester, I get both ends of the spectrum. I am often unnoticed (even in this small company) when things are moving along as they should, and I definitely get a center spotlight if something gets missed and makes its way out onto the production site (that’s not a complaint mind you, just a direct observation of fact). Be that as it may, what can we do to help raise that visibility? One of the things I do is right here, this blog. It’s a repository of my ideas and musings, not just for my general readers, but for those I work for, too. If you have a testing blog, don’t just have it be an external resource, but share it with your company and let people know what content would be relevant. I put the URL for the Practicum section for my most recent Performance Review, as well as a link to my book reviews and my articles published. Second, if you have a chance to participate in something where you can share your testing ideas with other teammates (even if they are not testers) take that opportunity. It doesn’t have to be elaborate, but even a quick brown bag on Heuristics or Domain Testing and the reasoning behind why we do them can be very eye-opening for a development team.
While I won’t say that we will be able to change perceptions immediately or that some organizations will really much care either way, there are some simple things we all can do to help raise our visibility and the way that we interact with our teams, and they don’t require us creating reams of documents that no one is going to read. They do require a different way of thinking, and perhaps a little showmanship and salesmanship, but with time and a bit of attention, it will be possible to change perceptions to our advantage.
2 comments:
So this is a very interesting topic for me, as I am having a similar discussion with my boss tomorrow morning.
I am curious, how much of your blogging, book reading, practicum entries, etc. is done 'on the clock'? You don't have to answer with a specific number here, but if I had to wager I would guess that at least a portion of it does. For me that leads to another question that I am still answering for myself, what is the balance of creating value for the product, and adding visibility of that value within your team/company? Is it 50/50? 80/20? 90/10?
In the teams I have worked on, the testing standards before I started had been sub par, and projects were almost expected to fail in some way, because they almost always did. After the help of some great testing teams, when features started rolling out without any problems, people started noticing. In my current team(which I joined 8 months ago), we have now had 4 consecutive release cycles without any significant issues and our team was recognized on the most recent company wide conference call. That said, there was definitely some salesmanship of my team to garner that recognition, as well as quite a bit of training and hard work, but the visibilty is a benefit to our team and the company.
The positive outlook on our team has actually had quite a significant impact on the effectiveness of our team. After a year or more of being blamed for all the problems in the software, some of the team was rather burtn out and down trodden. Now that the team is back in the good graces of the company, they are increasingly more effective. Perhaps that is one angle of value added to the business, happy testers are more effective at finding bugs and identifying risks.
(This has been a lingering string of thoughts that has been interupted several times today, hopefully it is cohesive somehow)
Ultimately, the dilema that I face is balancing time as a regular full time employee reading, writing, and developing myself and my team with the time we spend actively working on the product. I think it is definitely important to be aware of what is happening in testing outside of one's own environment, but defining the value added during that time can be (to use your term) 'nebulous'.
Wade, that's a great question and it has sparked a lot of comments and thoughts... enough that I can't really answer here. I'll do it in a blog post tomorrow :). Stay tuned.
Short answer is "yes", I get some time to work on ideas, books, practicum, etc. on my work time, but that a misleading answer if I just leave it at "yes". There's a more nuanced story, and I think it deserves to be told, so check back tomorrow :).
Post a Comment