블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

SOAPUI로 유명한 SmartBear의 ALM 툴들

ALM | 2013.12.31 01:35 | Posted by 조대협

SOAPUI로 유명한 SmartBear(http://smartbear.com가 얼마전에 LoadUI라는 부하 테스트 툴을 내놓더니

요즘들어 보니 정말 많은 툴들을 내놓고 있다.


Selenium과 같은 웹 테스트 자동화 툴인 TestComplete

- 웹뿐 아니라 테스트 탑 및 Flash까지 테스트가 가능하다.


Requirement 관리, 애자일 Sprint관리, Test Case관리 까지 가능한 ALMComplete

JIRA + GreenHopper + TestLink 이런 느낌?


코드리뷰 툴에서 부터, 자동 빌드 툴 그리고 시스템 모니터링 툴까지 갖추고 있다.

Atlassian과 비슷한 느낌?


Atlassian이 자유도가 높은 형태라면, SmartBear는 딱 프로세스가 잡혀진 느낌 각각의 장단점은 있겠으나..

둘다 쓸만한 툴인듯.



Vagrant를 이용한 개발환경 관리(간단한 VM관리)

ALM | 2013.10.24 00:48 | Posted by 조대협

Vagrant

시작하기

Vagrant는 한마디로 이야기 하면, “간소화된, VM 관리 서비스이다”. 이미 Virtual Machine 환경은 보편화 되서 사용되고 있고, VMWare Oracle Virtual Box등을 이용하면 PC에서도 손쉽게 VM 환경을 구축할 수 있다. 그러나 문제점은, Virtual Box와 같은 Hypervisor가 있다고 해도, VM을 생성하는 것 자체가 번거로운 작업이라는 것이다.

 Hypervisor에서 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고, 일일이 설정을 해줘야 한다. 이런 반복적인 작업을 조금더 손쉽게 자동화 할 수 없을까? 하는 아이디어에서 시작한 것이 Vagrant이다.

먼저 이해를 돕기 위해서 예제를 실행해보자.

Vagrant VM 관리도구 이기 때문에, 먼저 Hypervisor 부터 인스톨을 해야 한다.

https://www.virtualbox.org/ 에서 Virtual Box를 다운로드 받아서 설치하자.

다음으로 http://www.vagrantup.com/ 에서 vagrant를 받아서 인스톨한다. 이제 준비가 끝났다.

아래와 같이 vagrant init precise32 http://files.vagrantup.com/precise32.box 를 실행하면, Ubuntu Linux VM의 실행하기 위한 설정들을 자동으로 가지고 온다. 그리고 vagrant up 명령어를 실행하면 해당 설정에 따른 VM 을 자동으로 다운받아서 설치하고 Virtual Box를 통해서 해당 VM을 기동 시킨다. Putty를 이용하여 SSH localhost:2222 번으로 접속 (id:vagrant, passwd:vagrant)를 입력하면, 생성된 VM에 로그인할 수 있다. 또는 간단하게 “vagrant ssh”라고 실행하면, 현재 생성된 VM에 자동으로 SSH로 연결된다.



Vagrant 없이 Virtual Box에서 직접 Ubuntu VM을 설치하려면 VM을 만들고, Ubuntu OS를 설치해야 한다. 그러나 Vagrant가 있으면 이렇게 간단하게 두줄의 명령어로 VM을 만들고 실행시킬 수 있다.

Box 개념 이해하기

앞에서 vagrant init 명령을 실행할때, preceise32.box라는 파일을 지정하였다. box 파일은 VM을 만들기 위한 기본 OS 이미지를 포함한 VM 설정(CPU,메모리 사이즈등)에 대한 기본 템플릿이다. (사이즈가 보통 수백 메가가 나간다.)

http://www.vagrantbox.es/ 에 보면 공개된 box 파일들이 있다. Ubuntu, Debian 등 다양한 Linux OS 버전의 VM 들에 대한 box 파일들이 있다.

Vagrant file

Vagrant init을 하면, 해당 디렉토리에 “Vagrantfile” 이라는 이름으로 생성되는 파일인데, Box VM 생성을 위한 기본 템플릿이라면, Vagrant file은 생성될 VM에 대한 세부 설정을 정의한다. VM을 생성할때, 어떤 box 파일을 사용할 것인지, VM에 대한 하드웨어 설정 예를 들어 CPU,메모리 사이즈,네트워크, 네트워크 포트포워딩 설정등을 여기서 재정의 할 수 있다.

아래는 Oracle Virtual Box실행시 preceise32 box 이미지를

http://files.vagrantup.com/precise32.box 에서 읽어와서, CPU 2, 512M를 가진 “Terry_vargrant0”이라는 VM을 생성하는 Vagrantfile이다. 아래와 같이 파일을 생성한후에, vagrant up 명령을 수행시키면 설정한 정보 대로 VM이 생성된다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  # config.vm.network :forwarded_port, guest: 80, host: 8080

  # config.vm.network :private_network, ip: "192.168.33.10"

  # config.vm.network :public_network

  # config.ssh.forward_agent = true

  config.vm.provider "virtualbox" do |vm|

        vm.customize [

               "modifyvm",:id,

               "--memory","512",

               "--name","Terry_vagrant0",

               "--cpus","2",

                       ]

  end

end

 

Vagrant + Provisioning

Vagrant를 이용하면, VM을 쉽게 만들 수 있다. 그런데 개발환경을 구축하자면, OS가 인스톨된 VM 뿐만 아니라, 그위에 웹서버,DB등 미들웨어들을 설치해야 하고, 그리고 거기에 맞는 Configuration을 해야 한다. 물론 미리 VM 이미지에 웹서버등을 설치해놓고, 필요에 따라서 vagrant를 이용해서 해당 VM들을 설치해서 사용해야 하지만 그 경우에는 설정마다 매번 다른 VM이미지를 만들어놔야 하기 때문에 번거롭다. 만약에 OS 만 설치된 VM에다가, 설정에 따라서 소프트웨어와 설정을 하는 부분을 분리한다면?

이런 접근을 지원하는 기능이 Vagrant provisioning이라는 기능이 있다. VM을 기동한 후에, vagrantfile에 정의된 provisioning script를 수행해준다. 다음 예제를 보자. 다음 예제는 VM이 기동된 후에, apt-get 명령을 이용해서 apache2 (웹서버)를 자동으로 설치하는 설정이다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

config.vm.provision :shell, :inline => "sudo apt-get install -y apache2"

 

end

위의 예제는 VM이 기동될때 마다 shell 명령어를 수행하도록 한것인데, 명령어말고도 shell스크립트를 수행하게 할 수 도 있고, puppet이나 chef와 같은 configuration management 도구를 이용해서, 제품을 설치하게 할 수 도 있다.

한 가지 주의할점은 Vagrantfile provision 부분에 정의된 명령어는 vagrant up, reload, provision 3개의 명령어가 실행될때 마다 매번 실행된다. up에서도 매번 실행되기 때문에, 스크립트내에, 해당 소프트웨어가 미리 설치되었는지 확인한 후에, 설치가 안되어 있을 경우에만 설치하도록 스크립트를 짜는 것이 좋다.

Provisioning에 대한 자세한 방법은 http://docs.vagrantup.com/v2/provisioning/index.html 를 참고하면 된다.

Vagrant를 이용한 개발 환경 구축

그러면 Vagrant를 이용해서 개발환경을 어떻게 구축할 수 있는지 살펴보도록 하자



크게 그림과 같이 2개의 repository가 필요하다. Box image repository에는 기본 이미지가 인스톨된 box image들을 저장해놓는다.

그리고 svn이나 git와 같은 VCS 툴에 vagrantfile을 저장해놓는다. (아니면 간단하게 웹서버에 저장해놔도 된다.) Vagrantfile에는 box 파일들을 저장해놓은 repository pointing 하도록 하고, 필요에 따라서

1.  Ubuntu + Apache

2.  Ubuntu + MySQL

3.  Ubuntu + Tomcat

와 같이 다양한 설정을 만들어 놓고, 필요에 따라서 Vagrantfile이 받은 후에, 간단하게 “vagrant up” 명령어만 수행하면 간단하게 개발환경에 필요한 VM을 만들어낼 수 있다.

지금까지 간략하게 Vagrant에 개념과 사용법에 대해서 알아보았다.Vagrant는 그외에도, Vagrant는 단일 VM 뿐만 아니라 multi vm을 단일 vagrantfile에서 설정이 가능하고, Oracle Virtual Box뿐만 아니라,VMWare Amazon EC2 클라우드 까지 지원한다. 간단하게는 개발환경에서 부터,응용하면, QA,스테이징,운영환경 배포용으로도 활용할 수 있다.

자세한 내용들은 http://docs.vagrantup.com/ 를 참고하기 바란다

nexus pro에 대한 고급 기능소개


조대협 (bwcho75@지메일)


nexus는 maven repository로 매우 유명한 솔루션이다. 오픈 소스 버전은 maven을 사용하는 경우에는 거의 필수적으로 사용이 된다고 해도 과언이 아니다.

nexus의 상용 버전인 nexus pro의 경우 CLM (Component Life-cycle Management) 개념을 도입하여, 접근제어나 컴포넌트에 대한 security 나 license risk등을 관리 통제할 수 있다.

이 글에서는 nexus pro에 대한 몇 가지 고급 기능에 대해서 살펴보고, 이를 통해서 컴포넌트(라이브러리)의 관리가 단순한 중앙 집중형 공유만이 아닌 일종의 life cycle 개념이 있다는 것을 이해하도록 해보자


 

Nexus의 상용 버전인 Pro 버전에는 단순한 공유나 maven repository cache 용도뿐만이 아니라 조금 더 복잡한 기능의 라이브러리 관리 기능을 제공한다. Nexus에서는 이러한 개념을 CLM (Component Life-cycle Management)이라고 하는데, 라이브러리에 대한 접근 제어나 정책 관리등이 이에 해당한다. 몇가지 대표적인 오픈소스 정책 관리 기능을 살펴보자.

근래에 소프트웨어 개발 패러다임은 오픈소스를 이용한 소프트웨어 개발이 많다. 많은 오픈 소스 라이브러리를 사용하게 되는데, 문제는 각 오픈소스 컴포넌트들의 라이센스 정책이 다르다는 것이다. GPL,Apache,MIT,BSD 등 여러가지 라이센스 정책이 있는데, 라이센스 정책에 따라서, 어떤 오픈 소스는 사용에는 제약이 없지만 배포시 소스코드를 변경해야 하거나, 유료로 비용을 지불해야 하는 경우도 있고, 2.0 버전에서는 멀쩡하게 아무 제약없이 사용할 수 있었던 컴포넌트들이 3.0 버전으로 업그레이드 되면서 제약이 생기는 경우가 있다. (오라클이 인수한 MySQL의 경우 제품에 번들해서 재 배포할 경우 일정의 비용을 지불해야 한다.)  이러한 이유 때문에, 오픈소스 컴포넌트에 대한 라이센스 체크는 점점 필수적인 요건이 되어가는데 문제는 하나의 서비스나 소프트웨어 제품을 개발하는데, 수백개 이상의 라이브러리가 사용된다는 것이고, 각 버전마다 일일이 라이센스를 체크한다는 것은 보통일이 아니다. Nexus는 이런 오픈소스 라이브러리 정책을 repository 차원에서 관리해준다.

오픈소스 라이센스 정책 관리

Nexus proxy repository를 선택하고, Analysis 라는 버튼을 누르면, 현재 repository에 저장되어 있는 오픈 소스에 대한 라이센스 정책을 분석하여 다음과 같이 보여준다. 이 라이센스 정책에 대한 DB nexus 판매사인 sonatype으로 부터 제공된다.



각 라이브러리가 어떤 라이센스 정책을 사용하는지, 그리고 각 라이센스 정책이 문제가 없는 지등을 찾아준다.

Security 체크

또한, 보안에 위험이 있는 라이브러리등을 찾아서 보안 위험도등을 표시해준다. 2013년 기준으로 struts2에 대해서 아주 큰 보안 위험이 발생된 일이 있었다. 이렇게 중앙의 repository에서 회사내에서 사용하는 라이브러리에 대한 보안 위험성을 감지해서 중앙에서 통제하게 되면, 개별 개발자에 대한 수고도 덜 수 있을 뿐더러, 보안 위험에 대해서 피해갈 수 있는 장점을 가질 수 있다.



이렇게 체크만 할뿐만 아니라, 이렇게 검출된 문제 있는 라이브러리들을 접근하지 못하게 막을 수 있다.

Procurement

nexus pro에는 “artifact procurement” 라는 기능이 있는데, 이 기능을 사용하면 proxy repository를 만들고, 여기에 속해 있는 라이브러리에 대해서 white list 또는 black list 방식으로 접근을 제어할 수 있다. 아래 그림은 asm-parent 라이브러리에 대해서 모두 접근을 제어 하는 설정을 적용한 예이다.



 

Staging

또 다른 재미 있는 기능중에 하나는 staging 개념을 지원한다는 것이다.

즉 개발자가 컴포넌트나 라이브러리를 개발하여 nexus에 배포하면 다른 개발자나 사용자들이 바로 그 라이브러리를 사용하게 하는 것이 아니라, 일종의 워크플로우를 통해서 릴리즈 절차가 끝나면 일발 개발자들이 사용할 수 있도록 프로세스를 조정할 수 있다.

이를 위해서 staging repository라는 개념을 제공하는데, 설명하자면 다음과 같다.



개발자가 컴포넌트를 개발하고, 개발이 끝나면 staging repository로 배포를 진행한다. 배포된 repository QA 그룹 엔지니어만 접근이 가능하다. QA 엔지니어는 컴포넌트를 받아서 테스트를 진행하고, 문제가 없으면, 해당 컴포넌트를 베타 테스트 단계로 넘긴다.

베타 테스트 단계에 있는 컴포넌트는 베타 테스트 사용자에게만 접근이 허용되며, 테스트가 끝나면 일반 repository로 이동되어 일반 개발자도 접근이 가능하게 해준다.

이 워크플로우에서 단계별로 넘어갈때, 각 단계 이동별로 정책을 정할 수 있다. 예를 들어 앞서 설명한 security level이 낮은 경우 reject을 하거나, open source 라이센스가 문제가 있는 경우에, reject을 하는 중의 policy를 정의할 수 있다

< 출처 : http://www.sonatype.com/take-a-tour/nexus-pro-tour-start >

테스트 팀의 조직 구조

ALM/Test Automation | 2012.08.21 15:27 | Posted by 조대협

테스트 팀의 조직 구조


Facebook Server Side Architecture Group (SSAG)

http://www.facebook.com/groups/serverside

조대협


테스트를 수행하는 테스트팀의 구조는 테스트 방법론이나 개발 조직, 개발팀의 개발 방법론에 따라 모두 차이가 있다. 여기서는 일반적으로 적용할 수 있는 테스트 조직 구조에 대해서 소개한다.

각각의 역할은 중첩 될 수는 있으나, 생략 될 수 는 없다.




테스트 팀

테스트팀은 테스트를 계획하고 주도적으로 수행하는팀이다. 테스트팀의 일반적인 구조는 다음과 같다.

Test Lead

전체 테스트에 대한 모든 것을 관장한다. 테스트 팀 관리 뿐만 아니라 시스템에 대한 전체 품질 관리를 포함하여 관리한다.

-       Define strategy, methodology : 시스템의 품질 보장을 위한 테스트 전략과 운영할 방법론을 찾고, 조직에 맞게 테스트 방법론을 설계 및 수립한다.

-       Define Process : 시스템 개발 및 테스트 단계에서 운용할 테스트 프로세스를 수립한다. 테스트 프로세스는 테스트 팀만이 사용하는 방법론이 아니라, 개발 및 출시 전과정에서 적용해야 한다. 즉 테스트 팀 뿐만 아니라 개발팀에서도 사용해야 하며, 출시 여부를 결정하는 마케팅팀에서도 이 테스트 프로세스에 영향을 받는다.
수립된 테스트 프로세스는 FIX된 체로 운용되는 것이 아니라 적용 과정을 거쳐서 시스템과 조직의 성격에 맞도록 계속해서 성숙 시켜 나가야 하는데, 이 역할 역시 Test Lead가 담당해야 한다.

-       Manage test project : 테스트팀을 운용 하고 관리한다. 인원을 뽑는 것에서 부터, 일정 관리, 예산 관리와 같이 팀 관리에 해당하는 모든 업무를 수행한다.

-       Communicate with other team : Test Lead의 역할 중 가장 중요한 역할 중 하나가, 다른 팀과의 의사 소통 가교 역할을 하는 것이다. 테스트는 테스트 대상을 가지고 있으며, 제품 출시 여부를 결정 기준이 되며, 테스트 중 발견된 결함을 개발팀에서 수정되어야 하며, 테스트 운영을 위해 필요한 인원에 대한 채용, 테스트에 필요한 툴 구입을 위해서 예산을 확보해야 한다. 이러한 모든 작업은 테스트팀 자체적으로 해결할 수 없고 타팀과의 협업을 통해서만 해결할 수 있기 때문에, 타 팀과의 의사 소통은 매우 중요한 역할이다.

-       Educate team : Test Lead는 테스트 수립된 전략과 프로세스, 방법론에 따라 테스트 팀 및 개발팀이 테스트 작업을 수행할 수 있도록 교육을 진행한다.

-       Define matrix : 시스템에 대한 품질, 테스트 팀의 진척률, 개발 프로세스에 대한 품질등을 체크할 수 있는 정량화된(수치화된) Matrix 표를 정의한다. 여기에 사용될 수 있는 Matrix는 다음과 같다.

1) Defect / KLOC : 소스코드 1000라인당 발견되는 Defect의 수
2) Test Coverage :
전체 테스트 대상에 대해서 테스트가 커버하는 범위로, 전체 소스코드에 대한 테스트가 커버한 소스코드 라인 (라인 커버리지), IF와 같은 분기문에 대한 커버리지를 분석하는 브랜치 커버리지, 전체 기능 대비 테스트한 기능에 대한 기능 커버리지 등이 있다.
3) Defect / Hour :
개발 시간별 발생한 Defect
4) Days test effot / Requirement :
하나의 요구 사항에 대해서 테스트 하는데 소요된 날짜

