This post arose out of a question that a new manager of the team had for us, the middle management of the team. His basic question was that in the initial part of the cycle, where there were the requirement being framed by the product manager or the product management team (depending on how large the product was), and these requirements were being broken down into smaller features and tasks for the purpose of estimation. Even after this, there was the period where development of the features was happening, and this would be done by the development team who would finally deliver the required code to the testing team, and they could start testing. So, what was the role of the testing team. For the moment, this question was not meant to figure out what to do with the excess testing team at these periods of time, instead it was meant to understand the role of the testing team across the duration of the project cycle, from the beginning to the end. And there was a lot of understanding of what happened when the testing team got the features from the development team, but not in the initial parts of the project.
We had a detailed discussion with the manager about this, and helped him understand this from the perspective of the team. The first essential part was that the testing team did not just do testing, so we should call them them the QE team. Testing was what people saw them do, but there was a lot more work that they did. We finally walked him through a list such as this one below, and if you do not some do some of these in your team, maybe you can get some tips from here. And if your team does other work, then please share these in the comments.
- The testing team is an essential part of the breakdown of the features into tasks and also with the estimation. Members of the testing have an incredible knowledge of the features and the workflows because of their testing of the features on a regular basis; this knowledge can be more than the developers and the product management. So if there is a feature discussion, the testing team can help figure out the workflows that are impacted; in one case I saw the QE member causing embarrassment to the product manager when the QE pointed out that the workflow that the product manager was advocating could be done in much less change than what the product manager was advocating. After that, the product manager made sure that the QE team was involved in all such discussions.
- There are numerous cases when the previously released product needs a patch or a dot release. In such cases, the actual development change can be very small, but the testing of that patch or dot release can take much more time, and need many testing team members for one or less development team members.
- When the team is developing automation for testing, the initial time period of the project cycle helps give them a time required for developing automation scripts for features that are already released (and the automation ensures that the testing of these features takes less actual testing time and more regular automation runs).
- When the developer is busy doing the coding, that is the time when the QE team member finishes up writing or modifying the test plans and cases.
- During the design process of the feature, typically the QE team members plays an essential role, working with the product manager, the workflow / UI designer and the developers to work out the actual details of the feature in terms of implementation. This can take many iterations if the feature is complex, and in my experience, in many cases, the QE team member has pointed out several intricacies of current implementation that need to be taken care of in the design.
