The Tests module is used to assemble and define test forms - a set of items to be delivered together with the goal of obtaining a final score on a single construct (in most cases, there are a few rare test approaches that are inherently multidimensional). Assess.ai separates the assembly of these test forms from their publishing because a test form might be used in multiple situations. For example: if you are in charge of employment assessments for a large city government, you might have a Microsoft Excel test that is used for several different jobs (e.g., Bookkeeper I, Bookkeeper II, Accountant I, Data Analyst I) and for several time windows during the year. Perhaps the different jobs each use a different cutscore for pass/fail. The test itself never changes, but we need to separate the usage of the tests. So Assess.ai treats the multi-use tests as sessions that are managed in the Sessions Module; the test is only assembled once.
The word form is often used to define when there are several different sets of items for the same test. For example, to deter cheating you might have form A and form B, which contain 50 items spread across 5 domains with 10 items each, overlapping by 25 items but with 25 unique items. These would be treated as separate tests in Assess.ai.
Therefore, the primary purpose of the Tests module is to select which items are on a test and how they are to be presented (e.g., sections, sequence). Issues regarding the usage of the test (e.g., assigning examinees, setting a date window, time limits) are located within the Sessions module.
You can also build a test battery where several tests are delivered in a single sitting, but this is defined in the Sessions module as an aspect of delivery.