블로그 이미지
미국에서 모바일 애플리케이션을 개발하고 있습니다. 요즘 Corona로 앱을 하나 개발하고 있는데 나도 공부 하면서 여러 분들에게 소개도 하고 싶어서 블로그를 만들었습니다.
솔웅

최근에 받은 트랙백

글 보관함

calendar

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      


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 경과를 그래프로 표시해야 되서 이 공식을 이용 했었죠.



저작자 표시 비영리 동일 조건 변경 허락

엑셀 VLOOKUP 함수 사용하기

2014/12/11 06:35 | Posted by 솔웅


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


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



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

위와 같이 정리 돼 있는데 첫번째 표에 해당 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을 작성할 필요를 느끼게 해 주었다면 그 자체로서 나는 보람을 느낄 수 있을 것이다.



저작자 표시 비영리 동일 조건 변경 허락
이전 1 2 3 4 5 ... 273 다음

티스토리 툴바