CI (Continuous Integration) 에 대해 아시나요?

테스팅: Agile 이 되기 위해 Agile 스러울 필요는 없습니다

Andrew Prentice가 Agile에 대해 이야기 합니다. (2009년 8월)
http://www.atlassian.com/agile
테스트팀은 일반적으로 그들 조직에 맞는 소프트웨어 개발 방법론(Software development methodology)을 사용하지 않습니다.
이러한 아이러니는 스스로 "품질검증("Quality Assurance")이라고 부르는 팀에도 적용되지 않기를 바랍니다.
그러나 이것이 테스트 매니저와 테스트팀이 생산성 향상을 위한 방법론을 실무에 적용하지 못하도록 하는 것은 아닙니다.
이 포스트를 통해 저는 어떻게 애자일, 지속적인 통합(continuous integration)을 통해 효율을 올리고 실제 애자일환경이 아닌 곳에서 테스트팀이 어떻게 구현해야 하는지를 설명할 것입니다.

만약 여러분이 큰 조직에서 애자일 방법론이 아닌 방식으로, 큰 수동 테스트(testing) 방법을 수행하는, 특히 소프트웨어를 만드는 것이 핵심 업무가 아닌 환경인 경우는 그 고통을 충분히 이해하고도 남습니다.
저 또한 그와 유사한 환경에서 수년간 일을 했었습니다.
요구사항은 정확하지 않고 포괄적이지도 않으며 (불행히도 구체적이지도 않습니다) 디자인은 계속 바뀌고 물론 프로젝트 계획에 이러한 변경사항을 수용할 응급상황처리도 포함되어 있지 않습니다. 그러므로 스펙은 더 이상 현실을 반영하지 않으며, 개발과정에서 자연스럽게 지연된 일정으로 인해 발생하는 준비기간 또한 갑작스런 변경사항을 수용하기에는 역부족입니다. 게다가 개발부서는 허술한 테스트 코드(내 컴에선 잘 돌아가는데…)로 인해 할일은 더 많아지는 것입니다. 확실한 것은 릴리스 일정 연기는 반드시 거부된다는 것입니다.

감사하게도 이런 환경에서 이미 시장홍보가 시작되고, 영업 브러셔가 만들어진데다, 대표가 여러분이 자는 동안 발표장으로 이동중이라는 이유로, 중요한 테스트 정보나 리소스 없이 여러분은 원래 예정된 시간보다 더 적은 시간만 테스트(test) 하면 되는 것입니다.

어떤 테스터 엔지니어는 날짜를 줄이려거 더 많은 시간을 일을 하여 인정 받으려는 분도 계십니다. 그렇지만 진정 인정을 받는 사람은 문제를 회피하거나 과거로 되돌아가지는 않습니다. 만약 여러분이 위와 같은 상황에 있다면, 여러분이 싸워야 할 것은 버그있는 코드나 허술한 요구사항 그리고 안좋은 스펙이 아니란 점을 아셔야 합니다.
또한 프로젝트 매니저, 개발자, 비즈니스 분석자, 아커텍처 엔지니어 혹은 고객도 아닙니다.
여러분이 싸워야 할 것은 테스트팀이 언제나 이전 단계에서 발생했던 잘못된 점 해결하는, 그리고 고객을 괴롭게 했던 개발 프로세스입니다.
어떻게 할까요? 더 많은 일과 주말근무 혹은 더 많은 인원 투입은 결국 문제를 전혀 개선하지 못합니다. 무슨말인지 여러분은 이미 경험으로 알고 계실 것니다. 적절한 근본 해결 없이 문제를 축소시키는 것은 결국은 주요문제를 사소한 문제로 축소시켜 릴리스 되지 말아야할 제품이 나가게 되는 것입니다. 그러면 누가 인정받을까요?

나쁜 환경에서 최선을 다하지 말고, 먼저 환경을 개선하라.
만약 여러분이 기능 테스트를 수행, 관리한다면, 다음과 같은 테스트 계획은 가질 수 있는 행운이 있다고 합시다.:


