팀에 후배가 들어오면 꼭 한 번 읽어 보라고 하는 책 중에 한 권입니다.
이론적인 것을 공부해야한다는 부담담 대신에 가볍게 그리고 테스트가 무엇이고 테스터는 어떻게 해야하는지에 대해서 간략하게 이해할 수 있는 책인 것 같습니다.
아래 제목만 보시고 흥미 있으시면 책을 읽어 보시고 아니면 그정도는 아니다 싶으시면 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 테스트 주기를 테스트 프로세스의 심장박동처럼 취급하라.