기본 콘텐츠로 건너뛰기

8월, 2009의 게시물 표시

YES!! Man을 거부해라.

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

테스팅은 언제 시작하나요?

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

카노 모델과 피쳐 크리프(Feature creep)

피쳐 크리프라는 말이 있다. 자세한 것은 위키피디아에게 물어보라. 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년대 심리학자 레온 페스팅거가 주장한 이론이다. ... 자세히 알아보도

결과보다는 과정을

우리는 주변에서 결과만을 강조하는 것을 아주 쉽게 볼 수 있다. 빨리 빨리 문화도 그렇고.. 주먹구구식의 행정 처리도 살펴보면 과정을 무시하고 결과만을 강조하기 때문에 그렇다는 것을 알 수 있다. 학생들도 성적만을 가지고 평가하다 보면 성적을 얻기 위해 치팅을 하고 각종 부정행위를 저지르는데에 대한 양심의 가책이 희석되어 버린다. 그들에게 지금 중요한 것은 결과이다. 어릴 때부터 이렇게 자라서 그런지 많은 테스터들 역시 결과만을 중요시한다. 얼마나 빨리 테스트를 하였는가? 얼마나 많은 테스트 케이스를 수행하였는가? 테스트가 끝나고 나면 결함이 발견된 확률은 얼마나 낮아졌는가? 얼마나 자동화를 이룩해 내었는가? 많은 부분에 있어 결과만을 강조하는 모양새다. 하지만 당신이 정말 테스트를 정말로 정말로 하늘의 업으로 여기고 잘하고 싶다면 이제는 과정을 생각해 볼때가 되었다. 충분조건 논리와 필요조건 논리가 있다. 충분조건 논리는 결과가 나중에 오는 것이다. 만약 이 기능이 제공되지 않으면 고객은 실망할 것입니다. 와 같이 표현된다. 필요조건 논리는 결과가 먼저 오게 된다. 고객이 우리 제품에 실망하지 않기 위해서는 이 기능은 꼭 제공되어야 합니다. 와 같이 표현된다. 많은 경우 우리는 필요조건 논리를 강조한다. 제품을 출시하기 위해서는 다음주까지 테스트가 완료되어야만 하네.. 하지만 이것을 그대로 수용하기만 한다면 당신은 전문성도 없는 정말 단순 노무직에 불과한 테스터입니다. 바꿔서 생각해 보시기 바랍니다. 정말로 다음주까지 테스트가 완료되어야만 제품을 출시할 수 있는가? 다음주까지 제품을 출시하지 못하는 것이 테스트만의 잘못인가? 다른 원인은 없는가? 유연한 사고의 확장은 테스터에게 반드시 꼭 필요한 것입니다. 그리고 테스터는 논리적이어야만 합니다. 그리고 일선에 계신 여러 관리자분들에게 어렵지만 한가지 부탁을 하자면 실패하더라도 과정이 성공적이었다면 훌륭하다는 평가를 내려주었으면 합니다. 성공하더라도 과정이 잘못된 것이라면 그 성공은 다음에 또 다시 올 수가 없

QA와 테스터 #2

트위터에서 @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와 테스터

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

표준에 대한 단상

어제 하루 종일 블로그에 올리고 싶었던 글을 머리 속에 깔끔하게 정리했었는데.. 인터넷을 할 수 없는 환경에 하룻밤을 자고 일어나니 말끔하게 포맷이 되어 버렸다.. 블로그를 하려면 이제는 노트와 볼펜이라도 들고 다녀야 할런가 보다. 그래서 원래 하고 싶었던 얘기는 다음으로 미루고.. 짧은 글 하나 남겨볼까 한다.. 주제는 표준이다.. 영어로 Standard 우리 주변의 모든 사물은 알게 모르게 무수히 많은 표준이 적용되어 있다. 심지어 여러분의 찬장에 짱박혀 있을 포도주 잔도 엄연한 표준이 있다. 소프트웨어 테스팅은 현재 ISO/IEC 29119 표준은 제정중이고, IEEE829 라는 문서 표준, ISTQB 라는 비영리 조직의 de facto 표준, 영국의 BS, ISEB 등 여러 표준이 있다. 그런데 이런 표준에 대하여 주변의 인식을 보면 무슨 신주단지 모시듯 한다. 표준에 대한 깊은 이해도 없이 그저 형식적이고 수박 겉핡기 식으로 따라하면 자기가 그 수준에 도달한 것인양 착각하는 사람들이 은근히 많다. 가장 대표적인 케이스가 CMMI, SPICE, ISO 9000 시리즈 같은 것들이다. 저런 인증을 받은 조직은 정말 저 인증에 걸맞는 것일까? 그런 곳도 분명 있지만 많은 경우 일종의 TF 팀을 조직해서 인증을 취득하고 인증 부산물은 그대로 창고로 직행하고 인증은 마케팅 용도로만 활용하는 경우도 다반사다. 왜 이런 일이 발생하는 것일까? 개인적으로 표준은 2가지 정도로 요약된다고 생각됩니다. 하나는 기술적인 표준입니다. 웹, 이메일, 코딩 룰 등 우리 주변은 다른 어떤 것과의 호환성 등을 이유로 반드시 반드시 지켜야 하는 표준이 있습니다. 익스플로러와 아웃룩, MS 오피스 등은 표준을 안지키기로 아주 악명이 높은 것들이죠.. 지배적 사업자라는 특혜를 누리는 변종들이라고 할까? 어쨌든 기술적인 표준은 정말로 정말로 지켜야 하는 표준입니다. 다른 하나는 프로세스 계열의 표준들입니다. 위에서 말한 CMMI, SPICE 등이 여기에 해당되죠. 이러한 표준은 반드시

