위험 기반 테스트에 대한 궁극적 인 가이드 : 소프트웨어 테스트의 위험 관리

ultimate guide risk based testing

위험 기반 테스트, 위험 관리 및 예제를 통한 접근 방식에 대한 궁극적 인 가이드 :

위험 기반 테스트 란 무엇입니까?

위험 기반 테스트는 테스트를 수행하거나 시나리오를 설계하고 실행하여 고객이 식별 한대로 비즈니스에 부정적인 영향을 미칠 수있는 상위 비즈니스 위험이 라이프 사이클 초기에 제품 또는 기능에서 발견되고 완화 조치를 구현하여 완화됩니다.

=> 전체 테스트 계획 튜토리얼 시리즈를 보려면 여기를 클릭하십시오.

부정적인 영향에는 비용 영향, 불만족 고객, 나쁜 사용자 경험, 심지어 고객을 잃는 정도까지 포함될 수 있습니다.

즉, RBT 접근 방식은 사용자가 버그를 발견 프로덕션에서 소프트웨어 사용을 중단하지 않거나 비즈니스에 심각한 영향을 미치지 않습니다.

RBT는 제품 위험을 기반으로 수행되는 테스트입니다. RBT는 테스트 사례에 대한 우선 순위 지정 기술을 사용하여 프로덕션에서 특정 기능의 실패로 인한 위험과 비용 및 기타 손상 측면에서 비즈니스에 미치는 영향을 미리 파악하는 것입니다.

따라서 위험 기반 테스트는 다음 원칙을 사용합니다. 테스트 우선 순위 지정 제품 또는 소프트웨어의 기능, 모듈 및 기능. 우선 순위는 프로덕션에서 해당 기능이 실패 할 가능성과 고객에게 미치는 영향에 따라 결정됩니다.

학습 내용 :

• 위험 기반 테스트와 Agile 및 DevOps와의 관련성
  • 위험 기반 테스트 접근 방식
    • RBT 방식은 언제 사용합니까?
    • RBT 접근 예
  • 위험 분석을 수행하는 방법
  • 위험 분석 절차
  • 위험 분석 방법론
    • 단계 # 1) 3X3 그리드 사용
    • 2 단계) 실패 가능성 및 영향
    • 3 단계) 우선 순위 그리드 테스트
    • Step # 4) 테스트 내용
  • RBT는 Agile 및 DevOps와 어떤 관련이 있습니까?
  • 위험 기반 테스트 접근 방식의 이점
• 테스트 계획 중 위험 관리
  • 리스크 관리 프로세스
    • # 1) 위험 식별
    • # 2) 위험 평가 / 위험 영향 분석
    • # 3) 위험 완화
  • 결론
• 테스트 실행 단계에서 위험 관리 (예제 포함)
  • 위험 관리 – AUT에 초점
  • 위험 기반 테스트는 어떻게 이루어 집니까?
  • 결론
  • 추천 도서

위험 기반 테스트와 Agile 및 DevOps와의 관련성

소프트웨어 개발에 소요 된 300 시간은 생산 과정에서 단 하나의 결함이 확인되면 단 30 초 만에 쓸모가 없게됩니다.

이것은 결국 다른 옵션없이 전체 제품의 목적을 망칠 수 있지만 시장에서 제품을 철회 할뿐입니다. 이것이 바로 '품질 테스트'의 중요성이자 필요성입니다.

기술의 급속한 성장으로 인해 소프트웨어는 여러 OS, 여러 플랫폼, 복잡한 IT 인프라 등을 지원하는 클라우드에서 호스팅되고 최종 사용자는 기능, 옵션에 대해 점점 까다로워지고 있으며 고객 만족을 위해 절대 타협하지 않습니다. .

오늘날 '품질'은 소프트웨어 제공에서 중요한 요소가되고 있으며 고객 만족을 유지하기 위해 품질을 개선하기 위해 지속적으로 개선되고 있습니다.

우리는 종종 거의 모든 테스터가 테스트 기간이 꽉 찼고 일반적으로 마지막 순간에 테스트를 위해 빌드가 전달된다는 엄청난 압력을받는 것이 일반적인 문제라는 것을 알게됩니다. 그들이 설계 한 모든 테스트를 실행하기에 충분한 시간과 자원이 없으며 자동화 범위가 항상 100 %는 아니며 자체적 인 문제가 있습니다.

배송 일정을 놓칠 수 없으며 동시에 품질도 타협 할 수 없습니다. 계획 B가 다른 팀에서 빠져 나와서 추가 테스트 리소스를 추가하는 것이 작동하지 않습니다. 계획 C는 다른 모든 활동을 중단하고 노력을 이것만으로 전환하는 것은 실제로 도움이되지 않습니다. 그러나 결국 테스트 리소스의 많은 추가는 효과가 없습니다.

다른 옵션은 없지만 사용 가능한 시간과 리소스 내에서 제한적이고 중요한 테스트를 실행하는 것뿐입니다.

그렇다면이 단계에서 어떤 테스트가 중요한지 어떻게 결정합니까? 테스터가 중요하다고 생각하는 것이 고객에게는 실제로 중요하지 않을 수 있습니다. 기능의 중요성은 누구의 관점에서 결정됩니까? 누가 중요한 테스트를 결정할까요? 그리고 다른 많은 질문이 계속 발생합니다.

