번역_QA는 죽었나?

이 글은 ThoughtWorks(R)에 게재된 Is QA Dead?를 번역한 것입니다. 저의 의견과 100% 일치하지 않을 수 있으며, 저작권에 문제가 될 경우 언제든지 삭제될 수 있습니다(저작권 문의 중).

테스트 자동화는 그다지 새로운 프랙티스는 아니다. 많은 소프트웨어 팀들이 테스팅을 자동화하기 위한 노력을 기울이고 있고, 특히 시간이 오래 걸리는 수작업에 의한 리그레션 테스팅 사이클을 대체하기 위한 수단으로 테스팅 자동화를 선택하고 있다. 여러분이 QA의 역할을 하고 있다면, 이러한 흐름이 여러분의 업무에 어떤 의미를 가지게 되는지 궁금해할 것이다. ‘모든 것이 자동화된 세계’에서 여러분은 여러분이 할 수 있는 일을 찾을 수 있을 것인가? QA의 역할은 죽어비린 건 아닐까?

테스트 자동화를 통해 얻을 수 있는 분명한 이점들에 대해 설명하면서 시작해보도록 하겠다.

컴퓨터는 사람보다 빠른 속도로 테스트를 한다.

테스트 자동화를 통해 사람들이 가장 먼저 체감하게 되는 이익 중 하나는 바로 시스템을 테스트하는데 소요되는 시간이 급격하게 감소한다는 것이다. 테스트 스크립트럴 한번만 작성하면 스크립트들은 수분 이내에 반복적으로 모두 실행되며, 심지어 다른 테스트를 함께 수행하는 경우에도 속도의 저하기 눈에 띄게 나타나지 않는다. 리그레션 테스트 스위트를 자동화한 팀이라면 이내 그들이 대부분의 리그레션 테스팅을 자동화할 수 있다는 것을 알게 되며, 리그레션 테스트의 수행에 걸리는 시간 역시 몇일에서 몇분으로 단축되는 것을 발견한다. 팀은 피드백을 더 빈번하고 빠르게 받을 수 있게 되고 따라서 버그를 조기에 발견할 수 있으며 코드는 더울 빠르게 릴리즈 가능해진다.

컴퓨터는 사람보다 일관성 있다.

사람은 실수를 한다. 이는 매우 자연적인 현상이다. 매뉴얼 테스터는 동일한 테스트 케이스를 수백번 반복하는 과정에서 테스트 케이스나 시나리오를 한 두개 정도 쉽게 누락할 수 있다. 어쩌면 시나리오를 문서화하는 것을 잊어버릴 수도 있다. 자동화된 테스트는 살아 숨쉬는 문서와 같다. 그들은 수행하도록 되어 있는 모든 일을 수행하며, 편차를 발생시키지 않고 반복적으로 끊임없이 반복한다.
자동화 테스트는 위와 같이 멋진 특성을 가지고 있어며, 팀은 이를 활용해 소프트웨어에 더 빠르게 품질을 구축할 수 있다. 하지만 실제 자동화 테스트가 폼함하고 있는 중요한 특징은 다른데에 있다.

자동화 테스트가 주는 가장 큰 이 점은 여러분에게 자유로음을 준다는 것이며, 이로서 QA인 여러분은 정말로 해야할 것을 할 수 있게 된다.

확인(Checking)과 테스팅(Testing)은 다르다.

2015년 열린 OnAgile 컨퍼런스에서, Elisabeth Hendrickson는 매우 유용한 구분을 사용했다. 의미 있는 정의를 내렸다. 그녀는 자동화 된 테스트가 어떤 일을 하는지에 대해 이야기할 때, ‘자동화 테스팅은 기능을 확인하지만, 기능확인은 테스팅과 직결되지는 않는다’라는 언급을 한 것이다. 다시 말해:

테스팅(testing) = 확인하기(checking) + 탐색하기(exploring)

자동화 된 테스트 케이스들은 멍청하다. 우리는 이미 알고 있는 시나리오를 확인하기 위해서 테스트 케이스를 작성한다. 테스트 케이스들이 수행되면 시스템에 여전히 우리가 원하는 대로 동작하는 지(기능의 추가나 변경에도 불구하고)를 확인할 수 있다. 그런데 그 시나리오들은 어떻게 만들어지는가? 시스템이 혹여 잘못될 수 있는 부분에 대한 이해로부터 테스트 케이스를 작성하게 되는데… 그렇다면 누가 그 시스템을 이해하는가? 바로 여러분이다.

사람은 다음과 같은 두 가지 점 – 창의성(creativity)과 학습 능력(learning) –에서 항상 컴퓨터보다 뛰어나다. 이 두가지 요소를 합하게 되면 우리가 흔히 이야기하는 탐색적 테스팅(exploratory testing)¹이 된다. 시스템을 탐색하면서, 일반적이지 않도록(즉, 설계에 의도되지 않도록) 시스템과 상호 작용하는 방법을 생각한다. 이런 과정을 통해 시스템이 어떻게 동작하는 지를 관찰한다. Hendrickson은 이러한 관찰을 통해서 우리가 정말 테스트해야 할 것들에 대해 학습하게 되고, 향후 무언가를 테스트으할 때 필요한 정보가 만들어진다고 언급한다.

자동화 된 테스트 케이스들을 통해 확인할 수 있는 결함은 여러분이 이미 인지하고 있는 결함들이다. 사람이 직접 수행하는 탐색적 테스팅을 통해 인지하고 있지 못하는 결함을 발견할 수 있게 된다. 자동화 된 테스팅은 바로 여러분에게 이러한 탐색적 테스팅에 집중할 수 있도록 충분한 자유를 제공한다. 새로운 결함을 발견한다면, 즉시 이 결함을 재확인할 수 있는 자동화 된 테스트 케이스를 작성한다. 이러한 방법으로 해당 결함을 다시는 손으로 직접 확인하지 않을 수 있게 되며 다른 취약점들을 찾는 데 보다 집중할 수 있게 된다.

그럼 QA란 대체 무엇을 의미하는가?

여러분은 QA라는 직함을 가지고 있지만, 일부 사람들에게는 여전히 테스터(tester)로 인식되는 경우가 많을 것이다. 하지만 여러부은 이미 테스트 이외에 많은 일들을 하고 있을 것이다. 대체 QA는 무엇을 의미하는가? 이 질문에 대한 여러가지 대답을 들어봤고 그 말들은 모두 다 옳았다. 여러가지 대답들은 QA라는 역할의 다른 면면은 표현하고 있었다.

품질 보증(Quality Assurance)

품질 보증(Quality Assuarance)는 이전 ‘품질 제어(Quality Control)’라는 직함과 매칭된다. 품질 제어라는 용어는 제조업에서 사용하던 것이다. 제품은 제품 생산 전 공정을 지난 뒤 품질 제어부서(Quality Controller)로 전달된다. 품질 제어부서는 제품에 오점(flaws)이 없는지, 오점이 있다면 오점을 고칠 것인지 제품을 버릴 것인지 결정한다. 제품의 상태가 좋다면 제품은 고객에게 출하된다.

토요타(Toyota)는 이러한 전통적인 방법을 좀 다르게 수행하기로 결정했다. 그들은 우리가 ‘린 프랙티스(Lean practices)’라고 부르는 활동을 통해 자동차 생산 공정에 품질을 연결시켰다. 제조상의 모든 단계마다 품질을 높임으로서 결과적으로 최종 생상물인 자동차에서 불량이 적게 나도록 하는 것이었다.

QA의 역할 중 하나는 소프트웨어 개발 프로세스에 품질을 연결시키는 것이다. 여러분은 품질 제어부서가 되고 싶지는 않을 것이다. 낮은 품질로 인해서 새로운 멋진 기능을 버리고 싶어하지 않을 것이기 때문에, 여러분은 개발 과정에서 품질을 쉽게 고취할 수 있도록 도와야 한다. 이러한 작업을 돕기 위해서 테스트 시나리오를 자동화 된 테스트 케이스를 작성하는 것을 귀찮아 하는 개발팀에게 도움을 줄 수 있다. 여러분은 안전 그물(safety net)을 만들어 개발자들로 하여금 이미 알고 있는 함정과 같은 복잡한 시나리오를 모두 통과하면서 새로운 기능이 개발되고 있다는 것을 알도록 할 수 있다. 여러분은 개발이 시작되기 이전에 이러한 자동화 된 테스틐 에시스를 개발자들과 함께 작성할 수 있을 것이다.

