'Software Testing/Critical Testing Process'에 해당되는 글 3건

  1. 2009.01.27 FMEA (Failure Mode and Effect Analysis)
  2. 2009.01.22 Quality Risk Analysis Process과 주절주절
  3. 2009.01.21 이제 1장 끝...
아래 포스팅한 글에서 Risk based Testing에 대해서 잠시 언급했었습니다. 
책을 읽다 보니 이 부분에 대한 어느정도 자세한 언급이 나오더군요. Risk based testing에서 가장 중요한 risk를 측정하는 방법에 대한 설명이 있었습니다.
아래 적은 내용 중 일부 내용은 wikipedia에서 참고한 내용도 있습니다.

FMEA는 시스템에서 발생할 수 있는 잠재적인 실패 (Failure Mode)를 분석하여 도출하고, 이에 대한 위험도를 정량화하는 분석작업 중 하나입니다. FMEA는 최종적으로  정량화된 RPN (Risk Priority Number)를 산출하게 됩니다. 

RPN은 높은게 risky하다 혹은 낮은게 risky하다라는 정의는 없습니다. 측정하는 주최가 정하면 됩니다. 즉, 1점이 가장 risky할 수도 있고 만점이 가장 risky할 수도 있습니다. (wikipedia의 점수매김과 제 책의 점수매김이 반대더군요 ^^;)

이 RPN을 결정하는 요소는 다음과 같습니다 (이 부분은 책과 wikipedia에서 말하는 내용이 약간 다릅니다만, 어느정도 일치합니다)
  • Severity - 말그대로 심각도입니다. 이 failure가 발생했을 때, 사용자가 당하게(?) 되는 impact에 따라 분류합니다.
    ex) 1 - Critical, 2 - Major, 3 - Average, 4 - Minor, 5 - Enhancement. (어디서 많이 보던 것이지요 ^^)
  • Priority - Bug의 fix 우선순위 입니다. '반드시 ASAP로 수정해야 함'에서 부터, '다음번 release에 수정해도 됨' 정도로 분류합니다.
    ex) 1 - Urgent, 2 - Essential, 3 - Valuable, 4 - Desirable, 5 - Discretionary
  • Likelihood - 발생 확률입니다. '모든 사용자, 연산시 항상 발생함' 에서 '거의 발생하지 않음' 까지 단계 정도로 분류합니다.
    ex) 1 - Very Likely, 2 - Likely, 3 - Possible, 4 - Unlikely, 5 - Very Unlikely

RPN은 위의 각 요소의 점수를 곱해서 계산합니다. 만약 각 요소가 5단계까지 있다면 RPN은  1점에서 5 x 5 x 5 = 125점의 범위를 갖게 됩니다. 이 때 점수가 낮은 것을 risky하다고 한다면,  1점 (Severity - Critical, Priority - Urgent, Likelihood - Very Likely) 이 가장 risky한 failure mode가 되어 집중적으로 test해야 할 대상이 되는 것입니다. 

이 산출된 RPN의 점수 대역을 분류하여, 얼마나 집중적으로 이 failure mode에 대해서 테스트 할지를 전략적으로 정하게 됩니다. 
예를 들어 RPN 1 ~ 15점까지에 testing resource의 몇 %를 할당함, 머 이런 식으로 하게 됩니다.

이렇게 Risk based Testing에서 risk를 정량화 하는 기법은 FMEA말고도 COE (Cost Of Exposure), ANSI/ISO 9126 등이 있습니다. 참고하세요 ;-)
Posted by yunseong
요새 읽고 있는 Critical Testing Process란 책의 일부를 발췌하여 생각을 적은 글입니다.

이 책에서는 Quality Risk Analysis Process란 과정을 제시했습니다. 
총 6단계로 나누었으며, 내용은 다음과 같습니다. 

  1. 핵심 테스팅 포인트와 품질에 대한 이해관계자를 선별합니다. 이 이해관계자는 품질분석활동에 참여해야 합니다. 
  2. 핵심관계자들과 품질분석활동의 기술과 방법에 대해 조사합니다. 조사가 충분히 되면, 기술을 제시하고, 일치를 이끌어냅니다.
  3. 품질위험에 대해 아이디어를 모으고, 그 위험에 따라 실패했을 때의 상황, 품질의 손상, 그리고 그러한 위험들의 우선순위에 대해 논의합니다.
  4. 분석단계에서 발생했던 놓친 요구사항, 설계문제 등등 다른 문서에서 발생한 초기 버그에 대해 보고합니다.
  5. 기술적으로 도출된 품질위험에 대해 문서화 하고, 이해관계자들에게 그 문서를 배포합니다. 3,4,5 단계를 반복적으로 수행합니다.
  6. 품질위험분석 문서를 프로젝트 문서로 추가하고 변경관리를 합니다. 

