미스터리 브레드
QA 팀의 목표는 테스트를 잘하는 것이 아닙니다.
올바른 것을 올바른 방식으로 테스트하는 것도 아닙니다.
진짜 목표는 팀이 제대로 작동하는 소프트웨어를 구축하도록 돕는 것입니다. 테스트는 이 목표를 달성하기 위한 하나의 도구입니다. 유일한 도구가 아닙니다. 종종 최선의 도구가 아닐 때도 있습니다.
많은 기업이 테스트와 커버리지에만 집중합니다. 이것은 실수입니다.
테스트는 다음과 같은 구체적인 용도가 있습니다:
- 자동화된 테스트는 중요한 기능에 대해 빠른 피드백을 제공합니다.
- 탐색적 테스트는 소프트웨어가 어떻게 동작하는지 이해하는 데 도움을 줍니다.
하지만 많은 팀이 모든 것을 해결하기 위해 테스트를 사용합니다. 부실한 계획으로 인해 생긴 빈틈을 메우기 위해 테스트를 사용합니다. 모니터링과 관측성(observability)을 대체하기 위해 테스트를 사용하기도 합니다.
테스트 커버리지를 주요 품질 신호로 의존하는 것은 오븐에서 빵이 나온 후에 모양을 잡으려는 것과 같습니다.
소프트웨어를 빵이라고 생각해보세요. 재료는 코드를 작성하기 전에 필요한 것들입니다:
- 소프트웨어가 무엇을 해야 하는지에 대한 명확한 정의.
- 품질이 어떤 모습이어야 하는지에 대한 합의.
- 리스크와 제약 사항에 대한 이해.
잘못된 밀가루를 사용하거나 소금을 빼먹는다면, 아무리 모양을 다시 잡아도 반죽을 바로잡을 수 없습니다.
소프트웨어는 아직 반죽 상태일 때 모양을 잡기 쉽습니다. 이는 개발 초기 단계를 의미합니다. 일단 코드가 작성되면 반죽은 딱딱해집니다. 그 이후에 변경을 가하려면 더 많은 시간과 노력이 듭니다.
테스트 커버리지는 당신이 어디를 살펴보았는지를 알려줍니다. 당신이 살펴본 것이 중요한지는 알려주지 않습니다. 80%라는 커버리지 수치가 소프트웨어의 품질이 높다는 것을 의미하지는 않습니다. 그저 쓸모없는 테스트가 너무 많다는 뜻일 수도 있습니다.
커버리지 수치를 쫓는 것을 멈추세요. 대신, 다음과 같은 질문을 던져보세요:
- 우리 소프트웨어의 동작 중 알 수 없는 부분은 어디인가?
- 이를 알아낼 가장 빠른 방법은 무엇인가?
때로는 답이 테스트일 수도 있습니다. 하지만 많은 경우, 답은 대화에 있습니다. 모두가 당연하다고 가정하는 질문들을 던져야 합니다.
대부분의 소프트웨어는 결국 고장이 납니다. 고장이 났을 때, 이를 빠르게 알아야 합니다. 프로덕션 모니터링은 사용자가 알아채기 전에 문제가 발생했음을 알려줍니다. 테스트로는 이를 저렴하게 수행할 수 없습니다.
AI는 이 문제를 더욱 어렵게 만듭니다. 이제 실제 이해 없이도 코드와 테스트를 생성할 수 있습니다. 커버리지 수치는 올라가지만, 품질은 낮은 상태로 유지됩니다. 반죽 단계를 건너뛰고 곧장 오븐으로 들어가는 셈입니다.
테스트는 목적을 위한 수단입니다. 커버리지는 단지 대리 지표(proxy)일 뿐입니다. 진짜 작업은 반죽 단계에서 이루어집니다. 이 단계를 건너뛰지 마세요.
Source: https://dev.to/susanne_abdelrahman/mystery-bread-2526
Optional learning community: https://t.me/GyaanSetuAi