Helpful Glossary

Here is a list of the most common terms and brief descriptions which used on uTest.com and
within uTest projects. More details can be found on the Academy page.

Terms Description

Testing Team:

Client or Customer A company that has engaged Applause and the uTest Community to
test their product.

TTL The Test Team Lead (TTL) is the primary point of contact for testers.
The TTL helps testers within test cycles and reviews all submitted
bug reports and test cases, etc.

TE The Test Engineer (TE) builds the test cycle, assembles the testing
team and is responsible for the overall execution of the test cycle.
Also, the TE is responsible for marshalling the test team through
completion of the test cycle achieving the goals of the request.

TSM Test Architect (TA) title has been replaced by Testing Services
Manager (TSM). The TSM works directly with the client. They
manage a team of TTLs and TEs to identify and provide appropriate
solutions for the client’s testing, feedback or research needs.

SDM The Solution Delivery Manager (SDM) is the customer’s primary

point of contact, and works with the customer directly.

CM The Community Management (CM) team are members of the

Community Management Team. The Community Management
Team's goal is to help our global community to learn how to be
excellent testers, to get opportunities for paid projects, and to connect
with fellow testers across the community and the globe. Meet the
uTest Community Management team from here.

CE Community Engineers are members who work closely with the CM

team and help with their tasks and responsibility.
Terms Description

DT The Dedicated Testers’ function is to provide the team with speed,

specialized expertise, and quality control. This role differs from the
traditional role of our community testers and they are supposed to
have a singular focus and dive deep. These testers should be seen as
experts by their community peers and help support the TTL in chat
management as an expert. Testers who have a strong history of
quality work are more likely to be approached by a TSM/TE to ask
about becoming a DT.

Test Cycle Terms:

Project Or Test Cycle One specific test of a company's product. Each individual test cycle
includes numerous testers and can vary greatly from other test cycles
depending on the cycle setting, type, etc. In the test cycle, testers
must carefully follow the instructions in the test cycle's overview to
find bugs on the in scope product, execute test cases, submit reviews,
or conduct usability studies, if available.

Test Case A Test Case is a set of predefined steps that must be followed and
executed by a tester in order to test specific features and
functionalities of a product, such as exercising a particular program
path or verifying compliance with a specific requirement.

Slot A slot is a reserved position within a test cycle for a tester with
specific requirements such as location, device, OS, etc. A slot may or
may not be linked to test cases, if a slot is not linked to a test case it
is referred to as an Exploratory slot which means a tester can freely
test the product and report bugs that are found and are within the in
scope areas.

Issue/Bug report Is a written summary of a specific error or defect (bug) in a product's

features or functionality. A bug report should contain all the required
information to understand, reproduce, and fix the bug.
Terms Description

Testing Types:

Fn - Functional Testing the features/functionality of a product with the intent of

locating issues.

Ln - Localization Verify the quality of a product in terms of a particular target

culture/locale.

Ux - Usability Measures how easy to use and user-friendly a product is by testing it

with real users.

Security Testing A process intended to reveal flaws in the security mechanisms of a

product.

Automation Testing Using an automation testing tool to execute repetitive testing steps,
which may be difficult to perform manually.

PT / PI Payment At its core, Payment Testing is any test that requires the use of a
Testing / Payment payment instrument to complete.
Instruments

AC - Accessibility Ensures that a product is usable by people with disabilities like

hearing, color blindness, old age, and other disadvantaged groups.

API Testing: The purpose of API Testing is to check the functionality, reliability,
Validates Application performance, and security of the programming interfaces.
Programming
Interfaces (APIs).

Voice testing Testing voice-enabled products with native speakers. It combines

functional testing, dialogue verification, usability testing, and
payment testing to help companies deliver voice experiences that
foster ongoing customer engagement and satisfaction.

Bug Hunt Testing This is a robust exploratory test. The goal of this kind of testing is to
only find out a specific bug or a specific bug on a specific device or
Terms Description

