The above helped reduce the Engineering team’s time and effort in fixing minor issues. The support team as a result felt more empowered, valuable, and motivated.  

 

This was a smooth and obviously beneficial process but only by the time the product had relatively few features. If there were any impact on any of these features, the Engineering team is swift enough to fix it, test it and release it.  

 

However, in a few months’ time… few product issues started cropping up. Upon analysis, it was found that these were due to some of the fixes done by the support team!  

 

As part of our reviewing this process, I suggested a simple process:  

 

Identify impacted area —>Review by Engineering team —> Code changes (by support team) —> Required Testing  

 

Below situations will determine who owns the Testing activity  

 

Situation 1:

 If the impacted areas are minimal and focused regression tests are minimum then the support team itself would perform the testing activity  

 

Situation 2:

 If the impacted areas are medium or high and/or focused regression tests are high in number then the test team would take over the testing activity  

 

Benefits observed:  

• A habit of consistently delivering quality product updates

• Improved confidence of the support team in the changes they are doing to the production code

• Further time and effort saved of the Engineering team  

 

Thus I feel, in today’s fast-paced SaaS products; it is crucial how your Engineering team keep on evolving in their working style as the product grows and matures…  

 

Else, we have seen companies going downhill in no time!