Testing a survey can take days of human labor, whether Questra programmed it or not. Someone has to click through the questions, try different answers, follow the routing, and decide whether what happened was supposed to happen.
It's tedious work, but it demands attention. The person doing it often needs to know the questionnaire well enough to spot the difference between a legitimate screen-out and a broken condition, or between a correctly piped answer and one that belongs to a different respondent. You can't just hand someone a link and ask whether it works.
Then the survey goes through a round of revisions. A question changes, a brand list gets updated, a routing rule moves. And you have to do it all over again.
We built Questra Link Testing to take on that monotonous work. Upload your questionnaire, provide your survey's test link, and let agents do the clicking, answering, and evidence gathering. You spend less time preparing a survey for field and more time doing research.
How it works
Questra sends a coordinated group of AI respondents through your survey. Each has a purpose: exercise particular features and collect the evidence needed to check them against your questionnaire. You can use it with surveys built by Questra, your own team, or your programming partner.
The process has four steps:
-
Extract the tests. Questra reads your questionnaire and turns its requirements into checks. These cover wording and language accuracy, answer codes and recorded values, screening and routing logic, and the respondent experience—including piping, randomization, required inputs, and custom behaviors specified in the document.
-
Plan the respondents. Those checks determine where agents need to go and what they need to do. We combine compatible checks into shared paths to collect the necessary evidence with as little repetition as possible. If a later question only offers brands selected earlier, the plan has to make those selections first.
-
Explore and collect evidence. Agents interact with the survey according to the plan, capturing screenshots, page structure—the DOM—and other metadata as they go. On supported connected platforms, we also retrieve the recorded response data alongside those observations. Seeing the correct answer on screen and saving the correct value are separate things to test.
-
Compare and report. Questra evaluates the evidence against each check, showing what passed, what failed, and what couldn't be verified. If an upstream error prevents respondents from reaching a question, you can see that its checks were blocked, rather than mistake them for a pass.
Example report; counts and elapsed time are illustrative.
Use a test or QA link, since agents submit answers as they work. Your team can review the findings, make corrections in its existing platform, and run the checks again.
The sequence sounds straightforward. Getting it to be useful, fast, and practical to run took considerably more work.
Finding the right experience
Survey programming has a concrete starting point and deliverable: a questionnaire goes in, a programmed survey comes out. Link testing gave us a less obvious model to work from. What should someone see while the agents are working? How much detail helps them review a result? What should happen when the system can't finish a check?
We went through dozens of iterations of the experience and flow. One early version started exploring as soon as someone pasted a link, before reading the questionnaire. It was quick to start, but it couldn't yet know whether the survey matched the study's requirements. We moved the questionnaire and planning to the beginning.
The results needed just as much care. A browser run finishing doesn't mean the survey passed. A check lacking evidence isn't necessarily a survey defect. We landed on a report organized around the questionnaire's requirements, with the observations behind each verdict and explicit gaps where testing was blocked.
That gives the reviewer something useful to act on, instead of another long recording to watch.
Choosing which paths matter
Complex surveys can have quintillions of possible answer combinations. Exhaustively walking them would be impractical even if every click were free. The challenge was to cover the requirements and expose unexpected problems without repeatedly testing the same behavior.
We combined targeted probes derived from the questionnaire with combinatorial testing principles. NIST's research on interaction faults shows that many software failures arise from interactions among a relatively small number of inputs. That research informed how we approached interaction coverage alongside the explicit questionnaire checks.
For example, a routing defect may depend on the combination of age, purchase history, and a selected brand. Testing those conditions together is more useful than sending another respondent through a route we've already checked. And a single carefully planned respondent can provide evidence for several requirements along the way.
The goal is to collect the evidence each test needs efficiently. Coverage is measured against what we actually tested, with limitations visible in the report.
Making it fast enough—and affordable enough—to use
Some of our earliest tests cost hundreds of dollars for a single survey. One ran into the thousands before we cut it off.
The agents could do the work, but letting AI reason through every interaction was too slow and too expensive. This pushed the limits of what we could practically ask today's models to do. Better prompts alone weren't going to give us the speed and economics we needed.
We built libraries of heuristics: conventional algorithms that recognize survey elements and determine how to interact with them. Common controls no longer need an AI call just to identify a checkbox or fill a text field. The libraries also account for less common layouts and behaviors we've encountered across surveys.
For custom elements those rules can't handle, we refined how AI identifies the available interactions and carries them out. That gives us a way to navigate unusual surveys without paying for model reasoning at every step of every respondent's journey.
Together with more deliberate planning, that work brought testing that took hours down to minutes, depending on the survey. It's still expensive for us to run, but it's now practical to put in researchers' hands.
Less preparation, more research
Link Testing works with your existing programming workflow. When Questra also programs the survey, Fix with AI can take a failed check, correct the source, and re-check the change. With a supported connected setup, the QA specialist can coordinate testing and corrections before the survey reaches Review.
The researcher still makes the judgment about whether the study is ready. Getting to that decision should require less repetitive clicking—and revising a survey shouldn't mean spending another set of days doing it again.