원문: https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html (Translated by Google Gemini)

우리는 모두 코드를 작성할 때 테스트를 작성하도록 길들여져 있습니다 : 단위, 기능, UI 등 모든 것을 말이죠. 우리는 결국 전문가입니다. 우리 중 많은 사람들은 작은 테스트가 작업을 빠르게 진행하게 하고, 더 큰 테스트가 안전과 마무리에 영감을 주는 것을 좋아합니다. 아니면 단순히 검토 중에 비난을 예상할 수도 있습니다. 우리는 이러한 테스트에 너무 익숙해져서 왜 테스트를 작성하는지 더 이상 질문하지 않는 경우가 많습니다. 이것은 낭비적이고 위험할 수 있습니다.

테스트는 목적을 위한 수단입니다 : 프로젝트의 주요 위험을 줄이고 , 가장 큰 효과를 얻기 위함입니다. 이 효과는 항상 표준 관행에 따라 작성하는 테스트에서 나오지 않을 수 있으며, 심지어 테스트에서 전혀 나오지 않을 수도 있습니다.

두 가지 예시:

“우리는 새로운 디버깅 도구를 만들었습니다. 단위, 통합, UI 테스트를 작성했습니다. 출시할 준비가 되었습니다.”

뛰어난 관행입니다. 하지만 목표를 놓쳤습니다.

우리의 주요 위험은 디버깅 도구를 위해 데이터를 손상시키거나 서버를 다운시키는 것이었습니다. 어떤 테스트도 이를 해결하지 못했지만, 거짓된 안전감과 “완료되었다는” 느낌을 주었습니다.

우리는 출시를 중단했습니다.

“우리는 기능을 중단하고 싶었고, 그래서 영향을 받는 사용자에게 알림을 보내야 했습니다. 다시 단위 및 통합 테스트가 있었고, 심지어 비용이 많이 드는 엔드투엔드 테스트도 있었습니다.”

표준 관행입니다. 낭비된 노력입니다.

이 알림은 모든 시나리오에 대해 엔드투엔드 커버리지가 실제로 필요할 정도로 중요했습니다. 하지만 단 세 번의 릴리스 동안만 활성화될 것이었습니다. 가장 저렴하고 효과적인 테스트는? 각 릴리스 전에 수동 테스트를 하는 것이었습니다.

더 나은 접근 방식: 위험 우선#

모든 프로젝트나 기능에 대해 테스트를 고려하세요. 주요 위험과 이를 줄이기 위한 최상의 옵션을 브레인스토밍하세요. 노력을 낭비하지 않고 설계를 조정할 수 있도록 시작할 때 이 작업을 수행하세요. 검토 및 토론에서 참조할 수 있도록 QA 설계로 작성해 두세요.

확실히, 표준 관행은 대부분의 경우에 여전히 좋은 생각입니다 (그래서 표준입니다). 작은 테스트는 저렴하고 코딩 및 유지 보수 속도를 높이며, 더 큰 테스트는 핵심 사용 사례 및 통합을 보호합니다.

기억하세요: 테스트는 수단입니다. 중요한 것은 효과입니다. 그것을 극대화하는 것이 당신의 일입니다.