Trần Vương - Test Manual

🧩 [Day 390/100] Evidence sai cách = mất giá trị

Ở bài trước chúng ta đã đi qua lựa chọn lấy hay không lấy evidence.

Bài này mình lại gửi tới các bạn một nỗi đau không hề nhẹ

# Có evidence chưa chắc đã chứng minh được bạn test đúng 😄

Nghe hơi vô lý đúng không?

Mình từng nghĩ rất đơn giản: Có ảnh, có video kết quả test là đủ

Không 😄

Và đây là một trong những tư duy mình từng bị khách hàng “vả” cho sáng mắt ra.

🧠 Câu hỏi đặt ra là:

# Evidence của bạn đang chứng minh điều gì?

Dự án :

Đăng nhập bằng từng loại tài khoản → hiển thị thông tin đúng theo role

Lúc đó mình test với:

• 3 loại tài khoản khác nhau
• Mỗi role hiển thị dữ liệu khác nhau

Tất nhiên là sau khi lấy evidence Ảnh màn hình kết quả thì độ tự tin tăng theo cấp số nhân

Trong đầu mình nghĩ: Nhìn header là biết account nào rồi mà, vì:

• Số dư khác nhau
• Thông tin hiển thị khác nhau
---
Nhưng feedback khách hàng nhận được là:

Lấy gì chứng minh em thật sự login bằng đúng account đó?

Một phút lặng im và rồi mình bắt đầu cảm nhận rõ ràng hóa ra

# Mình đang tự cho rằng người xem sẽ hiểu thứ chỉ có mình hiểu

Với tester:

👉 Mình biết mình vừa thao tác gì

Nhưng với người review:

👉 Họ chỉ nhìn thấy evidence

Và cái họ cần không chỉ là kết quả đúng mà là bằng chứng đầy đủ rằng:

• Bạn test đúng flow
• Dùng đúng data
• Và kết quả đúng

Sau lần đó mình bổ sung thêm vào evidence

Ví dụ test nhiều loại account:

👉 Cách 1 — Chụp ảnh có đầu đuôi hơn

• Ảnh màn login có sẵn thông tin account
• Sau đó chụp màn kết quả

Tất nhiên nếu muốn “bắt bẻ” thì vẫn có thể, nhưng ít nhất:

👉 Logic bằng chứng đã đầy đủ hơn rất nhiều

Cách này thì khi áp dụng cũng đã nhận được sự đồng tình của Khách hàng

👉 Cách 2 — Quay video từ login → tới màn cần test

Cái này thì gần như khỏi cãi vì nó chứng minh được trọn vẹn

• Dùng account nào
• Thao tác thế nào
• Vào đúng flow nào
• Kết quả cuối ra sao

Chỉ là thời gian xử lý evidence sẽ lâu hơn so với chụp ảnh

🧠 Nhưng đây mới là điều mình muốn nói nhất:

# Evidence không phải càng nhiều là càng tốt

Mà là:

# Evidence phải đúng thứ cần chứng minh

Ví dụ:

Testcase: Username tối đa 10 ký tự

Mà evidence chỉ có: Popup lỗi thì vẫn chưa đủ

Vì người xem đâu biết:

• Bạn nhập bao nhiêu ký tự?
• Input là gì?
• Thao tác ra sao?

Một evidence có giá trị thường phải giúp người xem tự trả lời được:

• Em test cái gì?
• Em thao tác thế nào?
• Em dùng data gì?
• Và tại sao em kết luận PASS?

🎯 Nói đơn giản:

Evidence tốt không phải là có ảnh, có video

Mà là:

# Người khác nhìn vào vẫn hiểu và tin được kết quả test của bạn 😄

🔍 [Day 389/100] Evidence - Lựa chọn lấy và không lấy

Trong quá trình kiểm thử có bạn nào đang lấy evidence kiểu:

• Case PASS → đánh Pass
• Case FAIL → log bug + chụp evidence

Và những Pass rồi cho nên mặc nhiên không cần lấy evidence
---
Nghe thì có thể hơi lấn cấn nhưng bạn đã bao giờ thật sự dừng lại để nhìn nhận sâu hơn chưa, và thường thì việc bỏ qua bao giờ cũng là lựa chọn dễ dàng

Mình hỏi thật nhé:

Nếu bạn không lấy evidence cho case PASS thì người review dựa vào đâu để tin rằng bạn thật sự đã test?
---

Đặc biệt với khách hàng.

Rất nhiều khách:

• Không đủ nghiệp vụ hệ thống
• Không thể thực hiện các kỹ thuật như tester
• Không hiểu hết business rule bên trong

Cho nên thứ họ cần nhìn không chỉ là một trạng thái Pass
Mà là: Bằng chứng rằng testcase đó đã được thực hiện thật

🧠 Và đây mới là thứ đau nhất

Khi mọi thứ đang ổn thì không sao, nhưng đến lúc:

Leader hỏi:

• Em đã test chưa?
• Em test như thế nào?

Hoặc khách hàng hỏi:

• Lấy gì chứng minh testcase này từng Pass?

