| |

LangGraph for QA: Building Multi-Step Agent Workflows for Regression Testing

ByPromode

Contents

LangGraph for QA: Building Multi-Step Agent Workflows for Regression Testing

Most regression suites are fragile. I have seen teams spend 40% of their sprint time nursing flaky tests that fail for reasons unrelated to the product. The problem is not the tools. It is the architecture. When every test is a linear script with no memory, no branching logic, and no ability to recover from an intermediate state, you are asking for pain. LangGraph for QA changes that. It lets you build regression testing agents that remember where they are, decide what to do next based on current state, and retry or escalate without human hand-holding. In this guide, I will show you how to build multi-step agent workflows that actually survive a real CI/CD pipeline.

Table of Contents

What Is LangGraph and Why QA Teams Should Care

LangGraph is a low-level orchestration framework built by LangChain. It is not a testing tool. It is a graph-based runtime for building stateful, multi-actor applications with large language models. Think of it as the engine that lets you chain LLM calls, tool invocations, and decision points into a directed graph where each node can read and write shared state.

The numbers are hard to ignore. As of May 2026, the langgraph package on PyPI sits at version 1.2.1, with 32,784 GitHub stars and 5,544 forks. The npm package @langchain/langgraph clocked 9.65 million downloads in the last month alone. Playwright, by comparison, pulled in 219 million npm downloads in the same period with 89,294 GitHub stars. LangGraph is smaller, but it is growing fast because it solves a specific problem: agent orchestration.

For QA teams, that means you can finally move beyond “run this script, hope it passes.” You can build agents that:

  • Inspect the current application state before deciding which test path to take
  • Retry a failed step with adjusted parameters instead of failing the entire suite
  • Branch to a diagnostic subgraph when an assertion fails, collecting logs and screenshots before surfacing a summary
  • Pause for human approval on high-risk operations, then resume automatically

If you are already using LangChain for test documentation agents, LangGraph is the natural next step. LangChain handles the LLM interactions; LangGraph handles the workflow logic.

Real-World QA Use Cases for LangGraph

Before we get to code, here is what I have actually built with LangGraph in the last six months:

  • A regression agent that switches test paths based on the current Git diff. If only the payment service changed, it skips the inventory tests.
  • A visual regression agent that uses an LLM to classify UI diffs into “cosmetic,” “functional,” or “blocking” before deciding whether to fail the build.
  • A data validation agent that checks Kafka topic lag, waits for it to drop below a threshold, then runs downstream assertions.

None of these are possible with a linear pytest script. They require state, branching, and sometimes human input. That is exactly what LangGraph provides.

The Architecture: How Multi-Step Agent Workflows Actually Work

LangGraph models every workflow as a graph. There are three primitives you must understand before writing a single line of code.

Nodes

A node is a Python function (or TypeScript function) that receives the current state, does some work, and returns updates to that state. In a QA context, a node might authenticate a user, navigate to a checkout page, fill a form, or call an LLM to classify a UI anomaly.

Edges

Edges connect nodes. They can be unconditional (“always go from login to dashboard”) or conditional (“if login succeeded, go to dashboard; if it failed, go to the error handler subgraph”). Conditional edges are where the power lives. They let your agent react to runtime conditions instead of following a rigid script.

State and Checkpointers

State is a TypedDict (or interface in TypeScript) that every node reads and writes. It is the shared memory of your agent. A checkpointer saves that state after each step. If your CI runner dies mid-suite, you can resume from the last checkpoint instead of starting over. LangGraph ships with MemorySaver for testing and SqliteSaver or Postgres adapters for production.

Here is the simplest possible graph in Python:

from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END

class QAState(TypedDict):
    url: str
    status: str
    logs: list

def login_node(state: QAState) -> dict:
    # Your Playwright or API login logic here
    return {"status": "authenticated", "logs": ["login OK"]}

def run_tests_node(state: QAState) -> dict:
    if state["status"] != "authenticated":
        return {"status": "skipped", "logs": state["logs"] + ["skipped: not auth"]}
    # Run regression tests
    return {"status": "passed", "logs": state["logs"] + ["tests passed"]}

graph = StateGraph(QAState)
graph.add_node("login", login_node)
graph.add_node("run_tests", run_tests_node)
graph.add_edge(START, "login")
graph.add_edge("login", "run_tests")
graph.add_edge("run_tests", END)

compiled = graph.compile()
result = compiled.invoke({"url": "https://app.example.com", "status": "", "logs": []})
print(result["status"])  # passed

This is trivial, but it illustrates the pattern: state in, state out, edges decide what runs next. In production, your graph will have 8–15 nodes, conditional edges, and subgraphs for error recovery.

Subgraphs and Interrupts

Subgraphs let you package a collection of nodes into a reusable module. In a QA workflow, you might have a “diagnostic subgraph” that runs whenever a test fails. That subgraph collects logs, queries your RAG-based documentation agent, and suggests a root cause before escalating to a human. You define it once and attach it to any failure edge.

Interrupts are another LangGraph superpower. They let your agent pause execution mid-flight and wait for human input. Imagine a node that detects a payment gateway UI change. Instead of blindly continuing, the agent interrupts and asks: “The checkout button moved. Should I proceed with the new selector or abort?” Once you respond, the graph resumes exactly where it left off. This is impossible in a bash script without external polling loops.

Why State Matters More Than You Think

In a traditional test framework, state lives in page objects, environment variables, and global fixtures. It is scattered and implicit. In LangGraph, state is explicit, typed, and versioned. When you add a checkpoint, you get a snapshot of the entire workflow at that moment. You can replay it, debug it, or fork it into a new thread. For regression suites that run against multiple environments, this is a game-saver. I run the same graph against dev, staging, and prod by changing one key in the initial state. The graph structure stays identical.

Building Your First Regression Testing Agent with LangGraph

Let me walk you through a realistic agent I built for a microservices regression suite. The agent must log in, check service health, run API contract tests, run browser smoke tests, and generate a report. If any step fails, it retries once, then escalates to a human.

Step 1: Define the State

from typing_extensions import TypedDict
from typing import Literal

class RegressionState(TypedDict):
    env: str
    token: str
    health_status: Literal["unknown", "healthy", "degraded", "down"]
    api_results: list
    ui_results: list
    report_path: str
    retry_count: int
    final_status: Literal["pending", "passed", "failed", "escalated"]

Step 2: Build the Nodes

import requests

def authenticate(state: RegressionState) -> dict:
    resp = requests.post(
        f"https://{state['env']}.example.com/api/auth",
        json={"client_id": "regression_runner"}
    )
    resp.raise_for_status()
    return {"token": resp.json()["access_token"]}

def health_check(state: RegressionState) -> dict:
    resp = requests.get(
        f"https://{state['env']}.example.com/api/health",
        headers={"Authorization": f"Bearer {state['token']}"}
    )
    if resp.status_code == 200 and resp.json().get("status") == "ok":
        return {"health_status": "healthy"}
    return {"health_status": "degraded"}

def run_api_tests(state: RegressionState) -> dict:
    # Invoke your existing pytest API suite here
    results = [{"test": "user_crud", "status": "passed"}]
    return {"api_results": results}

def run_ui_tests(state: RegressionState) -> dict:
    # Invoke Playwright tests here
    results = [{"test": "checkout_flow", "status": "passed"}]
    return {"ui_results": results}

def generate_report(state: RegressionState) -> dict:
    path = f"/tmp/report_{state['env']}.json"
    with open(path, "w") as f:
        import json
        json.dump({
            "api": state["api_results"],
            "ui": state["ui_results"],
            "health": state["health_status"]
        }, f)
    return {"report_path": path, "final_status": "passed"}

def escalate(state: RegressionState) -> dict:
    # Send Slack alert or Jira ticket
    return {"final_status": "escalated"}

Step 3: Wire the Graph with Conditional Edges

from langgraph.graph import StateGraph, START, END

graph = StateGraph(RegressionState)
graph.add_node("authenticate", authenticate)
graph.add_node("health_check", health_check)
graph.add_node("run_api_tests", run_api_tests)
graph.add_node("run_ui_tests", run_ui_tests)
graph.add_node("generate_report", generate_report)
graph.add_node("escalate", escalate)

graph.add_edge(START, "authenticate")
graph.add_edge("authenticate", "health_check")

