2.4 테스트 전략

개요와 동기

테스트 전략은 팀이 코드를 깨뜨리지 않고 빠르게 바꿀 수 있도록, 무엇을, 어느 수준에서, 얼마나 자동으로, 어느 정도 확신으로 테스트할지에 대한 의도적 선택의 집합입니다. 테스트는 큰 조직이 자주, 안전하게 배포할 수 있게 해 주는 것입니다. 기대되는 동작을 부호화하고, 회귀를 잡아내고, 엔지니어에게 리팩터링할 확신을 줍니다. 일관된 전략이 없으면 테스트는 두 가지 나쁜 쪽 중 하나로 흐르기 쉽습니다. 없거나(두려움에 이끌린 느린 개발), 부풀거나(아무도 신뢰하지 않는 수천 개의 느리고 불안정한 테스트)입니다.

큰 팀에서는 어떤 단일 테스트보다 전략이 더 중요합니다. 공유 코드베이스에서 일하는 수백 명의 엔지니어에게는 빠르고 신뢰할 수 있는 안전망이 필요합니다. 그것이 없으면 모든 변경이 위험하고 모든 릴리스가 수동의 시련이 됩니다. 테스트는 의도된 동작의 실행 가능한 문서이기도 하며, 이는 원 작성자가 떠난 뒤 값을 매길 수 없습니다. 전략이 테스트 스위트가 전달을 가속하는 자산인지 늦추는 부채인지를 결정합니다.

기업과 정부 맥락에서 테스트는 추가적인 무게를 집니다. 규제가 문서화된 테스트 커버리지와 증거를 요구할 수 있습니다. 안전이 핵심이거나 시민 대면 시스템은 높은 보증을 요구합니다. 접근성과 보안 테스트가 법적으로 요구될 수 있습니다. 그래서 전략은 속도, 확신, 비용, 컴플라이언스의 균형을 잡아야 하며, 커버리지를 조작될 목표가 아니라 신호로 다뤄야 합니다.

핵심 원칙

숫자를 맞추려는 것이 아니라 변경할 확신을 얻으려고 테스트하십시오.
빠르고, 신뢰할 수 있고, 격리된 테스트를 선호하십시오. 느리거나 불안정한 테스트는 스위트를 유용하게 만드는 신뢰를 갉아먹습니다.
테스트를 진짜 확신을 주는 가장 낮은 수준으로 내리고, 느리고 넓은 테스트는 진정한 통합 위험에 남겨 두십시오.
불안정한 테스트는 깨진 테스트입니다. 불안정성을 일급 결함으로 다루십시오.
커버리지는 신호이지 목표가 아닙니다. 사소한 코드의 높은 커버리지는 거의 아무것도 증명하지 않습니다.
테스트가 리팩터링을 견디도록 구현 세부가 아니라 동작과 계약을 테스트하십시오.
비기능 테스트(접근성, 성능, 보안)를 사후 생각이 아니라 전략의 일부로 만드십시오.

권장 사항

테스트 피라미드를 기본으로 쓰되, 그 비판도 안다

범위가 커질수록 비용과 취약성이 오르므로, 많은 빠른 단위 테스트, 더 적은 통합 테스트, 소수의 종단 간 테스트를 기본으로 하십시오. 비판도 아십시오. 모양은 교조가 아니라 아키텍처를 따라야 합니다. 서비스가 많은 시스템은 더 큰 통합 계층(“테스팅 트로피”)이 필요할 수 있고, 진짜 목표는 특정한 실루엣이 아니라 비용과 속도 단위당 확신입니다. 무엇을 하든, 대부분 느린 종단 간 테스트로 이루어진 뒤집힌 피라미드는 피하십시오.

TDD, BDD, 명세 주도 개발을 도움이 되는 곳에 채택한다

특히 복잡한 로직에서 설계를 이끌고 테스트 용이성을 보장하는 데 테스트 주도 개발(TDD)을 쓰십시오. 이는 테스트 규율만큼이나 설계 규율입니다. 이해관계자와 공유하는 도메인 언어로 테스트를 표현하는 데 행위 주도 개발(BDD)을 쓰십시오. 규제나 요구사항이 많은 환경의 인수 기준에 값집니다. 명세 주도 개발은 한 걸음 더 나아가, 실행 가능한 명세(예시로 표현된 합의된 동작)를 구현을 이끌고 검증하는 단일 진실의 원천으로 다룹니다. 이는 정부와 규제 프로그램처럼 요구사항이 인수 증거까지 추적 가능해야 하는 곳에서 빛납니다. 셋 모두와 관련된 것이 시프트 레프트 테스트입니다. 검증을 수명주기에서 가능한 한 일찍 옮겨, 코드와 함께 또는 코드에 앞서 테스트를 쓰고 지속적으로 실행하여, 늦은 테스트 단계나 프로덕션이 아니라 고치는 비용이 가장 쌀 때 결함을 잡는 것입니다. 이 중 어느 것도 어디서나 필수는 아닙니다. 명확성을 더하는 곳에 적용하십시오.

가치가 높은 코드에는 고급 기법을 쓴다

예시 기반 테스트가 놓치는 엣지 케이스를 잡도록, 많은 생성된 입력에 걸쳐 불변식을 확인하는 속성 기반 테스트를 쓰십시오. 크래시와 보안 결함을 찾도록 파서와 신뢰할 수 없는 입력 경계에 퍼즈 테스트를 쓰십시오. 테스트가 주입된 결함을 실제로 탐지하는지 측정하는 변이 테스트를 쓰십시오. 원시 커버리지보다 훨씬 나은 품질 신호입니다. 직렬화된 출력에는 스냅샷 테스트를 신중히 쓰고, 스냅샷을 맹목적으로 재승인하는 함정을 조심하십시오.

테스트 데이터를 관리하고 합성 데이터를 쓴다

통제되고 격리된 테스트 데이터로 테스트를 결정적으로 만들고, 테스트를 서로 결합시키는 공유 가변 픽스처를 피하십시오. 실제 개인 정보를 노출하지 않으면서 프로덕션의 특성을 반영하는 합성 데이터를 생성하십시오. 프라이버시 규칙이 테스트 환경에서 프로덕션 데이터 사용을 금지하는 곳에서는 필수입니다. 각 테스트가 필요한 데이터를 정확히 구성할 수 있도록 팩토리나 빌더를 제공하십시오.

불안정한 테스트를 결함으로 다룬다

불안정성을 자동으로 탐지하고, 불안정한 테스트를 차단 경로에서 빼고, 기한을 두고 고치거나 삭제하십시오. 무작위로 실패하는 스위트는 엔지니어에게 실패를 무시하도록 가르쳐 그 모든 가치를 파괴합니다. 불안정 비율을 추적하고 신뢰성을 테스트 스위트 자체의 명시적 품질 지표로 만드십시오.

커버리지를 신호로 쓰고 비기능 테스트를 더한다

테스트되지 않은 영역을 찾는 데 커버리지를 측정하되, 단언 없는 테스트로 조작을 부르는 엄격한 목표로 바꾸지 마십시오. 깊이를 위해 변이 테스트로 보완하십시오. 접근성 테스트(자동 검사와 수동 감사), 성능 테스트(회귀 탐지를 갖춘 부하 및 지연 기준선), 보안 테스트(의존성 스캔, 정적 분석, 동적 테스트)를 파이프라인에 구축하십시오.

장단점

테스트 유형 / 관행	장점	단점
단위 테스트	빠르고, 정밀하고, 싸고, 안정적	통합과 시스템 수준 버그를 놓침
통합 테스트	인터페이스와 연결 결함을 잡음	더 느림. 설정이 더 많음. 더 취약
종단 간 테스트	실제 동작에 대한 가장 높은 확신	느리고, 불안정하고, 유지가 비쌈
TDD	더 나은 설계, 보장된 테스트 용이성	학습 곡선. 처음에는 느리게 느껴짐
속성 기반 테스트	엣지 케이스를 찾음. 불변식을 부호화	속성으로 생각해야 함. 쓰기 더 어려움
변이 테스트	테스트 효과성의 진짜 척도	계산 비용이 큼. 실행이 느림
높은 커버리지 목표	테스트되지 않은 코드를 드러냄	조작 가능. 가치 낮은 테스트를 유인할 수 있음

핵심 트레이드오프는 확신 대 속도와 비용입니다. 더 넓은 테스트는 더 많은 확신을 주지만 더 느리게 돌고 더 자주 깨집니다. 더 좁은 테스트는 빠르고 안정적이지만 시스템 수준 결함을 놓칩니다. 알맞은 혼합은 피드백 1초당, 유지보수 1시간당 확신을 극대화합니다. 그리고 과테스트는 실제 실패 양상입니다. 중복되고, 느리고, 취약한 테스트로 부푼 스위트는 막아 주는 버그보다 비용이 더 들 수 있습니다.

팀과 논의할 질문

