The start of system testing should mean the beginning of collaborative work with development and testing teams. Testers run scheduled tests, identify defects and write bug reports. Developers read bug reports, reproduce problems and fix the program code.
The question is this: how are the fixes handed over to the testing team?
The answer to this question depends on the flow of a software development process. Developers record the changes made to the configuration management system as a part of the preparation for the periodic build processes. The software build process is usually done on a daily or weekly basis, after which the unit is passed to the testing team according to their needs.
There are various questions as to how often the testing team can accept new software versions. If the builds are delivered too often, the stability of the testing environment may be compromised – it will take time to install new software products, run leak tests and verify that the defects that were detected in the previous build version have been fixed.
If the mix of versions is unnecessarily variegated, there simply will not be time to run enough tests to ensure the effectiveness of defect detection in accordance with the chosen testing methodology. Testing outsourcing companies are able to carefully, competently and cost-effectively examine software apps under development so it is always reasonable to turn to them for help.
On the other hand, if the builds are delivered too slowly, then in this case it will be impossible to achieve too high levels of defect detection efficiency levels.
In most cases, changes made to the program code lead to uncovering new defects, or defects that were present previously in the build, but were masked by the defects already eliminated. This means that it is necessary to include new versions of software products in the test cycle quite enough in order to detect the next batch of defects.
The frequency with which new software builds are received from developers depends on several factors, including the complexity of the software, the number of testers, and the percentage of automated tests to the total number of tests.
For example, if you can execute all tests within three days, it probably makes sense to take new builds every four-five days. In this case, three days can be spent running tests, and a day or so – verifying defect fixes, running specialized tests in some promising areas, preparing defect management reports and carrying out regular analysis of defects encountered.
Comments are closed.
