Bind teams for best product results

In my previous post, I discussed about the 3 M’s—Miscommunication, Misrepresentation and Misconception—factors that can play havoc with what a product looks like at the end of its development cycle. I had also said that it is improper collaboration between the business stakeholders, and the development and testing teams that could derail the product, and impact its overall quality.

In this post, I would be focusing on the steps that companies can take to avoid the pitfalls of the 3 M’s, ensuring complete coordination and cooperation between all the teams, hitherto working in silos. In simple words the solution is as simple as binding these different teams together, so that they think as one and work as one. By eliminating the barriers between the teams, aligning their different and distinctive working styles and unifying them in a single environment, it is possible to beat the bottlenecks.

The three challenges, need three solutions, or should I say, three simple steps.

Step 1 – identify the Tools and Frameworks that are used by the project teams on a recurring basis. There is also need to figure out the various Frameworks that are being used either to develop or test the applications.

Step 2 – Identify the Practices that are followed by the team at each phase of the development and testing process and further segregate the Tools and Practices based on their areas of usage.

Step 3

Step 3 is to rightly blend the tools and practices that have been identified in step 1 and 2; and integrate the same, bring them together.

Step 3

The three steps make it possible to understand how the practices are linking up with each other using various Tools and Frameworks. By rightly blending the Tools and Practices that have been identified in Steps 1 and 2, and bringing them together, companies can reduce various ambiguities that remain in the teams while performing testing.

It is also possible to develop a platform that integrates the tools and activities performed during development and testing. This platform can help in synchronizing the tasks, finally leading to productive testing. Furthermore, this platform can be made generic so that the teams do not need to change or replace the tools to enjoy its benefits.

Do let me know what in your view the solution to the 3M’s conundrum is, and how you have managed to overcome these challenges on your own turf.

Successful product testing and development – Watch out these 3 M’s

[Organizations often look for testing solutions that can help them quickly test and launch/position their products in the market to meet user needs, while maintaining lower development costs and higher quality standards.]

Most of the time, the solution they are looking for is dependent on the amount of collaboration that exists in their teams. In order to develop better, more relevant products for the target markets, one must ensure that all the stakeholders within the product development eco-system should work together. It is the unity, collaboration, cooperation and team work that work wonders when it comes to creating products that wow customers. Now the question comes… who all constitute the product development eco-system? Well, if we look at the broader level, they are business stakeholders, developers and the testers.

In fact, team collaboration wins hands down when one is discussing the most important factor responsible for successful product development i.e. Testing. This team play has to take place across the product life cycle—from the time the product is conceptualized, to the time when it is finally delivered to customer. As the saying goes, “It is not a question of how well each process works, but how well they all work together!”

In my experience, absence of team collaboration results in poor testing and reduced productivity and efficiency that have a spiraling impact on the product quality that is finally delivered to the customer.

In general, there are three factors that can make or break a product. As long as product teams can overcome these three challenges, they can deliver products that confirm to international standards and exceed the expectations of their users. These factors are what I call the 3 M’s: Miscommunication, Misinterpretation and Misconception.

These factors together can result in huge losses to the enterprise. As per Forrester Research, poorly defined applications contribute to 66 percent of the project failure rate, costing US businesses a whopping USD 30 billion every year!

If the business stakeholders, development and testing teams share information that is clear, concise and represents exactly what is expected from each other, the first lacuna of Miscommunication can be overcome.

By providing sufficient facts and data to back what needs to be done, the teams can also deal with the Misinterpretation.

The third factor, Misconception is about a mistaken thought, idea, or notion that creates discontent. It can be overcome by avoiding unnecessary metrics to avoid false impression that are generated during the project.

As of now I would recommend to watch out for the 3 M’s while working in your respective teams that can save considerable efforts and resources during any product development life cycle.

In my next post I will be talking about three basic Steps that can help you effectively manage/sync-up these 3 M’s. Stay tuned!

Top challenges faced by Product/Test Owners during Product Testing

