ITQB CTAL Test Automation Engineer - 1. Introduction and Objectives for Test Automation

Dahun Yoo·2024년 5월 19일
ISTQBQualityAssurancetesting
0

ISTQB CTAL TAE

목록 보기
4/9

테스트 자동화에 대한 소개와 목표

Keyword
API testing, CLI testing, GUI testing, SUT, TAA, taf, Test automation strategy, test automation, test script, testware

1.1 테스트 자동화의 목적

소프트웨어 테스팅에서, 테스트 자동화는 다음 작업 중 하나를 의미한다.

  • 특수한 목적의 소프트웨어 툴을 이용하여 테스트 전제조건을 설정하고 제어한다.
  • 테스트를 실행한다.
  • 예상 결과와 실제 결과를 비교한다.

좋은 방법으로는 테스트의 대상이 되는 시스템과 테스트 소프트웨어를 분리하는 것인데, 임베디드 시스템과 같이 SUT에 같이 테스트 소프트웨어가 배포되어야하는 소프트웨어는 예외이다.

테스트 자동화는 많은 테스트케이스에 대해 일관적이고 반복적으로 여러 버전의 테스트 대상 시스템 혹은 테스트 환경에 대해 실행하는 것을 기대한다. 그러나 테스트 자동화는 사람의 조작없이 테스트를 수행하는 것 그 이상이다. 아래와 같은 테스트웨어를 디자인하는 과정을 포함한다.

  • 소프트웨어
  • 문서
  • 테스트케이스
  • 테스트 환경
  • 테스트 데이터

테스트웨어는 아래를 포함하는 테스트활동에 꼭 필요하다.

  • 자동화된 테스트 케이스 구현
  • 자동화된 테스트의 제어와 모니터링
  • 자동화된 테스트의 결과 해석 및 로깅, 리포팅

테스트 자동화는 SUT(System Under Test) 와 인터렉션하는 여러가지 방법을 가지고 있다.

  • SUT의 public class, module, libraries 통한 테스트 (API)
  • SUT의 User interface를 통한 테스트 (GUI)
  • Protocol, server를 통한 테스트

테스트 자동화의 목적은 아래와 같다.

  • 테스트 효율 향상
  • 넓은 범위의 function coverage 보장
  • 전체 테스트 코스트 절감
  • 수동 테스트로는 어려운 테스트 수행
  • 테스트 실행 기간 단축
  • 테스트 빈도 증가 및 테스트 사이클에 필요한 시간 단축

테스트 자동화의 장점은 아래와 같다.

  • 빌드 당 테스트를 더 많이 수행할 수 있다.
  • 수동 테스트로는 수행하기 힘든 테스트를 할 수 있다. (실시간, 원격, 병렬)
  • 좀 더 복잡한 테스트를 수행할 수 있다.
  • 좀 더 빠른 테스트를 수행할 수 있다.
  • 조작 실수로 인한 영향을 덜 받으면서 테스트할 수 있다.
  • 테스트 리소스에 대해 좀 더 효과적이고 효율적으로 사용할 수 있다.
  • 소프트웨어 품질에 대한 빠른 피드백을 얻을 수 있다.
  • 시스템의 신뢰성이 향상된다. (반복성, 일관성 등)
  • 테스트의 일관성이 향상된다.

테스트 자동화의 단점은 아래와 같다.

  • 추가적인 코스트가 소모된다.
  • 테스트 자동화 솔루션 구축을 위한 초기 투자가 필요하다.
  • 추가적인 기술(인프라 등 Technologies) 들이 필요하다.
  • 팀에 개발과 자동화 기술(개개인의 Skills) 이 필요하다.
  • 테스트 자동화 솔루션의 유지보수가 필요하다.
  • 테스트 실행이 아닌 테스트케이스의 자동화가 우선되어 테스트 목표에 집중하지 못할 수 있다.
  • 테스트가 복잡해질 수 있다.
  • 자동화로 인해 추가적인 이슈가 발생할 수 있다.

테스트 자동화의 한계로는 아래와 같다.

  • 모든 수동 테스트를 자동화할 수 없다.

  • 테스트 자동화는 기계가 해석가능한 결과만 확인할 수 있다.

    • 사용성과 같은 사람이 보고 판단할 수 있는 그런 것은 자동 테스트로 확인할 수 없다.

  • 테스트 자동화는 자동화된 테스트 출처(Test oracle)에서만 확인할 수 있는 결과만 체크 가능하다.

    • 코드 상의 assert 를 통해서 확인가능 하다.

  • 탐색적 테스트를 대체할 수 없다.

