Nội dung sẽ xuất hiện trong đề thi

Các hoạt động kiểm thử cơ bản từ khi lập kế hoạch đến các hoạt động đóng kiểm thử
và các nhiệm vụ chính của mỗi hoạt động kiểm thử. (K1)

GIỚI THIỆU
Trong phần này, chúng ta sẽ mô tả quá trình và các hoạt động kiểm thử cơ bản. Bắt
đầu với việc lập kế hoạch thử nghiệm và tiếp tục đến cho đến quá trình đóng hoạt
động kiểm thử.

Đối với mỗi phần của quy trình kiểm thử, chúng ta sẽ thảo luận về các nhiệm vụ chính
của từng hoạt động.

Các thuật ngữ xuất hiện trong phần này: confirmation testing (kiểm thử xác
nhận), exit criteria (tiêu chí dừng), incident (sự cố), regression testing (kiểm thử
hồi quy), test basis (cơ sở kiểm thử ), test condition (điều kiện kiểm thử), test
coverage (kiểm thử bao phủ), test data (dữ liệu kiểm thử), test execution (thực thi
kiểm thử), test log (nhật ký kiểm thử), test plan (kế hoạch kiểm thử), test
strategy (chiến lược kiểm thử), test summary report (báo cáo tóm tắt kiểm thử)
and testware (phần mềm kiểm thử).

Kế hoạch kiểm thử

Như đã thấy, mặc dù việc thực hiện các bài kiểm thử là quan trọng, chúng ta cũng cần
có một kế hoạch hành động và một báo cáo về kết quả của việc kiểm thử.

Các kế hoạch dự án và kiểm thử phải bao gồm thời gian dành cho việc lập kế hoạch
kiểm thử, thiết kế các trường hợp kiểm thử, chuẩn bị cho việc thực hiện và đánh giá
trạng thái.

Ý tưởng về một quy trình kiểm thử cơ bản cho tất cả các cấp độ kiểm thử đã được
phát triển trong nhiều năm. Dù ở cấp độ kiểm thử nào, ta cũng thấy rằng, cùng một
loại hoạt động xảy ra, có thể có một lượng hình thức khác nhau ở các cấp độ khác
nhau, ví dụ:

Kiểm thử thành phần (component tests) có thể được thực hiện ít chính thức hơn kiểm
thử hệ thống trong hầu hết các tổ chức có quy trình kiểm thử.

Quyết định về mức độ chính thức của các quy trình sẽ phụ thuộc vào bối cảnh hệ
thống, phần mềm và mức độ rủi ro liên quan đến phần mềm.
Vì vậy, có thể chia các hoạt động trong quy trình thử nghiệm cơ bản thành các bước
cơ bản sau:

 Lập kế hoạch và kiểm soát;

 Phân tích và thiết kế;
 Triển khai và thực hiện;
 Đánh giá các tiêu chí dừng và báo cáo;
 Kiểm tra các hoạt động sau kiểm thử.

Các hoạt động này diễn ra một cách tuần tự, nhưng trong một dự án cụ thể, có thể
chồng chéo lên nhau, diễn ra đồng thời và thậm chí lặp đi lặp lại.

Quy trình này đặc biệt được sử dụng cho kiểm thử động (dynamic testing), nhưng các
tiêu đề chính của quy trình cũng có thể được áp dụng cho các đánh giá.

Ví dụ, cần lập kế hoạch và chuẩn bị cho các cuộc đánh giá, thực hiện các bài đánh giá
và đánh giá kết quả của các cuộc đánh giá. Đối với một số đánh giá, sẽ có các tiêu chí
dừng và sẽ thực hiện các hoạt động sau kiểm thử. Tuy nhiên, chi tiết và cách đặt tên
của các hoạt động sẽ khác đối với kiểm thử tĩnh.

LẬP KẾ HOẠCH VÀ KIỂM SOÁT KIỂM THỬ

Trong quá trình lập kế hoạch kiểm thử, cần đảm bảo việc hiểu các mục tiêu ngắn hạn
và mục tiêu dài hạn của khách hàng, các bên liên quan và dự án cũng như những rủi
ro mà kiểm thử cần giải quyết.