이러한 Matrix는 전체적인 제품의 품질 현황이나 개선 추이를 그래프로 한눈에 알아볼수 있기 때문에 많은 도움이 되며, 특히 Defect/KLOC, Defect/Hour 등의 척도는 개발 과정에서 발생하는 결함의 수와 이를 해결하는데 필요한 리소스를 산정할 수 있는 지표이기 때문에, 개발과정에서 소요되는 테스트 비용과 인력 계획의 기반 자료로 사용할 수 있다.

Test Designer

테스트 디자이너는 Test Lead에 의해 정의된 전략, 방법론, 프로세스에 따라 테스트 대상 시스템을 분석하고, 상세 테스트 전략을 수립한 후 상세 테스트 케이스를 디자인 한다.

-       Analysis & design test requirement : 테스트 대상 시스템의 기능, 요구 사항과 상세 아키텍쳐를 파악하고, Defect가 발생될 수 있는 부분을 탐색한 후에, Defect의 가능성이 있는 부분을 중심으로, 테스트 전략을 수립한다.

-       Design test case : 테스트 전략을 기반으로, 상세 테스트 케이스를 설계한다.

Test Operator

설계된 테스트 케이스 디자인에 따라서 상세 테스트 케이스를 구현 및 수행 한다.

-       Implement test case : 테스트 디자이너를 기반으로 상세 테스트 케이스를 구현한다.

