Kiểm thử rủi ro là một hướng tiếp cận kiểm thử giúp chúng ta có thể xử lý được việc nguồn nhân lực hạn chế. Nó cũng là một mô hình thích hợp được sử dụng trong một vài năm tới đây vì nó tập trung kiểm thử các tài nguyên mà chúng có thể tác động mạnh mẽ nhất như do ngân sách, do lịch trình chặt chẽ hay thậm chí là những rủi ro từ những tình huống bất người như COVID-19.

Dưới dây là một số những mẹo và ví dụ thực tế bạn có thể áp dụng kiểm thử rủi ro vào dự án của mình.

Kiểm thử rủi ro: Những điều cơ bản

Mọi dự án phần mềm đều thiết lập kế hoạch mục tiêu ngay từ đầu. Ví dụ như, thời gian phát triển dự án, thời gian kiểm thử và thời gian bàn giao sản phẩm,...

Rủi ro của một dự án phần mềm có thể rất khác nhau dựa trên các tính năng của sản phẩm đang được phát triển. Ví dụ rủi ro của phần mềm thiết bị y tế sẽ khác biệt so với rủi ro của phần mềm mua sắm trực tuyến

Rủi ro, cả bên trong và bên ngoài đều có thể ảnh hưởng đến mục tiêu của bạn. Các sự kiện không lường trước được có thể gây ra rủi ro mới cho dự án có thể biểu hiện theo những cách khác nhau. Chẳng hạn, nếu một lập trình viên cứng, nắm được rất nhiều logic của dự án quyết định rời đi khi dự án đang phát triển, sẽ mất thêm thời gian để người mới tìm hiểu nắm được logic của dự án để thay thế.

Rủi ro cũng sẽ thay đổi tùy thuộc vào loại phát triển. Nếu code là quá phức tạp, liên quan đến nhiều component quan trọng của phần mềm, điều đó cũng sẽ gây ra nhiều rủi ro hơn. Nếu dự án có thay đổi về các chức năng không quan trọng, bao gồm những code đã hiểu rõ logic hoặc được code bởi những lập trình viên có nhiều kinh nghiệm thì rủi ro sẽ thấp hơn.

COVID-19 là một rủi ro thú vị để doanh nghiệp xem xét. Trước tháng 12 năm 2019, hầu như nó không được biết đến và sẽ không phải là một yếu tố trong bất kỳ dự án phần mềm nào. Tuy nhiên, do virus đã chuyển sang trạng thái đại dịch, nên bây giờ đây là điều cần phải xem xét khi lập kế hoạch nguồn nhân lực và lịch trình dự án. Nó có ảnh hưởng đến khả năng làm việc nhóm trong văn phòng không? Nó sẽ lây nhiễm ra các thành viên của đội, khiến họ bỏ lỡ thời gian? Lập kế hoạch cho một ẩn số như vậy là khó khăn, nhưng khi rủi ro xảy ra, chúng có khả năng ảnh hưởng đáng kể đến nhóm của bạn để đáp ứng được các mục tiêu.

Cuối cùng, điều quan trọng là chỉ xem xét những rủi ro liên quan đến dự án phần mềm. Nó dễ dàng bị cuốn vào trí tưởng tượng của một ai đó, bao gồm các rủi ro rất khó xảy ra hoặc chỉ liên quan gián tiếp đến dự án phần mềm. Một số rủi ro chỉ là quá khó để dự đoán hoặc không liên quan đến dự án của bạn để tăng thêm giá trị cho dự án lập kế hoạch dựa trên rủi ro.

Kiểm thử dựa trên rủi ro là gì?

Kiểm thử dựa trên rủi ro (RBT) là một phương pháp kiểm thử sử dụng để đánh giá rủi ro từ đó giúp phân bổ nguồn nhân lực kiểm thử hợp lý. Mục đích là để phân bổ nguồn nhân lực hiệu quả tránh gây ra các rủi ro lớn nhất cho tổ chức và tránh những tác động như chất lượng kém hay sự không hài lòng của khách hàng và thương hiệu.

Kiểm thử dựa trên rủi ro cần xem xét 2 khía cạnh:

• Khả năng xảy ra lỗi của phần mềm
• Ảnh hưởng của lỗi đó đến tổ chức như thế nào? Codebase hiếm khi đồng nhất. Các ứng dụng được xây dựng bằng cách tích hợp code từ nhiều developer có chuyên môn và kinh nghiệm khác nhau. Code có thể bao gồm thư viện mã nguồn mở. Tất cả các yếu tố này ảnh hưởng đến khả năng xảy ra lỗi.

Từ góc độ tác động, khả năng một lỗi sẽ ảnh hưởng đến trải nghiệm của người dùng như thế nào? Liệu tác động đó sẽ gây phiền toái hay khiến họ không hoàn thành nhiệm vụ quan trọng? Người dùng có thể gọi hỗ trợ và nêu vấn đề gặp phải với người quản lý, với nhà phát triển và cách khắc phục nhanh không? Sử dụng kiểm thử rủi ro để giúp tập trung hầu hết nỗ lực của bạn vào các vùng ứng dụng có nhiều khả năng gây ra lỗi và có tác động lớn nhất.

Những thay đổi

