2021년 테스트 자동화 트렌드 리포트 (上)

본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반 번역문입니다. 웹 및 모바일 앱을 위한 지속적인 테스트 플랫폼 및 도구를 제공하는 퍼펙토(Perfecto)에서 발행한 글입니다. 작가는 퍼펙토의 직원일 것으로 추정됩니다. 본문은 디지털 플랫폼 기업에 대한 테스트 자동화 트렌드 리포트로 많은 기업들이 테스트를 어떻게 진행하고 있는지 함께 살펴보겠습니다. (내용이 길어 1,2편으로 나누어 소개하겠습니다!)

안녕하세요, 2021년 테스트 자동화(Test Automation) 보고서입니다.

준비가 되었든 그렇지 않든, 디지털 플랫폼은 2020년에 고성능 웹 애플리케이션과 모바일 앱 분야의 규모를 키웠고, 원격으로 테스트할 수 있는 능력을 갖추게 되면서 세상의 중심적인 위치를 차지하게 되었습니다. 그렇다면 현재의 상황은 어떨까요? 오늘날의 진취적인 기업들은 어떤 모습일까요? 그들은 어떤 부분에 초점을 맞추고 있을까요? 이를 밝혀내기 위해서, 저희는 다양한 분야에서 활약하고 있는 700개 이상의 주요한 디지털 기업들을 대상으로 설문조사를 실시했습니다. 이 글에서는 그 결과를 설명하고, 테스트 기법이 변화하고 있는 양상에 대해서도 살펴보겠습니다.

핵심 요약

• 개발팀들은 적용 범위를 넓히고 자동화의 수준을 더욱 높이는 데 초점을 맞추고 있습니다. 응답자들의 절반은 출시 일정이 더욱 빨라졌음에도 불구하고 전체적인 테스트의 절반 정도는 자동화를 하고 있었습니다. 2021년에도 비슷한 방식으로 변화하고 있습니다.
• 시프트 레프트(shift left)[1] 기법이 빠르게 트렌드로 자리를 잡고 있습니다. 이러한 움직임은 더욱 빨라진 릴리즈(새로운 버전의 출시) 주기와 연관이 있습니다. 주로 규모가 큰 조직들이 이런 트렌드를 주도하고 있습니다.
• 기술이 더욱 향상되면서 자동화 분야의 격차가 해소되고 있습니다. 출시 주기 안에서 자동화의 수준이 점점 더 고도화되면서, 선도적인 조직들은 행위주도개발(behavior driven development, BDD)[2]이나 스크립트리스(scriptless)[3]솔루션 등을 검토하고 있습니다.
• 경영진과 실무자들의 상황은 다릅니다. C레벨[4]이나 부사장 급의 임원들은 실무자들보다 자신들의 자동화 수준이 더욱 높다고 생각하고 있습니다. 2021년의 투자 우선순위를 정하기 위해서는 서로 간에 논의가 필요해 보입니다.

테스트 업무가 개발 담당 부서로 이동하고 있다

올해에는 대부분의 테스트가 개발을 지원하는 내부의 품질보증(QA) 부서에서 수행되었습니다.

조직 내에서 테스트를 책임지고 있는 이들은 누구인가요?

45% - 개발팀에 속한 내부의 QA & 테스트 자원

33% - 개발을 지원하는 내부의 QA

17% - 개발팀에 속한 테스트 자원

2% - 외부의 서비스 통합 업체에 테스트를 아웃소싱

개발팀에 속한 내부의 테스트 자원에게 의존하는 기업들은 다음과 같은 테스트 방식을 따를 가능성이 적었습니다.

• 자동화된 소프트웨어 테스트
• 지속적인 테스트(continuous testing, CT)[5], 지속적인 통합(continuous integration, CI)[6], 지속적인 전달(continuous delivery, CD)[7]
• 행위 주도 개발(behavior driven development, BDD)

개발을 지원하는 내부의 QA에 의존하는 기업들은 다음에 해당할 가능성이 높았습니다.

