ISTQB 용어집은 테스트 자동화(test automation)를 테스트 활동을 자동으로 돌아가게 바꾸는 일로 정의한다.[1] ISTQB CTAL-TAE(Certified Tester Advanced Level Test Automation Engineering) 강의계획서에 따르면 테스트 자동화는 자동화한 테스트 실행과 테스트 보고를 포함하며, 목적에 맞게 만든 도구로 테스트 스위트를 실행할 수 있게 제어하고 준비하는 일, 테스트를 자동으로 실행하는 일, 실제 결과를 기대 결과와 견주는 일 가운데 하나 이상을 가리킨다.[2]
ISO/IEC/IEEE 29119-1:2022는 수동 테스트(manual testing)를 사람이 테스트 항목에 정보를 넣고 그 결과를 확인하며 수행하는 테스트로 정의하고, 정의에 단 Note에서 자동화한 테스트는 도구, 로봇, 그 밖의 테스트 실행 엔진으로 테스트를 수행하며 수동 테스트는 이것들을 쓰지 않는다는 구분을 제시한다.[3]
테스트 자동화는 테스트 실행만이 아니라 테스트 케이스와 테스트 데이터를 만드는 일에도 쓰인다.[4][5]
이점과 한계
CTAL-TAE 강의계획서는 테스트 자동화의 이점으로 다음을 든다.[2]
- 빌드마다 수동 테스트보다 많은 테스트를 돌릴 수 있다.
- 실시간 응답, 원격 테스트, 병렬 테스트처럼 손으로는 할 수 없는 테스트를 만들고 실행할 수 있다.
- 수동 테스트보다 복잡한 테스트를 할 수 있고, 더 빨리 실행된다.
- 사람의 실수에 덜 휘둘리고, 테스트 자원을 더 효과적이고 효율적으로 쓴다.
- 테스트 대상의 품질을 더 빨리 알려 주고, 테스트 주기마다 테스트를 더 한결같이 실행한다.[2]
같은 강의계획서는 단점으로 테스트 자동화 엔지니어 채용, 새 하드웨어, 교육에 드는 비용, 자동화 솔루션을 갖추는 초기 투자와 그것을 개발하고 유지보수하는 시간, 테스트 대상의 변경에 잘 맞추지 못하는 경직성, 자동화가 새로 들여오는 결함을 든다. 한계도 있다. 수동 테스트를 모두 자동화할 수는 없고, 자동화한 테스트는 프로그래밍된 것만 확인한다. 기계가 해석할 수 있는 결과만 확인할 수 있어 자동화로 시험하지 못하는 품질 특성도 있고, 자동화한 테스트 오라클이 판정할 수 있는 결과만 확인한다.[2]
ISTQB CTFL 강의계획서에 따르면 테스트 자동화는 회귀 테스트 실행, 같은 테스트 데이터 다시 입력하기, 기대 결과와 실제 결과 비교하기처럼 되풀이하는 수작업을 줄일 수 있고, 테스터가 새롭고 더 효과적인 테스트를 설계할 시간을 늘릴 수 있다.[5]
아키텍처와 프레임워크
ISTQB 용어집은 gTAA(generic test automation architecture)를 테스트 자동화를 구조적이고 모듈화된 방식으로 구현할 수 있게 하는 층, 구성 요소, 인터페이스의 표현으로 정의한다.[6] CTAL-TAE 강의계획서에 따르면 gTAA는 테스트 자동화가 SUT(system under test), 프로젝트 관리, 테스트 관리, 형상 관리와 주고받는 것을 추상적으로 보이는 상위 설계 개념이다.[2]
ISTQB 용어집은 TAF(test automation framework)를 테스트 자동화를 위한 테스트 하네스와 테스트 라이브러리의 모음으로 정의한다.[7] CTAL-TAE 강의계획서에 따르면 TAF는 테스트 자동화 솔루션의 토대로, test runner라고도 부르는 테스트 하네스와 테스트 라이브러리, 테스트 스크립트, 테스트 스위트를 흔히 담는다.[2]
이 강의계획서는 목적이 비슷한 클래스를 층으로 묶되, 목적마다 층을 하나씩 두면 설계가 복잡해지므로 층의 수를 적게 두기를 권하고, 다음 세 층을 예로 든다.[2]
- 테스트 스크립트: SUT의 테스트 케이스 저장소와 테스트 스위트 주석을 담고, 비즈니스 로직 층의 서비스를 부른다. 핵심 라이브러리를 바로 부르지 않는다.
- 비즈니스 로직: SUT에 기대는 라이브러리를 모두 담고, TAF를 SUT에 맞춰 돌릴 수 있게 설정한다.
- 핵심 라이브러리: SUT와 상관없는 라이브러리를 담아, 같은 개발 스택을 쓰는 다른 프로젝트에서 다시 쓸 수 있다.[2]
자동화 접근
이 강의계획서는 자동화한 테스트 케이스를 만드는 접근으로 다음을 든다.[2]
- capture/playback: 손으로 하는 동작 순서를 SUT와의 상호작용으로 기록해 테스트 스크립트를 만든다. 처음에는 쓰기 쉽지만 유지보수와 확장이 어렵고, 기록하는 동안 SUT가 있어야 한다. 코드를 드러내지 않는 도구는 no-code, 드러내는 도구는 low-code 테스트 자동화라고도 부른다.
- linear scripting: 테스트 자동화 엔지니어가 만든 전용 테스트 라이브러리 없이 스크립트를 짜서 실행한다. capture/playback으로 기록한 스크립트를 고쳐 쓸 수 있다.
- structured scripting: 다시 쓸 수 있는 요소, 테스트 단계, 사용자 흐름을 담은 테스트 라이브러리를 들여온다. 유지보수와 확장이 쉽고 비즈니스 로직을 스크립트에서 뗄 수 있지만, 프로그래밍 지식과 TAF를 만드는 초기 투자가 든다.
- 데이터 기반 테스트: structured scripting 위에서, 스크립트에 파일이나 데이터베이스의 테스트 데이터를 주어 같은 스크립트를 여러 데이터로 되풀이해 돌린다.
- 키워드 기반 테스트: 키워드에서 끌어낸 테스트 단계와 키워드가 다루는 테스트 데이터를 목록이나 표로 적어 테스트 케이스를 만든다.
- TDD와 행위 주도 개발: 둘은 개발 방법론이지만, 제대로 따르면 자동화한 테스트 케이스가 만들어진다.[2]
테스트 환경
자동화한 테스트는 종류에 따라 서로 다른 환경에서 실행되고, 환경은 컨테이너나 가상화 소프트웨어로 만들 수 있다. 이 강의계획서는 고려할 환경으로 다음을 든다.[2]
- 로컬 개발 환경: 소프트웨어를 처음 만드는 곳으로, 컴포넌트 테스트, GUI 테스트, API 테스트를 자동화해 돌리고, 통합 개발 환경에서 화이트박스 테스트로 코드의 품질 문제를 일찍 찾는다.
- 빌드 환경: 소프트웨어를 빌드하고 그 빌드가 맞는지 확인하는 테스트를 돌린다. 다른 환경에 배포하지 않고 컴포넌트 테스트, 컴포넌트 통합 테스트 같은 낮은 수준의 테스트와 정적 분석을 한다.
- 통합 환경: 다른 시스템과 완전히 통합한 SUT의 릴리스 후보에 자동화한 UI 테스트나 API 테스트 스위트를 돌린다. 이 환경에서는 화이트박스 테스트 없이 블랙박스 테스트만 하고, 모니터링은 이 환경부터 둔다.
- 사전 운영 환경: 운영 환경과 되도록 닮게 꾸려 성능 효율 같은 비기능 품질 특성을 주로 평가하고, 업무 이해관계자가 사용자 인수 테스트를 하기도 한다.
- 운영 환경: 사용자가 배포된 시스템을 쓰는 동안 모니터링과 카나리 릴리스, 블루/그린 배포, A/B 테스트 같은 기법으로 기능과 비기능 품질 특성을 실시간으로 평가한다.[2]
파이프라인과 품질 게이트
자동화한 테스트는 사람이 지켜보지 않아도 돌아가므로 지속적 통합·지속적 전달 파이프라인에서 돌리기에 알맞다. 이 강의계획서에 따르면 파이프라인에는 대개 다음처럼 테스트를 넣는다.[2]
- 컴포넌트 테스트는 파이프라인의 빌드 단계에 들어 품질 게이트 구실을 하고, 낮은 수준의 컴포넌트를 시험하는 컴포넌트 통합 테스트도 함께 돌 수 있다.
- 시스템 통합 테스트는 흔히 지속적 전달 파이프라인에서 품질 게이트로 쓰여, 따로 개발한 시스템 컴포넌트가 함께 동작하는지 확인한다.
- 시스템 테스트는 흔히 지속적 배포 파이프라인에 들어, 전달할 SUT의 마지막 품질 게이트가 된다.
- 테스트 자동화 프로젝트 자체를 빌드할 때는 테스트 스크립트가 쓰는 파일의 경로가 맞는지 보는 설정 테스트를 돌린다.[2]
이 강의계획서에 따르면 시스템 통합 테스트, 시스템 테스트, 인수 테스트를 파이프라인에 넣는 방법은 둘이다. 컴포넌트를 배포한 뒤 배포 단계 안에서 실행하면 결과에 따라 배포를 실패시키고 되돌릴 수 있지만, 테스트를 다시 돌리려면 다시 배포해야 한다. 배포가 성공하면 따로 도는 파이프라인에서 실행하면 배포마다 다른 테스트 스위트를 돌리기 좋지만, 이때 테스트는 품질 게이트가 되지 못하고 실패한 배포를 되돌리는 데 대개 수작업이 든다.[2] 오래 걸리는 회귀 테스트 스위트를 밤마다 돌리는 것은 회귀 테스트에서 다룬다.
테스트 피라미드
ISTQB 용어집은 테스트 피라미드(test pyramid)를 레벨마다의 테스트 양의 관계를 아래쪽에 더 많이 두어 나타내는 그래픽 모델로 정의한다.[8]
CTFL 강의계획서에 따르면 테스트 피라미드의 층은 테스트의 묶음을 나타내고, 위층으로 갈수록 테스트의 세분성과 격리 정도가 낮아지고 실행 시간은 길어진다. 맨 아래층의 테스트는 작고 서로 떨어져 있으며 빠르고 기능의 작은 조각을 확인하므로, 적절한 커버리지를 얻으려면 대개 많이 필요하다. 맨 위층은 복잡한 끝에서 끝까지의 테스트로, 기능의 큰 덩어리를 확인하므로 대개 몇 개면 된다. 층의 수와 이름은 모델마다 다르다. 처음 나온 테스트 피라미드 모델(Cohn 2009)은 unit tests, service tests, UI tests의 세 층을 두고, 컴포넌트 테스트, 컴포넌트 통합 테스트, 끝에서 끝까지의 테스트를 두는 모델도 널리 쓰인다.[5]
도구와 리스크
이 강의계획서는 테스트를 지원하는 도구의 예로 다음을 든다.[5]
- 테스트 관리 도구
- 리뷰와 정적 분석을 돕는 정적 테스트 도구
- 테스트 케이스, 테스트 데이터, 테스트 절차를 만드는 테스트 설계·구현 도구
- 테스트 실행을 자동화하고 커버리지를 재는 테스트 실행·커버리지 도구
- 손으로 하기 어렵거나 할 수 없는 비기능 테스트를 하는 도구
- 전달 파이프라인과 자동화한 빌드를 지원하는 DevOps 도구
- 협업 도구, 가상 머신과 컨테이너 같은 확장과 배포 표준화를 돕는 도구[5]
이 강의계획서에 따르면 도구를 들이는 것만으로 성공이 보장되지 않고, 도구마다 도입, 유지보수, 교육에 노력이 든다. 테스트 자동화의 리스크로는 도구의 이점에 대한 비현실적인 기대, 도구 도입과 스크립트 유지보수에 드는 시간과 비용을 잘못 어림하는 것, 수동 테스트가 더 알맞은 곳에 도구를 쓰는 것, 사람의 비판적 사고를 제쳐 두고 도구에 지나치게 기대는 것, 도구 벤더나 버려진 오픈소스 소프트웨어에 매이는 것, 개발 플랫폼과 맞지 않는 도구, 규제 요구사항이나 안전 표준을 따르지 않는 도구를 고르는 것을 든다.[5]