이러한 모든 질문에 답하고 위의 상황을 효과적으로 처리하기 위해 테스트 접근 방식은 '위험 기반 테스트' , 곧 호출 됨 'RBT' , 팀은 '프로젝트 위험'기준에 따라 테스트 시나리오를 명확하게 계획하고 식별했습니다.

QA 팀은 중요한 테스트에 대한 명확한 그림을 가지고 있지만 RBT는 고객 및 비즈니스 관점에서 중요하고 중요한 테스트를 식별하는 입증 된 방법입니다. '위험도 분석' 순서 .

따라서 이제는 단순히 소프트웨어의 결함을 식별하는 전통적인 방법과는 달리 기술의 변화, 고품질 소프트웨어 출시를위한 시장 경쟁의 증가로 인해 시간이 지남에 따라 QA 접근 방식과 목표가 변경되었습니다. '모든 것을 자동화'하고 몇 시간 동안 소프트웨어를 제공하는 Agile 및 DevOps 사례를 전체적으로 소개합니다.

따라서 현재 '테스트 원리'의 트렌드는 단순히 '결함을 파악'하는 것이 아니라

#1) 생산 실패 또는 생산 실패 가능성으로 인해 비즈니스에 큰 영향을 미치는 제품 영역에 집중하십시오.

#두) 에 초점을 맞추고 결함 식별 팀이 가능한 한 빨리 문제를 해결할 수 있도록하여 소프트웨어 / 제품 또는 기능이 'Fail Fast'.

#삼) QA 팀의 서비스에서 가장 중요한 측면은 고객에게 초점을 맞춰 고객에게 가치를 제공하는 것입니다. '엔드 투 엔드 고객 경험'.

위험 기반 테스트 접근 방식

충분한 수의 테스트를 설계하고 실행하더라도 테스트가 충분하다고 말할 수없고 소프트웨어에 더 이상 결함이 없다는 것은 항상 시험을 준비하는 것과 같습니다.

테스트 케이스 수만 늘려도 소프트웨어 안정성이 이중으로 보장되지 않는 지점이 있습니다. 이 시점에서 테스트 수에만 초점을 맞추는 것이 아니라 실제로 고객이 릴리스에서 기대하는 것에 초점을 맞 춥니 다.

따라서 합리적인 테스트 노력으로 최대의 이익을 얻으려면 테스트 최적화에서 균형을 유지하는 것이 중요합니다. 그리고 이는 테스트 일정이 매우 촉박하고 충분한 테스트를 수행 할 수있는 충분한 리소스가 없을 때 더 중요합니다.

따라서이 경우 RBT 접근 방식은 QA 노력을 최적화하고 최소한의 비즈니스 위험으로 테스트 이점을 극대화하는 데 핵심적인 역할을합니다.

따라서 위의 측면에 집중하면 QA 작업이 훨씬 덜어 질 것입니다. 그들은 주말을 사무실에서 태울 필요가 없으며 소프트웨어를 지속적으로 테스트하고 테스트에서 나오는 모든 S4 (심각도 4) 및 P4 (우선 순위 4) 결함에 대해 걱정할 필요가 없습니다.

음, 4는 테스트에서 결함의 가장 낮은 우선 순위와 심각도로 간주됩니다. 그들은 프로젝트의 다른 유용한 측면에 시간을 더 잘 투자 할 수 있습니다.

'위험 기반 테스트'접근 방식의 주요 동인을 요약하면 다음과 같습니다.

• 비즈니스 관점에서 '고객이 원하는 것'을 테스트 할 수 있습니다.
• 예상되는 품질로 시간 일정을 맞추기 위해.
• QA 노력을 최적화합니다.

RBT 방식은 언제 사용합니까?

이것은 아래 시나리오에서 사용됩니다.

• RBT 접근법은 프로젝트의 시간, 비용 및 자원에 대한 제한이나 제약이있을 때 그리고 자원을 최적화해야 할 때마다 사용할 수 있습니다.
• RBT 접근 방식은 프로그램이 더 복잡하고 새로운 기술을 적용하여 많은 문제를 수반 할 때 사용됩니다.
• 프로그램이 R & D 프로젝트이고 첫 번째 유형이고 프로젝트에 알려지지 않은 많은 위험과 위험이있는 경우.

RBT 접근 예

IT 산업에서는 생산과 그 영향에 따른 위험을 극복하기 위해 여러 위험 기반 분석 접근 방식이 사용됩니다.

다음은 그러한 접근 방식 중 하나입니다.

이 RBT 접근 방식에는 제품의 '중요한 기능 또는 주요 기능'을 식별하고 이러한 각 기능이 생산 과정에서 노출되는 위험을 평가하고 위험을 낮추거나 완화하기위한 적절한 완화 조치를 구현하는 것이 포함됩니다.

따라서 RBT 접근 방식에는 실패 가능성이 있고 비즈니스에 가장 큰 영향을 미치는 기능 테스트가 포함됩니다. 실패 유형은 운영 또는 비즈니스, 기술, 외부 등일 수 있습니다.

위험 분석을 수행하는 방법

제품의 모든 기능에 대해 소프트웨어 테스트에서 위험 분석을 수행하기 위해 정의 된 표준 프로세스 또는 템플릿은 없습니다. 다양한 조직에서 위험 분석 방법에 대한 자체 접근 방식을 사용합니다.

위험을 식별하고 분석을위한 RBT 접근 방식을 구현하기 위해 다양한 프로젝트 항목에 대해 위험 분석을 수행 할 수 있습니다. 이러한 항목에는 다음이 포함됩니다.

