Test Slicing & Impact Analysis in Actions

Optimizing GitHub Actions for Agent PRs: Speculative Test Slicing and AST Impact Analysis

SitePoint TeamPublished inProgramming·DevOps·
September 22, 2026

The AI briefing for Developers

Stay up to date with AI tools, model releases, and developer workflows that matter.

Weekly. Free. One click to leave.

SitePoint Premium
Stay Relevant and Grow Your Career in Tech

• Premium Results
• Publish articles on SitePoint
• Daily curated jobs
• Learning Paths
• Discounts to dev tools

7 Day Free Trial. Cancel Anytime.

Coding agents produce pull requests at a fundamentally different cadence than human developers, and traditional CI strategies that execute the full test suite on every pull request event become unsustainable. This guide walks through a two-part solution: a TypeScript CLI that performs AST-level change-impact analysis using ts-morph, paired with a speculative test-slicing strategy implemented as a reusable GitHub Actions workflow.

How to Optimize GitHub Actions for Agent PRs with Speculative Test Slicing

1. Diagnose CI saturation by reviewing merge queue depth, runner billing, and p95 wait times for agent-authored PRs.
2. Scaffold the AST impact-analysis CLI using ts-morph, commander, and fast-glob inside a vendored tools/ast-impact-cli/ directory.
3. Extract changed exported symbols from diff-touched files by walking each file’s AST with ts-morph’s getExportedDeclarations.
4. Resolve the reverse dependency graph transitively using findReferencesAsNodes, capping traversal depth to prevent barrel-file explosion.
5. Map impacted source files to their co-located or glob-matched test files, falling back to full-suite execution when no match exists.
6. Configure a two-job GitHub Actions workflow: a blocking speculative-slice job and a non-blocking deferred full-suite verification job.
7. Validate accuracy by comparing speculative pass/fail results against full-suite outcomes over a two-week window, targeting a false-negative rate below 2%.
8. Harden the pipeline with a critical-paths.json allowlist, tsconfig integrity checks, and concurrency controls to cancel superseded runs.

Table of Contents

The CI Tax of Autonomous Coding Agents

How Agent PR Patterns Differ from Human PR Patterns

Coding agents like Copilot Workspace, Devin, and SWE-Agent produce pull requests at a fundamentally different cadence than human developers. Where a developer might open two to five PRs per day, an autonomous agent working across a monorepo can generate 10 to 50 PRs daily (based on observed patterns across teams running multiple agents concurrently), each targeting a narrow slice of the codebase. These diffs tend to be small (often a single function signature change or a localized refactor), but agents iterate rapidly, frequently pushing follow-up commits and triggering auto-rebase behavior against the main branch. Each push event fires a fresh CI run.

Traditional CI strategies that execute the full test suite on every pull request event become unsustainable at this cadence. A 500-file TypeScript monorepo with 4,000 tests might take 18 minutes per run on a standard GitHub-hosted Linux runner. Multiply that by 30 agent PRs per day, each averaging two to three synchronize events from rebases, and the result is 1,600+ runner minutes consumed daily by agent-authored PRs alone once setup overhead, queue wait, and rebase retries are included. Merge queues back up, human developers wait, and billing climbs.

Traditional CI strategies that execute the full test suite on every pull request event become unsustainable at this cadence.

What This Guide Delivers

This guide walks through a two-part solution designed for these agent PR patterns: a TypeScript CLI that performs AST-level change-impact analysis using ts-morph, paired with a speculative test-slicing strategy implemented as a reusable GitHub Actions workflow. Together, these components identify the minimal set of tests affected by a given diff and run only those tests as the blocking CI check, while a full-suite verification runs asynchronously in the background.

Prerequisites: intermediate-to-advanced GitHub Actions knowledge, a TypeScript codebase (monorepo or single-repo) using Vitest, Node.js 20.x, and basic familiarity with abstract syntax tree concepts. The CLI source must be vendored into your repository at tools/ast-impact-cli/ (the path is configurable via the workflow YAML). A root-level tsconfig.json (or a dedicated tsconfig.all.json) must include all source and test directories so that ts-morph’s language service can resolve references across the full project.

Diagnosing CI Pipeline Saturation from Agent PRs

Symptoms: Queue Depth, Runner Billing, and Developer Friction

