Walk through the test strategy with the rest of the product team - Call in a meeting with key stakeholders from the entire product team and explain what the testing strategy would be. This helps them understand the overall test methodology, test environment, key resources and timelines and their role in the overall test lifecycle. The test manager/director needs to ensure this meeting happens early on in the product lifecycle as an in-person or an online meeting to ensure the product teams buy in.
Such meetings need to percolate at various levels in the product team to promote lateral discussions and reviews and need to be managed by the head of the testing efforts.
Work with the product management team in finalizing user scenarios, incorporating field feedback and finalizing core metrics and data such as product performance numbers. The test team is the one that best understands the test environments and test data that will be used to simulate and test user scenarios. So, it is important for them to work with the business team in explaining additional product and feature design opportunities, test constraints, competitive analysis, etc., to help the business team finalize realistic, yet cutting-edge, product functionality.
Work with the development team to highlight core scenarios that test would be watching out for. Educating developers on such tests to be run, will help them additionally watch out for those areas up front, reducing chances of defects. Test should also explore the possibility of building a set of unit tests/build verification tests, which developers can use every time they check in new code. This will help catch any basic build breaks even before the test team looks at the build, thus promoting a very efficient dev-test handoff.
Deployment Team - If a deployment team exists, the test team should work on providing them a set of build verification as well as regression tests that they need to run every time a build is deployed. This will empower them to catch basic issues sooner and work with the dev team in resolving them while the test team can focus its efforts on more important areas such as test automation, performance testing, security testing, etc., and more system-level testing to best use their skills and competencies. For teams to take on such additional responsibilities though, the test team should do its part to make adoption as seamless as possible. They should look at providing the right test infrastructure, providing automated test suites (that have been well tested), required test data etc. to reduce any unwanted overhead for the other teams.
Operations Team - Quite often, the test team is pulled in very quickly as soon as a customer reports an issue from the field. While it is important for the test team to get involved in such cases, there are several cases, where the issues may not be real ones or they may be known issues that the team has decided to live with at this point of time. If the test team can work with the operations team up front, giving them an overview of existing known issues, workarounds, quick fixes, high level tests to run in a debugging process, etc., they can empower and motivate the operations team to handle a lot of the customer issues themselves. This saves time for everyone involved and can possibly even provide a faster turnaround to the customer. A knowledge base/guide can be prepared and built upon as an evolving document to handle ongoing issues over releases.
Effective defect management practices to all - Defect management is an area where test can additionally add value by reducing the product team's overhead. When multiple teams are working on a tight release, having a robust defect management process that is not very cumbersome and that everyone understands not only helps with everyone's productivity but also with the overall product's quality. If defects are not tracked and managed well, there is a very high chance of defect slippage, partial fixes, ongoing regressions all of which greatly impact product quality and burden the overall development costs. Specific to each project's requirements, the test team can create a set of defect management best practices, own it and educate the entire team about it. This could include several things such as:
What to include in a bug so as to increase the probability of reproducing it at the first shot
How to resolve bugs
Defect management timelines and service level agreements (SLAs)
How to handle bugs across platforms, locales, markets
Special tools to use for capturing bug repro steps
Conduct periodic bug bashes - Every quarter or so, enabling the entire product team to take the time to test the product and provide feedback. This will also help the test team uncover any issues it may have missed and further clarify its understanding of the product based on reported issues. Such cross-group exercises also help in team bonding across disciplines.
Clearly, the right levels of communication are very important to make all of the above happen at the right time and with the right entities. When such communication and cross-group collaboration happens along areas mentioned above, the test team would have clearly made its mark in improving quality not just in its own areas, but truly across the board, helping create a great product for the end users.