Số lượng thay đổi của một tập tin hoặc mô-đun đã được phát triển hoặc của một chức năng nào đó của ứng dụng mà các nhà phát triển thay đổi thường xuyên hơn sẽ có nhiều khả năng gây ra lỗi hơn là những chức năng mà gần như không bao giờ thay đổi.

Ví dụ như một ứng dụng thương mại điện tử đã được phát hành trong vài năm trước. Nhóm phát triển đã thực hiện thay đổi thường xuyên đối với các dịch vụ, giới thiệu các tính năng mới và thử các thử nghiệm để tăng mua hàng. Các chức năng bị ảnh hưởng từ code thay đổi thường xuyên sẽ có nhiều khả năng gây ra lỗi. Khi thay đổi diễn xa thường xuyên, lập kế hoạch dựa trên rủi ro nên đề xuất kiểm thử bổ sung kiểm thử đơn vị, kiểm thử tích hợp nhiền hơn, thường xuyên hơn và thử nghiệm giao diện người dùng nhiều hơn, ….

Độ phức tạp

Cuối cùng, độ phức tạp cũng là một thành phần quan trọng trong xác suất tìm thấy lỗi. Nói một cách đơn giản, code càng phức tạp càng có nhiều khả năng có lỗi. Điều ngược lại cũng đúng: code càng đơn giản thì càng ít có khả năng chứa lỗi.

Vậy làm thế nào để có thể đo được độ phức tạp của code? Mặc dù có nhiều số liệu bạn có thể sử dụng, nhưng bạn khó có thể tìm ra một số liệu tối ưu hơn cách tính độ phức tạp theo chu kỳ. Nói tóm lại, độ phức tạp chu kỳ là số lượng đường dẫn có thể có trong một phương thức hoặc hàm. Con số đó xác định số lượng tối thiểu các trường hợp kiểm tra mà bạn cần để kiểm tra một chức năng kỹ lưỡng. Ngoài ra, mã có độ phức tạp chu kỳ cao có thể khó đọc hơn và lý do, điều này có thể làm tăng số lượng lỗi.

Thông qua kiểm thử rủi ro

Bây giờ chúng ta đã hiểu rõ hơn về RBT và các loại rủi ro có thể ảnh hưởng đến sản phẩm phần mềm của bạn, dưới đây là một số bước để bắt đầu triển khai RBT trong tổ chức của bạn.

Trước tiên hãy đánh giá rủi ro về ứng dụng của bạn, tạo một file tài liệu trong đó liệt kê những component phức tạp. Có thể bắt đầu với một danh sách quản lý gồm 10 đến 15 chức năng chính. Tiếp theo, hãy xem mức độ quan trọng, độ phức tạp của từng chức năng với mức độ ưu tiên từ cao, trung bình và thấp.

Tiếp theo, bạn nên liệt kê phạm vi kiểm tra đầy đủ cho tất cả các chức năng có mức độ ưu tiên cao và trung bình. Điều quan trọng cần lưu ý là không chú trọng vào một loại kiểm thử cụ thể nào. Rủi ro phải được giải quyết với những kiểm thử thích hợp (kiểm thử đơn vị, kiểm thử tích hợp,...)

Làm việc với quản lý dự án và đội phát triển sản phẩm để hiểu rõ hơn về những ảnh hưởng đến các chức năng chính và tác động của rủi ro đó.

Xây dựng kế hoạch kiểm thử của bạn, cân nhắc nhiều hơn về nguồn nhân lực để kiểm tra cho các chức năng có rủi ro cao nhất. Chức năng mới được phát triển có rủi ro cao sẽ đảm bảo nhiều người kiểm thử hơn. Ngược lại, nếu nhóm đang sửa đổi chức năng có rủi ro thấp của ứng dụng, effort kiểm thử của bạn sẽ thấp hơn. Nếu bạn là một người kiểm thử tốt, bạn có thể được phân bổ để xây dựng các trường hợp kiểm thử cho các chức năng có rủi ro cao

Học hỏi từ những nỗ lực của bạn, giao tiếp với nhóm của bạn và điều chỉnh kế hoạch cho phù hợp. Bạn có thể cần thay đổi các đánh giá rủi ro của mình vì một người phát triển chính đã chuyển sang một dự án mới hoặc nhóm của bạn đang xây dựng một cái gì đó độc đáo và phức tạp. Bạn cũng có thể nhận ra rằng bạn có thể giảm rủi ro vì bạn đã xây dựng phạm vi kiểm tra mà bạn cần.

Kiểm thử khôn ngoan hơn

Mỗi năm trôi qua, các dự án phần mềm của chúng ta dường như ngày càng phức tạp hơn. Đồng thời, nguồn nhân lực ngày càng khan hiếm. Những thách thức mà chúng ta phải đối mặt là rất nhiều. Đó là lý do tại sao, khi nói đến kiểm thử phần mềm, chúng ta cần tiếp cận một cách thông minh hơn là chỉ kiểm tra mọi thứ. Không phải tất cả các đoạn code đều được tạo ra như nhau, không phải tất cả các rủi ro đều có khả năng như nhau và không phải tất cả các lỗi đều gây ra thiệt hại như nhau. Các tổ chức phần mềm phải tính đến các yếu tố này để đưa ra quyết định tốt hơn về cách phân bổ nguồn lực để kiểm tra hiệu quả hơn.

Nguồn: https://www.stickyminds.com/article/5-steps-getting-started-risk-based-testing