I’m Building a Bug Fix Retest Tool for Small Software Teams — What Am I Missing?

norvane — Sat, 22 Aug 2026 17:35:48 +0000

I'm Building a Lightweight Bug → Fix → Retest Tool for Small Software Teams

I've been thinking about a problem that looks simple at first:

A tester finds a bug. What happens next?

In a small team, the workflow usually looks something like this:

Test → Bug → Developer → Fix → Retest → Verified

Simple enough.

But once there are multiple bugs, builds, developers, and testers involved, things can get messy surprisingly fast.

Some information lives in Jira or GitHub Issues.

Some updates happen in Slack.

Screenshots get sent in messages.

A developer says, "fixed."

Then someone has to remember to test it again.

And a few days later:

"Was this actually retested?"

That's the problem I'm trying to solve.

I'm currently building a lightweight QA workflow tool focused specifically on connecting the entire lifecycle of a bug.

Not another full project management platform.

Just the testing workflow.

Here's what I have so far.

1. A Personal Inbox Instead of Another Huge Dashboard

One thing I wanted to avoid was showing everyone the same giant list of issues.

Instead, each person gets an action-oriented Inbox.

A tester might see:

Bugs ready for retest
Questions that need a response
Tests currently in progress

A developer might see:

Newly assigned bugs
Bugs currently in progress
Reopened bugs

The idea is simple:

When I open the app, I should immediately know what I need to do next.

2. Test Case → Test Run → Bug

Test cases can be executed directly inside the project.

Each test step can result in:

PASS
FAIL
BLOCKED
SKIPPED

But the important part happens when something fails.

Instead of manually copying everything into a new bug report, you can create a bug directly from the failed test.

The bug can automatically inherit:

Project
Test case
Steps
Expected result
Environment
Build

The tester mainly needs to describe what actually happened and attach evidence.

I'm hoping this makes reporting bugs much faster.

3. One Place for the Entire Bug Lifecycle

The bug detail page is probably the most important part of the application.

Instead of treating a bug as just a ticket, I'm trying to keep its entire lifecycle connected.

For example:

Reported → Assigned → In Progress → Ready for Retest → Retesting → Verified

If the retest fails:

Retesting → Reopened → Developer

The page keeps the important context together:

Description
Steps to reproduce
Expected result
Actual result
Screenshots / evidence
Developer
Reporter
Environment
Found in build
Fixed in build
Original test case / test run

So ideally, a developer shouldn't need to ask the tester for missing context in another tool.

4. Retest History That Never Disappears

This is one of the main reasons I started building this.

Every retest is stored separately.

For every attempt, I want to know:

Who tested it?
Which build was tested?
When was it tested?
Did it PASS or FAIL?
Were there any notes?

So a bug could have a history like:

Retest #1

❌ Failed · v2.1.0

Retest #2

❌ Failed · v2.1.1

Retest #3

✅ Passed · v2.1.2

Instead of only seeing that a bug is "closed", you can understand how it actually got there.

No more:

"Who verified this?"

or:

"Which version did we test?"

5. Activity, Retests and Comments Stay Connected

I'm also trying to avoid splitting the conversation and history across different places.

Each bug has three simple areas:

Activity

Who created it, who was assigned, when the status changed, when a fix became available, etc.

Retests

Every verification attempt and its result.

Comments

Questions and discussion between testers and developers.

This way, opening a bug should be enough to understand what happened without searching through Slack messages.

6. Notifications Without Creating More Noise

I don't want notifications for every tiny change.

The goal is to notify someone when their action is actually required.

For example:

A bug is assigned to you
A fix is ready for your retest
Your retest failed and the bug was reopened
Someone mentioned you

There's also an important distinction I'm experimenting with:

Notification

Mehmet marked BUG-184 as ready for retest.

Inbox

You need to retest BUG-184.

Reading the notification shouldn't remove the work from your Inbox.

The Inbox item disappears only when the required action is completed.

I think this distinction could make the workflow much clearer.

7. Basic Analytics — Not 30 Different Charts

I'm deliberately keeping analytics small.

Right now I'm experimenting with metrics like:

Open bugs
Critical bugs
Bugs waiting for retest
Verified bugs this week
Median time to assign
Median time to fix
Median time to retest
Median resolution time
First retest pass rate
Reopen rate
Stale bugs

The goal isn't to build a huge reporting platform.

I mainly want to answer:

Where is our QA workflow getting stuck?

For example, maybe developers are fixing bugs quickly, but bugs sit for two days waiting for someone to retest them.

That's something a simple "open bugs" counter doesn't show.

8. Projects and Test Cases Are Intentionally Simple

I'm trying very hard not to accidentally rebuild Jira.

Projects currently exist mainly to group:

Test Cases + Test Runs + Bugs

That's it.

I'm intentionally avoiding things like:

Sprints
Epics
Roadmaps
Story points
Complex permission matrices
Custom workflows
50 configuration screens

At least for now.

The target is a small software team that wants a clearer testing workflow without adopting another massive project management system.

🧩 The Workflow I'm Building Around

The whole product basically revolves around this:

Project

↓

Test Case

↓

Test Run

↓

Bug

↓

Developer

↓

Fix

↓

Retest

↓

Verified

And if the retest fails:

Reopened → Developer → Fix → Retest

That's the core.

Everything else should support that workflow.

🤔 And This Is Where I Need Feedback

The product is still being developed, so I'm trying to validate the workflow before adding too much.

If you work in a small software team, I'd really like to know:

1. How does your team handle this today?

Jira? Linear? GitHub Issues? Trello? Slack? Spreadsheets? Something else?

2. Is the Fix → Retest handoff actually a problem for your team?

When a developer fixes something, how does the tester know it's ready to be tested again?

3. Do you keep a history of multiple retest attempts?

Or do you simply change the status of the original issue?

4. Would a personal "QA Inbox" be useful?

Instead of another backlog, you only see things that currently require your action.

5. Which analytics would actually be useful?

Would you care about things like time-to-fix, time-to-retest, reopen rate, or first-retest pass rate?

And probably the most important question:

What should I NOT add?

I'm trying to keep this intentionally small.

I'd rather remove unnecessary features now than spend weeks building another complicated project management tool.

Any feedback from testers, developers, QA engineers, or small-team founders would be extremely useful.

DEV Community: norvane