현재 참여하고 있는 프로젝트에서는 Defect Management 를 위해 HP ALM 을 사용하고 있습니다.

Full name은 HP Application Lifecycle Management 이고 흔히 HP QC (Quality Center) 라고들 하더라구요.

이름 그대로 어플리케이션의 Lifecycle을 관리하는 툴인데 현재 프로젝트에서는 Defect 관리만 하고 있습니다. 이 외에 Rally 를 사용해서 Agile Methodology 를 구현하고 있구요.

Automation Testing 을 위해서는 Jenkins 를 사용하고 있습니다.

오늘 글에서는 HP QC 에 있는 데이터를 Excel Macro를 이용해서 불러오는 방법을 정리하겠습니다.

불러온 데이터를 가공해서 관련 테스터나 개발자 혹은 관리자에게 Report 를 이메일로 보내는 프로그램을 개발해서 현재 사용하고 있는데요.

오늘 글에서는 엑셀 매크로를 이용해서 HP QC에 접근하는 방법만 다루겠습니다.

(원문)

가장 먼저 해야할 일이 HP QC에 ID/PW를 입력해서 접근 권한을 얻는 겁니다.

이 때 ID/PW 이외에 Domain과 Project 정보를 함께 제공해야 합니다.

소스코드를 볼까요?

우선 URL,ID,PWD,Domain 그리고 Project 정보를 해당 변수에 대입시켰죠.

그리고 Application.StatusBar 프로퍼티는 일이 진행되는 동안 메세지를 표시하도록 합니다.

그 다음 19번째 줄에서 HP QC에 connect 할 객체를 생성합니다.

TDApiOle80.TDConnection 를 사용해서 생성하시면 됩니다.

21번째 줄에서는 URL을 사용해서 connection을 초기화 하구요 23번째 줄에서는 ID와 PW를 제공합니다.

25번째 줄에서 도메인과 프로젝트 정보를 제공해서 로그인에 필요한 모든 정보가 제공되게 됩니다.

여기까지 오면 HP QC에 무사히 접속한 겁니다.

27번째 줄에서는 무사히 접속했다는 메세지를 뿌려 줍니다.

그 다음에 Exit Sub를 해서 HP QC 접속 함수를 완료 합니다.

만약에 에러가 있으면 29번째 줄로 건너 뛰어서 에러 메세지를 뿌려주고 End Sub를 하게 되구요.

전달하는 URL은 항상 https://<server url>/qcbin  형태가 됩니다.

오른쪽 아래 CC 를 누르시면 한글 자막을 보실 수 있습니다.

(왼쪽 위의 제목 'Day of the Living Dead' 를 누르시면 유튜브 화면으로 가셔서 보실 수도 있습니다.)

Rawdata를 받아들고 Client 가 요청하는 통계를 만들다 보면 여러 가지 방법을 사용해야 될 때가 있습니다.

예전에 해당 날짜가 속한 주의 월요일을 구해야 될 일이 있었는데 그 때 사용했던 Formula 입니다. 

=TODAY()-WEEKDAY(TODAY(),2)+1

이 글을 작성하는 날짜가 12/12/2014 입니다.

그러니까 이번주의 월요일은 12/8/2014 이니까 이게 표시가 되겠네요.

함수를 보면 처음  TODAY() 는 오늘 날짜를 표시해 주는 함수 이죠.

그리고 WEEKDAY()의 첫번째 인자는 날짜가 되겠구요.

두번째 parameter 는 처음에 이해하기 좀 복잡하더라구요.

저는 2를 선택했는데요. 이 의미는 일주일을 1~7로 할당하고 1은 Monday가 된다는 얘기 입니다.

만약에 3을 선택하면 Monday 부터 시작하긴 하지만 시작하는 숫자는 0이라는 얘기 입니다.

오늘이 금요일이니까 두번째 것을 선택하면 결과 값은 5가 되겠고 세번째 것을 선택하면 결과 값은 4가 되겠죠.

일단 2를 선택했으니까 결과 값은 5가 나올 겁니다.

그러니까 Today (금요일) 에서 5를 빼면 5일 전을 말하니까 일요일이 되겠죠. 원하는 값은 월요일이니까 여기에 다시 1을 더해 준 겁니다.

그러면 오늘이 속한 주의 월요일을 구할 수 있습니다.

이 공식이 얼마나 자주 사용 될 지는 모르겠지만...

하여간 제가 하는 일에서는 사용을 했습니다.

주별 Defect Creation 경과를 그래프로 표시해야 되서 이 공식을 이용 했었죠.

어제 업무에 사용했던 함수를 하나 정리해 보겠습니다.

실제 회사 데이터를 올릴 수 는 없어서 가상으로 아래의 상황을 설정했습니다.

작년과 올해에 여러곳에서 마라톤을 완주 했습니다.

위와 같이 정리 돼 있는데 첫번째 표에 해당 City의 2014년도의 기록을 넣고 싶습니다.

이럴경우 VLOOKUP을 사용하면 되는데요.

=IFERROR(VLOOKUP(B6,$G$6:$H$11,2,FALSE),"No")

이렇게 사용하면 됩니다.

우선 VLOOKUP 함수부터 보면 첫번째 argument (B6)는 비교할 데이터 입니다.

첫번째 칸에서는 Chunchon 이 되겠죠.

그리고 두번째($G$6:$H$11)는 이 Chunchon 이라는 데이터랑 비교할 범위입니다.

G6:H11 이 범위인데 여기에 $를 사용한 이유는 나중에 다른 셀에도 적용하기 위해서 해당 셀을 더블클릭하거나 Drag 할 때 이 값이 변하지 않도록 하기 위해서 입니다.

첫번째 인자인 B6는 $이 없으니까 Drag 하면 B7-B8-B9... 이런식으로 숫자가 자동 증가하게 됩니다.

그리고 세번째 인자인 2 는 두번째 값을 셀에 넣겠다는 겁니다.

Chunchon 이랑 같은 값이 오면 그 라인의 두번째 값을 취하겠다는 겁니다.

(그런데 오른쪽에는 Chunchon 이 없네요. 이런 경우는 조금 있다가 설명드리겠습니다.)

대신 Delhi를 보면 3:18 이 두번째 값입니다.

마지막에 FALSE는 Chunchon 이랑 정확하게 match 되어야 한다는 조건이고 TRUE 를 사용하면 비슷한 단어가 있으면 match 됐다고 보라는 겁니다.

이렇게 하면 VLOOKUP은 완료 됐는데요.

아까 봤듯이 CHUNCHON이라는 도시가 오른쪽 표에 없습니다.

이런 경우 #N/A 라고 표시가 될 텐데, 이게 보기 싫으면 다른 문자를 표시할 수 있습니다.

그게 IFERROR 함수 입니다.

만약 결과가 ERROR 이면 No 라는 문자를 표시하라는 거죠.

이렇게 하면 아래와 같은 결과가 나옵니다.

작년과 올해 모두 참가한 마라톤 대회는 Roterdam과 Boston  대회이군요.

Roterdam 대회는 1시간을 앞당겼고 Boston 대회는 50여분이 늦춰졌네요.

뭐 이게 있을 법한 일인지는 모르겠지만요.

하여간 VLOOKUP과 IFERROR 를 잘 사용하면 위와 같이 데이터를 가공할 필요가 있을 때 아주 유용하게 사용 하실 수 있습니다.

Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps - part 2 -

Process to develop a good test strategy document:


여러분의 프로젝트에 어떤 것이 가장 잘 맞을지에 대해 고민해 보지 않고 무조건 template을 따르는 것은 자제하자. 고객들은 그들만의 요구 조건들이 있고 여러분은 그런 고객들의 특성을 잘 파악해서 이 문서가 여러분의 일에 제대로 적용될 수 있도록 만들어야 한다. 그냥 무조건 다른 문서를 복사해서 붙여넣기 하지 말자. 여러분이 만든 문서가 여러분의 프로젝트에 진정 도움이 되어야 하고 여러 프로세스를 만드는데 좋은 기초가 되어야 한다.

아래는 strategy template 샘플이다. 여기에는 어떤 내용들이 이 문서에서 커버되어야 하는지를 보여준다. 그리고 각 컴포넌트들을 커버하기 위해 어떻게 해야 하는지 감을 잡을 수 있도록 예제를 제공할 것이다.


Test Strategy in STLC:

Common sections of test strategy document:

Step #1 – Scope and Overview:


이 문서를 누가 사용할 것인지에 대한 정보와 함께 프로젝트 개요가 들어간다. 좀 더 자세하게 누가 이 문서를 검토하고 승인할 지에 대해서도 언급한다. testing activity들과 testing phases 등을 정의해서 test plan에 정의된 전체 프로젝트 타임라인에 맞춘 각 activity들과 phase 들의 타임라인을 정의한다.

Step #2 – Test Approach:


testing process와 level 을 정의하고 각 팀 멤버들의 역할 및 책임을 기술한다. 모든 test type에 대해서는 test plan에서 정의 돼 있다. (예: unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) 이러한 test type들은 언제 테스트를 시작하고 test owner가 누구이고 누가 책임을 지고 있고 testing approach는 어떻고 automation stragegy에 대한 자세한 내용 그리고 가능하면 tool들까지 자세한 내용들이 Tesst Stragegy 문서에 담기게 된다. 그리고 왜 이런 테스트 들을 해야 되는지도 언급하게 된다.

