QT MANUAL

Version 1.6

FOR RELIABILITY AND EFFICIENCY

Abbreviation:
QT RM: QT Region Manager
QT PM: Project Testing Manager
QT I/F: QT Interface/Liaison person
1 Test Preparation

1.1 Account and permission

1.1.1 VPN
Server Address: https://om.oppo.com

1.1.2 RTC
Pre-requisite: VPN has been set up
Web Link: https://rtc1:9444/ccm/web
Hosts/IP Address: Add 172.17.103.230 rtc1 to system hosts file
(C:\Windows\System32\Drivers\etc\hosts)
1.1.3 Email
Server Type: IMAP
IMAP Server/Port: smtp1.oppo.com:143
SMTP Server/Port: smtp1.oppo.com:9988

Note:
* Other server addresses (eg. 121.12.xxx.xxx, mail9xxx.oppo.com) are not suitable for area outside of China.
* Each email account has connection limit. Please do not share your account or log on multiple device at the
same time. (If you see error ‘C2 NO LOGIN FAILED’, please log out from other devices and log in again after
30 minutes.)
* Web access to email: https://smtp1.oppo.com/owa (For temporary use or changing password)
* Do not share your password to anyone, and do not let anyone access your account as this might jeopardize
your email security.

1.1.4 FTP
Server Host/Port: eftp.oppo.com:919
FTP Tool: Filezilla (https://filezilla-project.org/)

**Note: All the account and permission in charge person: Liu Xiao Nian 刘小念 yi ting ting 易婷婷

1.1.5 PC Driver
1.1.5.1 File transfer (MTP/PTP)

1.1.5.2 Qualcomm Driver

Qualcomm HS-USB QDLoader

Qualcomm HS-USB Diagnostics

1.1.5.2.1 Installation
1. Drivers are provided by HQ.
2. The TESTSIGNING Boot Configuration Option
Run cmd as administrator, type in bcdedit /set testsigning on and <Enter>.
Refer to: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/the-testsigning-boot-
configuration-option
3. Add test certificate which comes together with the driver package.
4. Install drivers.
**Note: Windows Update might install driver software for you which might affect your installed Qualcomm
driver. You can turn this auto install feature in ‘Device Installation Settings’.

1.1.5.3 MTK Driver

MediaTek DA USB VCOM

MediaTek PreLoader USB VCOM

Meta Mode:

MTK USB DEBUG

MTK USB Modem
* When flashing MTK device, open Device Manager and Expand Ports (COM & LPT), port displayed will be
‘MTK USB Port’ and changed to ‘DA USB VCOM Port’.

1.1.5.3.1 Installation
1. Drivers are provided by HQ.
2. Disable signature enforcement (Refer to next chapter)
3. Install drivers. If the installation unsuccessful, manually add the signed driver (.inf) which contained in the
driver package through Add legacy hardware in Device Manager.

1.1.5.3.2 Disable Driver Signature Enforcement

Purpose: To install and run driver that was not certified by Microsoft.

For Windows 7
Method 1:
 Run command prompt as administrator
Type bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS and <Enter>
Type bcdedit /set TESTSIGNING ON and <Enter>
Restart PC
Method 2:
Restart > Continuously press F8 while booting > Advanced Boot Options > Select [Disable Driver Signature
Enforcement] and <Enter> to continue

For Windows 8
Start menu > PC settings > General > Advanced Startup > Restart now
Troubleshoot > Advanced options > Startup Settings > Restart
Press 7 or F7 to choose Disable driver signature enforcement

For Windows 10
Start menu > Settings > Update and Security > Recovery > Advanced startup > Restart now
Troubleshoot > Advanced options > Startup Settings > Restart
Press 7 or F7 to choose Disable driver signature enforcement

1.1.6 Testing Tools

**Note: All tools mentioned in this chapter are provided by HQ, check on FTP server for the latest update.

1.1.6.1 ADB (Android Development Bridge)

Installation:
1. Java JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html
2. Android SDK: https://developer.android.com/studio/index.html (Get just the command line tools)
3. Add the path of platform-tools to Environment Variables.
set ANDROID_HOME=C:\<installation location>\android-sdk-windows
set PATH=%PATH%;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools
4. Verification:
Connect device to PC, enable USB Debugging on device and run command prompt on PC. Type in any adb
command to check is adb working.
**Note: You can download and install Powercmd in order to open multiple command prompt windows.
Download at http://www.powercmd.com/.

1.1.6.2 ADB Command line tool (Android Debug Bridge)

Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator
instance or connected Android-powered device.

For installation and instruction, please refer to android official website:

https://developer.android.com/studio/command-line/adb.html

1.1.6.2.1 ADB commands:

Commen ADB commands:
adb devices/remount/push/pull/install/logcat/getprop/setprop/shell

1.1.6.3 Qualcomm tools

 QPST Qualcomm Product Support Tool
QPST is a set of Windows tools designed to interface with, control, and test CDMA phones
that contain Qualcomm ASICs. The QPST server can keep track of multiple phones on
local host machines. QPST currently consists of the server application, which has no
interface, and five component, or “client,” applications. Two standalone utilities,
QCNView and Roaming List Editor, complete the QPST tool set. The client applications
include:
- QPST Configuration
- Service Programming
- Software Download
- RF NV Item Manager
- EFS Explorer
Port: Qualcomm HS-USB Diagnostics XXXX (COMX).
QXDM Qualcomm eXtensible Diagnostic Monitor
QXDM Pro is a real-time data collection and diagnostic logging tool for measuring mobile-
based RF performance. Designed to operate using all commercial handsets that contain
Qualcomm ASICs and with Qualcomm’s test/trial phones, QXDM Professional displays
statistics and diagnostic information, and enables users to read and write non-volatile
memory.
It is a powerful platform for evaluating handset and network performance.
**Note: different QXDM log masks are required to catch logs for different type of issues
QCAT Qualcomm Log Analysis Tool
QCAT is an integrated software package that allows user to decode the contents of binary
log files generated by QXDM and Qualcomm tools, supporting performance log packets,
mobile events, and logged signaling messages, etc.
QACT Qualcomm Audio Calibration Tool
QserIMEI manually modify device IMEI, Bluetooth address, and WiFi address on device with ROM
3.0, ROM 2.0 and below.

1.1.6.4 MediaTek tools

Download Flash firmware

Tool
SP_META To backup and restore device NV parameter on device with ROM 3.0.
MauiMETA To backup and restore device NV parameter on device with ROM 2.0 and below.
Mtk_IMEI4G Tool to manually modify device IMEI, Bluetooth address, and WiFi address on device
with ROM 3.0.
SN_Write_Tool Tool to manually modify device IMEI, Bluetooth address, and WiFi address on device
with ROM 2.0 and below.

1.1.6.5 Other PC Tools

PowerCmd Command Prompt Replacement Tool
Notepad++ Source code editor and Notepad replacement that supports several languages.
FTP Tool Filezilla
FTP Tool Xunlei
SecureCRT Telnet/SSH client (For USB serial port log)
Wireshark Network protocol analyser (For network log)
NovaMind, Visio, etc. Mind mapping tools
1.1.7 Precondition before start testing.

1.1.7.1 Restore Backup Resources to set up test environment

Purpose: Restore backup resources to DUT to simulate user real world phone usage environment.
Backup resources should include:

App and data

TOP 100 local applications and App data ★★★
Browser bookmarks OR browser home screen webpage

Personal data
Phone & SIM contacts ★★★
SMS & MMS
Calendar events
Call history

System data
Alarm clocks

Multimedia files
Pictures
Sound records in different format
Songs & lyrics
Videos in different format
Documents in different format
Compressed files in different format
Folders renamed with different languages (follow local’s favorite)

1.1.7.2 Turn on dump log for Qualcomm devices

Turn on dump log during functional testing and field testing using Qualcomm devices:
*#800# > Normal log info catching > Enable system dump log

When dump issue occurred, the phone will be switched off automatically and unable to turn on using power
button. At the moment please do not force start the device. Use QPST to export the dump log. Submit a bug
and feedback the issue to project team.

1.1.8 Testing Accounts

1.1.8.1 Third Party Applications
Create at least ONE testing account for below third party applications.
- Facebook / Facebook Messenger
- Instagram
- WhatsApp
- Skype
- WeChat
- Viber
- Line
- BBM
 - IMO
Add all your team members testing accounts to your testing accounts.

1.1.8.2 Email
Create at least ONE testing email account for each email service.
o Google mail, Yahoo mail, Hotmail, and others which is frequently used locally.
o At least one email with IMAP setting & at least one email with POP3 setting.

1.1.8.3 O-Cloud
Create at least ONE OPPO O-Cloud account.
2 Bugs on PDT & LMT Projects
For issues encountered during testing and replicable on both PDT and LMT project:
o No matter the issue was encountered in PDT or LMT testing, submit bugs on corresponding PDT
projects(If there’re more than one PDT projects have the issue, submit bugs on all of them),at the
same time raise the issue on LMT projects,attach PDT project bug ID on LMT bug comment.IF the
issue is critical or must be solved on LMT project, inform PM to follow up.
o IF the issue is critical or must be solved on LMT project, submit a bug to corresponding LMT projects
and inform PM to follow up.
If you are not confirmed about the bug severity and whether it must be solved on LMT project, please
get advice from superior.

3 Bug Report and Tracking

部分信息取自 OPPO 软件缺陷管理规范_V1.0_20150518

3.1 RTC bug submission guidelines

A good bug description should follow the following principles:
Accurately describe the time/location/conditions/results, without any misunderstanding
Clearly describe the operation steps with orderliness
Concisely contain essential information
Completely reproduce the operation steps and other essence
Neutrally and objectively describe the bugs without emotional words
Evidently shows the fact with data/photo/files.
Consistently be submitted in required format
一个好的 Bug 描述要遵循以下几个原则：
准确：准确描述 Bugs 发生的位置、产生条件和结果，不会引起误会 ；
清晰：清晰地描述操作步骤、条理清楚 ；
简洁：简洁明了，只包含必不可少的信息 ；
完整：重现 Bug 的完整操作步骤和其它本质信息 ；
中立：客观地描述 Bugs，不带任何情绪化的语言 ；
证据： 提供 Bugs 存在的数据、图像和文档等 ；
一致：按照一致的格式描述所有的 Bugs。

3.1.1 Bug description

Summary 【Case short name】【REGION - DOMAINModule】Brief summary
- add【market-feedback】for feedback from market or internal user after product released to market.
- add【trial-feedback】for feedback from user trial before product released to market.
- add【operator-feedback】【operator name】for feedback from operators testing.
Title should be written NOT MORE THAN 20 words.
Title MUST be simple, straight to the point and professional.
Avoid of using ambiguity words like unusual, abnormal, maybe, function incorrect.
Add label below when it is under condition:
e.g.:
【BasicFunction】【MY - Settings】XXXXXXXXXXXX
【IN-Volte】【operator-feedback】【JIO】UE doesn’t support conference call
If the issue not covered by any cases,please write 【None】【Region-module】
Project ID Corresponding project ID for PDT/LMT tests from Project teams
DEV-ROM for tests released by ROM team
Work Item Type Select QT Bugs (by default)
Domain Functional module where the issue happens.
Team UE Team for string issues
QT Test Team for the rest * This requirement may be updated in next edition
Module UE Team for string issues
QT Test Team for the rest * This requirement may be updated in next edition
Owner Select corresponding liaison QT of the test team. Each project has a particular QT from HQ project team who will
handle overseas bugs.
Severity Refer to Section: Bug severity classification
Probability of Select according to the probability of the issue occurred.
Reproduction Probability = 5, 100%
Probability = 4, 50%-100%
Probability = 3, 10%-50%
Probability = 2, 1%-10% (Issue can be reproduced after several attempts)
Probability = 1, Less than 1% (Issue only happened once, hard to reproduce)
For probabilistic issues, state reproduced times/tested times for bug description and verification comments.
* Note: If the issue is not critical and it’ll cost too much resource (manpower and time) to do the verification, or
there’s other difficulties, please confirm with Regional Manager or QT PM about the verification scheme.
Firmware Dial *#6776# -> OTA version
version adb shell getprop | findstr version.ota
prop file exported by getlog script
[ro.build.version.ota]: [X9079EX_11.A.01_INT_001_201605040043]
Last Version Has Select according to the situation:
This YES/ NO:
Phenomenon - Compare with last/previous software version to check when was the issue introduced.
Or Not - Provide version number and test result in Bug Description > Remark
Low probability issue (compared but not reduplicated on previous version):
- Probabilistic issue that cannot be reproduced by limited test times, which means that the tester cannot
confirm whether it exists in previous version or not. (normally with probability < 4)
Not compared with previous version:
First version:
- PDT SW version
- Test a new function for the first time
- Third party apps testing for first time
Customer feedback from market/operator/user trial
ROM Version Settings -> About phone -> ColorOS version. OR
*#6776# -> ColorOS Version
BUG Type Function issue/String issue
Refer to: How to define bug type?
Region Select current region.
APK Version Fill in the APK version for issues found in built-in apps (Email, Browser, Keyboard, Office, Google apps) and other
third-party apps.
Case ID Follow the Case ID defined in test cases
Some task email require specific case id, please fill up accordingly.
If there is no case ID defined in the test cases or tasks, CONFIRM with supervisor.
 Fill None if there is no case ID.
- OS-NONE for overseas function tests without case ID but should be covered in PDT/NRT function tests
- FT-NONE for field tests without case id but should be covered in Field tests
- OS-MENUTREE for menu tree testing
- NONE for other situations

3.1.2 Bug severity classification

Bug severity may range from “Blocker”, “Critical”, “Major”, “Minor”
1. Blocker: A bug that completely blocks testing is considered as a showstopper which need to solve
urgently. E.g.:
- Features not implemented for example failed to register to network, SIM card is not detected,
unable to make calls or send/receive SMS & MMS.
- High probability (> 30%) of phone crash, rebooting automatically, black screen, white screen,
flickering screen, phone unresponsive and major phone lag issue.
- Phone call successful rate less than 50%.
- Bug that impact user security and property loss, for example, unable to make emergency calls, no
notification for abnormal charges from third party apps.
- In-house accessories (software/hardware) unable to in-sync with device.
- Rules and regulation is not fulfilled for example WAP specification, GPRS/EDGE/3G/4G specification,
MMS specification, CMCC specification, CTA specification, UA specification and more.
2. Critical: Key function bug that affects user’s experience and have to be fixed before exit debug phase.
- Function does not work as expectation.
- Performance issue (Example: phone functioning speed, internet speed, MP3 audio quality, display
resolution, phone call quality, camera effect, photo quality, video player quality, phone standby
period and more).
- Call quality and sound quality is bad, for example echo, howling and noise.
- Cross test and interruption test issues which happen under particular scenario and cause function
error, black screen, device reboot, etc.
- Particular scenario means that issues don’t happen during common operations, e.g.: Must operate
at specific time, must operate with specific files, must interrupt and then do some specific
operations.
- If such issues happen under common scenario, it should be considered as Blocker issue
- Notification or alert message is misleading to users.
- Low probability (< 30%) of phone crash, rebooting automatically, black screen, white screen,
flickering screen, phone unresponsive and major phone lag issue.
- User interface design is not match with design requirement for example app icon (Calendar, Clock,
FM Radio and etc) misplaced, overlapping, spelling mistake, design mismatch and more. Menu tree
and symbols mismatched with the document provided by HQ UE team.
3. Major: A major bug which causes inconvenient/uncomfortable to the user and can be categorized as
enhancement.
- Menu and text displayed are redundant, device interface/content/format displayed incorrectly.
- Moderate system error.
- Moderate data processing error.
- Bugs that lower user’s satisfaction but not request for refund.
4. Minor: Bug that needs slight amendment but basic functions are not affected.
- Unusual minor scenarios where user seldom or unable to reproduce.
 - No alert message prompt when perform important action, for example delete function.
- System operational is inconvenient for user.
- Notification or interface that is incomplete or ambiguity but does not affect user’s understanding.
- Minor issue which functionality as a whole is not impacted.
- Phone features that not listed in requirement but might use by users.
- Bug related to sequence of the menu.
- Graphical user interface is not friendly.
3.1.3 Bug describe details
3.1.3.1 【Preconditions】
State clearly the conditions which are needed to perform next operation.
Must be simple and clear to understand.
Specially pay attention to low probabilistic issues: describe more detail about the operations before issue
happened, which may be helpful for analysis
3.1.3.2 【Operation Steps】
Clearly describe the steps to reproduce the bug.
Steps should be clear, in order, and simple to understand.
For bug which has complicated operation steps:
describe in sequence or describe step-by-step.
For bug which has simple operation steps:
describe the operation step in a sentence.
One new bug creation is for submitting one bug scenario only, avoid to describe many bugs in one bug. If
there are several issues under one same operation or same interface, describe them separately.
3.1.3.3 【Actual Results】
The results shown after performing according to the preconditions and operation steps.
Avoid of using ambiguity words like unusual, abnormal, maybe, function incorrect.
Should have one actual result only.
Support with images or videos when it is hard to describe in words.
For probabilistic issues, state: Test XXX times/minutes, reproduced XXX times
3.1.3.4 【Expected Results】
The results of the function should perform.
Should have one expected result only.
Must be correct and fulfill requirement, cannot be misleading or unsure.

3.1.3.5 【Remark】
- If log file is too large and unable to attach in RTC, please upload to ftp [/0_tester/log] and share log
link: Right click on the targeted file > Select Copy URL(s) to clipboard > Paste to RTC.
o Sample: ftp://eftp.oppo.com:919/0_tester/log/2017-02/6/921926/921926-log.zip
- Other information needed:
e.g.: State the effect of the bug: how it affects users and testers.

3.1.3.6 【How To Recover Abnormal Problem】

Describe how to make the device recover to correct behavior, state a way with the LEAST impact on user
experience. Pay attention to the order:
 Wait for some seconds
 Tap home key
 Kill background process
 Clean the app data
  Reboot
**Note:
- For low-probability issue, testers must be careful to check with developer if need to keep the scene. In
that way, state the actual situation.
- This information is helpful to access bug severity.

3.1.3.7 【Reference Phone's Phenomenon】

According to the suspected issue nature, compare with reference devices with same
chipset/platform/baseline/ColorOS version/Android version of internal/external brands, and state the useful
information. Tester should confirm with leader if not sure which REF model to use.
Test with a REF device at SAME scenario with DUT to avoid introducing irrelevant variables.
State the reference model and the behavior. If it’s internal model, state the firmware version as well.

REF behavior:
Model xxx, Comparison point(same/different - android version/chipset/ColorOS version/..):
- No problem/Have same issue
- Test ___ times/minutes, reproduced ___ times //For probabilistic issues
- Not compared with REF because _______.
Single-device problem:
Another device of same model with same firmware version:
- REF test condition; not able to replicate (for 100% reproduced issues)
- REF test condition; test ___ times/minutes, reproduced 0 times (for probabilistic issues)
* State firmware version for internal models.

e.g.:
【IN-VoLTE】JIO VoLTE MO fail on R9
…..
Probability: 4
…..
【Reference Phone’s Phenomenon】
F1s, MT6750: test 20 times, reproduced 4 times. (A1601EX_11_A.26_161222)
A33f, MSM8939: test 20 times, reproduced 0 times. (A33fEX_11.A.25_INT_025_201612220711)

3.1.3.8 【Discuss】 - Verification results

【Discuss】field is for analysis results and verification results. For testers, state essential information:
- Firmware version
- Pass/Fail or Test ___ times/minutes, reproduced ___ times (for probabilistic issues)
If the bug was not raised by a different person, the tester who take over the bug MUST verify the bug with
previous firmware under EXACTLY SAME time & condition, and state the behaviour as well, in case that
current tester doesn’t correctly understand the issue.
Version XXXX (original bug ver.): Pass/Fail or Test ___ times/minutes, reproduced ___ times
Version XXXX (current verification ver.): Pass/Fail or Test ___ times/minutes, reproduced ___ times
**Note: Never simply comment ‘issue solved’ only after verification.

3.1.3.9 Note
 Add link for similar bugs/new bugs introduced by fixing existed bugs/bugs copied from other projected
 Double confirm the information is correct before submitting/save.
  Subjective criticism/ridicule are not accepted in any bug description or comments
 Do not use bold/italic font, exclamation/question mark, other emotional symbols
 Confirm that there is no repeated bug submitted
 For critical bugs with low probability, protect the scene/keep screenshot/export log and timely contact
developer or QT tracking personnel.
 For critical bugs with low probability, try to find the reproduction steps.

3.1.4 Attachments/Link
Additional attachments are required to be uploaded for bug analysis:
Representative screenshot/video are required to attach directly into RTC (SEPARATELY from the log files) to
make it easier for PM to assess the bugs.
3.1.4.1 Screenshot
WHEN:
Screenshot is required when issue reproduced.
HOW:
DO NOT rename the screenshot picture, as the file name indicate the timestamp which is used for log
analysis
3.1.4.2 Video
WHEN:
If the behavior / operation step is hard to describe or your description is ambiguous, please record a video
for better understanding
HOW:
Screen recorder applications or adb shell screencap command are useful to record most function issues.
Please remember to turn on Show Touches before recording.
If you need to record the video using other devices, make sure the full screen is inside the preview.
3.1.4.3 Log
Reboot the phone after turn on the LOG SWITCH
Catch a screenshot when issue reproduced, DO NOT modify the filename which is timestamp for log analysis.
The time point on which issues occurred should be stated for analysis.
Modemlog occupies a relatively large space. If it’s not modem/telecommunication issue, there’s no need to
turn on modem log except in exceptional circumstances.
If file is oversized, upload it to FTP and state the path in bug. (Developer doesn’t have access to QT FTP
server, need to inform I/F if there’s an additional log).
**Note: Maximum file size of 1 file to upload on RTC is 40MB.

3.2 Particular issues

3.2.1 Third-party Apps (GMS and other non-built-in apps):
Apps downloaded from Google play store or other resources from the Internet.
IMPORTANT:
Preparation:
1. Run 8 application in background.
2. Insert SD card that contain > 50 music with different file format, > 500 pictures with different file format, >
20 videos with different file format.
3. Save 500 contacts in device, and 300 contacts in SIM card.
4. Set system language&region to local.
5. Installed applications in the device (Depends on the RAM condition)
2G RAM - install at least 50 applications
 3G RAM - install at least 90 applications
4G RAM - install at least 120 applications
7. Login email account that contain more than 100 emails in the inbox.
8. Encrypted particular application that going to perform testing.
9. Run application ‘Clean master’ in the background.
10. Enable auto sync option, login to Google account, Facebook, Line, Wechat or Messenger.
11. Turn on log. If testing using Qualcomm devices, please enable system dump as well.

Analysis/Comparison test is required for issues found. Refer to: App issues analysis)
ALL issues are required to report in RTC, including ColorOS issue, Android issue, Apps’ own issues, etc.
Bug report:
Summary 【Thirdparty】 【Application level (Super, popular, common)】【application package
name】Bug description
Project ID Corresponding project ID
Owner Corresponding project interface
Domain Third party
APK Version Mandatory (App version is always required for app issue)
Description Reference device: Remark the comparison test result (REF model, android version, chipset)
Downloads count: State the download counts on google play store.
Attachment Attach APK file
Reference Attach project required REF device result,same platform,same android version and same
phone’s chipsets,if it is low probability issue,make clear how many times tried and how many
phenomen times reproduced, attempt times should be the same as DUT
on

