소프트웨어 테스팅 전문가와 개발자의 필독서 (세트)
- 원서명The Art of Software Testing, Second Edition, How Google Tests Software, How We Test Software at Microsoft
- 지은이글렌포드 마이어스, 톰 뱃지트, 토드 토마스, 코리 샌들러, 제임스 휘태커, 제이슨 아본, 제프 카롤로, 앨런 페이지, 켄 존스톤, 비제이 롤리슨
- 옮긴이제갈호준, 이주형, 권원일, 이공선, 김민영, 김윤명, 여용구
- ISBN : 9788960774186
- 84,000원
- 2013년 04월 10일 펴냄 (절판)
- 페이퍼백 | 1,276쪽 | 188*235mm
- 시리즈 : 소프트웨어 테스팅
판매처
- 현재 이 도서는 구매할 수 없습니다.
책 소개
[ 세트 구성: 전3권 ]
1) 『The Art of Software Testing (Second Edition) 한국어판: 소프트웨어 테스팅의 정석』
2) 『구글은 소프트웨어를 어떻게 테스트하는가: 구글의 테스팅 문화와 기법에 관한 인사이드 스토리』
3) 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다: MS 최고의 현직 테스터들이 밝히는 베스트 프랙티스』
『The Art of Software Testing (Second Edition) 한국어판』 소개
글렌포드 J. 마이어스가 쓴 이 책은 소프트웨어 테스팅 분야에서 한 획을 그은 진정한 명서이며 고전이다. 테스팅에 대한 일반적인 내용을 개발과 연계해 최근 출간된 그 어떤 책보다 오히려 더 체계적이고 설득력 있게 소개한다. 또한 인터넷 애플리케이션 테스팅, 익스트림 테스팅 등 테스팅의 최신 내용도 같은 맥락에서 다뤄 30여 년 전에 저자가 정립한 테스팅 이론의 탁월성과 적용성을 입증하고 있다. 이 책은 소프트웨어 테스트 엔지니어만을 위한 것은 아니다. IT 전문가라면 누구나 한 번은 읽어야 할, 글자 그대로 소프트웨어 테스팅의 정석을 알려주는 책이다.
이 책에서 다루는 내용
■ 테스팅의 기본 원리와 전략
■ 프로그램 인스펙션과 워크스루
■ 코드 인스펙션
■ 오류 체크리스트
■ 동료 평가
■ 블랙박스와 화이트박스 테스팅
■ 오류 추정
■ 하향식 테스팅 대 상향식 테스팅
■ 고수준 테스팅
■ 기능 테스팅과 시스템 테스팅
■ 인수 테스팅
■ 설치 테스팅
■ 모듈(단위) 테스팅
■ 테스트 계획과 제어
■ 독립 테스팅 에이전시
■ 디버깅 원리
■ 오류 분석
■ 익스트림 테스팅
■ 인터넷 애플리케이션 테스팅
■ e커머스 아키텍처의 고수준 테스팅
『구글은 소프트웨어를 어떻게 테스트하는가』 소개
소프트웨어 개발은 어렵다. 소프트웨어 테스트 역시 어렵다. 웹 전반에 걸쳐 개발과 테스트에 대한 이야기를 할라치면 누구든 구글을 언급한다. 구글과 같은 회사들이 대규모의 테스팅을 어떻게 처리하는지 인터넷에서 관심 있게 찾아본 적이 있다면 여러분은 제대로 된 책을 만난 것이다.
매일 구글은 분산된 수백만의 소스 파일들에서 수억의 코드 라인을 테스트하고 릴리스한다. 수십억의 빌드 작업이 수백의 자동화된 테스트를 즉각적으로 수행해 매일 브라우저에서 수억 번 동작한다. 한 해 동안 운영 시스템에서 빌드, 테스트, 릴리스가 이뤄진다. 브라우저는 매일 빌드되고, 웹 애플리케이션은 끊임없이 출시, 배포된다. 2011년에는 구글플러스(Google+)의 100개 기능이 불과 100일 만에 출시됐다.
이것이 구글의 규모이자 구글의 스피드로, 곧 웹 그 자체의 규모와 매한가지이며, 바로 이 책에서 설명하는 테스팅 솔루션이다. 이 책에서는 이러한 인프라스트럭처가 어떻게 계획되고 구현되고 유지 보수되는지 설명한다. 또한 개념과 구현을 개발하는 데 중요한 수많은 인력에 대해 소개하고, 결과를 만들어내는 인프라스트럭처에 대해 이야기한다.
하지만 이 방법만이 유일한 길은 아니다. 구글이 오늘날 여기까지 온 과정은 우리가 테스트를 할 때 사용했던 많은 기술들만큼 흥미롭다. 6년 전 구글은 우리가 일해본 여러 회사들과 크게 다르지 않았다. 테스트는 주요 핵심 영역이 아니었다. 테스팅 분야에서 일하는 사람들은 별다른 인정을 받지 못했고 야근도 잦았다. 테스트는 수작업이 매우 많은 업무였기에, 자동화에 소질이 있는 사람들은 좀 더 큰 ‘영향’을 미칠 수 있는 개발에 재빨리 투입됐다. 오늘날 구글에서 ‘생산성 혁신(Engineering Productivity)’ 팀은 엔지니어링보다 영웅적인 활동을 선호하는 기업 문화, 그리고 테스팅에 대한 편견을 극복해야만 했다. 오늘날 구글 테스터들은 개발자들과 동일한 수준의 연봉을 받고, 보너스와 승진 기회도 동등하게 주어진다. (제품, 다양성, 수익 측면에서) 괄목할 만한 구글의 성장과 함께 테스터 직군이 형성되고 테스팅 문화가 살아났으며 구조적인 조직 재구성이 이뤄지자, 다른 기업들은 구글의 행로를 밟아나가기에 이르렀다. 이제 테스팅을 제대로 완료할 수 있고 상품화 팀과 회사 경영진은 테스팅 팀에 모두 감사하게 될 것이다.
웹에서 미래를 발견하고 돈을 벌기를 원하는 회사라면 이 책에서 설명하는 테스팅 기술과 조직 구조는 더더욱 유용할 것이다. 그러한 회사들은 이 책을 꼭 읽어보길 바란다.
『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』 소개
마이크로소프트 테스팅의 실체를 속속들이 들여다 본다! 마이크로소프트의 유명 현직 테스팅 전문가(SDET)들이 집필한 소프트웨어 테스팅 실무서. 사내 9,000여 명의 테스터가 사용하고 있는 툴과 시스템, 베스트 프랙티스를 소개한다. 마이크로소프트의 테스트 설계와 관리 방식, 그들만의 교육 방법과 커리어 개발 방식, 앞으로의 도전을 알려준다.
이 책에서 다루는 내용
■ 제품 생명주기에 걸쳐 효과적인 테스트를 설계하고 실행하는 방법
■ 기능 테스트의 비용과 리스크를 최소화하고 구조적 기법의 적용 시점을 파악하는 방법
■ 버그와 잠재적인 유지 보수 이슈를 파악하기 위해 코드 복잡도를 측정하는 방법
■ 모델을 사용해 테스트 케이스를 생성하고 예측 불가능한 애플리케이션 동작을 찾고 리스크를 관리하는 방법
■ 자동화 테스트를 적용하는 시점을 파악하는 방법과 자동화 테스트의 장기적 사용을 위해 설계하고 이를 자동화 인프라스트럭처에 통합하는 방법
■ 우수한 테스터의 특징을 파악하고, 테스트 실행, 시스템 검사, 효율적인 진척도를 추적하는 데 효과적인 툴을 검토하는 방법
■ 서비스와 상용 패키지 소프트웨어 테스팅의 차이점을 탐색하는 방법
1) 『The Art of Software Testing (Second Edition) 한국어판: 소프트웨어 테스팅의 정석』
2) 『구글은 소프트웨어를 어떻게 테스트하는가: 구글의 테스팅 문화와 기법에 관한 인사이드 스토리』
3) 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다: MS 최고의 현직 테스터들이 밝히는 베스트 프랙티스』
『The Art of Software Testing (Second Edition) 한국어판』 소개
글렌포드 J. 마이어스가 쓴 이 책은 소프트웨어 테스팅 분야에서 한 획을 그은 진정한 명서이며 고전이다. 테스팅에 대한 일반적인 내용을 개발과 연계해 최근 출간된 그 어떤 책보다 오히려 더 체계적이고 설득력 있게 소개한다. 또한 인터넷 애플리케이션 테스팅, 익스트림 테스팅 등 테스팅의 최신 내용도 같은 맥락에서 다뤄 30여 년 전에 저자가 정립한 테스팅 이론의 탁월성과 적용성을 입증하고 있다. 이 책은 소프트웨어 테스트 엔지니어만을 위한 것은 아니다. IT 전문가라면 누구나 한 번은 읽어야 할, 글자 그대로 소프트웨어 테스팅의 정석을 알려주는 책이다.
이 책에서 다루는 내용
■ 테스팅의 기본 원리와 전략
■ 프로그램 인스펙션과 워크스루
■ 코드 인스펙션
■ 오류 체크리스트
■ 동료 평가
■ 블랙박스와 화이트박스 테스팅
■ 오류 추정
■ 하향식 테스팅 대 상향식 테스팅
■ 고수준 테스팅
■ 기능 테스팅과 시스템 테스팅
■ 인수 테스팅
■ 설치 테스팅
■ 모듈(단위) 테스팅
■ 테스트 계획과 제어
■ 독립 테스팅 에이전시
■ 디버깅 원리
■ 오류 분석
■ 익스트림 테스팅
■ 인터넷 애플리케이션 테스팅
■ e커머스 아키텍처의 고수준 테스팅
『구글은 소프트웨어를 어떻게 테스트하는가』 소개
소프트웨어 개발은 어렵다. 소프트웨어 테스트 역시 어렵다. 웹 전반에 걸쳐 개발과 테스트에 대한 이야기를 할라치면 누구든 구글을 언급한다. 구글과 같은 회사들이 대규모의 테스팅을 어떻게 처리하는지 인터넷에서 관심 있게 찾아본 적이 있다면 여러분은 제대로 된 책을 만난 것이다.
매일 구글은 분산된 수백만의 소스 파일들에서 수억의 코드 라인을 테스트하고 릴리스한다. 수십억의 빌드 작업이 수백의 자동화된 테스트를 즉각적으로 수행해 매일 브라우저에서 수억 번 동작한다. 한 해 동안 운영 시스템에서 빌드, 테스트, 릴리스가 이뤄진다. 브라우저는 매일 빌드되고, 웹 애플리케이션은 끊임없이 출시, 배포된다. 2011년에는 구글플러스(Google+)의 100개 기능이 불과 100일 만에 출시됐다.
이것이 구글의 규모이자 구글의 스피드로, 곧 웹 그 자체의 규모와 매한가지이며, 바로 이 책에서 설명하는 테스팅 솔루션이다. 이 책에서는 이러한 인프라스트럭처가 어떻게 계획되고 구현되고 유지 보수되는지 설명한다. 또한 개념과 구현을 개발하는 데 중요한 수많은 인력에 대해 소개하고, 결과를 만들어내는 인프라스트럭처에 대해 이야기한다.
하지만 이 방법만이 유일한 길은 아니다. 구글이 오늘날 여기까지 온 과정은 우리가 테스트를 할 때 사용했던 많은 기술들만큼 흥미롭다. 6년 전 구글은 우리가 일해본 여러 회사들과 크게 다르지 않았다. 테스트는 주요 핵심 영역이 아니었다. 테스팅 분야에서 일하는 사람들은 별다른 인정을 받지 못했고 야근도 잦았다. 테스트는 수작업이 매우 많은 업무였기에, 자동화에 소질이 있는 사람들은 좀 더 큰 ‘영향’을 미칠 수 있는 개발에 재빨리 투입됐다. 오늘날 구글에서 ‘생산성 혁신(Engineering Productivity)’ 팀은 엔지니어링보다 영웅적인 활동을 선호하는 기업 문화, 그리고 테스팅에 대한 편견을 극복해야만 했다. 오늘날 구글 테스터들은 개발자들과 동일한 수준의 연봉을 받고, 보너스와 승진 기회도 동등하게 주어진다. (제품, 다양성, 수익 측면에서) 괄목할 만한 구글의 성장과 함께 테스터 직군이 형성되고 테스팅 문화가 살아났으며 구조적인 조직 재구성이 이뤄지자, 다른 기업들은 구글의 행로를 밟아나가기에 이르렀다. 이제 테스팅을 제대로 완료할 수 있고 상품화 팀과 회사 경영진은 테스팅 팀에 모두 감사하게 될 것이다.
웹에서 미래를 발견하고 돈을 벌기를 원하는 회사라면 이 책에서 설명하는 테스팅 기술과 조직 구조는 더더욱 유용할 것이다. 그러한 회사들은 이 책을 꼭 읽어보길 바란다.
『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』 소개
마이크로소프트 테스팅의 실체를 속속들이 들여다 본다! 마이크로소프트의 유명 현직 테스팅 전문가(SDET)들이 집필한 소프트웨어 테스팅 실무서. 사내 9,000여 명의 테스터가 사용하고 있는 툴과 시스템, 베스트 프랙티스를 소개한다. 마이크로소프트의 테스트 설계와 관리 방식, 그들만의 교육 방법과 커리어 개발 방식, 앞으로의 도전을 알려준다.
이 책에서 다루는 내용
■ 제품 생명주기에 걸쳐 효과적인 테스트를 설계하고 실행하는 방법
■ 기능 테스트의 비용과 리스크를 최소화하고 구조적 기법의 적용 시점을 파악하는 방법
■ 버그와 잠재적인 유지 보수 이슈를 파악하기 위해 코드 복잡도를 측정하는 방법
■ 모델을 사용해 테스트 케이스를 생성하고 예측 불가능한 애플리케이션 동작을 찾고 리스크를 관리하는 방법
■ 자동화 테스트를 적용하는 시점을 파악하는 방법과 자동화 테스트의 장기적 사용을 위해 설계하고 이를 자동화 인프라스트럭처에 통합하는 방법
■ 우수한 테스터의 특징을 파악하고, 테스트 실행, 시스템 검사, 효율적인 진척도를 추적하는 데 효과적인 툴을 검토하는 방법
■ 서비스와 상용 패키지 소프트웨어 테스팅의 차이점을 탐색하는 방법
목차
목차
- 『The Art of Software Testing (Second Edition) 한국어판』
- 1장 자체평가 테스트
- 2장 프로그램 테스팅의 심리학과 경제학
- 테스팅의 심리학
- 테스팅의 경제학
- 블랙박스 테스팅
- 화이트박스 테스팅
- 소프트웨어 테스팅 원칙
- 요약
- 3장 프로그램 인스펙션과 워크스루, 리뷰
- 인스펙션과 워크스루
- 코드 인스펙션
- 인스펙션용 에러 체크리스트
- 데이터 참조 에러
- 데이터 선언 에러
- 연산 에러
- 비교 에러
- 제어흐름 에러
- 인터페이스 에러
- 입출력 에러
- 기타 체크
- 워크스루
- 데스크 체킹
- 동료 평가
- 요약
- 4장 테스트 케이스 설계
- 화이트박스 테스팅
- 논리 커버리지 테스팅
- 동등분할
- 예제
- 경계 값 분석
- 원인-결과 그래핑
- 에러 추측
- 전략
- 화이트박스 테스팅
- 5장 모듈 테스팅
- 테스트 케이스 설계
- 점진적 테스트
- 하향식 테스팅 대 상향식 테스팅
- 하향식 테스팅
- 상향식 테스팅
- 비교
- 테스트 수행
- 6장 고수준 테스팅
- 기능 테스팅
- 시스템 테스팅
- 편의 테스팅
- 볼륨 테스팅
- 스트레스 테스팅
- 사용성 테스팅
- 보안성 테스팅
- 성능 테스팅
- 스토리지 테스팅
- 구성 테스팅
- 호환성∙변환 테스팅
- 설치 테스팅
- 신뢰성 테스팅
- 회복 테스팅
- 유용성 테스팅
- 문서 테스팅
- 절차 테스팅
- 시스템 테스팅 수행
- 인수 테스팅
- 설치 테스팅
- 테스트 계획 및 제어
- 테스트 완료 기준
- 독립적 테스트 기관
- 7장 디버깅
- 무차별 디버깅
- 귀납적 디버깅
- 연역적 디버깅
- 역추적에 의한 디버깅
- 테스팅에 의한 디버깅
- 디버깅 원리
- 에러 발생 위치 파악의 원리
- 에러 수정 기법
- 에러 분석
- 8장 익스트림 테스팅
- 익스트림 프로그래밍 기초
- 익스트림 테스팅의 개념
- 익스트림 단위 테스팅
- 인수 테스팅
- 익스트림 테스팅 활용
- 테스트 케이스 설계
- 테스트 드라이버와 테스트 애플리케이션
- 요약
- 9장 인터넷 애플리케이션 테스팅
- 기본적인 e커머스 아키텍처
- 테스팅 관련 어려운 과제
- 테스팅 전략
- 프리젠테이션 레이어 테스팅
- 비즈니스 레이어 테스팅
- 데이터 레이어 테스팅
- 부록 A 익스트림 테스팅 애플리케이션 예제
- 부록 B 1,000보다 작은 소수
- 『구글은 소프트웨어를 어떻게 테스트하는가』
- 1장 구글 소프트웨어 테스팅 개요
- 품질 ≠ 테스트
- 역할
- 조직적 구조
- 기기, 걷기, 뛰기
- 테스트 종류
- 2장 테스트 소프트웨어 엔지니어
- SET에 대한 이야기
- 개발과 테스트 작업 흐름
- SET란?
- 프로젝트의 초기 단계
- 팀 구조
- 설계 문서
- 인터페이스와 프로토콜
- 자동화 계획
- 테스트 가능성
- SET 작업 흐름: 예제
- 테스트 수행
- 테스트 크기 정의
- 공유 인프라스트럭처에서 테스트 크기 사용
- 테스트 크기에 따른 이점
- 테스트 수행에 대한 요구 사항
- 테스트 인증
- 테스트 인증 프로그램 창시자와의 인터뷰
- SET들과의 면접
- 툴 개발자 테드 마오와의 인터뷰
- 웹 드라이버의 창시자 사이몬 스튜어트와의 인터뷰
- SET에 대한 이야기
- 3장 테스트 엔지니어
- 사용자를 대변하는 테스트 역할
- TE에 대한 이야기
- 테스트 계획
- 리스크
- 테스트 케이스에 대한 이야기
- 버그에 대한 이야기
- TE 채용
- 구글의 테스트 리더십
- 유지 관리 모드 테스팅
- 퀄리티 봇 실험
- BITE 실험
- 구글 테스트 분석
- 무료 테스팅 업무 흐름
- 외부 업체
- 구글 문서도구의 TE 린제이 웹스터와의 인터뷰
- 유튜브 TE 애플 초우와의 인터뷰
- 4장 테스트 엔지니어 매니저
- TEM에 대한 이야기
- 프로젝트와 사람 모으기
- 영향력
- 지메일 TEM 앵킷 메타와의 인터뷰
- 안드로이드 TEM 훙 당과의 인터뷰
- 크롬 TEM 조엘 히노스키와의 인터뷰
- 테스트 엔지니어링 디렉터
- 검색과 지리 테스트 디렉터 쉘튼 마와의 인터뷰
- 엔지니어링 툴 디렉터 아쉬쉬 쿠마와의 인터뷰
- 구글 인디아의 테스트 디렉터 수제이 사니와의 인터뷰
- 엔지니어링 매니저, 브래드 그린과의 인터뷰
- 제임스 휘태커와의 인터뷰
- 5장 구글 소프트웨어 테스팅의 향상
- 구글 프로세스의 심각한 결함
- SET의 미래
- TE의 미래
- 테스트 디렉터와 매니저의 미래
- 테스트 인프라스트럭처의 미래
- 결론
- 부록 A 크롬OS 테스트 계획
- 개요
- 리스크 분석
- 빌드 베이스라인에 따른 테스트
- 매일 마지막으로 성공한 테스트
- 릴리스에 따른 테스팅
- 수동 테스트와 자동화 테스트
- 개발과 테스트 품질 초점
- 릴리스 채널
- 사용자 입력
- 테스트 케이스 저장소
- 테스트 대시보드
- 가상화
- 성능
- 스트레스, 장시간 수행, 안전성
- 테스트 수행 프레임워크(Autotest)
- OEM
- 하드웨어 랩
- E2E 팜 자동화
- 브라우저 앱매니저 테스팅
- 브라우저의 테스트 가능성
- 하드웨어
- 타임라인
- 주요 테스트 드라이버
- 관련 문서
- 부록 B 크롬에 대한 테스트 투어
- 쇼핑 투어
- 학생 투어
- 테스트 제안 영역
- 국제 전화 투어
- 테스트 제안 영역
- 랜드마크 투어
- 크롬에서 제안하는 랜드마크
- 올빼미 투어
- 테스트 제안 영역
- 장인 투어
- 크롬의 툴
- 나쁜 이웃 투어
- 크롬OS에서의 나쁜 이웃
- 개인화 투어
- 크롬을 커스트마이즈하는 방법
- 크롬을 커스트마이즈하는 방법
- 부록 C 툴과 코드에 대한 블로그 포스트
- 버그와 중복 노동을 없애기 위한 BITE의 사용
- 퀄리티 봇 풀어 놓기
- RPF: 구글의 기록/재생 프레임워크
- 구글 테스트 분석기 - 현재 오픈소스
- 이해 가능함
- 빠름
- 행동 가능함
- 일관된 가치
- 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』
- 1부 마이크로소프트에 대해
- 01장 마이크로소프트의 소프트웨어 엔지니어링
- 마이크로소프트의 비전, 기업 가치, 높은 선호도의 비결
- 대규모 소프트웨어 엔지니어링 기업
- 효율적인 대규모 비즈니스 개발
- 공유 팀 모델
- 대기업의 소규모 비즈니스
- 다양한 엔지니어 고용
- 엔지니어링 분야
- 세계적 소프트웨어 개발사를 향해
- 정리
- 02장 마이크로소프트의 소프트웨어 테스트 엔지니어
- 이름을 붙여볼까?
- 마이크로소프트의 테스터가 항상 SDET는 아니다
- 테스터가 더 많아야 한다
- 학교 방문 채용
- 업계 경력직 채용
- 마이크로소프트 SDET 되기
- 마이크로소프트 엔지니어링 커리어
- 테스트 부문의 커리어 패스
- 테스트 아키텍트
- IC 테스터
- 관리자가 되는 것이 승진은 아니다
- 테스트 관리자
- 정리
- 03장 엔지니어링 생명주기
- 마이크로소프트의 소프트웨어 공학
- 전통적 소프트웨어 공학 모델
- 마일스톤
- 마이크로소프트에서의 애자일
- 기능 통합
- 프로세스 개선
- 마이크로소프트의 정형적 프로세스 개선 시스템
- 전시상황실에서 소프트웨어 출시
- 의무 실행
- 정리: 음식을 다 만들고
- 마이크로소프트의 소프트웨어 공학
- 2부 테스팅
- 04장 테스트 케이스 작성을 위한 실용적 접근
- 좋은 소프트웨어 설계와 테스트 설계
- 테스트 패턴 사용
- 테스트 시간 추정
- 테스트 시작
- 질문하기
- 테스트 전략 수립
- 테스트 용이성
- 테스트 설계 명세서
- 정상 동작 테스트와 오동작 테스트
- 테스트 케이스 설계 시 고려해야 할 기타 항목
- 블랙박스, 화이트박스, 그레이박스
- 마이크로소프트의 탐색적 테스팅
- 정리
- 05장 기능 테스팅 기법
- 기능 테스팅의 필요성
- 동등 클래스 분할
- 변수 데이터 분할
- 동등 클래스 분할 동작
- 파라미터의 서브셋 분석
- ECP 테스트
- 동등 클래스 분할 요약
- 경계 값 분석
- 경계 값 테스트의 정의
- 경계 값 분석을 위한 새로운 공식
- 숨겨진 경계 값
- 경계 값 분석 요약
- 조합 분석
- 조합 테스팅 접근 방법
- 조합 분석의 적용
- 조합 분석의 효과
- 조합 분석 요약
- 정리
- 06장 구조적 테스팅 기법
- 블록 테스팅
- 블록 테스팅 요약
- 결정 테스팅
- 결정 테스팅 요약
- 조건 테스팅
- 조건 테스팅 요약
- 기본 경로 테스팅
- 기본 경로 테스팅 요약
- 정리
- 블록 테스팅
- 07장 코드 복잡도에 따른 리스크 분석
- 비지니스 리스크
- 복잡한 문제
- 코드 라인 수 측정
- 사이클로매틱 복잡도 측정
- 할스테드 메트릭
- 객체지향 메트릭
- 사이클로매틱 복잡도가 높다고 반드시 버그가 많은 것은 아니다
- 복잡도 메트릭 제대로 다루기
- 정리
- 08장 모델 기반 테스팅
- 모델링 기초
- 모델 테스팅
- 모델 설계
- 소프트웨어 모델링
- 유한 상태 모델 만들기
- 모델 자동화
- 테스팅을 지원하는 모델링
- 베이시안 도해 모델
- 페트리 넷
- 마이크로소프트의 모델 기반 테스팅 툴
- 스펙 익스플로러
- 언어와 엔진
- 모델링 팁
- 정리
- 추천 도서와 툴
- 버그 워크플로우
- 버그 추적
- 버그의 일생
- 버그 추적 시스템의 속성
- 버그 리포트를 작성하는 이유
- 버그 리포트의 구조
- 버그 선별
- 버그 리포트의 일반적인 실수
- 데이터 사용
- 데이터 오용: 성과 측정으로서의 버그
- 버그 바
- 테스트 케이스 관리
- 테스트 케이스란?
- 테스트 케이스의 가치
- 테스트 케이스 구조
- 테스트 케이스 작성 시의 실수
- 테스트 케이스 관리하기
- 케이스와 포인트: 테스트 케이스 수 세기
- 테스트 결과 추적과 해석
- 정리
- 자동화의 가치
- 자동화냐 아니냐, 그것이 문제로다
- UI 자동화
- 테스트 자동화 구성 요소
- 마이크로스프트에서의 SEARCH
- 설정
- 실행
- 분석
- 보고
- 초기화
- 도움말
- 실행, 자동화, 실행!
- 모두 연동하기
- 대규모의 테스트 자동화
- 일반적인 자동화 실수
- 정리
- 기능성을 넘어
- ‘~성’ 테스트하기
- 성능 테스팅
- 성능 측정 방법
- 스트레스 테스팅
- 분산 스트레스 테스팅
- 분산 스트레스 아키텍처
- 멀티 클라이언트 스트레스 테스트 속성
- 호환성 테스팅
- 애플리케이션 라이브러리
- 애플리케이션 검증기
- 자기 개밥 먹기
- 접근성 테스팅
- 접근성 페르소나
- 접근성 테스트하기
- MS 액티브 액세서빌리티를 위한 테스팅 툴
- 사용성 테스팅
- 보안성 테스팅
- 보안 위협 모델링
- 퍼지 테스팅
- 정리
- 코드 변경
- 통제하기
- 변경 추적
- 무엇이 변경됐나?
- 왜 변경됐나?
- 소스 관리를 위한 공간
- 빌드
- 일일 빌드
- 정적 분석
- 네이티브 코드 분석
- 매니지드 코드 분석
- 단지 또 다른 툴
- 테스트 코드 분석
- 테스트 코드가 제품 코드다
- 더 많은 툴
- 특수한 문제를 위한 툴
- 모든 사람을 위한 툴
- 정리
- 테스팅과 품질
- 정보를 제공하는 테스팅
- 품질에 대한 이해
- 해결책은 고객
- 게임에서의 사례
- 윈도우 오류 보고
- WER 사용 사례
- 버킷 활용하기
- 버킷에 쌓인 문제 처리하기
- 테스트와 WER
- 스마일 전송 프로그램
- 스마일 전송 프로그램 효과
- 고객과의 연결(커넥트)
- 정리
- 두 가지 부문: 서비스와 테스트 기법
- 마이크로소프트 서비스 전략
- 인터넷 서비스로의 관심 이동
- 라지 스케일에서 메가 스케일로의 성장
- 성장의 발목을 잡는 전력
- 서비스와 패키지 제품
- 독립형에서 계층형 서비스로 이동
- 혁신의 물결
- S+S와 서비스에 대한 테스트 접근 방법 설계
- S+S 테스팅 기법
- 통합 테스팅, 테스트 플래그, 에뮬레이션
- 지속적인 품질 개선 프로그램
- 내가 본 일반적인 버그
- 결함 분석 자동화
- 분석 마비 상황의 극복
- 결함 비교
- 좋은 로깅 사례
- 로그 파일의 구조
- 결함 분석 자동화 통합
- 머신 가상화
- 가상화의 장점
- 가상 머신 테스트 시나리오
- 테스트 도중 발생하는 오류
- 추천하지 않는 테스트 시나리오
- 코드 리뷰와 인스펙션
- 코드 리뷰의 유형
- 체크 리스트
- 리뷰 시 고려 사항
- 리뷰의 두 얼굴
- 툴이 너무 많아도 문제
- 간소화, 재사용, 재활용
- 무엇이 문제인가?
- 공개 개발
- 정리
- 전향적 사고의 필요성
- 한걸음 물러서서 앞을 내다보기
- 품질 문화를 위한 노력
- 테스팅과 품질 보증
- 누가 품질의 주인인가?
- 품질 비용
- 테스트의 새로운 역할
- 테스트 리더십
- 마이크로소프트 테스트 리더십 팀
- 테스트 리더십 의장
- 테스트 리더십 활동
- 테스트 아키텍트 그룹
- 테스트 엑설런스 팀
- 공유
- 도움
- 소통
- 미래 주목하기
- 마이크로소프트 테스트 엑설런스 팀의 감독
- 리더십 3원소