2020.07.06

“비즈니스 가치 극대화를 위한” 지속적 테스트 전략의 정의와 베스트 프랙티스

Isaac Sacolick | InfoWorld
지속적 테스트는 실행 방법이자 사고방식이다. 개발자와 품질 보증 전문가는 데브옵스 CI/CD(지속적 통합/지속적 개발) 파이프라인에서 지속적 테스트를 게시하면서 모든 빌드와 딜리버리(build and delivery)에 실행되는 자동화된 테스트 목록을 트리거한다. 이 사고방식의 핵심은 개발자와 엔지니어, 품질 보증 전문가가 테스트 전략과 구현에서 협업하는 데 있다.
 
ⓒ Getty Images Bank

이 협업은 매우 중요하다. 많은 기술 조직이 충분한 테스트를 위해 자금을 지원하거나 전담 리소스를 투입하거나 따로 시간을 마련하는 데 인색하기 때문이다. 따라서 개발팀은 제약 내에서 최적의 초점, 구현 전략 및 지속적인 지원 기능을 정의하는 테스트 전략을 수립해야 한다.

개발팀은 전체적인 테스트 전략을 수립해야 하지만, 다음과 같은 이유로 지속적 테스트에 국한된 전략도 필요하다.
 
  • 지속적 테스트는 코드가 딜리버리 환경에 도달하기 전에 개발자에게 피드백을 제공하므로 시프트-레프트(shift-left) 전략을 구현하는 최적의 방법이다. 특히 개발자가 더 나은 코딩 방법을 배우고 채택하도록 코드 품질 및 보안 분석을 실행하는 데 있어 중요하다.
  • 지속적 테스트는 먼저 자동화하고, CI/CD 파이프라인에 통합하고, 알림을 구성해서 각 툴이 발견한 문제를 적절한 담당자에게 알리도록 해야 하므로 투자 비용이 클 수 있다.
  • 테스트는 빌드와 딜리버리 중에 실행되므로 팀은 구현할 테스트의 유형을 선별하고 실행 기간을 고려해야 한다. 장시간 실행되는 테스트가 개발자 작업 및 빌드 파이프라인의 속도를 저하시킨다면 지속적 테스트에 적합하지 않다.

타협점과 구현을 위한 선택을 점검하고 팀이 솔루션을 위해 협업하는 최선의 방법은 하나의 지속적 테스트 전략에 따라 발을 맞춰 움직이는 것이다.
 

페르소나 기반 테스트 전략 정의

애자일 접근 방법을 사용해서 지속적 테스트 전략을 정의해 보자. 제품 소유자가 애자일 사용자 스토리를 작성하는 최선의 방법은 가치를 받고 구현의 혜택을 보는 최종 사용자의 관점에서 스토리를 쓰는 것이다. 스토리는 애자일 개발팀에 고객이 누구인지, 그 고객에게 구현이 중요한 이유가 무엇인지, 그리고 고객이 어떻게 혜택을 받는지를 상기시키기 위해 “특정 사용자 유형 또는 사용자 페르소나로서”라는 문구로 시작하는 경우가 많다.

