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

저는 업무차 한달에 한번 정도는 꼭 다른 회사의 사무실에 방문합니다. 저는 다른 회사를 방문할 때 티가 나지 않게 회사 직원들의 책상과 벽을 살펴보는 버릇이 있습니다. 왜냐하면 직원들의 책상과 벽을 통해서 그 회사가 무슨 일을 하고 어떤 정책적인 가치들을 추구하는지 짐작할 수 있기 때문입니다. 어떤 회사는 참 깨끗합니다. 우리는 깔끔하면 참 좋을 것 같지만 저는 갑갑합니다. 그 깨끗함을 유지하기 위해 얼마나 많은 노력을 기울였을까요? 그 노력으로 다른걸 한다면 어떨까요? 그런 깨끗함을 유지하려면 알게 모르게 많은 규칙들이 있을 겁니다. 이것도 안돼, 저것도 안돼, 안돼! 안돼! 안돼! 그런 조직이 과연 얼마나 즐겁고 좋은 곳일까요? 게임 회사를 상상해 보시기 바랍니다. 게임 회사는 특이하게도 어떤 업체를 방문해도 벽에는 회사에서 개발한 게임들의 포스터와 피규어로 장식되어 있고 직원들의 책상에는 자신만의 취미생활로 가득차 있습니다. 그런 회사들은 뭔가 항상 활기가 가득합니다. 한 회사 안의 벽이 어떻게 꾸며지고 사무공간이 어떻게 꾸며지는 것은 어떻게 보면 아주 하찮은 문제처럼 여겨집니다. 하지만 회사의 사무 공간은 우리가 하루에 8시간 이상 머무는 아주 중요한 장소입니다. 저는 그 장소가 최소한 편안해야 한다고 생각합니다. 자기가 원하는 것으로 꾸며질 수 있어야 한다고 생각합니다. 그리고 조직의 벽은 정말 필요한 것들로 채워져야 한다고 생각합니다. 어떤 회사처럼 한쪽 벽면 전체가 화이트보드로 되어 있어 직원들이 자유롭게 생각을 나눌 수 있도록 하는 것도 좋다고 생각합니다. 아니면 번다운 차트나 칸반 차트와 같이 실제적인 프로젝트의 정보가 표시되는 안내판이 설치되어도 좋을 것 같습니다. 이렇게 조직과 회사의 벽과 사무공간이 어떻게 꾸며지는가는 개인의 선택과 회사와 조직의 문화가 반영된 결과입니다. 여러분은 어떤 벽을 원하십니까? 그리고 그 벽을 어떻게 이용할지 누가 선택합니까? 저는 그 벽을 항상 마주보고 있어야 하는 사람이 선택해서 꾸밀 수 있어야 한다고 생각합

테스트란 기술은 아무리 좋게 포장한다고 하더라도 다른 사람에게 있어서는 자신을 비방하며 괄시하는 기술로 보이는 것이 사실이다. 왜냐하면 결함이라는 것이 제품의 결함처럼 보이지만 실상은 그 제품을 만든 사람들의 실수를 지적하는 것이기 때문이다. 즉, 테스터는 결함보고서를 통해 누군가를 꾸짖는 사람이라고 볼 수 있다. 꾸짖음은 많은 경우 부정적인 측면을 만들기 마련이고, 그것을 좋아하는 사람은 많지 않다. 그만큼 결함을 보고한다는 작업은 참 하기 힘든 작업 중 하나이다. 하지만 누군가 그런 실수를 지적해주지 않는다면 결국 만들어진 제품은 비효율적이고 한단계 더 나은 단계로 발전할 수 있는 기회조차 잃어버리게 될 것이다. 그렇기 때문에 테스터가 갖춰야 할 덕목은 여러가지가 있지만 그 중 하나가 다른 사람을 잘 꾸짖는 법을 아는 것이 중요하다. 우리가 흔히 하는 실수 중 하나가 자신은 남보다 더 잘난 듯 말한다는 것이다. 남을 질책할 때 자신이 기준이나 표준인것처럼 얘기한다는 것이다. 더 재미있는 것은 다른 사람들은 얘기를 하고 있는 사람의 단점이나 결점을 알고 있는데도 그렇게 얘기한다는 것이다. 사정이 그렇게 되다보면 당연히 신뢰를 잃게 되는 것은 당연지사이다. 왜 이런 실수를 하는 것일까? 거기에는 오만과 우월감을 과시하고자 하는 우리의 작은 욕망 때문에 그런 것이다. 이런 실수를 극복하기 위해서는 우선 자신을 질책하는 것에 익숙해질 필요가 있다. 물론 자아비판이란 매우 하기 힘든 행동이다. 왜냐하면 우리는 자기 자신에게 무척 관대하기 때문이다. 때문에 더 좋은 방법은 남의 질책을 받아들이는 것이다. 남의 비판을 수용하고 그것을 수용할 수 있는 능력이 절실하다. 하지만 대부분의 사람들은 역시 비판을 좋아하지 않는다. 이로 인해서 발전 가능성을 손상시키고 결국에는 고만고만한 지극히 평범한 수준에 자신을 제한해 버린다. 이것이 우리 나라에 아이폰이나 아이패드와 같은 혁신적인 제품이 나오지 못하는 이유 중 하나라고 생각한다. 테스터가 제품의 혁신과 품질의 향상에 대한

