소개

IBM®은 어떤 조직과 팀의 자동화 요구라도 충족시킬 수 있는 제품 라인을 보유하고 있다. 이들을 한데 묶어 강력한 솔루션을 만드는 것이 풀어야 할 숙제이다. 그래서 IBM에서는 기존의 표준 제품을 사용할 뿐 아니라, 강력하고 사용자 정의 가능하며 사용하기에 편리한 자동화 아키텍처를 만들기 위해 재사용 가능한 컴포넌트를 제공하는 아키텍처를 문서화하는 작업을 진행해왔다. 이 아키텍처의 목적은 불필요한 일을 하느라 시간과 노력을 낭비하겠다는 것이 아니라, 기존의 컴포넌트와 인프라를 활용하자는 것이다. 본 기사에서 설명하는 아키텍처는 완벽한 테스트 자동화 솔루션을 제공한다. 조직과 팀에서는 고유의 요구와 우선순위에 따라 솔루션 중 적절한 부분을 사용할 수 있다.

위로

테스트 자동화의 허와 실

이 아키텍처를 설명하기 전에, 테스트 팀에서는 테스트 자동화에 대한 몇 가지 오해를 정확히 이해하는 것이 중요하다. 오늘날, 대부분의 테스트 팀에서는 테스트 자동화 필요성을 잘 알고 있고, 자연스럽게 테스트 자동화가 점점 더 확산되고 있는 중이다. 테스트 프로세스의 역동적이고 예측 불가능한 특성과 테스트 스케줄을 최소한으로 단축할 필요성을 감안하여, 품질 보증(QA) 관리자들도 테스트 자동화 필요성이 점점 커지고 있다는 사실을 실감하고 있다. 그러나 대부분의 테스트 팀에서는 다음과 같이 공통적으로 몇 가지 잘못된 믿음을 가지고 있다.

• 테스트 자동화는 순차적인 작업이다. 테스트 팀에서는 테스트 자동화를 하나씩 순차적으로 실행할 일련의 이벤트로 보고 있다. 하지만, 실제 환경에서는 많은 경우에 있어 테스트 실행이 그 특성상 종속되는 복잡하고도 서로 긴밀하게 관련되어 있는 일련의 이벤트로 구성된다. 수동 테스트에서는 이런 일련의 복잡한 이벤트를 손쉽게 발견하여 테스트 실행 방향을 결정할 수 있다. 의욕만 앞서 모든 것을 한 번에 해내려고 하지 말고, 처음에는 간단하고 쉽게 자동화를 실행할 수 있는 테스트 단계를 통한 자동화에만 집중해야 한다. 모든 테스트 단계가 아니라 그 중 일부에만 자동화를 적용한다.

• 모든 수동 테스트를 자동화할 수 있다. 모든 수동 테스트를 자동화할 수 있고 자동화된 단계로 변환해야 한다는 생각하는 것은 잘못된 생각이다. 자동화 솔루션을 개발하기 전에, 우선 각 테스트 단계를 자동화된 단계로 변환함으로써 절약할 수 있는 비용이 얼마나 되는지 추정하는 것이 중요하다. 테스트 단계를 자동화하더라도 상당한 비용 절감 효과로 이어지지 않는다면, 수동 테스트 단계를 자동으로 변환하는 것이 실용적이지 않은 일일 것이다. QA 관리자는 어떤 단계를 자동화하고 어떤 단계는 그냥 수동으로 실행할지를 두고 적절히 절충해야 한다.

• 테스트 자동화는 항상 비용 절감으로 이어진다. 대부분의 팀에서는 자동화 도구의 개발, 유지보수 및 운영 비용을 총 자동화 솔루션 비용으로 간주한다. 그러나 장부상으로는 좋게 보이는 것이 항상 진실인 것은 아니다. 비용을 평가할 때 테스트 절차의 동적이고 예측 불가능한 특성을 간과할 수도 있다. 테스트 절차의 작은 변화가 자동화 도구의 큰 변화로 이어져 더 많은 비용을 지불해야 할 때가 많이 있다. (테스트 팀 교육, 테스트 사례 문서화 및 테스트 자동화 자체에 대한 테스트와 같이) 다른 중요한 요소들은 잘 고려하지 않는다.