3.2.2 Built-in apps/functions:

Apps/functions preloaded after flashing devices/factory reset, developed/maintained by third party: Input
method(TouchPal), Browser(Opera), email(WPS), WPS office etc.
Bug report:
ROM tests: Apps separately provided by ROM Team; Task from ROM I/F.
Project ID DEV-ROM
Owner ROM I/F
APK Version Mandatory (App version is always required for app issue)

Project tests: Apps PRELOADED in firmware.

Project ID Corresponding project ID
Owner Corresponding project I/F
APK Version Mandatory (App version is always required for app issue)

3.2.3 String issues

3.2.3.1 Bug description
Domain Related functional module (e.g.: Camera, contacts)
Owner 彭燕燕
Severity Critical Main screen, Menu Level 1
Major Menu Level 2/3, Common functions
Minor Menu Level > 3
 Summary 【REGION - String/LANGUAGE - DOMAIN - ID: StringID】Description
DOMAIN for built-in or non-built-in third party apps should write down the
app name in English (TouchPal, Swype, Opera, WPS email, Zaypa, etc.)
Use summarized & clear words to classify the issue, such as: not translated
(not localized), wrong translation (meaning), inconsistent translation, garbled
meaning, capitalization problem, wrong spelling, messy code, punctuation
error, RTL, not displayed, incomplete display, layout error, layout misaligned,
wrong line-break, etc.
e.g.:
【AU - String/en-uk - Message - ID: 59112】'Agree & Continue' not fully
displayed【MY - String/my - Wi-Fi Direct - ID: None】Invitation message not
translated to Malay
Avoid to use uncertain or unclear words, such as:
 String is not proper
 The string displays not well
 String error in weather update menu in Hindi language
 Some string issues in OPPO Manager