• 풍모
• 기능
• 사용자 스토리
• 요구 사항
• 사용 사례
• 테스트 케이스

이 경우 위험 기반 테스트 접근 방식 구현을 이해하기 위해 테스트 사례에만 집중하겠습니다.

위험 분석 절차

위험 분석에는 두 회사의 프로그램 관련 이해 관계자 참여가 포함됩니다. 기술팀 및 비즈니스 팀 ' , 여기에는 제품 소유자, 제품 관리자, 비즈니스 분석가, 설계자, 테스터 및 고객 담당자가 포함됩니다.

이러한 이해 관계자가 참여하는 브레인 스토밍 세션은 제품의 각 기능의 중요성을 식별하고 실패의 위험과 생산에서 최종 사용자에게 미치는 영향에 따라 우선 순위를 지정하기위한 토론을 수행하도록 구성됩니다.

요구 사항 문서, 기술 사양 문서, 아키텍처 및 설계 문서, 비즈니스 프로세스 문서, 사용 사례 문서 등과 같은 다양한 '프로젝트 문서'가 브레인 스토밍 세션의 입력이 될 것입니다.

제품 및 시장의 기존 제품에 대한 이해 관계자의 지식도 토론의 입력 요소가 될 것입니다.

다른 입력 소스에는 다음이 포함될 수 있습니다.

• 가장 많이 사용되는 기능에 대한 정보를 수집합니다.
• 도메인 전문가와상의하여 얻은 정보.
• 이전 버전의 제품 또는 시장에 나와있는 유사한 제품의 데이터.

시 브레인 스토밍 세션에서 이러한 각 기능과 관련된 위험이 식별됩니다. 위험 유형은 운영, 기술 또는 비즈니스 관련 일 수 있습니다. 이와 관련된 테스트 및 시나리오에는 가중치가 적용되고 위험 발생 가능성과 위험의 영향에 따라 위험 값이 평가됩니다.

'위험 발생 가능성'의 원인은 다음과 같습니다.

• 제품 개발 팀의 기능에 대한 이해가 부족합니다.
• 부적절한 아키텍처 및 디자인.
• 설계 시간이 충분하지 않습니다.
• 팀의 무능력.
• 불충분 한 자원 – 사람, 도구 및 기술.

'위험의 영향'은 실패가 발생할 경우 사용자와 비즈니스에 미치는 영향입니다. 영향은 다음과 같습니다.

• 비용 영향으로 손실이 발생합니다.
• 비즈니스 손실 또는 시장 점유율 손실을 초래하는 비즈니스 영향, 법률 절차, 라이센스 손실.
• 품질에 영향을 미쳐 표준 이하 또는 부적합한 제품 출시를 초래합니다.
• 사용자 경험이 좋지 않아 불만족스럽고 고객을 잃게됩니다.

기능 또는 제품의 위험을 평가하는 초점 영역은 다음과 같습니다.

• 기능의 비즈니스 중요도 영역.
• 가장 많이 사용되는 기능 및 중요한 기능.
• 결함이있는 부위
• 안전 및 보안에 영향을 미치는 기능.
• 복잡한 설계 및 건축 분야.
• 이전 버전에서 변경된 사항.

위험 분석 방법론

이제 '위험 기반 테스트 방법'을 자세히 이해하겠습니다.

위험 기반 테스트 접근 방식은 테스트주기의 모든 테스트 단계에서 위험을 기준으로 사용합니다. 테스트 계획 , 테스트 설계, 테스트 구현, 테스트 실행 및 테스트보고. 이상적으로는 가능한 수많은 테스트 시나리오 조합을 설계 할 수 있습니다.

따라서 RBT 접근 방식에는 위험의 심각도를 기반으로 한 테스트 순위가 포함되어있어 가장 결함이 있거나 위험한 장애 영역을 찾아 비즈니스에 큰 영향을줍니다.

위험 분석의 주요 목적은 '높은 가치' 제품 기능, 기능, 요구 사항, 사용자 스토리 , 테스트 사례 및‘ 낮은 가치 ' 따라서 나중에는 '낮은 가치'테스트 케이스에 덜 집중하여 '높은 가치'테스트 케이스에 더 초점을 맞 춥니 다. 위험 기반 테스트를 시작하기 전 위험 분석의 초기 단계입니다.

테스트 케이스를 High Value & Low Value로 분류하거나 그룹화하고 이러한 각 테스트 케이스에 우선 순위 값을 할당하는 주요 작업에는 다음 단계가 포함됩니다.

단계 # 1) 3X3 그리드 사용

위험 분석은 3X3 그리드를 사용하여 수행되며, 여기서 각 기능, 비 기능 및 관련 테스트 사례는 '있을 수 있는 일실패의 영향 '과'실패의 영향 '.

프로덕션에서 각 기능의 실패 가능성은 일반적으로 '기술 전문가'그룹이 액세스하며 그리드의 수직 축을 따라 '실패 할 가능성이 높음, 가능성이 높음'으로 분류됩니다.

자바에서 배열의 한 요소를 인쇄하는 방법

마찬가지로 프로덕션에서 이러한 특징 및 기능의 '실패 영향'은 테스트를 거치지 않은 경우 최종 고객이 경험합니다. ' Business Specialists”로 분류되며 그리드의 수평 축을 따라 '경미, 표시 및 중단'범주로 분류됩니다.

2 단계) 실패 가능성 및 영향

모든 테스트 사례는 아래 그림에서 점으로 표시된 고장 가능성 및 고장 영향의 식별 된 값을 기반으로 3 X 3 그리드의 사분면에 배치됩니다.

분명히 높은 실패 가능성과 높은 실패 영향 (중단)이 그리드의 오른쪽 상단 모서리에 그룹화되어 있으며 이는 매우 중요하므로 '높은 가치'테스트와 '낮은 가치'테스트가 그룹화되어있는 것으로 식별됩니다. 고객에게 가장 중요하지 않거나 전혀 중요하지 않은 왼쪽 하단 모서리로, 이러한 기능이나 테스트 사례에 약간의 초점을 맞출 수 있습니다.

3 단계) 우선 순위 그리드 테스트

그리드에서 테스트 케이스의 위 위치를 기반으로 테스트의 우선 순위가 지정되고 우선 순위 1,2,3,4 및 5로 레이블이 지정되고 각각에 대해 표시됩니다. 가장 중요한 테스트는 1^성우선 순위 1로 할당 된 그리드와 비슷하게 덜 중요한 그리드는 2, 3, 4 및 5로 순위가 매겨집니다.

마지막으로 모든 테스트 케이스는 우선 순위 번호를 기준으로 정렬되고 우선 순위에 따라 실행됩니다. 우선 순위가 높은 항목이 먼저 실행되고 우선 순위가 낮은 항목이 나중에 실행되거나 범위가 지정되지 않습니다.

Step # 4) 테스트 내용

다음 단계는 정의 된 테스트 범위에 대한 테스트 세부 수준을 결정하는 것입니다. 테스트 범위의 깊이는 아래 표에 따라 위의 순위를 기반으로 결정할 수 있습니다.

순위가 1 인 높은 우선 순위 테스트는 '더 철저하게'테스트되며 이에 따라 전문가가 이러한 중요도가 높은 기능과 관련 테스트 사례를 테스트하기 위해 배치됩니다. 마찬가지로 우선 순위가 2, 3, 4 인 테스트 케이스를 테스트합니다. 사용 가능한 시간과 리소스를 기반으로 우선 순위 5 기능의 범위를 없애고 테스트를 수행 할 수 있습니다.

따라서 기능 및 테스트 사례의 우선 순위를 지정하는 테스트 세부 수준 접근 방식은 테스터가 '고 가치 테스트'를 식별하는 데 도움이 될뿐만 아니라 이러한 우선 순위 순위 및 테스트 사례를 기반으로 '테스트 세부 수준'을 결정하도록 안내합니다. 더 나은 테스트를 수행하고 최적화 프로세스를 통해 테스트 비용을 줄일 수 있습니다.

RBT는 Agile 및 DevOps와 어떤 관련이 있습니까?

이제 특정 기능의 '실패 위험'과 라이브에서 '고객에 미치는 영향'에 따라 테스트의 우선 순위를 지정하여 테스트를 수행하는 위험 기반 테스트 접근 방식을 이해하면 분명히 다음과 같은 질문이 제기 될 것입니다. Agile 및 DevOps Practices에서 위험 기반 테스트 접근 방식의 관련성.

'모두 자동화', '모두 테스트', '지속적으로 테스트', '반복 테스트'는 이러한 관행의 핵심 개념입니다.

코드가 변경되거나 릴리스가있을 때마다 설계된 모든 테스트가 자동화 된 지속적인 통합 (CI) / 지속적 전달 (CD) 우선 순위에 관계없이 신속하고 반복적으로 파이프 라인을 연결합니다.

그렇다면 RBT와 DevOps의 관계는 무엇입니까? RBT는 Agile 및 DevOps에서 어디에 적합하고 관련이 있습니까 ???

#1) 예, 앞서 말했듯이 모든 산업과 모든 제품이 테스트 실행에 대해 100 % 자동화 범위를 갖는 것은 아닙니다. 따라서 팀이 수동 테스트 케이스의 선택에서 테스트 실행의 우선 순위를 선택해야하고 테스트 리소스의 에너지와 노력을 다른 활동에 아끼고 싶다면 RBT가 최선의 선택입니다.

위험 기반 접근 방식은 우선 순위가 높은 자동 테스트를 실행하고 초기에 테스트하는 데 더 나은 방법입니다.

#두) QA 팀은 요구 사항 분석 중에 RBT 접근 방식을보다 효과적으로 채택하여 요구 사항을 분석하고 제품 및 기능의 가능한 위험에 대한 사전 보고서를 제공하여 프로그램 팀이이를 완화하기 위해 적절한 조치를 취할 수 있도록 할 수 있습니다.

#삼) RBT 접근 방식은 고위험을 기반으로 한 테스트 사례 및 시나리오를 설계하는 데 효과적으로 사용될 수 있으므로 고위험 기능에 더 집중할 수 있습니다.

# 4) '고위험'영역을 식별하면 QA 팀이 해당 영역에 테스트 노력을 집중하여 '고급 테스터'를 사용하여 '더 철저하게'테스트 할 수 있습니다.

# 5) 우리 모두가 알고있는 'Fail Fast'는 'Agile'및 'DevOps'의 개념으로, RBT 접근 방식은 소프트웨어에서 '고위험'영역을 식별하고 결함을 조기에 식별하며 빠르게 실패하고 실패 할 수 있도록합니다. 먼저 팀이 수정하도록합니다.

