기본이 바로 선 나라

Elisabeth Hendrickson 의 2005년도 Google Tech Talks 내용이다.

나의 관심의 흐름은 당연한 것 같다. 좀 더 숙성 시키지 못하는 것이 아쉽지만…

힘내면서… 준비하면서… 때를 기다리자.

원문 : http://www.satisfice.com/articles/sfdpo.shtml

번역 : 삼성전자 조형헌

아직 테스트에 감이 없으신 분들은 이런 틀을 가지고 하시면 어떨까요? 많은 도움이 되실 것 같습니다.

어떤 식으로 테스팅을 시작하시나요?
- 테스팅을 시동 거는 연상법
by James Bach

탐색 시험 중에는 실시간으로 테스트를 설계하고 수행해야 합니다.
그렇다면 가치 있는 테스트를 하려면 어떤 식으로 생각을 정리해야
할까요?
여기에서 말씀드릴 ‘선험/연상법’이 하나의 방법이 될 수 있습니다.

여기서 선험이란
‘어림짐작으로 헤아려 보기, 단순화 하기 혹은 학습된 추측’을 의미합니다.

현관문 앞 매트 아래서 열쇠를 찾는 방식이 그 예가 되겠죠.

반대로 연상은 “복잡하고 긴 정보를 손쉽게 기억할 수 있도록 조직화한 단어나 운(rhyme) 또는 다른
암기법”을 말합니다.
이 두 가지는 촉박한 상황에서 문제를 해결하는데 유용합니다.

SFDPO로 테스팅을
시작하기

테스팅 중 제가 자주 사용했던 선험/연상법은 “샌 프란시스코 디폿(San Francisco
Depot)” 혹은 SFDPO 입니다.

이것은 구조(Structure), 기능(Function), 데이터(Data),
플랫폼(Platform) 그리고 작동법(Operations)의 첫 자를 따서 만든 겁니다.

이 단어들은 S/W 제품의 서로 다른 양상을 나타내기 때문에
이렇게 관점을 달리해서 제품을 고려해 보면 흥미로운 테스트를 생각해 낼
수 있습니다.

그래서 전 다뤄보지 않은 제품에 대해 테스팅 의뢰가 올때마다 “샌 프란시스코 디폿”을 되묻고,
이 제품의 다섯가지 항목에 대해
열거해 본 후, 테스트할 것에 대해 생각하기 시작합니다.

- 구조(Structure)
“어떤 거지?”

어떤 파일들을 다루지?

어떻게 만들어졌는지 알고 있게 있나?
하나의 프로그램으로 실행되나?

어떤 H/W에 담겨 출시되나?

모듈 별로 테스트 가능하나?

- 기능(Function)
“뭐하는 거지?”

무슨 기능을 하나?

어떤 예외 처리가 필요하려나?

어떤 UI를 가지고 있나?

사용자에게 숨겨진 무언가가 있나?
OS와의 인터페이스는 어떻게 하나?

- 데이터(Data) “무엇을
처리하지?”

어떤 입력을 처리하나?

출력은 어떻게 생겼나?

내부에 어떤 모드나 상태가 가능하나?
데이터를 미리 조절한(preset) 후 출시되나?

타이밍이나 순서에 민감한 입력 값이 있나?

- 플랫폼(Platform) “무엇에 연계되어
있지?“

어떤 OS에서 수행되나?

특수한 환경 설정을 해줘야 하나?

외부 컴포넌트에 연계되어 있나?

- 작동법(Operations) “어떻게
쓰이지?”

이걸 누가 쓰려나?

어디서 어떻게 쓰려나?

사용하기 위해 뭘해야 하나?
사용자가 해 볼 것 같은 뭔가가 있나?

보다 실제적인 테스트를 위해 얻을 수 있는 사용자 데이터가 있나?

아이디어를 빛 가운데로

제품에 대해 SFDPO 같은 약간의 트릭을 사용하면 보다 빠르게 아이디어를 얻을 수 있습니다.
하지만 전 이 방법의 민첩성보다
신뢰성 때문에 선호합니다.

SFDPO를 알기 전에는 테스트를 위해 다양한 아이디어를 생각해 낼 수 있었으나,
이 아이디어들이 임의적이고 분산되어 있음을
깨달았습니다.
즉 내 분석의 완결성을 평가할 방법이 없었던 거죠.

이런 선험/연상법을 체득한 지금은 여전히 뭔가 테스트 되지 않을 수 있음을 알고,
적어도 이 제품의 주요 양상에 대해 조직적으로
확인해 볼 수 있게 되었습니다.

따라서 이제는 테스트 기법에서부터 품질 기준에 걸친 모든 것에 대한 선험을 가지게 된거죠.

무언가를 알고 있다는 것이 시기적절하게 그것을 기억해 낼 수 있다는 것을 의미하는 것은 아닙니다.
때문에, SFDPO는 템플릿이나
테스트 플랜이 아니며 테스팅 중에 의식 속으로 중요한 아이디어를 가져다 주는 하나의 방법일 뿐입니다.
그래서 이것은 지적인 도구의
일부분입니다.

여러분이 보다 뛰어나고 신뢰할만한 탐색 테스터가 되기를 원한다면
지금부터라도 당신에게 맞는 이런 선험 창고를 만들고 수집하기를
시작해야 합니다.

동시에, 선험에는 어떤 지혜도 없음을 기억하세요.
지혜 자체는 여러분에게
있습니다.

선험은 단순히 아이디어를 일깨우는 일종의 자명 시계와 같아서 지금부터 어떤 행동을 취해야 하는지에 대해 말해 줄 수는 없습니다.

따라서 여기에 기술과 경험이 동반되어야 합니다.

좋은 테스팅은 섬세한 기예입니다.
따라서 좋은 도구를 지녀야만
합니다.

아주 기본적인 것이지만 혼돈해서 사용하는 분들이 많은 것 같습니다.

간단하게 정리해 봅니다.

“개발자도 알아야할 소프트웨어 테스팅 용어”에서 혼용해서 함께사용되곤 하는 용어를 찾아보았습니다.

Fail : 실제 결과가 예상 결과와 비교하여 다를 경우 테스트는 실패라고 간주됨. (A test is deemed to fail if its actual result does not match its expected result.)

Failure : 컴포넌트나 시스템이 예상된 인도(delivery)나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것. (Actual deviation of the component or system from its expected delivery, service or result.)

Fault : Defect 참고

Defect : 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점. 결함의 예는 부정확한 구문이나 부정확한 데이터 정의 드이다. 실행 중에 결함이 발생할 경우, 컴포넌트나 시스템의 장애(failure)를 야기시킬 수 있다. (A flaw in a component or system that can cause the component or  system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.)

Error : 부정확한 결과를 초래하는 인간의 활동. (A human action that produces an incorrect result.) 일반적으로 프로그래머에 의하여 생성된 실수(mistake)로 프로그램의 결함으로 나타난다.

제가 이것을 왜 정리했냐면 테스트에 대한 결과(효과)를 정리하는 과정에서 Test Case에 대한 Fail을
Defect으로 간주해서 그 수치를 늘리려고 하시는 분이 있어서 입니다. 아무리 급해도 그렇지 이건 아니라고 생각합니다.

테스터가 Test Case를 수행하다 실패한 것이 fail입니다. 이 때까지는 이것은 Defect이 아닙니다.  이 fail이 개발 담당자에 의해서 결함이라고 판단 되었을 때 이것은 Defect이 되는 것입니다. 그리고 Defect은 실패의 상황이 아닐 수도 있습니다. 로직의 오류가 인스펙션을 통해서 발견되어, 실제로 어떤 상황(문제)으로 나타나지 않더라고 이것은 Defect이라고 할 수 있습니다.

이런 말을 적는 저도 참 답답합니다만… 그 분도 참 답답합니다. ㅡ,.ㅡ;

이 버그를 누구에게 넘겨 줄 것인가?하는 글에 대한 Ray 님의 블로그 포스팅을 따라가서 김성훈 교수님에 대해서 알게 되었다.
아래는 “김성훈 교수와 일해보세요“에 나와있는 김교수님에 대한 소개이다.

