기능 자동화에 대한 설명을 하다가 받은 질문에 대한 생각 정리를 한번 해보려고 합니다 😀
반복되는 작업, 동일한 테스트는 더 이상 결함을 발견하지 못하기에 필요 없는 테스트가 되는 것일까요..?
이번에 한번 알아보도록 하겠습니다 :)
소프트웨어 테스팅 원리 - 살충제 패러독스
소프트웨어 테스팅의 7가지 원리가 있습니다.
- 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다.
- 완벽한 테스팅은 불가능하다.
- 조기 테스팅으로 시간과 비용을 절약할 수 있다.
- 결함은 집중된다.
- 테스트 효과는 줄어든다. (살충제 패러독스)
- 테스트는 정황에 의존적이다.
- 결함-부재는 궤변이다
이 항목 중에 기능 자동화 테스트의 단점이라고 생각이 들 수 있는 "테스트 효과는 줄어든다(살충제 패러독스)" 항목과 관련되어 자동화에 대한 설명을 해보려고 합니다.
우선 "테스트 효과는 줄어든다(살충제 패러독스)" 항목은 어떤 의미를 나타내는 것일까요?
ISTQB FL 자료에 따르면 아래와 같습니다.
만일 같은 테스트를 계속해서 반복하면, 결국 해당 테스트의 신규 결함 식별 효과는 점점 줄어들게 된다(Beizer 1990). 이런 현상을 극복하기 위해 기존 테스트와 테스트 데이터의 수정 및 새로운 테스트 작성이 필요할 수 있다. 그러나 자동 리그레션 테스팅처럼 같은 테스트를 반복하는 것이 유익한 결과로 이어지는 경우도 있다
동일한 테스트를 반복해서 수행하는 작업은 새로운 결함 식별 효과는 줄어들 수밖에 없습니다.
QC가 동일한 테스트 케이스로 같은 테스트를 반복한다면.. 업무적으로도 힘들 수 있고, 결함이 없는 걸 알고 있으니 테스트도 집중해서 못할 가능성도 크다고 생각합니다. 테스터에게는 결함을 발견해야 도파민이 마구마구 생기거든요..!!!!
원하는 결함을 발견하기 위해서! 새로운 기능에는 결함이 많을 것이니 나는 그쪽 테스트에 집중하고 싶어!라고 생각할 수 있습니다.
But. 세상은 좋은 일만 있을 수 없겠죠..? 실제 경험담을 예로 들어보자면, 테스터가 반복되는 테스트를 하는 도중 이전에도 결함이 없었으니 가중치를 줄여서 슥슥 넘겨 보고 다른 테스트에 집중하자라고 딱 생각한 그 시점에! 문제는 발생했습니다.
다른 항목의 결함 수정 건에 영향으로 Side Effect가 발생하여 기존 동작에 오류를 발생하고 있었습니다. 리그레션 테스트를 수행하긴 했으나, 전혀 예상치 못한 부분에서 오류가 발생하고 있었던 것입니다.
안타깝게도, 이것을 발견하지 못한 채로 고객사에 제품 버전이 전달되게 되었고, 결함은 고객사에서 발견되게 되었습니다. 그나마 크리티컬 한 이슈는 아니라서 금방 수정본을 다시 넘겨주긴 했지만, 큰 이슈였다면 굉장한 손해를 입어야 했겠죠..? 😥
"테스트 효과는 줄어든다(살충제 패러독스)" 원리의 대처 방안
위에서 설명한 대로 반복적으로 동일한 테스트를 수행하는 것은 공수 낭비나 테스트의 신규 결함 식별 효과는 점점 줄어들게 될 것입니다.
하지만 안 좋았던 사례처럼 리그레션 테스트를 수행해도, 테스터도 사람이기 때문에 놓치는 부분이 있을 수 있습니다. 이를 대처하기 위해서 사용되는 것이 "기능 테스트 자동화" 기술이라고 생각합니다.
처음으로 돌아가서 최근 받은 질문이었습니다.
"기능 테스트 자동화는 결국 살충제 패러독스에 걸리는 것 아닌가요?"
처음 이 질문을 받았을 때는 맞는 것도 같은데...?라고 생각했었습니다. 실제로 같은 테스트를 반복한다는 것은 의미 없는 일 일수도 있기 때문이죠.
하지만, 사람이 수행하지 않는 자동화는 처음 자동화 환경을 만들기 위한 공수가 많이 들지만 한번 구성하고 나면 자동으로 수행되기 때문에 결과적으로는 공수 절약의 효과를 볼 수 있으며, 자동화 영역은 단순히 같은 테스트를 반복한다는 것이 아닌 리그레션 테스트의 영역을 다수 커버한다면 공수 절감 효과뿐만 아니라, 제품의 안정성까지 확보할 수 있다고 답변드렸습니다.
자동화를 통한 이점은 굉장히 많습니다.
사람이 수행하는 것보다 굉장히 빠르고, 스크립트로 구성되어 있기 때문에 동일한 동작을 수행하여 믿을 수 있습니다.
하나의 스크립트를 구성한다면 이를 응용하여 다른 테스트에도 적용할 수 있습니다. 이는 재사용성에도 큰 영향을 미치죠.
가장 큰 장점은 공수 절약으로 인한 효과라고 생각합니다.
그렇다면, 반복되는 기능 테스트를 만들어둔다면 해결되는 문제일까요..?
마냥 해결될 문제는 아닐 수 있습니다. 결국 같은 테스트를 반복해서 수행한다는 것은 특별한 상황이 아닌 이상 결함을 발견할 수 없기 때문입니다. 그렇다면 어떤 방향으로 테스트 자동화를 구성해야 할까요?
제 의견은 아래와 같습니다.
- 테스트 커버리지를 확대해서 스크립트를 추가로 작성하는 방법
- 자동화 테스트 스크립트에 대한 주기적인 검토 및 갱신
- 무작위 입력값을 통해 반복적인 테스트라도 다양한 입력값을 수행하는 방법 (Fuzz Test)
- 성능, 보안, 사용성 등 다른 유형의 테스트 방식과 결합 하여 테스트하는 방법
- 실제 사용자가 되어 다양한 상태 전이 테스팅이 포함된 큰 시나리오를 수행해 보는 스크립트 작성
자동화도 결국 같은 기능을 반복해서 작업하는 것 이기에, 주기적인 스크립트 수정이나 새로운 스크립트 추가를 하여 안정성을 높여가는 게 가장 중요해 보입니다.
혹은, 쳬계적인 프로세스를 구축하고, 일일 루틴처럼 관리하는 방식의 체계를 잡는다면 좀 더 안정적이고 장점을 활용 할 수 있는 자동화 시스템이 될 수 있을 것 같습니다 !
그리고, 자동화는 모든 부분에 대한 테스트를 할 수 없기에 너무 의존하는 것도 좋진 않아보이네요! 자동화의 장점과 테스터가 TC를 수행하며 테스트하는 장점을 잘 섞는다면 더 좋은 품질의 SW를 만들 수 있지 않을까 싶습니다 :)
자동화 구성이나 사람이나 계속해서 발전해야 더 좋은 효과를 내는 것 같네요 🤗
다음 포스팅에서 만나 뵙겠습니다!
'QA > 기능 자동화' 카테고리의 다른 글
부족한 식별자로 신뢰도 있는 자동화 스크립트 구성하기 (1) | 2024.09.08 |
---|---|
기능 자동화, POM(Page Object Model) 구조 만들기 (1) | 2024.09.08 |
Playwright를 활용한 자동화 연습 (1) | 2024.06.16 |
기능 자동화 동작 방식과 식별자 (0) | 2024.06.15 |
기능 테스트 자동화, 왜 Playwright를 선정했을까? (2) (2) | 2024.06.09 |