def route_health(state: RegressionState) -> str:
    if state["health_status"] == "down":
        return "escalate"
    return "run_api_tests"

graph.add_conditional_edges("health_check", route_health)
graph.add_edge("run_api_tests", "run_ui_tests")
graph.add_edge("run_ui_tests", "generate_report")
graph.add_edge("generate_report", END)
graph.add_edge("escalate", END)

compiled = graph.compile()

When you invoke this graph, it follows the happy path if health is green. If health is down, it skips tests and escalates immediately. That is the kind of decision-making a linear bash script cannot do without turning into spaghetti.

From Linear Scripts to Stateful Graphs: The Real Upgrade

Most regression pipelines I audit look like this:

  1. A shell script runs pytest in one directory
  2. Another script runs Playwright in another directory
  3. A third script merges XML results into an HTML report
  4. If step 2 fails, step 3 still runs and produces a meaningless report
  5. No one knows which service caused the failure without grepping logs

The problem is not the tools. It is the lack of shared state and conditional logic. LangGraph gives you both.

Here is what changes when you move to a graph architecture:

Capability Linear Script LangGraph Agent
Shared state across steps Files or env vars Typed state object
Conditional branching if/then in bash First-class conditional edges
Retry with backoff Manual loop Built-in retry policies
Resume after crash Start from scratch Checkpoint restore
Human-in-the-loop Slack ping, wait Interrupt and resume
Parallel execution Background jobs Subgraphs and fan-out

I migrated one team’s regression suite from a 340-line bash orchestrator to a 90-node LangGraph workflow. The graph was easier to read because each node had a single responsibility. Debugging got faster because LangSmith (LangChain’s observability platform) traces every step with inputs, outputs, and timing. Most importantly, flaky tests stopped blocking the pipeline. When a UI smoke test failed, the agent retried with a fresh browser context instead of failing the entire build.

Testing Your Agent: Unit Tests for Nodes and Partial Execution

Ironically, the hardest part of building a testing agent is testing the agent itself. LangGraph makes this easier than you might expect. The official testing guide recommends three patterns.

Pattern 1: Create the Graph Fresh Per Test

Compile your graph with a new MemorySaver instance inside each test function. This prevents state leakage between tests.

import pytest
from langgraph.checkpoint.memory import MemorySaver

def test_happy_path() -> None:
    checkpointer = MemorySaver()
    compiled = graph.compile(checkpointer=checkpointer)
    result = compiled.invoke(
        {"env": "staging", "token": "", "health_status": "unknown", 
         "api_results": [], "ui_results": [], "report_path": "", 
         "retry_count": 0, "final_status": "pending"},
        config={"configurable": {"thread_id": "test-1"}}
    )
    assert result["final_status"] == "passed"
    assert result["report_path"].endswith(".json")

Pattern 2: Test Individual Nodes in Isolation

Compiled graphs expose graph.nodes["node_name"]. You can invoke a single node directly without running the entire workflow.

def test_health_check_node() -> None:
    compiled = graph.compile()
    result = compiled.nodes["health_check"].invoke(
        {"env": "staging", "token": "mock-token", "health_status": "unknown"}
    )
    assert result["health_status"] in ("healthy", "degraded", "down")

Pattern 3: Partial Execution with Checkpoints

For large graphs, you often want to test only a subgraph. You can simulate state at the end of one node, then resume from the next.

def test_api_to_ui_flow() -> None:
    checkpointer = MemorySaver()
    compiled = graph.compile(checkpointer=checkpointer)
    # Simulate that authenticate and health_check already ran
    compiled.update_state(
        config={"configurable": {"thread_id": "partial-1"}},
        values={"env": "staging", "token": "mock", "health_status": "healthy"},
        as_node="health_check",
    )
    result = compiled.invoke(
        None,
        config={"configurable": {"thread_id": "partial-1"}},
        interrupt_after="run_ui_tests",
    )
    assert len(result["ui_results"]) > 0

These patterns are documented in the LangGraph Test guide, but most QA engineers skip them and end up with slow, brittle end-to-end tests for their agent code. Do not make that mistake. Unit test your nodes. Partial-test your subgraphs. Keep the full integration test to one per release.

Connecting LangGraph to Playwright for Browser Automation

