Tải bản đầy đủ (.doc) (22 trang)

CÁC kỹ THUẬT KIỂM THỬ TÍNH TIỆN DỤNG của hệ TƯƠNG tác

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (204.12 KB, 22 trang )

5/8/2012
Học viện Công nghệ Bưu chính Viễn Thông | Bichtt004

FSE04

MÔN: TƯƠNG TÁC NGƯỜI MÁY
Giảng viên: Vũ Thị Hương Giang


2

Nhóm FSE04
Trần Thị Bích
Nguyễn Thị Thu Hồng
Trần Thị Thùy Linh
Nguyễn Văn Việt
Đề tài[BTL03] Các kỹ thuật kiểm thử tính tiện dụng của hệ tương tác
Phân công công việc trong nhóm như sau:
-

Mục tiêu và kế hoạch kiểm thử: Trần Thị Thùy Linh + Nguyễn Thị Thu

Hồng
-

Tìm người dùng thử và lựa chọn người dùng thử: Trần Thị Bích
Xác định các nhiệm vụ kiểm thử: Nguyễn Văn Việt
Đánh giá hiệu năng: Nguyễn Văn Việt
Ví dụ minh họa: Trần Thị Bích

Các tài liệu tham khảo của nhóm:



Bibliography
1. Jakob Nielsen. Usability Testing Enginering.
2. Michael O. Leavitt & Ben Shneiderman. Research-Based Web Design & Usability
Guidelines
3. Farhad Farzaneh. How many user is enough?
4. />5. />

3
6. />7. />8. />9. www.useit.com/alertbox/2000319.html
10. />
Table of Contents
I........................................................................................................................................................
Mục tiêu và kế hoạch kiểm thử....................................................................................................4
1........................................................................ Thế nào là kiểm thử tính tiện dụng của hệ tương tác
.............................................................................................................................................................4
Mục tiêu của kiểm thử tính tiện dụng................................................................................................4
Kế hoạch kiểm thử tính dùng được....................................................................................................5
II.................................................................... Tìm người dùng thử và lựa chọn người dùng thử
........................................................................................................................................................7
1.............................................................................................................. Tại sao cần người dung thử?
.............................................................................................................................................................7
2........................................................................................ Tìm người dùng thử nghiệm như thế nào?
.............................................................................................................................................................7
3................................................................. Tại sao chỉ cần tiến hành thử nghiệm với 5 người dung?
.............................................................................................................................................................9
III.............................................................................................. Xác định các nhiệm vụ kiểm thử
...........................................................................................................................................................12
IV.................................................................................................................... Đánh giá hiệu năng
...........................................................................................................................................................14



4
V.

Ví dụ minh

họa…………………………………………………………………………………………………
………………14

I.

Mục tiêu và kế hoạch kiểm thử

1.

Thế nào là kiểm thử tính tiện dụng (tính dùng được) của hệ tương tác


5

Kiểm thử tính tiện dụng là một kỹ thuật để đảm bảo những quan tâm của người
dùng về hệ thống có thể được đáp ứng một cách hiệu quả, và đem lại sự thỏa mãn
cho khách hàng
2.

Mục tiêu của kiểm thử tính tiện dụng

Hoạt động chính của kiểm thử tính tiện dụng là cung cấp thông tin phản hồi trong
quá trình thiết kế và phát triển để đảm bảo trang web sẽ thực sự được sử dụng dễ

dàng và hiệu quả, đồng thời cung cấp thông tin có giá trị cho người sử dụng. Có 4
điểm chính sau:
-

Kiểm thử cho chuyển hướng: chuyển hướng nghĩa là cách thức người dùng

lướt web (xem các trang webs), sử dụng các điều khiển khác nhau như các nút
bấm, các hộp (textobx, listbox…) hay cách người dùng sử dụng các đường links
trong các trang để lướt web
Kiểm thử tính khả dụng: trang web phải dễ sử dụng. Cung cấp các hướng
dẫn rõ ràng, rành mạch. Kiểm thử xem các hướng dẫn đó có đúng như những gì nó
phải đáp ứng không? Mỗi trang đều cần có menu chính, và menu này phải nhất
quán.
Kiểm thử nội dung: nội dung trang web phải hợp lý và dễ hiểu. Kiểm tra
các lỗi chính tả. Các màu tối sẽ gây phiền phúc cho người dùng và do đó không
nên được sử dụng. Bạn có thể theo một vài chuẩn nào đó được sử dụng cho việc
xây dựng nội dung web. Đây là những chuẩn được chấp nhận phổ biến như đã chú
ý về màu sắc, fonts, frames…
Nội dung cần phải đầy đủ ý nghĩa.Tất cả các đướng links được gán phải làm việc
tốt. Các tranh ảnh phải được đặt đúng chỗ với đúng kích thước. Có một vài chuẩn
cơ bản nên theo khi phát triển ứng dụng web. Nhiệm vụ là phải xác minh tất cả khi
kiểm thử giao diện.


