본문 바로가기

Book

[책] 애자일 테스팅 - 정보문화사

리사테스터와 애자일 팀을 위한 실용 가이드

리사 크리스핀, 자넷 그레고리 지음

김도균, 한동준 옮김


http://blog.naver.com/infopub/100175855844



개발자이지만 회사에서는 아직 폭포수 개발을 하고 있고 애자일은 멀게만 느껴진다.

전에 '불확실성과 화해하는 프로젝트 추정과 계획'이라는 책을 읽을 때에 느꼈던 좋은 것 같은데 막상 실제로 적용을 할 수 있을지 의문이 나는 읽고나서 실천하기 어려운 책이다. 과연 이론과 실제는 하나가 될 수 없나라는 생각이 들기도 하였다.


[책안에서]


[읽기기록]

p.57 전통적인 테스팅 VS. 애자일 테스팅


p.64 애자일 테스터란 누구인가?

 기술은 중요한 요소다. 하지만 자세는 더욱 중요한 요소다. 자넷은 "업무에 대한 올바른 자세가 갖추어지지 않았다면 기술은 의미가 없다"라는 말을 즐겨 한다.


p.71 단순함 지향

켄트 벡(Kent Beck)은 익스트림 프로그래밍에서 동작할 것 같은 방법 중 가장 단순한 것을 하라고 했다. 이 말은 실제로 첫 번째 시도에서 프로그램이 잘 동작해야 한다는 의미라기보다는 그만큼 단순한 모습이어야 한다는 것을 말한다.


p.211 사례와 요구사항을 이끌어내는 도구들

 마이크 콘(Mike cohn) <User Stories Applied> (2004)에서 다음처럼 묘사한 사용자 스토리에 대한 : "역할, 기능, 비즈니스 가치" 패턴을 좋아한다.

(역할)로서 (비즈니스 가치)를 얻기 위해 (기능)을 원한다.

이 형식은 모든 사람에게 잘 맞는 것은 아니므로 우리는 여러분이 실험적인 시도를 해보고 여러분의 상황에서 어떤 일이 최선인지를 파악하기를 권장한다.


p.212

 사례를 통한 원하는 동작을 설명하도록 도와주고 잠재적인 구현 사항들과 파급 효과를 브레인 스토밍하여 요구사항을 테스트로 전환해주는 도구에는 어떤 것이 있을까?

  • 체크리스트
    스티브 퍼킨(Steve Perkins)의 맞춤형 "스토리 체크리스트"
  • 마인드 맵
  • 스프레드시트
  • 모형
  • 흐름도
  • 소프트웨어 기반 도구

p.222~3 행위 주도 개발

 행위 주도 개발이라고 하는 BDD(Behavior-driven development) 도구가 이 목적에 적당한데 그 이유는 테스트 명세용으로  더 자연스런 언어를 사용하기 때문이다. BDD는 테스트 주도 개발의 변형으로 댄 노스(Dan North, 2006)가 처음 개척한 이후 많은 여러 사람들이 발전시켰다.  BDD는 도메인 주도 개발과 관련이 있고 기술보다 도메인에 초점을 맞추고 모델을 사용해 설계를 주도한다. BDD는 "테스트한다"나 "단정한다"는 말 대신 "해야 한다"는 표현을 사용한다.
 이 책을 쓰는 시점에서 사용할 수 있는 많은 BDD 도구의 일부로 자바 플랫폼용 easyb와 JBehave, .NET 용 NBehave와 NSpec, Ruby용 RSpec이 있다.


assertEquals(42.50, order.price(), 0.0)

vs

order.price().shouldBe 42.50


p.327 고통의 고갯마루 - 학습 곡선

 테스트의 자동화를 배우는 것은 어렵다. 특히 투자 대비 많이 얻는 방법은 더 그렇다. 브라이언 매릭(Brian Marick)이 사용한 용어.


p.339 테스트 자동화 피라미드

 많은 테스트 팀에서 컴포넌트, 시스템, 릴리즈 테스트가 코딩 작업이 끝난 후에 순차적으로 시행되는 이른바 "V" 모델을 사용해 왔다.


p.389 이제 시작해 보자

뭔가 시작하는 것을 두려워하지 말자. 성공의 가장 중요한 요소는 일단 시작하는 것이다.


p.411 왜 테스트 계획을 작성해야 할까?

 여러분도 우리가 그랬던 것처럼 전통적인 폭포수 환경에서 일하고 있다면, 아무도 읽지 않고 유지·보수도 하지 않는 거대한 테스트 계획을 작성하느라 시간을 낭비할 것이다. 애자일 개발에서 테스트 계획은 필요한 부분만 작성한다.


p.461 작업량 결정하기

 팀이 이터레이션에서 몇 개의 스토리를 인도할 수 있는지 결정할 때 "코딩을 얼마나 끝냈는가?"가 아니라 "완료한 코딩과 테스팅이 얼마나 되는가?"를 물어야 한다.


p.465 고객과 협업하기

 좋은 의사소통은 보통 할 일을 동반한다.


[읽기기록]

  1. 9/21 ~p.50
  2. 9/23 ~p.74
  3. 9/24 ~p.102
  4. 9/25 ~p.123
  5. 9/26 ~p.152
  6. 9/27 ~p.176
  7. 9/28 ~p.186
  8. 9/30 ~p.242
  9. 10/01 ~p.276
  10. 10/02 ~p.350
  11. 10/04 ~p.412
  12. 10/05 ~p.440
  13. 10/06 ~p.490
  14. 10/07 ~p.533
  15. 10/08 ~p.591 (完)