What is Bug Convergence? Why is it important for User Acceptance Testing (UAT)?
Last updated: February 02, 2024 Read in fullscreen view
Recommended for you
- 28 Oct 2023
The GOLDEN Rules of Software Engineering 27/522 - 18 Oct 2020 How to use the "Knowns" and "Unknowns" technique to manage assumptions 21/989
- 08 Dec 2021 What Are The 4 Types of Maintenance Strategies? 20/1031
- 01 Oct 2020 Fail fast, learn faster with Agile methodology 13/973
- 02 Dec 2022 3 Levels of Quality in KANO Analysis Model 8/1000
- 10 Nov 2022 Poor Code Indicators and How to Improve Your Code? 7/213
- 19 Oct 2021 Is gold plating good or bad in project management? 7/754
- 13 May 2022 IT Training and Development: The most effective options for upskilling IT staff 7/1021
- 14 Oct 2021 Stream Story - Low land stream or fast moving stream? 6/569
- 06 Feb 2021 Why fail fast and learn fast? 6/375
- 01 Mar 2023 Bug Prioritization - What are the 5 levels of priority? 6/207
- 10 Dec 2021 What is a Kano Analysis? 6/810
- 05 May 2021 TIGO Magic Scale - PoC tool for you to apply dichotomous thinking before submitting RFP 4/297
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M) 4/789
- 08 Oct 2022 KPI - The New Leadership 3/557
- 31 Oct 2021 Tips to Fail Fast With Outsourcing 3/375
- 03 Nov 2022 Questions and answers about Kano Model 3/804
- 18 Aug 2022 What are the consequences of poor requirements with software development projects? 3/242
- 10 Jan 2024 Like for Like – how to preserves existing business and leverage technological advancement 2/336
- 17 Feb 2022 Prioritizing Software Requirements with Kano Analysis 2/280
- 07 Dec 2023 The Myths Of Requirements 2/202
- 10 Dec 2023 Pain points of User Acceptance Testing (UAT) 2/416
- 23 Sep 2021 INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 2/411
- 13 Dec 2020 Move fast, fail fast, fail-safe 2/292
- 28 Dec 2021 8 types of pricing models in software development outsourcing 2/417
- 01 Oct 2020 Handling tight project deadlines as a business analyst 1/313
- 19 Apr 2021 7 Most Common Time-Wasters For Software Development 1/525
- 26 Dec 2023 Improving Meeting Effectiveness Through the Six Thinking Hats 1/205
- 05 Jan 2024 Easy ASANA tips & tricks for you and your team 1/180
- 11 Jan 2024 What are the Benefits and Limitations of Augmented Intelligence? 1/434
- 02 Jan 2024 What is User Provisioning & Deprovisioning? 1/480
- 14 Mar 2024 Why should you opt for software localization from a professional agency? /117
- 12 Mar 2024 How do you create FOMO in software prospects? /127
- 02 Apr 2022 Productivity vs. Efficiency – What Are the Differences? /196
- 11 Oct 2021 10 Myths About Low-End Project Management Software /274
- 06 Nov 2019 How to Access Software Project Size? /236
- 10 Nov 2021 Automated QA Outsourcing – Hire a Professional Software Testing Team /514
Bug convergence is a milestone in the stabilizing phase of a project life cycle. It is a point at which the new bug rate (found during an application testing) drops below the bug resolution rate. At this point, the rate of bugs resolved exceeds the rate of new bugs found during application testing. Therefore, the actual number of active bugs decreases as the number of bugs resolved increases. After bug convergence, it is important that the number of bugs decreases until zero bug bounce (another milestone).
Recommended Interim Milestones
Bug Convergence
Bug convergence is the point at which the team makes visible progress against the active bug count. That is, the rate of bugs resolved exceeds the rate of bugs found.
Because the bug rate will still go up and down—even after it starts its overall decline—bug convergence usually manifests itself as a trend rather than a fixed point in time.
After bug convergence, the number of bugs should continue to decrease until zero-bug release. Bug convergence tells the team that the end is actually within reach.
Zero Bug Bounce
Bug Convergence and Zero Bug BounceZero-bug bounce is the point in the project when development finally catches up to testing and there are no active bugs—for the moment. Figure 11 illustrates a zero-bug bounce. After zero-bug bounce, the bug peaks should become noticeably smaller and should continue to decrease until the solution is stable enough for the team to build the first release candidate.
Careful bug triaging is vital because every bug that is fixed risks the creation of a new bug. Achieving zero-bug bounce is a clear sign that the team is in the endgame as it drives to a stable release candidate.
Note that new bugs will certainly be found after this milestone is reached. However, zero-bug bounce marks the first time when the team can honestly report that that there are no active bugs—even if it is only for the moment—and it focuses the team on working to stay at that point.
Release Candidates
A series of release candidates are prepared and released to the pilot group. Each release candidate is an interim milestone.
Other features of a release candidate are:
- Bug Convergence
- Each release candidate has all the elements it needs to be released to production.
- Building a release candidate tests its fitness for release, that is, whether all necessary pieces are present.
- The test period that follows generation of a release candidate determines whether a release candidate is ready to release to production or whether the team must generate a new release candidate with the appropriate fixes.
- Testing release candidates, which is done internally by the team, requires highly focused and intensive efforts, and focuses heavily on flushing out showstopper bugs.
- Testing requires a triage process for resolving any newly discovered bugs.
- It is unlikely that the first release candidate will be the one that is released. Typically, show stopping bugs will be found during the intensive testing of a release candidate.
Pre-Production Test Complete
The focus of this interim milestone is to prepare for a pilot release. This interim milestone is important because the solution is about to “touch†the live production environment. For this reason the team must test as much of the entire solution as possible before the pilot test begins. Activities that must be completed during this interim milestone are:
- Evaluate test results against success criteria.
- Complete site preparation checklist and procedures.
- Complete implementation procedures, scripts, and load sets.
- Complete training material.
- Resolve support issues.
- Complete and test the rollback plan.
The pre-production test complete interim milestone is not complete until the team ensures that everything developed to deploy the solution is fully tested and ready.
User Acceptance Testing Complete
User acceptance testing and usability studies begin during the development phase and continue during stabilization. These are conducted to ensure that the new system is able to successfully meet user and business needs. This is not to be confused with customer acceptance, which occurs at the end of the project.
When this milestone has been achieved, users have tested and accepted the release in a non-production environment and verified that the system integrates with existing business applications and the IT production environment. The rollout and backout procedures should also be confirmed during this period.
Upon approval of release management, software developed in-house and any purchased applications are migrated from secure storage to a pristine archive location. In MOF, this is known as the Definitive Software Library (DSL).
Release management is responsible for building releases (assembling the release components) in the test environment from the applications stored in the DSL.
User acceptance testing gives support personnel and users the opportunity to understand and practice the new technology through hands-on training. The process helps to identify areas where users have trouble understanding, learning, and using the solution. Release testing also gives release management the opportunity to identify issues that could prevent successful implementation.
Pilot Complete
During this interim milestone, the team will test as much of the entire solution in as true a production environment as possible. In MSF, a pilot release is a deployment to a subset of the live production environment or user group. Depending on the context of the project, a pilot release can take the following forms:
- In an enterprise, a pilot can be a group of users or a set of servers in a data center.
- In Web development, pilot release takes the form of hosting site files on staging server(s) or folders that are live on the Internet, only with a test Web address.
- Commercial software vendors, such as Microsoft, often release products to a special group of early adopters prior to final release.
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News