Keyword
capture/playback, data-driven testing, generic test automation architecture, keyword-driven testing, linear scripting, model-based testing, process-driven scripting, structured scripting, test adaptation layer, test automation architecture, test automation framework, test automation solution, test definition layer, test execution layer, test generation layer

3.1 Introduction to gTAA

테스트 자동화 엔지니어는 테스트 자동화 솔루션(TAS)에 대해 설계하고, 개발 및 구현, 유지보수를 해야하는 역할을 가지고 있다. 여러 솔루션들이 개발될 유사한 작업들이 필요하고, 유사한 질문이 제기되고, 유사한 이슈들에 대해 직면하고 우선순위를 매기게 된다. 이렇게 반복되는 어떠한 개념, 절차 및 접근 방식들은 테스트 자동화 아키텍처의 기초가 되며, 이것을 gTAA, generic Test Automation Architecture 라고 한다.

gTAA는 gTAA의 인터페이스, 구조, 계층등을 나타내며, 이것은 특정 TAS를 위한 TAA로 재정의된다. 이것은 아래 내용들에 의해 구조적이고 모듈화된 방식으로 정의된다.

• TAS의 인터페이스, 서비스, 레이어, 개념 공간? 등을 정의하고 사내 및 외부에서 개발된 구성요소로 TAS를 구현할 수 있게 한다.
• 효과적이고 효율적인 테스트 자동화의 개발을 위한 간소화된 컴포넌트를 지원한다.
• 다른 혹은 더 좋은 TAS를 위해 소프트웨어 제품들과 소프트웨어 기술 및 도구 전반에 걸쳐 테스트 자동화 컴포넌트를 재사용한다.
• TAS의 유지 보수 및 발전을 쉽게 할 수 있게 한다.
• TAS를 사용하는 유저에게 필수 기능을 정의한다.

TAS는 테스트 스위트와 테스트 환경과 관련된 것들로 구성된다. Test Automation Framework(TAF)는 TAS를 실현하는 데에 사용될 수 있으며 이것은 테스트 환경의 구현을 지원하고 어떠한 도구, 테스트 하네스(테스트를 실행하는 데 필요한 스텁 및 드라이버) 또는 지원 라이브러리를 제공한다.

TAS의 TAA는 TAS의 쉬운 개발 및 기능 추가, 유지보수를 지원하기 위해 아래의 원칙들을 준수해야한다.

• 단일 책임 원칙 Single responsibility
  • 모든 TAS 컴포넌트는 단일 책임 원칙을 준수해야하며 그 책임은 해당 컴포넌트 내에서 완전히 캡슐화되어야한다. 다시 말 모든 TAS의 컴포넌트는 정확히 하나에 대해서만 책임을 가져야한다. 예를 들어 키워드나 데이터 생성, 테스트 시나리오 생성, 테스트 케이스 실행, 결과 로깅, 리포트 생성 등등에 대에 각각의 책임을 가지는 컴포넌트가 있어야 한다.
• 확장 가능성 Extension
  • 모든 TAS 구성요소는 확장할 수 있어야하나, 수정을 하기위해 닫혀있어야한다. 이것은 컴포넌트의 기능을 수정하거나 깨뜨리지 않고도 새로운 기능을 추가하거나 할 수 있어야 한다는 뜻이다.
• 대체 가능성 Replacement
  • 모든 TAS 컴포넌트는 전체 TAS 동작에 영향을 주지 않으면서도 대체가 가능해야한다. 구성요소는 하나 혹은 그 이상의 대체 요소로 교체될 수 있지만 전체 동작은 동일해야 한다.
• 구성 요소 분리 원칙 Component segregation
  • 일반적인 여러 목적을 가진 컴포넌트 보다 특정 목적을 가진 컴포넌트가 더 좋다. 이렇게 한다면 불필요한 종속성을 제거할 수 있어 컴포넌트의 대체 및 유지보수가 훨씬 쉬워진다.
• 의존성 역전 원칙 Dependency inversion
  • TAS 구성요소는 저수준의 세부사항보다는 높은 수준의 추상화에 의존해야 한다. 다시 말해, 컴포넌트는 어떠한 특정한 자동화된 테스트 시나리오에 의존해선 안된다.

일반적으로, gTAA를 기반으로한 TAS는 어떠한 도구, 플러그인 또는 구성요소의 집합으로 구성된다. gTAA는 특정 벤더사에 의존적이지 않다는 것이 중요하다. TAS의 실현을 위해서 어떠한 구체적인 방법이나 기술, 또는 도구를 사전에 정의하지 않는다. gTAA는 구조적, 객체지향적, 서비스 지향적, 모델-드리븐 방식 등 어떠한 소프트웨어 공학적 접근방식으로 구현될 수 있다. 사실 TAS는 상용 도구를 이용하여 구현되지만 일반적으로는 추가적으로 SUT의 특정 기능 추가라던지 적용이 필요하다.

TAS와 관련된 다른 지침과 레퍼런스들에서는 현재 수행중인 SDLC와 프로그래밍 기술, 형식 표준 등의 여러 소프트웨어 공학 표준이 포함된다. 본 커리큘럼에서는 소프트웨어 공학을 가르치는 것이 범위에 들어있지는 않지만, 테스트 자동화 엔지니어는 소프트웨어 공학에 대한 기술, 경험, 전문성을 갖추어야한다.

더불어서, 테스트 자동화 엔지니어는 TAS를 개발할 때 사용해야할 업계의 코딩, 문서화 표준 및 구현 모범 사례 등을 알고 있어야 한다. 이러한 관행은 TAS의 유지보수성, 신뢰성, 보안을 향상시킬 수 있다. 이 표준들은 도메인별로 다르며, 대표적인 표준은 아래와 같다.

• MISRA : C / C++
• JSF : C++
• AUTOSAR rule : Mathworks matlab

3.1.1 Overview of the gTAA

gTAA는 아래의 수평 레이어로 구성된다.

• 테스트 생성
• 테스트 정의
• 테스트 실행
• 테스트 적응

gTAA는 아래를 포함한다.

• Test generation layer
  • 수동 혹은 자동으로 테스트케이스를 설계할 수 있도록 한다. 테스트 케이스 설계를 위한 수단을 제공한다.
• Test definition layer
  • 테스트 스위트 및 테스트 케이스를 정의하고 구현할 수 있도록 한다. 테스트의 정의를 SUT 혹은 테스트 시스템과 기술, 도구로 부터 분리한다. 테스트 데이터, 테스트 케이스, 테스트 스텝 및 테스트 라이브러리 혹은 이것들의 조합을 통해 고수준 혹은 저수준의 테스트를 정의할 수 있는 수단을 포함한다.
• Test execution layer
  • 테스트 케이스 실행과 테스트 로깅을 지원한다. 선택한 테스트를 자동으로 실행할 수 있는 실행도구와 로깅 및 리포트 관련 컴포넌트를 제공한다.
• Test adaptation layer
  • SUT의 다양한 컴포넌트나 인터페이스에 대해, 자동 테스트를 적용할 수 있는 코드를 제공한다. API, 프로토콜, 서비스 등을 통해 SUT에 연결하기 위한 다양한 어댑터를 제공한다.
• 프로젝트, 구성, 테스트 관리 방법
  • 테스트 관리와 테스트 적용 레이어 간의 인터페이스는, 선택한 테스트 구성에 따라 적절한 어댑터의 선택 및 구성을 처리할 수 있어야한다.

gTAA 레이어와 그 컴포넌트들간의 인터페이스는 매우 구체적인 내용이라 실라버스에서는 제외한다.

