소프트웨어 테스팅의 프로젝트 위험 분석 및 솔루션

위험 분석이란 무엇입니까?

위험은 바람직하지 않은 사건이 발생할 확률입니다.

소프트웨어 엔지니어링의 위험 분석은 귀하와 관련된 위험을 분석하는 프로세스입니다. 지원 계획.

프로젝트의 성공을 위해서는 프로젝트 시작 전에 위험을 식별하고 해당 솔루션을 결정해야 합니다. 소프트웨어 엔지니어링의 위험 식별은 초기 단계에서 예상되는 위험을 식별하는 데 도움이 됩니다.

이 튜토리얼에서는 사례 연구를 통해 테스트 관리 프로세스의 첫 번째 단계인 위험 분석 및 솔루션을 알아봅니다.

이 주제에서는 사례 연구를 통해 테스트 관리 프로세스의 첫 번째 단계인 소프트웨어 테스팅 및 솔루션의 위험 분석을 살펴보겠습니다.

테스트 중인 애플리케이션은 http://demo.guru99.com/V4/, 소프트웨어 요구 사항 사양을 참조할 수 있습니다. 여기를 눌러 더 많은 정보를 찾으세요..

Guru99 Bank에는 두 가지 역할이 있습니다.

  • 매니저
  • 고객 사례

FOLLOwing 기능/모듈은 이 두 가지 역할에 사용할 수 있습니다.

위험 분석

다음은 웹사이트를 간략히 둘러보는 것입니다.

위험 분석

요구 사항 문서를 읽은 후 웹 사이트에 너무 많은 내용이 있다는 것을 깨달았을 것입니다. 기능의COMplex 시나리오.

상황은 이렇습니다 –

  1. Guru99 뱅킹 웹사이트는 이미 개발 단계를 완료했습니다. 이제 테스트 단계가 시작됩니다. 안타깝게도 요구 사항 단계 초기에는 참여하지 않았습니다.
  2. 당신의 상사는 당신이 테스트를 완료하기를 원합니다. 한달 제한된 예산으로만 가능하지만 품질.
  3. 숙련된 엔지니어인 팀원이 알려줍니다.

위험 분석

  1. 이런 경우에는 어떻게 해야 합니까?

A) 큰 문제인 것 같습니다. 최대한 빨리 처리해야 합니다!!!

B) 상관없어요. 우리는 지금 당장 일을 시작해야 합니다.

액션 B를 선택하면 한 달 후의 결과는 다음과 같습니다.

  • 프로젝트가 엉망이어서 모든 리소스와 시간이 소요되었습니다. 직원의 작업량이 급격히 증가하여 스트레스와 과부하를 느낍니다.
  • 위험 분석

  • – 프로젝트가 지연되어 상사에게 약속한 대로 정해진 기한에 제품을 출시하지 못했습니다. 귀하의 팀원이 말했듯이, 이 프로젝트의 일정은 현재 자원 할당에 비해 너무 빡빡합니다.
  • 위험 분석

액션 A를 선택하면 한 달 후의 결과는 다음과 같습니다.

위험 분석

위의 예는 중요성 테스트 관리의 위험 분석.

위험 관리는 다음과 같은 이점을 제공합니다.

위험 분석

위의 예에서 언급된 위험은 프로젝트에서 발생할 수 있는 많은 잠재적 위험 중 하나일 뿐입니다. 이를 식별하고 최대한 빨리 처리하기로 결정해야 합니다!!! 따라서 해당 예에서 올바른 조치는 다음과 같습니다. 액션 A.

따라서 테스트의 위험 분석은 중요합니다

위험 분석을 수행하는 방법은 무엇입니까?

3단계 과정이에요

  1. 위험 식별
  2. 식별된 각 위험의 영향 분석
  3. 식별 및 분석된 위험에 대한 대응 조치

위험 분석을 수행하는 방법

1단계) 위험 식별

