TechWell Insights에 올라온 "Why Software Testing is Key to DevOps"를 번역했습니다.
최근 CI/CD가 보편적으로 적용되면서 DevOps가 소프트웨어 업계의 핫이슈로 떠오르고 있습니다.
기존 테스팅 업무에만 치중하던 QA에게는(물론 그렇지 않은 QA들도 많습니다만) 업무의 외연을 확장할 수 있는 좋은 기회라고 생각됩니다.
이 글에서는 다양한 툴을 통해 신속한 빌드의 배포를 추구하는 DevOps에서도 이처럼 품질이 중요한 키워드라고 소개하고 있습니다. 간단한 테스팅 자동화를 통해 어떻게 DevOps에서 코드 품질을 보장할 수 있는지 고민해 보는 계기가 되길 바랍니다.
번역 및 포스팅에 대해서는 원 저자의 승인을 받았습니다.
Happy Testing.
다양한 조직에서 소프트웨어를 좀 더 신속하게 배포하기 위해 DevOps 사례를 수용하고 있다. 좀 더 자주 빌드를 수행하고 빌드 배포에 소모되는 불필요한 시간을 줄이는 것이야말로 DevOps를 수용하는 목적이라고 할 수 있다.
그러나 아직 대부분의 조직에서 DevOps의 업무를 품질과 관련해 생각하지는 않는다. 이전에 비해 코드를 더 빨리 배포할 수는 있지만 코드 상태가 엉망인 경우도 많다. 품질이 전제되지 않는 ‘지속적인 배포’는 단지 고객에게 ‘지속적으로’ 버그 투성이 코드를 전달하는 것과 같다.
이런 이야기가 낯설게 들리지 않는다면 아마 당신이 일하는 회사의 DevOps에서도 소프트웨어 테스팅을 간과하고 있는 것일 수도 있다. 넷플릭스, 아마존, 그리고 엣시(Etsy) 와 같이 최고의 DevOPS 퍼포먼스를 수행한다고 알려진 조직에서는 소프트웨어의 품질을 보장하기 위해 리그레션 테스팅, 성능 테스팅, 부하 테스팅, 그리고 보안 테스팅을 자동화해 수행하고 있다. 또한 DevOps 파이프라인 안에 이들 테스팅을 구현하고 모든 빌드를 대상으로 이 테스트를 수행한다. 넷플릭스의 경우 최종 버전의 소프트웨어를 커밋하고, 테스트하고, 이를 라이브에 배포하는데까지 걸리는 시간은 겨우 16분에 지나지 않는다!
당신이 속한 조직이 앞서 예를 든 회사처럼 규모가 크지 않거나 빠르게 빌드를 배포할 필요가 없다고 해도 DevOps 파이프라인에서 테스팅을 자동화한다면 여러 가지 장점을 얻을 수 있다. 아주 작은 규모의 리그레션 테스트라고 하더라도 이를 자동화한다면 모든 빌드에서 기본적인 테스트가 수행되도록 할 수 있다. 가장 먼저 스모킹 테스트를 자동화하는 것이 이런 작업의 첫 단계가 될 수 있다. 스모크 테스트를 통해 개발자의 코드에 대한 새너티를 체크할 수 있게 된다. 이를 통해 테스트 팀에서 수행하는 수동 테스팅 업무를 줄일 수 있을 뿐만 아니라, 최소한의 품질 기준을 충족하지 못하는 빌드에 더 이상 시간을 빼앗기지 않도록 하는 효과도 얻을 수 있다.
신뢰할 수 있는 자동화 테스트를 통해 수동 테스팅 업무를 줄일 수 있다는 건 잘 알려진 사실이다. 이렇게 절약한 리소스를 통해 애플리케이션에서 리스크가 높은 부분에 탐색적 테스팅을 집중해 수행할 수도 있다. 인터페이스 이슈나 오작동한 케이스와 같이, 시스템에서 가장 중요하다고 생각되는 부분에 좀 더 많이 신경을 쓸 수 있게 되는 것이다. 모든 테스트가 자동화될 수 있는 것은 아니지만 순전히 수동 테스팅으로만 진행되는 부분이 있다면 소중한 자원을 현명하게 분배할 필요가 있어 보인다. 이런 부분이야말로 주의해서 살펴볼 가치가 있는 부분이다.
오늘날 대부분의 조직에서 성능 테스팅, 부하 테스팅, 그리고 보안 테스팅과 관련해 일정 수준의 자동화를 구현하고 있다. 기존의 업무와 역량을 지렛대삼아 DevOps 파이프라인에 테스팅 자동화를 강화함으로써 소프트웨어 라이프사이클 후반에 특정 그룹에서 발생한 문제로 인해 배포가 중지되는 상황을 미연에 방지할 수 있다. 이는 소프트웨어 개발 라이프사이클의 앞단에서 애플리케이션과 데이터의 심각한 취약점을 미리 식별하고 이를 보완함으로써 이들 취약점이 에러로 진화하지 않도록 만들어 보안 리스크를 줄이는 것과 같다. 간단한 조치를 통해 지금 바로 얻을 수 있는 혜택인 것이다.
DevOps 업무에 소프트웨어 테스팅을 반영하는 것이 어려운 일이 되어서는 안 된다. 같이 일하는 테스트 엔지니어나 보안 엔지니어를 기획 회의에 참가하도록 하는 것부터 시작하면 된다. 그 다음, 파이프라인의 다음 단계로 넘어가기 위해 반드시 충족해야 하는 품질 관문(quality gate)과 소프트웨어 품질 기준을 설정한다. 마지막으로, 설정한 품질 목표와 현실의 차이를 인식하고 최대한의 ROI(Return on Investment)를 창출할 수 있도록 업무의 우선순위를 설정한다. 가장 자주 실행되는 소프트웨어의 가장 큰 소프트웨어 리스크를 줄이기 위해, 혹은 현재 가장 큰 병목 구간을 해소하기 위해 업무들이 가장 먼저 수행될 수 있다.
이런 간단한 단계들을 거쳐 단순히 코드를 빨리 배포할 뿐 아니라 더 나은 품질의 코드를 빠르게 배포할 수 있게 될 것이다.
'QA' 카테고리의 다른 글
[번역] 1주일 안에 유니티 엔진을 테스트 하는 법 (8) | 2018.10.29 |
---|---|
[번역] 제리 와인버그의 마지막 고민 (4) | 2018.08.16 |
[번역] 정말 프로젝트를 시작할 때부터 QA가 필요할까 (2) | 2018.01.08 |
[번역] 소프트웨어 테스팅의 미래 (4) | 2017.10.26 |
[번역] 테스터의 커리어 패스 (6) | 2017.08.25 |