A mobile QA workflow: tasks per build and a release activity feed

A tester reports that the login screen freezes. The report sits in a chat thread. Someone copies it into a task list, but without the build number. A developer fixes it, uploads a new build and moves on. Two days later the client asks whether the login bug is fixed, and nobody can say on which build it was found, which build has the fix, or whether anyone checked.

None of these steps is hard. The problem is that each one lives in a different place. This guide covers a lightweight QA workflow for mobile apps: a loop that ties every bug to a build, a simple way to turn tester reports into tasks, and an activity feed that answers "who promoted the build" without asking around. At the end it shows how tasks and the activity feed work in AppForShare.

Why mobile QA work scatters

On a typical small team, builds live in one tool, tester feedback arrives in another (chat, email, a form or the install page), and tasks sit in a third. Release decisions happen in a fourth: a message saying "build 52 is going to the client". What gets lost is the connection between them.

Mobile makes this worse than web work. On the web there is usually one version in production and one in staging. On mobile, testers may have three different builds installed, iOS and Android builds move at different speeds, and a fix is not real until a new build has been signed, uploaded and installed. A bug report without a build attached is often a report about an old version.

The lightweight QA loop

Most teams do not need a heavy test management process. They need a loop that closes every time:

1. Build. A new build is uploaded and shared with testers.
2. Test. Testers install it and work through what changed.
3. Report. They send what they find, tied to that build.
4. Task. Reports that need work become tasks with an owner.
5. Fix. A developer fixes the issue.
6. New build. The fix ships in a new build.
7. Verify. Someone checks the issue on the new build and closes the task.

The step teams skip most often is the last one. A task moved to Done because the code was merged is not the same as a task verified on a build a tester can install. Keeping a review column between In progress and Done gives verification its own place.

Linking tasks to builds: found in and fixed in

Every bug has two build numbers that matter.

• Found in. The build where the problem was seen. This tells the developer which code to look at and tells everyone whether the bug is new or old.
• Fixed in. The first build that contains the fix. This tells the tester which build to install to verify it, and tells the release owner whether the build going out includes the fix.

Why the build number matters

Version names such as 2.4.0 often stay the same across many test builds. The build number is what changes. Without it, "fixed in 2.4.0" can mean any of ten builds, and a tester may verify on a build that does not have the fix yet, see the bug again and reopen a task that was actually fixed.

Verify on the right build

When a task moves to review, write the fixed in build in the task or a comment, and ask the tester to install exactly that build or a later one. If the bug is platform specific, verify on the same platform and, where possible, a similar device to the one in the original report. Then move the task to Done.

If you already plan what testers should check on each build, the guide on what to test in a new app build covers ordering that list by risk.

Turning tester reports into tasks without retyping

Copying a report into a task by hand loses details. The device, the OS version and the screenshot are the first things to go. A good conversion keeps:

• A short title taken from the report, so the task is recognizable.
• The tester's full message and the device details in the task description.
• A link back to the original report and to the build it was sent from.
• One task per report, so the same bug does not end up as three tasks.

Not every report needs a task. Duplicates, questions and "works as intended" can be resolved directly. A task is for something someone has to do.

Your main tracker or a board next to the builds

If your team already runs everything in Linear or Jira, send bug reports there. One backlog is better than two, and the guide on sending beta feedback to Linear and Jira covers how to do it without losing context.

A lightweight board next to the builds makes more sense when:

• The project is small or short, such as an agency build for one client, and a full tracker setup is more than it needs.
• The people testing and fixing are not all in your main tracker, for example a freelancer or a QA contractor.
• The work is release specific: a list of things to fix before this build goes out, which you do not want mixed into a long product backlog.

Many teams use both: product work in the main tracker, and the short pre-release fix list on a board where the builds are.

Why a release team needs an activity feed

Releases involve small, quick actions by different people: someone uploads a build, someone else moves it to the channel testers or the client use, someone pauses an old link, an Admin overrides a checklist because the client is waiting. A week later, when a client installed the wrong build or a blocker shipped, the question is: who did what, and when?

Audit

