서론
개발 후에 JIRA에 이슈가 생성되는 것이 싫어서, “테스트를 공부하면 조금 나아질까?” 하는 생각으로 읽기 시작한 책입니다.
본론
이 책의 저자는 소프트웨어 품질 연구로 박사 학위를 취득 후, 오랜 기간 테스트 관련 업을 가져온 “다카하시 주이치"라는 사람입니다. 소프트웨어 테스팅 관련 컨설팅 경험을 바탕으로 책의 내용을 쉽게 설명 해주고 있습니다.
이 책에서 말하는 시프트-레프트 테스트를 설명하자면, 아래와 같습니다.
요구사항 분석, 설계, 코딩 등 소프트웨어 개발 사이클의 모든 단계에서는 의도치 않은 일이 발생할 수 있습니다. 이러한 것들을 버그라고 합니다. 하지만, 우리는 이 버그를 개발 사이클의 마지막 단계에서 QA가 모두 찾아주기를 기다립니다. 이러한 생각은 소프트웨어 개발의 일정과 품질에 부정적인 영향을 끼칩니다. 하나의 일이 끝났을 때마다 리뷰 혹은 검증을 하는 활동이 필요합니다. 즉, 테스트를 하는 시점을 점차 일의 시작 지점, 왼쪽으로 옮기는 전략이 필요합니다. 이것을 시프트-레프트라고 이야기합니다.
하지만, 이 시프트-레프트를 실현하기는 쉽지 않습니다. 빠듯해 보이는 일정과, 중요해 보이지 않는 테스트 때문일 것 입니다. 이 책에서는 합리적인 방법을 소개해주고 독자들에게 시프트-레프트의 중요성을 알게 해주기 위해 노력합니다. 가장 인상적 이었던 부분들만 소개를 해 보겠습니다.
"80:20법칙"
이 법칙은 소프트웨어의 20% 부분에서 전체의 80%의 버그가 발생한다는 법칙입니다. 즉, 우리는 이 20%에 해당하는 부분에 대해서 테스트를 작성하면, 전체 버그의 80%를 검증하는 것이 됩니다. 이 책에서는 20%에 해당하는 부분을 찾는 방법으로, 가장 최근에 가장 많이 변경된 파일을 선정하였습니다.
-> 항상, 복잡하고, 빠르게 작성되거나, 수정 사항이 많이 발생한 부분에서 버그가 많이 발생합니다. 테스트가 필요한 상황을 잊지 말아야할 것 같아서 작성합니다.
(플로우상 경우의 수가 많이 나오는 테스트의 경우)
"이것은 데이터가 n인 경우이므로 일단 작성하기 시작하면 그 경우의 수는 무한대가 됩니다. 따라서 먼저 데이터가 1과 2일 때 확실하게 커버하고, n이라는 테스트 케이스를 적절한 개수로 한정해 작성할 수 있으면 품질 측면에서는 거의 문제가 없습니다."
이 이야기는 모든 경우에 수에 대해서 테스트를 작성하는 것은 비효율적이며, 감당할 수 있는 범위의 테스트를 수행하여야 한다는 이야기 입니다. 또한 저자는 이러한 복잡한 테스트는 자동화를 하여야한다고 주장합니다.
-> 테스트를 작성하기 전에 너무 많은 테스트 케이스 때문에 그냥 테스트를 작성하지 않은 적이 있습니다. 이 내용이 위로와 공감이 되어서 작성합니다.
"코드 리뷰가 테스트보다 더 효율적인 버그 발견 방법"
-> 테스트가 완벽한 것 같지만, 커버리지가 높다고 하더라도, 100% 믿을 수는 없습니다. 이러한 내용을 확인해줄 다른 사람이 있을 때, 때로는 테스트 보다 더 성능이 좋은 버그 발견 방법이라고 생각해서 작성했습니다.
결론
테스트가 중요하고, 마지막에 한 번에 통합 테스트만 하는 것 보다도, 일이 끝나는 시점 마다 테스트 혹은 리뷰를 하여 테스트 시점을 앞 당기는 일의 중요성을 알게 되었습니다. 하지만, 프론트엔드 개발자로서 화면에 대한 테스트 방법이나 언급이 적어서 아쉬움도 있던 책입니다.
참조
책 링크 (교보문고): https://product.kyobobook.co.kr/detail/S000200939459