지속적 테스트에는 테스트를 통해 혜택을 보는 다양한 사람들이 있고 구현할 테스트의 유형에 우선 순위를 부여해야 하므로 페르소나 정의가 전략의 기반이 되어야 한다. 페르소나 또는 이해당사자와 이들이 관심을 갖는 위험 요소에는 다음이 포함된다.
  • 개발자 : 코드 품질, 그리고 자신의 코드 수정이 그 코드에 종속성을 가진 서비스 또는 코드의 다른 영역을 손상시키지 않음을 보장하고자 한다.
  • 운영팀 : 코드 변경이 성능 문제를 일으키거나 애플리케이션의 안정성에 영향을 미치지 않기를 원한다.
  • 정보보안팀 : 정적 코드 분석, 침투 테스트, 그리고 새 코드나 기타 변경이 보안 위험을 유발하는지 여부를 알리는 기타 조기 지표에 관심을 갖는다.
  • 품질 보증 전문가 : 애플리케이션 최종 사용자와 제품 소유자의 관심을 대변한다. 새로운 기능, 변경 및 기존 기능이 모두 비즈니스 요구 사항을 충족하는지 검증하기 위한 API, 기능, 브라우저 및 모바일 사용자 인터페이스 테스트가 이들의 최대 관심 영역이다.
  • 설계자 : 서비스 및 API 품질을 대변하며 신규 또는 변경된 프로토콜이 품질 문제를 나타내는지 여부에 대한 표준을 정의하기에 가장 적임이다
  • 데이터베이스 거버넌스 전문가 : 개발자가 의도하지 않게 빌드에 데이터 품질 또는 보안 관련 문제를 일으키는지 여부에 관심을 갖는다. 

애자일 개발팀은 CI/CD 빌드가 실패할 때 대응하고 문제를 교정해야 하지만, 이제 테스트에서는 이해당사자 역할을 하는 정의된 페르소나가 중요하다. 이해당사자는 파이프라인 초기, 그리고 진행 중에 개발자에게 전달해야 할 위험과 문제를 대상으로 우선 순위를 정해야 한다.
 

지속적 테스트 구현 전략

앞서 살펴봤듯이 자동화된 테스트라고 해서 모두 지속적 테스트에 잘 맞는 것은 아니다. 먼저 테스트를 실행하기 위한 툴이 젠킨스(Jenkins), 서클CI(CircleCI), 뱀부(Bamboo) 또는 다른 주요 CI/CD 툴과 원활하게 통합돼야 한다. 팀이 CI/CD 파이프라인에 테스트를 통합하는 데 너무 많은 노력을 쏟아야 한다면, 비즈니스에 중요한 다른 부분과 기술적 작업이 밀려나게 된다. 스마트베어(SmartBear), 블레이즈미터(BlazeMeter), 트리센티스 큐테스트(Tricentis qTest), 브라우저스택(BrowserStack), 소스랩(SauceLabs), 포스트맨(Postman)을 비롯한 많은 툴에는 젠킨스를 위한 통합과 플러그인이 있다.

둘째, 지속적 테스트에는 자동화된 테스트를 실행하기 위한 적절한 컴퓨팅 환경이 필요하다. 수동으로 구성되는 개발, 테스트, 프로덕션 환경을 사용하는 조직은 각 환경 간에 구성과 인프라 변경을 동기화하는 데 어려움을 겪는 경우가 많다. 가능한 경우 지속적 테스트에 투자하기 전에 환경을 표준화하고 퍼펫(Puppet), 셰프(Chef) 또는 앤서블(Ansible)과 같은 코드형 인프라 툴을 사용해서 구성을 관리하는 것이 좋다.

마지막으로, 지속적 테스트는 손쉽게 자동화하고 적절한 기간 동안 실행할 수 있어야 하며, 정의된 통과 또는 실패 조건과 문제 해결을 위한 구체적인 경로가 있어야 한다. 예를 들어 수천 개의 테스트 시나리오를 거치는 기능 테스트는 실행하는 데 너무 오랜 시간이 걸릴 수 있으므로 예약된 작업으로 야간에 실행하는 편이 더 낫다. 경고 알림이 많은 보안 테스트는 빌드 파이프라인을 멈추지 않도록 정보보안 담당자가 검토해야 한다. 문제를 유발한 코드, 개발자 또는 팀을 쉽게 추적할 수 없는 데이터 품질 테스트는 모든 단계의 빌드를 중단시키고 문제 검토에 대규모 팀이 필요할 수 있으므로 CI/CD 파이프라인에 있으면 안 된다.

