QA / Test Engineer

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterA pure function calculates VAT and rounding for an order total. Where should most of its rounding edge cases be checked?

   In a load test that sends varied order totals to the APIIn unit tests that call the function directly with many inputsIn E2E tests that go through the full checkout UI for each caseIn a manual regression pass run by QA before every release
2. Question 2 of 4·StarterA manager asks why 2,000 passing tests did not prove the release was bug-free. Which testing principle answers this?

   Testing early in the lifecycle saves time and money laterTesting shows the presence of defects, not their absenceDefects cluster together in a small number of modulesRepeating the same tests eventually stops finding new bugs
3. Question 3 of 4·StarterYou have two days to test a release touching the payment flow, the about page and avatar upload. How should risk-based testing split your effort?

   Give each area equal time so coverage looks balanced in the reportStart with the area that already has the most written test casesRate likelihood times impact, so payment gets the deepest coverageFocus on whichever change was merged last, since it is newest
4. Question 4 of 4·StarterIn story refinement, a story says 'User can apply a discount code'. What is the most valuable shift-left action for QA?

   Wait for the first build and then write test cases from what the UI showsAsk about expired, reused and stacked codes and capture them as Given/When/Then criteriaEstimate how many test cases the story needs and add that to the sprint planAsk developers to add E2E tests for the story before it can be merged

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterAn age field accepts 18 to 65 inclusive. Which set of values applies boundary value analysis correctly?

   0, 18, 65 and 10017, 18, 65 and 6618, 40 and 6519, 30, 50 and 64
2. Question 2 of 4·StarterWhy does pairwise testing cut the number of cases sharply while still catching most configuration bugs?

   Most interaction bugs are triggered by a combination of just two parameter valuesIt still runs every combination, just spread across parallel workersIt only tests the default value of each parameter, which users pick mostIt drops parameters that rarely change, so fewer columns remain
3. Question 3 of 4·StarterAn order moves draft, paid, shipped, delivered, and can be cancelled only before shipping. Which test is most likely to reveal a hidden bug?

   Try to cancel a delivered order and expect the system to reject itCheck that a shipped order displays its tracking numberCreate several draft orders in a row for the same userMove a draft order to paid using a valid test card
4. Question 4 of 4·StarterWhich bug report title is most useful for the developer who picks it up?

   Several issues found while testing checkout and profile pagesCheckout does not work, please check as soon as possible todayURGENT: payment is broken for users, blocking the releaseCheckout: Pay button stays disabled after valid card entry on Safari 18

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·StarterA logged-in user opens an admin page and the API returns 403. What does that tell you?

   The token is missing or expired, so the user must log in againThe request body failed validation on one or more fieldsThe resource has been deleted and no longer exists on the serverThe server knows who the user is, but they lack permission for this resource
2. Question 2 of 4·StarterAn API call works in Postman but fails in the browser with a CORS error. Why?

   The API rejects every request that has no User-Agent headerPostman sends a different HTTP method than the browser doesThe browser enforces CORS, and the server is not allowing this page's originThe browser cache is still serving an old, stale response
3. Question 3 of 4·StarterA list page shows 'No items yet' for a user who has items. In the Network tab the list request returns 500. How should you file it?

   As a UI bug about the wrong empty state message, without API detailsAs a flaky test, because refreshing the page sometimes makes it go awayAs an API bug with status, request ID and body, noting the UI hides the error as an empty stateAs a test data problem, asking someone to reseed the staging database
4. Question 4 of 4·StarterWhy is automatically retrying a PUT usually safer than retrying a POST?

   Browsers cache PUT responses, so a retry never reaches the server againPUT is idempotent, so repeating it leaves the same state, while POST may create duplicatesPUT requests are always encrypted, while POST requests are not by defaultPUT cannot carry a request body, so a retry has nothing to duplicate

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateIn a Playwright test, page.click('#save'); expect(page.getByText('Saved')).toBeVisible(); has no await. What is the problem?

   Only the click needs await; web-first assertions run synchronouslyThe test needs waitForTimeout before the assertion to workNothing, because Playwright awaits every action automaticallyThe test can finish before the actions run, so it may pass falsely or throw detached errors
2. Question 2 of 4·IntermediateSetup creates three independent test users with await Promise.all([...]). What does that give you?

   The users are created strictly in array order, one after anotherEach request is retried automatically until it finally succeedsRejected promises are ignored, so setup can never fail halfwayThe requests run concurrently, and setup fails if any one of them rejects
