Signup and account flow
Check account creation, login, password reset, profile updates and error states.
AccountsFormsStates
QA Testing
Manual QA testing for real product flows
I test how the product behaves when users click around, make mistakes, go back, refresh, submit twice or hit an unexpected state.
When this helps
Use this when a feature, release or product flow needs a careful human QA pass. I check the happy path, but also the messy paths users actually create.
What I check
- Core user flows and important feature paths
- Forms, validation, empty states and error states
- Regression checks around recent changes
- Smoke checks before release
- Mobile and responsive behaviour
- Clear bug reports with steps, evidence and impact
Common problems
Forms accept bad data or show unclear errors
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
A user can start a flow but not finish it
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
Back, refresh or retry creates a broken state
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
A recent fix breaks nearby behaviour
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
Mobile layout hides or damages important information
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
The product works once, but fails when the user repeats or changes the action
I check how this behaves in the real flow and whether it can block, confuse or mislead a user.
Example checks
What you get
Bug reports
Steps to reproduce, expected result, actual result, impact, screenshots and environment details.
Test summary
A short overview of what was checked, what failed and what still feels risky.
Retest notes
Confirmation when fixes are verified, partly fixed or still failing.
Example finding
Area: Checkout → Delivery address form Issue: User can continue without required postal code Steps: 1. Open checkout 2. Leave postal code empty 3. Click Continue Actual: The user reaches payment without a complete delivery address. Expected: The form should block progress and show a clear postal code validation message. Impact: Orders can be submitted with incomplete delivery information.
Good fit
- You are releasing a feature and need a focused QA pass
- Users report bugs but the team needs clearer reproduction
- You need regression checks around recent fixes
- You want bug reports developers can act on quickly
Not the best fit
- You only want a full automation framework with no manual testing
- You need 24/7 crowdtesting with many testers at once
- There is no test environment or safe test data available
How it usually runs
1
Define the risk
Clarify the feature, changed areas and known concerns.
2
Test the flow
Check main paths, negative paths, edge cases and regression areas.
3
Report clearly
Write issues with steps, evidence, impact and expected behaviour.
4
Retest fixes
Verify the fix and check whether nearby behaviour still works.
Related examples
A few useful pages that show how this kind of work is reported.
FAQ
Can this be a one-time release check?
Yes. A focused release check is often the best starting point when the team needs a second pair of eyes quickly.
Do you create test cases?
Yes, when they help future regression work. I avoid writing test documents nobody will use.
Can you report directly in Jira or another tracker?
Yes. I can report in Jira, Linear, GitHub Issues or a structured document depending on your workflow.
Need a practical QA pass before release?
Send the feature, test environment and what feels risky. I’ll help shape a focused testing scope.