6

-

Các thông tin hỗ trợ người dùng: như lựa chọn tìm kiếm, sơ đồ trang web,


các file hỗ trợ… Sơ đồ trang web cần có trong tất cả các links trong trang web với
cây thư mục để hỗ trợ chuyển hướng. Kiểm tra tất cả các links trong sơ đồ.
Tùy chọn “tìm kiếm trong trang web” sẽ giúp người dùng tìm kiếm các trang nội
dung một cách dễ dàng và nhanh chóng. Tất cả ác mục cần được phô bày và phải
được xác minh.
Kiểm thử tính khả dụng là kỹ thuật kiểm thử hộp đen. Mục đích của nó là quan sát
những người sử dụng sản phẩm để phát hiện ra các lỗi và những nơi cần sửa đổi.
Nói chung khả năng đạt mục tiêu của việc kiểm thử liên quan đến việc đo lường
phản ứng của đối tượng thử nghiệm trong 4 lĩnh vực: hiệu quả, chính xác, gọi lại
và cảm xúc phản ứng. Kết quả của phép thử nghiệm đầu tiên được coi như một
phép đo cơ vản hoặc để kiểm soát tất cả các phép kiểm thử tiếp theo nhằm so sánh
với mốc ban đầu để cải thiện hiệu năng.
-

Hiệu suất – bao nhiêu thời gian và bao nhiêu bước được yêu cầu để người

dùng hoàn thành tác vụ cơ bản của mình? (ví dụ,tìm một cái gì đó để mua, tạo ra
một tài khoản mới và sắp xếp các thư mục…)
Độ chính xác – mọi người đã mắc bao nhiêu lỗi? (và họ đã làm hỏng hay
phục hồi được những thông tin cần thiết)
Tính gọi lại – làm thế nào người ta có thể nhớ được sau một thời gian sử
dụng?
Cảm xúc phản ứng – làm thế nào để người dùng biết tác vụ của họ đã hoàn
thành? Liệu người dùng có giới thiệu hệ thống cho bạn của họ không?
3.
Kế hoạch kiểm thử tính dùng được
a.
Phát triển kế hoạch kiểm thử
Bước đầu tiên trong mỗi vòng kiểm thử tính khả dụng là phát triển một kế hoạch
cho việc kiểm thử này. Mục đích của kế hoạch là ghi lại thành tài liệu những gì sẽ

làm, tiến hành kiểm thử như thế nào, những số liệu cần nắm bắt, số lượng người sẽ
tham gia kiểm thử,và những kịch bản nào sẽ được sử dụng.


7

Thông thường, những chuyên gia về tính khả dụng sẽ gặp những người còn lại của
đội phát triển để quyết định những việc chính của kế hoạch đó. Thường thì các
chuyên gia về tính khả dụng đó sẽ dự thảo kế hoạch được chuyển đi để quản lý và
phần còn lại của đội phát triển. Khi tất cả mọi người đều có ý kiến riêng và phải đi
đến thương lượng, thì các chuyên gia tính khả dụng sẽ điều chỉnh lại kế hoạch đó
bằng văn bản để đưa đến quyết định cuối cùng.
b.

Các bước kiểm thử

Kế hoạch kiểm thử tính khả dụng cần bao gồm các thành phần dưới đây.
*** Phạm vi
Chỉ ra những gì đang được kiểm thử: tên của trang web, ứng dụng web, hoặc sản
phẩm khác. Ngoài ra, xác định có bao nhiêu sản phẩm sẽ được thử nghiệm (ví dụ
như mẫu đặc tả ngày, điều hướng, chuyển hướng và nội dung)
*** Mục đích
Xác định những mối quan tâm, câu hỏi và mục tiêu cho việc kiểm thử. Việc này có
thể bao gồm khá nhiều lĩnh vực. Ví dụ: “người sử dụng có thể điều hướng thông
tin quan trọng từ mẫu thử của trang chủ?” Hoặc cũng có thể khá cụ thể, ví dụ:
“Người sử dụng dễ dàng tìm thấy hộp tìm kiếm ở vị trí của nó?”
Trong mỗi vòng đời thử nghiệm, có thể sẽ có một số điều chung và một số cần
quan tâm cụ thể để tập trung vào đó. Mối quan tâm là nên lái các kịch bản đã chọn
cho các phép kiểm thử tính khả dụng.
*** Lập lịch và vị trí

