애자일 개발과 탐색적 테스팅

애자일 개발과 탐색적 테스팅

Concealed precondition of Agile Development and Exploratory Testing

 

  애자일 개발을 바라 보거나 적용하려 할 때 흔히 빠지게 되기 쉬운 오해의 함정 중 하나는 기존 방식에서 사용했던 방법들을 부정하거나 그 방법들의 가치를 인정하려 하지 않으려 한다는 점이다. 애자일을 적용(혹은 도입)하기 위해서는, 새로운 판에서 새로운 룰로 시작해야 한다고 자신도 모르는 사이에 은연중에 믿어 버리게 된다. 그래서는 UML 이라던가, 모델링이나 설계관련 문서들이 가치 없다고 간주해 버린다. 심지어는 전통적인 방식을 따르는 기존 맴버들을 향해 ‘애자일’을 폭력적으로 사용하기도 한다.

  애자일은, 전통적인 SW개발의 방식이나 산출물들이 가치가 없다고 호도하는 것으로 시작하는 것이 아니라, 형식이 목표와 가치를 넘어설 정도로 일방적으로 따르는 교조적인 접근 방식에 대한 비효율을 개선 하자는 데에 그 출발점을 두고 있다. 애자일 선언문(Agile Manifest)만 보더라도 애자일 적인 접근을 우위에 놓자는 것이지 기존 방식이 나쁘다고 말하는 부분은 어디에도 없다. 오히려 기존 방식의 가치를 존중하고 있음을 명백히 밝히고 있다.

We are uncovering better ways of developing software by doing it and helping others do it.

우리는, 소프트웨어 개발을 직접 수행하고, 다른 사람들의 개발을 도와 주는 것을 통해, 소프트 웨어 개발의 더 나은 방식을 찾아가고 있다.

Through this work we have come to value:

이 작업을 통해 우리는 다음과 같은 가치에 도달하였다.

    Individuals and interactions over processes and tools

    절차와 도구 보다는 개개인 및 상호작용을.

    Working software over comprehensive documentation

     많은 것들을 아우르는 문서 보다는 동작하는 소프트웨어를.

    Customer collaboration over contract negotiation 

    계약협상 보다는 고객과의 협력을.

    Responding to change over following a plan

    계획을 고수하기 보다는 변화에 반응하는 것을.

That is, while there is value in the items on the right, we value the items on the left more.

오른쪽 항목들도 가치가 있지만, 우리는 왼쪽 항목의 것들에 좀 더 가치를 둔다.

- from Manifesto for Agile Development

애자일 방식의 개발은 소위 ‘애자일’에서 이야기 하는 ‘기법들(Practice)’을 잘 따르는 개발 방식이기 앞서, 실용적인 정신이 밑바탕에 자리하고 있는 방식이라는 것을 알아야 한다. 가용 가능한 자원(Resource)내에서 ‘사용 가능하다면, 개발에 도움이 되는 것은 어떠한 방식이든 가리지 않고 최대한 이용한다’는 지극히 현실적인 노력의 자세가 그 밑에 깔려 있다. 따라서, 단순히 선언적으로 따라 하는 식으로는, 이미 오랜 세월에 걸쳐 팀 내에 충분히 정제되어 있는 상태의 기존 방식, 이를테면 폭포수 방식(Waterfall)이나 RUP 방식 등을 사용했을 때 보다 더 나은 효과를 누리기 어려울 수 있다. 때로, 애자일 개발 방식을 따르는 팀에서 팀원 개개인의 역량이 부족해서 가용 가능한 기법이나 자원이 적은 상태라면, 어려움이 생겼을 때 취할 수 있는 선택지가 더 한정적이 될 수 밖에 없고 결국 개발 팀은 더 좁은 벼랑 길을 걸을 수 밖에 없게 된다. 그것도 다양한 혼란스러움과 함께 말이다.

 