# 6) Agile / DevOps의 궁극적 인 목표는 '고객 중심'이므로 RBT 접근 방식을 통해 QA는 단순히 결함을 찾는 것보다 고객 경험에 집중할 수 있습니다.

위험 기반 테스트 접근 방식의 이점

우리는 이미 요구 사항을 분석하고 테스트 시나리오를 설계 및 실행하는 RBT 접근 방식의 목적과 사용을 이해했습니다. RBT에는 몇 가지 이점이 있습니다.

위험 기반 테스트의 이점을 다음과 같이 통합하고 나열 할 수 있습니다.

• 테스트 리소스의보다 효율적이고 최적화 된 사용을 지원합니다.
• 우선 순위를 지정하여 QA 작업, 테스트, 테스트 설계 및 개발, 테스트 준비 활동을 용이하게합니다.
• 핵심 리소스를 집중도가 높은 영역에 할당하여 QA 리소스를 더 잘 관리하는 데 도움이됩니다.
• 자원의 효과적인 활용을 돕고 프로젝트의 더 나은 일에 시간과 에너지를 바꿉니다.
• 위험 평가 및 휘발성 및 고위험 영역의 식별을 기반으로 테스트 노력을 계획하는 데 QA 팀을 지원합니다.
• 이는 팀이 중요도에 따라 수행 할 테스트를 최적화하는 데 도움이되므로 이해 관계자와 합의하여 낮은 값의 테스트 범위를 제거합니다.
• 전반적으로 최적화되고 감소 된 테스트 활동을 통해 비용 절감에 도움이됩니다.
• RBT 접근 방식을 통해 QA 팀은 위험도가 높은 영역을 먼저 테스트하고 제품이 '빠르게 실패'하고 빠르게 수정할 수 있습니다.
• RBT 접근 방식은‘ 테스트 범위 ' 그리고 전체 이해 관계자 그룹에 대한 '테스트 범위'.
• 팀은 고위험 영역에 대한 집중력을 높이고 저 위험 영역에 대한 집중력을 줄일 수 있습니다.
• RBT를 통해 팀은 제품 위험에 대한 가장 효과적인 완화 방법의 구현을 미리 결정할 수 있습니다.
• RBT는 부적절한 완화 구현의 영향을 피하는 데 도움이됩니다.
• 위험 기반 테스트를 통해 팀은 비상 사태를 완화하거나 계획하기 위해 적절한 조치를 취하거나 Live에서 위험이 발생하는 경우 실패를 극복하거나 그 영향을 줄이기위한 해결 방법을 배치 할 수 있습니다.
• RBT는 릴리스의 잔여 위험을 최소화하는 데 도움이됩니다.
• 비용이 적게 드는 생산 결함을 통해 '향상된 품질'을 달성하는 데 도움이됩니다.
• 궁극적으로 '개선 된 고객 경험'및 '고객 만족'을 지원합니다.

다음으로 소프트웨어 테스트 라이프 사이클의 테스트 계획 및 테스트 실행 단계에서 위험을 관리하는 방법을 배웁니다.

테스트 계획 중 위험 관리

테스트 계획 단계에서 위험을 관리하는 방법 :

인생은 위험으로 가득 차 있으며 소프트웨어 프로젝트도 마찬가지입니다. 언제든지 문제가 발생할 수 있습니다. 우리는 항상 일을 바로 잡기 위해 최선을 다하고 있습니다. 그러나 잘못된 것이 없는지 확인하는 것은 어떨까요? 위험 관리 진입 – 위험을 예방, 이해, 발견 및 극복 할 수 있도록 준비하는 소프트웨어 테스트 프로젝트의 일부입니다.

위험은 단순히 발생할 가능성이있는 문제이며 발생할 경우 손실을 초래합니다.

손실은 돈, 시간, 노력 또는 품질 저하 등 무엇이든 될 수 있습니다. 손실은 결코 좋지 않습니다. 아무리 많은 스핀을 주어도 긍정적 인 것은 아니며 결코 그렇지 않을 것입니다. 따라서 위기 관리 위험을 처리하고 손실을 예방 / 감소시키는 소프트웨어 프로젝트의 필수 부분입니다.

위험 기반 테스트 : 우리는 QA 커뮤니티이기 때문에 QA 세계에서 독점적으로 위험과 관련 프로세스에 대해 구체적으로 유지하도록하겠습니다. 위험은 대략 2 단계로 평가되고 관리됩니다. 소프트웨어 테스트 수명주기 . STLC는 테스트 계획, 테스트 설계 및 테스트 실행의 3 단계로 분류 할 수 있습니다.

위험 관리 프로세스는 다음 중 두 번 발생합니다.

1. 테스트 계획
2. 테스트 케이스 디자인 (끝) 또는 때때로 테스트 실행 단계

사례 1에서는 필수이지만 사례 2에서는 '필요 기반'상황에 더 가깝습니다.

두 부분으로 구성된 기사 시리즈 :

기본 프로세스는 동일하지만 위험 유형 이 두 영역에서 다룬 것은 완전히 다릅니다. 개별적으로 정의하기 위해 두 부분으로 구성된 시리즈로 다르게 처리 할 것입니다.

이 섹션은 '테스트 계획 중 위험 관리”.

리스크 관리 프로세스

