Smc1st2011.03.14 00:02

온오프믹스를 이용하면 10분 추첨을 통해 무료로 볼수있다네요!
온오프믹스 주소 : http://onoffmix.com/event/2490


Posted by SMC1st
Study2011.02.01 00:43

-Smc1st 강다솜

경계값 분석은 대표적인 명세 기반 기법(specification-based technique)중 하나로, 등가 분할의 경계부분에 해당되는 입력값에서 결함이 발견될 확률이 경험적으로 높기 때문에 결함을 방지하기 위해 경계값까지 포함하여 테스트하는 기법입니다.

결함 발견율이 높고, 적용하기 쉬운 장점이 있어 가장 많이 사용되는 테스트 기법 중 하나입니다.

경계값 분석은 Boolean variables에는 적합하지 않으며, Boolean variables의 경우 decision table-based testing을 하는 것이 더 좋습니다.

경계값 분석은 경계의 범위 및 보장하는 범위 등에 따라 다양한 종류가 존재할 수 있는데 그 중 몇가지를 정리해 보았습니다.

 

1.1   Boundary Value Analysis

먼저 Robustness testing입니다. 만약 x1, x2 두 값이 각각 아래의 범위안에 존재할 때,


Boundary Value Analysis 에서는 test cases가 경계선에서의 min, min+, normal, max-, max value로 산출되는데 이때 test case의 개수는 4n+1 개입니다. 이것을 그림으로 나타내면 아래와 같습니다.

 

 

1.2 Robustness Testing

Robustness testing boundary value analysis에서 약간만 확장된 개념으로, max+ 값만 더 추가됩니다. 그림으로 나타내면 아래와 같습니다.

 


Robustness Testing
의 가장 흥미로운 점은 값이 maximum을 초과했을 때 일어날 수 있는 일들을 생각해보면 알 수 있습니다. 만약 비행중인 비행기 날개의 각도가 허용범위를 초과했다면, 그 비행기는 실속(stall) 되고 말 것입니다. (실속상태를 그대로 방치해두면 스핀과 같은 위험한 상태에 빠질수도 있습니다.) 또한 엘리베이터가 수용할 수 있는 용량이 초과되거나, 달력에서 5 32일과같은 날짜가 나올 경우 우리는 error message를 기대하게 될 것입니다.

 

이처럼 Robustness Testing을 사용하면, max+ 값을 테스트 함으로써, 예외사항들을 다룰 수 있게 되며, 보통 경계값 분석을 한다고 하면 이러한 Robustness Testing 기법을 사용합니다.

 

1.3   Worst-Case Testing

전기회로 분석에서, 하나이상의 값이 extreme value일 때 우리는 이것을 ‘worst-case analysis’라고 부릅니다. Worst-case testing에서 각각의 valuemin, min+, nom, max-, max 이렇게 5개의 요소가 세트로 이루어져 있습니다. 그림으로 나타내면 아래와 같습니다.


boundary value analysis test case Worst-case test case 하부에 속해있다고 할 수 있을 정도로 Worst-case test caseboundary value analysis 보다 더 철저합니다. 이는 Worst-case testing이 더 많은 노력을 필요로 한다는 것을 의미하며, Worst-case testing에서는 개의 test case가 산출됩니다.

 

1.4 Robust worst-case testing

만약 편집증(paranoid)에 가까운 testing을 하기 위해서는 robust worst-case testing을 해야합니다. Robust worst-case testing robustness testing 기법 안에서 7가지 요소가 세트로 이루어져있습니다. 그림으로 나타내면 아래와 같습니다.

 


1.5 Random Testing                            

만약 x가 아래와 같을 때,

  


a
b값 사이에서 Random value를 발생시키기 위해선

 

 