Cho biết khi nào và nơi nào sẽ tiến hành kiểm thử. Ta có thể có được một lịch trình
làm việc cụ thể. Ví dụ, nó có thể cho biết có bao nhiêu phiên tiến hành trong một
ngày và thời gian chính xác các phiên sẽ diễn ra. (Ta sẽ cần những thông tin đó để
tuyển những người sẽ tham gia, vì vậy cần phải tiến hành lập lịch sớm)


8

*** Các phiên
Ta sẽ muốn mô tả các phiên, độ dài của mỗi phiên (thường là từ một giờ đến 90
phút). Khi tham gia lập lịch, hãy để lại cho mình một ít thời gian giữa các phiên để
thiết lập lại môi trường và một thời gian ngắn để xem xét các phiên với các quan
sát viên.
*** Trang thiết bị
Liệt kê các thiết bị sẽ được sử dụng trong các phiên kiểm thử. Bao gồm thông tin
về hệ thống máy tính, kích thước và độ phân giải màn hình, hệ điều hành, trình
duyệt,… Ngaofi ra nếu có kế hoạch ghi âm hoặc ghi hình các buổi kiểm thử âm
thanh hoặc sử dụng công cụ kiểm thử tính năng đặc biệt nào đó.
*** Thành phần tham gia
Cho biết số lượng và loại những người sẽ tham gia thử nghiệm đã được tuyển
dụng. Mô tả cách những người đó tham gia thử nghiệm như thế nào.
*** Kịch bản
Cho biết số lượng và loại nhiệm vụ được bao gồm trong thử nghiệm. Thông
thường chỉ có đến 10 kịch bản là tối đa. Có thể gộp nó vào kế hoạch kiểm thử để
đội có thể lựa chọn các nhiệm vụ thích hợp
*** Số liệu
-

Các số liệu chủ quan: bao gồm các câu hỏi ta sẽ hỏi những người tham gia


trước khi phiên kiểm thử diễn ra (ví dụ, các câu hỏi về background), sau khi mỗi
kịch bản tác vụ được hoàn thành (câu hỏi về sự hài lòng của giao diện các chức
năng), các câu hỏi về sự hài lòng về tổng thể sản phẩm sau khi hoàn thành các
phiên kiểm thử.


9

-

Số liệu định lượng: Chỉ ra các dữ liệu định lượng, sẽ tiến hành đo trong

phép kiểm thử (ví dụ, tỷ lệ hoàn thành thành công, tỷ lệ lỗi, thời gian hoàn thành
tác vụ)
***Vai trò
Bao gồm danh sách của đội ngũ nhân viên, những người sẽ tham gia vào kiểm thử
tính khả dụng và vai trò của từng người. Các chuyên gia về tính khả dụng sẽ điều
phối cac phiên. Nhóm nghiên cứu tính khả dụng có thể cung cấp cho người có
nhiệm vụ ghi chép. Các thành viên trong các team khác nên được tham gia với vai
trò là quan sát viên, chẳng hạn như người ghi chép lại các chú ý.

II.

Tìm người dùng thử và lựa chọn người dùng thử

1.

Tại sao cần người dùng thử?

Tìm người dùng thử là việc làm cần thiết trong kiểm thử tính tiện dụng.

Thật vậy, người dùng thử nghiệm chính là phương pháp đem lại hiệu quả cao với
mức chi phí không hề cao. Và nếu thực hiện sớm và thường xuyên, nó có thể giúp
người phát triển tiết kiệm hàng ngàn đô la cũng như nhiều tháng trong quá trình
phát triển.
Các nhà phát triển và thiết kế đồ họa là những người rất tài năng, nhưng họ không
giống những người dùng sẽ tiếp xúc với sản phẩm sau này. Họ có cách nhìn nhận
khác nhau với những vốn từ vựng hoàn toàn khác nhau. Do đó, những người thiết
kế thường tạo ra các sản phẩm không được dễ hiểu và dễ sử dụng cho lắm đối với
những người sử dụng cuối.
Theo Jakob Nielsen, tác giả cuốn “Usability Engineering”, thì chỉ cần 5 người
dùng để có thể phát hiện ra những vấn đề nghiêm trọng trong tính tiện dụng của
sản phẩm.
2.

Tìm người dùng thử nghiệm như thế nào?


10

Có rất nhiều nguồn để tìm những người tham gia làm người dùng thử nghiệm.
Điều quan trọng là họ có hiểu biết về những lĩnh vực mà bạn muốn kiểm thử. Ví
dụ:
-

Chơi các trò chơi trực tuyến
Thực hiện các cuộc bầu chọn
Kế hoạch nghỉ ngơi
Mua sắm một chiếc xe mới
Điều trị một căn bệnh mãn tính nào đó


