Daniel is the scrum master for a financial product and his team is responsible for the front office processing. Thamizhan is the QA lead for this financial product. They often work together to keep the quality and product wellness in perfect shape.
Regression testing of the product takes almost 4 weeks to complete and in case bugs are found, this period gets extended. This brings skepticism within the user community in asking for changes in the product as it’s hard to predict the release date.
In the beginning of the year, they together brought out a set of Definition of Done (DoD) criteria to improve the automation and the unit test coverage within the product. Further, they moved to a cross functional team where developers also started writing automation scripts and executing manual test cases. The third aspect they brought is to include a set of automation engineers to improve the automation of the regression bed. All three steps would be needed to improve the time of the regression testing and to achieve a predictable release date.
Teams started following the DoD in letter and spirit even though they had to spend more time to start with. During a recent sprint, it was found that the automation scripts were not updated as per the DoD criterion and Thamizhan sent a detailed note to all the team member re-iterating the steps that the teams needed to do to ensure that quality remains high. He added that one of the QA members needed to sign off on all the scripts going forward.
Daniel felt that this is a step backward in the practices that allowed the team to move towards cross functional teams, automation co-owned and improved collaboration across analysts and developers.
Have you faced such a situation? What can you do if you were in Daniel’s position or Thamizhan’s position?
Suggested solution:
While automation and regression continues the shape how quality is accepted and upgraded, it is important to keep the principles intact.
In this situation, Thamizhan seems to be of the belief that withholding quality goals is only the QA teams goal and not the entire teams’ goal. Reminding ourselves about the goals for the team should help.
Another immediate action that I as a coach would do is run a ‘Hopes and Concerns’ session with the entire team. Every scenario has two sides of the same situation. Its possible that Thamizhan is trying to solve the wrong problem. They would have to have an open conversation (kind of like a retrospective) with this topic and discuss what the concerns of the team and have a way to solve the problem.
This would lead to two benefits
A. Everyone is involved in understanding the exact problem and are part of the solution rather than thrusted upon by one lead
B. Quality becomes everyone’s goal and not only one function.
Next question that you may get is, then what is the QA leads role? Cant they enforce any changes in processes?
In the changing environment, QA roles responsibilities are
I. Enabler – Enables the teams to use the right practices and leads by example by understanding of using the right level of automation & regression that makes the product more valuable
II. Influencer – When there is regression in terms of practices, influencing the team by way they are thinking
III. Domain/SME – Another dimension that I am seeing very successful QA personnel is that of a subject matter expert of the product by bringing out multiple scenarios as well as pair with the product manager in creating solution that is most appropriate.
Hope this works well as a solution.