Lúc đó nếu không có evidence bạn sẽ bắt đầu có cảm giác mình trong sạch nhưng lại không có gì để chứng minh

Đặc biệt là khi bug UAT bị trả về và bạn thì thấy:

"Case này trước đây test PASS rồi mà?"

Nghe quen không? 😄

Và đau nhất là:

👉 Bạn nhớ mình đã test thật
👉 Bạn nhớ lúc đó nó từng PASS thật

Nhưng thứ duy nhất bạn có lại là: Status = PASS không hơn không kém

Không có:

• Ảnh chụp
• Video
• Bằng chứng thao tác
• Bằng chứng data test
• Bằng chứng kết quả lúc đó

🎯 Và lúc này rất khó để chứng minh:

Bug này là regression mới phát sinh hay thật ra testcase trước đó chưa từng được test đủ?

Nói hơi đau một chút

Nhưng trong thực tế: Câu nói “Em nhớ là em test rồi” không phải evidence

Ở đây mình không nói:

Phải chụp mọi thứ bằng mọi giá mà muốn nói đến mindset

# Evidence không phải để cho có

Nó là cách bạn chứng minh:

• Mình đã thật sự test
• Test đúng flow
• Test đúng data
• Test đúng kết quả
---
Có lần mình từng làm một dự án mà lấy evidence đủ tới mức khách gần như chỉ review evidence là đã tin tưởng phần lớn kết quả test. Thậm chí mức độ UAT giảm đi khá nhiều.
---
Tất nhiên:

❌ Không phải khách hàng nào cũng vậy và không phải cứ gửi evidence là auto được tin tưởng vì để nhận được tin tưởng luôn cần thời gian

Nhưng điều mình nhận ra là:

Evidence đầy đủ giúp giảm rất nhiều câu hỏi kiểu:
• Em có test chưa?
• Em test như thế nào?
• Tại sao em nói pass?
---
🧠 Một câu hỏi khác không kém phần quan trọng:

Vậy có cần lấy evidence cho tất cả testcase không?

Câu trả lời của mình chắc chắn là KHÔNG nhé.

• Vì có những lúc thời gian lấy evidence gần bằng thời gian test
• Vì người cần bằng chứng là người review và khách hàng thì cái họ quan tâm mình cũng khẳng định là không phải 100% testcase
---
Cho nên nếu mới bắt đầu và chưa biết chọn thế nào thì:

# 🎯 Ít nhất hãy bám theo Priority

Ví dụ:

👉 Nhóm testcase High

Nên là mức tối thiểu cần có evidence

Vì đây thường là:

• Luồng chính
• Chức năng chính
• Yêu cầu chính của task
• Vùng rủi ro cao
• Nơi bug dễ ảnh hưởng release

Ít nhất khi cần review lại bạn có ằng chứng mình đã cover phần quan trọng nhất

⚠️ Nhưng có một điều mình từng hiểu sai khá lâu:

Mình từng nghĩ: “Miễn có evidence là được”

Nhưng không, thực tế lại vả cái đốp:

# Evidence có giá trị hay không lại không nằm ở số lượng

Mà nằm ở:

# Nó có thật sự chứng minh được điều bạn đang muốn chứng minh hay không

Cái này mình sẽ kể kỹ hơn ở bài tiếp theo với chủ đề:

👉 Có evidence nhưng vẫn khiến người xem không tin mới là thứ đau đầu hơn

Cùng chờ vào sáng ngày mai nhé!

🔰 [Day 388/100] Priority Testcase — Tiêu chí nào để đánh giá

Trong bộ testcase của bạn có bao giờ cột Priority xuất hiện và khi nhìn lại thì:

👉 80% testcase có Priority là High
👉 Hoặc không biết để đâu thì Medium

Nếu hỏi: Đánh priority testcase dựa vào gì? Bạn có tin rằng tỉ lệ cao sẽ trả lời kiểu:

• Quan trọng thì High
• Ít quan trọng thì Low
• Ở giữa thì Medium

Nhưng nghĩ mà coi, vấn đề nằm trong chính câu trả lời đó:

“Quan trọng” là quan trọng theo cái gì?

Và đây là lý do rất nhiều bạn bị mơ hồ khi đánh priority

Đặc biệt là: Medium — vùng nửa nạc nửa mỡ, đôi khi nó chẳng đủ rõ ràng để bạn đưa ra quyết định

Đầu tiên phải nói rõ một điều:

🎯 Priority testcase không phải để cho đẹp

Mà để trả lời một câu hỏi thực tế sau:

❓Nếu thời gian không đủ mình test cái gì trước?

Thật ra cái này là tư duy không phải để bạn đánh đúng 100% mà là giúp bạn:

👉 Quyết định nhanh
👉 Cover đúng trọng tâm khoảng 80%

Là đã rất tốt rồi. Chứ ngồi đánh độ ưu tiên mà khiến bạn phải suy nghĩ cả phút thì tính ra lợi chả đủ bù hại

🧠 Sau nhiều dự án, mình thường nhìn testcase qua 4 câu hỏi:

• Có thuộc luồng chính không?
• Có phải phần chính của task đang làm không?
• Nếu lỗi thì ảnh hưởng có lớn không?
• Có phải vùng từng dễ lỗi / bug hay quay lại không?

Rồi từ đó mới phân loại

# 🔴 HIGH — Không test là thấy không thể yên tâm

Đây thường là nhóm:

• Luồng chính của hệ thống
• Chức năng chính của task đang làm
• Nơi Fail sẽ ảnh hưởng lớn tới business
• Điểm từng dễ lỗi hoặc hay bug lại
• Vùng vừa sửa code / dễ gây ảnh hưởng

Ví dụ:

• Login
• Payment
• Tạo đơn hàng
• Permission
• Tính toán tiền
• Validate chính của task
---
❓Có thể tự hỏi: Nếu release mà chưa test case này mình có thấy bất an không?

Nếu câu trả lời là: Có

Gần như có thể chắc chắn là High

⚠️ Nhưng có một cú lừa rất hay gặp:

Nhiều bạn nghĩ:
UI = Low

Không hẳn nhé.

Ví dụ:

Task hiện tại là:

• Update giao diện popup thanh toán lỗi

Lúc này:

• UI popup
• Text popup
• Trạng thái hiển thị

👉 Hoàn toàn có thể là High.

Không phải vì nó to tát gì mà vì nó là phần chính của task sẽ release

# 🟡 MEDIUM — Không cấp bách như High, nhưng không được phép quên

Đây là vùng khoai nhất và cũng là vùng dễ bị đánh sai nhất

Cho nên ở đây mục tiêu là bạn có thể đưa ra quyết định nhanh nhất, đảm bảo tỉ lệ chính xác trong phạm vi chấp nhận được thay vì cố gắng đánh chính xác nhất nhưng lại mất nhiều thời gian.

Bạn có thể nghĩ là:

👉 Không phải thứ cần test đầu tiên

NHƯNG:

👉 Không được phép quên quay lại test

Thường là:

• Flow phụ
• Validate phụ
• Logic không chặn luồng chính
• Trải nghiệm ảnh hưởng vừa phải
• Hành vi liên quan nhưng nếu lỗi thì không nghiêm trọng
---
Ví dụ:

• Sorting
• Filter phụ
• Warning text
• Trạng thái hiển thị phụ
• Một số case ngoại lệ không nghiêm trọng
---
❓Có thể tự hỏi: Nếu chưa kịp test ngay mình có cần quay lại test trước release không?

Nếu câu trả lời là “Có”

Có thể mạnh dạn đánh Medium

⚠️ Lưu ý: Medium KHÔNG phải: “Không biết để đâu thì nhét vào”

# 🟢 LOW — Có thời gian thì cover thêm

Đây thường là nhóm:

• Sai lệch nhỏ về giao diện/hiển thị
• Flow ít người dùng hoặc hiếm xảy ra
• Hành vi ít ảnh hưởng tới chức năng chính
• Các tình huống nếu có thì tốt hơn
---

❓Có thể tự hỏi: Nếu chưa test vòng này release có còn tương đối an toàn không?

Nếu: “Vẫn ổn" Khả năng cao là Low

⚠️⚠️⚠️ Nhưng đây mới là thứ rất nhiều người chưa để ý:

# Priority không phải bất biến

Ví dụ:

• Trong task hiện tại: Update UI popup payment failed

👉 UI popup có thể là High

Nhưng khi đưa vào regression tổng thể thì cùng testcase đó có thể chỉ còn Medium

Vì lúc này:

🎯 Bối cảnh đã thay đổi.

Ta không còn đánh giá theo Task hiện tại sửa gì mà dựa trên đánh giá nếu release lỗi thì Rủi ro tổng thể là gì
---
Cho nên:

# Priority = testcase + bối cảnh

Chứ không phải:

# Một testcase sinh ra là High mãi mãi

⚠️ Một dấu hiệu mình hay tự cảnh báo bản thân:

Nếu nhìn vào bộ testcase mà 70–80% đều High

👉 Có thể bạn đang chưa thật sự ưu tiên:

Vì nếu cái gì cũng quan trọng thì thật ra chẳng còn gì thật sự quan trọng nữa 😄

💬 Còn theo mọi người thì sao?

Khi đánh priority testcase, mọi người thường dựa vào tiêu chí nào nhất?

🧩 [Day 387/100] Một cách mình quản lý testcase "Từng bị lỗi"

Trong quá trình test, chuyện test lỗi là điều quá bình thường, đôi khi không phát hiện ra lỗi mới cần lo lắng 😅

Kết quả test mình từng tham khảo thông thường sẽ kiểu:

• Pass: Kết quả thực tế đúng
• Failed: Kết quả thực tế khác so với mong muốn
• Pending: Vì một lý do nào đó mà chưa thể thực hiện được
• N/A: Bỏ qua không test có lý do

Và flow quen thuộc thường là:

• Testcase fail
• Log bug
• Đính kèm ticket bug vào Note hoặc cột nào đó
• Dev fix
• Verify lại PASS
• Update testcase thành Pass

