|User Guide / Test execution|
Time-traveling execution provides the support for "retroactive" execution; that is, the ability to execute a particular set of revisions of project items in a given project.
Under some circumstances you may need to run automated tests against a specific release version of an AUT, say, version 1, when that is no longer the current version. Now, in a perfect world, you might have used linked variations to associate all the right versions of project items to the version 1 system. In practice, though, we don't always do things that way. So what do you do when you need to "go back in time" to execute existing tests on an older AUT version? Fortunately, you still have all the necessary versions of project items preserved through TestArchitect's revision control system. And time-traveling execution helps grant your test run access to the specific revisions that you require for all the project items invoked by your test.
Suppose that your team has released test assets for an AUT version 1.
Now, your team is developing tests for the next release, AUT version
During test development, your team is not in the habit of creating variations associated to each release version. They only update the tests as needed, checking in each update, as normal, to TestArchitect revision control.
Out of the blue, management decides to release a hot fix, AUT version 1 patch 1, to resolve some defects in AUT version 1. These defects, however, are not related to UI controls, nor to the business logic. Hence the test assets developed for version 1 should be fully reusable for this released hot fix. On the other hand, the current state of the test assets, being targeted at AUT version 2, have changed significantly in term of UI controls, business logic, and other new features.
Given that the new, patched version of AUT version 1 is expected to be able to pass the same set of tests as those of the pre-patch version, what is needed is a way to recapture that "snapshot" of test assets last used for version 1. This is the function of time traveling: to allow your team, at runtime, to specify a retroactive point in the history of your test assets; that point determines which revisions of project items invoked for the test run will be used.