위험 관리를위한 일반적인 프로세스는 3 가지 중요한 단계를 포함합니다.

1. 위험 식별
2. 위험 영향 분석
3. 위험 완화

위험 및 완화 예제 테스트 :

# 1) 위험 식별

말했듯이 문제를 해결하는 첫 번째 단계는 문제를 식별하는 것입니다. 이 단계에서는 잠재적으로 발생하여 정상적인 이벤트 흐름을 방해 할 수있는 모든 항목의 목록을 작성합니다.

이 단계의 주요 결과는 위험 목록입니다.

이 위험 기반 테스트 단계는 일반적으로 QA 리드 / 관리자 / 대표자가 주도합니다. 하지만 리드 혼자서는 전체 목록을 만들 수 없습니다. 전체 QA 팀의 의견이 큰 영향을 미칩니다. 이것은 QA 리더가 이끄는 집단 활동이라고 말할 수 있습니다.

또한 테스트 계획 단계에서 식별 된 위험은보다 '관리적'방향입니다. 즉, QA 프로젝트의 일정, 노력, 예산, 인프라 변경 등에 영향을 미칠 수있는 모든 것을 살펴볼 것입니다. 여기서 초점은 AUT가 아니라 QA 단계가 진행되는 방식입니다.

테스트 계획 중 위험 : 위험 기반 테스트 예

다음은 테스트 계획 단계 중에 나열 될 수있는 위험의 샘플 목록입니다. AUT와 그 기능은 여기서 중점을 두지 않습니다.

1. 테스트 일정이 촉박합니다. 설계 작업으로 인해 테스트 시작이 지연되는 경우 테스트는 UAT 예정된 시작 날짜를 초과하여 연장 할 수 없습니다.
2. 리소스 부족, 리소스 온 보딩이 너무 늦었습니다 (프로세스에는 약 15 일 소요).
3. 결함은주기의 후반 단계 또는 후반주기에서 발견됩니다. 늦게 발견 된 결함은 대부분 불분명 한 사양으로 인한 것이며 해결하는 데 시간이 많이 걸립니다.
4. 범위가 완전히 정의되지 않았습니다.
5. 자연 재해
6. Independent의 비 가용성 테스트 환경 및 접근성
7. 새로운 문제로 인해 지연된 테스트

이 시점에서 사용 가능한 시간에 따라 원하는만큼 철저하게 선택할 수 있습니다.

모든 위험이 나열되면 위험 평가 / 위험 영향 분석으로 진행합니다.

# 2) 위험 평가 / 위험 영향 분석

위험 분석이 이와 비슷한가요? :)

소프트웨어 테스트의 위험 분석 :이 단계에서는 모든 위험을 정량화하고 우선 순위를 지정합니다. 모든 위험의 확률 (발생 가능성)과 영향 (이 위험이 구체화 될 때 발생할 수있는 손실의 양)은 체계적으로 결정됩니다.

높음 – 중간 낮음 , 값은 각 위험의 확률과 영향 모두에 할당됩니다. '높은'확률과 '높은'영향이있는 위험을 먼저 처리 한 다음 순서를 따릅니다.

위험 영향 분석 표 :

이러한 단계에 따라 나열된 위 위험에 대한 위험 영향 분석 테이블은 다음과 같습니다 (모든 값은 가설이며 이해 목적으로 만 사용).

# 3) 위험 완화

이 위험 기반 테스트 (RBT) 프로세스의 마지막 단계는 이러한 각 상황을 처리하는 방법을 계획하는 솔루션을 찾는 것입니다. 이러한 계획은 회사마다, 프로젝트마다, 심지어 사람마다 다를 수 있습니다.

위험 완화 기법 :

다음은이 단계가 완료 될 때 위험 테이블이 변환되는 내용의 예입니다.

참고할 몇 가지 사항 :

1. QA 프로젝트 계획 단계에서 위험 관리가 빨리 시작 될수록 좋습니다.
2. 3 단계 중 위험 식별이 가장 중요합니다 . 나열되지 않고 추가 단계를 고려할 경우 위험은 처리되지 않습니다.
3. 이 활동에 이상적인 시간 프레임을 찾으십시오. 계획을 너무 많이 세우면 수행 할 시간이 너무 적습니다.
4. 또한 리스크 관리 프로세스 후 새로운 상황이 발생하면 리스크 관리 계획을 변경하거나 업데이트하여 최신 상황을 반영 할 수 있습니다.
5. 역사적 데이터 이 프로세스의 성공에 매우 유용 할 수 있습니다.

결론

이를 통해 테스트 계획 단계에서 위험 관리가 끝납니다. 기본 단계와 원칙은 유사하지만 위험 관리 프로세스는 테스트 설계 / 실행 단계에서 발생할 때 AUT에 더 집중됩니다.

다음 섹션에서 다룰 것입니다. 테스트 실행 단계의 위험 관리.

테스트 실행 단계에서 위험 관리 (예제 포함)

위험 관리 프로세스를 이해하기위한 여정에서 우리는 그것이 독점적으로 어떻게 진행되는지에 대해 이야기했습니다. 위험 기반 테스트의 테스트 계획 단계 . 또한 위험 식별, 위험 평가 및 위험 완화 계획과 관련된 일반적인 프로세스를 이해했습니다.

테스트 설계 또는 테스트 실행 단계에서 위험을 관리하는 방법 :