Lưu ý rằng không thực hiện các vấn đề liên quan đến dân số hay nhân khẩu ở đây.
Sau khi xác định được chức năng muốn tiến hành kiểm thử, tốt hơn là bằng cách
quan sát những người sử dụng thiết kế chứ không phải là yêu cầu họ đưa ra ý
tưởng, hãy suy nghĩ về những điều có thể làm cho người dùng cảm thấy thỏa mãn.
Có vô số những lựa chọn về người dùng thử.
Những đối tượng nên xem xét
Bạn bè và gia đình:
Ta có thể mời bạn bè và gia đình của mình tham gia những nghiên cứu, nếu họ
chính là người có kỹ năng về vấn đề mà ta đang quan tâm. Đây là một cách tuyệt
vời để giữ bí mật bởi ta có thể yêu cầu họ giữ bí mật, không tiết lộ ra ngoài. Họ sẽ
giữ cam kết với ta.
Những người này là một nguồn người dùng thử nghiệm rất tốt mà không phải lúc
nào ta cũng nhận ra. Ta có thể mô tả những gì mình đang cần và yêu cầu họ làm
giúp. Nếu biết đưa ra những yêu cầu hợp lý và hấp dẫn thì mọi người có thể sẽ
tham gia mà không yêu cầu bất cứ một khoản thù lao nào.
-

Người dùng của các nhóm, các tổ chức mang tính cộng đồng, các câu lạc bộ

có tính xã hội:
Hãy kêu gọi những người đứng đầu của các câu lạc bộ, các nhóm mà bạn biết như
các tổ chức từ thiện, các câu lạc bộ thể thao, cờ vua, bơi lội, … hay bất cứ nhóm


11

nào mà ta có quan hệ và có thể nghĩ tới. Ta có thể sẽ thu được một lượng lớn
những người quan tâm đến vấn đề của mình. Những mạng lưới này sẽ làm việc
thật sự tốt nếu thử nghiệm của ta có liên quan đến hoạt động của họ, cũng có nhiều
người sẽ tham gia chỉ vì họ tò mò hay thích khám phá.

-

Các mạng xã hội trực tuyến:

Có rất nhiều mạng xã hội trực tuyến miễn phí có lượng người dùng lớn hiện nay,
như Twitter, Facebook, Google+… Hãy tham gia bất kỳ một trang mạng xã hội
nào có thể, và đưa ra đề nghị của mình. Có thể những người bạn của ta trên đó
không hẳn là người mà ta muốn họ tham gia dùng thử, nhưng ít nhất họ cũng có
thể giới thiệu cho ta những người phù hợp
Tất cả những nguồn trên tuy là phong phú và dễ tìm nhưng nó không tự xuất hiện.
Ta cần chủ động tham gia và hoạt động để có được các mối quan hệ cần thiết.
Việc tìm người dùng thử được thực hiện với những sản phẩm cả trong cuộc sống
thật lẫn trực tuyến. Và nhóm đối tượng nêu trên được áp dụng cho cả hai nơi đó.
Trong cuộc sống thực, nó giúp tiếp cận những người đang đang hoặc thường làm
những việc mà ta muốn thử nghiệm mà bản thân ta lại không thực hiện. Ví dụ nếu
đang phát triển phần mềm kế toán thì có thể tìm đến những người đang làm kế
toán, yêu cầu họ thực hiện công việc của họ trên sản phẩm của mình và đưa ra
những ý kiến, nhận xét hay góp ý.
Nếu là trực tuyến (website bán hàng….), ta có thể yêu cầu những người dùng thử
thực hiện việc thử nghiệm qua mạng, ngay trên chính sản phẩm của mình hoặc bản
dùng thử (đã được đưa trên mạng). Ví dụ, nếu muốn thử nghiệm tính dùng được
của chức năng đặt mua xe hơi của website(trong khi bản thân không có đủ tiền để
mua chẳng hạn) thì ta sẽ tìm đến những đại lý xe hơi, gặp gỡ những người đang có
ý định hoặc đã mua rồi, thuê hoặc nhờ họ kiểm nghiệm sản phẩm của mình.
3.

Tại sao chỉ cần tiến hành kiểm thử với 5 người dùng


12


Nhiều người nghĩ rằng tính tiện dụng của sản phẩm rất tốn kém và phức tạp, và
rằng người dùng thử dành cho dự án có thể sẽ cần một ngân sách lớn và kế hoạch
lâu dài. Điều đó không đúng. Xây dựng một đội ngũ người dùng thử lớn là một sự
lãng phí tài nguyên. Kết quả tốt nhất từ các cuộc thử nghiệm không nhiều hơn 5
người và chạy các test nhỏ nhất có thể.
Trong một nghiên cứu trước đây, Tom Landauer và Jakob Nielsen đã chỉ ra rằng số
lượng các vấn đề về tính dùng được được tìm thấy trong các cuộc kiểm thử với n
người dùng là:
N(1-(1-L)2)
Trong đó N là tổng số vấn đề của tính tiện dụng trong thiết kế và L là tỉ lệ các vấn
đề được phát hiện bởi một người dùng. Giá trị điển hình của L là 31% đối với một
lượng lớn các dự án mà họ đã nghiên cứu. Vẽ đường cong cho L=31% cho kết quả
như sau:


13

Sự thật rõ ràng nhất cùa đường cong trên là nếu không có người dùng nào thì tỉ lệ
là 0%
Ngay khi có được dữ liệu từ người đầu tiên, những hiểu biết đã vọt lên và ta đã
biết được gần một phần ba các vấn đề về tính tiện dụng của thiết kế. Sự khác biệt
giữa 0 và một chút dữ liệu có được thật sự đáng kinh ngạc.
Khi sử dụng đến người thứ hai, ta sẽ thấy rằng người này thực hiện một số điều
tương tự như người đầu tiên, vì vậy sẽ có những điều chồng chéo trong tất cả
những điều ta thu được. Tuy nhiên, mọi người chắc chắn không ai giống ai hoàn
toàn, do đó cũng sẽ có một cái gì đó mới ở người thứ hai mà ta không thấy ở
người thứ nhất. Vì vậy, người thứ hai sẽ cho biết thêm một số cái nhìn khá sâu sắc
mới, nhưng hầu như là không nhiều như người đầu tiên.
Người dùng thử thứ ba sẽ làm lại nhiều việc mà ta thu được từ người thứ nhất hoặc

thứ hai, và thậm chí có những điều ta đã thấy cả 2 lần. Nhưng người thứ ba này
cũng sẽ tạo ra một lượng dữ liệu nhỏ mới, dù không nhiều như người đầu tiên
hoặc người thứ hai đã làm.
Khi thêm càng nhiều người dùng thử hơn, ta càng thu được ít dữ liệu hơn vì ta sẽ
tiếp tục phải nhìn thấy những điều tương tự nhau. Khi đó ta không cần tiếp tục
thực hiện các phép thử nghiệm nữa và nên quay trở lại thiết kế của mình để loại bỏ
các vấn đề về tính tiện dụng đã được phát hiện.
Sau người dùng thử thứ năm, ta sẽ lãng phí thời gian bằng cách tiếp tục quan sát
những điều lặp đi lặp lại mà không thu được gì nhiều.
Lặp đi lặp lại thiết kế
Đường cong trên rõ ràng cho thấy rằng cần phải thử nghiệm với ít nhất 15 người
để khám phá ra tất cả các vấn đề về tính tiện dụng của thiết kế. Vậy, tại sao lại nên
thử nghiệm với một số lượng nhỏ hơn?


14

Lý do chính là điều đó sẽ tốt hơn nếu phân phối ngân sách cho thử nghiệm với
người dùng qua nhiều thử nghiệm nhỏ thay vì sử dụng nhiều người mà chỉ thực
hiện một lần thử nghiệm. Hãy thấy rằng không có kinh phí để thuê 15 khách hàng
để thử nghiệm thiết kế một lần, mà hãy chi tiêu số tiền đó để thực hiện 3 lần thử
nghiệm với 5 người.
Ta cần thử nghiệm nhiều lần vì mục đích thực sự của việc kiểm thử tính dùng
được là để cải thiện thiết kế chứ không phải chỉ để ghi lại những điểm yếu của nó.
Sau nghiên cứu với 5 người dùng đầu tiên đã có thể tìm thấy 85% vấn đề, đây là
lúc nên sửa lại những vấn đề trong thiết kế.
Sau khi tạo ra các thiết kế mới, ta cần phải kiểm tra lại một lần nữa. Mặc dù những
vấn đề của thiết kế đầu tiên đã được sửa, và nhiều người nghĩ rằng thiết kế mới đã
hoàn toàn khắc phục được những vấn đề đó. Nhưng không ai có thể thiết kế một
giao diện người dùng hoàn hảo, nên không thể đảm bảo rằng thiết kế mới đã thật

