소득공제
이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
에이콘 소프트웨어 아키텍처 시리즈
책소개
목차
|
1부 3인의 이야기
___1장 프롤로그 ______1.1 소프트웨어 개발 방법 _________1.1.1 첫 번째 방법 _________1.1.2 두 번째 방법 _________1.1.3 차이점 ______1.2 인수 테스트의 중요성 ______1.3 시스템과 팀 소개 _________1.3.1 시스템 _________1.3.2 인물 소개 ______1.4 정리 ___2장 린과 애자일 ______2.1 3인체제와 팀 ______2.2 후 구현 테스트 ______2.3 느린 피드백보다는 빠른 피드백 ______2.4 구현 전의 테스트 ______2.5 린과 애자일의 원리 ______2.6 정리 ___3장 테스트 전략 ______3.1 테스트의 종류 ______3.2 테스트가 수행되는 장소 ______3.3 테스트 측면 _________3.3.1 제어점과 관찰점 _________3.3.2 새로운 테스트는 새로운 요구사항이다 ______3.4 정리 ___4장 인수 테스트 소개 ______4.1 업무 규칙 예제 ______4.2 인수 테스트의 구현 _________4.2.1 테스트 스크립트 _________4.2.2 사용자 인터페이스 테스트 _________4.2.3 xUnit 테스트 _________4.2.4 자동화 인수 테스트 _________4.2.5 종합 테스트 ______4.3 테스트 절차 ______4.4 정리 ___5장 예제 프로젝트 ______5.1 기획 _________5.1.1 목표 _________5.1.2 프로젝트 인수 테스트 ______5.2 고수준의 요구사항 _________5.2.1 기능 _________5.2.2 기능 인수 기준 ______5.3 정리 ___6장 사용자 스토리 기술 ______6.1 스토리 _________6.1.1 기능을 스토리로 분할 _________6.1.2 역할 _________6.1.3 역할 속성 _________6.1.4 페르소나 _________6.1.5 역할의 스토리 _________6.1.6 스토리 인수 기준 _________6.1.7 인수 테스트가 크기를 결정한다 _________6.1.8 고객 용어 ______6.2 INVEST 기준 ______6.3 정리 ___7장 시나리오 협업 ______7.1 사용자 스토리로부터 유스케이스 생성 _________7.1.1 간단한 유스케이스 _________7.1.2 예외와 대안. _________7.1.3 인수 테스트 _________7.1.4 문서화 ______7.2 스토리 지도 ______7.3 개념적인 흐름 ______7.4 의사소통 ______7.5정리 ___8장 테스트 분해 ______8.1 3인체제의 테스트 생성 ______8.2 테스트 컨텍스트 ______8.3 테스트 구조 _________8.3.1 계산 테이블 _________8.3.2 데이터 테이블 _________8.3.3 액션 테이블 ______8.4 예제 값으로 테스트 _________8.4.1 요구사항 수정 _________8.4.2 인수 테스트 수정 ______8.5 문장에 있는 값으로 테스트 ______8.6 테스트가 실행 시기와 장소 ______8.7 정리 ___9장 시나리오 테스트 ______9.1 예외 시나리오 테스트 ______9.2 업무 규칙 테스트 ______9.3스토리 충돌 문제 ______9.4 모든 것을 자동화할 수 없다 ______9.5 다중 레벨 테스트 ______9.6 사용자 인터페이스 테스트 ______9.7 목표 검사 ______9.8 정리 ___10장 사용자 스토리 분할 ______10.1 인수 테스트가 스토리 분할을 돕는다 ______10.2 업무 규칙 테스트 ______10.3 업무 규칙과 스토리 ______10.4 정리 ___11장 시스템 경계 ______11.1 외부 인터페이스 _________11.1.1 상세사항 ______11.2 외부 인터페이스 테스트 _________11.2.1 컴포넌트 테스트 _________11.2.2 테스트 더블과 모의 객체 ______11.3 진짜와 가짜 ______11.4 액티비티 스토리 지도 ______11.5 정리 ___12장 개발 리뷰 ______12.1 나머지 스토리 _________12.1.1 사용성 테스트 _________12.1.2 화면과 상태의 분리 _________12.1.3 품질 속성 테스트 _________12.1.4 작업흐름 테스트 ______12.2 개발 계획 ______12.3 기획에서 인수까지 ______12.4 정리 2부 상세사항 ___13장 분리를 통한 간략화 ______13.1 복잡한 업무 규칙 _________13.1.1 분리에 의한 간략화 _________13.1.2 단순화된 규칙 ______13.2대여 이력 ______13.3 정리 ___14장 모델과 뷰의 분리 ______14.1 사용자 인터페이스의 분리 ______14.2 분리는 테스팅을 쉽게 한다 ______14.3 정리 ___15장 이벤트, 반응, 상태 ______15.1 이벤트와 이벤트 테이블 ______15.2 상태와 상태 전이 ______15.3 내부 상태와 외부 반응 _________15.3.1 임시 상태나 영속 상태 _________15.3.2 젠 질문 ______15.4 정리 ___16장 개발자 인수 테스트 ______16.1 컴포넌트 인수 테스트 _________16.1.1 필드 디스플레이 테스트 _________16.1.2 테이블 디스플레이 테스트 ______16.2 정리 ___17장 인터페이스 분리 ______17.1 서비스 제공자에 대한 테스트 _________17.1.1 인터페이스 _________17.1.2 품질 속성 테스트 _________17.1.3 구현의 비교 ______17.2 서비스와 사용자 인터페이스 분리 _________17.2.1 관심의 분리 _________17.2.2 재사용 가능한 업무 규칙 ______17.3 정리 ___18장 엔티티와 릴레이션십 ______18.1 릴레이션십 _________18.1.1 엔티티와 릴레이션십 _________18.1.2 다중 릴레이션십 _________18.1.3 다른 표현법 ______18.2 정리 ___19장 대규모 시스템에서의 3인체제 ______19.1 대규모 시스템 ______19.2 고객 테스트가 꼭 필요하지 않은 경우 _________19.2.1 데이터 변환 _________19.2.2 데이터베이스 변환 ______19.3 테스트가 전혀 없을 경우 _________19.3.1 레거시 시스템 ______19.4 정리 3부 일반적인 이슈 ___20장 업무 가능성, 규칙, 가치 ______20.1 업무 역량 ______20.2 시나리오 처리 ______20.3 업무 규칙 표출 ______20.4 다른 업무 가치 ______20.5 정리 ___21장 테스트 표현 ______21.1 고객이 이해 가능한 테이블 ______21.2 테이블과 텍스트 ______21.3 다중 행동의 구체화 ______21.4 복잡한 데이터 ______21.5 수정된 테이블 형태 ______21.6 정리 ___22장 테스트 평가 ______22.1 테스트 양상 _________22.1.1 고객이 이해하기 쉬워야 한다 _________21.1.2 맞춤법을 검사해야 한다 _________21.1.3 결과가 항상 동일해야 한다 _________21.1.4 깨지지 않아야 한다 ______22.2 테스트 순서 _________22.2.1 작업흐름 테스트 ______22.3 테스트 조건 _________22.3.1 관심의 분리 _________22.3.2 테스트 실패 _________22.3.3 테스트 중복 ______22.4 구현 이슈 배제 ______22.5 기억해야 할 사항들 ______22.6 정리 ___23장 다른 부분에 테스트 활용 ______23.1 인수 테스트의 활용 _________23.1.1 완성도 _________23.1.2 예측 도우미 _________23.1.3 스토리 분할 _________23.1.4 개발자 스토리 ______23.2 버그 리포트로서의 테스트 _________23.2.1 원인 분석 _________23.2.2 제품 버그 _________23.2.3 회귀 테스트 ______23.3 정리 ___24장 테스트 컨텍스트와 도메인 언어 ______24.1 유비쿼터스 언어 ______24.2 두 개의 도메인 ______24.3 정리 ___25장 회고와 관점 ______25.1 복습 _________25.1.1 프로세스 _________25.1.2 테스트 레이어 _________25.1.3 테스트 _________25.1.4 의사소통 ______25.2 장벽 _________25.2.1 모나드 _________25.2.2 이용 불가능한 고객 _________25.2.3 변경 _________25.2.4 리스크 ______25.3 이익 ______25.4정리 4부 사례 연구 ___26장 사례 연구: 은퇴 연금 ______26.1 테스트 컨텍스트 ______26.2 주 경로 테스트 _________26.2.1 설정 _________26.2.2 이벤트 _________26.2.3 예상 결과 _________26.2.4 구현 이슈 _________26.2.5 관심의 분리 ______26.3 업무 가치 추적 ______26.4 하나의 예외 _________26.4.1 이벤트 _________26.4.2 예상 결과 ______26.5 기타 예외 사항 _________26.5.1 이벤트 _________26.5.2 예상 결과 ______26.6 동시에 발생하는 두 개의 예외 상황 _________26.6.1 이벤트 _________26.6.2 예상 결과 ______26.7 큰 그림 _________26.7.1 이벤트 테이블 ______26.8 상태 전이 테이블 ______26.9 정리 ___27장 사례 연구: 신호처리 ______27.1 너무 시끄럽다 ______27.2 소음도 ______27.3 개발자 테스트 ______27.4 정리 ___28장 사례 연구: 도서관 프린트 서버 ______28.1 테스트 컨텍스트 ______28.2 작업흐름 테스트 ______28.3 정리 ___29장 사례 연구: 가용성이 높은 플랫폼 ______29.1 서버 교환에 대한 테스트 컨텍스트 ______29.2 서버 교환에 대한 테스트 ______29.3 기술적인 규칙에 대한 테스트 ______29.4 정리 5부 기술적인 주제 ___30장 ATDD에 적용할 수 있는 것과 그 방법 ______30.1 테스트 플랫폼 ______30.2 테스트부터 시작하는 내부 설계 ______30.3 디바이스 테스팅 ______30.4 사용자 인터페이스에서 시작 ______30.5 블랙박스 테스팅 ______30.6 단위 테스트 ______30.7정리 ___31장 테스트 설정 ______31.1 공통 설정 ______31.2 몇 가지 개선 사항 ______31.3 테스트 순서 ______31.4 영속적인 저장소의 이슈 ______31.5 정리 ___32장 사례 연구: 이메일 주소 ______32.1 테스트 컨텍스트 ______32.2 테스트 분할 _________32.2.1 로컬 파트 확인 _________32.2.2 도메인 테스트 _________32.2.3 허용되지 않는 도메인의 테스트 _________32.2.4 연결을 확인하는 테스트 _________32.2.5 검토 테스트 ______32.3 정리 부록 ___부록A 그밖의 이슈들 ______A.1 테스트 컨텍스트 ______A.2 고객 예제 _________A.2.1 애매한 인수 테스트 _________A.2.2 인수 테스트 상세 ______A.3 요구사항과 인수 테스트 _________A.3.1 요구사항과 테스트 문서화 _________A.3.2 요구사항 분리 _________A.3.3 이슈의 분리 ______A.4 랜덤 이벤트를 이용한 시스템 테스트 ______A.5 숫자 3의 힘 ______A.6 정리 ___부록B 업무 가치 예측 ______B.1 업무 가치 ______B.2 개발자 스토리 ______B.3 정리 ___부록C 테스트 프레임워크 예제 ______C.1 예제 ______C.2 Fit 구현 _________C.2.1 설정 _________C.2.2 CD 대여 _________C.2.3 반납 _________C.2.4 CD 종류에 따른 대여 요금 ______C.3 Slim-테이블 스타일 _________C.3.1 헤더 _________C.3.2 설정 _________C.3.3 CD 대여 _________C.3.4 반납 _________C.3.5 CD 종류에 따른 대여 요금 ______C.4 Slim-Cucumber 스타일 _________C.4.1 설정 _________C.4.2 CD 대여 _________C.4.3 CD 반납 _________C.4.4 시나리오 라이브러리 _________C.4.5 CD 종류에 따른 대여 요금 ______C.5 Robot _________C.5.1 설정 _________C.5.2 CD 대여 _________C.5.3 CD 반납 _________C.5.4 CD 종류에 따른 대여 요금 ______C.6 Cucumber _________C.6.1 CD 대여 _________C.6.1 CD 반납 _________C.6.2 CD 종류에 따른 대여 요금 ______C.7 테스트 프레임워크 ______C.8 정리 ___부록D 테이블의 활용 ______D.1 테이블을 이용해 사용자 인터페이스 테스트 ______D.2 요구사항 테이블 _________D.2.1 그 외의 테이블 ______D.3 품질 속성 요구사항 ______D.4 데이터 테이블 ______D.5 정리 ___부록E ATDD와 화폐 테스트 ______E.1 테스트 컨텍스트 ______E.2 본래의 테스트 ______E.3 인수 테스트 접근 방법 ______E.4 정리 ___부록F 연습문제 ______F.1 계산기 _________F.1.1 테스트 생성 ______F.2 좀 더 많은 연습문제 _________F.2.1 샘의 CD 대여점 _________F.2.2 삼각형 연습문제 _________F.2.3 파일 복사 연습문제 ___참고문헌과 참고자료 _________참고자료 _________참고문헌 ___에필로그 ______육하원칙: 누가, 무엇을, 언제, 어디서, 왜, 어떻게 _________그 밖의 사항 _________법적 공지 ______다른 이들의 경험 _________재작업이 60%에서 20%로 감소했다 _________처음으로 동작한 작업흐름 _________의사소통 오류의 감소 _________시간 절약 _________올바른 업무 규칙 얻어내기 _________테스트를 위한 시나리오 _________인수 테스트와 단위 테스트 _________게임 변경 _________더욱 밀접해진 교차 기능 팀 통합, 산뜻한 시각 스토리 완성 기준, 자동화로 감소된 테스트 시간 _________여러분의 이야기는 어떠한가? ______정리 |
저자 소개
저자 : 케네스 퍼그
25년 이상 소프트웨어 분야에 종사했다. 이전에는 퍼그 킬린(Pugh-Killeen)협회의 학장이었으며, 넷 오브젝티브스(Net Objectives)의 펠로우(fellow) 컨설턴트를 맡고 있다. 레이더 추적장치부터 금융 분석에 관련된 애플리케이션까지 다양한 분야의 소프트웨어를 개발했다. 요구사항 수집부터 테스팅까지 전 분야를 다루어봤고, 21세기에 들어서면서부터는 린과 애자일 프로세스를 도입해 그의 팀원들과 좀 더 효율적으로 소프트웨어를 만들어보려고 노력했다. 다양한 국제 컨퍼런스에서 연설을 한 경험이 있으며, 전 세계에 걸쳐 컨설팅과 강연을 하고 다양한 기술 분야의 주제를 다뤘다. 이 책은 그의 7번째 책이다. 그의 책 『프리 팩토링Prefactoring』은 2006 졸트 상을 수상했다. 여가 시간에는 스노우보드나 윈드서핑, 캠핑을 즐긴다. 1997년부터 2003년에는 애팔래치아 자연 산책로를 횡단했다.
역자 : 이주형
카이스트 소프트웨어 대학원 석사 과정을 졸업했으며, 현재는 삼성전자 가전 사업부 SE파트에서 책임연구원으로 재직 중이다. 주요 관심 분야는 요구공학, 소프트웨어 테스팅이다. 에이콘출판사에서 펴낸 『엔터프라이즈급 애자일 방법론』(2008), 『구글은 소프트웨어를 어떻게 테스트하는가』(2013)를 공역했다.
역자 : 제갈호준
아이오와 주립대에서 컴퓨터 사이언스 박사 학위를 받고, 삼성전자 무선사업부에서 타이젠 플랫폼TIZEN PLATFORM을 개발하고 있다. 주요 관심 분야는 플랫폼 개발, 아키텍처, 오픈 소스, 자동화 테스팅이다. 에이콘출판사에서 펴낸 『SWT/JFACE 인 액션』(2006), 『엔터프라이즈급 애자일 방법론』(2008), 『구글은 소프트웨어를 어떻게 테스트하는가』(2013) 등을 공역했다.
관련 분류
- 카테고리 분류
품목정보
- 발행일
- 2014년 05월 29일
- 쪽수, 무게, 크기
- 428쪽 | 1069g | 188*250*30mm
- ISBN13
- 9788960775619
출판사 리뷰
|
★ 이 책에서 다루는 내용 ★
■ 완전히 테스트 가능한 요구사항으로 소프트웨어를 개발하는 방법 ■ 단순하고 컴포넌트화된 테스트 작성 방법과 누락된 로직을 검사하는 방법 ■ 소프트웨어 시스템의 사용자 인터페이스, 서비스 구현과 그 외 까다로운 요소들을 테스트하는 방법 ■ 외부 소프트웨어를 가장 잘 다룰 수 있도록 요구사항을 식별하는 방법 ■ 테스트 결과를 표현하고 평가해 프로젝트 진행 상황을 측정하는 데 사용하는 방법 ■ 인수 테스트를 만들어서 개발 조직과 고객에게 모두 이익을 줄 수 있는 방법 ■ 대규모 프로젝트에 ATDD를 확대 적용하는 방법 ★ 이 책의 구성 ★ 1부: 고객, 개발자, 테스터의 3인체제가 소프트웨어 시스템을 만드는 이야기를 다룬다. 이는 인수 테스트가 어떻게 프로젝트 기획부터 각 사용자 스토리에 이르는 전체 프로세스에 녹아들 수 있는지 보여준다. 2부: 인수 테스트를 분해하여 세세히 다룬다. 3부: 테스트 표현(test presentation)과 평가(evaluation)라는 일반적인 주제에 대해 다룬다. 4부: 실제 상황에 대한 사례 연구를 다룬다. 일부 상황은 관련이 있는 부분만을 보여주기 위해서 간략화시켰다. 5부: 테스트 설정(Test Setup)을 어떻게 다루는지 등과 같은 좀 더 기술적인 주제에 관해 다룬다. 6부: 업무 가치와 테스트 자동화 같은 추가적인 주제를 부록에 싣는다. ATDD에 대한 요약과 이에 대한 장점을 빠르게 익히고자 하는 독자는 ’25장, 회고와 관점’을 먼저 읽어보기 바란다. 다른 사람의 경험을 들어보고 싶은 독자는 ‘에필로그’를 읽어보기 바란다. ★ 저자의 말 ★ 이 책의 주제는 테스트가 가능한 요구사항으로 소프트웨어를 개발하는 것이다. 테스트 가능한 요구사항은 인수 테스트(acceptance test)에 꼭 필요한 사항이다. 인수 테스트가 소프트웨어의 개발 방향을 정하기 때문이다. 많은 개발자가 이미 경험했듯이 요구사항을 구현하기 전에 인수 테스트를 먼저 생성해야 오류를 줄이고 생산성을 높인다(후반부 ‘에필로그’ 절의 예제 참조). 무엇이 구현되어야 하는지 명확하게 하기 위해 고객/업무 분석가, 개발자, 테스터는 인수 테스트를 함께 만들어낸다. ATDD에서 양질의 제품을 생산하기 위해서는 실제 테스트할 수 있을 만큼의 명확한 요구사항이 있어야만 한다. 예를 들어 이 책이 여러분이 원하는 것을 만족시켜준다는 걸 판단할 기준이 있는가? 이 책을 다 읽고난 후에 어떻게 이 책이 당신의 기준들을 만족시켰는가? 이 책은 독자가 원하는 질문들에 대한 구현 방법을 보여준다. 여러분은 이미 이 책을 읽는 중이기 때문에 이 책의 인수 테스트 기준에 영향을 끼칠 기회가 없을 것이므로, 독자가 필요로 하는 기준이 무엇인지 내가 다음과 같이 정리해봤다. 영어 수업에서 선생님은 육하원칙(누가, 무엇을, 언제, 어디서, 왜, 어떻게)을 강조한다. 그래서 이 책도 다음과 같이 육하원칙 하에 그 기준을 만들어봤다. ■ 누가 인수 테스트를 생성하는가 ■ 인수 테스트란 무엇인가 ■ 언제 인수 테스트가 생성돼야 하는가 ■ 어디에 인수 테스트가 사용돼야 하는가 ■ 인수 테스트 주도 개발은 왜 효과적인가 ■ 어떻게 인수 테스트를 생성하는가 이 책을 다 읽을 즈음에는 어떻게 테스트 가능한 요구사항이 소프트웨어 개발 프로세스를 좀 더 즐겁게 (혹은 좀 덜 고통스럽게) 만들고, 양질의 제품을 생산하는 데 도움을 주는지 이해할 것이다. ★ 옮긴이의 말 ★ “이건 사양이 정해졌어야 하는데…” 프로젝트 관리자나 개발자, 또는 품질보증담당자로 테스트를 진행해본 경험이 있는 사람이라면, 소프트웨어 테스트를 진행하는 중에 사양이 정해지지 않아서 곤란했던 경험이 한 번씩은 있을 것이다. 이러한 경험이 있다면 꼭 이 책을 읽어보기를 권한다. 개인적으로 애자일, 특히 테스팅에 관심이 많아서 이 책의 번역 제의가 들어 왔을 때, 선뜻 번역을 맡겠다고 이야기했다. 하지만, 번역을 진행하고 책을 꼼꼼히 읽으면서 이 책은 굳이 애자일에 관심이 없더라도, 소프트웨어 개발과 관련된 업무를 하고 있는 사람이라면 한 번쯤 읽어볼 만하다고 생각하게 되었다. 이 책은 요구사항을 결정해주는 고객과 이를 기반으로 소프트웨어를 구현하고 검증해야 하는 개발자와 테스터 간의 ‘긴밀하고 타이트한 협력’과 ‘빠른 피드백’을 강조하기 위해서 ‘린 애자일(Lean Agile)’이라는 단어를 붙인 듯 하다. 책의 내용은 가상 인물인 샘의 CD 대여점에서 사용할 시스템을 만들어가는 이야기인데, 소프트웨어 시스템을 구축하면서 어떻게 테스트 가능한 요구사항을 도출하는지와 어떤 방식으로 좀 더 명확하게 이를 이끌어내고 정리할 수 있는지를 아주 실질적이고 쉬운 예로 보여준다. 실제로 번역을 진행하면서, “아, 이런 부분은 이렇게 후배사원들에게 설명해주면 좋겠구나”라든가, “개발자들에게 명확한 요구사항의 중요성을 이런 식으로 설명할 수 있겠구나”라고 생각한 부분들이 종종 있었다. 특히 요구사항을 표로 정리하고, 흔히 테스팅 분야에서 이야기하는 결정테이블(decision table) 형태로 표현하고 이를 분리하며 간략화해가는 내용 등은 실제 업무에서 큰 도움이 될 것이라고 생각한다. |