사실, 애자일 적용에 대한 이런 내용은 애자일 도입 초반부터 강조 되었어야 하는 것이 맞다. 하지만, 애석하게도 그리 되지 않은 이유 중 하나는, 애자일 확산 초기에 애자일을 추진했던 사람들 중 다수에, 전통적인 개발 방법론를 비롯하여 UML, RUP 등의 기존 모델링 기법의 전문가나 관련 경험자들이 많이 포함되어 있었기 때문이다. 그래서 속칭, 선구자로 이름을 날린 이들의 말을 가만히 듣다 보면 애자일 방식만 알면 OK 가 아니라, ‘기존 방식은 기본으로 알고 있거나 여차 하면 쓸수 있다고 가정하고, 그 위에서 장단점을 살려 새로운 제안 방식들을 말 그대로 애자일하게 필요한 만큼 가져다 쓴다’는 개념이 종종 숨어 있다는 걸 알 수 있다. 마치, C나 C++에서 자바로 넘어온 중급 개발자들이, 기존 지식에 해당하는 주소(Address)와 포인터, 참조(reference) 등의 컨셉을 개발 기저에 놓고는 자바의 여러 가지 규칙을 그 위에서 이해하며 사용했던 것 처럼 말이다. 그에 비해, 자바로 개발 언어를 시작한 많은 개발자들은 주소나 메모리 관련 부분에서 초반에 곧잘 혼란을 겪을 수 밖에 없었다.(주1) 마찬가지로, 처음 애자일로 시작한 사람들은, 미묘한 전제 조건에 주의를 기울이지 않으면 오해/오용과 함께 헤매게 되기 쉽다. 결국 어설픈 개발 실력과 지식으로 Agile 개발 방식만을 흉내 내듯 팀에 도입하면 프로젝트가 훨씬 더 어렵게 진행되어 버린다는 이야기이다.

실제로, 애자일 접근방식의 하나인 스크럼(Scrum)을 열심히 따랐는데도 프로젝트들이 실패하는 현상들에 대해 마틴 파울러(Martin Fowler)는 ‘시들시들한 스크럼(Flaccid Scrum)’이라는 글에서 해당 현상의 이유를 비슷한 개념을 들어 설명하고 있다.

“스크럼에 기술관련 기법들이 범위(scope) 안에 포함하고 있지 않다고 해서 기술적인 기법들이 중요하지 않다고 생각해서는 안 된다” - http://martinfowler.com/bliki/FlaccidScrum.html

마찬가지로, 많은 스크럼 활동가들이 “좋은 기술적인 기법들을 사용하는 것, 그리고 그런 기술적인 기법을 적절히 사용할 수 있는 수준의 실력 있는 팀을 유지하는 것이 프로젝트 성공에 있어 중요한 점”이라고 지적 한다.

 

지금까지 애자일 개발 방식에 대해 이야기 했는데, 탐색적 테스팅의 경우도 이와 비슷하다..

 

탐색적 테스팅(Exploratory Testing, 이하 ET)은 Cem Kaner 의해 소개되었고 제임스 바크(James Bach)릍 통해 널리 알려진 방식으로 방법론이라기 보다는 테스트 접근 방식에 더 가깝다. SW 프로젝트에서 보통 테스트를 수행할 때에는, 테스트 관련 문서를 미리 작성하고 그에 맞추어서 절차적으로 진행하게 되는 데에 반해, ET는 계획서나 설계서 같은 문서를 미리 작성하지 않고, 테스터가 테스트 대상이 되는 제품을 직접 다루면서 자신의 경험과 지식을 기반으로 자유롭게 테스트를 진행한다. ‘탐색적’이라는 단어의 의미처럼, 제품을 조금씩 탐색해 가면서 테스트 범위를 늘려가게 되며, 결과적으로 테스터가 빠른 시간 내에 제품에 대해 효율적으로 테스트를 수행할 수 있게 된다. 말은 간단한데 실제로 이것만으로 탐색적 테스팅 기법을 적용하겠다고 마음을 먹는다면 ‘마구잡이 테스트’나 특별한 체계가 없는 ‘내 맘대로 테스트’가 되어서는 ET에서 이야기하는 장점을 누리지 못하고 혼란만 가중 되기 쉽다. 아니면 전통적인 테스트 방식을 따르기 싫은 거부감과 귀찮음에 대한 변명거리로 쓰이는 수준이 돼버리고 만다.

