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

국내에 ISTQB가 보급되고 최근 몇년동안 국내 테스트 업계에 종사하는 많은 사람들은 테스터가 전문직이라는 의견에 별다른 이견이 없을 것이라고 생각됩니다. 우리는 테스트는 아무나 하는 것이 아닌 전문적인 훈련을 받은 사람들이 하는 것이라는 것에 인식을 같이 하고 있습니다. 그런데 정말 그런것일...

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

얼마전 테스터의 커리어 패스에 대한 얘기를 나누게 되었다. 테스터의 커리어 패스에 대해서 이야기를 하게 되면 참 암담한 느낌이 드는 건 해가 바뀌어도 바뀌지 않는 것 같다. 솔직히 커리어 패스라는 것은 학계와 산업 전반에 걸친 인식의 변화와 지원이 뒷받침되어야 하는 것이기 때문에 더 그런것 같다. 실제로 내 주변에서도 반복되는 업무와 진로에 대한 고민을 하다가 다른 직군으로 진로를 바꾼 사람들도 많다. 테스터는 어떤 직업일까? 사람들이 생각하는 것처럼 보람도 없고, 반복되는 지겨운 작업과 정해진 진로도 없는 그런 암담하기만 직업일까? 꼭 그런것이 아닌 것은 실제로 주변에는 테스터로서의 자부심과 열정으로 오랜 기간동안 종사한 분들도 많기 때문이다. 테스터라는 직업에 대해 암담하게 생각하는 사람들은 대체로 아래와 같은 이야기를 한다. 1. 테스트는 아무나 하는 단순 작업이다. 2. 테스트는 개발 이후의 결과물의 정상 작동만을 확인하는 작업이다. 그런데 위와 같은 이야기는 사실일까? 테스터는 어떤 일을 하고 어떻게 일을 해야하는 것일까? 그에 대해 곰곰히 생각해 보니 테스터와 해커는 어떤 면에서 참 많은 부분을 닯았다는 생각이 들었다. 테스터와 해커는 1. 기존의 제품을 재구성한다. 2. 기존의 제품의 취약점을 집중 공략한다. 는 점에서는 비슷한 면이 있다. 하지만 그 접근 방법에서는 약간의 차이를 느낄 수 있다. 해커는 기존의 제품을 재구성하고 취약점을 공략하기 위해서 끊임없이 새로운 방법을 찾아낸다. 새로운 방법을 시도하고 또 시도하는 접근 방법을 취한다면 테스터들은 여러 이유로 정해진 방법만을 되풀이 하는 경우가 많다. 어떤 조직에서는 누가 만들었는지도 모르는 테스트케이스(라고 쓰고 체크리스트라고 읽는다.)만을 매번 반복하는가 하면 어떤 조직에서는 매번 테스터의 직관에만 의존하기도 한다. 제품에 대해 차분하고 체계적으로 접근하고 분석하고 재구성하여 끊임없이 새로운 것을 고민하는 경우가 그다지 많지 않다. 그리고 그러한 새로운 시도가 적은 조직에 속한 테스터일수...

