• Automation Hosts are all the different systems (ie testing machines) used to run automated tests in the product.
  • Documents are all the attachments, documents, images (including screenshots) and other files connected to the product, with built-in versioning.
  • Incident: these are very flexible and can be classified however you wish. They are used to log bugs (for instance during testing), enhancements, risks, or any other type as specified by the product owner.
  • Releases are a hierarchical collection of a product releases (including sprints and epics)
  • Requirements are a hierarchical collection of requirements of any type, including user stories, use cases, and features.
  • Resources are every active member of a product,  and let you access their total workload (both completed and planned).
  • Risks: use these to implement a full risk management solution for your products. Each risk can have a probability and an impact to help you analyze each risks exposure. Add risk mitigations to track how you are treating the risk
  • Source code: if you have source code connected to the application, you can view each file, including specific commits, file revisions, and branches.
  • Tasks help break down larger areas of work like Requirements or Incidents, so discreet parts can be done by different people. Tasks can also be standalone activities.
  • Test Cases are the key unit of testing in the application. Each Test Case is made up of Test Steps. The execution status of a Test Case (eg pass or fail) can be traced across the system to Releases and Requirements.
  • A Test Configuration is a matrix of parameters that tests (both manual and automated) can be run against. Configurations let you quickly create every possible combination from multiple different parameters.
  • Test Run: Each time a Test Case is executed it creates a Test Run. Every execution in a product is collected as Test Runs that act as records for all testing activity.
  • Test Sets contain Test Cases. A Test Set acts as a store for dynamic testing data and for setting a specific order of execution of Test Cases.Test Sets are not folders: a Test Case can live in many Test Sets and even be in one Test Set multiple times.
  • Test Steps are the individual building blocks for test cases. Each test case is expected to represent up to half a day of work. Each step in that test case should represent one specific action to perform and verify (for instance logging in to a site). Each test step should only take a few minutes to execute