QA와 테스트

만든 것이 의도대로 도는지 확인하는 일이 모여 있는 자리입니다. 사람이 직접 써 보며 확인합니다. 확인을 코드로 짜 두고 기계가 되풀이해 돌리게도 합니다. 그 확인이 제때 일어나게 만드는 일도 여기서 마주칩니다.

상세

표제어의 두 낱말은 표준 용어집에서 각각 따로 정의됩니다. 테스팅은 대상을 동작시켜 보는 활동입니다. 품질 보증은 요구사항이 충족된다는 확신을 주는 프로세스입니다.

ISO/IEC/IEEE 29119-2 는 테스팅을 하나 이상의 테스트 대상이 가진 속성을 발견하거나 평가하기 쉽게 하려고 수행하는 활동의 집합이라고 정의합니다. ISO/IEC 25051 은 같은 것을 다르게 적습니다. 정해진 조건에서 시스템이나 구성요소를 동작시키고 결과를 관찰하거나 기록해 어떤 측면을 평가하는 과정입니다. 용어집은 테스팅 활동에 계획·준비·실행·보고·관리가 들어간다고 덧붙입니다. 그것들이 테스팅을 향한 것인 한에서 그렇습니다.

품질 보증(QA, Quality Assurance)은 실행이 아니라 확신 쪽에 서 있습니다. ISO/IEC/IEEE 12207 은 품질 보증을 품질 요구사항이 충족된다는 확신을 제공하는 데 초점을 둔 프로세스라고 정의합니다. ISO/IEC/IEEE 15288 은 그것을 품질 관리의 한 부분이라고 적습니다. 용어집은 목적이 안팎으로 둘이라고 덧붙입니다. 조직 안에서는 경영진에게 확신을 줍니다. 계약 상황에서는 고객이나 다른 이들에게 확신을 줍니다. 품질에 대한 요구사항이 사용자의 필요를 온전히 반영하지 않는 한, 품질 보증이 반드시 충분한 확신을 주지는 않는다고 못 박습니다.

	테스팅	품질 보증
정의를 둔 표준	ISO/IEC/IEEE 29119-2 · ISO/IEC 25051	ISO/IEC/IEEE 12207 · ISO/IEC/IEEE 15288
초점	대상을 동작시키고 결과를 관찰해 평가하는 활동	품질 요구사항이 충족된다는 확신을 제공하는 것
딸린 것	계획 · 준비 · 실행 · 보고 · 관리	품질 관리의 한 부분

자동으로 도는 검사 하나는 단순합니다. Google 은 가장 단순한 테스트가 넷으로 정의된다고 적습니다. 검사하려는 동작 하나, 그 API(Application Programming Interface, 응용 프로그램 인터페이스)에 넘기는 특정 입력, 관찰할 수 있는 출력이나 동작, 단일 격리 프로세스 같은 통제된 환경입니다. 입력을 넘기고 출력을 확인하면 시스템이 기대대로 도는지 알게 됩니다. 이런 단순한 검사 수백 수천 개를 한데 모은 것을 대개 테스트 스위트라고 부릅니다. 제품 전체가 의도한 설계에 얼마나 들어맞는지, 그리고 더 중요하게는 언제 안 맞는지를 알려 줍니다.

검사 한 벌의 안쪽도 단계로 나뉩니다. pytest 문서는 테스트 하나를 준비·실행·확인·정리 네 단계로 쪼개 볼 수 있다고 적습니다. 실행 단계가 검사 대상 시스템(SUT, System Under Test)의 상태를 바꿉니다.

flowchart TD
    A[준비] --> B[실행]
    B --> C[확인]
    C --> D[정리]

누가 검사를 쓰는지는 정의 안에 열려 있습니다. ISO/IEC TR 7052 는 단위 테스트를 개별 루틴과 모듈을 개발자나 독립 시험자가 검사하는 것이라고 정의합니다. 만드는 사람과 따로 있는 시험자가 정의 문장 안에 함께 들어 있습니다.

그래서 이 표제어는 한 문장으로 닫히지 않습니다. 무엇을 어느 크기로 검사할지, 무엇을 가짜로 바꿔 끼울지, 얼마나 덮었는지 어떻게 셀지, 언제 어디서 돌릴지가 각각 따로 이름을 갖습니다. 이 자리에서는 그 이름들을 목록으로 마주칩니다.

경계

배포된 뒤 프로덕션에서 하는 확인

프로덕션 환경에 실제로 요청을 던져 보는 프로버도 이 구역인가. 맞습니다. Google 은 프로버를 프로덕션 환경에 대해 인코딩된 단언을 실행하는 기능 테스트라고 적습니다. 검사 대상 시스템이 프로덕션입니다. 데이터도 프로덕션입니다. 검증은 단언과 지표의 A/B diff 비교입니다. 카나리아 분석도 비슷합니다. 다만 릴리스가 프로덕션으로 밀려 나가는 시점에 초점을 둔다고 적습니다.

같은 문서가 곧바로 덧붙입니다. 이것들은 프로덕션 환경 자체가 건강한지 확인하는 방법입니다. 그 점에서는 프로덕션 모니터링의 한 형태이지만, 구조적으로는 다른 큰 테스트와 매우 비슷하다는 것입니다. 이웃 쪽은 스스로를 다르게 정의합니다. OpenTelemetry 문서는 관측성을 시스템의 내부 동작을 몰라도 밖에서 그 시스템에 질문을 던져 이해하게 해 주는 것이라고 적습니다. 미리 적어 둔 단언을 돌려 통과와 실패를 가르면 이 구역입니다. 미리 정하지 않은 질문을 나중에 던지려고 데이터를 남기면 그쪽 구역입니다.

