During the regular product development cycle, the build (typically daily) is the most important input to ensure that the process of build testing, defect fixing and incorporation of the fix into the product, and testing again continues. If the build does not come on a regular basis, defects are not available for the testing team to fix on a regular basis; and it is essential that defects get into the product at a regular basis. If not, team developers start getting out of phase with respect to files being changed during defect fixes by multiple people, and more effort needs to be spent to resolve these dependencies.
Most teams typically like to get the daily product build early in the morning, before the developers and testers are in position. Such a technique ensures that when the team arrives, the build is already available and ensures the maximum utilization of time. However, as a part of this, it is also essential that the build be ready and be fully fit, not have major defects. For this purpose, it is essential that the build be verified before it is started to be used by the team.
A lot of teams have built automated smoke tests that take the build when it is available, launch it and do a quick major tests, and if everything goes right, an email could be configured to go out to a specially setup email list which would ensure that the right people knew that the build was correct. This works in most cases, but there can be cases where there are false negatives. For example, there is a small change in UI or some other feature which was not incorporated into the smoke test, then the smoke test would give a failure, but the build could have been successful (and one can think that such a case may not happen, where the information about a change would always be built into the smoke test, it can happen and has happened).
In other cases, a person needs to evaluate whether a partly successful smoke test and see whether the new build need to be built or the existing build can be used, with some assumptions. For example, one particular feature need not be fully working, but everything else could be working. Now why would the team want to use a build where not everything was working fine. Well, because there is a cost to make a new build. Building a new build could take time, many hours in some cases, and till that time, the developers and testers would have to be using an older build, which may be fine in the early stages, but gets more problematic as you move along the schedule, since such delays in getting defects fixes in the build may increase the cost and impact.
To take such calls needs to be done by a person on the team; and this needs to be specially assigned, since such a person would need to review the build and take a call before the other team members start working on the build, which would mean that the person would need to get on the job much earlier than normal.
Most teams typically like to get the daily product build early in the morning, before the developers and testers are in position. Such a technique ensures that when the team arrives, the build is already available and ensures the maximum utilization of time. However, as a part of this, it is also essential that the build be ready and be fully fit, not have major defects. For this purpose, it is essential that the build be verified before it is started to be used by the team.
A lot of teams have built automated smoke tests that take the build when it is available, launch it and do a quick major tests, and if everything goes right, an email could be configured to go out to a specially setup email list which would ensure that the right people knew that the build was correct. This works in most cases, but there can be cases where there are false negatives. For example, there is a small change in UI or some other feature which was not incorporated into the smoke test, then the smoke test would give a failure, but the build could have been successful (and one can think that such a case may not happen, where the information about a change would always be built into the smoke test, it can happen and has happened).
In other cases, a person needs to evaluate whether a partly successful smoke test and see whether the new build need to be built or the existing build can be used, with some assumptions. For example, one particular feature need not be fully working, but everything else could be working. Now why would the team want to use a build where not everything was working fine. Well, because there is a cost to make a new build. Building a new build could take time, many hours in some cases, and till that time, the developers and testers would have to be using an older build, which may be fine in the early stages, but gets more problematic as you move along the schedule, since such delays in getting defects fixes in the build may increase the cost and impact.
To take such calls needs to be done by a person on the team; and this needs to be specially assigned, since such a person would need to review the build and take a call before the other team members start working on the build, which would mean that the person would need to get on the job much earlier than normal.
No comments:
Post a Comment