Đây đôi khi được gọi là nhiệm vụ kiểm thử. Dựa vào điều này, ta đặt ra các mục tiêu
dài hạn và mục tiêu ngắn hạn cho chính việc kiểm thử, đồng thời đưa ra cách tiếp cận
và lập kế hoạch kiểm thử, bao gồm đặc điểm kỹ thuật của các hoạt động kiểm thử.
Chính sách kiểm thử

Có thể có các chính sách kiểm thử của tổ chức hoặc chương trình kiểm thử và chiến
lược kiểm thử.

Chính sách kiểm thử đưa ra các quy tắc để kiểm thử, ví dụ: "luôn xem xét các tài liệu
thiết kế";

Chiến lược kiểm thử là cách tiếp cận mức cao tổng thể, ví dụ: "kiểm thử hệ thống
được thực hiện bởi một nhóm độc lập, báo cáo cho người quản lý chất lượng. Nó sẽ
dựa trên rủi ro và thu được từ phân tích rủi ro của sản phẩm (chất lượng) "(xem
Chương 5).

Nếu chính sách và chiến lược đã được xác định thì chúng sẽ thúc đẩy việc lập kế
hoạch nhưng nếu không, ta nên yêu cầu chúng được nêu ra và xác định.

Lập kế hoạch kiểm thử có các nhiệm vụ chính sau đây để giúp xây dựng kế hoạch
kiểm thử:
Xác định phạm vi, rủi ro và xác định các mục tiêu của kiểm thử

Xem xét phần mềm, thành phần, hệ thống hoặc sản phẩm nào khác nằm trong phạm vi
kiểm thử; các rủi ro kinh doanh, sản phẩm, dự án và kỹ thuật cần được giải quyết; và
liệu chúng ta có đang kiểm thử chủ yếu là để phát hiện ra lỗi hay không, để chứng tỏ
rằng phần mềm đáp ứng các yêu cầu, để chứng minh rằng hệ thống phù hợp với mục
đích hoặc để đo lường chất lượng và thuộc tính của phần mềm.
Xác định cách tiếp cận kiểm thử

Bao gồm kỹ thuật, hạng mục kiểm thử, độ bao phủ, xác định và giao tiếp với các
nhóm liên quan đến kiểm thử, phần mềm kiểm thử.

Xem xét cách thực hiện kiểm thử, các kỹ thuật sử dụng, những gì cần kiểm thử và
mức độ rộng rãi (ví dụ mức độ bao phủ là gì).

Xem xét ai cần tham gia và khi nào (có thể bao gồm các nhà phát triển, người dùng,
nhóm cơ sở hạ tầng CNTT); quyết định cung cấp những gì như một phần của kiểm
thử (ví dụ: phần mềm kiểm thử (testware) như thủ tục kiểm thử và dữ liệu kiểm thử).
Điều này sẽ liên quan đến các yêu cầu của chiến lược kiểm thử.
Thực thi chính sách kiểm thử và/hoặc chiến lược kiểm thử
Có thể có một tổ chức hoặc chính sách chương trình và chiến lược để kiểm thử. Nếu
trường hợp này xảy ra, trong quá trình lập kế hoạch, phải đảm bảo rằng những gì dự
định thực hiện phải tuân thủ chính sách và chiến lược hoặc phải đã đồng ý với các bên
liên quan và được tài liệu hóa lại.
Xác định các tài nguyên kiểm thử cần thiết

Ví dụ: con người, môi trường thử nghiệm, PC

Từ việc lập kế hoạch đã thực hiện, bây giờ chúng ta có thể đi vào chi tiết; thiết lập tất
cả phần cứng và phần mềm hỗ trợ mà yêu cầu cho môi trường kiểm thử.
Lên lịch cho các nhiệm vụ phân tích và thiết kế kiểm thử, triển khai, thực hiện và đánh giá thử nghiệm

Chúng ta sẽ cần lên lịch trình cho tất cả các nhiệm vụ và hoạt động để có thể theo dõi
chúng và đảm bảo rằng chúng thể được hoàn thành việc kiểm thử đúng thời hạn.
Xác định tiêu chí dừng

