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


Archive»


 

'QA'에 해당되는 글 3

  1. 2013.06.11 개발 환경(dev,stage,qa,production)
  2. 2012.08.21 테스트 팀의 조직 구조 (1)
  3. 2009.04.09 Software Testing Proces
 

개발 환경(dev,stage,qa,production)

ALM/배포(Deployment) | 2013.06.11 00:13 | Posted by 조대협

서버 개발을 가정하고, 먼저, 개발 및 운영에 사용할 서버를 어떻게 배치 해야할지를 살펴보자

일반적인 서버 개발환겨은 아래와 같이 local,dev,integration,qa,staging 그리고 production 환경을로 나뉘어 진다. 각자의 개발 과정에 따라, 각자의 역할과 목적이 다르고, 그에 따라서 시스템의 크기도 다르다.



꼭 모든 환경을 갖출 필요가 없으며, 프로젝트 환경에 따라서 각 환경을 합치거나 생략해도 된다.

그러면 각 환경에 대해서 살펴 보도록 하자.

환경

설명

local

로컬 개발 환경

먼저 개발을 하려면, 각자 개발자 PC에 개발 및 테스트 환경이 셋업 되어 있어야 한다. 각 개발자마다, 설치된 서버 환경을 local 환경이라고 한다. (. PC MySQL등의 DB Tomcat등의 제품을 설치하고, Eclipse와 같은 개발툴과, 컴파일러 등이 설치되어 있는 환경)

local 환경을 구축할시에 가장 주의해야 할점은 모든 개발자가 같은 개발 환경을 사용해야 한다는 것이다. 실제로 많이 일어나는 문제인데, 다른 version JVM를 사용하거나, 다른 버전의 Tomcat을 사용하거나 Lang (문자 local 설정)을 서로 다르게 해서, 정작 코드를 합칠때, local에서 잘 작동했던 코드가 작동하지 않는 경우가 많다.

개발 환경을 표준화 하는 방법은 여러 방법이 있지만, 전체 개발 환경 (JDK, Eclipse, 라이브러리) zip 파일 형태로 묶어서 사용하는 방법이 가장 일반적이다. 또는 뒤에서도 설명하겠지만, maven을 사용할 경우, 개발에 사용되는 JDK,라이브러리 버전등을 지정할 수 있기 때문에 개발환경 차이에서 오는 문제점 상당 부분을 해소할 수 있다.

dev
서버 개발 환경

개발 환경은 각 개별 개발자들이, 만든 코드를 합쳐서 서버 환경에서 테스트해볼 수 있는 환경이다. 소스코드를 형상관리 시스템에 commit하면, 코드는 이 dev 환경에 자동으로 배포되고, 이 환경에서 테스트가 된다.

기능 개발을 위주로 하기 때문에, 서버의 환경은 production 보다 훨씬 작다. 예를 들어 production이 클러스터링 환경으로 수개의 서버로 구성된다면, 개발 환경은 한 두 개의 서버로 기능 구현이 가능한 정도로 구축하는 것이 일반적이다.

Integration

통합 개발 환경

통합 개발 환경은, 여러개의 컴포넌트를 동시 개발하는 프로젝트가 있고, 각 컴포넌트가 다른컴포넌트에 대해서 dependecy를 가지고 있을때, 컴포넌트를 통합 및 테스트 하는 환경으로 사용한다.

예를 들어 단말과 서버를 같이 개발하는 환경의 경우 이 integration 환경에서 통합을 한다.

dev 환경과 마찬가지고, 최소한의 set으로 구성하되, dev 환경에서 release가 되면 주기적으로 deploy 한다.

qa

테스팅 환경

테스트 환경은 QA 엔지니어에 의해서 사용되는 환경으로, short release 주기에 따라서, 개발환경에서 QA 환경으로 배포 되고, 여기서 기능 및 비기능 (Load Test)등을 QA 엔지니어가 수행한다.

비 기능 테스트를 수행할 시에는, production과 거의 유사한 환경을 만들어 놓고, 테스트를 수행한다. (경우에 따라서는 비기능 테스트는 release전에, production 환경에서 직접 수행하는 경우도 있다. 이런 경우는 release cycle이 매우 긴 경우 주로 사용하는데, 기업의 내부 IT 시스템 만들어서 몇 년씩 사용 하는 경우와 같은 때 이런 방식을 이용한다

staging
스테이징 환경

운영 환경과 거의 동일한 환경을 만들어 놓고, 운영환경으로 이전하기 전에, 여러 가지 비 기능적인 부분 (Security, 성능, 장애등)을 검증하는 환경이다.

production
운영 환경

실제 서비스를 위한 운영 환경

 

대부분 개발환경은 별도로 운영하는 것이 일반적이고, 상황에 따라서 integration, qa, stating 환경은 요구 사항에 따라서 합치거나 별도 운영한다. 환경이 많아지면 조금 더 다양한 형태의 검증과 각 stakeholder (테스터, 개발자, 사용자 등)별로 테스트가 쉽지만 반대로, 각 환경을 유지 하는데, 필요한 서버들과, 운영 인력이 많이 소요되는 단점이 있다.

그래서 요즘과 같이 가상화 환경을 사용하는 경우에는  이미지를 만들어놨다가, 실제 테스트나 사용을 할 경우에만 가상 서버에 환경을 deploy해서 사용하고, 사용이 끝나면 다시 이미지를 스토리지에 저장해 놓는 전략을 많이 사용한다.

테스트 팀의 조직 구조

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

Software Testing Proces

ALM/Test Automation | 2009.04.09 10:25 | Posted by 조대협
Testing process
View more presentations from Byungwook.

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

테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18
Selenium (UI 테스트 자동화)  (1) 2009.02.09
EasyMock을 이용한 단위 테스트  (4) 2008.11.07