여러분은 선입견이 무엇인지 이미 알고 계실겁니다. 어떤 사람들은 자신은 선입견 따위는 없다고 말씀하실것이고, 실제로도 선입견이 다른 사람보다 적은 사람들도 있긴 하지만 대부분의 사람들은 꽤 많은 선입견을 가지고 있습니다. 선입견은 당사자의 성장 환경, 학습, 경험 등이 복합적으로 작용하여 마음 속 깊이 뿌리 깊게 자리 잡은 감정이기 때문에 대부분의 사람들은 어떤 결정을 내리고 선택을 할 때 자신의 선입견이 개입되어 있다는 것을 쉽게 알아차리기 힘듭니다. 사람이 어떤 결정을 하고 선택을 하는 과정은 크게 두가지로 나뉘는데.. 하나는 숙고 체계라는 방식으로 말 그대로 생각하고 생각하고 또 생각해서 결정하는 것이고, 다른 하나는 반사 체계로 그냥 무의식적으로 순간적으로 결정하는 방식을 말합니다. 선입견은 반사 체계에 속하는 것으로 우리의 결정에 무의식적으로 또한 신속하고 강력하게 영향을 미칩니다. 이러한 선입견을 알아보는 재미난 심리 테스트가 있습니다. 일명 '암묵적 연상 테스트(Implicit Association Test, IAT)' 불리는 테스트입니다. IAT는 http://www.implicit.harvard.edu 에서 몇가지 시범 검사를 해볼 수 있습니다. 한글도 지원하기 때문에 관심 있는 분들은 한번 해보시는 것도 좋을 것 같습니다. 저는 인종에 관한 검사를 진행한 결과로 당신의 데이터가 제시하는 것: 흑인에 비해 백인에게 자동적 선호 다소 있음  당신의 검사 결과 해석은 '백인에게 자동적 선호있음' 입니다. 왜냐하면 당신이 백인 얼굴과 좋은 단어들을 동일한 자판 키로 반응할 때 흑인 얼굴과 좋은 단어들을 동일한 자판 키로 반응할 때에 비해 더 빨리 반응하셨기 때문입니다. 위와 같이 나왔습니다. 어떤 분들은 IAT의 결과에 동의하지 못하실 수도 있으실 겁니다. 그리고 솔직히 말하면 IAT는 사람의 선입견을 측정하는 검사는 아닙니다. 하지만 위 검사를 통해서 우리가 자신에 대해 판단하고 있던 것과 전혀 다른 결과를 얻을 수도...

전 사범대학교 출신입니다. 2급 정교사 자격증도 있고, 학원 강사나 기간제 교사 경험도 있습니다. 그리고 지금도 남을 가르치는 업종에 종사하고 있습니다. 개인적으로 저는 사립 사범대와 사범대가 아닌 다른 방법으로 선생님을 임용하는 것에 대해 반대하는 입장입니다. 교육은 국가의 백년지대계이고, 그 교육을 짊어질 교사는 국가가 직접 교육하고 관리해야 한다고 생각하는 사람입니다. 무슨 얘기를 하고 싶은걸까요? 여러분 중에는 누군가를 가르쳐본 사람이 있으실 것이라고 생각합니다. 어느 강연장과 같은 곳에서 여러 사람을 가르치는 것이 아니더라도 한창 자라고 있는 귀여운 자식에게 말을 가르친다던지 아니면 팀안의 신입사원에게 회사 생활에 필요한 여러 가지를 가르치는 경우 등 주변에서 우리는 흔하게 내가 알고 있는 지식을 다른 사람에게 전달하고 또한 배우면서 지내고 있습니다. 그런데, 다른 사람에게 내가 알고 있는 지식을 전달할 때 먼가 설명하기 어려운 답답함을 겪어보신적이 있으신지요? 내가 알고 있는 것, 당연하다고 생각하는 것을 상대방이 왜 모르는지에 대하여 이해하기 어려웠던 감정을 느껴보신적이 있으신지요? 한번이라도 그러한 감정을 겪어보신 분이라면 바로 그 감정이 '지식의 저주'입니다. 저도 그러한 감정을 자주 느끼는 편이고, 많은 경우 인내를 잘 하지 못하는 편입니다. 이 '지식의 저주'를 다른 사람에게 설명할 때 좋은 예로 텔레비젼의 오락 프로그램에서 항상 빠지지 않는 게임 중 하나가 특정 단어에 대해 설명을 하거나 몸짓 등을 통하여 상대방이 그 단어를 맞추도록 하는 게임이 있습니다. '지식의 저주'라는 것을 가장 빠르게 느껴보고 싶으시다면 위와 같은 유사한 게임을 주변 사람들과 해보시기 바랍니다. 한 사람은 설명하는 사람이 되고, 한 사람은 듣는 사람이 됩니다. 설명하는 사람은 자신이 설명하고자 하는 단어, 즉 정답을 보는 그 순간 그 정보는 아주 당연한 정보가 됩니다. 이 때, 설명하는 사람에게 상대방이 정답을 맞출 확률...