• 테스트 자동화는 단지 "적당한" 박스를 구매하는 문제일 뿐이다. 많은 경우, 팀에서는 자동화 요구사항을 충족시키기 위해 도구 세트를 구입하며 그것으로 끝일 것이라 생각한다. 그러나 이런 경우는 드물다. 어떤 도구를 구입한다는 것은 테스트 절차 자동화를 향한 시작 단계에 불과하다. 팀에서는 어떤 테스트를 자동화해야 하고 어떤 테스트를 수동으로 완료할지 구분하고, 테스트 절차를 문서화하고, 테스트 팀을 교육할 필요가 있다. 또한, 상용 도구가 도구를 구매하는 팀의 모든 요구사항을 충족시키는 경우도 드물다. 부족한 기능을 어떻게 해서든 보완해야 도구를 완전히 배치할 수 있다. 기대 사항과 실제로 제공되는 가치 사이의 이런 격차는 결국 불만족으로 이어지고, 많은 경우에 테스트 자동화 프로젝트의 실패로 귀결된다.

위로

일반적인 오류

위에서 설명한 자동화에 대한 허상을 잘 인식하고 있음에도, 일부 테스트 팀과 QA 관리자들은 테스트 팀의 요구사항에 맞는 자동화 도구의 디자인과 개발 작업을 진행한다. 대부분의 경우, 자원의 부적절한 이용, 개발 및 유지보수 비용의 상승 그리고 잠재적으로는 테스트 자동화 실패로 이어지는 몇 가지 기본적인 오류가 아키텍처에 도사리고 있다. 테스트 자동화 개발 팀에서 종종 저지르는 실수는 다음과 같다.

• 확장 불가능한 자동화 아키텍처: 이는 어떤 도구를 디자인하는 동안 자동화 개발 팀에서 가장 흔히 저지르는 실수 중 하나다. 대부분의 시나리오에서, 자동화 개발 팀은 한 테스트 팀의 요구사항만 충족시키는 도구를 디자인한다. 그 도구의 일부 기능을 다른 테스트 팀에서 재사용할 수 있다 할지라도, 확장 불가능한 아키텍처라면 다른 테스트 팀에서 그 도구를 채택하긴 어려운 법이다. 그런 상황이 발생하면 결국 다른 팀에서도 유사한 도구를 다시 개발해야 하는 비효율로 이어진다.

• 중복된 노력: 중복된 자동화 노력이 조직 전체적으로 테스트 자동화 솔루션의 성공을 좌절시키는 또 다른 주 요인이다. 위에서 설명한 것처럼, 대부분의 테스트 자동화 솔루션에는 재사용 불가능한 컴포넌트를 작성하는 확장 불가능한 아키텍처가 있다. 새로운 개발 프로젝트를 진행하기 전에 우선 활용할 수 있는 기존 솔루션과 제품이 있는지 찾아봐야 한다.

• 사용자 정의 도구의 급증: 수많은 테스트 자동화 도구가 처음부터 개발되고 있다. 하지만, 대부분의 경우 기존 제품이나 몇 가지 확장 기능을 갖춘 기존 제품에서 이미 직접적으로 똑같은 워크플로우가 구현되었을 수 있다. IBM은 대부분의 테스트 자동화 팀이 가지고 있는 요구사항을 충족시키기 위해 직접 사용하거나 확장할 수 있는 테스트 자동화 제품군을 보유하고 있다. 이런 접근 방식에서는 테스트 자동화에 필요한 작업 노력을 줄일 뿐 아니라, 테스트 팀들 사이에서 표준화를 증진할 수도 있다. 따라서 우선 기존 도구에 대해 조사하여 사용 환경에 적합한 아키텍처를 찾는 데 시간을 할애해야 한다.

