Utest에서 제가 존경하는 Super Tester인 James Bach님의 이름이 나오길래 뭔가 해서 봤더니, 재미있는 글이 올라와 있네요. 우리나라에도 적용되는 내용이라 번역해 봤습니다. 원문은 이곳을 클릭해서 보실 수 있습니다.
언제나 그렇듯이 제 번역은 의역을 조금 지나친 완전 번역입니다. 원문에 쓰여있지 않은 내용이 더라도, 독자들의 이해를 돕기 위해 추가된 한글 구문이 있을 수 있습니다. 또한, 원문이 존재해야 더 설득력이 있는 경우 번역본과 함께 원문을 추가해 두었습니다.
시작하기에 앞서...
일반적으로 소프트웨어 테스팅 관련된 부분을 번역할 때는, 영어로 Test라는 단어는 '테스트 항목'을 의미하며, 여기에는 단위테스트의 코드나 블랙박스테스트에서의 테스트케이스, 체크리스트 하나를 이야기 하기도 합니다. 그리고 Testing은 '테스팅 활동', '테스팅 작업'을 의미합니다. 마찬가지로 본문에서 알아보기 쉽게 하기 위해 번역은 아래와 같은 부분을 기초로 하였습니다.
- Test = 테스트 항목, Testing = 테스팅 활동
- Check = 확인 항목, Checking = 확인 활동
Bolton과 Bach의 테스팅 활동과 확인 활동의 차이점
대부분의 소프트웨어 테스팅(testing) 활동에 대한 부정적인 고정관념들이 사실은 소프트웨어 확인(checking)활동에 대한 내용이라
고 한다면 어떻게 생각하시나요? 아니, 다른 말로 하자면, 대부분 사람들이 가지고 있는 소프트웨어 테스팅에 대한 관점이 틀렸다고 말한다면 어떠실까요? 누군가 이런 것들에 대한 답을 말할 수 있다면, 그 사람은 테스팅 활동과 확인 활동에 대한 차이를 이해하고 있는 것입니다.
마이클 볼튼(Michael Bolton)과 제임스 바흐(James Bach)는 테스팅 활동과 확인 활동 사이에 존재하는 몇 가지 차이점에 대한 아이디어를 내 놓았습니다. 사실 이 부분에 대한 두 저자들의 포스트는 Satisfice 블로그에 기재되어 있고, 사실 필자는 독자들에게 그분들의 포스트를 통째로 읽어보기를 더 권장합니다만, 그렇다고 필자가 그분들의 설명을 요약하는 글을 쓰고 싶지는 않습니다. 필자의 주장은 조금 뒤쪽에 다시 설명하기로 하고요, 일단 그 두 분들이 정의하신 내용을 살펴보는 편이 좋겠습니다.
(ㄱ) 테스팅(testing) 활동은 질문이나 학습, 모델링, 관찰, 추론 등을 이용하는 특정한 등급을 가진 실험 과정을 통해 학습하게 되는 제품에 대한 평가 프로세스를 말합니다. (Testing is the process of evaluating a product by learning about it through experimentation, which includes to some degree: questioning, study, modeling, observation and inference.)
(ㄴ) 확인(checking)은 제품에 대한 특정한 형태의 관찰을 통해 결정 알고리즘 규칙을 적용하는 활동을 수행하고, 이를 기반으로 만들어지는 평가 프로세스를 말합니다. (Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.)
그러고 나서, 두 분들은 더 명확한 그림을 그릴 수 있도록 하기 위해 핵심이 될 수 있는 구분점과 가정을 제공하였습니다.
(1) 테스팅 활동은 확인 활동까지를 포함하는 반면, 확인 활동은 테스팅 활동을 포함하지는 않습니다. (Testing encompasses checking, whereas checking cannot encompass testing.)
(2) 테스팅 활동에서는 도구를 필요할 때만 부수적으로 사용하는 데 비해, 확인이라는 활동은 원칙적으로는 사람 대신 도구로 수행하는 프로세스입니다. (Checking is a process that can, in principle be performed by a tool instead of a human, whereas testing can only be supported by tools. Nevertheless, tools can be used for much more than checking.)
(3) 확인 활동은 "사실 확인"의 줄임말이거나, 특정한 사실이나 그 사실과 관련된 규칙에 집중하는 활동이지만, 테스팅 활동은 가능성을 열어 두고 진행하는 조사 활동입니다 -"설록 홈즈"를 생각해보세요. (Testing is an open-ended investigation– think “Sherlock Holmes”– whereas checking is short for “fact checking” and focuses on specific facts and rules related to those facts.)
확인 활동은 확정한다는(confirming) 의미와도 다릅니다. 확인한다는 의미는 때로 (대부분의 경우 회귀 테스팅을 할 때) 다시 한번 확인해서 확정한다는 의미로 사용될 수도 있겠지만, 또 한 편으로는 현재 상태의 부당성을 입증(disconfirmation)하거나 이론적인 탐색(speculative exploration)을 수행하는 활동으로도 생각할 수도 있기 때문입니다. (예를 들어 자동으로 생성된 확인 코드가 광대한 범위의 소프트웨어 내에서 무작위로 어떤 부분이 다른 지 찾는 작업을 하는 등으로도 사용될 수 있습니다.)
소프트웨어 업계에서의 가장 흔한 문제점 중 하나는 확인 활동이 테스팅 활동과 혼동되고 있다는 점입니다. 지금 이 글은 그 혼동을 줄여보려고 하는 것이구요.
확인 항목 하나 하나는 서술 가능하지만, 테스트 항목들은 그렇지 않을 수도 있습니다. (왜냐하면 확인 항목과 다르게 테스트 항목은 암묵적인 지식까지를 포함하기 때문입니다.)
컴퓨터 과학에서 말하는 판단완료 항목(assertion)은 확인 항목(check)에 가깝습니다. 그렇다고 해서 모든 확인 항목이 판단완료 항목인 것은 아니며, 판단완료 항목인 경우라도 할지라도, 판단하기 위한 코드가 존재할 것이고, 이 코드 자체가 확인 과정의 일부 일 수 있고, 혹은 판단하기 위한 과정의 일부가 아닌 경우도 있습니다.
이런 정의들은 도덕적인 측면의 판단으로 결정된건 아닙니다. 지금 우리는 확인 작업이 나쁜거라고 말하고 있는 것도 아닙니다. 반대로 말해 확인은 매우 중요할 수도 있는 작업입니다. 확인 활동이 좋은 작업이라 판단고 있기에, 확인 작업들은 매우 이치에 맞는 올바른 테스팅 프로세스 상에서 발생해야만 합니다. 확인 활동이라는 것은 전략적인 테스팅 활동 중 하나입니다.
필자가 글의 초반에 언급한 바와 같이 테스팅에 관한 수 많은 부정적인 고정관념은, 사실 볼튼과 바흐가 정의한 바처럼, 사실은 확인 활동에 대한 부분임은 매우 흥미로운 사실입니니다. 예를 들어,
(A) 테스팅은 지루한 작업이 아닙니다. 반면에 확인은 그럴 가능성이 큽니다. (Testing is a not a boring task. Checking, on the other hand, very well could be.)
(B) 테스팅은 쉽지 않습니다. 반면에 확인은 때때로 매우 쉽습니다. (Testing is not easy. Checking, on the other hand, is sometimes quite easy.)
(C) 테스팅은 컴퓨터만으로 수행되지 않습니다. 확인은 (아마도) 자동화가 가능합니다. (Testing cannot really be done by computers alone. Checking can (and probably should) be automated.)
(D) 테스트를 하는 사람은 항상 쓸모 있지만, 확인을 하는 사람은 쓸모 없어질 수 있습니다. (Human testers will never be obsolete, but human checkers (for lack of a better word) might be.)
여러분들은 자신만의 "테스팅"과 "확인"의 정의를 가지고 계신가요? 그렇다면 우리에게 그 아이디어들을 공유해주세요.
다음 이 시간까지, 행복한 테스팅(행복한 확인도) 하세요.