Cần thiết lập các tiêu chí như tiêu chí về phạm vi (ví dụ: tỷ lệ phần trăm các câu lệnh
trong phần mềm phải được thực thi trong quá trình kiểm thử) sẽ giúp theo dõi xem ta
có đang hoàn thành các hoạt động kiểm thử một cách chính xác hay không. Chúng sẽ
chỉ cho ta những việc cần phải hoàn thành đối với một cấp độ kiểm thử cụ thể trước
khi có thể nói rằng kiểm thử đã kết thúc.

Kiểm soát hoạt động kiểm thử

Quản lý bất kỳ hoạt động nào không chỉ dừng lại ở việc lập kế hoạch. Chúng ta cần
kiểm soát và đo lường tiến độ so với kế hoạch. Vì vậy, kiểm soát kiểm thử là một hoạt
động liên tục.

Cần so sánh tiến độ thực tế so với tiến độ dự kiến, và báo cáo cho người quản lý dự án
và khách hàng về tình trạng kiểm thử hiện tại, bao gồm bất kỳ thay đổi hoặc sai lệch
nào so với kế hoạch.

Chúng ta sẽ cần thực hiện các hành động nếu cần thiết để đáp ứng các mục tiêu của dự
án. Những hành động như vậy có thể dẫn đến việc thay đổi kế hoạch ban đầu, điều
này thường xuyên xảy ra.

Khi các nhóm khác nhau thực hiện các hoạt động xem xét và kiểm thử khác nhau
trong dự án, việc lập kế hoạch và kiểm soát cần phải thực hiện trong từng nhóm đó
nhưng vẫn cần sự phối hợp giữa các nhóm, cho phép thực hiện suôn sẻ giữa mỗi giai
đoạn kiểm thử.
Lập kế hoạch kiểm thử có tính đến phản hồi từ việc giám sát và kiểm soát các hoạt
động diễn ra thông qua dự án. Kiểm soát kiểm thử có các nhiệm vụ chính sau:
Đo lường và phân tích kết quả của việc đánh giá và kiểm thử

Cần biết đã thực hiện bao nhiêu bài đánh giá và kiểm thử. Cần theo dõi xem có bao
nhiêu bài kiểm thử đạt và bao nhiêu bài không đạt, cùng với số lượng, loại và tầm
quan trọng của các lỗi được báo cáo.
Theo dõi và lập tài liệu tiến độ, độ bao phủ kiểm thử và tiêu chí dừng

Điều quan trọng là phải thông báo cho nhóm dự án về mức độ kiểm thử đã được thực
hiện, kết quả ra sao, đã đưa ra kết luận và đánh giá rủi ro nào. Phải làm cho kết quả
kiểm thử có thể nhìn thấy được và hữu ích cho cả nhóm.
Cung cấp thông tin về kiểm thử

Nên thực hiện các báo cáo thường xuyên và đột xuất cho người quản lý dự án, nhà tài
trợ, khách hàng và các bên liên quan chính khác để giúp họ đưa ra quyết định sáng
suốt về tình trạng dự án. Cũng nên sử dụng thông tin mà chúng ta có để tự phân tích
việc kiểm thử.
Bắt đầu các hành động sửa chữa

Ví dụ, thắt chặt các tiêu chí dừng cho các lỗi đã được sửa, yêu cầu nỗ lực nhiều hơn
để gỡ lỗi hoặc ưu tiên các lỗi cần sửa.
Ra quyết định

Dựa trên việc đo lường và thu thập thông tin trong quá trình kiểm thử và bất kỳ thay
đổi nào tới rủi ro kinh doanh và rủi ro dự án hoặc sự gia tăng rủi ro sản phẩm và kỹ
thuật, chúng ta sẽ đưa ra quyết định hoặc cho phép những người khác đưa ra quyết
định là tiếp tục thử nghiệm, dừng thử nghiệm, phát hành phần mềm hoặc giữ lại nó để
làm việc sau này.

Nội dung tiếp theo sẽ giới thiệu về phân tích và thiết kế kiểm thử.

PHÂN TÍCH VÀ THIẾT KẾ KIỂM THỬ

Phân tích và thiết kế kiểm thử là hoạt động mà các mục tiêu kiểm thử chung được
chuyển thành các điều kiện kiểm thử và thiết kế kiểm thử hữu hình. Trong quá trình
phân tích và thiết kế kiểm thử, chúng ta thực hiện các mục tiêu kiểm thử chung được
xác định trong quá trình lập kế hoạch và xây dựng các thiết kế và quy trình kiểm thử
(kịch bản).

