[번역] 수동 테스팅 vs. 자동 테스팅, 정답은?

최근 회사에서 QA 인턴분들의 과제 발표회가 있었습니다. QA 업무와 관련된 도서를 읽고 실제 업무와 연관된 내용들을 정리하고 발표하는 자리였는데 가장 많이 언급된 단어 중 하나가 바로 테스트 자동화였습니다. 도메인을 가리지 않고 최근 소프트웨어 테스팅 업계에서 뜨거운 화두가 되고 있는 단어라고 할 수 있을 것 같네요. 

우연히 링크드인에서 접하게 된 "Testing, It's About the Results"를 오랜만에 번역해서 포스팅해 봅니다. 단어는 그것을 사용하는 사람의 의식의 단면을 표현해 준다고 하죠. 흔하게 사용하는 업계의 단어들이 그 업계의 의식을 대변해 준다고 보아도 무방할 것 같습니다. 이 글을 읽고 나서 나를 포함한 SQA들이 너무 자동화라는 화두에 매몰되어서 더 중요한 것들을 놓치고 있는 것이 아닌지 다시 한번 생각해 보는 계기가 되었습니다. 저자의 업무 상 홍보와 마케팅과 관련된 뉘앙스가 풍겨나올 수 밖에 없지만 그래도 충분히 영감을 주는 글이라 생각됩니다. 

늘 잊지 말아야 할 주제는 '무엇이 더 중요한가?'일 수 밖에 없습니다. 저자인 John Kensinger의 연작 포스트 중 마지막 부분을 번역한 것이라 좀 더 자세한 정보를 알고 싶다면 저자의 이전 포스트를  Test IO 에서 읽어보기를 권장합니다. 번역과 포스트에 대해서는 저자의 승인을 받았습니다. 

Happy Testing! :)

---

때론 잘못된 것에 집중하느라 앞으로 더 나가지 못하는 경우가 생깁니다. 수동 테스팅 vs. 자동 테스팅이라는 논쟁도 마찬가지입니다. 우리는 실제로 테스트가 수행되는 환경과 그 결과에 집중하지 못하고 오히려 개념에만 집중하고는 합니다. 실제로는 하나임에도 불구하고 이 두 가지를 각각 분리된 것으로 생각하거나 혹은 다른 하나를 수행한 다음 추가로 수행하면 더 좋은 것 정도로 이해합니다. 개념을 머릿속에 정리하는 것보다 테스트를 수행해서 얻게 되는 결과를 분석하는데 시간을 쏟는 것이 더 효율적인데 말이죠. 

이 글은 소프트웨어 배포와 품질 프로세스를 책임지고 있는 사람들을 대상으로 합니다. 이들은 매니저와 동료들, C 레벨 임원들에게 테스팅이 어떻게 수행되는지에 대해 큰 그림을 그리며 설명해야 하는 사람들입니다. 아래의 대화를 통해 얻을 수 있는 인사이트는 이런 상황을 잘 알고 있는 사람들에게 더욱 절실하게 다가갈 수 있을 것입니다. 그들과 주고받은 대화를 공개하고 그들의 생각을 공유할 수 있도록 허락해준 마이클 볼튼(Michael Bolton) 과 폴 제라드(Paul Gerrad)에게 감사의 인사를 드립니다. 

최근에 “수동 테스팅의 몰락(The Downfall of Manual Testing)”이라는 아티클을 포스트 했었습니다. 이 글에서는 테스팅에 대한 이해와 핵심적인 시각에 관한 대화를 자세하게 다루었습니다. 한 줄로 요약하자면 다음과 같습니다. 

테스팅은 언제나 사람에 의해 수행되고 “수동”으로 수행되지도 않고 “자동”으로 수행되지도 않습니다. 항상 사람이 테스트를 수행하고 이 사람의 업무를 도와주는 툴이 함께 사용됩니다. 

아래의 대화는 폴 제라드로 시작해 마이클 볼튼과 나 사이에 이루어진 대화들입니다. 앞서 언급했던 포스트에 대한 폴 제라드의 반응으로 대화가 시작됩니다.  

---

 폴 제라드 

현실에서 실제로 수행되는 탐색적 테스팅(exploratory real-world), 휴먼 테스팅(human testing)에 대비되는 개념으로 ‘수동 테스팅(manual testing)’을 정의해 봅시다.

이 문장을 통해 하고싶은 말이 정확하게 무엇일까요? 사실 모든 테스팅은 탐색적 테스팅일 수밖에 없습니다. 누군가가 정보의 원천을 탐험한다는 사실을 필연적으로 포함할 수밖에 없기 때문입니다. 현실이라는 말은 우선 생각하지 말죠. 비현실적인 세계라면 환상을 품고 있는 사람만 있을 테니까요. 

포스트에서 수동 테스팅에 비판적인 조 콜란토니오(Joe Colantonio)의 말을 인용하고 있는 것이 흥미롭습니다. 인용된 말들을 하나하나 살펴보죠. 

1. 많은 리소스를 사용한다 - 코멘트를 달 필요가 없어 보이네요. 당연히 테스팅에는 시간과 돈이 들어갑니다. 말하고 싶은 것이 이것밖에 없나요?

2. 시간이 필요하다 - 또 다른 문장이기는 하지만 앞선 문장과 마찬가지로 딱히 추가할 말이 필요치 않아 보이네요. 사용자 경험 스토리를 테스팅하는데 180,000 시간이 걸리기도 합니다! 이 중 얼마나 많은 일이 사람의 손에 의해 수행되었을까요? 이 중 얼마나 많은 테스트들이 제대로 분석되었을까요? 테스트 결과에 대해 얼마나 많은 논쟁과 논의가 수행되었고 이를 통해 민감한 결정들이 이루어졌을까요? 여기서 진짜 문제는 과연 무엇일까요?

3. 때로 적절한 커버리지를 확보하지 못한다 - 글쎄, 가장 간단하게 답변하자면 이런 경우 당신이 무언가를 잘못하고 있는 것이라고 생각되네요. 그 다음 질문은?

4. 근본적으로 반복적인 성격을 가진 일이므로 테스터들이 지루해하고 테스팅을 수행하는 동안 이로 인해 실수를 하게 된다 - 확실히 이런 면이 존재합니다. 맞습니다. 그래서 테스팅 툴을 사용하는 것이죠. 툴이 이런 지루함을 덜어주기 때문입니다. 하지만 툴이 결과를 분석하는 눈이나 지능을 가지고 있는 것은 아닙니다. 실제 화면에서 100가지 일이 일어나도 툴이 관찰할 수 있는 일은 한 두 가지에 지나지 않습니다. 나머지는 무시되기 마련이죠. 하지만 사람은 최소한 두 개 이상의 테스팅을 병렬적으로 수행하면서 추이를 관찰할 수 있고, 툴보다 많게는 5~10배가량 많은 문제를 찾아낼 수도 있습니다. 

하지만 결국 제대로 된 수동 테스트를 수행하려면 대규모로 테스터들을 채용해야 한다는 결론에 도달합니다. 그렇다고 무조건 이들이 좋은 결과를 줄 것이라고 기대해서는 안됩니다. 이들이 기존의 테스터들과 다른 시각을 가지고 있지 않는한 테스팅 업무를 잘 수행해 낼 것이라는 기대는 하지 않는 것이 좋습니다. 

존 켄싱어 
2. 시간이 필요하다 - 테스팅을 수행할 때 시간이 걸린다는 것이 문제가 아니라, 당신의 팀이 사용해서는 안 되는 것 중에 하나가 시간이라는 것이 더 큰 문제라고 할 수 있습니다. 크라우드 테스팅을 통해 즉시 테스팅 인력을 확보할 수 있습니다. 테스팅 프로세스가 여전히 빡빡할 수도 있지만 크라우드 테스팅을 통해 기존 조직의 부담을 덜고 좀 더 효율적으로 업무를 위임할 수 있을 겁니다. 

3. 때로 적절한 커버리지를 확보하지 못한다 - 물론입니다. 이 질문을 던진 개인이나 조직이 넓은 커버리지의 테스팅을 수행하기에 충분한 리소스를 가지고 있지 않을 수도 있습니다. 예를 들어, 소규모 인하우스 테스트 조직이나 오래된 단말로만 구성된 테스트 디바이스 팜을 가지고 있다거나, 온라인 시뮬레이터가 부족한 경우 등이 이 경우에 속할 수 있습니다.  

4. 근본적으로 반복적인 성격을 가진 일이므로 테스터들이 지루해하고 테스팅을 수행하는 동안 이로 인해 실수를 하게 된다 - 정곡을 찌르는 말입니다. 완전하게 동의합니다. 또한 이것이야말로 자동화 테스팅과 수동 테스팅이 완벽하게 조화를 이루어야 한다고 믿는 이유이기도 합니다.

마지막으로 저는 많은 테스터들을 한꺼번에 고용하는 것도 다양한 시각을 제공해 주는 하나의 방법이라고 생각합니다. 특히 소규모 인하우스 테스트 조직이나 과중한 업무로 지쳐있는 테스터와 개발자가 유용하게 사용할 수 있는 방법이라고 생각합니다. 

마이클 볼튼 
“또한 이것이야말로 자동화 테스팅과 수동 테스팅이 완벽하게 조화를 이루어야 한다고 믿는 이유이기도 합니다”라고 말한 것에 대해… 

분명히. 말하지만. 자동화 테스팅이나. 수동 테스팅은. 존재하지 않는다고. 이 빵꾸똥꾸들아. 

흥분해서 미안합니다. 하지만 생각해보죠. 당신은 자동 의사(automated doctor)나 수동 의사(manual doctor)를 만나본 적이 있나요? 자동화 진찰과 수동 진찰이 완벽하게 조화를 이루도록 노력하는 의사를 본 적이 있나요?

당신(존 켄싱어)은 온라인 플랫폼으로 링크드인을 사용해 마케팅을 수행하고 있는 것으로 알고 있습니다. 이런 마케팅을 좀 더 잘하려면 기계나 툴의 도움이 필요하겠죠. 자, 그럼 당신은 매뉴얼 마케팅을 하고 있는 건가요 아니면 자동화 마케팅을 하고 있는 건가요?

다른 사례를 살펴보죠. 당신은 당신의 상관이나 관리자에게 보고서를 보낼 겁니다. 관리자 역시 일상적인 업무의 하나로 툴을 사용하겠죠. 그럼 이 관리자는 수동 관리를 하고 있는 건가요 자동 관리를 하고 있는 건가요?

의사 이야기나 마케팅, 관리자와 관련된 위의 질문을 듣고 아마 어처구니가 없었을 겁니다. 그런데 왜 수동 테스팅이나 자동화 테스팅이라는 말이 이 보다 덜 우스울 거라고 생각하나요?

현실 세계에서 수행되는 탐색적 테스팅(exploratory real-world), 휴먼 테스팅(human testing)에 대비되는 개념으로 ‘수동 테스팅(manual testing)’을 정의해 봅시다

하지 말죠. 일에 하등 도움될 게 없는 논쟁을 더 이상 벌릴 필요가 없습니다. 현실 세계에서 수행되는 탐색적 테스팅, 휴먼 테스팅을 정확한 용어로 대체해 사용해야 합니다. 전 그냥 이렇게 불렀으면 좋겠네요. 테스팅.

존 켄싱어 
맞아요, 자동화 테스팅이던 수동 테스팅이던 그것은 테스팅이죠. 하지만 셀레늄(자동화를 통해 수행되는 스크립트가 핵심으로 개인적으로 “자동화된” 테스팅으로 분류하고 있음)과 수동 테스트(예를 들어 누군가가 기능적 결함을 찾기 위해 웹 사이트를 클릭해 보는 것)를 혼합하면 이분법적인 테스팅 개념을 희석할 수 있다는 생각은 해보셨나요? 이런 경우, 아마 당신은 ‘이분법적으로 부를만한 것 자체가 없다’라고 대답할 것 같네요. 하지만 그 말이 사실이라면 내가 방금 말한 자동화 테스트와 수동 테스트의 혼합 같은 것을 어떻게 이해해야 하는지  알려주면 좋겠네요. 알아요, 둘 다 테스팅이기는 하죠. 하지만 분명 두 개의 차이는 존재해요. 이 다름을 어떻게 정의할 건가요?

마이클 볼튼 
우선 앞선 내 코멘트를 살펴보는 것에서부터 당신 질문에 대한 대답을 시작해보죠. 내가 앞서 언급했던 분야에서 테스팅에서 사용하는 이분법적인 사고를 발견할 수 있었나요? 의사들, 마케팅 담당자들, 그리고 관리자들 역시 툴을 사용합니다. 이들이 툴을 사용할 때 그렇다고 자동화된 의료, 자동화된 마케팅, 자동화된 관리라고 부르지 않죠. 외과 수술은 중요한 의학적 차원의 행위입니다. 하지만 수술용 로봇인 다 빈치 를 “자동화된 수술도구”라고 부르지 않습니다. 대신 의사들이 수술하는 방식을 보완해주고 강화해주는 방법의 하나로 이 기계를 인식하고 있습니다. 우리가 단지 수술을 물리적인 행위로만 인식하지 않기 때문이죠. 수술은 의사의 스킬과 상황 분석 능력, 문제 해결 능력, 말로는 표현하기 힘든 전문 분야에 대한 지식 등이 모두 망라되어 있는 행위이기 때문입니다. 의사가 인상적인 최첨단 기계를 사용한다고 해도 의사가 가지고 있는 역량이나 기술이 무시되는 것은 아닙니다. 