다른 형태의 위기 관리 (때때로 위험 기반 테스트 ) 상황에 따라 테스트 설계 또는 테스트 실행 단계에서 발생합니다. 이제 우리는 어떤 상황에 대해 이야기하고 있습니까? 먼저 그것을 이해하려고 노력합시다.

우리 모두는 테스트 작업이 반응 적이라는 것을 알고 있습니다. 요구 사항 (또는 정의 된 범위)이 없으므로 타당성 분석을 수행하고 테스트 시나리오를 작성하거나 테스트 활동을 계획 할 수 없습니다.

마찬가지로 코드가 준비되지 않은 경우 테스트 케이스, 테스트 데이터 등의 측면에서 준비된 준비 작업이 아무리 많아도 테스트 할 것이 없습니다. 또한 테스트는 제품이 출시되기 전에 남은 유일한 단계입니다. 라이브.

위험 관리 – AUT에 초점

예를 들어 이것을 더 잘 이해합시다.

테스트가 해당 날짜에 시작되는 경우 1 월 1 일^성그리고 1 월 14 일까지 계속해서^일– 테스트가 완료되면 일반적으로 제품의 가동 날짜가 즉시 수정됩니다. 예 : 1 월 15 일^일단순함을 위해. 이제 완벽한 세상에서는 모든 것이 계획대로 정확하게 진행될 것입니다. 그러나 우리 모두는 현실을 알고 있습니다.

이 경우 어떤 이유로 테스트가 1 월 7 일까지 시작되지 않았다고 가정하겠습니다.^일즉, 테스트 시간의 절반을 잃었습니다. 그러나 제품을 철저히 테스트하려면 14 일이 필요합니다. 우리는 가동 날짜를 7 일 더 멀리 이동할 수 있습니다. 이것은 일반적으로 옵션이 아닙니다. 제품이 특정 날짜에 시장에 출시 될 것을 약속하고 지연이 비즈니스에 좋지 않기 때문입니다.

따라서 일반적으로 테스트 팀은 지연을 흡수하고, 어떻게 든 보상하고, 사용 가능한 시간에 맞춰 작업하고, 제품이 제대로 테스트되었는지 확인해야합니다. 힘든 일 이죠?

여기에서 위험 관리 프로세스가 다시 사용됩니다.

• 자, 만약 지연이 미리 예상됩니다 테스트가 시작되기도 전에 테스트 설계 단계에서 프로세스가 진행됩니다.
• 만약 지연은 테스트 실행 단계 정상적으로 시작된 프로세스는 테스트 실행 단계에서 수행됩니다.
• 단계와 방법은 어떤 단계에서 발생하든 동일합니다.

과정은 무엇입니까?

위험 관리는 AUT (Application Under Test)에서 최대 초점이 필요한 영역을 결정하기 위해 수행됩니다. 이들은 일반적으로 최종 제품의 성공에 중요하고 실패하기 가장 쉬운 기능 영역 (모듈 또는 구성 요소)입니다.

또한 읽기=> FMEA (고장 모드 및 영향 분석)는 위험 관리 기법입니다.

누가 수행합니까?

애니메이션을 볼 수있는 최고의 애니메이션 사이트

AUT에 관한 것이기 때문에 이에 대한 지식은 QA뿐만 아니라 Dev, BA, Client, Project Management 팀 등 다른 모든 팀에도 있습니다. 따라서 테스트 팀이 주도하는 공동 노력입니다.

위험 기반 테스트는 어떻게 이루어 집니까?

1 단계) 위험 식별

AUT의 모든 기능 영역을 식별합니다. 여기에는 목록 작성이 포함됩니다.

2 단계) 위험 평가

모든 위험은이 단계에서 정량화되고 우선 순위가 지정됩니다. 정량화는 간단하게 목록의 각 위험에 번호를 할당하여 해결해야하는 우선 순위를 표시하는 것입니다.

모든 위험의 확률 (발생 가능성)과 영향 (이 위험이 구체화 될 때 발생할 수있는 손실의 양)이 결정됩니다.

일반적인 방법은 등급을 지정하는 것입니다. 예를 들어, 확률은 1에서 5까지의 값을 가질 수 있습니다. 1은 발생 확률이 낮고 (전혀 발생할 가능성이 없음) 5는 높음 (확실히 발생 함)입니다.

마찬가지로 Impact에도 1-5 등급을 지정할 수 있습니다. 1은 낮은 영향 (이 위험이 구체화 되더라도 손실은 최소화 됨)이고 5는 높은 영향 (발생시 막대한 손실)입니다.

3 단계)

테이블 형식을 만들고 모든 팀 담당자 (Dev, BA, Client, PM, QA 및 기타 관련 사람)에게 배포합니다.

4 단계)

각 팀에게 확률과 영향에 대한 등급에 따라 값을 입력하도록 지시합니다.

확률 및 영향 값은 숫자이므로 '위험 요소'값을 쉽게 계산할 수 있습니다.

위험 요소 = 확률 X 영향. 위험 요소가 높을수록 문제가 심각합니다.

예:

이 시점에서 이것은 단순히 한 팀의 평가 결과입니다. 5 개의 다른 팀이 관련된 프로젝트의 경우 QA 팀은 5 개의 다른 테이블로 끝납니다.

5 단계)

위험 요소 값의 평균을 취하십시오. 예를 들어, 5 개 팀이있는 경우 각 모듈에 대해 모든 위험 요소 값을 더하고 5로 나눕니다. 이것이 우리가 다룰 최종 값입니다. 평균 위험 요소는 다음과 같습니다.

