Benefits of Accurate Versioning Management
Many users, as they start their journey of testing their products with Applause, tend to focus on the testing results of an individual test cycle. This has a lot of sense to it – quality testing at speed and scale is what the testing community specializes in, and clearly if quality digital experience is what users are after, then granted they would like to get the issues, test case results and product reviews, and act on them.
But, as you keep testing your product with Applause, some other questions may start to interest you as well. Is your product quality improving over time? How do initial builds compare to release candidates, and how long and how much effort is required to get them there? When can a build quality might be sufficient to push it to production? In short, you may start looking for trends in aggregated results collected over time. And, in order to achieve that, a proper understanding of the hierarchical or sequential order of the tested builds is required.
Here are few example on how we can use the versioning data, when captured properly:
- Knowing that build “3.2.4” and “3.2.3” are part of the same release (“3.2”) allows us to not only trend how quality improved between these builds, but also to point the release quality based on the latest build tested for it – and later compare the release quality with other releases.
- While builds “2.9.3” and “2.10.1” may have been tested one after the other, clearly “2.9.3” is the latest build for release “2.9”, thus the expectations of quality in terms of testing results will be very different than what we may expect of “2.10.0”, or the first build of the following release. Understanding such “expected quality” is what allows us to accurately score the quality of the build.
- Moreover, when we know both “4.1.1” and “7.1.1” are both first builds of their corresponding releases, we can now compare between them, and gain insights into how quality of those like-builds trend.
Versioning Management in Applause Platform
Managing version in Applause Platform includes 2 parts: Defining the versioning format (or schema) you use to track your builds or versions or your product, and setting the accurate version number according to the defined format for every tested build.
Defining the Product’s Versioning Format
Generally speaking, you’ll be required to define the versioning format for your product only once, when it is created. Obviously changes may be made over time.
To define your product’s versioning format:
1. While In the Product wizard, as you either create a new product or edit an existing one, navigate to Step 1: Basic. Learn more about how to manage your products here.
Note: this option might not be available for you, depending on your role.
2. Next to Product Versioning, define the format your product versioning follows, by creating a label for each of the levels (or groups), and select the separators between them.
Note: you may create up to 6 levels.
Here are few examples you might use:
- “Year-Week (Build)”
Setting a Build’s Number
Once the versioning format is set at the product level, you will be required to follow it whenever a new build is created.
To set the build number:
1. While creating or editing a build from either product or test cycle context, navigate to the build details in the corresponding page or wizard. Learn more about how to create builds here.
2. Provide the accurate numbering of each set level of the create build.