Archive for January, 2011

Problem on the table

Posted: January 26, 2011 by Vipul Gupta in Agile, Testing
Tags: ,

This idea came to my mind when I, alongwith Ajoy Singha and Vipul Kocher, were discussing on the agenda of first NCR Testers Monthly Meet (NCRTMM) that we started in December 2010.The main motivation behind developing this idea was to provide an informal space during NCRTMM where testers can discuss the problems that they face and get the resolution from other testers present in the room.

We have already implemented this in the two NCRTMM and attendees have found it beneficial. The testers  have utilized this space to resolve the problems that they face in their live projects.

This post of mine will provide the complete details about “Problem on the table”.

What is “Problem on the table”
“Problem on the table” defines a space that allows group of testers to interact in a simple and organized way to enable valuable dialogs that addresses the day to day issues that they get stuck with and want some expert help to get them resolved. This space encourages people to discuss and resolve the issues and be more productive within their organizations.

Fundamental Rules

  • No one will control your discussions
  • Whoever wants to provide help is the right person
  • Allow owner of the problem to steer his or her topic in the right direction
  • Always thank individuals whose suggestions have actually helped you

How “Problem on the table” works?

  • Come up with some interesting problem area that you would like to discuss during any NCR Testers meet to ITB NCR Chapter with as much detail as possible.
  • After receiving an email from your side, there will be a space allocated during the meet to discuss about your “Problem”.
  • Anyone attending the meet is free to walk to the designated area for your listed “problem” and provide their frank suggestions.
  • It is upto the owner how they would like to steer the discussion.
  • At the end of the session, the owner of the “problem” needs to present their “problem area” alongwith the best solution, that fits in their context using a defined template.

Benefits of owning “Problem on the table” session?

  • You manage and define your own agenda
  • As most of the test experts from the industry are joining the NCR Testers Meet, there is a high probability that you will be able to find the answer to trivial issues that remain unanswered elsewhere.

[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!

In one of my blog post, I detailed out the challenges that are often faced by the product/test owners during software product testing. In this one I will be talking about some methods or activities that can help in overcoming those challenges. I will leave it open for you to map the answers one on one to the challenges that I detailed out there.

Testing team is often involved very late in the PDLC. The product management team also collates frequently changing customer requirements and market expectations of a product, while also contributing to the product roadmap. As a result, the scope of the product changes constantly and testing becomes complicated with daily builds involved.

It is important to design the test strategy early along with the product roadmap so that everyone knows what all will be needed to test and what all methodologies will be applied during the process. This will enable the test owner to define the right budget for the testing cycle and get the necessary approvals on time.

There is a wide range of testing methods and testing techniques currently in use that serve multiple purposes in different life cycle phases. Team should choose the testing programs best suited to their needs.

Additionally, team must also focus on the cost element when identifying and evaluating testing tools available in the market. By picking Open Source tools, organizations can cut capital expenditure. At the same time, automated testing tools can also allow companies to undertake cheaper regression testing. Automation is again a debatable approach, might be I will share more thoughts on this in my upcoming posts.

It is also important to prioritize the test areas based on business criticality and test coverage. A test metric driven report also helps in getting the visibility into the exact team/product status from time to time. This enables management to take a decision regarding the market release of the product.

When examining the outsourcing option, companies must explore and clearly differentiate on what part of testing can be done onsite and what to outsource, while optimally using the collaboration tools. If there are questions of who is doing what, setup a transparent system in order to track each remote team member of the test team.

Currently I am busy designing a test solution that will act as a SINGLE solution to overcome all the challenges in software product testing space. It might be too early to talk about it or maybe you will need to wait for few more days before I start detailing about it in my blog posts.