Chương 3 đề cập đến kiểm thử tĩnh, tài liệu và code, nhưng không thực thi code.

Chương này xem xét kiểm thử động, trong đó phần mềm được chạy bằng cách thực
hiện kiểm thử trên code đang chạy.

XÁC ĐỊNH ĐIỀU KIỆN KIỂM THỬ VÀ THIẾT

KẾTRƯỜNG HỢP KIỂM THỬ
Các nội dung sẽ có trong đề thi ISTQB Foundation (CTFL)
1. Phân biệt giữa đặc tả thiết kế kiểm thử, đặc tả trường hợp kiểm thử và đặc tả
quy trình kiểm thử. (K1)
2. So sánh điều kiện kiểm thử, trường hợp kiểm thử và quy trình kiểm thử. (K2)
3. Viết test case: (K3)
thể hiện khả năng truy xuất nguồn gốc rõ ràng đối với các yêu cầu; chứa một
kết quả mong đợi.
4. Chuyển các trường hợp kiểm thử thành đặc tả quy trình kiểm thử có cấu trúc tốt
ở mức độ chi tiết phù hợp với kiến thức của người kiểm thử. (K3)
5. Viết lịch trình thực hiện kiểm thử cho một tập hợp các trường hợp kiểm thử
nhất định, xem xét mức độ ưu tiên và các phụ thuộc logic và kỹ thuật. (K3)

Giới thiệu
Trước khi thực sự có thể thực hiện một bài kiểm thử, cần biết chúng ta đang cố gắng
kiểm thử những gì, đầu vào, kết quả được tạo ra bởi những đầu vào đó và cách mà
chúng ta thực sự sẵn sàng và chạy các bài kiểm thử.

Trong phần này, ta xem xét ba điều: điều kiện kiểm thử, trường hợp kiểm thử và thủ
tục kiểm thử (hoặc tập lệnh) - các nội dung này sẽ được mô tả trong ở dưới. Mỗi nội
dung được chỉ định trong tài liệu riêng, theo Tiêu chuẩn tài liệu kiểm thử [IEEE829].

Các điều kiện thử nghiệm được tài liệu hóa trong đặc tả thiết kế kiểm thử (Test
Design Specification). Chúng ta sẽ xem xét cách chọn các điều kiện kiểm thử và cách
đánh độ ưu tiên cho chúng

Các trường hợp kiểm thử được ghi lại trong Đặc tả trường hợp kiểm thử (Test Case
Specification). Chúng ta sẽ xem xét cách viết một trường hợp kiểm thử tốt, cho thấy
khả năng truy nguyên rõ ràng đến cơ sở kiểm thử (ví dụ: đặc tả yêu cầu) cũng như các
điều kiện kiểm thử.
Thủ tục kiểm thử (test procedure) được ghi lại (như bạn kì vọng) trong một đặc tả thủ
tục kiểm thử (còn được biết đến với tên gọi là tập lệnh kiểm thử hoặc tập lệnh kiểm
thử thủ công). Chúng ta sẽ xem xét cách dịch các trường hợp kiểm thử thành các thủ
tục kiểm thử phù hợp với kiến thức của người kiểm thử (là những người sẽ thực hiện
kiểm thử) và xem cách tạo lịch biểu thực hiện kiểm thử, sử dụng việc đánh mức độ ưu
tiên và các phụ thuộc logic và kỹ thuật.

Trong phần này, hãy tìm định nghĩa của các thuật ngữ: trường hợp kiểm thử (test
case), đặc tả trường hợp kiểm thử (test case specification), điều kiện kiểm thử (test
condition), dữ liệu kiểm thử (test data), đặc tả thủ tục kiểm thử (test procedure
specification), kịch bản kiểm thử (test script) và truy xuất nguồn gốc (traceability).

Hình thức của tài liệu kiểm thử

Việc kiểm thử có thể được thực hiện với các mức độ hình thức khác nhau. Kiểm thử
rất chính thức nên có nhiều tài liệu được kiểm soát tốt và nên kì vọng vào mức độ chi
tiết của tài liệu của việc kiểm thử, bao gồm đầu vào và đặc tả chính xác cũng như kết
quả mong đợi của việc kiểm thử. Kiểm thử rất không chính thức có thể không có tài
liệu nào cả, hoặc chỉ có các ghi chú được lưu giữ bởi từng người kiểm thử, nhưng
chúng ta vẫn mong đợi những người kiểm thử ghi nhớ và ghi chú một số ý tưởng về
những gì họ dự định kiểm thử và những kết quả mong đợi mà họ kì vọng.