품질 분석가(Quality Analyst)

소프트웨어를 작성하는 것은 쉽지 않다. 컴퓨터 프로그래밍의 자연적인 특성상 몇가지 복잡함이 존재할 수 있지만, 대부분의 복잠합은 시스템이 상호 작용하는 주변의 세계로부터 만들어지는 것이다: 예를 들면 여러분이 개발하는 시스템이 통신을 해야하는 상대 시스템이 이해하기 어렵거나, 사용자들이 기대하지 않않은 방법으로 시스템을 사용하거나, 네트워킹이나 컴퓨터 인프라가 예측하지 못한 방법으로 뻗어버리는 경우 등등 수도 없는 복잡성이 존재한다.

QA의 역할 중 또 하나는 개발하고 있는 시스템이 주변 세계와 어떻게 상호 작용하는지 이해하도록 돕는 것이다. 어떤 점들을 고려해야 하는지 알도록 돕는 것이 여러분의 역할이다. 여러분은 조기에 적절한 옳은 질문을 던짐으로서 팀의 시간을 절약하도록 도울 수 있다. 테스트 자동화를 통해 발생하는 여유 시간을 활용해 팀이 개발 준비를 더 잘 할 수 있도록 해야 한다 – 여러분은 개발 초기부터 품질에 대해 더 많은 고려를 할 수 있게 된다.

Tip: 품질 분석가 역할과 품질 보증 역할을 병행히면서 여러분이 발견한 테스트 케이스들을 모두 자동화하자. 이를 통해 개발자들은 그들이 작성한 코드가 테스트 케이스를 만족하는지 알 수 있는 자동화 된 수단을 확보하게 된다.

품질 대사(Quality Ambassador)

개인적으로 이 표현을 가장 좋아한다. 품질은 QA가 전적으로 책임을 지는 것이 아니기 때문이다. 팀 전체가 품질을 중요하게 여기지 않는다면 새로운 기능의 릴리즈는 언제나 지연될 수밖에 없을 것이다(더 나쁜 것은 결함을 가진 소프트웨어가 그대로 릴리즈 되는 것이지만). 여러분은 팀 전체가 산출물의 품질에 대한 책임을 가질 수 있도록 도와야 한다. 필자가 함께 일해봤던 정말 뛰어난 QA들은 팀 전채가 품질을 중요하게 생각할 수 있도록 이끌었다. 그들이 가지고 있는 품질에 대한 지식을 팀과 공유하고 팀이 산출물의 품질을 높이는 습관을 들일 수 있도록 지원했다.

Tip: 품질 대사의 역할과 품질 분석가의 역할을 병행하면서 모든 사람의 품질 의식을 향상시켜서 개개인이 어떤 일을 해야하고, 어떻게 품질에 접근해야 할지 의식화하도록 돕기를 권한다.

여전이 QA의 일을 하고 있는가?

여러분은 불필요하거나 쓸모없는 사람이 아니다. 오히려 그 반대이다 – 테스트 자동화를 통해 여러분은 이전의 역할보다 더 중요한 역할을 수행할 수 있게 된다. 테스트 자동화를 통해 여러분의 업무를 종종 방해할 지 모르는 단순한 작업들을 수행하는 것이다. 이를 통해 확보된 시간을 사용해 보다 창의적으로 시스템을 테스트하는 방법을 생각하자. 테스터로서 살아가는 시간을 줄이고 여러분의 팀이 정말 필요로하는 품질 보증 전문가(Quality Assuarer),품질 분석가(Quality Analysit) 그리고 품질 대사(Quality Ambassator)로서의 삶을 사는 것이 어떻겠는가?