수식을 이용하면 됩니다. (엑셀기준) Random Selection에 대해 더 자세한 내용은, @OEHAN님의
Random Selection by Statistical Usage(http://noogabar.com/3)을 참조하면 좋을 것 같습니다.

 

경계값 분석이 사용하기 용이하고 활용도가 높은 기법이기는 하지만 아래와 같은 한계점을 지니고 있습니다.

 

 

1.     일련의 동작에 대한 조합을 테스트하기에는 적합하지 않다.

2.     입력 범위를 등가 분할하여 제한하더라도 입력값 조합의 수가 테스트 가능한 수를 넘어서는 경우가 많다.

3.     입력 조합이 상호간에 독립적이라는 가정에서만 적합한 기법이다.

4.     출력이 입력조건이나 변수들 사이의 관계에 따라 달라지는 경우, 입력 조건을 등가분할하는 것이 매우 어려울 수 있다.

 

위 내용은 개발자도 알아야할 소프트웨어 테스팅 실무, 2, 권원일 외 3‘Software Testing A Craftsman’s Approach, Second Edition, Paul C. Jorgensen’에서 발췌하여 작성한 것입니다.



'Study' 카테고리의 다른 글

경계값 분석(Boundary value analysis)  (0) 2011.02.01
BVT  (0) 2010.12.30
리스크 기반 테스팅(Risk-based testing)  (0) 2010.08.31
탐색적 테스팅(Exploratory testing)  (0) 2010.08.29
테스트 케이스(Test Case)  (0) 2010.08.22
인지부조화 '내 코드엔 문제가 없어!'  (0) 2010.08.08
Posted by SMC1st
Study2010.12.30 20:19

BVT

-Smc1st 강다솜

BVTBuild Verification Testing의 약자로, 빌드가 새로 나올 때 해당 빌드가 테스트를 계속 진행할 가치가 있는지를 판단하기 위해 수행되는 테스트 입니다.

 

BVT TCL(Test Case List)이 작성된 후에 TCL중 중요기능을 추려서 작성하게 되는데, 이때 추려진 케이스는 다른 케이스들과의 의존성이 없도록 독립적으로 만듭니다. 또한 BVT에 투입할 수 있는 시간이나 직원 등의 리소스도 고려하여 만듭니다.

 

참고 MS BVT속성

1.     모든 것을 자동화 하라.

2.     일부만 테스트 하라.

3.     신속하게 테스트 하라.

4.     실패를 정확하게 인지하라.

5.     깊게가 아닌 넓게 테스트 하라.

6.     디버그와 유지 보수가 용이하게 하라.

7.     신뢰할 수 있어야 한다.

 

이렇게 작성된 BVT 내용 중 하나라도 테스트에 실패하면, 더 이상의 테스트를 진행하지 않기 때문에 BVT 요소 선정 시 개발팀과의 협의가 필요하며, BVT를 수행할 시 테스트와 개발에 있어서 불필요한 리소스 낭비를 줄일 수 있다는 이점이 있지만, 프로젝트 상황에 맞춰서 최대한 신속하게 끝내는 것도 중요합니다.

'Study' 카테고리의 다른 글

경계값 분석(Boundary value analysis)  (0) 2011.02.01
BVT  (0) 2010.12.30
리스크 기반 테스팅(Risk-based testing)  (0) 2010.08.31
탐색적 테스팅(Exploratory testing)  (0) 2010.08.29
테스트 케이스(Test Case)  (0) 2010.08.22
인지부조화 '내 코드엔 문제가 없어!'  (0) 2010.08.08
Posted by SMC1st
영상처리 알고리즘에는 '화소 점 처리', '영역 처리', '기하학적 처리', '프레임 처리' 등이 있다. 더 복잡하고, 다양한 기능을 구현 할 수 있는 알고리즘들이 있겠지만, 하위 알고리즘들이 존재함을 감안하면, 간단한 영상 편집 도구 구현은 이 알고리즘든 만드로 충분히 구현이 가능하지 싶다. 
 지금부터 소개할 '영상 회전' 기능은 '기하학적 처리'에 해당한다. 영상을 임의의 방향으로 임의의 각도만큼 회전시키는게 회전 기하학적 변환이다.  우리가 디지털 기기로 디지털 영상을 생성 했을 경우 방향을 바꾸기 위해 시계방향이나 반 시계 방향으로 회전하는데, 이때 쓰이는 기능이다. 영상 회전은 생각만큼 간단하지 않다. 따라서 우리가 영상회전 시 알고 있어야 할 주의사항을 중심으로 나열하겠다.

* 홀 문제 해결하는 방안
영상회전을 위해선 공식이 적용된다.  영상회전을 위해선 변화된 좌표를 이용하고, 영상을 회전시키는 작업이 필요하다. 처음 원시영상에 공식과 좌표변환(이 부분은 전공 내용이므로 넘어가자)를 거치면 화소값을 배정 받지 못한 빈 화소가 나타난다. 이렇게 빈 화소, 즉 '홀'이 발생할 경우 화소가 값을 할당받지 못하여 영상의 품질이 떨어진다.


 우리가 앞으로 주의하여 테스팅 해야 할 부분이 여기에 있다. 영상을 회전 할 경우 '홀 문제'가 발생하는가의 여부이다. 이는 보간 기술을 적용하지 않은 미숙한 알고리즘들을 적용할 경우 나타 날 수 있다.  다행히, 앞서 '포토상추'를 실행해 본 결과 '홀 문제'는 발생 하지 않은 것을 확인하였으니, 안심하고 넘어가도 좋을 듯 하다.

* 회전결과 보이는 부분이 줄어드는 것을 방지하는 방법 
 영상 회전 구현 시 가장 구현이 어려운 부분이다. 원점을 기준으로 회전하는 경우 영상의 일부가 잘려나가는 현상이 나타난다. 이는, 영상의 질을 떨어뜨리므로, 화소의 좌표가 음수가 되지 않도록, 개발자는 주의해야 한다. 

하지만, 회전의 기준을 영상의 중심점으로 변경하면 결과 영상의 좌표값 대부분이 양수여서 적은 부분만 잘려나가지만, 영상의 모서리가 잘려나간 것을 확인 할 수 있다.  회전 기하학적 변환에서 입력 영상과 출력 영상의 크기를 같게 했기 때문에 출력영상에서 잘려나가는 부분이 발생한 것이다. 
이를 해결 하기 위해선, 출력영상에서 잘려나가는 부분이 없게, 출력의 영상 크기를 미리 계산해야 한다. 출력 영상의 크기는 회전 각도로 결정한다.  

<출처 : 디지털 영상처리 입문, 한빛미디어>
Posted by SMC1st
'포토상추'에서 색상>선명을 조절하는 기능에 관한 내용이다.

선명을 조절하는데 있어서 '선명'과 '노이즈' 두 가지 옵션이 있다. 여기서 선명은 '샤프닝', '노이즈'는 블러링 효과라고도 불린다.

* 선명 
'샤프닝' 은 디지털 영상에서 상세한 부분을 더욱 강조하여 포현할 수 있다. 영상의 상세한 부분은 저주파 성분만 제거함으로써 효과를 얻을 수 있다.  이 부분은 너무 깊은 내용이므로 제외하도록 하겠다. 앞으로 우리가 주의해야 할 부분은 '선명' 기능 테스트시 값을 높혀 주었을때 상세한 부분이 더욱 강조되는지를 확인해야 한다.


샤프닝 효과가 적용된 사례 : 경계선이 더 선명해 졌다
<출처 : http://donghuna.com/35>


* 노이즈 
블러링은 샤프닝과 반대로 영상의 세밀한 부분을 제거하여 영상을 흐리게 하거나 부드럽게 하는 기술을 말한다. 영상의 세밀한 부분은 주파수축에서 보면 고주파 성분인데, 블러링은 이 고주파 성분을 제거해 준다. 이 효과를 주었을 때 안개가 낀 것처럼 흐려짐을 알 수 있다.

<출처 : 디지털 영상처리 입문, 한빛미디어>
Posted by SMC1st
이미지 편집을 해 본 사람이라면 디지털 기기(디지털 카메라, 스캐너 등)을 통해 읽어들인 이미지의 밝기나 명암이 낮아 편집을 해 본 경험이 있을 것이다. 그렇다면 '밝기'와 '명암'은 무엇일까?
'포토 상추'에서는 '채도', '명도', '대비'를 변경하는 메뉴가 있는데, 제품을 접하기 전에 이 개념에 대하여 명확히 알고 넘어가자.

1. 기본 개념
* RGB 모델 
 이미지를 이루는 하나의 점을 '화소'라고 한다. 이 화소는 0~255의 값(256단계)을 갖고 있는데,  0번은 검정색 최대값 255는 흰색을 나타낸다. 참고로, 이미지는 그레이 영상과 컬러 영상이 있다. 그레이레벨 영상은 색은 없고 밝기만 있을 뿐이다. 

RGB컬러 모델이라고 들어 보았는가? 간단히 설명하자면, 컬러 영상을 표현하기 위한 컬러 모델은 다양하다. 그 중 디스플레이 장치에 많이 쓰이는 RGB모델이 잘 알려져 있다. R은 Red, G은 Green, B는 Blue을 가리킨다. 예를 들어  R(1,0,0)는 Red를, G(0,1,0)은 Green을 B(0,0,1)을 나타낸다. 따라서 (1,1,1)은 R,G,B를 모두 합친 흰색이 된다. 

* 밝기
앞에서 잠깐 설명 했듯이 화소는 0~255의 256가지 값을 갖고 있다.  이 값이 RGB의 값으로 나타날 경우 (255,0,0)이라 하면 가장 밝은 빨간 색을 나타내게 된다. 

* 명암
 밝기와 구분 하기 혼동되는 개념이 '명암'이 아닐까 한다. 밝기는 영상 전체적인 값이 높은 것이고 명암은 영상의 어둡고, 밝은 정도를 의미한다. 따라서 명암 대비라 함은 가장 '어두운 값'과 '밝은 값'의 차이를 의미 한다. 이 대비는 영상의 품질을 결정하는 중요한 요소이다. 만약,  영상이 높은 대비를 보인다면 어두운 명도와 밝은 명도의 차이가 커서 시각적으로 좀더 명확하게 보인다. 반면, 낮은 대비를 보이는 디지털 영상은 시각적으로 명확하지 않다. 

 2. 디지털 영상의 밝기와 명암은 어떻게 만들어 지는가?
 영상을 시청하다가 전체적으로 '밝게' 해주거나 '콘트라스트 조정'이라는 메뉴를 조절 해 주는 경우가 있다. 보통 영상을 조정할 때 밝기 보다는 명암 대비를 조절하면 시각적으로 효과가 더 좋은데 이는 인간의 눈이 밝기의 차이에 더 민감하기 때문이다. 그렇다면 이 밝기와 콘트라스트는 어떻게 구현 되는 기술일까?

* 밝기 연산 
 앞에서 말했듯 화소는 값을 갖고 있다. 화소의 밝기 값에 특정한 상수를 더하면 값은 255에 가까워져 화소는 밝은 값을 갖게 된다. 만약, 상수를 빼면 0에 가까워져 어두워 지는 것이다. 화소의 집합인 영상에 일정 상수를 일률적으로 더하거나 빼주면 영상의 밝기가 조절 된다. 

화소 + 상수 : 영상의 밝기 증가 = 밝아짐
화소  - 상수 : 영상의 밝기 감소 = 어두워짐 

* 명암 연산 
명암의 차이가 커지면 대비가 커져 영상이 조금 더 선명하게 보이게 된다(밝은데는 더 밝게, 어두운데는 더 어둡게 하기 때문에).
따라서 화소의 최소값과 최대값의 편차를 크거나 작게 하기 위해서 일정 상수 값을 곱하거나 나눌 수 있다. 예를 들어 영상내 화소의 최소값이 5, 최대값이 45일때 밝기의 차이는 40이 된다.  이 영상의 화소값에 2를 곱하면 최소값은 10, 최대값은 90. 즉, 대비가 80이 된다. 밝기의 차이가 커지므로 영상의 선명도 또한 증가 한다.

화소 * 상수 : 영상의 밝기 차이 증가 = 뚜렷해짐
화소 / 상수 : 영상의 밝기 차이 감소 = 희미해짐

이상으로, 영상에서 밝기와 명암조절이 어떻게 연산되는지 알아 보았다. 

'포토상추'에서 테스트를 할 경우 스크롤 바를 조절했을 때 옮긴 값 만큼 밝기나 명암 조절이 정상동작 하는 가에 방향을 두어야 하겠다. 


<출처 : 디지털 영상처리 입문, 한빛미디어>
Posted by SMC1st
서론
'포토상추'는 간단하게 이미지를 편집할 수 있는 툴 입니다.

윈도우즈에 탑재되어 있는 '그림판' 보다는 다양하고,  Adobe의 포토샵 보다는 가볍고 기능도 적습니다.  간단한 이미지 편집 기능이 필요한 사용자에게는 유용할 것으로 보입니다.

본 포스트는 테스트 계획을 세우기 이전에 제품에 대한 이해를 돕기 위한 목적으로 만들어 졌습니다.

'포토 상추'에서 구현된 이미지 편집 기능은 다음과 같습니다.

* 이미지 크기 조정 
  - 픽셀 조정
  - 너비/높이 조정 두가지 방법
* 이미지 회전
* 이미지 확대 / 축소
* 이미지 색상 조정
  - 색상(RGB 조정)
  - 채도
  - 노출  (명도 / 대비)
  - 선명 (선명 / 노이즈)

제품을 이해하는 차원에서 이미지/영상 처리 이론의 내용을 간단히 알아보도록 하겠습니다. 






Posted by SMC1st
Smc1st2010.10.05 23:20

드디어 올것이 왔습니다!!! 생각만해도 설레는 군요..

이번 컨퍼런스는 올해들어 국내 최대규모로 진행되는 마지막 테스팅 관련 행사라고 합니다.
'SW테스팅, MS에선 이렇게 한다'의 저자 BJ Rollison ISTQB위원장 Yaron Tsubery
해외 테스팅 전문가들이 드디어 한국에 옵니다.


안녕하십니까? . 2010년 가을, 선진국의 SW 테스팅 전문가들이 2년 만에 한국을 방문합니다. IT와 비IT산업간의 융합으로 발생되는 시너지 효과의 극대화스마트폰 등 최신 소프트웨어의 품질 경쟁력 확보를 위해 그 어느 때 보다 SW테스팅이 중요한 시점입니다. 해외의 테스팅 전문가들로부터 선진이론과 사례를 배워 귀사의 테스팅 수준을 국제 수준으로 끌어올릴 수 있는 좋은 기회이오니 많은 참여 바랍니다.
주      제 : Advanced Testing Experience for IT Convergence
일      정 : 2010. 10. 18(월) ~ 10. 20(수) (18, 19일 튜토리얼/20일 컨퍼런스)
장      소 : 튜토리얼 - 구로 STA 교육장 (약도보기)
  컨퍼런스 - 잠실 한국광고문화회관 2층 대회의실 (약도보기)
참여 대상 : 테스트 매니저/엔지니어, 개발자/ PM, QA 매니저/엔지니어, 기술지원등
 
SW품질과 관련된 모든 분
참  석  비 : 튜토리얼 - 275,000원/1일, 550,000원/2일(VAT 포함)
  컨퍼런스 - 조기등록 155,000원(10월 7일까지 신청자에 한함), 정상등록 195,000원
  ※ 튜토리얼 수강자는 컨퍼런스 참가비용을 할인해드립니다.
     (1일 수강: 정상가의 25% 할인 / 2일 수강: 정상가의 50% 할인)

주제별 요약보기       각 주제를 클릭하시면 상세 내용을 보실 수 있습니다.  
※ 통역은 제공되지 않습니다. ※ 각 튜토리얼의 정원은 24명이며, 교재 및 중식 제공됩니다.  
주제별 요약보기
       각 주제를 클릭하면 상세 내용을 볼 수 있습니다.  
세 션/시 간
주 제
발 표 자
09:00 ~ 09:20
Registration
-
09:20 ~ 09:30
개회사
Yaron Tsubery
Session 109:30 ~ 10:00
BJ Rollison
Session 210:00 ~ 10:45
Geoff Thompson
10:45 ~ 11:00
Break
 
Session 311:00 ~ 11:45
Tsuyoshi Yumoto
Session 411:45 ~ 12:30
Yaron Tsubery
12:30 ~ 13:30
Lunch
-
Session 513:30 ~ 14:20
BJ Rollison
Session 614:20 ~ 15:10
Eric Riou
15:10 ~ 15:30
Break
-
Session 715:30 ~ 16:20
Klaus Olsen
Session 816:20 ~ 17:10
Stuart Reid
17:10 ~ 17:30
경품 추첨
 
※ 동시통역 제공됩니다. ※ 위 프로그램은 주최측의 사정에 의해 변경될 수 있습니다. ※ 프로그램북 및 중식(식권), 추첨을 통한 경품이 제공됩니다.  
주차는 지원되지 않사오니 대중교통을 이용하여 주시기 바랍니다.
현장 등록은 받지 않습니다.
프로그램 및 접수관련 문의 : 02-890-8459 / seminar@sta.co.kr
세금계산서 관련 문의 : 02-890-8456 / accounting@sta.co.kr

아이팟터치 4세대(32G) 1대
USB 메모리 16G 3대
SW테스팅 MS에선 이렇게 한다 10권 (에이콘협찬)
개발자도 알아야 할 SW 테스팅 실무3판 3권
CGV 영화관람권 3매
RADAR (리스크 분석 및 전략수립 도구) 2copy
SW 테스팅 교육 할인 쿠폰 2매
스타벅스 상품권 3매

Introduction to More Effective Test Automation - 마이크로소프트 Top 테스트 아키텍트가 보는 MS의 실무적 테스트 자동화TMMi in Action-See it and Use it! - TMMi저자가 이야기하는 TMMi실무를 통한 테스팅 프로세스 진단 및 개선Risk-Based Testing(ISO테스팅 국제표준화 위원장이 실무에서 활용하는 리스크 기반 테스팅의 핵심)BJ Rollison 튜토리얼(SSTC 2010)신청하기Geoff Thomson 튜토리얼(SSTC 2010)신청하기Stuart Reid 튜토리얼(SSTC 2010)신청하기

Posted by SMC1st
Alzip 첫번째 Test Plan에 대해 받은 피드백을 정리한 것입니다. 

1. 압축샘플에 대한 정보가 빠져있다.
2. 설계기법을 다 적용하려하기보다는 한군데라도 적용해 보려는 노력이 중요하다. 
3. 목적은 goal과 Non-goal을 명확하게 해야한다. 뻔한 목적은 목적이 아니다. (범위도 마찬가지) 
4. 작성한 표1은 보기가 힘들다.
5. 계획서에 약자나 약어를 사용할 경우에는 주석을 달거나 괄호안에 정식 명칭을 달아주어야 한다.
6. BVT에서 항목이 모호하다(내용) 리스크 테이블의 경우 리스크가 높은 항목은 더 잘보이게 해준다. 
7. 4번5번 항목은 생각과 고려사항이 더 필요하다. 일반적이고 그다지 강한 규칙으로 보이지 않는다. 
8. 산출물이 좀 많다. 학습이 목표라면 현재 Plan에 적혀있는 산출물들을 조합해서 나은 효과를 볼 수 있도록 한다. 
9. 제품을 계획하기 이전에 제품의 대상이 무엇인지 항상 생각해본다. 
10. 샘플이 필요한 Test라면, 샘플이 차지하는 비중도 무시할수 없다.
11. 문서간의 관계가 계획서에 포함된다면 더 좋을것 같다.
12. IEEE829나 830의 테스트 문서 표준을 참조해서 본다. 610도 함께 참조한다.
13. 계획은 실행을 전제로 하는 것인데, 실행을 하려면 사실에 기반하여야 한다. 실제 조직에는 실행에 영향을 주는 변수들이 있다. 조직구조나 프로젝트의 제약조건, 사용자(고객) 등.. 실제 조직처럼 쓰고싶으면 이런부분도 정해야 한다. 
14. 오프라인 리뷰를 해보는것을 추천한다. 예를들어 ㅇ리시중지 조건같은건 매우 민감한 문제이다. 따라서 무슨 의미인지 해석의 여지가 없도록 명확해야 한다. 
15. 다 만들어져서 정식 릴리즈가 된 제품을 테스트 하는 것인지 아니면 프로젝트 초반의 요구분석 단계라고 가정하고 플랜을 작성한다는 의미인지 모호하다. 둘중 어느쪽인가에 따라 내용이 완전히 달라져야 한다.

처음 작성해본 플랜에 대해 의견을 주신 분들(@vbb001 @murianwind @mygihwan @tomais @will_story @jungho83 @jongkwan) 모두 감사드립니다. 

Posted by SMC1st
Study2010.08.31 15:08
- Smc1st 강다솜

리스크 기반 테스팅은 Smc수업내용과, '개발자도 알아야할 소프트웨어 테스팅 실무' , benchmark QA의 'Suffering from Release Remorse?' 라는 ppt내용을 참조하여 작성하였습니다. (대부분의 자료는 개알책에서..)

소프트웨어 테스팅은 제한된 시간, 인력, 장비 등의 리소스로 제품의 리스크를 최소화(고품질의 소프트웨어)하기 위한 일련의 활동이며 그러기 위해서는 효과적이고 효율적으로 테스트가 이루어져야 합니다.

여기서 효과적(Effective)인 테스트와 효율적(Efficient)인 테스트의 차이점을 아시나요? 

효과적인 테스트는 '결과' 중심으로, 테스터는 테스팅 노력으로부터 어떤 결과를 산출할것인지를 결정합니다.
반면에 효율적인 테스트는 '과정' 중심입니다. 가용한 리소스(시간, 자금, 인력)을 적절하게 배치함으로써 과정을 효율적으로 수행할수있도록 합니다. 

리스크 기반 테스트(Risk based testing)는 바로 이 효과적이고 효율적인 테스트를 위한 최적의 테스트 방법이라고 하네요!

※ benchmarkQA에선 리스크와 리스크 기반 테스트를 아래와 같이 정의하고 있습니다.
 Risk : "Event" that might occur that would have negative impacts to the project or product.
 Risk-based Testing : Prioritization of the testing effort in general, and also the specific features and functions to be  tested, based on the identified risks.

리스크는 발생가능한 잠재적인 문제입니다. 이 안에는 어떤 위험요소(Hazard)나 위협(Threat) 혹은 상황의 발생 가능성과, 발생했을 경우의 바람직하지 못한결과들이 포함됩니다.

레이놀즈(Raynolds)는 리스크를 '장애(Failure)로 인해 주어진 기간에 발생하는 비용'으로 정의하고, 아래와같이 산출하였습니다.

리스크(Risk) = 장애(Failure)가능성 * 손실(Damage) [Reynolds, 1996]

여기서 장애가능성은 사용 빈도(Frequency of use)와 결함가능성(Chance of defect)를 곱한 값으로 볼 수 있으므로, 
리스크를 아래와 같이 산출할 수 있습니다. 

리스크(Risk) = 사용빈도(Frequency of use) * 결함 가능성(Chance of defect) * 손실(Damage)

※ benchmarkQA에서 말하는 Risk-based Testing을 해야하는 이유.
 1. Software system architectures have become increasingly complex.
 2. Software products have become increasingly feature-robust.
 3. Over time there are more and more versions of operating environments to consider (browsers, operation system,     
    mobile devices)
 4. Increased demand for shorter delivery cycles.
 5. Exhaustive testing is simply not feasible.

리스크 기반 테스팅은 프로젝트 초기 단계부터 리스크에 미리 대처할 수 있게 하여 제품의 여러 리스크들을 줄여줍니다.
그렇다면 지금부터 소개해드릴 방법은 가장 실무적이고 적용성이 검증된 것중의 한가지라는 리스크 관리(Risk management) 
방법입니다.

그림1. Risk-based testing management (참고로 'Monitor Risks'는 임의로 작성한 것입니다.)

먼저 리스크 식별(Risk Identification) 단계입니다.
리스크를 식별하는 일반적인 방법은, 기능적 또는 기술적 아이템으로 분리하여 각각의 아이템에 리스크가 존재하는 것으로 보는 것입니다. 이밖에도 요구사항에 따른 상위레벨 테스트 관련 항목과 아키텍처에 따른 테스트 관련 항목들을 도출하면 이것들도 리스크 아이템이 됩니다.

표1. 식별된 리스크(리스크 아이템 결정)

리스크 아이템을 식별할땐 브레인스토밍 세션을 이용할수도 있으며, 실무 적용성을 높이기 위해 리스크 아이템은 35개 이하로 
선정하는 것이 좋다고 합니다.

다음은 리스크 분석(Risk analysis) 단계입니다.
리스크 분석단계에서는 리스크 요소(Risk Factors)를 결정한 후 이해관계자(Stakeholders)를 참여시켜 리스크 테이블을 작성한 후 장애 발생 가능성(Likelihood)와 장애로 인한 영향(Impact)를 식별하고 리스크 우선순위를 결정합니다.

리스크 요소는 위 표1처럼 장애발생가능성과 영향으로 분리하여 도출할 수 있는데, 이 때 각각의 리스크 요소는 상황에 맞게
변형시킬 수 있고, 가중치(Weightings)를 적용하는 것도 가능합니다.

리스크 요소가 결정되었으면 리스크 아이템별로 해당 리스크 요소가 어느 정도의 리스크 레벨이 되는지를 결정합니다.
이때, 이해관계자의 참여가 필수적인데 이들에게 리스크 레벨 결정을 요청하면 모두 리스크가 높고 중요하다고 답변하는 것이
일반적이므로, 신중하에 의견을 모아야 합니다.

이때 리스크 레벨 선정의 변별력을 높이고 리스트가 높은 것을 낮은 것과 확실히 구분하기 위해 아래의 스케일(Scale)을 
사용하는 것이 좋습니다. (해당 스케일은 프로젝트의 성격과 조직의 특성 등을 반영하여 변형시켜 사용가능)

리스크 레벨: 9 = 심각(Critical), 5 = 높음(High), 3 = 보통(Moderate), 1 = 낮음(Low), 0 = 없음(None)

 ※ 예전에 Smc1st 팀원들과 함께 리스트 레벨을 협의한 적이 있는데, 이때 카드게임 방법을 사용했었습니다.
    1. 리스크 레벨이 적힌 카드를 팀원의 수만큼 만들어 나눠 갖습니다.
    2. 표1의 각 항목에 대해 팀원이 각각 생각하는 레벨의 카드를 동시에 냅니다. (한 항목씩 모든항목)
    3. 제일 적은 수의 카드를 낸 팀원과, 가장 큰 수의 카드를 낸 팀원이 한명씩 자신이 카드를 낸 이유를 설명합니다. 
       (단, 이때 발표하는 팀원 외에 다른팀원은 어떤 말도 하지 않고 듣기만 합니다.)
    4. 팀원들이 해당 항목에 대해 다시 자신이 생각하는 레벨의 카드를 동시에 냅니다.
    5. 2~3 과정을 만장일치가 될때까지 반복합니다.
    6. 만장일치로 선정된 리스크 레벨을 표1에 작성합니다.

표2. 리스크 테이블 완성예

다음은 리스크 계획 활동(Risk planing) 단계입니다.
리스크 계획 활동은 리스크 정보를 근거로 대처방안을 수립하는, 즉 리스크를 줄일는 '테스트'를 생성하는 단계입니다.
리스크 분석에서 합의/결정된 리스크 아이템별 리스크 요소 총점을 리스크 매트릭스(Risk Matrix)에 표시합니다.


그림2. 리스크 매트릭스(Risk Matrix)예(몇가지의 리스크 아이템만 넣었습니다.)

리스크 매트릭스에서 가운데 논의필요라고 적혀있는 부분과 십자모양의 선에 해당되는 리스크 아이템은, 테스트 전략을 수립할때 논의가 필요한 부분입니다. (1~2점 차이로 반드시 강력하게 테스트해야 하는 부분과, 테스트 하지 않아도 되는 부분으로
나뉠 수 있기 때문입니다.)

- STA(Severs Test Area) : 반드시 테스트 해야함
- STTA(STrong Test Area) : 테스트 해야함
- ITA(Intensive Test Area) : 테스트 함
- FTA(Fundamental Test Area) : 테스트하지 않을 수 있음

※ Risk Matrix를 작성해주는 프로그램을 @OEHAN 님이 엑셀로 작성하여 공유해주신게 있네요! ☞ 요기

리스크 매트릭스의 STA에 해당하는 부분은 우선적으로 주어진 시간과 자원을 고려하여, 공식적인 기법을 적용한 강력한 테스팅을 진행하고, FTA에 해당하는 부분의 경우 자유롭게 시간이 허용하는 범위에서 테스팅을 진행하면 됩니다.

다음은 리스크 추적(Monitor Risks) 단계입니다.
리스크 추적 단계에선 리스크 레벨멸 결함 및 대응 방안을 분석합니다. 테스팅 전략을 수립할땐 테스트 레벨별로 차별화된 전략을 가져갈 수 있습니다. 여기에서는 테스트 레벨을 하위 레벨 테스트(Low level test)와 상위 레벨 테스트(High level test)로 
양분해서 살펴보도록 하겠습니다. 


그림3. 리스크 기반 테스팅 전략 사례(Low level test)

하위 레벨 테스트의 경우 개발 테스팅 중심으로, 기술적인 리스크를 중점적으로 다루므로 위 그림과 같은 우선순위로 
강도를 조정하며 테스팅이 진행되어야 합니다. [Veneendaal, 2006]


그림4. 리스크 기반 테스팅 전략 사례(High level test)

상위 레벨 테스트의 경우 인수 테스팅 중심으로, 사업적 리스크를 중점적으로 다루므로 위 그림과 같은 우선순위로
강도를 조정하며 테스팅이 진행되어야 합니다. [Veneendaal, 2006]


지금까지 소개했던 리스크 기반 접근법은, 공식적인 기법들을 사용하는것 외에도 사용자로부터 보고되었거나, 내부적으로 
보고된 결함 중, 심각하고 높은수정 우선순위로 결정된 기존 결함유형을 반영하여야 합니다.
이밖에도 경험기반기법들을 병행해서 보완해준다면 보다 다양하고 많은 결함을 발견하는데 도움이 될 것입니다.

'Study' 카테고리의 다른 글

경계값 분석(Boundary value analysis)  (0) 2011.02.01
BVT  (0) 2010.12.30
리스크 기반 테스팅(Risk-based testing)  (0) 2010.08.31
탐색적 테스팅(Exploratory testing)  (0) 2010.08.29
테스트 케이스(Test Case)  (0) 2010.08.22
인지부조화 '내 코드엔 문제가 없어!'  (0) 2010.08.08
Posted by SMC1st