Nghe quá hợp lý luôn rồi, trước đây mình cũng làm như vậy. Cơ bản thường thì không có vấn đề gì cả.

Cho đến khi chính mình tự tạo nghiệt.

# 🎯 Bug cũ quay trở lại

Ví dụ:

• Test round 1 → fail
• Dev fix → verify pass
• Deploy môi trường khác / test round 2

Và rồi một ngày đẹp trời:

Ơ bug này hình như trước đây từng lỗi rồi mà?

Nếu làm lâu mình khá chắc không ít bạn gặp tình trạng này.

🧠 Sau này mình hay ví bug dạng này kiểu như một cành cây bị gãy.

Khi sửa nó để gắn lại thì dù cố thế nào nó vẫn không còn “nguyên vẹn như chưa từng gãy”.

Còn các bạn Dev khi thực hiện Code cũng vậy, khi bug phát sinh và sau đó:

• Merge lại source code chính
• Deploy nhiều môi trường
• Nhiều người cùng sửa

Thì chuyện:

• Fix bug này ảnh hưởng bug khác
• Deploy thiếu source
• Conflict logic (Xung đột xử lý logic)

Là chuyện hoàn toàn có thể xảy ra.

🎯 Lúc này thì nhóm testcase mình ưu tiên retest là nhóm từng phát sinh bug

Vấn đề bắt đầu phát sinh là:

# Làm sao để lọc ra được những testcase từng bị lỗi đó một cách hiệu quả?

• Thông thường chúng ta thường đính kèm ticket bug vào cột Note, khi cần retest thì filter cột Note có dữ liệu.

• Bạn nào cẩn thận hơn thì thêm 1 cột Ticket bug chỉ để gắn link bug vì cột Note thường sẽ ghi nhiều hơn 1 nội dung.
---
Nhưng thực tế bản thân mình có mấy cái lỗi ngớ ngẩn sau

• Có đánh testcase trạng thái Fail nhưng lại quên không note lại ticket
• Có thời điểm dùng cột Note thì không phải chỉ gắn mỗi ticket bug mà còn ghi chú nhiều thứ, thành ra lúc Filter thì cũng kém hiệu quả

Hậu quả: Khi muốn lọc ra toàn bộ testcase từng lỗi thì nhìn lại không có gì khác so với case Pass ngay từ đầu

# 🧩 Đây là cách mình xử lý vấn đề:

Mình thêm một trạng thái testcase nữa là Closed

Ý nghĩa rất đơn giản:

👉 Nếu testcase từng phát sinh bug thì sau khi:

• Dev fix
• Verify pass

❌ Mình không update về Pass nữa mà chuyển sang Closed

🧠 Lúc này:

🔹 Pass

• Case chạy ổn ngay từ đầu
• Chưa từng phát sinh bug

🔹 Closed

• Case từng fail bug
• Đã được fix và verify lại OK

🎯 Và giá trị của nó là khi cần:

• Retest round 2
• Regression
• Verify trên môi trường staging
• Verify release

👉 Mình chỉ cần filter:

Status = Closed

Cũng không cần tạo thêm cột mới để lưu Ticket bug

⚠️ Một điều rất quan trọng nhé:

Bài này chỉ đơn giản là: Một cách mình từng dùng để giảm việc sót lại những bug cũ từng phát sinh.

Và sau nhiều dự án mình càng thấy:

🎯 Những bug đáng sợ nhất không hẳn là bug mới mà là mấy cái bug:

Từng fix rồi nhưng lỗi lại vì rất khó để xác định được khi nào nó xuất hiện 😅

Chúc bạn không phải gặp nhiều loại bug này nhé.

✅ [Day 386/100] Kiểm thử API trên Mobile với công cụ Charles

Mình mới hoàn thành bộ tài liệu hướng dẫn cài đặt và ứng dụng công cụ Charles trong kiểm thử API trên Mobile phần cơ bản gửi tặng cả nhà.

Thực tế còn rất nhiều tính năng khác tuy nhiên với công cụ này phần khó khăn nhất là cài đặt đến giai đoạn có thể bắt được các Request từ ứng dụng trên mobile. Ngoài ra phần mình cảm thấy có tính ứng dụng cao trong thực tế là tính năng Breakpoint cho phép thay đổi dữ liệu Response trả về từ API cho nên phạm vi lần này cũng sẽ tập trung vào cài đặt, sử dụng breadkpoint và các lưu ý cùng tiptrick.

Khi các bạn đã hoàn thành được việc cài đặt, các ứng dụng khác của Charles hoàn toàn có thể tìm hiểu thêm trên mạng hoặc các công cụ AI phổ biến hiện nay.

Chúc các bạn thành công!

