My first goal in any new company is to make friends with the Customer Support team. They are a wonderful source of valuable information, particularly for the QA team and there are huge payoffs for both teams in creating a close alliance. They are the experts in helping to answer the following questions:
What is really important for our customer?
The QA department should be able to represent and advocate for the customer needs during the requirement, design and the defect severity evaluation stages of the SLDC. Often the best source for this knowledge is the Customer Support team. QA should continually review Customer Support reports and customer reported defects. One story that illustrates this – we had a minor defect that was found during the QA final testing where the tab order on the screen changed. The product ended up shipping with this not fixed as it was a low severity and low priority but our customers had a fit! The order entry staff used the tab key continuously when entering orders and changing the order caused them a great deal of annoyance and slowed them down. We ended up having to issue an emergency hot fix. Had we known how important the tab key was, we would not have given this a low severity in the first place!
How do our customers use the application?
On another occasion, I asked the Customer Support team where their most frequent problems came from and was told the API interface which surprised me because the majority of our QA testing was through the GUI! It turned out that most customers had legacy applications that used the API to communicate our application and they only used the GUI to troubleshoot problem issues. We quickly changed our focus in QA to have more priority testing for the API interface. Once we started testing through the API, we were able to develop an in-house automation tool which quickly surpassed our WinRunner GUI tests for efficiency and ease of use with much less maintenance than the WinRunner tests needed. Often customers find short cuts or variations in how to use the application that were never document or part of the original design and these should be reflected in the regression test cases. How many times have we found that we accidentally eliminated an undocumented short cut that our customers had come to depend on? More communication with the Customer Support team can help eliminate some of these problems.
How well is the QA team performing?
As I mentioned in an earlier post, QA cannot say that an application is defect free but only that no defects remain to found when testing the majority of the application. But how accurate is this statement that no defects remained to be found? The way to find out how well we did is to check with the Customer Support team and see if the customers are finding any defects. Each defect found by a customer should trigger an investigation into the QA regression tests to see how this was overlooked and a new test case should be added to the regression suite to cover this missing scenario.
Encourage cross training between the QA and Customer Support teams
Where possible, I always try to have the QA team spend some time in the Customer Support department and also have the Customer Support team help out with the regression testing. It promotes better insight into customer issues and improvements to the quality of the regression tests. It also helps train the Customer Support team on the new functionality before the product is released. Even just scheduling a joint team coffee break over coffee and muffins to swap stories will generate ideas for improvements.