The first indicators of agent-driven CI saturation appear in merge queue metrics. A healthy queue typically shows fewer than three pending workflow runs at any time. When agents are active, that number can spike to 15 or more, with p95 queue wait times climbing from under 5 minutes to 30+ minutes. Blocked merges and stale review cycles follow quickly.

Cost signals are equally telling. Runner minutes trending upward week-over-week, particularly on GitHub-hosted runners at $0.008/minute for Linux, translate directly to budget pressure. A team seeing 1,600 daily runner minutes from agent PRs is spending roughly $384/month on CI for changes that touch, on average, fewer than five files per PR.

Root Cause: Full Suite Execution on Narrow Diffs

An agent changes one utility function in src/utils/formatDate.ts. The CI pipeline runs all 4,000 tests. Only 12 of those tests actually import or transitively depend on formatDate. The remaining 3,988 test executions are wasted compute.

Label-based filtering (paths filters in GitHub Actions, or manual labels) is too coarse-grained for agent diffs. A paths filter matching src/utils/** might still trigger hundreds of irrelevant tests. Agents also do not reliably apply labels, and adding label-management logic to agent workflows introduces its own maintenance burden.

Architectural Overview: AST Impact Analysis + Speculative Test Slicing

How the Pieces Fit Together

The pipeline follows a deterministic flow: PR opened or synchronized triggers diff extractionST impact-analysis CLI, which parses each changed file, identifies modified exported symbols, resolves the reverse dependency graph across the repository, and maps impactedes execute in the blocking CI job

The term “speculative” in speculative test slicing refers to a deliberate architectural choice: the predicted minimal test set runs immediately as the required status check, while a full-suite verification is queued as a separate, non-blocking job at lower concurrency priority. If the speculative slice passes, the PR is eligible to merge. If the full suite later reveals a failure the slice missed, a re-review label is applied and the team is notified. This two-layer approach trades a small false-negative risk for an ~81% reduction in queue wait time and runner cost (see Benchmarks below).

This two-layer approach trades a small false-negative risk for an ~81% reduction in queue wait time and runner cost.

Building the AST Impact-Analysis CLI in TypeScript

Project Scaffolding and Dependencies

The CLI relies on four key dependencies. ts-morph provides a high-level wrapper around the TypeScript compiler API, offering structured AST traversal with type-checker integration. For TypeScript-heavy codebases, ts-morph is preferred over the raw Babel parser because Babel parses TypeScript syntax but does not perform cross-file type resolution, so type aliases, interface hierarchies, and const enum values cannot be followed transitively. For JS/JSX-dominant repositories, @babel/parser with @babel/traverse remains a viable alternative, though cross-file reference resolution depth is reduced without a type-checker. commander handles CLI argument parsing, fast-glob enables efficient file discovery, and minimatch matches changed files against the critical-paths configuration.

{"name":"ast-impact-cli","version":"1.0.0","type":"module","bin":{"ast-impact":"./dist/cli.js"},"dependencies":{"ts-morph":"22.0.0","commander":"^12.1.0","fast-glob":"^3.3.2","minimatch":"^9.0.0"},"devDependencies":{"typescript":"^5.4.0"},"scripts":{"build":"tsc","start":"node dist/cli.js"}}

Parsing the Diff: Extracting Changed Symbols

The CLI accepts a list of changed file paths (piped from git diff --name-only or passed as arguments) and uses ts-morph to identify which exported symbols within those files were added, modified, or removed. The key mechanism is loading only the changed files into a ts-morph Project alongside the full tsconfig.json, then walking each file’s AST to collect exported declarations.

The function takes the Project instance as a parameter instead of constructing one internally. This avoids initializing multiple Project instances, which would double the startup cost on large repositories.

import{ Project, SyntaxKind }from"ts-morph";importtype{ SourceFile }from"ts-morph";exportinterfaceChangedSymbol{name:string;filePath:string;kind:string;}exportfunctionextractChangedSymbols(changedFilePaths:string[],project: Project): Map<string, ChangedSymbol>{const changedSymbols =newMap<string, ChangedSymbol>();for(const filePath of changedFilePaths){const sourceFile = project.getSourceFile(filePath);if(!sourceFile)continue;const exportedDeclarations = sourceFile.getExportedDeclarations();for(const[name, declarations]of exportedDeclarations){const key =`${sourceFile.getFilePath()}::${name}`;if(changedSymbols.has(key))continue;for(const decl of declarations){changedSymbols.set(key,{name,filePath: sourceFile.getFilePath(),kind: decl.getKindName(),});break;}}}return changedSymbols;}

This function returns every exported symbol from the changed files, deduplicated by a composite key of file path and symbol name. In a more refined implementation, the CLI could compare against the base branch’s AST to detect only symbols whose signatures or bodies actually changed, but for agent PRs with narrow diffs, treating all exports from changed files as impacted provides a practical and fast approximation.

Resolving the Reverse Dependency Graph

With the changed symbols identified, the next step walks outward through the codebase to find every file that imports or references those symbols, transitively. The ts-morph findReferencesAsNodes method uses the TypeScript language service to resolve references across the entire project, including through type-only imports and interface implementations.

Ensure the tsconfig.json passed to the CLI includes allves exclude restrictions gives the CLI complete reference resolution. If test directories are excluded from the tsconfig, findReferencesAsNodes will return no results for references into those directories, causing silent under-selection

A depth cap (configurable, default 3 hops) prevents barrel-file explosion from silently degrading to full-suite semantics. When the traversal exceeds the maximum hop count, the CLI conservatively falls back to __FULL_SUITE__.

import{ Project }from"ts-morph";importtype{ SourceFile }from"ts-morph";importtype{ ChangedSymbol }from"./extract.js";exportfunctionresolveImpactedFiles(changedSymbols: Map<string, ChangedSymbol>,project: Project,maxHops =3): Set<string>{const impactedFiles =newSet<string>();const byFile =newMap<string,string[]>();for(const sym of changedSymbols.values()){const names = byFile.get(sym.filePath)??[];names.push(sym.name);byFile.set(sym.filePath, names);}for(const[filePath, names]of byFile){const sourceFile = project.getSourceFile(filePath);if(!sourceFile)continue;impactedFiles.add(filePath);const exportMap = sourceFile.getExportedDeclarations();for(const name of names){const exportedDecl = exportMap.get(name);if(!exportedDecl || exportedDecl.length ===0)continue;const visited =newSet<string>();const queue:Array<{ node:typeof exportedDecl[0]; hop:number}>=exportedDecl.map((d)=>({ node: d, hop:0}));while(queue.length >0){const item = queue.shift()!;if(item.hop >= maxHops){impactedFiles.add("__FULL_SUITE__");continue;}const references = item.node.findReferencesAsNodes();for(const ref of references){const refPath = ref.getSourceFile().getFilePath();if(visited.has(refPath))continue;visited.add(refPath);impactedFiles.add(refPath);}}}}return impactedFiles;}

Handling Dynamic Imports, Re-exports, and Barrel Files

Several edge cases inflate or distort the impact set. export * re-exports in barrel files (typically index.ts) cause every consumer of the barrel to appear as impacted, even if they only use unrelated exports. The TypeScript language service’s reference finder does not always resolve lazy import() expressions, which can cause under-selection.

The recommended heuristic: if a barrel file is impacted, include all its direct consumers but cap transitive depth (the maxHops parameter in resolveImpactedFiles controls this, defaulting to 3) to avoid degrading back to a full suite. For dynamic imports, the CLI should maintain a static mapping of known lazy-loaded entry points that always trigger their associated test files.

Mapping Impacted

The final step maps impactedd approach assumes co-located tests: src/utils/formatDate.ts maps to src/utils/formatDate.test.ts. For repositories with separate test directories, a configurable glob pattern handles the translation. When no test file is found for an impactedse negatives

Before performing AST analysis, the CLI checks changed files against a critical-paths.json allowlist. If any critical path is touched, the CLI immediately falls back to __FULL_SUITE__.

import{ program }from"commander";import fg from"fast-glob";import{ readFileSync, existsSync }from"fs";import{ minimatch }from"minimatch";import{ extractChangedSymbols }from"./extract.js";import{ resolveImpactedFiles }from"./resolve.js";import{ Project }from"ts-morph";exportasyncfunctionmapToTestFiles(impactedFiles: Set<string>,testGlob:string):Promise<string[]>{let allTests:string[];try{allTests =awaitfg(testGlob);}catch(err){process.stderr.write(`[ast-impact-cli] Failed to expand test glob "${testGlob}":${err}`);return["__FULL_SUITE__"];}if(impactedFiles.has("__FULL_SUITE__")){return["__FULL_SUITE__"];}const testSet =newSet(allTests);const matched:string[]=[];for(const srcFile of impactedFiles){const testFile = srcFile.replace(/.ts$/,".test.ts");if(testSet.has(testFile)){matched.push(testFile);}}return matched.length >0? matched :["__FULL_SUITE__"];}functiontouchesCriticalPaths(changedFiles:string[],criticalPathsFile:string):boolean{if(!existsSync(criticalPathsFile))returnfalse;let patterns:string[];try{patterns =JSON.parse(readFileSync(criticalPathsFile,"utf8"));}catch{process.stderr.write(`[ast-impact-cli] Could not parse${criticalPathsFile}; defaulting to full suite`);returntrue;}return changedFiles.some((f)=>patterns.some((p)=>minimatch(f, p,{ matchBase:true})));}program.argument("<files...>","Changed file paths").option("--tsconfig <path>","Path to tsconfig.json","./tsconfig.json").option("--test-glob <pattern>","Glob for test files","src/**/*.test.ts").option("--critical-paths <path>","Path to critical-paths.json","./critical-paths.json").action(async(files:string[], opts)=>{if(opts.tsconfig.includes("..")|| opts.testGlob.includes("..")){process.stderr.write("[ast-impact-cli] Refusing path with'..'");process.exit(1);}if(touchesCriticalPaths(files, opts.criticalPaths)){process.stdout.write("__FULL_SUITE__");return;}const project =newProject({ tsConfigFilePath: opts.tsconfig });const symbols =extractChangedSymbols(files, project);const impacted =resolveImpactedFiles(symbols, project);const tests =awaitmapToTestFiles(impacted, opts.testGlob);process.stdout.write(tests.join("") + "");});program.parse(process.argv);

