Quiz: The Practitioner's Playbook | E-Commerce Test Automation: The Practitioner's Playbook

1

You can automate a small internal report that one colleague opens once a month, or the guest checkout flow. Which should you automate first, and why?

The report — it's simpler to automate Checkout — high breakage risk and catastrophic cost if it breaks Both equally; automate whatever is quickest to write Neither; both should be manual

2

The tax on a ₹185.00 item should be ₹14.80. What's the best layer to verify that calculation?

A full end-to-end browser test through checkout A unit test on the tax function A manual check every release It doesn't need testing

3

Which describes the 'ice-cream cone' anti-pattern?

Too many unit tests and no E2E tests A suite that is mostly slow, flaky UI tests with almost no unit tests underneath Tests that run in a random order Using factories instead of hard-coded data

4

You need to verify checkout rejects a missing first name, a missing last name, AND a missing postal code. What's the cleanest approach?

Write three separate copy-pasted test functions One data-driven test that loops over a table of cases, generating one test per row One test with three assertions in a row Test only the missing-postal-code case; the others are similar

5

What is the main benefit of the Page Object Model?

It makes tests run faster Selectors live in one place, so a UI change is a one-file fix and tests read like business intent It removes the need for assertions It lets you skip writing test data

6

A factory function like makeCustomer({ lastName: '' }) is preferred over a hard-coded customer object because...

It runs in parallel automatically The test states only the field that matters, and there's one place to change if the shape changes It avoids needing a Page Object It makes the browser faster

7

A test uses `await page.waitForTimeout(6000)` to wait for a slow page. Why is this a problem?

Hard waits are always either too short (flaky) or too long (slow); there is no correct number waitForTimeout is not a real function It only works in CI It's fine as long as the number is big enough

8

Your suite passes when run alone but fails intermittently when run in parallel. What's the most likely cause?

The CI machine is too fast Shared mutable state — data pollution, order dependence, or a shared account between tests Too many unit tests The Page Objects are too detailed

9

When is auto-retrying a failed test in CI a legitimate tool rather than a bandage?

Whenever a test fails, to keep the build green Only to absorb rare, provably external non-determinism (e.g. a flaky third-party sandbox), after diagnosing the cause Never; retries are always wrong Only for unit tests

10

A bug corrupts data on an internal page no customer can reach yet. How should severity and priority be set?

High severity, but potentially lower priority Low severity and low priority — it's internal They are the same thing, so both High High priority automatically because data is involved

11

You reported and got a fix for a checkout bug. What closes the loop?

Nothing — the fix is enough Add a regression test asserting the correct behavior, so the bug can't silently return Delete all related tests Re-run the whole suite once

12

Why must a suite be made deterministic (flake-free) BEFORE it's used as a required check that blocks deploys?

Because CI can't run flaky tests Because a flaky required check trains the team to ignore red, so a green check stops meaning the app works Because parallel execution requires it It doesn't matter; blocking is always safe

Launch Offer