The Second Brain That Changed How I Test Legacy Systems

1. The Memory Problem in Legacy Systems

Legacy systems have a memory problem, and it is nobody’s fault.

The documentation exists. The user stories are written. The feature files are here. But a system that has been running for years develops a second layer of knowledge that no document quite captures: the exception that surfaces only under a specific data combination, the status that flips for a reason that made sense three releases ago, the business rule that lives in the heads of the people who have been closest to it the longest.

As a tester, you can follow every written artifact correctly and still miss the thing that matters. Not because the documentation is wrong. Because legacy systems accumulate lived knowledge faster than any document can keep up with, and until something breaks, nobody knows the gap is there.

That is the problem we decided to solve.

2. One Place for What the Project Actually Knows

We started building what we call a second brain for the project: a shared Obsidian vault where we write down what the code does not state out loud.

Obsidian made sense because legacy knowledge is not linear. It is a graph. A screen links to a status. That status links to a table. That table connects to a support defect from three years ago, and that defect points to the exact data that reproduces it. Plain markdown notes with links between them matched the way the knowledge actually works. Anyone on the team can read them. And as we started exploring AI-assisted testing, it turned out agents can ingest them without needing any special export.

What goes in? Anything the team has had to rediscover more than once:

• Workflows. How a workflow moves, including the branches a user story describes in a single optimistic line.
• Tables. Which tables matter and how they relate.
• Statuses and exceptions. And the support issues that taught us those exceptions.
• Test data. Data that is valid, and data that looks valid but fails later because of a rule that only surfaces at runtime.
• Decisions. Decisions already made, so the next person does not spend a week reopening them.

Each note stays short and links. That link structure is the point: it is what you follow when a support ticket lands and you need to understand what you are looking at.

3. What Happened When We Started Troubleshooting from It

The first shift I noticed was how support questions got answered.

• Before the vault

  Find whoever had seen it before

  The fastest path to an answer was still a person, and a repeat issue could take a day and a half.

• With the vault

  Search the symptom

  The screen, the status, the table name. The note shows the rule, the earlier case and the check that confirmed it, in about five minutes.

Now the first move is to search. A tester hits a status they do not recognize; a ticket arrives with a specific complaint; someone has a doubt mid-sprint. We search for the symptom, the screen, the table name. The note shows what we already know: the rule, the table, the earlier case, the check that confirmed it.

If it is genuinely new, we add it. The next person inherits the analysis instead of starting from scratch.

This alone was worth the effort. The same edge cases come back with different ticket numbers all the time. A shared vault turns those repeats into a lookup that takes five minutes instead of a day and a half.

4. What It Means for AI-Assisted Testing

Once the vault existed, we started using it as the knowledge base for our AI agents when automating user stories.

This changed what the agents could do. An agent that only sees a user story will generate a happy path, because that is what a user story describes. An agent that has ingested the vault can see the rules, the data shapes, and the failures we already paid for.

• Real Workflows

  Scripts that follow the real workflow, including the branches the story left implicit.

• Realistic Data

  Test data that matches how the system actually stores a case.

• Known Exceptions

  Test cases that cover the exceptions already sitting in the notes.

5. The Part I Did Not Expect: SQL and Small Backend Changes

I want to be honest about something that surprised me.

Database checks and small backend changes are often where testing slows down. The query lives in someone’s history. The table’s name is almost right. A join that was safe last year is wrong after a workflow change. As a tester, I could describe exactly what I needed to check and still be blocked on finding the right SQL.

With the vault and our historical scripts in reach, the agent can search the related tables and the code we have already run and draft the database query from that evidence. I review it, run it, and adjust it.

It is not magic. I still have to understand what I am looking at. But I can now produce a sound query and prove a user story in the data layer, not only in the browser. Defects that would never appear on the screen get caught because I could look.

That felt significant. The vault and the agents make accumulated project knowledge accessible to someone earlier in their journey on the system, not just to the person who has been there longest.

6. Testing New Applications with What the Old One Taught Us

One more thing that changed: how we approach new applications being built alongside the legacy system.

New applications inherit statuses, roles, documents, and failure modes from what already exists. When we started testing a new application, the agent read the vault and brought that context forward, pointing at the rules that still apply, the data shapes that will not survive a migration unchanged, and the support issues likely to reappear under a new screen.

Walking into a new test cycle with what the older system already taught us is a different experience than starting from a blank feature file.

7. What I Would Tell Another Tester

Start writing things down before you think you need to. The vault is only useful because we maintained it, and the habit of adding to it after every support issue, every discovered exception, every piece of knowledge you had to dig for is what makes it worth opening.

We stopped treating project knowledge as something locked inside the system’s history. We are building something anyone can open, add to, and learn from, including the AI tools we use. The same knowledge that helps the team troubleshoot on a Friday afternoon helps generate a test case on a Monday morning.

That, for me, is the shift.

Key Takeaways

• Legacy knowledge outgrows documents. Testers can follow every artifact and still miss what matters.
• Knowledge is a graph. Short, linked markdown notes match how screens, statuses, tables and defects connect.
• Search first. A shared vault turns repeat support issues into a five-minute lookup instead of a day and a half.
• Context beats the happy path. Agents that ingest the vault cover real workflows, realistic data and known exceptions.
• Testers can prove stories in the data layer. Agents draft SQL from evidence; the tester reviews, runs and adjusts.
• Maintenance is the habit. Add to the vault after every support issue and discovered exception.

Frequently Asked Questions

Sridevi Kandula

QA Engineer, Sails Software — tests legacy and new applications using shared project knowledge and AI agents, with a focus on covering the exceptions a user story leaves out.

Connect on LinkedIn