sự tốt. Một cuộc kiểm thử thứ hai sẽ cho thấy xem bản sửa lỗi có làm việc hay
không. Ngoài ra, việc kiểm tra lại thiết kế này có thể sẽ chỉ ra vấn đề mới của tính
dùng được, ngay cả khi bản cũ đã được sửa.
Ngoài ra các thử nghiệm lần hai với 5 người dùng thử sẽ tìm ra hầu hết 15% các
vấn đề còn lại của tính tiện dụng mà lần đàu không tìm thấy. (Sẽ vấn còn 2% còn
sót lại, và sẽ phải đợi đến lần thử nghiệm thứ 3)
Cuối cùng, lần kiểm thử thứ 2 sẽ thăm dò sâu hơn vào tính tiện dụng của cấu trúc
cơ bản của sản phẩm, đánh giá các vấn đề như kiến trúc thông tin, task flow, và sự
phù hợp với người dùng. Những vấn đề quan trọng thường bị che khuất trong lần
đầu bởi người dùng thử bị bối rối trước mức độ chỉ mang tính bề mặt thậm chí có
phần dễ dàng của tính tiện dụng , làm họ không thực sự hiểu sâu về sản phẩm.
Vì vậy, lần kiểm thử thứ 2 sẽ làm tốt cả 2 việc là đảm bảo chất lượng các kết quả
của lần đầu và cung cấp những vấn đề sâu sắc hơn. Lần thử nghiệm thứ 2 sẽ đem
lại một danh sách (nhỏ hơn lần 1) các vấn đề của tính tiện dụng cần được sửa. Và


15

cũng tương tự như lần 1: không phải tất cả các bản sửa lỗi đều làm việc, một số
vấn đề sâu hơn sẽ được phát hiện sau khi “làm sạch” giao diện. Do đó, một cuộc
thử nghiệm lần 3 là cần thiết.
Kinh nghiệm cho thấy thiết kế được cải thiện tốt hơn bằng cách kiểm thử 3 lần với
5 người hơn là một lần với 15 người.
Tại sao lại không thực hiện kiểm thử với chỉ 1 người?
Có thể có người sẽ nghĩ rằng vậy thì làm 15 thử nghiệm với 1 người sẽ tốt hơn so
với làm 3 thử nghiệm trên 5 người. Đường cong cũng cho thấy ta tìm được nhiều
lỗi hơn từ người đầu tiên so với tất cả những người sau đó. Vậy tại sao phải tiếp
tục với những người khác? Có hai lý do:
Luôn luôn có một rủi ro sẽ bị lạc hướng bởi 1 người thường có các hành vi lặp đi
lặp lại hoặc không có tính chất đại diện. Thậm chí chỉ cần 3 người là đủ để thấy

được sự đa dạng trong hành vi của người dùng và cái nhìn sâu sắc vào những gì là
độc đáo và những gì có thể tổng quát được.
Các phân tích về chi phí – lợi ích của kiểm thử người dùng cung cấp cho ta những
tỷ lệ tối ưu là khoảng 3 đến 5 người, tùy vào loại kiểm thử. Luôn có một chi phí cố
định ban đầu liên quan đến việc lập kế hoạch và chạy một kiểm thử, và để giảm
chi phí này thì nên dùng nhiều người hơn.
Khi nào cần thử nghiệm trên nhiều người dùng hơn
Cần tiến hành kiểm thử trên nhiều người dùng hơn khi một trang web có một số
nhóm người sử dụng khác biệt. Công thức trên đây chỉ đúng cho những người
dùng sử dụng trang web theo những cách khá giống nhau.
Ví dụ, một trang web được sử dụng bỏi cả trẻ em và các phụ huynh, hai nhóm
người dùng này sẽ có hành vi khác nhau. Khi đó cần phải tiến hành kiểm thử với


16

cả 2 nhóm. Điều này cũng đúng cho một hệ thống có mục đích kết nối giữa các đại
lý mua bán với đội ngũ nhân viên.

III. Xác định các nhiệm vụ kiểm thử
Nhiệm vụ của kiểm thử tính tiện dụng được ví là quả tim của kiểm thử tính tiện
dụng. Những nhiệm vụ này xác định các bộ phận của một hệ thống mà người tham
gia kiểm thử sẽ xem và tương tác. Nhiệm vụ của kiểm thử tính tiện dụng là rất
quan trọng, thậm chí còn quan trọng hơn số lượng người tham gia
Kịch bản cho nhiệm vụ của kiểm thử tính tiện dụng cần những thành phần sau:
-

Số thứ tự và tên nhiệm vụ

Đánh số và đặt tên cho mỗi nhiệm vụ. Tên của nhiệm vụ giúp ta nhớ được mục

đích của nó là gì, số thứ tự giúp ta biết được thứ tự thực hiện các task mà không
cần biết cụ thể nội dung mỗi task là gì.
-

Goal/outputs

Người dùng sẽ làm những gì khi họ đã thực hiện xong task của mình? Đó có phải
là những đầu ra nhìn thấy được? Làm thế nào họ biết được task của mình đã hoàn
thành? Liệu người dùng có thể làm một cách chắc chắn hay không?
-

Inputs