접근성, 성능, 보안 같은 비기능 테스트 중 어느 것이 릴리스를 막아야 하고, 어느 것이 보고만 해야 합니까? 이 장은 비기능 테스트가 사후 생각이 아니라 전략에 속한다고 주장하며, 접근성은 법적으로 요구될 수 있고 보안 테스트는 운영 허가 증거의 일부일 수 있다고 지적합니다. 크거나 시민 대면 시스템에서 차단 관문은 전달을 늦추지만, 프로덕션에서 발견된 접근성이나 보안 결함은 테스트 비용을 압도하는 시정, 평판, 법적 비용을 집니다. 결정하는 신호를 가져오십시오. 규제 노출, 시스템이 시민 대면인지, 이런 결함이 현재 얼마나 자주 프로덕션으로 빠져나가는지입니다. 법적으로 요구되는 검사는 차단하게 하고 위험이 낮은 검사는 추세와 함께 보고하게 하여, 관문이 교조가 아니라 실제 위험을 반영하게 하십시오. 답은 무엇이 병합될 수 있고 없는지를 직접 정합니다.
관문으로서 엄격한 커버리지 비율을 설정합니까, 그렇다면 무엇이 엔지니어가 단언 없는 테스트로 이를 조작하지 못하게 합니까? 이 장은 커버리지가 신호이지 목표가 아니며, 사소한 코드의 높은 커버리지는 거의 증명하지 않고, 엄격한 목표는 조작을 부른다고 단호합니다. 큰 조직에 부과된 단일 숫자는 아무것도 단언하지 않고 코드를 실행하는 테스트를 꾸준히 만들어 내며, 이는 지표를 올리고 진짜 확신을 낮춥니다. 더 나은 신호를 논의에 가져오십시오. 가장 가치 높은 모듈의 변이 테스트 점수는 테스트가 주입된 결함을 실제로 탐지하는지 측정합니다. 테스트되지 않은 영역을 찾는 데 커버리지를, 깊이를 위해 변이 테스트를 쓰고, 어느 쪽이든 리더십이 단독으로 추적하는 목표로 바꾸려는 데 저항하십시오. 숫자가 어디서 정말 도움이 되고 어디서 연극만 부르는지 결정하십시오.
테스트 스위트가 엔지니어가 기다리기엔 너무 느려졌을 때의 정책은 무엇입니까? 이 장의 핵심 트레이드오프는 확신 대 속도와 비용이며, 과테스트를 중복되고 느린 부푼 스위트가 막아 주는 버그보다 비용이 더 드는 실제 실패 양상으로 이름 붙입니다. 큰 팀에서 스위트 실행 시간은 모든 변경에 치르는 공유 세금이고, 사람들이 우회하게 된 스위트는 모든 가치를 잃습니다. 증거를 가져오십시오. CI 벽시계 시간, 가장 느린 테스트, 더 싼 단위 테스트와 중복되는 종단 간 커버리지가 얼마나 되는지입니다. 테스트를 진짜 확신을 주는 가장 낮은 수준으로 내리고, 병렬화하고, 중복된 느린 테스트는 기한을 두고 삭제하십시오. 목표는 원시 테스트 수가 아니라 피드백 1초당 확신의 최적화입니다.
테스트가 불안정해지면 누가 소유하고, 얼마나 빨리 고치거나 삭제해야 하며, 무엇이 그 기한을 시행합니까? 이 장은 불안정한 테스트를 깨진 테스트, 즉 일급 결함으로 다룹니다. 무작위로 실패하는 스위트는 큰 팀에게 빨간 빌드를 무시하도록 가르치고 모두가 의존하는 안전망을 조용히 파괴하기 때문입니다. 상충하는 압력은 실제입니다. 불안정한 테스트를 격리하면 오늘 전달이 풀리지만 진짜 간헐적 버그를 가릴 위험이 있고, 그것에 막히면 순수한 잡음일 수 있는 실패 때문에 수백 명의 엔지니어가 멈춥니다. 이를 결정짓는 증거를 가져오십시오. 현재의 불안정 비율, 누가 건드리기 전까지 테스트가 격리된 채 있는 기간, 격리된 테스트 중 진짜 결함을 가리고 있던 것이 몇 개인지입니다. 격리된 모든 테스트에 소유자를 배정하고, 고치거나 삭제하는 확고한 기한을 정하고, 신뢰성을 스위트 자체의 명시적 지표로 추적하십시오. 초록 빌드가 릴리스 증거의 일부인 기업과 정부 환경에서, 관리되지 않는 격리 더미는 감사 부채이기도 합니다. 불신하기로 사적으로 합의한 신호 위에서 출시하고 있기 때문입니다.
테스트 환경에서 프로덕션 데이터 사용이 허용됩니까, 그렇지 않다면 실제 결함을 잡을 만큼 충실한 합성 데이터를 어떻게 생성합니까? 이 장은 프라이버시 규칙이 테스트에서 실제 개인 데이터를 금지하는 경우가 많으며, 합성 데이터가 프로덕션의 특성을 반영해야 테스트가 거짓 확신을 주지 않는다고 직접 말합니다. 큰 조직에서 긴장은 충실도와 컴플라이언스 사이에 있습니다. 프로덕션 데이터는 합성 데이터가 놓치는 지저분한 엣지 케이스를 잡지만, 그 모든 사본이 노출과 의무를 곱합니다. 구체적 사항을 가져오십시오. 어느 데이터셋이 개인 또는 규제 대상 데이터를 담는지, 프라이버시와 데이터 거주 규칙이 실제로 무엇을 요구하는지, 현재 픽스처가 프로덕션에서 보이는 분포와 엣지 케이스를 얼마나 잘 재현하는지입니다. 각 테스트가 필요한 데이터를 정확히 구성하도록 팩토리나 빌더를 표준화하고, 실제 인구통계와 양의 분포에 맞는 합성 생성에 투자하십시오. 정부와 규제 프로그램에서 테스트 환경의 시민 데이터 사용은 지름길이 아니라 보고해야 하는 침해이므로, 첫 환경이 세워지기 전에 데이터 전략이 정해져야 합니다.
TDD, BDD, 명세 주도 개발이 선택이 아닌 기대되어야 하는 곳은 어디이며, 누가 결정합니까? 이 장은 이것들을 모든 코드 줄에 대한 의무가 아니라 명확성을 더하는 곳에 적용할 규율로 제시하지만, 큰 팀은 관행이 팀별로 갈라지지 않도록 공유 기본값의 덕을 봅니다. 트레이드오프는 설계와 추적성의 이점(정책 전문가가 검토할 수 있는 실행 가능한 명세, 리팩터링을 견디는 테스트)과, 일괄 의무를 역효과로 만드는 진짜 학습 곡선과 선행의 느림 사이에 있습니다. 범위를 정할 증거를 가져오십시오. 어느 모듈이 복잡한 로직이나 높은 변경 실패율을 지니는지, 인수 기준이 요구사항까지 추적 가능해야 하는 곳이 어디인지, 이미 이를 실천하는 팀이 속도와 결함률에 대해 어떻게 보고하는지입니다. 기대는 복잡한 로직과 요구사항이 많은 영역에 남겨 두고, 더 단순한 코드는 스스로 선택하게 하십시오. 소프트웨어가 구현하는 법까지 추적 가능해야 하는 규제 및 정부 프로그램에서, 실행 가능한 인수 증거를 갖춘 명세 주도 개발은 선호라기보다 운영 허가로 가는 길이므로, 어디에서 요구되는지 명시하십시오.

