테스트 자동화는 왜 중요한가?
이유부터 알고 하자
모든 것은 애자일 방법론에서부터
Agile methodology (애자일 방법론)을 도입하려는, 도입한 이유를 확실히 짚고 넘어가 봐야 한다. 간단하게는 대부분 계속해서 지속적으로, 자주 유저에게 업데이트된 잘 작동되는 소프트웨어를 배포하고 싶고, 개발 중간 언제든지 요구사항의 변경에 대해 빠르게 대응할 수 있는 환경을 원하는 팀이 애자일을 도입한다.
애자일을 도입하면, 조금씩의 변경을 소프트웨어에 구현시키고 배포하는 것을 반복할 수 있게 된다. 장점은, 변경하는 양과 크기가 작기 때문에 문제 발생에 대한 리스크도 적어지며, 그에 따른 새로운 배포 버전의 안정성이 올라가게 된다.
기본적인 사이클을 보면 기획 + 디자인 + 개발 + 테스트이다. 이 사이클을 보다 빠르게 자주 하려면, 주어진 시간에 따라 기획, 디자인, 개발의 크기가 줄어들 수밖에 없다. 하지만 그렇다고 해서 테스트에 필요한 시간은 꼭 줄어들지 않는다.
어떠한 작은 코드 변경이라도, 매우 큰 리스크를 가지고 있을 수 있기 때문에, 충분한 리스크 분석 및 계획이 필요하고, 회귀 테스트를 수행해야 한다. 이 회귀 테스트는 보통 기능을 추가하면 할수록 그 양과 필요한 시간이 늘어난다. 다시 말해, 계속해서 배포를 한다면, 매 배포 당 테스트에 필요한 시간은 최소한 유지될 것이라는 것, 따라서 배포 횟수가 늘어나면, 그만큼 테스트에 필요한 시간은 늘어나는 것이다. 테스트가 이러한 부분에서 애자일 환경의 발목을 처음 잡았다. 빠르게 기획하고 디자인하고 개발을 해내도, 배포 전 테스트에 필요한 시간은 그대로였고, 배포는 자주 해도 이 부분은 변하지 않았다. 이에 맞춰 리스크 기반 테스팅, 탐색적 테스팅 등 여러 방법들이 도입되지만, 테스팅 방법은 때에 맞춰 변경될 수밖에 없다. 해서 이 시간을 최대한 줄이면서, 유용하게 쓸 수 있도록 해주는 것이 테스트 자동화였고, 애자일 방법론 안에서 중요한 부분을 차지하게 되었다.
애자일 팀 내에서 그때그때 개발하는 기능과 변화들에 맞게 효과적으로 분석하여 테스트 전략을 짜고 진행시켜야만 매번 배포가 효율적일 수 있다. 하지만 이 또한 매우 어려운 일이며, 각 팀마다 이를 잘 수행할, 테스터가 아닌 QA가 필요하다. 금전적 효율성인 방향으로 가는 팀은 개발자들이 테스트 자동화에 뛰어들기도 하지만, 대부분의 개발자들은 Quality Assurance에 대한 전문적 지식이 갖춰져있지 않기 때문에, 효율적으로 프로세스를 디자인하고 구축해내기에는 어렵다. 이 가운데에서 테스트 자동화와 프로세스 및 전략 수립을 동시에 할 수 있는 QA 자동화 엔지니어 포지션이 등장하여, 애자일 팀에 효율성을 높이고 최적화에 보탬이 되기도 한다.
발전이 더딘 이유
현재 애자일 환경에서 이행되는 QA 리소스 확립은 크게 4가지로 나뉠 수 있다. 1. 개발자가 개발과 동시에 자동화 테스트를 작성, Quality를 일임하고 따로 테스터를 두지 않는다. 2. Quality 관련 과정은 애자일에서 벗어나, 테스터들을 두고 개발 공정 마지막에서 직접 테스트를 한다. 3. QA 엔지니어 혹은 QA 자동화 엔지니어를 팀에 배치해, Quality 전략 수립 및 테스트 자동화를 보다 효율적으로 한다. 4. 대부분의 테스트는 사용자 피드백으로 대처한다.
4번을 이행하는 회사들이 의외로 많다. 하지만 사용자 수가 많다거나, 핀테크 같이 안정성과 보안성이 중요한 곳에서는 이런 식의 Quality Management는 불가능하다. 3번이 어찌 보면 가장 이상적인 옵션이지만, 이 일이 가능한 전문가들을 찾기가 힘든 것이 사실이다. 해서 대부분은 2번을 유지하며 3번으로 가기 위해 테스터들을 코칭해보기도 하지만, 테스터들에게서는 Quality 전략 수립에 대한 전문적 지식은 부족한 것이 사실이라 갈 길이 멀다. 이를 이미 인지한 몇몇 회사들은 1번 옵션으로, 오히려 개발자들에게 Quality 전략 수립에 대한 책임을 일임하기도 한다. 여기서도 개발자가 개발 및 전체적 Qualty 전략까지 전부 전문적이긴 어렵지만, 현재로선 테스터들이 자동화의 기술적인 부분을 배워 적용하는 것보다, 개발자가 자동화의 기술적인 부분을 배워 적용하는 것이 훨씬 빠르기 때문에 훨씬 더 효율적인 선택이다. 테스터를 둔 Quality만 워터폴 형식을 이룬 반-애자일 형식의 개발 환경을 유지한다면, 애자일 방법론의 지속적인 발전이라는 목표 상 다음 스텝으로의 발전이 매우 어렵게 되고, 반-애자일에서 머무르게 될 것이다.
전 세계적으로 아직은 시험적인, 그리고 부족한 QA 자동화 엔지니어 / Quality 엔지니어는 늘어나지 않는다. 그 이유가 뭘까? 1. 프로그래밍 기반이 없는 테스터에게는 높은 진입장벽. 2. 개발자에게는 한 발자국 뒤로 물러나는 듯 느껴지는 진입문과 인식. 3. 자동화 엔지니어 정도 기술이면 더 높은 연봉받고 개발자가 되는 것이 나은 현실. 메리트가 없고, 매력이 크게 느껴지지 않는, 중간에 있는 애매모호한 직종인 것이다. 이 문화는 마켓에서 변화를 주어야 한다. 해외에서는 이미 QA 엔지니어나 QA 자동화 엔지니어, Quality 엔지니어의 연봉은 개발자와 동급으로 계산된다. 한국에서는 아직 개발자의 연봉이 좀 더 높다. 더 나은 근무환경과 개발환경, 나의 발전을 위해서라면, 이러한 문화의 변화를 현 직종에 종사하는 회사들, 사람들이 책임감을 가지고서 널리 퍼질 수 있도록 해야 하는 것 아닐까 생각된다.
