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

효과적인 테스팅과 효율적인 테스팅의 트레이드 오프의 결과로 최근에 가장 추천되는 테스팅 수행 전략과 접근법은 리스크 기반 테스팅이다. 리스크 기반 테스팅은 간단히 말한다면 리스크가 높은 영역은 동원할 수 있는 모든 리소스를 투입하여 완성도 높게 테스트 하고 리스크가 낮은 영역은 그에 맞는 리소스를 투입하자는 것이다. 이 리스크 기반 테스팅을 소개할 때 가장 많이 드는 예제 중 하나가 원자력 발전, 우주항공산업, 의료산업 등에 사용되는 소프트웨어들이다. 이러한 산업들에 사용되는 소프트웨어들의 공통점은 결함에 의한 장애가 발생할 경우 인간의 생명과 직결되는 경우가 많고 비용적인 손해가 막대하다는 점이다. 즉, 리스크가 매우 높다는 것이다. 이러한 소프트웨어에 요구되는 여러 특성 중 하나가 바로 결함발생율이다. 위의 산업 분야에서 사용되는 소프트웨어들은 실제 운용되는 환경에서 결함이 발생할 확률은 말 그대로 0에 가까워야만 한다. 지금까지 이야기는 그 자체로 그다지 문제가 없어 보이는 아주 당연한 이야기이다. 하지만 위의 예제에서 우리가 한가지 잊고 있는 가정이 하나 있다. 그것이 과연 무엇일까? 아마 많은 분들이 쉽게 알아낼 수 있을 것이라고 생각되지만, 혹시 확~~ 생각나지 않으신다면 잠시 곰곰히 생각해 보시기 바란다. 펼쳐두기.. 위의 예제에서 우리가 잊고 있는 가정은 바로 변동성, 그 변동성의 근본이 되는 사용자이다. 잘 생각해 보자. 원자력 발전, 우주항공산업, 의료 산업등에 사용되는 소프트웨어는 그 사용자가 매우 제한되어 있다. 이 사용자들의 행동 패턴은 충분히 통제 가능한 수준이다. 필요한 경우에는 정해진 행동만을 할 수 있도록 사용자를 교육하기도 한다. 위의 소프트웨어들은 개발 초기부터 발생할 수 있는 모든 상황과 사용 가능한 모든 경우를 한정하고 통제 가능한 상황아래 가정을 세우고 개발을 한다. 때문에 위의 소프트웨어들을 개발할 때는 폭포수 개발 모델이 유용할 수도 있다. 그리고 위와 같이 변동성을 통제할 수 있다면 결함의 발생...

보안성 테스팅은 크게 2가지로 생각해 볼 수 있다. 하드웨어 그리고 소프트웨어.. 무슨 말인고 하니.. 단순히 기술적인 그리고 장비 위주의 보안 테스팅이 있다. 방화벽, 라우터, 공격 탐지, 트래픽 추적 등 눈에 보이고 자동화 가능하고 수많은 벽을 둘러치고 그 벽이 튼튼하고 안전한지 검증하는 테스팅은 하드웨어라고 볼 수 있다. 이러한 테스팅 방법은 지금도 많은 곳에서 수 없는 기법과 장비가 만들어지고 소개되고 판매되고 있다. 때문에 이 방법은 정보를 얻기도 쉽고 커뮤니티도 쉽게 찾을 수 있다. 힘들긴 하지만 미칠 듯 노력하면 쉽게 어느 정도의 경지에 도달할 수도 있다. 하지만 우리는 이러한 이면에 숨겨져 있는 다른 부분에 대해서는 그다지 많이 고민하지는 않는 것 같다. 물론 국제 표준도 있으며, 국내에 커뮤니티도 있고, 이와 관련된 자격증도 있는 것으로 안다. 하지만 하드웨어적인 보안 테스팅에 비해 많이 알려지지 않은 것은 사실인 것 같다. 누구나 알고 있지만 해답을 찾기도 쉽지 않고 테스팅 하기도 어려운 이것은 조직과 개인 그리고 정책 차원의 보안 테스팅 즉, 내가 소프트웨어 보안 테스팅이라고 부르는 것이다. 이 소프트한 보안의 근간은 신뢰이다. 신뢰는 일종의 맹신과 같은 형태로 나타나기도 한다. 이것이 하드웨어적인 보안을 한방에 부술 수 있는 매우 강력한 형태로 나타나기도 한다. 신뢰란 무엇일까? 우리는 무엇을 근거로 신뢰를 하는 것일까? 이것을 파악할 수 있다면 좀 더 튼튼한 보안 체계를 구축할 수 있을 것이다. 한가지 예를 들어보도록 하자.. 자 당신이 은행에 가서 상담원과 독대를 하고 펀드나 적금 상품을 가입한다고 해보자. 상담원이 당신에게 주민등록증을 요구할 때 당신은 당신의 소중한 개인정보를 건네주면서 어떤 생각을 하시나요? 상담원을 의심해 본적 있으신가요? 잠시 고민을 하지만 거의 대부분 스스럼 없이 주민등록증을 건네줍니다. 반대로 당신이 길에서 생판 처음 보는 사람이 주민등록증 좀 잠시 보여달라고 하면 어...

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