Kiểm thử dựa trên rủi ro bắt đầu với phân tích rủi ro sản phẩm. Một kỹ thuật để phân tích rủi ro là đọc kỹ đặc tả yêu cầu, đặc tả thiết kế, tài liệu người dùng và các mục khác. Một kỹ thuật khác là động não với nhiều bên liên quan của dự án. Một cách khác nữa là một chuỗi các buổi gặp mặt trực tiếp hoặc theo nhóm nhỏ với các chuyên gia nghiệp vụ và công nghệ trong công ty.
Một số người sử dụng tất cả các kỹ thuật này khi họ có thể. Đối với chúng tôi, cách tiếp cận dựa trên nhóm có sự tham gia của các bên liên quan chính và các chuyên gia được ưu tiên hơn so với cách tiếp cận hoàn toàn dựa trên tài liệu, vì cách tiếp cận theo nhóm dựa trên kiến thức, trí tuệ và hiểu biết sâu sắc của toàn bộ nhóm để xác định những gì cần kiểm thử và mức độ kiểm thử.
Trong khi có thể thực hiện phân tích rủi ro bằng cách hỏi, “Chúng ta nên lo lắng về điều gì?” thông thường cần phải có nhiều cấu trúc hơn để tránh bỏ sót. Một cách để cung cấp cấu trúc đó là tìm kiếm những rủi ro cụ thể trong các loại rủi ro sản phẩm cụ thể. Bạn có thể xem xét rủi ro trong các lĩnh vực chức năng, địa phương hóa, khả năng sử dụng, độ tin cậy, hiệu suất và khả năng hỗ trợ.
Ngoài ra, bạn có thể sử dụng các đặc tính chất lượng và đặc tính phụ từ ISO 9126 (được giới thiệu trong Chương 1), vì mỗi đặc tính phụ quan trọng đều có rủi ro rằng hệ thống có thể gặp sự cố trong khu vực đó. Bạn có thể có một danh sách kiểm thử các rủi ro điển hình hoặc trong quá khứ cần được xem xét. Bạn cũng có thể muốn xem lại các kiểm thử không thành công và các lỗi mà bạn tìm thấy trong bản phát hành trước hoặc một sản phẩm tương tự. Những danh sách và phản ánh này dùng để chạy bộ nhớ, buộc bạn phải suy nghĩ về các loại rủi ro cụ thể, cũng như giúp bạn cấu trúc tài liệu về các rủi ro của sản phẩm.
Khi nói về những rủi ro cụ thể, chúng tôi muốn nói đến một loại lỗi hoặc lỗi cụ thể có thể xảy ra. Ví dụ: nếu bạn đang kiểm thử tiện ích máy tính đi kèm với Microsoft Windows, thì bạn có thể xác định “tính toán sai” là một rủi ro cụ thể trong danh mục chức năng. Tuy nhiên, việc này quá rộng. Xem xét phép cộng không đúng. Đây là một loại lỗi có tác động lớn, vì tất cả những người sử dụng máy tính đều sẽ thấy nó. Điều đó là không thể, vì phép cộng không phải là một thuật toán phức tạp. Ngược lại với một phép tính sin không chính xác. Đây là một loại khiếm khuyết có tác động thấp, vì ít người sử dụng hàm sin trên máy tính Windows. Tuy nhiên, nó có nhiều khả năng bị lỗi hơn vì các hàm sin khó tính toán.
Sau khi xác định các hạng mục rủi ro, nếu có thể, bạn và các bên liên quan nên xem lại danh sách để chỉ định khả năng xảy ra các vấn đề và tác động của các vấn đề liên quan đến từng vấn đề. Có nhiều cách để thực hiện việc phân bổ khả năng và tác động này. Bạn có thể làm điều này với tất cả các bên liên quan cùng một lúc. Bạn có thể yêu cầu BA xác định tác động và những người làm kỹ thuật xác định khả năng xảy ra, sau đó hợp nhất các quyết định. Dù bằng cách nào, lý do để xác định rủi ro trước và sau đó đánh giá mức độ của chúng là do các rủi ro có liên quan đến nhau.
Các thang đo được sử dụng để đánh giá khả năng xảy ra và tác động khác nhau. Một số người đánh giá chúng cao, trung bình và thấp. Một số sử dụng thang điểm 1-10. Vấn đề với thang điểm 1-10 là thường rất khó để phân biệt điểm 2 với điểm 3 hoặc điểm 7 với điểm 8, trừ khi sự khác biệt giữa mỗi điểm được xác định rõ ràng. Thang điểm năm (rất cao, cao, trung bình, thấp và rất thấp) có xu hướng hoạt động tốt.
Tuy nhiên, với hai cách phân loại mức độ rủi ro, khả năng xảy ra và tác động lại gặp một vấn đề: Chúng ta cần một xếp hạng rủi ro tổng hợp, duy nhất để hướng dẫn nỗ lực kiểm thử. Như với thang đánh giá, thực tiễn khác nhau. Một cách tiếp cận là chuyển đổi từng phân loại rủi ro thành một số và sau đó cộng hoặc nhân các số để tính toán số ưu tiên rủi ro. Ví dụ: giả sử một rủi ro cụ thể có khả năng xảy ra cao và tác động trung bình. Số ưu tiên rủi ro khi đó sẽ là 6 (2 nhân 3).
Được trang bị số ưu tiên rủi ro, giờ đây chúng ta có thể quyết định các tùy chọn giảm thiểu rủi ro khác nhau có sẵn cho mình. Có thể sử dụng chương trình đào tạo chính quy cho các lập trình viên hoặc BA, dựa vào đào tạo chéo và đánh giá hay cho rằng họ đã biết đủ? Có thể thực hiện kiểm thử theo chiều rộng, kiểm thử lướt qua hoặc không kiểm thử gì cả? Chúng ta có nên đảm bảo kiểm thử đơn vị và kiểm thử hệ thống về rủi ro này hay không? Những tùy chọn này và nhiều tùy chọn khác có sẵn.
Khi thực hiện quy trình này, hãy đảm bảo bạn nắm bắt được thông tin chính trong tài liệu. Chúng ta không thích tài liệu thừa nhưng lượng thông tin này đơn giản là không thể quản lý được trong đầu bạn. Một bảng nhẹ như bảng được trình bày trong Bảng 5.2 được đề xuất.
Hãy kết thúc phần này với hai mẹo nhanh về phân tích rủi ro sản phẩm. Đầu tiên, hãy nhớ xem xét cả khả năng xảy ra và tác động. Mặc dù nó có thể khiến bạn cảm thấy mình giống như một anh hùng khi tìm ra nhiều lỗi, nhưng kiểm thử cũng là để xây dựng niềm tin vào các chức năng chính. Chúng ta cần kiểm thử những thứ có thể sẽ không bị lỗi nhưng sẽ là thảm họa nếu chúng xảy ra.
Thứ hai, các phân tích rủi ro (đặc biệt là những phân tích ban đầu) là những phỏng đoán có cơ sở. Đảm bảo rằng bạn theo dõi và xem xét lại phân tích rủi ro tại các mốc quan trọng của dự án.
Ví dụ: nếu bạn đang theo mô hình chữ V (V-model), bạn có thể thực hiện phân tích ban đầu trong giai đoạn yêu cầu, sau đó xem xét và sửa đổi nó ở cuối giai đoạn thiết kế và triển khai, cũng như trước khi bắt đầu kiểm thử đơn vị, kiểm thử tích hợp , và kiểm nghiệm hệ thống. Chúng tôi cũng khuyên bạn nên xem lại phân tích rủi ro trong quá trình kiểm thử. Bạn có thể thấy rằng bạn đã phát hiện ra những rủi ro mới hoặc thấy rằng một số rủi ro không nguy hiểm như bạn nghĩ và tăng sự tự tin của bạn trong phân tích rủi ro
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
