In some of the previous posts, I have been talking about the issues and processes involved in ensuring that the interaction with the vendors (especially when they are involved in testing) is fine. In the last post (Working with vendors to ensure that tools are synchronized), I talked about how the team should be spending time on defining a process for transferring knowledge about the tools used by the team during testing. Now, this is easy for tools that are in generic usage, such as tools for Defect Management, Source Safe, or for capturing the details of Test Plans and Test cases. However, this is more complicated when the tools are specialized such as Fiddler, and other such tools that take time for vendors to learn more.
In this line of thought, there are several other processes that the team needs to transfer to the vendor team and do this in a systematic way to increase the level of efficiency. Some of the processes that the team might need to convey to the vendor team are:
- Certain specific processes such as the dealing with defects that have existed for some time. Consider the case of a defect that has been present in the product for more than one version, and the team has decided that they do not want to make the fix. Similarly, there may be cases where there is a difference of opinion with respect to the functionality, but anybody who needs to do this testing will be able to log a defect. In such cases, the team members know about these defects and do not try to file them, but somebody who is new to that area such as a vendor team member will not know, and will file defects in such areas. It is for the product team to ensure that they have transferred instructions regarding how to handle these defects to the vendor. If this does not happen, there will be wastage of time when the vendors actually do these testing. I saw such a case whereby there were some new members to the vendor team and there was a delay in passing on such information, and suddenly there was a buzz in the team about the vendor finding a number of defects that the team members had not found. There was some pressure on the testing team, but then it was found that most of these defects were of the types that the team already knew about, and there was a sigh of relief in the testing team (they would have come under a lot of pressure if the vendors found a number of defects that the core testing team was not able to find).
- Similarly, there are certain points of focus for every release. Or it could be the case where this is a patch or dot release that is focusing on a certain area, and it is incumbent on the product team to pass on the application focus onto the vendor team. This is needed to ensure that the testing done by the vendor team focuses on the relevant area instead of spending time on other areas which are not relevant. The team needs to decide on the best way to do this, one way to do this is to take the application where test plans and test cases are captured and create a plan that shows the vendor the focus areas where testing needs to be done. However, this pre-supposes that the test cases are written in a way that a subset can be used by the vendors and would make sense.
In this line of thought, there are several other processes that the team needs to transfer to the vendor team and do this in a systematic way to increase the level of efficiency. Some of the processes that the team might need to convey to the vendor team are:
- Certain specific processes such as the dealing with defects that have existed for some time. Consider the case of a defect that has been present in the product for more than one version, and the team has decided that they do not want to make the fix. Similarly, there may be cases where there is a difference of opinion with respect to the functionality, but anybody who needs to do this testing will be able to log a defect. In such cases, the team members know about these defects and do not try to file them, but somebody who is new to that area such as a vendor team member will not know, and will file defects in such areas. It is for the product team to ensure that they have transferred instructions regarding how to handle these defects to the vendor. If this does not happen, there will be wastage of time when the vendors actually do these testing. I saw such a case whereby there were some new members to the vendor team and there was a delay in passing on such information, and suddenly there was a buzz in the team about the vendor finding a number of defects that the team members had not found. There was some pressure on the testing team, but then it was found that most of these defects were of the types that the team already knew about, and there was a sigh of relief in the testing team (they would have come under a lot of pressure if the vendors found a number of defects that the core testing team was not able to find).
- Similarly, there are certain points of focus for every release. Or it could be the case where this is a patch or dot release that is focusing on a certain area, and it is incumbent on the product team to pass on the application focus onto the vendor team. This is needed to ensure that the testing done by the vendor team focuses on the relevant area instead of spending time on other areas which are not relevant. The team needs to decide on the best way to do this, one way to do this is to take the application where test plans and test cases are captured and create a plan that shows the vendor the focus areas where testing needs to be done. However, this pre-supposes that the test cases are written in a way that a subset can be used by the vendors and would make sense.
No comments:
Post a Comment