ALM/Test Automation

TestLink를 이용한 Test Case 관리 자동화

Terry Cho 2013. 12. 31. 01:05

TestLink를 이용한 Test Case 관리

조대협 (http://bcho.tistory.com)


테스트 케이스가 어떻게 요구 사항에 맵핑이 되는지, 테스트 케이스의 시나리오는 어떻게 되고 요구 되는 결과 (Expected Result)는 어떻게 되는지, 테스트 결과는 어떻게 되는지, 그리고 Version 별 릴리즈에 따른 테스트 계획과 결과는 어떻게 되는지를 관리할 수 있는 도구가 필요하다.

 대부분 테스트 엔지니어나 개발팀들이 위의 테스트 도구 자체에는 관심이 많은 것 처럼 보이지만, 정작 테스트 프로세스나 테스트 케이스 전체를 관리하기 위한 관리도구에는 그다지 집중하지 않는 것 처럼 보인다. 테스트 케이스 자체를 구현하는 것도 중요하지만, 전체 시스템에 대해 어떻게 테스트를 하고, 테스트에 대한 내용을 어떻게 관리할 것인가도 상당히 중요한 일이라고 본다.

그렇다고 거창하고 복잡한 프로세스가 필요하다는 이야기가 아니라 최소한의 테스트 조직에서 테스트 케이스에 대한 관리를 할 수 있는 툴이 필요하다는 것이다.

조금 쉽게 설명하면 테스트 케이스를 액셀로 만들어서 그 액셀 문서를 여러 사람이 나눠서 테스트를 진행하고 결과를 기입하던 절차를 자동화 했다고 생각하면 된다.

Test Link

오픈소스 도구중에서 널리 사용되고, Learning Curve가 낮은 도구중의 하나가 TestLink 라는 도구이다. http://testlink.org/

먼저 TestLink에서 사용되는 개념에 대해서 먼저 알아보자



Test Project

테스트 프로젝트는 테스트를 수행하는 프로젝트 자체를 이야기 한다. 블로그 서비스를 만들었을때 블로그 서비스 프로젝트”; 와 같은 단일 테스트 프로젝트로도 만들 수 있고, 내지는 블로그 서비스 모바일 클라이언트 테스트”, “블로그 서비스 웹 서비스 테스트와 같이 하나의 서비스에 대해서도 특성에 따라서 여러가지 프로젝트로 분할해서 테스트를 진행할 수 있다. 분할의 기준은 자유롭지만, 테스트 팀 단위로 분할 하는 것이 관리에 용이하다. (클라이언트 테스트 팀, 웹 테스트 팀 또는 미국 테스트 팀, 한국 테스트팀 등)

Test Specification

Test Spec은 테스트를 진행하고자 하는 테스트 케이스들의 집합이다.

Test Spec Test Suite, Test Case로 나뉘어져 있는데, Test Suite은 대분류, Teste Suite의 소분류의 테스트 케이스라고 보면 된다.

흥미로운 점중의 하나는 TestLink에서는 이 Test Case에 대한 버전 관리가 가능하다는 것이다. 예를 들어, “로그인이라는 Test Case, 예전에는 Facebook 계정을 이용한 로그인만을 테스트하는 케이스였는데, 향후에, 케이스가 추가 되서, Google 계정 로그인도 지원한다면, Test Case의 버전을 새로운 버전으로 정의할 수 있다.

Test Plan

테스트 플랜은 실제 진행하는 테스트를 의미한다. Test Project내에서, 테스트 대상 시스템의 특정 버전을 테스트 하기 위해서 Test Spec내의 Test Suite/Case를 모아 놓은 것을 Test Plan이라고 한다. Test Spec이 전체 테스트 케이스의 집합이라면, Test Plan에서는 실제로 이번에 테스트 할 Test Suite/Case들을 모아 놓은 subset이다. Test Plan Test Case를 맵핑할때, 실제 어느 Test Engineer가 테스트를 진행할지 Test Engineer assign할 수 있다.

Test Execution

Test Plan을 세웠으면, 실제로 각 Test Engineer가 자기에게 할당된 테스트를 수행하고, 테스트 결과 Pass/Fail 여부를 체크한다. 만약에 실패한 케이스일 경우에는 재 테스트를 하는데, 그 간 Minor Release가 되었을 경우에는 Minor Release 버전으로 테스트를 다시 해서 Pass 여부를 결정한다.

Test Report

마지막으로, 테스트 결과를 리포팅한다. 테스트 실패,성공 여부, 주요 Test Category (TestSuite)별 성공 실패 여부등을 리포팅 한다.

Test Link 사용 예제

그러면 이 흐름에 따라서 Test Link에서 실제로 어떻게 Test를 수행하는지를 알아보자. 먼저 TestLink를 인스톨하고

1.     Test Project 생성

먼저 Create New Project에서 테스트 프로젝트를 생성한다.

프로젝트 명과, 테스트 케이스에 적용할 prefix를 정의한다.



몇가지 옵션들이 있는데, TestLink BugZilla,Mantis,JIRA와 같은 버그 트랙킹 도구와 연동이 가능하다. “Issue Track Integration”을 선택하면, 버그 트랙킹도구를 연결할 수 있다. (별도의 Configuration이 필요하다.)

          • Ÿ   - Enable Requirement Feature : Requirement TestLink에 정의해서, Requirement à Test Case까지의 추적성을 부여할 수 있다.

          • Ÿ   - Enable Testing Priority : Test Case에 가중치를 부여할 수 있다.

          • Ÿ   - Enable Test Automation : 수동으로 테스트 하는 것이 아니라, Test Case SOAP UI Selenium과 같은 다른 테스트 도구를 연동하도록 설정할 수 있다. 

자 이제 테스트 프로젝트가 위의 그림처럼 생성되었다.


2.     Test Spec 작성

상단 메뉴에서 “Test Specification” 이라는 곳으로 들어가면 Test Suite/Case를 정의할 수 있다. 해당 메뉴로 들어가면 Test Suite/Case를 넣을 수 있는 화면이 나온다. 여기서 좌측 아래에 있는 트리를 선택한 후 오른쪽 버튼을 눌러서 Test Suite을 생성한다. Test Suite 이름과 간단하게, Test Suite에 대한 내용을 “Detail” 부분에 기술한다. 본인의 경우에는 이 Test Suite Scrum Epic 1:1 맵핑을 시키고, Epic에 있는 Description을 그대로 사용한다.

Test Suite Test Case의 집합으로, Test Case에 대한 대분류 정도로 생각하면 되고, 생성된 Test Suite들은 아래 그림과 같이 폴더 형태로 생성된다.


다음으로, 생성된 TestSuite (폴더)에서 오른쪽 버튼을 눌러서 Test Case를 생성한다.



Test Case는 개개별 테스트 시나리오로, 먼저 Summary 부분에 어떤 내용을 테스트 하는지 기술 하고, PreCondition을 입력한다. 예를 들어 Facebook 계정을 이용해서 로그인하는 시나리오를 테스트 한다면, Precondition사용자는 Facebook 계정을 가지고 있어야 한다.” 로 정의할 수 있다.

다음으로 구체적인 테스트 절차를 입력한다.

Step을 입력하는 버튼을 누르면, 아래와 같이 Step을 입력할 수 있는 부분이 나온다. 쉽게 이야기해서 테스트 절차가 된다. 각 단계별로 필요한 Action“Step actions”에 적어놓고, 우측에는 “Expected results”에 정상적으로 Action을 수행했을때 기대되는 결과를 기록한다.


위와 같이 Step by Step으로 action을 정의할 수 도 있지만 굳이 필요하지 않다면,아래 그립과 같이 하나의 action안에 전체 Step을 기술할 수 도 있다.



여기 까지 진행하면, Test Project Test 시나리오를 담은 Test Specification이 모두 완성되었다.


3.     Test Plan 작성

이제 실제로 테스트를 진행하기 위해서 Test Plan을 작성해보자. Home 메뉴에서 Test Plan Management를 선택한후에, 아래와 같이 Test Plan을 생성한다.



4.     Build Version 생성

다음으로 Test Plan내에서 사용할 Build Version을 정의한다.



처음에는 1.0과 같은 Major 버전을 정의하고, 개발팀에서 Minor 버전을 Release할때 마다 1.1, 1.2 식으로 Minor Version도 같이 생성한다. 그리고 각 버전에는 아래 그림과 같이 Release date를 선택해놓으면 관리하기가 편리하다.



5.     Test Suite/Case Test Plan Assign

이제 Test Plan Test Specification에 정의된 Test Case들을 맵핑해보자 메인화면에서 Test Plan Contents 라는 메뉴에서 “Add Remove Test Cases”를 선택한다.

아래와 같이 Test Case를 선택할 수 있는 창이 나오는데, 좌측 아래에서 Test Case를 골라서, 우측 상단에서 처럼 Test Engineer Test Taget Version을 선택한 후에, “Add Selected”를 선택하여, 테스트 케이스를 Test Engineer에게 할당한다.



이제 테스트 수행을 위한 준비가 다 되었다. 개별 Test Engineer에게 상세한 Test Scenario들이 모두 배정 되었다.


6.     Test Execution

이제 테스트를 수행하는데, Test Engineer들은 할당된 Test Spec Step action에 따라서 테스트를 수행하고, 성공/실패 여부를 아래 그림과 같이 선택한다.


위의 그림은 테스트가 성공했을때의 케이스이다. 만약에 Test가 실패하면, Failed라고 나타나는데, 이때 BUG management의 벌레 모양 버튼을 누르면 아래와 같이 버그 트랙킹 시스템에 등록된 버그 번호를 입력할 수 있다.



이렇게 버그 번호를 입력하면, Relevant bugs에 해당 버그에 대한 링크가 생성되고, 이 링크를 누르면, 해당 버그 트랙킹 시스템으로 이동한다. Relvant bugs 항목을 보면 이 Bug의 현재 처리 상태가 나온다. 위의 그림에서는 “Testing” 상태로 나타나는데, 이 상태는 버그 트랙킹 시스템의 상태를 그대로 출력해준다. Open이나 In Progress 처럼 개발자가 버그 수정을 하다가 수정이 끝나서 위의 그림처럼 “Testing”상태로 상태를 바꿔 놓으면, Test Engineer가 버그가 수정되었음을 인지하고, 버그 트랙킹 시스템에서 수정 결과와 버전을 확인한 후에, 그 버전(Minor 버전)을 선택하여 다시 Test를 수행한후 Pass/Fail 여부를 결정한다.

이 과정에서 TestLink와 버그 트랙킹 시스템간의 프로세스 연계가 중요하다.

테스트가 실패한 경우, Test engineer가 버그 트랙킹 시스템에 Bug를 등록해야 하고, Bug가 수정되면 개발자가 해당 Bug를 다시 Test Engineer에게 assign한후에, Test Engineer가 테스트를 확인하면, 버그 트랙킹 시스템에서 해당 Bug Close 처리하도록 하는 것이 권장되는 프로세스 이다.

Test Execution 시에, 1.0에서 발견된 버그라도 수정이 1.2 버전에서 수정되었다면, Test Execution에서 테스트 수행전에 “Build to Execute” 리스트박스에서 수정된 버전을 선택해서 테스트를 진행해줘야 한다.


7.     Reporting

테스트가 종료되었으면, 상단 메뉴의 “Test Reports”에서, 여러 형태의 테스트 리포트를 생성할 수 있다.



위의 그림은 Test Suite 별로 성공/실패 율과 전체 Test Case 수를 리포팅해주는 화면이다.

Test Link 향상된 기능

이외에도 Test Link는 앞에서 잠깐 언급한 바와 같이 Selenium,SOAPUI와 같은 테스트 도구 뿐만 아니라, JUnit과 같은 다양한 테스트 프레임웍 연동은 물론이거니와, Jenkins까지 같이 연계가 가능해진다.

기존에 테스트 도구만을 사용했을 때는 전체 테스트 현황이나 History, 상세한 테스트 케이스 특히 JUnit과 같은 코드가 아니라, Human readable한 형태로 테스트 케이스를 관리할 수 있게 해주며, 요구 사항에서 부터 Test Case 및 결과에 까지의 추적성을 보장해주기 때문에 매우 편리한 도구이다. Learning Curve도 상당히 낮은 도구이기 때문에 반드시 사용해보기를 권장한다.

그리고 누가 강조하지만, 도구는 도구일뿐이다. 어떻게 테스트팀의 구조를 잘 세팅하고, 프로세스를 잘 정의하느냐가 가장 중요한 항목이다.

그리드형

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

Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06