• 팀들 간의 커뮤니케이션 및 정보 공유 부족: 테스트 팀에서 앞서 언급한 실수를 하지 않더라도, 팀들 간의 커뮤니케이션이 부족하면 확장 및 재사용 가능한 아키텍처의 효과를 보기 어렵다. 기존 자동화 도구에 대한 정보를 널리 알리고, 그런 도구에 대한 지식과 이해를 증진하여, 궁극적으로는 테스트 작업을 최소화하고 테스트 비용을 절감하는 것이 중요하다.

위로

테스트 자동화 아키텍처

이 섹션에서 설명하는 제품들은 유연하고 확장 가능한 자동화 아키텍처의 컴포넌트를 제공한다. IBM® Rational® Quality Manager는 테스트 계획, 워크플로우 제어, 테스트 추적 및 메트릭 보고를 위한 협력적이고 사용자 정의 가능한 솔루션을 제공하는 웹 기반 중앙 집중식 테스트 관리 환경이다. 이 솔루션은 아키텍처의 허브로서 다른 컴포넌트와의 중앙 통합 지점을 제공한다.

그림 1은 제안된 테스트 자동화 아키텍처와 서로 다른 제품 간 상호 작용의 전체 뷰를 나타낸 것이다.

다음으로, 본 기사에서는 다양한 테스트 자동화 기능과 그런 기능들의 요구사항을 충족시키기 위해 사용되는 IBM 제품을 소개한다.

주: 둘 이상의 제품에서 같은 기능이 구현된 이 아키텍처에서는 몇몇 중복된 기능의 예가 있다. 가장 명백한 중복 기능이 강조되며, 선택한 기능을 사용하는 이유를 설명할 것이다.

테스트 관리: Rational Quality Manager

Rational Quality Manager는 테스트 활동의 중앙 허브로서, 다음과 같은 기능을 간소화하고 자동화할 수 있도록 다른 도구에 기능 및 통합 세트를 제공한다.

• 테스트 작업 계획
• 요구사항 관리
• 테스트 사례, 테스트 스위트 및 테스트 실행 레코드 개발
• 수동 테스트 스크립트 개발
• 테스트 자산 관리
• 랩 자원 관리
• 제품 빌드 관리
• 자동 테스트 스크립트 실행 및 모니터링
• 결함 제출 및 추적

Rational Quality Manager는 RESTful(Representational State Transfer) 인터페이스 아키텍처를 사용하여 외부 제품(예: 요구사항 관리를 위한 IBM® Rational® Requirements Composer)과 간단하게 통합할 수 있는 기능과 아울러, 다음 섹션에서 설명하는 다른 제품과의 통합 기능도 제공한다.

또한, Rational Quality Manager는 다양한 목적으로 Rational Quality Manager 자원을 읽고 쓰는 사용자 정의 어댑터를 쓸 수 있도록 하는 방식으로 RESTful 인터페이스를 활용한다. 기존 테스트 자동화 프레임워크를 Rational Quality Manager 서버와 통합하면 Rational Quality Manager 배치를 한 번에 모두 끝내는 것이 아니라, 점진적이고 단계적인 프로세스로 수행할 수 있다는 것이 한 가지 예다.

Rational Quality Manager에서의 보고

Rational Quality Manager를 사용하면 IBM® Rational® Insight 제품에서 엔터프라이즈급 보고 솔루션도 사용할 수 있다. Rational Insight에서 바로 사용할 수 있도록 많은 표준 데이터 항목과 테스트 보고서가 제공된다. Rational Insight 개발 도구를 사용하면 Rational Insight Data Warehouse 컴포넌트에서 수집할 추가 데이터를 지정하고, 보고서 작성을 단순화하기 위해 특정 데이터 웨어하우스 메타데이터를 게시하고, 다양한 사용자 정의 보고서 및 대시보드를 작성할 수 있다. Rational Insight에서는 둘 이상의 Rational Quality Manager 프로젝트 영역 또는 서버의 데이터를 사용하여 보고서를 작성할 수도 있다.

Rational Team Concert로 결함 통합 설정

Rational Quality Manager와 IBM® Rational Team Concert™를 통합하여 Rational Team Concert를 결함 제공자로 사용하고 결함 및 기타 작업 항목을 Rational Quality Manager와 동기화할 수 있다. 이런 통합을 설정한 후, 작업 항목이 Rational Team Concert에서 유지보수되더라도 Rational Quality Manager에서 (결함을 포함한) 작업 항목을 추적할 수 있다.

ClearQuest 브릿지

ClearQuest 브릿지를 사용하여 Rational Quality Manager와 IBM® Rational® ClearQuest® 결함 추적 시스템을 통합할 수 있다. ClearQuest 브릿지를 사용하면 Rational Quality Manager 환경에서 직접 ClearQuest 레코드로 작업할 수 있다. 그래서 ClearQuest 레코드를 작성하고 보고 수정하고, ClearQuest 쿼리를 실행하고, ClearQuest 레코드를 Rational Quality Manager 실행 결과와 연관할 수 있다. ClearQuest 브릿지에서는 여러 저장소에 있는 데이터의 동기화 규칙 또는 중복을 작성하고 유지보수할 필요가 없고, 이 브릿지가 ClearQuest 데이터에 직접 링크한다.

테스트 자원 프로비저닝: Tivoli Provisioning Manager

IBM Tivoli Provisioning Manager는 데이터 센터 프로비저닝 활동을 자동화하기 위한 IBM의 엔터프라이즈급 컴포넌트로서, 다음을 포함한 다양한 기능을 제공한다.

• IT 자원 검색
• 운영 체제, 소프트웨어 패키지, 스토리지 및 네트워크 자원 프로비저닝
• 테스트 랩에 있는 모든 IT 자원을 표현할 수 있는 세부적인 데이터 센터 모델
• 자동화 패키지를 작성하거나 사용자 정의하기 위한 강력한 자동화 패키지 개발 환경
• 원격 컴퓨터에서 자동화 패키지를 실행하고 모니터링하기 위한 자동화 엔진
• 현재 상태 그대로 사용하거나 사용자 정의 워크플로우에 대한 예제로 사용할 수 있는 자동화 패키지 라이브러리
• 소프트웨어 준수 관리 및 라이센스 관리

Tivoli Provisioning Manager는 다른 소프트웨어 컴포넌트와의 통합을 용이하게 하는 SOAP(Simple Open Access Protocol) 인터페이스를 제공한다. 외부 컴포넌트는 이 인터페이스를 사용하여 작업(예: 검색 또는 프로비저닝 워크플로우의 실행)을 요청하거나 데이터 센터 모델에서 정보를 검색할 수 있다.

테스트 자동화 아키텍처 내에서, Rational Quality Manager는 통합 인터페이스를 통해 프로비저닝 태스크를 Tivoli Provisioning Manager에 위임한다. 이런 통합 덕분에, Rational Quality Manager의 Lab Management 서브시스템에서 Tivoli Provisioning Manager 자원 및 자동화 패키지를 볼 수 있다. 테스트 엔지니어는 하나 이상의 랩 자원에서 자동화 프로젝트의 실행을 요청할 수 있다. Rational Quality Manager 인터페이스는 단순히 Tivoli Provisioning Manager가 자동화 프로젝트를 실행하도록 요청한 다음, 결과를 얻을 수 없게 될 때 자동화 프로젝트의 결과를 표시한다.

상상할 수 있는 모든 자동화 태스크에 대해 Tivoli Provisioning Manager의 다양한 기능 콜렉션을 사용할 수 있으므로 복잡도가 증가할 수 있다. 그래서 IBM에서는 Tivoli Provisioning Manager가 독보적으로 뛰어난 능력을 보이는 기능에 집중하는 전략을 세웠고, 이는 곧 테스트 랩 인프라에서 복잡한 태스크를 관리하는 것이다. 예를 들어, Tivoli Provisioning Manager를 사용하여 모든 필수 플랫폼에서의 운영 체제 프로비저닝을 관리한다. 간단한 자동화 태스크는 범용 워크플로우 엔진인 IBM® Rational® Build Forge®로 손쉽게 처리할 수 있다.

