'The Practical Test Pyramid' 번역본 아티클 내용을 읽고 기억하고싶은 내용들.
Spring Boot 기반 REST API를 사용한 샘플 프로젝트를 사용하여 테스트 피라미드의 각 계층에서 테스트 방법등을 설명해주었다
테스트 피라미드란?
다양한 테스트 계층을 생각하도록 돕는 시각적 은유
테스트 피라미드 왜 필요한가?
소프트웨어가 빠르게 발전하면서 제품을 제공하는 시기도 빨라졌다.
소프트웨어가 배포하기 위해선 테스트가 필요하다.
따라서 테스트 활동도 효율적인 방법을 모색하고, 테스트 자동화가 중요하게 된 현 시점이다.
자동화된 테스트의 핵심개념으로 테스트 피라미드가 사용되어 진다.
테스트 피라미드의 본질 두가지.
- 다양한 테스트를 작성하는것.
- 상위계층 일수록 테스트 비율이 적어지는것.

통합테스트 (Integration Test)
다른부분(데이터베이스, 파일시스템, 다른 앱에 네트워크호출 )과 상호작용하는 테스트를 진행해야하는데,
외부 종속성을 로컬에서 실행하는것을 목표로함.
자동화된 테스트에서 실제 프로덕션과 통합해서 테스트 하지말것.
* 별도 서비스와 통합
외부 서비스와 독립적으로 실행할것.
Wiremock과 같은 도구를 사용하여 가짜 서버구성 가능하여 API 테스트
Contract 테스트
그동안 인터페이스 사양을 작성하고, 정의된 인터페이스에 따라 구현이 완료되고 테스트 후 사용했었다면,
소비자 주도 계약 테스트 (CDC, Consumer-Driven Contract tests)를 사용하면 소비자가 계약의 구현을 주도할수 있다.
CDC 접근 방식의 프로세스 사례 :
- 소비 팀이 모든 소비자의 기대치를 반영하여 자동화된 테스트를 작성합니다.
- 소비 팀은 제공 팀을 위해 테스트를 게시합니다.
- 제공 팀은 CDC 테스트를 지속적으로 실행하고 녹색으로 유지합니다.
- CDC 테스트가 중단되면 두 팀이 서로 대화합니다.
조직에서 마이크로 서비스 접근 방식을 채택하는 경우, CDC 테스트는 자율적인 팀을 구축하는 데 큰 도움이 된다.
CDC 테스트는 팀 커뮤니케이션을 촉진하는 자동화된 방법이다.
팀 간의 인터페이스가 언제든지 작동하는지 확인할 수 있다.
CDC 테스트에 실패하면 해당 팀에 가서 예정된 API 변경 사항에 대해 대화를 나누고 앞으로 어떻게 진행할지 결정해야 한다는 좋은 지표가 될수있다.
* Pact (CDC 테스트 교환 지원 서비스)
= 컨트랙트 테스트를 사용하여 HTTP 및 메시지 통합을 테스트하기 위한 코드 우선 도구
UI 테스트
사용자 인터페이스 테스트가 반드시 end-to-end 방식으로 수행될 필요는 없다.
REST API나 command line 인터페이스로도 사용할수 있다.
자동화된 테스트 영역을 벗어나 테스터의 경험적 기반으로 다양하게 테스트 할수있는 영역
End-to-End 테스트
소프트웨어의 작동 여부를 결정할때 가장 큰 확신을 준다.
하지만 고유한 문제가 있다. 예측할수 없는 이유로 실패하는것으로 악명이 높다.
브라우저의 결함, 타이밍 문제, 애니메이션, 예기치 않은 팝업 대화 상자 등은 디버깅에 많은 시간을 할애하게 만든다.
또한 end-to-end 테스트는 많은 유지관리가 필요하고 실행속도가 매우 느리다.
따라서 제품의 핵심가치를 정의하는 사용자 여정을 생각해 내고 이러한 사용자 여정의 가장 중요한 단계를 자동화된 end-to-end 테스트로 전환하는것을 권고한다.
테스트 중복 피하기
프로덕션 코드와 마찬가지로 단순성을 추구하고 중복을 피하기 위해 노력해야 한다.
테스트 피라미드를 구현 할때, 두가지 경험 법칙을 염두에 두어야 한다.
- 상위 수준 테스트에서 오류를 발견했지만 실패한 하위 수준 테스트가 없는 경우 하위 수준 테스트를 작성해야 한다.
- 테스트를 테스트 피라미드에서 가능한 한 아래로 밀어 넣어라.
하위 수준 테스트에서 이미 다루고 있는 모든 조건부 로직과 에지 케이스를 상위 수준 테스트에서 다시 테스트하지는 않는다.
상위 수준 테스트가 하위 수준 테스트에서 다루지 못한 부분에 초점을 맞추도록 해라.
마이크로서비스 환경, IoT 디바이스, 모바일 앱 또는 웹 어플리케이션 등 어떤 환경에서 작업하든 이 글에서 교훈은 모두 적용될수 있다.
참고
https://www.integer.blog/practical-test-pyramid/
https://martinfowler.com/articles/practical-test-pyramid.html
'2024 > QA' 카테고리의 다른 글
[QA] 테스트 자동화 환경 구축하기 docker, jenkins (1) | 2024.08.16 |
---|---|
[Appium] 디렉토리 구조 개선과 시나리오간 의존성 이슈 고민 (0) | 2024.08.07 |
[트러블슈팅] Appium 드라이버 초기화 이슈 (0) | 2024.08.03 |
[트러블슈팅] Appium 프로젝트명 변경시, 독립된 가상환경 이슈 (0) | 2024.08.03 |
[QA]ISTQB FL 자격증 후기 / Syllabus 4.0 개편버전 (0) | 2024.07.01 |
'The Practical Test Pyramid' 번역본 아티클 내용을 읽고 기억하고싶은 내용들.
Spring Boot 기반 REST API를 사용한 샘플 프로젝트를 사용하여 테스트 피라미드의 각 계층에서 테스트 방법등을 설명해주었다
테스트 피라미드란?
다양한 테스트 계층을 생각하도록 돕는 시각적 은유
테스트 피라미드 왜 필요한가?
소프트웨어가 빠르게 발전하면서 제품을 제공하는 시기도 빨라졌다.
소프트웨어가 배포하기 위해선 테스트가 필요하다.
따라서 테스트 활동도 효율적인 방법을 모색하고, 테스트 자동화가 중요하게 된 현 시점이다.
자동화된 테스트의 핵심개념으로 테스트 피라미드가 사용되어 진다.
테스트 피라미드의 본질 두가지.
- 다양한 테스트를 작성하는것.
- 상위계층 일수록 테스트 비율이 적어지는것.

통합테스트 (Integration Test)
다른부분(데이터베이스, 파일시스템, 다른 앱에 네트워크호출 )과 상호작용하는 테스트를 진행해야하는데,
외부 종속성을 로컬에서 실행하는것을 목표로함.
자동화된 테스트에서 실제 프로덕션과 통합해서 테스트 하지말것.
* 별도 서비스와 통합
외부 서비스와 독립적으로 실행할것.
Wiremock과 같은 도구를 사용하여 가짜 서버구성 가능하여 API 테스트
Contract 테스트
그동안 인터페이스 사양을 작성하고, 정의된 인터페이스에 따라 구현이 완료되고 테스트 후 사용했었다면,
소비자 주도 계약 테스트 (CDC, Consumer-Driven Contract tests)를 사용하면 소비자가 계약의 구현을 주도할수 있다.
CDC 접근 방식의 프로세스 사례 :
- 소비 팀이 모든 소비자의 기대치를 반영하여 자동화된 테스트를 작성합니다.
- 소비 팀은 제공 팀을 위해 테스트를 게시합니다.
- 제공 팀은 CDC 테스트를 지속적으로 실행하고 녹색으로 유지합니다.
- CDC 테스트가 중단되면 두 팀이 서로 대화합니다.
조직에서 마이크로 서비스 접근 방식을 채택하는 경우, CDC 테스트는 자율적인 팀을 구축하는 데 큰 도움이 된다.
CDC 테스트는 팀 커뮤니케이션을 촉진하는 자동화된 방법이다.
팀 간의 인터페이스가 언제든지 작동하는지 확인할 수 있다.
CDC 테스트에 실패하면 해당 팀에 가서 예정된 API 변경 사항에 대해 대화를 나누고 앞으로 어떻게 진행할지 결정해야 한다는 좋은 지표가 될수있다.
* Pact (CDC 테스트 교환 지원 서비스)
= 컨트랙트 테스트를 사용하여 HTTP 및 메시지 통합을 테스트하기 위한 코드 우선 도구
UI 테스트
사용자 인터페이스 테스트가 반드시 end-to-end 방식으로 수행될 필요는 없다.
REST API나 command line 인터페이스로도 사용할수 있다.
자동화된 테스트 영역을 벗어나 테스터의 경험적 기반으로 다양하게 테스트 할수있는 영역
End-to-End 테스트
소프트웨어의 작동 여부를 결정할때 가장 큰 확신을 준다.
하지만 고유한 문제가 있다. 예측할수 없는 이유로 실패하는것으로 악명이 높다.
브라우저의 결함, 타이밍 문제, 애니메이션, 예기치 않은 팝업 대화 상자 등은 디버깅에 많은 시간을 할애하게 만든다.
또한 end-to-end 테스트는 많은 유지관리가 필요하고 실행속도가 매우 느리다.
따라서 제품의 핵심가치를 정의하는 사용자 여정을 생각해 내고 이러한 사용자 여정의 가장 중요한 단계를 자동화된 end-to-end 테스트로 전환하는것을 권고한다.
테스트 중복 피하기
프로덕션 코드와 마찬가지로 단순성을 추구하고 중복을 피하기 위해 노력해야 한다.
테스트 피라미드를 구현 할때, 두가지 경험 법칙을 염두에 두어야 한다.
- 상위 수준 테스트에서 오류를 발견했지만 실패한 하위 수준 테스트가 없는 경우 하위 수준 테스트를 작성해야 한다.
- 테스트를 테스트 피라미드에서 가능한 한 아래로 밀어 넣어라.
하위 수준 테스트에서 이미 다루고 있는 모든 조건부 로직과 에지 케이스를 상위 수준 테스트에서 다시 테스트하지는 않는다.
상위 수준 테스트가 하위 수준 테스트에서 다루지 못한 부분에 초점을 맞추도록 해라.
마이크로서비스 환경, IoT 디바이스, 모바일 앱 또는 웹 어플리케이션 등 어떤 환경에서 작업하든 이 글에서 교훈은 모두 적용될수 있다.
참고
https://www.integer.blog/practical-test-pyramid/
https://martinfowler.com/articles/practical-test-pyramid.html
'2024 > QA' 카테고리의 다른 글
[QA] 테스트 자동화 환경 구축하기 docker, jenkins (1) | 2024.08.16 |
---|---|
[Appium] 디렉토리 구조 개선과 시나리오간 의존성 이슈 고민 (0) | 2024.08.07 |
[트러블슈팅] Appium 드라이버 초기화 이슈 (0) | 2024.08.03 |
[트러블슈팅] Appium 프로젝트명 변경시, 독립된 가상환경 이슈 (0) | 2024.08.03 |
[QA]ISTQB FL 자격증 후기 / Syllabus 4.0 개편버전 (0) | 2024.07.01 |