An activity feed answers that question without anyone having to remember. It is especially useful for actions that skip a safeguard, such as promoting a build before the release checklist was finished. The point is not to blame anyone. It is to see the decision clearly and decide whether the process needs to change.

Handover

When someone joins a project, comes back from leave or takes over a release, a list of recent events shows the state of things faster than reading chat history: which builds went where, which reports came in, which tasks were finished.

What to log

A useful release log records events that change what testers, clients or the team see:

• Builds uploaded and deleted.
• Builds put into a channel, and whether a release gate was overridden.
• Tester feedback received, resolved, reopened or marked as a blocker.
• Tasks added and finished.
• Release checklist steps ticked.
• Install links paused, given a stop date or an install limit.
• Reports sent to an outside tracker.

Each line needs who did it and when. Keep it to one line per event so the feed stays readable.

How tasks and the activity feed work in AppForShare

AppForShare shares iOS and Android test builds through install links and QR codes, and collects tester feedback on the install page. On the Team plan, every project also has a task board and the workspace has an activity feed. See tasks and activity for the feature page.

The task board

Open a project and go to Tasks. The board has four columns: To do, In progress, In review and Done. Drag a card or change its column to move it. A task can have an assignee from the workspace, a due date, comments and a linked build of that project, which is where you record the build a fix shipped in.

No client is needed to use the board. If the project also has a client set up for client work, tasks marked for the client show in the client portal, and all other tasks stay visible to the team only.

Developers can add and move tasks. Viewers can read them.

Make a task from a tester report

On a feedback report, in the feedback inbox or on the build page, press Make a task. AppForShare adds a task to the project of that build, titled from the report ("Bug: " followed by the first line), with the tester's message and device in the details. The task is linked to the build and to the report. Each report can become a task once, so the same report does not create duplicates.

The activity feed

Under Dashboard, Activity, the feed shows one line per event with who did it and when, newest first. You can filter by project and by kind. It records:

• Uploads and deleted builds.
• Builds put into channels, including a note when it happened before the release checklist was done because an Admin overrode the gate.
• Tester feedback received, resolved, reopened or marked as a blocker.
• Tasks added and finished.
• Release checklist steps ticked.
• Links paused or given a stop date or install limit.
• Feedback sent to Linear or Jira.

Events are recorded on every plan, so the feed already has history on the day a workspace moves to Team. Reading the feed needs Team.

CLI and MCP

From the command line, npx appforshare feedback-task <feedback id> turns a report into a task, and npx appforshare activity --project 12 --kind channel lists channel events for one project. The MCP server has two matching tools: task_from_feedback, which asks for confirmation before it adds the task, and recent_activity, which only reads. Setup is on the MCP page.

How it fits with the rest

• Send feedback to Linear or Jira (Pro and Team) when the work belongs in your main tracker.
• The release checklist and blockers (Team) hold a build back from the Live channel until open blockers are resolved.
• The AI test plan suggests what testers should check on each build.

What it does not do

• There is no time tracking and no sprints. The board is a simple list of work per project.
• There is no two way sync between the board and Linear or Jira.
• The activity feed is a log to read. It does not send a notification for every event.

Tasks and the activity feed are part of the Team plan; see pricing for what each plan includes.

Common questions

What is a good QA workflow for a small mobile team?

A loop of build, test, report, task, fix, new build and verify, with every report and task tied to a build number. Keep a review column so fixes are checked on an installable build before they count as done.

How do I track bugs per build?

Record the build each bug was found in and the build that contains the fix. Use the build number, not only the version name, because the version often stays the same across many test builds.

Should QA tasks live in Jira or Linear or next to the builds?

If the whole team works in one tracker, keep bugs there. A board next to the builds suits short projects, agency work and pre-release fix lists, especially when some testers or contractors are not in your main tracker.

How can I see who promoted a build?

Keep an activity log that records channel changes with the person and time. In AppForShare, the activity feed on Team lists every build put into a channel and notes when an Admin overrode the release checklist.

Do I lose activity history if I upgrade to Team later?

No. AppForShare records events on every plan. Reading the feed needs Team, so the history is there once you upgrade.