-       Execute test case : 테스트를 검증하고, 테스트 과정에서 구현된 테스트를 수행한다.

-       Result document : 테스트 수행 과정에서 나온 데이타를 수집하고, 결과를 리포팅 한다.

-       Generate defect report : 테스트 과정에서 결함이 발견된 다면, 결함의 내용과 결함의 발생 절차를 기록한다.

-       Track defect : 향후 결함을 개발팀과 함께 FIX할 때, 개발자와 함께 Defect에 대한 수정에 대해서 의사 소통을 하고, 결함의 해결 과정을 자세하게 리포팅 한다.

-       Test tool set up : 필요에 따라서 테스트에 필요한 툴를 셋업 한다.

Test Environment Manager

일반적인 테스트 조직에서는 존재하지 않는 경우가 많은데, 테스트 환경을 셋업하고 유지하는 역할을 한다.

테스트 환경이란, 테스트 대상이 되는 대상 시스템을 테스트 환경에 배포한 환경과 테스트를 위해 사용되는 부하 발생 툴등의 테스트 툴, 테스트 과정중 대상 시스템을 관측하기 위한 모니터링 시스템 그리고 테스트에서 발견된 결함을 로깅하기 위한 결함 관리 시스템등으로 구성된다.

이런 테스트 환경의 구성은 개발팀 또는 테스트 엔지니어가 겸하는 경우가 많은데, 테스트 환경 구축 자체가 많은 시간이 들기 때문에 이를 구축하는 개발자나 테스트 엔지니어의 리소스가 허비되고 이로 인해서 개발일정이나 테스트 일정에 차질을 가지고 올 수 있기 때문에 명시적으로 테스트 환경을 셋업하고 유지하는 역할을 만들 필요가 있다.

