비즈니스최적화를위한...

비즈니스 최적화를 위한소프트웨어 테스트 전략

© 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


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


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


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


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

− 테스트 절차는 다음 사항을 적용하기 위한 테스트 전략을 의미• 테스트 접근법 정의

• 테스트 데이터 선택

• 테스트 최적화 레벨 선정 (테스트 자동화 적용, 비즈니스 프로세스 프레임워크 적용, 다른 테스트 전략 적용등)

− 테스트 절차: 리스크 기반 접근법


− 테스트 절차: 리스크 기반 접근법

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.

− 목 표:• 비즈니스의 단일 비즈니스 활동의 구현을 하는 복잡도를 정의

• 테스트를 하기 위해 대략적으로 어느 정도의 노력을 필요로하는지 정의 (준비, 실행, 평가)

− 접 근:• 애플리케이션이 지원하는 비즈니스 활동을 나열


• 애플리케이션이 지원하는 비즈니스 활동을 나열

• 평가를 위한 다른 기준 (최대 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. 테스트 공수 산정

− 동 기:• 앞 단계 에서 어느 정도의 예상인력이 필요한지를 얻어 예산과 가용 인력과 비교하는데 사용

− 방 법• 기술적인 복잡도별로 리스크 레벨별로 공수를 할당

• 각각의 비즈니스 활동별로 리스크와 복잡도를 할당

• 모든 비즈니스 활동들을 결합하여

• 테스트 활동별로 테스트 노력을 분류


• 테스트 활동별로 테스트 노력을 분류

− 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


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


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


• 테스트 디자인

− “키워드” 선택, 오퍼레이션선택으로 테스트 디자인

− 테스트 문서 작성과 자동화스크립트 작성이 동시에 해결

• Pre-packaged test assets

− SAP, Oracle, Siebel, Peoplesoft

• 테스트 케이스 구성

− Business component building block

− 비즈니스 시나리오, 테스트 데이터


• 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


• 테스트 유지보수 효율성 향상

− 중앙집중식 콤포넌트 관리

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

비즈니스최적화를위한...

Documents