Phân tích và thiết kế kiểm thử có các nhiệm vụ chính sau đây:

Xem xét cơ sở kiểm thử

Chẳng hạn như phân tích rủi ro sản phẩm, yêu cầu, kiến trúc, đặc điểm kỹ thuật thiết
kế và giao diện, kiểm tra các thông số kỹ thuật cho phần mềm đang kiểm thử.

Sử dụng cơ sở kiểm thử để giúp xây dựng việc kiểm thử. Có thể bắt đầu thiết kế một
số loại kiểm thử nhất định (được gọi là kiểm thử hộp đen) trước khi lập trình, vì có thể
sử dụng các tài liệu đã có để hiểu yêu cầu của hệ thống.

Khi nghiên cứu cơ sở kiểm thử, ta thường xác định các lỗ hổng và sự không rõ ràng
trong các thông số kỹ thuật, điều này cũng ngăn ngừa các lỗi xuất hiện trong lập trình.

Xác định các điều kiện kiểm thử

Dựa trên phân tích các mục kiểm thử, thông số kỹ thuật và những gì chúng ta biết về
hành vi và cấu trúc của chúng. Điều này cung cấp một danh sách chi tiết về những gì
muốn kiểm thử.

Quay lại ví dụ về sát hạch lái xe, người kiểm tra có thể có một danh sách các điều kiện
kiểm tra bao gồm "hành vi tại nơi đường giao nhau", "sử dụng các chỉ số", "khả năng
điều khiển xe",....

Trong kiểm thử, ta sử dụng các kỹ thuật kiểm thử để giúp xác định các điều kiện kiểm
thử. Từ đó, có thể bắt đầu xác định loại dữ liệu kiểm thử chung mà ta có thể cần.
Thiết kế các bài kiểm thử

Chương 4 sẽ mô tả chi tiết về điều này. Sử dụng các kỹ thuật để giúp chọn các bài
kiểm thử đại diện liên quan đến các khía cạnh cụ thể của phần mềm mang rủi ro hoặc
được quan tâm cụ thể, dựa trên các điều kiện kiểm thử.

Ví dụ: giám định lái xe có thể xem xét danh sách các điều kiện kiểm thử và quyết định
rằng các nút giao thông cần bao gồm nút giao chữ T, đường cắt ngang, ....

Trong kiểm thử, chúng ta sẽ xác định trường hợp kiểm thử và các thủ tục kiểm thử.

Đánh giá khả năng kiểm thử của các yêu cầu và hệ thống.

Các yêu cầu có thể được viết theo cách cho phép tester thiết kế các thử nghiệm.

Vi dụ, nếu hiệu suất phần mềm là quan trọng, điều đó phải được chỉ định theo cách có
thể kiểm tra được.

Nếu các yêu cầu chỉ nói rằng "phần mềm cần đáp ứng đủ nhanh" thì không thể kiểm
tra được, bởi vì "đủ nhanh" có thể có ý nghĩa khác nhau đối với những người khác
nhau. Một yêu cầu dễ kiểm tra hơn sẽ là "mềm kho cần phản hồi trong 5 giây với 20
người đăng nhập".

Khả năng kiểm thử của hệ thống phụ thuộc vào các khía cạnh như liệu có thể thiết lập
hệ thống trong một môi trường phù hợp với môi trường hoạt động hay không và liệu
tất cả các hệ thống có thể được cấu hình hoặc sử dụng có thể được hiểu và kiểm tra
hay không.

Ví dụ: nếu kiểm thử một trang web, có thể định nghĩa và tạo lại được tất cả các cấu
hình của phần cứng, hệ điều hành, trình duyệt, kết nối, tường lửa và các yếu tố khác
mà trang web có thể bắt gặp.

Thiết kế cài đặt môi trường kiểm thử và xác định bất kỳ cơ sở hạ tầng và công cụ cần thiết nào.

Điều này bao gồm các công cụ kiểm tra (xem Chương 6) và các công cụ hỗ trợ như
bảng tính, bộ xử lý văn bản, công cụ lập kế hoạch dự án cũng như các công cụ và thiết
bị phi CNTT - mọi thứ chúng ta cần để thực hiện công việc của mình.