테스팅에 대해 이야기할 때 우리는 늘 가장 근본적인 실수를 하고는 합니다. 우리는 누군가가 "클릭한다"라고 말하면서 클릭을 하는 물리적인 행위가 모든 테스팅 행위의 중심에 있는 것처럼 말하고는 합니다. 그 누군가는 문제를 찾기 위해 클릭을 하는 것이 아닙니다. 그 누군가는 제품에 대해 조사하고 분석하고 탐색하면서 실험을 수행하고 이를 통해 경험을 쌓고 있는 것입니다. 흥미롭게도 누군가가 프로그래밍을 한다고 이야기할 때 누군가가 "타이핑한다"라고 하면서 그 행위에 주목하지는 않습니다. 

테스팅과 관련된 생각에서 또 하나 놓치고 있는 것은 그 누군가가 수행하는 "스크립트"입니다. 이 스크립트가 어디서 왔는지, 어떻게 설계되었는지, 어떤 리스크 분석을 통해 설계되었는지, 그 결과로 도출되는 행동들이 어떻게 해석되어야 하는지 등의 내용은 전혀 고려되지 않습니다. 

우리는 누군가가 프로그램 언어를 기계어로 변환했다고 이야기할 때 프로그램이 어디서 왔고(누가 작성했고), 어떻게 설계되었고, 어떤 분석이 수행되었고, 사용자가 원하는 업무가 제대로 처리되었는지 고려하지 않으면서 기계어로 변환되었는지 이야기하지 않습니다. 

프로그램에서 컨버젼 단계는 사람이 수행할 수도 있습니다. 그리고 종종 그렇게 수행됩니다. 하지만 최근에는 대부분 시스템이 알아서 자동으로 변환해주며 이 과정을 컴파일링이라고 부르고 있습니다. 컴파일링 역시 프로그래밍 영역에 포함됩니다. 프로그래밍의 일부인 것이죠. 이 과정이 자동화될 수는 있지만, 그렇다고 해서 이것을 “자동화된 프로그래밍”이라고 부르지는 않습니다. 

테스트에서는 수행해야 하는 과정의 일부가 기계에 의해서 수행됩니다. 나는 이 과정이 프로그래밍에서 컴파일링과 유사하다고 생각하며 이 과정을 “자동화된 체킹(automated checking)”이라고 부르자고 제안한 적이 있습니다. 이 과정 역시 테스트에 포함되는 영역이며, 테스팅의 일부입니다. 또한 자동화 될 수 있는 영역입니다. 하지만 개인적인 관점에서는 이 부분을 “자동화된 테스팅”이라고 불러서는 안 된다고 생각하고 있습니다. 

존 켄싱어 
테스팅이 늘 사람에 의해 수행되고, 따라서 이를 “수동” 테스팅이나 “자동” 테스팅으로 구별할 필요가 없으며, 제품에 대해 조사하고 분석하고 탐색하면서 실험을 수행하고 이를 통해 경험을 쌓는 사람을 도와주는 데 사용되는 툴(혹은 “체크”)이 늘 결합하는 형태로 수행된다고 보면 될까요?

마이클 볼튼  
딱 맞습니다. 당신이 말한 내용 중에서 조금 더 수정이 필요한 부분은 (혹은 “체크”) 부분이 “(그리고/혹은 “체크”)로 바뀌어야 하는 것뿐이죠. 하지만 그 부분의 차이는 거의 대동소이 합니다. 

---

요약
짧게 설명하자면, 오직 테스팅이라는 행위만 존재하는 겁니다. “자동화된” 테스팅도, “수동” 테스팅도 존재하지 않습니다. 또한 “탐색적”이거나, “비탐색적”인 테스팅도 존재하지 않습니다. 마찬가지로 “휴먼” 테스팅도, “논 휴먼” 테스팅도, “리얼 월드” 테스팅도, “언리얼 월드” 테스팅도 존재하는 것은 아닙니다. 여기서 우리가 배워야 할 것은 하나의 테스트 환경이나 툴, 혹은 기초적인 테스트 접근법에 대해 고민하는 시간을 절약할수록 정말 중요한 것에 더 많은 시간을 투자할 수 있다는 겁니다. 테스팅의 실제 결과와 그 궁극적인 품질이 바로 그것이죠.