그리고 개통 테스트 단계가 많은 시간이 소요되는 경우가 많은데, 개통 테스트에 많은 시간이 소요되는 주요한 원인은 테스트 환경 셋업과 점검에서 발생하는 경우가 많다. IP가 틀리고, 설정 정보가 잘못되고, 제대로 문서화 되어 있지 않은 등에 사소한 문제인 경우가 대부분인데, 이러한 문제를 사전에 예방하기 위해서

, 구축도 중요하지만 해당 환경을 계속적으로 유지해야 반복적인 회귀 테스트가 가능하다.

-       Set up test environment : 테스트 대상 시스템을 테스트 환경에 배포하고, 테스트에 필요한 테스팅 툴와 모니터링 툴들을 설치 관리한다. 그리고 이 환경에 대한 설정 정보를 문서화 하여 관리한다.

-       Monitor environment during test : 테스트가 진행되는 중에 모니터링 툴를 이용하여 테스트 환경 인프라와 테스트 시스템등에 대한 모니터링을 수행하고, 테스트 진행중 환경에 대한 모니터링 정보를 저장한다.

외부 지원팀

테스트는 대상 시스템에 대한 검증을 수행하는 작업이다. 작게 보면 테스트를 수행하는 조직이 만들지 않은 외부의 것을 검증하는 작업으로, 테스트의 주체는 테스트 대상을 잘 알지 못한다. 그래서 테스트에 필요한 기술적인 지원이 필요하다.

Development Team

테스트 환경에 대한 설정에서 부터 Defect에 대한 해결까지 개발팀에 대한 지원은 필수적이다.

-       Support test environment set up : 테스트 환경에 개발 대상 시스템을 배포한다. 개발 대상 배포 시스템의 설치는 테스트팀이 독립적으로 수행할 수는 없고 테스트 대상 시스템에 대한 지식이 있어야 하기 때문에 개발 당사자인 개발팀의 지원은 필수적이다.

-       Fix defect : 발생된 결함에 대해서 테스트 엔지니어로부터 현상과 관련 자료를 받아서, 결함을 수정하고 이에 대한 확인 작업을 같이 수행한다.

-       Monitoring test : 테스트 과정중에 테스트 대상 시스템에 대한 모니터링을 수행한다.

System Engineer

시스템 엔지니어는 테스트 대상 시스템 이외의 테스트 툴, 모니터링 툴, 하드웨어 인프라나 RDBMS 또는 미들웨어 등에 대한 모니터링 작업을 지원하는 엔지니어이다. 테스트 대상 시스템에 대한 지식은 개발자가 알고 있지만, 미들웨어와 같이 개발에 사용한 기반 시스템등에 대한 지식은 미약한 경우가 많기 때문에, 제품에 대한 전문적인 지식을 가지고 있는 기술 지원 엔지니어의 지원이 있다면 조금더 효율적인 테스트가 가능하다.

-       Monitoring & Tuning : 테스트 대상 시스템 이외의 부분(위에 언급한 부분) 에 대한 제품 모니터링과 튜닝을  지원한다.

'ALM > Test Automation' 카테고리의 다른 글

Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18

관심가는 ALM툴

ALM | 2009.08.18 17:33 | Posted by 조대협
http://www.visual-paradigm.com/product
가격이 매우싸고, ALM Task 관리쪽 잘 지원하고 무엇보다 모델링 기능이 있는게 맘에 드는데
빌드나 테스트쪽 커버는 좀 약하고, 요구 사항 및 디자인 추적성은 좋은듯.

단 이거가지고 돈은 안될거 같고... SI 업체등에서 표준 툴로 쓰면 싸고 좋겠네.

Oracle ALM 솔루션

ALM | 2009.07.24 10:39 | Posted by 조대협
그토록 찾았는데 몰랐다. 오라클에도 ALM 솔루션이 있는지는
형상 관리와 TASK 관리는 되는것 같은데, JDeveloper 기반이네.
http://www.oracle.com/technology/obe/obe11jdev/bulldog/gettingstartedtpc/getting_started_tpc.htm

'ALM' 카테고리의 다른 글

Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14

ALM 에서 각 기능들은 필수인가?

ALM | 2009.07.03 10:07 | Posted by 조대협

KX사의 프로젝트에서는 Bugzilla
S사의 프로젝트에서는 JIRA + Hudson + xUnit
H사의 프로젝트에서는 JIRA + Confluence + Bamboo + xUnit 
또다른 H사의 프로젝트에서는 JIRA + Hudson + xUnit + Mantis
S사의 프로젝트에서는 Confluence + Hudson + xUnit
K사에서는 DokuWiki
지금 K사의 프로젝트에서는 Trac 

매번 프로젝트마다 ALM 툴셋을 바꿔가면서 사용해보고 있습니다. 제품들을 실제 경험해봄으로써 최적의 조합을 찾기 위함입니다.

그런데, 프로젝트를 하면서 ALM을 적용하면서 깨달은것중의 하나가, ALM의 4개의 Module을 꼭 모두 적용할 필요가 없다는 것입니다. 프로세스나 사상을 기반으로 하되 프로젝트의 특성에 따라서 필요한 모듈만 사용하면 된다는 것입니다.

Issue Tracker를 이용한 Task Management의 경우, 팀의 규모가 적어도 5인 이상이 되고, 이슈가 많을 경우 즉 추적성을 많이 필요로 하고 Task에 대한 공유가 도구 없이 통제할 수 있는 범위를 벗어나는 경우에만 도입하는 것이 유리합니다. 그렇지 않을 경우 Task Logging하는 것 자체가 Burden이 될 수 있습니다. 특히나 Issue Logging에 대해서는 일정기간 개발자들이 시스템에 익숙해지는 Learning Curve에 대한 시간이 필요하기 때문에, 그 전에는 Excel 을 이용한 Scrum 방법론 기반의 팀 운영 방식이 가장 효율적입니다. 

빌드 자동화의 경우 개발이 있는 경우는 대부분 긍정적입니다. 투자되는 시간대비 효과가 좋습니다. 단 이는 개발 중심의 프로젝트인 경우입니다. EAI와 같은 솔루션 기반의 시스템 개발의 경우 코딩 보다 솔루션의 기능을 사용하는 경우가 많기 때문에 이러한 경우에는 CI의 필요성이 반감됩니다.

