Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
비즈니스 최적화를 위한소프트웨어 테스트 전략
© 2007 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice
Date: Sep. 19 (Wed.)
서보희/차장
한국 HP
Agenda
• IT 프로젝트의 현실
• 테스트
• 테스트 계획
− 효율적인 테스트 디자인 방법 – behavioral modeling
− 테스트 최적화: balancing risk and effort
• 테스트 자동화
− Business Process Testing Framework
• HP 품질 관리 전략
26%
28%
29%
28%
23%
53%
46%
49%
18%
1998
2000
2004
IT 프로젝트의 현실
16%
27%
26%
31%
40%
28%
53%
33%
46%
0% 20% 40% 60% 80% 100%
1994
1996
1998
Succeeded Challenged Failed
Source: CHAOS Report, Standish Group International, Inc.
결함의 이해
0%
20%
40%
60%
80%
Requirement
& Design
Coding &
Unit test
User
Acceptance
Production
Hundreds
결함 생성
� 주요 결함들은 요구사항정의 및 설계 단계에서생성됨
& Design Unit test Acceptance
Test
0%
20%
40%
60%
80%
Requirement
& Design
Coding &
Unit test
User
Acceptance
Test
Production
Hundreds
결함 발견
Source: NIST 2002 RTI Project 7007.011Source: NIST 2002 RTI Project 7007.011Source: NIST 2002 RTI Project 7007.011Source: NIST 2002 RTI Project 7007.011
� 반면 사용자 인수 테스트나운영단으로 넘어간이후에야 주요 결함들이발견됨
결함의 이해
시내를 빠르게돌아다닐 수있는 탈것을
만들어 주세요
하지만 나는 비가올때는 젖지 않길
바라는데…그리고내 서류가방은어디에 싣죠?
결함 제거 비용
Industry References: 3 B. Boehm and V. Basili, "Software Defect Reduction Top 10 List," IEEE Computer, IEEE Computer Society, Vol. 34, No. 1, January 2001, pp. 135-137.
This industry average is used as a baseline for arriving at cost savingsThis industry average is used as a baseline for arriving at cost savingsThis industry average is used as a baseline for arriving at cost savingsThis industry average is used as a baseline for arriving at cost savings
테스트의 목적
• 비즈니스 요구사항을 테스트한다:
− 문제의 근본원인에서 출발
− 일반적으로 테스트는 결함을 발견하는 것이지만, 또한 요구사항이만족되는지를 확인하는 것
Clear requirements improve the final quality, reduce time to complete the project and lower the cost of project delivery.
Clear requirements improve the final quality, reduce time to complete the project and lower the cost of project delivery.
테스트란?
40%
• 단순 평가활동을 의미하지 않음− 빙하 이론
• 실제 테스트 수행은 테스트 활동의 40%
• 나머지 60% 보이지 않는 활동
− 계획, 관리, 준비, 명세화, 완료
• 테스트는 릴리즈와 인수에 대한 의사결정행위가 아님− 품질에 대한 객관적인 정보
− 의사결정권자를 위한 백그라운드 데이터 제공
• 테스트는 개발 완료 이후 작업이 아님
60%
− 개발의 초기 단계에서 부터 수행되어야 하는 활동
− 기능 명세화 단계에서 부터 테스트 계획이 준비되어야함
• 테스트는 공짜가 아님− 프로젝트의 종류에 따라 개발 비용의 20~50% 소요
− 적절한 시점의 좋은 테스트는 개발 프로세스를향상시키고 좋은 품질을 가져온다
테스트 계획 - 테스트 케이스 설계
• 개발자요구사항 기준이 아닌, 개발내용을 기준으로 작성하게 됨
• 현업항상 바쁨Use case의 정의
• Ping-pong -> Ad-hoc 테스팅
− 누가 테스트 케이스를 만들어야 하느냐를 Ping-pong− 누가 테스트 케이스를 만들어야 하느냐를 Ping-pong
− 결국 테스트 케이스 작성 없이 ad-hoc 테스트 하는 것으로 결론
, 테스트 케이스 자산화가 되지 않으며, 일관된 품질 보증을 하기 어려움
효율적인 테스트 디자인 방법 –Behavioral Modeling
• Behavioral Modeling:테스트 대상 애플리케이션의 동작을 모델링 함으로써 테스트 케이스를 얻어내는 방법. 독립된기능의 동작을 다이아그램으로 그려서 만들어냄
• Behavioral Modeling vs Flow Chart
− Flow Chart: 프로그램의 로직을 설명하기 위한 다이아그램. 플로우 차트에서 decision은 프로그램이 질문을하고 답변에 대해 응답하게 됨
− Behavioral Model: 질문이 존재하지 않음. 질문 대신 테스터가 결정을 내림, 그래서 다이아그램에서decision의 의미는 테스트 설계자의 선택을 의미
Functional decomposition:• Functional decomposition:제품 또는 프로세스를 테스트 하고자 하는 독립적 Function 단위로 나누는 것
− 고려사항:
• Function의 실제 동작이 무엇인가?
• 동작의 영향은 무엇인가? 무엇이 동작에 영향을 미치는지를 알게 됨으로써 control point를 발견하게 됨
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling ---- diagramdiagramdiagramdiagram
Terminator: Start or EndDefined Process
Case
Decision: true or false, yes or no
Representaive Sample
Manual Process
Displayed Result
Connector
Result
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling –––– Sample: FASTSample: FASTSample: FASTSample: FAST
• FAST-Familiar Automated Teller Machine
−저축성 예금 계좌/당좌 예금 계좌 입금, 출금
−계좌간 이체
−계좌 조회
• Function decomposition:• Function decomposition:
−입금(Deposit)
−출금(Withdraw)
−이체(Transfer)
−조회(Balance)
Behavioral Modeling– Functional Decomposition 결과
FAST
Sign-on ExceptionsSign-on Exceptions
Deposit
Withdraw String Transfer
Balance
End
Behavioral Modeling - DepositDeposit
To account
Exist
“Requested Account does not
exist. Re-enter”
Checking Savings
NoExist
Validamountentered
AmountUpdated
End
“Invalid amount. Re-enter”No
• Tips한번에 완벽한 모델을 얻으려고많은 시간(하루, 몇 주, 몇 달)을쏟지 마세요.일단 완벽하지 않더라도 가능한모델을 만들어 내고 지속적으로보강해 가는게 좋습니다.
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling –––– Deposit: Test PathDeposit: Test PathDeposit: Test PathDeposit: Test PathDeposit
To account
Exist
“Requested Account does not
exist. Re-enter”
Checking Savings
NoExist
Validamountentered
AmountUpdated
End
“Invalid amount. Re-enter”No
• Tips한번에 완벽한 모델을 얻으려고많은 시간(하루, 몇 주, 몇 달)을쏟지 마세요.일단 완벽하지 않더라도 가능한모델을 만들어 내고 지속적으로보강해 가는게 좋습니다.
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling ---- WithdrawWithdrawWithdrawWithdrawWithdraw
From account
Exist
“Requested Account does not
exist. Re-enter”
Checking Savings
No
Validamountentered
Enough in
account
End
“Invalid amount. Re-enter”
Enough in FAST
Money dispensed and account
updated
No
Zero
Not Multiple of $20WhyInvalid
No
No
“Insufficient funds in account”
“Insufficient funds in FAST”
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling ---- StringStringStringStringString
Balance Deposit
• String:function간의상호연결로서 보다 high-level behavioral model
• String은 function간의상호영향을 테스트 하기위한 것으로Function자체의
End
Deposit
Withdraw
Withdraw
Balance
Function자체의상호영향을 테스트하기위한 것이 아님예) deposit function자체는완벽하다고 가정하고function의 한 샘플을representative sample로표현
Representative Sample
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling –––– String String String String
• String model:
−각 function자체의 test case는 고려하지 않음
−가능한 모든 조합을 나열하고자 하는 것은 아님
• 단, 이 조합은 경험에 의한 판단에 따름
• Project관련자와 AUT 사용자가 가장 최상의 의사결정을 내려야• Project관련자와 AUT 사용자가 가장 최상의 의사결정을 내려야함
• 즉, 많은 테스트로 인한 프로젝트 지연과 더 많은 테스트로 인한이익간의 최적점을 찾아야 함
Every decision you make in testing is a risk decision, including how much testing you do. Balance the risk of missing a bug against the risk of missing deadline.
Every decision you make in testing is a risk decision, including how much testing you do. Balance the risk of missing a bug against the risk of missing deadline.
Behavioral Modeling Behavioral Modeling Behavioral Modeling Behavioral Modeling –––– Tips Tips Tips Tips
• Behavioral model 작성시:
− 각 function model은 한 페이지를 넘지 않도록 하는 것이 중요
− 만약 한 페이지를 넘는다면, functional decomposition을 다시살펴보고 더 분류해 나간다.
− 그래도 한 페이지를 넘는다면, 요구사항 명세서가 더 이상단순화할 수 없을 만큼 복잡하다는 의미 => 결함은 복잡도와 비례단순화할 수 없을 만큼 복잡하다는 의미 => 결함은 복잡도와 비례=> AUT는 재설계가 필요한 상태일 수 있음
• Behavioral modeling
− Behavioral model을 작성하는 것은 자전거 타는 것과 비슷
• 책을 읽는 것만으로는 배울 수가 없음. 직접 페달을 밟아 봐야 하듯직접 작성해 봐야 배울 수 있음
− Decomposition한 결과 function별로 담당자가 각자의 behavioral model을 작성하도록 함
Test Case DesignTest Case DesignTest Case DesignTest Case Design
• Behavioral Modeling결과를 기반으로 테스트 케이스 디자인− Behavioral model을 정해진 규칙에 의해 TCD spread sheet으로 옮김으로써 완성
− TCD• Header, Body로 나뉨
• Body는 control points와 test case로 나뉨
− Control Points• 테스터가 콘트롤 할 수 있는 모든 것: behavioral model에서 모든 선택은 control point가 됨
• 각 test case의 가장 하위 레벨 input 리스트
Function:Function:Function:Function: TCD:TCD:TCD:TCD: Page:Page:Page:Page:
Balance FBDeposit FDExceptions FESign-on FSTransfer FTWithdraw FWAtring FR
TCD ID: F TCD ID: F TCD ID: F TCD ID: F Description: FAST Description: FAST Description: FAST Description: FAST Author: Author: Author: Author: Original Release: 1.0 Date: Original Release: 1.0 Date: Original Release: 1.0 Date: Original Release: 1.0 Date:
Test Case:Test Case:Test Case:Test Case: FD01 FD02 FD03 FD04 FD05 FD06
Control Points:Control Points:Control Points:Control Points:To Account: * * * * * * Checking * * * Savings * * *Account exist? N Y Y N Y YAmount of deposit: * * * * valid * * invalid * *
Expected ResultExpected ResultExpected ResultExpected Result
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
exi
st.
Re-ente
r"exi
st.
Re-ente
r"exi
st.
Re-ente
r"exi
st.
Re-ente
r"
"Inva
lid a
mount.
Re-ente
r""I
nva
lid a
mount.
Re-ente
r""I
nva
lid a
mount.
Re-ente
r""I
nva
lid a
mount.
Re-ente
r"Re-ente
red a
mount accepte
d.
Re-ente
red a
mount accepte
d.
Re-ente
red a
mount accepte
d.
Re-ente
red a
mount accepte
d.
Am
ont bala
nce u
pdate
d w
ith the
Am
ont bala
nce u
pdate
d w
ith the
Am
ont bala
nce u
pdate
d w
ith the
Am
ont bala
nce u
pdate
d w
ith the
deposited a
mount
deposited a
mount
deposited a
mount
deposited a
mount
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
"Requeste
d a
ccount does n
ot
exi
st.
Re-ente
r"exi
st.
Re-ente
r"exi
st.
Re-ente
r"exi
st.
Re-ente
r"
"Inva
lid a
mount.
Re-ente
r."
"Inva
lid a
mount.
Re-ente
r."
"Inva
lid a
mount.
Re-ente
r."
"Inva
lid a
mount.
Re-ente
r."
Account
bala
nce u
pdate
d w
ith
Account
bala
nce u
pdate
d w
ith
Account
bala
nce u
pdate
d w
ith
Account
bala
nce u
pdate
d w
ith
the d
eposited a
mount
the d
eposited a
mount
the d
eposited a
mount
the d
eposited a
mount
TCD ID: FD TCD ID: FD TCD ID: FD TCD ID: FD Description: FAST Deposit Description: FAST Deposit Description: FAST Deposit Description: FAST Deposit Author: Author: Author: Author: Original Release: 1.0 Date: Original Release: 1.0 Date: Original Release: 1.0 Date: Original Release: 1.0 Date:
FAST High-level TCD FAST Deposit TCD
테스트 최적화
• 테스트의 제약− 제한적인 시간과 리소스
− 수용 가능한 결함률과 테스트 투자 사이의 밸런스가 필요
• HP’s Approach− 비즈니스 관점, 비즈니스와 IT간의 격차 해소
− 비즈니스 관점에서 테스트 팀의 의견을 고려하여 문제없는 운영에 필요한 품질 레벨을 정해야한다고 봄
− 이를 “Business Impact Testing”이라 명명
• Business Impact Testing• Business Impact Testing− 비즈니스 리스크 분석
− 리스크에 기반, 최적화된 테스트 의사결정을 내리기 위함
CostsCostsCostsCosts
Quality LevelQuality LevelQuality LevelQuality Level
0%0%0%0%
100% Defective
100%100%100%100%
100% Good
TotalTotalTotalTotal
QualityQualityQualityQuality
CostCostCostCost
(indirect) Failure Cost(indirect) Failure Cost(indirect) Failure Cost(indirect) Failure Cost
(Direct) Testing Cost(Direct) Testing Cost(Direct) Testing Cost(Direct) Testing Cost
OptimumOptimumOptimumOptimum
60%60%60%60% 80%80%80%80%
• 리스크 분석의 기본 단위는 behavioral modeling에서 나눈 function 단위를 기준으로 함
• Business Impact Testing을 위한 단계1. 비즈니스 function 단위의 비즈니스 영향 분석
2. 비즈니스 function 단위의 실패율 분석
3. 위 두 분석 결과를 토대로 비즈니스 리스크 도출
4. 각 리스크 레벨에 따른 테스트 절차 정의
5. 비즈니스 function 단위의 복잡도 분석
6. 테스트 공수 산정
7. 자동 테스트와 수동 테스트간의 공수 조절
8.
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
8. 테스트 프레임웍 적용 및 최적화된 테스트 공수 조정
• Risk Model:
− 비즈니스에 대한 지식과 시스템 디자인에 대한 이해만으로 산정할 수 있도록 하는 매우실용적인 모델 제시
− 적정한 비용에 리스크를 완화하기 위한 방안
− 목표
• 테스트 하고자 하는 기능의 투명성
• 비즈니스 크리티컬 function에 테스트를 집중하기 위함
• 테스트 커버리지 인지
− 비즈니스 리스크를 얻어내기 위해서는, 해당 기능의 실패로 인해 예상되는 손해와 실패가일어날 확률 데이터가 필요
• Business Impact
• Failure Probability
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
1. Business Impact Analysis(비즈니스 영향 분석)
− Business impact criteria(비즈니스 영향 기준): 모든 비즈니스 단위에 공통적으로 적용될 수 있는기준을 사용
− 많은 프로젝트에서 성공적으로 사용되어 검증된 기준 제시(주어진 상황과 환경에 따라 변경적용 가능)
− 이 분석의 결과로 비즈니스 function을 세가지 비즈니스 영향 카테고리로 분류할 수 있게 됨: High, Medium, Low
Criteria
Result
B
− Formula: 현업과 테스트 팀간의 협의를 통해 도출, 아래는 예시(상황에 따라 변경 적용 가능)• High impact: High2~3개 또는 Medium 2~3개 & High 1개
• Medium impact: Medium 2~3개 & High가 하나도 없을 때 또는 High1개, Medium 1개 나머지가 Low
• Low: 나머지 경우
Criteria(기준기준기준기준) A
High Impact
BMedium Impact
CLow Impact
비즈니스 종류Calculation/Validation Change of Data Display
비즈니스 연관관계
Legal Wrong Information None
사용빈도 Very Often Often Rare
영향을 받는고객 수
Large number/Very Important Group Some
2. Failure Probability (실패 확률 분석)
− Failure Probability criteria(실패 확률 기준): 모든 비즈니스 단위에 공통적으로 적용될 수 있는기준을 사용
− 많은 프로젝트에서 성공적으로 사용되어 검증된 기준 제시(주어진 상황과 환경에 따라 변경적용 가능)
− 이 분석의 결과로 비즈니스 function을 세가지 실패 확률 카테고리로 분류할 수 있게 됨: Very Likely, Likely, Unlikely
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
CriteriaResult
− Formula: 현업과 테스트 팀간의 협의를 통해 도출, 아래는 예시(상황에 따라 변경 적용 가능)• Very Likely: Very likey 2개 이상 또는 Likely 2~3개 Very likely 1개
• Likely: Likely 2개 이상 very likely 0개 또는 Very likely 1개 Likely 1개 나머지 unlikely
• Unlikely: 나머지 경우
Criteria(기준기준기준기준) 3
Unlikely2
Likely1
Very Likely
변경율 Unchanged Change function New function
소프트웨어성숙도
Mature(>10 years)
Progressing(5-10 years)
Immature(< 5 years)
결함율 Low Medium High
3. 비즈니스 리스크 도출
− Business Impact Analysis와 Failure Probability 결과를 종합하여 최종적으로 비즈니스 function에대한 High risk, Medium risk, Low risk 분류를 이끌어 냄
테스트 최적화 – Business Impact Testing
Impact
Probability
3Unlikely
2Likely
1Very Likely
A
High ImpactMedium risk High risk High risk
− 이 리스크 분석 결과를 기반으로 테스트 절차를 디자인
High Impact
BMedium Impact Low risk Medium risk Medium risk
CLow Impact Low risk Low risk Medium risk
4. 테스트 절차 정의
− 리스크 레벨에 따른 테스트 절차를 정의
− The key is to invest testing resources according to the priority of risk
− 테스트 절차는 다음 사항을 적용하기 위한 테스트 전략을 의미• 테스트 접근법 정의
• 테스트 데이터 선택
• 테스트 최적화 레벨 선정 (테스트 자동화 적용, 비즈니스 프로세스 프레임워크 적용, 다른 테스트 전략 적용등)
− 테스트 절차: 리스크 기반 접근법
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
− 테스트 절차: 리스크 기반 접근법
High Risk절차
체계적인 테스트 진행
근본적인 원인 분석
접근법자동화 테스트(Business Component Testing Framework 적용) 30% 수동 테스트 70%
Medium Risk절차
체계적인 테스트 진행
근본적인 원인 분석
접근법자동화 테스트(BCT Framework 미적용) 20% 수동테스트 80%
Low Risk절차 체계적인 또는 임기응변적 테스트 진행
접근법 자동화5%, 수동95%, 아웃소싱 테스트
5. 기능 복잡도(Functional Complexity) 분석
− 테스트를 위한 예산 확보를 위한 기능 복잡도 분석
− Being able to estimate testing efforts allows us to better plan the software testing life cycle, align resources, and leverage test strategies and technology.
− 목 표:• 비즈니스의 단일 비즈니스 활동의 구현을 하는 복잡도를 정의
• 테스트를 하기 위해 대략적으로 어느 정도의 노력을 필요로하는지 정의 (준비, 실행, 평가)
− 접 근:• 애플리케이션이 지원하는 비즈니스 활동을 나열
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
• 애플리케이션이 지원하는 비즈니스 활동을 나열
• 평가를 위한 다른 기준 (최대 5)을 정의
• 최종 영향도 값을 계산하기 위한 알고리즘 정의
결과결과결과결과
기준기준기준기준
1 - Complex 2 - Medium 3 - Low
영향 받는오브젝트의 수
> 9> 9> 9> 9 4 4 4 4 –––– 9999 < 4< 4< 4< 4
쓰기권한이 있는오브젝트의 수
> 3> 3> 3> 3 1 1 1 1 –––– 3333 < 1< 1< 1< 1
읽기권한이 있는오브젝트의 수
> 5> 5> 5> 5 3 3 3 3 ---- 5555 < 3< 3< 3< 3
영향 받는화면의 수
> 4> 4> 4> 4 2 2 2 2 –––– 4444 < 2< 2< 2< 2
6. 테스트 공수 산정
− 동 기:• 앞 단계 에서 어느 정도의 예상인력이 필요한지를 얻어 예산과 가용 인력과 비교하는데 사용
− 방 법• 기술적인 복잡도별로 리스크 레벨별로 공수를 할당
• 각각의 비즈니스 활동별로 리스크와 복잡도를 할당
• 모든 비즈니스 활동들을 결합하여
• 테스트 활동별로 테스트 노력을 분류
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
• 테스트 활동별로 테스트 노력을 분류
− Test effort baseline model• 통합 테스트에 소요되는 공수
\복잡도복잡도복잡도복잡도
리스크리스크리스크리스크(영향영향영향영향) 1 - Complex 2 - Medium 3 - Low
A – High 13 - 19 10 - 16 7 - 13
B – Medium 6.5 – 9.5 6.5 – 9.5 4 – 6.5
C - Low 2.3 2.2 1.2 – 2.2
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
7. 자동 테스트와 수동 테스트간의 공수 조정
− 어느 정도의 자동화가 cost-value 비율에서 최적인지를 끌어냄
− 방법:• 자동화를 준비하기 위해 추가로 필요한 공수 산정 (for one cycle)
• 자동화 실행을 통해 절감되는 공수 산정 (for one cycle)
• 자동화 준비에 필요한 추가 공수를 커버하는데 필요한 사이클 수 산정
• 자동화율을 조정하면서 가장 최적의 사이클과 자동화율을 도출
\\\\복잡도복잡도복잡도복잡도1 - Complex 2 - Medium 3 - Low Test Procedure
리스크리스크리스크리스크((((영향영향영향영향) ) ) ) 1 - Complex 2 - Medium 3 - Low Test Procedure
A – High 13 - 19 10 - 16 7 - 13Procedure for High
Risk
B – Medium 6.5 – 9.5 6.5 – 9.5 4 – 6.5Procedure for Medium Risk
C - Low 2.3 2.2 1.2 – 2.2Procedure for Low
Risk
테스트테스트테스트테스트 최적화최적화최적화최적화 –––– Business Impact TestingBusiness Impact TestingBusiness Impact TestingBusiness Impact Testing
7. 테스트 프레임웍 적용 및 최적화된 테스트 공수 조정
− 테스트 자동화의 장점• 회귀테스트의 생산성 향상
• 빠른 변경 사이클에서 last-minute sanity 체크
• 일관성을 유지하고 테스트 커버리지 분석 가능
• 더 많은 회귀테스트 가능
− 테스트 자동화의 장애• 자동화를 위한 추가 공수
• 기존 리소스의 skill set• 기존 리소스의 skill set
테스트 자동화 – Business Process Testing Framework
• 기존 테스트 자동화 프레임웍의 한계
− 테스트 케이스 디자인에 많은 시간소요
• 전체 비즈니스 프로세스를 위한 테스트케이스를 디자인 하기 위해서는 많은“키워드” 나열 필요
− 테스트 케이스 작성 이후에 다시스크립트 작성 작업 필요
− 테스트 케이스 변경이 생겼을 경우, 스크립트 재작성 필요
−
• Business Process Testing 프레임웍
− 테스트 디자인 프로세스를 간소화
• 콤포넌트 이용: 비즈니스 프로세스building block
− 테스트 디자인 시작 시점을 앞당겨 줌
− 테스트 자동화와 테스트 케이스 문서작성을 한번에 해결
− Pre-packaged test asset
• ERP/CRM 솔루션에 대한 테스트 케이스, 테스트 콤포넌트, 테스트 데이터 제공
− 테스트 자동화 도구는 IT Skill level을요구함
• C, Visual Basic, Java 등
− 테스트 자동화 도구는 테스트 문서를만들어 주지 못함
테스트 콤포넌트, 테스트 데이터 제공
− 테스트 자동화율을 높여줌
• 쉽게 적용하고 사용할 수 있게 함으로써
CostsCostsCostsCosts
Quality LevelQuality LevelQuality LevelQuality Level0%0%0%0%
100% Defective
100%100%100%100%
100% Good
TotalTotalTotalTotal
QualityQualityQualityQuality
CostCostCostCost
(indirect) Failure Cost(indirect) Failure Cost(indirect) Failure Cost(indirect) Failure Cost
(Direct) Testing Cost(Direct) Testing Cost(Direct) Testing Cost(Direct) Testing Cost
OptimumOptimumOptimumOptimum
60%60%60%60% 80%80%80%80%
Automation
테스트 자동화 – Business Process Testing Framework
• 테스트 디자인
− “키워드” 선택, 오퍼레이션선택으로 테스트 디자인
− 테스트 문서 작성과 자동화스크립트 작성이 동시에 해결
• Pre-packaged test assets
− SAP, Oracle, Siebel, Peoplesoft
• 테스트 케이스 구성
− Business component building block
− 비즈니스 시나리오, 테스트 데이터
테스트 자동화 – Business Process Testing Framework
• Business Process Validation“Components”의 이해
Login
Get Invoice
Number Reject
Enter Purchase OrderNet 30No Terms
Functional Test
Path Example
Ship
Number
(via WebService)
Reject
Order
General
Ledger
Enter Purchase OrderNet 30No Terms
Cash
Adjust
Inventory
Process
Shipping
Item
Financials
Customer Info
테스트 자동화 – Business Process Testing Framework
• 테스트 유지보수 효율성 향상
− 중앙집중식 콤포넌트 관리
Login Component
Test One
Test Two Test ThreeTest Four
•비즈니스 영향/리스크에 따른 요구사항 우선순위화•Business Process Framework을 이용한 테스트
DesignDesignDesignDesign ImplementImplementImplementImplement DeployDeployDeployDeployTestTestTestTest
Requirements Requirements Requirements Requirements VerificationVerificationVerificationVerification
Business Business Business Business RequirementRequirementRequirementRequirement
PlanPlanPlanPlan
TestTestTestTestTestTestTestTest
품질 관리 전략HP’s Quality Approach
VerificationVerificationVerificationVerification
HP ApproachHP ApproachHP ApproachHP Approach
TraditionalTraditionalTraditionalTraditionalCostCostCostCost
QualityEffort
andCost
Time
TestTestTestTestTestTestTestTest
Manage
IT portfolio andfinancial management
CIO/Biz/IT Steering
Committee
IT 전략
HP Software BTO blueprintIT applications
비즈니스비즈니스
운영비즈니스
전략
IT APPLICATIONS(개발)
요구사항관리
기능품질
최적화
보안최적화
성능최적화
품질 관리 프로세스
QA
비즈니스CAB App.
support
•요구사항 캡쳐 및 정의•품질 및 보안 보증•성능 Validation
전략적 요구
36
Manage projects
and programs
PMO
Manage enterprise portfolio
CTO(architecture, policies and
standards, e.g., SOA)
Service portfolio repository
Planned Federation
& Integrations
•결함•기능 향상
• 프로젝트 제안• 새로운 애플리케이션• 새로운 서비스
품질관리
저장소
최적화
설계 빌드
개발
결함 & 이슈새로운 프로젝트 & 개선 요청사항
운영CAB
영구
운요
Business Impact Testing SlidesBusiness Impact Testing SlidesBusiness Impact Testing SlidesBusiness Impact Testing Slides
HPS Services Portfolio v3.0
리스크 기반 품질 관리Business Impact Analysis
리스크 기반 품질 관리Failure Probability Assessment
리스크 기반 품질 관리Business Impact Analysis 결과
리스크 기반 품질 관리테스트 공수 산정 및 자동화율 조정
Q & AQ & AQ & AQ & A
42단기 4340년 9월27일 HPS Services Portfolio v3.0