• 매일 또는 매주 릴리즈한다.
• 테스트의 50% 이상을 자동화한다.
• 오픈소스 기술에 의존한다.
• 소프트웨어 스프린트(sprint)[8]가 시작될 때마다 테스트를 수행한다.

테스트를 아웃 소싱해서 수행하고 있는 조직은 테스트를 안정적으로 수행하는데 어려움을 겪을 가능성이 가장 높았습니다. 조직의 내부에 QA 팀과 테스트 자원을 모두 갖추고 있는 팀들은 테스트를 시프트 레프트(shift left) 방식으로 전환할 가능성이 가장 높았습니다.

개발팀을 가장 힘들게 하는 것은 테스트 자동화를 생성하는 것, 그리고 적용 가능한 범위가 제한되어 있다는 것이다.

업계 전반에 걸쳐서, 기업들이 마주한 가장 커다란 어려움은 테스트 자동화를 생성하기 위한 자원이 부족하다는 것이었고, 그다음으로 근소하게 뒤따르는 문제는 테스트 자동화 시나리오를 적용할 수 있을 만한 범위가 제한되어 있다는 것이었습니다.

테스트에 있어서 가장 어려운 부분은 무엇인가요?

20% - 완전한 테스트 자동화 대상 영역을 찾아내는 것

14% - 우선순위가 정해지지 않은 테스트

4% - 기타

23% - 테스트 자동화를 생성할 수 있는 자원의 부족

19% - 테스트의 불안정성/테스트 결과의 오류

11% - 실험 기반 구축 & 유지관리

9% - 테스트 실패의 원인을 해석하는 것

각 집단 별로 나뉘는 답변

가장 큰 어려움은 각자의 역할에 따라서도 달랐습니다.

<개발팀의 고충>

1. 테스트를 위한 우선순위의 결여
2. 테스트 자동화 생성을 위한 자원의 부족
3. 테스트의 신뢰도

<QA 부서의 고충>

1. 테스트 자동화 생성을 위한 자원의 부족
2. 적절한 테스트 영역을 찾는 것
3. 테스트의 신뢰도

자동화의 성숙도 수준에 따라서도 어려움이 달랐습니다.

자동화 수준이 테스트 케이스의 10% 미만인 조직의 경우

• 실험 환경을 유지 관리하는 데 어려움이 있고, 테스트 자체에 있어서도 우선순위가 결여되어 있을 가능성이 높았습니다.
• 1년에 1-2회 정도만 릴리즈 할 가능성이 높았습니다.
• 행위 주도 개발 방식을 시행할 가능성이 낮았습니다.
• 지속적인 테스트, 지속적인 통합, 지속적인 전달을 달성할 가능성이 낮았습니다.

상황이 그 정반대에 해당하며, 시프트 레프트 기법을 시행하고 있거나 자동화 수준이 테스트 케이스의 50%를 넘는 조직의 경우

• 테스트 결과의 오류나 신뢰도의 문제, 테스트의 불안정성과 같은 어려움을 겪을 가능성이 낮았습니다.
• 스크립트(테스트 코드) 유지관리, 테스트 환경 구축, 테스트 실패 분석 등의 업무에 더욱 많은 시간을 투입하고 있었습니다.
• 매일 또는 매주 릴리즈 할 가능성이 높았습니다.

테스트 자동화 생성 및 대상 영역에 대한 솔루션

테스트 자동화 생성과 관련한 문제에 더욱 효율적으로 대처하기 위해서, 기업들은 조직의 구성원들이 갖고 있는 역량에 맞는 도구를 선택할 필요가 있습니다. 그러면 더욱 많은 구성원들이 테스트 자동화 생성 프로세스에 참여할 수 있습니다. 또한 테스트 시나리오를 적용할 수 있는 대상의 범위도 더욱 넓힐 수 있습니다.

테스트 기반을 적용할 수 있는 범위를 넓히기 위해서, 기업들은 다음과 같은 두 가지의 시도를 해볼 수 있습니다.