모든 TAS에 이러한 계층이 항상 존재하는 것은 아니다. 예를 들어

• 테스트 실행이 자동화될 경우, 테스트 실행 레이어와 테스트 적용 레이어를 사용해야한다. 이것들은 분리될 필요가 없다. 유닛 테스트 프레임워크 처럼 같이 사용할 수 있다.
• 테스트 정의가 자동화될 경우, test definition layer가 필요하다.
• 테스트 생성이 자동화될 경우, test generation layer가 필요하다.

대부분 일반적으로, TAS의 구현은 bottom-up의 형태로 시작되나, 매뉴얼 테스트를 위한 자동 테스트 생성등을 포함한 다른 방법도 효과적일 수 있다. 일반적으로 TAS의 구현은 가능한 빠르게 TAS를 사용하고, TAS의 부가 가치를 증명하기 위해 단계적으로 수행해나가는 것이 필요하다. 또한 이러한 개념 증명을 테스트 자동화 프로젝트의 일환으로 권장한다.

모든 테스트 자동화 프로젝트는 소프트웨어 개발 프로젝트로 이해되고 설정되며 관리되어야하며 전담 관리인력이 필요하다. TAF 개발 프로젝트 관리 (회사 전체 제품군 혹은 제품군을 위한 테스트 자동화 지원) 는 TAS를 위한 프로젝트 관리 (구체적인 제품을 위한 테스트 자동화) 와 분리될 수 있다.

3.1.2 Test Generation Layer

테스트 생성 레이어는 아래와 같은 도구/기능들을 지원해야한다.

• 수동으로 테스트 케이스 설계
• 테스트 데이터를 개발, 캡쳐, 추출
• SUT 혹은 해당 환경을 정의하는 모델에서 테스트 케이스 생성 (자동화된 모델 기반 테스트)

이 계층의 컴포넌트는 다음을 수행하는 데에 사용된다.

• 테스트 스위트 구조를 수정하고 확인한다.
• 테스트 케이스를 테스트 목표 또는 SUT의 요구사항과 연관짓기
• 테스트 설계 문서화

자동화된 테스트 생성을 위해 아래 내용들이 포함될 수 있다.

• SUT, 실행 환경 또는 테스트 시스템을 모델링하는 능력
• 테스트 스텝을 정의하고 테스트 생성 알고리즘을 구성하고 매개변수화할 수 있는 능력
• 생성된 테스트를 모델로 추적하는 능력

3.1.3 Test Definition Layer

테스트 정의 레이어는 아래와 같은 기능/도구들을 지원해야한다.

• 고수준 또는 저수준의 테스트 케이스 특정
• 저수준 테스트 케이스를 위한 테스트 데이터 정의
• 테스트 케이스 혹은 테스트 케이스 집합을 위한 테스트 절차/스텝 특정
• 테스트 케이스 실행을 위한 테스트 스크립트 정의
• 필요에 따라서는 테스트 라이브러리에 대한 접근 제공

이 레이어의 컴포넌트들은 다음을 수행한다.

• 테스트 데이터 분할 및 제한, 매개변수화 또는 인스턴스화
• 어떠한 테스트 절차 혹은 테스트 흐름을 지정하고 이것에 대해 매개변수화 혹은 그룹핑
• 테스트 데이터, 테스트 케이스 및 테스트 스텝의 문서화

3.1.4 Test Execution Layer

테스트 실행 레이어는 다음과 같은 도구들을 지원해야한다.

• 테스트 케이스의 자동 실행
• 테스트 케이스 실행 로깅
• 테스트 결과의 리포팅

테스트 실행 레이어는 아래와 같은 컴포넌트들로 구성될 수 있다.

• 테스트 실행을 위한 SUT의 셋업 및 종료처리
• 테스트 스위트의 셋업 및 종료처리
• 테스트 자체의 설정 구성 및 매개변수화
• 테스트 데이터와 테스트 케이스를 해석하고 실행가능한 스크립트로 변환
• 테스트 실행 로깅과 오류 확인을 위한 테스트 시스템 / SUT 계측
• 후속 테스트 실행을 유도하기 위한 SUT 응답 분석
• 자동화된 테스트 케이스 실행결과를 위한 SUT 응답 검증
• 시간 내 자동 테스트 실행 제어

3.1.5 Test Adaptation Layer

테스트 적용 레이어는 다음과 같은 도구들을 지원해야한다.

• 테스트 도구 제어
• SUT와의 상호작용
• SUT의 모니터링
• SUT 환경의 시뮬레이션/에뮬레이션

테스트 적용 레이어는 아래의 기능을 제공한다.

• 기술 중립적인 테스트의 정의와 SUT 및 테스트 장치의 특정 기술 요구사항 간의 조정
• SUT와 상호작용을 하기 위한 다양한 기술 특화 기능들의 적용
• 여러 테스트 장치 / 인터페이스나 로컬에서의 테스트 실행 및 실행 분배

3.1.6 TAS의 구성 관리

일반적으로, TAS는 다양한 반복/버전으로 개발되며 SUT의 반복/버전과 호환되어야한다. TAS의 구성관리로는 아래와 같은 것들이 포함되어야할 수 있다.

• 테스트 모델
• 테스트 데이터, 테스트 케이스와 라이브러리를 포함하는 테스트 정의/요구사항
• 테스트 스크립트
• 테스트 실행 엔진 및 보조 도구와 컴포넌트
• SUT를 위한 테스트 어댑터
• SUT 환경을 위한 시뮬레이터 혹은 에뮬레이터
• 테스트 결과와 테스트 리포트

이러한 항목들은 테스트 웨어를 구성하며, SUT의 버전과 일치하는 버전이어야 한다. 일부 상황에서는 TAS의 버전을 이전 버전으로 되돌려야할 필요가 있을 수 있다. 예를 들어 어떠한 문제에 대해 이전 SUT버전에서 재현시켜야할 필요가 있을 때다. 좋은 구성 관리는 이러한 기능을 가능하게 한다.

3.1.7 Project Management of a TAS

테스트 자동화 프로젝트는 소프트웨어 프로젝트이므로, 어떠한 다른 소프트웨어 프로젝트와 마찬가지로 프로젝트 관리가 필요하다. TAE는 TAS를 개발할 때 SDLC의 모든 단계에 대한 작업을 수행해야한다. TAS의 개발 환경은 메트릭과 같은 상태 정보를 쉽게 추출하거나 자동으로 TAS 프로젝트 관리에 보고할 수 있도록 설계되어야 한다.

3.1.8 TAS Support for Test Management

TAS는 SUT에 대한 테스트 관리를 지원해야한다. 테스트 리포트에는 테스트 로그와 테스트 결과가 포함되어야하고 SUT의 테스트 관리자를 위해 손쉽게 추출할 수 있거나 자동으로 제공되어야 한다.

---

3.2 TAA Design

3.2.1 Introduction to TAA Design

테스트 자동화 아키텍처를 설계하기 위해 필요한 몇가지 활동들이 있으며, 그것들은 테스트 자동화 프로젝트나 조직에 따라 정리될 수 있다. 그러한 활동들은 아래 섹션에서 확인할 수 있다. TAA의 복잡성에 따라 더 많거나 더 적은 활동이 필요할 수 있다.

적절한 Test Automation Architecture, TAA의 정의를 위해 필요한 요구사항 확인

테스트 자동화를 위한 요구사항은 아래와 같은 내용을 고려해야한다.

