4.3 Risks Associated with Software

4.3 Risks Associated with Software Testing
Testing is inherently a risk-based activity. Exhaustive testing is impractical for most applications under development. Exceptions include applications that support very high risk processes, such as air traffic control, nuclear power generation station operations, defense systems, and so on.
It is the test manager’s responsibility to determine how to apply the test methodology to achieve the greatest level of confidence in the application under development. Risk is a major driver in the test planning activity. When conducting risk analysis, two major components are taken into consideration:
• The probability that the negative event will occur
• The potential loss or impactassociated with the event
The test manager is also responsible for identification of potential risks that might impact testing. Some of the primary testing risks include:
• Not Enough Training/Lack of Test Competency
• Us versus Them Mentality
• Lack of Test Tools
• Lack of Management Understanding and Support of Testing
• Lack of Customer and User Involvement
• Not Enough Schedule or Budget for Testing
• Over Reliance on Independent Testers
• Rapid Change
• Testers are in a Lose-Lose Situation
• Having to Say “No”
• Test Environment
• New technology
• New developmental processes
Risk analysis will determine the risks associated with the software being tested and performing the test process. Risk analysis should determine the magnitude of the risks, and prioritize them in importance. Test planning willthen consider those risks in developing the Test Plan.
4.3.1 Premature Release Risk
Premature release is defined asreleasing the software into production under the following conditions:
• The requirements were implemented incorrectly
• The test plan has not been completed
• Defects uncovered in testing have not been corrected
Some IT organizations at a high maturity level have what iscalled a “defect expectation.” This means that testers expecta certain quantity of defects based on the history of software developed using the software methodology. If testers fail to uncover the expected defect frequency they should be concerned about releasing the software.
The customer/user of software should expect operational problems if the software is released without completing the project or completing testing. These risks include the risks defined as software risks. The decision that the customer/user must make is, “Is the risk associated with premature release of software less than the risk of not releasing the software?”
In premature release of softwarethe testers should include in their report the most probable outcomes associated with premature release. For example if they could not test requirements A, B and C, the test report should indicate that the functioning of those requirements has not been validated and the user should be alert to potential incorrect processing associated with those three requirements.
4.4 Risk Analysis
The objective of performing risk analysis as part of test planning is to helpallocate limited test resources to those software components that pose the greatest risk to the organization. Testing is a process designed to minimize software risks. To make software testing most effective it is important to assure all the high risks associated with the software, will be tested first.

4.4.1 Risk Analysis Process
Performing risk analysis during test planning is a four-step process as follows:
1. Form the risk analysis team
2. Identify risks
3. Estimate the magnitude of the risk
4. Select testing priorities
4.4.1.1 Form the Risk Analysis Team
The key to a successful risk analysis is the establishment of the correct risk team, whose responsibility will be to identifyrisks and prioritize the use oftest resources. The objective is to reduce the risks to an acceptable level.
The risk team may be part of the requirements team, or part of the test team, or it may be a team specifically selected for the purpose of completing risk analysis. The team should be comprised of three to six members and at a minimum possess the following skills:
• Knowledge of the user application
• Understanding of risk concepts
• Ability to identify controls
• Familiarity with both application and information services risks
• Understanding of information services concepts and systems design
• Understanding of computeroperations procedures
The candidates included on the risk team should, ata minimum, includesomeone from the user area and any or all of the following:
• Software testing
• Risk consultant
• Project leader
4.4.1.2 Identify Risks
The objective of the risk team is first to identify the application-oriented, not environmental, risks associated with the application system. The risk team can use one of the following two methods of risk identification:
• Risk analysis scenario
In this method, the risk team “brainstorms” the potential application risks using their experience, judgment, and knowledge of the application area. It is important to have the synergistic effect of a group so that group members can challenge one another to develop a complete list of risks that are realistic for the application.
• Risk checklist
The risk team is provided with a list of the more common risks that occur in automated applications. From this list, the team selects those risks that are applicable to the application. In this method, the team needs fewer skills because the risk list provides the stimuli for the process, and the objective of the team is to determine which of the risks on the list are applicable to the application.
4.4.1.3 Estimate the Magnitude of the Risk
The magnitude of a risk can be determined by any of the following means:
• Intuition and Judgment
• Consensus
• Risk Formula
• Annual Loss Expectation (ALE) Estimation
• A Process for Estimating the Annual Loss Expectation (ALE)