Mức độ chính thức phù hợp tùy thuộc vào ngữ cảnh: một ứng dụng quan trọng về an
toàn thương mại có những nhu cầu rất khác so với một ứng dụng dùng một lần chỉ
được một số ít người sử dụng trong một thời gian ngắn.

Mức độ chính thức cũng bị ảnh hưởng bởi tổ chức - văn hóa của tổ chức, những người
làm việc ở đó, quy trình phát triển hoàn thiện như thế nào, quy trình kiểm thử hoàn
thiện như thế nào.... Tính kỹ lưỡng của tài liệu kiểm thử cũng có thể phụ thuộc vào
hạn chế về thời gian; dưới áp lực thời hạn quá mức, việc lưu giữ tài liệu tốt có thể bị
tổn hại.

Chương này mô tả kiểu tài liệu hóa khá trang trọng. Nếu điều này không phù hợp với
bạn, bạn có thể áp dụng cách tiếp cận ít trang trọng hơn, nhưng bạn sẽ biết cách tăng
tính trang trọng nếu cần.

Phân tích kiểm thử: xác định điều kiện kiểm thử
Phân tích kiểm thử là quá trình xem xét một cái gì đó có thể được sử dụng để lấy
thông tin kiểm thử. Cơ sở cho các bài kiểm thử này được gọi là "cơ sở kiểm thử". Nó
có thể là một yêu cầu hệ thống, một đặc tả kỹ thuật, bản thân code (để kiểm thử cấu
trúc) hoặc một quy trình nghiệp vụ. Đôi khi, việc kiểm thử có thể dựa trên kiến thức
của người dùng có kinh nghiệm về hệ thống, điều này có thể không được ghi chép lại.
Cơ sở kiểm thử bao gồm bất cứ điều gì mà các bài kiểm thử dựa vào. Điều này cũng
đã được thảo luận trong Chương 1.

Từ góc độ kiểm thử, xem xét cơ sở kiểm thử để xem những gì có thể được kiểm thử -
đây là các điều kiện kiểm thử. Điều kiện kiểm thử (test condition) đơn giản chỉ là
thứ mà chúng ta có thể kiểm thử. Nếu chúng ta đang tìm cách đo độ bao phủ của các
quyết định của code (nhánh), thì cơ sở kiểm thử sẽ là chính mã code đó và danh sách
các điều kiện kiểm thử sẽ là kết quả quyết định (Đúng và Sai). Nếu có một đặc tả yêu
cầu, mục lục có thể là danh sách ban đầu về các điều kiện kiểm thử.

Một cách tốt để hiểu các yêu cầu tốt hơn đo là cố gắng xác định các bài kiểm thử đáp
ứng được các yêu cầu đó, như [Hetzel, 1988] đã chỉ ra.

Ví dụ, nếu đang kiểm thử hệ thống tiếp thị và quản lý khách hàng cho một công ty
điện thoại di động, có thể có các điều kiện kiểm thử liên quan đến chiến dịch tiếp thị,
chẳng hạn như độ tuổi của khách hàng (dưới tuổi vị thành niên, thiếu niên, thanh niên,
trưởng thành), giới tính, mã bưu chính hoặc mã zip và tùy chọn mua hàng (thanh toán
theo mức sử dụng hoặc hợp đồng). Ví dụ, một chiến dịch quảng cáo cụ thể có thể
nhắm đến các khách hàng nam thanh thiếu niên ở miền trung tây Hoa Kỳ theo hình
thức trả tiền khi sử dụng.

Các chuyên gia kiểm thử sử dụng nhiều tên gọi khác nhau để thể hiện ý tưởng cơ bản
về "danh sách những thứ có thể kiểm thử".

Ví dụ, Marick đề cập đến "yêu cầu kiểm thử" là những thứ cần được kiểm thử. Mặc
dù, nó không có ý ám chỉ rằng mọi thứ cần phải được kiểm thử, nhưng cũng quá dễ
dàng để diễn giải theo cách như vậy. [Marick, 1994]

