Helpful Definitions
Helpful Definitions
Here is a list of the most common terminology and acronyms 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.
CE Community Engineers are members who work closely with the CM team and
help with their tasks and responsibility.
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.
TCW Test Case Writer responsible for writing test cases and ensuring each test case
has detailed, clear and easy to follow steps and expected results as well as
verifying that the documentation and test cases provided by the customer are
valid and can be used and making any necessary adjustments
Project Or Test One specific test of a company's product. Each individual test cycle includes
Cycle 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
Terms Description
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.
Testing Types:
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 payment
Testing / Payment instrument to complete.
Instruments
AC - Accessibility Ensures that a product is usable by people with disabilities like hearing, color
Terms Description
API Testing: The purpose of API Testing is to check the functionality, reliability,
Validates performance, and security of the programming interfaces.
Application
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 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 design, and test
Testing 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:
Terms Description
SRS - Special Is a tool that is widely used by Testing Services and Community Management
Requirement Survey 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 or a new
Verification build for the product is released. Applause allows customers to run a re-test
once a new build with fixes for those bugs is available, effectively verifying
that the bug has been fixed.
NDA - Non Which is a binding contract between Tester and Applause App Quality, and
Disclosure by signing the NDA the tester agrees not to disclose any information covered
Agreement 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.
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.
WAD - Working As Work as designed is a rejection where the reported issue is working as
Designed designed, meaning that the behavior is exactly how the product is designed to
work.
DUP - Duplicate A duplicate rejection is a rejection where the bug reported is already reported
issue 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 tested like an external website.
DNFI - Did Not Can be used when the tester ignored clear instructions which affected the
Follow Instructions outcome or made the report unusable.
INF - Need more A tester did not provide the requested information to the bug report when an
info info request was sent.
Other All rejection reasons should be covered by using the above ones. In case the
Terms Description
customer has a different reason for rejection, they might use Other.
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 bugs
Valuable 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.
Ratings:
G Gold
S Silver
B Bronze
P Proven
R Rated
U Unrated
Terms Description
Badges:
Testing:
QA Quality Assurance
TF TestFlight
UAT User Acceptance Testing (aka Beta Testing or End User Testing)
IP Internet Protocol
OS Operating System
IE Internet Explorer
VM Virtual Machine
Miscellaneous:
AI Artificial Intelligence
CC Closed Captions
CTV Connected TV
CVV / CVC / CSC / Card Verification Value / Card Verification Code / Card Security Code / Card
CVN Verification Number
PM Private Message