Specification By Example. Introduction

출처 : Specification By Example, Gojko Adzic, Manning

Specification By Example Introduction.

- 결국 개발 프로세스에서 가장 중요한 것은 specification 에 대해 협업하는 방법, 구현 방법, 그리고 테스팅 방법.

Specification by Example.

  Agile acceptance testing 

  Acceptance Test-Driven Development
 

  Example-Driven Development
 

  Specification by Example
 

  Behavior-Driven Development
 

  Story testing

 

- 위의 표현은 모두 같은 말이다. 저자는 Specification by Example 이라는 용어 하나만을 사용할 것이다.

In the real world

- 저자는 interview 와 case study 를 기반으로 이 책을 작성하였다.

Who should read this book?

- agile process 를 시도했지만, 제대로 관리되지 않아 낮은 품질의 제품을 생산하거나, 다시 일하거나, 고객의 요구를 충분히 반영하지 못하고, 이를 반복학습으로서 해결하려고 하는 팀에게 Specification by Example 은 꼭 필요하다.

- agile process 를 통해 실패하는 팀들은 해당 문제를 그 팀만이 직면했으며( rare case 라 생각 ), agile process 는 현실 세계에는 맞지 않는 이론이라고 생각하기도 한다. 하지만 이는 대부분의 팀이 봉착한 문제이다.

What's inside?

- software 에서 best practice 는 없지만, 적용할만한 good idea 는 확실히 있다.

Beyond the basics

- Shu-ha-ri 라는 학습 모델에 기반하자면, 이 책은 Ha level 이다. Ha 는 old rule 을 타파하고, 많은 성공적인 모델이 있음을 보여주는 것이다. Communication gap 을 줄이기 위해서 용어를 확실히 명시할 필요가 있으며, 기초적 학습이 되어 있지 않은 경우는 http://specificationbyexample.com 에서 Bridging the Communication Gap 이라는 PDF 를 무료로 다운로드 받을 수 있다.
 

- 이 책을 통해 Ri 단계에 접근할 수 있다. 하지만 이 책에서는 다루지 않는다.
 

- 참고로 Shu 단계는 반드시 이해해야 한다. 이는 이론적인 내용이다.

This book has no source code and doesn't explain any tools

- 많은 팀들이 tool 을 이용해 Specification by Example 을 automation 하려다가 비효율적인 작업으로 가곤 한다.
 

- 이 책에서는 특정 tool 에 focus 하기 보다는 왜 팀들이 그들의 아이디어를 실현하는데 어려움을 겪는가 에 대한 진짜 이유에 대해 이야기하고자 한다.
 

- 커뮤니케이션과 상호협동이 잘 된다면, 그 다음에 적합한 tool 을 찾는 것이 맞다.

A few words on the terminology

- business user 도 제대로 involve 되기 위해서라도, 가장 적절한 terminology 를 선택하고 통일하여 사용할 필요가 있다.

Why Specification by Example?

- 이제 agile 이란 단어는 어느 곳에도 적용될 수 있어 정확한 의미전달이 어렵다.
 

- BDD( Behavior-Driven Development ) 란 용어도 이곳저곳서 다른 의미로 받아들여진다.
 

- test 란 단어도 가급적 사용하지 않으려 한다. test 란 business user 들은 involve 되지 않은 형태로 생각되어 진다.
 

- 그래서 가장 부정적 영향을 미치지 않고 남을 수 있는 다른 이름 같은 역할인 Specification by Example 을 선택하게 되었다.

Process Patterns

- Specification by Example 은 광범위한 소프트웨어 개발 life cycle에 대한 많은 process pattern 과 elements 들을 가지고 있다.
 

- 어떤 목적을 이루기 위한 process 들은 많고 제각각 이름이 있어 이를 포괄적으로 담을 수 있는 용어를 선택하려고 노력했다.
 

- Specification by Example 의 가장 큰 이슈 중 하나는 누가 what and when 을 기술할 것인가이다.
 

- feature injection 대신 "deriving scope from goals" 
 

- acceptance test 대신에 "test first" 하지만 이는 who 가 빠져있기 때문에 "specifying collaboratively" 를 사용.
 

- write functional test 대신 "illustrating using examples"  결과물은 "key examples"
 

- 모든 test 작성을 "refining the specification" 으로 정의.
 

- "specification with examples". 이라는 용어를 통해 raw data 에 대한 설명을 첨가.
 

- tool 의 강조성을 줄이면서 automating 이란 개념을 포함하기 위해  "automating validation without changing specification" 이란 용어 사용.
 

- system 을 "executable specifications" 라 부름.
 

- regression test 대신 "validating frequently".
 

- System이 무엇을 하는지를 reference로 기술한 것은 code 와 밀접한 관련을 가지면서, business user 와 communication 을 하는데도 중요하게 작용한다. 하지만 많은 시간을 소요한다.
 

- reference 가 의미있기 위해서는 지속적으로 유지보수가 되어야 하며, 코드와 일관되어야 한다. 
 

- "evolving a living document system" 이라는 용어로 reference 의 유지보수를 지칭.