회귀 테스팅(Regression testing)은 일반적으로 마지막에 수행되는데 그 이유는 다음과 같습니다,

1. 버그는 변경되지 않고 이전에 테스트 되었던 코드 보다는 새로운 테스트되지 않은 코드에서 주로 발견되므로, 새로운 기능의 테스트는 우선적으로 수행되어야 합니다.


2. 버그 수정은 그 자체로 회귀을 발생하기 때문에, 반복되는 회귀 테스트를 줄이기 위해서는, 회귀 테스트가 버그 수정 완료 후 계획되어야 합니다.

이것은 매우 일반적은 접근 방법으로 여겨지며 만약 실제 그렇다면 맞는 말일 것입니다. 허나 실제는 다음과 같습니다.:


변함없는 개발과정은 전체적으로 종반가서야 끝나게 되지만, 일부 기능은 그 이전에 예정 시간에 맞게 완료됩니다. 이것은 때로 프로젝트 매니저와 테스트 매니저에게 테스팅 단계를 이에 맞게 분할하도록 유혹합니다. 각 단계를 전환하는 테스터들은 생산성비용은 나중에 더 소모될 것이나, 이것이 가능한 빠른 일부 테스팅을 시작함으로서 얻는 이익을 넘지 않기를 바랍니다.
단계 1이 끝나면, 테스트팀은 단계 2에 영향받지 않는 기능 부분을 회귀 테스트 하고 싶어질 것입니다. 때로는 최종 변경사항이 늦어져 테스터가 신규 변경사항을 테스트해야 하거나 혹은 변경사항이 회귀 테스트를 무의미 하게 하는 경우 건너띄는 경우도 있습니다.
이러한 나중의 변경사항은 또한 이미 테스트 한 새로운 기능에 대한 변경사항을 포함하는 경우도 있습니다. 그래서 다시 테스트가 필요하며 이것은 전체 릴리스의 회귀 테스트가 시작되기 전에 시작되어야 합니다.
그러나 이것이 일단 회귀 테스트가 최종적으로 수행되어 더 많은 수정사항과 또다른 회귀 테스트가 끝나면, 더 이상의 중요한 회귀 테스트의 필요성이 발견되지 않을 것임을 의미하지는 않습니다.
더 많은 단계와 늦은 변경이 있다면 더욱 반복하는 상황이 됩니다.
결국은 테스팅이 계획된 것보다 더 오래 걸리게 되며 이것은 지름길 (테스트 범위 축소, 버그 중요성 낮춤 등의)을 선택하도록 강요합니다.
테스트 매니저는 다시 우선순위를 정하는데 지치고, 테스터들은 계속적인 테스트 전환으로 심신이 지쳐갑니다. 그러나 이대로는 안됩니다. 여기 방법이 있습니다….

단계 1: 회귀 테스트(regression tests) 자동화

4가지 이유:

1. 테스트(testers)가 직접 수행해야 하는 새로운 기능 테스트 시간을 늘려줍니다. (사람이 직접 해야 하는 지능적이고 창조적인 수동 테스트)


2. 회귀 테스트 결과의 신뢰성 단계를 올려줍니다. (솔직이, 사람은 허술한 회귀 테스터입니다. 같은 일을 반복하는 것은 매우 지루한 작업입니다. 컴퓨터와는 다르게 저희 사람은 지루해 지고, 집중력이 떨어집니다)


3. 일단 자동화 되면, 원하는 때에 언제든 수행할 수 있습니다. (회귀 테스트에 더 이상의 자원걱정이 없이 그저 "시작" 버튼만 누르면 됩니다.)


4. 테스터의 직장만족도를 올려줍니다. – 더 적은 테스트 작업 전환과 반복 테스트, 버그를 찾을 더 많은 시간, 머리를 쓰는 일에 대한 더 많은 시간 할애