The following six tasks should be used to estimate ALE.
1. Make a preliminary assessment of the loss.

2. Make a preliminary assessment of frequency using a frequency table of multiples of five as in Figure 4-3.

3. Calculate an ALE using the loss and frequency tables in Figure 4-2 and Figure 4-3.
4. Narrow the ALE by:
• Using multiple opinions to establish most likely ALE.
• Rank intangible elements (see Figure 4-4Preliminary Evaluation of Intangible Factors.)
• Assign monetary values to intangibles.
• Accumulate additional evidence, if needed.


Figure 4-4 Preliminary Evaluation of Intangible Factors

5. Make a post-analysis challenge of the decision.
6. Document the decision reached.
4.4.1.4 Select Testing Priorities
The risk team needs to rank the risks as an input to the testplanning process. Risks are normally ranked by the severity of the risk. However, other considerations may impact the prioritization such as:
• Compliance required to laws and regulations
• Impact on competitiveness
• Impact on ethics, values and image

Kết quả (Việt) 1:

4.3 rủi ro liên quan với kiểm thử phần mềmThử nghiệm vốn là một rủi ro dựa trên hoạt động. Kiểm tra đầy đủ là không thực tế cho hầu hết các ứng dụng đang được phát triển. Trường hợp ngoại lệ bao gồm các ứng dụng hỗ trợ quá trình rủi ro rất cao, chẳng hạn như kiểm soát không lưu, năng lượng hạt nhân thế hệ station hoạt động, Hệ thống phòng thủ, và như vậy.Đó là trách nhiệm của người quản lý kiểm tra để xác định làm thế nào để áp dụng các phương pháp thử nghiệm để đạt được mức độ lớn nhất của sự tự tin trong các ứng dụng đang được phát triển. Rủi ro là một trình điều khiển chính trong thử nghiệm kế hoạch hoạt động. Khi tiến hành phân tích rủi ro, hai thành phần chính được đưa vào xem xét: • Khả năng rằng các sự kiện tiêu cực sẽ xảy ra• Khả năng mất hoặc impactassociated với các sự kiệnNgười quản lý kiểm tra cũng có trách nhiệm xác định các rủi ro tiềm năng có thể tác động đến thử nghiệm. Một số rủi ro thử nghiệm chính bao gồm:• Không đủ đào tạo/thiếu khả năng thử nghiệm• Chúng tôi so với họ tâm lý• Thiếu kiểm tra công cụ• Thiếu sự hiểu biết quản lý và hỗ trợ của thử nghiệm• Thiếu của khách hàng và sự tham gia của người dùng• Không đủ lịch trình hoặc ngân sách để thử nghiệm• Qua sự phụ thuộc vào độc lập xét nghiệm• Thay đổi nhanh chóng• Xét nghiệm trong một tình huống mất-mất• Phải nói "Không"• Kiểm tra môi trường• Công nghệ mới• Quy trình phát triển mớiPhân tích rủi ro sẽ xác định các rủi ro liên quan với các phần mềm được thử nghiệm và thực hiện quá trình thử nghiệm. Phân tích rủi ro nên xác định tầm quan trọng của những rủi ro, và ưu tiên trong tầm quan trọng. Kiểm tra lập kế hoạch willthen xem xét những rủi ro trong việc phát triển các kế hoạch thử nghiệm.4.3.1 Phiên bản sớm rủi roPhát hành sớm là xác định asreleasing phần mềm vào sản xuất theo các điều kiện sau đây: • Các yêu cầu đã được thực hiện không chính xác• Kế hoạch thử nghiệm đã không được hoàn thành• Khuyết tật phát hiện trong thử nghiệm đã không được sửa chữaMột số tổ chức CNTT ở mức cao sự trưởng thành có iscalled những gì một "lỗi kỳ vọng." Điều này có nghĩa rằng thử nghiệm ồ nhất định số lượng lỗi dựa trên lịch sử của phần mềm phát triển bằng cách sử dụng phương pháp phần mềm. Nếu xét nghiệm không phát hiện ra tần số dự kiến lỗi họ cần được quan tâm về phát hành phần mềm.Khách hàng/người sử dụng của phần mềm sẽ hoạt động vấn đề nếu các phần mềm được phát hành mà không hoàn thành dự án hoặc hoàn thành thử nghiệm. Những rủi ro này bao gồm những rủi ro được xác định là phần mềm rủi ro. Quyết định khách hàng/người sử dụng phải làm là, "nguy cơ liên kết với các phiên bản sớm của phần mềm ít hơn nguy cơ không phát hành phần mềm?"Trong các phiên bản sớm của softwarethe thử nghiệm nên bao gồm trong báo cáo của họ những kết quả nhất có thể xảy ra liên quan đến phát hành sớm. Ví dụ: nếu họ không thể kiểm tra yêu cầu A, B và C, báo cáo thử nghiệm nên chỉ ra rằng các hoạt động của các yêu cầu không đã được kiểm chứng và người sử dụng nên là cảnh báo để xử lý không đúng tiềm năng kết hợp với những yêu cầu ba.4.4 phân tích rủi ro Mục tiêu thực hiện phân tích rủi ro như một phần của thử nghiệm kế hoạch để helpallocate giới hạn kiểm tra nguồn lực để những thành phần phần mềm gây nguy cơ lớn nhất đối với tổ chức. Thử nghiệm là một quá trình được thiết kế để giảm thiểu rủi ro phần mềm. Để thực hiện kiểm thử phần mềm hiệu quả nhất, nó là quan trọng để đảm bảo tất cả các rủi ro cao kết hợp với phần mềm, sẽ được kiểm tra đầu tiên. 4.4.1 nguy cơ phân tích quá trìnhThực hiện phân tích rủi ro trong thời gian thử nghiệm kế hoạch là một quá trình bốn bước như sau:1. tạo thành nhóm nghiên cứu phân tích rủi ro2. xác định các rủi ro3. dân số ước tính cường độ của rủi ro4. chọn thử nghiệm ưu tiên4.4.1.1 tạo thành nhóm nghiên cứu phân tích rủi roChìa khóa để phân tích rủi ro thành công là thành lập đội rủi ro chính xác, có trách nhiệm sẽ để identifyrisks và ưu tiên cho việc sử dụng tài nguyên oftest. Mục tiêu là để giảm bớt những rủi ro đến một mức độ chấp nhận được.Đội rủi ro có thể là một phần của đội yêu cầu, hoặc một phần của nhóm nghiên cứu thử nghiệm, hoặc nó có thể là một đội đặc biệt chọn cho các mục đích hoàn thành phân tích rủi ro. Nhóm nghiên cứu nên được bao gồm 3-6 thành viên và ít có các kỹ năng sau đây:• Kiến thức về ứng dụng người dùng• Hiểu biết về khái niệm rủi ro• Có khả năng để xác định điều khiển• Quen với cả hai ứng dụng và thông tin dịch vụ rủi ro• Hiểu biết về thông tin dịch vụ thiết kế khái niệm và hệ thống• Hiểu biết về thủ tục computeroperationsCác ứng cử viên bao gồm nhóm nguy cơ nên, ata tối thiểu, includesomeone từ khu vực người sử dụng và bất kỳ hoặc tất cả những điều sau đây:• Kiểm thử phần mềm• Rủi ro tư vấn• Dự án lãnh đạo4.4.1.2 xác định rủi roMục tiêu của nhóm nghiên cứu nguy cơ là đầu tiên xác định theo định hướng ứng dụng, không phải về môi trường, rủi ro liên quan hệ thống ứng dụng. Nhóm nghiên cứu nguy cơ có thể sử dụng một trong hai phương pháp sau đây xác định rủi ro:• Kịch bản phân tích rủi roTrong phương pháp này, nhóm nguy cơ "brainstorms" những rủi ro tiềm năng ứng dụng bằng cách sử dụng kinh nghiệm, bản án và kiến thức về khu vực ứng dụng của họ. Nó là quan trọng để có tác dụng hiệp đồng của một nhóm để nhóm thành viên có thể thách thức lẫn nhau để phát triển một danh sách đầy đủ của các rủi ro được thực tế cho các ứng dụng.• Rủi ro danh sách kiểm traĐội rủi ro cung cấp một danh sách những rủi ro phổ biến hơn xảy ra trong các ứng dụng tự động. Từ danh sách này, các đội chọn những rủi ro được áp dụng cho các ứng dụng. Trong phương pháp này, các đội cần kỹ năng ít hơn vì danh sách nguy cơ cung cấp các kích thích cho quá trình, và mục tiêu của nhóm nghiên cứu là để xác định các rủi ro trong danh sách được áp dụng cho các ứng dụng.4.4.1.3 ước tính cường độ của rủi roTầm quan trọng của một nguy cơ có thể được xác định bởi bất kỳ phương tiện sau đây:• Trực giác và bản án• Sự đồng thuận• Rủi ro công thức• Hàng năm mất dự toán kỳ vọng (ALE)• Một quá trình để ước tính kỳ vọng mất hàng năm (ALE)Các tác vụ sau sáu nên được sử dụng để ước tính ALE.1. thực hiện một đánh giá sơ bộ của sự mất mát. 2. thực hiện một đánh giá sơ bộ của tần số bằng cách sử dụng một bảng tần số của các bội số của năm như trong hình 4-3. 3. tính toán một ALE bằng cách sử dụng các bảng mất và tần số trong hình 4-2 và hình 4-3.4. thu hẹp ALE bởi:• Sử dụng nhiều ý kiến để thiết lập khả năng đặt rượu bia.Yếu tố vô hình • xếp hạng (xem hình 4-4Preliminary đánh giá của vô hình yếu tố).• Chỉ định giá trị tiền tệ cho intangibles.• Tích lũy thêm bằng chứng, nếu cần thiết. Đánh giá sơ bộ hình 4-4 yếu tố vô hình 5. làm cho một thách thức Post-phân tích của các quyết định.6. tài liệu quyết định đến.4.4.1.4 chọn thử nghiệm ưu tiênNhóm nguy cơ cần để xếp hạng những rủi ro như một đầu vào cho quá trình testplanning. Rủi ro thường được xếp hạng theo mức độ nghiêm trọng của nguy cơ. Tuy nhiên, cân nhắc khác có thể tác động ưu tiên chẳng hạn như:• Tuân thủ yêu cầu pháp luật và các quy định• Tác động đến khả năng cạnh tranh• Các tác động về đạo Đức, giá trị và hình ảnh