소프트웨어 제품에서는 위험을 식별하고 2가지 유형으로 분류할 수 있습니다.

위험 식별

프로젝트 리스크

프로젝트 위험은 다음과 같이 정의될 수 있습니다. 불확실한 프로젝트 진행에 영향을 미칠 수 있는 이벤트 또는 활동. 영향은 긍정적인 or 부정 프로젝트 목표 달성 전망에 영향을 미칩니다.

프로젝트 위험에는 주로 3가지 범주가 있습니다.

프로젝트 리스크

조직적 위험

이는 귀하와 관련된 위험입니다. 인적 자원 또는 테스트 팀. 예를 들어, 프로젝트에서 기술적으로 숙련된 구성원이 부족하면 위험합니다. 프로젝트를 제 시간에 완료할 만큼 충분한 인력이 없는 것도 또 다른 위험입니다.

조직적 위험

조직의 위험을 식별하려면 몇 가지 질문 목록을 만들고 스스로 대답해야 합니다. 다음은 몇 가지 추천 질문입니다.

1. 잘 조직된 팀인가요?

A) 예

나) 아니오

귀하의 프로젝트에는 조직 위험이 없습니다
더욱 강력한 팀을 만들고 협력 환경을 조성하세요.

2. 팀원 각자가 자신의 업무를 수행할 수 있는 능력을 갖추고 있습니까?

A) 예

나) 아니오

귀하의 프로젝트에는 조직 위험이 없습니다
회원의 기술 향상을 위한 교육 과정 구축

3. 프로젝트 규모와 일정을 비교해 보면, 이 프로젝트를 마감일에 완료할 만큼 충분한 인적 자원이 있습니까?

A) 예

나) 아니오

귀하의 프로젝트에는 조직 위험이 없습니다
프로젝트 보드에 더 많은 인적 자원을 확보하도록 요청하세요.

위의 모든 질문에 답하면 프로젝트에 영향을 미칠 수 있는 잠재적 위험을 쉽게 식별할 수 있습니다.

기술적 위험

기술적 위험은 테스트되지 않은 엔지니어링, 잘못된 테스트 절차 등과 같은 기술 프로세스를 실행하는 동안 발생하는 손실 가능성입니다. 기술적 위험의 예는 다음과 같습니다.

  • 이 프로젝트의 작업은 은행 웹사이트를 테스트하는 것입니다. 실제 비즈니스 환경을 반영하는 적절한 테스트 환경을 설정해야 합니다. 만약 테스트 환경 제대로 설정되지 않으면 제품이 지원 올바르게 테스트되고 많은 결함 감지되지 않습니다.

비즈니스 위험

위험에는 외부 실재. 당신의 회사, 당신의 고객으로부터 올 수 있는 위험이지만 지원 귀하의 프로젝트에서.

더 폴로wing 그림은 비즈니스 위험의 예를 보여줍니다.

비즈니스 위험

이러한 경우 테스트 관리자는 다음과 같은 위험을 처리할 수 있는 솔루션을 찾아야 합니다.

  • 세트 우선 테스트 단계에서는 웹사이트의 주요 기능을 테스트하는 데 중점을 둡니다.
  • 활용 테스트 생산성을 높이는 테스트 도구
  • 신청 프로세스 개선 관리 노력을 줄이기 위해.

제품 위험

제품 위험 시스템이나 소프트웨어가 고객, 사용자 또는 이해관계자의 기대를 충족하지 못할 가능성이 있습니다. 테스트 계획의 이 위험은 다음과 관련이 있습니다. 기능 성능 문제, 보안 문제, 충돌 시나리오 등과 같은 제품의

