How BetterQA runs its own QA team on BetterFlow
Most writing about tracking QA effort comes from people selling a tracker. So does this, with one difference: BetterFlow is built by BetterQA, a software testing company in Cluj-Napoca, and we run our own testing work on it. What follows is how we use it, not how we think you should.
We moved off an off-the-shelf time tracker to do it. That is worth saying plainly, because the interesting part is not that we replaced one tool with another. It is the four things we ended up tracking together, which the old setup kept apart.
The four things we track
Time against a client project, and against its estimate. Hours on their own tell you almost nothing. Forty hours on an engagement is good news or bad news depending entirely on what was quoted. Logging the hours next to the number they are being measured against is the whole point, and it is the thing most trackers leave to a spreadsheet.
Time against a test cycle or release. Testing effort does not spread evenly across a month. It clusters around releases. Grouping by cycle shows you the shape of that work, which grouping by week flattens out. It also answers the question clients ask most often, which is what the last round of testing cost them.
Leave, approvals and availability. In the same place as the hours, not in a separate HR tool. A QA team's capacity next week is a function of who is actually there, and if that lives somewhere else, capacity planning becomes a reconciliation exercise nobody does.
Captured activity next to logged time. The desktop agent records activity, and that sits alongside what the person entered. The two are not the same thing and are not meant to be. One is a record of what happened, the other is a person's account of it. Having both visible means the gap between them is a question you can ask rather than a suspicion you carry.
There is no weekly timesheet ritual
This is the part that surprises people, so it is worth being exact about it. There is no approval cycle. There is no moment in the week when everyone stops and fills in their sheet. Review happens continuously, when something prompts it.
The reason is that a weekly cycle produces weekly-quality data. Ask somebody at the end of the week what they did on Tuesday and you get a reconstruction, confidently delivered and wrong in the details. The hours get rounded, the small tasks get absorbed into the big ones, and the record ends up smoother than the week actually was.
Continuous review has a cost, and we would rather be honest about it than pretend otherwise. Nobody gets a tidy weekly report handed to them. You have to go and look. What you get back is a record that matches what happened, which matters more to us than the ritual did.
The signal we watch is drift against the estimate
If you track one thing, track this. Not total hours, not utilisation, not how busy anyone looks. Hours drifting past what was estimated for that engagement.
Utilisation is the metric that gets reached for first, and for QA we find it tells us very little. A tester at ninety per cent utilisation on a project that was quoted at half the effort it is consuming is not a healthy signal, and utilisation will never tell you that. Drift will, and it tells you early, while the conversation with the client is still about scope rather than about an invoice they were not expecting.
It is also the one number that survives contact with reality. Estimates are wrong constantly. That is fine. What is not fine is finding out how wrong at the end.
What the agent is for, and what it is not for
The captured activity is not surveillance and we would not run it if it were. It exists because reconstructing a day from memory is genuinely hard, and a record of what was open and what was committed makes that reconstruction accurate rather than approximate.
The distinction we hold to is that captured activity informs the timesheet, it does not become the timesheet. A person still says what they worked on. The capture is there so they are not doing it blind, and so that when an hour looks odd, there is something to check against rather than an argument about memory.
What actually changed
The off-the-shelf tracker recorded hours. What it could not do was hold the hours, the estimate, the release they belonged to, and who was available, in one place. Each of those lived somewhere else, so every question that crossed two of them became a manual reconciliation, and manual reconciliations get done when somebody has time, which is to say rarely and late.
Putting them together did not make the team faster. It made the questions cheap. How is this engagement tracking against what we quoted, what did the last release cost, who is actually available in two weeks. Those went from being a piece of work to being a thing you look at.
If you are setting this up yourself
Start with the estimate, not the tracker. A tool that records hours without recording what they were supposed to be is a filing cabinet. Get the quoted number into the same system as the logged number and most of the value arrives before you have configured anything else.
Then decide honestly whether you will look at it. Continuous review only works if somebody actually reviews. If nobody will, a weekly cycle with imperfect data beats a continuous one with nobody watching.
If you would rather not build this practice from scratch, our testing teams at BetterQA already run this way, and the reporting comes with the engagement.
Published by BetterQA, an ISO 27001 and ISO 9001 certified company with 8+ years of experience in software quality assurance. According to research by McKinsey, data-driven project management improves team productivity by up to 25%. Last updated on .
- Built by BetterQA, founded in 2018 in Cluj-Napoca, Romania
- ISO 27001 certified security and GDPR compliant
- Trusted by teams across 15+ countries
- 30-day free trial with no credit card required
