Collaborating with the Product Team on Testing to Improve Quality

Rajini Padmanaban
Product quality is no longer the onus of just the test team. Quality awareness and ownership is now becoming a collective responsibility of the entire product team. The test team, which has traditionally owned product quality, plays an even greater role in this current-day scenario of not just doing their part in ensuring quality, but also educating the rest of the team on what product quality is all about. In this short article, I will touch upon some important things that the test team could do, to help collaborate with the product team in this drive towards improved product quality.

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

Scalable infrastructure, accessible environments, use of ALM - When multiple teams work on a project and are especially globally distributed, the challenge often is around how to use an environment that is accessible to all, how to share artifacts, etc., that everyone needs. A lot of time is often wasted on resolving such access issues. In the best interest of the entire team, the test team can take ownership of maintaining test beds not just for their use, but that can be leveraged by the entire team. Scalable infrastructure has been a breeze lately with advent of technologies such as cloud and virtualization. Test team would command a lot of respect if it can keep itself abreast of such latest technologies that will help improve the overall team's productivity. Even if the rest of the product team has not implemented an application lifecycle management (ALM) tool, the test team should certainly look into doing so, given the number of artifacts it uses and needs to share with the product team, as discussed above. If the test team can take the lead in implementing such solutions, it certainly creates a lot of efficiencies and also motivates the other teams to follow.    

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.

Add Comment      Leave a comment on this blog post
Nov 3, 2011 12:11 PM Raja Sundaram Subramanian Raja Sundaram Subramanian  says:
Rajni, this is a very insightful blog and I completely agree with you on the fact that a collaborative effort amongst the teams can play a key role of a catalyst in improving the quality of the end product. The collaboration amongst the business, development and testing teams can reduce the risk during the entire software development lifecycle and considerably improve the overall quality of the end application. As a testing practitioner myself, I believe that the testing teams need to begin collaboration at a stage earlier in the entire software development lifecycle. To know more how this can be achieved, please visit: Reply
Nov 10, 2011 6:11 PM  says:
Thanks for taking the time to read and comment, Raja. I enjoyed your blog post too! Reply
Nov 10, 2011 6:11 PM Rajini P Rajini P  says:
Thanks for taking the time to read and comment, Raja. I enjoyed reading your blog post too. Reply
Nov 10, 2011 6:58 PM Rajini P Rajini P  says: in response to Raja Sundaram Subramanian
Thanks for taking the time to read and comment, Raja. I enjoyed your blog post too! Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.