Bug Describe Path, string id, expected results written in bug details (not only in screenshot,
it’s hard for people who don’t speak the language need to type.)
*Note: When you think some string needs improvement, please raise it in your
local group team for discussion and find a best solution.
Screenshot Mark the string in screenshot, with String ID written on it or take another
screenshot with *#4321# *#394321# string ID enabled

3.2.3.2 String issue classifications

String Issues Linguistic issues
Not localized
1. Vary with system Capitalization problem
language settings Wrong(garbled) translations
2. Can be fixed by just Grammar
update the translation Spelling error
in string database. Inconsistency
Wrong line-break
Punctuation
Messy code
Translation improvement
……
Layout issues that can be fixed by replacing with a shorter expression to fit
Wrong Layout/RTL
Misaligned/Truncation
Overlapped
Function Issues Following are function issue which may have been misunderstood as string
issue:
1. Must be fixed by Carrier operator name displaying wrong
modifying the source Font type: Inconsistent Font Type for Email Address Field and Password Field
 code, program logic, Data saving: Phone shows wrong name after save the contact
UI elements, etc. Data reading: SIM card showing number of contact is wrong.
Date/time format is not same as system settings: 04.03 20:44
Wrong directory path, file name, file type: When download file from yahoo
email, name of file displayed using Opera browser is different from Chrome.
Login address switched.
Call interface does not show numbers, logo, and name.
Browser does not fully load (website strings/images does not store in phone)
Long song name does not auto roll while playing. (Interface scrolling text
feature)

Note: If developer need to change the layout to fix the issue, tester need to change the Issue type to
Function issue.

3.2.3.3 String issue sources

ColorOS ROM apps (SMS, Camera, etc.) MUST be fixed
Built-in third-party apps (Email, WPS office, Keyboard, Browser, etc.)
Built-in Google Apps (GMS apps) May not be fixed
Non built-in third party apps Won’t/Can’t be fixed
Note: Always use REFERENCE device to confirm whether it is ColorOS string issue or third-party string issue
3.2.4.1 Function issues
1.For PDT OPPO case:【Case short name】【Region-Module】summary details
e.g.【NetworkFunction】【SG-Sim Toolkit】DUT do not have SimTool Kit
Application on the menu screen
Explain:
【NetworkFunction】--->According to the current test plan name to fill out,This is
the short name for our current test
plan<OS_FiledTest_NetworkFunction_V1.0_20170412>
【SG-Sim Toolkit】---> Indicating that Region is SG, module is SIM Toolkit
2.For Operator requirements:【OP Requirement Test-Operator name】【Region-
Summary
Module】Summary details
E.g. 【OP Requirement Test-Singtel】【SG-SMS】DUT take 50s more than REF
(Google Pixel) to send concatenated SMS (more than 120words).
Explain:
【OP Requirement Test-Singtel】-->Indicating that the content of the current test for
the operator Singtel Requirements
【SG-SMS】-->Region is SG and module is SMS
*Note if there is no test plan which covered the issue,when you raise bug,please
write summary as 【None】【Region-Module】summary details
Domain group Select the corresponding group
Domain Select correct correct domain
Module QT Test Team
Owner Local leader
Case ID Fill in with correct case ID
3.2.5 Audio issues
Refer to QT Audio Test Tutorial

