Different Testing Needs Across Industries

Over the past fifteen years, I’ve worked as a software testing engineer for several companies. The products I’ve worked on range from navigation and fitness apps at Garmin to a start-up social music app, to online banking software, to software for the legal services industry (to name a few.) In my experience, every organization has unique testing needs, and corresponding processes have to be implemented so those needs can be met. While most software development teams use agile methodologies, the approach to development and testing must be customized to fit the product and team.

When it comes to testing, everything from how test cases are documented, organized, and recorded, to how regression testing and smoke testing is done, will be unique to the situation. There’s no single approach or process that fits every testing team. There are many reasons why different testing approaches between industries are necessary. If you are a QA engineer in one industry and decide to make a move as a QA engineer to another industry, you might find it difficult to adjust at first to some of the changes.

Here are some reasons why a unique approach to each testing situation is necessary, as well as why certain aspects remain the same.

The Product

When it comes to testing across organizations, the biggest difference you will see is the in the product and its intended use. Obviously, there is a wide range of software products that could be tested. For example, a start-up developing a simple game app would use a testing approach that is significantly different from that of an organization developing life-saving medical software products. This makes for a wide range of products that a QA engineer could be tasked to test. Let’s say you work for years testing in a financial institution where test cases are scrutinized and audited, with releases eventually being tested by a large team, making sure all boxes are checked. Then, let’s say you change jobs and join a start-up organization developing an entertainment app that is trying to gain traction in the marketplace.

At the financial institution, the release will be meticulously planned and executed by multiple teams within the organization, but at the entertainment start-up, the QA team (or person) may be notified by that a new feature needs to be released as soon as possible at the request of an investor. This may mean releasing the feature “as is” to secure funding for the product. As you can imagine, the role QA play in each scenario and the processes followed are quite different. If you took testing processes and procedures from one of these organizations and tried to implement them in the other, it would obviously not end well in either case.

Testing Resources

When it comes to QA team contributions there are many determining factors, including an organization’s mindset. In the case of a lot of products, the bottom line will obviously play a role when decisions have to be made on the level of testing resources to fund. As a result, the functions of the QA team can be more limited in some organizations than others. Some consider QA as “nice to have,” where other companies see QA as absolutely vital to the success of the product and organization.

Where QA is considered a vital asset, you will see more resources not only in employee count but also in tools, automation and overall contribution to development. Alternately, other organizations who don’t give QA as much priority might not think it necessary to much in-depth testing due to resource constraints. (Think of the entertainment app example earlier.)

Differences in resources contribute to the philosophy of the QA team. Where a large team is present, certain tasks such as test case writing or automation might be given to a particular person or team while other team members focus on test case execution. If you are part of a development team that has only one or two testers, you might find that you need to change gears multiple times a day because you will need to cover every aspect of your team’s testing needs.

Success or Failure

With every project, regardless of the industry or the product, the goal is success. Whether that comes after releasing a product following multiple years of development and testing in the medical industry, or the release of a small feature within a mobile app in less than a week, the goal is the same. Release the product in a way that drives success for your company, in whichever industry, as it is today.

Reputation

One thing that never changes is the damage that can be caused by releasing buggy software.

Sure, your entertainment industry app isn’t about saving lives. But, if your app is buggy and your competitors app is not, you won’t succeed in the long run.

Your product, and ultimately your job, depends on the reputation your product takes on as a result of its perceived quality. This is true if you have ten users, or even ten million users.

Conclusion

The primary role of QA doesn’t change across different products or industries, because the goal is to contribute to the success of the product. If you are tester looking to expand into other industries, remember not to dwell too much on the way you did things in the past, whether the past is ten years ago or ten days ago.

Be ready for a new approach, even if it seems to go against what your experience tells you is right. And besides, it’s good practice to step back and make sure you aren’t following a testing process just because you did it that way in the past. Sometimes it takes a 10,000-foot view to see the best path to your destination.