• 어떤 활동이나 테스트 프로세스 단계에서 자동화되어야하는지.
  • 예를 들어 테스트 관리, 테스트 설계, 테스트 생성 혹은 테스트 실행.
  • 테스트 자동화는 테스트 설계와 테스트 구현 사이에 테스트 생성을 삽입하여 기본 테스트 프로세스를 세분화한다.
• 어떤 테스트 레벨이 지원되어야하는지.
  • 컴포넌트 레벨, 통합 레벨, 시스템 레벨 등
• 어떤 종류의 테스트가 지원되어야 하는지.
  • 기능 테스트, 편의성 테스트, 상호운용성 테스트 등
• 어떤 테스트 역할이 지원되어야 하는지.
  • 테스트 실행자, 테스트 분석가, 테스트 설계자, 테스트 매니저 등
• 어떤 소프트웨어 제품, 제품 라인, 제품군이 지원되어야 하는지
  • 구현된 TAS의 범위와 수명을 정의하기 위해.
• 어떤 SUT 기술이 지원되어야 하는지
  • SUT 기술과 호환성을 고려한 TAS 정의를 위해.

다양한 설계 및 아키텍처 접근방식 비교 및 대조

TAE는 TAA의 레이어를 설계할 때 다양한 접근 방식의 장단점을 분석해야한다. 여기에는 아래와 같은 요소들이 포함될 것이다.

• 테스트 생성 레이어에 대한 고려사항:
  • 수동 혹은 자동 테스트의 선택
  • 요구사항 기반, 데이터 기반, 시나리오 기반, 행동 기반 테스트 등 테스트 생성의 선택
  • 테스트 생성 전략 선택 (데이터 기반 접근법을 위한 분류 트리와 같은 모델 커버리지, 시나리오 기반 접근법을 위한 유스케이스/예외 사례 커버리지, 행동 기반 접근법을 위한 전이/상태/경로 커버리지)
  • 테스트 선택 전략의 선택. 일례로 전체 조합 테스트 작성은 테스트케이스가 폭발적으로 생성될 수 있으므로 실행이 불가능하다. 그러므로 실용적인 커버리지 기준, 가중치, 리스크 평가 등을 사용하여 테스트 생성과 테스트 선택을 가이드해야한다.
• 테스트 정의 레이어에 대한 고려사항:
  • 데이터 중심, 키워드 중심, 패턴 기반, 혹은 모델 기반의 테스트 정의의 선택
  • 테스트 정의를 위한 표기법 선택 (표, 상태 기반 표기법, 확률 표기법, 데이터흐름 표기법, 비즈니스 프로세스 표기법, 시나리오 기반 표기법, 스프레드시트 사용, 도메인 특화 언어, 테스트 및 테스트 제어 표기법, UML 테스트 프로필 등)
  • 고품질 테스트 정의를 위한 스타일 가이드 선정
  • 테스트 케이스 저장소 선정 (스프레드시트, 데이터베이스, 파일 등등)
• 테스트 생성 레이어에 대한 고려사항
  • 테스트 실행 도구 선택
  • 테스트 절차를 구현하기 위한 해석 또는 컴파일 접근법의 선택 (보통 테스트 실행 도구에 따라 다르다)
  • 테스트 절차를 구현하기 위한 구현 기술의 선정 (특정 프로그래밍 언어 또는 도구 특화 기술)
  • 테스트 실행을 용이하게 해주는 헬퍼 라이브러리의 선택
• 테스트 적용 레이어에 대한 고려사항
  • SUT에 대한 테스트 인터페이스 선택
  • 테스트 인터페이스를 조작하고 관찰하는 도구 선택
  • 테스트 실행 중 SUT를 모니터링하는 도구 선택
  • 테스트 실행을 추적하는 도구 선택

추상화를 하면 좋다라는 것을 전달할 수 있는 영역의 식별

TAA에서 추상화 라는 것은, 동일한 테스트 스위트를 다양한 테스트 환경과 다양한 목표 기술들에 사용할 수 있게 기술적 독립성을 제공하는 의미를 갖는다. 테스트 아티팩트(SUT를 테스트하면서 작성한 문서나 스크립트와 같은 산출물) 의 이식성이 향상된다. 게다가 TAS의 특정 공급 업체에 대한 종속효과를 방지하여 공급 업체에 대한 중립성이 보장된다. 추상화는 신규 혹은 진보된 SUT 기술에 대한 유지보수성과 적용성을 향상시켜준다. 게다가 추상화는 TAA (혹은 TAS의 구체화)를 테크니션이 아닌 사람들에게 좀 더 접근하기 쉽게하여 테스트 스위트를 그래픽적인 요소를 포함하여 좀 더 고수준의 문서화를 가능하게 하는데, 이것은 가독성과 이해도를 향상시켜준다.

TAE는 소프트웨어 개발, 품질 보증 및 테스트의 이해관계자들과 함께 TAS의 어느 영역에서 어느 수준의 추상화를 사용해야할지 논의해야한다. 예를 들어, 테스트 적용 또는 테스트 실행 레이어의 어떠한 인터페이스를 외부로 노출시키고 공식적으로 정의할지, 그리고 TAA의 수명 동안 안정적으로 유지를 해야하는지 등을 논의해야한다. 또한 추상적인 테스트 정의를 사용할지, 테스트 스크립트만 사용하는 테스트 실행 레이어를 사용할지도 논의되어야 한다. 게다가 테스트 생성이 테스트 모델 및 모델 기반 테스트 접근 방식을 사용하여 추상화가 이루어지는 지에 대한 이해가 필요할 수 있다. TAE는 TAE의 전반적인 기능성, 유지보수성, 확장성과 관련하여 복잡한 구현과 간단한 구현간의 트레이드 오프가 있다는 것을 인지해야한다. TAA에서 어떠한 추상화를 사용할 지 결정할 때 이러한 점들에 대해 절충안을 고려해야한다.

TAA에 더 많은 추상화를 사용할수록, 새로운 접근법이나 새로운 기술의 접목에 대해 더욱 유연해진다. 이것은 초기 투자 비용 (더 복잡한 테스트 자동화 구조나 도구, 높은 기술 능력 요구사항과 러닝 커브 등) 을 증가시켜 초기 손익분기점을 딜레이 시키지만, 장기적으로는 이득이 될 수 있다. 또한 TAS의 성능이 낮아질 수 있다.

세부적인 투자대비 수익에 대한 고려사항은 TAM의 책임이나, TAE는 타이밍, 비용, 노력, 혜택의 측면에서의 테스트 자동화 구조와 접근법에 대한 기술적인 평가와 비교를 제공함으로써 ROI 분석에 필요한 매개변수를 제공해야한다.

SUT 기술과 TAS와의 상호 연결 방법 이해

SUT의 테스트 인터페이스로의 접근은 테스트 자동화의 핵심이다. 아래의 수준에서 접근할 수 있다.

• 소프트웨어 레벨 : SUT와 테스트 소프트웨어를 같이 묶는다
• API 레벨 : TAS가 제공된 API를 이용해 메소드,동작,함수를 직접 호출한다.
• 프로토콜 레벨 : TAS가 HTTP, TCP등을 통해 SUT와 상호작용
• 서비스 레벨 : RESTful 서비스, 웹 서비스 등을 통해 SUT의 서비스와 상호작용

게다가, TAE는 TAS와 SUT간의 API, 프로토콜 혹은 서비스 등으로 분리된 경우 상호작용을 위해 사용할 TAA의 인터렉션 패러다임을 결정해야한다. 이 패러다음에는 아래와 같은 것들이 포함된다.

• Event-driven 패러다임 : 이벤트 버스를 통해 이벤트를 상호 교환하여 상호작용을 주도
• Client-server 패러다임 : 서비스 요구자가 서비스 제공자의 기능을 호출하여 상호작용을 주도
• Peer-to-Peer 패러다임 : 상호 피어간 서비스를 호출하여 상호작용을 주도

패러다임의 선택은 종종 SUT의 아키텍처에 의존하기도 하며, SUT 아키텍처에 영향을 끼칠 수도 있다. SUT와 TAA의 상호 연결은 두 시스템 간의 미래안전적 아키텍처를 선택하기 위해 신중하게 분석하고 설계되어야 한다.

SUT 환경의 이해

SUT는 독립형 소프트웨어 일수도 있고, 다른 소프트웨어(시스템의 시스템)나 하드웨어(임베디드), 혹은 환경적 요인(사이버-물리시스템)과 관계를 맺어야만 동작하는 소프트웨어일 수도 있다. TAS는 자동 테스트 설치의 한 파트로써 SUT 환경에 대해 시뮬레이션/에뮬레이션을 해야한다.

시뮬레이션 : 실시간성이 없고 외부와의 인터페이스가 다르다
에뮬레이션 : 실시간성이 있고 외부와의 인터페이스가 원 시스템과 동일하다

테스트 환경과 예시 용도는 아래와 같다.

• SUT와 TAS가 모두 설치된 컴퓨터 - 소프트웨어앱의 테스트에 유용
• SUT와 TAS를 위해 각각의 네트워크에 연결된 컴퓨터 - 서버 소프트웨어 테스트에 유용
• SUT의 기술적 인터페이스를 관찰하고 시뮬레이션하기 위한 추가 테스트 장비 - 셋톱박스 소프트웨어 테스팅에 유용
• SUT의 운용환경을 에뮬레이트하는 네트워크에 연결된 테스트 장비 - 네트워크 라우터 소프트웨어의 테스트에 유용
• SUT의 실제 물리 환경을 모방하는 시뮬레이터 - 임베디드 제어 장치 테스트에 유용

주어진 테스트웨어 구조 구현의 시간과 복잡성

TAS 프로젝트의 코스트 추정 평가는 TAM의 몫이지만, TAE는 TAA 설계의 시간과 복잡성에 대한 좋은 추정을 실시하여 TAM을 지원해야한다. 평가 방법과 예시는 아래와 같다.

• 유사성 기반 추정 : function point, 3-porint, 와이드밴드 델파이, 전문가 추정
• WBS를 통한 추정 : 관리 소프트웨어나 프로젝트 템플릿
• 파라메트릭 추정 : COCOMO 방법
• 크기 기반 추정 : function point, story point, use-case 기반 분석
• 그룹 추정 : 플래닝 포커

주어진 테스트웨어 아키텍처 구현의 사용 용이성

TAS의 기능성, SUT와의 호환성, 장기 안정성과 업데이트 가능성, 필요 요구능력, 투자대비 수익 이외에도, TAE는 TAS의 사용 용이성 문제에 대해서는 책임이 있다. 다음사항이 포함되긴하나 꼭 여기에만 정해져있진 않다.

• 테스터 지향 설계
• TAS의 사용 용이성
• 소프트웨어 개발, 품질 보증, 프로젝트 관리 등 다른 역할에 대한 TAS 지원
• TAS와의 효과적인 조직, 방향성, 연구 등
• 유용한 문서, 매뉴얼, TAS에 도움이 되는 텍스트
• TAS에 대한 실용적인 리포트
• TAS로의 피드백 및 경험적 통찰을 다루기 위한 반복적 설계

3.2.2 Approaches for Automating Test Case

테스트 케이스 자동화를 위한 접근방법

테스트케이스는 SUT에 대해 실행되는 일련의 액션으로 번역되어야할 필요가 있다. 해당 동작의 순서는 테스트 절차에 문서화되거나, 테스트 스크립트로 구현될 수도 있다. 동작외에도 자동화된 테스트케이스는 SUT와의 상호작용을 위한 테스트 데이터를 정의하고, SUT가 예상 결과를 달성했는지 확인하는 검증단계를 포함해야한다. 일련의 동작을 생성하는 데에는 아래와 같은 여러가지 접근 방법이 있다.

1. TAE가 직접 테스트 케이스를 자동화된 테스트 스크립트로 구현한다. 이것은 추상화가 부족하고 유지보수 비용이 증가하므로 가장 권장하지 않는다.
2. TAE가 테스트 절차를 설계하고 이것을 테스트 자동화 스크립트로 변환한다. 이 방법은 추상화의 정도는 가지고 있으나 테스트 스크립트를 생성하는 자동화가 부족하다.
3. TAE가 도구를 사용하여 테스트 절차를 테스트 자동화 스크립트로 변환한다. 이 방법은 추상화와 자동 스크립트 생성은 동시에 수행한다.
4. TAE가 도구를 사용하여 자동화된 테스트 절차를 생성하거나 모델에서 직접 테스트 스크립트로 변환해낸다. 이 방법은 가장 높은 수준의 자동화를 제공한다.

위 방법들은 프로젝트의 맥락에 따라 좌지우지된다. 위 방법들은 일반적으로 구현하기 쉽기때문에 테스트 자동화를 덜 진보적인 방법 중 하나를 골라 시작하는 것이 효율적일지도 모른다. 단기적으로는 어떠한 가치를 제공할지는 모르나, 유지보수가 좋지 않은 솔루션이 만들어질지도 모른다.

잘 확립된 테스트 케이스 자동화 접근방법은 아래를 포함한다.

• 1번에 사용할 수 있는 캡쳐/플레이백 접근방법
• 2번과 3번에 적용할 수 있는 구조화된 스크립팅 접근방법, data-driven 접근 방법, keyword-driven 접근방법
• 4번에 적용할 수 있는 Model-based testing 방법

이러한 접근 방법들의 주요 개념과 장단점은 아래에 이어서 설명한다.

Capture / Playback 방법

캡쳐/플레이백 방법은 도구를 사용하여 테스트 절차에 정의된 일련의 동작들을 수행할 때, SUT와의 상호작용을 녹화한다. 입력이 녹화되고, 출력 또한 녹화된다. 녹화한 것을 재생하는 동안 여러가지 수동/자동 출력 확인을 할 수 있다.

• 수동 : 테스터가 SUT의 출력을 보면서 이상 여부를 확인해야한다.
• 완전성 : 녹화 중 발생된 시스템의 출력은 SUT에 의해 재현되어야한다.
• 정확성 : 녹화 중 발생된 모든 시스템의 출력은 기록된 세부 수준까지 SUT에 의해 재현되어야한다.
• 확인 : 특정한 지점에서 지정된 값에 대해 선택된 시스템 출력만 확인한다.

장점
캡쳐/플레이백 방법은 GUI 혹은 API 단계에서 SUT 에 사용할 수 있다. 초기 설정 및 사용이 쉽다.
단점
유지보수가 힘들고 기능 추가가 어렵다. 녹화를 수행한 SUT의 버전에 매우 의존적이다. 변경에 취약하다.

테스트 케이스의 구현은 SUT를 사용가능할 때만 구현할 수 있다.

Linear scripting