When the output contains __FULL_SUITE__, the calling workflow knows to fall back to running all tests rather than risk missing coverage.

Implementing Speculative Test Slicing in GitHub Actions

Workflow Design: Speculative Fast Path + Deferred Full Verification

The workflow uses two jobs. The impact-tests job is the required status check, running only the affected tests identified by the CLI. It blocks merge until it passes. The full-suite-verify job runs the complete test suite at lower concurrency priority and is non-blocking. If the full suite reveals a failure that the speculative slice missed, a label is applied to the PR prompting re-review.

For agent PRs, the speculative job provides high confidence for merge gating because the diffs are narrow and the AST-based mapping covers the most common dependency patterns. The deferred job catches failures the slice missed, covering the rare cases where the impact analysis under-selects. Human (non-agent) PRs always run the full suite in both jobs.

name: Speculative Test Slicingon:pull_request:types:[opened, synchronize]permissions:contents: readpull-requests: writejobs:impact-tests:runs-on: ubuntu-latestoutputs:test-files: ${{ steps.analyze.outputs.tests }}steps:-uses: actions/checkout@v4with:fetch-depth:0-uses: actions/setup-node@v4with:node-version:20-name: Install root dependenciesrun: npm ci-name: Detect agent-authored PRid: detect-agentrun:|AUTHOR="${{ github.event.pull_request.user.login }}"# Pattern list is illustrative; maintain a repository variable# AGENT_AUTHOR_PATTERNS for production use.IS_AGENT=falsecase "$AUTHOR" in*'[bot]'*|devin-ai*|copilot*)IS_AGENT=true;;esacecho "is_agent=$IS_AGENT" >> "$GITHUB_OUTPUT"-name: Install AST CLIif: steps.detect-agent.outputs.is_agent == 'true'run:|cd tools/ast-impact-cli && npm ci && npm run build-name: Validate tsconfig integrityif: steps.detect-agent.outputs.is_agent == 'true'id: tsconfig-checkrun:|if git diff origin/${{ github.base_ref }}...HEAD --quiet -- tsconfig.json; thenecho "tsconfig unchanged"elseecho "::warning::tsconfig.json was modified; falling back to full suite"echo "tests=__FULL_SUITE__" >> "$GITHUB_OUTPUT"exit 0fi-name: Analyze changed filesif: steps.detect-agent.outputs.is_agent == 'true' && steps.tsconfig-check.outputs.tests != '__FULL_SUITE__'id: analyzerun:|# Use NUL-delimited output and pass via temp file to avoid shell injection.git diff --name-only -z origin/${{ github.base_ref }}...HEAD -- '*.ts' '*.tsx' > /tmp/changed_files.txtif [!-s /tmp/changed_files.txt ]; thenecho "tests=__FULL_SUITE__" >> "$GITHUB_OUTPUT"elseTESTS=$(xargs -0 node tools/ast-impact-cli/dist/cli.js < /tmp/changed_files.txt){echo "tests<<EOF_TESTS"echo "$TESTS"echo "EOF_TESTS"}>> "$GITHUB_OUTPUT"fi-name: Run affected testsrun:|TESTS="${{ steps.tsconfig-check.outputs.tests || steps.analyze.outputs.tests || '__FULL_SUITE__' }}"# Treat empty output as full-suite fallback.if [ -z "$TESTS" ] || [ "$TESTS" = "__FULL_SUITE__" ]; thenecho "Running full test suite (non-agent PR or fallback)"npx vitest runelse# Write test paths to a file to avoid word-splitting and injection.echo "$TESTS" > /tmp/test_files.txt# Use xargs with -d '' to pass each path as a separate argument.xargs -d '' npx vitest run < /tmp/test_files.txtfifull-suite-verify:runs-on: ubuntu-latestneeds: impact-testsif: always()concurrency:group: full-suite-${{ github.head_ref }}cancel-in-progress:falsesteps:-uses: actions/checkout@v4-uses: actions/setup-node@v4with:node-version:20-run: npm ci-name: Run full test suiterun: npx vitest run-name: Label on failureif: failure()continue-on-error:truerun:|# Ensure label exists before attempting to apply it.gh label create "full-suite-failure" --color "d73a4a" --description "Full suite caught a miss" --repo "${{ github.repository }}" 2>/dev/null || truegh pr edit "${{ github.event.number }}" --add-label "full-suite-failure" --repo "${{ github.repository }}"env:GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Note on cancel-in-progress: The full-suite-verify job uses cancel-in-progress: false to ensure that a superseding push does not silently discard a failing full-suite run. If the full suite is 95% complete when a new push arrives, the result is still recorded and the failure label is applied. This is a deliberate trade-off favoring safety over runner savings in the verification layer.

Concurrency Controls and Merge Queue Integration

Agent rebase loops are the single largestnize events within 60 seconds, three CI runs fire. Only the last one matters. The concurrency key, grouped by github.head_ref, ensures that superseded runs are canceled immediately

concurrency:group: agent-ci-${{ github.head_ref }}cancel-in-progress:true

Branch protection configuration should require only the impact-tests check for merge eligibility. This can be setires the full protection object:

gh api repos/{owner}/{repo}/branches/main/protection --method PUT --input - <<'EOF'{"required_status_checks": {"strict": true,"contexts": ["impact-tests"]},"enforce_admins": true,"required_pull_request_reviews": {},"restrictions": null}EOF

This ensures the merge queue does not wait for the non-blocking full-suite-verify job.

Caching the AST Dependency Graph Between Runs

Initializing a ts-morph Project from scratch on a 500-file repo takes 12 seconds (observed on a GitHub-hosted ubuntu-latest 2-core runner; actual times vary with repo size and runner specs). ts-morph does not provide a built-in serialization API for the Project object. You can cache the computed impact graph as .ast-cache/impact-graph.json, keyed by file hash. The ts-morph Project itself must still be re-initialized on each run, but graph traversal can be skipped for unchanged files, reducing end-to-end analysis time.

The cache key should incorporate the TypeScript configuration and the dependency manifest to invalidate correctly when the dependency structure changes, while avoiding over-invalidation on every