• 자체적인 DIY 방식의 실험 환경이 아니라 상용 클라우드 기반의 솔루션으로 테스트를 수행한다.
• 테스트의 적용 범위를 리스크 기반으로 정하는 대신에, 데이터 위주로 결정하는 전략을 수립한다.

개발이 완료될 때까지 테스트를 미뤄두고 있는 팀들이 더 많았다

성공적인 조직은 자신들의 개발 프로세스 안에 테스트 자동화를 배치할 수 있는 역량을 갖추고 있으며, 그로부터 더욱 빠른 피드백을 얻어낼 수 있습니다. 저희의 연구에 의하면, 대상 기업들의 70% 이상이 여전히 그러한 목표를 달성하기 위해서 고군분투하고 있는 것으로 나타났습니다. 또한 다양한 부서들 간의 더욱 효과적인 협업과 조정이 필요한 것으로 드러났습니다.

소프트웨어 개발 수명주기(SDLC)[11] 내에서 테스트 단계는 어디에 위치하고 있나요?

42% - 소프트웨어 스프린트가 시작될 때마다

71% - 신규 빌드(build)[12]가 준비된 이후

54% - 각 코드의 변경사항에 대해서

12% - 스프린트 일정 내에서 수행하지 못하지만, 전체 개발 과정에는 포함되어 있음

뛰어난 데브옵스 조직이 되기 위해서는, 모든 점검 항목들을 자동으로 확인할 수 있어야 합니다. 사람이 개입해서 해야 할 일이 많아질수록, 프로세스는 더욱 느려지게 됩니다. 이를 위한 한 가지의 대안을 제시하자면 이런 형태일 것입니다. 즉, 테스트 엔지니어가 테스트를 시작하기 위해서 새로운 빌드가 준비될 때까지 기다리는 것이 아니라, 태그(tag)[13]버전 이외에도 테스트 자동화를 위한 별도의 브랜치(branch)[14]를 생성해서 테스트 엔지니어들이 개발의 초기 단계부터 해당 버전에 액세스 할 수 있게 허용하는 것입니다. 그러면 테스트 자동화 업무를 병행해서 시작할 수 있습니다.

코로나 19와 원격 업무가 조직의 속도를 느리게 만들었다

응답한 기업들 중에서 매일 릴리즈 한다는 곳은 9%에 불과했는데, 이는 지난해의 14%에서 줄어든 것입니다. 2020년 전반에 걸쳐서 널리 활용되기 시작한 원격 테스트와 관련한 어려움 때문에 조직의 속도가 느려진 것으로 보입니다.

일반적인 릴리즈 주기는 어떤가요?

9% - 매일

39% - 매주

33% - 매달

14% - 분기마다

4% - 연간 1-2회

더 자주 릴리즈 하는 방법

보다 자주 릴리즈 하기 위한 방법은 코드의 작성, 빌드, 통합, 테스트, 전개(deploy)[15]에서부터 소프트웨어의 실제 양산 과정에 이르기까지의 전체적인 개발 프로세스에 따라서 다를 수 있습니다. 중간에 일시적으로 작업이 중단되거나 자동화가 되지 않았을 경우에는 전체적인 프로세스가 느려지며 릴리즈 일정이 지연될 수 있습니다.

본 연구에서는 테스트 자동화에 대해서만 초점을 맞추고 있기는 하지만, 실제 현실에서는 자동화가 이루어져야 할 부분이 훨씬 더 많습니다. 자동화라는 것은 단지 하나의 팀에서만 필요한 게 아니라 데브옵스 조직 전체의 우선순위가 되어야 합니다. 개발 과정 내의 다양한 구성원들 사이를 연결시켜 주는 것은 적절한 프로세스와 기술을 통해서 가능합니다. 그리고 이러한 프로세스와 기술은 경영진이 판단한 우선순위를 근거로 선택되는 것입니다.

수동 테스트는 시프트 레프트 전략으로의 이행을 늦춘다