컨설턴트와 매니저

컨설턴트라는 사람들이 있습니다. 어느 날 사장님이 우리는 변하여만 한다며 어디서 이상한 사람을 데려왔습니다. 하지만 우리는 힘들긴 하지만 변하고 싶은 생각은 쥐꼽만치도 없습니다. 특히 저 갑자기 튀어나온 인간이 도데체 머하는 인간인지는 모르겠지만 부하 직원들을 불러다가 이것 저것 꼬치 꼬치 캐묻고 사무실을 왔다 갔다 하면서 이것 저것 물어보고 있습니다. 그러더니 이것 저것 바꾸어야 한다면서 두툼한 문서를 들이밀고 있습니다. 이것은 명백한 도전입니다. 이것은 당신에게 당장 극복해야만 하는 과제입니다. 보고서라고 읽어보니 우리가 하는 일은 쥐뿔도 모르는 것 같습니다.. 아 정말 이사람은 뭐하는 인간이야? 이런 경험을 해보신 분 있으신가요? 우리는 주변에서 컨설팅 업체를 아주 쉽게 찾아 볼 수 있습니다. 그에 맞게 정말 많은 사람들이 컨설턴트로 일하고 있습니다. 사외에서 오는 컨설턴트 뿐만 아니라 사내에도 컨설턴트가 있습니다. 컨설턴트가 특별히 규정된 직업은 아닙니다. 당신에게 무엇인가를 조언해 주는 사람이 있다면 그 사람은 당신에게 있어서 컨설턴트입니다. 하지만 주변의 많은 경우에 컨설턴트에 대한 입장을 들어보면 무척 냉소적이고 비아냥 거리는 사람들이 많습니다. 이렇게 된 저변에는 무능한 컨설턴트들도 한 몫을 한 것도 있지만 컨설턴트에 대해 많은 것을 오해하고 있는 부분도 있습니다. 여러분은 컨설턴트를 누구라고 생각하시나요? 컨설턴트는 무슨 일을 하는 사람일까요? 우리 조직을 변화시키겠다고 옆에서 들쑤시는 이 컨설턴트에게 무슨 일을 맡기면 좋을까요? 자, 만약 지금 당신이 무기력해지고 냉소적으로 변한 조직에 변화를 주고자 열심히 노력중이지만 당신의 정치적인 능력이나 인지도를 보충할 목적으로 컨설턴트를 부른다면 어떨까요? 즉, 당신은 컨설턴트를 일종의 방패막으로 사용할 예정입니다. 아니면 컨설턴트에게 조직의 프로세스 개선을 모두 맡기고 모든 작업을 일임한다면 어떨까요? 만약 지금 당신이 위와 같은 목적으로 컨설팅을 의뢰할 예정이라면 포기하실 것을 권합니다. 당신이

호손 효과