specific type of bug that occurs within the testing scope. Testers
invited to this cycle should carefully read and understand the
overview and the requirements and they must avoid reporting issues
that are not in scope.

On-site testing Visiting a physical location to evaluate the quality of the service and
collect feedback.

Live Testing Testing at a specific time, testers must perform testing at that time,
they cannot be late or test earlier.

ET - Exploratory Exploratory Testing is a simultaneous activity of learning, test

Testing design, and test execution. In other words, the tester is designing
their tests and executing them at the same time. As an exploratory
tester, your next action (the next test) is influenced by your previous
actions, your observations of the product’s behavior, and your own
thought process. The key aspect of Exploratory Testing is not the test
technique being used or the product being tested, but the skills and
experience of individual testers.

uTest Terms:

SRS - Special Is a tool that is widely used by Testing Services and Community
Requirement Survey Management to recruit testers for test cycles where data points are
needed that the platform doesn’t capture yet.

KI - Known Issue Known Issues are the issues that are already been found in previous
Test Cycles or the issues that the customer already knows about.
Known issues are helpful to prevent duplicate submissions, and in
order to avoid rejections, testers should always check them before
starting testing. The known issues can be added in the Cycle in sort
of a spreadsheet or you can recognize them by seeing a blue
“bookmark” tag next to the issue to indicate that this is a Known
Issue in the title column of the issues page.

BFV - Bug Fix Is a process of verifying if a reported bug has been fixed when a fix
Verification or a new build for the product is released. Applause allows customers
to run a re-test once a new build with fixes for those bugs is
Terms Description

available, effectively verifying that the bug has been fixed.

NDA - Non Which is a binding contract between Tester and Applause App
Disclosure Agreement Quality, and by signing the NDA the tester agrees not to disclose any
information covered by the agreement. Typically used to protect any
type of confidential and proprietary information.

IR - Info Request More information is requested on a bug report or test case, or a tester
is required to fix the bug report or test case.

Environment Refers to device, OS, OS version, browser, or any specific setup that
is used for testing.

Triage/Triaging A process of reviewing a bug report or test case and then sending an
info request or recommending the bug report or the test case for
approval or rejection.

Placeholder A placeholder is a submitted bug report without complete

information or required attachments for the purpose of reserving the
position of the report and later on edit and completing the report or
changing it to a different bug.

Reproduction Is the process of recreating a bug by following the action performed

steps in a bug report.

Turnaround Time This is the time limit when testing work should be submitted. For
example, a slot or test case with a turnaround time of 6 hours should
be submitted within 6 hours after claiming the slot or test case.

Bug Rejection Types:

WAD - Working As Work as designed is a rejection where the reported issue is working
Designed as designed, meaning that the behavior is exactly how the product is
designed to work.

DUP - Duplicate issue A duplicate rejection is a rejection where the bug reported is already
Terms Description

reported by another tester or is a Known Issue that is added to the

cycle.

OOS - Out Of Scope An Out of Scope rejection is a rejection where the reported bug is not
in the scope of the testing product, for example only certain areas of
the website are being tested in the cycle and any other areas should
not be tested, reporting a bug that is found in one of these areas that
are not in the scope of the cycle will be categorized as Out of Scope,
the same case applies if the issue was found in a product that was not
being testes like an external website.

DNFI - Did Not Can be used when the tester ignored clear instructions which affected
Follow Instructions the outcome or made the report unusable.

INF - Need more info A tester did not provide the requested information to the bug report
when an info request was sent.

Other All rejection reasons should be covered by using the above ones. In
case the customer has a different reason for rejection, they might use
Other.

Bug Approval Types:

Somewhat Valuable The bug has some impact on the product and has some value to the
customer.

Very Valuable The bug has a significant impact on the product and very valuable to
the customer.

Exceptionally The bug has a critical impact on the product and must be fixed. These
Valuable bugs bring exceptional value to the customer.

WNF - Won't Fix The bug is valid and approved but the customer is not interested in it
or not planning to fix it.