최근 많은 사람들이 관심을 가지고 있는 리스크 기반 테스팅에 관해, 렉스 블랙(Rex Black)이 그의 책 『Advanced Software Testing Vol.1 - Test Analyst』에서 설명한 것을 일부 발췌 번역했다.
3.9 리스크[1] 기반 테스팅(Risk-Based Testing)
리스크(Risk)는 부정적이거나 기대하지 않았던 결과(Outcome), 혹은 이벤트가 발생할 가능성을 의미한다. 구체적으로 리스크는 이것이 발생함으로써 고객, 사용자, 프로젝트의 참가자, 혹은 이해당사자들이 가지고 있는 제품의 품질이나 프로젝트의 성공에 대한 인식을 경감시킬 가능성이 있는 모든 문제를 의미한다.[2]
테스팅과 관련되어서는 주로 두 가지의 리스크 유형이 언급된다.
첫 번째 유형의 리스크는 제품 혹은 품질 리스크(Product or Quality risks)다. 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 제품의 품질에 영향을 미칠 때, 그러한 잠재적인 문제들을 제품 리스크(Product risks)라고 부른다. 제품 리스크와 동일한 의미로 내가 자주 사용하는 단어는 품질 리스크(Quality risks)다. 품질 리스크의 예로는, 제품을 사용하는 일반적인 상황 아래서 시스템 크래시를 일으키는 잠재적 신뢰성 결함을 들 수 있겠다.
두 번째 유형의 리스크는 프로젝트 혹은 계획상의 리스크(Project or planning risks)다. 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 프로젝트의 성공에 영향을 미칠 때, 그러한 잠재적인 문제들을 프로젝트 리스크(Project risks)라고 부른다. 프로젝트 리스크의 예로는, 프로젝트의 완성을 연기시킬 수 있는 인력 부족을 들 수 있겠다.
모든 리스크가 똑같이 중요한 것은 아니다. 리스크의 수준을 분류하는 다양한 방법이 존재한다.
가장 간단한 것은 아래의 두 가지 요소를 살펴보는 것이다.
■ 문제가 발생할 수 있는 가능성(The likelihood of the problem occurring)
■ 문제로 인해 발생하는 영향(The impact of the problem should it occur)
문제의 재현 가능성을 예측하기 위해서는 우선 기술적인 측면에서 문제를 고려해 보아야 한다. 제품 개발에 사용되는 프로그래밍 언어나 네트워크의 대역폭(bandwidth)과 같은 것들이 고려될 수 있다. 문제의 영향을 알아보기 위해서는 사업적인 측면에서 문제를 바라보아야 한다. 이 문제로 인해 사업이 겪게 될 재정적인 손실, 문제로 인해 영향을 받을 수 있는 사용자 혹은 고객의 숫자와 같은 것들이 고려될 수 있다.
ISTQB Glosary
리스크(Risk): 향후에 부정적인 결론을 도출해 낼수 있는 요인. 일반적으로 영향(Impact)과 발생가능성(Likelihood)으로 표현된다.
리스크 유형(Risk type): 특정 리스크 카테고리는 그 카테고리를 제어할 수 있는 테스팅의 유형과 관련되어 있다. 예를 들어, 잘못 이해되고 있는 사용자 상호 작용의 위험은 사용성 테스팅을 수행함으로써 감소될 수 있다.
제품 리스크(Product risk): 테스트 대상과 직접 관련이 있는 리스크
프로젝트 리스크(Project risk): 테스트나 프로젝트의 관리 및 제어와 관련된 리스크. 예를 들어, 인력의 부족, 빡빡한 일정, 요구사항의 변경 등.
리스크 기반 테스팅(Risk-based testing): 제품 위험의 수준을 줄이고, 이해 당사자들에게 제품의 상황을 알리기 위해 프로젝트의 초반부터 시작되는 테스팅 기법. 여기에는 제품 위험을 식별하고 이를 테스트 프로세스에 사용하는 것도 포함된다.
리스크 기반 테스팅에서는, 각각의 리스크에 대해 어느 정도의 테스팅이 수행되어야 하는지를 가이드 해주는 리스크 레벨(Level of risk)을 가지고 있는 리스크 아이템을 리스크 분석 프로세스를 통해 식별하고 이를 사용한다. 진정한 의미의 분석적인 리스크 기반 테스팅 전략에서, 리스크는 그 자체로 테스팅의 가장 우선적인 베이시스(Basis)가 되는 것이다.
리스크는 다양한 방법으로 테스팅을 가이드할 수 있는데, 그 중 가장 일반적인 3가지 경우는 다음과 같다.
■ 첫 번째로, 모든 테스트 행위에 걸쳐, 테스트 매니저와 테스트 분석가는 각각의 품질 리스크에 상응하는 리스크 레벨에 적합하게 업무를 할당한다. 테스트 분석가는 각각의 리스크 레벨에 맞는 엄격함(Rigor)과 확장성(Extensiveness)을 가진 테스트 기법을 선택해야 한다. 테스트 매니저와 테스트 분석가들은 가장 중요한 품질 리스크에 대해 테스트를 제일 먼저 수행하고, 덜 중요한 품질 리스크에 대한 테스트는 나중에 수행한다. 테스트 매니저와 테스트 분석가는 결함 수정이 리스크 레벨에 맞게 수행되는 지를 확인하기 위해 프로젝트 팀과 함께 작업한다.
■ 두 번째로, 테스트 계획과 테스트 제어 프로세스가 수행되는 동안, 테스트 매니저는 모든 중요하고 식별된 프로젝트 리스크에 대해 이를 완화할 수 있는 방법과 의도하지 않은 상태에서 이러한 리스크가 발생했을 때 대처할 수 있는 방법을 강구해야 한다. 리스크 수준이 높을수록, 좀 더 철저하게 프로젝트 리스크가 관리되어야 한다.
■ 세 번째로, 테스트 매니저와 테스트 분석가는 잔여 이슈라는 측면에서 테스트 결과와 프로젝트 상태를 보고해야 한다. 예를 들어, 어떤 테스트가 아직 수행되지 않았으며 어떤 테스트가 수행되지 않을 것인가? 어떤 테스트가 수행되었는가? 어떤 테스트가 성공했는가? 어떤 테스트가 실패했는가? 어떤 결함이 아직 수정되지 않았거나 재테스트 되지 않았는가? 어떻게 테스트와 결함이 리스크에 다시 영향을 미치는가?
ISTQB Glosary
테스트 제어(Test control): 개발과 관련있는 테스트 관리 업무로 모니터링을 통해 테스트 프로젝트가 계획되었던 것에서 변경된 것을 보여줄 때 이를 정상적인 상태로 되돌리기 위한 수정 행위를 수행하는 것을 포함한다.
리스크 레벨(Risk level): 리스크의 중요성은 그 영향(Impact)과 발생가능성(Likelihood)에 의해 분류될 수 있다. 리스크 레벨은 수행될 테스팅의 강도(intensity)를 결정하는데 사용될 수 있다. 리스크 레벨은 정성적(예를 들어, High, Medium, Low) 혹은 정량적으로 표현될 수 있다.
진정한 의미의 분석적 리스크 기반 테스팅 전략을 수행한다면, 리스크 관리가 프로젝트에서 단 한 번만 일어나지 않는다는 것이 무척 중요하다. 앞서 언급한 리스크에 대한 3가지 대응은 필요할지도 모르는 모든 다른 행위들과 함께 제품의 라이프사이클 전체에 걸쳐서 언제라도 발생할 수 있다. 테스트 수행과 결함 발견을 통해 품질 리스크를 경감시키고, 우발적 사고에 대응하는 방법을 강구함으로써 프로젝트 리스크를 경감시키려고 노력해야만 하는 것이다. 아울러 프로젝트를 진행하는 동안 정기적으로 새로운 정보에 기반해 리스크와 리스크 수준을 재평가 해야만 한다. 이로 인해 테스트와 결함의 우선순위가 다시 결정되고, 테스트 업무가 다시 조정되어 할당되며, 그밖의 다른 테스트 제어 행동들이 실행된다.
사람들이 이해하기 쉽도록 리스크 기반 테스팅을 보험에 비유하기도 한다. 일상적인 삶 속에서 걱정할만한 잠재적인 리스크가 있을 때 사람들은 보험에 가입한다. 걱정하지 않는 것에 대해서는 보험에 가입하지 않는다. 이와 마찬가지로, 문제를 일으킬 것으로 염려되는 부분의 버그와 해당 영역을 테스트 해야하는 것이며, 그렇지 않은 부분들은 무시하는 것이 리스크 기반 테스팅이다.
이러한 비유로 인해 리스크 기반 테스팅이 잘못 이해될 수 있는데 그 중 하나는, 보험 설계사와 보험 회계사들은 정량적인 리스크 분석을 위한 통계적인 유효 데이터를 사용할 수 있다는 것이다. 일반적으로 리스크 기반 테스팅은 정성적인 분석에 의지할 수 밖에 없는데, 그 이유는 보험 회사가 가지고 있는 데이터와 같은 종류의 데이터를 우리가 가지고 있지 않기 때문이다.
아울러 리스크 기반 테스팅을 진행하는 동안에도 다양한 잠재적인 리스크 요소들이 존재하고 있다는 것을 인식하고 있어야 한다. 어떤 시스템에는 안전과 관련돤 리스크가 있을 수 있다. 대부분의 시스템에는 사업적이고 경제적인 리스크가 존재한다. 또한 많은 시스템에서 개인 보안 혹은 데이터 보안과 관련된 리스크가 존재한다. 기술적, 조직적, 그리고 정치적인 리스크 역시 어디에나 존재하기 마련이다.
3.9.1 리스크 관리(Risk Management)
리스크 관리는 아래의 3 가지 주요 행위를 포함한다.
■ 리스크 식별(Risk identification).
해당 프로젝트의 서로 다른 프로젝트 리스크와 품질 리스크를 구별한다.
■ 리스크 분석(Risk Analysis).
각각 식별된 리스크 아이템에 대해 일반적으로 영향(Impact)과 발생가능성(Likelihood)에 기반해 리스크 수준을 평가한다.
■ 리스크 경감(Risk mitigation).
“리스크 제어(Risk control)”라고 부르는 것이 더 적합할 듯 한데, 여기에는 다양한 리스크들에 대한 경감(Mitigation), 우발적인 발생 가능성(Contingency), 전이(Transference), 그리고 수용(Acceptance)과 같은 행위들이 포함되기 때문이다.
최소한 이러한 행동들이 시작하는 시점을 기준으로 해서 본다면 이러한 행위들은 순차적으로 발생한다고 볼 수 있다. 즉, 리스크 식별이 가장 먼저 수행되고 그 다음 단계들은 순차적으로 수행되는 것이다. 리스크 제어는 리스크 분석 단계에서 리스크 레벨을 결정하고 나서부터 시작된다. 그러나, 리스크 관리는 프로젝트 기간 동안 내내 지속되는 활동이므로 실제로는 리스크 식별, 리스크 분석 그리고 리스크 제어의 행위들은 모두 지속적으로 순환해서 발생한다.
어떤 것들이 리스크에 속하느냐와 같은 리스크의 정의에서부터 시작해, 리스크의 레벨, 그리고 이러한 리스크들에 대한 적합한 조치를 포함해 프로젝트 상에서 어떻게 이런 리스크들을 관리할 것이냐에 대해서는 모든 사람들이 나름대로의 합당한 시각을 가지고 있다. 따라서, 리스크 관리에는 모든 프로젝트의 이해당사자들이 포함되어야 한다.
대부분의 경우, 많은 이해당사자들이 리스크 관리 작업에 참여하지 않고 있고 또한 그러기를 바라지도 않을 것이다. 이런 경우 일부 이해당사자들이 다른 이해당사자들의 입장을 대변하게 된다. 예를 들어, 일반인 대상의 소프트웨어를 개발한다면, 마케팅 팀에서는 잠재적인 결함을 식별하기 위해 소규모의 잠재적 고객 그룹에게 그들이 소프트웨어를 사용할 때 가장 많은 영향을 받는 것이 무엇인지 물어볼 수 있다. 이 경우, 잠재적인 일부 고객들이 전체 고객들을 대변하는 경우라고 볼 수 있다. 이런 또 다른 예로, IT 프로젝트의 비즈니스 분석가는 그들이 주로 참가하는 리스크 분석 세션에서 무엇이 잘못 되어가고 있으며 이로 인해 얼마나 상황이 좋지 않을 수 있는지를 알려주는 스트레스를 주는 동료로서 인식되어 있지만, 이들을 일반적인 사용자를 대변하는 소규모 그룹으로 사용할 수도 있는 것이다.
테스트 분석가들은 그들이 가지고 있는 결함 중심의 시각을 통해 리스크 제어에 기여할 수 있다. 따라서 그들은 언제라도 그들의 여건이 허락한다면 리스크 관리 프로세스에 동참해야 한다. 사실 많은 경우 테스트 매니저들이 품질 리스크 분석 업무를 주도하며, 테스트 분석가들이 이 과정에서 핵심적인 내용들을 제공한다.
앞서 살펴본 리스크 관리의 개요를 마음에 새겨두고, 다음으로 3가지 주된 리스크 관리 행위를 살펴보자.
3.9.2 리스크 식별(Risk Identification)
적합한 리스크 기반 테스팅의 수행을 위해 제품과 프로젝트 리스크를 각기 식별할 필요가 있다.
아래와 같은 기법을 사용해 우리는 이 두 가지 리스크의 종류를 식별해 낼 수 있다.
■ 전문가 인터뷰
■ 독립적인 평가(Independent assessments)
■ 리스크 템플릿 사용
■ 프로젝트 회고(Project retrospective)
■ 리스크 워크샵과 브레인스토밍
■ 체크리스트
■ 과거의 경험 참고
생각해 보니 제품과 프로젝트 리스크를 식별하기 위해 하나의 통합된 프로세스를 사용할 수 있을 것 같다.
나는 일반적으로 이들을 두 가지 개별적인 프로세스로 구별하는데, 그 이유는 그들이 서로 다른 산출물을 내어놓기 때문이다. 나는 프로젝트 리스크 식별 프로세스를 일반적으로 테스트 계획 프로세스에 포함시킨다. 하지만 이와 병행해서, 품질 리스크 식별 프로세스도 프로젝트의 초기에 동시에 진행되어야 한다.
프로젝트 리스크는 단지 테스팅에 국한된 사항이 아니라 프로젝트 전체에 관여된 리스크를 의미하는 것이며, 주로 품질 리스크 분석의 부산물로 얻어진다. 여기에 더해, 만약 요구사항 명세서, 설계 문서(Design specification), 유즈 케이스나 그밖의 문서들을 품질 리스크 분석 프로세스를 위한 자료로 사용하고 있다면, 또 다른 부산물로 이러한 문서들 속에 내재되어 있는 결함도 찾아낼 수 있을 것이다. 이들은 부산물 중에서도 매우 유용한 것들이며 이러한 부산물을 잘 챙겨서 적합한 사람이 처리할 수 있도록 승계해 주어야 한다.
앞서 나는 리스크 관리 프로세스에 모든 가능한 이해당사자 그룹의 대표자를 포함시킬 것을 권장했다. 특히 리스크 식별 과정에서는 가능한 한 많은 이해당사자들이 참가함으로써 더 완벽하고, 정확하며, 정밀한 리스크 식별이 가능해진다. 만약 이해당사자 그룹의 대표자들을 이 프로세스에서 제외시킨다면, 아마 많은 리스크 아이템을 놓치거나 혹은 특정 리스크 카테고리 전체를 식별 과정에서 빠트릴수도 있을 것이다.
이 프로세스를 어느 정도까지 자세하게 진행할 것인가라는 의문이 제기될 수 있다. 이는 어떤 기법을 사용하느냐에 달려있다. 내가 즐겨 사용하는 비공식적인 기법에서는, 리스크 아이템을 일단 식별한 다음 더 이상 자세한 식별 과정을 진행하지 않는다. 그러나 각각의 리스크 아이템을 분석하고 평가할 때, 각각의 리스크가 가지는 발생 가능성과 영향이 서로 애매모호하지 않을 정도로는 자세할 필요가 있다.
좀 더 공식적인 기법에서는 리스크 아이템의 잠재적인 영향들이 실제로 부정적인 결과로 나타날 수 있는지를 식별하기 위해 더 “하위의 것(Downstream)”들을 본다. 이러한 영향들에는 시스템 혹은 거대 시스템(System of systems)에 나타나는 영향들도 포함된다. 뿐만 아니라 잠재적인 사용자, 고객, 이해당사자 그리고 심지어는 일반 사회에 대한 영향들도 포함되는 것이다. FMEA(Failure Mode and Effect Analysis)는 이러한 공식적인 리스크 관리의 대표적인 예이며, 주로 안전 최우선 시스템(Safety-critical System)이나 임베디드 시스템에 사용된다.
리스크의 원인을 식별하기 위해 더 “상위의 것(Upstream)”을 관찰하는 공식적 기법도 있다. 리스크 요소 분석(Hazard Analysis)이 이러한 공식적인 리스크 관리 기법의 대표적인 예이다. 내가 이 기법을 사용해 본적은 없지만, 안전 최우선 시스템인 의료 시스템에서 이를 사용하고 있는 클라이언트와 이에 대해 대화를 나눠본 적은 있다.
3.9.3 리스크 분석 혹은 리스크 평가(Risk Analysis or Risk Assessment)
리스크 관리 프로세스의 다음 단계는 어드밴스드 실라버스에서 리스크 분석(Risk Analysis)이라고 언급하고 있는 것이다. 나는 리스크 평가라는 말을 더 선호하는데, 왜냐하면 분석이란 말에는 식별과 평가의 의미가 모두 포함되어 있기 때문이다. 무엇이라고 부르든 간에, 리스크 분석 혹은 리스크 평가는 식별된 리스크에 대한 조사 작업을 포함한다. 일반적으로 우리는 각 리스크 아이템을 적절하게 분류하고 각각의 리스크에 적합한 리스크 레벨을 부여해야 할 필요가 있기 때문이다.
리스크 아이템을 분류하기 위해 ISO 9126이나 그 밖의 품질 카테고리를 사용할 수 있다. 개인적으로는, 어떤 기준을 적용하는지는 그리 중요한 문제가 아니라고 생각한다. 그러나 크고 복잡한 프로젝트를 수행하거나 대규모 개발 조직인 경우에는, 리스크의 카테고리가 누가 그 리스크를 처리해야하는 지를 지정하는 수단으로 활용될 수 있다. 리스크 분류에는 이러한 실용적인 효과도 있으므로 특정 조건에서는 더욱 중요해질 수 있다.
리스크 평가의 또 다른 단계는 리스크 레벨을 결정하는 것이다.
이 과정에서 발생가능성(Likelihood)과 영향(Impact)이 두 가지 중요한 요소로 다루어진다.
일반적으로 발생가능성은 기술적인 측면에서 리스크를 바라보는 것이고, 영향은 사업적인 관점에서 리스크를 바라보는 것이다.
그럼 발생가능성을 평가할 때 우리가 고려해야 할 기술적인 요소들은 어떤 것들이 있을까?
아래와 같은 것들이 여기에 포함될 수 있다.
■ 기술과 팀의 복잡성(Complexity of technology and teams)
■ 팀 구성원들과 구성원들이 얼마나 훈련되었는지와 관련된 이슈(Personal and training issues)
■ 팀 내외부의 갈등(Intrateam and interteam conflict)
■ 공급자와 회사와의 계약상의 문제(Supplier and vendor contractual problems)
■ 아웃소싱을 포함하는 개발 조직의 지역적 분산 문제
■ 레거시 혹은 자체 개발된 설계 및 기술과 새로운 기술 및 설계의 대립
■ 사용하는 툴과 기술의 품질
■ 잘못된 관리 혹은 기술적 리더십
■ 시간, 리소스 그리고 관리적 압박, 특히 금전적인 패널티가 부과되는 경우
■ 얼리 테스팅과 라이프사이클에서의 QA 활동 부재
■ 요구사항, 설계, 코드의 잦은 변경
■ 높은 결함 발생율
■ 복잡한 인터페이스와 이로 인한 통합 이슈
영향을 평가할 때 고려해야 할 사업적인 요소들은 어떤 것들이 있을까?
아래와 같은 것들이 포함될 수 있다.
■ 영향을 받는 기능들이 얼마나 자주 사용되는가?
■ 이미지에 끼치는 잠재적인 영향
■ 고객 및 사업상의 손실
■ 잠재적으로 발생할 수 있는 금전적 손실 혹은 생태계에 끼칠 수 있는 영향, 사회적인 손실과 법적 책임
■ 민형사상의 제재
■ 라이선스 및 허가의 손실
■ 합리적인 워크어라운드의 부재
■ 제품 실패의 가능성과 이에 대한 매스컴의 부정적인 관심
일반적으로, 리스크의 레벨을 정량적 혹은 정성적으로 부여할 수 있다.
정량적으로 리스크를 분석할 경우에는 발생가능성과 영향을 수치로 표시한다. 발생가능성은 백분율로, 영향은 종종 화폐단위로 표시하고는 한다. 이 두 값을 곱해서 우리는 리스크가 노출되었을 때의 비용을 산정할 수 있다. 보험업계에서는 이를 기대 지불(Expected payout) 혹은 기대 손실(Expected loss)이라고 부른다. 미래의 소프트웨어 엔지니어링 분야에서 우리는 이런 기대 손실을 정해진 규칙에 따라 환산할 수 있게 될 지 모르지만, 일반적으로 리스크의 레벨을 결정하는 것은 사람이 직접 해야할 것이다. 그 이유는 우리가 이러한 정량적인 품질 리스크 분석을 수행할 만큼의 통계적으로 유효한 자료를 가지고 있지 않기 때문이다. 일반적으로 발생가능성을 매우 높음(Very high), 높음(High), 중간(Medium), 낮음(Low) 혹은 아주 낮음(Very low)의 5단계로 분류하지만 이를 어떤 최소한의 의미있는 방법을 통해서라도 90%의 발생가능성, 혹은 75%, 50%, 25%, 10%의 발생가능성을 가지고 있다고 말할 수 없는 것이다.
그렇다고 해서 이러한 정성적인 분석 방법이 저급하다거나 의미가 없다는 것은 전혀 아니다.
사실, 우리가 활용할 수 있는 데이터 중에서 정량적인 방법을 사용한 데이터가 있다고 하더라도, 대부분의 프로젝트에 거의 적합하게 사용할 수 없는 것이 현실이다. 어떤 식으로든 정량적 기법을 사용해 도출된 데이터가 훨씬 정확할 것이라는 잘못된 환상으로 인해 프로젝트의 이해당사자들은 당신이 실제로 리스크를 잘못 다루고 처리하고 있다고 오해할 수도 있다. 나의 경험으로 볼때, 이러한 정량적인 데이터의 한계를 수용하고 적합한 비공식적인 품질 리스크 관리 기법을 적용했을 경우, 실제로도 아주 유용했을 뿐 아니라 테스트 프로세스를 원활하게 관리하는 데에도 큰 도움이 되었다.
리스크 분석이 확장 가능하고 통계적으로 유효한 리스크 데이터에 기반하고 있지 않는 한, 이것은 정성적으로 인지된 만큼의 발생가능성과 영향을 반영할 수 밖에 없다. 이 말은 즉, 이해당사자들이 가지고 있는 개념과 의견으로 인해 리스크의 레벨이 정해질 수 있다는 것이다.
다시 한 번 말하지만, 이러한 사실이 잘못된 것이 아닐 뿐더러, 나 역시 이를 비난할 생각은 추호도 없다.
여기서 핵심은, 프로젝트 매니저, 프로그래머, 사용자, 비즈니스 분석가, 아키텍트, 그리고 테스터들이 서로 다른 전형적인 사고방식을 가지고 있으며 이로 인해 각각의 리스크 아이템에 대해 부여되는 리스크 레벨에 대해 서로 다른 의견을 제시할 수 있다는 것이다. 리스크 레벨을 정할 때, 각기 다른 이런 개념들을 모두 포함해 팀의 지혜를 한 데 모아 정제해야 할 필요가 있는 것이다.
그러나, 모든 이해당사자들이 하나의 의견에 동조하는 것은 사실상 불가능하다. 리스크 분석 프로세스는 각기 다른 의견을 가진 이해당사자들을 합의에 도달하도록 만드는 방법을 포함하고 있어야 한다. 최악의 경우 우리가 일정한 합의에 도달할 수 없다면, 이러한 불일치에 따르는 리스크를 최소한 관리 차원에서 해결할 수 있는 수준으로 완화시킬 필요가 있다. 그렇지 않을 경우, 리스크 레벨은 애매모호하고 갈등을 유발하는 것이 될 것이며 이로 인해 테스팅을 포함하는 리스크 완화 행위에 필요한 유용한 가이드로써의 역할을 수행하지 못할 것이다.
'QA' 카테고리의 다른 글
| 테스터들에게 프로그래밍 스킬이 필요한가? (2) | 2010.10.18 |
|---|---|
| 스타크래프트2 엔딩 크레딧으로 블리자드 QA 엿보기 (10) | 2010.08.21 |
| 리스크 기반 테스팅 - Part 2 (2) | 2010.06.21 |
| 잘못된 애자일의 다섯 가지 증상 (16) | 2010.05.27 |
| 효율적인 테스트 케이스 작성법 - 직관적으로 질문하라 (10) | 2010.05.10 |
