Kiểm thử khi có Change request để đảm bảo được chất lượng của phần mềm

Trong quá trình phát triển phần mềm, việc phát sinh các thay đổi là việc thường xuyên xảy ra, đặc biệt là khi phần lớn các dự án đang phát triển theo mô hình Agile. Với vai trò QC, bạn cần đưa ra chiến lược phù hợp để đảm bảo những thay đổi này không làm ảnh hưởng đến chất lượng của sản phẩm. Đây là một loại test type là regression test, hay kiểm thử hồi quy. Vậy cách tiếp cận thế nào để đảm bảo quá trình regression test đảm bảo được chất lượng. Dưới đây là một số điểm bạn có thể tham khảo.

1. Phân tích mức độ ảnh hưởng của thay đổi

Đây là công đoạn quan trọng nhất trong quá trình quản lý yêu cầu thay đổi. Vì nếu không thực hiện phân tích đầy đủ thì có thể bạn sẽ để lọt các vùng bị ảnh hưởng do thay đổi hoặc thêm mới tính năng.

1.1 Mục tiêu 

Giai đoạn này bạn cần chỉ rõ được các thay đổi, tính năng mới được yêu cầu cho hệ thống sẽ ảnh hưởng đến những thành phần nào trong nó. Từ đó, tiến hành tạo, cập nhật các bộ regression test case để bao phủ các vùng ảnh hưởng đã được phân tích và xác định có liên quan.

1.2 Cách tiến hành

Có nhiều cách tiếp cận để bạn phân tích đầy đủ vùng ảnh hưởng, dưới đây là một số biện pháp mà mình đã sử dụng và thấy tương đối hiệu quả.

a. Phân tích nội bộ team QC

Với góc nhìn của mình QC sẽ cần phải đưa ra phán đoán về vùng ảnh hưởng của CR dựa trên nghiệp vụ của hệ thống cũng như tính năng của chúng. 

•  Thực hiện mô hình hóa luồng xử lý của hệ thống qua các biểu đồ. Bằng cách này, Tester cỏ thể dễ dàng thấy được điểm thay đổi trong hệ thống từ đó nhìn rõ được các tính năng chịu ảnh hưởng do cung cấp đầu vào cho tính năng thay đổi hoặc sử dụng dữ liệu của tính năng thay đổi. 
• Thực hiện liệt kê các màn hình chịu ảnh hưởng. Danh sách các màn hình chịu ảnh hưởng cũng là một yếu tố quan trọng. Từ mô hình hóa việc xử lý chúng ta có thể dễ dàng để liệt kê các màn hình trong hệ thống chịu ảnh hưởng và đưa vào scope kiểm thử.
• Phân tích các tính năng tương tự với tính năng thay đổi/ thêm mới. Ví dụ như thay đổi độ dài của trường mật khẩu trong form login, thì chắc chắn các tính năng liên quan như đổi mật khẩu, đăng ký sẽ cần phải kiểm thử lại. Việc phân tích tính năng tương tự này có thể sẽ không được thể hiện rõ ràng trong các biểu đồ, do đó, tester cần có kinh nghiệm về hệ thống để detech được các điểm này.

b. Phân tích từ các đối tượng khác trong dự án

Ngoài việc phân tích vùng ảnh hưởng từ phía QC, thì các quan điểm từ các bộ phận khác cũng giúp cho quá trình phân tích đầy đủ quan điểm hơn, từ đó, sẽ giúp chất lượng regression test tốt hơn

• Dev team: Có thể cung cấp quan điểm về việc khi thay đổi hoặc thêm mới thì những method, class … nào bị thay đổi, từ đó ảnh hưởng đến luồng xử lý nào của hệ thống.
• BA team: cung cấp thêm góc nhìn từ phía nghiệp vụ người dùng về các vùng ảnh hưởng do thêm mới hoặc chỉnh sửa tính năng.

Team có thể tổ chức các buổi phân tích mức độ ảnh hưởng để các bên có thể đóng góp đánh giá của mình vào xác định vùng ảnh hưởng của CR. Buổi này có thể lồng ghép trong buổi Refinement.

2. Lên kế hoạch kiểm thử cho các thay đổi

Đến giai đoạn này, các phần cần kiểm thử để đảm bảo chất lượng cho việc thêm mới hoặc thay đổi tính năng đã rõ ràng. Công việc của chúng ta là phải lên kế hoạch và thực hiện các công việc để đảm bảo được chất lượng như đã phân tích. Các công việc bao gồm.

2.1 Lên kế hoạch cho việc cập nhật, tạo mới test case/test script

Với các phần xác định có ảnh hưởng thì chúng ta cần xem lại bộ test case/test script đã có và chia thành 3 nhóm chính

• Nhóm tái sử dụng: Là những test case/test script không cần thay đổi, nhóm này giúp kiểm tra tính năng vẫn hoạt động đúng như phiên bản trước đó.
• Nhóm thay đổi/xóa: Là những test case/test script có một số phần cần thay đổi hoặc bản thân test case đó cần xóa bỏ vì tính năng của phần mềm đã bị thay đổi.
• Nhóm tạo mới: Chắc chắn với nhứng thay đổi lớn thì bạn cần bổ sung test case để đảm bảo độ phủ cho qua trình regression test

2.2 Lên kế hoạch cho việc thực hiện test

Quá trình này cũng khá giống với việc lên kế hoạch kiểm thử thông thường. Tuy nhiên, bạn nên bố trí các thành viên có kinh nghiệm về tính năng và vùng tính năng bị ảnh hưởng để nâng cao chất lượng kiêm thử. Vì dù sao thì test case cũng chỉ đảm bảo được những case quan trọng nhất và còn rất nhiều trường hợp khác mà có thể chưa được liệt kê trong test case.

3. Thực hiện quá trình kiểm thử

            Giai đoạn thực hiện kiểm thử hồi quy tình cũng không có điểm gì quá khác biệt với quy trình kiểm thử thông thường. Tuy nhiên, trong quá trình kiểm thử mà bạn có phát hiện các lỗi ở những phần khác thì bạn nên bổ sung thêm các quan điểm mới vào phần kiểm thử của mình để đảm bảo độ phù cần thiết

            Với bài viết này, IT Learn mong muốn cung cấp cho các bạn một phương pháp cơ bản và tương đổi hiệu quả để quản lý CR cũng như có thể đảm bảo được chất lượng kiểm thử cho các CR này. Và hãy nhớ 1 trong 7 nguyên lý kiểm thử phần mềm là “Kiểm thử phụ thuộc ngữ cảnh”, bạn hãy chọn phương pháp phù hợp với dự án và công ty mình nhé.