최근 뉴스에서 가장 큰 화두는 신종 플루이다. 항간에는 음모론까지 나돌 정도이다. 여기저기서 쏟아지는 정보에 정신이 없다. 무엇이 진실인지 거짓인지도 명확하지 않다. 인간의 공포는 무지에서 온다. 진실을 판단할 기준이 명확하지 않다 보니 혼란만 가중되는 것 같다. 강도의 차이는 있지만 영락없는 광우병 사태와 다름이 없다. 솔직히 나로서도 무엇이 진실인지 명확하게 판단하기가 쉽지 않다. 그런데 왜 이러한 혼란이 야기되는지에 대해서는 일부 추측해 볼 수 있다. 한가지 예로 현재까지의 신종플루의 사망율은 과연 얼마나 되는 것일까? 정확한 자료가 없기 때문에 딱 잘라 말할 순 없지만 공식적인 발표에서는 0.03%였다. 0.03%라 하면 1만명이 감염되어 3명이 숨졌다는 얘기이다. 반면에 대한결핵협회에 따르면 2008년 결핵에 의한 사망율은 인구 10만명당 4.7% 즉, 인구 1만명당 470명이라고 발표했다. 단순히 사망율만 놓고 비교해 본다면 신종플루는 결핵에 비하면 병도 아니다. 신종플루에 쏟아지는 관심과 비용등은 당연히 결핵과 같은 병에 쏟아지는 것이 더 옳다. 머 신종플루는 전염성이 강하다고 말씀하시는 분도 있으실텐데.. 결핵도 전염성이라면 만만치 않다. 그렇다면 왜 이런일이 생기는 것일까? 심리학자들은 이것을 '틀 짜기(framing)'라고 부른다. 잘 생각해보자. 사망율 몇%라는 방송과 금일까지 몇명이 죽었다는 방송 사이에서 여러분은 어떤 방송이 더 위험한 내용으로 인식되는가? 즉, 우리는 동일한 내용이라도 판단의 기준을 바꾸면 전혀 다른 내용으로 인식하게 된다는 것이다. 특히 이것이 어떤 것과 비교를 하게 되는 닻 내림 효과와 마주지면 그 효과는 더욱 상승하게 된다. 인구 1만명당 3명이 죽는 신종플루라고 표현한다면 인구 1만명이 일종의 기준점이 되고 사람은 그에 맞추어 판단하게 된다. 이러한 기준이라면 사람들은 신종플루가 그다지 위험한 질병이라고 판단하지 않게 될 것이다. 반면에 금일도 신종플루로 인하여 사망자가 발생하였으며 해당 환자는 신...

어제 ISO/IEC 29119 테스팅 국제 표준을 제정중인 WG 26의 의장인 Stuart Reid 초청 강연이 있었습니다. 강연 주제는 Agile Testing 이었는데.. 근래에 들었던 강연 중에 가장 맘에 드는 강연 중 하나였습니다. 여러 내용이 있었는데, 그 중 하나 맘에 걸리는 것은 Agile 조직에서의 테스터는 개발 관련 지식을 반드시 알아야 한다는 것이었습니다. 혹시나 해서 여러번 비슷한 질문을 해봤었는데, 역시나 어떤 형태로든 개발 관련 지식을 아주 풍부하게 알고 있어야 한다는 의견이었습니다. 예전 우리 나라가 월드컵 4강 진출을 위업을 달성했을 때 우리 나라 대표팀을 이끌던 히딩크 감독이 원하던 선수는 멀티 플레이어였던 것처럼 최근 개발 프로세스가 Agile로 급속하게 이행하면서(외국 기준으로.. 좀 논란은 있지만..) 기존의 테스터의 입지가 좁아지고 개발자와 테스터의 Role이 불분명해지면서 테스터의 자격 요건으로 개발 관련 지식을 요구하는 경우가 매우 크게 늘어나고 있습니다. 우리가 잘 아는 MS와 구글은 테스트 엔지니어를 구인할 때, 자동화 도구 설계와 개발 관련 경력이 없을 경우 직원을 채용하지 않을 정도입다. 테스트 하나 잘하는 것도 힘겨운 마당에 개발까지 잘해야 한다는 건 거의 완전한 고문 수준인 것 같습니다. 하지만 주변의 의견들은 이미 테스터가 개발 관련 지식을 알고 있어야 한다는 것이 주류가 되어 가는 것 같습니다. 하지만 개인적으로 테스터가 개발 관련 지식을 습득을 할 수는 있겠지만 과연 이 두가지를 모두 잘 할 수 있을지는 의문이 든다. 개인적으로는 개발 관련 지식도 중요하지만 아키텍처 관련 지식을 습득하는 것이 테스트를 수행하는 것에 더 큰 도움이 된다고 생각하는 입장이다. 이렇게 주변에서는 테스터의 자격 요건에 대해 분분한 의견이 있는데요.. 아래 소개해 드리는 것은 스튜어트가 제안한 모델로 기존에 업무 능력이나 직업 능력을 측정하는 많은 모델이 있지만 직관적으로 이해하는 면에서는 이 모델이 아주 유용한 것 같습니다. 이...

