The latest articles on DEV Community by QA Debug Lab (@qadebuglab). https://dev.to/qadebuglab https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4203209%2Fa7c4c53e-8f0c-4bce-8bfe-1f5977199f6a.png https://dev.to/qadebuglab en QA Debug Lab Fri, 23 Oct 2026 18:13:13 +0000 https://dev.to/qadebuglab/i-turned-the-most-common-causes-of-flaky-tests-into-3-debugging-exercises-free-sample-inside-31aj https://dev.to/qadebuglab/i-turned-the-most-common-causes-of-flaky-tests-into-3-debugging-exercises-free-sample-inside-31aj <p>I've done a lot of QA automation interviews on both sides of the table. The best signal I ever got from a candidate was not a Q&amp;A answer. It was watching them open a broken suite and work out why it was broken.</p> <p>So I built a few small practice projects for that. Each one is a tiny app plus a Playwright suite with several seeded problems. Some are test bugs, some are config bugs, and some are real bugs in the app that the tests were right about. Part of the exercise is deciding which is which.</p> <h2> A few of the seeded problems </h2> <ul> <li>A test that passes forever because it calls <code>/account</code> instead of <code>/accounts</code> and asserts "status is not 200"</li> <li>A coupon test that passes every day until the coupon expires, then fails with no code change</li> <li>A date check that breaks every evening in New York, because the test uses local time and the API uses UTC</li> <li>A leftover <code>test.only</code>, so CI is green and runs exactly one test</li> <li> <code>waitForResponse</code> registered after the click, so the delete test races</li> <li>Two same-key requests that both move money, because the idempotency key is saved after the first <code>await</code> </li> </ul> <h2> Why this format </h2> <p>Interview Q&amp;A lists test recall. A broken suite tests judgment: reading a failure, forming a hypothesis, and proving it. A green test that cannot fail is worse than a red one, and spotting those is a skill you can practice.</p> <p>You can use these on your own, or as a take-home or live pairing exercise when you interview candidates.</p> <h2> Try the first one free </h2> <p>Exercise 1 is free. It is a small task-manager app with a Playwright suite that has seeded problems. There is no answer key in the free pack, so you work it out yourself: <a href="https://qadebuglab.gumroad.com/l/zmtsv" rel="noopener noreferrer">download the free sample</a>. Gumroad asks for an email at checkout.</p> <p>I'd like to know if the difficulty is right.</p> <h2> Two questions for you </h2> <ol> <li>What's the nastiest seeded bug you've seen, or would put in an exercise like this?</li> <li>Would you want this for yourself, for interviewing candidates, or both?</li> </ol> <p><em>Disclosure: I'm the author of these exercises, and the full set (3 projects, 24 bugs, solutions and rubrics) is a paid kit under the QA Debug Lab name.</em></p> qa testing playwright career