그런데 자동화된 테스트가 깨지거나 혹은 유지비용이 크지 않을는지 의문스러우실 수 있습니다. 만약 자동화된 테스트가 잘못 설계되고 테스터가 이것을 수정할 기술이 없다면 그렇습니다.
테스트 자동화 툴의 기록 및 구동은 사용하기 쉽습니다만, 이것은 생성하는 테스트가 디자인을 가지지 않아서 입니다. 테스트가 효율적이고 융통성 있거나 견고하게 디자인 되지 않았다면 그러한 테스트가 깨지는 것은 놀랄일이 아닙니다. 이러한 테스트 도구로 테스트를 기록하고 그 다음 디자인을 구성하는 것이 가능합니다, 그러나 이것은 마치 집을 먼저 짓고나서 나중에 디자인을 수정하여 리노베이션 하는 것과 마찬가지 입니다. 물론 벽을 허물로 옮기거나 할 수는 있습니다. 그러나 결국은 구조적인 지지대나 배로수에서는 별다른 도리가 없이 불만족스러운 상태로 끼워집기 형태의 수정으로 귀결될 것입니다.
그러나, 좋은 디자인으로 쓰여진 자동화된 테스트는 불필요하게 깨지지 않습니다. 이러한 방식으로 테스트를 작성하는 것은 아마도 여러분 팀이 가지지 않은 기술적인 능력을 요구합니다. 어떤 경우는 자동화 전문가로 시작할 필요가 있지만, 나중에는 이러한 몇몇 사람에게 의존하는 것을 원치는 않을 것입니다.
테스트팀을 전체를 개개인이 잘 설계된 테스트를 디자인하는 기술을 가지게 개발시키는 것이 최종 목표가 되어야 합니다.
이것은 더 많은 자동화된 테스트가 작성되면 될수록, 시간은 더 적게 소요되며 이것은 자동화된 테스트의 유지보수와 수정사항이 모든 팀에게 공유될 수 있도록 해 주는 것을 의미합니다.

팀 전체에 이러한 능력을 개발시키는 것은 또 다른 이유가 있습니다.
개발 생산성은 급격히 증가하고 있습니다. 개발자들은 더 효율적인 개발환경과 도구를 가지며, 사용하는 라이브러리와 효과적인 개발 프로세스를 늘려 가고 있습니다.
개발자들은 점점 더 적은 시간에 더 많은 것을 만들어 냅니다. 이런 상황에서 자동화 능력이 없이는 테스트 엔니지니어는 버텨나가기 힘든 것입니다.

이이 많은 오픈소스 기반을 포함하여 자동화 테스트 도구를 제공하는 회사들이 있습니다. (www.opensourcetesting.org 사이트는 광범위한 오픈소스 자동화 툴 목록을 제공합니다). 수 다른 환경에서 서로다른 도구들, 그러므로 Atlassian에서 사용하는 것이 여러분에게는 적합하지 않을 수 있습니다. 그러나 만약 여러분이 Java 기반의 웹 어플리케이션에 대한 테스트를 하고 있다면, 저희가 사용하는 다음의 무료 오픈 소스 툴을 확인해 보십시요.: JUnit, JWebUnit, HtmlUnit , HttpUnit & Selenium

 

단계 2: 자동화된 회귀테스트를 더욱 빠르게
회귀테스트를 수행하는데 얼마나 걸리나요?
저는 수동 회귀테스트의 경우 3명의 테스터가 3주가 걸린 경험이 있습니다. 분명히 상당한 비용이 들어간 회귀 테스트는 지연과 재작업으로 인한 것임을 발견했습니다. Atlassian에서는 그렇게 크거나 혹은 회귀테스트가 3주나 걸리는 시스템은 아닙니다. 제품에 따라 30분에서 3시간정도가 소요되는 정도입니다. 테스트는 모두 2000 항목 (단위 테스트 제외) 정도 됩니다. 릴리스된 후에 2시간만에 회귀테스트가 버그로 정지되는 경우를 상상해 보십시요.
이러한 상황이라면, 우리가 빠른 자동화된 회귀테스트를 만드는 것이 이전의 상황이 좀 더 나아지도록 할 것이라고 예상할 수 있습니다.


