I started the Foundations Black Box Software Testing class earlier this week and we are now into lesson two of six. I thought the discussion question was interesting so I’d like to share it along with my response.
[P]lease describe the role of the test group (services and responsibilities) in your organization. How do you think this mix differs from what you think of as the “typical” test group? How would you change this?
Up until a month ago I was the sole tester in small software company (our entire company was about 11 people). Since then we’ve been purchased by a large multinational company with over 15,000 people world-wide and I’m still not quite sure what exact group I belong to, what my overall responsibilities are so I’ll focus my answer on the company prior to this acquisition.
Since our company was small so was our technical team, which consisted of 3 full time developers and me. For a few years we also had a CTO who acted as a development manager and occasionally for big projects we’d hire contractors. Like others on our technical team I essentially had two roles in the company: first as a tester of our products and secondly as a jack of all trades, used where-ever I’m needed. My responsibilities and services include:
- Support our existing Clients deployments
- Questions about software behavior
- Debug problems with existing systems
- Install and Configure customer deployments (production systems)
- Install and Configure test and development labs
- Build the releases for our software (release management)
- Document installation procedures, update existing online help system
- Test software releases and patches which includes:
- Make sense of the changes development made
- Understand what was asked of our development team (no formal specs) by our customers or executives
- Make sure the company knows the risks and stability of the release in both functional and para-functional areas.
- Anything else asked of me by management
While these responsibilities can limit the amount of time I can spend on a particular release testing, they provide different points of views which feed into what I know and learn about the product. Those influences then get reflected in my testing approach. This holistic view can help identify pain points which I might otherwise not get to see.
I’m not really sure what a “typical” test group is but in my experience working for large and small companies, each seem to have services and responsibilities that suit what someone thinks the companies needs are. I think the difference between mine and other testing groups has been the amount of time devoted to learning about the craft of software testing and how that can be applied to helping the business. The only way to change this is to set a good example for others to follow.