테스트 방식을 시프트 레프트로 전환하고 싶지만 실무에서는 수동으로 테스트를 하고 있다면 그 목표를 달성하기가 어렵습니다. 현실에서는 소프트웨어의 개발과 테스트를 반복하는 과정에서 수동 테스트와 탐색적 테스트(exploratory testing)[16]를 적절하게 혼합해서 사용하는 것이 권장되는 경우가 많기 때문에, 어쩔 수 없이 어느 정도는 수동으로 테스트가 이루어집니다. 그러나 시프트 레프트 방식으로 좀 더 자동화된 테스트일수록 그 효율성이 더욱 뛰어납니다.

테스트 과정 내에서 가장 시간이 많이 소요되는 작업은 무엇인가요?

20% - 테스트 과정 분석

18% - 테스트 환경 구성

29% - 수동 테스트

16% - 고급 스크립트 작성

13% - 스크립트 유지관리

응답한 기업들의 거의 10%는 여전히 모든 테스트 과정을 수동으로만 진행하고 있었습니다. 그 외의 20%는 이제 막 자동화를 시작하고 있었습니다. 그리고 자동화된 비율이 전체 테스트의 50%에 못 미친다고 응답한 기업들도 47%에 달했습니다.

수동 테스트를 하면서 어려움을 겪고 있는 기업들의 특징은 다음과 같습니다.

• 릴리즈 주기 내에서 테스트 케이스의 10% 이하만 자동화하고 있을 가능성이 더 높았습니다.
• 신규 빌드가 준비될 때까지 테스트를 미뤄두고 있을 가능성이 더 높았습니다.
• 1년에 1-2회만 릴리즈 할 가능성이 더 높았습니다.
• 오픈소스 기술에 의존하고 있을 가능성이 더 높았습니다.

다음 편에서는 모바일 자동화 테스트에 대한 내용과 2021년 트렌드 전망에 대해서도 함께 살펴보겠습니다.

[1] 소프트웨어 개발 주기에서 테스트를 시작하는 시점을 일찍 앞으로 당겨서 오류나 결함의 수정에 드는 비용을 획기적으로 절감하는 기법. 개발 프로세스를 도표로 나타낸 그림에서 테스트 과정이 위치한 부분을 왼쪽(left)으로 이동(shift)하는 것이어서 이렇게 부릅니다.

[2] 유저 스토리를 기반으로 테스트 코드를 작성하고 결과를 검증하는 개발 방식

[3] 코드나 스크립트를 직접 작성하지 않고 테스트 등을 자동화하는 기법

[4] CEO, CTO, COO 등 직함의 앞에 C가 붙는 고위급 임원들

[5] 소프트웨어 개발 과정에서 자동화된 테스트를 동시에 수행함으로써 발생할 수 있는 리스크를 미리 발견하는 기법

[6] 개발 과정에서 구현과 테스트를 통합해서 효율적으로 진행하는 기법

[7] 언제든지 빠르게 원하는 소프트웨어를 출시할 수 있게 하는 기법

[8] 어떤 과제를 해결하거나 결과를 도출하기 위해서 1-4주 정도의 짧은 기간 동안 집중적으로 운영되는 프로젝트

[9] 끊임 없이 변화하는 환경에서 살아남기 위해서 조직을 기민하게 만들어서 운용하는 기법

[10] 프로젝트에서 개발(development)과 운영(operation) 부문을 하나로 통합해서 개발하는 방식

[11] 소프트웨어를 기획하고, 구현하고, 테스트하고, 배포하는 과정까지 이어지는 일련의 프로세스

[12] 실행 가능한 형태로 소프트웨어를 완성하는 것

[13] 소프트웨어 개발의 중심이 되는 소스 코드

[14] 소프트웨어 개발 과정에서 테스트 등을 위해서 만드는 별도 버전의 소스 코드

[15] 소프트웨어나 코드를 본격적으로 이용할 수 있게 하는 전반적인 활동

[16] 테스트 케이스를 문서로 작성하지 않고 경험에 근거를 두고 탐구하듯이 테스트를 하는 기법

[17] 테스트를 통한 코드의 검증을 중시하는 소프트웨어 개발 기법

> 이 글은 'Psychological principles for every product designer'을 각색하여 작성되었습니다.