여러분의 조직에서는 테스트케이스를 누가 만드십니까? 아니, 여러분의 조직에서는 테스트케이스를 만드십니까? 여러분의 조직에서는 얼마나 자주 테스트케이스를 교체하십니까? 많은 경우에 테스트케이스는 테스트 리드나 매니저와 같은 테스터의 장이 만듭니다. 테스터는 그렇게 만들어진 테스트케이스를 가지고 열심히 제품을 테스트 합니다. 아주 일반적인 광경으로 거부감이 없으신가요? 하지만 매번 이렇게 일한다면 테스터는 과연 뭐하는 사람일까요? 만약, 여러분이 성공하는 테스터가 되고 싶으시다면 여러분이 해야할 일을 찾아서 여러분이 하시기 바랍니다. 먼저 여러분이 제품을 분석하고 여러분이 테스트케이스를 만들겠다고 선언하시기 바랍니다. 만약 여러분이 의도적으로 이렇게 하지 않으신다면, 누구도 여러분에게 테스트케이스를 만들라고 하지 않을 것입니다. 여러분이 할 일을 다른 사람이 하게 되는 것입니다. 여러분은 그 사람들의 노예나 기계가 되어 버리는 것입니다. 이것은 조직이라는 기계속에서 닳고 닳아 없어져 버릴 하나의 부속품처럼 된다는 것입니다. 많은 계약직 테스터들이 이렇게 사라져갔습니다. 여러분도 그렇게 사라지고 싶으신가요? 많은 관리자들은 직원들이 스스로 생각하는 것을 좋아하지 않습니다. 직원들이 스스로 생각한다는 것은 직원들이 밖에 나가서 사고를 치고 회사에 유무형적인 막대한 피해를 끼치는 아주 위험한 행위라고 생각합니다. 관리자는 직원을 신뢰하지 못합니다. 그런데 그 신뢰하지 못하는 직원과 함께 꿈과 미래를 얘기하는 아이러니한 상황을 매일 반복하고 있습니다. 이보다 재미있는 개그가 또 있을까요? 관리자들은 항상 직원들이 자신처럼 생각하기를 바랍니다. 자신과 항상 똑같은 것을 바라보기를 원합니다. 하지만 사람은 그렇게 하지 못합니다. 그렇기 때문에 어떤 관리자들은 모든 일을 끌어안고 자폭하기도 합니다. 참 불쌍한 사람이 아닐 수 없습니다. 이런 조직에서 직원들은 관습에 따르고 순응해야만 합니다. 하지만 이런 조직에서 행해지는 테스트는 살충제 패러독스에 빠져들어갈 확률이 99.9%