<Exploratory Testing : skill & tactics>

 사실 ET 접근 방식에도 적용 전에 고려해야 하는 중요한 전제 조건 하나가 있다. 테스트를 하게 될 테스터는 다양한 테스트 기법과 방법론에 익숙해져 있는 잘 훈련된 인원이어야 한다는 점이 바로 그것이다. 경험이 많고 지식이 쌓여있는 인원이 테스트를 해 나가기 때문에, 필요에 따라, 명세기반, 구조기반을 가로지르면서 등가 분할, 경계값 분석, 결정 테이블, 상태 전이, 유즈케이스, 페어와이즈 조합, 구문 테스트, 결정 테스트 등등 사용가능 한, 그리고 필요하다고 생각하는 방법은 무엇이든 적극 활용할 수 있어야 한다는 소리다. 이 부분이 단순히 경험에 따라 테스트 한다는 일반적인 경험기반 테스트 방식 과 ET를 구별 지어 주는 점이다.

 

이 글은, ET(탐색적 테스팅)을 설명하고자 하는 글은 아니지만 ET에 대해 조금만 더 설명하자면, ET를 효율적으로 수행하기 위해서는, 우선 경험 있는 테스터가 필요하고, 그 다음 선정된 테스터는 테스트 대상을 실제로 다루면서 학습을 해 나가고 학습된 부분에 대해 테스트를 계획(=설계)하고 테스트를 수행한다. 이런 식으로 학습과 계획, 테스트가 반복되는 주기(cycle)을 통해 제품 자체에 대한 이해도 높아지고 그와 함께 점점 더 효율적으로 테스트가 가능해 진다는 사상이다.

ET는 여러 면에서 애자일 방식과 매우 닮아 있다. 방법론으로 규정 짓기 어렵다는 점, 전체에 대한 설계를 위해 사전에 많은 시간을 투입하지 않는다는 점, 그리고 문서를 자세히 작성하는 데에 치중하기 보다는 수행 단계를 바로 시작해서는 점진적으로 발전해 나간다는 점이 유독 그러하다. 그래서 몇 가지 사항에 대해서는 애자일 개발방식과 장/단점을 공유하게 되는데, 개발자들에게는 플러스 요소와 마이너스요소를 함께 제공한다.

 

바로 실제 수행하는 인원들의 안정된 기술적 밑바탕이 필요하다는 점이다.

 

어떤 운동이 되었든, 해당 운동을 잘하기 위해서 아주 기본이 되는 요건은 그 운동을 하게 될 선수의 체력이다. 마찬가지로 어떤 방법론을 사용하던지, 어느 업무를 하든, 소위 말하는 'IT'이라는 걸 하는 한, 해당 방식을 잘 따라 해서 효과를 거두기 위해서는 참여 엔지니어들의 기술력은 기본이 될 수 밖에 없다.

 

하지만, 여러가지 이유로 우리는 기술을 버리고 관리를 우위에 두곤 한다. 생각보다 많은 경영자들은 엔지니어를, 그리고 기술을, 교체가능한(Replaceable) 일반재로 보는데, 내가 보기엔 '방법론/관리방식'이 훨씬 더 교체가능한 일반재라고 본다. 경영진이 몇 년에 한 번씩 바뀌어서는 새로운 정책을 도입할때, 어렵지 않게 적용하는 모습을 볼 때면 더더욱 그렇다는 믿음이 강해진다. 

어쨌든, 지금 까지 주절주절 이런저런 이야기를 했는데, 우리가 흔히 간과해서 애자일이나 탐색적 테스트 적용의 실패를 이곳 저곳으로 둘러대곤 했던 핑계를 잠시 접고, 그 근본이 깔려있는 숨은 원칙이 무엇이었는지 한 번쯤 곰곰히 따져 볼 필요가 있다.

마지막으로, 많은 이들이 끝까지 읽지 않고 넘어가서 곧잘 간과되곤 하는 애자일 선언문의 뒤에 나오는 '숨은 원칙들'에 대한 부분 중 하나를 인용하며 글을 마칠까 하다.

탁월한 기술과 뛰어난 설계에 대한 끊임없는 관심은 기민성(Agility)을 강화시킨다.
- Principles behind the Agile Manifesto

이미지 출처

http://www.flickr.com/photos/zerega/2774725981/

http://www.flickr.com/photos/twelve-paws/3717904846/

http://www.flickr.com/photos/23076491@N02/3115363478/

주1. 비약이 컸다면 양해를 :)