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

김기창 교수님의 '한국 웹의 불편한 진실'을 읽으면서 매번 하던 생각을 글로 올려보고자 한다. 누누히 얘기했던 말이지만 많은 사람들은 테스팅을 개발이 끝난 후에 기능 확인이나 하는 활동쯤으로 생각하는 경우가 많다. 테스팅을 이렇게 생각할 경우 테스팅 활동은 매우 제약적이 될 수밖에 없다. 테스팅을 하기 위해서는 테스트 케이스를 만들어야 하고 테스트 케이스에 꼭 포함되어야 할 항목 중에는 기대 결과와 실제 결과가 있다. 이 두 결과가 차이가 생긴다면 우리는 그것을 결함이라고 한다. 여기서 기대 결과의 기준이 되는 것을 테스트 오라클이라고 하는데.. 일반적으로 많이 사용되는 테스트 오라클은 기술명세서 계열의 문서들이다. 그런데 테스터가 무조건 YES!!! 만을 외치는 예스맨이 된다면 기술 명세서 계열의 모든 항목들은 진리가 된다. 거기에는 어떠한 의심도 개입할 여지가 없어져 버린다. 하지만 과연 그럴까? 그러한 명세서들이 항상 참일수 있을까? 명세서도 사람이 작성한다. 그리고 그러한 명세서에 담긴 내용들은 고객의 요구사항이다. 하지만 진짜로 고객의 요구사항을 수렴해서 작성된 명세서가 몇이나 될까? 아니면 고객의 요구사항이 반영된 명세서가 있다 할지라도 그것이 정말 고객이 원하던 것이라고 누가 말할 수 있을까? 고객의 요구사항을 수집/분석하고 문서로 만드는 과정 중에 사람이 실수할 여지는 얼마든지 충분할 만큼 넘쳐난다. 자신의 생각조차 글로 옮기는 것이 힘든 법인데.. 하물며 다른 사람의 생각을 글로 옮긴다면 그 과정에 잘못 전달되는 것들은 얼마나 될지 아무도 알 수 없다. 그래서 테스터는 이 모든 것을 의심하고 문제를 제기할 수 있어야만 한다. 그리고 이것이 테스터가 개발 초기부터 참여해야 하는 이유이고, 테스터의 존재 이유이다. 모두가 당연하다고 생각하고 모두가 참이라고 하는 것도 테스터라면 한번 더 의심하고 한번 더 생각해 볼수 있어야 한다. 그리고 그 기준은 항상 사용자 즉, 고객이 되어야 한다. 하지만 이런 의심이 너무 깊어져서 직업병 수준이...

테스팅은 개발 기간 중 언제부터 시작될까요? 테스팅에 대해 조금 공부를 하신 분들은 아마 대부분 정답을 알고 계실것이고, 또 그런 것이 우리 나라 현실에서는 아직 머나먼 일이라는 것도 아실 겁니다. 대부분의 경우 테스팅이라 하면 많은 사람들이 제품이 완성 된 후 기능의 정상 유무를 확인하는 활동 쯤으로 생각합니다. 그렇기 때문에 테스팅은 개발이 거의 끝나갈 무렵 시작하게 되고 그러다 보니 테스팅을 통해 결함이 많이 나올 경우 출시가 연기되거나 결함이 많은 제품이 그대로 고객에게 전달되는 악순환이 반복됩니다. 그런데 정말로 테스팅이 단순히 개발 결과물이나 확인하고 개발 말미에 어쩔 수 없이 하는 활동이고 시간 없으면 안해도 되는 걸까요? 그렇다면 제가 이런 글도 안적고 있겠죠. 테스팅이 언제 시작하는 활동인지를 알기 위해서는 우선 결함이 무엇이고 테스팅의 목적이 무엇인지 알 필요가 있습니다. 우선 결함이란 무엇일까요? 먼저 Error에 대해 알아봅시다. 우리가 흔히 에러라고 부르는 것은 흔히 사람이 하는 실수를 말합니다. 여기서 사람이라 하면 개발자를 포함하여 개발 과정 전체에 관련된 모든 사람들을 말합니다. 실수를 하지 않는 사람은 없습니다. 개발 과정 전체에 걸쳐 수많은 사람들이 관련이 되고 그 모든 사람들은 알게 모르게 실수를 합니다. 그러한 실수를 모두 에러라고 합니다. 결함(Defect)이란 이러한 에러가 확인할 수 있는 현상으로 나타난 것을 말합니다. 이러한 작업을 테스터들이 하게 되죠. 테스터는 결함을 찾는 사람이고 결함이란 에러에 의해 발생하기 때문에 테스터를 다른 말로 하면 개발 과정에서 사람들이 하는 실수를 발견해 내는 사람이라고 할 수 있습니다. 하지만 모든 에러가 결함이 되는 것은 아닙니다. 그렇기 때문에 테스터는 보다 많은 에러를 찾을 수 있도록 많이 공부하고 연습할 필요가 있습니다. 그렇지 않으면 테스터가 찾지 못한 결함을 고객이 찾게 되겠죠. 자 여기까지를 이해하셨다면 테스팅을 언제부터 시작해야는지 감이 오셨을 거라고 생각합니다. 그렇...