테스트 자동화의 경우도 마찬가지입니다. In-House 개발의 경우에는 효과가 좋습니다. 그리고 팀원이 많을수록 품질관리에 대한 요구 사항은 올라가기 마련이지만 소규모 팀의 경우 Sprint (주기)를 짧게 나눠서 Short Release를 하면서 매번 테스트를 하는 것이 단위 테스트 구현이나 테스트 자동화 보다 훨씬 효율적입니다. JUnit을 만든 Kent Beck역시 JUnit Max를 만들면서 단위테스트가 모든 프로젝트에서 필요하지 않다는 것을 언급한적이 있습니다.
 제가 제시하는 방안은 시스템에서는 몇가지 대표적인 구현 패턴이 존재합니다. 이런 패턴들을 프로젝트 초기에 Prototyping을 하고 아키텍쳐 검증이라는 이름으로 테스트를 진행해서 해당 패턴의 아키텍쳐 적인 특성을 검증합니다. 이 단계에서는 기능적인면보다는 성능,장애,안정성에 대한 비기능적 테스트를 위주로 함으로써 아키텍쳐의 위험성을 초기에 검출하여 해결안을 찾아내고 RISK를 조기에 없앱니다. 검증된 패턴에 대해서 개발자들이 찍어내기식의 개발을 하게 되는데, 이미 검증된 아키텍쳐이기 때문에, 비기능적 요건에 대해서는 테스트를 할 필요가 없고, 기능적으로 되냐 안되냐만 검증을 하면 됩니다. 필요할 경우에만 기능 위주의 단위 테스트를 적용하도록 합니다.

모든 기술과 이론은 "꼭 이래야 한다" 라는 것은 없는 것 같습니다. 상황과 조건에 따라서 적절하게 사용해야 그 효과가 극대화 되는 것 같습니다.

다음 프로젝트에서는 Polarion을 도입해서 사용해봐야 겠습니다.




'ALM' 카테고리의 다른 글

관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
TAG ALM

2년동안 만든 기술이...

분류없음 | 2009.07.02 10:01 | Posted by 조대협
제 블로그에 오시는 분들은 잘 아시겠지만.
2년동안 ALM에 대해서 많이 공부도 하고, 프로젝트에서 사용도 해보고 보안도 해서 나름대로 체계를 만들어서 블로그에 정리해서 올렸습니다. 공감해주시는 분들도 많았구요.

그래서 이 ALM을 제가 다니는 회사에서 전략 기술로 사용할 수 있도록 몇번 건의도 하고, 발표도 했습니다만, 회사에서는 별 반응이 없었습니다. 홍콩에 있는 친구가 내용을 보고 Global Consulting Program으로 만들자고 했을때도 준비하다가 결국 또 혼자 삽질 하겠구나 싶어서 블로그에만 포스팅 하였습니다.

그런데 이 ALM 프레임웍과 프로세스를 몇몇 회사에 구현 방안을 컨설팅 해주고 자료를 넘겨준 일이 있었는데, 그 회사들이 ALM 프레임웍을 실제 구현해서 아주 자알~~ 팔고.. 그리고 여기저기서 세미나도 하시더군요.

무슨 댓가를 바라고 한일도 아니고 정보를 공유하고자 한일인데...
- 내가 만든 이론들이 왜 내가 다니는 회사에서는 가치를 인정 받지 못하고 다른 회사 사람들이 열광하고 돈을 벌고 있는지..
- 이론들을 가져다가 쓰는 사람들은 IP(Interllectual Property-지적인 권리)에 대한 비용은 지불은 생각도 안했지만, 제 글에 대한 출처를 왜 공개 안하시는지...

별일아닐 수도 있지만 여러가지로 섭섭한 아침입니다.
TAG ALM

IBM에서 ALM E-Book을 무료 배포합니다.

ALM | 2009.06.30 15:28 | Posted by 조대협
http://www.infoq.com/articles/scaling-agile-with-calm

C ALM이라는 개념을 사용합니다. C는 Collaboration을 의미합니다. 애자일 사상에 근간한 ALM을 설명합니다.
Erich Gamma가 필자로 참여했다는 것이 흥미롭고, 그리고 다들 아시겠지만 IBM은 Rational 제품군을 위주로 한 케이스 툴과 Jazz라는 ALM 플랫폼을 가지고 있기 때문에 강력한 ALM 벤더중의 하나입니다.
그러나 Rational 제품들은 툴의 복잡도가 높아서 실제 구현할때 구현 난이도가 고민인 부분중에도 하나입니다.

'ALM' 카테고리의 다른 글

Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
현재 진행하고 있는 프로젝트에서 Trac을 도입해서 사용하고 있습니다.
Trac 뿐만 아니라 사실상 거의 모든 이슈 트랙킹 시스템을 이용하여 팀 일정 관리를 할때 공통적으로 생기는 문제 같은데,
팀관리에서 가장 중요한것은 어떤 TASK를 누가, 언제 하느냐 입니다.
이슈 트랙킹 시스템은, 어떤과 누가를 잘 추적할 수 있게 해줄뿐만 아니라 Comment등을 통한 History 기능으로 어떻게 하느냐까지 잘 관리할 수 있습니다.

그런데 문제는 "언제" 즉 시간에 대한 부분입니다.
이슈 트랙킹 시스템들은 대부분 Time Frame,Mile stone, Due date 식으로 대략 Task 단위의 시간을 제공합니다만, 프로젝트 관리에 있어서 간트 챠트만한것이 없습니다. 문제는 이 이슈 트랙킹 시스템들이 간트 챠트를 제대로 제공하지 않는 경우가 허다하다는 것입니다.

매일 아침 Scrum 미팅을 할때, 간트 챠트를 이용하면 팀원이 무엇을 하고 있는지, 어제와 그제 무었을했고, 이번주에 무엇을 하고 있는지를 비주얼하게 보여줘서 리소스를 할당하는데 편리한데
이슈 트랙킹 시스템은 각 태스크로 관점이 맞춰져 있어서 사실상 팀관리를 하는데 어려움이 많습니다. (사실상 이부분은 엑셀이 더 편할것 같습니다.) 몬가 방법을 더 찾아봐야할것 같습니다.

ALM의 괴리.

ALM | 2009.05.14 22:58 | Posted by 조대협
요즘 매일 대전으로 출퇴근을 하고 있습니다.
계약 관계가 복잡하게 얽혀서 근 3달정도 지연이 되어 버린 프로젝트입니다.
원래는 Project Manager와 Cheif Architect 역할로 계약이 되었지만, 구현일정 관계로 한 모듈의 설계와 구현을 모두 맏고 있습니다.

그러다 보니, 처음에는 ALM을 도입하여 SVN을 이용한 형상관리, WAS Configuration Management, Trac을 이용한 이슈 관리와 Wiki를 이용한 문서화를 진행하려고 계획을 했었습니다.
이번달이 아니라 3월경에 SOW(Scope Of Work )작업으로 일주일정도 진행한 적이 있었는데, 그때는 코딩할당량이 없어서 그나마 프로젝트 관리를 할 수 있었습니다만,
지금은 구현에 치여서 ALM적용을 하지 못하고 있습니다. (부분적으로나마 하고는 있지만... 왠지 체계가...)
프로젝트 관리와 프로세스의 셋업등은 역시나 개발을 하면서(선행 개발이 아니라, 직접 모듈 개발)는 쉽지가 않은 일입니다.
이번에 깨달은 교훈중에 하나는 ALM을 적용하기 위해서는 그만큼의 Man month가 필요하다는 것입니다.누가 그러더군요.. No free lunch...

