As testers we are often caught in the middle, if fact it happens so frequently you may not even realize that it is occurring. It can be awkward, it can be frustrating but after a while you end up being fluent in the languages of business and software development.
Then like most people that can speak multiple languages you end up spending a great deal of time translating for other people.
Between Expectations and Realities
Software often starts with some pretty vague requirements, even if your team is using acceptance criteria it's not a detailed blueprint of what is going to be built. Even down that road with waterfall style development, we found that expectations are not always clearly conveyed or universally understood.
Enter the tester, using whatever oracles of information that can be found we begin the process of evaluating and identifying the explicit and implicit expectations of what is being tested. Once our internal expectations are built up we go about translating those feelings into actionable interactions. This could be in the form of bug reports, conversations, or other documentation but we'll dive deeper as is only the initial phase of translations.
Between Developers and Managers
Let's assume after building up a model of expectation about the system under test, we happen to uncover an inconsistency. To resolve this issue you end up in a hallway meeting with the developer and program/product manager. This might seem like a common interaction, but lets decompose it and focus on what is expected of the tester.
You start by explaining the issue to the manager, they have a good grasp of the product but aren't necessarily the most interested in the specific technical details of this issue. The tester is then responsible for communicating the issue in language that the more business minded person can understand.
The developer then chimes in with some clarifications able the technical ramifications. The tester must on the fly process the technical information, possibly explain the relevance to the manager and often refute or defend the issue in terms that satisfy both the developer and manager.
Imagine in the context of a news interview, asking the person translating between the news reporter and interviewee to provide on the fly commentary that both sides could understand.
Between Development and Deployment
Traditionally our focus has been that if software is functioning as we expect (well mostly), then we might sign off on a release. While testers may be progressing away from being a quality guardians, we are still often asked to translate if work is ready for release or increasingly frequently might be responsible for deploying the release.
Now here we are again spanning domains, only time we expand our language skills into operations. Testers might be deploying the software, or they may be supporting on premise installations. In either case you'll probably run into a "works on my machine" dilemma, and you may find yourself interpreting between IT requirements or restrictions and development practices to various members of your team.
Between Creators and Consumers
It could be through your company's public bug tracking system, it could be in your organization that testers pull double duty and assist in customer support or somewhere in between. When an issue gets reported from an external source it often gets assigned to a tester to investigate. The tester may also take on the role of trainer since testers often have the most experience with updates to the product. In any case you are seeing your product through a lens that few people with the ability to impact change have access to. It also opens you up to a fair amount information that is essentially background noise and distraction. It's a testers job to translate this feedback whether it's a direct communication or the indirect understanding of customer needs into words and actions that your developers and managers can understand and act upon.
So Why Is This Important?
What it means is that while technical skills for a tester are important, we are primarily communicators. It's easy to lose sight of that as testing roles shift left. Your day-to-day activities may lean heavily toward the product management side, or they may seem to have blended with developers (mine has) but the biggest value a tester brings is their ability to bridge the gap between different disciplines. Additional knowledge be it technical, product or project related just enables you influence and guide your team toward higher quality more effectively.