분야별 관점

스타트업. 작은 팀은 QA를 둘 수 없으니 스위트가 제 몫을 하게 하십시오. 모든 커밋에서의 빠른 단위 테스트와 생계를 책임지는 한 경로에 대한 몇 개의 종단 간 테스트, 그리고 유지하지 않을 것은 두지 마십시오. 커버리지 목표는 건너뛰고 가장 깨질까 두려운 로직을 테스트하여, 수동 회귀 점검 없이 하루에 여러 번 출시할 수 있게 하십시오. 불안정한 테스트는 같은 날 고치십시오. 이 단계에서 팀이 무시하게 되는 스위트는 스위트가 없는 것보다 나쁩니다.

소기업. 전담 테스트 엔지니어도 빠듯한 예산도 있으니, 지원할 수 없는 맞춤 하네스보다 이미 운영하는 프레임워크와 도구에 내장된 테스트에 의지하십시오. 수익과 고객 신뢰를 지키는 소수의 검사를 우선하고, 빌드 인프라를 직접 유지하지 않도록 호스팅 CI를 쓰십시오. 접근성과 보안 스캔은 만들기보다 서비스로 사는 쪽을 선호하십시오. 단 하나의 놓친 결함이 그 도구의 1년 치보다 더 들 수 있습니다.

대기업. 많은 팀에 걸쳐 전략 문제는 일관성입니다. 공유 피라미드 기본값, 자동 불안정 테스트 격리, 어디서나 같은 뜻인 비기능 관문으로, 누가 만들었든 초록 빌드를 신뢰할 수 있게 하십시오. CI 벽시계 시간은 모든 엔지니어가 모든 변경에 치르므로, 스위트 실행 시간을 공유 세금으로 예산 잡고 적극적으로 병렬화하십시오. 커버리지와 변이 점수를 리더십이 단독으로 추적하는 숫자가 아니라 분명한 소유권이 있는 포트폴리오 신호로 관리하십시오.

정부. 조달과 감독은 테스트를 단순한 엔지니어링 위생이 아닌 증거로 만듭니다. 자격과 정책 규칙을 도메인 전문가가 검토하는 실행 가능한 명세로 표현해 소프트웨어를 그것이 구현하는 법까지 추적할 수 있게 하고, 접근성과 보안 테스트는 법적으로 요구되고 운영 허가 증거의 일부이므로 차단하게 하십시오. 실제 분포에 맞춰 생성된 합성 데이터를 쓰십시오. 테스트 환경의 시민 데이터는 보고해야 하는 침해이기 때문입니다. 외부 검토자가 무엇이 검증되었는지 정확히 확인할 수 있도록 테스트 산출물을 감사 가능하게 유지하십시오.

사례

스타트업. 다섯 명 규모의 스타트업은 QA 팀을 둘 여유가 없어서, 모든 커밋에서 도는 빠른 단위 테스트 스위트와 생계를 책임지는 가입부터 결제까지의 경로를 다루는 몇 개의 종단 간 테스트에 의지합니다. 창업자들은 철저한 커버리지를 건너뛰고 대신 가장 깨질까 두려운 로직을 테스트하여, 수동 회귀 점검 없이 하루에 여러 번 출시합니다. 불안정한 테스트가 무작위로 실패하기 시작하면 같은 날 고칩니다. 신뢰가 전부인 단계에서 팀이 무시하게 되는 스위트는 스위트가 없는 것보다 나쁘기 때문입니다.

대기업. 한 대형 전자상거래 플랫폼은 모든 커밋에서 몇 분 만에 도는 수천 개의 빠른 단위 테스트, 결제와 재고 경계 주변의 집중된 통합 테스트 묶음, 핵심 결제 여정을 위한 작은 종단 간 테스트 스위트를 유지합니다. 불안정한 종단 간 테스트는 자동으로 격리되고 수리하도록 배정됩니다. 엔지니어들이 스위트를 신뢰하기 때문에, 빨간 빌드는 진짜 문제를 뜻한다고 확신하며 하루에 여러 번 배포합니다.

정부. 규제 감독 아래 운영되는 한 국가 급여 시스템은 BDD를 써서 자격 규칙을 정책 전문가가 검토하는 실행 가능한 명세로 표현하며, 이는 소프트웨어가 법을 구현한다는 추적 가능한 증거를 줍니다. 프라이버시 규칙이 테스트 환경의 시민 데이터를 금지하므로 실제 인구통계 분포에 맞춰 생성된 합성 데이터를 씁니다. 접근성 테스트는 필수이며 릴리스를 막습니다. 서비스는 모든 시민이 쓸 수 있어야 하기 때문입니다. 그리고 보안 테스트는 시스템을 프로덕션에서 운영하는 공식 승인인 운영 허가(ATO) 증거의 일부입니다.

비즈니스 사례: 동기, ROI, TCO

테스트의 수익은 소프트웨어를 빠르고 안전하게 바꿀 수 있다는 것이며, 이는 지속적인 전달 속도의 토대입니다. 신뢰할 수 있는 자동화된 스위트는 느리고 비싼 수동 회귀 테스트를 대체하고, 고치는 비용이 가장 쌀 때, 즉 프로덕션이 아닌 릴리스 전에 결함을 잡습니다. 규제 또는 시민 대면 시스템에서 프로덕션 결함의 비용(시정, 평판, 잠재적 법적 노출)은 그것을 잡았을 테스트의 비용을 압도합니다.

도입 비용은 실제입니다. 테스트를 쓰고 유지하며 지속적 통합(CI) 인프라를 구축합니다. 그러나 테스트하지 않는 비용이 더 크고 누적됩니다. 느려져 기어가는 두려움 중심의 개발, 빈번한 회귀, 확장되지 못하는 수동 릴리스 프로세스입니다. 과테스트에도 비용이 있으므로, 논거는 최대 테스트 수가 아니라 잘 설계된 전략에 있습니다. 리더십을 설득하려면 스위트를 배포 빈도, 변경 실패율, 평균 복구 시간에 연결하고, 그것이 대체하는 수동 테스트 노력과 막아 주는 프로덕션 인시던트를 정량화하십시오.

안티패턴과 함정

아이스크림 콘 테스트: 얇은 단위 기반 위에 대부분 느린 종단 간 테스트. 느리고, 불안정하고, 비쌉니다.
목표로서의 커버리지: 아무것도 증명하지 않는 단언 없는 또는 사소한 테스트로 비율을 쫓는 것.
구현 세부 테스트: 내부에 결합되어 모든 리팩터링에서 깨지고 변경을 낙담시키는 테스트.
용인되는 불안정성: 팀에게 빨간 빌드를 무시하도록 가르치는 무작위 실패.
공유 가변 테스트 데이터: 서로 간섭하고 예측할 수 없이 실패하는 테스트.
테스트에서 프로덕션 데이터 사용: 터지기를 기다리는 프라이버시와 컴플라이언스 침해.
건너뛴 비기능 테스트: 프로덕션에서야 발견되는 접근성, 성능, 보안.
신뢰받지 못하는 스위트: 엔지니어가 일상적으로 다시 실행하거나 우회할 만큼 신뢰할 수 없어 목적이 무효화되는 것.

성숙도 모델

1단계, 시작: 테스트는 수동이고 반응적입니다. 자동화된 커버리지가 최소이고, 회귀가 빈번하며 늦게 잡히고, 흔히 스위트가 아닌 사용자가 발견합니다.
2단계, 발전: 자동화된 단위 테스트와 일부 통합 테스트가 있지만 스위트가 느리거나 불안정하고, 신뢰가 낮으며, 관행은 팀마다 크게 다릅니다.
3단계, 표준화: 균형 잡히고, 빠르고, 신뢰할 수 있는 스위트가 모든 변경을 관문으로 통제합니다. 문서화된 피라미드 기본값, 불안정 테스트 정책, 비기능 테스트(접근성, 성능, 보안)가 팀 전반에서 일관되게 시행됩니다.
4단계, 관리: 스위트 건강이 기준선에 대해 측정되고 통제됩니다. 불안정 비율, CI 벽시계 시간, 가치 높은 모듈의 변이 점수, 놓친 결함 비율이 추적되고 검토되며, 커버리지는 여러 신호 중 하나이고, 관문은 의견이 아닌 증거에 따라 촉발됩니다.
5단계, 오케스트레이션: 고급 기법(속성 기반, 변이, 퍼즈)이 가치 높은 코드를 겨냥합니다. 테스트가 배포 빈도, 변경 실패율, 평균 복구 시간 같은 전달 지표와 통합되고, 조직은 스위트를 아키텍처와 위험에 맞게 지속적으로 재편하며, 중복된 테스트를 폐기하고 증거가 결함이 여전히 빠져나감을 보이는 곳에 투자합니다.

논의를 위한 아이디어

테스트 분포는 실제로 어떤 모양이며, 아키텍처와 위험에 맞습니까?
어떤 코드가 예시 테스트 대신 속성 기반 또는 변이 테스트를 필요로 하는지 어떻게 결정합니까?
불안정한 테스트에 대한 정책은 무엇이며, 실제로 시행됩니까?
민감한 정보를 새지 않으면서 현실적인 합성 데이터를 어떻게 생성합니까?
커버리지는 어디에서 진정으로 도움이 되었고, 어디에서 조작되었습니까?
AI가 생성한 테스트는 잡음이 아닌 확신을 더하도록 어떻게 리뷰해야 합니까?

핵심 요점

변경할 확신을 얻으려고 테스트하십시오. 속도와 비용 단위당 확신에 최적화하십시오.
피라미드를 기본으로 쓰되 테스트를 아키텍처에 맞게 빚으십시오.
불안정한 테스트는 결함으로, 커버리지는 목표가 아닌 신호로 다루십시오.
가치가 비용을 정당화하는 곳에 고급 기법을 적용하십시오.
접근성, 성능, 보안 테스트를 전략에 포함하고, 프라이버시를 지키기 위해 합성 데이터를 쓰십시오.

참고 문헌과 더 읽을거리

Kent Beck, Test-Driven Development: By Example
Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams
Gerard Meszaros, xUnit Test Patterns: Refactoring Test Code
Michael Feathers, Working Effectively with Legacy Code
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps
Martin Fowler, articles on the Test Pyramid and test-related patterns