12/08/2018, 16:39

Tại sao cần phải phân tích tác động trong kiểm thử phần mềm? Một số ví dụ thực tế.

Phần 1: Tổng quan về impact analysis Phát triển phần mềm là một quá trình liên tục. Chúc ta liên tục thực hiện các sửa đổi, cải tiến và thêm mới các tính năng, tất cả vì một nỗ lực là mang tới những giá trị hữu ích cho người dùng. Sự liên tục là cần thiết, nhưng nó cũng có một phần hạn chế. ...

Phần 1: Tổng quan về impact analysis

Phát triển phần mềm là một quá trình liên tục. Chúc ta liên tục thực hiện các sửa đổi, cải tiến và thêm mới các tính năng, tất cả vì một nỗ lực là mang tới những giá trị hữu ích cho người dùng. Sự liên tục là cần thiết, nhưng nó cũng có một phần hạn chế. Thi thoảng chúng ta khó có thể đánh giá ảnh hưởng của những một thay đổi đơn lẻ có thể ảnh hưởng tới hệ thống

Thậm chí với một kiểm thử kỹ lưỡng, một phần đặc tính hay một phần của phần mềm có thể bị bỏ qua hoặc được test không đầy đủ. Nếu việc bổ sung tính năng mới mà xuất hiện lỗi trong các phần này thì các lỗi ấy sẽ không được phát hiện. Để tránh tình trạng này, phân tích ảnh hưởng phần mềm (software impact analysis ) nên được sử dụng.

Impact analysis là một kỹ thuật được sử dụng trong quy trình kiểm thử và mang lại thành công lớn. Đầu tiên chúng ta phải trả lời câu hỏi Phân tích tác động là gì và hiểu những thông tin chung của kỹ thuật này. Sau đó chúng ta sẽ thực hành sử dụng phân tích tác động trong các ví dụ được trình bày ở phần dưới.

1. Xác định phân tích tác động

Trước khi bắt đầu thảo luận về impact analysis , trước tiên chúng ta phải định nghĩa nó.

  • Đầu tiên, impaImpact analysis có thể được mô tả như là một cách đánh giá tất cả những rủi ro (risk) phát sinh khi thực hiện thay đổi sản phẩm. Có rất nhiều khía cạnh định nghĩa phân tích tác động, nhưng nhìn vào định nghĩa này sẽ cung cấp cho chúng ta thấy bức tranh tổng quan về impac analysis
  • Một định nghĩa được phổ biến rộng rãi về impact analysis đó là cách để estimate những rủi ro tiềm ẩn liên quan đến một thay đổi cụ thể, như là những thay đổi này ảnh hưởng như thế nào tới resources, schelule, performance của phần mềm đã được phát triển.
  • Bảng thuật ngữ ISTQB đưa ra định nghĩa riêng về phân tích tác động. Theo đó , phân tích tác động là ước lượng các hậu quả ở tất cả các cấp độ của tài liệu thử nghiệm và phát triển, bao gồm đăng ký những thay đổi này trog một tài liệu tương ứng. Do đó theo khía cạnh thực tế của phân tích tác động thì những thay đổi này cần phải được ghi lại (change request)

Để hiểu được thực sự Phân tích tác động là gì, chúng ta cần hiểu, khi nào chúng được sử dụng? Phân tích tác động phải được áp dụng trong các tình huống sau:

  • Những thay đổi trong tài liệu
  • Những yêu cầu thanh đổi sản phẩm được submit
  • Chức năng mới
  • Những module và sản phẩm đang tồn tại được thay đổi tính năng
  • Hot fix

Vậy tại sao chúng ta phải phân tích ảnh hưởng? Phân tích tác động giúp chúng ta những điều sau:

  • Các thay đổi ảnh hưởng như thế nào đến các modul và tính năng hiện có, và các module nào bị ảnh hưởng.
  • Quyết định những testcase mới cần thiết để kiểm thử module hay tính năng mới
  • Kiểm tra Quy trình kiểm thử bị ảnh hưởng như thế nào bởi các thay đổi và liệu quy trình hiện tại có đang đúng đắn?
  • Quyết định những ảnh hưởng do thay đổi này có trên ngân sách của dự án?

Phân biệt 3 loại phân tích tác động trong phần mềm:

  • PHân tích tác động của sự phụ thuộc
  • Phân tích tác động dựa trên kinh nghiệm
  • Phân tích tác động dựa trên truy xuất nguồn gốc

2. Phân tích tác động trong hoạt động phát triển.

Bây giờ chúng ta cùng xem phân tích tác động sẽ được áp dụng như thế nào đối với developer. Kỹ năng nào 1 developer có và những bước nào cần thiết để phân tích tác động đúng? Một vài yêu cầu cần phải được đáp ứng để phân tích tác động thành công, developer phải:

  • Nghiên cứu mối quan hệ giữa các modules và chi tiết chúng.
  • Ghi nhớ các thông tin đã được chia sẻ
  • Cập nhật tất cả các tài liệu phục vụ cho phân tích Nếu 1 developer giữ 3 điểm trên trong suy nghĩ và áp dụng chúng khi thực hiện phân tích ảnh hưởng thì sẽ nhận được kết quả tích cực ngay lập tức.

Theo cách này Developer phải: Suy nghĩ vè sản phẩm như là toàn bộ , không phải một tính năng hay module riêng biệt. Hiểu về kỹ thuật, công nghệ của phần mềm, theo dõi mối quan hệ giữa các module. Để làm giảm rủi ro của việc phát hiện ra bug trong các module đã bị bỏ qua trước đó thì điều cần thiết phải làm đó là cập nhật các thay đổi vào tài liệu.

3. Phân tích tác động trong hoạt động kiểm thử.

Phân tích tác động là vô cùng có lợi đối với QA. Hiểu về mối quan hệ giữa các thay đổi sẽ giúp testers:

  • Không mất thời gian kiểm thử các phần không bị ảnh hưởng của project
  • Tập trung vào những thay đổi thực tế
  • Xem xét phần nào của project bị ảnh hưởng tiềm ẩn Nếu một tester không sử dụng phân tích ảnh hưởng, sẽ dẫn tới khả năng test không đầy đủ , các testcase sẽ không bao gồm các thay đổi mới nhất và mất nhiều thời gian để kiểm thử các phần không thay đổi của dự án. Phân tích tác động cho phép QA team tập trung chuyên tâm vào nơi cần thiết nhất, tối ưu hóa thời gian vào thử nghiệm giúp giảm chi phí và tăng hiệu quả.

Các ví dụ thực tế về phân tích tác động: https://viblo.asia/p/tai-sao-can-phai-phan-tich-tac-dong-trong-kiem-thu-phan-mem-mot-so-vi-du-thuc-te-phan-2-L4x5xgAqlBM

0