모든 스크립팅 기술과 마찬가지로, 리니어 스크립팅은 수동 테스트 절차로부터 시작된다. 그러나 이러한 절차는 문서가 아닐수도 있으며, 실행할 테스트에 대한 지식과 어떻게 테스트를 실행하는지는 한 명 이상의 테스트 분석가만 알 수도 있다.
각 테스트는 수동으로 실행되며, 테스트 도구가 동작 순서를 기록하고, 어떠한 경우에는 SUT의 화면에 나타나는 출력도 녹화한다. 일반적으로 이는 각 테스트 절차에 대해 하나의 스크립트를 생성한다. 녹화된 스크립트는 수정하거나 가독성을 향상시키기 위해 코멘트를 추가하거나 할 수도 있고, 도구에 스크립트 언어를 추가하여 추가 확인을 수행할 수 있다.
도구는 이러한 스크립트를 재생할 수 있어야하며, 스크립트가 기록할 때 테스터가 취한 동작을 반복해야한다. 이것은 GUI 테스트 자동화에는 사용할 수 있으나, 많은 수의 테스트를 자동화해야하거나 소프트웨어의 많은 릴리즈에 대응해야할때는 적절하지 못할 수 있다. 왜냐하면 SUT의 변경으로 인해 기록된 스크립트를 다수 수정해야하는 높은 유지보수 비용 떄문이다.

장점
리니어 스크립팅의 장점은 자동화를 시작하기 전에 준비작업이 거의 없다는 것이다. 도구 사용법을 배운다면, 간단하게 매뉴얼 테스트를 기록하고 재생하는 것으로 충분하다. 프로그래밍 언어는 필수는 아니나 알면 도움된다.

단점
리니어 스크립팅의 단점은 매우 많다. 주어진 테스트 절차에 대해 자동화하는 노력은 주로 수행해야할 동작의 수에 비례한다. 즉, 1000개의 테스트를 자동화하는 데에 필요한 노력은, 100개를 자동화하는 데 필요한 노력과 비슷하다. 다시 말해, 새롭게 자동화하는 비용을 줄일 여지가 거의 없다.
또한 다른 입력값으로 비슷한 테스트를 수행하는 2번째 스크립트가 있다고 한다면, 해당 스크립트는 첫 번쨰 스크립트와 동일한 동작 흐름을 포함하며 단지 입력값만 다를 것이다. 여러 테스트가 존재한다면, 이것은 곧 같은 동작의 흐름을 전부 포함할 것이며 소프트웨어에 변경점이 발생할 때마다 모두 유지보수해야한다.
스크립트는 프로그래밍언어로 작성되므로, 프로그래밍 언어에 익숙하지 않은 사람은 이해하기 어려울 수 있다. 일부 테스트는 고유 언어를 사용하므로 언어를 배우고 숙달하는데 시간이 걸린다.
기록된 스크립트에는 코멘트가 거의 없거나 일반적인 설명만 포함될 것 이다. 긴 스크립트는 각 단계에서 무슨일이 일어나고 있는지 설명하는 주석을 추가하는 것이 좋다. 이것은 유지보수를 쉽게 만든다. 테스트가 많은 단계를 포함할 때는 스크립트는 매우 커질 수 있다.
스크립트는 모듈화할 수 없고 유지보수하기 어렵다. 리니어 스크립팅은 일반적인 소프트웨어 재사용성과 모듈화 패러다임을 따르지 않으며, 사용중인 도구와 밀접하게 연관되어 있다.

Structured scripting

구조화된 스크립팅 기술과 리니어 스크립팅 기술간의 주된 차이로는 스크립트 라이브러리의 도입에 있다. 이 라이브러리는 여러 테스트에서 공통으로 사용될 수 있는 어떠한 명령의 절차들을 수행하는, 재사용 가능한 스크립트가 포함되어 있다. 이러한 스크립트의 좋은 예시로는 SUT 인터페이스의 작업과 연동되는 스크립트가 있다.

장점
이 방법의 장점으로는 유지보수 변경에 필요한 코스트가 상당히 줄어들며, 더 많은 테스트를 자동화할 수 있고, 리니어 스크립팅에서 요구되는 대량의 스크립트를 생성할 필요가 없음을 의미한다. 이것은 빌드 및 유지보수 비용에 직접적인 영향을 미친다. 두 번째 및 그 이후 테스트는 첫 번째 테스트를 구현하기 위해 생성된 일부 스크립트를 재사용할 수 있어 자동화하는데 많은 노력이 들지 않는다.

단점
여러 테스트에서 재사용할 수 있는 스크립트를 작성하는 초기 노력은 단점으로 보일 수 있으나, 적절히 이용하면 초기 투자는 큰 이익을 가져다 줄 수 있다. 단순히 녹화만으로는 충분하지 않기 때문에 모든 스크립트를 작성하려면 프로그래밍 기술이 필요하다. 스크립트 라이브러리는 잘 관리되어야 하며, 스크립트는 문서화되어야하고, 테크니컬 테스트 분석가가 필요한 스크립트를 쉽게 찾을 수 있어야 한다.

Data-driven testing

데이터 주도 스크립팅 기술은 구조화 스크립팅 기술을 기반으로 한다. 제일 큰 차이점은 테스트 입력을 처리하는 방법이다. 입력 데이터는 스크립트에서 추출되어 하나 이사의 별도 파일에 저장한다.
이것으로 인해 주요 테스트 스크립트를 여러 테스트를 구현하는 데 재사용할 수 있다. 일반적으로 재사용 가능한 주요 테스트 스크립트를 제어 스크립트 라고 한다. 제어 스크립트에는 테스트를 수행하는 데 필요한 명령의 흐름들이 포함되어있으며, 입력 데이터는 데이터 파일로 읽어온다. 하나의 제어 테스트는 여러 테스트에 사용될 수 있지만, 다양한 테스트를 자동화하기에는 충분하진 않다. 따라서 여러 개의 제어 스크립트가 필요하나, 이것은 자동화된 테스트의 일부에 불과하다.

장점
신규 자동테스트를 추가하는 코스트를 크게 절감할 수 있다. 이 방법은 테스트의 다양한 변형을 자동화하는데 유용하고, 특정 영역에서 더 deep한 테스틀르 수행하며 테스트 범위를 확장할 수 있다.
테스트가 데이터 파일에 의해 설명되므로, 테스트 분석가가 하나 이상의 데이터 파일을 채워, 자동화된 테스트를 지정할 수 있다. 이는 테스트 분석가가 테크니컬 테스트 분석가에게 크게 의존하지 ㅇ낳고 자동화된 테스틀르 지정할 수 있게 한다.

단점
데이터 파일을 관리하고 TAS에서 읽을 수 있도록 하는 것은 단점이긴 하나, 적절히 핸들링 할 수 있다. 또한 중요한 네거티브 테스트케이스가 누락될 수 있다. 네거티브 테스트는 테스트 절차와 테스트 데이터의 조합으로 만들어지는데, 주로 테스트 데이터를 타겟으로 하는 접근방식에서는 네거티브 테스트 스텝이 누락될 수 있다.

Keyword-driven Testing

키워드 주도 스크립팅 기술은 데이터 주도 스크립팅 기술을 기반으로 한다. 2가지 차이가 있는데, 1. 데이터 파일은 테스트 정의 파일 또는 그와 비슷한 이름으로 불린다. 2. 제어 스크립트는 단 하나만 존재한다.

테스트 정의 파일은 테스트 분석가가 이해하기 쉽게 작성된 테스트 설명을 포함하고 있다. 이 파일에는 키워드 뿐만 아니라 고수준의 명령도 포함된다. 키워드는 테스트 분석가에게 의미있는 단어들로 선택되어야하며, 설명하는 테스트와 테스트 되는 앱에 적합해야한다. 이러한 키워드는 주로 시스템과 고수준의 비즈니스 레벨 인터렉션을 나타나는데 사용한다. 각 키워드는 SUT와의 세부 인터렉션을 나타낸다. 키워드의 흐름을 이용하여 테스트 케이스를 지정한다. 특정 키워드는 검증 단계를 위해 사용되거나, 동작과 검증 모두를 포함할 수 있다. 테스트 분석가는 키워드 파일을 생성하고 유지보수할 책임을 가지고 있다. 이것은, 지원 스크립트가 구현되면, 테스트 분석가가 키워드 파일에 테스트를 지정함으로써 자동화 된 테스트를 추가할 수 있음을 의미한다.

장점
제어 스크립트와 키워드 지원 스크립트가 작성되면, 새로운 자동화 테스트를 추가하는 비용이 크게 줄어든다.
테스트가 키워드 파일에 의해 설명이 되므로 테스트 분석가는 키워드와 관련된 데이터를 사용하여 테스트를 설명함으로써 자동화된 테스틀르 지정할 수 있다. 이것은 테스트 분석가가 테크니컬 테스트 분석가에게 의존하지 않고 자동화된 테스트를 지정할 수 있는 자유를 제공한다. 이 측면에서 키워드 기반 접근 방식의 장점은, 데이터 기반 접근 방식보다 키워드 를 사용한다는 것이다. 각각의 키워드는 의미 있는 결과를 생성하는 일련의 동작을 나타내야한다.
예를 들어, 계정 생성, 주문하기, 주문 상태 확인하기 는 각각의 여러 상세 단계를 포함하는 온라인 쇼핑 앱에서의 가능한 동작들이다. 한 테스트 분석가가 다른 테스트 분석가에게 시스템 테스트를 설명할 때, 고수준의 동작을 기준으로 설명할 가능성이 높으며 이것은 상세한 단계가 아니다. 키워드 주도 접근방식의 목적은, 이러한 고수준 동작을 구현하고 테스트를 고수준 동작으로 정의할 의할 수 있게 하는 것이다.

이러한 테스트케이스는 유지관리 및 가독성, 작성난이도가 쉽다. 복잡한 것은 키워드 및 라이브러리에 숨길 수 있다. 키워드는 SUT 인터페이스의 복잡성으로부터 추상화를 제공한다.

단점
키워드를 구현하는 것은 이 스크립팅 기술을 지원하지 않는 도구를 사용할 때에는 테스트 자동화 엔지니어에게는 큰 작업이다. 적은 시스템의 경우 구현하는데 너무 많은 코스트가 사용될 수 있다.

올바른 키워드를 구현하는 데에 신경을 써야한다. 좋은 키워드는 많은 다른 테스트에서 자주 사용되지만, 좋지 않은 키워드는 한 번 또는 몇 번만 사용될 가능성이 높다.

Process-driven scripting

프로세스 주도 접근법은 키워드 주도 스크립팅 기술을 기반으로 하며, 차이점은 시나리오가 스크립트를 구성한다는 것 이다. 이러한 시나리오는 SUT의 사용 사례와 다른 변형을 나타내며 테스트 데이터로 매개변수화하거나 고수준의 테스트 정의와 결합한다.
이러한 테스트 정의는 동작간의 논리적인 관계, 예를 들어 기능 테스트에서 “주문 후 상태 확인” 이나 견고성 테스트에서 이전 “주문 없이 상태 확인” 등의 관계를 쉽게 처리할 수 있다.

장점
프로세스처럼 시나리오 기반으로 정의된 테스트 케이스를 사용하면, 워크플로우 관점에서 테스트 절차를 정의할 수 있다. 프로세스 기반 접근법의 목표는, 이러한 고 수준의 워크플로우를 상세한 테스트 단계를 나타내는 테스트 라이브러리를 사용해서 구현하는 것이다.

단점
SUT의 프로세스를 기술 테스트 분석가가 이해하기 쉽지 않을 수 있다. 도구가 비즈니스 프로세스 로직을 지원하지 않는 경우, 프로세스 지향 스크립트의 구현도 어렵다.
올바른 키워드를 사용하여 올바른 프로세스를 구현하도록 주의가 필요하다. 좋은 프로세스는 다른 프로세스에 의해 많이 참조되고 많은 관련 테스트를 생성하지만, 좋지 못한 프로세스는 관련성, 오류 감지 능력 등에서 이점을 제공하지 못할 것이다.

Model-based testing

모델 주도 테스트는 테스트 케이스의 자동 실행이 아닌 자동 생성을 의미한다. 이것은 캡쳐/플레이백, 리니어 스크립팅, 구조적 스크립팅, 데이터 주도 스크립트 혹은 프로세스 주도 스크립트를 이용해 실행하게 된다. 모델 주도 테스트는 TAA의 스크립팅 기술로부터 추상화된 공식 모델을 사용한다. 다양한 테스트 생성 방법이 이전에 논의된 모든 스크립팅 프레임워크에 대한 테스트를 도출하는데 사용될 수 있다.

장점
모델 기반 테스트는 추상화를 통해 비즈니스 로직, 데이터, 시나리오, 환경 등 테스트 본질에 집중할 수 있게 해준다. 다양한 대상 시스템과 기술에 대한 테스트를 생성할 수가 있어서 테스트 생성에 사용된 모델이 기술이 발전하더라도 재사용 및 유지 관리가 가능한 미래 지향적인 테스트웨어 표현을 가능하게 한다.
요구사항이 변경되는 경우, 테스트 모델만 수정하면 된다. 전체 테스트 케이스 세트는 자동으로 생성된다. 테스트 케이스 설계 기술은 테스트 케이스 생성기에 포함된다.

단점
모델 기반 테스트를 효과적으로 실행하려면 모델링 전문 지식이 필요하다. SUT의 인터페이스, 데이터 및 동작을 추상화하고 모델링하는 작업은 어려울 수 있다. 게다가 모델링 및 모델 기반 테스트 도구는 아직은 주류가 아니지만 성숙해지고 있다. 모델 기반 테스트는 테스트 프로세스의 조정이 필요하다. 예를 들어 테스트 설계자의 역할이 확립되어야한다. 또한 테스트 생성에 사용되는 모델은 SUT의 품질 보증을 위한 주요 산출물이므로 품질 보증 및 유지 관리가 필요하다.

3.2.3 Technical considerations of the SUT

SUT의 기술적 고려사항

TTA를 설계할 때 SUT의 기술적 측면을 고려해야한다. 아래는 중요한 예시들이며 완전한 목록은 아니다.

SUT의 인터페이스

SUT의 내부 인터페이스(시스템 내부)와 외부 인터페이스 (시스템 환경과 사용자 또는 외부 노출된 구성 요소)로 나뉜다. TAA는 테스트 절차에 영향을 받을 수 있는 모든 SUT 인터페이스를 제어 및 관찰할 수 있어야한다. (즉, 인터페이스는 테스트 가능해야한다.) 또한, 다양한 상세 수준으로 SUT와 TAS간의 상호작용을 로깅할 수 있어야하며, 일반적으로는 타임스탬프까지 포함되게 된다.
테스트 초점(테스트)는 프로젝트 초기(혹은 계속적인 애자일 환경)에 아키텍쳐를 정의하는 동안 SUT가 테스트 가능하도록 필요한 테스트 인터페이스나 테스트 시설등의 가용성을 확인하기 위해 필요하다.

SUT 데이터

