Build (in BTS)

In the context of Bug Tracking Systems (BTS), the term Build refers to a specific version of the software application or system that is generated after a series of code changes, updates, or bug fixes have been made by the development team. A build is typically tracked within a BTS to link issues, defects, or feature requests with particular iterations of the software. In software testing, builds are essential because they provide a reference point for identifying and resolving bugs within the context of the software’s current state, functionality, and version.

Key Aspects of “Build” in Bug Tracking Systems (BTS)

1. Version Control: each build represents a version of the software that includes code changes, bug fixes, or enhancements. These builds are assigned unique identifiers, typically referred to as build numbers or version numbers, which help testers and developers track which specific iteration of the software the issue occurred in. For example, a build might be labeled as “Build 102” or “Version 1.2.3”.
2. Linking Bugs to Builds: a crucial part of bug tracking in a BTS is associating defects (or bugs) with specific builds. Each bug reported in the system can be linked to the build where it was discovered, which helps in tracing the bug back to its source and understanding which changes caused it. This is important for debugging and regression testing because it allows the development team to know exactly which changes (in the corresponding build) may have introduced the defect.
3. Build Information in BTS: when a bug is reported in a BTS, the details of the build in which the issue was found are typically recorded. Information captured may include:
   • Build ID/Version: The specific identifier or version of the build.
   • Build Environment: The environment in which the build was deployed, such as operating systems, browser versions, or hardware configurations.
   • Release Notes: Notes describing the changes or fixes included in that particular build.
   • Build Date: The date and time when the build was generated, helping to understand the timeline of changes.
   • Deployment Status: Whether the build is in the development, staging, or production phase.
4. Build Verification and Testing: bug tracking systems often track whether a bug exists in a particular build and whether it is resolved in subsequent builds. After a bug fix is applied in a specific build, testers will re-verify the fix in future builds. For example, if a bug was reported in “Build 102,” testers would check if the bug is still present in “Build 103” after the fix was applied.
5. Build and Release Notes: a BTS may include links to release notes for specific builds, allowing testers, developers, and stakeholders to see what changes have been made between builds. These release notes detail bug fixes, new features, and any other changes in the build, helping teams to understand the context in which bugs were introduced or resolved.

Example of How “Build” Is Used in a Bug Tracking System (BTS)

• Bug Report: a tester identifies a bug in the software where the login button is not responsive in the latest version.
• Bug Entry: the tester logs the bug in the BTS, linking it to “Build 2.3.1.” The system records all the relevant details, including steps to reproduce, expected behavior, actual behavior, and build version.
• Investigation: the development team reviews the issue and determines that it was caused by a recent change in the UI code in Build 2.3.1.
• Bug Fix: a developer fixes the issue in the next build, “Build 2.3.2,” and links the bug report to this build to indicate the fix.
• Verification: testers verify that the bug is resolved in Build 2.3.2 and close the bug report in the BTS, noting the successful resolution and linking it to the fixed build.