'ALM' 카테고리의 다른 글

ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20

Trac

ALM | 2009.04.09 17:03 | Posted by 조대협
이번 프로젝트에 6번째로 ALM을 사용해보기로 결정하였습니다.
SVN,WIKI,Issue Tracking이 모두 필요하고 설치할 시간도 없어서 Trac (Trac On Windows - 압축만 풀면 사용 가능하게 한 패키징)을 설치하여 사용하고 있습니다.

올인원 패키지이고 플러그인을 지원해서 좋긴하지만 JIRA의 파워풀한 기능을 경험한 저로써는 불편한점이 많더군요. (예를 들어서 조회 조건 같은 것을 Query로 직접 코딩해야 하는 불편함등.)

이번 프로젝트도 상당히 긴 프로젝트가 될것 같습니다. Trac 기반의 ALM을 시험해볼 좋은 기회가 되겠지요.

Trac에 설치한것은 다음과 같습니다.
- TOW (Trac On Windows)
- Timingandestimation plug in
- ScrumBurnDownChart plug in
을 설치하였습니다. Burn down chart 관리함에 있어서 Estimated time을 얼마나 잘 예측하고 시간에 대한 관리를 어떻게 할 수 있느냐가 주요 포인트가 될것 같습니다.
 

'ALM' 카테고리의 다른 글

IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18

ALM Overview PPT

ALM | 2009.03.16 15:15 | Posted by 조대협

그간 정리해왔던 ALM에 대해서 전체 그림을 다시 한번 정리하였습니다. 컨버팅 과정에서 폰트가 깨져서 좀 보기가 어려울 수 있습니다. 별도로 자료가 필요하신분들은 요청하시면 보내드리도록 하겠습니다.

ALM의 전체 Full Process와 어떤 제품으로 어떻게 구혀하는지, 그리고 구현 전략에 대해서 기술되어 있습니다.

감사합니다.


ALM (Application Lifecycle Management)
View more presentations from Byungwook.

'ALM' 카테고리의 다른 글

ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
TAG Agile, ALM, PPT

언제 어떤 코드 리뷰 기법을 사용해야 하는가?

 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까?

 코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다.

, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다.

인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다.

 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다.

 1 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍쳐의 큰 틀이 되며, 추후 개발에도 이 아키텍쳐는 크게 변경되지 않는다. (1 Release 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다.)  그래서 1 Release후에 정밀 Inspection을 해서 아키텍쳐의 안정성을 검증할 필요가 있다.

 개발 후반의 시스템 테스트는 주로 비기능적인 요건 (성능,안정성등..)에 대한 성능 테스트가 이루어지는 단계이기 때문에, 테스트 시나리오가 미리 잡혀져 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있기 때문에, 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

 인스펙션을 수행하는 주체는 전문 SI Task Force를 운영하여 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체 (네이X)와 같은 업체는 QA 조직내에 자체적으로 인스펙션팀을 운영하는 것을 권장한다. 그외의 일반 업체 ()나 기업의 경우 인스펙션팀을 운영하기 보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

 인스펙션의 결정 주체는 주로 PMO(Project Management Office) AA (Application Architect) 되는 것이 바람직하다, 대체로 개발 주체 조직 외부에서 인력을 데리고 오고, 여러팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

 팀리뷰

팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다.

일주일에 한번정도, 한시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다.

리뷰는 발표자가 리드를 하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케쥴로 조정을 해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용하여 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management Task로 연결이 되어야 한다.

리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해서 반영 내용을 반드시 검증하도록 한다.

 웍쓰루 (WalkThrough)

일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다.

팀리뷰처럼 PL이나 시니어 개발자가 중재를 하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

 Peer Review

신입 개발자 교육이나, 해당 제품이나 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식공유)와 품질 유지를 위해서 유용하다.. 대신 리뷰어의 Task 부담이 가중되기 때문에 (예상하는 것 보다 많이. 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

 요약

 

시기

효과

변경에 대한 비용

수행 비용

주체

인스펙션

1 Release,
시스템 테스트

매우높음

매우 높음

높음

PMO,QA,AA

팀리뷰 ★

매주

높음

보통

보통

PL

웍쓰루

비정기적

낮음

보통

낮음

원하는 개발자

Peer Review

필요한 경우

경우에 따라 높음

낮음

보통

시니어 개발자

 본인의 경험상 팀리뷰가 가장 효과가 높다. Peer Review는 팀원간의 실력 편차가 클 때 탄력적으로 운영하였고, Enterprise System과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍쳐로 인해서 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸떼 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 내가 만든 코드를 남이 잘못되었다고 이야기 한다.” 입니다.

리뷰의 주요 목적은 결함의 발견과 개선 방안입니다. 흔히 농담 삼아서 창던지기라고 이야기 하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하게 됩니다. 그래서 실제로 인스펙션을 해보게 되면 개발자는 인터뷰를 당하는 것에 대해 취조 당하는 느낌을 가지게 될 수 도 있고 방어적으로 행동할 수 도 있게 됩니다.

 팀리뷰의 경우 감정싸움까지 가는 경우가 허다하지요.

 팀리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신 공격을 받지 않도록 중재하는 기능도 필요합니다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 사람 사이의 관계에서 발생되는 일이기 때문에 문화의 변화가 필수적입니다.

 또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리가 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이루어져야 합니다.

 경험상으로 팀리뷰가 팀에 자리잡기 위해서는 좋은 리더가 있다하더라도 최소한 1달정도의 (통상 2) 기간이 필요합니다. 급하게 할일은 아니라는 겁니다.

들어가기에 앞서서.

소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다

코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다

코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드리뷰 기법일 수 록, Defect의 발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 Defect의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 주니어 개발자에게로의 지식 전달등의 부가적인 목적들도 함께 가지고 있다

코드 리뷰 스펙트럼

코드 리뷰의 기법을 나누는 방법은 크게, 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, Offline에서 직접 커뮤니케이션을 하느냐? 또는 메신져,Email 이나 기타 자동화된 코드리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

 먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다

) 코드리뷰 기법중에는 Pair Programming이 종종 언급되고는 하지만, 본인의 사견상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용한다는 것은 매우 어렵다고 판단하기 때문에, 코드 리뷰 스펙트럼에서는 제외한다. 


코드 인스펙션

코드리뷰 기법중에서 가장 정형화된 패턴의 기법이다.전문화된 코드리뷰팀이 시스템이 어느정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다.인스펙션팀은 크게 4가지 역할을 가지고 구성이 된다.

1.     Moderator

는 인스펙션팀의 실제적인 메니져로 생각하면 된다. 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다.