김교수님은 현재 소프트웨어 스토리라는 블로그를 운영하고 있다.
거기서 Dissertation Defense 슬라이드가 소개되어 있었는데 내가 계속 관심을 가지고 우리회사에서 가장 필요한 일 중의 하나라고 생각했던 것이 소개되어 있었다.
버그를 잘 찾는 것과 그에 대한 해결에만(물론 이것도 중요하다) 집중되어 있는 현재 상황을 극복할 수 있는 방법중의 하나라고 생각했던 것이다.

김미령 박사의 “Analyzing and Inferring the Structure of Code Changes“도 흥미있었는데 이 두 부분에 대해서 잘 적용하면 우리가 만들고 있는 툴로도 많은 효과를 가지고 올 수 있을 것 같다.

<Adaptive Bug Prediction by Analyzing Project History>

나의 연구는 소프트웨어 개발 history에서 버그 패턴을 찾아 보는 연구이다. 어느 부분에 버그가 집중되는지를 캐쉬알고리즘으로
풀었고 소프트웨어에 변화가 생길때마다 이 변화에 버그가 있는지를 학습하여 새로운 변화가 있을때 버그가 있을지를 예측하는 연구였다.

조금 있으면 김교수님은 홍콩으로 가실 것 같은데 그 전에라도 우리 회사의 문제에 대해서 이야기하고 김교수님의 생각을 들어보는 자리가 있었으면 좋겠다. 일단 연락부터 한 번 드릴까? ^,.^;

최근에 Agile과 CMMI, 조직 문화에 대해서 공부하고 있었는데 잼난 것을 찾은 것 같아 흥분된다. 이런 시국에는 역량 강화를 할 수 있는 절호의 기회다. 열심히 공부하자.. 푸핫…

테스트 관련 Groups는 어떤 곳에 참여하시나요?

알고 계시는 테스트 관련 Blog는 어떤 것이 있으신가요?

댓글이나 트랙백 주시면 업데이트 하겠습니다.

(사이트는 너무 많아서 다음에 찬찬히 정리해 보죠.)

Groups

• http://tech.groups.yahoo.com/group/AgileEmbedded/
  : 테스트는 아니지만 테스트부터 Embedded 업계에 있는 Agile 실천가들의 고민이
  올라옵니다.

• http://groups.yahoo.com/group/testdrivendevelopment/
  : TDD 관련된 내용이 많이 올라옵니다. 그래서 Unit Test에 대한 질문들도 많이 올라오죠

• http://groups.yahoo.com/group/Testingkings/
  : 테스팅 전반적인 내용이 올라옵니다.

• http://groups.google.co.kr/group/comp.software.testing
  : 테스팅 전반적인 내용이 올라옵니다.

• http://groups.google.co.kr/group/googletestframework
  : Google C++ Testing Framework 그룹스 입니다.

• https://lists.sourceforge.net/lists/listinfo/unittest-cpp-devel
  : 그룹스는 아니지만 UnitTest++의 메일리스트 입니다.

Blog

• http://googletesting.blogspot.com/
  : 구글 테스팅 블로그죠.
• http://www.aphids.com/agiletesting/
  : Stan Taylor(Boland 에서 QA Architect로 근무)씨가 Agile Testing 관련 경험을 올리고있다.
• http://xelion.pe.kr/
  : 리얼 네트웍스에서 QA 관련 업무를 하시는 것 같다.
• http://jooyunghan.da.to/blog/ 
  : Agile과 Testing 쪽으로 업무를 하신다. 회사는 ^^
• http://alones.kr/blog
  : 테스팅 관련 업무를 한다. ^^;
• http://testcrunch.kr
  : 아직 활성되지 못한 테스팅 팀 블로그이다. (못난 관리자 때문이다. ㅡㅡ;)
• http://techbard.tistory.com/
  : 지금은 네이버에 계신 신재문님의 블로그이다.

너무 많은 정보들을 필요한 정보만 뽑아 내기가 혼자서는 쉽지가 않죠. 저는 RSS 리더에 등록하고 제목으로 읽어야 하는 것을 결정하고 필요에 따라서 따로 정리를 합니다.
테스트 관련 정보들을 수집하는 것을 목표로 가벼운 포스팅해 봅니다. 테스트 관련 정보들을 주간 단위로 정리해서 포스팅하는 것도 생각했었는데 최근에 업무가 자주 바뀌다 보니 그러지도 못햇네요.  ㅡㅡ;

제임스 바흐가 최근에 한국에 와서 쾌속 소프트웨어 테스팅 교육을 하였습니다. 저는 참석하지 못했습니다만 최근에 회사 내에서 이야기가 나오는 것 같아 정리해 봅니다.

탐험적 테스팅이란?
테스트 설계와 실행이 함께 이루어지는 테스팅을 말합니다.

스무고개를 할 때 미리 스무개의 질문을 모두 정해놓고 답을 듣는 것이 아니고, 하나의 질문을 묻고 거기에 대한 답을 들은 다음, 거기에 기반해 다음 질문을 생각해 내고 하면서 피드백의 순환고리를 돌며 진행하는 것이죠. – 김창준

최근 회사 내에서 품질 개선의 방법으로 관심을 받고 있는 것 같습니다. Agile한 테스트 방법이라고도 알려져 있는 탐험(탐색)적 테스팅이 어떤 것인지는 아래 제임스 바흐의 “Becoming a Software Testing Expert” 강연 동영상을 참고하시기 바랍니다.
탐험적 테스트 관련 자료는 satisfice.com에서도 받으실 수 있다고 합니다.

탐험적 테스팅은 적은 비용으로 높은 효과를 낼 수 있다고합니다. 저는 비용에 관한 것은 측정?해 보지 않아 잘 모르지만 학습과 테스트에 대한 집중의 효과는 크다고 생각합니다.

반복을 통해서 테스트 프로세스를 지속적으로 개선하고 테스터가 테스트 작업 자체에 더 집중하도록 하는것이 탐험적 테스팅에서 정말 중요한 포인트 같습니다. - 황상철

저는 회사 내에서 탐험적 테스팅이 테스트 케이스 없이 테스트할 수 있는 것이라는 오해는 없었으면 좋겠습니다. 어디다 이야기 할 곳이 없어 이렇게 블로그에 정리해봅니다.

값싼 인력으로 탐험적 테스팅을 하면 효과있을꺼라고 착각하시는 테스트 매니저, 관리자, 경영자분들… 아니거든요? 함께 수반해야 하는 것들이 많거든요? 쫌… 공부 좀 합시다. 귀를 열어 놓으시던지요.

TestCrunch에 올라온  “테스트는 누가해야 하는가?”에 대한 트랙백을 위한 글 입니다.

Nikkei Electronics 2007년 4월 23일 자에 나온 “공들여 만드는 소프트웨어, 검증하기 쉬운 설계로“라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.

” 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!”
- 테스터

아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다.

“아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!”
- 생산담당자

생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.
생산을 고려해서 설계를하고 개발하라는 것입니다.

Application/Game 개발자분들은… 디자이너분들과 이런 이야기 자주 나누지 않습니까?

“이런 디자인/컨셉은 개발하기 힘들다… 당신들이 개발을 안해봐서 그런가 본데… 이건 너무 힘들어요…”
- 개발자

테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.
그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.

개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.
Test Driven Development 보다는 Design의 의미가 강하다고 생각됩니다.
TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.

“Clean code that works!"- Test Driven Devlopment 에서 Kent Bect

TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.
TDD의 궁극의 목적은 “Clean Code That Works”라고 봅니다.

테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

이론적인 것을 공부해야한다는 부담담 대신에 가볍게 그리고 테스트가 무엇이고 테스터는 어떻게 해야하는지에 대해서 간략하게 이해할 수 있는 책인 것 같습니다.

아래 제목만 보시고 흥미 있으시면 책을 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

근데 내 책은 어디갔지? 작년 신입 사원인가? 재작년 신입사원한테 빌려 준 것 같은데… ㅡㅡ;

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다. (가장 좋아하는 말…^^)
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

법칙 16 테스트는 응용 인식론이다.
법칙 17 인식론을 배우면 테스트를 잘 수행할 수 있다.
법칙 18 테스트는 인지심리학에 바탕을 둔다.
법칙 19 테스트는 당신의 머리 속에 있다.
법칙 20 테스트에는 원하는 결과와 실제 결과의 단순 비교가 아닌 추론이 필요하다.
법칙 21 기술적, 창조적, 비판적, 실질적 사고를 하는 사람이 뛰어난 테스터이다.
법칙 22 블랙박스 테스트는 알지 못함을 기반으로 테스트를 실행하는 방법이다.
법칙 23 테스터는 여행객 이상이다.
법칙 24 모든 테스트는 질문에 대한 대답을 찾는 과정이다.
법칙 25 모든 테스트는 모델을 기반으로 수행된다.
법칙 26 육감은 좋은 출발점이나 결론은 형편없다.
법칙 27 반드시 직접 테스트해보아야 한다.
법칙 28 답사에는 다양한 사고가 필요하다.
법칙 29 판독을 위하여 가정적 귀납법을 이용하라.
법칙 30 제품을 평가할 때 추측과 반박의 논리를 사용하라.
법칙 31 요구조건은 중요한 사람에게 품질과 조건이다.
법칙 32 회의, 추론, 참조를 통해 요구사항을 알아내라.
법칙 33 명시적인 명세서뿐만 아니라 암묵적인 명세서도 사용하라.
법칙 34 “동작한다”는 말은 사실 적절한 수준으로 특정 요구조건을 만족하는 것처럼 보인다라는 의미이다.
법칙 35 결국 우리가 가지는 모든 것은 제품에 대한 인상이다.
법칙 36 ‘테스트’와 ‘테스트하다’를 혼동하지 마라.
법칙 37 복잡한 제품을 테스트할 경우: 시도해보고 그만두기
법칙 38 테스트에 대한 아이디어를 신속하게 떠올리기 위하여 시행착오법을 사용하라.
법칙 39 편향성을 피할 수는 없지만 관리할 수는 있다.
법칙 40 자신이 멍청하다는 사실을 알고 있다면 실제로 멍청한 짓을 잘하지 않는다.
법칙 41 버그를 놓쳤을 때, 버그가 의외의 것이라서 놓쳤는지 아니면 단순히 전략의 자연스러운 결과였는지를 확인하라.
법칙 42 혼란스러움도 테스트 도구이다.
법칙 43 참신한 시각이 오류를 발견한다.
법칙 44 이해하지 못한 채 절차를 따라하지 마라.
법칙 45 테스트 절차를 작성할 때 “1287”을 피하라.
법칙 46 테스트 과정에서 중요한 성과 중 하나는 날로 나아져 가는 영리한 테스터이다.
법칙 47 다시 창안하지 못한다면 테스트를 자유로이 구사할 수 없다.

제3장 테스트 기법

법칙 48 테스트는 테스터, 범위, 잠재적 문제, 행위, 평가에 중점을 두는 기법들로 구분할 수 있다.
법칙 49 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
법칙 50 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
법칙 51 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
법칙 52 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
법칙 53 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
법칙 54 생각하는 방식에 따라 기법이 분류된다.

제4장 버그 보고

법칙 55 버그 보고서의 질이 곧 테스터의 능력을 말해준다.
법칙 56 버그를 보고해야 해당 버그가 고쳐진다.
법칙 57 버그 보고서를 효과적인 세일즈 도구로 만들어라.
법칙 58 버그 보고서는 당신을 대표하는 것이다.
법칙 59 시간을 들여서 버그 보고서의 가치를 높여라.
법칙 60 이해 당사자도 버그를 보고할 수 있다.
법칙 61 다른 사람이 작성한 버그 보고서를 옮겨 적을 때에는 조심하라.
법칙 62 품질 격차도 버그로 보고하라.
법칙 63 몇몇 이해 당사자들은 버그를 보고할 수 없다. 사람이다.
법칙 64 버그가 쟁점이 될 경우, 이 버그 때문에 영향을 받게 될 이해 당사자의 관심을 이끌어내라.
법칙 65 프로그래머의 성능을 모니터하기 위하여 버그 추적 시스템을 절대로 사용하지 마라.
법칙 66 테스터의 성능을 모니터하기 위하여 버그 추적 시스템을 사용하지 마라.
법칙 67 결함은 즉시 보고하라.
법칙 68 명백한 버그가 이미 보고되었을 것이라고 추측하지 마라.
법칙 69 설계 오류를 보고하라.
법칙 70 극단적으로 보이는 버그들이 보안상 잠재적인 취약점이 된다.
법칙 71 드문 경우를 드물게 만들어라.
법칙 72 사소한 버그일지라도 보고해서 고쳐야 할 가치를 가진다.
법칙 73 심각도와 우선순위의 차이를 명확히 이해하라.
법칙 74 실패는 오류의 현상이지, 오류 그 자체는 아니다.
법칙 75 따라하기 테스트를 통해 사소한 오류를 발견하라.
법칙 76 재현 불가능한 오류를 항상 보고하라: 이 오류는 시한폭탄이 될 수 있다.
법칙 77 재현되지 않는 버그도 재현된다.
법칙 78 버그 보고서의 처리 비용을 생각하라.
법칙 79 도구나 환경에 관한 버그는 특별히 취급하라.
법칙 80 프로토타입이나 초기의 개인적인 버전에 대한 버그는 보고하기 전에 물어보라.
법칙 81 버그 보고서를 중복 작성하면서 스스로 문제를 고칠 수도 있다.
법칙 82 모든 버그는 보고되어야 할 가치를 지니고 있다.
법칙 83 요약 부분은 버그 보고서에서 가장 중요한 부분이다.
법칙 84 버그를 과장하지 마라.
법칙 85 문제는 명확하게 보고하되, 해결하려고 하지 마라.
법칙 86 보고서의 어조를 조심하라.
법칙 87 지치거나 까다로운 사람조차도 쉽게 읽을 수 있도록 가독성이 뛰어난 보고서를 작성하라.
법칙 88 보고서 작성 기술을 향상시켜라.
법칙 89 적절한 경우에 시장/기술 지원 데이터를 사용하라.
법칙 90 각자 다른 사람의 버그 보고서를 검토하라.
법칙 91 보고서를 읽게 될 프로그래머를 만나보라.
법칙 92 버그를 프로그래머에게 보여주는 것이 가장 좋은 방법일 수도 있다.
법칙 93 프로그래머가 버그를 고쳤다고 말할 때, 여전히 버그가 있는지를 확인하라.
법칙 94 버그 수정은 바로바로 점검하라.
법칙 95 버그가 제대로 고쳐지지 않았다면 프로그래머와 함께 이야기를 나눠보라.
법칙 96 버그 보고서는 테스트에 의해 마감되어야 한다.
법칙 97 모든 버그를 수정해야 한다고 주장하지 마라.
법칙 98 보류된 버그가 사라지도록 내버려두지 마라.
법칙 99 테스트 관성이 버그 보류의 원인이 되어서는 안 된다.
법칙 100 버그 보류에 대해서는 바로 이의를 제기하라.
법칙 101 싸우기로 했다면 이겨라.

제5장 테스트 자동화

법칙 102 테스트에 드는 비용을 몇 푼 아끼기보다는 개발 프로세스의 속도를 높여라.
법칙 103 동일한 테스트를 반복하기보다는 더 넓은 범위를 테스트하라.
법칙 104 상황에 적절한 자동화 전략을 선택하라.
법칙 105 100% 자동화를 지시하지 마라.
법칙 106 테스트 도구는 전략이 아니다.
법칙 107 뒤죽박죽일 때에는 자동화를 하지 마라.
법칙 108 수동 테스트와 자동 테스트를 동일시하지 마라.
법칙 109 ‘얼마나 자주 실행하는가’라는 기준으로 테스트의 가치를 평가하지 마라.
법칙 110 자동화된 회귀 테스트를 통해 발견할 수 있는 버그의 개수는 적다.
법칙 111 테스트를 자동화할 때에는 발견하지 못하는 버그가 무엇인지를 고려하라.
법칙 112 잘못된 자동화의 문제점은 아무도 알아차리지 못한다는 사실이다.
법칙 113 반복 오류를 잡아라.
법칙 114 테스트 도구도 버그가 있다.
법칙 115 사용자 인터페이스는 변경된다.
법칙 116 호환성, 친밀성, 서비스에 따라 GUI 테스트 도구를 선택하라.
법칙 117 자동화된 회귀 테스트들은 사라진다.
법칙 118 테스트 자동화는 소프트웨어 개발 프로세스이다.
법칙 119 테스트 자동화는 중요한 투자이다.
법칙 120 테스트 자동화 프로젝트에는 프로그래밍, 테스트, 프로젝트 관리에 관한 기술이 필요하다.
법칙 121 파일럿 프로젝트를 통해 실행 가능성을 증명하라.
법칙 122 테스터와 프로그래머에게 자동화된 프로젝트에 대한 특권을 부여하라.
법칙 123 재검토가 용이하도록 자동화된 테스트를 설계하라.
법칙 124 자동화된 테스트를 허술하게 설계하지 마라.
법칙 125 테스트 스크립트에 복잡한 논리를 넣지 마라.
법칙 126 단순히 코드를 반복하지 않기 위하여 테스트 라이브러리를 만들지 마라.
법칙 127 데이터 중심 테스트 자동화는 많은 변종 테스트의 실행을 용이하게 도와준다.
법칙 128 키워드 중심 테스트 자동화는 프로그래머가 아닌 사람이 테스트를 쉽게 생성할 수 있도록 도와준다.
법칙 129 자동화 기법을 사용하여 테스트 입력을 생성하라.
법칙 130 테스트 생성과 테스트 실행을 구분하라.
법칙 131 표준 스크립트 언어를 사용하라.
법칙 132 프로그래밍 인터페이스를 사용하여 테스트를 자동화하라.
법칙 133 유닛 테스트 스위트를 개발하라.
법칙 134 테스트를 이해하지 못하는 사람에게 자동화를 맡기지 마라.
법칙 135 테스트를 존중하지 않는 자동화 담당자는 피하라.
법칙 136 테스트 용이성이 자동화보다 훨씬 더 나은 투자인 경우가 자주 있다.
법칙 137 테스트 용이성이란 가시성과 제어성을 의미한다.
법칙 138 초기에 테스트 자동화를 시작하라.
법칙 139 중앙 집중화된 팀에게 분명한 권한을 부여하라.
법칙 140 바로 효과를 볼 수 있는 것부터 자동화하라.
법칙 141 흔히들 알고 있는 것보다 훨씬 많은 테스트 도구들이 존재한다.

제6장 테스트 문서화

법칙 142 솔루션을 효과적으로 적용하려면 문제를 명확히 이해해야 한다.
법칙 143 테스트 문서 템플릿을 사용하지 마라: 템플릿이 필요하지 않다면 무용지물에 불과하다.
법칙 144 테스트 문서 템플릿을 사용하라: 템플릿은 일관성 있는 의사전달을 촉진시킨다.
법칙 145 IEEE 829 표준안을 사용하여 테스트 문서를 작성하라.
법칙 146 IEEE 829 표준안을 사용하지 마라.
법칙 147 요구조건을 분석한 다음 어떤 제품을 만들지 결정하라: 이 말은 소프트웨어와 마찬가지로 문서화에도 적용된다.
법칙 148 테스트 문서 요구조건을 분석하기 위하여 다음 사항을 물어보라.
법칙 149 핵심적인 문서 요구사항을 세 부분 이하로 한 문장씩 요약하라.

제7장 프로그래머와의 상호관계

법칙 150 프로그래머들의 사고방식을 이해하라.
법칙 151 프로그래머와 신뢰를 쌓아라.
법칙 152 서비스를 제공하라.
법칙 153 성실하고 능력을 갖추어야 존중을 받게 된다.
법칙 154 사람이 아닌 작업에 집중하라.
법칙 155 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라.
법칙 156 프로그래머는 테스트를 도와주고 싶어한다.

제8장 테스트 프로젝트 관리

법칙 157 서비스 문화를 만들어라.
법칙 158 통제 문화를 만들지 마라.
법칙 159 임금님 귀(?)처럼 다양한 의견을 들어라.
법칙 160 개발 프로젝트가 아니라 테스트 서비스를 제공하는 하위 프로젝트를 관리하는 것이다.
법칙 161 모든 프로젝트는 진화한다. 잘 진행된 프로젝트는 진화도 잘한다.
법칙 162 항상 뒤늦은 변경사항이 존재한다.
법칙 163 프로젝트에는 기능, 신뢰성, 시간, 돈 사이의 트레이드오프가 존재한다.
법칙 164 프로젝트 관리자가 프로젝트의 수명주기를 선택하도록 하라.
법칙 165 폭포수 수명주기 모델은 시간에 대한 신뢰성이 부족하다.
법칙 166 진화 수명주기 모델은 시간에 대한 기능이 부족하다.
법칙 167 개발 초기에 프로젝트에 대한 자원을 할당하라.
법칙 168 계약에 따른 개발과 시장에 대한 개발은 다르다.
법칙 169 테스터 용이성 기능을 요구하라.
법칙 170 빌드에 대한 일정을 협의하라.
법칙 171 빌드를 전달하기 전에 프로그래머가 한 일(그리고 하지 않은 일)을 이해하라.
법칙 172 빌드를 준비하라.
법칙 173 때로는 빌드에 대한 테스트를 거부해야 한다.
법칙 174 빌드를 평가하기 위하여 연기 테스트를 사용하라.
법칙 175 때로는 테스트를 멈추고, 개발 주기를 수정한 다음 소프트웨어를 다시 설계하는 것이 올바른 결정이다.
법칙 176 실제로 사용되는 개발 사례에 프로세스를 적용하라.
법칙 177 프로젝트 문서는 재미있는 소설이다: 유용하지만 충분하지는 않다. – Brian Marick
법칙 178 사용하지 않을 항목은 요청하지 마라.
법칙 179 다른 정보 출처도 이용하라.
법칙 180 프로젝트 관리자에게 구성 관리 문제점을 보고하라.
법칙 181 프로그래머는 태풍과 같다.
법칙 182 테스트 계획을 잘 세우면 뒤늦게 변경하기도 쉽다.
법칙 183 인위적인 결과물을 다른 사람에게 전달할 때마다 테스트를 수행해야 한다.
법칙 184 충분히 많은 테스트를 수행했음을 판단하는 공식은 존재하지 않는다.
법칙 185 충분한 테스트란 고객이 좋은 판단을 내릴 수 있도록 충분한 정보를 제공한다는 의미이다.
법칙 186 단순히 테스트를 두 번 수행하기 위한 예산을 책정하지 마라.
법칙 187 작업에 대한 일정 계획을 세울 때 각 작업에 필요한 소요시간을 평가하라.
법칙 188 작업을 담당할 사람이 직접 소요시간을 이야기하도록 하라.
법칙 189 테스터와 다른 개발자 사이의 적절한 비율은 없다.
법칙 190 작업에 실패하였다면 담당 작업을 서로 바꾸거나 사람을 교체하라.
법칙 191 테스터를 기능별로 순환시켜라.
법칙 192 짝을 이뤄 테스트를 하라.
법칙 193 프로젝트에 버그 헌터를 지명하라.
법칙 194 테스트 세션, 특히 답사 방식의 테스트 세션을 계획하라.
법칙 195 테스트를 세션 단위로 수행하라.
법칙 196 테스터의 작업을 방해하는 중단요소를 밝히기 위하여 행동 기록을 사용하라.
법칙 197 정기 상태 보고서는 강력한 도구이다.
법칙 198 부사장이 통계 데이터를 가지는 경우가 가장 위험하다.
법칙 199 버그 개수라는 관점에서 프로젝트의 진척도를 측정하지 않도록 주의하라.
법칙 200 더 많은 독립 기준을 사용할수록 더 많은 것을 알게 된다.
법칙 201 다차원 상태를 보고하기 위하여 균형 잡힌 점수 카드를 사용하라.
법칙 202 주간 상태 보고서는 다음과 같이 작성하라.
법칙 203 프로젝트 상황판은 현재 상태를 알려주는 또다른 유용한 방법이다.
법칙 204 마일스톤(milestone)이 잘 정의되어있다면 마일스톤 보고서가 유용하다.
법칙 205 제품 출시에 찬성한다는 서명을 하지 마라.
법칙 206 만족할 정도로 테스트를 해본 제품에 대해서만 서명하라.
법칙 207 출시 보고서에는 제품에 대한 자신의 의견이 아니라 테스트 작업 결과에 대해 적어야 한다.
법칙 208 최종 출시 보고서에는 수정되지 않은 버그의 목록도 함께 적어두라.
법칙 209 유익한 출시 보고서에는 10가지 단점이 들어있어야 한다.

제9장 테스트 그룹 관리

법칙 210 개성이 사라지면 직장이 무기력해진다.
법칙 211 팀을 경영진처럼 대하라.
법칙 212 팀원들이 작성한 버그 보고서를 읽어라.
법칙 213 경영자의 입장에서 팀을 평가하라.
법칙 214 어떻게 진행되고 있는지 정말 알고싶다면 팀원과 함께 테스트를 수행하라.
법칙 215 여러 개의 프로젝트를 효율적으로 담당하도록 요구하지 마라.
법칙 216 테스트팀의 영역 전문 지식을 만들어라.
법칙 217 테스트 팀원을 관련 기술 전문가로 만들어라.
법칙 218 기술을 적극적으로 개발하라.
법칙 219 기술 지원 기록을 재검토하라.
법칙 220 새로운 테스터가 성공하도록 도와주어라.
법칙 221 새로운 테스터에게는 소프트웨어에 대한 문서를 점검하도록 하라.
법칙 222 새로운 테스터가 제품에 익숙해지도록 긍정적 테스트를 수행하라.
법칙 223 초보 테스터에게는 새로운 버그 보고서를 작성하기 전에 예전 버그 보고서를 수정하도록 하라.
법칙 224 새로운 테스터가 새로운 버그를 테스트하기 전에 예전 버그를 다시 테스트하도록 하라.
법칙 225 초보 테스터에게 거의 종료된 프로젝트를 맡기지 마라.
법칙 226 팀원의 의욕은 중요한 자산이다.
법칙 227 자신을 혹사시키지 마라.
법칙 228 팀원들을 초과 근무로 혹사시키지 마라.
법칙 229 팀원들을 대우해 주어라.
법칙 230 교육 기회를 만들어라.
법칙 231 당신이 내리는 채용 결정은 가장 중요한 판단이다.
법칙 232 채용 기간동안 숨쉴 여유를 제공하는 외주업체를 사용하라.
법칙 233 다른 그룹에서 거절된 사람을 테스트팀에 받아들이지 마라.
법칙 234 그룹에서 해야 하는 업무와 그 업무를 수행하는 데 필요한 기술의 관점에서 계획을 수립하라.
법칙 235 다양한 배경 지식을 가진 사람들로 테스트팀을 구성하라.
법칙 236 기회가 닿은 지원자를 채용하라.
법칙 237 교감에 의해 채용하라.
법칙 238 자신의 업무를 좋아하는 사람을 채용하라.
법칙 239 성실한 사람을 채용하라.
법칙 240 면접시 당신이 왜 그를 테스터로 채용해야 하는지, 테스터에게 그를 채용해야만 하는 고유한 기술을 보여달라고 하라.
법칙 241 면접시 비공식 적성 테스트의 한 방법으로 직장에서 실제로 사용할 기술을 보여달라고 요청하라.
법칙 242 채용시 작업 예제를 요구하라.
법칙 243 마음먹었다면 바로 채용하라.
법칙 244 채용 약속을 서면으로 받아서 잘 보관하라.

제10장 소프트웨어 테스트 분야에서의 경력 관리

법칙 245 진로를 선택하고, 그 방향에 매진하라.
법칙 246 테스터의 연봉이 프로그래머의 연봉보다 많을 수 있다.
법칙 247 진로 변경을 편안하게 느끼고, 다른 직종을 추구하라.
법칙 248 어떤 진로를 택하든지 적극적으로 추구하라.
법칙 249 경력을 소프트웨어 테스팅 이외의 영역까지 확장하라.
법칙 250 현재의 회사를 벗어나는 경력을 확장하라.
법칙 251 컨퍼런스는 이야기를 나누기 위한 것이다.
법칙 252 다른 많은 회사들도 지금 회사와 별반 차이가 없다.
법칙 253 현 직장이 마음에 들지 않는다면 다른 직장을 찾아보아라.
법칙 254 현 직장에서 승부를 걸어야 할(그리고 잃을) 경우에 대비하라.
법칙 255 일하고 싶은 회사의 목록을 작성하여 관리하라.
법칙 256 포트폴리오를 작성하라.
법칙 257 이력서를 세일즈 도구로 사용하라.
법칙 258 내부 추천제도를 이용하라.
법칙 259 급여 데이터를 알아보라.
법칙 260 구직 광고를 보고 지원하는 것이라면, 광고 내용에 대한 답변을 준비하라.
법칙 261 인터뷰 기회를 이용하라.
법칙 262 마음에 드는 회사라면 그 회사에 대한 정보를 습득하라.
법칙 263 직장 인터뷰 중 질문을 하라.
법칙 264 직급을 협상하라.
법칙 265 인사부에 대해 조심하라.
법칙 266 펄(Perl)을 배워라.
법칙 267 자바나 C++를 배워라.
법칙 268 테스트 도구의 데모 버전을 다운로드 받아서 사용해보라.
법칙 269 글 쓰기 능력을 향상시켜라.
법칙 270 대중 앞에서 말하는 기술을 향상시켜라.
법칙 271 자격증을 취득하는 것도 고려하라.
법칙 272 단 2주만에 검은 띠를 딸 수 있다면, 싸움을 피하라.
법칙 273 CSTE 자격증을 취득하라.

제11장 테스트 전략 계획

법칙 274 테스트 전략에 대한 세 가지 기본 질문은 쓰는가?, 얼마나 많이?이다.
법칙 275 가능한 테스트 전략은 매우 많다.
법칙 276 테스트 계획은 실제 테스트 프로세스를 이끌어줄 아이디어의 모음이다.
법칙 277 자신의 상황에 적절한 테스트 계획을 수립하라.
법칙 278 전략, 지원 방안, 그리고 작업 결과물에 대한 결정을 알 수 있는 테스트 계획을 수립하라.
법칙 279 지원 방안과 작업 결과로 인해 전략이 가려지지 않도록 하라.
법칙 280 테스트 사례에 대한 거짓말
법칙 281 테스트 전략은 테스트보다 더 큰 것이다.
법칙 282 테스트 전략은 테스트를 설명한다.
법칙 283 다양한 임시 방법을 적용하라.
법칙 284 강력한 테스트 전략의 원 재료를 만들어라.
법칙 285 프로젝트에 대한 첫 번째 전략은 항상 잘못된 전략이다.
법칙 286 프로젝트의 각 단계마다 스스로에게 “현재 무엇을 테스트할 수 있으며, 어떻게 테스트할 수 있는가?”라는 질문을 던져보라.
법칙 287 프로젝트의 성숙도에 따라 테스트를 진행하라.
법칙 288 테스트 복잡성에 대한 논의를 단순화하기 위하여 테스트 수준을 사용하라.
법칙 289 그레이박스를 테스트하라.
법칙 290 이전 테스트 자료를 다시 사용할 경우 무조건적 신뢰는 위험하다.
법칙 291 두 명의 테스터가 동일한 것을 테스트한다고 해서 중복된 노력을 들이고 있는 것은 아니다.
법칙 292 제품의 위험요소 뿐만 아니라 프로젝트의 요소들에 대한 테스트 전략을 수립하라.
법칙 293 테스트 주기를 테스트 프로세스의 심장박동처럼 취급하라.

팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.

이론적인 것을 공부해야한다는 부담담 대신에 가볍게 그리고 테스트가 무엇이고 테스터는 어떻게 해야하는지에 대해서 간략하게 이해할 수 있는 책인 것 같습니다.

아래 제목만 보시고 흥미 있으시면 읽어 보시고 아니면 그정도는 아니다 싶으시면 dejavu_blog에 추가로 요약된 글을 보시면 좋을 것 같습니다.

제1장 테스터의 역할

법칙 1 테스터는 프로젝트의 전조등이다.
법칙 2 임무에 따라 행동이 결정된다.
법칙 3 테스터는 많은 고객들에게 서비스를 제공한다.
법칙 4 고객이 가치 있다고 생각하는 “버그”를 발견하라.
법칙 5 중요한 버그를 신속하게 찾아내라.
법칙 6 프로그래머와 함께 진행하라.법칙 7 모든 것에 의문을 가져라. 그러나 밖으로 크게 드러내지는 마라.
법칙 8 테스터가 실패에 초점을 맞추면 고객은 성공에 초점을 맞출 수 있다.
법칙 9 모든 버그를 찾아낼 수는 없다.
법칙 10 “완전히” 테스트한다는 말을 조심하라.
법칙 11 테스트를 통해서 품질을 보장할 수는 없다.
법칙 12 문지기가 되지는 마라!
법칙 13 테스트에서 “내 업무가 아니야”의 논리를 조심하라.
법칙 14 프로세스 개선 그룹이 되는 것을 조심하라.
법칙 15 테스트를 잘 수행하기 위하여 필요한 항목들을 모든 사람들이 이해할 것이라고 기대하지 마라.

제2장 테스터의 사고방식

법칙 16 테스트는 응용 인식론이다.
법칙 17 인식론을 배우면 테스트를 잘 수행할 수 있다.
법칙 18 테스트는 인지심리학에 바탕을 둔다.
법칙 19 테스트는 당신의 머리 속에 있다.
법칙 20 테스트에는 원하는 결과와 실제 결과의 단순 비교가 아닌 추론이 필요하다.
법칙 21 기술적, 창조적, 비판적, 실질적 사고를 하는 사람이 뛰어난 테스터이다.
법칙 22 블랙박스 테스트는 알지 못함을 기반으로 테스트를 실행하는 방법이다.
법칙 23 테스터는 여행객 이상이다.
법칙 24 모든 테스트는 질문에 대한 대답을 찾는 과정이다.
법칙 25 모든 테스트는 모델을 기반으로 수행된다.
법칙 26 육감은 좋은 출발점이나 결론은 형편없다.
법칙 27 반드시 직접 테스트해보아야 한다.
법칙 28 답사에는 다양한 사고가 필요하다.
법칙 29 판독을 위하여 가정적 귀납법을 이용하라.
법칙 30 제품을 평가할 때 추측과 반박의 논리를 사용하라.
법칙 31 요구조건은 중요한 사람에게 품질과 조건이다.
법칙 32 회의, 추론, 참조를 통해 요구사항을 알아내라.
법칙 33 명시적인 명세서뿐만 아니라 암묵적인 명세서도 사용하라.
법칙 34 “동작한다”는 말은 사실 적절한 수준으로 특정 요구조건을 만족하는 것처럼 보인다라는 의미이다.
법칙 35 결국 우리가 가지는 모든 것은 제품에 대한 인상이다.
법칙 36 ‘테스트’와 ‘테스트하다’를 혼동하지 마라.
법칙 37 복잡한 제품을 테스트할 경우: 시도해보고 그만두기
법칙 38 테스트에 대한 아이디어를 신속하게 떠올리기 위하여 시행착오법을 사용하라.
법칙 39 편향성을 피할 수는 없지만 관리할 수는 있다.
법칙 40 자신이 멍청하다는 사실을 알고 있다면 실제로 멍청한 짓을 잘하지 않는다.
법칙 41 버그를 놓쳤을 때, 버그가 의외의 것이라서 놓쳤는지 아니면 단순히 전략의 자연스러운 결과였는지를 확인하라.
법칙 42 혼란스러움도 테스트 도구이다.
법칙 43 참신한 시각이 오류를 발견한다.
법칙 44 이해하지 못한 채 절차를 따라하지 마라.
법칙 45 테스트 절차를 작성할 때 “1287”을 피하라.
법칙 46 테스트 과정에서 중요한 성과 중 하나는 날로 나아져 가는 영리한 테스터이다.
법칙 47 다시 창안하지 못한다면 테스트를 자유로이 구사할 수 없다.

제3장 테스트 기법

법칙 48 테스트는 테스터, 범위, 잠재적 문제, 행위, 평가에 중점을 두는 기법들로 구분할 수 있다.
법칙 49 누가 테스트를 수행하는가에 중점을 둔 사람 중심 기법
법칙 50 무엇을 테스트하는가에 중점을 두는 범위 기반 기법
법칙 51 왜 테스트를 하는가(테스트에 대한 위험)에 중점을 둔 문제 중심 기법
법칙 52 어떻게 테스트를 수행하는가에 중점을 둔 행위 기반 기법
법칙 53 테스트를 통과했는지의 여부를 어떻게 알 것인가에 중점을 두는 평가 기반 기법
법칙 54 생각하는 방식에 따라 기법이 분류된다.

제4장 버그 보고

법칙 55 버그 보고서의 질이 곧 테스터의 능력을 말해준다.
법칙 56 버그를 보고해야 해당 버그가 고쳐진다.
법칙 57 버그 보고서를 효과적인 세일즈 도구로 만들어라.
법칙 58 버그 보고서는 당신을 대표하는 것이다.
법칙 59 시간을 들여서 버그 보고서의 가치를 높여라.
법칙 60 이해 당사자도 버그를 보고할 수 있다.
법칙 61 다른 사람이 작성한 버그 보고서를 옮겨 적을 때에는 조심하라.
법칙 62 품질 격차도 버그로 보고하라.
법칙 63 몇몇 이해 당사자들은 버그를 보고할 수 없다. 사람이다.
법칙 64 버그가 쟁점이 될 경우, 이 버그 때문에 영향을 받게 될 이해 당사자의 관심을 이끌어내라.
법칙 65 프로그래머의 성능을 모니터하기 위하여 버그 추적 시스템을 절대로 사용하지 마라.
법칙 66 테스터의 성능을 모니터하기 위하여 버그 추적 시스템을 사용하지 마라.
법칙 67 결함은 즉시 보고하라.
법칙 68 명백한 버그가 이미 보고되었을 것이라고 추측하지 마라.
법칙 69 설계 오류를 보고하라.
법칙 70 극단적으로 보이는 버그들이 보안상 잠재적인 취약점이 된다.
법칙 71 드문 경우를 드물게 만들어라.
법칙 72 사소한 버그일지라도 보고해서 고쳐야 할 가치를 가진다.
법칙 73 심각도와 우선순위의 차이를 명확히 이해하라.
법칙 74 실패는 오류의 현상이지, 오류 그 자체는 아니다.
법칙 75 따라하기 테스트를 통해 사소한 오류를 발견하라.
법칙 76 재현 불가능한 오류를 항상 보고하라: 이 오류는 시한폭탄이 될 수 있다.
법칙 77 재현되지 않는 버그도 재현된다.
법칙 78 버그 보고서의 처리 비용을 생각하라.
법칙 79 도구나 환경에 관한 버그는 특별히 취급하라.
법칙 80 프로토타입이나 초기의 개인적인 버전에 대한 버그는 보고하기 전에 물어보라.
법칙 81 버그 보고서를 중복 작성하면서 스스로 문제를 고칠 수도 있다.
법칙 82 모든 버그는 보고되어야 할 가치를 지니고 있다.
법칙 83 요약 부분은 버그 보고서에서 가장 중요한 부분이다.
법칙 84 버그를 과장하지 마라.
법칙 85 문제는 명확하게 보고하되, 해결하려고 하지 마라.
법칙 86 보고서의 어조를 조심하라.
법칙 87 지치거나 까다로운 사람조차도 쉽게 읽을 수 있도록 가독성이 뛰어난 보고서를 작성하라.
법칙 88 보고서 작성 기술을 향상시켜라.
법칙 89 적절한 경우에 시장/기술 지원 데이터를 사용하라.
법칙 90 각자 다른 사람의 버그 보고서를 검토하라.
법칙 91 보고서를 읽게 될 프로그래머를 만나보라.
법칙 92 버그를 프로그래머에게 보여주는 것이 가장 좋은 방법일 수도 있다.
법칙 93 프로그래머가 버그를 고쳤다고 말할 때, 여전히 버그가 있는지를 확인하라.
법칙 94 버그 수정은 바로바로 점검하라.
법칙 95 버그가 제대로 고쳐지지 않았다면 프로그래머와 함께 이야기를 나눠보라.
법칙 96 버그 보고서는 테스트에 의해 마감되어야 한다.
법칙 97 모든 버그를 수정해야 한다고 주장하지 마라.
법칙 98 보류된 버그가 사라지도록 내버려두지 마라.
법칙 99 테스트 관성이 버그 보류의 원인이 되어서는 안 된다.
법칙 100 버그 보류에 대해서는 바로 이의를 제기하라.
법칙 101 싸우기로 했다면 이겨라.

제5장 테스트 자동화

법칙 102 테스트에 드는 비용을 몇 푼 아끼기보다는 개발 프로세스의 속도를 높여라.
법칙 103 동일한 테스트를 반복하기보다는 더 넓은 범위를 테스트하라.
법칙 104 상황에 적절한 자동화 전략을 선택하라.
법칙 105 100% 자동화를 지시하지 마라.
법칙 106 테스트 도구는 전략이 아니다.
법칙 107 뒤죽박죽일 때에는 자동화를 하지 마라.
법칙 108 수동 테스트와 자동 테스트를 동일시하지 마라.
법칙 109 ‘얼마나 자주 실행하는가’라는 기준으로 테스트의 가치를 평가하지 마라.
법칙 110 자동화된 회귀 테스트를 통해 발견할 수 있는 버그의 개수는 적다.
법칙 111 테스트를 자동화할 때에는 발견하지 못하는 버그가 무엇인지를 고려하라.
법칙 112 잘못된 자동화의 문제점은 아무도 알아차리지 못한다는 사실이다.
법칙 113 반복 오류를 잡아라.
법칙 114 테스트 도구도 버그가 있다.
법칙 115 사용자 인터페이스는 변경된다.
법칙 116 호환성, 친밀성, 서비스에 따라 GUI 테스트 도구를 선택하라.
법칙 117 자동화된 회귀 테스트들은 사라진다.
법칙 118 테스트 자동화는 소프트웨어 개발 프로세스이다.
법칙 119 테스트 자동화는 중요한 투자이다.
법칙 120 테스트 자동화 프로젝트에는 프로그래밍, 테스트, 프로젝트 관리에 관한 기술이 필요하다.
법칙 121 파일럿 프로젝트를 통해 실행 가능성을 증명하라.
법칙 122 테스터와 프로그래머에게 자동화된 프로젝트에 대한 특권을 부여하라.
법칙 123 재검토가 용이하도록 자동화된 테스트를 설계하라.
법칙 124 자동화된 테스트를 허술하게 설계하지 마라.
법칙 125 테스트 스크립트에 복잡한 논리를 넣지 마라.
법칙 126 단순히 코드를 반복하지 않기 위하여 테스트 라이브러리를 만들지 마라.
법칙 127 데이터 중심 테스트 자동화는 많은 변종 테스트의 실행을 용이하게 도와준다.
법칙 128 키워드 중심 테스트 자동화는 프로그래머가 아닌 사람이 테스트를 쉽게 생성할 수 있도록 도와준다.
법칙 129 자동화 기법을 사용하여 테스트 입력을 생성하라.
법칙 130 테스트 생성과 테스트 실행을 구분하라.
법칙 131 표준 스크립트 언어를 사용하라.
법칙 132 프로그래밍 인터페이스를 사용하여 테스트를 자동화하라.
법칙 133 유닛 테스트 스위트를 개발하라.
법칙 134 테스트를 이해하지 못하는 사람에게 자동화를 맡기지 마라.
법칙 135 테스트를 존중하지 않는 자동화 담당자는 피하라.
법칙 136 테스트 용이성이 자동화보다 훨씬 더 나은 투자인 경우가 자주 있다.
법칙 137 테스트 용이성이란 가시성과 제어성을 의미한다.
법칙 138 초기에 테스트 자동화를 시작하라.
법칙 139 중앙 집중화된 팀에게 분명한 권한을 부여하라.
법칙 140 바로 효과를 볼 수 있는 것부터 자동화하라.
법칙 141 흔히들 알고 있는 것보다 훨씬 많은 테스트 도구들이 존재한다.

제6장 테스트 문서화

법칙 142 솔루션을 효과적으로 적용하려면 문제를 명확히 이해해야 한다.
법칙 143 테스트 문서 템플릿을 사용하지 마라: 템플릿이 필요하지 않다면 무용지물에 불과하다.
법칙 144 테스트 문서 템플릿을 사용하라: 템플릿은 일관성 있는 의사전달을 촉진시킨다.
법칙 145 IEEE 829 표준안을 사용하여 테스트 문서를 작성하라.
법칙 146 IEEE 829 표준안을 사용하지 마라.
법칙 147 요구조건을 분석한 다음 어떤 제품을 만들지 결정하라: 이 말은 소프트웨어와 마찬가지로 문서화에도 적용된다.
법칙 148 테스트 문서 요구조건을 분석하기 위하여 다음 사항을 물어보라.
법칙 149 핵심적인 문서 요구사항을 세 부분 이하로 한 문장씩 요약하라.

제7장 프로그래머와의 상호관계

법칙 150 프로그래머들의 사고방식을 이해하라.
법칙 151 프로그래머와 신뢰를 쌓아라.
법칙 152 서비스를 제공하라.
법칙 153 성실하고 능력을 갖추어야 존중을 받게 된다.
법칙 154 사람이 아닌 작업에 집중하라.
법칙 155 프로그래머들은 자신의 일에 대해 이야기하는 것을 좋아한다. 궁금한 점이 있으면 직접 물어보라.
법칙 156 프로그래머는 테스트를 도와주고 싶어한다.

제8장 테스트 프로젝트 관리

법칙 157 서비스 문화를 만들어라.
법칙 158 통제 문화를 만들지 마라.
법칙 159 임금님 귀(?)처럼 다양한 의견을 들어라.
법칙 160 개발 프로젝트가 아니라 테스트 서비스를 제공하는 하위 프로젝트를 관리하는 것이다.
법칙 161 모든 프로젝트는 진화한다. 잘 진행된 프로젝트는 진화도 잘한다.
법칙 162 항상 뒤늦은 변경사항이 존재한다.
법칙 163 프로젝트에는 기능, 신뢰성, 시간, 돈 사이의 트레이드오프가 존재한다.
법칙 164 프로젝트 관리자가 프로젝트의 수명주기를 선택하도록 하라.
법칙 165 폭포수 수명주기 모델은 시간에 대한 신뢰성이 부족하다.
법칙 166 진화 수명주기 모델은 시간에 대한 기능이 부족하다.
법칙 167 개발 초기에 프로젝트에 대한 자원을 할당하라.
법칙 168 계약에 따른 개발과 시장에 대한 개발은 다르다.
법칙 169 테스터 용이성 기능을 요구하라.
법칙 170 빌드에 대한 일정을 협의하라.
법칙 171 빌드를 전달하기 전에 프로그래머가 한 일(그리고 하지 않은 일)을 이해하라.
법칙 172 빌드를 준비하라.
법칙 173 때로는 빌드에 대한 테스트를 거부해야 한다.
법칙 174 빌드를 평가하기 위하여 연기 테스트를 사용하라.
법칙 175 때로는 테스트를 멈추고, 개발 주기를 수정한 다음 소프트웨어를 다시 설계하는 것이 올바른 결정이다.
법칙 176 실제로 사용되는 개발 사례에 프로세스를 적용하라.
법칙 177 프로젝트 문서는 재미있는 소설이다: 유용하지만 충분하지는 않다. – Brian Marick
법칙 178 사용하지 않을 항목은 요청하지 마라.
법칙 179 다른 정보 출처도 이용하라.
법칙 180 프로젝트 관리자에게 구성 관리 문제점을 보고하라.
법칙 181 프로그래머는 태풍과 같다.
법칙 182 테스트 계획을 잘 세우면 뒤늦게 변경하기도 쉽다.
법칙 183 인위적인 결과물을 다른 사람에게 전달할 때마다 테스트를 수행해야 한다.
법칙 184 충분히 많은 테스트를 수행했음을 판단하는 공식은 존재하지 않는다.
법칙 185 충분한 테스트란 고객이 좋은 판단을 내릴 수 있도록 충분한 정보를 제공한다는 의미이다.
법칙 186 단순히 테스트를 두 번 수행하기 위한 예산을 책정하지 마라.
법칙 187 작업에 대한 일정 계획을 세울 때 각 작업에 필요한 소요시간을 평가하라.
법칙 188 작업을 담당할 사람이 직접 소요시간을 이야기하도록 하라.
법칙 189 테스터와 다른 개발자 사이의 적절한 비율은 없다.
법칙 190 작업에 실패하였다면 담당 작업을 서로 바꾸거나 사람을 교체하라.
법칙 191 테스터를 기능별로 순환시켜라.
법칙 192 짝을 이뤄 테스트를 하라.
법칙 193 프로젝트에 버그 헌터를 지명하라.
법칙 194 테스트 세션, 특히 답사 방식의 테스트 세션을 계획하라.
법칙 195 테스트를 세션 단위로 수행하라.
법칙 196 테스터의 작업을 방해하는 중단요소를 밝히기 위하여 행동 기록을 사용하라.
법칙 197 정기 상태 보고서는 강력한 도구이다.
법칙 198 부사장이 통계 데이터를 가지는 경우가 가장 위험하다.
법칙 199 버그 개수라는 관점에서 프로젝트의 진척도를 측정하지 않도록 주의하라.
법칙 200 더 많은 독립 기준을 사용할수록 더 많은 것을 알게 된다.
법칙 201 다차원 상태를 보고하기 위하여 균형 잡힌 점수 카드를 사용하라.
법칙 202 주간 상태 보고서는 다음과 같이 작성하라.
법칙 203 프로젝트 상황판은 현재 상태를 알려주는 또다른 유용한 방법이다.
법칙 204 마일스톤(milestone)이 잘 정의되어있다면 마일스톤 보고서가 유용하다.
법칙 205 제품 출시에 찬성한다는 서명을 하지 마라.
법칙 206 만족할 정도로 테스트를 해본 제품에 대해서만 서명하라.
법칙 207 출시 보고서에는 제품에 대한 자신의 의견이 아니라 테스트 작업 결과에 대해 적어야 한다.
법칙 208 최종 출시 보고서에는 수정되지 않은 버그의 목록도 함께 적어두라.
법칙 209 유익한 출시 보고서에는 10가지 단점이 들어있어야 한다.