TRIỂN KHAI VÀ THỰC HIỆN KIỂM THỬ

Trong quá trình triển khai và thực thi kiểm thử, ta thực hiện các điều kiện kiểm thử,
biến chúng thành trường hợp kiểm thử, phần mềm kiểm thử và thiết lập môi trường
kiểm thử.

Điều này có nghĩa là, sau khi đã đưa ra một thiết kế mức cao, phải bắt đầu xây dựng
các bài kiểm thử.

Các điều kiện kiểm thử được chuyển đổi thành các trường hợp và thủ tục kiểm thử,
các phần mềm kiểm thử (testware) khác như tập lệnh để tự động hóa.

Cũng cần thiết lập một môi trường nơi sẽ chạy các bài kiểm thử và xây dựng dữ liệu
kiểm thử.

Thiết lập môi trường và dữ liệu thường đòi hỏi thời gian và nỗ lực đáng kể, vì vậy nên
lập kế hoạch và giám sát công việc này một cách cẩn thận.

Việc triển khai và thực thi kiểm thử có các nhiệm vụ chính sau đây:

Thiết lập

Phát triển và ưu tiên các trường hợp kiểm thử, sử dụng các kỹ thuật trong Chương 4
và tạo dữ liệu kiểm thử cho các thử nghiệm đó. Hướng dẫn thực hiện các bài kiểm thử
(quy trình kiểm thử) cũng cần được tài liệu hóa lại.

Đối với người thi sát hạch, điều này có thể có nghĩa là thay đổi điều kiện kiểm tra "các
nút giao thông" thành "đi theo tuyến đường xuống Đường Mayfield đến đường giao
nhau với Summer Road, yêu cầu người lái xe rẽ trái vào Summer Road và sau đó đi
thẳng vào Green Road", yêu cầu đặt ra là người lái xe sẽ phải kiểm tra gương, tín
hiệu và thao tác một cách chính xác, trong khi vẫn nhận biết được những người đi
đường khác.

Có thể cần tự động hóa một số bài kiểm thử bằng cách sử dụng kỹ thuật kiểm thử
thăm dò và kiểm thử tự động. Kiểm thử tự động sẽ được nói chi tiết ở Chương 6.
Tạo bộ kiểm thử từ các trường hợp kiểm thử để thực thi hiệu quả.

Bộ kiểm thử là một tập hợp các trường hợp kiểm thử hoạt động cùng nhau một cách
tự nhiên.

Bộ kiểm thử thường chia sẻ dữ liệu và một mục tiêu mức cao chung. Chúng ta cũng sẽ
thiết lập một lịch trình thực hiện kiểm thử.
Thực hiện và xác minh môi trường.
Đảm bảo môi trường kiểm thử đã được thiết lập chính xác, thậm chí có thể chạy các
thử nghiệm cụ thể trên đó.

Thực thi
Thực thi các bộ kiểm thử và các trường hợp thử nghiệm riêng lẻ

Có thể thực hiện việc này theo cách thủ công hoặc bằng cách sử dụng các công cụ
thực thi kiểm thử, theo trình tự đã lên kế hoạch.
Lưu lại nhật ký kết quả

Phải lưu lại nhật ký kết quả của việc thực hiện kiểm thử cũng như phiên bản của phần
mềm được kiểm thử, các công cụ kiểm thử và phần mềm kiểm thử.

Phải biết chính xác những bài kiểm thử đã sử dụng đối với phiên bản phần mềm nào;
phải báo cáo về các lỗi đối với từng phiên bản cụ thể; và nhật ký kiểm tra lưu giữ
cung cấp một dấu vết đã kiểm tra.
So sánh kết quả thực tế với kết quả mong đợi

Khi có sự khác biệt giữa kết quả thực tế và kết quả mong đợi, phải báo cáo sự khác
biệt như sự cố.

Phân tích chúng để thu thập thêm chi tiết về lỗi, báo cáo thông tin bổ sung về vấn đề.

Xác định nguyên nhân của lỗi và phân biệt giữa các vấn đề trong phần mềm với các
sản phẩm khác đang được thử nghiệm và bất kỳ lỗi trong dữ liệu dùng để thực hiện
bài kiểm thử, trong tài liệu hoặc sai lầm trong cách chúng ta thực hiện bài kiểm thử.