둘 이상의 프로덕션 Tivoli Provisioning Manager 서버를 두는 것이 적당한 특수한 상황이 있을 수 있지만, 각 사이트에는 일반적으로 Tivoli Provisioning Manager의 프로덕션 인스턴스가 하나만 있을 것이다.

범용 자동화 엔진: Rational Build Forge

Rational Build Forge는 이 아키텍처의 워크플로우 엔진이다. 이 엔진은 실행할 단계를 포함한 프로젝트를 지정할 수 있게 해주는 간단한 제품이다. 단계는 테스트 인프라에서 선택한 서버에서 실행될 하나 이상의 명령일 수 있다. Rational Build Forge 자동화 프로젝트는 더 큰 프로젝트에 임베드될 수 있는 방식으로 작성될 수 있다. 이 프로젝트는 철저한 테스트를 거친 하위 레벨 빌딩 블록 프로젝트의 콜렉션을 사용하여 매우 복잡한 테스트 자동화 프로세스를 배치하기 위한 간단한 메커니즘을 제공한다.

Rational Build Forge는 프로젝트 단계 실패 시 오류 검색 및 복구를 위한 내장 메커니즘을 제공한다. 실패 후 다른 프로젝트를 실행하도록 지정할 수 있다. 그 프로젝트에서 실패한 경우 이를 정리한 후 자동화 프로세스를 계속할 수 있다. 실행 시간에 값을 바인드하기 위해 자동화 논리를 사용하는 환경 개념도 있다.

Java™ 및 Perl 바인딩을 포함한 Rational Build Forge API는 사용자 인터페이스(UI)에서 사용 가능한 기능 중 대부분을 노출한다. 이 API를 사용하면 외부 스펙에서 테스트 프로젝트를 동적으로 생성하는 것과 같은 확장 기능을 작성할 수 있다. 예를 들어, 특정 코드 릴리스와 관련된 회귀 테스트만으로 구성된 회귀 테스트 프로젝트를 작성할 수 있다. 이를 통해 문제가 될 만한 요소를 더 확실히 분리할 수 있으므로 실행할 테스트를 결정할 책임이 Rational Build Forge 외부에 놓이게 되어, Rational Build Forge는 테스트 환경 준비와 그런 환경에서의 테스트 실행만 책임지면 된다.

테스트 자동화 아키텍처 내부에서, Rational Quality Manager는 통합 인터페이스를 통해 자동화 태스크를 Rational Build Forge에 위임한다. 이런 통합 덕분에, Rational Quality Manager의 Lab Management 서브시스템에서 Rational Build Forge 서버 및 프로젝트를 볼 수 있다. 하나 이상의 랩 자원에서 자동화 프로젝트 실행을 선택할 수 있다. 게다가 설치 단계, 자동 테스트 스위트 실행 단계 및 해체 단계를 포함하는 복잡한 테스트 시나리오를 Rational Quality Manager에서 생성할 수 있다. Rational Build Forge 내에서는 테스트 스탠드 설치 및 해체가 자동 프로젝트로 이루어질 수 있다. Rational Quality Manager 인터페이스는 단순히 Rational Build Forge가 자동화 프로젝트를 실행하도록 요청한 다음, 그 결과를 기다린 후 다음 단계로 계속 진행한다.

Rational Build Forge의 여러 프로덕션 인스턴스가 있을 수 있고, 제품 테스트 영역당 하나씩 있을 것으로 예상된다.

UI 자동화 도구: Rational Functional Tester

팀에서 IBM® Rational® Functional Tester를 사용하여 UI 자동화 테스트를 수행할 수 있다. Rational Functional Tester로 테스트할 수 있는 UI 애플리케이션의 유형으로는 다음과 같은 것들이 있다.