Kết quả (Việt) 2:

4.3 Rủi ro Kết hợp với kiểm thử phần mềm
kiểm tra vốn là một hoạt động dựa trên rủi ro. Thử nghiệm đầy đủ là không thực tế đối với hầu hết các ứng dụng được phát triển. Ngoại lệ bao gồm các ứng dụng có hỗ trợ các quy trình rủi ro rất cao, chẳng hạn như kiểm soát không lưu, hoạt động trạm phát điện hạt nhân, hệ thống phòng thủ, và như vậy.
Đó là trách nhiệm của người quản lý kiểm tra để xác định làm thế nào để áp dụng các phương pháp thử nghiệm để đạt được mức độ cao nhất của sự tự tin trong các ứng dụng được phát triển. Rủi ro là một động lực chính trong các hoạt động lập kế hoạch kiểm tra. Khi tiến hành phân tích rủi ro, hai thành phần chính được đưa ra xem xét:
• Xác suất mà các sự kiện tiêu cực sẽ xảy ra
• Các khả năng mất hoặc impactassociated với sự kiện
người quản lý kiểm tra cũng có trách nhiệm xác định các rủi ro tiềm tàng mà có thể ảnh hưởng đến xét ​​nghiệm. Một số rủi ro kiểm nghiệm chính bao gồm:
• Không Đủ Đào tạo / Thiếu Kiểm tra năng lực
• hệ so với Them Tâm
• Thiếu các công cụ thử nghiệm
• Thiếu hiểu biết quản lý và Hỗ trợ kiểm tra
• Thiếu khách hàng và tài khoản Tham Gia
• Không Đủ Schedule hoặc ngân sách cho Thử nghiệm
• Hơn Reliance trên Independent Testers
• Thay đổi nhanh
• Testers đang ở trong một trạng Thua-Thua
• Phải Nói "Không"
• Môi trường thử nghiệm
• Công nghệ mới
• phát triển các quy trình mới
phân tích rủi ro sẽ xác định các rủi ro liên quan với các phần mềm đang được thử nghiệm và thực hiện quá trình thử nghiệm. Phân tích rủi ro nên xác định độ lớn của những rủi ro, và thứ tự ưu tiên quan trọng. Kiểm tra quy hoạch willthen xem xét những rủi ro trong việc phát triển các kế hoạch kiểm tra.
4.3.1 Phát hành sớm rủi ro
phát hành sớm được định nghĩa asreleasing các phần mềm vào sản xuất theo các điều kiện sau đây:
• Các yêu cầu đã được thực hiện không đúng cách
• Các kế hoạch kiểm tra đã không được hoàn thành
• Phế phát hiện tại thử nghiệm đã không được sửa chữa
Một số tổ chức CNTT ở mức độ trưởng thành cao có gì iscalled một "kỳ vọng khiếm khuyết." Điều này có nghĩa là kiểm thử mong đợi của số lượng nhất định các khuyết tật dựa trên lịch sử của phần mềm được phát triển bằng cách sử dụng phương pháp phần mềm. Nếu kiểm tra không phát hiện ra các tần số khiếm khuyết dự kiến họ nên quan tâm về việc phát hành phần mềm.
Các khách hàng / người dùng của phần mềm nên mong đợi các vấn đề hoạt động nếu phần mềm được phát hành mà không hoàn thành dự án hoặc hoàn thành thử nghiệm. Những rủi ro này bao gồm những rủi ro được xác định là rủi ro phần mềm. Các quyết định mà khách hàng / người sử dụng phải làm là, "Có phải các rủi ro liên quan đến phát hành sớm các phần mềm ít hơn so với nguy cơ không phát hành các phần mềm?"
Trong phiên bản sớm của softwarethe xét nghiệm nên bao gồm trong báo cáo các kết quả có thể xảy ra nhất liên quan đến sinh non phát hành. Ví dụ nếu họ không thể kiểm tra các yêu cầu A, B và C, các báo cáo thử nghiệm nên chỉ ra rằng các hoạt động của những yêu cầu chưa được xác nhận và người dùng nên cảnh giác với chế biến không đúng tiềm năng liên kết với ba yêu cầu.
4.4 Phân tích rủi ro
Mục tiêu thực hiện phân tích rủi ro như là một phần của kế hoạch kiểm tra là để helpallocate nguồn thử nghiệm giới hạn cho những thành phần có rủi ro cao nhất cho tổ chức. Thử nghiệm là một quá trình được thiết kế để giảm thiểu rủi ro phần mềm. Để làm cho thử nghiệm phần mềm hiệu quả nhất, điều quan trọng để đảm bảo tất cả các rủi ro liên quan cao với phần mềm là, sẽ được thử nghiệm đầu tiên. Quy trình phân tích rủi ro 4.4.1 Thực hiện phân tích rủi ro trong quá trình lập kế hoạch kiểm tra là một quy trình bốn bước như sau: 1. Hình thành các nhóm phân tích nguy cơ 2. Xác định rủi ro 3. Ước tính độ lớn của các rủi ro 4. Chọn ưu tiên thử nghiệm 4.4.1.1 Mẫu Nhóm Phân tích rủi ro Chìa khóa để phân tích rủi ro thành công là việc thành lập các nhóm nguy cơ chính xác, có trách nhiệm sẽ identifyrisks và ưu tiên sử dụng nguồn tài nguyên oftest. Mục tiêu là để giảm thiểu rủi ro đến mức có thể chấp nhận được. Các nhóm nguy cơ có thể là một phần của đội bóng yêu cầu, hoặc là một phần của nhóm thử nghiệm, hoặc nó có thể là một nhóm được lựa chọn đặc biệt cho mục đích hoàn phân tích rủi ro. Các đội nên được bao gồm 3-6 thành viên và tối thiểu có các kỹ năng sau đây: • Kiến thức về các ứng dụng người dùng • Hiểu biết về các khái niệm rủi ro • Khả năng nhận dạng điều khiển • Quen thuộc với cả hai ứng dụng và dịch vụ thông tin rủi ro • Hiểu biết về các khái niệm dịch vụ thông tin và các hệ thống thiết kế • Hiểu biết về thủ tục computeroperations Các ứng cử viên bao gồm trong nhóm nguy cơ nên, ata tối thiểu, includesomeone từ các khu vực người dùng và bất kỳ hoặc tất cả những điều sau đây: • Kiểm thử phần mềm • Tư vấn rủi ro • Phụ trách dự án 4.4.1.2 Xác định rủi ro Mục tiêu của các nhóm có nguy cơ là người đầu tiên xác định hướng ứng dụng, chứ không phải môi trường, rủi ro liên quan với các hệ thống ứng dụng. Các nhóm nguy cơ có thể sử dụng một trong hai phương pháp sau đây xác định rủi ro: • Kịch bản Phân tích rủi ro Trong phương pháp này, nhóm nghiên cứu nguy cơ "góp trí tuệ" các ứng dụng tiềm năng rủi ro sử dụng kinh nghiệm của họ, sự phán xét, và kiến thức về các lĩnh vực ứng dụng. Điều quan trọng là phải có tác dụng hiệp đồng của một nhóm để các thành viên nhóm có thể thách thức lẫn nhau để phát triển một danh sách đầy đủ các rủi ro đó là thực tế cho các ứng dụng. • Rủi ro danh mục Các nhóm nguy cơ được cung cấp với một danh sách các rủi ro phổ biến hơn mà xảy ra trong các ứng dụng tự động. Từ danh sách này, nhóm nghiên cứu lựa chọn những rủi ro có thể áp dụng cho các ứng dụng. Trong phương pháp này, đội bóng cần những kỹ năng ít hơn bởi vì trong danh sách có nguy cơ cung cấp các kích thích cho quá trình này, và mục tiêu của nhóm nghiên cứu là xác định các rủi ro trong danh sách được áp dụng cho các ứng dụng. 4.4.1.3 Ước tính Tầm quan trọng của Rủi ro Mức độ rủi ro có thể được xác định bằng bất kỳ phương tiện sau đây: • Trực giác và Judgment • Đồng thuận • Công thức rủi ro • Mất vọng hàng năm (ALE) Dự toán • Tiến trình Ước tính Expectation Mất hàng năm (ALE) Sáu nhiệm vụ sau đây nên được sử dụng để ước tính ALE. 1. Thực hiện một đánh giá sơ bộ của sự mất mát. 2. Thực hiện một đánh giá sơ bộ về tần số sử dụng một bảng tần số là bội số của năm như trong hình 4-3. 3. Tính toán một ALE sử dụng các bảng mất và tần số trong Hình 4-2 và Hình 4-3. 4. Thu hẹp ALE bởi: • Sử dụng nhiều ý kiến để thiết lập có khả năng nhất ALE. • Rank yếu tố vô hình (xem hình 4-4Preliminary đánh giá của các yếu tố phi vật thể.) • Gán giá trị tiền tệ để tài sản vô hình. • Tích lũy bằng chứng bổ sung, nếu cần thiết. Hình 4-4 Đánh giá sơ bộ của các yếu tố vô hình 5. Thực hiện một thách thức bài phân tích của các quyết định. 6. Tài liệu các quyết định đạt được. 4.4.1.4 Chọn Testing ưu tiên Các nhóm nguy cơ cần để xếp hạng các rủi ro như là một đầu vào cho quá trình testplanning. Rủi ro thường được xếp theo mức độ nghiêm trọng của các rủi ro. Tuy nhiên, mối quan tâm khác có thể tác động đến các ưu tiên như: • Tuân thủ yêu cầu pháp luật và các quy định • Tác động đến khả năng cạnh tranh • Tác động về đạo đức, các giá trị và hình ảnh