A Test Group of One

A Test Group of One
Photo by Kelly Kiernan / Unsplash

I started the Foundations Black Box Software Testing class earlier this week and we are now into lesson two. 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?

My response

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. I’m still not quite sure what exact group I belong to or 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
  • Compile / build the releases for our software (release management)
  • Document installation procedures and 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’ve worked in large and small companies. Each organization seems 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.

Subscribe to Shattered Illusion by Chris Kenst

Sign up now to get access to the library of members-only issues.
Jamie Larson