Day 386. Kiểm thử API trên mobile với Charles.docx 1. Cài đặt ứng dụng trên Máy tính (PC) Link tải: Charles Proxy Download Lựa chọn phiên bản: Ver 5.x (Mới nhất): Thường hiện modal yêu cầu trả phí, phải khởi động lại ứng dụng thường xuyên (Windows x86_64 (msi, 65.8 MB) Ver 4.6.1: Bản cũ nhưng ....

📣[Day 385] Tài liệu cuối tuần
Gửi mọi người Checklist common kiểm thử Scroll bar

Web_common_Checklist

👉 [Day 384/100] Cuối tuần rồi tài liệu thôi
Gửi mọi người checklist kiểm thử Date picker

NOTE: Với Date picker có khá nhiều điểm tương đồng với tài liệu Time picker của Day 378, do đó những nội dung khác biệt mình có highlight màu đỏ trong tài liệu nhé

Web_common_Checklist

🧩 [Day 383/100] Testcase truy cập - Quan trọng nhưng dễ bỏ sót

Mình từng review không ít bộ testcase, có một điều mình thấy lặp đi lặp lại khá nhiều:

👉 Test function rất kỹ
👉 Validate data rất nhiều
👉 Nhưng phần “truy cập vào chức năng đó như thế nào” thì lại gần như không được tách ra rõ ràng
---
Đầu tiên phải nói rõ một điều để tránh hiểu sai nhé:

❌ Không có chuyện:
• Đúng tuyệt đối hay sai tuyệt đối

Vì:

• Mỗi dự án khác nhau
• Mỗi team khác nhau
• Mỗi người có cách triển khai testcase khác nhau

Miễn là vẫn đạt được mục tiêu chất lượng và đúng tiến độ thì đôi khi sự phù hợp lại trở thành ưu tiên hàng đầu

👉Bài này đơn giản là góc nhìn mình đúc rút sau khá nhiều dự án thực tế

🧠 Mình thấy có một tư duy rất phổ biến:

Muốn test chức năng thì kiểu gì cũng phải vào màn đó trước cho nên đương nhiên sẽ test qua case truy cập

Nghe rất hợp lý đúng không 😄

Và cũng chính vì hợp lý nên rất nhiều người bỏ luôn nhóm case truy cập

Ví dụ:

👉 Khi viết testcase cho màn quản lý user

Mọi người sẽ tập trung vào:

• Tạo user
• Sửa user
• Validate
• Tìm kiếm
• Phân trang...

🎯 Tức là đang focus vào: Chức năng bên trong màn hình

Trong khi lại ít tự hỏi:

“Màn này thực tế có thể được truy cập bằng những cách nào?”

Và đây là chỗ mình gặp không ít bug xảy ra, mà thường lại là bug nghiêm trọng

🧩 Một điều rất quan trọng cần làm rõ

Case truy cập không tách biệt hoàn toàn với function

Vì bản chất:

👉 Quyền truy cập vẫn là hành vi của hệ thống

Nhưng vấn đề là:

🎯 Trong rất nhiều bộ testcase, phần access thường không được tách ra cover như một góc nhìn riêng

Và khi không tách ra suy nghĩ:

👉 Tỉ lệ bỏ sót rất cao.

🧩 Vì sao chuyện này hay xảy ra?

Vì đa số testcase function sẽ bám vào:

• Requirement
• Spec
• Business flow

Trong khi tài liệu đặc tả thường mô tả:

• Chức năng làm gì
• Validate gì
• Kết quả ra sao

Chứ thường lại không mô tả đầy đủ cho từng màn hình là:

• Truy cập từ đâu
• Điều kiện truy cập
• Session nào được phép
• Trạng thái nào được vào
• Điều hướng đặc biệt nào tồn tại

Trừ khi nó nằm trong yêu cầu rõ ràng. Cho nên rất nhiều người vô tình mặc định:

“Mở được màn rồi thì test chức năng thôi”

👉 Thực tế: Chỉ riêng việc “vào màn như thế nào” đã có thể sinh bug rồi

# 🧩 Những nhóm case truy cập mình thấy rất dễ bị bỏ sót

🔹 Truy cập khi chưa đủ điều kiện

Ví dụ:

• Chưa login
• Session hết hạn
• Chưa xác thực tài khoản
• Chưa hoàn thành bước trước đó
---
Ví dụ:

👉 Có những màn dù đã login vẫn không được phép vào trực tiếp như:

• Màn thanh toán
• Màn xác nhận OTP
• Màn step-by-step flow (Bạn nào từng thực hiện KYC hoặc luồng đăng ký thì có thể gặp cái này)

👉 Nếu bypass flow mà vẫn vào được thì tỉ lệ cao là Bug

# 🧩 Truy cập sai quyền (Được gọi với cái tên Leo quyền dọc)

Hiểu nhanh thì tài khoản quyền thấp hơn cố gắng truy cập vào màn mà chỉ có quyền cao hơn mới được phép

Đây là phần nhiều người nghĩ ngay đến bảo mật (security)

Nhưng không nhé, thật ra đây là case kiểm soát truy cập cơ bản mà tester functional cũng nên để ý

Ví dụ:

• Admin có quyền vào màn quản trị
• User thường thì không

Flow cơ bản cần kiểm tra:

• Login Admin
• Copy URL hoặc giữ trạng thái màn hình
• Logout
• Login User thường
• Truy cập lại màn của Admin trước đó bằng cách Paste Url thử coi

🎯 Điều cần kiểm tra là:

• Hệ thống có chặn đúng không?
• Session cũ có bị tái sử dụng không?
• Cache có bị giữ lại không?

Đơn giản là: Nếu cho phép truy cập vào màn mà không được quyền là toang rồi

# 🧩 Truy cập chéo dữ liệu cùng quyền (Gọi là leo quyền ngang)

Case này còn dễ bị bỏ sót hơn

Ví dụ:

• User A xem lịch sử đơn hàng của mình
• Sau đó dùng link / trạng thái cũ / deeplink
• Login bằng User B

🎯 Điều cần kiểm tra:

👉 User B có nhìn thấy dữ liệu của User A không?

# 🧩 Deeplink / Push Notification

Case này mobile app gặp rất nhiều.

Ví dụ:

• App mở trực tiếp vào màn chi tiết từ push notification
• Hoặc deeplink mở thẳng màn bên trong app

Lúc này cần để ý:

• User đã login chưa?
• Session còn hợp lệ không?
• Có đúng quyền không?
• Trạng thái dữ liệu hiện tại còn hợp lệ không?

👉 Đây đều là access case

# 🧩 Một case mobile rất hay gặp

Ví dụ:

• Đang login User A
• Mở menu bằng swipe (Là vuốt ngang màn hình để mở Menu thay vi tap vào Menu)
• Logout ngay tại màn hiện tại
• Login User B

🎯 Điều cần quan sát không phải thao tác swipe

Mà là:

👉 Sau khi đổi trạng thái account:

• Dữ liệu cũ có bị giữ lại không?
• Cache có clear đúng không?
• Một số hoạt động không được phép có bị sai trạng thái không?

Đây là dạng bug state/session thực tế mình gặp khá nhiều trên mobile app

# 🧠 Bạn nên nhớ rằng người dùng thực tế thì luôn có một nhóm không làm theo cách thông thường mà Flow định nghĩa:

Họ có thể:

• Back app
• Vào bằng deeplink từ một email hay tờ rời nào đó
• Làm mới phiên hoạt động
• Paste URL
• Dổi account
• Mở từ push notification
• Sử dụng lại trạng thái cũ

👉 Và rất nhiều bug chỉ xuất hiện ở những tình huống như vậy. Cho nên bạn nào mà trải nghiệm nhiều có bao giờ tự hỏi bug UAT sao nó dị vậy chưa :>

🎯 Nên với mình:

Case truy cập dù không phải là thứ tách biệt khỏi function nhưng nó nên tách ra thành một góc nhìn cover để tránh bị phân tán bởi nhóm tính năng cốt lõi

👉 Có những bug không nằm ở chức năng chạy sai mà nằm ở việc hệ thống cho phép người dùng đi vào một trạng thái mà đáng lẽ họ không nên vào được

Chúc bạn thành công!

🔰[Day 382/100] Các loại Test Case — Làm chi tiết liệu có thật sự tốt?

Mình từng đi qua khá nhiều dự án nên cũng từng gặp rất nhiều kiểu template testcase

Có những bộ testcase phân loại cực kỳ chi tiết:

• Normal
• Abnormal
• Exception
• Boundary
• Security
• UI
• Business
• Permission
• ...v.v...

Có những template tách tiếp kiểu:

• Normal Login
• Normal Email
• Normal Password...

Mình không nói là sai nhé.

Thậm chí với một vài dự án đặc thù thì việc phân loại chi tiết cũng cần thiết

👉Tuy nhiên nếu theo chiều ngược lại với những bạn mới việc chia thành nhiều loại testcase vô tình khiến các bạn thấy bối rối và mất khá nhiều thời gian để đánh đúng loại testcase

Chưa dừng tại đó, có lần mình từng đưa một bộ testcase phân loại cực chi tiết sang phía khách hàng Nhật (Với tệp khách hàng này bạn thừa hiểu họ chi tiết và cẩn thận ra sao)

Phía khách:
• Có nền tảng kỹ thuật và cũng có team test riêng

Và feedback mình nhận lại là:

• Khó filter
• Khó tìm kiếm
• Khó nhìn tổng quan độ bao phủ

Lúc đó mình mới bắt đầu suy nghĩ lại một chuyện:

🎯 Liệu testcase type sinh ra để hỗ trợ việc test hay đang dần trở thành thứ làm khó người sử dụng hơn?

Sau nhiều lần chỉnh sửa, mình nhận ra với đa số dự án phổ thông:

👉 Thật ra chỉ cần chia đủ để định hình tư duy cover là đã rất mạnh rồi

🧩 Hiện tại mình thường gom về 6 nhóm chính

🔹 1. Case truy cập (Access Case)

👉 Cái này cực kỳ quan trọng.

Nhưng rất nhiều bạn lại bỏ qua

Ví dụ:

• Chưa login
• Sai quyền
• Token hết hạn
• Truy cập trực tiếp URL
..

👉 Nhóm này mình sẽ nói riêng ở bài sau vì nó thật sự rất quan trọng.

🔹 2. Case UI/UX

Đây là nhóm:

• Hiển thị
• Layout
• Màu sắc
• Responsive
• Trải nghiệm người dùng

🔹 3. Case Function

Đây là phần logic chức năng

Ví dụ:

• Login thành công
• Tạo đơn hàng
• Cập nhật profile
• Tính toán đúng

👉 Đây thường là phần mọi người tập trung nhiều nhất

🔹 4. Data Validation Case

Nhóm này liên quan:

• Validate
• Phân vùng tương đương
• Phân tích giá trị biên
• Dữ liệu đặc biệt

Ví dụ:

• Dể trống
• Vượt giới hạn
• Ký tự đặc biệt
• Data duplicate

🔹 5. Nhóm testcase bảo mật (Security)

Ở đây mình đang nói theo hướng: Security cơ bản của tester functional

Không phải:
• Pentest
• Cũng không đến mức security chuyên sâu

Mà là:

• Truy cập trái quyền
• Bypass validate
• Kiểm tra lộ dữ liệu nhạy cảm
• Truyền dữ liệu bất thường

👉 Những thứ tester thường vẫn nên có nhận thức cơ bản

🔹 6. Case hiệu suất (Performance)

Tương tự.

Không phải:
• Load test chuyên sâu
• Stress test hàng nghìn user

Mà là:

• Màn hình load bất thường
• API quá chậm
• Thao tác lag
• Timeout cơ bản

# 🧠 Điều mình thấy quan trọng nhất ở cách chia này

Không phải vì:

6 loại là chuẩn nhất mà vì nó đủ để định hình cách cover testcase mà không làm người viết bị ngộp

Đặc biệt với:
• Người mới
• Dự án vừa và nhỏ

👉 Việc có một khung đủ rõ sẽ giúp:

• Dễ nghĩ testcase hơn
• Ít bị sót góc nhìn hơn
• Dễ review hơn
• Dễ filter hơn
• Dễ maintain hơn

# 🎯 Một bộ testcase tốt không nhất thiết là một bộ chia nhiều loại nhất mà nên là bộ giúp team dễ hiểu, dễ cover và dễ sử dụng nhất.

💬 Còn theo mọi người thì sao?

Với kinh nghiệm hiện tại, liệu 6 nhóm như trên đã đủ để định hình một bộ testcase cover cơ bản chưa 😄

🧩 [Day 381/100] Phân tích giá trị biên – Dấu hiệu nhận biết khi nào dùng

👉Phân tích giá trị biên có khi nào bạn từng dừng lại và tự hỏi:

Khi nào thì mình nên dùng phân tích giá trị biên?

Ây nếu chưa từng thì đừng vội trả lời là:

• min - 1
• min
• max
• max + 1

🎯 Ý mình muốn nói là bạn nhìn vào yêu cầu như thế nào để nhận ra:

À, chỗ này nên áp dụng phân tích giá trị biên.

Vì thực tế: Phân tích giá trị biên KHÔNG phải lúc nào cũng áp dụng được nhé.

🧩 Lúc này câu trả lời phổ biến thường là: Khi validate dữ liệu số

OK đến đây nghe thì không sai nhưng bạn hãy thử trả lời tiếp câu hỏi sau

Vậy dữ liệu số là những loại nào?

Lúc này mình nhận ra một số bạn bắt đầu khựng lại, tất nhiên trước đây mình cũng thế mà :>

🧩 OK vậy cùng thử nhìn lại nhé

Khi nói “dữ liệu số”, có phải đa số chúng ta thường chỉ nghĩ đến:

• Số nguyên
• Số thập phân
• Số âm

Lý do rất đơn giản vì trong đó nó bao gồm từ "Số" đúng không?

Nhưng thực tế trong dự án, dữ liệu có thể áp dụng phân tích giá trị biên còn rộng hơn rất nhiều.

🎯 Các nhóm dữ liệu thường có thể áp dụng phân tích giá trị biên

🔹 Nhóm số lượng / giá trị

• Số lượng sản phẩm
• Số tiền
• Điểm số
• Phần trăm
• Số lượt
---
🔹 Nhóm kích thước / độ dài

• Dộ dài username
• Chiều cao
• Cân nặng
• Kích thước file upload
• Số ký tự nhập vào
---
🔹 Nhóm thời gian

• Giờ
• Phút
• Giây
• Ngày
• Tháng
• Năm
• Thời gian bắt đầu / kết thúc
---
🔹 Nhóm tuổi / mốc giới hạn

• Tuổi tối thiểu/Tối đa
• Năm sinh hợp lệ
---
🔹 Nhóm số thứ tự / giới hạn hệ thống

• Page size
• Số item tối đa
• Số request cho phép
• Giới hạn upload
---
🔹 Nhóm dữ liệu có khoảng giá trị

Ví dụ:

• Điểm từ 0 → 10
• Số lượng từ 1 → 100
• Mật khẩu từ 8 → 20 ký tự
---
👉 Đây mới là dấu hiệu quan trọng. Tức bạn cần nhận biết và định nghĩa được biểu hiện của loại dữ liệu trong yêu cầu để xác định sẽ dùng kỹ thuật Phân tích giá trị biên chứ không phải chỉ nằm ở một định nghĩa chung chung "Số".

Vì nếu như thế bạn rất dễ bị giới hạn phạm vi mà vô tình bỏ qua các giá trị cần thiết để đưa vào trong kiểm thử.

🧠 Do đó thứ chúng ta thật sự cần nhìn không phải

Nó có phải số hay không mà là dữ liệu đó có giới hạn để so sánh hay không

• Nhỏ hơn
• Lớn hơn
• Tối thiểu
• Tối đa
• Trong khoảng
• Vượt giới hạn
---
👉 Khi bắt đầu xuất hiện những dấu hiệu đó:

Thì gần như chắc chắn đó là nơi nên nghĩ đến phân tích giá trị biên.

⚠️ Trong thực tế có rất nhiều bạn vẫn áp dụng được khi gặp case thực tế, vẫn test được bằng phân tích giá trị biên.

Nhưng nếu hỏi:

Tại sao chỗ này cần Phân tích giá trị biên thì lại không diễn đạt được đầy đủ

Mình nghĩ đây là khác biệt rất lớn giữa làm theo phản xạ và thật sự hiểu mình đang test cái gì

👉Vì phản xạ thường đến từ:

• Làm nhiều
• Gặp nhiều
• Quen dần

Nhưng với người mới hoặc người chưa có nhiều va chạm thì nếu không tự định nghĩa lại trong đầu:

“Dữ liệu nào thật sự có ý nghĩa về biên?”

👉 Thì rất khó tự suy ra để áp dụng đúng

💬 Chốt lại:

“Phân tích giá trị biên không nằm ở việc dữ liệu có phải số hay không mà nằm ở việc dữ liệu đó có giới hạn để so sánh hay không.”

Chúc bạn thành công!

☪️ [Day 380/100] Phân vùng tương đương và Phân tích giá trị biên

Có một câu hỏi muôn thuở em thường dùng kỹ thuật nào trong kiểm thử thì 100% các bạn trả lời chắc nịch 2 kỹ thuật phổ biến nhất là:

• Phân vùng tương đương
• Phân tích giá trị biên

👉 Hầu như ai cũng biết dùng, nhưng vẫn đề là khi hỏi sâu hơn một chút thì nhiều bạn bắt đầu mơ hồ

Ví dụ có yêu cầu:

• Cho phép nhập từ 1 → 10 ký tự

Câu hỏi đặt ra là:

• Em sẽ test những giá trị nào?

Một câu trả lời khá phổ biến là:

0, 1, 2, 5, 9, 10, 11, 20

Cái này 90% trở lên có chung câu trả lời. Tuy nhiên lúc này nếu hỏi tiếp:

• Tại sao đã test 5 rồi vẫn cần test 2?
• Tại sao đã test 11 rồi vẫn cần test 20?

Lúc này một số bạn bắt đầu khựng lại.

👉 Rất nhiều người đang dùng cả 2 kỹ thuật cùng lúc nhưng chưa thực sự phân biệt được tại sao lại cần dùng nhiều hơn 1 giá trị trong cùng 1 vùng.

OK quay lại lý thuyết một chút:

🎯 Phân vùng tương đương

Là chia dữ liệu thành các vùng xử lý giống nhau và trong mỗi vùng chỉ cần chọn 1 giá trị đại diện:

Ví dụ:

1 → 10 là hợp lệ

Thì các giá trị từ 2 đến 9 về logic xử lý là thuộc cùng 1 nhóm đúng không, do đó việc lựa chọn 1 giá trị dựa trên nguyên tắc:

Nếu hệ thống xử lý đúng với 5 thì khả năng rất cao các giá trị còn lại cũng sẽ đúng

👉 Cho nên không cần test tất cả mà chỉ cần chọn 1 giá trị đại diện trong vùng.

Đây là ý nghĩa của: “Phân vùng tương đương”

🎯 Còn phân tích giá trị biên thì sao?

Đây là chỗ rất nhiều người chưa từng tự hỏi

Tại sao bug lại hay nằm ở biên?

👉Mình hay giải thích kiểu này

Hãy tưởng tượng:

• Việt Nam và Trung Quốc nằm cạnh nhau, phần giáp nhau gọi là biên giới
• Hai huyện gần biên giới nhất gọi là cận biên

Nếu có xung đột xảy ra thì rõ ràng hai Huyện cận biên giới là nơi dễ bị ảnh hưởng đầu tiên và nghiêm trọng nhất

👉Phần mềm cũng y chang vậy

Những giá trị:

• Sát giới hạn
• Vừa chạm ngưỡng
• Vừa vượt ngưỡng

👉 Luôn là nơi dễ sinh bug nhất.

Vì đây là vùng logic đúng ↔ logic sai nó chỉ cách nhau bằng sợi chỉ

🧩 Ví dụ nhé:

Yêu cầu:

• Tuổi không được vượt quá 20

Nghe đơn giản đúng không, và nói về xử lý thì dev hoàn toàn có 2 cách