비즈니스최적화를위한소프트웨어테스트전략 Date: Sep. 19 (Wed.) 서보희 / 차장 한국 HP 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
Agenda IT 프로젝트의현실 테스트 테스트계획 효율적인테스트디자인방법 behavioral modeling 테스트최적화 : balancing risk and effort 테스트자동화 Business Process Testing Framework HP 품질관리전략
IT 프로젝트의현실 2004 29% 53% 18% 2000 28% 23% 49% 1998 26% 28% 46% 1996 27% 40% 33% 1994 16% 31% 53% 0% 20% 40% 60% 80% 100% Succeeded Challenged Failed Source: CHAOS Report, Standish Group International, Inc.
결함의이해 주요결함들은요구사항정의및설계단계에서생성됨 Hundreds 80% 60% 40% 결함생성 20% 반면사용자인수테스트나운영단으로넘어간이후에야주요결함들이발견됨 Hundreds 0% 80% 60% 40% Requirement Coding & User & Design Unit test Acceptance Test 결함발견 Production 20% 0% Requirement & Design Coding & Unit test User Acceptance Test Production Source: NIST 2002 RTI Project 7007.011
결함의이해 시내를빠르게돌아다닐수있는탈것을만들어주세요 하지만나는비가올때는젖지않길바라는데 그리고내서류가방은어디에싣죠?
결함제거비용 This industry average is used as a baseline for arriving at cost savings 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.
테스트의목적 비즈니스요구사항을테스트한다 : 문제의근본원인에서출발 일반적으로테스트는결함을발견하는것이지만, 또한요구사항이만족되는지를확인하는것 Clear requirements improve the final quality, reduce time to complete the project and lower the cost of project delivery.
테스트란? 단순평가활동을의미하지않음 빙하이론 실제테스트수행은테스트활동의 40% 나머지 60% 보이지않는활동 계획, 관리, 준비, 명세화, 완료 테스트는릴리즈와인수에대한의사결정행위가아님 품질에대한객관적인정보 의사결정권자를위한백그라운드데이터제공 테스트는개발완료이후작업이아님 개발의초기단계에서부터수행되어야하는활동 기능명세화단계에서부터테스트계획이준비되어야함 테스트는공짜가아님 프로젝트의종류에따라개발비용의 20~50% 소요 적절한시점의좋은테스트는개발프로세스를향상시키고좋은품질을가져온다 40% 60%
테스트계획 - 테스트케이스설계 개발자요구사항기준이아닌, 개발내용을기준으로작성하게됨 현업항상바쁨 Use case 의정의 Ping-pong -> Ad-hoc 테스팅 누가테스트케이스를만들어야하느냐를 Ping-pong 결국테스트케이스작성없이 ad-hoc 테스트하는것으로결론 테스트케이스자산화가되지않으며, 일관된품질보증을하기어려움
효율적인테스트디자인방법 Behavioral Modeling Behavioral Modeling: 테스트대상애플리케이션의동작을모델링함으로써테스트케이스를얻어내는방법. 독립된기능의동작을다이아그램으로그려서만들어냄 Behavioral Modeling vs Flow Chart Flow Chart: 프로그램의로직을설명하기위한다이아그램. 플로우차트에서 decision 은프로그램이질문을하고답변에대해응답하게됨 Behavioral Model: 질문이존재하지않음. 질문대신테스터가결정을내림, 그래서다이아그램에서 decision 의의미는테스트설계자의선택을의미 Functional decomposition: 제품또는프로세스를테스트하고자하는독립적 Function 단위로나누는것 고려사항 : Function 의실제동작이무엇인가? 동작의영향은무엇인가? 무엇이동작에영향을미치는지를알게됨으로써 control point 를발견하게됨
Behavioral Modeling - diagram Terminator: Start or End Defined Process Case Decision: true or false, yes or no Manual Process Connector Representaive Sample Displayed Result Result
Behavioral Modeling Sample: FAST FAST-Familiar Automated Teller Machine 저축성예금계좌 / 당좌예금계좌입금, 출금 계좌간이체 계좌조회 Function decomposition: 입금 (Deposit) 출금 (Withdraw) 이체 (Transfer) 조회 (Balance)
Behavioral Modeling Functional Decomposition 결과 FAST Sign-on Withdraw String Transfer Exceptions Deposit Balance End
Behavioral Modeling - Deposit Deposit To account Checking Savings Exist No Requested Account does not exist. Re-enter Valid amount entered Amount Updated End No Invalid amount. Re-enter Tips 한번에완벽한모델을얻으려고많은시간 ( 하루, 몇주, 몇달 ) 을쏟지마세요. 일단완벽하지않더라도가능한모델을만들어내고지속적으로보강해가는게좋습니다.
Behavioral Modeling Deposit: Test Path Deposit To account Checking Savings Exist No Requested Account does not exist. Re-enter Valid amount entered Amount Updated End No Invalid amount. Re-enter Tips 한번에완벽한모델을얻으려고많은시간 ( 하루, 몇주, 몇달 ) 을쏟지마세요. 일단완벽하지않더라도가능한모델을만들어내고지속적으로보강해가는게좋습니다.
Behavioral Modeling - Withdraw Withdraw Checking From account Savings Exist No Requested Account does not exist. Re-enter Insufficient funds in account Valid amount entered No Zero Invalid amount. Re-enter Insufficient funds in FAST No No Enough in account Enough in FAST Why Invalid Not Multiple of $20 Money dispensed and account updated End
Behavioral Modeling - String Balance Deposit Withdraw String Deposit Withdraw Balance String: function 간의상호연결로서보다 highlevel behavioral model String은 function간의상호영향을테스트하기위한것으로 Function 자체의상호영향을테스트하기위한것이아님예 ) deposit function자체는완벽하다고가정하고 function의한샘플을 representative sample로표현 End Representative Sample
Behavioral Modeling String String model: 각 function 자체의 test case 는고려하지않음 가능한모든조합을나열하고자하는것은아님 단, 이조합은경험에의한판단에따름 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.
Behavioral Modeling Tips Behavioral model 작성시 : 각 function model 은한페이지를넘지않도록하는것이중요 만약한페이지를넘는다면, functional decomposition 을다시살펴보고더분류해나간다. 그래도한페이지를넘는다면, 요구사항명세서가더이상단순화할수없을만큼복잡하다는의미 => 결함은복잡도와비례 => AUT는재설계가필요한상태일수있음 Behavioral modeling Behavioral model 을작성하는것은자전거타는것과비슷 책을읽는것만으로는배울수가없음. 직접페달을밟아봐야하듯직접작성해봐야배울수있음 Decomposition 한결과 function 별로담당자가각자의 behavioral model 을작성하도록함
Test 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: Balance Deposit Exceptions Sign-on Transfer Withdraw Atring TCD ID: F Description: FAST Author: Original Release: 1.0 Date: TCD: Page: FB FD FE FS FT FW FR FAST High-level TCD Test Case: FD01 FD02 FD03 FD04 FD05 FD06 Control Points: To Account: * * * * * * Checking * * * Savings * * * Account exist? N Y Y N Y Y Amount of deposit: * * * * valid * * invalid * * Expected Result TCD ID: FD Description: FAST Deposit Author: Original Release: 1.0 Date: "Requested account does not exist. Re-enter" "Invalid amount. Re-enter" Re-entered amount accepted. FAST Deposit TCD Amont balance updated with the deposited amount "Requested account does not exist. Re-enter" "Invalid amount. Re-enter." Account balance updated with the deposited amount
테스트최적화 테스트의제약 제한적인시간과리소스 수용가능한결함률과테스트투자사이의밸런스가필요 HP s Approach 비즈니스관점, 비즈니스와 IT 간의격차해소 비즈니스관점에서테스트팀의의견을고려하여문제없는운영에필요한품질레벨을정해야한다고봄 이를 Business Impact Testing 이라명명 Business Impact Testing 비즈니스리스크분석 리스크에기반, 최적화된테스트의사결정을내리기위함 Costs (indirect) Failure Cost Total Quality Cost Optimum (Direct) Testing Cost 0% 100% Defective Quality Level 100% 100% Good 60% 80%
테스트최적화 Business Impact Testing 리스크분석의기본단위는 behavioral modeling에서나눈 function 단위를기준으로함 Business Impact Testing을위한단계 1. 비즈니스 function 단위의비즈니스영향분석 2. 비즈니스 function 단위의실패율분석 3. 위두분석결과를토대로비즈니스리스크도출 4. 각리스크레벨에따른테스트절차정의 5. 비즈니스 function 단위의복잡도분석 6. 테스트공수산정 7. 자동테스트와수동테스트간의공수조절 8. 테스트프레임웍적용및최적화된테스트공수조정 Risk Model: 비즈니스에대한지식과시스템디자인에대한이해만으로산정할수있도록하는매우실용적인모델제시 적정한비용에리스크를완화하기위한방안 목표 테스트하고자하는기능의투명성 비즈니스크리티컬 function 에테스트를집중하기위함 테스트커버리지인지 비즈니스리스크를얻어내기위해서는, 해당기능의실패로인해예상되는손해와실패가일어날확률데이터가필요 Business Impact Failure Probability
테스트최적화 Business Impact Testing 1. Business Impact Analysis( 비즈니스영향분석 ) Business impact criteria( 비즈니스영향기준 ): 모든비즈니스단위에공통적으로적용될수있는기준을사용 많은프로젝트에서성공적으로사용되어검증된기준제시 ( 주어진상황과환경에따라변경적용가능 ) 이분석의결과로비즈니스 function 을세가지비즈니스영향카테고리로분류할수있게됨 : High, Medium, Low Criteria ( 기준 ) 비즈니스종류 비즈니스연관관계 A High Impact Calculation /Validation Legal Formula: 현업과테스트팀간의협의를통해도출, 아래는예시 ( 상황에따라변경적용가능 ) High impact: High2~3 개또는 Medium 2~3 개 & High 1 개 Medium impact: Medium 2~3 개 & High 가하나도없을때또는 High1 개, Medium 1 개나머지가 Low Low: 나머지경우 Result B Medium Impact Change of Data Wrong Information C Low Impact Display None 사용빈도 Very Often Often Rare 영향을받는고객수 Large number /Very Important Group Some
테스트최적화 Business Impact Testing 2. Failure Probability ( 실패확률분석 ) Failure Probability criteria( 실패확률기준 ): 모든비즈니스단위에공통적으로적용될수있는기준을사용 많은프로젝트에서성공적으로사용되어검증된기준제시 ( 주어진상황과환경에따라변경적용가능 ) 이분석의결과로비즈니스 function 을세가지실패확률카테고리로분류할수있게됨 : Very Likely, Likely, Unlikely Criteria ( 기준 ) 3 Unlikely Result 2 Likely 1 Very Likely 변경율 Unchanged Change function New function 소프트웨어성숙도 Mature (>10 years) Progressing (5-10 years) Immature (< 5 years) 결함율 Low Medium High 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: 나머지경우
테스트최적화 Business Impact Testing 3. 비즈니스리스크도출 Business Impact Analysis 와 Failure Probability 결과를종합하여최종적으로비즈니스 function 에대한 High risk, Medium risk, Low risk 분류를이끌어냄 A Impact High Impact B Medium Impact C Low Impact 3 Unlikely Probability 2 Likely Medium risk High risk High risk 1 Very Likely Low risk Medium risk Medium risk Low risk Low risk Medium risk 이리스크분석결과를기반으로테스트절차를디자인
테스트최적화 Business Impact Testing 4. 테스트절차정의 리스크레벨에따른테스트절차를정의 The key is to invest testing resources according to the priority of risk 테스트절차는다음사항을적용하기위한테스트전략을의미 테스트접근법정의 테스트데이터선택 테스트최적화레벨선정 ( 테스트자동화적용, 비즈니스프로세스프레임워크적용, 다른테스트전략적용등 ) 테스트절차: 리스크기반접근법 High Risk Medium Risk Low Risk 절차접근법절차접근법절차접근법 체계적인테스트진행 근본적인원인분석 자동화테스트 (Business Component Testing Framework 적용 ) 30% 수동테스트 70% 체계적인테스트진행 근본적인원인분석 자동화테스트 (BCT Framework 미적용 ) 20% 수동테스트 80% 체계적인또는임기응변적테스트진행 자동화 5%, 수동 95%, 아웃소싱테스트
테스트최적화 Business Impact Testing 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 4 9 < 4 > 3 1 3 < 1 > 5 3-5 < 3 > 4 2 4 < 2
테스트최적화 Business Impact Testing 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
테스트최적화 Business Impact Testing 7. 자동테스트와수동테스트간의공수조정 어느정도의자동화가 cost-value 비율에서최적인지를끌어냄 방법 : 자동화를준비하기위해추가로필요한공수산정 (for one cycle) 자동화실행을통해절감되는공수산정 (for one cycle) 자동화준비에필요한추가공수를커버하는데필요한사이클수산정 자동화율을조정하면서가장최적의사이클과자동화율을도출 \ 복잡도리스크 ( 영향 ) 1 - Complex 2 - Medium 3 - Low Test Procedure 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 Procedure for High Risk Procedure for Medium Risk Procedure for Low Risk
테스트최적화 Business Impact Testing 7. 테스트프레임웍적용및최적화된테스트공수조정 테스트자동화의장점 회귀테스트의생산성향상 빠른변경사이클에서 last-minute sanity 체크 일관성을유지하고테스트커버리지분석가능 더많은회귀테스트가능 테스트자동화의장애 자동화를위한추가공수 기존리소스의 skill set
테스트자동화 Business Process Testing Framework 기존테스트자동화프레임웍의한계 테스트케이스디자인에많은시간소요 전체비즈니스프로세스를위한테스트케이스를디자인하기위해서는많은 키워드 나열필요 테스트케이스작성이후에다시스크립트작성작업필요 테스트케이스변경이생겼을경우, 스크립트재작성필요 테스트자동화도구는 IT Skill level 을요구함 C, Visual Basic, Java 등 테스트자동화도구는테스트문서를만들어주지못함 Business Process Testing 프레임웍 테스트디자인프로세스를간소화 콤포넌트이용 : 비즈니스프로세스 building block 테스트디자인시작시점을앞당겨줌 테스트자동화와테스트케이스문서작성을한번에해결 Pre-packaged test asset ERP/CRM 솔루션에대한테스트케이스, 테스트콤포넌트, 테스트데이터제공 테스트자동화율을높여줌 쉽게적용하고사용할수있게함으로써 Costs (indirect) Failure Cost Total Quality Cost Optimum (Direct) Testing Cost Automation 0% 100% Defective Quality Level 60% 80% 100% 100% Good
테스트자동화 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 Functional Test Path Example Reject No Terms Order Enter Purchase Order Net 30 Cash Get Invoice Number (via WebService) Process Shipping Customer Info Ship Item Financials General Ledger Adjust Inventory
테스트자동화 Business Process Testing Framework 테스트유지보수효율성향상 중앙집중식콤포넌트관리 Login Component Test One Test Two Test Three Test Four
품질관리전략 HP s Quality Approach 비즈니스영향 / 리스크에따른요구사항우선순위화 Business Process Framework 을이용한테스트 Plan Business Requirement Design Implement Test Deploy Requirements Verification Test Test Quality Effort and Cost Traditional Cost HP Approach Time
HP Software BTO blueprint IT applications 비즈니스전략 요구사항캡쳐및정의 품질및보안보증 성능 Validation 전략적요구 프로젝트제안 새로운애플리케이션 새로운서비스 CIO/Biz/IT Steering Committee IT 전략 IT portfolio and financial management Manage enterprise portfolio Manage projects and programs 비즈니스 CAB 요구사항관리 비즈니스 IT APPLICATIONS( 개발 ) 품질관리프로세스 기능품질최적화 QA 보안최적화 비즈니스운영 성능최적화 App. support CTO (architecture, policies and standards, e.g., SOA) Service portfolio repository PMO 설계 개발 빌드 결함 기능향상 운요영구Planned Federation & Integrations 새로운프로젝트 & 개선요청사항 품질관리저장소 결함 & 이슈 운영 CAB 36
Business Impact Testing Slides HPS Services Portfolio v3.0
리스크기반품질관리 Business Impact Analysis
리스크기반품질관리 Failure Probability Assessment
리스크기반품질관리 Business Impact Analysis 결과
리스크기반품질관리테스트공수산정및자동화율조정
Q & A 42 단기 4340 년 9 월 27 일 HPS Services Portfolio v3.0