日本語
EnglishCác hoạt động chính trong quy trình kiểm thử phần mềm – Phần 1
Quy trình kiểm thử phần mềm là toàn bộ quá trình từ khi chuẩn bị kiểm thử cho đến khi hoàn thành kiểm thử. Trong quá trình này, có rất nhiều hoạt động được thực hiện. Quy trình kiểm thử phần mềm có thể được hiểu đơn giản là tổng hợp những hoạt động kiểm thử đã được sắp xếp và phân loại theo từng giai đoạn. Tùy theo tình hình thực tế, quy trình này có thể được rút gọn, loại bỏ một số giai đoạn. Những yếu tố có thể ảnh hưởng đến quy trình kiểm thử phần mềm bao gồm quy mô dự án, dự toán ngân sách và các tiêu chuẩn pháp luật.
Một quy trình kiểm thử cơ bản, thông thường sẽ bao gồm 7 loại hoạt động dưới đây:
- Lập kế hoạch kiểm thử
- Giám sát và kiểm soát kiểm thử
- Phân tích kiểm thử
- Thiết kế kiểm thử
- Phát triển kiểm thử
- Thực hiện kiểm thử
- Hoàn thành kiểm thử
Tùy thuộc vào từng trường hợp, các hoạt động trên có thể được thực hiện theo thứ tự hoặc đồng thời. Ví dụ, người ta có thể vừa phân tích, vừa thiết kế kiểm thử, đồng thời thực hiện kiểm thử với các trường hợp đã rõ yêu cầu. Cần dựa vào các yếu tố khách quan, như mô hình phát triển của phần mềm, để điều chỉnh thời điểm và thời gian thực hiện các hoạt động kiểm thử sao cho phù hợp.
Hôm nay chúng ta sẽ cùng tìm hiểu chi tiết về 3 hoạt động đầu tiên trong quy trình kiểm thử:
- Lập kế hoạch kiểm thử
- Giám sát và kiểm soát kiểm thử
- Phân tích kiểm thử
1/ Lập kế hoạch kiểm thử
Trong việc hoạch định kế hoạch kiểm thử, bước đầu tiên cần thực hiện là làm rõ mục đích của việc kiểm thử. Mục đích kiểm thử sẽ khác nhau tùy thuộc vào thời gian giao hàng và lý do tồn tại của sản phẩm được kiểm thử. Ví dụ, nếu ưu tiên là thời gian giao sản phẩm, thì mục đích kiểm thử sẽ tập trung vào việc xác nhận các chức năng chính của sản phẩm.
Ngoài ra, tùy theo loại kiểm thử như unit test, integration test (IT test), hay system test, mục đích kiểm thử cũng sẽ khác nhau. Cụ thể, khi thực hiện unit test, mục đích sẽ là kiểm tra kỹ lưỡng và chi tiết các chức năng riêng lẻ, trong khi đó, khi thực hiện integration test, mục đích là kiểm tra luồng di chuyển và tương tác giữa các thành phần của phần mềm.
2/ Giám sát và kiểm soát kiểm thử
Điều quan trọng để có thể kiểm soát quy trình kiểm thử là nắm rõ tình trạng các hoạt động và nhiệm vụ kiểm thử, tức là cần tổ chức giám sát quy trình kiểm thử. Nếu không giám sát, sẽ khó xác định liệu việc kiểm thử có đang được thực hiện theo đúng phương hướng hay không, và không thể lý giải một cách khách quan về tình hình kiểm thử có đang diễn ra thuận lợi hay không. Việc lý giải khách quan này liên quan đến tiêu chí kết thúc kiểm thử, cho phép phán đoán về việc có thể kết thúc các hoạt động kiểm thử hay không. Chỉ cần có tiêu chí kết thúc, ta có thể đưa ra quyết định về việc hoàn tất các hoạt động kiểm thử.
Về các hạng mục giám sát, trong thời gian thực hiện kiểm thử, cần xem xét độ lệch giữa kế hoạch test và tiến độ hiện tại, đồng thời phân tích chất lượng của đối tượng kiểm thử dựa trên tình trạng bug xuất hiện và tiến độ hàng ngày của các ca kiểm thử. Các vấn đề này nên được báo cáo với các bên liên quan dưới dạng báo cáo tiến độ kiểm thử. Thông qua những hoạt động này, ta không chỉ so sánh độ lệch với kế hoạch kiểm thử mà còn xem xét cả mục đích đã được đề ra trong kế hoạch dự án. Nếu cần thiết, cần đưa ra ý kiến xem xét lại kế hoạch kiểm thử và kế hoạch của dự án.
3/ Phân tích kiểm thử
Khi phân tích kiểm thử, chúng ta sẽ thu thập các thông tin cần thiết để tiến hành kiểm thử, tức là thu thập test basis (cơ sở kiểm thử), trong đó ghi lại các thông tin về thiết kế phần mềm, yêu cầu chức năng, yêu cầu phi chức năng, cũng như các thành phần và cấu trúc của phần mềm. Tiếp theo, chúng ta sẽ tiến hành xem xét, chọn lọc và thu thập lại thông tin, đồng thời tạo ra những thông tin mới nếu cần thiết. Từ đó, chúng ta sẽ phán đoán xem chức năng nào (bao gồm component và thuộc tính hệ thống) có thể được kiểm thử.
Đối với những đối tượng kiểm thử đã trải qua bước phân tích, các kỹ thuật test và chiến lược test sẽ được xây dựng trong hoạt động tiếp theo, là hoạt động Thiết kế kiểm thử. Dưới đây là chi tiết về những nhiệm vụ cần thực hiện trong quá trình phân tích kiểm thử.
Phân tích test basis hợp lý ở mỗi test level
Kỹ thuật viên thiết kế test (kiểm thử) sẽ là người phân tích test basis. Trong test basis bao gồm các tài liệu như RFP (Đề nghị mời thầu), Use Case (Trường hợp sử dụng), Purchase Specification (Đặc điểm kỹ thuật mua), và User Story (Tài liệu mô tả tính năng từ góc nhìn của người dùng). Ngoài ra, còn rất nhiều tài liệu khác như thông số yêu cầu kỹ thuật, định nghĩa kiến trúc, báo cáo phân tích rủi ro, thông số kỹ thuật thiết kế, thông số giao diện, và các tài liệu tiêu chuẩn (bao gồm cả các tài liệu công khai như RFC và tiêu chuẩn ISO/IEC, cũng như các tiêu chuẩn nội bộ của tổ chức).
Test basis không chỉ bao gồm các tài liệu chính thức, mà còn chứa các ghi chép từ các cuộc họp, email trao đổi, và ghi chú trên bảng trắng từ thời điểm phát triển. Nó sẽ khác nhau tùy thuộc vào phương thức và phong cách giao tiếp của mỗi dự án.
Đánh giá test basis và hạng mục test để phân chia các loại lỗi khác nhau
Sau khi phân tích test basis, cần nhận diện những lỗi cố hữu có trong test basis. Những lỗi dễ nhận biết, chẳng hạn như khi tài liệu đặc tả yêu cầu ghi nhận một thông tin nào đó nhưng tài liệu đặc tả chức năng lại không đề cập đến, ta có thể báo cáo vấn đề này là lỗi hoặc tài liệu có thể phát sinh mâu thuẫn. Ngoài ra, cũng có những lỗi do ghi chép không chính xác hoặc không rõ ràng. Ví dụ, nếu tài liệu yêu cầu kiểm tra xem nội dung có dễ đọc hay không nhưng không mô tả cụ thể tiêu chí nào là “dễ đọc”, thì chuyên viên kiểm thử có thể thực hiện kiểm thử dựa trên đánh giá chủ quan của bản thân. Do đó, để thực hiện kiểm thử một cách khách quan, cần cung cấp thông tin thiết kế có định lượng cụ thể (ví dụ: font chữ Times New Roman, kích thước chữ 13) thay vì định tính như trên. Đặc biệt cần chú ý trong trường hợp tài liệu được viết bằng ngôn ngữ logic hoặc có cấu trúc câu dài, không rõ ràng về chủ ngữ và vị ngữ.
Phân chia tính năng (feature) cần kiểm thử và nhóm tính năng (feature set)
Feature là “một tính năng được xác định rõ ràng hoặc ngầm định của một thành phần hoặc thuộc tính của hệ thống (ví dụ: độ tin cậy, khả năng sử dụng, các ràng buộc về thiết kế, v.v.)”. Khi thực hiện kiểm thử các tính năng này, ở mỗi cấp độ kiểm thử, ta sẽ lọc ra những tính năng có thể kiểm thử được ở cấp độ đó và nhóm chúng lại thành các nhóm tính năng, gọi là feature set, sao cho mỗi set có thể được kiểm thử độc lập. Trong một số trường hợp, đối với các dự án nhỏ chỉ có một tính năng, sẽ chỉ tồn tại một feature set duy nhất.
Quyết định điều kiện kiểm thử của từng tính năng và thứ tự kiểm thử dựa trên phân tích test basis
Từ việc thu thập và phân tích test basis, ta làm rõ điều kiện kiểm thử cho từng tính năng. Cần bổ sung vào tài liệu xem xét những yếu tố kinh doanh như thời gian có thể thực hiện kiểm thử dựa trên tình hình chuẩn bị môi trường test, các ràng buộc về lịch trình, trình độ cần có của kỹ thuật viên kiểm thử, và các kỹ thuật cần thiết để thực hiện kiểm thử. Các điều kiện kiểm thử được xác định bằng cách phân tích mối tương quan và sự phụ thuộc, điểm tương đồng, và cấu trúc phần mềm, v.v. giữa các thông số kỹ thuật đối với chức năng và phi chức năng của từng hạng mục kiểm thử.
Sau khi xác định được các điều kiện kiểm thử, cần sắp xếp thứ tự ưu tiên cho chúng để phù hợp với mục tiêu và cách tiếp cận kiểm thử. Việc sắp xếp thứ tự ưu tiên cũng nên xem xét các điều kiện kiểm thử liên quan đến rủi ro sản phẩm (Product Risk).
Thiết lập khả năng truy vết hai chiều giữa các yếu tố trong test basis và điều kiện kiểm thử liên quan
Việc thiết lập khả năng truy vết hai chiều giữa các yếu tố trong test basis và điều kiện kiểm thử liên quan nhằm đảm bảo rằng mọi điều kiện kiểm thử được xác định từ test basis đều được phân tích và triển khai một cách đầy đủ. Điều này giúp đảm bảo rằng quá trình kiểm thử sẽ bao phủ toàn bộ các yêu cầu và chức năng của phần mềm.
Thực hiện loạt hoạt động này ở giai đoạn phân tích kiểm thử sẽ giúp phát hiện lỗi trong test basis trước khi tiến hành thiết kế kiểm thử. Bằng cách thu thập và phân tích test basis từ nhiều phương diện khác nhau, ta có thể thu được nhiều góc nhìn liên quan đến việc phát triển sản phẩm. Từ các lập trường của khách hàng, người dùng cuối, quản lý dự án, quản lý sản phẩm, kỹ sư, và lập trình viên, yêu cầu đối với sản phẩm và chất lượng của sản phẩm có thể khác nhau hoặc thậm chí mâu thuẫn với nhau. Hoạt động phân tích kiểm thử này cũng hữu ích trong việc xác nhận xem yêu cầu của các bên liên quan có được phản ánh đúng trong test basis hay không.
※Câu hỏi luyện tập: