아래 위키에서 최신 내용을 볼 수 있습니다.
: in my wiki: 누가 테스트 해야 하는가?
* initial version: 2007.08.12
목차
1 들어가기 전에
2 누가 테스트 해야 하는가?
2.1 단위 시험은 개발자가
2.2 통합 시험은 개발팀내 Integrator가 (특정 경우 개발자 자신이)
2.3 시스템 시험은 제 3의 조직이
1 들어가기 전에
SQA (Software Quality Assurance)에 대해서 글을 써보려고 하는데, 왜 첫 주제 (제목)가 이 것일까?
조직의 성숙도 - CMM이나 SPICE에서 말하는 - 가 낮거나 높거나 이 것은 중요한 문제이고, SE 또는 SQA의 존재 여부를 결정하는 조직 (또는 개인)의 의지 (will)와도 관계가 있기 때문에 첫 주제로 선택했다.
이 글은 테스트 - 단위 테스트 (unit testing) ~ 시스템 테스트 (system testing) - 를 누가 해야 하는지에 대한 답에 관해서다룬다.
2 누가 테스트 해야 하는가?
이 질문에 대한 답변은 바로 당신 (You)이다.
설령, 당신이 조직에서 최고의 자리에 있다고 해도 예외일 수는 없다.
2.1 단위 시험은 개발자가
한 모듈 - module, component, 또는 단 하나의 함수 등 - 을 맡은 개발자는 책임 (responsibility)을 가지고 자신이 맡은 것에 대해서 검증 (validation & verification) 해야 한다.
하지만, 우리는 현실 - 일정 (Schedule)과 Man/Month - 을 이야기 한다.
* 테스트할 시간이 없어요. 이 번 주가 릴리즈 (Release)인데요.
* 코드 짜면서 야근해서 너무 피곤한데 그거 (단위 테스트) 할 시간이 어디 있어요?
* 테스트 한다고 - 소스 기반은 테스트 케이스를 만들어서 테스트 했다고 - 누가 알아 주나요?
* 다 합쳐서 (통합해서) 꾹꾹 눌러보면서 - System testing - (Defect)잡는게 더 빨라요. 그리고 그건 테스트 하는 애들이 해요.
* 신입 사원 시키면 돼요.
* 우리 개발자들 힘든데, 그리고 일정 맞추기 힘든데 꼭 해야 합니까?
모두 현실이라는 말에서 핑계로 치부하고 외면하기 힘든 말들이다.
하지만, 위 모든 질문들은 악순환을 막기 위해서 감수해야하는 일들이기도 하다.
단위 시험을 개발자 스스로 꼭 해야 하는 이유는
* 자신이 팀장에게 구현이 잘못 되었다는 꾸지람을 피하기 위한 것 뿐만 아니라
* 나 자신으로 인해 내 모듈과 연관된 다른 개발자에게 피해를 주지 않기 위해서
o 당신의 코드가 라이브러리 (또는 컴포넌트)라면 더욱더 중요할 것이다. 사용자가 믿고 쓸 수 있게 제공해야할 것 아닌가.
* 각 개발자들의 모듈을 통합하는 Integrator의 수고를 덜어주기 위해서
* 수만에서 수백만 라인이 된 거대 공룡의 소프트웨어를 블랙 박스로 테스트 (Black Box Testing)해서 발견된 결함 (Defect)을 공룡 (수만에서 수백만 라인을 가진)의 몸 속 구석 구석을 뒤져 재현 (re- production) 하고, 원인 (cause of defect)을 찾는 수고를 조금이라도 덜기 위해서
* 자신이 아닌 제 3자가 (third-party 이든, 신입사원이든) 자신의 모듈을 이해하는 시간을 줄이고, 자신의 모듈을 오해해서 잘 못 테스트하는 것을 막기 위해서
개발자 자신이 천국에 가기 위해서 수행해야 한다. 특히, 네 번째 이유는 일정이 부족하다는 핑계로 단위 시험을 소홀히 했을 경우 돌아오는 재앙일 수 있다.
SQA의 Testing에서 말하는 V 모델에서 개발자가 수행하는 단위 시험 (unit testing)은 제일 아래 - 구현과 pair로 - 에 있고 그 것의 의미를 V를 지탱하는 테스트 (엄밀하게는 dynamic testing에서)의 초석으로 생각해도 될 것이다.
TDD (Test Driven Development)와 같은 기법이 나온 것이 이와 같은 이유에서 일 것이다.
(※ 이 주제는 Regression Testing에서 좀 더 다뤄야할 주제이지만)
2.2 통합 시험은 개발팀내 Integrator가 (특정 경우 개발자 자신이)
통합 시험 (Integration Testing) 자체가 포함할 수 있는 것은 광범위할 것이다.
모든 모듈들을 통합 후,
* 각 개발자들이 만들어 놓은 단위 시험 테스트 케이스를 수행
* 여러 모듈에 걸친 시나리오 테스트 케이스 (Scenario test case)를 작성해서 수행
* 모듈간 호출 규약을 어기는 것이 없는지 (인터페이스를 거치지 않거나, 레이어를 넘어서 호출하거나) 정적 (static), 동적 (dynamic) 테스트
하는 것이 통합 시험이 될 수 있을 것이다.
일 정과 조직에 따라 이런 통합은 매일 일어날 수도 있고, 한 주에 한 번씩 또는 특정 phase에 한 번씩 일어날 수도 있을 것이다. 하지만 중요한 것은 이런 통합 시험은 통합이 일어날 때 마다 Integrator가 책임지고 수행해주어야 할 것이다.
통합이 일어나고 소프트웨어가 거대한 공룡이 되어 블랙박스 형태로 제 3의 조직 (third-party)에 넘겨지기 전에 어머니가 딸을 보내는 것 처럼 정성을 다해 개발 조직 내에서 수행해야 할 것이다.
꼭 개발팀 내에서 해야하는 이유는 위에서 언급한 통합 시험의 형태와 연관지어 보면 다음과 같다.
* 첫 번째 형태의 이유 - 각 개발자들의 단위 시험 테스트 케이스 수행
다른 조직의 구성원이 모든 개발자들의 단위 시험 테스트 케이스를 수행시키는 것은 쉽지만은 않은 일이다. 가슴에 손을 올리고 생각해보라.
만 약 당신이 코드 기반의 단위 시험 테스트 케이스를 작성했다고 가정한다면, 단 한 마디의 설명 없이 (설령 관련 문서가 있다고 하더라도) 제 3자가 당신의 단위시험 테스트 케이스를 당신의 모듈과 함께 컴파일해서 수행해 볼 수 있을 것인가?
컴파일해서 수행한다고 해도 수행 결과가 pass인지 fail인지 제 3자가 쉽게 알 수 있을까?
아무리 JUnit, CppUnit, CUnit, CUTest, CXXUnit, JsUnit, NUnit 으로 코드 기반의 테스트 케이스를 잘 작성하고 테스트 케이스 명세서 (Test case specification document)를 잘 작성해두었다고 해도 제 3자가 당신의 단위 시험을 대신해주기 위해서는 시간이 걸릴 것이다.
이 것은 개발 팀내의 Integrator도 마찬가지겠지만, 그는 각은 팀 내에 있기 때문에 의사 소통이 좀 더 용이하고 다른 조직의 테스터 보다 소프트웨어에 대한 도메인 지식 (Domain Knowledge)이 많기 때문에, 제 3 조직 보다 수월하게 당신의 단위 시험 테스트 케이스를 충실히 돌릴 수 있다.
* 두 번째 형태의 이유 - 시나리오 테스트 케이스
당신의 모듈이 미들웨어 (middleware)의 어떤 모듈이라면, 시나리오 테스트 케이스를 작성한다는 것은 그런 모듈들을 이용해서 어플리케이션 (application)을 작성하는 것과 같은 것이다. 그리고 정상적인 경우 (positive) 이외에 예외 상황 (negative)에 대한 테스트 케이스라면 도메인에 대한 많은 지식을 요구할 것이다. 이 것을 제 3의 조직에서 할 수 있을까? 할 수도 있겠지만 시간이 너무 많이 걸릴 것이다. 또는 당신의 유능한 메인 프로그래머를 제 3 조직으로 보내면 해결 될 수도 있는 문제이다. (이 것인 OSGi와 같이 framework이나 각 service에 대해 환상적으로 Spec.이 작성되어있다고 해도 마찬가지일 것이다)
* 세 번째 형태의 이유 - Call violation check
정적 분석 (static-analysis)을 도구 (prevent 등)를 통해서 하는 경우 수행 주체는 제 3의 조직이 할 수 있겠지만, 분석은 개발 조직에서 해야할 것이다.
정적 분석을 도구를 사용하지 않고 리뷰 (review)나 inspection을 통해서 수행한다면 당연히 도메인 지식이 있는 각 개발자나 integrator가 수행해야 할 것이다.
동적으로 이 것을 체크 한다면 두 번째 형태의 이유와 같이 소프트웨어에 대한 지식이 있는 개발팀 내 구성원이 수행해야 할 것이다.
2.3 시스템 시험은 제 3의 조직이
시스템 시험 (System testing)의 경우 블랙 박스 테스팅 (Black box testing)의 형태로 매뉴얼 테스트 (manual testing)가 되어지는 경우가 많을 것이다. (물론 TestQuest 와 같은 자동화된 도구를 사용할 수도 있을 것이다, 그리고 코드 기반으로 Gray box testing을 수행할 수도 있을 것이다.) 이 것을 제 3의 조직이 하는 것에 대해서 불만을 내보일 개발 조직은 없을 것이다. (누군가가 대신 먼가를 해준다는 관점에서) 하지만 어떤 경우 - 제 3의 조직이 없는 경우, 개발팀 내에서 시스템 시험을 하는 경우가 있다. 우선, 누구든 시험을 하는 것 자체만으로도 고마운 것이 현실이지만, 이 형태가 좋다고는 말할 수 없다. 위의 단위 시험과 통합 시험 이야기에서 테스트 대상 소프트웨어의 도메인 지식이 풍부한 개발자가 수행하는 것이 무엇이 나쁘겠는가? 라고 반문할 수도 있겠지만 이유는 다음과 같다.
* 제 3자의 객관적인 눈을 가지고 테스트할 수 없다.
단 한 번이라도 단위 시험 테스트 케이스를 만들어 본 사람이라면 이해할 수 있을 것이다. 테스트 케이스를 작성할 것 까지 갈 것도 없이 자신이 만든 함수를 자신이 사용해 본 사람이라면 이해할 수 있을 것이다. 사람은 자신에 대해서 관대 하다. Exception handling으로 똘똘 뭉친 완전한 java programmar나 어느 정도 경력이 쌓인 개발자가 아닌 이상 - 그렇다고 해도 시간이나 상황에 따라 그들도 피할 수 없을 것이다 - 자신의 모듈을 테스트 해서 예외 적인 상황을 검출하기는 힘들다. 이 것을 우물안 개구리가 되지 않기 위함이다. 다음의 두 대화를 보자.
Test engineer (system testing을 수행 중인): 이 거 제대로 동작하지 않고 죽는데요.. defect이 아닌지요? (공손하다) Developer:끙... 이렇게 짜는 사람이 어디있어요? 당연히 이거 먼저 해주셔야죠? (짜증이다) Defect 아닙니다. Test case 잘 못 만드셨네요!! Test engineer: ...
Test engineer가 임시직이나 신입 사원에 가까울 수록 위의 대화는 더 거칠어 질 수 있다. 천국에 가고 싶은 개발자라면 - 이 세상 고생하는 모든 개발자들은 모두 천국에 가야겠지만 - 가슴에 손을 올리고 생각해보라.
테 스터가 위와 같은 실수를 하지 않도록 당신 모듈에 대한 요구 명세서 (Requirement Specification)이나 구조/상세 설계서를 잘 작성해두었는가? 코드 기반의 시스템 테스트라면 Programmer Guide 문서를 잘 작성해두었는가? 그리고, 테스터의 실수를 당신의 코드가 제대로 예외 처리해주고 있는가? 테스터의 실수는 고객의 실수일 수도 있다.
" 어떠한 상황에서도 이 값이 들어올 수 없습니다." 라고 마음속으로 또는 직접 말로 할 수도 있겠지만, 당신은 신이 아니다. 내가 본 어떤 곳에선 자석을 제품에 가까이 대었을 때 자기장으로 bit들이 바뀌는 상황에 대한 예외 처리를 하는 것을 본 적이 있다. -_- 믿거나 말거나
요지는, 당신이 아닌 제 3자의 어린 아이 눈과 같은 객관성으로 당신의 코드와 코드의 예외 처리와 필요한 문서를 점검하는 것이 시스템 테스트이기 때문에 제 3의 조직 (thirdparty)가 시스템 테스트를 수행하는 것이 바람직하다.
: in my wiki: 누가 테스트 해야 하는가?* initial version: 2007.08.12
목차
1 들어가기 전에
2 누가 테스트 해야 하는가?
2.1 단위 시험은 개발자가
2.2 통합 시험은 개발팀내 Integrator가 (특정 경우 개발자 자신이)
2.3 시스템 시험은 제 3의 조직이
1 들어가기 전에
SQA (Software Quality Assurance)에 대해서 글을 써보려고 하는데, 왜 첫 주제 (제목)가 이 것일까?
조직의 성숙도 - CMM이나 SPICE에서 말하는 - 가 낮거나 높거나 이 것은 중요한 문제이고, SE 또는 SQA의 존재 여부를 결정하는 조직 (또는 개인)의 의지 (will)와도 관계가 있기 때문에 첫 주제로 선택했다.
이 글은 테스트 - 단위 테스트 (unit testing) ~ 시스템 테스트 (system testing) - 를 누가 해야 하는지에 대한 답에 관해서다룬다.
2 누가 테스트 해야 하는가?
이 질문에 대한 답변은 바로 당신 (You)이다.
설령, 당신이 조직에서 최고의 자리에 있다고 해도 예외일 수는 없다.
2.1 단위 시험은 개발자가
한 모듈 - module, component, 또는 단 하나의 함수 등 - 을 맡은 개발자는 책임 (responsibility)을 가지고 자신이 맡은 것에 대해서 검증 (validation & verification) 해야 한다.
하지만, 우리는 현실 - 일정 (Schedule)과 Man/Month - 을 이야기 한다.
* 테스트할 시간이 없어요. 이 번 주가 릴리즈 (Release)인데요.
* 코드 짜면서 야근해서 너무 피곤한데 그거 (단위 테스트) 할 시간이 어디 있어요?
* 테스트 한다고 - 소스 기반은 테스트 케이스를 만들어서 테스트 했다고 - 누가 알아 주나요?
* 다 합쳐서 (통합해서) 꾹꾹 눌러보면서 - System testing - (Defect)잡는게 더 빨라요. 그리고 그건 테스트 하는 애들이 해요.
* 신입 사원 시키면 돼요.
* 우리 개발자들 힘든데, 그리고 일정 맞추기 힘든데 꼭 해야 합니까?
모두 현실이라는 말에서 핑계로 치부하고 외면하기 힘든 말들이다.
하지만, 위 모든 질문들은 악순환을 막기 위해서 감수해야하는 일들이기도 하다.
단위 시험을 개발자 스스로 꼭 해야 하는 이유는
* 자신이 팀장에게 구현이 잘못 되었다는 꾸지람을 피하기 위한 것 뿐만 아니라
* 나 자신으로 인해 내 모듈과 연관된 다른 개발자에게 피해를 주지 않기 위해서
o 당신의 코드가 라이브러리 (또는 컴포넌트)라면 더욱더 중요할 것이다. 사용자가 믿고 쓸 수 있게 제공해야할 것 아닌가.
* 각 개발자들의 모듈을 통합하는 Integrator의 수고를 덜어주기 위해서
* 수만에서 수백만 라인이 된 거대 공룡의 소프트웨어를 블랙 박스로 테스트 (Black Box Testing)해서 발견된 결함 (Defect)을 공룡 (수만에서 수백만 라인을 가진)의 몸 속 구석 구석을 뒤져 재현 (re- production) 하고, 원인 (cause of defect)을 찾는 수고를 조금이라도 덜기 위해서
* 자신이 아닌 제 3자가 (third-party 이든, 신입사원이든) 자신의 모듈을 이해하는 시간을 줄이고, 자신의 모듈을 오해해서 잘 못 테스트하는 것을 막기 위해서
개발자 자신이 천국에 가기 위해서 수행해야 한다. 특히, 네 번째 이유는 일정이 부족하다는 핑계로 단위 시험을 소홀히 했을 경우 돌아오는 재앙일 수 있다.
SQA의 Testing에서 말하는 V 모델에서 개발자가 수행하는 단위 시험 (unit testing)은 제일 아래 - 구현과 pair로 - 에 있고 그 것의 의미를 V를 지탱하는 테스트 (엄밀하게는 dynamic testing에서)의 초석으로 생각해도 될 것이다.
TDD (Test Driven Development)와 같은 기법이 나온 것이 이와 같은 이유에서 일 것이다.
(※ 이 주제는 Regression Testing에서 좀 더 다뤄야할 주제이지만)
2.2 통합 시험은 개발팀내 Integrator가 (특정 경우 개발자 자신이)
통합 시험 (Integration Testing) 자체가 포함할 수 있는 것은 광범위할 것이다.
모든 모듈들을 통합 후,
* 각 개발자들이 만들어 놓은 단위 시험 테스트 케이스를 수행
* 여러 모듈에 걸친 시나리오 테스트 케이스 (Scenario test case)를 작성해서 수행
* 모듈간 호출 규약을 어기는 것이 없는지 (인터페이스를 거치지 않거나, 레이어를 넘어서 호출하거나) 정적 (static), 동적 (dynamic) 테스트
하는 것이 통합 시험이 될 수 있을 것이다.
일 정과 조직에 따라 이런 통합은 매일 일어날 수도 있고, 한 주에 한 번씩 또는 특정 phase에 한 번씩 일어날 수도 있을 것이다. 하지만 중요한 것은 이런 통합 시험은 통합이 일어날 때 마다 Integrator가 책임지고 수행해주어야 할 것이다.
통합이 일어나고 소프트웨어가 거대한 공룡이 되어 블랙박스 형태로 제 3의 조직 (third-party)에 넘겨지기 전에 어머니가 딸을 보내는 것 처럼 정성을 다해 개발 조직 내에서 수행해야 할 것이다.
꼭 개발팀 내에서 해야하는 이유는 위에서 언급한 통합 시험의 형태와 연관지어 보면 다음과 같다.
* 첫 번째 형태의 이유 - 각 개발자들의 단위 시험 테스트 케이스 수행
다른 조직의 구성원이 모든 개발자들의 단위 시험 테스트 케이스를 수행시키는 것은 쉽지만은 않은 일이다. 가슴에 손을 올리고 생각해보라.
만 약 당신이 코드 기반의 단위 시험 테스트 케이스를 작성했다고 가정한다면, 단 한 마디의 설명 없이 (설령 관련 문서가 있다고 하더라도) 제 3자가 당신의 단위시험 테스트 케이스를 당신의 모듈과 함께 컴파일해서 수행해 볼 수 있을 것인가?
컴파일해서 수행한다고 해도 수행 결과가 pass인지 fail인지 제 3자가 쉽게 알 수 있을까?
아무리 JUnit, CppUnit, CUnit, CUTest, CXXUnit, JsUnit, NUnit 으로 코드 기반의 테스트 케이스를 잘 작성하고 테스트 케이스 명세서 (Test case specification document)를 잘 작성해두었다고 해도 제 3자가 당신의 단위 시험을 대신해주기 위해서는 시간이 걸릴 것이다.
이 것은 개발 팀내의 Integrator도 마찬가지겠지만, 그는 각은 팀 내에 있기 때문에 의사 소통이 좀 더 용이하고 다른 조직의 테스터 보다 소프트웨어에 대한 도메인 지식 (Domain Knowledge)이 많기 때문에, 제 3 조직 보다 수월하게 당신의 단위 시험 테스트 케이스를 충실히 돌릴 수 있다.
* 두 번째 형태의 이유 - 시나리오 테스트 케이스
당신의 모듈이 미들웨어 (middleware)의 어떤 모듈이라면, 시나리오 테스트 케이스를 작성한다는 것은 그런 모듈들을 이용해서 어플리케이션 (application)을 작성하는 것과 같은 것이다. 그리고 정상적인 경우 (positive) 이외에 예외 상황 (negative)에 대한 테스트 케이스라면 도메인에 대한 많은 지식을 요구할 것이다. 이 것을 제 3의 조직에서 할 수 있을까? 할 수도 있겠지만 시간이 너무 많이 걸릴 것이다. 또는 당신의 유능한 메인 프로그래머를 제 3 조직으로 보내면 해결 될 수도 있는 문제이다. (이 것인 OSGi와 같이 framework이나 각 service에 대해 환상적으로 Spec.이 작성되어있다고 해도 마찬가지일 것이다)
* 세 번째 형태의 이유 - Call violation check
정적 분석 (static-analysis)을 도구 (prevent 등)를 통해서 하는 경우 수행 주체는 제 3의 조직이 할 수 있겠지만, 분석은 개발 조직에서 해야할 것이다.
정적 분석을 도구를 사용하지 않고 리뷰 (review)나 inspection을 통해서 수행한다면 당연히 도메인 지식이 있는 각 개발자나 integrator가 수행해야 할 것이다.
동적으로 이 것을 체크 한다면 두 번째 형태의 이유와 같이 소프트웨어에 대한 지식이 있는 개발팀 내 구성원이 수행해야 할 것이다.
2.3 시스템 시험은 제 3의 조직이
시스템 시험 (System testing)의 경우 블랙 박스 테스팅 (Black box testing)의 형태로 매뉴얼 테스트 (manual testing)가 되어지는 경우가 많을 것이다. (물론 TestQuest 와 같은 자동화된 도구를 사용할 수도 있을 것이다, 그리고 코드 기반으로 Gray box testing을 수행할 수도 있을 것이다.) 이 것을 제 3의 조직이 하는 것에 대해서 불만을 내보일 개발 조직은 없을 것이다. (누군가가 대신 먼가를 해준다는 관점에서) 하지만 어떤 경우 - 제 3의 조직이 없는 경우, 개발팀 내에서 시스템 시험을 하는 경우가 있다. 우선, 누구든 시험을 하는 것 자체만으로도 고마운 것이 현실이지만, 이 형태가 좋다고는 말할 수 없다. 위의 단위 시험과 통합 시험 이야기에서 테스트 대상 소프트웨어의 도메인 지식이 풍부한 개발자가 수행하는 것이 무엇이 나쁘겠는가? 라고 반문할 수도 있겠지만 이유는 다음과 같다.
* 제 3자의 객관적인 눈을 가지고 테스트할 수 없다.
단 한 번이라도 단위 시험 테스트 케이스를 만들어 본 사람이라면 이해할 수 있을 것이다. 테스트 케이스를 작성할 것 까지 갈 것도 없이 자신이 만든 함수를 자신이 사용해 본 사람이라면 이해할 수 있을 것이다. 사람은 자신에 대해서 관대 하다. Exception handling으로 똘똘 뭉친 완전한 java programmar나 어느 정도 경력이 쌓인 개발자가 아닌 이상 - 그렇다고 해도 시간이나 상황에 따라 그들도 피할 수 없을 것이다 - 자신의 모듈을 테스트 해서 예외 적인 상황을 검출하기는 힘들다. 이 것을 우물안 개구리가 되지 않기 위함이다. 다음의 두 대화를 보자.
Test engineer (system testing을 수행 중인): 이 거 제대로 동작하지 않고 죽는데요.. defect이 아닌지요? (공손하다) Developer:끙... 이렇게 짜는 사람이 어디있어요? 당연히 이거 먼저 해주셔야죠? (짜증이다) Defect 아닙니다. Test case 잘 못 만드셨네요!! Test engineer: ...
Test engineer가 임시직이나 신입 사원에 가까울 수록 위의 대화는 더 거칠어 질 수 있다. 천국에 가고 싶은 개발자라면 - 이 세상 고생하는 모든 개발자들은 모두 천국에 가야겠지만 - 가슴에 손을 올리고 생각해보라.
테 스터가 위와 같은 실수를 하지 않도록 당신 모듈에 대한 요구 명세서 (Requirement Specification)이나 구조/상세 설계서를 잘 작성해두었는가? 코드 기반의 시스템 테스트라면 Programmer Guide 문서를 잘 작성해두었는가? 그리고, 테스터의 실수를 당신의 코드가 제대로 예외 처리해주고 있는가? 테스터의 실수는 고객의 실수일 수도 있다.
" 어떠한 상황에서도 이 값이 들어올 수 없습니다." 라고 마음속으로 또는 직접 말로 할 수도 있겠지만, 당신은 신이 아니다. 내가 본 어떤 곳에선 자석을 제품에 가까이 대었을 때 자기장으로 bit들이 바뀌는 상황에 대한 예외 처리를 하는 것을 본 적이 있다. -_- 믿거나 말거나
요지는, 당신이 아닌 제 3자의 어린 아이 눈과 같은 객관성으로 당신의 코드와 코드의 예외 처리와 필요한 문서를 점검하는 것이 시스템 테스트이기 때문에 제 3의 조직 (thirdparty)가 시스템 테스트를 수행하는 것이 바람직하다.