Liệt kê tất cả các thông tin hay tài nguyên – hữu hình và vô hìn – mà một người
dùng sẽ cần để hoàn thành được task đó. Một số ví dụ: một log – in đúng, các đối
tượng vật lý như sách hay thẻ tín dụng, các tên file,… Người dùng thật có thể có
một vài thông tin trên trong đầu họ - trong task tính tiện dụng ta có thể phải cung
cấp những thông tin này một cách thuộc lòng, nhưng ta cần phải tạo một sơ đồ
mạng lưới với các chi tiết liên quan, như tên server và địa chỉ IP.
-

Các giả định


17

Các giả định là các điều kiện và những tiền yêu cầu mà ở đó task bắt đầu. Các giả
định phụ thuộc vào việc ta muốn thu được gì từ task đó. Ví dụ, nếu một task chỉ ra
làm thế nào để người dùng phục hồi được nếu bị lỗi từ các bản ghi sao chép, các
giả định của ta phải bao gồm điều kiện để các lỗi có thể xảy ra, chẳng hạn, “một

nhân viên với tên đã tồn tại trong cơ sở dữ liệu”
-

Các bước

Viết ra các bước ta mong muốn người dùng sẽ thực hiện trong khi hoàn thành task.
Điều này giúp ta định ra các bản mẫu mà ta sẽ cần phải tạo. Viết ra các bước mong
đợi có thể có ích nếu những người quan sát không quen với giao diện giống ta.
Giữ các bước hầu hết chỉ ở mức màn hình – không cần phải liệt kê tất cả mọi
trường có trên form.
-

Ước lượng thời gian

Ước lượng xem mất bao lâu để một chuyên gia (ai đó trong đội phát triển thiết kế)
cần để hoàn thành một task. Bỏ qua mọi thời gian mà hệ thống cần để thực hiện
tiến trình của nó và chỉ chú ý đến thời gian nhập dữ liệu và click các nút. Một vài
task, chẳng hạn như soạn một email, yêu cầu thời gian để suy nghĩ hay tạo công
việc, nên thời gian có thể tính như vậy.
-

Hướng dẫn người dùng

Đừng viết những hướng dẫn cho người dùng khi còn đang làm nốt phần cuối của
template. Mặc dù thiết kế task có tốt như một nhóm hoạt động, viết các hướng dẫn
có thể được làm bởi một người sau khi có bản nháp của task.
-

Notes


Các phần ghi chú thường ghi lại các loại của thông tin, bao gồm các lý do tại sao
lại tạo task, những đặc thù cần chú ý, và các câu hỏi cho người dùng sau khi task
hoàn thành. Thông tin bao gồm nhiều ghi cú khác nhau phụ thuộc vào việc test cái


18

gì. Viết ra bất kỳ thông tin nào cảm thấy nó có ích trong suốt quá trình kiểm thử
tính tiện dụng.

IV.

Đánh giá hiệu năng

Hiệu năng là số phần trăm của những người tham gia, đó là những người có kinh
nghiệm về các vấn đề khi làm việc trong một task.
-

Cao: kinh nghiệm phát hiện vấn đề của những người tham gia lớn hơn hoặc

bằng 30%
Trung bình: kinh nghiệm phát hiện lỗi của những người tham gia từ 11% 29%
Thấp: kinh nghiệm phát hiện lỗi của những người tham gia thấp hơn hoặc
bằng 10%

V.

Ví dụ minh họa

1.


Giới thiệu chung

Ví dụ về hoạt động kiểm thử tính dùng được cho website của ERS (Economic
Research Service), một trong bốn cơ quan Nghiên cứu, Giáo dục và Kinh tế (REE)
có nhiệm vụ nghiên cứu về diện tích của bộ Nông nghiệp Mỹ.
Web dựa trên bản đồ tương tác trở thành công cụ mạnh mẽ cho người dùng sử
dụng ERS để truy cập và hình dung ra các thông tin phức tạp. ERS hiện có 20 các
sản phẩm tương tác dữ liệu, trong đó có 5 có kết hợp các tính năng lập bản đồ chi
tiết về không gian địa lý.
2.

Các mục tiêu

ERS yêu cầu các nhà thầu dịch vụ để cung cấp tính dùng được và các tiêu chuẩn
hỗ trợ phát triển sản phẩm dựa trên web của cơ quan trực quan lập bản đồ GIS.
ERS muốn sử dụng phương thức XXXMethodTM để thiết kế, phát triển và cài đặt
một bộ tiêu chuẩn các tính năng để cải thiện tính hữu dụng và những tác động của
sản phẩm đến cơ quan lập bản đồ GIS.


19

XXXMethodTM, một chứng chỉ ISO về quá trính trong lĩnh vực khoa học kỹ thuật
có các yếu tố lien quan đến con người, là quá trình thiết kế lấy người dùng làm
trung tâm nhằm hỗ trợ tối ưu hóa thiết kế web phục vụ người dùng.
3.