• 웹 기반 애플리케이션
• Microsoft® .Net 애플리케이션
• Java 애플리케이션(예: SWT(Eclipse) 또는 Swing)
• 3270(IBM® zSeries®) 및 5250(IBM® iSeries®)용 애플리케이션
• Siebel 애플리케이션
• SAP 애플리케이션
• 플래시 애플리케이션

많이 사용하는 Rational Functional Tester 기능 몇 가지를 소개한다.

• 라이프사이클 추적성:Rational Functional Tester에는 협력적인 애플리케이션 라이프사이클 관리를 지원하기 위한 IBM® Jazz™ 통합 기능이 있다. Jazz Eclipse Client 버전 2.0 통합 기능을 통해 Rational Functional Tester는 Rational Team Concert와 Rational Quality Manager 내부의 작업 항목에 액세스할 수 있다. 또한, Rational Team Concert와의 향상된 SCM(Software Configuration Manager) 통합 기능은 테스트 자산의 관리와 공유를 지원한다.
• GUI 테스트 자동화 간소화를 위한 키워드 테스트:Rational Functional Tester에는 기능 및 수동 테스트에서 모두 재사용할 수 있는 키워드를 정의하고 자동화하는 기능이 있다. 이 기능을 통해 스크립트 재사용을 촉진하고 수동 테스트 작업자는 수동 테스트 주기 내에서 자동화의 이점을 손쉽게 선택적으로 활용할 수 있다.
• Java 또는 Visual Basic .NET 중에서 테스트 편집 언어 선택:가장 기본적인 테스트를 제외하고는, 어떤 것이든 수행하려면 테스트 스크립트 사용자 정의가 필수적이다. Rational Functional Tester를 사용할 때는 강력한 주요 스크립트 언어를 선택할 수 있으므로 이것이 가능하다. 두 옵션 모두 지원되는 모든 사용자 인터페이스 기술과 함께 사용할 수 있다.
• Microsoft® Internet Explorer, Firefox 및 Adobe® PDF 지원:Internet Explorer V8.0, Firefox V3.0 및 Adobe PDF V7.0과 V8.0에서 HTML 애플리케이션을 위한 기능 테스트가 지원된다. 또한, Internet Explorer의 여러 탭에 로드되는 HTML 페이지를 테스트할 수도 있다.

Rational Functional Tester를 사용할 때는 Rational Functional Tester의 레코드 재생 기능이 자동화 테스트에 적합한지 결정해야 한다. 테스트 대상 애플리케이션(AUT)이 단기 프로젝트(단일 릴리스)이거나 GUI 변경이 릴리스 간에 제한되는 경우에는 레코드 재생을 사용하는 것이 적절할 수 있다. 그렇지 않으면, 프로그래밍을 통해 GUI 자동화 테스트를 구현해야 하며 스크립팅 보조 도구로서 레코드 재생 기능만 사용해야 한다.

AUT에서 "무엇을" 테스트해야 할 것인가 하는 점에서 테스트 스크립트를 작성하고 별개의 클래스 메소드의 UI 내에서 이를 "어떻게" 달성할지 그 방법을 캡슐화해야 한다. 즉, 작성할 테스트 스크립트는 AUT에서 주어진 태스크 또는 함수를 구현하기 위해 각각의 메소드를 사용하는 메소드 호출 세트로 이루어져야 한다. 이렇듯 UI에서 작업을 격리하는 것이 릴리스 간 유지보수 비용을 줄이기 위한 관건이다.

랩 자원 관리: Tivoli Application Dependency Manager 및 Tivoli Change and Configuration Management Database

IBM® Tivoli® Application Dependency Discovery Manager(TADDM)를 사용하여 IT 자원과 그 자원들 간의 종속 항목을 검색할 수 있다. TADDM 에이전트 없는 검색 기술을 사용하여 애플리케이션, 미들웨어 및 데이터베이스뿐 아니라, 데이터 센터의 라우터, 스위치 및 방화벽과 같은 네트워크 컴포넌트, 호스트 및 스토리지를 식별한다. TADDM은 각 컴포넌트의 구성 방식뿐 아니라 그들 간의 관계도 검색하고, 시간의 경과에 따라 어떻게 바뀌는지 식별할 수 있다. 또한, TADDM은 IBM에서 정의한 자원이나 IBM TotalStorage® Productivity Center와 같은 다른 Storage Resource Manager 제품을 검색할 수 있다.

