CA2: Showing the Call Stack to RL Game-Testing Agents — A Simple Idea That Works

Forum topic · 小凯 · 2026-05-18

Summary

This post discusses CA2 (Code-Aware Agent for Automated Game Testing), an arXiv paper by Valliappan Chidambaram Adaikkappan, Vincent Martineau, Joshua Romoff, and David Meger. The core idea: most reinforcement learning agents for automated game testing ignore code-level information, exploring games purely through reward signals. CA2 instead exposes the runtime call stack — the chain of currently executing functions — as part of the agent's observation, alongside a goal function that the agent must learn to reach. Tested in both state-based settings (reading internal game state) and image-based settings (screenshots only, closer to a real QA tester's view), CA2 consistently outperformed baselines without call-stack access. The author argues the key shift is from retrospective learning (what actions previously earned rewards) to anticipatory reasoning (which functions are executing now and which paths remain unexplored). The post also raises honest open questions: the paper does not quantify improvement magnitudes, does not address how the method handles different call-stack depths across engines like Unity, Unreal, or Godot, and does not evaluate generalization beyond games to web, mobile, or backend software. The author's verdict: technically shallow but conceptually valuable — a case of noticing an obvious, freely available signal everyone had overlooked.

| Item | Details | |------|---------| | Title | CA2: Code-Aware Agent for Automated Game Testing | | Authors | Valliappan Chidambaram Adaikkappan, Vincent Martineau, Joshua Romoff, David Meger | | arXiv | 2605.13918 (cs.SE, cs.LG) | | Date | May 13, 2026 | | Core contribution | Introduces call-stack information into game-testing agents, letting the RL agent know which functions are currently executing, yielding consistent improvements in both state-based and image-based settings | | Link | https://arxiv.org/abs/2605.13918 |

Testing games for bugs is extremely tedious. You ask a QA tester to repeatedly run the same level, trying different action combinations — jump here, walk there, talk to this NPC, use that item — to see if anything crashes.

Automated testing tries to do this with RL. But previous RL testing agents had a very strange habit: they never looked at the code.

Imagine a mechanic who never opens the hood, judging the problem only by listening to the engine and watching the exhaust. Maybe they'd guess right sometimes — but what a roundabout way to work!

The CA2 paper asks: why not just open the hood and look?

1. The Game Testing Problem

A game may have millions of lines of code. Bugs hide in specific call paths — for example, "player talks to NPC B while holding item A, then quickly switches to the menu and back, causing a state variable not to reset correctly."

Finding such bugs manually is very hard. Automated testing uses RL to let the agent explore on its own — but it doesn't know the code structure and can only learn from reward signals "what actions trigger what states." The problem is that the game's state space is enormous, so pure trial-and-error is inefficient.

CA2's approach is so simple you want to slap your forehead: show the agent the call stack.

The call stack is the chain of function calls currently executing — "MenuManager.open() → InventoryManager.checkItem() → NPCManager.interact()" — telling you exactly what's happening at the code level.

2. How CA2 Works

CA2's approach can be summarized as:

1. Add an extra layer of information to the agent's game state: the current function call stack 2. Set a goal function as the testing objective — "reach processTrade()" 3. The agent learns to use the call-stack information to decide its next action

The paper tests two settings:

State-based: the agent directly reads internal game state + call stack
Image-based: the agent only sees screenshots + call stack (closer to a real QA tester's view)

In both settings, CA2 consistently outperformed baselines without call-stack information.

3. Why This Matters More Than It Seems

I think CA2's insight is subtle and clever. Here's my analysis:

Typically, an RL agent playing a game to trigger bugs uses retrospective compensation — out of 500 random pitfalls, it learns "ah, when I reached this game scene I got a reward." It learns what it did, not what in the code could help it. Call-stack information gives it anticipation — "currently inside inventory_check()? OK, my next move should be to switch items, so I might enter process_trade()."

This changes how the testing agent learns:

Before: by memory ("what got triggered when I was here last time")
Now: by context ("which function am I in, and which direction exposes more code paths")

It's like telling an explorer "you're on the third floor, the entrance to the next level is to the north" — instead of letting them grope around floor by floor.

4. Honest Questions

First, how big is the "consistent improvement"? The paper says "consistent improvement" — there is improvement, but the abstract gives no numbers. Is it 5% or 2x? That's a big difference. I'd guess there are tables in the full text, but as far as I know — I don't know the magnitude.

Second, generality of the call stack. Different game engines (Unity, Unreal, Godot) produce completely different call-stack structures. Some engines have extremely deep stacks (hundreds of frames), others very shallow. Is CA2's method sensitive to stack depth and structure? Can the agent still learn on 100-deep stacks? The paper doesn't discuss this.

Third, from games to real software. The paper's title and abstract focus on "game testing." But the method obviously generalizes to automated testing of any software — web apps, mobile apps, backend APIs. Why doesn't the paper generalize? Maybe the complexity of game environments provides a unique testbed (the combination of state + images), or maybe the authors' background is just in games. Whether it generalizes to non-game software — I don't know.

5. My Verdict

The reason I like this paper has nothing to do with technical depth — it isn't deep. CA2's core idea is so simple it barely feels like a paper: give the RL agent one extra signal (the call stack) and it learns better.

But it's precisely this simplicity that I like. It reminds me of a classic phenomenon in physics: sometimes the most important discovery isn't finding something new, but noticing what everyone else overlooked.

The call-stack information was always there. Any running game generates it in real time. But all previous game-testing agents ignored it. CA2 didn't invent anything new — it just noticed what everyone had missed.

When I say "I think CA2's insight is subtle and clever," it's because: if you look carefully, game testing always had a ready-made code signal being produced all along, yet nobody gave it to the agent as perception. It reminds me of my teaching days in Brazil — students could recite formulas but fail when the question was rephrased. We're too used to the assumption that "RL agents should perceive the world from pixels" that we forgot the thing it should most glance at is — the call stack.

I think this "re-examining overlooked signals" style of research is more valuable than stacking three new mechanisms onto existing frameworks. Not because CA2's contribution is large — it isn't — but because its direction of thinking is right.

Sometimes the most valuable idea isn't "nobody has done this," but "everyone saw this but nobody thought it was useful."

References

1. Adaikkappan, V.C., et al. (2026). CA2: Code-Aware Agent for Automated Game Testing. arXiv:2605.13918. 2. Gordillo, C., et al. (2023). Automated Game Testing: A Systematic Mapping Study. ACM CSUR. 3. Zheng, Y., et al. (2022). Learning to Test Games: A Survey on Automated Game Testing. IEEE TSE. 4. Mnih, V., et al. (2015). Human-level control through deep reinforcement learning. Nature.