기본 콘텐츠로 건너뛰기

생산성 혁신의 순서로 보는 테스팅 조직의 성숙도

프랙탈이라는 것이 있습니다.

부분 부분의 모습이 자기 복제를 통해 전체 역시 동일한 형태를 가지는 기하학적인 도형을 일컫는 말입니다.

즉, 전체와 부분이 유사한 형태를 지닌다는 말입니다.

테스팅 조직의 성숙도와 발전 역시 회사의 성숙도와 발전과 유사한 모습을 지닙니다.

생산성 혁신의 순서는 제조업의 발전과 맞물려 있지만 그 발전 순서는 작은 조직 또는 개인의 발전에도 충분히 적용하여 생각해 볼 수 있습니다.

아무리 작은 조직과 개인이라도 자신의 생산성을 더 낫게 만들기 위해서 노력합니다. 더 나아진 상태로 나가기 위해 항상 노력하는 것은 어쩌면 우리의 본능일지도 모릅니다.

그런데 우리 자신과 우리의 조직이 항상 생산성 혁신을 성공하는 것은 아닙니다. 많은 경우는 실패로 끝나는 경우도 많습니다.

왜 그런것일까요?

가장 큰 원인은 자신의 성숙성과 관계가 있습니다. 자신의 조직이 현재 어떤 단계에 있고 그 단계에 어떤 접근법을 취해야 할것인지에 대한 고민도 없이 최신의 방법론을 도입하기 위해 서두르기 때문입니다.

어떻게 하면 우리는 성공할 수 있는 것일까요? 그것은 지금 자신의 상태와 환경에 적합한 방법론을 선정해서 합리적인 절차에 따라 수행하는 것이라고 생각합니다.

그러한 합리적 절차는 5S 3I로 요약할 수 있습니다.

5S와 3I란 경영 혁신 절차 8단계의 머리 글자를 딴것입니다.

각 경영 혁신 절차는 그 시대적 환경에서 기업이 부딪친 경영 환경에 맞게 개발된 시대적 산물로 우리 조직 역시 아무리 노력한다고 해도 그 기간을 단축할 뿐이지 각 단계를 뛰어넘을 수는 없습니다.

그것은 개구리 알이 올챙이가 되고 앞다리가 나오고 뒷다리가 나오고 꼬리가 사라져야 개구리가 될 수 있지 중간의 어떤 단계도 건너뛸 수 없는 것과 마찬가지입니다.

만약 여러분이 테스팅 조직 성숙도 모델인 TMMi나 TPI 또는 ISO/IEC 29119과 같은 표준, Agile Testing와 같은 방법론을 도입하려고 노력해도 성공하지 못한다면 여러분의 조직은 아직 이러한 단계를 도입할 준비가 되지 않은 것입니다. 여러분이 알아차리지 못했던 어떤 단계에 대한 더 나은 성숙도에 도달해야만 그 다음 단계를 성공할 수 잇씁니다.

즉, 먼저 그 길을 달려갔던 조직과 회사가 성장하면서 거쳤던 생산성 혁신의 순서를 우리도 짧게나마 밟지 않으면 안되는 것입니다.

생산성 혁신을 생각할 때 가장 먼저 생각할 것이 전문화입니다.

크게는 개발팀과 테스팅을 구분하여 전문화 하는 것을 생각해 볼 수 있고 테스팅 안에서도 테스트 설계, 성능 테스팅, 보안 테스팅, 사용성 테스팅 등 각각의 영역에서 전문성을 취하고 분업화를 하는 단계라고 볼 수 있습니다.

전문화 다음으로 생각할 수 있는 것이 표준화입니다.

업무 수행의 표준화, 보고서의 표준화, 코딩작성 방법에 대한 표준화 등 생각해 볼 수 있는 표준화는 무척 많습니다. 표준화란 약속이며 질서를 만드는 단계라고 볼 수 있습니다.

전문화와 표준화가 이루어지면 그 다음으로 찾아오는 것이 단순화입니다.

단순화는 전문화와 표준화를 거치면서 복잡해졌던 많은 단계를 단순화 하는 단계입니다.

제 경험상 많은 업체들은 아직까지는 표준화 진행 단계로 생각됩니다. 많은 조직에서 ISO 인증이나 표준의 도입들에 열심을 낼 뿐, 그 표준에 있어서 어떻게 자신의 조직에 맞게 적절하게 단순화 시킬 것인지에 대한 고민은 그다지 많지 않은 것 같습니다.