사람들이 테스터에 대해 가장 많이 하고 있는 오해 몇가지가 있다. 대표적으로 1. 테스트는 아무나 할 수 있다. 2. 테스트는 개발자도 할 수있다.(사실 제품에 대해서는 개발자가 훨씬 더 잘 알기 때문에 개발자가 테스트를 해도 충분하다.) 이번에는 위와 같은 오해가 왜 잘못된 것인지 얘기해 보고자 한다. 일반적으로 개발자와 얘기해 보면 1. 코드를 자기 것으로 이해한다.(자기가 코드를 작성했으므로 자기 것으로 생각한다.) 2. 코딩을 거의 예술의 경지로 이해한다. 이런 경향은 게임 쪽에서 더 두드러지게 느낄 수 있다. 쉬운 말로 개발자는 자기 자신을 작곡가, 미술가, 음악가 등과 거의 동급으로 여긴다. 자기 자신의 작업에 무한한 창의력과 무한한 노력이 들어가는 예술의 경지 쯤으로 여긴다. 하지만 실제로 코드는 개발자 소유가 아니다. 예술 작품은 다분히 개인적인 작업이다. 그런 의미에서 나는 영화도 예술 작품의 범주로 이해하지는 않는다. 머 예술 영화도 있긴 하지만.. 어쨌든.. 무슨 말이냐 하면 작품에 대한 비평을 수용하지 않아도 되고 작품에 대하여 작가는 거의 무한한 권리를 가진다. 하지만 소프트웨어의 코드는 여러명의 개발자과 관련되어 있다. 때문에 공동의 규칙이 필요하고 호환을 위한 많은 부분을 고민을 해야 한다. 코드는 자기 자신의 의지로 만든다기 보다는 다른 사람을 배려하고 만들어야만 한다. 하지만 실상은 그렇지 못하고 주변의 많은 사람들도 코딩을 개발자 고유의 영역인 개발자 개인의 소유로 암묵적으로 인정하는 분위기이다. 이런 분위기가 바뀌지 않는 한 개발자는 절대 테스트를 수행할 수 없다. 이유인즉 인지 부조화를 생각해 볼 수 있다. 어려운 말 나오셨다.. 인지 부조화 위키피디아에는 다음과 같이 적혀 있다. 인지부조화 - 위키백과, 우리 모두의 백과사전 ko.wikipedia.org 위키백과 ― 우리 모두의 백과사전. 이동: 둘러보기, 찾기. 인지부조화 (認知不調和)는 1950년대 심리학자 레온 페스팅거가 주장한 이론이다. ... 자세히 알아보도...