test execution에는 여러 activity들이 있는데, 예를 들어 defect 등록, defect 분류, defect assignments, re-testing, regression testing 그리고 최종 test sign-off 같은 것들이다. 각 activity 들에 대해 정확한 step들을 정의해 두어야 한다. 여러분이 이전에 사용했던 프로세스를 다시 사용해도 된다. 테스터 인원수와 누가 어떤 activity를 진행해야 하는지 등등 각 팀 멤버들의 role과 responsibility를 명시해 놓아야 한다.

예) defect management cycle - 새로운 defect를 등록하는 프로세스 명시. 어디에 등록하고 어떻게 등록하고 defect status는 어떠해야 하고 누가 defect triage (defect 등급 분류)를 해야 하고 이 등급 분류 후에 누구에게 이 defect를 할당해야 하는 지 등등에 대해 명시되어야 한다.

또한 management process 변화도 정의한다. 여기에는 change request submission과 사용될 template 그리고 해당 request를 다룰 프로세스들이 정의된다.

Step #3 – Test Environment:


테스트 환경 셋업에 대해 정의한다. environment 갯수와 각 environment 를 셋업하는 방법등을 설명한다.

예) functional test team을 위한 test environment 한개 그리고 UAT 팀을 위한 다른 한개.
각 environmet 에 허용되는 user 수와 각 유저에 요구되는 access role들 그리고 운영체제나 메모리, free disk space, 시스템 수 등등의 필요한 하드웨어에 대해서 설명한다.

test data requirement에 대해 정의하는 것도 아주 중요하다. 어떻게 test data를 생성하는지에 대해 분명한 방법을 제시한다. (either generate data or use production data by masking fields for privacy)

test data 백업과 restore strategy 에 대해 정의한다. 아마도 프로그래밍 code에서 제대로 처리하지 않는 문제 때문에 Test environment database 운영에 어떤 문제가 발생할 수도 있을 것이다. 어떤 프로젝트에서 내가 경험했던 문제는 database backup strategy 가 정의 되지 않아서 일어났다. 언제 백업을 하고 그 백업에는 어떠한 것들이 있어야 하고 언제 이 데이터베이스를 restore 하고 누가 restore 하고 데이타베이스가 restore 된 후 따라야 할 data masking step 등등이 명시되어 있어야 한다.

Step #4 – Testing Tools:


test execution에 필요한 test management와 automation tool들에 대해 정의한다. 퍼포먼스를 위해 load와 security 테스팅에서 test approach와 필요한 tool들을 명시한다. 그것이 오픈소스인지 유료 툴인지도 언급하고 얼마나 많은 user 가 사용할 수 있는지를 알아보고 이에 맞게 계획을 세운다.

Step #5 – Release Control:


이전 UAT article에서 언급했듯이, release cycle에 대한 계획이 없으면 test와 UAT 환경에서 서로 다른 software version에 대한 result를 얻게 된다. release management 계획은 확실한 version history 를 확보할 수 있는 상태에서 수립하게 된다. 그렇게 되면 해당 release 의 모든 modification들에 대한 test execution을 보장할 수 있게 된다.

예) build management 프로세스를 수립하면 - 현재 release가 가능한 build를 파악할 수 있고 그 build들이 어디에 deploy 되는지를 명확하게 공유할 수 있다. 즉 production build 들을 어디에서 구하고 누가 해당 production release 에 대해 go or no-go를 할 것인지도 명시하게 된다.


Step #6 – Risk Analysis:


가능한 모든 risk들을 정리한다. 이런 리스크들을 완화하기 위한 clear 한 계획을 제공한다. 그리고 실제 이러한 risk가 발생했을 때를 대비한 contingency plan을 명시한다.


Step #7 – Review and Approvals:

이러한 모든 activity들이 test strategy plan에 정의 되면 이 문서는 sign-off를 위해 검토 되어야 한다. 검토할 당사자들은 project management, business team, development team 그리고 system administration (혹은 environment management) team 등이 해당 될 것이다. review change 에 대한 이력은 approver 의 이름과 날짜 그리고 comment들을 문서 시작 부분에 명시할 수 있도록 작성돼 있어야 한다.
그리고 이 문서는 현재 진행형의 문서이다. 즉 이 문서는 testing process enhancement를 위해 지속적으로 review 되고 update 되어야 한다.

마무리:


Test Strategy는 그냥 종이조각이 아니다. 이 문서는 소프트웨어 테스팅 life cycle의 전체 QA activity에 대해 설명한 문서이다. 이 문서를 test execution process 마다 수시로 참고하고 software release 까지 해당 내용들을 따라야 한다. 프로젝트가 release date에 가까와 오면 올 수록 이 test strategy 문서에 정의된 내용들을 간과함으로서 초래되는 부정적인 결과들이 점점 더 많이 발생하게 될 것이다.

agile 팀에서 일을 간소화 하려고 하는 부분은 strategy 문서 작성이 아니라 test execution 부분이어야 한다. 이러한 기본적인 strategy plan을 가지고 있으면 프로젝트에 내재해 있는 리스크 피해를 줄이거나 이에 대해 분명한 계획을 세울 수 있다. Agile 팀은 모든 high level activity들을 파악하고 이를 문서화 해서 어떠한 문제도 없이 test execution이 제 때에 완료 될 수 있도록 해야 한다.

좋은 test strategy plan을 만들고 이를 제대로 따르면 분명히 testing process 가 충분히 개선되고 소프트웨어의 품질이 향상될 것이라고 확신한다. 이 글이 당신이 당신의 프로젝트에 대한 test strategy plan을 작성할 필요를 느끼게 해 주었다면 그 자체로서 나는 보람을 느낄 수 있을 것이다.

Definitive Guide to Develop a Good Test Strategy Document with These 7 Simple Steps - part 1-

What is Test Strategy?

Testing을 통해 무엇을 얻고 그것을 어떻게 달성할 것인지에 대한 접근법을 정의하는 것이 strategy plan이다.

이 문서는 테스트의 목적을 달성하기 위한 분명한 접근법을 취하기 위해 모든 불확실하고 애매한 부분을 다 제거한다. Test Strategy는 QA 팀에가 가장 중요한 문서 중 하나이다. 이 문서를 효율적으로 작성하는 것은 모든 테스터들이 그들의 경력 속에서 취득해야할 기술이다.

이 문서는 간과할 수 있는 요구조건들이 정리됨으로로서 작업의 완결성을 높여줄 것이다. 그리고 각 테스트 계획의 activity들은 팀에게 테스트 범위나 테스트 영역을 정의하는데 도움을 줄 것이다. 또한 테스트 매니저에게는 어느때 이든지 현재 프로젝트의 상태를 파악할 수 있도록 도움을 줄 수 있다. 그리고 제대로 된 strategy 가 마련돼 있으면 test activity들을 missing 할 수 있는 위험성을 줄여준다.

아무 계획없이 테스트를 하는 것은 거의 성공확률이 없다. 그리고 strategy document를 작성은 했지만 이후 테스트 할 때 한번도 참조하지 않는 경우도 있다. Testing strategy plan은 반드시 모든 팀 멤버들과 같이 공유되고 논의 되어야 한다. 그렇게 함으로서 팀이 지속적으로 관련 업무에 이를 활용하고 거기에 대한 책임도 인지하고 있어야 한다. 시간이 촉박하다고 해서 그 strategy document에 있는 testing activity들을 보류하거나 건너 뛰어서는 안된다. 여기에 언급된 프로세스는 반드시 실행되어야 한다.

Test Strategy vs. Test Plan:


몇년 간 두 문서 사이에 많은 혼동이 있었다. 아주 기본적인 정의부터 하자. 일반적으로 어느 문서부터 오는지는 중요하지 않다. Test Planning 문서는 전체 프로젝트 계획과 strategy가 같이 있는 문서이다. IEEE Standard 829-2008에 따르면 strategy plan은 test plan의 하위 문서이다.


모든 조직은 그들만의 표준과 프로세스를 가지고 이러한 문서들을 관리한다. 어떤 조직들은 test plan 에 strategy details를 포함하기도 한다. (여기에 그 예가 있다) 어떤 조직들은 strategy를 testing plan의 subsection으로 두고 자세한 내용들을 별도의 strategy 문서로 만들기도 한다.

test plan에는 프로젝트의 범위와 test focus가 정의 돼 있다. 기본적으로 test coverage, 테스트해야 할 features 그리고 테스트 하지 말아야할 features, estimation, schedule 그리고 resource management 등이 있다.

test strategy에는 test objectives를 달성하기 위해 따라야 할 test approach에 대한 guideline들과 testing plan에 정의 된 test type들의 실행 등이 들어 있다. 여기에는 test objective, approach, test environment, automation strategy 그리고 tool 들과 contingency plan 등과 같은 risk analysis 등이 있다.

요약하면 test plan은 여러분이 달성하고자 하는 비젼이고 test strategy는 그 비젼을 달성하기 위해 마련된 action plan 이다.

이렇게 정의함으로서 혼동스러운 개념이 깨끗하게 정리되길 바란다. James Bach는 여기에서 이와 관련해 좀 더 자세하게 논했다.