Ngược lại, Hutcheson nói về "kiểm thử tồn kho" (test inventory) như một danh sách
những thứ có thể kiểm thử [Hutcheson, 2003].

Craig nói về "mục tiêu kiểm thử" như là những thể loại rộng rãi của những thứ cần
kiểm thử, và "kiểm thử tồn kho" là danh sách thực tế những thứ cần được kiểm thử
[Craig, 2002].

Tất cả các tác giả này đều đề cập đến thuật ngữ ISTQB điều kiện kiểm thử (test
condition).
Khi xác định các điều kiện kiểm thử, chúng ta muốn "mở rộng mạng lưới" để xác định
càng nhiều điều kiện càng tốt, sau đó bắt đầu chọn lọc xem điều kiện nào tiếp tục phát
triển chi tiết hơn và kết hợp thành các trường hợp kiểm thử. Có thể gọi chúng là "khả
năng kiểm thử" (test possibilities).

Trong Chương 1, đã giải thích rằng kiểm thử mọi thứ được gọi là kiểm thử toàn bộ
(được định nghĩa là thực hiện mọi kết hợp đầu vào và điều kiện tiên quyết) và chúng
ta đã chứng minh rằng đây là một mục tiêu không thực tế. Do đó, vì không thể kiểm
tra mọi thứ, ta phải chọn một tập hợp con của tất cả các kiểm thử có thể. Trong thực
tế, tập hợp con được chọn có thể là một tập hợp con rất nhỏ và nó phải có xác suất cao
tìm thấy hầu hết các lỗi trong hệ thống. Cần một số quy trình tư duy thông minh để
hướng dẫn lựa chọn; kỹ thuật kiểm thử (test techniques) (tức là kỹ thuật thiết kế kiểm
thử) là những quy trình tư duy như vậy.

Một kỹ thuật kiểm thử giúp ta chọn một tập các kiểm thử tốt từ tổng số tất cả các bài
kiểm thử có thể có. Các kỹ thuật khác nhau đưa ra những cách nhìn khác nhau về
phần mềm đang được kiểm thử, có thể thách thức các giả định được đưa ra về nó. Mỗi
kỹ thuật cung cấp một bộ quy tắc hoặc hướng dẫn để người kiểm thử tuân theo trong
việc xác định các điều kiện kiểm thử và trường hợp kiểm thử. Các kỹ thuật được mô
tả chi tiết sau trong chương này.

Các điều kiện kiểm thử được chọn sẽ phụ thuộc vào chiến lược kiểm thử hoặc phương
pháp kiểm thử chi tiết. Ví dụ, chúng có thể dựa trên rủi ro, mô hình hệ thống, lỗi có
thể xảy ra, yêu cầu tuân thủ, lời khuyên của chuyên gia hoặc tự tìm tòi.

Từ "tự tìm tòi" (heuristic) xuất phát từ cùng một gốc tiếng Hy Lạp với eureka, có
nghĩa là "tôi tìm thấy". Heuristic là một cách hướng sự chú ý của bạn, một quy tắc
thông thường hữu ích trong việc giải quyết vấn đề.

Các điều kiện kiểm thử sẽ có thể được liên kết trở lại nguồn của chúng trong cơ sở
kiểm thử - điều này được gọi là truy xuất nguồn gốc (traceability).

Truy xuất nguồn gốc có thể theo chiều ngang thông qua tất cả các tài liệu kiểm thử ở
một cấp độ kiểm thử nhất định (ví dụ: kiểm thử hệ thống, từ điều kiện kiểm thử thông
qua trường hợp kiểm thử đến tập lệnh kiểm thử) hoặc theo chiều dọc thông qua các
lớp tài liệu phát triển (ví dụ: từ yêu cầu đến thành phần).

Tại sao truy xuất nguồn gốc lại quan trọng? Hãy xem xét các ví dụ sau:

 Các yêu cầu đối với một chức năng hoặc tính năng nhất định đã thay đổi. Một
số trường thì dải giá trị khác nhau có thể nhập được. Những bài kiểm thử nào
 đang xem xét những giá trị biên đó? Những giá trị này cần phải thay đổi. Có
bao nhiêu bài kiểm thử thực sự sẽ bị ảnh hưởng bởi sự thay đổi này trong các
yêu cầu? Những câu hỏi này có thể được trả lời dễ dàng nếu các yêu cầu có thể
dễ dàng được truy xuất từ các bài kiểm thử.
 Một tập hợp các bài kiểm thử đã chạy tốt trong quá khứ đã bắt đầu có vấn đề