트위터에서 @onsooyoung 님이 QA가 무엇을 말하는지.. 그리고 결론적으로 테스터와 QA의 큰 차이가 무엇인지에 대해 물어보셨다.. 내가 이전에 썼던 글이 그다지 친철하지 못했던 것 같아 반성해 본다.. 혹시나 했지만 역시나 글을 쓴다는 건 무척 어려운것 같다. 특히 나에게는 당연한 것을 다른 사람에게 전달할 때는 더 어려운 것 같다. 먼저 QA에 대해서 잠깐 말해보도록 하겠습니다. QA 는 Quality Assuranced의 약자를 말합니다. 우리 나라 말로 하자면 품질 보증이라고 할 수 있습니다. QA는 QM(Quality management)의 한 단계입니다. QM은 QC(Quality control), QA, QI(Quality improvement)의 3가지 주요 단계로 구성됩니다. 자세한 것은 위키피디아와 같은 내용을 참조하시고, 여기서는 간략하게 결론부터 말하자면.. 테스트는 QC에 훨씬 가깝습니다. 품질 공학에서 말하는 곳마다 조금씩 틀리지만 제품의 품질을 관리하는 것은 3단계를 걸칩니다. 먼저 품질 매트릭을 정의하고 측정하고 수집하고 통계를 내는 QC 단계를 거칩니다. QC 단계를 지나면 수집된 데이터를 통해 생산되는 제품에 대해 일정 품질을 보장할 수 있는 QA 단계에 이릅니다. 그리고 그 다음은 그런 품질을 더 나은 품질로 개선하는 QI 단계로 갑니다. 소프트웨어의 품질에 대해서는 ISO/IEC 25000 표준(ISO/IEC 9126의 최신 버전)을 참고하시면 됩니다. ISO/IEC 25000을 참고한다면 QA가 하는 일이라 하면 기능성 뿐만 아니라, 이식성, 유지 보수성, 보안성, 상호운용성, 사용성 등 품질에 대한 매트릭이 측정 가능해야 하며 그런 측정 활동을 통해 제품에 일정 수준의 품질을 보장할 수 있어야 합니다. 하지만 국내에서 QA 조직을 보면 대부분의 경우 기능성, 성능, 보안성 등 특정 영역에 치중되어 있고, 측정하는 부분도 제대로 된 매트릭을 수집해서 측정하고 보장할 정도의 수준에 도달한 곳도 손에 꼽을 정도입니다. ...

여러분은 회사에서 조직에서 테스터를 어떻게 부르고 계신가요? 테스터라고 부르고 있는 곳이 있나요? 테스트 조직을 정말로 테스트 조직으로 부르고 있는 곳이 있나요? 제 경험상으로 분명 그렇게 부르는 곳도 있지만, 많은 경우 테스트 조직을 QA로 부릅니다. 최근에는 TE(Test E ngineering )라고 부르는 곳도 있더군요. 그럼 왜 많은 곳에서 테스트 조직을 QA라고 부를까요? 여러 이유가 있겠지만 가장 많은 대답은 속된말로 뽀대가 안난다였습니다. 테스터 조차 자기 자신이 테스터라고 부르는 것에 대해 심각할 정도로 자괴감을 느끼는 경우가 많았습니다. 테스터라고 자기를 소개하면 단순 노가다나 하는 무식한 사람을 비춰지기 때문에 QA라고 부른다는 것이었습니다. 과연 이것은 사실일까요? 이런 편견의 기저에는 테스트는 아무나 할 수 있다. 테스트는 전문직이 아니다. 라는 잘못된 생각이 깔려 있습니다. 그렇게 때문에 최대한 자기를 포장하게 된 것으로 보입니다. 하지만 테스트와 QA는 전혀 다른 업무를 하는 사람들이고 테스트는 아무나 하는 그런 쉬운 노가다 작업이 아니라는 것입니다. 관련해서 두 가지 정도만 말해볼까 합니다. 우선은 테스트는 여러분이 흔히 생각하는 완성된 제품의 기능의 정상 동작이나 확인하는 그런 단순 노무직은 아닙니다. 분명 테스팅 활동 중 가장 많은 부분을 찾지하는 것 처럼 일견 보이는 건 사실입니다. 하지만 최근에 테스팅 활동은 개발 전반에 걸쳐 확대되고 있으며, 많은 곳에서 테스터들에게 그런 능력을 요구하고 있습니다. 대표적으로 보면, 요구사항 분석 및 리뷰, 기술 명세서 리뷰, 테스트 설계, 자동화 도구 개발, 테스트 자동화 구축, 테스트 스크립트 설계, 리스크 분석 등등 정말 많은 작업이 테스팅 활동에 포함되고 있습니다. 외국에서는 관련 직종만 30여가지가 넘는 타이틀로 세분화되어 전문직으로 대우받는 것이 사실입니다. 우리 나라는 최근에서야 테스트 리드라는 타이틀이 더 추가되어 조금씩 테스트 활동에 대한 인식이 개선되어 가고 있는 실정입니...