Performing software testing looks always to be an easy task for an outsider who does not belong to testing community but for most of the product/test owners it has always been a challenge to do it RIGHT most of the time. There are various instances of defect leakages in the past that have caused multi-million dollar losses to various companies and agencies. For a more detailed list of such issues you can visit site (

The product/test owners who are part software PDLC often face the following challenges that are either addressed by them internally or they need to hire external consultants to overcome them.

#1 Are we doing the right thing the right way?

#2 Is my testing team doing enough testing?

#3 Wish I had more budget to test more…

#4 The product has to ship tomorrow not sure if will have tested it enough

#5 Is my product of acceptable quality?

#6 Shall I outsource?

With all the above challenges, the idea is to understand whether testing is taking the correct route and leading to a greater understanding of the product, its strengths, weaknesses and market potential.

The first question that comes to mind of a product/test owner, whenever any testing assignment is started is “What to test”. It is quite a tedious task and needs a thoughtful thinking while deciding on the areas that needs to be tested for delivering a better quality product. If we do not define it at the starting, it becomes a very painful task going forward and various stakeholders keep on guessing the outcome of testing.

Once it is decided as to what to test, the next challenge comes in “How to test” It is indeed very important to select the right tools and activities amongst the that should be performed to do the right kind of testing to achieve desired test coverage. Desired test coverage! Did I talk about this?

This is again another challenge to decide on “how much to test” so that the test team can say that the product is ready to ship. It is tough to clearly differentiate and define the exact time of closure of testing activities. Once the scope and methodology is selected and decided upon, the next is the identification of Risks that needs to be identified upon and a mitigation plan needs to be formed for the same. Risk identification should include risks throughout the life cycle in the areas like cost, schedule, technical, staffing, external dependencies and maintainability and should include organizational and programmatic political risks. Risk identification need to be updated regularly. Risk mitigation activities need to be included and communicated to various stakeholders.

Even if one has clarified and answered each of the questions that are discussed above, one doubt still remains throughout the testing process. It is “Will all the bugs be reported during testing”. Though everyone knows that Testing does not guarantee reporting of all the bugs, but effective and efficient testing does guarantee the reporting of all the critical defects that exist in any product for its smooth running after it goes live. Still, the product/test owner has to face a lot of heat if even a single defect is found by end users after going live and there is a question mark that is put on the complete testing cycle. So it becomes a big challenge to find out the bugs during the testing cycle.

Product/test owner has to determine at the outset whether their teams are doing enough testing. This is not as simple to identify as most of the time product/test owners do not have complete visibility into the testing process that is being followed by the testing teams. There is sometimes no way to identify whether the team is spending the time correctly on various tasks that are being assigned to them. To identify that the test team efforts are being put in the right direction for getting adequate test coverage is a big challenge. If these efforts are not measured and corrected at the right time, then it might create a bigger problem at later stages and the overall test coverage achieved might not be up to the expectations of the stakeholders. And after this, to validate the product status that has been reported by the team is also a challenge that is hard to meet.

At the same time, product/test owner have to examine whether the product is finally market ready and of acceptable quality for clients.

One of the major challenges faced by product/test owners is to identify the correct budget for testing activities. It is often seen that there is not much introspection done to decide on the testing budgets and they are fixed more on the random basis e.g. fix testing budget as 30% of development budget or so on. But for a product/test owner it is tough to plan (as much as possible) for the budget that will be required during testing of the product? The correct identification of the correct tools, resources, skills, required during testing, remains a major bottleneck for the identification of the correct budget.

Finally, they are also grappling with the question related to outsourcing and considering outsourcing as an option when drawing up testing strategies. But for the beginners, thinking outsourcing has its own challenges like how can I know who is doing what within the team, does the team understand the product domain and functionalities completely so as to take the testing assignment and whether they value my IP and will it remain in safe hands even if I decide to outsource.

In my next post, I will be detailing out on some of the possible solutions that if implemented within any testing team, can help in overcoming the challenges listed above.

Do feel free to put in your comments on this post.