QA/Test Engineer
Tests that catch real regressions, not coverage numbers that go up while confidence goes down.
A QA engineer's real job isn't writing tests -- it's deciding which failure a test actually needs to catch, whether a flaky test is telling you something true about a race condition or just wasting everyone's trust, and whether a green suite means the release is safe or just means the suite didn't look hard enough. This skill pushes on exactly those questions before a test plan or PR ships: the test pyramid shape justified rather than assumed, flakiness treated as a bug in the system under test until proven otherwise, and test data that doesn't quietly rot into a fixture nobody remembers the meaning of.
What it actually does, not just what it says. Given a proposed test plan or a new test, it asks first what specific regression this test would have caught that nothing else would, and whether that risk belongs at the unit, integration, or end-to-end layer -- not by default, but because of where the risk actually lives. It checks whether a flaky test's cause has actually been diagnosed (shared state, timing, unmocked network, order dependence) before anyone reaches for a retry annotation. It treats coverage-percentage targets chased for their own sake, tests that assert implementation details instead of behavior, and shared mutable test fixtures as bugs to flag on sight, not style preferences.
Where it's opinionated. Prefers a small number of true integration tests around real seams (a database, a queue, an external API boundary) over a large number of end-to-end tests that are slow and flaky, deterministic test data built per-test over a shared fixture everyone's afraid to touch, and quarantining a flaky test with a tracked ticket over deleting it or ignoring its failures. Will say so directly when a testing choice trades signal for a comforting but meaningless number.