3. Question 3 of 4·IntermediateTest B only passes when test A runs first, because A creates the user that B logs in with. What is the consequence?

   The runner detects the dependency and runs A first automaticallyB becomes faster because it can reuse the data A createdB fails when run alone, shuffled or in parallel, for reasons unrelated to the featureNothing harmful, since test order is stable in every runner
4. Question 4 of 4·IntermediateA pull request changes a shared date-formatting helper used by invoices and reports. Where should you focus testing?

   The login flow, because it is the most used part of the productNowhere extra, because the helper already has its own unit testsEvery screen and export that uses the helper, especially invoices and reports across time zonesOnly the files listed in the diff, since nothing else was touched

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateHow do you test GET /orders/{id} for broken object level authorization (BOLA)?

   Send the request without any token and expect a 401 responseSend 1,000 requests per second and expect a 429 from the APISend an id in the wrong format and expect a 400 validation errorUse user A's token to request an order owned by user B and expect 403 or 404
2. Question 2 of 4·IntermediateWhy validate each response against the OpenAPI schema before asserting specific values?

   It cheaply catches renamed fields, type changes and unexpected nulls across every responseIt proves the business rules behind each value are correctIt replaces the need to test authorization and access controlIt makes requests faster because the server returns a smaller body
3. Question 3 of 4·IntermediateWhat should a Pact contract test between a web app and an orders API verify?

   That the web app renders the order list correctly on screenThat the request and response shapes the consumer relies on are still honoredThat the provider meets its p95 latency target under loadThat the provider calculates every discount rule correctly
4. Question 4 of 4·IntermediateBefore releasing a new consumer version, the team runs can-i-deploy against the Pact Broker. What does it answer?

   Whether the target environment has enough capacity for the releaseWhether the release notes and changelog for the version are completeWhether the provider version in that environment has verified this consumer's pactWhether the new consumer version passed its own unit test suite

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·Intermediateawait page.getByRole('button', { name: 'Delete' }).click() runs on a page with two matching Delete buttons. What happens?

   Playwright throws a strict mode violation instead of guessingPlaywright clicks both buttons one after the otherPlaywright clicks the first matching button in DOM orderPlaywright waits until one button disappears, then clicks
2. Question 2 of 4·IntermediateA test is flaky because the 'Saved' toast sometimes appears after 2 seconds. Which fix is right?

   Raise retries to 3 in the config so a slow run gets another chanceCheck await page.getByText('Saved').isVisible() once in an ifAdd await page.waitForTimeout(3000) right before checking the toastUse await expect(page.getByText('Saved')).toBeVisible(), which retries until timeout
3. Question 3 of 4·IntermediateEvery test in a 300-test suite logs in through the UI first. What is the recommended improvement?

   Share a single browser context across all tests so the session persistsDisable authentication entirely on the test environmentLog in once in a setup project, save storageState, and reuse it in testsRun the suite serially so only one login happens at a time
4. Question 4 of 4·IntermediateWhy is cranking up retries to keep the pipeline green a risky habit?

   Retries make every passing test run noticeably slowerRetries can mask real race-condition bugs that users will also hitRetries turn off trace recording for the failing attemptsRetries force all tests to run in a fixed serial order

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateYou split a Playwright suite across 4 CI machines with --shard. How do you get a single HTML report?

   Use the blob reporter on each shard, then run npx playwright merge-reportsUse the list reporter, which merges shard output automaticallyDownload every shard's HTML report and keep the newest oneSet workers: 4 on one machine instead, since shards cannot merge
2. Question 2 of 4·IntermediateScreenshot tests pass locally but fail on CI with tiny font and anti-aliasing diffs. What is the most likely cause?

   CI runs tests faster, so screenshots are taken before animations endBaselines were captured on a laptop whose fonts and rendering differ from the CI containerVisual comparisons are not supported when browsers run headlessThe diff threshold must be set to zero for CI comparisons
3. Question 3 of 4·IntermediateTests fail on staging because someone edited a shared test account. Which approach fixes this best?

   Lock the shared account so nobody on the team can edit itRestore a full database snapshot every morning before the runCreate fresh data per test through APIs or factories, namespaced and cleaned upRetry failing tests until the shared data happens to be right
