Throughout our lengthy history, Centercode has partnered with a tremendous variety of clients with an equally wide variety of products. There have been many constants in our business, but one thing that seems to vary is the location of the beta test program. Companies place beta testing responsibilities in a variety of departments and give its ownership to people with a wide range of backgrounds.
So, which department should host the beta test program? There are some obvious choices and some less obvious. Many organizations shuffle it around, desperate to hand it off to anyone willing to take on the challenging task. Others fight over it, demanding complete ownership to ensure they get what they want out of the test. In the end, who has the best argument?
Marketing seems to make sense. The product manager ultimately owns what is delivered to market and the feedback generated in a beta test is critical to both current and future products. Beta tests generate lots of valuable marketing data including testimonials (via Praise) and user feedback about product concepts. As the owner of the beta test, Marketing can use the entire process to help deliver a great product to the customer.
Engineering is an obvious place for a beta program to reside. Beta tests prove design implementation and identify product issues. The feedback users provide can reveal critical data about the success or failure of Engineering’s implementation of a design. The Engineering Team needs beta testing to validate and deliver a great product to market.
Quality Assurance certainly is a big stakeholder and a natural owner of the process. Even its name evokes its right to the procedure. Feedback from a beta test helps reveal critical bugs and exercise the product before its launch. Moreover, the QA team is responsible for ensuring the delivery of a quality product. Beta testing has a natural place in QA and it is hard to argue against it being the proper location for beta.
Support has to face the actual people who buy the product. As a beta test is a process involving the actual customer, Support is at the forefront of wanting involvement in the process. The data gathered in the test is incredibly valuable to Support and the customer experience after a product is shipped is tied to their involvement in the beta test process.
Beta as its own high level organization is certainly ideal. This offers the benefit of focus and dedicated resources, hopefully with a direct line of communication to each of the departments noted above. Yet the reality is that most companies can’t justify a separate beta department. The inconsistent workload of a beta program means that only larger companies can keep them occupied year round.
Outsourcing is also obviously an option. Companies like ours (Centercode) provide this as a service, which is nice for two reasons. First, it allows for a more wide-ranged take on beta, due to no allegiance to any specific aspect of beta (quality, marketing, etc). Second, it helps balance workload for companies who would have trouble dedicating resources to the process during key periods of their development process. Yet, some workplaces struggle with this situation because it means handing over an important process to someone outside their company. Depending on the needs of the team and vendors selected, the other company may or may not be geographically convenient. Nearshore outsourcing can be a strategic solution in such cases, offering closer collaboration and time zone alignment due to geographical proximity.
Defining which department should own the process can be tough, as each group can make a good case for ownership. That said, if you’re creating a new beta program, or shooting for a major overhaul — and are still conflicted as to where your beta program should live, then we would recommend Quality as the best candidate.
Certainly each group mentioned should keep an active role in the test. Yet, Quality is ultimately responsible for ensuring the delivery of as few defects as possible, and discovering these issues is a primary role of beta testing.
It also just makes a lot of sense for beta testing to complement the quality process. Remember, when things go wrong, the first question is generally “Why didn’t Quality didn’t catch it?” Having a large stake in beta equips Quality teams with a much wider net, helping ensure that question never needs to be asked.
In addition, given the right tools QA engineers make great beta managers, allowing QA managers to turn a single employee into a representative of hundreds of real customers — who generally identify more issues and generate exponentially more data than any individual QA engineer could ever accomplish on their own.
To learn more about how beta testing benefits your entire organization, click below to check out our free resource, The Ultimate Guide to Beta Testing.
