# Tiêu chí   Quy ước
1 Project setting Module code Tên viết tắt chữ hoa của chức năng Ví dụ chức năng chuyển tiền
- Module code = CT
- Module name = Chuyển tiền
=> Leader khai báo đồng bộ 1 format cho tất cả các chức năng
2 Teamplate testcase auto Đối với các trường bắt buộc 1. Phạm vi các chức năng sẽ auto
2. Kế hoạch phân bổ nhân sự cho từng chức năng
3. Mốc timeline chung cho từng GĐ/ gói, phạm vi yêu cầu
4. Mốc timeline chi tiết cho từng chức năng với từng nhân sự đảm nhiệm
3 Đối với trường APPLICATION_MODULE Đúng mã code của module mà leader đã khai báo trên Project
4 CODE của share steps Theo định dạng HDH_ST_XXX
trong đó;
- HDH gồm: IOS, AND, WEB
(webclient), API, BO, BE
- ST: viết tắt của từ share steps
- XXX: 3 số tự nhiên tự tăng theo thứ tự (đảm bảo không trùng nhau)
VD: AND_ST_001
5 CODE của test scenario Theo định dạng HDH_SC_ModuleCode_XXX trong đó;
- HDH gồm: IOS, AND, WEB
(webclient), API, BO, BE
- SC: viết tắt của từ scenario
- ModuleCode ; code module của chức năng đã khai báo trên project
- XXX: 3 số tự nhiên tự tăng theo thứ tự (đảm bảo không trùng nhau)
VD: AND_SC_CT_001
6 CODE của test case Theo định dạng HDH_TS_ModuleCode_XXX trong đó;
- HDH gồm: IOS, AND, WEB
(webclient), API, BO, BE
- SC: viết tắt của từ scenario
- ModuleCode ; code module của chức năng đã khai báo trên project
- XXX: 3 số tự nhiên tự tăng theo thứ tự (đảm bảo không trùng nhau)
VD: AND_TS_CT_001
7 CODE của test suite Theo định dạng HDH_TS_ModuleCode_XXX trong đó;
- HDH gồm: IOS, AND, WEB
(webclient), API, BO, BE
- SC: viết tắt của từ scenario
- ModuleCode ; code module của chức năng đã khai báo trên project
- XXX: 3 số tự nhiên tự tăng theo thứ tự (đảm bảo không trùng nhau)
VD: AND_TS_CT_001
8 PRECONDITIONS Tất cả những case có yêu cầu điều kiện cần thiết để chuẩn bị trước khi run đều phải mô tả đầy đủ cột này
9 INPUTS Tất cả các case có tham số input đầu vào đều phải mô tả cột này
10 DIRECTORY_PATH Ghi đúng cấu trúc mà thư mục cần lưu tương ứng
11 STEPS Bắt buộc nhập (để sử dụng cho maintain sau này)
'- Với bước nào gọi share steps thì sẽ có đính kèm code share đó
12 Cấu hình cho case login Đối với các hệ thống mà 1 acc chỉ được login trên thiết bị tại 1 thời điểm Yêu cầu sẽ phải cấu hình tham số input username/ password là biến môi trường và có setup riêng cho từng device
NOTE: Nếu không đúng cấu hình theo device sẽ phát sinh khi chạy batch, 1 acc sẽ bị lấy để run đồng thời cho 2 thiết bị dẫn đến sẽ có 1 thiết bị fail do acc bị logout
13 Cách đặt tên biến Đối với case chuyển tiền khác chủ Yêu cầu check số tiền + đối với tài khoản hưởng Data số tài khoản hưởng của tài khoản nhận phải khác với account đang được setting cho các device trong batch
14 Biến input Khai báo theo format: input_tên biến
- với tên biến:
+ Nếu là field trên UI thì đặt là tên viết tắt của trường đó
Ví dụ: trên UI có trường số tài khoản nguồn thì tên biến sẽ là input_stkn
+ Nếu không phải là field trên màn hình: đặt tùy ý nhưng mang tính dễ hiểu
15 Biến output Khai báo theo format: output_tên biến
+ Nếu là field trên UI thì đặt là tên viết tắt của trường đó
Ví dụ: trên UI có trường số tài khoản nguồn thì tên biến sẽ là output_stkn
+ Nếu không phải là field trên màn hình: đặt tùy ý nhưng mang tính dễ hiểu
16 Biến sử dụng trong suite Trong suite được phép gọi đến nhiều scenario
- Các biến của scenario được gọi trong suite bắt buộc phải khai báo khác nhau
17 Batch Cấu hình device Yêu cầu run đủ các các version OS theo yêu cầu
18 Quy ước Tổ chức version testcase, test scenario, test suite, share steps Khai báo testcase, test scenario, test suite, share steps theo version đang phát triển chức năng
19 Khi có update ảnh hưởng đến UI của các chức năng cũ 1. Phạm vi logic cập nhật
- Chỉ update logic server
- Chỉ update giao diện client
- Update cả logic server + giao diện client
2.. Đánh giá phạm vi ảnh hưởng auto: gồm những share steps, scenario, testcase, test suit nào bị ảnh hưởng
3. Đánh giá điều kiện update force hay không force ??
=> Yêu cầu:
- Clone 1 bản mới và chính sửa trên bản clone chứ không chỉnh sửa trên ver cũ
- Sửa lại ver của bản clone đúng với ver hiện tại
- Nếu phạm vi chỉ update logic server: giữ nguyên code cũ chỉ chạy lại trên ver mới
- Nếu phạm vi chỉ update giao diện client
+ Clone các phạm vi share steps, scenario, testcase, test suite có ảnh hưởng + đổi tên ver tương ứng
+ Chỉnh sửa lại logic trên bản clone ver mới, không chỉnh trên ver cũ
- Nếu phạm vi update cả logic server
+ giao diện client
+ Clone các phạm vi share steps, scenario, testcase, test suite có ảnh hưởng + đổi tên ver tương ứng
+ Chỉnh sửa lại logic trên bản clone ver mới, không chỉnh trên ver cũ
20 Quy ước Tổ chức và Đặt tên Element Repository Repository 1. Tổ chức repository theo level:
Nền tảng > Chức năng > Màn hình cấp 1 > Màn hình cấp n
VD: IOS > Chức năng Chuyển tiền > Màn hình khởi tạo > Màn hình danh sách
- Nếu trong trường hợp có trong chức năng có những chức năng nhỏ hơn thì  sẽ có 2 các tổ chức
+ Kho của chức năng nhỏ sẽ nằm trong chức năng lớn
VD: IOS > Chức năng Chuyển tiền > Chức năng Chuyển tiền trong nước > Màn hình khởi tạo
+ Trải phẳng các chức năng đó ra để làm kho chức năng to nhất
VD: IOS > Chức năng Chuyển tiền trong nước > Màn hình khởi tạo
2. Đặt tên repository
- Nền tảng: Đặt tên theo đúng nền tảng
VD: iOS, Android, Web, ...
- Chức năng: Đặt tên theo đúng chức năng của kho
VD: Chức năng Chuyển tiền, Chức năng Tất toán, ...
- Màn hình: Đặt tên theo màn hình quản lý element
VD: Màn hình khởi tạo, Màn hình xác nhận, Màn hình kết quả, ...
- Có thể đặt thêm STT ở các level Chức năng, và Màn hình. STT cũng đặt theo level
VD:
- Chức năng: 1. Chức năng Chuyển tiền, 2. Chức năng tất toán
- Màn hình: 1.1. Màn hình khởi tạo, 1.2. Màn hình kết quả/1.1.1 Màn hình Mẫu Chuyển tiền
  Element - Nếu tên element được tạo từ tính năng smart locator có thể định danh được cho element đó, người dùng đọc tên element có thể biết và hiểu được đang chỉ đến elemenet nào thì không cần đặt lại tên
- Trường hợp tên element không đủ định danh, đặt lại tên element đúng theo ý nghĩa của element đó

Sửa lần cuối: Thứ Ba, 21 tháng 10 2025, 5:14 AM