Cần phải tài liệu hóa lại để cải thiện chính quá trình kiểm thử sau này.
Lặp lại các hoạt động kiểm thử

Như là kết quả của hành động được thực hiện cho mỗi sự khác biệt. Cần kiểm thử lại
các bài không thành công trước đó để xác nhận bản sửa lỗi (xác nhận hoặc kiểm tra
lại).

Thực hiện kiểm thử lại các phần đã được sửa lỗi. Kiểm tra lại phần mềm đã sửa để
đảm bảo rằng lỗi thực sự đã được sửa chính xác (confirmation test) và các lập trình
viên không đưa ra thêm lỗi vào trong các vùng không thay đổi của phần mềm và việc
sửa một lỗi không phát hiện ra lỗi khác (regression test).

Ở phần tiếp theo, các bạn sẽ được tìm hiểu kiến thức về Đánh giá và báo cáo, các hoạt
động kết thúc kiểm thử
ĐÁNH GIÁ CÁC TIÊU CHÍ DỪNG VÀ BÁO CÁO
Đánh giá tiêu chí dừng là hoạt động mà việc thực hiện kiểm thử được đánh giá dựa
trên các mục tiêu đã xác định.

Điều này nên được thực hiện cho từng cấp độ kiểm thử, vì đối với mỗi cấp độ, cần
biết liệu đã thực hiện đủ việc kiểm thử hay chưa.

Dựa trên đánh giá rủi ro sẽ đưa ra các tiêu chí mà chúng ta đo lường là "đủ". Các tiêu
chí này khác nhau đối với từng dự án và được gọi là tiêu chí dừng (exit criteria).

Chúng cho biết liệu có thể khai báo một hoạt động hoặc cấp độ kiểm thử nhất định đã
hoàn thành hay chưa. Có thể kết hợp độ bao phủ hoặc tiêu chí hoàn thành, tiêu chí
chấp nhận và tiêu chí dừng
Tiêu chí hoàn thành

Cho biết các trường hợp kiểm thử phải được bao gồm.

Ví dụ: "kiểm tra sát hạch lái xe phải bao gồm bài thi dừng khẩn cấp" hoặc "kiểm tra
phần mềm phải bao gồm đo lường phản ứng").
Tiêu chí chấp nhận
Cho biết rằng liệu phần mềm đã đạt hay thất bại về tổng thể

Ví dụ: "người thi lái xe chỉ đạt nếu họ đã hoàn thành việc dừng khẩn cấp một cách
chính xác" hoặc "chỉ chuyển phần mềm để phát hành nếu nó đáp ứng danh sách yêu
cầu ưu tiên"
Tiêu chí dừng

Cho biết liệu đã hoàn thành tất cả các nhiệm vụ cần làm hay chưa

Ví dụ: tester vẫn chưa được tính là hoàn thành cho đến khi họ viết và nộp báo cáo kết
thúc kiểm thử .

Các tiêu chí dừng phải được thiết lập và đánh giá cho mỗi cấp độ kiểm thử.

Đánh giá các tiêu chí dừng có các nhiệm vụ chính sau
Kiểm tra nhật ký kiểm thử

Dựa trên các tiêu chí dừng được chỉ định trong lập kế hoạch kiểm thử.

Xem xét xem có bằng chứng nào cho những kiểm tra nào đã được thực hiện và kiểm
thử, và những lỗi nào đã được tìm thấy, được sửa chữa, lỗi nào được xác nhận hoặc
lỗi nào nổi bật.
Đánh giá xem có cần nhiều bài kiểm thử hơn hay không

Hoặc đánh giá xem liệu tiêu chí dừng đã chỉ định có nên được thay đổi hay không

Có thể cần chạy nhiều bài kiểm thử hơn nếu chưa chạy tất cả các bài kiểm thử đã thiết
kế hoặc nếu nhận ra rằng chưa đạt được phạm vi mong đợi, hoặc nếu rủi ro đã tăng
lên cho dự án.

Có thể cần thay đổi các tiêu chí dừng, nếu rủi ro kinh doanh và dự án tăng quan trọng
hơn là rủi ro sản phẩm hoặc kỹ thuật giảm. Lưu ý rằng việc này không dễ thực hiện và
phải được sự đồng ý của các bên liên quan.
Viết báo cáo tóm tắt kiểm thử cho các bên liên quan

