테스팅 히치하이커를 위한 안내서

최근에 ISTQB 재단에서 Agile Tester 자격증이 런칭이 되기도 했고, xper의 slack 채널에서 이런 저런 얘기가 오고가다.. 어떻게 하다 보니.. 행아웃으로 몇명의 사람들이 모여서 '애자일 테스팅 자유 주제 토론'이라는 것을 진행해보았습니다. 지난 4월 30일에 첫번째 모임을 행아웃 화상채팅으로 진행했고 어제 5월 14일에 두번째 모임을 행아웃 온에러로 진행해보았습니다. 관련 내용은 http://j.mp/XperAgileTesting 에서 보실 수 있습니다. 어제 진행된 내용은 http://youtu.be/udvWjRTdVVg 에서 들어보실 수 있습니다. 좀 쓸데 없는 얘기도 많지만 재미 삼아서 한번 들어보세요. 이런 모임을 계속 진행할지는 잘 모르겠습니다. 혹시 나누고 싶은 주제를 댓글이나 xper 메일링 리스트로 공유해주시면 다음 모임을 추진해보도록 하겠습니다. 그리고 두번 진행된 간담회 내용 중 궁금하신 내용 등도 댓글로 남겨주시면 고맙겠습니다.

생산성 혁신의 순서로 5S 3I 를 소개한 적이 있습니다. 5S와 3I란 경영 혁신 절차 8단계의 머리 글자를 딴것으로 분업화, 전문화, 표준화, 과학화, 시스템화, 집적화, 지능화, 비상식화를 말합니다. 관련된 내용은 http://murian.textcube.com/351 나 검색을 통해 알아보시면 좋을 것 같습니다. 이 5S 3I를 기반으로 Agile 과 Waterfall 의 관계에 대하여 나름대로 각색을 해보았습니다. 결론적으로 말한다면 저는 Agile 은 절대 은총알이 될 수 없다는 것과 Waterfall 조차 제대로 수행할 능력이 없는 조직은 Agile 을 도입하지 않는 것이 좋다고 생각합니다. 저는 5S 3I가 아래와 같은 관계를 가지면서 발전한다고 생각합니다. 하나씩 설명을 하자면 전문화와 표준화는 거의 동시적으로 발생하는 가장 초기 단계의 활동이라고 생각합니다. 그리고 전문화와 표준화를 묶어주는 아교와 같은 역할을 하는 것이 과학화라고 생각합니다. 단순화는 부분적으로 발생할 수도 있고 그렇지 못할 수도 있다고 생각합니다. 개인적으로는 잘 발생하지 않는 활동이라고 생각됩니다. 특히나 표준이나 인증을 도입하는 경우에는 거의 발생하지 않는 활동이라고 생각합니다. 결론적으로 전문화, 표준화, 단순화 즉, 생산성 혁신의 기본 3S 는 순차적이라기보다는 병렬적으로 발생하는 활동이라고 생각합니다. 그리고 이 3가지 활동을 유기적으로 묶어주는 것이 과학화라고 생각합니다. 이렇게 4가지 활동이 묶이면 하나의 시스템 즉, 프로세스가 된다고 생각합니다. Waterfall 은 이 4가지 활동으로 묶여진 하나의 프로세스 즉, 방법론인 것입니다. Waterfall 안에는 전문적인 분업조직과 R&R이 있고, 그러한 활동들에 대한 표준적인 사항들이 있으며 그러한 사항들을 측정하는 측정 지표가 모두 포함되어 있습니다. 기존에는 이 Waterfall 로도 충분한 환경이었다면 이 환경에 충격을 가한 것이 1I 즉, 집적화라고 생각합니다. 시간은 흘러 고객은 변했고 고객은...

