QAwork Tour
A visual walk-through of how QAwork looks in practice, with separate flows for testers and admins inside the same project.
Demo Flow
Pick a role and view the full project flow in screenshot-style scenes. This is a mock walkthrough, not a live project.
Tester walkthrough
See how a tester opens the right project, works through one scenario at a time, updates environments, and reads reporting without touching admin settings.
1. Open Test Execution and choose a checklist
The tester opens the checklist they need, expands the right scenario, and focuses only on the exact test card they are running now.
User authentication on Demo Portal
Login recovery and access checks
Orders and profile updates
2. Open the scenario first, then the exact test inside it
QAwork keeps the structure clear: first the tester opens the scenario, then drills into the one test case they want to execute right now.
User authentication on Demo Portal
Sign in with email and password
Password reset request
Sign in with Gmail
Sign in with SMS code
3. Open one test and read the context before execution
Inside the scenario, the tester sees one focused test card with the title, description, expected result, and a link to the supporting reference.
Sign in with email and password
4. Keep test references connected to the scenario
Links help the tester move straight to Jira, Google Sheets, docs, or any other source, then return with the right context instead of searching manually.
5. Update only the environments that were actually checked
Each platform keeps its own status, so Android, iPhone, web, and desktop do not get mixed into one unclear result.
Sign in with email and password
6. Create a bug or link Jira directly from the test
Every test can hold its own follow-up work. Teams with Jira can link existing tickets and sync solved statuses, while teams without Jira can use QAwork's internal bug tracking instead.
Sign in with email and password
7. Open Analytics and see the run status
The report compares the current run with the planned scope, shows coverage and pass rate, and highlights regressions when something that worked before is now failing or has become worse.
8. Ask for help if anything blocks the flow
Support stays visible in the product, so testers always know where to ask for access, project help, or clarification.
Admin walkthrough
See how a QA lead prepares the project, shapes the checklist, opens the active run, manages the team, and still uses test execution when needed.
1. Create or open the right project space
Every project has its own users, checklists, settings, link base, and report visibility, so client work does not leak into another workspace.
2. Start with Checklist Builder With AI when you want a more accurate first draft
The AI builder is better when the admin wants a faster and more precise first structure for the checklist, scenario, test title, description, and expected result, while still keeping full manual control over the final wording. If needed, the admin can also skip AI completely and create everything manually from the start.
Who usually uses this functionality?
What does the user want to do?
3. Open the active run in Planning Control
The admin creates a run, reviews unplanned tests, and attaches the right scope so testers only see what belongs to the current execution cycle.
4. Manage testers and access in Team Access
The admin adds testers, disables accounts when needed, and keeps project access clean without touching other projects.
5. Test like a tester when validation is needed
The admin still uses Test Execution in the same focused way as a tester, updating only environment statuses instead of editing structure there.
6. Track follow-up work from each test
The QA lead can keep bugs tied to the exact test case. Jira-linked tickets sync back into QAwork, and solved Jira tickets stop increasing the open bug counter; teams without Jira can stay fully inside the internal tracker.
7. Open Analytics and see the run status
The admin reviews the same report logic as the tester, while using it to monitor scope, regressions, risk, trends, and optional sprint visuals across the whole run.
Why teams use QAwork
QAwork keeps planning, execution, and reporting connected in one workspace instead of scattering the process across disconnected sheets and status updates.
Less confusion
One shared project flow makes it easier to know what should be tested now, what is still open, and what belongs to each team member.
Better prioritization
Risk, priority, and checklist structure help the team decide what to run first when release time is short.
Faster updates
Saved results update the report directly, so stakeholders can see progress without waiting for someone to rebuild a summary manually.
Closed and guided
QAwork is a closed platform. Project creation and access are managed intentionally, and support is available at [email protected].