A regression agent without a browser is like a car without wheels. Playwright is the obvious choice here. I covered the benchmark data in my Selenium vs Playwright 2026 breakdown, but the short version is: Playwright’s auto-wait, tracing, and API testing layers make it the perfect tool node inside a LangGraph workflow.

Here is a minimal Playwright node you can drop into your graph:

from playwright.sync_api import sync_playwright

def run_playwright_smoke(state: RegressionState) -> dict:
    results = []
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        context = browser.new_context(
            viewport={"width": 1280, "height": 720},
            record_video_dir="/tmp/videos/"
        )
        page = context.new_page()
        try:
            page.goto(f"https://{state['env']}.example.com")
            page.fill("[name=username]", "regression_user")
            page.fill("[name=password]", state["token"])
            page.click("button[type=submit]")
            page.wait_for_url("**/dashboard")
            results.append({"test": "login_smoke", "status": "passed"})
        except Exception as e:
            results.append({"test": "login_smoke", "status": "failed", "error": str(e)})
        finally:
            context.close()
            browser.close()
    return {"ui_results": results}

If you are building more advanced AI-driven browser agents, my post on MCP for QA Engineers with Playwright AI Agents covers the Model Context Protocol integration that lets Claude and Cursor control Playwright directly. You can combine that with LangGraph to build agents that not only run tests but also diagnose failures using visual reasoning.

One tip: always launch Playwright inside the node, not outside. If you try to share a browser instance across nodes, you will leak state between tests and get nondeterministic failures. Each node should be self-contained.

TypeScript Version for Node.js QA Pipelines

If your CI pipeline runs on Node.js, here is the equivalent Playwright node in TypeScript:

import { RegressionState } from "./types";
import { chromium } from "playwright";

export async function runPlaywrightSmoke(state: RegressionState): Promise<Partial<RegressionState>> {
  const results: Array<{ test: string; status: string; error?: string }> = [];
  const browser = await chromium.launch({ headless: true });
  const context = await browser.newContext({
    viewport: { width: 1280, height: 720 },
    recordVideo: { dir: "/tmp/videos/" }
  });
  const page = await context.newPage();
  try {
    await page.goto(`https://${state.env}.example.com`);
    await page.fill("[name=username]", "regression_user");
    await page.fill("[name=password]", state.token);
    await page.click("button[type=submit]");
    await page.waitForURL("**/dashboard");
    results.push({ test: "login_smoke", status: "passed" });
  } catch (e: any) {
    results.push({ test: "login_smoke", status: "failed", error: e.message });
  } finally {
    await context.close();
    await browser.close();
  }
  return { ui_results: results };
}

The TypeScript SDK for LangGraph follows the same graph-building API. You use StateGraph, addNode, and addEdge exactly as in Python. I prefer TypeScript when the agent is part of a larger testing dashboard because it shares types with the frontend.

Common Traps When Building QA Agents with LangGraph

I have built six production LangGraph agents in the last year. Here are the mistakes that cost me the most time.

Trap 1: Over-Engineering the Graph

Not every regression suite needs a graph. If you have 20 API tests that always run in the same order and never branch, a Makefile plus pytest is faster and simpler. Use LangGraph when you have branching logic, retries, or human-in-the-loop requirements.

Trap 2: Mutable State Side Effects

LangGraph state updates must be pure. If your node mutates a list in place instead of returning a new list, checkpointing will behave unpredictably. Always return new dictionaries from nodes.

Trap 3: Ignoring Thread IDs

Every graph invocation needs a unique thread_id in the configuration. If you reuse thread IDs across concurrent CI jobs, their states will collide. Use the CI build number plus a UUID suffix.

Trap 4: Skipping LangSmith Tracing

When a graph fails in production, you need to see the exact inputs and outputs of each node. LangSmith tracing is free for individuals and small teams. Turn it on before you need it.

Trap 5: No Evaluation Framework for the Agent Itself

Your agent is code, and code needs quality gates. If you use LLMs inside nodes, you need an evaluation framework. I compared the two leading options in my DeepEval vs PromptFoo article. Pick one and add it to your CI pipeline.

Trap 6: Forgetting to Version Your Graph Structure

