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 life cycle. The test manager/director needs to ensure this meeting happens early on in the product life cycle as an in person or an online meeting to ensure the product team’s 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 prod3izing user scenarios, incorporating field feedback and prod3izing 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 prod3ize 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 upfront, 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 upfront, 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 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 which will help improve the overall team’s productivity. Even if the rest of the product team has not implemented an ALM (Application Life Cycle Management 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.

Test Center of Excellence (TCoE) is a term that is gaining a lot of visibility in the recent years due to the benefits of this execution model that have been widely talked about. When carefully planned for and diligently implemented this model, certainly has a lot to offer to improve the overall test team’s productivity and efficiency. This write-up aims at talking about things to keep in mind in such a TCoE implementation to make the overall adoption process smooth and successful.

Firstly, let’s look at what a TCoE is. A TCoE is a team model where multiple teams come together to work in a “shared” mode to share knowledge, best practices and resources. It is a model which retains the core specialization of individual teams yet offers room for cross team collaboration.
The ideal operating model to be implemented for a TCoE will be one that leverages the strengths of the TCoE setup and at the same time that does not add too much overhead and bureaucracy to the overall setup. It will be setup as a model that promotes end to end collaboration, yielding:

• Team load balancing
• Cross product knowledge
• Tools and process sharing
• Faster team ramp up
• Access to specialists

Individual silos with core teams will be setup for specific projects so as to have focused test effort to meet the quality needs of each of the projects. These individual teams will be managed by lead level resources who will manage daily project deliverables. Virtual teams will be setup with specialists to handle specialized testing needs such as performance, security, globalization, accessibility/usability across the TCoE projects. Given that these testing needs do not span throughout the Software Testing Life Cycle (STLC) and these resources are expensive they will work as a virtual team to address the specialized testing needs of all the projects in the TCoE umbrella, rather than just one project. All these leads, their respective teams and the virtual specialized teams will report to a test manager, who will manage the overarching TCoE. He/She will ensure:

• Projects share common best practices
• Teams understand the bigger picture and quality requirements at large so as to drive value upstream
• Teams are empowered with the required common training
• Buffer resources are maintained across projects to take care of flexible and dynamic project needs

Such a test manager will work closely with the stakeholders from the product team and conduct quarterly reviews reflecting the work done under the TCoE umbrella helping everyone on the product team understand and be on the same page about the project and product status and health, from a QA standpoint. This review will not be just a retrospective/backward looking meeting, but will be proactive in focusing on the road ahead to practically implement an objective QA effort.

The test manager should encourage monthly meetings of the entire team, inclusive of all projects in the TCoE umbrella. During such meetings the following could be discussed: Project accomplishments, challenges, work arounds, presentations made by team members on specific products/new technologies. Such monthly meetings could also set aside 15 to 30 minutes for cross group bug bashes, allowing testers from other teams to test cross group products. This promotes cross product knowledge as well as helps find bugs that the core team may have missed. Such meetings bring in good team bonding which plays a major role in the TCoE’s success. Email aliases should be setup for intra project and inter project communication helping share useful information to the required set of people on time. Dedicated trainings should be conducted periodically either during monthly team meetings or outside of such sessions. Depending on the size and scale of the TCoE implementation the test manager should determine the size of the buffer team to be maintained. Such a team will be trained and ready to work on any of the TCoE projects within a very short lead time. Typically a 10% shadow/buffer team of the overall team size is a good size to have providing the flexibility of the shadow team yet not being an expensive overhead to maintain.

Thus, a TCoE has its own nuances for a right implementation. A test manager plays a very pivotal role in its successful implementation. As a first step the test manager should get buy in from the overall product team in educating them about the model, how it works etc. and then carefully implement the TCoE as a step by step process. Such a planned approach along with the test manager’s objective mindset open to feedback will help make the overall model a success and well received by the entire product team.

We, at QA InfoTech, have successfully leveraged the TCoE model for some of our strategic project implementations including one for a leading ISV in the rich media product space. Our team strength for this account at peak times has been upwards of 75 people. This included testers’ onsite at the client’s location, and in our premises, each working on different release cycles, reporting into various client managers. From our end, we had an overarching TCoE setup which accommodated the individual needs of each project but provided specialists across the board. Our common pool of buffers combined with different release cycles at the client’s end, helped us effectively load balance resources. Such cross sharing of resources also helped share knowledge across projects, build detailed product and process training material and also the entire team understand the overall mission of the test effort. Such a team setup not only helped provide great opportunities to our team but also share the economies of scale with the client in providing cost effective services at a much faster turnaround.