위험 요소가 많을수록 해당 모듈을 더 많이 테스트해야합니다.

따라서 모듈 5와 2는 비즈니스의 성공에 가장 중요합니다. 모든 팀과 결과를 공유하십시오.

6 단계)

위험 완화 계획 : 이제 Project에서 Project로 변경되는 단계입니다. 우리는 모듈 5와 2가 가장 집중해야 할 모듈임을 확인했습니다.

예계획의 다음과 같을 수 있습니다.

1. 모듈 5와 2는 관련된 모든 테스트 케이스를 테스트하여 철저히 테스트합니다. 다른 모듈은 탐색 기반으로 테스트됩니다.
2. 모듈 5와 2가 먼저 테스트되고 사용 가능한 시간에 따라 다른 모듈이 처리됩니다.

계획이 수립되면 모든 팀이 합의에 도달하고 그에 따라 위험 요소를 고려하여 제품을 테스트합니다.

그게 다야!

참고해야 할 몇 가지 중요한 사항 :

• 이것은 집단 활동이기 때문에 모두의 의견을 고려 ; 정확하고 효과적 일 가능성이 더 높습니다.
• 이것은 공식적인 방법이 아니다 모든 QA 프로젝트의 일부일 필요는 없습니다.
• 때로는 팀이 테이블을 그리지 않고 값을 할당하지 않기로 선택하더라도 간단한 브레인 스토밍 세션 모두 참석하면 QA 팀에게 진행 방법에 대한 좋은 방향을 제시 할 수 있습니다.
• 그만큼 개발팀의 의견 그들은 제품을 만드는 사람이기 때문에 매우 중요합니다. 그래서 그들은 무엇이 효과가 있고 어떤 것이 추가 검사가 필요한지 알게 될 것입니다. 그것을 조심하십시오.
• 프로세스에는 여러 단계가 있지만 이를 수행하는 데 상당한 시간이 걸리지 않습니다. . 특히 모든 팀이 함께 앉아 동시에 일할 수 있다면.
• 이 과정과 그 결과는 유일한 대안 . 테스트를 위해 계획된만큼 많은 시간을 확보하는 것이 QA 활동을 수행하는 가장 좋은 방법입니다.

결론

위험 기반 테스트 접근 방식은 테스터의 초점이 심각도 및 우선 순위에 관계없이 결함을 계속 탐색하는 것이 아니라는 것을 분명히 나타냅니다. 이제 상황이 바뀌었고 테스터는 현명하게 작업해야하며 '고객의 요구 사항과 사용자의 요구 사항'을 명확하게 이해해야합니다.

그들은 제품을 철저히 연구하고 생산에서 가장 자주 사용되는 기능이 수익 창출에 가장 중요한 경로이며 생산 문제와 비즈니스 위협으로부터 고객을 보호하고 보호하는 방법을 이해해야합니다.

따라서 RBT 접근 방식은 모든 것을 테스트하거나 광범위하게 테스트하는 것이 테스트가 완료되었거나 제품에 결함이 없음을 의미하지 않는다는 3 명의 테스터를 명확하게 교육합니다. 규정 된 시간에 효과적으로 테스트하고 중요하고 중요한 비즈니스 영향이 무효화되는지 확인하고 이는 테스터에게 매우 중요합니다.

따라서 위험 기반 테스트는 QA 팀이 프로젝트 위험을 기반으로 프로젝트 이해 관계자를 안내하는 가장 효율적인 도구입니다. RBT 접근 방식은 QA 팀이 전반적인 프로젝트 목표 및 목표 달성을 위험에 빠뜨릴 수있는 위험과 해결 방법을 지속적으로 파악하고 QA 그룹의 궁극적 인 목표를 달성하는 데 도움이됩니다.

추신 QA와 테스트라는 단어는 문서 전체에서 같은 의미로 사용되었습니다.

저자 정보 : 이 기사는 여러 STH 팀원 인 Gayathri Subrahmanyam과 Swati S가 작성했습니다.

Gayathri는 소프트웨어 테스트 분야에서 20 년 이상의 경험을 보유한 소프트웨어 테스트 SME이며 여러 계약에서 테스트 산업화의 일환으로 '위험 기반 테스트'접근 방식을 광범위하게 채택했으며 테스트 리소스 최적화 및 품질 테스트의 이점을 실현했습니다.

위험 기반 테스트가 어려운 일 이었습니까? 튜토리얼에 추가 할 흥미로운 사실이 있습니까? 아래 댓글란에 자유롭게 의견을 남겨주세요 !!

=> 전체 테스트 계획 자습서 시리즈를 보려면 여기를 방문하십시오.

추천 도서

• 지속적인 통합 프로세스 : 소프트웨어 품질을 개선하고 위험을 줄이는 방법
• FMEA (고장 모드 및 영향 분석) – 더 나은 소프트웨어 품질 및 만족스러운 고객을 위해 위험을 분석하는 방법!
• 위험 기반 테스트에 대한 궁극적 인 가이드 : 소프트웨어 테스트의 위험 관리
• 상위 10 가지 위험 평가 및 관리 도구 및 기법
• 소프트웨어 프로젝트의 위험 유형
• 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
• 경력으로 소프트웨어 테스트 선택
• 소프트웨어 테스팅 과정 피드백 및 리뷰