Vì sao nên dùng phân tích tác động trong kiểm thử?

Phát triển phần mềm là một quá trình liên tục, liên tục sửa đổi, cải tiến và thêm tính năng mới, tất cả nỗ lực chỉ để mang lại giá trị gia tăng cho người sử dụng. Tính liên tục này là cần thiết, nhưng nó cũng có những hạn chế. Đó là đối lúc gây khó khăn để đánh giá hậu quả mà những thay đổi tác động lên hệ thống. Với sự kết hợp của các tính năng mới vào ứng dụng hoặc sản phẩm, trở thành bắt buộc để kiểm tra ảnh hưởng của các tính năng mới hoặc thay đổi về hiệu suất của hệ thống. Do đó, phân tích tác động được thực hiện

Phân tích tác động là gì?

Phân tích tác động có thể được mô tả như là một cách để đánh giá tất cả các rủi ro phát sinh với sự ra đời của một sự thay đổi đặc biệt cho sản phẩm. Có nhiều định nghĩa khác nhau của phân tích tác động đặt trọng tâm vào các khía cạnh khác nhau của nó. Nhưng nhìn chung thì Phân tích tác động là việc phân tích các tác động của những thay đổi trong sản phẩm hoặc ứng dụng được triển khai. Nó cung cấp cho các thông tin về các lĩnh vực của hệ thống có thể bị ảnh hưởng do sự thay đổi trong phần cụ thể hoặc tính năng của ứng dụng. Các tác động được phân tích về yêu cầu, thiết kế và kiến trúc, tác động vào kiểm thử và ảnh hưởng đến tiến độ.

Tại sao chúng ta cần phải sử dụng phân tích tác động?

Phát triển phần mềm có thể là một thách thức có hiệu quả thực sự hay một cơn ác mộng cho các lập trình viên và người sử dụng. Phát triển nhanh đòi hỏi nghi thức nhiều hơn chuyên môn cú pháp. Một trong những hoạt động phát triển quan trọng nhất tốt là biết làm thế nào để kiểm tra ứng dụng với tư cách là người dùng cuối. Coders nghĩ rằng đó là dễ dàng để sửa đổi bất kỳ đoạn mã họ có. Rất ít sẽ xem xét các tác dụng phụ của các sửa đổi này. Lập trình Ít sẽ quan tâm ngay cả để nghiên cứu tác động của việc biến đổi của họ về cách mà phần mềm sẽ chạy, sử dụng tài nguyên của mình, cách người dùng tương tác với các phần mềm và các rủi ro liên quan với mảnh sửa đổi.

Do vậy, lợi ích của việc phân tích tác động đối với QA đó là:

• Không lãng phí thời gian vào các funcition của dự án mà không bị ảnh hưởng
• Tập trung kiểm thử vào những thay đổi thực tế
• Tìm ra những gì loại rủi ro sẽ ảnh hưởng tới hệ thống bởi những thay đổi. Giúp tester có thể đưa ra nhưng loại kiểu thử cần thiết để đảm bảo chất lượng của sản phẩm khi áp dụng những thay đổi đó.
• Xem xét những thay đổi và quá trình hiện tại sẽ ảnh hưởng đến quy trình và cách kiểm thử như thế nào? Những thay đổi có ảnh hưởng đến ngân sách hiện tại của dự án hay không? Để có thể ước lượng effort cần thiết đằng sau việc thực hiện các thay đổi.
• Xem xét những gì các phần khác của dự án tiềm năng có thể bị ảnh hưởng

Tùy từng dự án quy mô khác nhau đòi hỏi một cách tiếp cận hoàn toàn khác nhau để tổ chức thông tin.

Với dự án nhỏ và không có nhiều tính năng thì ta có thể xây dựng một bảng phân tích tác động như sau: Có thể sử dụng số để cung cấp một thông tin tốt hơn về mức độ tính năng mà có thể có nhiều khả năng bị ảnh hưởng bởi những thay đổi:

• 3 tác động mạnh mẽ
• 2 cho tác động vừa phải
• 1 cho tác động yếu

Trong ví dụ này, nó là rõ ràng rằng có 1, 4, 6 cần phải được kiểm tra kỹ lưỡng hơn và trước khi mọi thứ khác, hơn tính năng 3, 5, và cuối cùng là tính năng 2. Bằng cách này, có thể nhìn thấy rõ ràng những funcition có mức độ ảnh hưởng nghiêm trọng khi có sự thay đổi. Nó giúp chúng ta tiết kiệm effort kiểm thử những vùng không bị ảnh hưởng nhiều để tập trung vào phần có độ rủi ro nhất. Có những dự án lớn và nhiều tính năng, quy mô 1-3 là không đủ để mô tả mức độ tác động của một sự thay đổi. Trong trường hợp này, chúng tôi sử dụng quy mô 1-5:

• 5 tác động rất mạnh
• 4 tác động mạnh mẽ
• 3 tác động vừa phải
• 2 cho tác động yếu
• 1 cho tác động rất yếu

Với các dự án có quy mô lớn, các dự án này thường có một số lượng lớn các tính năng, gồm nhiều tính năng con. Sử dụng ma trận từ ví dụ trước cho các dự án quy mô lớn như vậy là không khả thi vì nó sẽ dẫn đến một bảng rất lớn và rất chật chội đó là hầu như không thể đọc được. Đối với dự án có khá nhiều tính năng chính và phụ thì chúng ta có thể xây dựng 1 bảng phân tích như sau: Bảng này sẽ liệt kê tất cả các tính năng chính của dự án và các tính năng con nên được bao gồm trong các cột.

Bản này sẽ đánh dấu các tính năng mà bị ảnh hưởng bởi sự thay đổi.

Thông thường, khi thay đổi có tác động vào một tiểu tính năng cụ thể nào đó, nó không nhất thiết có nghĩa là các tính năng phụ thuộc khác cũng bị ảnh hưởng. Trong ví dụ trên, chỉ có các tính năng con 1, 3 và 4 bị ảnh hưởng bởi những thay đổi. Ngay cả trong trường hợp, khi một sự thay đổi có ảnh hưởng đến tất cả các tính năng con dưới một tính năng nào đó, nó không nhất thiết có nghĩa là sức mạnh của tác động này là như nhau. Do đó, bảng này cung cấp cho chúng ta với tất cả các thông tin chi tiết cần thiết trong một hình thức dễ đọc đơn giản. Bất kỳ thông tin bổ sung có liên quan đến quá trình thử nghiệm nên được đề cập trong các ô tương ứng trong bảng tính. Thông tin này có thể bao gồm:

• Cấu hình
• Đề cập đến vấn đề tồn tại trước đó
• Đề cập đến các sản phẩm có liên quan đã được release mà khi thay đổi cần kiểm tra lại (đối với trường hợp sản phẩm được ứng dụng cho nhiều nền tảng hoặc device)
• Thông tin cần thiết khác

Ví dụ:

Qua bài viết , tôi hy vọng chúng ta có thể nhìn ra được tầm quan trọng của việc phân tích tác động trong quá trình phát phần mềm cũng như là quá trình kiểm thử. Nếu một QA không sử dụng phân tích tác động, họ sẽ không tránh khỏi trường hợp mất thời gian kiểm thử cho các tính năng không bị ảnh hưởng bởi sự thay đổi. Phân tích tác động cho phép đội ngũ QA tập trung kiểm thử những function cần thiết nhất, tối ưu hóa thời gian dành vào kiểm thử, giúp QA trong quá trình kiểm thử có thể đưa ra các quyết định sử dụng loại kiểm thử cần thiết để đảm bảo tính chính xác của những thay đổi đó. Quá trình làm việc được cải thiện là dễ dàng hơn để làm theo và mang lại kết quả tốt hơn.