3.3 Bug process flow and QT activities

SW DEV: Newly built, Reopened, Solving
QT: Create bug, To be verified, Rejected, Verified, Tracking
QT PM: Delayed, Refused, To be verified (QT Group Leader), To be confirmed (QT Group Leader)
3.3.1 To be Verified, Verified

**Note:
- Refer to flowchart above, most of the firmware version that we tested are PVT version.
- In special case after PVT Master branch version, task owner will mention in the task email what to do
with the bug.

QT processing time limit: ≤ 3 days (1 day for blocker/critical issues)

Verify on the firmware on the Resolve Version or latest version
Probability Times to verify Bug flow
on each
firmware
5 1 Pass: Change status to To be confirmed (QT Group Leader)
Fail: Change status to Reopen
4 >=5 1st version
3 >=20 Comment the firmware version/test times/data/results on RTC
2 >=30 Pass: Change status to Verified
1 >=50 Fail: Change status to Reopen
 2nd version
Comment the firmware version/test times/data/results on RTC
Pass: Change status to Verified
Fail: Change status to Reopen

3rd version
Comment the firmware version/test times/data/results on RTC
Pass: Change status to To be confirmed (QT Group Leader)
Fail: Change status to Reopen

** Required to add RTC comments for each verification (Results/data/firmware)