TADDM에는 다른 소프트웨어 컴포넌트와의 통합을 지원하는 Java API가 있다. 외부 컴포넌트는 이 API를 사용하여 검색을 요청하고 검색된 자원에 대한 정보를 불러올 수 있다.

테스트 자동화 아키텍처 내에서, Rational Quality Manager는 TADDM과 통합하여 Lab Management 서브시스템에 자원을 채울 수 있는 다양한 방법을 제공한다. TADDM을 사용하여 검색한 컴퓨터 자원과 아울러, Tivoli Provisioning Manager 및 Rational Build Forge의 컴퓨터 자원으로 Rational Quality Manager Lab Manager를 채울 수 있다. 그 밖에도, TADDM은 테스트에 사용 가능한 모든 자원의 세부적인 인벤토리를 자동으로 유지보수하고 고가의 랩 자원을 간단히 공유할 수 있다.

각 사이트에는 일반적으로 TADDM의 프로덕션 인스턴스가 하나씩만 있다. TADDM의 이런 사이트 인스턴스는 조직 전체의 CCMDB 인스턴스로 피드하여 랩 자원을 전사적으로 볼 수 있게 할 수 있다.

위로

IBM 테스트 자동화 전략의 이점

테스트 자동화 팀에서는 이 기사에서 설명한 아키텍처를 활용하여 테스트 비용을 줄이고 테스트 레벨 및 품질을 개선하고 새로운 테스트 자동화 기능을 배치하는 데 필요한 노력을 줄일 수 있다. 이 아키텍처를 사용함으로써 얻을 수 있는 생산성 향상 효과를 통해 조직 전체적으로 더욱 자주, 더욱 완벽하게 테스트를 수행할 수 있다. 일반적인 오류 섹션에서 언급한 문제점을 없애는 것 외에도, IBM의 테스트 자동화 전략은 테스트 팀에 다음과 같은 이점이 있다.

• 시간 요소:많은 테스트 자동화 도구가 사용자 정의 방식으로 개발되고 있어 개발 및 유지보수 비용의 증가로 이어진다. 기존 제품을 새로운 테스트 자동화를 위한 기초로 삼으면 개발이 아닌 통합으로 초점을 바꿀 수 있다. 따라서 테스트 자동화 팀에서 불필요한 일을 하느라 시간과 노력을 낭비하지 않아도 된다. 이는 곧 개발 반복 시간 단축으로 이어질 것이다. 제품을 사용할 준비가 되기 전까지의 시간이 줄어들 것이며, 결국 제품을 더 빨리 출시할 수 있다.

• 높은 스킬 가용성:공통 테스트 자동화 컴포넌트와 표준 제품을 사용한다는 것은 숙련된 테스트 자동화 개발자를 더욱 가치 있는 일에 활용할 수 있음을 의미한다. 테스트 자동화 개발 팀에서는 표준 제품과 그 사용 방법에 대해 더 깊이 이해하고 인식하게 될 것이다. 한편, 테스트 팀은 테스트 개발에 더욱 집중하여 제품 테스트를 위한 보다 심층적이고 포괄적인 테스트 스크립트를 개발할 수 있다. 수동 테스트 작업자는 반복적이고 평범한 태스크를 실행하지 않아도 되므로, 테스트 자동화를 통해 그들이 각자 지닌 창의성, 지식 및 본능을 이용해 더 효과적으로 테스트하는 데 집중할 수 있다.