xper 모임을 나가보거나 주변에서 얘기되는 Agile 얘기를 나눠본지도 벌써 2년이 다되어 가는 것 같습니다. STA Consulting Inc. 에서는 얼마전 2010년 테스팅 트렌드의 하나로 Agile Testing 을 이야기했고, 4월 21일에는 애자일(Agile) 소프트웨어 개발 및 테스팅 세미나 가 열리기도 합니다. 그런데, 여기저기 이야기를 나누고 다니다 보면 Waterfall 개발방법론과 Agile 개발방법론을 대척점으로 놓고 이해하고 있는 사람들이 은근히 많습니다. 마치 흑백의 논리 처럼 명확하게 둘을 구분짓고 대척점에 놓는 사람들 말입니다. 과연 그런것일까요? Agile 과 Waterfall 은 흑백처럼 서로 절대 만날 수 없는 견우와 직녀와 같은 그런 관계일까요? 저는 아니라고 생각합니다. 제약이론의 사고 프로세스에 의하면 Agile 개발 방법론은 궁극적으로 발전된 형태의 Waterfall 로 규정할 수 있습니다. 팀의 진화에 따라 많은 조직은 Waterfall 에서 Agile 로 자연스럽게 이동하게 되어 있다라는 결론에 도달합니다. 또한 Agile 그 너머를 생각해 볼 수도 있습니다. 많은 조직에서 Waterfall 을 통해 실패와 한계를 경험하고 그것을 극복하기 위한 방법의 하나로 Agile 을 도입하려고 합니다. 하지만 생각보다 Agile 로 성공적으로 이행하는 조직은 많지 않습니다. 분명 많은 성공사례가 보고되고 있지만 실제 현실에서는 여러 이유로 실패하는 경우가 많습니다. 왜 그런것일까요? 전 이것을 '모 아니면 도'와 같은 생각으로 Agile 을 도입하였기 때문이라고 생각합니다. 사람들은 Waterfall 반대편에 있는 것을 Agile 로 규정하고 Agile 을 도입하면 Waterfall 에서 발생한 모든 문제가 모두 해결될 것처럼 생각하기 때문에 실패한다고 생각합니다. 그리고 그러한 가정은 틀렸다라는 것이 제 생각입니다. Waterfall 에서도 제대로 된 성공경험이 없는 조직은 Agile 을 도입한다고 해도 ...

근래에 들어 가장 화두에 오르는 단어 중 하나가 바로 Agile이다. 그리고 그 이면에 아직까지 활발히 논의 되지 못하고 있는 것 중 하나가 Agile Testing이다. 나름 수많은 Agile 관련 모임을 나가보았지만 오고가는 이야기는 Management, Development, Design 과 같은 이야기는 오고 가지만 막상 Testing에 관한 논의는 찾아보기 힘들다. 실제로 TDD는 분명 테스트라는 단어를 사용하고 있지만 막상 테스트를 어떻게 설계할 것인가에 대한 논의는 그다지 활발하지 않다. 일전에 켄트 벡이 국내에 방한 했을 때 어렵게 질문을 해보았지만 켄트 벡은 디자인에 관한 답변만을 들려주었다. Agile Testing은 무엇일까? 이 질문에 대한 답을 하기 위해서는 Agile이 무엇인지에 대해 먼저 생각해 볼 필요가 있다. Agile은 무엇인가? 어떤 사람은 TDD, XP와 같은 개발 이야기를 하고, 어떤 사람은 Scrum, Lean 과 같은 관리 이야기를 하는 경우도 있다. 모든 사람이 동일하게 Agile에 느끼고 공감하는 것은 생각보다 찾아보기 힘들다. 하지만 많은 사람들이 애자일 선언이 Agile이 추구하는 목표와 목적 그리고 근간이 된다는 것에는 그다지 이견이 없다. 현재까지 나와 있는 많은 도구와 방법론은 애자일 선언에서 얘기하는 가치관을 달성하기 위한 것들이다. 그렇다면 Agile Testing은 어떨까? Agile Testing 역시 애자일 선언의 영향을 받고 있는 것일까? 개인적인 내 의견을 말한다면 아니다이다. 개인적으로 Agile Testing에 대해 정의하자면 Agile Testing은 Agile 조직 또는 프로세스 안에서 테스팅을 수행하기 위한 방법에 대한 통칭 정도로 정의할 것이다. Agile Testing이라고 해서 아직까지 나는 특별히 새로 만들어진 기법이나 방법론을 접해본 적이 없다. Agile Testing라는 주제에 대한 글들을 접해 보면 대부분 공통적...