Security Classification:

Document History
Document Location
File Name Location
HNVN_SD_008_10_Template_GUI_TestCase Process Asset Library

Document Version History

Version Date Author Details

Approvers
Distribution List
Name Role Signature Date
ty Classification: Confidential

Details

Version
 Test Case

Project Reviewer
Creator Review Date
Approver
Approve Date

Record of change
Effective Date Version Change Item *A,D,M Change description
<Date when these
changes are effective>
 Reference
<List of documents which are
refered in this version.>
 GUI Test
<<Client Name>>

Build Name [Build Name - Version XXX]

Tested by [Name of executor]

Tested [Date of executing]

Date

Test Result Passed Failed

[Build Name - 17 0
Version XXX]

ID Checklist Category Step

1 General Screen
Layout
2 General Screen
Layout
3 General Screen
Layout
4 General Screen
Layout
5 General Screen
Layout
6 General Screen
Layout
7 General Screen
Layout
8 Date Entry Fields
9 Date Entry Fields

10 Date Entry Fields

11 Date Entry Fields

12 Date Entry Fields

13 Date Entry Fields

14 Dialog box (for

window aplication)
15 Dialog box (for
window aplication)
16 Dialog box (for
window aplication)
17 Dialog box (for
window aplication)
18 Dialog box (for
window aplication)
19 Content
20 Content

21 Content

22 Content
23 Content
24 Content
25 Alert standards

26 Alert standards
27 Alert standards
28 Alert standards

29 Alert standards

30 TAB
31 TAB

32 TAB
33 TAB
34 Screen Size

35 Screen Size
36 Screen Size

37 Paging

38 COLOR
39 COLOR

40 COLOR
41 LINK
42 LINK
 Security Classification:

GUI Test
<<Project Name

rsion XXX]

or]

g]

Passed in previous
N/A Not Run Blocked
builds
1 21 0 3

Expected Output Test Data Bug ID Note

All buttons, labels, fields should be aligned vertically and
horizontally and consistent across all applications
Are all the fields prompt spelt correctly?

Are fonts too large or too small to read?

Labels on buttons should be consistent and have same

meanings across all applications and screens.
Buttons should be same width and height.

The mouse pointer will be in the first input field.

Essure that all windows have a consistent look and feel.

Ensure all fields are disabled in read-only mode

Assure that leap years are validated correctly & do not
cause errors/miscalculations
Assure that month code 00 and 13 are validated correctly &
do not cause
errors/miscalculations
Assure that day values 00 and 32 are validated correctly &
do not cause errors/miscalculations
Assure that Feb. 28, 29, 30 are validated correctly & do not
cause errors / miscalculations ( consider on leap-year)
Length of the data entry field displayed should equal the
commonly used length of the corresponding database field.
Ensure each dialog box has a title bar

Ensure each dialog box has a default non-destructive

pushbutton that closes dialog box.
Press Esc to exit

Assure that all dialog boxes have a consistent look and feel.

Do not allow resizing, minimizing, or maximizing of dialog

boxes.
All fonts are to be the same and consistance
Are all the screens prompt specified in the correct screen
font?
Does content remain if you need to go back to a previous
page, or if you move forward to another new page?
Is all text properly aligned?
Is the text in all fields specified in the correct screen font?
Is all the heading the same alignment?
Only have prompt boxes for when there are errors or an
action has not happened successfully.
Do the alert icon and message fit the situation?
Is all the error message text spelt correctly?
Warning and Confirmation message will follow Window
standards for icons, sounds, themes, etc.
Are the warning message/field name consitance in all
forms?
Are all read-only fields avoided in the TAB sequence?
Does the Tab Order specified on the screen go in sequence
from Top Left to bottom right? This is the default unless
otherwise specified.
Use SHIFT+TAB to move focus backwards
On open of tab focus will be on first editable field
The system should be able to handle multiple screen
resolutions, with the minimum being 1024 * 768 and the
preferred being 1280 * 1024 and 1366 * 768.
It should be possible for the screen size to be adjustable
The system should work on 4:3 and widescreen (16:9 and
16:10) monitors
The paging will apply new value when loosing focus on
Number of items per page field
Are hyperlink colours standard?
Are the screens and field colour adjusted correctly for non-
editable mode?
Are all the buttons are in standard format and size?
Check that the link takes you to the page it said it would.
Are all referenced web sites or email addresses
hyperlinked?
ty Classification: Confidential