이렇게 전문화, 표준화 , 단순화를 생산성 혁신의 3S라고 합니다.

이 3S에 정확한 측정과 그에 걸맞는 보상 체계를 맞추는 과학화가 더해져 4S가 됩니다. 이러한 합리적 보상체계는 조직 구성원에 대해 동기를 부여하는 요인이 됩니다.

그리고 이러한 보상 체계는 직간접적으로 조직의 구성원의 활동에 영향을 미치게 됩니다.

가장 흔하게 얘기되는 예가 테스팅 조직의 보상 체계로 테스터를 결함의 갯수로만 평가하게 된다면 테스터는 발견하기 쉬운 결함에만 집착하게 됩니다.

이렇게 되면 테스팅의 완성도와 조직 전체에 좋지 않은 영향을 끼치게 되는 것은 자명한 일입니다.

과학화란 테스팅의 완성도를 높이기 위해서 반드시 의미있는 매트릭을 개발해야 된다는 것입니다.

이상과 같은 4S는 순차적으로 진행될 수도 있지만 사실 순차적이라기 보다는 병렬적으로 그리고 개별적으로 진행되는 개선으로 4S가 조화를 이뤄 효과를 내기 위해서는 이를 체계화할 필요성이 있습니다.

이것을 우리는 프로세스라고도 부르고 어떤 경우는 모델 또는 방법론이라고도 부르는 것입니다.

이는 다섯번째의 S로 시스템화입니다.

어떤 제품을 이루는 부품들이 흩어지면 아무런 힘이 되지 않지만 정해진 역할에 따라 모인다면 목표로 하는 효과가 나타나는 것처럼 효과가 극대화되기 위해서는 전문화, 표준화, 단순화, 과학화의 4S가 이루어지고 난 다음에는 이를 시스템으로로 구축해야할 필요가 있습니다.

이렇게 시스템이 구축되면 그 다음이 1I, 집적화 입니다.

집적화란 고객의 요구사항에 대한 신속한 대응을 말합니다. 즉, Agile 개발 방법론 등이 목표로 하는 바가 이 집적화 단계입니다.

다른 말로 한다면 조직 자체가 5S 단계를 거쳐서 이루지 못했다면 Agile 개발 방법론을 아무리 도입하려고 해도 그 효과가 빠르고 직접적으로 나타나지 못한다는 것과 같습니다.

그 다음은 2I, 지능화입니다.

지능화는 무인 자동화를 말합니다. 지능화 단계는 선진국에서도 실험적인 응용이 시도중인 단계입니다. 하지만 우리 나라에서는 많은 경우 이전 단계들을 무시하고 자동화만을 추구하는 우를 범하는 경우도 많습니다.

마지막 3I 는 비상식화의 단계입니다.

기존의 상식적인 개선으로 한계에 다다랐을 때 생각해 볼 수 있는 것이 이 단계이고 이것을 혁신이라고 합니다.

즉, 혁신이라는 것을 이루기 위해서는 상식의 기초가 갖추어져야 한다는 것입니다.

정리해 본다면 생산성 혁신은 아래와 같은 순서로 진행됩니다.
생산성 혁신의
여러분과 여러분의 조직은 지금 어느 단계에 도달했나요? 어떤 단계가 부족한가요?

발전하고 발전해서 더 나은 단계에 도달하고 싶으시다면 꼭 한번 여러분의 조직이 현재 어떤 환경에서 어떤 단계에 도달해 있는지 꼭 한번 고민해 보시기 바랍니다.

만약 객관적인 시각이 필요하시다면 믿을만한 컨설팅 회사를 찾아보시기 바랍니다. 만약 여러분의 조직이 가지고 있는 제약과, 강점과 약점, 환경을 고려하지 않고 단순히 자동화, 표준화 만을 강조한다면 그 컨설턴트는 가짜일겁니다.

여러분이 지금 추진중인 6시그마, TQC, Agile, Lean 등의 방법론이 정착되지 못하고 힘들고 어렵고 실패한 경험이 있다면 방법론이 잘못된 것이 아니라 여러분의 성숙도가 문제인 것입니다.

여러분을 돌아보시기 바랍니다.

개인적으로는 우리 나라의 IT와 SW 업계를 포함해서 테스팅 조직에서 가장 필요한 단계는 단순화 그리고 시스템화와 함께 TQC 적인 사고와 정책의 도입이 아닌가 생각됩니다.

댓글

이 블로그의 인기 게시물

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

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, 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)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단