최근에는 직접 서비스 개발보다는 전체적인 운영이나 관리를 하게 되면서, 소프트웨어 엔지니어링과 관련된 글들을 찾아보고 있습니다. ThoughtWorks라는 상당히 괜찮은 블로그를 재밌게 읽고 있는데, 생각해볼 만한 글이 있어 번역해보았습니다.
- 원본글은 ThoughtWorks > “Is QA Dead?”에서 살펴보실 수 있습니다.
번역을 한 이유는 크게 2가지 입니다.
- 제목이 마음에 들었습니다. ( 묘하게 TDD is dead가 떠오르는 제목 )
- 아래의 문장이 마음에 들어서 번역하게 되었습니다 :
“they check functionality, but checking alone does not add up to testing: testing = checking + exploring”
QA(Quality Assurance)는 더 이상 필요 없는가?
테스트 자동화(Test Automation)는 새로운 일이 아닙니다. 대부분의 소프트웨어 팀들이 여러 가지 방법으로 테스트를 자동화하기 위해 노력하고 있는데, 특히 매우 길고 수동으로 작업해야 하는 회귀 테스트(Regression Test)를 대체하기 위해 노력하고 있습니다. 만약 당신이 QA라면 아마도 당신은 이것이 당신의 역할에 어떤 영향을 줄 것인지 궁금할 것입니다. 모든 것을 자동화하는 세상에서 당신의 자리는 어디일까요? QA의 역할은 사라질까요?
일단 테스트 자동화의 명확한 이점들에 대해 이야기 하며 시작하도록 하겠습니다.
컴퓨터는 사람보다 빠르다
테스트 자동화의 이점 중 하나는 시스템을 테스트하는데 걸리는 시간을 비약적으로 감소시킨다는 것입니다. 당신이 테스트 스크립트를 한 번 만들기만 하면 스크립트는 1분도 지나지 않아 수 차례 동작할 것입니다.
심지어 이것은 다른 테스트와 병렬적으로 수행할 수도 있습니다. 회귀 테스트들을 자동화한 팀들은 머지않아 예전엔 며칠이나 걸렸던 대부분의 회귀 테스트를 수 분만에 끝낼 수 있다는 것을 알게 되었습니다. 그들은 조금 더 빠르게 자주 피드백을 받을 수 있었고, 그로인해 버그를 금방 찾아내고 빠르게 코드를 생산해 낼 수 있었습니다.
컴퓨터는 사람보다 일관성이 있다
인간은 실수를 합니다. 이것은 인간의 천성입니다. 숙련된 테스터도 같은 테스트를 수백 번 수행하면 일정 단계를 건너뛰거나 시나리오를 잊어버리는 일이 잦습니다. 당신은 아마도 특정 시나리오를 기록하는 것을 잊어버릴 것입니다. 자동화된 테스트는 살아있는 기록과 같습니다. 그것은 하겠다고 말한 것을 그대로 하고, 할 수 있는 것을 편차 없이 수없이 반복합니다.
이러한 이점들은 훌륭하고 팀들이 빠르게 양질의 소프트웨어를 만들 수 있도록 크게 돕습니다. 그러나 이러한 것들이 테스트 자동화의 가장 큰 이점은 아닙니다.
“테스트 자동화(Test Automation)의 가장 큰 이점은 QA(Quality Assurance)를 자유롭게 만들어 준다는 것이다.”
점검(Checking)은 테스트(Testing)가 아니다
2015년 OnAgile 컨퍼런스 Elisabeth Hendrickson는 자동화된 테스트들의 역할 대해 말하며 매우 유용한 구분법을 만들어냈습니다. “자동화된 테스트들은 기능적으로 점검할 뿐입니다. 점검만 하는 것은 테스트라 할 수 없습니다.”
“테스트(Testing)” = “점검(Checking)” + “탐색(Exploring)”
자동화된 테스트들은 멍청합니다. 우리는 그것들이 우리가 이미 알고 있는 시나리오들을 점검하도록 만듭니다. 자동화된 테스들은 우리가 기대하고 있는 시나리오에 따라 시스템이 동작하고 있는지 점검합니다. 이러한 시나리오는 어디서 왔을까요? 시스템에서 무엇이 잘못 될 수 있는지 이해하는 것에서 부터 왔을 것입니다. 그러면 누가 시스템을 이해하고 있을까요? 바로 당신입니다.
인간이 컴퓨터보다 항상 잘하는 것이 두 가지 있습니다. 창조성과 학습입니다. 이 두 가지 요소가 우리가 탐색적 테스트(Exploratory Testing)라고 부르는 것을 구성합니다. 우리는 시스템을 탐색할 때 우리가 상호작용할 수 있는 흔치 않은 방법들에 대해 생각합니다. 이렇게 함으로써 우리는 시스템이 어떻게 동작하는지 관찰할 수 있습니다. Hendrickson은 이러한 관찰들로부터 우리가 다음에 무언가 테스트 할 때 무엇을 테스트해야 하는지 학습할 수 있다고 말했습니다.
자동화된 테스트는 당신이 이미 존재할 가능성이 있다고 생각하고 있는 버그들을 점검합니다. 수동으로 진행하는 탐색적 테스트는 당신이 모르는 버그들을 찾아냅니다. 테스트 자동화는 당신을 자유롭게 만들어 당신이 이미 하고 있는 기계적 반복에 의한 점검이 아닌 탐색적 테스트를 더 할 수 있도록 만들 것입니다. 새로운 버그를 찾아낼 때 마다 당신은 이 버그를 점검하는 것을 자동화 할 수 있습니다. 이렇게 함으로써 당신은 수동으로 테스트하는 것을 반복하지 않고 다른 약점들을 찾아낼 수 있습니다.
QA(Quality Assurance)는 무엇을 의미하는가?
당신의 직책은 QA지만 종종 테스터로 취급받습니다. 사실 당신은 테스트 말고 더 많은 것을 하는데 말입니다. QA는 무엇을 의미할까요? 저는 이 질문에 대해 몇몇 다른 대답들을 들었지만 모든 대답들이 맞습니다. 모든 대답들이 QA의 필수적 역할의 다른 측면들을 보여주고 있습니다.
Quality Assurance
Quality Assurance라는 용어는 옛 직책인 품질 관리(Quality Control)에서 나왔습니다. 품질 관리라는 용어는 생산 산업에서 나왔습니다. 제품은 모든 생산라인을 거쳐 품질 관리자(Quality Controller)에게 도착합니다. 그들은 제품에 결함이 있는지 확인합니다. 만약 제품에 결함이 있다면, 제품은 버려지거나 결함을 수정해야 합니다. 만약 괜찮다면, 제품은 소비자에게로 가게 됩니다.
토요타는 다른 방식으로 일하기로 결정했습니다. 그들은 자동차를 생산하는 과정에서 품질을 확보하기 위해 우리가 린 방식(Lean Practice)라고 부르는 것을 사용하였습니다. 이것의 목적은 모든 생산과정에서 품질을 향상시켜 제품의 불량률을 줄이는 것이었습니다.
QA의 한 가지 역할은 소프트웨어 개발과정에서 품질을 확보할 수 있도록 돕는 것입니다. 당신은 품질 관리자가 되고 싶진 않을 것입니다. 당신은 낮은 품질 때문에 새로운 생산물을 버려야만 하는 일이 벌어지는 것을 원치 않을 것입니다. 당신은 높은 품질의 생산물을 쉽게 만들도록 도울 수 있습니다. 당신은 개발팀은 실수 할 수 있는 자동화 테스트를 위한 시나리오를 쓰는데 도움을 줌으로써 이것을 가능하게 할 수 있습니다. 당신은 개발자가 생산물이 우리가 알고 있는 모든 까다로운 시나리오를 다 통과할 수 있는지 알고 일하도록 하는 안전장치를 만들 수 있습니다. 당신은 심지어 개발자가 일을 시작하기도 전에 개발자와 함께 테스트를 만들 수도 있습니다.
품질 분석가(Quality Analyst)
소프트웨어를 개발하는 것은 쉽지 않습니다. 몇몇의 어려움은 컴퓨터 프로그래밍의 특성 때문이지만, 대부분의 어려움은 시스템의 상호작용 때문입니다. 당신의 시스템은 이해하기 힘든 다른 시스템들과 소통해야할 필요가 있습니다. 사용자들은 생각지도 못했던 행동들을 하고, 네트워크와 컴퓨터 인프라는 예측할 수 없는 방식으로 다운되기도 합니다.
당신의 역할중 하나는 팀을 도와 이러한 세계를 어떻게 다루어야 하는지 알고 있는 소프트웨어를 개발하는 것입니다. 고려해야 하는 올바른 것들은 무엇인지 알 수 있도록 돕는 것이 당신의 일입니다. 당신은 올바른 질문을 미리 함으로써 당신의 팀의 시간을 절약할 수 있습니다. 자동화는 당신을 자유롭게 만들어 당신이 팀이 일을 준비하도록 돕는데 시간을 더 많이 할애하게 만들고, 진행 단계 초입부터 품질을 향상시키도록 만들 것입니다.
팁: 이것을 QA로서 당신의 역할과 연결시키십시오. 그리고 당신이 발견한 테스트 케이스들을 자동화 하십시오. 그렇게 한다면 개발자들은 그들의 코드가 테스트 케이스를 만족하는지 못하는지 자동화된 방법으로 점검할 수 있을 것입니다.
품질 대사(Quality Ambassador)
저는 이 역할이 좋습니다. 품질은 QA만 책임져야 할 일이 아닙니다. 만약 팀 전체가 품질에 대해 심각하게 고려하지 않는다면, 새로운 생산물은 항상 지연될 것입니다(혹은 좋지 않거나, 버그가 가득한 소프트웨어로 배포될 것입니다). 당신이 할 일은 팀 전체가 일을 할 때 품질을 갖출 수 있도록 하는 것입니다.
제가 함께 일해 본 가장 훌륭한 QA는 팀 전체가 품질을 고려하도록 고취시켰습니다. 그들은 가까이서 일하며 서로의 지식을 나누었고, 업무의 질을 향상시킬 수 있는 습관들을 다른 사람들이 배우게끔 자극하였습니다.
팁: 이것을 품질 분석가로서 당신의 역할과 연결시키십시오. 그리고 팀원 모두의 품질에 대한 이해를 확장시켜 어떤 일을 해야 하는지 어떻게 접근해야 하는지 생각할 수 있도록 도우십시오.
그래서 당신은 여전히 일할 것이 있습니까?
당신은 쓸모없지 않습니다. 오히려 테스트 자동화는 당신의 역할에 이전보다 더 큰 권한을 주었습니다. 자동화는 당신이 때때로 막혔던 반복적 점검을 대체할 수 있습니다. 당신은 자유로워 질 것이고, 당신의 창조성을 이용해 시스템을 테스트할 새로운 방식을 탐색할 것입니다. 당신은 테스터로써 일하는 시간이 줄어들고, 더 많은 시간을 팀원들이 필요로 하는 품질 보증인, 품질 분석가, 품질 대사로서 일할 수 있을 것입니다.