FOLLOwing 다음은 몇 가지 제품 위험의 예입니다.

  • 소프트웨어가 일부를 건너뜁니다. 고객이 사용자 '에서 지정한 기능
    요구 사항
  • 소프트웨어는 신뢰할 수없는 그리고 자주 실패 작동합니다.
  • 소프트웨어가 사용자 또는 소프트웨어를 사용하는 회사에 금전적 또는 기타 피해를 입히는 방식으로 작동하지 않습니다.
  • 소프트웨어에 보안, 신뢰성, 유용성, 유지 관리 가능성 또는 성능과 같은 특정 품질 특성과 관련된 문제가 있습니다.

이제 프로젝트로 돌아가서 Guru 99 Bank 웹사이트에 제품 위험이 있습니까? 이 질문에 대답하려면 다음을 따라야 합니다.wing 단계


제품 위험

위의 3단계를 완료한 후 아래의 간단한 퀴즈를 풀어 제품 위험을 확인하세요.

1) Guru99 은행 웹사이트를 이용할 수 있나요? 안전해야합니다. 고객 계정과 그의 데이터는 무엇입니까?
A) 예

나) 아니오

다) 잘 모르겠다

부정확 한
옳은

2) 웹사이트인가요? 쓸 수 있는 고객을 위해?
A) 예

나) 아니오

옳은
부정확 한

3) 웹사이트에는 어떤 다른 기능이 있어야 합니까?
A) 안전한 자금 이체

나) 사용자는 새로운 계정을 등록할 수 있습니다.

C) 더 많은 기능이 필요하지 않습니다.

부정확 한
옳은

2단계) 발생하는 리스크의 영향 분석

이전 주제에서는 프로젝트를 방해할 수 있는 위험을 이미 식별했습니다. 확인된 위험 목록은 다음과 같습니다.

  • 당신은 충분하지 않을 수 있습니다 인적 자원 마감일에 프로젝트를 끝내기 위해
  • 테스트 환경 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
  • 귀하의 프로젝트 예산 경영상황에 따라 절반으로 삭감될 수도
  • 이 웹사이트는 결핍 보안 기능

다음으로 이러한 위험을 분석해야 합니다.

각 위험은 다음 사항에 따라 분류되어야 합니다.wing 두 개의 매개변수

  • 확률 발생의
  • 충격 프로젝트에

아래 매트릭스를 사용하면 다음을 수행할 수 있습니다. 분류하다 위험을 네 가지 범주로 분류 높음, 중간, 낮음 또는 값 3,2, 1

있을 법한 일

높음 (3)

발생할 가능성이 매우 높으며 전체 프로젝트에 영향을 미칠 수 있음

중간 (2)

발생 확률 50%

낮음 (1)

낮은 발생 확률

영향

높음 (3)

해결되지 않으면 프로젝트 활동을 계속할 수 없습니다. 바로

중간 (2)

해결되지 않으면 프로젝트 활동을 계속할 수 없습니다

낮음 (1)

해결이 필요하지만 당분간 대체 솔루션을 사용할 수 있습니다.

다음을 고려하십시오.wing 위험

위험

있을 법한 일

영향

우선순위 = 확률* 영향

프로젝트 마감일을 지키지 못했습니다.

3

3

9

정전

1

2

2

위의 우선순위에 따라 테스트 시 위험 완화 또는 아래 표에 언급된 대응 조치를 취할 수 있습니다.

우선

리스크 관리 방법

높은

6 - 9

즉시 완화 조치를 취하고 상태가 종료될 때까지 매일 위험을 모니터링합니다.

중간

3-5

매주 내부 진행회의를 통해 리스크 모니터링

낮은

1-2

위험을 수용하고 마일스톤 기준으로 위험을 모니터링합니다.

이제 연습할 시간입니다. Guru4 Banking 프로젝트에서 확인된 99가지 위험이 있습니다. 스스로 분류해 보세요

위험 높은 중급 낮은 Status
  1. 당신은 충분하지 않을 수 있습니다 인적 자원 마감일에 프로젝트를 끝내기 위해
옳은.
올바르지 않습니다.
  1. 테스트 환경 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