호손 효과라는 것이 있습니다. 간단히 정의하면 호손 효과 (Hawthorne effect)는 근로자의 행동을 관찰함으로서 그들의 행동이 변하며 따라서 일시적으로 효율이 변화하는 현상을 말한다. 이 현상은 1924년에서 1932년 사이에 호손 웍스라는 공장에서 수행된 일련의 실험에서 얻어진 결과에서 처음 관찰된데서 유래한다. 최근 들어서는 호손 효과의 의미는 확장되어 어떤 새로운 관심을 기울이거나 관심을 더 쏟는 것으로 대상의 사람들이 행동과 능률에 변화가 일어나는 현상을 말하는 것으로 변했다. -위키피디아- 로 정의되어 있다. 어떤 분들은 호손 효과를 인정하지 않는 분도 있지만 우리는 이러한 현상을 주변에서 아주 쉽게 접할 수 있습니다. 약간 어려운 얘기 하나와 쉬운 예기 하나를 해보겠습니다. 우선 어려운 얘기부터.. 여러분은 혹시 고등학교 물리에 나오는 전자의 준위에 대해 기억하시나요? 우리의 주변의 모든 사물은 분자로 구성됩니다. 그리고 분자는 원자핵과 전자로 구성되죠.. 원자핵은.. 도 어쩌고 저쩌고... 여기서 고등학교 물리책을 보면 가운데 원자핵을 그리고 주변에 원자핵 주변을 도는 태양계와 비슷한 그림 혹시 기억하시나요? 하지만 그건 진실이 아닙니다. 전자의 위치를 확인하기 위해 바깥에서 에너지를 주입할 경우 전자의 준위는 변하게 되고 우리는 실제 전자의 위치가 아닌 확률상의 위치만을 가늠할 수 있을 뿐이죠.. 이걸 전자 구름이라고 합니다. 즉, 전자가 자신의 위치에서 외부의 에너지로 인하여 일시적으로 자신의 위치가 변경되는 것도 어떻게 보면 호손 효과라 할 수 있습니다. 쉬운 예기를 해볼까요? 전 컨설턴트도 해보았고 테스트 팀의 매니저나 리드도 해보았습니다. 이때 재미있는 것이 제가 어떤 조직에 컨설팅을 나갈 경우 제가 있을 때는 성과도 나오고 효율도 올라간 팀이 제가 철수하고 나면 원상 복귀되는 현상이 생긴다는 겁니다. 이것도 일종의 호손 효과라 할 수 있습니다. 실제 조직의 효율에 제가 일시적으로 변화를 일으킨 것입니다. 문제는 이러한 것들이 컨

화이트박스 테스팅과 블랙박스 테스팅

테스팅 관련 서적을 구매하면 어디든 빠지지 않고 나오는 것이 화이트박스 테스팅과 블랙박스 테스팅이다. 하지만 국내외 많은 서적들이 아직 ISO/IEC 29119와 ISTQB에서 제공하는 내용이 아닌 옛날의 개념을 담고 있는 것이 많아 혼란스러워하거나 잘못 알고 있는 사람들이 많아 우선 짧게 화이트박스 테스팅과 블랙박스 테스팅의 최근 개념에 대하여 적고자 한다. 자세한 내용은 추후에 좀 더 보강해볼 생각이다. 우선 첫번째 문제는 많은 곳에서 화이트 박스 테스팅과 블랙박스 테스팅을 기법으로 소개하고 있다는 것이다. 하지만 최근에는 화이트 박스 테스팅과 블랙박스 테스팅은 접근법으로 분류한다. ISTQB Foundation Level에서는 테스팅 기법은 명세기반 기법, 구조기반 기법, 경험기반 기법의 3가지로 분류한다. 화이트박스 테스팅과 블랙박스 테스팅을 기법으로 분류하면서 생기는 두번째 문제는 테스트 레벨과 연계된 설명에서 발생한다. 일부 서적에서는 하위레벨 테스팅(즉, 단위 테스팅과 통합테스팅)에서는 화이트박스 테스팅, 상위레벨 테스팅(시스템 테스팅, 인수 테스팅)에서는 블랙박스 테스팅이라는 어이없는 설명을 하는 경우가 아직도 있고, 그렇게 알고 있는 사람도 의외로 많다. 하지만 이것은 예전의 개념이고 최근에는 테스팅 레벨과 테스팅 접근법, 테스팅 기법은 단순한 조합의 문제로 취급한다. 하위레벨 테스팅이나 상위레벨 테스팅에 관계없이 어떤 테스팅 레벨에서도 다양한 테스팅 접근법과 기법을 적용하여 완성도 높은 테스팅을 수행하는 것을 목적으로 한다. 여기에는 리소스(인력, 자원, 예산 등)의 문제가 발생할 수 있는데, 리소스에 대한 문제는 리스크 기반 테스팅 전략으로 커버한다. 최근의 ISO/IEC 29119에서는 아래와 같이 분류하고 있다.