대략 위와 같은 내용입니다. 

왜 이런 품질 분석활동을 하는 것일까요? 사실 위의 내용이 나온 chapter 에 잘 설명되어 있습니다. -_-;;, 아니 사실 이 책의 제목을 보면 이미 알 수도 있겠네요. 

"Critical"한 Testing을 하기 위해서 입니다. 중요하고 risk가 큰 부분에 "집중" 하고 많은 resource를 투입하여 Quality의 risk를 낮추자 (mitigate) 라는 것입니다. 결국 "risk 기반 testing"으로 귀결되겠군요. 

"risk기반 testing"에서 risk를 어떻게 측정해야 할까요? 위험도의 기준은 무엇일까요? 흔히 S/W의 목적에 따라 다르다고 합니다. 
당연히 그렇겠죠. 그런 뜬구릅 잡는 대답은 말고 (퍽)

Quality의 위험도를 결정하는 중요한 지표는 빈도가 있을 수 있을 것 같네요. 또... 복구 가능 여부 혹은 대체 가능 여부가 있을 듯 하구요. (지극히 제 개인적인 생각입니다. 이견이나 덧붙이고 싶으신 분은 대환영입니다 ^^)
아, 얼마전에 세미나가서 들은 내용인데 (권원일 님이 발표하신 내용입니다) Business risk와 Technical risk(잘 기억 안남 -_-)로 나눌 수 있다고 하셨었던게 기억이 나네요. 

어찌되었든 이 Quality Risk Analysis Process라는 것은 결국 Risk based testing을 잘 하기 위한 단계로 보이는 군요. 실제 업무에적용가능하다면 적용해보고 그 결과를 이 posting에 덧붙여보아야 겠습니다 ㅋ
Posted by yunseong
Software testing의 대가 Rex Black의 Critical Testing Processes라는 책을 올 1월부터 보고 있습니다.

근데 너무 어렵습니다.  매 문장마다 모르는 단어는 수두룩 하고, 

원래 주어 / 동사 이런 문법 따져가며 읽는 편은 아닌데, 이건 머 도통 이해가 안가는 문장이 한둘이 아니네요 ㅠㅠ

그래도 요약을 굳이 하자면, 1장의 Title은 큰 그림 먼저 보기 입니다.

Test 팀의 프로젝트 전체에서의 위치, 임무, 태도, 팀 내부 관리의 중점, mind 머 그런 내용에 대해 설명하고 있습니다. 

뒤를 쭈욱 훑어봤는데 답답하네요 -_-;;

인내력이 다하면 잠시 이 책을 덮고 다른 책을 봐야 할지도 모르겠습니다. 

벌써 "Metrics and Model in Software Quality Engineering"도 쉬고 있는데... 그 책은 영어도 영어지만

통계 머 이런 내용 (6 sigma, 등등) 이 많다 보니 도통 이해가 안가더군요...

쉬운게 없습니다 ㅠㅠ


I've read the "Critical Testing Process" written by Rex Black, who is most famous in software testing. 
But... it goes over my head!!! I know my english is poor...  but it is too difficult. 
There are so many delicate words in a sentence. 
Actually, i'm not acquainted with strict grammar like which is subject, and verb, but, some sentences are too complicated to me. 
But, positively, to say summary, the title of first chapter is "Start with Big Picture". 
It explains test team's context, task, attitude, management internal team member (testing team). 
i go over beyond this chapter, it make me feel heavy. 
If my patient is gone, i may replace to another book (i already bought a new book named "Host we test software at microsoft" ).
Already i gave up to read "Metric and Models in software Quality Engineering". ;-(. i'm not acquainted with statistics, but it deals with it, like 6 sigma, probability distribution... 

There is nothing to get easily.. T.T


Posted by yunseong
이전버튼 1 이전버튼