옳은.
부정확 한
  1. 귀하의 프로젝트 예산 경영상황에 따라 절반으로 삭감될 수도
옳은.
부정확 한
  1. 이 웹사이트는 결핍 보안 기능
옳은.
올바르지 않습니다.

3단계) ​​위험을 완화하기 위한 대책을 강구합니다.

이 활동은 3부분으로 나누어져 있습니다

위험을 완화하기 위한 대책을 강구하세요

리스크 대응

프로젝트 관리자는 위험을 최소화하는 전략을 선택해야 합니다. 프로젝트 관리자는 다음 중에서 선택할 수 있습니다.wing 네 가지 위험 대응 전략

리스크 대응

앞에서 식별한 4가지 위험으로 돌아가서 테스트에서 위험과 완화를 찾아야 합니다. 대책 그들을 피하거나 제거하기 위해.

A) 충분하지 않을 수도 있습니다 인적 자원 마감일에 프로젝트를 끝내기 위해

B) 테스트 환경 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.

다) 귀하의 프로젝트 예산 경영상황에 따라 절반으로 삭감될 수도

D) 이 웹사이트는 결핍 보안 기능

A. 마감일에 프로젝트를 완료할 인력이 부족할 수 있습니다.
이러한 위험은 회사의 상황에 따라 피할 수 없습니다. 프로젝트에 더 많은 인적 자원을 요청할 수 없습니다. 이러한 경우 아래 옵션을 선택하여 위험의 영향을 줄일 수 있습니다.

  • 프로젝트 팀에 합류할 재능 있고 경험이 풍부한 구성원을 선택하세요.
  • 회원의 기술을 향상시키고 생산성을 향상시킬 수 있도록 교육 과정을 개설하십시오.

나. 테스트 환경이 실제 비즈니스 환경처럼 제대로 설정되지 않을 수 있습니다.
다음 사항을 수행하면 이러한 위험을 피할 수 있습니다.wing 방과 후 액티비티

  • 테스트 환경 구축을 위해 개발팀에 도움을 요청하세요.
  • 환경설정에 필요한 모든 장비나 자재(서버, 데이터베이스, PC..)를 준비합니다.

다. 사업상황에 따라 프로젝트가 절반으로 축소될 수 있습니다.
이 위험은 매우 중요합니다. 전체 프로젝트가 진행되지 않을 수 있습니다. 그럴 경우에는 다음을 수행해야 합니다.

  • 프로젝트 범위를 재정의하고, 테스트할 항목과 무시할 항목을 식별합니다.
  • 프로젝트 예산에 맞춰 프로젝트 기간을 고객과 협의합니다.
  • 테스트, 테스트 스펙 작성 등 프로젝트 각 단계의 생산성 향상…시간을 절약할 수 있으면 비용도 절감 가능

D. 이 웹사이트에는 보안 기능이 부족할 수 있습니다.
이 위험은 전체 프로젝트에 영향을 미치지 않고 피할 수 있으므로 중간 우선순위로 간주됩니다. 이러한 기능을 확인하고 웹사이트에 추가하도록 개발팀에 요청할 수 있습니다.

위험 등록

모든 위험은 프로젝트 관리자, 이해관계자 및 프로젝트 구성원이 기록하고 문서화하고 인정해야 합니다. 위험 등록부는 프로젝트 팀의 모든 구성원이 자유롭게 접근할 수 있어야 합니다.

다음과 같은 위험을 등록하는 데 유용한 몇 가지가 있습니다. 레드 마인, MITRA… 등

위험 모니터링 및 제어

위험을 지속적으로 모니터링하여 변경 사항이 있는지 확인할 수 있습니다. 지속적인 모니터링 및 평가 메커니즘을 통해 새로운 위험을 식별할 수 있습니다.

더 나은 위험 관리를 위해 다음을 참조할 수 있습니다. 위기 관리 이 기사에 포함된 템플릿