During the development of the browser, we receive error messages from users – they help us fix bugs and make the product better.
An error message is the easiest way to get the information you need to reproduce and fix a browser bug. The more information the user provides, the easier it is to understand the problem (everything is useful: browser version, operating system, screenshots, links to sites where the problem occurs).
In such a complex software product as a browser, errors appear constantly. Some of them require us to stop working on new features and immediately start fixing the bugs that have arisen. Therefore, the team should always have the resources to deal with bugs and regressions as they arise. In the last 30 days alone, 1231 error messages have been received and 1704 problems have been resolved (data only for the desktop).
After receiving an error message from the user, it goes through several stages before the fix appears in the stable version of the browser. We use the Jira tool to manage projects, including tracking bugs submitted by users.
Let’s briefly describe the life cycle of an error message in the Vivaldi browser.
New message arriving
Whenever we receive a new error message – either from team members or from Vivaldi users – it is by default set to Not Confirmed.
Error check
The testing team tries to reproduce the bug based on the information and steps provided in the message. Since Vivaldi is available on multiple versions of Windows, Linux, Mac and Android, testers need access to different testing environments. Once we can reproduce the bug and verify it, the status will change from Not Confirmed to Confirmed.
Passing the error to the developer
After confirming the error, we assign it a priority level from 1 to 5, where 1 is the highest priority. At this stage, the developer decides which errors require immediate attention and which can be postponed for a while. If he thinks he is doing a task, he assigns the error to himself so that everyone knows who is working on it. If we find a regression, which is usually caused by a previous bug fix, we assign it to the developer who worked on the bug fix.
Submitting the fix to the main branch and to the beta build
Once a bug has been fixed and passed internal testing processes, the developer pushes it to the mainline. Almost every day we make test builds, which we distribute to voluntary beta testers (our Sopranos) before the release goes public. At this point, Sopranos begins manual testing.
Add comment