Reducing Information Loss in QA

Have you ever started testing a feature only to discover that an important design decision had already changed days earlier? By the time QA learns about the change, testing has already begun, effort has been duplicated, and valuable context has been lost. In my experience, having one QA representative attend selected design or feature meetings provides valuable context that often never reaches QA through tickets or documentation alone. QA’s role is not to drive discussions. Their purpose in attending is to listen, observe, take notes, and ask or answer questions if needed. 

Throughout my career, I’ve experienced many times the following scenario:

1. Development discusses a feature or design change.

2. Decisions are made.

3. QA isn't present.

4. The Jira ticket gets updated, but the reasoning behind the change often doesn't.

5. QA now has to reconstruct what happened from tickets, commits, Slack messages, or by asking developers individually.

6. That wastes time and increases the risk of misunderstanding the feature.

Having a QA representative present is an intentionally lightweight solution:

• They attend selected design or feature discussions.

• They listen.

• They take notes.

• They ask clarifying questions after the discussion if needed.

• They bring that knowledge back to the QA team.

That's not adding bureaucracy. It's reducing information loss. The information gathered from these discussions provides valuable context that often never makes its way into a Jira ticket.

• Why was this changed?

• What alternatives were rejected?

• What assumptions are we making?

• What systems could this impact?

• What concerns the dev team?

Those answers help QA build a better testing strategy long before the first test case is executed. 

I think of it like ordering food. You can wait for it to be delivered, or you can pick it up yourself. Either way, you get the meal. But when you pick it up, you usually get it sooner and with less uncertainty. In much the same way, having one QA representative gather information directly from key discussions reduces delays and prevents details from being lost as they pass through multiple people. 

Development teams are busy. Information naturally gets lost as it passes through multiple people. Rather than blaming anyone, QA can proactively reduce that loss. The goal isn't more meetings. The goal is better-informed testing.