LangGraph does not enforce backward compatibility automatically. If you add a new required key to your state schema, older checkpoints will fail to load. The official docs recommend bumping a version field in your state and maintaining migration nodes for backward compatibility. I learned this the hard way when a staging checkpoint from last week crashed after I refactored a node name. Now I version every graph change and test checkpoint restore in CI.

Trap 7: Running Everything Sequentially

LangGraph supports parallel node execution via fan-out patterns. If your API tests and UI tests do not depend on each other, run them in parallel nodes. I cut my regression suite runtime from 14 minutes to 6 minutes simply by parallelizing the API contract tests and the browser smoke tests. The graph waits for both to finish before generating the report. This is built into the framework; you do not need a separate task runner.

India Context: What Hiring Managers Want in 2026

In 2025, most Indian job postings for SDET roles listed Selenium and Java as mandatory. In 2026, that is shifting. I track hiring data from Bangalore, Hyderabad, and Pune markets weekly. Here is what I am seeing.

Product companies and Series B startups now explicitly ask for “agentic automation” or “AI-augmented testing” in job descriptions. The salary bands tell the story. A senior SDET with only Selenium skills is still capped around ₹18–25 LPA at most services companies. The same person with Playwright plus LangChain or LangGraph experience is pulling ₹30–45 LPA at product firms.

The gap is not just technical. Hiring managers want people who can reason about workflow architecture, not just write page objects. If you can explain when to use a state graph versus a linear script, you are already in the top 10% of applicants I review for my team at Tekion.

For manual testers looking to transition, the path is clearer than ever. Learn Playwright first. Then add LangChain for LLM interactions. Then graduate to LangGraph when your workflows need branching, retries, or human-in-the-loop logic. That three-step progression maps directly to the ₹8 LPA → ₹18 LPA → ₹35 LPA salary curve I see in the market.

One more thing. The interview questions are changing too. In 2025, I was asked about Page Object Model and explicit waits. In 2026, I am asked about agent architectures, state management, and when to use LangGraph over a simple DAG. If you are preparing for SDET interviews at product companies, make sure you can whiteboard a multi-step agent workflow with conditional edges. It is no longer niche. It is the new baseline for senior roles.

Key Takeaways

  • LangGraph for QA is not a replacement for Playwright or pytest. It is the orchestration layer that sits above them, adding state, branching, and resilience.
  • Use nodes for single responsibilities (login, health check, API tests, UI tests) and conditional edges for decision logic.
  • Always checkpoint state with MemorySaver in tests and a persistent saver in production so you can resume after crashes.
  • Unit test individual nodes with compiled.nodes["name"].invoke() and use partial execution with update_state for subgraph testing.
  • Do not share Playwright browser instances across nodes. Launch and close inside each node to avoid state leakage.
  • If you use LLMs inside your agent, add an evaluation framework like DeepEval or PromptFoo to your pipeline.

FAQ

Do I need to know LangChain before learning LangGraph?

Not strictly, but it helps. LangGraph uses LangChain’s model and tool abstractions. If you have never called an LLM from Python, start with LangChain. If you already know how to invoke GPT-4 or Claude via API, you can jump into LangGraph immediately.

Can I use LangGraph with TypeScript instead of Python?

Yes. LangGraph has a first-class JavaScript/TypeScript SDK. The API is nearly identical. I use Python for backend agent logic and TypeScript when the agent lives inside a Next.js testing dashboard. Both work.

How does LangGraph compare to Airflow or GitHub Actions for test orchestration?

Airflow and Actions are pipeline orchestrators. They run tasks on schedules or triggers. LangGraph is an agent orchestrator. It makes runtime decisions based on state. Use Actions to kick off your LangGraph agent. Use LangGraph to decide what that agent actually does once it starts.

Is LangGraph production-ready?

With 32,784 GitHub stars, 9.65 million monthly downloads, and companies like Klarna and Uber running it in production, yes. Version 1.2.1 is marked stable on PyPI. The testing and checkpointing features are mature enough for CI/CD workloads.

What is the memory overhead of running LangGraph in CI?

Minimal. The graph itself is lightweight. Most memory goes to your actual tools: Playwright browsers, API clients, or LLM inference. I run a 15-node graph on a GitHub Actions runner with 2 vCPUs and 7 GB RAM without issues.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.