소프트웨어 테스트에서의 프로젝트 위험 분석 및 완화
토마스 해밀턴
⚡ 스마트 요약
테스트 관리에서의 프로젝트 위험 분석은 일정, 예산 또는 품질에 차질을 초래할 수 있는 위협 요소를 식별, 평가 및 완화하는 것을 목표로 합니다. Less이 문서에서는 3단계 위험 분석 워크플로, 프로젝트 및 제품 위험, 영향 확률 매트릭스, 완화 전략 등을 다룹니다. Guru99 은행 사례 연구.
위험 분석이란 무엇입니까?
위험은 바람직하지 않은 사건이 발생할 확률입니다.
소프트웨어 엔지니어링의 위험 분석은 귀하와 관련된 위험을 분석하는 프로세스입니다. 지원 계획.
프로젝트의 성공을 위해서는 프로젝트 시작 전에 위험을 식별하고 해당 솔루션을 결정해야 합니다. 소프트웨어 엔지니어링의 위험 식별은 초기 단계에서 예상되는 위험을 식별하는 데 도움이 됩니다.
이 튜토리얼에서는 사례 연구를 통해 테스트 관리 프로세스의 첫 번째 단계인 위험 분석 및 솔루션을 알아봅니다.
이 주제에서는 사례 연구를 통해 테스트 관리 프로세스의 첫 번째 단계인 소프트웨어 테스팅 및 솔루션의 위험 분석을 살펴보겠습니다.
테스트 중인 애플리케이션은 https://demo.guru99.com/V4/, 소프트웨어 요구 사항 사양을 참조할 수 있습니다. 여기에서 확인하세요.
The Guru99 은행은 두 가지 역할을 수행할 것입니다.
- 매니저
- 빠른
다음 기능/모듈은 이 두 가지 다른 역할에 사용할 수 있습니다.
다음은 웹사이트를 간략히 둘러보는 것입니다.
요구 사항 문서를 읽은 후 웹 사이트에 너무 많은 내용이 있다는 것을 깨달았을 것입니다. 기능의 복잡한 시나리오.
상황은 이렇습니다 –
- The Guru99 은행 웹사이트 개발은 이미 완료되었고, 이제 테스트 단계에 들어갑니다. 안타깝게도 요구사항 정의 단계에 참여하지 못하셨네요.
- 당신의 상사는 당신이 테스트를 완료하기를 원합니다. 한달 제한된 예산으로만 가능하지만 큰 품질.
- 숙련된 엔지니어인 팀원이 알려줍니다.
- 이런 경우에는 어떻게 해야 합니까?
A) 큰 문제인 것 같습니다. 우리는 A를 상대해야 해SAP!!!
B) 상관없어요. 우리는 지금 당장 일을 시작해야 합니다.
- 프로젝트가 엉망이어서 모든 리소스와 시간이 소요되었습니다. 직원의 작업량이 급격히 증가하여 스트레스와 과부하를 느낍니다.
- – 당신의 프로젝트가 지연되어 상사에게 약속한 대로 정해진 마감일에 제품을 출시할 수 없었습니다. 팀원이 말했듯이, 이 프로젝트의 일정은 현재 리소스 할당에 비해 너무 촉박합니다.
위의 예는 중요성 테스트 관리에서의 위험 분석.
위험 완화는 다음과 같은 이점을 제공합니다.
위의 예에서 언급된 위험은 프로젝트에서 발생할 수 있는 많은 잠재적 위험 중 하나일 뿐입니다. 이를 식별하고 처리 결정을 내려야 합니다.SAP!!! 따라서 해당 예에서 올바른 조치는 다음과 같습니다. 액션 A.
따라서 테스트의 위험 분석은 중요합니다
위험 분석은 어떻게 수행하나요?
3단계 과정이에요
- 위험 식별
- 식별된 각 위험의 영향 분석
- 식별 및 분석된 위험에 대한 대응 조치
1단계) 위험 식별
소프트웨어 제품에서는 위험을 식별하고 2가지 유형으로 분류할 수 있습니다.
프로젝트 리스크
프로젝트 위험은 다음과 같이 정의될 수 있습니다. 불확실한 프로젝트 진행에 영향을 미칠 수 있는 이벤트 또는 활동. 영향은 긍정적인 or 부정 프로젝트 목표 달성 전망에 영향을 미칩니다.
프로젝트 위험에는 기본적으로 3가지 범주가 있습니다.
조직적 위험
이는 귀하와 관련된 위험입니다. 인적 자원 또는 테스트 팀. 예를 들어, 프로젝트에서 기술적으로 숙련된 구성원이 부족하면 위험합니다. 프로젝트를 제 시간에 완료할 만큼 충분한 인력이 없는 것도 또 다른 위험입니다.
조직의 위험을 식별하려면 몇 가지 질문 목록을 만들고 스스로 대답해야 합니다. 다음은 몇 가지 추천 질문입니다.
A) 예
나) 아니오
A) 예
나) 아니오
A) 예
나) 아니오
위의 모든 질문에 답하면 프로젝트에 영향을 미칠 수 있는 잠재적 위험을 쉽게 식별할 수 있습니다.
기술적 위험
기술적 위험은 테스트되지 않은 엔지니어링, 잘못된 테스트 절차 등과 같은 기술 프로세스를 실행하는 동안 발생하는 손실 가능성입니다. 기술적 위험의 예는 다음과 같습니다.
- 이 프로젝트의 작업은 은행 웹사이트를 테스트하는 것입니다. 실제 비즈니스 환경을 반영하는 적절한 테스트 환경을 설정해야 합니다. 만약 테스트 환경 제대로 설정되지 않으면 제품이 지원 올바르게 테스트되고 많은 결함 감지되지 않습니다.
비즈니스 위험
위험에는 외부 실재. 당신의 회사, 당신의 고객으로부터 올 수 있는 위험이지만 지원 귀하의 프로젝트에서.
다음 그림은 사업상 위험의 예를 보여줍니다.
이러한 경우 테스트 관리자는 다음과 같은 위험을 처리할 수 있는 솔루션을 찾아야 합니다.
- 세트 우선 테스트 단계에서는 웹사이트의 주요 기능을 테스트하는 데 중점을 둡니다.
- 활용 테스트 생산성을 높이는 테스트 도구
- 신청 프로세스 개선 관리 노력을 줄이기 위해.
제품 위험
제품 위험 시스템이나 소프트웨어가 고객, 사용자 또는 이해관계자의 기대를 충족하지 못할 가능성이 있습니다. 테스트 계획의 이 위험은 다음과 관련이 있습니다. 기능 성능 문제, 보안 문제, 충돌 시나리오 등과 같은 제품의
다음은 몇 가지 제품 위험의 예입니다.
- 소프트웨어가 일부를 건너뜁니다. 키 고객이 사용자 '에서 지정한 기능
요구 사항 - 소프트웨어는 신뢰할 수없는 그리고 자주 실패 작동합니다.
- 소프트웨어가 사용자 또는 소프트웨어를 사용하는 회사에 금전적 또는 기타 피해를 입히는 방식으로 작동하지 않습니다.
- 소프트웨어에 보안, 신뢰성, 유용성, 유지 관리 가능성 또는 성능과 같은 특정 품질 특성과 관련된 문제가 있습니다.
자, 다시 프로젝트로 돌아가서, 제품 관련 위험 요소가 있나요? Guru 99뱅크 웹사이트는 어디인가요? 이 질문에 답하려면 다음 단계를 따르세요.
위의 3단계를 완료한 후 아래의 간단한 퀴즈를 풀어 제품 위험을 확인하세요.
A) 예
나) 아니오
다) 잘 모르겠다
A) 예
나) 아니오
A) 안전한 자금 이체
나) 사용자는 새로운 계정을 등록할 수 있습니다.
C) 더 많은 기능이 필요하지 않습니다.
2단계) 발생하는 리스크의 영향 분석
이전 주제에서는 프로젝트를 방해할 수 있는 위험을 이미 식별했습니다. 확인된 위험 목록은 다음과 같습니다.
- 당신은 충분하지 않을 수 있습니다 인적 자원 마감일에 프로젝트를 끝내기 위해
- 테스트 환경 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
- 귀하의 프로젝트 예산 경영상황에 따라 절반으로 삭감될 수도
- 이 웹사이트는 결핍 보안 기능
다음으로 이러한 위험을 분석해야 합니다.
각 위험은 다음 두 가지 매개변수를 기준으로 분류되어야 합니다.
- The 확률 발생의
- The 충격 프로젝트에
아래 매트릭스를 사용하면 다음을 수행할 수 있습니다. 분류하다 위험을 네 가지 범주로 분류 높음, 중간, 낮음 또는 값 3,2, 1
|
있을 법한 일 |
|
|---|---|
|
높음 (3) |
발생할 가능성이 매우 높으며 전체 프로젝트에 영향을 미칠 수 있음 |
|
중간 (2) |
발생 확률 50% |
|
낮음 (1) |
낮은 발생 확률 |
|
영향 |
|
|---|---|
|
높음 (3) |
해결되지 않으면 프로젝트 활동을 계속할 수 없습니다. 바로 |
|
중간 (2) |
해결되지 않으면 프로젝트 활동을 계속할 수 없습니다 |
|
낮음 (1) |
해결이 필요하지만 당분간 대체 솔루션을 사용할 수 있습니다. |
다음 위험을 고려하세요
|
위험 |
있을 법한 일 |
영향 |
우선순위 = 확률* 영향 |
|---|---|---|---|
|
프로젝트 마감일을 지키지 못했습니다. |
3 |
3 |
9 |
|
정전 |
1 |
2 |
2 |
위의 우선순위에 따라 테스트 시 위험 완화 또는 아래 표에 언급된 대응 조치를 취할 수 있습니다.
|
우선 |
리스크 관리 방법 |
|
|---|---|---|
|
높음 |
6 - 9 |
즉시 완화 조치를 취하고 상태가 종료될 때까지 매일 위험을 모니터링합니다. |
|
중간 |
3-5 |
매주 내부 진행회의를 통해 리스크 모니터링 |
|
높음 |
1-2 |
위험을 수용하고 마일스톤 기준으로 위험을 모니터링합니다. |
이제 실습 시간입니다. 우리는 4가지 위험 요소를 파악했습니다. Guru99개 은행 프로젝트. 직접 분류해 보세요.
| 위험 | 높음 | 중급 | 높음 | Status |
|
|
|
|
|
옳은.
올바르지 않습니다.
|
|
|
|
|
|
옳은.
부정확 한
|
|
|
|
|
옳은.
부정확 한
|
|
|
|
|
|
|
옳은.
올바르지 않습니다.
|
3단계) 위험을 완화하기 위한 대응 조치를 취하십시오.
이 활동은 3부분으로 나누어져 있습니다
리스크 대응
프로젝트 관리자는 위험을 최소한으로 줄일 수 있는 전략을 선택해야 합니다. 프로젝트 관리자는 다음 네 가지 위험 대응 전략 중에서 선택할 수 있습니다.
앞서 언급한 4가지 위험 요소로 돌아가서, 테스트 단계에서 위험 완화 방안을 찾아야 합니다. 대책 그들을 피하거나 제거하기 위해.
B) 테스트 환경 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
다) 귀하의 프로젝트 예산 경영상황에 따라 절반으로 삭감될 수도
D) 이 웹사이트는 결핍 보안 기능
이러한 위험은 회사의 상황에 따라 피할 수 없습니다. 프로젝트에 더 많은 인적 자원을 요청할 수 없습니다. 이러한 경우 아래 옵션을 선택하여 위험의 영향을 줄일 수 있습니다.
- 프로젝트 팀에 합류할 재능 있고 경험이 풍부한 구성원을 선택하세요.
- 회원의 기술을 향상시키고 생산성을 향상시킬 수 있도록 교육 과정을 개설하십시오.
나. 테스트 환경이 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
다음 활동을 수행하면 이러한 위험을 피할 수 있습니다.
- 테스트 환경 구축을 위해 개발팀에 도움을 요청하세요.
- 환경설정에 필요한 모든 장비나 자재(서버, 데이터베이스, PC..)를 준비합니다.
다. 사업상황에 따라 프로젝트가 절반으로 축소될 수 있습니다.
이 위험은 매우 중요합니다. 전체 프로젝트가 진행되지 않을 수 있습니다. 그럴 경우에는 다음을 수행해야 합니다.
- 프로젝트 범위를 재정의하고, 테스트할 항목과 무시할 항목을 식별합니다.
- 프로젝트 예산에 맞춰 프로젝트 기간을 고객과 협의합니다.
- 테스트, 테스트 스펙 작성 등 프로젝트 각 단계의 생산성 향상…시간을 절약할 수 있으면 비용도 절감 가능
D. 이 웹사이트에는 보안 기능이 부족할 수 있습니다.
이 위험은 전체 프로젝트에 영향을 미치지 않고 피할 수 있으므로 중간 우선순위로 간주됩니다. 이러한 기능을 확인하고 웹사이트에 추가하도록 개발팀에 요청할 수 있습니다.
위험 등록
모든 위험은 프로젝트 관리자, 이해관계자 및 프로젝트 구성원이 기록하고 문서화하고 인정해야 합니다. 위험 등록부는 프로젝트 팀의 모든 구성원이 자유롭게 접근할 수 있어야 합니다.
다음과 같은 위험을 등록하는 데 유용한 몇 가지가 있습니다. 레드 마인, MITRA… 등
위험 모니터링 및 제어
위험을 지속적으로 모니터링하여 변경 사항이 있는지 확인할 수 있습니다. 지속적인 모니터링 및 평가 메커니즘을 통해 새로운 위험을 식별할 수 있습니다.
더 나은 위험 관리를 위해 다음을 참조할 수 있습니다. 위기 관리 이 기사에 포함된 템플릿
