Why Some Automation Tester Candidates Ace Every Round Except the Last

"First, I would spend a few days understanding where
the risk is: which features cause most production bugs,
and what the team checks manually before each release.

Then I would automate a small smoke suite: login,
search, add to cart, checkout and payment success.
It should run on every build in a few minutes.

Next, business rules like pricing and discounts would
be tested at API level, because that is faster and more
stable than through the UI.

Only after that would I grow the UI regression suite,
focused on journeys, not field validations."

             /\
            /UI\        few: end-to-end journeys
           /----\       (login -> checkout)
          / API  \      more: pricing, discounts,
         /--------\     stock, order status rules
        /  Unit    \    most: owned by developers,
       /------------\   I review coverage gaps

Smoke suite (every build):    a handful of UI journeys
                               + core API checks
Regression (nightly):          full API + UI journeys
Exploratory (each sprint):     manual, on new features

"I would split the failures into three groups.

One: failures that reproduce on rerun and locally. These
are likely real bugs, so I would raise them immediately
with steps, screenshots and the affected flow.

Two: failures that pass on rerun. I would check their
history. If they have failed randomly before, I would
cover that flow with a quick manual check and log the
test for fixing.

Three: failures caused by environment, like a test
server timeout. I would confirm with the team that owns
the environment.

Then I would give the release owner a short summary:
what is a real risk, what is noise, and what I checked
manually. The go or no-go decision is theirs."

# conftest.py
import pytest

def pytest_configure(config):
    config.addinivalue_line(
        "markers", "quarantine(ticket): known flaky test with a fix ticket")

# test_checkout.py
import pytest

@pytest.mark.quarantine(ticket="QA-214")
def test_coupon_applies_on_slow_network(checkout_page):
    ...

# Main pipeline: everything except quarantine
#   pytest -m "not quarantine"

# Separate job, reported but not blocking:
#   pytest -m quarantine

# Rule we follow: a quarantined test must have a ticket,
# an owner, and is reviewed every sprint.

Q: How would you show the team that automation is
   worth the effort?

A: "I would avoid claiming big savings up front.

Instead I would track a few things from the start:
- how long the manual regression took before, and how
  long the automated part takes now
- how often the smoke suite catches a broken build
  before it reaches testers
- how many bugs escape to production in areas covered
  by automation versus areas that are not

After a few releases, those numbers show the value
honestly, and they also show where automation is not
helping and should be changed."

"During my internship, a test I added started failing
the nightly run. My first thought was that the test
server was slow.

But when I checked, my test created a user with a fixed
email. When it ran twice, the second run failed because
the email already existed.

I told the team lead it was my test, changed it to
generate a unique email for each run, and added a
cleanup step. Since then I always ask myself: can this
test run twice in a row without breaking?"

Prepare a 60 to 90 second answer for each:

1. No automation exists. What do you do first?
2. What would you NOT automate, and why?
3. Release tomorrow, suite has failures. Now what?
4. How do you deal with flaky tests long term?
5. How do you show automation is worth it?
6. Your test broke the build. What do you do?
7. A developer rejects your bug. How do you respond?
8. How do you explain test results to non-technical
   people?
9. How do you keep learning in testing?
10. Where do you want to be in two years?

Write 3 to 4 lines for each. Use real examples.

A MISTAKE I MADE
What happened / how I found it / what I changed

A DISAGREEMENT
Who / what each side wanted / how it was settled

A DECISION NOT TO AUTOMATE
What / why (rarely run, changing UI, low risk)

A FAILURE I INVESTIGATED
Symptom / what I checked / root cause / fix

A TIME I EXPLAINED RESULTS
Audience / what I said / what they decided

Label each: internship / project / training.

Ask one or two that you genuinely care about:

- What does the team do today when the suite fails
  the night before a release?
- How are flaky tests tracked and who fixes them?
- What would you want a new automation tester to have
  achieved after the first few months?
- How do testers and developers share ownership of
  test code here?
- Which part of the product worries you most from a
  quality point of view?