nghiêm trọng. Những bài kiểm thử này thực sự thực hiện chức năng gì? Khả
năng truy xuất nguồn gốc giữa các bài kiểm thử và yêu cầu đang được kiểm thử
cho phép các chức năng hoặc tính năng bị ảnh hưởng được xác định dễ dàng
hơn.
 Trước khi cung cấp một bản phát hành mới, chúng ta muốn biết liệu đã kiểm
tra tất cả các yêu cầu được chỉ định trong đặc tả yêu cầu hay chưa. Chúng ta có
danh sách các bài kiểm thử đã vượt qua - mọi yêu cầu đã được kiểm thử chưa?

Sau khi đã xác định danh sách các điều kiện kiểm thử, điều quan trọng là phải ưu tiên
chúng để xác định các điều kiện kiểm thử quan trọng nhất (trước khi dành nhiều thời
gian cho việc thiết kế các trường hợp kiểm thử dựa trên chúng). Bạn nên thử và nghĩ
về gấp đôi số điều kiện kiểm thử nếu bạn cần - sau đó bạn có thể loại bỏ những điều
kiện ít quan trọng hơn và bạn sẽ có một tập hợp các điều kiện kiểm thử tốt hơn nhiều!

Lưu ý rằng việc dành thêm thời gian ngay bây giờ để xác định các điều kiện kiểm thử
sẽ không mất nhiều thời gian vì chúng ta chỉ liệt kê những thứ có thể kiểm thử. Đây là
một khoản đầu tư tốt cho thời gian của chúng ta - chúng ta không muốn dành thời gian
thực hiện các bài kiểm thử kém!

Điều kiện kiểm thử có thể được xác định cho dữ liệu kiểm thử cũng như đầu vào kiểm
thử và kết quả kiểm thử, ví dụ: các loại bản ghi khác nhau, phân phối các loại bản ghi
khác nhau trong một tệp hoặc cơ sở dữ liệu, các kích thước bản ghi hoặc trường khác
nhau trong một bản ghi. Dữ liệu kiểm thử phải được thiết kế để đại diện cho các loại
dữ liệu quan trọng nhất, tức là các điều kiện dữ liệu quan trọng nhất.

Các điều kiện kiểm thử được ghi lại trong tài liệu IEEE 829 có tên là Thông số kỹ
thuật thiết kế kiểm thử, được hiển thị bên dưới. (Tài liệu này có thể được gọi là Đặc tả
điều kiện kiểm thử, vì nội dung được đề cập trong tiêu chuẩn thực sự là điều kiện
kiểm thử.)
Thiết kế kiểm thử: xác định các trường hợp kiểm thử
Các điều kiện kiểm thử có thể khá mơ hồ, bao gồm khá nhiều khả năng như đã thấy
với ví dụ về công ty điện thoại di động (ví dụ: một thiếu niên ở miền Trung Tây) hoặc
một điều kiện kiểm thử có thể cụ thể hơn (ví dụ: một khách hàng nam trả theo từng
lần với số tiền ít hơn 10$ tín dụng). Tuy nhiên, khi thực hiện một trường hợp kiểm
thử, phải được yêu cầu rất cụ thể; trên thực tế, cần thông tin đầu vào cụ thể chính xác
và chi tiết, chứ không phải mô tả chung chung (ví dụ: Jim Green, 17 tuổi, sống ở
Grand Rapids, Michigan, với khoản tín dụng là 8,64 đô la, kết quả mong đợi: thêm
vào chiến dịch tiếp thị Q4). Lưu ý rằng một trường hợp kiểm thử bao gồm một số điều
kiện (thanh thiếu niên, nam giới, khu vực trung tây, thanh toán theo mức sử dụng và
tín dụng dưới 10 đô la).

Đối với điều kiện kiểm thử là "một khách hàng đã tồn tại", đầu vào của trường hợp
kiểm thử cần phải là "Jim Green" trong đó Jim Green đã tồn tại trên cơ sở dữ liệu
khách hàng hoặc một phần của kiểm thử này là thiết lập bản ghi cơ sở dữ liệu cho Jim
Green.

Tất nhiên, một trường hợp kiểm thử cần phải có các giá trị đầu vào, nhưng chỉ có một
vài giá trị để nhập vào hệ thống thì không phải là một bài kiểm thử! Nếu bạn không
biết hệ thống phải làm gì với đầu vào, bạn không thể biết bài kiểm thử của mình đạt
hay không.

Những trường hợp kiểm thử chi tiết này có nên được viết ra không? Chúng có thể
được ghi lại chính thức (được mô tả cụ thể ở dưới). Tuy nhiên, có thể kiểm thử mà
không cần tài liệu ở cấp độ kịch bản kiểm thử. Nếu cung cấp cho người kiểm thử chấp
nhận của người dùng có kinh nghiệm với một nền tảng nghiệp vụ vững chắc danh
sách các điều kiện kiểm thử mức cao, thì họ có thể thực hiện tốt công việc kiểm thử.
Nhưng nếu đưa cùng một danh sách cho một người mới bắt đầu hoàn toàn không biết
gì về hệ thống, thì họ có thể sẽ không thực hiện tốt công việc, vì vậy họ sẽ được
hưởng lợi từ việc có các kịch bản kiểm thử chi tiết hơn.

Kịch bản kiểm thử có thể được ghi lại như được mô tả trong Tiêu chuẩn IEEE 829 cho
Tài liệu Kiểm thử. Lưu ý rằng tất cả các nội dung được mô tả trong tiêu chuẩn không
nhất thiết phải là các tài liệu vật lý riêng biệt. Nhưng danh sách tiêu chuẩn về những
gì cần được theo dõi là một điểm khởi đầu tốt, ngay cả khi các điều kiện kiểm thử và
kịch bản kiểm thử cho một chức năng hoặc tính năng nhất định đều được lưu giữ
trong một tài liệu vật lý.

Một trong những khía cạnh quan trọng nhất của kiểm thử là nó đánh giá hệ thống có
làm những gì nó phải làm hay không. Copeland đã từng nói "Về cốt lõi, kiểm thử là
quá trình so sánh "cái gì là" với "cái gì phải là"". [Copeland, 2003]

Nếu chúng ta chỉ đơn giản đưa vào các thông tin đầu vào và nghĩ rằng "điều này thật
thú vị, tôi đoán hệ thống có thể ổn vì nó không gặp sự cố", vậy thì chúng ta có thực sự
đang kiểm thử không? Bạn đã quan sát thấy rằng hệ thống làm những gì hệ thống làm
- đây không phải là kiểm thử.

Boris Beizer gọi đây là "kiểm thử dành cho trẻ nhỏ" [Beizer, 1990]. Chúng ta có thể
không biết chi tiết câu trả lời đúng ở mỗi lần là gì và đôi khi vẫn có thể nhận được
một số lợi ích từ phương pháp này, nhưng nó không thực sự là kiểm thử.

Để biết hệ thống nên làm gì, chúng ta cần có một nguồn thông tin về hành vi chính
xác của hệ thống - đây được gọi là "tiên tri" (oracle) hoặc kiểm thử tiên (test oracle).

Điều này không liên quan gì đến cơ sở dữ liệu hoặc công ty tạo ra chúng. Nó xuất
phát từ Nhà tiên tri Hy Lạp cổ đại ở Delphi, người được cho là có thể dự đoán tương
lai với độ chính xác không thể nhầm lẫn. Trên thực tế, câu trả lời của nhà tiên tri ấy
mơ hồ đến mức mọi người diễn giải chúng theo bất kỳ cách nào họ muốn - có lẽ hơi
giống với đặc tả yêu cầu!

Khi một giá trị đầu vào nhất định đã được chọn, người kiểm thử cần xác định kết quả
mong đợi của việc nhập đầu vào đó sẽ là gì và ghi lại nó như một phần của trường hợp
kiểm thử.

Kết quả mong đợi bao gồm thông tin được hiển thị trên màn hình để phản hồi đầu
vào, nhưng cũng bao gồm các thay đổi trong dữ liệu và/hoặc trạng thái cũng như bất
kỳ hậu quả nào khác của kiểm thử (ví dụ: một bức thư sẽ được in suốt đêm).
Điều gì sẽ xảy ra nếu không xác định kết quả mong đợi trước khi chạy bài kiểm thử?

