CHƯƠNG 1 CÁC YẾU TỐ CƠ BẢN CỦA KIỂM THỬ - TIẾN TRÌNH KIỂM THỬ CĂN BẢN

1. Giới thiệu

Trong phần này sẽ có các hoạt động kiểm thử:

• Kiểm thử xác nhận.
• Tiêu chuẩn hoàn thành.
• Sự cố.
• Kiểm thử hồi quy.
• Cơ sở kiểm thử.
• Điều kiện kiểm thử.
• Tỷ lệ testcase đã thực hiện kiểm thử so với tổng số testcase cần thiết của ứng dụng.
• Chiến lược kiểm thử.
• Test summary report.
• Testware ( các đối tượng sinh ra trong quá trình kiểm thử ).

Mặc dù việc thực hiện các bài kiểm tra là quan trọng, chúng ta cũng cần một kế hoạch thực hiện và báo cáo về kết quả của kiểm thử. Kế hoạch dự án và kế hoạch kiểm thử cần bao gồm thời gian để 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á tình trạng. Ý tưởng về một quá trình kiểm thử cơ bản cho tất cả các mức độ kiểm thử đã được phát triển qua nhiều năm. Ví dụ, Kiểm thử thành phần có thể được thực hiện ít chính thức hơn so với các kiểm thử hệ thống trong hầu hết các tổ chức với ít tài liệu kiểm tra quá trình. 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, chúng ta có thể chia các hoạt động trong quá trình kiểm tra cơ bản các bước sau:

• Lập kế hoạch và kiểm soát.
• Phân tích và thiết kế.
• Thực hiện đầy đủ và thực thi.
• Đánh giá tiêu chí hoàn thành và báo cáo.
• Hành động kết thúc kiểm thử.

Những hoạt động này có tính logic, nhưng trong một dự án cụ thể có thể chồng chéo lên nhau, diễn ra đồng thời thập chí được lặp lại. Quá trình này đặc biệt được sử dụng để kiểm thử động, tuy nhiên các tiêu đề chính của quy trình cũng có thể được áp dụng cho các bài đánh giá. ví dụ, chúng ta có thể lập kế hoạch và chuẩn bị cho việc đánh giá, thực hiện các rà soát, và đánh giá kết quả của các bài rà soát. Đối với một số rà soát, chẳng hạn như kiểm tra, chúng ta sẽ có tiêu chí đánh giá hoàn thành và sẽ đi qua các hoạt động thu nhập dữ liệu từ các hoạt động test đã hoàn thành để tập trung lại các kinh nghiệm, tài liệu test. Tuy nhiên, chi tiết và đặt tên của các hoạt động sẽ khác nhau cho các kiểm thử tĩnh.

2. Kế hoạch kiểm thử và kiểm soát.

Trong quá trình lập kế hoạch kiểm thử, chúng ta đảm bảo hiểu các mục tiêu của khách hàng, các bên liên quan, dự án và các rủi ro kiểm thử nhặp để giải quyết kịp thời. Dựa trên sự hiểu biết này, chúng ta đặc mục tiêu cho bản thân kiểm thử, và có được một cách tiếp cận và kế hoạch cho các bài kiểm thử bao gồm cả các đặc điểm của các hoạt động kiểm thử. Từ đó chúng ta có thể có các chính sách kiểm thử tổ chức hoặc chương trình hay một chiến lược kiểm thử.

Chính sách kiểm thử đưa ra các quy tắc cho kiểm thử, ví dụ: 'chúng ta 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 tổng thể cấp cao, 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 chương trình. Nếu chính sách và chiến lược đã được xác định thì họ đã thúc đẩy kế hoạch của chúng ta nhưng nếu không chúng ta nên yêu cầu họ được nêu và xác định. Kế hoạch kiểm thử có các nhiệm vụ chính sau đây, được đưa ra theo thứ tự, giúp chúng ta xây dựng kế hoạch kiểm thử:

• Xác định phạm vi, rủi ro và xác định mục tiêu kiểm thử: chúng ta xem xét phần mềm, thành phần, hệ thống hoặc các sản phẩm khác nằm trong phạm vi kiểm thử; rủi ro kinh doanh, sản phẩm, dự án và kỹ thuật cần phải có để giải quyết; và chúng ta đang kiểm thử chủ yếu để phát hiện ra các khiếm khuyế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 cho mục đích hoặc để đo lường các 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ử (kỹ thuật, bài kiểm tra, bảo hiểm, xác định và giao tiếp với các đội tham gia kiểm thử, testware): chúng ta xem xét làm thế nào chúng ta sẽ thực hiện các 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 (nghĩa là mức độ bao phủ). Chúng ta sẽ xem xét những ai cần tham gia và khi nào (điều này có thể bao gồm các nhà phát triển, người dùng, cơ sở hạ tầng IT các đội); chúng ta sẽ quyết định những gì chúng ta sẽ sản xuất như là một phần của kiểm thử (ví dụ như phần mềm testware như các thủ tục kiểm tra 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 hiện chính sách kiểm thử và / hoặc chiến lược kiểm tra: chúng ta đã đề cập ở đó có thể là một chính sách tổ chức hoặc chương trình và chiến lược để kiểm thử. Nếu đây là trường hợp, trong quá trình lập kế hoạch của chúng ta, chúng ta phải đảm bảo rằng những gì chúng ta dự định làm 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à tài liệu.
• Xác định các tài nguyên kiểm thử được yêu cầu (ví dụ: người, môi trường kiểm thử, máy tính cá nhân): từ kế hoạch chúng ta đã làm bây giờ chúng ta có thể đi vào chi tiết; chúng ta quyết định về đội hình của chúng ta và chúng ta cũng thiết lập tất cả phần cứng hỗ trợ và phần mềm chúng ta yêu cầu cho môi trường kiểm thử.
• Lập kế hoạch kiểm thử phân tích và nhiệm vụ thiết kế, thực hiện kiểm tra, thực hiện và đánh giá: chúng ta sẽ cần một lịch trình của tất cả các nhiệm vụ và hoạt động, để chúng ta có thể theo dõi chúng và đảm bảo chúng ta có thể hoàn thành việc kiểm tra đúng hạn.
• Xác định tiêu chí kết thúc: chúng ta cần phải đặt các tiêu chí như tiêu chí bảo hiểm (ví dụ, phần trăm các câu lệnh trong phần mềm phải được thực hiện trong quá trình kiểm thử) sẽ giúp chúng ta theo dõi liệu chúng ta có hoàn thành hoạt động kiểm tra hay không. Họ sẽ cho chúng ta biết nhiệm vụ và kiểm tra nào chúng ta phải hoàn thành một mức độ kiểm tra cụ thể trước khi chúng ta có thể nói rằng việc kiểm thử đã kết thúc.

Quản lý bất kỳ hoạt động nào không dừng lại khi lên kế hoạch. Chúng ta cần phải 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 tra là một hoạt động liên tục. Chúng ta cần phải so sánh sự tiến bộ thực tế với sự tiến bộ theo kế hoạch, và báo cáo cho người quản lý dự án và khách hàng về tình trạng hiện tại của kiểm thử, bao gồm bất kỳ thay đổi hoặc sai lệch nào từ kế hoạch. Chúng ta sẽ cần hành động khi 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 thay đổi kế hoạch ban đầu của chúng ta, điều này thường xảy ra. Khi các nhóm khác nhau thực hiện các hoạt động rà soát và kiểm tra khác nhau trong dự án, quy hoạch và kiểm soát không chỉ xảy ra trong mỗi nhóm mà còn trên các nhóm để phối hợp giữa chúng, cho phép xử lý mượt mà giữa mỗi giai đoạn kiểm thử. Kế hoạch kiểm tra có tính đến phản hồi từ giám sát và kiểm soát các hoạt động diễn ra thông qua trong dự án. Kiểm tra kiểm soát thực hiện các nhiệm vụ chính sau:

• Đo lường và phân tích kết quả đánh giá và kiểm thử: Chúng ta cần biết có bao nhiêu bài đánh giá và bài kiểm tra chúng ta đã làm. Chúng ta cần theo dõi xem có bao nhiêu các bài kiểm tra đã được thông qua và bao nhiêu thất bại, cùng với số lượng, loại và tầm quan trọng của các khiếm khuyết được báo cáo.
• Theo dõi và lập hồ sơ tiến độ, phạm vi kiểm tra và tiêu chuẩn hoàn thành kiểm thử: Điều quan trọng là chúng ta thông báo cho nhóm dự án bao nhiêu kiểm tra đã được thực hiện, kết quả và kết luận và đánh giá rủi ro của chúng ta. Chúng ta phải làm cho kết quả kiểm tra được nhìn thấy và hữu ích cho cả nhóm.
• Cung cấp thông tin về kiểm tra: Chúng ta nên kỳ vọng phải thực hiện báo cáo đặc biệt cho người quản lý dự án, nhà tài trợ dự án, khách hàng và các bên liên quan chủ chốt khác để giúp họ đưa ra quyết định sáng suốt về tình trạng của dự án. Chúng ta cũng nên sử dụng thông tin chúng ta phải phân tích kiểm thử chính nó.
• Khởi tạo các hành động khắc phục: Ví dụ, thắt chặt tiêu chuẩn hoàn thành kiểm thử cho các khiếm khuyết cố định, yêu cầu nhiều nỗ lực để được đưa vào gỡ lỗi hoặc ưu tiên các khiếm khuyết để sửa.
• Ra quyết định: Dựa trên các biện pháp và thông tin thu thập được trong suốt kiểm thử và bất kỳ thay đổi nào đối với rủi ro nghiệp vụ và dự án hoặc sự gia tăng của chúng ta theo rủi ro về kỹ thuật và sản phẩm, chúng ta sẽ quyết định hoặc cho phép những người khác để đưa ra quyết định: tiếp tục kiểm thử, ngừng kiểm thử, để phát hành phần mềm hoặc để giữ nó để làm việc thêm.

3. 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 đổi thành các điều kiện kiểm tra hữu hình và thiết kế kiểm tra. Trong quá trình phân tích kiểm thử và thiết kế, chúng ta có 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 thiết kế kiểm thử và thủ tục kiểm tra (kịch bản). Kiểm tra phân tích và thiết kế có những nhiệm vụ chính sau đây:

• Xem xét cơ sở kiểm tra (chẳng hạn như phân tích rủi ro sản phẩm, yêu cầu, kiến trúc, thông số kỹ thuật thiết kế, và giao diện), kiểm tra các chi tiết kỹ thuật cho phần mềm chúng ta đang kiểm thử. Chúng ta sử dụng cơ sở kiểm tra để giúp chúng ta xây dựng kiểm tra. Chúng ta có thể bắt đầu thiết kế các loại kiểm thử nhất định (gọi là kiểm tra hộp đen) trước khi mã tồn tại, vì chúng ta có thể sử dụng các tài liệu cơ sở kiểm tra để hiểu hệ thống nên làm gì khi được xây dựng. Khi chúng ta nghiên cứu cơ sở kiểm tra, chúng ta thường xác định khoảng cách và sự mơ hồ trong các thông số kỹ thuật, bởi vì chúng ta đang cố gắng để xác định chính xác những gì xảy ra ở mỗi điểm trong hệ thống, và điều này cũng ngăn ngừa các khiếm khuyết xuất hiện trong mã.
• Xác định các điều kiện kiểm tra dựa trên phân tích các mục kiểm tra, các thông số kỹ thuật của chúng, 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 cho chúng ta một danh sách cao cấp về những gì chúng ta quan tâm đến việc kiểm thử. Chúng ta ví dụ việc lái xe của chúng ta, 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 ở đường giao thông đường bộ', 'sử dụng các chỉ số', 'khả năng cơ động xe' .Trong kiểm thử, chúng ta sử dụng các kỹ thuật kiểm tra để giúp chúng ta xác định các điều kiện kiểm tra. Từ đó chúng ta có thể bắt đầu xác định loại dữ liệu kiểm thử chung mà chúng ta có thể cần.
• Thiết kế các bài kiểm tra , sử dụng các kỹ thuật để giúp chọn các bài kiểm tra đại diện có liên quan đến các khía cạnh đặc biệt của phần mềm thương mại mà mang rủi ro hoặc có lợi ích đặc biệt, dựa trên điều kiện kiểm tra và đi vào chi tiết hơn. Ví dụ, người giám sát lái xe có thể xem xét mộ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 phải bao gồm các nút giao cắt T, đường chéo. Trong kiểm thử, chúng ta sẽ xác định trường hợp kiểm thử và thủ tục kiểm tra.
• Đánh giá khả năng kiểm tra 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 người kiểm tra thiết kế các bài kiểm tra; ví dụ, nếu mỗi hình thức của phần mềm là rất quan trọng, cần được xác định trong một cách kiểm chứng được. Nếu các yêu cầu chỉ cần nói 'phần mềm cần đáp ứng nhanh là đủ "không thể kiểm chứng được, bởi vì 'đủ nhanh' có thể có nghĩa là khác nhau với những người khác nhau. Một yêu cầu kiểm chứng nhiều hơn sẽ là "phần mềm cần đáp ứng trong 5 giây với 20 người đăng nhập '. Các testability 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 và cho dù tất cả các cách hệ thống có thể được cấu hình hoặc sử dụng có thể được hiểu và kiểm thử. Ví dụ: nếu chúng ta kiểm tra một trang web, có thể không phải là identify và tạo lại 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ể.
• Thiết kế môi trường kiểm thử thiết lập và xác định bất kỳ yêu cầu cơ sở hạ tầng và công cụ. Điều này bao gồm các công cụ kiểm tra 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 và các công cụ không phải là CNTT và trang thiết bị - tất cả mọi thứ chúng ta cần để thực hiện công việc của chúng ta.

4. Hoàn thành kiểm thử và thực hiện.

Thiết lập môi trường và dữ liệu thường đòi hỏi nhiều thời gian và công sức, vì vậy bạn nên lên kế hoạch và giám sát công việc này một cách cẩn thận. Kiểm thử thực hiện và thực hiện theo các nhiệm vụ chính, theo thứ tự sau:

• Thực hiện:
  • Phát triển và ưu tiên các trường hợp kiểm thử của chúng ta, sử dụng các kỹ thuật bạn sẽ thấy và tạo ra dữ liệu kiểm thử cho các bài kiểm tra đó. Chúng ta cũng sẽ viết hướng dẫn thực hiện các bài kiểm tra (thủ tục kiểm tra). Ví dụ người lái xe này có thể có nghĩa là thay đổi điều kiện kiểm thử 'junctions 'để' đi theo con đường xuống Mayfield Road đến ngã ba với Summer Road và yêu cầu người lái xe quẹo trái vào Summer Road và rồi vào Green Road, mong rằng người lái xe sẽ kiểm tra gương, tín hiệu và cách điều khiển một cách chính xác, trong khi vẫn nhận thức được những người sử dụng đường khác '. Chúng ta có thể cần phải tự động hóa một số bài kiểm tra bằng cách sử dụng kiểm thử khai thác và các kịch bản kiểm tra tự động. Tạo bộ kiểm tra từ các trường hợp kiểm thử để thực hiện kiểm tra hiệu quả. Một bộ kiểm tra là một bộ sưu tập hợp lý các trường hợp kiểm thử mà tự nhiên làm việc cùng nhau. Bộ phần mềm kiểm thử thường chia sẻ dữ liệu và một bộ mục tiêu chung cấp cao. Chúng ta cũng sẽ thiết lập lịch thực hiện kiểm tra.
  • Thực hiện và xác minh môi trường. Chúng ta đảm bảo rằng môi trường kiểm thử đã được thiết lập chính xác, thậm chí có thể chạy kiểm thử cụ thể trên đó.
• Thực thi:
  • Thực hiện các bộ kiểm tra và các trường hợp kiểm tra cá nhân, sau các thủ tục kiểm tra kiểm thử của chúng ta. Chúng ta có thể làm điều này bằng tay hoặc bằng cách sử dụng các công cụ thực hiện kiểm tra, phù hợp theo thứ tự kế hoạch.
  • Đăng nhập kết quả thực hiện kiểm tra và ghi lại định danh và các phiên bản phần mềm đang được kiểm tra, các công cụ kiểm tra và phần mềm kiểm tra. Chúng ta phải biết chính xác những gì chúng ta sử dụng kiểm thử đối với những gì phiên bản của phần mềm; chúng ta phải báo cáo khiếm khuyết chống lại các phiên bản cụ thể; và nhật ký kiểm tra .
  • So sánh kết quả thực tế (điều xảy ra khi chúng ta chạy kiểm thử) với kết quả mong đợi (những gì chúng ta dự đoán sẽ xảy ra).
  • Trường hợp có sự khác biệt giữa kết quả thực tế và dự kiến, báo cáo sự khác biệt như sự cố. Chúng ta phân tích chúng để thu thập thêm chi tiết về khiếm khuyết, báo cáo thêm thông tin về vấn đề, xác định nguyên nhân của khiếm khuyết, và phân biệt giữa các vấn đề trong phần mềm và các sản phẩm khác đang được kiểm tra và bất kỳ lỗi trong dữ liệu kiểm thử, trong tài liệu kiểm thử, hoặc sai lầm trong cách chúng ta thực hiện kiểm tra.
  • Lặp lại các hoạt động kiểm tra như là kết quả của hành động thực hiện cho mỗi sai lệch. Chúng ta cần phải thực hiện lại các kiểm thử mà trước đó thất bại để xác nhận một sửa chữa (xác nhận kiểm thử hoặc kiểm thử lại). Chúng ta thực hiện các bài kiểm tra và dãy được chỉnh sửa nếu có các khiếm khuyết trong các kiểm thử của chúng ta. Chúng ta đã thử sửa lại phần mềm để đảm bảo khiếm khuyết thực sự được cố định một cách chính xác (kiểm tra xác nhận) và rằng các lập trình đã không giới thiệu các khiếm khuyết trong các khu vực không thay đổi của phần mềm và sửa lỗi không tìm ra các khiếm khuyết khác ( kiểm thử hồi quy).

5. Đánh giá tiêu chuẩn hoàn thành kiểm thử và báo cáo.

Đánh giá tiêu chí hoàn thành kiểm thử là hoạt động thực hiện kiểm tra được đánh giá dựa trên các mục tiêu đã được xác định. Điều này nên được thực hiện cho mỗi cấp độ kiểm tra, như đối với mỗi cần phải biết liệu chúng ta đã làm đủ bài kiểm tra. Dựa trên đánh giá rủi ro của chúng ta, chúng ta sẽ có các tiêu chí mà chúng ta sẽ đo lường 'đủ'. Các tiêu chí này khác nhau đối với mỗi dự án và được gọi là các tiêu chí hoàn thành kiểm thử . Họ cho chúng ta biết liệu chúng ta có thể tuyên bố một hoạt động kiểm thử nhất định hoặc mức độ hoàn thành. Chúng ta có thể có kết hợp các tiêu chí cục bộ hoặc hoàn thành (cho chúng ta biết về các trường hợp kiểm thử phải bao gồm, ví dụ: 'kiểm thử lái xe phải bao gồm một điểm dừng khẩn cấp' hoặc 'phần mềm kiểm thử phải bao gồm một phép đo phản ứng '), tiêu chí chấp nhận (mà cho chúng ta biết cách chúng ta biết liệu phần mềm đã vượt qua hay thất bại tổng thể, ví dụ: 'chỉ vượt qua người lái xe nếu họ đã hoàn thành dừng khẩn cấp một cách chính xác 'hoặc' chỉ vượt qua phần mềm để phát hành nếu nó đáp ứng được yêu cầu ưu tiên 1 ') và quá trình thoát tiêu chí (cho chúng ta biết chúng ta đã hoàn thành tất cả các nhiệm vụ chúng ta cần làm, ví dụ. 'người kiểm tra / người kiểm tra đã không hoàn thành cho đến khi họ đã viết và nộp hồ sơ kết thúc bài kiểm tra '). Tiêu chuẩn hoàn thành kiểm thử phải được thiết lập và đánh giá cho từng mức độ kiểm tra. Đánh giá tiêu chí hoàn thành kiểm thử có những nhiệm vụ chính sau:

• Kiểm tra các bản ghi kiểm tra đối với các tiêu chí hoàn thành kiểm thử được chỉ định trong kế hoạch kiểm tra: Chúng ta xem xét xem những bằng chứng nào mà chúng ta đã kiểm tra và đã kiểm tra những lỗi nào và lỗi nào đã được nêu ra, cố định, xác nhận đã được kiểm tra hoặc đang đứng ngoài.
• Đánh giá nếu cần thêm các xét nghiệm hoặc nếu các tiêu chí hoàn thành kiểm thử được chỉ định đã thay đổi: Chúng ta có thể cần chạy thêm các kiểm tra nếu chúng ta không chạy tất cả các bài kiểm tra mà chúng ta thiết kế, hoặc nếu chúng ta nhận ra rằng chúng ta đã không đạt được vùng mà chúng ta dự kiến, hoặc nếu rủi ro đã tăng lên cho dự án. Chúng ta có thể cần thay đổi tiêu chuẩn hoàn thành kiểm thử để hạ thấp chúng, nếu rủi ro về nghiệp vụ và dự án tăng lên và rủi ro về sản phẩm hoặc kỹ thuật giảm xuống . Lưu ý rằng điều này không dễ dàng để làm 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: Không đủ để người kiểm tra biết kết quả của bài kiểm tra. Tất cả các bên liên quan cần phải biết kiểm thử đã được thực hiện và kết quả của kiểm thử, để làm cho các quyết định thông báo về phần mềm.

6. Các hoạt động kiểm thử kết thúc.

Trong các hoạt động hoàn thiện kiểm thử, chúng ta 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 kiểm tra và lưu trữ các phần mềm kiểm tra, phân tích sự kiện và con số. Chúng ta có thể cần phải làm điều này khi phần mềm được cung cấp. Chúng ta cũng có thể hoàn thiện kiểm tra vì các lý do khác, chẳng hạn như khi chúng ta thu thập thông tin cần thiết từ kiểm thử, khi dự án bị hủy bỏ, khi đạt được mốc quan trọng, hoặc khi một bản phát hành bảo trì hoặc cập nhật đượ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 các sản phẩm dự kiến mà chúng ta thực sự phân phối và đảm bảo tất cả các báo cáo sự cố đã được giải quyết thông qua sửa chữa lỗi hoặc hoãn lại.
• Hoàn thiện và lưu trữ phần mềm testware, chẳng hạn như các kịch bản, môi trường kiểm thử, và bất kỳ cơ sở kiểm thử khác, để sử dụng lại sau này. Điều quan trọng là phải sử dụng lại bất cứ điều gì chúng ta có thể testware; chúng ta sẽ không thể tránh khỏi thực hiện kiểm thử bảo trì, và nó tiết kiệm thời gian và công sức nếu kiểm thử của chúng ta có thể được kéo ra từ một thư viện của các bài kiểm tra hiện tại.
• Bàn giao tài liệu kiểm thử cho tổ chức bảo dưỡng sẽ hỗ trợ phần mềm và thực hiện bất kỳ sửa lỗi hoặc thay đổi bảo trì, để sử dụng trong kiểm thử vững chắc và kiểm tra hồi quy.
• Đánh giá cách kiểm thử và phân tích các bài học cho tương lai phát hành và dự án. Điều này có thể bao gồm cải tiến qui trình cho phát triển vòng đời sản phẩm phần mềm như một toàn thể và cũng cải thiện quy trình kiểm thử. . Chúng ta có thể nhìn vào số lượng sự cố đó là vấn đề kiểm tra, với mục đích cải tiến cách chúng ta thiết kế, thực hiện và kiểm tra các bài kiểm tra của chúng ta hoặc quản lý môi trường kiểm thử và dữ liệu. Điều này giúp chúng ta làm cho kiểm thử của chúng ta phát triển và hiệu quả về chi phí hơn cho tổ chức. Đây là tài liệu trong một báo cáo tóm tắt kiểm thử hoặc có thể là một phần của một báo cáo tổng thể đánh giá dự án.