또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다.

예를 들면, 인스펙션팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청하여 담당 개발자를 섭외하거나 소프트웨어 설계 문서등을 받아다가 인스펙션팀에 전달한다.

또는 인스펙션된 결과에 대해서 테스트가 필요할 때, 테스팅 환경을 확보하고 인원 (DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 갖는다.

가장 중요한 역할중의 하나는 인스펙션이 언제 끝날 것인지 (Exit Criteria)를 정의하는 역할을 갖는다.

2.     Reader

Reader는 각종 산출물들을 읽고, 인터뷰등을 통해서 전체 시스템을 이해하여 인스펙션팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해서 팀내에서 가장 많은 도메인 지식을 갖는 사람이다.

Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라서 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라서 인스펙션을 진행하게 된다.

3.     Designer/Coder

Designer Coder Reader가 지시한 방향에 따라서 코드를 검증하고 잠재적인 Defect의 발견 및 권장 수정 방안을 만들어 낸다.

4.     Tester

Tester는 인스펙션이 진행중인 모듈에 대해서 테스트를 수행하고 Defect를 찾아내는 역할을 수행하며, 이외에 Designer Coder가 권장한 수정 코드안에 대한 검증과, 실제 업무 개발자가 수정해온 코드에 대한 검증 작업을 수행한다

4가지 역할을 가지고 인스펙션은 다음 6단계로 진행된다.

 

1.     Planning

전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건 (금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건, 등등). 그리고 인스펙션 팀이 이때 SET UP이 된다.

2.     Overview

이 단계에서는 인스펙션 팀에 시스템과 구성 제품등에 대한 교육이 이루어지고, 팀원간의 역할이 정의된다.

3.     Preparation

Inspection을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 Tool (테스팅 툴이나, profiler, Application Performance Monitoring 도구..)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축한다.)

4.     Meeting (Inspection)

각자의 역할에 따라서 Inspection을 수행한다. Inspection을 통해서 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실업무 개발자에게 전달되어 FIX되도록 하고, 필요에 따라서는 권장 수정안을 전달하기도 한다.

5.     Rework

보고된 Defect를 수정한다.

6.     Follow-up

보고된 모든 Defect가 수정되었는지 확인한다.

 팀리뷰

팀리뷰는 코드 인스펙션보다 좀 덜 정형화 되었지만 그래도 일정한 계획과 프로세스를 따른다.

코드 인스펙션 프로세스의 단계 (Planning ,Overview ,Preparation등의 사전 준비 단계는 생략된다.) 역할은 중복되거나 생략될 수 있는데, 발표자(Author) Moderator는 필수적으로 구성된다.

리뷰시간에는 발표자(코드를 만든 사람)가 코드에 대한 설명을 하고, 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정하여 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다. (일정에 반영되어야 한다.)

 Moderator는 프로젝트 관리자 (PM이나 PL)이 될 수도 있으나, 팀내에서 기술적인 실력이 가장 좋은 Senior 개발자가 그 역할을 맏는 것을 권장한다

 일주일에 한번정도 팀리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점 (Short Release) 시점에 수행을 하거나, 테스트 결과를 가지고 리뷰를 하는것도 좋은 방법이 된다

 필자의 경우 프로젝트를 수행할 때, 일주일에 한번 정도 팀리뷰를 진행하였으며, Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해서 팀리뷰를 진행하도록 개발자에게 지시 하였다.

 리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 코드 리뷰 결과라는 분류를 따로 만들어서 관리하였고, 각 의견은 TASK로 생성되어 스케쥴에 포함되었다.


<그림. 팀리뷰 리포트>

