지식 제로부터 배우는 소프트웨어 테스트 표지.
소프트웨어 테스팅은 프로그래밍 못지 않게 어렵고 복잡한 하나의 전문 영역이라고, 머리로는 알고 있었다. 하지만 실제로 그렇게 여기고 있지는 않고 있었다는 것을 이 책을 읽고 알게 되었다. 예컨대 나는 은연중에 개발자나 기획자가 기획서나 테크스펙에서 테스트케이스를 잘 짜면, 모든 버그를 막을 수 있을 것이라 생각했다. 만약 버그가 발생했다면, 테스트케이스를 잘 짜지 못했거나, 성실하게 테스트 케이스를 수행하지 않은 나의 잘못이라고 생각했다. 이 얼마나 오만한 생각이었나!
책은 먼저 다음과 같은 아주 간단한 프로그램에 대해 이야기하며 시작한다.
프로그램은 3개의 정수를 입력받습니다. 각 숫자는 삼각형의 변의 길이입니다. 프로그램은 입력받은 숫자를 기반으로 만들어진 삼각형이 정삼각형인지, 이등변삼각형인지, 부등변삼각형인지를 판단하고 그 판단 결과를 출력합니다.
이 프로그램을 테스트하는데 충분하다고 생각하는 테스트케이스를 적어보세요
- Glenford Myers, The Art of Software Testing, 1979
정말 간단한 프로그램이다. 책에는 심지어 이 프로그램의 구현 코드도 나와있다. 수십 줄 짜리의 간단한 이 프로그램은, 프로그래밍을 막 시작한 초보도 쉽게 구현할 수 있다. 하지만 제대로 된 테스트케이스를 작성하는 것은 어렵다. 실무를 하는 QA엔지니어 중에서도 충분히 유능한 사람들 정도가 위 문제에서 요구하는 모든 테스트케이스를 제대로 작성 할 수 있다고 한다. 예컨대 나는 다음과 같은 테스트케이스는 생각하지 못했다.
•
입력의 개수가 틀림
•
모든 변의 길이가 0
•
한 변의 길이가 음수
•
두 변의 합이 다른 한 변의 합과 같음
책에서는 최소 11개의 테스트케이스가 이 프로그램을 충분히 테스트 할 수 있다고 얘기한다. 하지만 조금만 상상력을 더 발휘하면 테스트케이스는 금새 수십 개까지 늘어날 수 있다. 수십줄의 짜리의 프로그램에서 최소 수십 개 이상의 테스트케이스가 나올 수 있다면, 수십만줄의 프로그램에서 얼마나 많은 테스트케이스가 필요할까!
비전문가들이 "어떻게 하면 충분한 테스트 케이스를 만들 수 있을까?"를 고민하는 레벨에 그친다면, 이렇게 무수한 테스트케이스를 상상할 수 있는, 그리고 소프트웨어에서 버그를 완전히 제거하는 것이 불가능하다는 것을 알고 있는 테스트 전문가들은, 결국 "어떻게 하면 테스트 케이스를 줄이면서도, 치명적인 버그가 발생하지 않도록 품질을 유지 할 수 있을까?" 에 대해 고민한다. 책은 이 고민에 대한 학계의 오랜 고민의 결과물들을 쉬운 언어로, 그러나 언제나 그 고민들의 이론적 토대에 대한 명확한 출처와 함께, 그리고 저자 본인의 실무에서의 경험과 곁들여 소개한다.
특히 개발자 입장에서, 책에서 소개한 내용들은 내게 크게 3가지 분류로 나뉘었다.
먼저 개발자도 반드시 알아야 할 테스팅 개념들이 있다. 예컨대 조합테스트를 하지 말 것 을 권고하는 부분은 소프트웨어 품질에 있어 개발자의 책임이 어디까지인지 명확히 하고 있다. 어떤 종류의 버그는, QA 단에서 발견되어서는 안 되고 설계, 그리고 개발 차원에서 예방되고 제거되어야 한다. 그 어떤 종류가 어떤 종류인지, 개발자들은 명확하게 알 필요가 있다.
다음으로 개발자들도 알면 좋은 지식들이 많았다. 품질을 양보하지 않으며 테스트케이스의 수를 조절하기위해 어떻게 등가분할 이라는 개념이 만들어졌는지, 그리고 이 개념을 통해 발견 할 수 있는 "경계값 버그의 4종류"에는 어떤 것들이 있는지와 같은 지식은 개발자 차원의 테스팅은 물론 코드리뷰 시에도 매우 유용하게 사용 할 수 있는 지식들이다.
하지만 내게 가장 가치있었던 지식은, "개발자가 알 필요까지는 없는" 지식들이었다. 예컨대 테스트케이스 작성에 소요되는 시간과 실제로 테스트를 실행하는데 드는 시간을 어떻게 조율해야 하는지와 같은 부분에 대한 지식은, 테스팅을 전업으로 하지 않는 이들에게는 그다지 유용한 지식이 아니다. 그렇지만 오히려 그렇기에, 어째서 "일정 규모 이상의 프로젝트에 전업 테스터가 필요한가"에 대해 이해하고 공감 할 수 있는 토대를 만들어 주었다.
많은 기술조직에서 아직까지도 QA의 업무 범위와 그 중요성은 과소평가 받고 있다. 예컨대 소프트웨어를 만드는 팀을 만드는데, 백앤드 개발자, 프론트엔드 개발자, 기획자, 디자이너가 필요하다는 것은 모두가 이해하지만, 여기에 QA엔지니어가 필요하다는 발상은 쉽게 하지 못한다. 흔히들 "기획자와 디자이너가 테스트도 같이 하면 된다"고 여긴다. 또는 개발자가 테스트코드를 잘 짜면 버그를 막을 수 있다고 생각하기도 한다. 그런 생각을 하고 있던 사람이라면, 즉 테스팅이 개발이나 디자인에 비해 조금이라도 쉽거나 덜 전문적인 역할이라고 여겼던 사람이라면, 그러니까 얼마 전의 나와 같은 사람이라면, 분명 이 책에서 생각지 못한 다양한 통찰을 얻어갈 수 있을 것이다.