1.2 테스트 자동화의 성공 요인

다음 성공 요인은 운영 중인 테스트 자동화 프로젝트에 적용되므로 프로젝트의 장기적인 성공에 영향을 미치는 요소에 중점을 둔다. 아래 내용에서는 테스트 자동화의 초기 단계에 영향을 미칠만한 요소는 고려되지 않았다.

주요 성공 요인으로는 아래와 같다.

Test Automation Architecture (TAA)

테스트 자동화 아키텍처(TAA)는 소프트웨어 아키텍처와 매우 밀접하게 관련된다. 아키텍처가 어떤 기능적 요구 사항과 비기능적 요구 사항을 지원하는지 명확해야 한다. 일반적으로 이것은 가장 중요한 요구 사항이 될 것이다.

TAA는 일반적으로 유지보수성, 성능, 학습성(learnability) 을 위해 설계된다. (ISO/IEC 25000:2014에서 이 내용과 비기능 특성에 대해 확인가능하다.) 테스트 대상 소프트웨어의 구조를 이해하고 있는 개발자를 TAA개발에 참여시키면 도움이 된다.

SUT Testability

테스트 대상 소프트웨어는 자동화된 테스트를 지원하기 위한 가능성을 염두하고 설계되어야한다. GUI 테스트의 경우, SUT(System Under Test)가 가능한 한 GUI와 관련 데이터들로부터 분리되어야하는 것을 의미할 수 있다. API테스트의 경우 더 많은 테스트가 수행될 수 있도록 많은 클래스, 모듈 CLI 등에 대해 public하게 제공되어야할 수도 있다.

SUT 의 테스트 가능한 부분을 먼저 목표로 설정해야한다. 일반적으로 테스트 자동화의 핵심 요소는 자동 테스트 스크립트를 쉽게 구현하는 것에 있다. 이것을 목표로 염두에 두고, 테스트 자동화 엔지니어 (Test Automation Engineer, TAE)는 쉽게 자동화할 수 있는 모듈이나 구성요소를 식별하고, 거기서부터 프로젝트를 시작하는 것이 필요하다.

Test Automation Strategy

실용적이고 일관성있는 테스트 자동화 전략으로는 SUT의 유지보수성과 일관성에 대해 고려해야한다.

SUT의 레거시 영역과 새로운 기능에 대해 모두 동일한 전략을 적용하는 것은 불가능할 수 있다. 자동화 전략을 세울 때 기존 기능과 신규 기능에 대한 테스트를 자동화 할 때 소모될 비용과 이점, 및 리스크를 고려해야한다.

테스트 결과의 일관성을 담보하기 위해 UI테스트와 API테스트를 둘 다 자동화하는 것을 고려해야한다.

Test Automation Framework, (TAF)

사용하기 쉽고, 잘 문서화되어있으며 유지보수하기 쉬운 테스트 자동화 프레임워크는, 자동 테스트에 대한 일관된 접근 방식을 지원한다.

