Staff Quality Engineer - Exploratory Test Lead

ABOUT BESTOW Life insurance is one of the world's most important products. It's also one of the hardest to build, distribute, and modernize. Bestow exists to change that. Bestow is a leading vertical technology platform serving some of the largest and most innovative life insurers. Our platform unifies the fragmented, legacy value chain, enabling carriers to launch products in weeks instead of years. Carriers choose us to scale and operate at unprecedented speed, powered by AI and automation. Bestow isn't selling policies. We're building the infrastructure that helps an entire industry move faster, reach more people, and deliver on its promise. Backed by leading investors (Goldman Sachs, Hedosophia, NEA, Valar, 8VC) and trusted by major carriers, Bestow is powered by a team that moves with precision, purpose, and heart. If you want to help reimagine a centuries-old industry with lasting impact, join us. Bestow offers flexible remote/hybrid work, meaningful benefits, equity, and substantial growth opportunities. Bestow uses E-Verify to confirm the employment eligibility of all newly hired employees. To learn more about E-Verify, including your rights and responsibilities, please visit E-Verify.gov http://e-verify.gov. ABOUT THE TEAM Bestow's Quality Engineering organization is building the verification backbone for an AI-enabled software development lifecycle: specification-driven development, Definition-of-Ready enforcement, requirements-to-test traceability, and a growing non-functional verification stack. We are not a downstream test team. We shape how software is defined, not only how it is checked. ABOUT THE ROLE This Staff Quality Engineer role is embedded first within Bestow Innovation Lab https://www.bestow.com/intelligence#:~:text=IN%20R%26D-,Innovation%20Lab, the R&D group that invents the next generation of our platform and then scales the practice across Engineering. You will work alongside domain experts and researchers, product engineering teams, Platform Engineers, Technical Program Management, Compliance, and the rest of the Quality Engineering team. This role reports to the Director of Quality and is open to Remote (US). HOW WE THINK ABOUT TESTING We are stating this explicitly so you can tell whether this is your kind of job. - Test automation and automated checks confirm what we already knew to ask, but they cannot tell us whether we asked the right questions. - Testing is the process of evaluating a product by learning about it through exploration and experimentation; questioning, modeling, observation, inference, and yes, output checking. - We distinguish testing from checking. A check applies a decision rule to an observation and reports the outcome. Checks are enormously valuable and we invest heavily in them. They are also incapable of noticing anything they were not told to notice, which is why they cannot substitute for a person who is trying to find out what is true. - Tools extend the tester. We expect you to build and use tools, including but not limited to AI technologies, aggressively for a wide variety of things including data generation, state manipulation, differential comparison, log and trace analysis, oracle construction. "Automated" and "manual" is not a distinction we find useful. - Testers inform decisions; they do not own quality. Our Quality Engineering team’s north star is to give the people accountable for a release the clearest possible account of the product and its risks, including an honest account of what was not examined. The decision is theirs. Making it well-informed is ours. - Risk analysis is an argument, not arithmetic. We want risk stated as a specific failure story that our colleagues can inspect and dispute, not as a number that ends the conversation. - We are careful about what we claim. "So far I haven't found a problem here" and "this area is fine" are very different statements. In a regulated business the difference eventually matters to someone outside the company. WHAT YOU’LL DO Testing, Embedded in Labs / R&D (~40%) - Embed with Labs / R&D through invention and specification, developing a model of the product as it is being conceived, capturing risks and questions as they form before they become code. - Design and execute chartered, time-boxed testing sessions. Through structured debriefs, teams capture vital learnings, refine session charters, and validate the return on testing efforts. - Investigate critical failure modes that structural checks cannot catch: multi-tenant isolation, configuration interaction, concurrency and lifecycle state transitions, integration timing, operability and observability gaps, and long-horizon temporal behavior such as renewals, lapses, and mid-term endorsements. - Model risk using the Heuristic Test Strategy Model and related approaches; product elements (structure, function, data, interfaces, platform, operations, time), quality criteria, and risk heuristics and maintain a living risk catalogue across policy lifecycle, claims, partner integrations, and regulatory workflows. Each significant risk is written as a failure story: what could go wrong, who it would harm, why you believe it is plausible. - Report findings in four distinct kinds, because they need four different responses: - Bugs — anything about the product that threatens its value. Filed with severity, priority, and the investigative context in which you found them. - Risks — plausible failure stories not yet demonstrated. They become charters. - Questions about intent — missing, ambiguous, or contradictory rules. These go back to specification before more testing happens. - Obstacles to testing — testability limits, missing observability, environments that lie, tools you don't have. In an R&D context this is often the most valuable category, and it is the one most organizations never collect. - Maintain a coverage and testability map: what we have examined, with respect to what model of the product, and where we currently cannot see. The blank regions are the point. - Practice bug advocacy. Finding a problem is half the work; getting an important problem understood and fixed by people who are proud of what they built is the other half, and it is harder. Specification & Risk Engagement (~25%) - Partner with Product, Labs, and Engineering in Example Mapping and Specification-by-Example workshops, using what you learn from testing to sharpen "Definition of Ready" in surfacing missing rules, unexamined assumptions, conflicting behaviors, and persona variation. - Bring the oracle question into specification work: how would we know this behavior was wrong? Requirements that cannot be tested against any oracle are not yet requirements. - Analyze and advocate for system testability through deep observability, precise controllability, and trustworthy test oracles. Treat any system that lacks examin-ability as an independent blocker and escalate it as a core defect. - Identify where our automated checks cannot detect a class of failure, and route those to the automation and specification-test backlogs so that what we check keeps improving. - Aim for sufficiency for the decision at hand rather than completeness. No specification is ever complete; the useful question is whether we understand this well enough, for this purpose, given these risks. - Make investigation part of the traceable record, so that our account of what we know is auditable rather than tribal. Tools, Automation & AI Under Test (~15%) - Build and use tools to extend your own reach; data generation, state manipulation, differential and round-trip comparison, log and trace mining, property-based and high-volume techniques, and oracle construction. - Investigate AI-generated code, tests, and agentic workflow output: prompt-to-implementation mismatch, variation across identical inputs, multi-step state consistency and audit-ability, and whether generated tests actually detect regressions we know about. - Use agentic coding tools as a normal part of your own workflow and hold them to the same scrutiny you apply to everything else. - Help the organization read its own dashboards honestly. A green suite is evidence that specific checks passed; it is not evidence of quality, and the gap between those two statements is where trouble accumulates. Coaching, Enablement & Decision Support (~20%) - Build skill in other people through coaching, paired sessions, debriefs, and critique of real work on real products. Support that with artifacts light enough that nobody games them: charter catalogues, session notes conventions, heuristics and oracle references. The artifacts help; the skill is the deliverable. - Coach Quality Engineers, SDETs, engineers, and product managers to model risk, charter their own sessions, take useful notes, and report findings in a way that gets acted on. - Produce the testing story that release and transition decisions are made against — a story about the product, a story about the testing, and a story about the quality of that testing, including what was not examined and what therefore remains unknown. At the Labs → Engineering transition, this is your primary deliverable. The decision belongs to the accountable engineering and business leaders; your job is to make sure they make it with open eyes. - Contribute to release readiness practice, promotion gates, rollback validation, and canary strategy as a source of evidence and risk narrative, not as an approver. - Supply failure hypotheses and scenarios to the non-functional verification stack: performance modeling, resilience and disaster recovery simulation, accessibility, security posture, chaos experiments. - Strengthen how we account for our testing to regulators and auditors. Escalate compliance findings promptly, and be precise about the difference between a demonstrated violation and a possible one. WHO YOU ARE We care much more about demonstrated skill than about years or credentials. Expect to show us your work session notes, a bug report you're proud of, a test strategy you wrote. - 10+ years of demonstrated experience with progressively increasing responsibility, from individual contributor to thought leadership in software testing and test automation. - A serious tester. You investigate products, not just verify them. You have a considered position on how you know something is wrong, and you can teach it. Somewhere around 8+ years of relevant experience usually produces this, but we're hiring the skill, not the number. - Fluent in the craft vocabulary and able to apply it under pressure: modeling, coverage with respect to a model, oracles and their fallibility, heuristics and where each one misleads, chartering, note-taking, test framing, safety language, bug advocacy. If you've come through Rapid Software Testing, BBST, or an equivalent grounding, say so. - Risk-analysis depth. You can walk into an unfamiliar system and produce plausible, specific, arguable failure stories and explain the reasoning well enough that a team can reproduce the thinking without you. - Experience with decision logic and configuration-driven behavior: rules engines, eligibility or underwriting logic, pricing or calculation engines, multi-tenant configuration variation. Systems where the same code produces different answers for different customers. - A track record of finding what green suites miss, and of explaining how you got there. - You have built a capability in an organization that didn't have one as a consultant, a coach, or a practice lead and left it working after you moved on. - Exceptional written communication. Your notes, bug reports, and testing stories will be read by engineers, executives, auditors, and regulators. They need to be clear, honest about uncertainty, and hard to argue with. - Influence without formal authority, and the specific skill…