제9장 테스트 그룹 관리

법칙 210 개성이 사라지면 직장이 무기력해진다.
법칙 211 팀을 경영진처럼 대하라.
법칙 212 팀원들이 작성한 버그 보고서를 읽어라.
법칙 213 경영자의 입장에서 팀을 평가하라.
법칙 214 어떻게 진행되고 있는지 정말 알고싶다면 팀원과 함께 테스트를 수행하라.
법칙 215 여러 개의 프로젝트를 효율적으로 담당하도록 요구하지 마라.
법칙 216 테스트팀의 영역 전문 지식을 만들어라.
법칙 217 테스트 팀원을 관련 기술 전문가로 만들어라.
법칙 218 기술을 적극적으로 개발하라.
법칙 219 기술 지원 기록을 재검토하라.
법칙 220 새로운 테스터가 성공하도록 도와주어라.
법칙 221 새로운 테스터에게는 소프트웨어에 대한 문서를 점검하도록 하라.
법칙 222 새로운 테스터가 제품에 익숙해지도록 긍정적 테스트를 수행하라.
법칙 223 초보 테스터에게는 새로운 버그 보고서를 작성하기 전에 예전 버그 보고서를 수정하도록 하라.
법칙 224 새로운 테스터가 새로운 버그를 테스트하기 전에 예전 버그를 다시 테스트하도록 하라.
법칙 225 초보 테스터에게 거의 종료된 프로젝트를 맡기지 마라.
법칙 226 팀원의 의욕은 중요한 자산이다.
법칙 227 자신을 혹사시키지 마라.
법칙 228 팀원들을 초과 근무로 혹사시키지 마라.
법칙 229 팀원들을 대우해 주어라.
법칙 230 교육 기회를 만들어라.
법칙 231 당신이 내리는 채용 결정은 가장 중요한 판단이다.
법칙 232 채용 기간동안 숨쉴 여유를 제공하는 외주업체를 사용하라.
법칙 233 다른 그룹에서 거절된 사람을 테스트팀에 받아들이지 마라.
법칙 234 그룹에서 해야 하는 업무와 그 업무를 수행하는 데 필요한 기술의 관점에서 계획을 수립하라.
법칙 235 다양한 배경 지식을 가진 사람들로 테스트팀을 구성하라.
법칙 236 기회가 닿은 지원자를 채용하라.
법칙 237 교감에 의해 채용하라.
법칙 238 자신의 업무를 좋아하는 사람을 채용하라.
법칙 239 성실한 사람을 채용하라.
법칙 240 면접시 당신이 왜 그를 테스터로 채용해야 하는지, 테스터에게 그를 채용해야만 하는 고유한 기술을 보여달라고 하라.
법칙 241 면접시 비공식 적성 테스트의 한 방법으로 직장에서 실제로 사용할 기술을 보여달라고 요청하라.
법칙 242 채용시 작업 예제를 요구하라.
법칙 243 마음먹었다면 바로 채용하라.
법칙 244 채용 약속을 서면으로 받아서 잘 보관하라.

제10장 소프트웨어 테스트 분야에서의 경력 관리

법칙 245 진로를 선택하고, 그 방향에 매진하라.
법칙 246 테스터의 연봉이 프로그래머의 연봉보다 많을 수 있다.
법칙 247 진로 변경을 편안하게 느끼고, 다른 직종을 추구하라.
법칙 248 어떤 진로를 택하든지 적극적으로 추구하라.
법칙 249 경력을 소프트웨어 테스팅 이외의 영역까지 확장하라.
법칙 250 현재의 회사를 벗어나는 경력을 확장하라.
법칙 251 컨퍼런스는 이야기를 나누기 위한 것이다.
법칙 252 다른 많은 회사들도 지금 회사와 별반 차이가 없다.
법칙 253 현 직장이 마음에 들지 않는다면 다른 직장을 찾아보아라.
법칙 254 현 직장에서 승부를 걸어야 할(그리고 잃을) 경우에 대비하라.
법칙 255 일하고 싶은 회사의 목록을 작성하여 관리하라.
법칙 256 포트폴리오를 작성하라.
법칙 257 이력서를 세일즈 도구로 사용하라.
법칙 258 내부 추천제도를 이용하라.
법칙 259 급여 데이터를 알아보라.
법칙 260 구직 광고를 보고 지원하는 것이라면, 광고 내용에 대한 답변을 준비하라.
법칙 261 인터뷰 기회를 이용하라.
법칙 262 마음에 드는 회사라면 그 회사에 대한 정보를 습득하라.
법칙 263 직장 인터뷰 중 질문을 하라.
법칙 264 직급을 협상하라.
법칙 265 인사부에 대해 조심하라.
법칙 266 펄(Perl)을 배워라.
법칙 267 자바나 C++를 배워라.
법칙 268 테스트 도구의 데모 버전을 다운로드 받아서 사용해보라.
법칙 269 글 쓰기 능력을 향상시켜라.
법칙 270 대중 앞에서 말하는 기술을 향상시켜라.
법칙 271 자격증을 취득하는 것도 고려하라.
법칙 272 단 2주만에 검은 띠를 딸 수 있다면, 싸움을 피하라.
법칙 273 CSTE 자격증을 취득하라.

제11장 테스트 전략 계획

법칙 274 테스트 전략에 대한 세 가지 기본 질문은 쓰는가?, 얼마나 많이?이다.
법칙 275 가능한 테스트 전략은 매우 많다.
법칙 276 테스트 계획은 실제 테스트 프로세스를 이끌어줄 아이디어의 모음이다.
법칙 277 자신의 상황에 적절한 테스트 계획을 수립하라.
법칙 278 전략, 지원 방안, 그리고 작업 결과물에 대한 결정을 알 수 있는 테스트 계획을 수립하라.
법칙 279 지원 방안과 작업 결과로 인해 전략이 가려지지 않도록 하라.
법칙 280 테스트 사례에 대한 거짓말
법칙 281 테스트 전략은 테스트보다 더 큰 것이다.
법칙 282 테스트 전략은 테스트를 설명한다.
법칙 283 다양한 임시 방법을 적용하라.
법칙 284 강력한 테스트 전략의 원 재료를 만들어라.
법칙 285 프로젝트에 대한 첫 번째 전략은 항상 잘못된 전략이다.
법칙 286 프로젝트의 각 단계마다 스스로에게 “현재 무엇을 테스트할 수 있으며, 어떻게 테스트할 수 있는가?”라는 질문을 던져보라.
법칙 287 프로젝트의 성숙도에 따라 테스트를 진행하라.
법칙 288 테스트 복잡성에 대한 논의를 단순화하기 위하여 테스트 수준을 사용하라.
법칙 289 그레이박스를 테스트하라.
법칙 290 이전 테스트 자료를 다시 사용할 경우 무조건적 신뢰는 위험하다.
법칙 291 두 명의 테스터가 동일한 것을 테스트한다고 해서 중복된 노력을 들이고 있는 것은 아니다.
법칙 292 제품의 위험요소 뿐만 아니라 프로젝트의 요소들에 대한 테스트 전략을 수립하라.
법칙 293 테스트 주기를 테스트 프로세스의 심장박동처럼 취급하라.