베스트 프랙티스 연구도 중요하다. 예를 들어 지속적 테스트에 관해 트리센티스(Tricentis)가 제안하는 14가지 요점은 테스트가 변경 사항을 환경으로 푸시하기 전 단계의 안전망 역할을 하고, 조치 가능한 피드백을 제공하고, 딜리버리 파이프라인의 적절한 단계에 맞는 적절한 일련의 유효성 검사를 수행할 것을 제안한다. 지속적 테스트가 제대로 되지 않고 있음을 나타내는 징후도 있다. 예를 들어 사용자 인터페이스 테스트에 대한 과도한 투자나 테스트 데이터 관리가 자동화되지 않은 경우가 여기에 해당된다.
 

지속적 테스트에 우선 순위를 부여할 때 애자일 원칙 사용

팀 전체가 지속적 테스트 전략에 동의하고 나면, 팀은 제안된 테스트의 혜택과 제약을 모두 고려해서 작업의 우선 순위를 정해야 한다. 이해당사자들은 각자 권장하는 테스트에 우선 순위를 부여하고 테스트에서 다루는 위험을 기준으로 중요도 순위를 정해야 한다. 애자일팀은 테스트가 CI/CD 파이프라인에 통합하기에 적합한지 여부를 판단한 다음 구현을 추산해야 한다. 마지막으로, 테스트가 너무 많으면 빌드 속도가 저하되거나 필요한 인프라 요건이 높아질 수 있으므로 테스트를 카탈로그화하는 것이 중요하다.

지속적 테스트에 대한 투자는 협업 개선과 더 높은 품질의 소프트웨어로 이어지지만, 이를 위해서는 우선 순위와 범위, 구현 세부 사항에 관한 정렬이 필요하다. 페르소나 정의, 가치 우선 순위 부여, 개발 추산, 구현 지원을 위한 전략을 정의하고 애자일 원칙을 활용하는 팀은 테스트를 통해 위험을 낮추고 가치를 제공할 가능성이 높다. editor@itworld.co.kr


2020.07.06

“비즈니스 가치 극대화를 위한” 지속적 테스트 전략의 정의와 베스트 프랙티스

Isaac Sacolick | InfoWorld
지속적 테스트는 실행 방법이자 사고방식이다. 개발자와 품질 보증 전문가는 데브옵스 CI/CD(지속적 통합/지속적 개발) 파이프라인에서 지속적 테스트를 게시하면서 모든 빌드와 딜리버리(build and delivery)에 실행되는 자동화된 테스트 목록을 트리거한다. 이 사고방식의 핵심은 개발자와 엔지니어, 품질 보증 전문가가 테스트 전략과 구현에서 협업하는 데 있다.
 
ⓒ Getty Images Bank

이 협업은 매우 중요하다. 많은 기술 조직이 충분한 테스트를 위해 자금을 지원하거나 전담 리소스를 투입하거나 따로 시간을 마련하는 데 인색하기 때문이다. 따라서 개발팀은 제약 내에서 최적의 초점, 구현 전략 및 지속적인 지원 기능을 정의하는 테스트 전략을 수립해야 한다.

개발팀은 전체적인 테스트 전략을 수립해야 하지만, 다음과 같은 이유로 지속적 테스트에 국한된 전략도 필요하다.
 
  • 지속적 테스트는 코드가 딜리버리 환경에 도달하기 전에 개발자에게 피드백을 제공하므로 시프트-레프트(shift-left) 전략을 구현하는 최적의 방법이다. 특히 개발자가 더 나은 코딩 방법을 배우고 채택하도록 코드 품질 및 보안 분석을 실행하는 데 있어 중요하다.
  • 지속적 테스트는 먼저 자동화하고, CI/CD 파이프라인에 통합하고, 알림을 구성해서 각 툴이 발견한 문제를 적절한 담당자에게 알리도록 해야 하므로 투자 비용이 클 수 있다.
  • 테스트는 빌드와 딜리버리 중에 실행되므로 팀은 구현할 테스트의 유형을 선별하고 실행 기간을 고려해야 한다. 장시간 실행되는 테스트가 개발자 작업 및 빌드 파이프라인의 속도를 저하시킨다면 지속적 테스트에 적합하지 않다.

