| ID | Priority | Item | Preconditions | Procedure | Expected Result | Judgment | Notes/Log | Environment |
|---|---|---|---|---|---|---|---|---|
| 1 | H | Quest Acceptance Behavior when YES is selected |
・Acceptance dialog displayed ・Stamina ≥10 |
1) Select "YES" in the acceptance dialog 2) Wait until loading completes |
・Transition to battle screen ・Consume 10 stamina ・Switch BGM to battle music |
OK | Screenshot quest_yes_ok.png |
iPhone 13 (iOS 17) |
| 2 | M | Use Item Recover HP with "Potion" |
・In battle ・Inventory has "Potion" ×1 ・Current HP is below max |
1) Open item menu 2) Use "Potion" |
・Recover +50 HP ・Inventory decreases by 1 ・Output usage log |
OK | Log /battle/item_green_003.txt |
Pixel 6 (Android 13) |
| 3 | H | Shop Cancel behavior in confirmation dialog |
・Shop screen ・"100 Gems" purchase button enabled |
1) Tap "100 Gems" to display purchase confirmation 2) Select "Cancel" in the dialog |
・Do not start purchase process ・Remain in shop |
NG | Bug report №101 Redirected to external store vid/cancel_bug.mp4 |
iPhone 14 (iOS 17) |
| ID | Tên kỹ năng | Mô tả | Đối tượng | Hiệu quả | Thời gian hiệu lực | Ghi chú/Log |
|---|---|---|---|---|---|---|
| 1 | Liệt Hỏa Trảm | OK | NG | OK | OK | Bug report №204 Đối tượng là kẻ địch đơn (Yêu cầu: nhóm kẻ địch) |
| 2 | Hộ Vệ Bầu Trời Xanh | OK | OK | OK | OK | |
| 3 | Bó Bóng | OK | OK | OK | NG | Bug report №207 Thời gian hiệu lực 60 giây (Yêu cầu: 30 giây) |
| 4 | Lời Cầu Nguyện Tinh Linh | OK | OK | OK | OK | |
| 5 | Hư Không Xung | OK | OK | NG | OK | Bug report №208 Sát thương 200~250 (Yêu cầu: khoảng 100) |
Purchase Confirmation |
→ OK |
Shop |
← Pending |
Sale Confirmation |
↑ OK |
↓ OK |
↑ NG |
||
Select Product |
↓ OK |
Select Owned Item |
||
↑ OK |
↓ OK |
↑ OK |
||
Product List |
← NG |
Purchase/Sell |
→ OK |
Owned Item List |
 |
NG |
Verify that the behavior when selecting an item is correct |
"Correct" is ambiguous, and judgment differs by tester, leading to inconsistent results Specific expected results should be clearly stated |
| OK |
Verify that a confirmation dialog opens when selecting an item |
 |
NG |
Verify that the character’s behavior is not unnatural |
"Whether it is unnatural or not" depends on the tester’s perception, so results will be inconsistent While specifying reference material can unify judgment, if the reference location is unclear, verification may take time or cause misinterpretation |
| OK |
Verify that the character’s behavior is as per the specification |
 |
NG |
Verify that the save data has no issues |
A test can show that "there is an issue," but cannot prove that "there are no issues" Instead of "no issues," the condition for OK (judgment criteria) should be specified |
| OK |
Verify that upon loading, the game resumes from the save point |
 |
NG |
Verify that there is no way to open the door without using the "Gold Key" |
"Checking that there is no way" leads to exhaustive search, which is impractical Instead of negative exhaustive checks, specific expected results based on specifications should be stated |
| OK |
・Verify that with the "Silver Key," the door does not open ・Verify that with the "Bronze Key," the door does not open |
 |
NG |
Verify that upon clearing, the player obtains a Large Healing Potion |
Do not use "temporary names" or "nicknames" used during development Unify with the official names displayed in the game to prevent discrepancies and confusion |
| OK |
Verify that upon clearing, the player obtains a Green Potion |
 |
NG |
Upon mission clear, 「Character A」 joins |
If preconditions are not stated, test results will be inaccurate In the NG test case, if 「Character B」 has already joined, Character A joining will not be recognized as a defect |
| OK |
Precondition: 「Character B」 is not in the party Upon mission clear, 「Character A」 joins |
 |
NG |
Verify that an image is displayed |
If the test case only states "whether displayed or not," anything displayed may be misjudged as OK Reference materials for the expected image should be clearly indicated |
| OK |
Verify that the correct image per specification is displayed |
 |
NG |
1.「YES」→ Start quest 2.「NO」 → Do not start |
If YES is executed first, NO cannot be tested in the same flow To verify NO, rollback/restart of save data is needed, causing extra effort From a workload perspective, this test case order is inappropriate |
| OK |
1.「NO」 → Do not start 2.「YES」→ Start quest |
 |
NG |
Verify all combinations of new "Weapon" with existing "Helmet" and "Armor" |
Even with 10 of each, it results in 10×10×10=1000 cases, greatly increasing workload Covering all combinations is impractical Even if executed, it should be validated using a matrix table or representative combinations |
| OK |
Verify combination of new "Weapon" with "Flame Helmet" and "Water Armor" |
 |
NG |
Verify that behavior at battle start is as per specification |
If multiple aspects are included in one case, root cause isolation becomes difficult when it fails, and reporting becomes vague Follow the principle: 1 test case = 1 aspect |
| OK |
・Verify transition to battle screen ・Verify animation playback ・Verify BGM playback |
 |
NG |
Verify that after quest start, the correct dialogue is displayed and BGM switches |
This becomes a long test case with multiple aspects Elements should be broken down, and separate test cases created for each aspect |
| OK |
・Verify quest start ・Verify dialogue is displayed as per specification ・Verify BGM switches |