여러분의 자동화된 회귀테스트를 더욱 빠르게, 더 많이 할 수 있는 많은 방법들이 있습니다. 그러나 다음사항은 항상 기억하시기 바랍니다.:

1. GUI를 확인하는 것이 아니라면 GUI를 통해 테스트하지 마십시요. 화면과 웹페이지를 이용한 테스트는 많은 시간이 걸립니다. API나 혹은 로컬 브라우징은 시간을 더욱 단축시킵니다.


2. 자동 회귀테스트를 병렬로 수행할 수 있도록 구분해 분리하십시요. 예를들면, 우리는 각기 다른 웹 브라우저가 동시에 테스트하도록 테스트 케이스를 구분하였습니다..


3. 변경된 부분만 테스트하십시요. Clover의 테스트 최적화 기능은 각 테스트의 코드 커버리지를 추적하여 자동으로 최종 회귀 테스트 이후 변경된 부분만을 테스트하도록 수행될 수 있습니다.

.
단계 3: 지속적 통합(Continuous Integration) 서버가 여러분의 자동화된 테스트를 수행하도록 하라
이제 여러분은 자동화된 회귀테스트를 가지고 계시며 매우 빠르게 동작하는데 왜 테스트가 모두 수행될 동안 기다려야 하나요? 이제는 언제든 수행할 수 있습니다. 모든 릴리스, 패치 그리고 긴급 수정에 대해 전체 회귀테스트를 수행할 수 있습니다.
그러나 누가 테스트를 실행하고, 결과를 모으고, 리포트를 준비해 제출하나요?
회귀테스트가 매일 실행할 준비가 되었다면, 나머지는 모두 관리작업입니다. 물론, 이러한 것들을 자동화할 수 있습니다. 그것이 바로 continuous integration (CI), 즉 지속적 혹은 연속적 통합입니다.


CI는 소스코드로부터 소프트웨어를 빌드하고 테스트하여, 소스코드 저장소의 모든 변경사항을 지속적으로 통합하는 애자일 개발방법(Agile development practice) 입니다.
이것은 개발자에게 변경사항에 대해 빠른 피드백을 제공해 줍니다.
CI가 수동으로 수행될 수도 있지만, 흔히 지속적통합 서버(continuous integration servers)로 알려진 소프트웨어 도구를 사용하면 더욱 효율적입니다.
소스코드를 컴파일하고 빌드하는 것은 더 이상 테스트팀에게는 관심사가 아니며, 자동화된 테스트의 수행을 CI 서버가 자동으로 수행하도록 하는 기술이 관심사가 됩니다.
이미 많은 상용, 오픈소스 CI 서버가 있습니다. 이 중에 저희 Atlassian에서는 Bamboo 라고 하는 상용 CI 소프트웨어 제품을 직접 만들어 판매하고 있습니다.
그리고 여기 이 툴을 이용하여 할 수 있는 것들이 있습니다.:

• 지정된 스케쥴에 따라 자동으로 테스트 수행


