uTest follows a structured test process that typically includes project onboarding, test case execution, bug reporting, and test cycle closure. Testers are assigned specific test cases and executed within the designated test environment. After execution, testers submit detailed bug reports to the platform.

If a bug report gets rejected, it negatively affects the tester's scores based on the type of rejection received.

Testers can dispute rejected bugs from customers.

Placeholders are forbidden.

Testers can use any registered device if it matches the test cycle requirements.

The Test Engineer selects the testers to participate in a test.

Test IO employs an agile test process that involves test planning, execution, and continuous feedback. Testers participate in test cycles that match their language, devices and location. We emphasize real-time and manual exploratory testing, enabling testers to discover and report bugs on the fly.

To start contributing to a test cycle, testers need to start test sessions in advance and acknowledge that the instructions of the features in scope were read and understood.

To identify duplicates, when submitting a bug, the ❝Similar bugs❞ list on the right-hand side of the bug form will show you the list of already submitted bugs in the current test, and you can also search and filter the bugs and Known Bugs list to do so.

If a bug report gets rejected, it negatively affects the tester's scores based on the type of rejection received.

Testers can dispute rejected bugs by Team Leaders. Once a report is disputed, it gets locked for review by the Bug Dispute Team.

Placeholder reports are highly forbidden.

Based on the devices registered in the Tester's Profile and other information, the system selects one of the devices and invites you to participate in the test. Depending on the seats left for each cycle, you may be unable to select a different device than the one the system chose. You cannot switch to another device once you have been invited to a device. Therefore, you can only submit bugs found on this device.

The uTest bug form is structured as follows:

Test IO's bug form, on the other hand, simplifies tester documentation with the following structure:

You don't have to follow a specific format to construct a title. However, you must respond to what happened, where the bug occurred and when it triggered.

On our bug form, you don't have to add the step number; our form already provides it. You can drag them around and rearrange them at will.

Except for the browser while website testing, the device's information is retrieved from the device you selected when accepting to participate in a test cycle, which cannot be changed afterward.

uTest classify bugs such as:

Testers are required to identify and report these bugs with accuracy.
​

Test IO categorizes bugs as:

We don't perform security tests.
​
Here are more specifications. Content bugs are related to every type of information, not only text (e.g., translations; typos are not reported), so missing images and buttons are content bugs rather than visual bugs.

Functional bugs considered performance, like endless loading can be regarded as functional bugs if they directly affect end-users, for instance, accessing content or progress over a task.

On the other hand, during performance test cycles, which are run as per demand, endless loading is a performance issue, and they are reported as such; therefore, measuring the internet speed and .har files is part of the attachments needed to attach to the report.

uTest bug severity is:

In which you decide which severity applies better to the issue.

At Test IO, we offer specific scenarios to guide you through the correct selection of the severity; these are only three:

The scenarios we provide will help analyse the issue in different ways, such as considering the functionality compromised and the bug's potential impact on end-users. For instance, showstopper bugs are critical, while if there is an easy and intuitive workaround like reloading the page, the correct severity will be low.

uTest allows testers to attach relevant files, such as screenshots, screen recordings, and log files, to their bug reports.

Screenshots:

Screencasts:

Test IO testers can include attachments, such as screenshots, screencasts, and crash logs.

Screenshots:

Screencast:

For performance testing, .har files are required.

uTest fosters communication between testers, project managers, and developers through a dedicated messaging system. Testers can seek clarifications on requirements and interact with stakeholders throughout the testing cycle.

​

Test IO emphasises real-time communication, enabling testers to collaborate and discuss issues through test chat, bug report comments, Discord server, and email platforms between testers, team leaders (TL), Customer Success Managers (CSMs), and customers. Testers can ask questions, seek clarifications, and receive instant feedback from the abovementioned stakeholders, as these can request information from testers' tasks.

uTest, the payout depends on how valuable the bug is:

Test IO payout depends on the type of task performed. There are tasks directly related to Test Cycles. In contrast, others, like Reproductions, Bug Fix Confirmation and Bug Report Confirmation, can be performed without joining the test cycle the report belongs to.
​
However, in a test cycle, the payout depends on the type and severity of the bug, as well as device specifications.

At uTest, testers can perform:

​

At Test IO, freelance testers can perform these paid tasks and receive the following bonuses:
​

Instead of waiting for the client to accept or reject your work at Test IO, you're being paid as soon as the Team Leader takes your bug or execution.