4. Question 4 of 4·IntermediateWhy gate pull requests on a fast tier and run the full E2E suite on a schedule or before release?

   Developers get feedback in minutes while full coverage still runs before shippingFast tiers find more bugs than full suites, so full runs are optionalFull E2E suites cannot run inside CI containers at allScheduled runs are free because CI minutes are not billed at night

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·IntermediateHow should you choose the devices in a mobile test matrix?

   The newest flagship phone from each major brand on the marketWhatever emulator images ship by default with the IDEOnly the physical devices the team already has on handFrom real user analytics on devices and OS versions, reviewed every quarter
2. Question 2 of 4·IntermediateA user fills a long form, switches to the camera app, and comes back to an empty form. Which test would catch this?

   Background the app mid-form, let the OS kill it, then restore itSubmit the form with one required field left emptyOpen the same form on a tablet-sized emulator insteadRotate the device between portrait and landscape on the form
3. Question 3 of 4·IntermediateWhy is Maestro a good fit for fast smoke tests across React Native, Flutter and native apps?

   It compiles tests into the app binary so they run faster than other toolsIt only runs on physical devices, so its results are always realisticIt runs YAML flows against release builds without instrumentation and has built-in waitingIt replaces the unit tests that mobile developers would otherwise write
4. Question 4 of 4·IntermediateYour Appium tests break every time designers tweak copy or layout. What is the most effective fix?

   Run the suite only on the newest emulator to reduce variationAdd a fixed five-second sleep before each interactionSwitch every locator to absolute XPath copied from the inspectorAdd stable accessibility identifiers or testIDs and locate elements by them

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·AdvancedA load test reports an average response time of 180 ms and a p99 of 4 s. What should you conclude?

   Only the first requests were slow, so warm-up explains the whole gapThe system is healthy, because the average is well under the targetAbout 1 in 100 requests takes 4 s or longer, a tail that real users feelThe tool measured incorrectly, since p99 cannot be that far from the mean
2. Question 2 of 4·AdvancedWhich k6 option makes a run fail automatically when latency regresses?

   console.log(res.timings.duration) in every iterationsleep(1) between requests in the default functionvus: 1000 with a long duration in the optionsthresholds: { http_req_duration: ['p(95)<500'] }
3. Question 3 of 4·Advancedaxe reports zero violations on the signup page. Why can you not call the page accessible yet?

   Automated tools catch only some issues; keyboard, focus and screen reader checks need a humanaxe only checks color contrast and ignores labels and ARIAWCAG 2.2 does not cover forms, so signup pages need a different standardaxe results change randomly between runs, so one run proves nothing
4. Question 4 of 4·AdvancedLogged in as yourself, which test checks for an IDOR vulnerability?

   Change the ID in GET /invoices/1042 to another customer's invoice IDCheck that plain HTTP requests redirect to HTTPSEnter <script>alert(1)</script> into the profile name fieldSubmit the login form 50 times with a wrong password

Get at least 3 of 4 right to mark this stage as passed.

1. Question 1 of 4·AdvancedWhy is code coverage a weak KPI for test quality?

   It counts the number of tests instead of the lines they executeIt shows lines that never ran, not whether assertions would catch wrong behaviorIt only works for backend code and cannot measure frontendsIt is too expensive to collect on every CI run to be practical
2. Question 2 of 4·AdvancedA new checkout ships behind a feature flag rolling out to 10% of users. What must QA test before rollout?

   Only the off state, since 90% of users will still see itOnly the on state, since that is where the new code livesNothing yet, because testing can wait until the flag reaches 100%Both the on and off states, plus important combinations with other active flags
3. Question 3 of 4·AdvancedA self-healing tool updates a locator after a button label changed from 'Pay' to 'Pya'. Why must such fixes go through review?

   Healing can accept a wrong UI change, turning a real bug into a green testHealed locators only work locally and cannot run in CIEvery file change in the repo needs two approvals regardless of contentHealers are slower than fixing locators by hand, so review saves time
4. Question 4 of 4·AdvancedHow should you test an LLM-powered support answer feature before each release?

   Check only that the endpoint returns 200 within the latency budgetRun an eval set from real cases, scored by rules or a calibrated LLM-as-judge, in CITry ten prompts by hand before each release and check they look fineAssert an exact string match for the expected answer to each prompt