When you start using Test Urbis, you will encounter some specific QA-related domain terms that are new for you or you may have seen before but used in a different context.

To help you understand our platform terminology, here is a brief glossary of common terms that are used across Test Urbis.

Before we start, let’s take a quick look at the overall platform design. The main goal of Test Urbis is to efficiently connect three types of actors:

• The customer. The customer creates in the platform requests to have various QA activities executed, and it is responsible for providing the information needed by the platform QA/Test team.
• The (platform) QA/Test team. Responsible for executing the customer requests. This team is organized and managed by us (the platform operator, aka Arnia Software).
• The platform operator. Our company, Arnia Software, manages the platform functionalities, provides customer support, manages the QA/Test team, and acts as an intermediary between the customer and the QA/Test team, when needed.

Platform Test/QA team

This is the team that responds to customer’s demands to execute various QA/Test activities (Test runs, QA activities). It is composed of highly skilled QA/test engineers, located on our premises – in Romania, or in remote locations; the team is completely managed by the platform operator – Arnia Software, so the customer does not have to invest its own resources in the management of this team. Arnia Software will take care of specific project resources assignments, resources replacements and supervising the platform usage.

Platform operator (Arnia Software)

The platform operator role is assumed by our company – Arnia Software. We are the ones behind the design, development, implementation and maintenance of the platform, and we are also the ones who administer it.

We act as a link between the customers and the QA/Test team, but we strive to keep our interventions minimal – this is one of the main goals we targeted when designing Test Urbis. Both customers and the QA/Test team can communicate with us through the platform, and they can both ask for our help.

We take care of having the platform functioning as intended, ensuring its high availability, the security of the data and its proper usage. We also work hard to build more and more features into Test Urbis and to fix any issues encountered.

Subscription

A subscription is a logical entity that describes the QA/Test services the customer has bought from us. A subscription generally targets a specific type of service, such as manual test execution, test cases design or test cases automation development. But it can also be used for a wider set of QA/Test activities. The legal agreements (including the negotiations) between the customer and the platform operator – Arnia Software, are done outside the platform. When they are finalized, the customer gets a subscription key that can be used to register online the agreed services (i.e. the subscription) in the platform.

A subscription can have a start date, and end date, a number of contracted hours, a price per hour and other information, depending on the agreement.

Test project

In Test Urbis, a Test project is a logical entity that defines the product that is to be tested – a web application, a mobile application etc., from a QA/Test perspective A Test project must comprise the information the QA/Test team needs to test the product, such as:

• General information about the product to be tested (where do you get it, how do you install it, how do you use it etc.).
• The list of all combinations of browsers and operating systems where the product is to be tested.
• Information about the issues management procedures (how and where does the QA/test team reports them).
• The list of test cases available for the product.
• Any other relevant information.

You can view a Test project as the “parent” of the Test runs and QA activities entities – they are always created and executed in a Test project scope. The Test project does not contain execution results information, nor information about the effort spent – such information belongs to Test runs and QA activities “children”, as they represent the specific materialization of the Test project purpose.

Test run

A Test run is an activity consisting in product testing, performed following a well-defined scenario (i.e. execute it by following a predefined list of test cases). During a Test run execution, two important categories of information are continuously updated in the platform:

• The time spent by the QA/Test team.
• The testing results (passing tests, failing tests etc.).

If you don’t have a list of test cases, then before you create requests to test the product please consider using our QA/Test team to design the missing test cases. This is not only a short-time benefit, but also a long-time smart investment, simplifying product maintenance and the future next releases. Otherwise, if you want to do testing without a list of test cases, instead of a Test run create a QA Activity (of type “Exploratory manual testing”, for example).

QA Activity

A QA Activity is a generic placeholder for any other QA/Test activity which is not a Test run; it can be, for example: test cases design, test automation development, special types of testing, such as performance or security testing etc.

Whenever you need the QA/Test team to execute an activity which is not about testing the product using a fixed scenario – a set of predefined test cases, just create a QA Activity.

Inquiry

Inquiries are the place where all communication between the platform actors is done and kept centralized. This feature is very similar to a forum, where any user can create a post and other users can reply to it. No information is lost, and everything can be accessed later. When you create a post (i.e. an Inquiry), you can specify its recipients. An Inquiry can be Closed when the author decides, meaning that no more replies are allowed. Messages can be searched by content and an advanced search implementation is on our short-term product roadmap.

Notification

Notifications are automated messages sent by the platform. They will appear in the Notifications area, but they are also sent to your Inbox, if you choose to (see your user account profile page). Some examples of such automatic messages – notifications, are:

• When the status of a Test project is changed.
• When the status of a Test run or a QA Activity is changed.
• When the platform operator needs to send a wide audience message.
• When a Reply was added to your Inquiry.

If you have any questions or you need more information please contact us – we will be happy to get back to you.