-name: Cache AST impact graphuses: actions/cache@v4with:path: tools/ast-impact-cli/.ast-cachekey: ast-graph-${{ hashFiles('tsconfig.json','package-lock.json', 'tools/ast-impact-cli/package-lock.json') }}restore-keys:|ast-graph-

The CLI needs a modification to write and read from the .ast-cache directory: after computing the impact graph cached graph and skip recomputation for files whose content hashes have not changed

Benchmarks and Results

Before vs. After: Runner Minutes, Queue Wait, and Cost

This table shows metrics from a 500-file TypeScript monorepo generating approximately 30 agent PRs per day, each averaging 2.5 synchronize events from rebases. The “Before” daily minutes include CI execution time plus estimated setup and queue overhead. Runner costs assume GitHub-hosted Linux runners at $0.008/minute.

The full-suite-verify job adds some overhead, but because it runs at lower concurrency and is not canceled on superseding pushes (to preserve failure signals), its incremental cost is approximately 15% of the pre-optimization baseline.

Confidence and False-Negative Rate

The speculative approach works only if the impact analysis reliably selects all relevant tests. To validate, compare the speculative slice’s pass/fail result against the deferred full-suite result for every agent PR over a two-week window. Target a false-negative rate below 2%, meaning fewer than 2 in 100 agent PRs should have a speculative pass followed by a full-suite failure.

