저는 작년 11월, 미국 플로리다 올랜도에서 열린 Agile + DevOps EAST 2018에 다녀왔습니다. Agile + DevOps는 TechWell Corporation에서 주최하는 콘퍼런스 중 하나입니다. 콘퍼런스에선 어떻게 하면 안전하고 신뢰할 수 있는 소프트웨어 애플리케이션을 좀 더 빨리 사용자에게 전달할 수 있을지에 대한 내용을 다룹니다. 또한 그렇게 하기 위해 여러 기능의 이해 당사자들을 하나로 모을 수 있는 애자일과 DevOps 사례도 다룹니다.
이번 콘퍼런스는 애자일, DevOps와 관련된 리더십, 사례, 테스트 자동화와 더불어 애자일과 DevOps 문화를 형성하는 방법, 관련 역량을 강화하는 방법 등이 주제로 다뤄졌습니다. 또한 CI(Continuous Integration), CD(Continuous Delivery/Deployment)에 관한 내용도 다뤄졌습니다. 콘퍼런스엔 네트워킹 세션도 있었는데요. 저는 아침 달리기와 Lean Coffee, 아침 요가가 흥미로웠습니다(여기에서 전체 네트워킹 세션 목록을 확인할 수 있습니다).
저는 이번 글에서 감명깊었던 아래 4개 세션을 소개하려고 합니다.
- How AI is transforming software testing
- Shift Left: Continuous Performance Testing in the CI/CD Pipeline
- Integrating Infrastructure as Code into a Continuous Delivery Pipeline
- Service Virtualization: How to Test More by Testing Less
How AI Is Transforming Software Testing
이번 세션은 Testim.io에서 개발자 겸 이벤절리스트(evangelist)로 계신 Raj Subramanian님이 발표해주셨습니다. 현재 AI(artificial intelligence)와 머신러닝은 급격한 속도로 발전하고 있습니다. 이미 Apple이나 Google, Facebook 등 여러 유명한 회사들이 헬스케어나 자율주행자동차, 검색 엔진, 예측 모델링 같이 서로 다른 문제를 풀기 위해 AI 기술에 투자하고 있습니다. 그러면 소프트웨어 테스트 분야는 어떨까요? 변화에 적응하고 AI를 잘 받아들일 수 있을까요? 관련해서 Raj는 아래와 같은 내용을 설명했습니다.
소프트웨어 테스트의 진화
Raj는 지난 40년 동안 테스트 사례가 어떻게 진화해왔는지 요약했습니다.
- 1980년대에는 많은 소프트웨어 회사에서 waterfall 방법론과 수기 테스트를 사용했습니다.
- 1990년대에는 소프트웨어를 테스트하기 위한 자동화 도구들이 나타났지만 불안정하고 기능이 많지 않은데다 가격도 비쌌습니다.
- 2003년과 2010년 사이에 여러 오픈 소스 프레임워크가 이름을 알리기 시작했습니다. 소프트웨어 관련 커뮤니티에서는 소프트웨어 테스트를 개선하고 공유하기 시작했습니다. 동시에 사람들은 소프트웨어 기능이 좀 더 빨리 배포되길 원했습니다. 그런 흐름을 타고 애자일(agile)이 SDLC(Software Development Life Cycle)에서 존재감을 키워나갈 수 있었습니다.
- 2010년대에는 테스트를 작성하고 버그를 찾는 시간을 줄일 수 있는 방법을 찾길 원했습니다. Crowdtesting은 사람들이 애플리케이션에 피드백을 하도록 독려했습니다. 그리고 클라우드 테스팅이 시작되자 좀 더 많은 서버 공간과 빠른 처리가 필요하다는 것을 깨닫게 되었습니다. 또한 유지관리 측면의 문제점도 찾아냈습니다. 테스트를 유지하기 위해 하드웨어와 소프트웨어를 구입하는 것은 매우 비쌌으니까요. 이제 우리는 DevOps와 Continuous Testing, CI/CD integration을 갖게 되었습니다.
- 앞으로 소프트웨어 테스트의 미래는 어떻게 될까요? Raj는 머신러닝과 AI를 활용한 자율(autonomous) 테스트가 될 것이라고 믿고 있습니다.
Raj가 쓴 블로그 글을 더 보고 싶으시면 이곳을 클릭해보세요.
우리는 QA에서 어떤 도전에 직면해 있을까요?
자동화 테스트를 개발하고 유지하는 일은 쉽지 않습니다. 그리고 누군가는 그런 일을 수행할 수 있는 시간이나 테스터와 같은 자원이 부족할 수도 있습니다. Raj에 따르면 QA단계에서는 아래 5가지 카테고리에서 어려움을 겪게 됩니다.
| Category | Challenges |
|---|---|
| Skill set |
|
| Authoring |
|
| Initialization state |
|
| Maintenance |
|
| Scalability |
|
어떻게 하면 AI를 이용해 테스트 문제를 해결할 수 있을까요?
Testim에선 페이지의 모든 DOM 오브젝트를 분석하여 오브젝트와 프로퍼티를 실시간으로 추출하는 AI 플랫폼인 동적 탐지(dynamic locators)를 사용합니다. AI는 이 분석을 토대로 특정 엘리먼트를 어디에 위치시키는 게 좋을 지 위치 전략을 결정합니다. 만약 개발자가 엘리먼트의 특성을 변경하더라도 테스트는 계속 수행되어 테스트의 안정성을 향상시킵니다. Authoring의 결과로 자동화된 테스트는 훨씬 빠르면서 보다 안정적입니다.
Shift Left: Continuous Performance Testing in the CI/CD Pipeline
이번 세션은 Quicken Loans에서 Enterprise Quality Architecture의 리더를 맡고 있는 Gajan Pathmanathan이 발표했습니다. 그가 세션에서 공유한 내용 중 몇 가지를 말씀드리겠습니다.
지속적인 성능 테스트란?
위키피디아에 따르면 성능 테스트는 품질이나 역량을 평가하는 프로세스입니다. 일반적으로 소프트웨어 엔지니어는 확장가능성(scalability), 신뢰성(reliability), 자원 사용량(resource usages) 같은 시스템의 품질 속성을 조사하고, 측정하고, 확인하고, 검증하고 싶어합니다. 지속적인 성능 테스트는 자동화된 성능 테스트를 CI/CD 파이프라인의 한 부분으로 실행하는 프로세스입니다. 지속적인 성능테스트에는 두 가지 유형이 있습니다. 하나는 성능 스모크(smoke) 테스트 혹은 성능 회귀(regression) 테스트이고 다른 하나는 end-to-end 성능 테스트입니다.
Boehm의 곡선
Boehm의 곡선이 말해주는 것은 무엇일까요? Boehm의 곡선이 전달하는 주요 메시지는 버그를 수정하는 비용은 프로세스의 뒤로 갈수록 항상 비싸진다는 것입니다. Regtest 블로그에 나온 다이어그램은 같은 버그라면 Boehm의 곡선에서 더 이른 시기에 수정할수록 비용이 저렴해진다는 것을 보여주고 있습니다. Boehm의 곡선은 우리가 가능한 한 최대한 많은 버그를 프로젝트의 요구 분석 단계와 테스트 단계에서 수정하는 게 필요하다는 것을 의미합니다. 배포 후엔 이런 버그들이 엄청난 지출을 초래하게 됩니다. 데이터와 수치를 좀 더 확인하고 싶으신 분은 여기를 읽어보시기 바랍니다.
소프트웨어 장애가 여러분의 회사에서 얼마나 큰 비용을 차지할까요?
tricentis.com의 소프트웨어 에러 보고서에 따르면 2017년에 소프트웨어 장애가 경제에 끼친 손해가 약 1.7조 미화 달러라고 합니다. 총 314개의 기업에서 발생한 소프트웨어 장애가 36억 명의 사람들에게 영향을 미쳤고 268년에 달하는 다운타임을 발생시켰습니다.
지속적인 성능 테스트의 프로세스는 어떻게 될까요?
Gajan은 자신이 근무하는 회사인 QuickenLoans Technology를 예로 들어 설명했습니다.
- 개발자가 PR을 생성하면 코드 안정성을 측정하기 위한 유닛 테스트가 자동으로 실행됩니다.
- 코드 품질을 검증하는 데 가장 중요한 상호 코드 리뷰가 실시됩니다. 다른 활동에는 레거시 코드, 코딩 로직과 스타일 등에 대한 확인이 포함됩니다.
- 코드리뷰에서 승인된 후 master 혹은 main 브랜치로 체크인 됩니다.
테스트 환경으로 빌드 결과물이 배포되기 전에 파이프라인에서 성능 스모크 테스트 혹은 성능 회귀 테스트가 수행됩니다.
- 빌드 결과물이 테스트 환경으로 배포되면, 품질을 검증하기 위해 통합(integration), UI, 회귀, 보안, 성능 스모크, 성능 회귀 테스트와 같은 전체 자동화 테스트가 실행됩니다.
- 자동화 테스트가 완료되면 QA는 수동으로 exploratory testing을 수행하고 베타 환경에 배포합니다.
- 베타 환경에선 전체 자동화 테스트, 특히 end-to-end 성능 테스트와 end-to-end 기능 테스트가 다시 수행됩니다.
- 수행결과 모든 신호등이 녹색이라면, 빌드 결과물은 운영 환경에 배포됩니다.
빌드 결과물이 완전히 배포되면 지속적인 성능 모니터링을 수행하여 운영 환경 상태를 추적합니다.
Integrating Infrastructure as Code into a Continuous Delivery Pipeline
이번 세션에선 Contino에서 근무하는 Adarsh Shah가 IaC(Infrastructure as Code)를 소개해주었습니다.
Infrastructure as Code란?
Infrastructure as Code(IaC)란 소프트웨어 시스템에서 사용된 검증된 코딩 기법을 가져와 인프라로 확장시키는 접근 방법입니다. IaC는 설정 문제나 반복 작업, 실수(human error), 완료하는 데 걸리는 시간 등의 문제를 해결해줍니다.
Continuous Delivery란?
Continuous Delivery(CD)는 새로운 기능, 설정 변경, 버그 수정과 실험 등 모든 유형의 변경 사항을 지속 가능한 방식으로 안전하고 신속하게 운영 환경 혹은 고객에게 전달하는 능력입니다.
고려 사항과 모범 사례
소스 관리
모든 것이 소스 코드 관리에 달려 있습니다. 소스 코드가 관리되면 코드 변경이 쉽고 팀원 간 협업도 강화됩니다. Adarsh는 코드는 빈번하게 변경되니 코드/테스트를 문서로 사용할 것을 제안했습니다.
Infra as Code testing
테스트 피라미드의 낮은 단계에선 높은 단계에서보다 빠른 피드백을 받을 수 있습니다. 더미 앱을 이용한 스모크 테스트와 같이 테스트 피라미드의 높은 단계에선, 사용자들로부터 더욱 많은 신뢰를 얻을 수 있지만 유지하는 데 더욱 많은 비용이 필요합니다.
보안 패턴
Adarsh는 CIS benchmarks를 자동화하고 정적 스캐닝 정책을 강화할 것을 제안했습니다. 그들은 앱을 안전하게 만들기 위해 'secrets management'와 'artifact signing/verification'을 사용했습니다. 만약 여러분의 회사가 금융이나 헬스케어 분야라면, SOX, PII, HIPPA, PCI와 같은 표준 compliance가 있습니다. Chef InSpec, HashiCorp Sentinel(Policy as Code)과 같은 Compliance as Code를 사용하는 게 문서작업보다 더 좋은 선택입니다.
프로비저닝을 위한 패턴
Adarsh는 Immutable VMs, Containerized services, Base Image & App Pull 등 기업 인프라를 프로비저닝 하기 위한 몇 가지 패턴을 제공했습니다.
- Immutable VM: Immutable VM은 인프라 모듈이 사용하는 앱 이미지입니다.
- Containerized services: 도커 컨테이너를 사용하고 있다면 앱 테스트, 보안 스캔, 인증서 서명으로 Kubernetes에 배포되기 전 이미지의 품질을 검증해야 합니다.
- Base Image & App Pull: 인프라에 VM이나 컨테이너형 서비스가 없을 때 사용하는 전통적인 방법입니다.
- People and Process: 팀이 인프라, 보안, 컴플리언스, QA 등과 상호 작용할 수 있도록 만들어야 하고 모든 팀이 CI/CD 프로세스 개선을 위해 협력해야 합니다. 그렇게 되면 좀 더 빠른 피드백을 받을 수 있습니다.
Service Virtualization: How to Test More by Testing Less
Beaufort Fairmont Automated Testing Services에서 근무하는 Paul Merill은 서비스 가상화(service virtualization)에 대해서 공유해주었습니다.
왜 당신의 테스트는 엉망일까요?
대부분의 테스트는 '적절한 테스트 데이터 관리 부족'으로 엉망인 상태입니다. 테스트를 위한 소프트웨어나 앱 소스코드를 계획, 설계, 저장, 관리하는 프로세스를 소프트웨어 테스트 데이터 관리라고 합니다. 소프트웨어 품질을 테스트하고 확인하는 게 주 목적인데요. 테스트 데이터를 운영 데이터와 분리하고, 소프트웨어 테스트 데이터의 크기를 최적화하고 테스트 보고서를 작성하는 일입니다. 테스트 데이터 관리가 부족하거나 데이터 품질이 낮아지면 테스트 케이스가 불안정해지고 버그가 발생할 위험이 높아집니다.
서비스 가상화란?
서비스 가상화(service virtualization)란 소프트웨어 개발 라이프 사이클의 테스트 단계에서 이용할 수 없거나 이용이 제한되는 소프트웨어 컴포넌트의 동작을 시뮬레이션하는 것입니다. 가상 자산(virtual assets)이라고도 불리는 시뮬레이터 컴포넌트는 실제 소프트웨어 컴포넌트의 동작을 테스트에 필요한 만큼 최대한 반영합니다. Paul은 서비스 가상화를 여러 상황에서 사용했는데요. 서비스를 이용할 수 없거나 개발자들이 아직 개발하지 않았지만 버그를 일찍 찾아내기 위해 컴포넌트의 반응이 필요하거나, 테스트 케이스를 자꾸 실패하게 만드는 불안정한 외부 서비스가 존재할 때도 사용했습니다. 외부 서비스에 서비스 가상화를 사용하면 자동화된 테스트가 가능하고 이를 더욱 넓은 범위로 확장할 수 있습니다. 또한 컴포넌트에서 여러 가지 동작을 촉발시킬 필요가 있는 데모에서도 유용합니다.
서비스 가상화의 장점은 무엇일까요?
우리는 적어도 한 번은 아래와 같은 상황과 마주합니다.
- 개발자가 아직 개발을 완료하지 않아 서비스를 이용할 수 없는 상황
- 외부 서비스 혹은 서드 파티 라이브러리를 이용할 수 없는 상황
- 데모를 하려는데 몇몇 외부 서비스가 연결되지 않는 상황
- 더 많은 테스트 시나리오를 만들기 위해 서비스 동작을 시뮬레이션해야 하는 상황
서비스 가상화는 아래와 같은 장점이 있습니다.
- 서비스 가상화는 테스트 환경의 의존 가용성(dependency availability)에 관한 제약을 제거합니다.
- 데이터 드리븐 가상 자산은 테스트 팀이 쉽게 테스트 데이터를 관리하고 테스트 커버리지를 높일 수 있도록 만듭니다.
- 서비스 가상화는 테스트를 자동화할 수 있게 도와주거나 자동화를 더욱 넓은 범위로 확장할 수 있게 도와줍니다.
- 서비스 가상화의 장점은 테스터에게만 국한되지 않습니다.
정리하며
Agile + DevOps 콘퍼런스에서는 애자일 프로세스, DevOps, 보안, 테스트 자동화와 관련하여 여러 가지 주제를 다루고 있습니다. 많은 전문가와 연사들이 세션에서 자신들의 프로젝트 경험과 지식을 공유하고, 소프트웨어 엔지니어, 스크럼 마스터, 관리자 등 서로 다른 백그라운드를 갖고 있는 다양한 사람들과 만나 이야기를 나눌 수도 있습니다.
저는 인상 깊었던 여러 기술 세션들을 이번 글에서 공유해 드렸습니다. 예를 들어 Adarsh가 Integrating Infrastructure as Code into a Continuous Delivery Pipeline 세션에서 언급했던 것처럼 그는 보안 확인, 컴플리언스, 소스 코드 통제를 포함한 어떤 것이든 자동화하는 것에 초첨을 맞췄습니다. 이것을 우리 CI/CD 파이프라인에 적용할 수 있다면 우리는 테스트를 'shift left'할 수 있고, 운영 환경에 배포하기 전에 버그를 찾아 수정할 수 있게 될 것입니다. Paul은 Service virtualization: How to Test More by Testing Less 세션에서 서비스 가상화의 개념을 소개하고 시스템에 서비스 가상화를 구현하면 어떤 이점이 있는지 설명했습니다. 컴포넌트의 동작을 시뮬레이션하면 테스트 환경이 갖고 있는 의존성과 제약을 제거할 수 있어서 자동화 테스트의 범위를 확장시켜 테스트 커버리지를 높일 수 있을 것입니다.
이 행사는 저에게 굉장한 경험이었습니다. 저는 소프트웨어 개발 사이클에서 어떻게 'shift left' 테스트를 하는지, 어떻게 자동화 커버리지를 확장하는지 등 많은 것을 배웠습니다. 여러분도 기회가 된다면 이 콘퍼런스에 한 번 참석해보시길 권해드립니다.