brunch

You can make anything
by writing

C.S.Lewis

by 전현수 Apr 24. 2020

알고리즘과 휴리스틱의 차이

테스트는 체험을 바탕으로


테스트 케이스의 효율성


소프트웨어의 높은 Quality를 위해 테스트를 진행할 때, 테스트 케이스를 작성하여 이에 따라 테스트를 실행하고, 실패율로 품질을 측정하는 방식을 선택하는 회사들이 많다. 하지만 현재까지 제품의 모든 경우의 수가 고려되고 전부 테스트 케이스로 옮겨지는 것은 사실상 현실적으로 불가능하며, 이러한 부분은 따라서 수치로 계산되지 못한다. 그렇다면, 이러한 테스트 결과 수치가 소프트웨어의 품질을 증명한다고 할 수 있을까? 

테스트 케이스는 시간이 지나며 제품의 기능이 발전하고 늘어날수록, 같이 늘어난다. 그만큼 테스트 수행 시간도 늘어나기 때문에, 결국 부분적 회귀 테스트를 테스트 전략을 많이 선택한다. 이러다 보면, 오랫동안 건드려지지 않는 위험요소가 적은 부분도 있을 테고, 그 부분의 테스트 케이스들을 계속해서 유지 보수하며 갱신하기는 시간이 지날수록 어마어마한 양의 힘들지만 큰 쓸모가 없을지도 모를 일이 된다. 또한 이를 따라가지 못하면, 실제 테스트를 수행할 때 테스트 케이스가 최신으로 갱신되지 않은 상태에서 테스트가 실패하는 경우 또한 발생할 수 있다. 다시 말해, 상황에 따라 테스트 케이스를 이용하는 테스트 방식이 시간적 소모가 매우 비효율적일 수 있다는 이야기이다.






Algorithm 대 Heuristic


알고리즘은 정해진 정답을 보장하는 문제를 해결하는 방법이며, 따라야 하는 규칙과 같은 것이다. 휴리스틱(체험적) 또한 이러한 규칙이지만, 경험을 바탕으로 한 일반적/대략적 규칙이며, 항상 문제를 해결하거나, 정답이 보장되는 것은 아니다.


문을 여는 것을 문제로 예로 들어보자. 휴리스틱은 대부분 문제가 해결된다. "손잡이를 돌리고 문을 민다" 하지만 항상은 아니다. 문을 당겨야 할 때도 있고, 손잡이를 돌리는 것이 아닌, 버튼을 누르는 방식일 수도 있다. 하지만 이 또한 실패할 수도 있다. 그렇다면 또 다른 휴리스틱을 적용해 보는 것이다. 이러한 휴리스틱들은 어느 것도 해결책을 무조건 보장하지는 않지만, 문제 해결에는 도움이 된다.


테스트 케이스를 수행하다가, 기능적인 결과는 사실상 통과지만, 매우 세밀하고 사소한 부분 때문에 이 테스트 케이스를 통과시킬지, 실패시킬지 고민해 본 경험이 있을 것이다. 사람들마다, 팀마다 각자의 방식으로 이행하겠지만, 과연 이것이 빠르고 효율적인 테스트 방법일까? 테스트 케이스들은 대부분 알고리즘 방식으로, 통과 혹을 실패로 결과가 도출될 뿐이다. 테스트 케이스를 실행하는 것은, 알고리즘을 따르는 것이다. 휴리스틱은 가이드라인 같은 것이며, 따르는 것이 아닌 적용하는 것이다. 그러므로 테스트 케이스를 작성하는데 휴리스틱을 적용하는 것은 매우 어렵고, 거의 불가능하다고 볼 수 있다. 그렇게 되면 실패하게 되는 테스트 케이스는 현저하게 줄어들 것이다.


소프트웨어의 품질을 숫자로 나타내는 것은 사실상 무의미하다. 제품의 모든 경우의 수를 전부 생각해내고 검증하는 것은 불가능하기 때문이다. 제품의 품질은, 체험을 바탕으로 테스트 결과를 이슈나 궁금증 등을 이야기로 풀어내야 하는 것이 제품의 개발을 위해 더 효율적이고 점진적인 테스트 방법, 그리고 테스트 결과를 사용하는 방법이지 않을까 생각된다.

매거진의 이전글 기술적 전략에서 팀 능력 전략으로
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari