QA Engineer
Full time Posted April 11, 2026
About Fog Panther
Fog Panther is a professional desktop image editor for Linux. We build native packages for the major distributions as well as Flatpak and Snap, and we care deeply about performance, correctness, and a clean native feel on the GNOME desktop.
We are a very small team. The work is varied and the bar is high.
About the role
A creative tool fails in ways that matter. A filter that produces a wrong pixel at one zoom level. A file that opens correctly today and corrupts tomorrow. An undo that quietly forgets a step. A tool that behaves differently with a stylus than with a mouse. A keyboard shortcut that works in one panel and not in another. The bugs that frustrate professional users are the ones that no one notices until they cost somebody an hour of work.
We are looking for someone whose job is to find those bugs before our users do, and to build the test infrastructure that keeps them from coming back.
What you'll do
- Test the application end to end, manually and methodically. Real workflows on real files, across the kinds of documents our users actually open.
- Design and maintain test plans for releases. Decide what to cover, how deeply, and on which configurations. Sign off on what ships.
- Write automated tests where automation is the right tool: unit tests for new code paths, regression tests for fixed bugs, golden-image comparisons for filters and rendering, scripted UI interaction where feasible.
- Build and improve the test infrastructure itself: fixtures, harnesses, CI configuration, coverage reporting, flake triage. We want fewer flaky tests, not a culture of hitting "retry."
- Reproduce reported bugs reliably and reduce them to the smallest case that shows the problem. A good repro is half the fix.
- File bug reports that an engineer can act on without asking follow-up questions: steps, expected, actual, environment, attachment, and the one detail that turns out to be load-bearing.
- Test on the configurations our users actually run: multiple Linux distributions, both packaging formats (Flatpak and Snap), HiDPI and standard displays, single and multi-monitor, mouse and tablet input, different keyboard layouts and locales, including right-to-left.
- Test imported and exported files round-trip against the tools our users come from. Files leave our app and have to survive what comes next.
- Keep an eye on performance. Spot the regression in the release branch before it ships, not after.
- Push back on us when something is shippable but shouldn't ship. We need that.
What we're looking for
Required:
- Real QA experience on a non-trivial software product. You can describe bugs you found that mattered, and explain how you found them.
- A methodical mind. You can take a feature you've never seen before and enumerate the ways it could break, then go try them.
- Comfort with Linux as a daily driver, the command line, git, and reading log output. You are not afraid of a stack trace.
- Scripting fluency in at least one of Python, Bash, or similar. Enough to automate repetitive checks, drive a test harness, and process the output.
- Reading-level comfort with C or C++. You don't need to write production code, but you should be able to follow what the code is doing when an engineer points at it, and you should be able to read a test that someone else wrote.
- Clear written communication. Your bug reports are the artifact your job is judged on.
- Patience and stubbornness in roughly equal measure.
Nice to have (any of these):
- Experience testing creative or professional desktop software — image editors, vector tools, video, 3D, audio, CAD.
- Hands-on experience with photography, illustration, retouching, or another creative practice that uses these kinds of tools.
- Familiarity with image file formats and the things that go wrong in them: colour profiles, layers, alpha, metadata, encoding edge cases.
- GTK or other desktop UI testing experience.
- Performance testing and profiling.
- Accessibility testing: keyboard navigation, screen readers, contrast.
- Internationalisation testing, especially right-to-left layouts and non-Latin scripts.
- Fuzzing, property-based testing, or other systematic bug-finding techniques.
- Experience setting up CI for desktop applications.
How we work
- Small team, direct communication, no process theatre.
- QA, design, and engineering sit at the same table. You'll see features before they're done and be expected to have opinions.
- A bug report is the start of a conversation, not the end of one.
- We document non-obvious decisions so the next person understands why.
Practical details
- Location: on-site in Toronto, Canada. This is not a remote role. You must already be authorised to work in Canada — we are not able to sponsor visas.
- Compensation: competitive, depends on experience. Tell us what you need.
- Start date: flexible.
How to apply
Send an email with:
1. A short note about why this project interests you. Skip the cover letter boilerplate. One or two paragraphs is plenty.
2. A description of a real bug you found that you're proud of. What were you doing, what tipped you off, how did you isolate it, and why did it matter? Any product, any stack.
3. Optional: pick a feature in any creative tool you use today and write us a short test plan for it — what you'd cover, what you'd skip, and why. A page is plenty.
We read every application ourselves. No recruiters.
Fog Panther is a professional desktop image editor for Linux. We build native packages for the major distributions as well as Flatpak and Snap, and we care deeply about performance, correctness, and a clean native feel on the GNOME desktop.
We are a very small team. The work is varied and the bar is high.
About the role
A creative tool fails in ways that matter. A filter that produces a wrong pixel at one zoom level. A file that opens correctly today and corrupts tomorrow. An undo that quietly forgets a step. A tool that behaves differently with a stylus than with a mouse. A keyboard shortcut that works in one panel and not in another. The bugs that frustrate professional users are the ones that no one notices until they cost somebody an hour of work.
We are looking for someone whose job is to find those bugs before our users do, and to build the test infrastructure that keeps them from coming back.
What you'll do
- Test the application end to end, manually and methodically. Real workflows on real files, across the kinds of documents our users actually open.
- Design and maintain test plans for releases. Decide what to cover, how deeply, and on which configurations. Sign off on what ships.
- Write automated tests where automation is the right tool: unit tests for new code paths, regression tests for fixed bugs, golden-image comparisons for filters and rendering, scripted UI interaction where feasible.
- Build and improve the test infrastructure itself: fixtures, harnesses, CI configuration, coverage reporting, flake triage. We want fewer flaky tests, not a culture of hitting "retry."
- Reproduce reported bugs reliably and reduce them to the smallest case that shows the problem. A good repro is half the fix.
- File bug reports that an engineer can act on without asking follow-up questions: steps, expected, actual, environment, attachment, and the one detail that turns out to be load-bearing.
- Test on the configurations our users actually run: multiple Linux distributions, both packaging formats (Flatpak and Snap), HiDPI and standard displays, single and multi-monitor, mouse and tablet input, different keyboard layouts and locales, including right-to-left.
- Test imported and exported files round-trip against the tools our users come from. Files leave our app and have to survive what comes next.
- Keep an eye on performance. Spot the regression in the release branch before it ships, not after.
- Push back on us when something is shippable but shouldn't ship. We need that.
What we're looking for
Required:
- Real QA experience on a non-trivial software product. You can describe bugs you found that mattered, and explain how you found them.
- A methodical mind. You can take a feature you've never seen before and enumerate the ways it could break, then go try them.
- Comfort with Linux as a daily driver, the command line, git, and reading log output. You are not afraid of a stack trace.
- Scripting fluency in at least one of Python, Bash, or similar. Enough to automate repetitive checks, drive a test harness, and process the output.
- Reading-level comfort with C or C++. You don't need to write production code, but you should be able to follow what the code is doing when an engineer points at it, and you should be able to read a test that someone else wrote.
- Clear written communication. Your bug reports are the artifact your job is judged on.
- Patience and stubbornness in roughly equal measure.
Nice to have (any of these):
- Experience testing creative or professional desktop software — image editors, vector tools, video, 3D, audio, CAD.
- Hands-on experience with photography, illustration, retouching, or another creative practice that uses these kinds of tools.
- Familiarity with image file formats and the things that go wrong in them: colour profiles, layers, alpha, metadata, encoding edge cases.
- GTK or other desktop UI testing experience.
- Performance testing and profiling.
- Accessibility testing: keyboard navigation, screen readers, contrast.
- Internationalisation testing, especially right-to-left layouts and non-Latin scripts.
- Fuzzing, property-based testing, or other systematic bug-finding techniques.
- Experience setting up CI for desktop applications.
How we work
- Small team, direct communication, no process theatre.
- QA, design, and engineering sit at the same table. You'll see features before they're done and be expected to have opinions.
- A bug report is the start of a conversation, not the end of one.
- We document non-obvious decisions so the next person understands why.
Practical details
- Location: on-site in Toronto, Canada. This is not a remote role. You must already be authorised to work in Canada — we are not able to sponsor visas.
- Compensation: competitive, depends on experience. Tell us what you need.
- Start date: flexible.
How to apply
Send an email with:
1. A short note about why this project interests you. Skip the cover letter boilerplate. One or two paragraphs is plenty.
2. A description of a real bug you found that you're proud of. What were you doing, what tipped you off, how did you isolate it, and why did it matter? Any product, any stack.
3. Optional: pick a feature in any creative tool you use today and write us a short test plan for it — what you'd cover, what you'd skip, and why. A page is plenty.
We read every application ourselves. No recruiters.