SUT는 인스턴스화, 구성, 관리 등을 제어하기 위해 구성 데이터를 사용한다. 게다가 사용자 데이터를 처리하며 다른 시스템에서 외부 데이터를 사용할 수도 있다. SUT의 테스트 절차에 따라, 이러한 모든 유형의 데이터는 TAA에 의해 정의, 구성 및 인스턴스화가 가능해야한다. SUT 데이터를 다루는 특정한 방법은 TAA 설계에서 결정된다. 접근 방식에 따라 데이터는 파라미터, 테스트 데이터 시트, 테스트 데이터베이스, 실제 데이터 등으로 처리할 수 있다.

SUT 구성

SUT는 다양한 구성으로 배포될 수 있으며, 예를 들어 여러가지 OS, 여러가지 디바이스 혹은 여러가지 언어 세팅들에서 실행될 수 있다. 테스트 절차에 따라 TAA는 다양한 SUT 구성을 다루어야할 수도 있다. 테스트 절차는 TAA와 주어진 SUT 환경의 조합으로 다른 테스트 설정 혹은 가상 테스트 설정을 요구할 수 있다. 또한 선택된 SUT 에 대한 선택된 구성요소를 위해 에뮬레이터/시뮬레이터를 추가해야할 수도 있다.

SUT 표준 및 법적 설정

SUT의 기술적인 측면 이외에도 TAA 설계는 법적/표준 요구사항을 준수하여 호환가능하게 설계해야할 수도 있다. 예를 들어 테스트 데이터의 프라이버시 요구사항이나 TAA의 리포팅 및 보고 기능에 영향을 미치는 기밀성 요구사항 등이 있다.

SUT 개발에 사용된 도구와 도구 환경

SUT 개발과 함께 요구사항 엔지니어링, 설계 및 모델링, 코딩, 통합 및 배포를 위해 다양한 도구들이 사용될 수 있다. TAA와 그 도구들은 SUT 도구 환경을 고려하여 도구 호환성, 추적성 및 아티팩트 재사용성을 고려해야한다.

소프트웨어 제품의 테스트 인터페이스

프로덕트 릴리즈 이전에 테스트 인터페이스를 제거하지 않는 것을 강력히 권장한다. 대부분의 경우, 이러한 인터페이스들을 남겨도 문제를 일으키지 않는다. 인터페이스를 남겨두면 서비스 및 서포트 엔지니어들이 문제 진단 및 유지보수 단계에서의 테스트를 하는데 사용할 수 있다. 물론 인터페이스가 보안리스크를 야기하지 않는 것을 확인하는 것이 중요하다. 필요하다면, 개발자들은 이러한 테스트 인터페이스를 개발 부서 외부에서 사용하지 못하도록 비활성화해야한다.

3.2.4 Considerations for Development/QA Process

개발/QA 프로세스에 대한 고려 사항

TAA를 설계할 때 SUT의 개발 및 QA 프로세스를 고려해야한다. 아래는 중요한 예시들이며 완전하진 않다.

테스트 실행 제어 요구사항

TAA에서 요구되는 자동화 수준에 따라서, 상호작용 테스트 실행, 배치 모드 테스트 실행 혹은 완전 자동화된 테스트 실행을 지원해야할 필요가 있다.

리포팅 요구사항

리포트의 종류와 어떠한 구조를 포함한 보고 요구사항에 따라, TAA는 다양한 포맷과 레이아웃으로 고정된 매개변수화 혹은 정의된 테스트 보고서를 제공해야한다.

역할 및 접근 권한

보안 요구사항에따라 TAA는 역할별 접근 권한 시스템을 제공해야할 수도 있다.

확립된 도구 환경

SUT 프로젝트 관리, 테스트 관리, 코드와 테스트 레포지토리, 결함 추적, 이슈 관리, 리스크 분석 등은 도구 환경에 의해 지원받아야할 수도 있다. TAA는 다른 도구들과 함께 원활하게 통합되어야하는 또는 그러한 세트들로부터 지원받는다. 또한 테스트 스크립트는 SUT 코드 처럼 버저닝되고 저장되어야한다.

---

3.3 TAS Development

3.3.1 Introduction to TAS Development

TAS 개발은 다른 소프트웨어 개발 프로젝트와 비교할 수 있다. 테스터와 개발자간의 피어리뷰를 포함한 어떠한 동일한 프로세스나 절차를 따른다. TAS의 특이한 점으로는 SUT와의 호환성 및 동기화이다. 이 요구사항들은 TAA 설계와 TAS 개발 시에 고려되어야한다. 또한 SUT는 어떠한 테스트 전략에 영향을 받는데, 그것은 TAS를 사용할 수 있도록 어떠한 테스트 인터페이스 등을 제공해야하는 등의 전략이다.

이 섹션에서는 소프트웨어 개발 사이클 SDLC 를 사용하여 TAS 개발 프로세스와 SUT와의 호환성 및 동기화와 관련된 프로세스를 설명한다. 이러한 것들은 SUT 및 TAS 개발을 위해 선택되었거나, 실행중인 다른 개발 프로세스들에도 동일하게 중요하며, 이것에 따라 적절하게 조정되어야 한다.

TAS에 대한 요구사항들은 분석하고 수집해야한다. 이러한 요구 사항은 TAA가 정의한대로 TAS의 설계가 될 수 있도록 안내한다. 이 설계는 소프트웨어 엔지니어링 접근법을 통해 소프트웨어로 개발된다. TAS는 전용 테스트 장치를 사용할 수도 있는데 이것은 이번 실라버스에서는 제외한다. 다른 소프트웨어와 마찬가지로, TAS 또한 테스트됭어ㅑ한다. 일반적으로 TAS의 기본 기능 테스트로 시작하여 SUT와 TAS간의 상호작용으로 이어진다. TAS 배포 및 사용 후에, 테스트 기능을 추가한다거나, 테스트를 변경한다거나, 변경되는 SUT에 맞추어 TAS를 업데이트해야하는 TAS의 진화가 필요하다. TAS의 진화는 SDLC에 따라 새로운 TAS 개발 라운드로 진입하는 것이 필요하다.

SDLC에는 TAS의 백업, 아카이브 및 제거가 포함되지 않는다는 것을 알아야한다. TAS 개발과 마찬가지로, 이러한 절차는 조직에서 확립된 어떠한 방법을 따라야 한다.

3.3.2 Compatibility between the TAS and the SUT

SUT와 TAS간의 호환성

프로세스 호환성

SUT 테스트는 SUT 개발과 동기화되어야하며, 테스트 자동화의 경우에도 TAS 개발과도 동기화되어야 한다. 따라서, SUT개발, TAS개발 및 테스트의 프로세스를 조율하는 것이 유리하다. SUT와 TAS 개발이 프로세스 구조, 프로세스 관리 및 도구 지원 측면에서 호환될 때 큰 이익을 얻을 수 있다.

팀 호환성

팀 호환성은 TAS와 SUT 개발간의 다른 호환성 측면이다. TAS와 SUT 개발을 접근하고 관리하는 데 있어 호환이 가능한 사고방식이 있다면, 두 팀은 서로의 요구사항, 설계 및 개발 산출물을 검토하고, 문제를 논의하고 호환 가능한 솔루션을 찾음으로 인해 이익을 얻을 수 있을 것이다.팀 호환성은 서로간의 커뮤니케이션과 상호 작용에도 도움이 된다.

기술 호환성

게다가 TAS와 SUT간에 기술호환성이 고려되어야한다. 처음 시작할 때부터 TAS와 SUT간의 원활한 상호작용을 설계하고 구현하는 것이 유리하다. 심지어 그것이 불가능할 경우 (TAS와 SUT에 공통적으로 사용할 수 없는 경우) 어떠한 어댑터/랩퍼 혹은 또다른 어떤 중계자의 형태를 이용해서 상호작용을 해야 유리하다.