Chúng ta vẫn có thể xem những gì hệ thống tạo ra và có thể sẽ nhận thấy nếu có gì đó
không ổn. Tuy nhiên, chúng ta có thể sẽ không nhận thấy những khác biệt nhỏ trong
tính toán hoặc kết quả có vẻ ổn (nghĩa là hợp lý). Vì vậy, sẽ kết luận rằng bài kiểm
thử đã vượt qua, trong khi thực tế phần mềm không đưa ra kết quả chính xác. Những
khác biệt nhỏ trong một phép tính có thể cộng lại thành một điều gì đó rất lớn sau này,
chẳng hạn nếu kết quả được nhân với một hệ số lớn.

Kết quả mong đợi lý tưởng nên được dự đoán trước khi chạy kiểm thử - khi đó đánh
giá về việc phần mềm có làm đúng hay không sẽ khách quan hơn.

Đối với một số ứng dụng, có thể không dự đoán hoặc biết chính xác kết quả mong đợi
sẽ là gì; chỉ có thể thực hiện "kiểm tra tính hợp lý". Trong trường hợp này, chúng ta
có "tiên tri một phần" (partial oracle)- biết khi nào có điều gì đó rất không ổn, nhưng
có lẽ sẽ phải chấp nhận điều gì đó có vẻ hợp lý. Một ví dụ là khi một hệ thống đã
được viết để tính toán một thứ gì đó mà nó không thể tạo ra các kết quả mong đợi theo
cách thủ công trong một khoảng thời gian hợp lý vì các phép tính quá phức tạp.

Ngoài kết quả mong đợi, kịch bản kiểm thử cũng chỉ định môi trường và những thứ
khác phải có trước khi kiểm thử có thể chạy (điều kiện tiên quyết) và bất kỳ điều gì
nên áp dụng sau khi kiểm thử hoàn thành (điều kiện sau).

Kịch bản kiểm thử cũng nên cho biết lý do tại sao nó tồn tại - tức là mục tiêu kiểm thử
mà nó là một phần của hoặc các điều kiện kiểm thử mà nó đang thực hiện (truy xuất
nguồn gốc). Kịch bản kiểm thử giờ đây có thể được ưu tiên sao cho các trường hợp
kiểm thử quan trọng nhất được thực hiện trước và các trường hợp kiểm thử có mức độ
ưu tiên thấp được thực hiện sau hoặc thậm chí không được thực hiện. Điều này có thể
phản ánh các ưu tiên đã được thiết lập cho các điều kiện kiểm thử hoặc mức độ ưu
tiên có thể được xác định bởi các yếu tố khác liên quan đến các trường hợp kiểm thử
cụ thể, chẳng hạn như một giá trị đầu vào cụ thể đã gây rắc rối trong quá khứ, rủi ro
liên quan
với bài kiểm thử hoặc trình tự hợp lý nhất để chạy các bài kiểm thử. Chương 5 cung
cấp thêm chi tiết về kiểm thử dựa trên rủi ro.

Các trường hợp kiểm thử cần phải được chi tiết để có thể kiểm tra chính xác kết quả
và biết rằng chúng ta có phản hồi chính xác từ hệ thống. Nếu các bài kiểm thử được tự
động hóa, công cụ kiểm thử cần biết chính xác những gì để so sánh đầu ra của hệ
thống.

Triển khai kiểm thử: xác định thủ tục (tập lệnh) kiểm thử
Bước tiếp theo là nhóm các trường hợp kiểm thử theo cách hợp lý để thực hiện chúng
và để xác định các bước tuần tự cần được thực hiện để chạy bài kiểm thử. Ví dụ: một
tập hợp các bài kiểm thử đơn giản bao trùm toàn bộ hệ thống có thể tạo thành một bộ
hồi quy hoặc tất cả các bài kiểm thử khám phá sâu về hoạt động của một chức năng
hoặc tính năng nhất định có thể được nhóm lại để chạy cùng nhau.

Một số kịch bản kiểm thử có thể cần được chạy theo một trình tự cụ thể. Ví dụ: một
bài kiểm thử có thể là tạo một bản ghi khách hàng mới, sửa đổi bản ghi mới tạo đó rồi
xóa nó. Các bài kiểm thử này cần được chạy theo đúng thứ tự, nếu không, chúng sẽ
không kiểm thử được những gì chúng dự định kiểm thử.