피쳐 크리프라는 말이 있다. 자세한 것은 위키피디아에게 물어보라. Feature creep - Wikipedia, the free encyclopedia en.wikipedia.org Feature creep is the proliferation of features in a product such as computer software. Extra features go beyond the basic function of the product and so can ... 구글신에게 물어봐도 무슨 예기인지 아주 친절하게 알려주는 수많은 웹페이지를 볼 수 있다. 그만큼 아주 유명한 단어 중 하나이다. 결론적으로 말하면 피쳐 크리프란 개발 중 이런 저런 이유로 원래 계획과 상관 없이 덕지 덕지 붙게 되는 기능들을 말한다. 이러한 경우를 우리는 주변에서 아주 쉽게 경험할 수 있다. 그리고 그러한 경우 대부분 공통적으로 하는 말이 사용자를 위해서이다. 하지만 정작 개발과정에서 사용자의 의견이 반영되는 경우는 거의 없다. 테스터 뿐만 아니라 개발에 관련된 모든 사람들은 가장 최우선적으로 고려해야할 사람은 사용자이다. 하지만 개발 과정에서 사용자와 접촉할 수 있는 기회는 매우 제한적이다. 그리고 그러한 정보의 공유 역시 매우 제한적인 것이 현실이다. 마케팅 부서 또는 UX 관련 부서에서 진행 된 사용자 조사를 우리는 얼마나 신뢰할 수 있을까? 사용자로부터 데이터를 얻어내는 방법은 무수히 많은 방법들이 있다. 그중에서 이번에는 카노 모델이라는 것에 대해 소개해 보고자 한다. 카노 모델이라 하면 카노 모델 - 위키백과, 우리 모두의 백과사전 ko.wikipedia.org 2009년 3월 31일 ... 카노 모델 은 각종 소비자 조사 방법과 연구를 통해 얻어진 '소비자의 목소리'(Voice of Consumer)를 분석하는 틀로 이용된다. ... 을 참고해 보시기 바란다. 사실 카노 모델은 매우 유명한 모델 중 하나로 구글신에게 물어보시면 매우 많은...

지난 주 토요일 그러니까.. 23일.. 7번째 게임 디자인 워크샵에 갔다 왔다.. 몇번이고 간다 간다 하면서 가보지 못했던 워크샵이었는데, 아내가 산후 조리원에 있을 때라 정말 갈까? 말까? 무수하게도 고민했었다. 거기다 하필이면 이날 XPER의 8월 정기 모임도 있었다. 어쨌든 이런 저런 이유로 참석하기로 마음 먹기가 쉽지 않았지만 큰 맘 먹고 참석한 워크샵은 결론적으로 흡족했다. 우선 2시 30분쯤 이제 너무 자주 가서 익숙해져 버린 마이크로소프트의 라운지에 도착했다. 그전에 보니 포스코 빌딩 중앙 라운지에서 DJ.DOC의 공연 준비가 한창이었다. 나중에 공연장을 가로질러 집으로 가려다가 보안요원의 제지로 살짝 기분이 상했었다. 라운지에 들어서니 내 눈에 떡하니 보이는 것은 바로 소문으로만 듣던 서페이스.. 너무 너무 체험해 보고 싶던거라 열심히 손가락을 움직여 보았는데.. 움.. 생각보다 직관적이지 못하고 반응이 너무 느려서 실제로 제품을 출시해야한다면 좀 더 개선해야할 것 같다. 게임 디자인 워크샵은 우선 나중에라도 참여하고 싶은 분은 우선 MDA 프레임웍에 대해 사전 지식을 어느 정도 가지고 가야할 것 같다. 아무 생각 없이 참여해서는 진행 속도가 너무 빠르고 상세한 설명이 생략되어서 자칫 산만하다고만 느끼고 얻는 것이 아무것도 없을 수 있다. 사실 지금도 MDA에 대해서 확 하니 와닿지 않고 있다. 그냥 개인적으로 게임의 재미를 정의하기 위해 많이 노력했었는데 사고의 지평을 한 뼘 더 늘릴 수 있던 아주 유익했던 시간이었다. 이 워크샵은 그냥 한번 단발로 참여해서는 얻는 것이 별로 없을 것 같다. 좀 더 많이 참여하고 싶지만 그럴 기회가 될 지 모르겠다. 그리고 조금은 아쉬운 것은 게임의 재미라는 것에 대해 좀 더 깊게 토론하고 의견을 나누는 그런 시간이 있었으면 하는 아쉬움이 있다. 아니면 참석한 사람 중 몇몇 유명한 분들의 게임의 재미에 대한 의견을 들어보는 것도 좋을 것 같은데.. 게임을 만들어 보는 과정에만 치중되어서 막상 그 과정에서 많은 ...

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