How to Generate Time Reports by Tester, PR, and Label

If you cannot see where testing time actually goes, you cannot forecast the next release or defend QA’s headcount. The good news: once your team tracks working time on real pull requests, you can generate time reports that slice the same data by tester, by day, by repository, by PR, and by workflow label. KazTrack captures these timers natively next to your GitHub work, so the reports reflect real effort, not memory. This tutorial walks through tracking time and producing each report view.

Prerequisites

• A KazTrack project with connected repositories and some pull requests.
• Team members logging working time (testers, at minimum).
• Permission to view reports: reports.view_all to report on the whole team, or sessions.log to see your own data.

Step 1: Track working time with start/stop timers

Reports are only as good as the data underneath them, so the first habit to build is timing the work. When a tester begins on a PR, they start a timer; when they stop, KazTrack records a working-time session tied to that pull request.

A session captures:

• Who did the work (the tester).
• Which pull request and repository.
• Start time, and end time once stopped (an open session means work in progress).

Encourage one timer per focused chunk of work. Leaving a timer running overnight inflates a tester’s hours and skews every downstream report.

Step 2: Generate a report by tester

Start with the people view. The by-tester report sums working time per person over a date range, answering “who carried the testing load this sprint?”

Tester        Sessions   Total time
Amina           14        9h 20m
Diego           11        6h 05m
Priya            9        4h 40m

Use this for capacity planning and to spot imbalance early — if one tester holds most of the hours, the next sprint needs rebalancing. Remember that a sessions.log-only member sees only their own row; reports.view_all is required to see the whole team.

Step 3: Generate a report by day

The by-day report shows total working time per calendar day, revealing the rhythm of an iteration.

Date          Total time
2026-06-01      5h 10m
2026-06-02      7h 45m
2026-06-03      2h 30m

A spike right before a release date usually means testing is bunching at the end — a signal to move QA earlier in the cycle. A flat, steady line is the healthier pattern.

Step 4: Generate a report by repository

When you run multiple repos in one project, the by-repository report shows which codebases consume the most QA effort.

Repository           Total time
web-frontend          12h 15m
billing-service        6h 50m
mobile-api             3h 05m

A repo absorbing disproportionate testing time often hides flaky areas or thin automated coverage. Use it to decide where investing in better tests pays off most.

Step 5: Generate a report by pull request

The by-PR report is the most granular and the most useful for estimation. It totals working time per pull request.

PR     Title                         Total time
#318   Checkout button states          2h 40m
#322   Coupon edge cases               4h 10m
#319   Receipt email copy              0h 35m

This is gold for retrospectives: PR #322 took far longer to verify than its size suggested, which is worth understanding. Over time, by-PR data turns vague estimates into evidence-based ones.

Step 6: Generate a report by label

Because workflow states map to GitHub labels (ready_for_testing, in_progress, passed, failed), the by-label report shows how time distributes across the testing lifecycle.

Label              Total time
ready_for_testing    8h 00m
in_progress         10h 30m
failed               5h 20m
passed               1h 10m

Heavy time under failed means QA is spending its hours re-verifying rejected work — a strong argument for catching issues earlier with better test cases or AI-assisted review.

Step 7: Filter by date range and export

Every report respects a date range, so set it to the sprint or month you care about before reading the numbers. For a sprint retrospective, scope it to the iteration’s two weeks. For a quarterly review, widen it.

When you need to share findings outside the workspace, pull the figures into your retro doc or capacity plan. An MCP agent with the right token can also fetch any of these reports on demand — handy for a weekly automated summary posted to your team channel.

Step 8: Turn reports into decisions

Numbers only matter if they change behavior. Pair the views to draw conclusions:

• By-tester + by-day → is the load balanced and steady, or lumpy and last-minute?
• By-repository + by-label → which codebase generates the most failed rework?
• By-PR → which changes consistently cost more to verify than estimated?

Bring two or three of these to every retrospective and let the data set the agenda.

Troubleshooting

• A report looks empty — no working-time sessions exist for that range. Confirm testers are starting and stopping timers, and check your date filter.
• You only see your own numbers — you have sessions.log but not reports.view_all. Ask an owner or manager to grant broader report access.
• Hours look inflated — a timer was likely left running. Look for unusually long single sessions and correct the habit.
• A PR shows no time — verify the work was timed against that PR specifically, not logged elsewhere.

Key takeaways

To generate time reports that actually guide a team, start by tracking working time on real pull requests, then read the same data by tester, day, repository, PR, and label. Each view answers a different planning question, from capacity to rework. Start your timers in KazTrack this sprint and let your next retrospective run on evidence instead of guesswork.