Advanced Manual QA Tester Needed — Flutter App
Publicada el 2026-07-19
Descripción de la oferta
Type: Fixed-price project (with option to extend into ongoing QA) Category: Mobile QA / Manual Testing Duration estimate: 1–2 weeks Overview We have a Flutter mobile app (Android + iOS) for a sports-coaching marketplace — athletes book sessions with coaches and academies, three user roles (Athlete, Coach, Academy) plus an Admin panel, real backend and real data. Basic QA is already done in-house — core happy-path flows (signup, browse, book, cancel, basic profile edits) have already been tested and are working. We do not need someone to click through the obvious flows again. We need an experienced QA tester who can find the bugs that basic testing misses: edge cases, race conditions, concurrent-user scenarios, partial/malformed input, boundary conditions, and the kind of subtle data-integrity issues that only show up under adversarial or unusual usage — not someone doing a first-pass functional walkthrough. If your QA process is "follow the happy path and confirm it works," this isn't the right fit. If you actively try to break things — rapid double-taps, concurrent sessions, partial form submissions, weird input, interrupted flows — please apply. The debug APK will be shared directly with the freelancer selected for this job (not posted publicly). What You'll Need - A physical Android device or emulator — we'll provide a debug APK once you're selected - Ability to install and sideload a debug build - Strong bug-report writing: steps, expected vs. actual, screenshots/screen recordings, and — where relevant — what state you'd expect on the backend/database and why the observed state is wrong - Comfort inspecting network requests/responses (via a proxy or device logs) to catch silent failures that don't show an error on screen What We Mean by "Advanced" — Test Categories - Race conditions: two devices/sessions booking the same slot simultaneously; rapid double-tap on submit/pay/cancel buttons; switching accounts quickly and checking for state bleed between sessions. - Partial/malformed data: submitting forms with only some fields filled where the API expects all; editing a single field in a large profile object and confirming unrelated fields (venues, availability, packages, gallery) aren't silently dropped. - Boundary and adversarial input: extremely long text, emoji/unicode in names and reviews, 0-byte and oversized file uploads, wrong file types disguised with a valid extension. - Session/auth edge cases: token expiry mid-action, backgrounding the app during a network call, logging in via a different auth method (Google vs Apple vs OTP) on the same account and checking for identity/state conflicts, rapid logout/login cycling. - Discount/pricing logic abuse: applying a discount code twice, applying it after removing it, reusing a one-time code, checking the charged amount actually matches the discounted price shown. - Booking lifecycle edge cases: cancel a booking the instant after creating it, reschedule a booking that's already been cancelled, cancel from two different screens at once, check whether a "cancelled" slot is actually freed up for other users. - Offline/interrupted flows: kill connectivity mid-booking, mid-upload, mid-payment; reconnect and check whether the app recovers cleanly or leaves orphaned/duplicate state. - Cross-role interference: same physical device/account switching between athlete and coach roles (where applicable), checking for cached data leaking across role switches. Deliverables 1. Bug tracker (spreadsheet or your tool of choice) — every finding with severity (Critical/Major/Minor/Cosmetic), exact repro steps, expected vs. actual, evidence (screenshot/recording/network trace). 2. A short note on which categories above you covered and how — we want to know your actual test methodology, not just a pass/fail list. 3. A prioritized "what I'd fix before release" summary, ranked by real user impact and exploitability, not just by how easy each bug is to reproduce. Nice to Have - Background in QA for marketplace/booking/fintech-adjacent apps (two-sided scheduling, payments, discount logic) - Comfort with a proxy tool (Charles/Proxyman/mitmproxy) to inspect and tamper with requests - Prior experience specifically hunting race conditions or data-integrity bugs, not just UI bugs To Qualify / How to Apply This role requires proof of advanced QA thinking before hiring — general applications without this will be skipped. Please DM me directly (do not post publicly in the proposal) with: 1. A specific, non-obvious bug you've found in a past project — not "I tested the login flow and it worked." We want a real example with the technique you used to find it. 2. A short list of 5–8 advanced test steps/scenarios you would personally run against a booking + payment app like this one, in your own words — this is the main screening filter, so make it specific to booking/scheduling/payment logic, not generic checklist items. 3. Devices/tools you have available, and your estimated timeline for the categories listed above. "Nice to Have": "Comfortable using Appium or similar for repeatable regression scripts, if useful for your workflow — not required." That signals openness without changing the core ask. Want me to add that line, or leave the post as-is? Applicants who send a generic proposal without the above will not be considered.
Skills
Fuente original: freelancer