타협점과 구현을 위한 선택을 점검하고 팀이 솔루션을 위해 협업하는 최선의 방법은 하나의 지속적 테스트 전략에 따라 발을 맞춰 움직이는 것이다.
 

페르소나 기반 테스트 전략 정의

애자일 접근 방법을 사용해서 지속적 테스트 전략을 정의해 보자. 제품 소유자가 애자일 사용자 스토리를 작성하는 최선의 방법은 가치를 받고 구현의 혜택을 보는 최종 사용자의 관점에서 스토리를 쓰는 것이다. 스토리는 애자일 개발팀에 고객이 누구인지, 그 고객에게 구현이 중요한 이유가 무엇인지, 그리고 고객이 어떻게 혜택을 받는지를 상기시키기 위해 “특정 사용자 유형 또는 사용자 페르소나로서”라는 문구로 시작하는 경우가 많다.

지속적 테스트에는 테스트를 통해 혜택을 보는 다양한 사람들이 있고 구현할 테스트의 유형에 우선 순위를 부여해야 하므로 페르소나 정의가 전략의 기반이 되어야 한다. 페르소나 또는 이해당사자와 이들이 관심을 갖는 위험 요소에는 다음이 포함된다.
  • 개발자 : 코드 품질, 그리고 자신의 코드 수정이 그 코드에 종속성을 가진 서비스 또는 코드의 다른 영역을 손상시키지 않음을 보장하고자 한다.
  • 운영팀 : 코드 변경이 성능 문제를 일으키거나 애플리케이션의 안정성에 영향을 미치지 않기를 원한다.
  • 정보보안팀 : 정적 코드 분석, 침투 테스트, 그리고 새 코드나 기타 변경이 보안 위험을 유발하는지 여부를 알리는 기타 조기 지표에 관심을 갖는다.
  • 품질 보증 전문가 : 애플리케이션 최종 사용자와 제품 소유자의 관심을 대변한다. 새로운 기능, 변경 및 기존 기능이 모두 비즈니스 요구 사항을 충족하는지 검증하기 위한 API, 기능, 브라우저 및 모바일 사용자 인터페이스 테스트가 이들의 최대 관심 영역이다.
  • 설계자 : 서비스 및 API 품질을 대변하며 신규 또는 변경된 프로토콜이 품질 문제를 나타내는지 여부에 대한 표준을 정의하기에 가장 적임이다
  • 데이터베이스 거버넌스 전문가 : 개발자가 의도하지 않게 빌드에 데이터 품질 또는 보안 관련 문제를 일으키는지 여부에 관심을 갖는다. 

애자일 개발팀은 CI/CD 빌드가 실패할 때 대응하고 문제를 교정해야 하지만, 이제 테스트에서는 이해당사자 역할을 하는 정의된 페르소나가 중요하다. 이해당사자는 파이프라인 초기, 그리고 진행 중에 개발자에게 전달해야 할 위험과 문제를 대상으로 우선 순위를 정해야 한다.
 

지속적 테스트 구현 전략

앞서 살펴봤듯이 자동화된 테스트라고 해서 모두 지속적 테스트에 잘 맞는 것은 아니다. 먼저 테스트를 실행하기 위한 툴이 젠킨스(Jenkins), 서클CI(CircleCI), 뱀부(Bamboo) 또는 다른 주요 CI/CD 툴과 원활하게 통합돼야 한다. 팀이 CI/CD 파이프라인에 테스트를 통합하는 데 너무 많은 노력을 쏟아야 한다면, 비즈니스에 중요한 다른 부분과 기술적 작업이 밀려나게 된다. 스마트베어(SmartBear), 블레이즈미터(BlazeMeter), 트리센티스 큐테스트(Tricentis qTest), 브라우저스택(BrowserStack), 소스랩(SauceLabs), 포스트맨(Postman)을 비롯한 많은 툴에는 젠킨스를 위한 통합과 플러그인이 있다.