정말 오랜만에 xper 5월 정기 모임을 다녀왔습니다. 사실 그동안 이런 저런 핑계로 참석을 못했지만 이번에는 김창준님 그 유명한 제럴드 와인버그 의 PSL 워크샵 후기 발표가 있어서 기필코 참석하겠다는 의지와 함께 끝내 참석할 수 있었습니다. 아마 와인버그 생전에 제가 PSL 워크샵에 참석할 수 있을 것 같지는 않지만 김창준님을 통해 간접적으로 경험해복 참 많은 걸 생각해 볼 수 있던 복 받은 자리였습니다. 제가 최근에 읽었던 '절대로 후회하지 않을 선택의 기술'이라는 책과 제약이론의 사고 프로세스와 맞물려서 참 많은 걸 생각해 볼 수 있던 자리였습니다. 이번 정기 모임에서는 김창준님이 PSL 워크샵에서 하셨던 일종의 역할극을 체험했습니다. 이 역할극이라는 것이 사람을 몰입하게 하더군요. 하지만 전 초반에 감옥에 끌려가서 참여자가 아닌 관찰자와 같은 입장으로 역할극에 참여하는 기이한 경험을 했습니다. 역할극을 통해서 제가 느낀 것은 정보의 공유 그리고 투명성이 조직과 사람 사이의 관계에서 얼마나 중요한가를 느낄 수 있었습니다. 역할극을 통해 제가 느낀 것들은 아래와 같습니다. 사람은 시지키 않으면 움직이지 않는다. 그냥 논다. 하지만 동기가 부여된다면 사람은 움직인다. 사람이 모이면 리더가 생긴다. 리더의 능력치가 높으면 조직의 능력치가 같이 높아진다. 유능한 리더는 목표를 명확히 제시한다. 목표가 명확하고 리더가 유능해도 조직에는 꼭 노는 사람(방관자)가 생긴다. 상황이 긴박해질수록 조직의 집중도는 향상된다. 뭔가 우리 일상생활에서 보던 모습들이 그대로 투영된 느낌이었습니다. 그리고 그 속에서 제가 어떻게 행동하는지를 생각해 볼 수 있었습니다. 위의 느낌들로 제가 앞으로 노력하기로 마음 먹은 것은 선택의 폭을 넓히기 위해 노력하자라는 것입니다. No라고 말하기 전에 Yes라고 말하기 위해 한번 더 고민하고 노력해야 겠다는 것이었습니다. 김창준님이 리더쉽이란 문제해결을 위한 창조적인 생각을 해낼 수 있는 권한이 생기는 환경을 만들어 내는 능력(

지난 5월 19일 STA 컨설팅과 STEN에서 매달 한번씩 진행하는 야간 세미나에서 사용성 테스팅에 대해 발표했었습니다. 많이 부족한 발표였지만 많은 분들이 들어주셨고, 몇몇 분들은 유익하고 좋은 발표였다고 격려도 해주시고 어떤 분은 제가 실수한 부분에 대해서 지적도 해주셔서 개인적으로도 무척 유익했던 발표였습니다. 아래는 그날 발표한 내용의 요약본입니다. 발표내용 보기.. 요즘 가장 뜨고 있는 화두, 가장 유행하고 있는 단어 중 하나를 꼽는다면 바로 UX라는 단어입니다. IT 업계에 종사하고 있는 사람이나 그렇지 않은 사람이나 UX라는 단어는 더 이상 낯설지만은 않은 단어입니다. UX 단어 이전에는 UI나 사용성이라는 단어가 있었다면 요즘은 사용자의 경험을 더 강조하면서 기존의 개념들을 포괄하는 UX라는 단어가 완전히 대세로 자리잡았다고 볼 수 있습니다. 하지만 테스트 업계에서는 아직 UX 테스트라는 명칭보다는 사용성 테스팅이라는 명칭이 더 익숙하고 친숙한 단어입니다. 사용성은 ISO/IEC 9126 의 주 특성 중 하나로 아주 익숙한 개념이지만 실제 사용성에 대하여 물어보았을 경우 사용성에 대하여 명확하게 대답할 수 있는 사람은 의외로 많지 않습니다. 또한 대답하는 사람들마다 사용성에 대한 정의가 조금씩 다 다르게 정의를 합니다. 위의 슬라이드에서 보시는 바와 같이 사용성은 여러곳에서 조금씩 다른 의미로 정의되고 해석되어 왔습니다. 하지만 위의 정의들을 포함해서 여러분이 알고 계시는 사용성의 정의에 대해 조금만 생각해보시면 모든 사용성의 정의에 꼭 빠지지 않는 3가지가 있습니다. 그것은 사용자 사용자와 제품의 상호 작용 사용자의 경험 입니다. 위 3가지의 중심에는 사용자가 있습니다. 사용자는 사람입니다. 즉, 사용성 테스팅은 제품이 아닌 사람을 테스트 하는 것이고 이것이 사용성 테스팅의 정의를 어렵게 하는 하나의 요소가 되었습니다. 이런 사용성은 우리 주변에서 흔하게 접할 수 있습니다. 우리가 불편하다, 편하다라고 느끼는 가장 원초적인 감

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해 - 로버트 L. 글래스 지음, 윤성준 외 옮김/인사이트 이 책은 IT 업계에서 소프트웨어를 개발하는 작업에 관계된 모든 사람들이 미처 깨닫지 못했거나 알면서도 무시했던 수많은 오해와 사실들에 대해 화두를 던지고 있다. 어떤 것들은 우리가 진실로 믿었던 것이 진실이 아닐 수 있다는 것에.. 어떤 것들은 우리가 이미 알고 있었던 사실이지만 애써 무시했던 것에.. 그런 것들에 대해 다시 한번 생각해 볼 수 있도록 저자의 오랜 경험과 수많은 인용서적들을 통해 우리에게 다시 한번 질문을 하고 있다. 이 책을 읽은 후 그래 다 알고 있는 사실이지만 우리는 어쩔 수 없어라는 패배주의에 빠지지 않았으면 한다. 틀린 것은 틀리다고 맞는 것은 맞다고 말하는 사람이 점점 더 많아져야 시궁창 같기만 한 우리의 현실도 바뀔 수 있지 않을까 싶다. 물론 이 책의 모든 내용에 대해 나 자신조차 100% 동의하기 힘든 부분도 있다. 그것이 내 일천한 경력과 지식 때문일 수도 있고, 저자와 내가 겪었고 처했던 상황이 다를 수도 있기 때문이 아닐까 싶다. 이 책은 한번 읽고 덮어버리기보다는 잊지 않기 위해 여러번 읽어도 충분히 좋은 내용들로 가득차 있다. 이 책에 5점 만점에 5점을 부여하는 바이다. http://murian.textcube.com 2010-05-14T01:29:21 0.3 10 10

SW Testing Camp 가 2주 앞으로 다가왔습니다. 지난하고 길었던 준비 기간을 마무리하느라 자원봉사자들은 정신이 없습니다. 정말 즐겁고 유익한 행사를 만들기 위해서 오늘도 자원봉사자들은 동분서주하고 있습니다. 밥상 잘 차려놓겠습니다. 여러분은 오셔서 맛있게 드시기 바랍니다. SW Testing Camp 아직도 망설이고 계시다면 망설이지 마시고 가벼운 마음으로 놀러오시기 바랍니다. 지금 여기 를 눌러 얼릉 신청하세요.

세간에 떠도는 자조섞인 말 중에 가장 많이 회자되는 말 중 '1등만 기억하는 더러운 세상' 이란 말이 있다. 최초, 최고, 1등.. 우리가 기억하는 사건, 사고, 인물 중 많은 부분에는 저런 수식어가 붙어 있다. 신문과 같은 언론에도 무슨 사건만 터졌다 하면 1등, 최초, 최고라는 수식어가 꼭 따라붙는다. 그런데 이런 현상이 소프트웨어 개발에도 마찬가지인것 같다. 일반적으로 소프트웨어 개발은 요구사항 수집, 설계, 구현, 테스트와 같은 단계를 거친다고 알려져 있다.(실제 그런 경우는 그리 많지 않다고 본다.) 어쨌든, 순서상 테스트는 맨 마지막이다.. 그렇다.. 맨 마지막이라서 아무도 기억하지 못하나 보다.. 요구분석이나 설계, 구현과 같은 단계는 언제나 사람들의 많은 관심을 받는다. 대학교에서는 4년 내내 가르치기도 한다.(실제로 이번 SW Testing Camp 를 준비하면서 일선 대학의 테스팅에 대한 인식이 얼마나 바닥인지 절실히 느낄 수 있었다.) 그리고 각각의 단계를 지원하는 자동화 도구 역시 차고도 넘친다. 하지만 테스트는 어떤가? 가르치는 대학도 없다.(없지는 않다. 있기는 하지만 독립된 과목으로 가르치지는 않는다. 더구나 4년 내내 테스트만 가르치는 것도 아니다. 최근 국내에서 일부나마 석사과정에 포함되는 소기의 성과도 있었지만.. 아직은 갈길이 먼것만 같다.) 테스트 자동화를 지원하는 도구 역시 많지만 그다지 관심들이 없다. 물론 잘 사용되지도 않는다. 실제적으로 정적 테스팅 지원 도구(테스트 커버리지 분석기와 같은) 등은 단위 테스트를 수행함에 있어 필수 도구인 것은 사실이다.(하지만 여전히 많은 조직에서는 사용조차 하지 않는다.) 왜 이런 필수적인 도구조차 관심을 받지 못하고 사용되지 않는 것일까? 확실한건 테스트가 다른 개발 단계에 비해 확실히 관심을 덜 받고 있다는 것이다. 많은 사람들이 테스팅의 중요성에 대해 심각하게 고민하지 않는다. 그리고 테스팅을 수행하고 결함을 수정하는 작업은 힘들고 지루하다는 것도 이유가 아닐까?

테스터 여러분. 이 세상에서 제일 발견하기 힘든 결함은 무엇이라고 생각하십니까? 그 전에 과연 결함이란 무엇일까요? 요즘은 이슈라는 단어를 더 많이 사용하기도 하는데... 솔직히 저희가 힘들이고 고생해서 잡은 결함도 기획팀에서 '기획 의도이다.' 라고 하거나 개발팀에서 '수정할 필요가 없다.'  는 한마디로 무시당하는 경우도 많습니다. 결함이라는 것에 대해 서로 인식하고 있는 바가 틀리기 때문입니다. 과연 결함은 무엇이고 이 세상에서 제일 발견하기 힘든 결함은 과연 무엇일까요? 아래 그림을 보시면 요구사항과 구현한 제품이 100% 일치하는 아주 아름다운 경우입니다. 이런 경우에는 요구사항에 따라 작동하지 않는 것은 모두 결함이라고 생각할 수 있습니다. 하지만 많은 경우 실제 제품과 요구사항은 정도의 차이는 있지만 대략 아래와 같다고 생각해 볼 수 있습니다. 위와 같은 경우에 색칠이 된 영역은 결함일까요? 결함이 아닐까요? 요구사항에 정의되어 있지 않지만 구현이 되어 있는 부분(특히 정상적으로 작동하는 부분)은 과연 결함일까요? 결함이 아닐까요? 조금 더 극단적으로 생각해서 아래와 같은 경우를 생각해 봅시다. 테스트해야 될 대상이 요구사항에 따라 구현된 부분이 단 한군데도 없이 정말 쌩뚱맞은 제품이 나온 경우 과연 이 제품 전체를 결함으로 생각해야 하는 것일까요? 아니면 구현된 제품 중 정상적으로 구동이 되지 않는 부분만을 결함으로 생각해야 하는 것일까요? 하지만 위의 경우에서 생각해 볼 수 있는 결함들보다 더 찾기 어려운 결함이 있다면 믿으시겠습니까? 믿으십시오.. 있습니다. 바로 요구사항이 아예 누락되어 버린 결함입니다. 즉, 요구사항으로 정의되어서 구현되어야 할 부분이 아예 요구사항으로 정의조차 되지 못한 경우입니다. 누락된 요구사항이 가장 발견하기 어려운 결함인 이유는 우리가 결함을 찾기 위해 테스트 케이스를 설계하는 절차 자체의 시작점이 요구사항으로부터 출발하기 때문입니다. 기본적인 테스트 활동이 요구사항으로 기준을 삼고 그

테스팅 프로젝트의 추정은 누가 하고 계신가요? 테스팅 팀장님이 하시나요? 음.. 그런곳도 있을 것 같습니다. 하지만 전 아직 들어보지 못했습니다. 제가 겪어 보고 일반적으로 들어서 알고 있는 테스팅 프로젝트의 일정은 아래와 같은 상황입니다. 몇몇의 경영자와 기획자 그리고 마케터들이 모여서 제품 출시일을 논합니다. 물론 개발자 분들도 있습니다. 잠시 열띤 토론 끝에 마케터 분들이나 경영자의 한마디로 회의가 끝납니다. 이 제품은 6개월 후에 출시합니다. 그 이후로는 전쟁입니다. Gantt 차트나 기타 여러가지 방법으로 척척 아름다운 추정들이 쏟아져 나와서 MS 프로젝트나 엑셀로 멋지게 그려집니다. 그리고 그걸로 끝입니다. 해당 일정은 가끔 기획자나 경영자들이 들여다보면서 이러면 안돼~~ 라는 외마디 비명을 지를때 외에는 다른 사람들은 그다지 관심이 없습니다. 우선 한 2달간 열심히 기획을 하면서 개발이 시작됩니다. 그리고 출시 한달 전까지 죽어라 개발만 합니다. 그리고 출시 한달을 앞두고 어느 정도 모양이 잡힌 실행을 할 수 있을 만한 제품이 테스트 팀으로 넘어옵니다. 하지만 곧바로 테스트를 할 수가 없습니다. 제품이 정상적으로 구동되지 않거나 환경이 제대로 갖춰지지 않은 경우가 많습니다. 개발팀에서 테스트를 요청할 때는 그냥 언제까지 끝내달라고만 말합니다. 야근과 철야로 어떻게든 일정에 맞춰주면 그 뒤로 수정되었다는 소식은 함흥차사입니다. 출시일은 제꺽 제꺽 다가오고 한달 정도 전쟁과 같은 테스트와 수정을 하던 제품은 우선 출시일에 출시가 됩니다. 그리고 나서 또 몇달 간의 전쟁과 같은 수정과 테스팅이 반복이 됩니다. 위 상황에서 누구도 테스트 팀에게 테스트 일정을 물어보지 않습니다. 테스트 팀의 일정은 전체 개발 기간에서 남는 시간동안 진행하는 것이거나 개발팀이나 다른 부서에서 정해준 시간까지인 경우가 제가 듣고 겪어본 일정 추정 방법입니다. 여러분은 어떠신가요? 이게 과연 제대로 된 일정 추정인가요? 추정이라는 것이 현실적이라고 생각하는 사람은 많지 않습니다

난 나름 얼리어답터라고 자부를 한다. 물론 경제적인 이유로 돈이 들어가는 하드웨어나 일부 상용소프트웨어나 게임 같은 것은 건들지는 않는다. 하지만 뉴스그룹이나 블로그 등을 매일 매일 보면서 새로이 소개되는 각종 오픈소스 프로그램이나 프리웨어는 내 컴퓨가 걸레가 되어도 꼭 사용해본다. 하지만 그 수많은 프로그램 중에서 내가 지속적으로 쭈욱 사용하는 프로그램은 많지 않다. 실제로 아이폰과 같은 스마트폰에 수만개의 어플리케이션이 있고 새로 구매한 사람들은 그중에서 많은 수의 어플리케이션을 시도해 보지만 실제적으로 꾸준하게 사용되는 어플리케이션은 몇개 되지 않는다는 것은 이미 잘 알려진 사실이다. 일전에 어떤 한 업체를 방문했을 때 선반 가득 진열되어 있던 생전에 한번 구경해볼까 생각했던 비싼 도구들이 가득 진열되어 있는 것을 본적이 있다. 너무 비싼 가격에 한번도 써보지 못했지만 주변에서 그 도구들의 엄청난 유요성과 효과에 들었던터라 그 도구를 실제로 업무에 적용하느냐고 물어보았을 때 대답은 '아니오' 였다. 너무나 의외의 대답에 참 놀랬던 기억이 있다. 그때는 왜 그러한 도구들을 제대로 사용하지 못하고 그렇게 전시품으로 쓰는 것인지 잘 알지 못했다. 이렇게 구매만 하고 잘 사용되지 않는 버려진 도구들을 가리켜 '쉘프웨어(shelfware)' 라고도 한다. 테스팅은 주로 사람이 하는 작업이 많지만 테스팅에도 분명 자동화 도구들이 있고 그러한 도구 중에는 테스팅의 생산성을 높일 수 있는 도구들이 있다. 품질을 높이는데 도움을 줄 수 있는 도구들도 있다. 하지만 많은 경우 그러한 도구들이 있다는 사실조차 모르는 경우도 있고 사용이 되지 않고 선반에서 먼지만 쌓이는 경우도 있다.(물론, 제대로 잘 사용하고 있는 업체들도 많다.) 왜 그런것일까? 역시나 문제는 학습곡선이다. 도구를 사용해야하는 사람이 문제다. 그리고 그러한 사람을 통제하는 성과지표와 정책 그리고 전략의 문제이다. 새로운 도구나 기술을 도입하는 경우 즉각적인 생산성 향상의 효과는

최근 국내에는 때아닌 Agile 바람이 불고 있다. 사실 몇년 전부터 Agile 개발 방법론은 꾸준히 국내 기업들에 도입이 되고 있었지만 올해에는 IBM, MS, HP 모두 Agile 관련 도구들을 시장에 내놓으면서 그 도입 속도에 기름을 붇고 있다. 거기에다 Agile Testing 이라 하며 테스팅 업계마저 Agile 대오에 뛰어든 형국이다. 많은 사람들이 Agile 을 외치고 있지만 실제로 국내에 얼마나 많은 회사들이(팀이나 조직이 아닌 전사적으로) Agile 을 도입하고 있고 얼마나 제대로 실천하고 있는지에 대한 자료는 오리무중이다. 오히려 어떻게 하면 자신의 조직이나 팀에 Agile 을 도입할 수 있을지, 상사와 동료들을 어떻게 하면 설득할 수 있을지 고민하는 사람이 더 많은 듯하다. Agile은 새롭다. 새로운 방법론이다. 아직까지는.. 하지만 Agile 이나 기타 새로운 자동화 도구들이 실제로 조직에 성공적으로 도입되는 경우는 그다지 많지 않다. 왜 그런것일까? 그것은 우리의 문화 자체가 그렇기 때문이다. 이것은 비단 한국의 문제가 아니라 이 세상 어디든 마찬가지인 문제다. 단도직입적으로 말하면 많은 조직이나 회사들은 학습효과라는 것을 수용하지 못하기 때문에 새로운 도구나 기술이 성공적으로 도입되지 못한다고 할 수 있다. 예를 들면, 자동차 조립 공장에 새로운 용접 로봇이 도입되었다고 했을 때, 용접 로봇은 학습이 필요없다. 이미 필요한 모든 것은 프로그래밍되어 있고 설치와 동시에 생산력을 100% 발휘할 수 있다. 그런데, 이것은 제조업의 현실이지 IT 업계의 현실이 아니다. 그런데 많은 사람들은 사람도 로봇과 같은 것이라는 가정을 너무 쉽게 한다. IT 업계는 사람을 기본으로 하는 산업이고 사람은 로봇과 다르다. 사람은 학습이라는 것이 필요하다. 사람의 생산력이 일정 한계에 도달하기까지는 각 개개인의 능력에 따른 학습곡선이 필요하다. 어느 한 테스트 조직에서 테스트 커버리지 분석기를 단위테스트에 도입하였다면 해당 도구를 배우는데 비용이 든다.

얼마전 구글에서 일방적인 공지가 하나 올라왔다. 블로거닷컴에 텍스트큐브가 흡수된다는 공지였다. 블로거닷컴과 텍스트큐브는 분명 블로깅 서비스로 같은 서비스 같지만 그 철학적인 배경은 상당히 다르다. 단적인 예로 블로거닷컴에는 트랙백 기능이 없다. 카테고리 기능도 없다. 서로 다른 철학적 배경에서 출발한 두 서비스가 어떻게 합쳐질 수 있는 것일까? 텍스트큐브가 사라진다는 그 공지를 보고 일순간 정말 심각한 정신적 공황 상태에 빠져버렸다. 블로거를 포함해 언론을 장악하여 심각한 자기 검열의 악순환을 통한 표현의 자유를 탄압하는 우리 나라의 서비스를 이용하고 싶지는 않아 미칠듯이 외국의 블로그 서비스를 뒤졌다. 그렇게 며칠이 지난 지금은 그냥 초연해져 버렸다. 그러면서 든 생각은 두가지 정도다. 하나는 내 블로그가 과연 유료 호스팅 서비스를 통해 설치형 블로그로 운영할 만큼 시간과 노력을 들여야 할 만큼 가치 있는가라는 생각이다. 다른 하나는 기업과 서비스의 영속성이다. 그냥 내 생애 동안만이라도 내가 마음 놓고 이용할 수 있는 서비스가 과연 존재할것인가에 대한 생각이 들었다. 한때 유행했던 '아이러브스쿨', '네이트온', '싸이월드' 모두 난 지금은 사용하지 않는다. 사용하지는 않지만 그 서비스들에는 내 한시절의 추억들이 차곡 차곡 쌓여있다. 그런데 그런 서비스가 어느 한순간 폐쇄되어 버린다면 어떻게 되는 것일까? 얼마전까지 애용하던 t2b 서비스가 별다른 공지도 없이 서비스가 중지되어 버렸다. 덕분에 난 트위터에 있는 내 기억들을 더 이상 보존할 방법을 생각하지 못하고 있다. 어쨌든 난 이미 '네띠앙' 만행을 통해 수년간 모아두었던 내 추억을 송두리째 날려버린 경험이 있다. 하지만 이미 기억도 못할 정도의 아련한 기억들의 창고였던 '네띠앙'보다 현재 진행형인 '텍스트큐브'의 폐쇄는 정말 정신적 충격이 엄청나다. 과연 구글은 이러한 사용자의 경험에 대해 약간의 고민이라도 했던 것일

소프트웨어를 개발하기 위해서는 수많은 이해관계자가 협업을 하게 되어 있다. 대표적으로 개발자, 기획자, 디자이너, 테스터, 사용자 등을 들 수 있다. 그중에서 누가 누가 더 중요한가에 대해 얘기를 나누다 보면 결국에 테스터는 있어도 그만 없어도 그만이라는 식이 된다. 왜 테스터는 그런 대우를 받는 것일까? 이런 저런 이유가 많겠지만 가장 간단한 것은 역시나 성과가 눈에 보이는가에 따른 것이 아닐까? '우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해'라는 책에 보면 '단단한 것이 부드러운 것을 몰아낸다' 라는 옛 말을 소개하고 있다. 짧은 말이지만 아주 간단하게 우리의 인식의 범위를 설명하는 문구가 아닐 수 없다. 우리는 눈에 보이는 것, 측정 가능한 것만을 우선시 하는 경향이 강하다. 개발자는 개발 산출물 자체를 우리는 눈으로 학인할 수 있다. 디자이너의 화려한 그래픽 효과도 확인이 가능하다. 구현된 시스템은 기획자의 몫이 된다. 하지만 테스터는 어떨까? 테스터가 열심히 테스트를 해서 소프트웨어에 잠재되어 있던 1000개의 결함 중 출시 전에 800개를 해결했다. 하지만 그래도 아직 200개의 결함이 남아있다. 결함이 줄어든 것은 실제로 확인하기 어렵다. 확인 가능한 것은 어쨌든 아직까지 결함이 존재한다는 것이다. 품질은 측정하기 어렵다. 하지만 예산과 일정은 측정하기 상대적으로 쉽고 인식하기도 쉽다. 측정 가능한 것은 측정하기 어려운 것에 대한 관심을 사라지게 하는 효과가 있다. 그렇다면 우리가 테스팅에 대한 관심을 높이기 위해서는 어떻게 해야만 하는 것일까?

SW Testing Camp 가 5월 29일 삼성역 한국마이크로소프트에서 열립니다. 자세한 내용은 http://testingcamp.tistory.com/ 에서 확인하실 수 있습니다. 참가비는 만원으로 입금순으로 선착순 마갑됩니다. 지금 신청하세요. Loading...

SW Testing Camp 는 이제 장소가 정해지고 그 준비에 박차를 가하고 있습니다. 참여하시는 분들을 위한 점심 준비도 끝났고, 참가자 모집도 다음주 월요일부터 시작됩니다. SW Testing Camp 에 많은 관심을 부탁드립니다.

작년 10월 쯤이었다. 난 한창 트위터의 재미에 푹 빠져들어가고 있는 시점이었고.. 이제 막 한 아이의 아빠로서 어리버리하던 시절이었다. 그때 트위터에서 육아에 관련된 글을 모집하는 트윗을 아주 우연하게 보게 되었고, 그것이 인연이 되어 짧은 지식이나마 글을 쓰게 되었다. 정확히 내가 어떤 이유로 어떤 맘으로 이 작업에 참여하게 되었는지 모르겠지만 이렇게 나의 경험과 다른 사람의 경험이 오롯이 담긴 책한권이 나왔다는 것이 너무 가슴에 벅차다. 내 기록이 맞다면 이 작업은 맨 처음 2009년 10월 11일 트위터의 @1seren 님의 블로그 에서 시작되었다. 그리고 내가 트위터에서 관련 트윗을 접한 것이 2009년 10월 14일이었다. 2009년 10월 21일  나눔 육아 일정이 확정되고 내 원고는 2009년 10월 22일 최초로 발송되었다. 그리고 거의 반년이 흐르고 흘러서 드디어 책 한권이 오롯이 나오게 되었다. 책 판매로 의한 수익은 전액 기부금으로 기부되기 때문에 기부 한다는 마음으로 한권씩 구매하셔도 좋을 것 같다. 이 책은 @ 1serene , @ murianwind , @ acoralreef , @ openLEE ,  @ minang79 , @ ds1dbx , @ gemfactory , @ sehaya , @ jhrhee , @ awakers , @ iloview , @ kimjini , @ hanDoctor 님 등 모두 트위터로 만난 사람들이 참여하여서 만들었다. 책에는 아래와 같은 내용들이 담겨 있습니다. 1. 여는 글: ‘나눔 육아’를 쓰기까지 2. 부모 되는 마음가짐 출산 전- 아빠의 역할1(@murianwind) 출산 후- 아빠의 역할2(@acoralreef) 엄마 되는 마음가짐(@1serene) 직 장맘 육아기(@openLEE) 3. 영아기의 육아법 모유수유 가이드(@minang79) 아빠의 분유수유 성공기(@ds1dbx) 아기 재우는 법(@1serene) 이유식 제대로 하기(@gemfactory) 임신과 수유기의 영양소보충(@g