Việc tester biết kết quả kiểm thử là chưa đủ. Tất cả các bên liên quan cần biết bài
kiểm thử nào đã được thực hiện và kết quả của bài kiểm thử đó, để đưa ra quyết định
sáng suốt về phần mềm.

HOẠT ĐỘNG KẾT THÚC KIỂM THỬ

Trong hoạt động kết thúc kiểm thử, thực hiện thu thập dữ liệu từ các hoạt động kiểm
thử đã hoàn thành để củng cố kinh nghiệm, bao gồm cả việc kiểm tra phần mềm kiểm
thử cũng như phân tích các dữ kiện và con số.

Có thể cần làm hoạt động này khi phần mềm được chuyển giao. Cũng có thể kết thúc
kiểm thử vì các lý do khác, chẳng hạn như khi đã thu thập thông tin cần thiết từ, khi
dự án bị hủy bỏ, khi đạt được cột mốc quan trọng hoặc khi bản cập nhật hoặc bản phát
hành bảo trì được thực hiện.

Các hoạt động kết thúc kiểm thử bao gồm các nhiệm vụ chính sau
Kiểm tra sản phẩm bàn giao

Kiểm tra xem đã thực sự bàn giao sản phẩm theo kế hoạch đã lên chưa và đảm bảo
rằng tất cả các báo cáo sự cố đã được giải quyết thông qua việc sửa chữa lỗi hoặc một
số lỗi được hoãn lại.

Đối với những lỗi được hoãn lại, hay nói cách khác là những lỗi ở trạng thái mở, có
thể yêu cầu thay đổi ở một bản phát hành trong tương lai. Ghi lại việc chấp nhận hoặc
từ chối hệ thống phần mềm.
Hoàn thiện và lưu trữ phần mềm thử nghiệm

Chẳng hạn như tập lệnh, môi trường kiểm thử và bất kỳ cơ sở hạ tầng kiểm thử nào
khác, để sử dụng lại sau này.

Điều quan trọng là sử dụng lại bất cứ thứ gì có thể của phần mềm; không thể tránh
khỏi việc thực hiện kiểm thử bảo trì và sẽ tiết kiệm thời gian và công sức nếu phần
mềm kiểm thử có thể được lấy ra từ thư viện các bài kiểm thử hiện có.

Nó cũng cho phép so sánh kết quả kiểm thử giữa các phiên bản phần mềm.
Bàn giao phần mềm kiểm thử (testware) cho tổ chức bảo trì

Tổ chức bảo trì là người sẽ hỗ trợ phần mềm và thực hiện bất kỳ bản sửa lỗi hoặc thay
đổi bảo trì nào, được sử dụng trong kiểm thử xác nhận và kiểm thử hồi quy.

Nhóm này có thể là một nhóm riêng biệt với những người xây dựng và kiểm thử phần
mềm; người kiểm thử bảo trì là một trong những khách hàng của người kiểm thử phát
triển; họ sẽ sử dụng thư viện các bài kiểm thử.
Đánh giá cách kiểm thử diễn ra
Phân tích các bài học kinh nghiệm cho các bản phát hành và dự án trong tương lai.

Điều này có thể bao gồm cải tiến quy trình cho toàn bộ vòng đời phát triển phần mềm
và cải tiến các quy trình kiểm thử.

Có thể sử dụng kết quả kiểm thử để đặt mục tiêu cải thiện việc đánh giá và kiểm thử
với mục tiêu giảm thiểu số lượng lỗi trong quá trình sử dụng trực tiếp.

Có thể xem xét số lượng sự cố là sự cố thử nghiệm, với mục tiêu cải thiện cách thiết
kế, thực thi và kiểm thử các thử nghiệm của mình hoặc việc quản lý môi trường thử
nghiệm và dữ liệu.

Điều này giúp thực hiện kiểm thử hoàn thiện hơn và tiết kiệm chi phí hơn cho tổ chức.
Điều này được ghi lại trong báo cáo tóm tắt kiểm thử hoặc có thể là một phần của báo
cáo đánh giá dự án tổng thể.