기본 콘텐츠로 건너뛰기

Agile Testing에 대한 단상

근래에 들어 가장 화두에 오르는 단어 중 하나가 바로 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라는 주제에 대한 글들을 접해 보면 대부분 공통적으로 기존의 방법론을 Agile 조직에 적용하기 위해 경량화 하는 방법 또는 테스트 자동화에 대한 주제가 대부분이다.

어떤 사람들은 탐색적 테스팅을 애자일 테스팅과 혼용해서 이해하는 분들도 있지만 애자일 테스팅과 탐색적 테스팅을 연관이 없다고 봐도 무관하다.

그렇다면 왜 애자일 테스팅에 대해 획기적이고 아주 새로운 방법이 나오지 못하는 것일까?

그것은 개발과 테스팅이 전혀 다른 성격을 가지고 있기 때문이 아닐까? 싶다.

일전에도 언급한 적이 있지만 애자일 에서는 개발과 테스팅, 설계를 담당하는 사람들의 역할이 매우 모호하다.

테스팅 진영에서도 대부분 테스터가 개발 지식을 알아야 한다는 것이 주론이다. 어떤 사람들은 테스터가 개발도 할 수 있어야 한다고 말한다.

하지만 난 아니라고 생각한다.

왜냐하면 개발과 테스팅은 상대방이 없으면 절대로 안되는 아주 밀접한 관계를 지니고 있지만 실상은 거의 상극에 가깝기 때문이다.

개발은 대체적으로 창조적인 작업이다. 무엇인가를 만드는 작업이다. 우리는 일반적으로 무엇인가를 만들어 나갈때 더 많은 방법을 생각하게 된다.

애자일에서 개발과 설계에 대한 논의가 더 활발한 것은 이런 속성에 기인한다고 생각한다.

더 빠르게, 더 안정적인 개발을 하기 위한 방법에 대한 논의는 다양해 질 수 있다.

하지만 테스팅은 파괴적인 작업이다. 무엇인가를 비틀고 파괴하고 해체하는 작업이다. 이러한 작업은 대체로 그냥 막가는 방식으로 해체하거나(탐색적 테스팅), 만들어진 방식을 역순으로 해체하는 작업(스크립트 기반 테스팅) 이외에는 별다른 방법이 없다.

테스트 설계 기법은 이러한 만들어진 방식을 이해하기 위한 일종의 기법이라고 생각된다.

이런 면으로 접근하면 분명 테스터가 개발 지식을 어느 정도 알고 있다면 테스팅에 큰 도움이 된다는 것은 맞는 말이다.

하지만 테스터가 개발을 할 수 있을 것 같지는 않다.

마찬가지로 TDD의 문제점은 개발자가 테스터와 같은 사고 방식을 가지기 힘들다는 점에 있다고 생각된다.

개발과 테스팅은 사람의 두 다리와 같다고 생각된다. 한쪽이 기형이거나 없다면 사람은 걸을 수가 없게 된다.

그리고 왼쪽 다리가 없다 해서 그 자리에 오른쪽 다리를 이식할 수도 없는 것이다.

각 다리가 정확하게 역할을 해야만 사람이 올바로 걸을 수 있는 것처럼 개발과 테스팅이 서로를 보완하고 각자의 할일을 잘 할 때 개발도 잘 되는 것이 아닐까?

난 Agile Testing에서 테스터가 어떻게 하면 더 개발을 잘 할 수 있을까? 라던지 자동화를 어떻게 하면 더 잘할 수 있을까? 라는 논의도 중요하지만 개발자와 어떻게 하면 협업을 더 잘할 수 있을지? 신속한 개발 환경에서 어떻게 하면 테스팅을 더 잘할 수 있고 그 안에서 테스트의 역할을 어떻게 정의할 수 있을지에 대한 논의가 더 활발해 졌으면 하는 바램이다.

댓글

  1. 고개를 끄덕이게 하네요!! 좋은 글 감사합니다.~

    답글삭제
  2. 김주봉22/6/10 18:53

    좋은 글 감사합니다.

    Gracias! (감사합니다.)

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다. 각각에 대한 정의가 다 제각각입니다. 사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다. 물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만.. ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다. 예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다. 실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다. 그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다. 그렇습니다. 어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데.. 테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다. 최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다. 전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다. 하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다. 프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요. 전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다. 더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다. 이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS 사이즈의 이어팁

탐색적 테스팅의 역사

이 글은 James Bach 의 ' Exploratory Testing 3.0 '을 번역한 글입니다. 이번 글은 의미를 전달하는데 무리가 없는 선에서 대부분 의역으로 번역되었습니다. 때문에 잘못 번역된 부분은 댓글로 남겨주시면 수정하도록 하겠습니다.(읽어보시면 시제나 문체가 시시각각으로 변합니다. 감안해서 읽어주시면 고맙겠습니다.) 이 글은 James Bach의 허락을 얻은 후 번역한 글로 다른 곳에 퍼가실때는 반드시 원 출처와 본 블로그를 같이 언급해주시기 바랍니다. ----- [저자 주: 다른 글에서 이미 탐색적 테스팅을 이제는 테스팅으로 불러야 한다는 것을 얘기했다. 사실 Michael은 2009년에 테스트에 대해 얘기했었고, James는 테스터에 대해 얘기했던 것을 2010년에 블로그에 작성했다. Aaron Hodder는 2011년에 직접적으로 언급했고 Paul Gerrard 역시 그러했다.우리는 모든 테스팅은 탐색적이라는 것을 깊이 이해하고 가르쳤지만(여기에 James가 작년에 한 학생과 대화를 나눈 예가 있다.), "탐색적 테스팅"이라는 용어를 더이상 사용하지 않을 준비가 되어 있지 않다. 지금도 우리는 탐색적 테스팅이라는 용어를 사용하지 말아야 한다고 주장하지는 않는다. 다만 테스팅이 탐색을 어느 정도 포함한 스크립트 테스팅을 의미하는 것이 아니라 테스팅이 곧 탐색적 테스팅이라는 것이다.] By James Bach and Michael Bolton 태초에 테스팅이 있었다. 아무도 탐색과 스크립트 테스팅을 구별하지 못했다. Jerry Weinberg는 1961년 Computer Programming Fundamentals에서 테스팅의 형식화(formalizing)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단