도구 호환성

TAS와 SUT 관리, 개발, 품질 보증을 위해 도구 호환성을 고려해야한다. 예를 들어 동일한 요구사항 관리 및 이슈 관리 도구를 사용한다면, 정보 교환 및 TAS와 SUT 개발간의 조정이 훨씬 쉬워질 것 이다.

3.3.3 Synchronization between TAS and SUT

SUT와 TAS간의 동기화

요구사항 동기화

요구사항을 수집한 후에, SUT와 TAS의 요구사항이 개발되어야한다. TAS 요구사항은 두 가지 주요 그룹으로 나눌 수 있다.

1. 테스트 설계, 테스트 명세, 테스트 결과 분석 등을 위한 TAS 기능에 대한 요구사항과 같은 소프트웨어 기반 시스템으로서의 TAS를 다루는 내용
2. TAS를 통해 SUT를 테스트하는 내용의 요구사항

이러한 이른바 테스트 요구사항은 SUT의 요구사항에 해당하며, TAS가 테스트해야할 SUT의 기능과 속성을 반영한다. SUT나 TAS의 요구사항이 업데이트될 때 마다 두 요구사항 간의 일관성을 검증하고, TAS가 테스트해야할 모든 SUT 요구사항이 정의되어있는지를 확인해야한다.

개발 단계의 동기화

SUT를 테스트하기 위해 TAS가 필요할 때 준비될 수 있도록 개발단계를 조정해야한다. SUT와 TAS 요구사항, 설계, 명셰 및 구현이 동기화될 때 가장 효율적이다.

결함 추적의 동기화

결함은 SUT, TAS 또는 요구사항, 설계, 명세와 관련될 수 있다. 이러한 두 프로젝트간의 관계로 인해서, 한 프로젝트에서 결함이 수정될 때, 다른 쪽에 영향을 미칠 수 있다. 결함 추적과 확인 테스트는 TAS와 SUT 양쪽에서 다루어야한다.

SUT와 TAS 개선 동기화

SUT와 TAS 모두 새로운 기능을 추가하거나 비활성화하거나, 결함을 수정하거나 새로운 환경에 대응하기 위해 (SUT와 TAS가 상대 환경 구성 요소로서 변화를 포함하여) 개선할 수 있어야한다. SUT나 TAS에 적용된 어떠한 변경사항이라도 다른 한쪽에 영향을 미칠 수 있으므로, 이러한 변경사항 관리는 SUT와 TAS 모두를 관리해야한다.

SUT와 TAS 개발 프로세스 간의 2가지 동기화 방식은 아래 도식에 나타나 있다.

Figure 3은 SUT와 TAS 의 SDLC 프로세스가 두 단계에서 주로 동기화되는 방식을 나타낸다.

1. TAS 분석은 SUT 설계에 기반하며 이것은 SUT 분석에 다시 기반함
2. 배포된 TAS를 이용한 SUT 테스트

Figure 4는 수동 테스트와 자동 테스트를 모두 사용하는 하이브리드 방식을 나타낸다. 테스트가 자동화되기 전에 수동 테스트가 사용되거나 혹은 수동 및 자동테스트가 함 께 사용될 때, TAS 분석은 SUT 설계와 수동 테스트 모두에 기반되어야한다. 이렇게 함으로써 TAS가 둘 다와 동기화된다. 이 접근 방식의 두 번째 동기화 지점은 이전과 동일하게, SUT테스트는 배포된 테스트를 필요로 하며 수동테스트의 경우 수동 테스트 절차를 따르는 것일 수 있다.

3.3.4 Building Reuse into the TAS

TAS의 재사용성 구축하기

TAS의 재사용성은 제품 라인, 제픔 프레임워크, 제핌 도멘 및 다른 프로젝트들을 걸쳐 TAS 아티팩트를 재사용하는 것을 의미한다. 재사용성에 대한 요구사항은 다른 제품 변형, 제품 또는 프로젝트에 대한 TAS 아티팩트의 연관성으로부터 비롯된다. TAS 아티팩트의 재사용은 아래를 포함한다.

• 테스트 목표, 테스트 시나리오, 테스트 구성 요소 또는 테스트 데이터의 일부 테스트 모델
• 테스트 케이스, 테스트 데이터, 테스트 절차 또는 테스트 라이브러리 자체 혹은 일부
• 테스트 엔진 또는 테스트 보고서 프레임 워크
• SUT 구성요소 또는 인터페이스에 대한 어댑터

TAS가 정의될 때 이미 재사용 측면이 적용되어있으나, TAS는 다음을 통해 재사용 능력을 향상시킬 수 있다.

• 필요할 때마다 TAA를 따르거나 수정하기
• TAS 아티팩트를 쉽게 이해할 수 있고 새로운 맥락에 통합될 수 있도록 문서화하기
• 어떠한 TAS 아티팩트의 정확성을 보장하여 새로운 맥락에서 사용 품질이 높은 상태로 지원하기

재사용을 위한 설계는 주로 TAA의 문제이지만, 재사용을 위한 유지보수 및 개선은 TAS 라이프사이클 전반의 문제이다. 재사용을 실현하고, 재사용의 부가가치를 측정 및 입증하며, 기존 TAS를 재사용하도록 다른 사람을 설득하기 위한 지속적인 고려와 노력이 필요하다.

3.3.5 Support for a Variety of Target Systems

다양한 대상 시스템 지원

TAS가 다양한 대상 시스템을 지원하는 것은, TAS가 소프트웨어 제품의 다양한 구성요소를 테스트할 수 있는 능력을 의미한다. 다른 구성요소에는 아래의 항목들을 포함한다.

• SUT 구성 요소의 갯수와 상호 연결
• SUT 구성 요소가 실행되는 환경(소프트웨어/하드웨어)
• SUT 구성 요소를 구현하는 데에 사용되는 기술, 프로그래밍 언어, 운영 체제
• SUT 구성 요소가 사용하는 라이브러리 및 패키지
• SUT 구성 요소를 구현하는데 사용되는 도구

처음 4가지 측면에 대해서는 모든 테스트 수준에서 영향을 미치지만, 마지막 측면은 컴포넌트 레벨/통합테스트에서만 영향을 미친다.

TAS가 다양한 소프트웨어 제품 구성을 테스트할 수 있는 능력을 TAA가 결정될 때 정의된다. 그러나 TAS는 기술적 변화를 처리하는 능력을 구현해야하고 소프트웨어 프로덕트의 다양한 구성요소에 필요한 TAS 기능 및 구성요소를 관리할 수 있어야한다.

소프트웨어 제품의 다양성과 관련된 TAS의 다양성 처리는 다음과 같이 다룰 수 있다.

• TAS 및 SUT의 각각의 버전과 구성을 제공하기 위해 버전/구성 관리를 사용할 수 있다.
• TAS를 SUT의 구성에 맞추기 위해 TAS 매개변수를 사용할 수 있다.

TAS의 다양성을 위한 설계는 주로 TAA의 문제이긴 하지만, 다양성의 유지보수 및 개선은 TAS 수명 주기 전반에 걸친 문제이다. 이는 지속적인 고려와 노력이 필요하며, 옵션과 다양한 형태의 변수를 수정/추가하며 제거하는 과정을 포함한다.

끝!

---

Ref

• ISTQB CTAL TAE Syllabus