When dealing with testing or development by external teams, there are a lot of infrastructural issues to deal with, and in a number of cases, teams have not prepared some kind of process documentation to take care of such needs and processes. Some of the external teams that can be involved in the process of development or testing for a software application include the following:
- External teams that are working as an extension of the testing team. This is getting more and more common, whereby the testing team can be expanded as necessary by adding vendors to the testing resources. However, when the these external vendors need to start their work, they need access to the testing infrastructure such as test cases repository and the defect management software.
- External teams working on the localization (conversion of the software into different languages). Such teams typically work on both development and testing of the application in different languages and need access to the source repository, as well as the testing infrastructure (test plan and case repository, defect management software, and so on).
- Teams working on the documentation of the product typically need access to the defect management software, since there can be several issues that need to be documented which are typically present in the defect management software, and the documentation team would be provided access to the defect management software.
For these 3 teams and others working in a similar area, if they are located outside the organization, then there may be a necessity for them to be provide the required VPN access to get access to all these tools. In modern secure organizations, such access policies would go through an approval process, and to ensure that such a process is accelerated, it makes sense to prep the approving authorities about these requests for approval.
- External testers / pre-release testers. Such pre-release testers typically do not need any access to source code repository or the testing infrastructure. However, these testers do need a platform where the defects they have logged get into the defect management software in an easy and transparent way (and where the testers are not expected to do any additional work - in some cases, it is as simple as providing them a web page where they can enter the defects that they have found, and some additional parameters that testers are expected to enter but pre-release testers are not expected to enter are entered by default).
For all these teams, there may be other access issues that teams may not have thought about. Typically when a team has any kind of feature that provides access to an online feature, such features are available in staged servers that need some kind of setting or special access. For ensuring that all the teams listed above and similar teams do not get stuck, it is required to plan for such an access. We had a problem in the past whereby an important online feature was rolled out to the press reviewing team, but there was a big screw up relating to the access for these features, and the team was not able to provide access for around 3 days, in which time, some of the press withdrew - a big disaster. So, a great team has plans for all these before they look to execute such features.
- External teams that are working as an extension of the testing team. This is getting more and more common, whereby the testing team can be expanded as necessary by adding vendors to the testing resources. However, when the these external vendors need to start their work, they need access to the testing infrastructure such as test cases repository and the defect management software.
- External teams working on the localization (conversion of the software into different languages). Such teams typically work on both development and testing of the application in different languages and need access to the source repository, as well as the testing infrastructure (test plan and case repository, defect management software, and so on).
- Teams working on the documentation of the product typically need access to the defect management software, since there can be several issues that need to be documented which are typically present in the defect management software, and the documentation team would be provided access to the defect management software.
For these 3 teams and others working in a similar area, if they are located outside the organization, then there may be a necessity for them to be provide the required VPN access to get access to all these tools. In modern secure organizations, such access policies would go through an approval process, and to ensure that such a process is accelerated, it makes sense to prep the approving authorities about these requests for approval.
- External testers / pre-release testers. Such pre-release testers typically do not need any access to source code repository or the testing infrastructure. However, these testers do need a platform where the defects they have logged get into the defect management software in an easy and transparent way (and where the testers are not expected to do any additional work - in some cases, it is as simple as providing them a web page where they can enter the defects that they have found, and some additional parameters that testers are expected to enter but pre-release testers are not expected to enter are entered by default).
For all these teams, there may be other access issues that teams may not have thought about. Typically when a team has any kind of feature that provides access to an online feature, such features are available in staged servers that need some kind of setting or special access. For ensuring that all the teams listed above and similar teams do not get stuck, it is required to plan for such an access. We had a problem in the past whereby an important online feature was rolled out to the press reviewing team, but there was a big screw up relating to the access for these features, and the team was not able to provide access for around 3 days, in which time, some of the press withdrew - a big disaster. So, a great team has plans for all these before they look to execute such features.
No comments:
Post a Comment