Version 89 is a large release with significantly expanded support for Veeva studies. Our AI Agents have moved from answering one question at a time to authoring at scale and the machinery that runs Automated tests has become more resilient to interruption.

For more information see the release notes for Version 89.

Veeva: More of the Rule Language

The Veeva Test Case Advisor works by reading a rule and generating the test cases that exercise it, and its reach grows with the amount of Veeva's expression language it covers. Each release widens that coverage; this one widens it considerably.

The Advisor now understands the system attributes that real rules lean on: item-level values and units, the value an item held at the previous submit, a form's submit counter, change reason and status, and the Casebook, Study Country and Site attributes that describe the context a rule is running in. Site attributes were a particularly interesting problem, because a site is not known until the test is actually run - so a derivation that builds a value from the site name now embeds the real run-time value, looked up from Veeva and substituted automatically, while a rule that compares against a fixed site generates a scenario telling you which site the test must run on.

The Advisor also now handles rules that reach across linked forms - both counting links and reading data on the linked form - which it can do because the test language itself learned to link and unlink forms. That is the pattern for this release: the generator got smarter because the steps underneath it got richer.

A Fuller Vocabulary for Veeva Tests

A generated test case is built from the steps available to it, so the vocabulary of steps matters as much as the generator. Veeva tests can now add an Event Group to a subject, link and unlink forms, mark a form as intentionally left blank, and re-open a submitted form for edit - including re-opening automatically when a submitted form needs to be marked blank. These are everyday operations of running a Veeva study, and each one added is another part of the study your tests can speak to directly.

The editor around those steps has grown alongside them. Repeating event groups, forms and item groups each have a repeat input with validation of sequence numbers. The "has value" helpers suggest a field's codelist and dictionary values, in Rave as well as Veeva. Date fields keep what you type as you type it, so what you enter is what gets validated against the study's date format. And the editor now warns you when a step enters data into an item that is hidden by default, naming the item and value that would make it visible - so you can spot that at authoring time rather than at run time.

Agents That Author, and Agents That Tell You Where They Stop

Our Agents' work so far has been conversational: ask for an edit check, get an edit check. This release takes two steps beyond that.

The first is scale. The new bulk Edit Check Creator agent builds checks from specifications across a whole draft - it can fill in existing empty checks from the specification attached to them, or create new checks from custom specification objects. Every specification is classified by outcome - built with high confidence, built but needs review, needs a custom function, or failed - and those outcomes drive configurable action hooks, so the result of a bulk run feeds straight into your workflow. Results appear in the chat as they are built, so you can watch it work.

The second is judgment. Some specifications describe behavior that Rave's edit check steps do not express - regular expressions, extracting a component of a date, aggregating across records, conditions on form status. The Edit Check and Test Case agents now recognize those cases and tell you, so the boundary between what the agent can build and what needs a human is drawn explicitly, up front.

The same instinct shows up after the work is done. Having generated a check, the agent verifies that the logic it produced matches the specification it was given, and tells you if it does not. And when a specification names a custom function as handling the behavior, the agents build the check that calls it - noting if that function is not in the draft yet.

Runs That Look After Themselves

A test run depends on more than the test: the automated browser, the worker it runs on, and the environment around both. Those are the moving parts you have least control over, and the ones most exposed to interruption from outside. This release extends the runner's fault tolerance to cover them - if Chrome stops mid-run the runner restarts it and the run carries on, and a run whose browser is lost entirely is paused and picked up automatically on another worker. That is another class of interruption a run absorbs on its own, without anyone needing to watch for it.

Test running is smoother in other ways too. On the new Rave EDC, a step against a Folder that does not exist in the subject now names the Folder as the missing piece. Running a test set directly carries over the screenshot and continue-on-failure settings you chose last time in the wizard. Test Cases can now assert that an email is not received - matching on subject alone, subject with exact body, or subject with partial body.

In Summary

Veeva is where most of this release went: the Test Case Advisor now reads the bulk of the rule language you write day to day, and the test steps underneath it reach more of the operations a Veeva study performs. The test runner tolerates more of what goes on around it. And our Agents are being built to be clear about the boundaries of their work, because an agent that is open about where its work ends is one you can trust with the work it does.

This post was auto-generated by a LLM.