<<Client Logo>>

<<Project Name>>

Test Result

Test Environment [Build Name - Version XXX]

Windows 7 -IE8 Passed in previous builds

Windows 7 -IE8 Not Run

Windows 7 -IE8 N/A

Windows 7 -IE8 Not Run

Windows 7 -IE8 Not Run

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed in previous builds

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed
Windows 7 -IE8 Not Run
Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed
Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed
Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed

Windows 7 -IE8 Not Run

Windows 7 -IE8 Passed
Windows 7 -IE8 Passed in previous builds
1. Website

Check layout tổng quan

Kiểm tra layout

1. Kiểm tra kích thước, màu sắc, hình ảnh, icon…

2. Kiểm tra màu chữ, font chữ của link khi mouse hover, click..
3. Kiểm tra việc phân chia các phần: header, footer, body

4. Trường hợp có ảnh hiển thị trên size thì ảnh phải được resize theo cả 2 chiều

5. Kiểm tra font chữ mặc định của hệ thống

Kiểm tra giá trị default

1. Kiểm tra sự hiển thị của textbox, textarea… có dòng chữ mờ ở bên trong không. Khi user click vào
được nhập vào màu chữ phải rõ chứ không mờ như chữ default.
2. Kiểm tra việc hiển thị mặc định của các trường combobox, listbox (Thường hiển thị giá trị có sẵn tr
3. Kiểm tra các giá trị checked default checkbox, radio button.
4. Kiểm tra sự hiển thị mặc định của table khi không có bản ghi nào.
5. Phải có kí tự * ở các trường bắt buộc. Khi thông báo lỗi ở trường nào thì phải focus ở trường đấy.

6. Khi chuyển tab, các trường bị disable thì không được focus vào.

7. Kiểm tra mặc định của các button khi được disable phải để ở dạng xám mờ, khi mouse hover thì k

Các chức năng của đối tượng

Link

1. Link từ trang này đến trang khác phải hoạt động

2. Link từ trang này đến trang khác phải đúng trang

Textbox

1. Kiểm tra các giá trị biên của textbox

2. Kiểm tra các giá trị hợp lệ
3. Kiểm tra khi nhập các kí tự HTML, Javasript (vd: <html>abc</html> hoặc <script> alert ('Hello') </
 4. Kiểm tra khi nhập các kí tự đặc biệt (kí tự @, ~,!,...)

5. Kiểm tra khi nhập giá trị SPACE đầu, cuối/ hoặc để trống
6. Kiểm tra khi thực hiện CTRL+V; CTRL+C; CTRL+X
7. Kiểm tra khi ấn nút TAB thì con trỏ có di chuyển giữa các textbox theo thứ tự từ trái sang phải, từ t
8. Kiểm tra khi ấn SHIFT+TAB thì con trỏ có di chuyển giữa các textbox theo thứ tự ngược lại, từ phải
textbox Readonly: Tất cả các trường và điều khiển đều không có hiệu lực trong chế độ Read_only kh
9. Text area: Kiểm tra các giá trị biên của field

Selection box

1. Kiểm tra chức năng Sort của các cột trong phần danh sách
2. Kiểm tra các nội dung trong selection box đúng và đủ

Combobox

1. Các đối tượng trong combobox được sắp xếp theo thứ tự alphabet.
2. Cho phép sử dụng phím lên, xuống và phím enter để lựa chọn các đối tượng.
3. Cho phép nhập tìm kiếm theo chữ cái đầu tiền của danh sách các đối tượng
4. Khi nội dung trong nó dài => thêm scroll

List box

1. Dùng chuột để chọn 1 đối tượng trong danh sách

2. Cho phép nhập tìm kiếm theo chữ cái đầu tiền của danh sách các đối tượng
3. Danh sách các đối tượng được sắp xếp theo bảng chữ cái
4. Hiển thị scroll bar ngang và dọc để có thể xem hết được nội dung

Checkbox

1. Kiểm tra nếu Click 1 lần và 2 lần hộp checkbox

2. Kiểm tra có thể không chọn checkbox hoặc chọn một giá trị
3. Kiểm tra chọn nhiều hộp checkbox

Button

1. Kiểm tra xử lý khi click vào button này (vd: chuyển đến trang khác, thêm, cập nhật, xoá...)

Trường DateTime
 1. Kiểm tra ngày giờ của chức năng lấy theo ngày giờ server hệ thống hay client
2. Kiểm tra Date Picker có sử dụng được không. Click chọn có chọn được không.
3. Kiểm tra tính ràng buộc các trường kiểu Date (ngày bắt đầu <= ngày kết thúc)
4. Trường hợp được nhập datetime thì kiểm tra giá trị ngày thứ 31 của tháng 4, 6, 9, 11 có 30 ngày.
5. Trường hợp được nhập datetime thì kiểm tra giá trị ngày 29 của tháng 2 có 28 ngày - năm không
6. Trường hợp được nhập datetime thì kiểm tra giá trị ngày 29 của tháng 2 có 29 ngày - năm nhuận.

Edit text kiểu số

1. Kiểm tra nhập phép chia cho 0

2. Kiểm tra nhập giá trị biên và ngoài biên
3. Kiểm tra nhập giá trị <=0 đối với các trường yêu cầu số nguyên dương
4. Kiểm tra nhập số thập phân đối với các trường yêu cầu nhập số nguyên
5. Kiểm tra nhập dấu currency khác với định dạng ("." hoặc ",")
6. Kiểm tra khi thay đổi dấu currency trong Regional Setting

Edit text kiểu Link

1. Kiểm tra khi đang ở trang cuối cùng thì link chuyển đến last page bị disable
2. Kiểm tra khi đang ở trang đầu tiên thì link chuyển đến first page bị disable
3. Kiểm tra khả năng lưu giữ điều kiện tìm kiếm khi phân trang
4. Kiểm tra chức năng của các liên kết này khi click vào (vd: xem trang được chuyển đến có chính xác

Table

1. Kiểm tra hiển thị table khi không có bản ghi hoặc khi đã có bản ghi rồi
2. Kiểm tra chức năng sort của table

Scroll bar

1. Kiểm tra hướng của scroll bar (ngang, dọc)

Pop-up message; dialog; alert

1. Kiểm tra pop-up msg được hiển thị ở phía client hay server.
2. Kiểm tra thứ tự thông báo lỗi của các hộp thoại trên trang khi không kết nối được tới DB phải có t
trình duyệt. Phải có thông báo lỗi khi xảy ra lỗi nhập liệu trên màn hình.

Các xử lý khác

Zoom in
 1. Khi nhấn vào biểu tượng Zoom in . Giao diện hiển thị nhỏ lại tùy theo độ zoom mà không bị lệch g
2. Khi nhấn Ctrl+ Chuột theo chiều hướng vào trong. Giao diện hiển thị nhỏ lại tùy theo độ zoom và

Zoom out

1. Khi nhấn vào biểu tượng Zoom out. Giao diện hiển thị to lên tùy theo độ zoom mà không bị lệch g
2. Khi nhấn Ctrl+ Chuột theo chiều hướng ra ngoài. Giao diện hiển thị to ra tùy theo độ zoom và khô

Độ phân giải màn hình

1. Thay đổi độ phân giải màn hình. Giao diện hiển thị không bị lệch, màu sắc, dữ liệu... được giữ nguy

Brower- version

1. Ví dụ như IE, Firefox, Chrome, Opera mini .. Và các vesion tương ứng của chúng.

Session

1. Kiểm tra session: Sau khi thực hiện xong 1 action phải xóa session nếu không sẽ dẫn tới dữ liệu cũ

Cookie

1. Kiểm tra việc xử lý của cookie

Check mạng

1. Hiển thị thông báo đến user khi mất mạng (dưới dạng alert, dialog,..)

Phân trang

1. Kiểm tra khi đang ở trang cuối cùng thì link chuyển đến last page bị disable
2. Kiểm tra khi đang ở trang đầu tiên thì link chuyển đến first page bị disable
3. Kiểm tra sự kiện next , previous trang khi có nhiều trang. Di chuyển đến trang tiếp theo trang trướ
4. Kiểm tra khi nhấn vào một trang bất kì. Di chuyển đến trang tương ứng

Search

1. Search theo toán tử or hoặc not (search thông tin với riêng từng giá trị hoặc phủ định của giá trị tr
2. Search theo toán tử and (tạo ra các bộ tương ứng để thực hiện search)
3. Phân biệt chữ hoa chữ thường, tiếng việt, tiếng anh, .. Khi thực hiện test
4. Khả năng lưu giữ điều kiện tìm kiếm khi thực hiện phân trang
2. Mobile

Cài đặt

Kiểm tra cài đặt

1. Kiểm tra app có được cài đặt vào thiết bị thành công không
2. Kiểm tra có icon của app trong thiết bị không? Icon có đúng không?

Kiểm tra update app

1. Kiểm tra sau khi update app dữ liệu có còn lưu không?

Kiểm tra gỡ cài đặt

1. Kiểm tra sau khi delete app dữ liệu và các phần liên quan tới app có còn trong device hay không?

Khởi động app

Kiểm tra khởi động app

1. Lần khởi động đầu tiên: có thể mất thời gian nếu cần load dữ liệu cho app
2. Lần khởi động sau: thời gian cần để khởi động: <5s, nếu sau 5s thì cần phải có message thông báo

App Flow

Kiểm tra điều hướng app

1. Kiểm tra app có hoạt động theo đúng flow thiết kế không? (ví dụ click button A có đi tới màn hình

UI

Kiểm tra tổng quan

1. Kiểm tra vị trí các trường, đối tượng có đúng vị trí hay không
2. Kiểm tra các chữ trên màn hình có viết đúng chính tả không
3. Kiểm tra các control điều khiển có được căn đúng không: không lệch, đúng kích thước….
4. Kiểm tra màu nền, hình nền của app có được set đúng không
5. Kiểm tra việc hiển thị app khi quay màn hình(ngang, dọc)
6. Kiểm tra tiêu đề screen
7. Kiểm tra thanh cuộn (màu sắc, hoạt động)

Kiểm tra Default

 1. Kiểm tra giá trị, màu sắc, kích cỡ, kiểu chữ của giá trị default của listbox
2. Kiểm tra giá trị, màu sắc, kích cỡ, kiểu chữ của giá trị default của listview
3. Listview kiểm tra số bản ghi ảnh hưởng đến scrollbar và link trang như thế nào
4. Kiểm tra giá trị, màu sắc, kích cỡ, kiểu chữ của giá trị default các trường edittext (không có; có dòn
mặc định của hệ thống,...)
5. Kiểm tra giá trị default của trường combobox (không có; có giá trị: Nam (trường giới tính), Hà Nội
6. Kiểm tra giá trị checked default checkbox, radiobutton

Textview

1. Kiểm tra chữ đúng định dạng chưa: về màu sắc, cỡ chữ, font chữ,…
2. Kí tự phải được căn trái, trừ trường hợp có yêu cầu đặc biệt

Edittext kiểu text

1. Kiểm tra khi nhập kí tự đặc biệt, mã html, script.

2. Kiểm tra khi nhập kí tự "space"(cả đầu, cuối)
3. Kiểm tra khi để null (trường bắt buộc mới yêu cầu không null)
4. Kiểm tra phân biệt chữ hoa chữ thường không?
5. Kiểm tra maxlengh
6. Kiểm tra chữ đúng định dạng chưa: về màu sắc, cỡ chữ, font chữ,…
7. Kiểm tra kí tự có căn trái sau khi nhập không; Số căn giữa; Tiền căn phải (trừ trường hợp yêu cầu k

Edittext kiểu number

1. Kiểm tra số phải được căn phải, trừ trường hợp có yêu cầu đặc biệt
2. Kiểm tra sự không cho phép nhập khoảng trống ở đầu và cuối number
3. Kiểm tra sự không cho phép nhập chữ và kí tự đăc biệt
4. Kiểm tra maxlengh
5. Kiểm tra giá trị hợp lệ
6. Kiểm tra giá trị biên

Edittext kiểu date

1. Hiển thị đúng định dạng chưa? (dd/mm/yy, dd/mm/yyyy…)

2. Kiểm tra Date Picker có sử dụng được không. Click chọn có chọn được không.
3. Kiểm tra tính ràng buộc các trường kiểu Date (ngày bắt đầu <= ngày kết thúc)
4. Trường hợp được nhập datetime thì kiểm tra giá trị ngày thứ 31 của tháng 4, 6, 9, 11 có 30 ngày.
5. Trường hợp được nhập datetime thì kiểm tra giá trị ngày 29 của tháng 2 có 28 ngày - năm không
6. Trường hợp được nhập datetime thì kiểm tra giá trị ngày 29 của tháng 2 có 29 ngày - năm nhuận.

Button
 1. Kiểm tra kích thước, background button
2. Kiểm tra font - màu - kích cỡ text
3. Kiểm tra button xử lý đúng chức năng hay chưa

Checkbox

1. Kiểm tra giá trị label tương ứng checkbox đúng chưa

Radiobutton

1. Kiểm tra số lượng giá trị của radiobutton

Listview

1. Kiểm tra màu nền của các phần tử của listview (tùy dự án)
2. Kiểm tra cách sắp xếp các phần tử trong listview có yêu cầu không? Theo thứ tự nào
3. Kiểm tra số lượng bản ghi (chú ý scrollbar, phân trang)

Combobox

1. Kiểm tra kích cỡ, kiểu chữ, màu sắc text trong combobox
2. Kiểm tra kích cỡ, màu nền combobox
3. Kiểm tra danh sách giá trị trên combobox có đúng không
4. Kiểm tra sự kiện chọn giá trị combobox đúng hay không

Dialog

1. Kiểm tra tiêu đề, nội dung, nhãn message (kích thước, màu, vị trí,...)

Sự gián đoạn

Có cuộc gọi đến

1. Kiểm tra khi app đang sử dụng thì có thông báo cuộc gọi đến không?
2. Kiểm tra sau khi nghe xong cuộc gọi, vẫn có khả năng quay lại app và không bị mất dữ liệu

App ở chế độ chạy background

1. Khi đang ở chế độ chạy ở nền background thì sau khi trở lại app vẫn hiển thị đúng màn hình trước

Trường hợp Pin yếu

1. Có thông báo Pin yếu và app vẫn có thể hoạt động bình thường.
Cắm sạc

1. Thực hiện app trong khi cắm sạc app vẫn hoạt động bình thường

Trường hợp khác

1. Thực hiện app trong khi quay phim, chụp hình, alarm,.. app vẫn hoạt động bình thường

Device

Nhiều device

1.Kiểm tra sự hoạt động của app trên nhiều thiết bị: về giao diện và chức năng (chú ý các device có kích th
với ứng dụng)

Phiên bản tablet

1.Kiểm tra cả trên tablet nếu yêu cầu cả phiên bản tablet

Version OS

1. Tùy dự án để kiểm tra các version nằm trong và ngoài yêu cầu tương thích.

Ứng dụng cần internet

Test theo mạng

1. Kiểm tra với nhiều mạng khác nhau: wifi, 3G, 4G...

Độ ưu tiên mạng

1. Kiểm tra trong trường hợp có cả Wifi và 3G thì phải ưu tiên dung wifi (không bị mất tiền, Kb của 3

Chuyển mạng

1. Chuyển mạng - từ 3G sang Wifi (gặp trường hợp ưu tiên), ngược lại (mất mạng wifi-có thông báo)

Mất mạng

1. Trường hợp sử dụng mạng Wifi bị mất mạng: không thực hiện được các chức năng cần đến mạng

Share dữ liệu

1. Share dữ liệu thông qua bluetooth, 3G, Wifi,..

Media
1. Kiểm tra ON/OFF âm thanh, nhạc nền app
2. Kiểm tra tính đồng bộ âm thanh với các thao tác app
3. ON/OFF âm của device và kiểm tra âm của app
4. Kiểm tra chế độ rung nếu có
5. Kiểm tra âm thanh của app khi chạy đồng thời ứng dụng phát nhạc và ON âm thanh app
6. Kiểm tra khi đang phát nhạc trên device, khởi động app, nhạc có bị tắt (đóng) đi không

Hao pin
1. Kiểm tra tính hao pin của app

Tốc độ app
1. Thỏa mãn yêu cầu người dùng

Lựa chọn ngôn ngữ

1.Kiểm tra khi lựa chọn ngôn ngữ app có chạy đúng theo ngôn ngữ đã chọn không

Folder lưu trữ

1.Kiểm tra dữ liệu app lưu trữ có đúng folder chưa
Test Result

P
P

N/A

P
P
P
N/A

P
P

P
P
P
P

P
N/A
N/A

N/A
P

P
N/A

P
P
P
N/A

P
P
P

P
N/A
P
P
P
P
P

N/A
N/A
N/A
N/A
N/A
N/A

F
F
P
P

P
N/A

N/A

P
P
P

P
P

N/A

N/A

F
F
P
P

N/A
N/A
N/A
P
 Test Case- Instruction

1. PURPOSE
Test Case is a set of test inputs, execution conditions, and expected results developed for particular objective, such as to exerc
The purpose of the Test Case is to identify and communicate the conditions, which will be implemented and are necessary to v
QC will perform tests and give the result in the test case.

2. How to Use
Cover sheet: Update the history information of the test case and list all test case name in the file. Each function has

Some special sheets:

Common Checklist Each function has a column in this checklist. QC is to check which items are verified in each module.
Smoke Test Some positive test cases will be defined for each build. QC will write the test case when receive the re
End2End Test Each test case will go through some functions. It is to make sure that all functions are integrated corre
GUI Checklist It depends on the testing technique in the test plan, the GUI checklist will be used to verify the whole s
Bug list The purpose of this sheet is to create the chart in the "bug status" sheet.
Bug status The chart will be copied to the weekly report or final summary report.
Bug Trend The chart will be copied to the weekly report or final summary report.

3. Test Result
Passed: The actual result is met the expected result
Failed: The actual
run such as:result is NOT met the expected result
- Because of
another bug.

Not Run:
N/A The function has not been implemented in the current release (out of scope)
Not Regression The actual result is met the expected result in previous build, not to be regression test in last build

4. Tips
4.1 Bug is not met any case in the test cases
During testing, the QC is able to find a bug which is not met any case in the test case. In this situation
The step: is the step to reproduce bug.
The expected result: mention the actual and expected result of the bug

Test case #18: Ad-hoc testing

Detail the task as
the bug description Actual result:
-
-
Expectation:
-
-

4.2 In the build 2, does the team need to re-test all cases which have been tested in build 1?
Some cases are in passed, failed, Not Run in the build 1.
 In build 2, the team just needs to verify the failed cases and Not Run cases in build 1.
- If the team does not test the passed case in build 1, Just keep blank for the cases which are passe
- If the team is really re-tested the passed cases in build 1, it is OK to set "Passed/Failed" in the resu

4.3 A Test case has 100 cases. In the build 1, the team completes testing 60 cases and the t
The team needs to deploy the new package and continue testing the rest of cases (40 cases) of the te
The result (passed/Failed) is still enterred in the build 1.
Te result Passed in build 1 will be change to Not Regression in build 2 if they aren't re_tested in build

4.4 How many expectation is there in a case?

Should keep 1 expectation for a cell in the expecation.
There is no problem if a step has no expecation.

4.5 There are many repeat information in a step of the test case such as go to the URL, logi
Is there any way to reduce the step?
There are two ways to reduce the steps in the test cases:
a. Put the general information or common steps in the Precondition field in the top of test cas
b. Just enter detail information in some first cases. In other cases, it can say "go to xxx page

4.6 How to write a good Test case?

Tests only one thing: Always make sure that your test case tests only one thing, if you try to
it becomes very difficult to track results and errors.
Organize your test cases consistently: You can organize your test cases in many ways ho
same pattern to organize you test cases.

Write independent test cases: Your test cases should not have dependency on other test c
it in any order without any dependency on other test cases.
Write simple case: No unnecessary steps should be included in it. Don't write any case which
Resuable: The test case can be re-run for another purpose.
Traceable: Don't test more than requirement. The case should be traceable to requirements

4.7 Do we need to write the detail of test case for GUI verification?
If there is no special requirement, don't need to spend more time to write what will be tested
Just update the GUI checklist what we intend to test. During testing, the QC will have some a

4.8 There are only 5 builds in the template. What will we do if we have more than 5 builds d
Just create the build 6 next to build 5 and so on.

4.9 Do we have fixed the expectation in the common checklist?

No. The expectation is for a standard system. If the project has any special requirement, it sh

4.10 How many cases is it enough for a function?

It depends on the strategy in the test plan.

4.11 Is the test case template support for regression test and smoke test?
There are two ways for writing the cases for regression test and smoke test.
1. create a "smoke test" column next to "Test data" column. According to the test plan, the Q
2. create a "smoke test" sheet to put all cases for running the smoke test.
 The same idea is for regression test.

4.12 Is there any special requirement for call the build as build 1, build 2, build 3, build 4, bu
No, The build name can be updated as the CM plan of the project.
Instruction

lar objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
ented and are necessary to verify successful and acceptable implementation of the project.

e in the file. Each function has a sheet. Generally, each sheet is test case of a UC

are verified in each module.

test case when receive the release package.
functions are integrated correctly.
l be used to verify the whole system in different environment.

egression test in last build

the test case. In this situation, QC need to add the case into the related function as an ad-hoc case.

een tested in build 1?

ses in build 1.
for the cases which are passed in the build 1 in the result of build 2.
set "Passed/Failed" in the result of build 2.

ng 60 cases and the team received the new package. What will the team do?
st of cases (40 cases) of the test case.

they aren't re_tested in build 2

as go to the URL, login to the system, click on ABC link,…

n field in the top of test case.

it can say "go to xxx page"

s only one thing, if you try to test multiple conditions in one test case

est cases in many ways however you should always follow the

dependency on other test cases, i.e You should be able to execute

Don't write any case which has more than 10 steps.

traceable to requirements and/or HvN standard testing.

o write what will be tested for each element in the GUI.

ng, the QC will have some actions to make sure that it is make sense.

more than 5 builds during testing?

ny special requirement, it should be updated.

smoke test.
rding to the test plan, the QC will set "Yes/No" for smoke test.
d 2, build 3, build 4, build 5?