If the observed rate exceeds 2%, the most common causes are config file changes not captured by AST analysis, global type augmentations, or untracked side effects. To diagnose which cause applies, diff the full-suite failure log against the speculative file list: files that failed but were absent from the slice reveal whether the gap is a missing config trigger, an untracked global type, or a side-effect dependency. At that point, widen the impact set or fall back to full-suite execution for the relevant change categories.

Edge Cases, Limitations, and Hardening

When AST Analysis Under-Selects Tests

The AST CLI operates on TypeScriptn (which can alter compilation behavior and type resolution), .env files (which affect runtime behavior), or CSS module side effects that modify component rendering. Global type augmentations in *.d.ts files can silently change type-checking results across the entire project without appearing in the import graph

The safeguard is a critical-paths.json allowlist: a manually maintained JSON file listing paths that, when changed, always trigger the full test suite. Entries like tsconfig.json, jest.config.ts, vitest.config.ts, and src/types/global.d.ts belong here by default. The schema is a flat array of glob patterns:

["tsconfig.json","vitest.config.ts","src/types/global.d.ts",".env*"]

Before performing AST analysis, the CLI checks the diff against this list and falls back to __FULL_SUITE__ if any critical path is touched.

Non-TypeScript Assets and Polyglot Repos

For monorepos containing Python, Go, or plain JavaScript alongside TypeScript, the AST CLI covers only the TypeScript surface. Swap in @babel/parser with the typescript and jsx plugins to cover JavaScript and JSX files, though Babel does not provide the type-checker integration that makes ts-morph’s reference resolution work. For Python, tools like modulefinder or importlab can produce Python import graphs suitable for programmatic CI impact analysis; pydeps is a visualization tool and import-linter enforces rules rather than computing reverse dependency graphs. For Go, the go/packages standard library API provides import graph resolution. Each language requires its own impact-analysis implementation, but the speculative slicing workflow pattern in GitHub Actions remains the same.

Security Considerations for Agent-Authored PRs

The AST CLI parses but does not execute code from the diff. However, if the CLI is invoked in a context where ts-morph triggers TypeScript’s type-checker, and the diff introduces a malicious tsconfig.json that modifies paths to resolve imports from unexpected locations, a malicious tsconfig.json could redirect which files the CLI loads. This is a hypothetical risk that has not been reproduced in practice, but the attack surface exists. The workflow above includes a Validate tsconfig integrity step that checks whether tsconfig.json was modified in the PR diff and falls back to the full suite if so. The CLI also validates that --tsconfig and --test-glob paths do not contain .. to prevent path traversal. Additionally, sandboxing the CLI execution in a container with read-only filesystem access to the repository checkout further mitigates this risk.

The workflow above includes a Validate tsconfig integrity step that checks whether tsconfig.json was modified in the PR diff and falls back to the full suite if so.

Next Steps and Further Optimization

The two-layer strategy of AST impact analysis for precision and speculative slicing for speed addresses the immediate pain of agent-driven CI saturation. Teams running this in production should consider two follow-up investments: extending the impact-analysis approach to additional languages in a polyglot monorepo (preventing the optimization from applying to only a fraction of agent PRs), and packaging the CLI and workflow as a published GitHub Action or reusable workflow to make the tooling available across organizations without duplicating code.

The complete workflow YAML and TypeScript CLIon into a standalone repository. Teams can fork, configure the critical-paths.json and test glob patterns for their codebase, and begin measuring false-negative rates within a single sprint

Sharing our passion for building incredible internet things.