3.3.2 Reject, Tracking

QT processing time limit: ≤24h

In which conditions will my bug be rejected?
Bugs pending necessary information from QT such as logs, will be stated as Reject.
Bugs which were confirmed as not a bug by developer or HQ side may be stated as Reject.
1. Pending necessary information from QT such as logs, reference data, etc.
2. Bugs which were consider invalid (not a bug) by developer or HQ may be stated as Reject
What to do with a rejected bugs
1. Once all information required by developer has been provided on the bug, Change the state: Reject ->
Initialize.
2. For bugs which confirmed as not a bug, Change the state: Reject -> To be Confirmed (QT Group Leader).
3. If cannot confirm whether it is a bug, and need the UE confirm, please confirm with QT Tracking
personnel or QT I/F to change the bug owner the UE person of the current project.
3.3.3 Delayed, Refused
Confirm with developer/QT tracking personnel/QT PM:
Agree: Change state -> To be Confirmed (QT Group Leader)
Still consider as bug/risk: Change state -> Initialize/Reopen

3.4 Queries
3.4.1 Create query
3.4.1.1 Condition
New Query > Name > Project ID: Select xxxx > Creator: Add User
3.4.1.2 Result layout

3.4.2 Share query

Details > User Sharing > Add user to share this query
4 Test Report

