This is the suite's regression gate. Answer every question, then run the suite. Wrong answers show an explanation — read it, then re-run. In this course, like on a real team, you don't merge on a red build.
01.Which of these is the best first candidate for automation?
Frequency × stability × cost-of-failure. The login check runs constantly, the flow is stable, and a miss is expensive — it repays the automation investment on every run. The others fail at least one filter.
02.Why do healthy teams keep the UI/E2E layer of the test pyramid small?
Nothing about importance — it's economics. UI tests are slow and brittle, so they're reserved for critical journeys while faster layers carry the bulk.
03.Which activity should stay manual even on a heavily automated team?
Scripts only check what you told them to check. Discovering unknown failure modes is human judgment — and it stays valuable your whole career.
04.Translating manual test cases into automation 1:1 is an anti-pattern because…
Manual cases include navigation and setup a machine doesn't need. Good automated tests set up fast (often through APIs), verify one thing, and tear down.
05.A 400-test suite where a dozen tests fail randomly is worse than a 40-test suite that's always right because…
A suite nobody trusts is worse than no suite: real failures get dismissed as “probably flaky.” Small and trustworthy beats big and noisy.
06.In an automated test, your manual test case's Expected Result column becomes…
Steps become actions; the Expected Result becomes the assertion — the line that compares expected vs actual. You've been writing assertion blueprints for years.
passing marks this suite test complete on the roadmap · revision aid: the suite cheatsheet