日本語
EnglishCác hoạt động chính trong quy trình kiểm thử phần mềm – Phần 3
Bài viết Các hoạt động chính trong quy trình kiểm thử phần mềm – Phần 2 đã giới thiệu hai hoạt động trong quy trình kiểm thử là “Thiết kế kiểm thử” và “Phát triển kiểm thử”. Trong bài viết này, chúng ta sẽ cùng nhau tìm hiểu về hai hoạt động cuối cùng:
- Tiến hành kiểm thử
- Hoàn thành kiểm thử
6/ Tiến hành kiểm thử
Hoạt động tiến hành kiểm thử bao gồm các hoạt động chính sau
Ghi lại ID và phiên bản của hạng mục kiểm thử, đối tượng kiểm thử, công cụ kiểm thử và phần mềm kiểm thử
Khi bắt đầu tiến hành kiểm thử, cần ghi lại các thông tin cần thiết cho các trường hợp kiểm thử. Phần mềm được kiểm thử thường được xác định rõ ràng, tuy nhiên cũng cần kiểm tra phiên bản của phần mềm ngay trước khi thực hiện kiểm thử. Ngoài ra, nếu sử dụng dữ liệu kiểm thử hoặc công cụ kiểm thử thì cũng cần ghi lại phiên bản của chúng cũng như thông tin các script dưới dạng ID của phần mềm kiểm thử. Bên cạnh đó, kết quả kiểm thử thì được ghi lại dựa theo các trường hợp kiểm thử và các quy trình đã thống nhất trước đó. Với các môi trường phát triển dạo gần đây, nhiều hệ thống có thể tự động lưu lại các bản ghi này.
Tiến hành kiểm thử bằng cách thủ công hoặc sử dụng công cụ tiến hành kiểm thử
Quá trình kiểm thử được thực hiện theo quy trình kiểm thử bởi con người hoặc bằng công cụ kiểm thử. Chúng ta có thể tiến hành bằng cách thao tác trực tiếp lên đối tượng kiểm thử, hoặc cũng có thể thao tác từ xa thông qua các phương pháp truy cập từ xa. Theo đó, nhiều phương pháp kiểm thử khác nhau có thể được sử dụng, bao gồm cả kiểm thử trong môi trường phát triển tích hợp (IDE).
So sánh kết quả kiểm thử với kết quả mong đợi
So sánh kết quả kiểm thử với các tiêu chí đánh giá và tiêu chuẩn đã định trong tài liệu kiểm thử. Nếu kết quả so sánh khớp nhau, hoặc nếu mục đích ban đầu đơn giản chỉ để đo lường thì kiểm thử sẽ được ghi nhận là thành công hoặc hoàn tất, và sau đó tiếp tục thực hiện các trường hợp kiểm thử tiếp theo.
Phân tích lỗi và xác định nguyên nhân tiềm ẩn
So sánh các trường hợp kiểm thử với các nội dung căn bản trong thiết kế kiểm thử để phân tích các cử động chưa phù hợp. Để xác định được nguyên nhân, cần xác định các ngữ cảnh và các trường hợp kiểm thử đã khiến phát sinh lỗi, chẳng hạn như lỗi phát sinh do chưa tiến hành kiểm thử đối tượng kiểm thử theo thứ tự phù hợp hay do thay đổi data kiểm thử.
Theo dõi quá trình xảy ra lỗi và báo cáo nội dung lỗi dựa vào kết quả quan sát
Nếu kết quả kiểm thử khác với kết quả mong đợi và được xác định là lỗi, lúc này cần báo cáo nội dung lỗi. Trong quá trình tổng hợp báo cáo, không chỉ chú trọng về hiện tượng trực tiếp quan sát được từ lỗi mà còn cân nhắc khả năng lỗi tương tự có thể xảy ra do các yếu tố khác hoặc liệu các trường hợp kiểm thử khác có bị ảnh hưởng hay không.
Ghi lại kết quả tiến hành kiểm thử
Đối chiếu kết quả của từng trường hợp kiểm thử với kết quả mong đợi và xác định xem có đạt hay không. Nếu không đạt thì tạo báo cáo về nội dung lỗi và ghi lại các trường hợp kiểm thử dự kiến không đạt (block case) dù cho có thực hiện lại quy trình tương tự. Các trường hợp kiểm thử bị block (block case) là các trường hợp không thể tiến hành kiểm thử bởi các yếu tố bên ngoài hoặc do môi trường kiểm thử chưa hoàn thiện (chẳng hạn như đang chờ mua giấy phép phần mềm hoặc đang chờ đến lượt sử dụng thiết bị kiểm thử).
Kết quả kiểm thử cần được ghi lại chi tiết, bao gồm cả môi trường kiểm thử, cấu hình phần mềm và công cụ kiểm thử.
Lặp lại hoạt động kiểm thử để kiểm tra kết quả đối ứng lỗi hoặc lặp lại nếu đây là một phần trong kế hoạch kiểm thử đã đề ra
Sau khi lỗi đã được báo cáo và được sửa chữa, lúc này sẽ tiến hành Kiểm thử xác nhận. Kiểm thử xác nhận có thể thực hiện ngay sau khi đối tượng được triển khai phần sửa chữa lên môi trường kiểm thử, hoặc có thể được gom lại để tiến hành trong khoảng thời gian đã lên kế hoạch theo lịch trình kiểm thử ban đầu. Ngoài ra, bên cạnh Kiểm thử xác nhận, Kiểm thử hồi quy cũng được lên kế hoạch để kiểm tra xem các chức năng cũ có bị ảnh hưởng hay không.
Kiểm tra và cập nhật khả năng truy vết hai chiều giữa cơ sở kiểm thử, điều kiện kiểm thử, trường hợp kiểm thử, quy trình kiểm thử, và bộ kiểm thử (test suite)
Đây là quá trình kiểm tra xem kiểm thử đã được thực hiện đúng theo yêu cầu và đảm bảo rằng tất cả các yếu tố liên quan đều đang được liên kết với nhau một cách chính xác. Điều này giúp đảm bảo rằng nếu có bất kỳ thay đổi hoặc sửa đổi nào trong quá trình kiểm thử đều sẽ được phản ánh ở mọi yếu tố liên quan, nhằm duy trì tính nhất quán.
7/ Hoàn thành kiểm thử
Trong giai đoạn hoàn thành kiểm thử, các thành phẩm như kịch bản kiểm thử và báo cáo lỗi được tổng hợp để đánh giá xem đã đạt được mục tiêu của kế hoạch kiểm thử hay chưa. Lúc này sẽ phân tích mức độ bao phủ mã nguồn (code coverage), mức độ hoàn thiện của các yêu cầu phi chức năng và mức độ bao quát cấu hình hệ thống, sau đó là phân tích kết quả dựa trên các tiêu chuẩn kết thúc kiểm thử. Ngoài ra, sử dụng các biểu đồ quản lý lỗi và các chỉ số (metrics) làm cơ sở để kiểm tra tình trạng cải thiện của lỗi và tiến độ của quá trình kiểm thử.
Ngoài ra, các tiêu chuẩn kết thúc kiểm thử đặt ra ở giai đoạn lên kế hoạch thật ra cũng chỉ được quyết định dựa trên các yêu cầu và giả định chất lượng trước khi bắt đầu kiểm thử, nhưng sau đó có thể được xem xét lại do các thay đổi về yêu cầu hoặc nhu cầu của khách hàng trong quá trình kiểm thử. Do đó, thời điểm hoàn thành kiểm thử có thể khác nhau tùy vào trạng thái của dự án. Nó có thể tiến hành khi có sự chuyển đổi giữa các cấp độ kiểm thử, khi hoàn thành toàn bộ kiểm thử, hoặc trong trường hợp các dự án Agile nơi kiểm thử có thể được thực hiện theo từng giai đoạn (iteration). Trong một số trường hợp, kiểm thử cũng có thể bị ngưng giữa chừng.
Bài viết này đã trình bày về hai hoạt động trong quy trình kiểm thử phần mềm. Hãy thử thực hiện bài kiểm tra nhỏ ở liên kết dưới đây để kiểm tra kiến thức của bạn về các hoạt động này!
Dưới đây là các hoạt động chính trong giai đoạn này.
Xác nhận rằng tất cả các báo cáo lỗi đã đóng. Nếu có lỗi chưa được giải quyết vào thời điểm kết thúc kiểm thử, yêu cầu thay đổi hoặc các mục backlog của sản phẩm sẽ được tạo ra
Kiểm tra xem có các báo cáo lỗi chưa được giải quyết nào từ các cấp độ kiểm thử trước hoặc hiện tại hay không. Nếu toàn bộ vấn đề đã được giải quyết, báo cáo lỗi xem như là đã hoàn tất và sẽ được đóng lại. Nếu quyết định sửa chữa vấn đề ở cấp độ kiểm thử tiếp theo, báo cáo lỗi sẽ được chuyển tiếp đến cấp độ đó. Trường hợp lỗi chưa được xử lý, lúc này lỗi sẽ được lưu lại thành một mục backlog của sản phẩm để đảm bảo sau này không đối ứng sót.
Tạo báo cáo tổng kết kiểm thử và gửi cho các bên liên quan
Ở hoạt động này sẽ tạo tài liệu báo cáo so sánh và phân tích kết quả kiểm thử với các tiêu chí kết thúc để xác định xem cấp độ kiểm thử có thể kết thúc hay chưa, sau đó gửi báo cáo này đến các bên liên quan. Báo cáo này tổng hợp tỷ lệ đạt của các trường hợp kiểm thử, số lượng báo cáo lỗi và tình trạng xử lý, và được gửi đến tất cả các bên liên quan đến quá trình kiểm thử.
Các bên liên quan là những người chịu ảnh hưởng trực tiếp hoặc gián tiếp khi quá trình kiểm thử kết thúc, tùy thuộc vào cấp độ kiểm thử và đối tượng kiểm thử. Cuối cùng, sau khi phân tích kết quả kiểm thử và so sánh với các tiêu chí kết thúc, nếu đạt được sự đồng thuận từ các bên liên quan về việc kết thúc hoặc dừng kiểm thử, thì cấp độ kiểm thử sẽ được tuyên bố hoàn tất. Tuy nhiên, trong thực tế, việc kết thúc kiểm thử có thể do người chịu trách nhiệm phát triển chỉ đạo, và khi đó, người liên quan chính là người quản lý phát triển. Nếu cần lưu giữ bằng chứng về việc quản lý kiểm thử, thì kết quả giám sát và kiểm soát sẽ được thu thập, phân tích và lập thành văn bản. Đặc biệt, nếu một đội ngũ kiểm thử độc lập chịu trách nhiệm, việc lập văn bản kết quả cũng là một phần quan trọng trong các hoạt động của họ.
Sắp xếp và lưu trữ môi trường kiểm thử, dữ liệu kiểm thử, hạ tầng kiểm thử, và các phần mềm kiểm thử khác để sử dụng cho lần sau
Đối với các nội dung kiểm thử có thể tái sử dụng, việc sắp xếp và bảo trì chúng là cần thiết. Điều này bao gồm việc chỉnh sửa trực tiếp các phần mềm kiểm thử, chuẩn bị hướng dẫn hoặc tài liệu đào tạo, điều chỉnh các kịch bản kiểm thử để tương thích với phiên bản mới của công cụ kiểm thử, và các công việc khác để đảm bảo khả năng tái sử dụng. Khi sản phẩm được nâng cấp phiên bản hoặc chuyển sang các thiết bị khác, việc bảo trì các trường hợp kiểm thử, cơ sở kiểm thử, và quy trình kiểm thử là cần thiết để có thể hỗ trợ cho các lần phát hành hoặc chuyển đổi thiết bị tiếp theo.
Chuyển giao các phần mềm kiểm thử cho đội bảo trì, các nhóm dự án khác, và/hoặc các bên liên quan khác có thể hưởng lợi từ việc sử dụng chúng
Khi bộ phận phát triển của dự án và bộ phận bảo trì khác nhau, bộ phần mềm kiểm thử sẽ được chuyển giao cho bộ phận bảo trì. Bộ phận bảo trì sẽ sử dụng phần mềm kiểm thử này để nắm bắt tình hình chất lượng của sản phẩm dựa trên kết quả kiểm thử, cũng như để hỗ trợ khắc phục sự cố khi có lỗi phát sinh sau khi phát hành sản phẩm.
Sử dụng thông tin thu thập được để cải thiện mức độ phát triển của quy trình kiểm thử
Để thực hiện nhiệm vụ này, sau khi hoàn thành kiểm thử, một buổi họp để “nhìn lại và đánh giá” (post-mortem) sẽ được tổ chức với tất cả các bên liên quan của cấp độ kiểm thử. Trong cuộc họp này, các vấn đề liên quan đến kiểm soát kiểm thử và kết quả kiểm thử sẽ được thảo luận cởi mở để xác định những điểm tốt và điểm cần cải thiện nhằm cải tiến quy trình và phần mềm kiểm thử.
Nếu không thiết lập hệ thống tiếp nhận các điểm cải thiện thu được từ buổi họp đánh giá để áp dụng cho cấp độ kiểm thử tiếp theo hoặc dự án khác, các đánh giá này sẽ chỉ dừng lại ở cuộc họp mà không mang lại cải tiến. Vì vậy, việc lập biên bản cuộc họp và danh sách các việc cần thực hiện, cũng như sự theo dõi của quản lý, là rất quan trọng.
Hôm nay, chúng ta đã tìm hiểu về hai hoạt động còn lại trong Quy trình kiểm thử phần mềm. Hãy cùng xác nhận lại kiến thức của bạn về hai hoạt động này bằng cách làm bài trắc nghiệm nhỏ sau đây nhé!