4.1 Test report

Report
Bug list
Test cases

4.2 REPORT page

Firmware version Same firmware version format as used for submitting bugs
Stage EVT/DVT/PVT/MP
Reference devices All REF devices including OPPO and other brands’ models
Revised by Reports must be revised by team leader
Test result PASS
PASS with issues (minor issues which is acceptable)
FAIL (major and serious issues which will affect the normal usage)
TBD
N/A
Conclusion A brief conclusion is required to summarise the test results
Suggestion Suggestions to improve the test cases

4.3 BUGLIST Page

List ALL bugs encountered in this testing

4.4 Test cases and data

For ANY Fail results, MUST state the bug id and summary in comments
For ANY N/A or N/T results, state the reason. E.g.: Function not supported by operator.
For Pass with issues or Pass with observation, state the test result and why accepted.

4.5 Email
Subject:
Reply the original task email with the test reports.
An email with a unique subject/title is very likely to be ignored by the task owner.
Message body:
Explicitly describe the test results and other important information in the email.
Highlight the risk and inform regional manager/leader
DO NOT just attach files: not only for task email, but also for daily communication
Attachments:
Test reports
Other files if necessary
4.6 RDM
1.When you receive a task, you should log in to RDM, then you can see “my scope”, click,.
2. The red color means unread information.
 3. Click the red script and then you can read the task and load the attachment(“添加附件”means
add attachment), after confirm that you have received the task, you need to click “update”button and find task
region, change “Y”to “T”(means you are doing test), click “ok”