Tài liệu mô tả các bước cần thực hiện khi chạy một bộ kiểm thử (và chỉ định thứ tự
thực thi của các bài kiểm thử) được gọi là thủ tục kiểm thử (test procedure) trong
IEEE 829 và thường được gọi là tập lệnh kiểm thử (test script). Nó có thể được gọi là
kịch bản kiểm thử thủ công dành cho các kiểm thử dự định chạy thủ công thay vì sử
dụng công cụ thực hiện kiểm thử. Tập lệnh kiểm thử cũng được sử dụng để mô tả các
hướng dẫn cho công cụ thực hiện kiểm thử. Tập lệnh tự động hóa được viết bằng ngôn
ngữ lập trình mà công cụ có thể diễn giải. (Đây là quy trình kiểm thử tự động.) Xem
Chương 6 để biết thêm thông tin về điều này và các loại công cụ kiểm thử khác.

Sau đó, các thủ tục kiểm thử hoặc tập lệnh kiểm thử được tạo thành một lịch trình
thực hiện kiểm thử chỉ định quy trình nào sẽ được chạy trước. Lịch kiểm thử sẽ cho
biết khi nào một tập lệnh nhất định sẽ được chạy và chạy bởi ai. Ví dụ, lịch trình có
thể thay đổi tùy thuộc vào các rủi ro mới được nhận biết ảnh hưởng đến mức độ ưu
tiên của tập lệnh giải quyết rủi ro đó. Sự phụ thuộc logic và kỹ thuật giữa các tập lệnh
cũng sẽ được tính đến khi lên lịch cho các tập lệnh. Ví dụ: tập lệnh hồi quy có thể
luôn là tập lệnh đầu tiên được chạy khi có bản phát hành mới của phần mềm, dưới
dạng smock test hoặc kiểm tra sự tỉnh táo (sanity check).
Trở lại với ví dụ về chiến dịch tiếp thị của công ty điện thoại di động, chúng ta có thể
có một sốbài kiểm thử để thiết lập các loại khách hàng khác nhau trên cơ sở dữ liệu.
Trước tiên, có thể hợp lý khi chạy tất cả thiết lập cho một nhóm kiểm thử. Vì vậy, quy
trình kiểm thử đầu tiên sẽ yêu cầu thiết lập một số khách hàng, bao gồm cả Jim Green,
trên cơ sở dữ liệu.

Quy trình kiểm tra DB15: Thiết lập khách hàng cho chiến dịch tiếp thị Y. Bước 1:
Mở cơ sở dữ liệu với đặc quyền ghi Bước 2: Thiết lập khách hàng Bob Flounders,
nam, 62 tuổi, Hudsonville, hợp đồng Bước 3: Thiết lập khách hàng Jim Green nam,
17 tuổi, Grand Rapids, thanh toán theo mức sử dụng, $8,64 Bước 4: ...
Sau đó, có thể có một quy trình kiểm thử khác để thực hiện với chiến dịch tiếp thị:
Thủ tục kiểm thử MC03: Ưu đãi đặc biệt cho thanh thiếu niên tín dụng thấp Bước 1:
Nhận thông tin chi tiết về Jim Green từ cơ sở dữ liệu Bước 2: Gửi tin nhắn văn bản
cung cấp tín dụng gấp đôi Bước 3: Jim Green yêu cầu tín dụng $20, tín dụng $40

Viết thủ tục kiểm thử là một cơ hội khác để ưu tiên các bài kiểm thử, nhằm đảm bảo
rằng việc kiểm thử tốt nhất được thực hiện trong thời gian có sẵn. Một nguyên tắc nhỏ
là "Tìm thứ đáng sợ trước". Tuy nhiên, định nghĩa thế nào là "đáng sợ" tùy thuộc vào
doanh nghiệp, hệ thống hoặc dự án. Ví dụ, việc tăng hạn mức tín dụng của Bob
Founders khi anh ta có rủi ro tín dụng không cao (anh ta có thể không trả khoản tín
dụng mà anh ta yêu cầu) hoặc từ chối tăng hạn mức tín dụng khi anh ta có rủi ro tín
dụng tốt (anh ta có thể sử dụng dịch vụ của nơi khác và chúng ta mất cơ hội kiếm
được nhiều thu nhập từ anh ấy).