둘째, 지속적 테스트에는 자동화된 테스트를 실행하기 위한 적절한 컴퓨팅 환경이 필요하다. 수동으로 구성되는 개발, 테스트, 프로덕션 환경을 사용하는 조직은 각 환경 간에 구성과 인프라 변경을 동기화하는 데 어려움을 겪는 경우가 많다. 가능한 경우 지속적 테스트에 투자하기 전에 환경을 표준화하고 퍼펫(Puppet), 셰프(Chef) 또는 앤서블(Ansible)과 같은 코드형 인프라 툴을 사용해서 구성을 관리하는 것이 좋다.

마지막으로, 지속적 테스트는 손쉽게 자동화하고 적절한 기간 동안 실행할 수 있어야 하며, 정의된 통과 또는 실패 조건과 문제 해결을 위한 구체적인 경로가 있어야 한다. 예를 들어 수천 개의 테스트 시나리오를 거치는 기능 테스트는 실행하는 데 너무 오랜 시간이 걸릴 수 있으므로 예약된 작업으로 야간에 실행하는 편이 더 낫다. 경고 알림이 많은 보안 테스트는 빌드 파이프라인을 멈추지 않도록 정보보안 담당자가 검토해야 한다. 문제를 유발한 코드, 개발자 또는 팀을 쉽게 추적할 수 없는 데이터 품질 테스트는 모든 단계의 빌드를 중단시키고 문제 검토에 대규모 팀이 필요할 수 있으므로 CI/CD 파이프라인에 있으면 안 된다.

베스트 프랙티스 연구도 중요하다. 예를 들어 지속적 테스트에 관해 트리센티스(Tricentis)가 제안하는 14가지 요점은 테스트가 변경 사항을 환경으로 푸시하기 전 단계의 안전망 역할을 하고, 조치 가능한 피드백을 제공하고, 딜리버리 파이프라인의 적절한 단계에 맞는 적절한 일련의 유효성 검사를 수행할 것을 제안한다. 지속적 테스트가 제대로 되지 않고 있음을 나타내는 징후도 있다. 예를 들어 사용자 인터페이스 테스트에 대한 과도한 투자나 테스트 데이터 관리가 자동화되지 않은 경우가 여기에 해당된다.
 

지속적 테스트에 우선 순위를 부여할 때 애자일 원칙 사용

팀 전체가 지속적 테스트 전략에 동의하고 나면, 팀은 제안된 테스트의 혜택과 제약을 모두 고려해서 작업의 우선 순위를 정해야 한다. 이해당사자들은 각자 권장하는 테스트에 우선 순위를 부여하고 테스트에서 다루는 위험을 기준으로 중요도 순위를 정해야 한다. 애자일팀은 테스트가 CI/CD 파이프라인에 통합하기에 적합한지 여부를 판단한 다음 구현을 추산해야 한다. 마지막으로, 테스트가 너무 많으면 빌드 속도가 저하되거나 필요한 인프라 요건이 높아질 수 있으므로 테스트를 카탈로그화하는 것이 중요하다.

지속적 테스트에 대한 투자는 협업 개선과 더 높은 품질의 소프트웨어로 이어지지만, 이를 위해서는 우선 순위와 범위, 구현 세부 사항에 관한 정렬이 필요하다. 페르소나 정의, 가치 우선 순위 부여, 개발 추산, 구현 지원을 위한 전략을 정의하고 애자일 원칙을 활용하는 팀은 테스트를 통해 위험을 낮추고 가치를 제공할 가능성이 높다. editor@itworld.co.kr


X