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.
Top comments (0)