Các nhiệm vụ


Dự án này có hai nhiệm vụ. Nhà thầu phải cung cấp các báo cáo, tài liệu và
chuyển giao dưới dạng điện tử và sẽ cung cấp báo cáo tiến độ hang tháng bằng văn
bản.
-

Task 1: Kick – off dự án và xác định FFP:_________

Nhà thầu phải tổ chức một buổi kick – off dự án với ERS để đánh giá các ứng
dụng lập bản đồ GIS dựa trên MethodTMXXXX
Nhà thầu có trách nhiệm:
+ Hỗ trợ tổ chức kick – off dự án với ERS Improved Data Delivery
Working Group to:
Rà soát dự án
Rà soát lịch biểu và phân phối
Rà soát các yêu cầu “mức trên” của dự án và mong muốn của ERS
về vai trò, đầu vào, đầu ra, và thông tin tổng thể
Xác định người dùng hiện tại và tương lai của các sản phẩm bản đồ
GIS ERS để phát triển một sự hiểu biết thấu đáo về các mục tiêu, nhiệm vụ điển
hình của chúng, và các khó khăn cụ thể có thể gặp phải. Những người dùng này có
thể bao gồm những đại diện như: người dùng cá nhân ERS, các nhân viên ERS
(các nhà phân tích), và các nhà phân tích tại các cơ quan lien bang khác (APHIS,
FSA).


20

Xây dựng hoặc rà soát hồ sơ người dùng (danh sách các đặc tính của
người sử dụng)
Xác định rõ tầm nhìn, sứ mệnh và mục tiêu cho các sản phẩm GIS
ERS (có thể thay đổi tùy theo phản ứng)

Lien kết mục tiêu của sản phẩm GIS với các mục tiêu của cơ quan
ERS.
Rà soát kế hoạch dự án ở mức độ cao và thời gian.



Phân phối Task 1

Date due: 08-May-2012
1.
2.

Kick-off hội thảo
3-5 trang ghi nhớ tóm tắt kết quả hội thảo và các khuyến nghị đi kèm

-

Task 2: phân tích tính khả dụng, kiểm thử và các phiên rà soát nhân

viên
Nhà thầu phải thực hiện việc kiểm thử tính khả dụng của một sản phẩm GIS ERS
cụ thể dựa trên MethodTMXXXX và tổ chức một phiên họp với các bên liên quan
đến dự án ERS để xem xét kết quả thử nghiệm.
Nhà thầu có trách nhiệm:
1.

Trao đổi bằng điện thoại với đội GIS ERS để xác nhận sản phẩm GIS dùng

để kiểm thử, cùng với nhiệm vụ trọng tâm, xác định các mục tiêu của việc thử
nghiệm, thiết lập tiêu chuẩn hoàn thành nhiệm vụ, và xác định mục tiêu người

dùng.


21

2.

Làm việc với ERS để nháp một kịch bản thử nghiệm cho một vòng thử

nghiệm tính khả dụng.
3.
Cung cấp ERS với hai vòng sửa đổi kịch bản thử nghiệm dựa trên ý kiến từ
các nhân viên thiết kế ERS.
4.
Tiến hành một đợt kiểm thử tính khả dụng với 8 thành viên đại diện của các
sản phẩm GIS, 4 người trong hai nhóm người dùng.
5.
ERS sẽ chịu trách nhiệm tuyển dụng, lập kế hoạch, sang lọc, và hoàn trả đại
diện người sử dụng.
6.
Biên dịch và phân tích kết quả kiểm thử tính khả dụng để phát triển một
báo cáo bằng văn bản, bao gồm cả ảnh chụp màn hình, bảng xếp hạng mức độ
nghiêm trọng của các vấn đề, xác định sự cân bằng để giải quyết các mục tiêu mâu
thuẫn nhau và đề nghị giải quyết các xung đột, đưa ra khuyến nghị để cải thiện các
sản phẩm GIS.
7.
Trình bày tại chỗ các kết quả cho ERS Improved Data Delivery Working
Group.

Phân phối Task 2

Date due: 10-May-2012
1.
2.
3.
4.

Dự thảo và kịch bản kiểm thử tính khả dụng cuối cùng
Tạo thuận lợi cho kiểm thử tính khả dụng
Viết báo cáo kết quả việc kiểm thử tính khả dụng
Trình bày bằng lời cùng với trình chiếu slide bằng MS PowerPoint về các

kết quả dựa trên báo cáo kiểm thử tính khả dụng
5.
Thời gian còn lại trong ngày để tư vấn và ăn trưa với đội GIS
(Ví dụ có tham khảo tại website: />


×