Hi! This is Purrweb QA department. We’ve recently tried a new method of bug tracking and we want to share our experience with you.
How we tested before
For example, we have 3 developers and a team lead working on a project.
That’s how things worked 4 months ago: before all tests, a team lead merged everything that his team had done and then uploaded it to the stage. Only after the finished build was ready, I could start the front-end testing.
Then I opened the stage and started working.
The ‘QA-waiting’ column in Jira showed me all the things I needed to check.
After front-end testing I moved the cards to:
- Done — if everything was okay.
- Backlog — if there were new bugs.
- To do (with comments on cards) — if nothing worked or a significant part of a task wasn’t done.
Backlog section: the colored tags indicate epics
Why do we need epics in the backlog? We filtered tasks by particular epics to understand which bugs need to be fixed. For example, if we had to finish the onboarding tasks first, devs could just click on this epic and see everything related to it.
Now let me get straight to the point.
Jira — the storage of all bugs. What are the problems we faced?
The first: all bugs were floating at the bottom of the backlog, waiting for a special Bug Day(by the way, it still exists). Even tiny mistakes in a layout had to wait for 1-1,5 week until we could start dealing with them during the front-end testing.
The second: (caused by the first one): the project team is a dynamic, living organism. Since the bugs were in a waiting list, it often turned out that the tasks started by one developer had to be finished by another one — because the first developer is already busy/broke a leg/took a leave/quit.
The third: (I’m sure my teammates support me with this one): it’s much more painful to close the tasks which you have started a month or two ago. That’s like writing an article: if you skip placing commas in the process and decide to do it in the end, you’ll have to review the whole text again and again before publishing. There’s no other way. Same with bug-fixing: even with the smallest details, first of all, you have to find them and make sure that the changes won’t break anything, and then fix it.
Switching to Vercel: why? How?
We have first tried the new front-end testing approach upon request of our client on one of the projects — a financial B2B service ‘HeadCount’. If it wasn’t for the customer request, would we like to try something new? Maybe. Did we realise that the previous bug-tracking method can be hardly considered perfect? No doubt. Either way, we decided to try the Vercel platform — and shortly after found out how cool this thing is.
I’ll tell you a little about how the process of tracking and fixing bugs has changed. The main thing is that now we can test the work of a single developer before a team lead merges all the branches.
Each member of the development team generates his own link and gets it tested
How do we complete the task ‘Get the work tested — receive and handle feedback’? With the help of project-channels in Slack.
A great tool which helps you sync up quickly
We have a special approach for discussing bugs — it’s not unique but it works just fine 🙂 Here are the emojis that help us speed up the conversation:
⚠️ — when there’s a comment to a task. It helps to easily find a message about errors. I write in Slack what exactly needs to be fixed.
➕ — when a task was checked and everything’s okay. I also write in a thread to let the team lead know that everything functions properly — it means that he can upload the branch. By the way, when a team lead uploads a branch, he uses the plus emoji as well.
👌 — when the developers inform about task details. For example, if they decided to put it off or to do something differently. I use the emoji to show that I’m aware.
Only 3 emojis and so many benefits. The biggest advantage is that the team clearly understands what’s going on with the tasks and they don’t have to look through the endless threads in Slack.
The benefits of Vercel
There are benefits for all the parties involved.
For clients: ‘Only a stable and ‘clean’ version of a product can get into production. A clean build = a happy client’.
If you ask me: ‘Marina, what about QA specialists?’. I’ll tell you this: with Vercel, you get tasks gradually as soon as they are ready. As well as developers, I don’t have to go back to small tasks after a long time and try to recall what they were about. And that’s freaking awesome!
Here’s a good example from our experience in web front-end testing:
Once our dev team uploaded a build where I found 28 bugs. All of them were small – they had to move a pixel a little, make a font bolder. If we delivered this version to the customer, he would definitely be upset (fair enough). With Vercel we left it ‘behind-the-scenes’ and when we uploaded the build to the testing server, the interface bugs were already managed.
So what about Jira? And the Bug Day?
Did we completely cut Jira out of our bug-tracking process? Of course not. Jira stopped being our main tool, but we still use it during integration and regression testing.
What happened to the Bug Day? As I said before, it still exists – we keep fixing bugs at the end of every sprint. However, there are some changes. The main thing is that dealing with all small and urgent tasks beforehand we finally live happily and manage to complete the front-end testing in 1-2 days.
What’s the point?
There are two reasons.
The first one: our team loves trying new things.
The second one: we want to improve product development processes. We want our clients to be excited to work with us again and again. So it was, so it is and so it will be.
Did Vercel make my life easier? On the contrary, with Vercel my participation in the team processes increased a lot. The ‘total’ front-end testing at the end of every sprint was replaced with everyday monitoring of the progress of all team members. Now there’s a lot more updates on bugs, communication and interaction. Everything we do is for high-quality results at the output.
