SmartBear: Context is the new code: why self-service QA will deliver AI’s promised productivity

Bottleneck nervous wrecks

The bottleneck on delivery that AI was to solve hasn’t gone away – it’s just moved down the line.

Eliminating that bottleneck means giving QA/testing teams more than automated tool parity with developers; however, it means uplevelling the job itself.

We’ve seen conceptual leaps in developer tools while QA/testing has lagged. The tools are fragmented, teams are working with inconsistent and unstable test environments and apps that are UI-heavy, highly distributed or change frequently come with a huge testing maintenance overhead. AI has made inroads but we’re at a stage similar to early code assistants – task-oriented tools automating the mundane, such as generating unit tests in volume.

The pace will pick up and tools will take on more complex roles, such as integration and end-to-end testing. No-code/low-code tools will stitch together underlying services, manage dependencies and evaluate behaviour to realise test outcomes.

Context is king/queen

At that point it will be necessary to uplevel the QA role in parallel because context is king and queen when it comes to self-service. Agents need information – context – to perform accurately, safely and to operate on their own productively.

Context is used to guide agents’ decisions and help them determine when – in the QA world – a test is complete. It helps agents understand what to do, what to avoid, how to complete a test safely and securely and how to evaluate results. QA/test engineers are primed to author that context, thanks to a hands-on understanding of their employers’ technology domain, products and regulatory requirements.

With this in mind, the question for engineers becomes: what does “good” context look like?

SmartBear’s Kingsley: Give QA/testing teams automated tool parity with developers.

There are three main principles: context should be clear and avoid ambiguity; it should provide information relevant only to the specific task; and it should describe background conditions – for example, system and state, policy and constraints such as rules of governance and security.

What does this look like on the ground?

Context should span four domains – the business, systems, testing and security. For business, that includes explaining intent – instructing the agent on business and product goals so it can adjust to changes and still do the right thing.

Clarifying contextualisation

On systems, context would include information about data and configurations, API contracts and integration points. For testing, it would cover elements such as test and scenario patterns and examples of failure. With security and regulation, its elements such as risk, data protection and rules of authorisation and system access.

Once engineers establish and codify context, testing team can apply it to build a comprehensive and flexible testing pyramid – from API and web to mobile, integration and end-to-end testing. This shared context can be reused at scale, flow consistently across projects and be updated easily as requirements change. It also enables full traceability back to requirements and policies, strengthening auditing and compliance.

Automated QA self-service will re-accelerate software delivery but speed alone isn’t the answer. By mastering the rich, structured context AI depends on and embedding that into QA workflows, test engineers can ensure self-service delivers its promised potential.