BIMachine is a SaaS platform that has several services operating constantly, so that they keep running at their best, frequent updates are required to improve the user experience, as well as the release of new features.
For this to happen in an efficient way, so that the user can enjoy it, our team has structured a software quality certification phase, aiming at the best final experience of the product.
BIMachine’s version validation process goes through a cycle of steps, containing a series of meetings and tests to evaluate the improvements and new features releases of the platform. As well as a series of self-tests that ensure the quality of the development team.
Every task developed goes through a delivery flow with the objective of guaranteeing that there are no failures in the productive environment. The first phase of this process has as its main objective to perform the following tasks:
- Development: Stage of production of the source code with adjustments or implementations of new features.
- Code Review: Review of the source code produced by a more experienced developer, where the goal is to ensure the quality of the source code, spread knowledge among what was produced and also ensure a good performance of the tool.
- Developer Test: Manual test by another developer, he will validate with a technical view the implementation produced, in order to understand if the setting or functionality was actually delivered.
- Automated version test: The automated test persists in validating a series of tool functionalities with the use of "robots", this test validates the creation of all types of objects, export, navigation, load and send schedules, presenter, creation of connections, filters, among other available resources. In the occurrence of a critical incident, we always create a new automation to ensure that the same problem does not occur again.
The second phase of the release validation process goes through the Product team, which performs the following cycle of tasks before release:
At the beginning of this cycle, the documentation stage of versioning takes place in our knowledge base, where Release Notes articles are published reporting the platform’s fixes, bug fixes, and new features in the following way:
- #.##.0
Release Notes ending in ".0" have information about new feature releases and major changes.
- #.##.(1-9)
Release Notes ending in any other digit than 0 have the information about bugfixes and other improvements in general.
In the second stage of the cycle a validation plan is thought out where the functionalities to be validated are defined, how they will be validated, what will be the version test plan, what will be the validation check-list, as well as which SQUAD members will be responsible for validating the update.
Example of a check-list:
The third stage of validation SQUAD happens as follows:
- The technical areas of the support team, product, development and deployment are selected with the Heads, who are then summoned to the SQUAD (~8 people)
- Validation of the new functionalities
- Validation of the check-list of core functionalities
- Closing meeting to evaluate the problems found
- Delivery of the signed check-list
- Definition of the points of adjustments and improvements for the closing of the version
- Translation of the update into English and Spanish
Finally, there is the versioning stage where, again, the development team performs final adjustments as needed.
Manual test after upgrade: manual test performed by the product team to ensure that the environments operate normally and also certify that the features available in the new version are working correctly.
Automated test after upgrade: automated check-list that validates the main features of the tool, the test today takes 30 minutes and is run in the productive environment after each upgrade.
Then a new validation by the support and product team takes place to close the version.