• 생산성:많은 테스트 팀들이 테스트 자체가 아니라 자동화 도구 개발에 대부분의 시간을 쓰고 있다. 기존 제품을 재사용하고 전담 테스트 자동화 개발 팀을 조직하면 테스트 작업자가 테스트에 집중할 수 있다. 그들은 테스트 자동화 컴포넌트의 개발과 유지보수를 걱정할 필요가 없다. 이 점 역시, 더욱 철저한 테스트를 거쳐 안정적인 제품을 생산하는 데 기여한다.

• 적은 비용:개발 대신 통합을 하게 되면 개발 주기가 짧아질 것이다. 서로 다른 테스트 팀들이 동일한 제품 및 자동화 컴포넌트 세트를 사용함으로써 개발 비용을 더욱 줄일 수 있다.

• 표준화:테스트 팀에서 직면하는 한 가지 주요 문제점은 통합 및 공유 불가능한 테스트 자동화 컴포넌트이다. 테스트 자동화 프로젝트에서 사용되는 표준이 없다는 점이 이 문제점의 주 원인이다. 기존 제품을 사용하고 재사용 가능한 컴포넌트라는 관점에서 테스트 자동화에 대해 생각하면 더욱 손쉽게 통합 및 재사용 가능한 테스트 자동화 도구를 구현할 수 있다.

위로

학습 내용

본 기사에서는 테스트 자동화를 위한 아키텍처를 제시했다. 이 아키텍처를 사용하여 기존 자동화 제품의 기능을 직접 사용하거나 활용하는 자동화 도구를 디자인하고 개발해 볼 것을 권장한다. 확장 가능하고 다른 테스트 팀에서 재사용할 수 있으며, 궁극적으로는 표준화를 증진하는 도구를 디자인할 수 있다. 이런 식으로 테스트 자동화의 파워를 보다 완벽히 실현할 수 있다.

참고자료

교육

• Rational Quality Manager에 관한 자세한 정보를 찾을 수 있는 방법:
  
  • Rational Quality Manager developerWorks 페이지에서 기술 관련 기사와 다양한 관련 참고자료에 대한 링크를 살펴보자. developerWorks Rational 소프트웨어 페이지 또한 좋은 출발점이다.
  • Rational Quality Manager Information Center를 살펴보자.
  
  
• IBM Rational Software Delivery Platform에서 병렬 개발 및 지역적으로 분산된 팀을 위한 협업 도구와 아키텍처 관리, 자산 관리, 변경 및 릴리스 관리, 통합 요구사항 관리, 프로세스 및 포트폴리오 관리, 품질 관리를 위한 특수 소프트웨어를 포함한 기타 애플리케이션에 대해 살펴보자. 제품 매뉴얼, 설치 안내서 및 기타 문서는 IBM Rational Online Documentation Center에서 확인할 수 있다.
  
  
• developerWorks의 Rational 소프트웨어 영역에서 Rational Software Delivery Platform 제품과 관련된 기술 자료와 우수 사례를 볼 수 있다.
  
  
• 강사가 지도하는 컴퓨터와 웹을 기반으로 하는 Rational 온라인 강의를 살펴보자. 초급에서 고급까지의 다양한 강의를 통해 Rational 도구에 대한 지식을 쌓고 기술을 연마하자. 이 카탈로그의 강의는 컴퓨터 기반 교육 또는 웹 기반 교육을 통해 구입할 수 있다. 일부 "시작하기" 강의의 경우 무료로 제공된다.
  
  
• 1주일 동안의 developerWorks 튜토리얼, 기사, 다운로드, 커뮤니티 활동, 웹 캐스트, 이벤트 등에 대한 소식을 전하는 developerWorks 뉴스레터를 구독하자.
  
  
• Jazz.net: Rational Quality Manager and Rational Team Concert와 같은 실습용 제품을 구할 수 있다.
  
  
• Jazz.net: Rational Quality Manager API 를 이용한 작업
  
  

제품 및 기술 얻기

• IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 테스트 자동화의 허와 실
• 일반적인 오류
• 테스트 자동화 아키텍처
• IBM 테스트 자동화 전략의 이점
• 학습 내용
• 참고자료
• 필자소개
• 의견