검사를 돌려 주는 파이프라인

검사를 자동으로 돌려 주는 파이프라인을 세우는 일도 이 구역인가. 아닙니다. IEEE 2675 는 지속적 통합(CI, Continuous Integration)을 팀의 모든 개발자가 낸 소스 코드 갱신을 포함한 산출물을 공유 메인라인으로 계속 병합해 개발 중인 시스템을 빌드하고 테스트하는 기법이라고 정의합니다. 병합과 빌드가 정의 문장 안에 함께 들어 있습니다. Martin Fowler 도 지속적 통합을 팀 구성원 각자가 최소 하루 한 번 자기 변경을 동료의 변경과 함께 코드베이스에 병합하는 개발 관행이라고 적습니다. 그 통합 각각이 테스트를 포함한 자동화된 빌드로 검증된다고 이어 적습니다.

검사는 그 파이프라인이 실행하는 대상입니다. 파이프라인 쪽은 병합과 빌드까지 함께 맡으므로 이 구역 하나에 담기지 않습니다. 두 자리는 대신 서로를 통해 만납니다. pytest 문서는 불안정한 테스트가 지속적 통합 서버를 쓸 때 특히 성가시다고 적습니다. 새 코드 변경이 병합되려면 모든 테스트가 통과해야 하기 때문입니다. 테스트 결과가 믿을 만한 신호가 아니면 개발자들이 그 결과를 불신하게 될 수 있다고 덧붙입니다.

이견

이 구역을 어떤 축으로 나누고 어디에 무게를 둘지가 사람마다 다릅니다.

테스트 피라미드는 Mike Cohn 이 2009년 책 Succeeding with Agile 에서 기술했습니다. Martin Fowler 가 자기 bliki 에 그것을 정리했습니다. Fowler 는 피라미드를 여러 종류의 자동화된 테스트를 어떻게 써서 균형 잡힌 포트폴리오를 만들지 생각하는 방법이라고 적습니다. 요점은 그래픽 사용자 인터페이스를 지나는 상위 수준의 넓은 스택 테스트보다 하위 수준의 단위 테스트를 훨씬 많이 두라는 것입니다. 근거로 사용자 인터페이스를 지나는 테스트가 빌드 시간을 늘린다는 점을 듭니다. 무엇보다 그런 테스트는 매우 부서지기 쉽다고 적습니다.

Kent C. Dodds 는 2019년 글에서 여기에 명시적으로 답합니다. Guillermo Rauch 의 트윗 "Write tests. Not too many. Mostly integration." 을 인용해 글을 엽니다. 도구가 Martin 의 원래 테스팅 피라미드 개념이 깔고 있던 전제를 이미 넘어섰다고 적습니다. 그래서 피라미드에 작별하고 트로피를 든다고 적습니다. 테스팅 트로피는 여러 형태의 테스팅이 갖는 투자 대비 회수에 대한 일반적인 안내입니다. 종단 간과 통합과 단위와 정적을 각각의 자리에 둡니다.

Google 은 아예 다른 축을 씁니다. 자기네 책은 모든 테스트를 크기로 분류한다고 적습니다. 주어진 기능에 대해 언제나 가능한 한 작은 테스트를 쓰도록 엔지니어에게 권한다고 적습니다. 크기는 코드 줄 수가 아니라 어떻게 도는지, 무엇을 하도록 허용되는지, 자원을 얼마나 쓰는지로 정해집니다. 작은 테스트는 단일 프로세스에서 돕니다. 중간 테스트는 단일 머신에서 돕니다. 큰 테스트는 원하는 어디서나 돕니다. 전통적인 단위나 통합 대신 이렇게 가르는 이유도 스스로 적습니다. 테스트 스위트에서 가장 중요하게 보는 성질이 범위와 무관하게 속도와 결정성이기 때문입니다.

범위는 같은 책이 따로 셉니다. 좁은 범위 테스트를 흔히 단위 테스트라 부릅니다. 중간 범위 테스트를 흔히 통합 테스트라 부릅니다. 넓은 범위 테스트는 기능 테스트나 종단 간 테스트나 시스템 테스트 같은 이름으로 불린다고 적습니다.

어느 쪽이 맞는지는 여기서 판정하지 않습니다. 같은 구역을 한쪽은 자동화 테스트의 종류별 개수로 나눕니다. 다른 쪽은 도구가 바뀐 뒤의 투자 대비 회수로 나눕니다. 또 다른 쪽은 종류 대신 크기로 나눕니다.

QA와 테스트

상세

경계

배포된 뒤 프로덕션에서 하는 확인

검사를 돌려 주는 파이프라인

이견

관련 항목

크기와 범위로 가르는 테스트의 하위 종류

테스트 한 벌을 이루는 구성 요소

테스트 하나가 거치는 단계와 판정 기준

테스트가 도는 환경과 그 성질

실제 의존성을 대신하는 대역

덮은 범위를 재는 지표

검사를 자동으로 돌리는 파이프라인

배포된 뒤 프로덕션에서 도는 검사

사람이 직접 진행하는 검사

부하를 걸어 성능을 재는 테스트

테스트에서 자주 나는 오류·장애

이 구역을 가르는 서로 다른 모델

이름이 헷갈리는 이웃 개념

실제로 쓰는 도구

이 구역을 놓고 글을 쓴 사람과 조직

정의를 두는 표준 문서