사용하기 쉽고 유지보수하기 좋은 TAF를 만들기 위해서는 아래 내용이 반드시 수행되어야 한다.

  • 리포트 기능 구현 : 테스트 리포트에는 SUT의 퀄리티에 대한 정보 (테스트 성공실패 여부 등)이 포함되어야 한다. 또한 리포트는 테스터, 테스트 매니저, 개발자, PM, 그리고 다른 이해관계자들에게 제공되어야한다.
  • Troubleshooting을 하기 위한 방법 제공 : 테스트 실행과 로깅뿐만 아니라, TAF는 실패한 테스트에 대해 문제해결을 할 수 있는 방법을 제공해야한다. 테스트는 아래와 같은 이유로 실패할 수 있다.
    • SUT의 이슈로 인한 실패
    • TAS(Test Automation Solution) 으로 인한 실패
    • 테스트 자체의 오류 혹은 테스트 환경 이슈로 인한 실패
  • 적절한 테스트 환경의 준비 : 테스트 도구들은 테스트 환경의 일관성에 의존한다. 즉, 자동화된 테스트를 위해 전용 환경이 필요하다. 만약 테스트 환경과 테스트 데이터를 조작할 권한이 없는 경우, 테스트 실행을 위한 요구사항을 충족할 수 없을 수 있으며 이것은 잘못된 테스트 결과를 야기할 수 있다.
  • 자동 테스트케이스에 대한 문서화 : 테스트 자동화의 목표는 명확해야한다. 예를 들어 앱의 어느 부분이 테스트되어야하는지, 어느 정도 / 어떤 속성을 테스트해야하는지에 대해 명확하게 설명할 수 있어야하고 이것이 문서화되어야한다.
  • 자동 테스트의 대한 이력 추적 : TAF는 테스트케이스의 수행 단계들에 대해 수행이력을 추적할 수 있어야 한다.
  • 쉬운 유지보수성 : 이상적으로는 자동화된 테스트케이스는 테스트 자동화의 코스트의 많은 부분이 소비되지않도록, 쉽게 유지보수할 수 있어야한다. 게다가 유지보수에 들어가는 코스트는 SUT의 변경 사항 규모에 비례해야한다.(SUT의 변경범위보다 더 큰 범위로 유지보수가 이루어지면 안된다.) 이것을 위해서는 자동화 대상 케이스에 대해서 쉽게 분석할 수 있어야하고, 변경할 수 있고, 확장할 수 있어야 한다. 더욱이 자동화된 테스트웨어의 재사용성은 수정/변경이 필요한 항목을 최소화하기 위해 높아야한다.
  • 자동화된 테스트의 최신 상태 유지 : 새로운 요구사항이나 기존 기능의 변경으로 인하여 기존 테스트케이스가 실행 실패하는 경우, 해당 테스트를 비활성화하지 말고 수정해야한다.
  • 배포 계획 : 테스트 스크립트는 쉽게 수정할 수 있어야하고 반복적으로 배포할 수 있어야한다.
  • 테스트 제거 : 더 이상 필요없는 테스트케이스에 대해서는 쉽게 제거할 수 있어야 한다.
  • SUT의 모니터링과 자동 테스트의 복구 : 실제로는 계속적으로 테스트케이스를 실행하면서 SUT를 지속적으로 모니터링해야한다. 만약 SUT에 크래시와 같은 에러가 발생한다면, TAF는 현재 케이스를 스킵하고 다음 케이스가 실행되도록 회복이 가능해야한다.

테스트 자동화 코드는 유지보수하기 복잡해질 수 있다. SUT의 코드만큼 많은 코드를 가지고 있는 것은 드문일은 아니다. 이것이 테스트 코드가 유지보수할 수 있어야하는 이유이다. 테스트 자동화 코드가 SUT의 코드만큼 많은 이유는 다양한 테스트 도구, 다양한 유형의 검증 및 유지되어야하는 테스트웨어(테스트 데이터, 리포트 등)때문이다.

유지보수에 관한 점들을 염두에 두고 수행해야하는 점들과 더불어, 수행하면 안되는 몇가지 점들도 있다.

  • 인터페이스에 민감한 코드를 만들지 마라 (GUI나 API변경에 의존적인 코드)
  • 데이터의 변화나 특정 데이터값에 의존적인 코드를 만들지 마라
  • 운영체제의 날짜 혹은 운영체제의 지역, 다른 앱의 실행 상황에 의존적인 자동 테스트 전용 환경을 만들지 마라

테스트 자동화 프로젝트 성공 요인이 충족될 수록, 프로젝트가 성공할 가능성이 높아진다. 모든 요인이 필요한 것은 아니며 실제로 모든 조건이 충족되는 경우도 거의 없다. 테스트 자동화 프로젝트를 시작하기 전에, 프로젝트의 맥락 뿐 아니라 선택가능한 접근 방식들의 리스크를 염두에 두고, 누락될 요인들을 고려하여 프로젝트의 성공 가능성을 분석하는 것이 중요하다. TAA가 준비되면 어떤 항목이 빠졌는지 확인하는 작업이 필요하다.

ref.

  • ISTQB CTAL TAE Syllabus
profile
Dahun Yoo
QA Engineer
이전 포스트

ITQB CTAL Test Automation Engineer - 4. Deployment Risks and Contingencies

다음 포스트

ITQB CTAL Test Automation Engineer - 5. Test Automation Reporting and Metrics

0개의 댓글