웍쓰루 (Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법중에서 가장 비정형적인 방법중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나, 아이디어 수집을 위해서 사용될 수 있다.

개발을 위한 프로세스에서 보다는 “Bug 사례에 대한 회의와 같은 정보 공유성격에 유리하다.

유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다.

웍쓰루는 정기적으로 (주일에 한번) 진행할 수 도 있으며, 또는 정보공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다. (정기적으로 진행하는 것이 참여율이나 집중도가 더 높다.) 

Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review2~3 (주로 2)이 진행하는 코드 리뷰의 형태이다.

코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.

 사전 준비등이 거의 필요없고, 필요할때 마다 자주 사용할 수 있는 리뷰 방법이다.

주로 Senior 개발자(사수) Junior 개발자를 멘토링할 때 사용할 수 있으며, Junior 개발자에 대한 교육과 함께, Junior 개발자가 양산한 코드에 대한 품질을 관리할 수 있다.

 그러나 이 기법은 Senior 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, Senior 개발자의 시간 투여량이 많은 만큼. Senior 개발자의 참여도가 떨어질 수 있다. (형식적으로 될 수 있다. )그래서 프로젝트 관리 관점에서 Peer Review 에 대해서도 프로젝트 스케쥴상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 시켜야할 상황이 있었고, 그때 이 Peer Review를 진행하도록 하였다. 결과적으로 만족할만한 품질을 얻었지만, Senior 개발자에게 Review에 대해서 Task를 지정하고 스케쥴링을 하였음에도 불구하고, Senior 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있기 때문에, 팀원간의 실력 편차와 난이도에 따른 시간 배분과 함께, 경험적 (3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다. )인 작업량 측정이 필요하다

Passaround

코드리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다.

Passaround는 번역하자면 돌려보기이다. 온라인 보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애를 받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 Ownership이 애매하여 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해서 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

 이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다

필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품의 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맏는 개발자가 개발팀에 속해 있었기 때문에 원할한 Passaround 리뷰가 가능했고, 이슈(버그) 트랙킹 시스템 (AtlassianJIRA와 같은)과 소스 코드 Viewing system (AtlassianFisheye)이 많은 도움이 되었다

지금까지 간단하게나마 코드 리뷰의 기법에 대해서 살펴보았다. Formal한 리뷰 (코드 인스펙션..)등에 대한 설명이 많은 것은, Formal한 리뷰가 좋아서라기 보다는 정형화 되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다

회사의 성격 (SI,게임,임베디드,인하우스개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다.

그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다.
결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요.

그런데, 만약에 Short Release를 통해서 매번 회귀 테스트를 진행했더라면 어땠을까 하는 생각이 문득 집에 도착한후에 들더군요. 그러한 문제는 아주 조기에 발견이 되었을 것이고, 초반에 아키텍쳐 수정이 가해졌을 것이며, 이렇게 비용을 들여서 Code Inspection을 하거나 추가 비용을 들여서 하드웨어를 증설할 일도 없겠지요...

그리고 여러개의 시스템이 연결된 시스템이기 때문에, 이제서야 통합 작업을 수행합니다. 마찬가지로 Interative and ieration 전략을 사용했더라면 초반부터 통합을 해왔기 때문에 통합때문에 드는 작업이 거의 없었겠지요.

특히 통합이 일정대로 원할하지 못한 경우, 이번에 튜닝을 위해서 거의 5명의 벤더 엔지니어를 불러다 놓고 하루종일 거래 개통도 되지 않아 엔지니어들이 대기하다가 돌아갔습니다. 보통 벤더 엔지니어의 하루 몸값은 Charging을 하는 경우에는 100~120만원선이 됩니다. 5명이니 대략 아무것도 안하고 600만원을 날린셈이 되는 것입니다.

회귀 테스트나 Iteration 방법론, Short Release 를 실제 프로젝트에서는 시간이 없다. 예산이 없다는 이유로 잘 사용하지 않습니다. 기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요.

결국은 위의 사례와 같이 오픈 연기, 하드웨어 추가 구매, 튜닝 컨설팅등의 추가 비용이 발생하고, 끊임없는 야근과 누더기 코드로 이어집니다.

반대로 지난번 프로젝트를 진행했던 S사의 경우 제가 진행했던 파트는 2주 주기의 Short Release를 사용했고, Short Release 마다 어떤 형태로든 비기능 테스트를 통해서 끊임없이 아키텍쳐를 검증했기 때문에, 지금 프로젝트에서는 통합에 대한 이슈나 아키텍쳐를 통째로 흔드는 일이 없습니다.

항상 자연계 열역학 제 1의 법칙을 이야기 하지만, "에너지 불변의 법칙"은 사람이 일할때도 통하나 봅니다. 개발과정에 생략한 테스트와 검증은 프로젝트 말에 그만한 부담으로 다시 돌아옵니다. 아니 에너지 불변의 법칙이 아니라, Defect 증폭의 법칙이라고 해야할까요?

ALM / Polarion Review

ALM/Task Management | 2009.02.20 19:05 | Posted by 조대협
ALM에 대해서 정리하다가 오늘은 Polarion (http://www.polarion.com) 을 직접 인스톨해서 Evaluate해보았습니다.
Polarion이 개념상으로도 만족 스럽고 무엇보다 AJAX기반의 깔끔한 UI가 마음에 들어서 비싼 가격에도 불구하고 미련이 남아서 다시 테스트를 해보았습니다.

Polarion ALM은 Enterprise Version으로 많은 기능을 제공하고 자체적으로 CMMI Level까지 충족시키는 프로세스를 포함한다고 해서 복잡도가 높고 속도가 느린 것으로 알려져있습니다. 그리고 가격도 만만하지 않구요.
오늘 테스트 한 버전은 Polarion Track + Wiki 라는 버전으로 일종의 Light 버전으로 생각하면 됩니다.

테스트해보고 딱 드는 생각은 Trac의 Commercial Version이다. 입니다.

1. 가격
25 User를 기준으로 1250$ 입니다. 가격은 만만합니다.

2. 구성
Issue Tracking + Wiki + Subversion + 간단한 CI 입니다.

3. 장점
일단 UI가 미려하고, 쉬운 인스톨에 인스톨만 끝나면 Trac과 마찬가지로 All in on package이기 때문에, 처음에 진입하기가 수월합니다.
그리고 하나의 UI내에서 모든 인터페이스를 제공하기 때문에, Seamless integration이 이미 구현되어 있습니다.
Eclipse Plugin 을 제공하고 또한 Java platform만 아니라 make나 다른 빌드 스크립트를 제공하기 때문에, 플랫폼에 종속성이 낮습니다.
또한 JIRA와 마찬가지로 Workflow에 대한 정의가 가능합니다. 이건 꼭 필요하고 강력한 기능입니다.
멀티 프로젝트를 지원하는 것도 장점중의 하나라고 할 수 있겠습니다.
무엇보다 Task간의 Hierachy 정의가 가능하고 이를 리스트에서 트리형태로 보여주는 것은 아주 장점중의 하나입니다.

4. 단점
Issue Tracking의 경우, Iteration이나 Release Plan에 대한 개념이 없어서, Short release (개발 프로세스를 작은 단위로 쪼개서 프로젝트를 진행하는 개념, Scrum의 Sprint를 생각하면 됩니다.) 이게 약간 걸리기는 하지만 Time point라는 개념으로 충분히 커버라 가능합니다..
또한 Wiki의 경우는 어느정도 기능을 가지고는 있지만, Confluence Wiki에 비하면 많이 떨어지는 것은 사실입니다. Confluence Wiki의 경우 Export나 MS-WORD 기능이 강력하기 때문에, 문서를 밖으로 Export하여 산출물로 활용할 수 도 있는데,  Polarion도 Wiki에 PDF Export기능이 있기는 하지만, Confluence 대비해서 얼마나 경쟁이될지는 미지수 입니다.
CI 부분을 살펴보면, 역시 Hudson에 익숙해져 있는 저로써는 눈에 거슬리는 부분이 많습니다. Hudson의 강력한 플러그인으로 여러 리포트를 만들어낼 수 있는데 반해서, Triggering으로 Build를 돌려주고 결과를 로깅하는 정도입니다.
 그러나 빌드 #와 Task를 연결 시켜주는 기능은 마음에 드는 군요.

5. 총평
말 그대로 Trac의 Commercial Version이라고 보시면 될것 같습니다.
쉬운 인스톨과 통합된 환경, 미려한 UI, 낮은 가격으로 ALM의 성숙도를 아주 높게 끌고 가지 않을 것이라면 손쉽게 선택할 수 있는 대중적인 솔루션이 아닌가 싶습니다. 조금 더 유연한 환경을 원하는 사람들을 위해서라면 글쎄요.. 그 부분에 대해서는 의문이 듭니다만, 충분히 추천해볼만 한 솔루션이라고 봅니다.




Adapting JIRA For Scrum
Scrum을 JIRA로 구현하는 방법인데, 간단하지만 실용적인 가이드 입니다. 확장 여지는 있지만 기본 방향은 권장할만 합니다. 참고하세요.
TAG ALM, JIRA, Scrum

재미있는 ALM 도구 발견

ALM | 2009.02.20 14:53 | Posted by 조대협
http://www.inflectra.com/HomePage.aspx 에서 제공하는 SpiraTeam이라는 시스템이다.
가격도 매우 저렴하고
무엇보다 마음에 드는것이, Requirement 부터 Test case까지 End2End 추적이 가능하도록 되어 있고
Release 관리와, Iteration 관리.. 그리고 Requirement와 Task에 대한 추적성까지 깔끔하게 제공한다는 것이다.
UI는 다른 툴에 비해서 다소 떨어지는 것 같지만 개념적으로 매우 마음에 드는 도구이다.
Report도 Velocity나 기타 왠만한 Reporting도 다 제공하고, Defect(Bug) Tracking 시스템도 내장되어 있고 또는 JIRA나 Bugzilla와 같은 외부 Bug tracking 시스템과 연계 가능한 플러그인도 가지고 있다.

단 빌드나 고수준의 테스팅에 대한 연계성은 다소 떨어지기 때문에, (Code Inspection이나 Coverage등) 이 부분은 별도의 커버가 필요할듯하다.

아래는 Dashboard에 대한 스크린샷

'ALM' 카테고리의 다른 글

Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
오랜만에 ALM 업데이트  (0) 2009.02.17
PDF 버전입니다.