4.Task finished, you need to click “post comment”, and then follow this format“region+Y/N(Y

means finished)+PASS/FAIL(select pass or fail)

5.All the things finished, don’t forget click “report”button, and then if the result is ok, change “T”to”
√”， else change “T”to”R”, at the same time, you need to upload the attachments to the FTP address and here, at
last, click “ok”.
5 Work Norms

5.1 Task Arrangement & Operation

1. Plan
Leader should provide an expected due date when assign a task
Tester should set an ACCEPTABLE due date and feedback if no due date being assigned.
Inform Team Leader and set a new ACCEPTABLE date/time if unable to complete the task on time.
Plan change:
If there is any new task which may affect scheduled plan, testers should discuss with team leader and related
person to confirm if the plan change is acceptable and make new arrangement, including but not limited to:
- Make a new schedule and inform all -> Archive the work at hand -> Start new task -> Finish new task
-> Continue with previous work
- Hand over unfinished task to other colleagues and track the results
QUALITY of work should not be affected by any plan changes.

2. Any testing instructions/tasks which are not clear, PLEASE ASK immediately.

3. All the official task are send out via email. Verbally task assign can be rejected.

4. Outstation requirement: Please pass down all the unfinished tasks status to local employee, local region
manager, your team lead and manager via email.

5. Daily Summary Report: Send daily report in QQ group. Standard format for daily report as per below -
[Previous day task]
[Bug submit, closed]
[Today’s Plan]

6. Results/Reports/Progress by Email
All testing results/reports and progress/schedule MUST SEND via email to team leader and manager.
For long-term task which takes more than 1 day, feedback the progress to team leader every day.
All reports MUST be COMPLETE, CORRECT and CLEAR to understand.

7. Risk control
Report INSTANTLY if critical issues found during testing.
If there’s any possible delay, please notice team leader immediately and highlight the risk.

8. Bug report
In principle, it’s required to submit bug on the same day that the bug is found.
Inform leader to push the bug solving.

9. Hardware resources availability:

If a task has been assigned to testers and is lacking of testing resources, for example, devices, SIMs and etc.,
PLEASE GO and FIND immediately, DO NOT WAIT for others to provide to you.
If the lack of resources MAY affect the test plan/schedule, inform team leader for help immediately. For
example, the driver is not confirmed to be available for driving test.
 10. Resource Sharing
Firmware downloaded from FTP MUST UPLOAD to QT-Server.

11. For FT Team, ALL bug’s logs, screenshots and videos MUST UPLOAD to \\QT-SERVER\Firmware\Logs\FT. If
there are new logs, screenshots and videos for previous submitted bugs, state the date time and brief
description.

5.2 Off Day

1. Annual leave of X days should be applied 2X working days in advance.
2. Emergency Leave: CALL team leader to apply emergency leave with reasonable grounds.
3. For any leave taken, must make sure that
- inform team leader
- inform other colleagues who is collaborating closely with you or whose work will be affected by your
absence are informed
- hand over the work at hand
- urgent issues will not be affected
- At last Email/MO to inform all team members and related person about your leaving period and
handover arrangement before off day

5.3 Privacy & Confidentiality

5.3.1 PC/Laptop
1. MUST set password for PC/laptop.
2. LOG OFF laptop or PC if leaving your seat, no matter leaving for short or long period of time.
3. All testing related documents, including scheme/plan/test cases/data/reports/etc. are confidential.
Printed sensitive information must be safe kept or destroyed.
5.3.2 Testing devices
1. KEEP ALL devices in drawer if leaving your seat, especially lunch time or before leaving office.
2. For battery life/standby test, keep devices in enclosed/isolated spaces.
3. Sample devices which are UNLAUNCHED need to REGISTER with Team Leader before bringing out for testing.
It is PROHIBITED to bring out of office overnight without permission of QA Manager.
4. Any testing devices are PROHIBITED to lend to other departments without authorization.
5. For devices borrowing and lending, tester need to apply with Device administrator. Signature is required for
all records. (Including Managers’)
6. Inventory at intervals of not more than one month is required. (Device administrator)
7. Compensation is required for lost devices. (Device borrower)
8. For devices which need to remove cover, team leaders send an email application to Regional Manager to
confirm. Device administrator help to remove the cover after getting confirmation from manager and
remark in inventory list/system.

5.4 Penalties
1. Penalties will be given according to KPI rule, company policy or in accordance with conventional provision.

Reliability and Efficiency