• 테스트 결과에 대해 자동으로 결과 보고서를 작성하여 웹 사이트로 포스팅 (권한있는 사용자가 볼수 있도록


• 자동으로 테스트 성공과 실패에 대한 결과를 사용자에게 메일, RSS, 혹은 메신저로 통보


• 자동으로 중앙 데이터베이스에 회귀테스트 결과를 저장

Bamboo는 테스트 매니저의 절대적인 지원자입니다. 작업에 지각도 없으며, 아프거나 휴가도 없으며, 오로지 여러분의 회귀 테스트를 지정된 때에 수행하고 그 결과와 상태를 모아 처리합니다.
관리적인 작업이 모두 처리되므로, 여러분의 회귀테스트는 언제나 실행되는 것입니다.
그러므로 이제 상황은 다음 그림과 같습니다:

인기 있는 CI 도구(continuous integration tool) 인 Bamboo에 대해 더 알고 싶으시다면, 무료로 다운로드 하여 30일 기간동안 직접 시험 사용해 보십시요. 혹은 Atlassian 개발자 네트워크를 위해 저희가 제공하는 Bamboo instance를 훓어보실 수 있습니다.

단계 4: 여러분의 자동화된 테스트를 빌드 프로세스에 연동하라
이제 여러분은 CI 서버(continuous integration server)를 통해 여러분의 회귀테스트를 실행할 수 있게 되었으며, 개발자를 위해 자동으로 지속적인 빌드를 수행하도록 하는 필요한 플랫폼을 가지고 계십니다.
이제 개발 인프라는 준비되었으며, 개발자에게 이것을 사용하도록 하는 다음의 장점들을 개발자들에게 전달하시면 됩니다.:

• 회귀테스트(Regression tests)는 테스트단계가 아닐 때도 자동으로 수행됩니다. "모든 회귀테스트 통과"는 이제 테스팅 단계에서 끝이 아니라 시작점이 됩니다.


• 스모크 테스트(Smoke tests-테스트가능여부 파악을 위한 기본 테스트) 는 새로운 기능에만 이루어지면 되며, 기존의 기능들은 이미 전체적으로 테스트 된 상태가 됩니다.


• CI 서버가 자동으로 테스트 실패를 통지하기 때문에, 자동화된 테스트가 실패할 때 버그 보고서를 별도로 작성할 필요가 없습니다.


• CI 서버를 통해 개발의 진정한 상태가 모두(개발자외에도)에게 투명하게 항상 공개됩니다. 이것은 테스트가 계속 실패하는 상황인 경우 모든 사람에게 즉각적으로 확인이 되어 허술한 개발코드가 들어가는 것을 근본적으로 차단합니다.


• 소프트웨어에서 변경으로 인해 업데이트가 필요한 회귀 테스트가 개발단계에서 발견될 수 있으며, 테스터에게 테스트 단계가 시작되기 전에 변경사항을 처리할 충분한 시간을 제공합니다.


• 이제 여러분은 배포나 테스트환경의 패치와 같은 다른 작업들을 자동으로 처리하는데 확장 가능한 자동화된 빌드와 테스트 통합 프레임워크를 가지게 된 것입니다.

이것은 여러분의 개발팀이 형상관리 도구(소스관리 툴)를 사용해야 하는 환경과 자동화된 빌드 프로세스 환경을 가지도록 요구합니다.
만약 개발팀이 할 의지가 없거나 개발팀의 빌드 프로세스를 여러분의 CI(continuous integration) 서버에 설정해 넣을 수 없다면, 여러분의 위해 며칠/몇주 작업할 빌드 엔지니어를 구하십시요.
여러분의 소프트웨어의 최종 패키지가 나올때까지, 소스코드를 접근할 필요가 없습니다.

단계 5: 결과를 수확하라
이것들을 모두 모아 이제 여러분의 여러분의 테스트 계획이 아래와 같이 되며 그것이 현실이 됩니다.:

이제 여러분은 새로운 기능을 테스트할 더욱 많은 시간을 가지며 테스트 실패 보고서에 시간을 허비하지 않습니다. 그것은 모든 변경사항이 테스트와 개발단계에서 전체 회귀테스팅 될 것이며, 스케쥴을 날려버릴 심각한 버그가 테스팅 단계에서 발견되는 일은 이제 없습니다.
동일한 시간동안 여러분은 더 많이 테스트 하실 수 있으며, 더욱 빨리 피드백을 받으며 모두가 테스트 작업을 볼 수 있습니다. 이제 더 이상 반복적인 작업을 하며 날밤을 세우는 일은 없을 것입니다. – 여러분 조직의 개발방법론은 Agile 이 아닐 수도 있습니다. 그러나 테스팅은 Agile 방법론을 사용하고 있는 것입니다.