specification by example

전통적으로 올바른 제품을 만들려면 방대한 기능 명세, 문서화, 그리고 오랜 기간에 걸친 테스트 단계가 필요했다. 하지만 요즘처럼 주 단위로 SW를 출시하는 시대에는 이런 방법이 통하지 않는다. 따라서 다음과 같은 해결책이 필요하다.

• 지나친 명세화는 피한다. 실제 개발에 들어가기도 전에 변경될지도 모르는 세부 사항을 정의하느라 시간을 허비하지 않는다.

• 시스템이 수행하는 내용을 설명하는 신뢰할 만한 문서를 만든다. 그러면 시스템을 쉽게 변경할 수 있다.

• 명세에 정의된 대로 시스템이 실행되는지 효율적으로 점검한다.

• 최소한의 유지보수 비용으로 문서를 적절하고 신뢰할 수 있게 유지한다.

• 앞으로 수행해야 할 작업에 관한 정보를 적기에 공급할 수 있게 모든 것을 짧은 이터레이션과 흐름 기반의 프로세스에 맞춘다.

그리고 프로젝트에서 공통적으로 발견한, SW를 만드는 좋은 방법 중 하나는 바로 예제를 활용한 명세다.

'예제를 활용한 명세'의 이점 1. 변경 작업의 효율화 - 'living documentation’을 활용 2. 재작업 감소 3. 더 나은 업무 배치

명세 정제하기 협업 과정에서 이뤄지는 열린 토로은 모두가 도메인을 이해하는 데 기여하지만 그 결과로 나온 예제는 종종 필요 이상으로 자세히 작성되곤 한다. 이를테면, 비지니스 사용자는 사용자 인터페이스의 관점에서 생각해서 링크를 클릭하거나 입력 필드에 뭔가를 입력했을 때 시스템이 어떻게 동작할지를 예제로 제공한다. 이 같은 장황한 설명은 시스템을 제한하는데, 필요한 바가 무엇인가가 아닌 뭔가가 어떻게 작동해야 하는가를 상세하게 밝히는 것은 낭비이기 때문이다. 불필요하게 상세하게 작성된 예제는 이해하기도 어렵고 의사소통에 사용하기도 힘들다.

cf) '기능 회귀’란 이전에 제대로 동작하던 기능에 문제가 생기는 경우를 말한다. 이러한 현상은 변경 과정에서 의도치 않게 발생한다. 이 같은 현상을 막기 위해 회귀 테스트를 수행하는데, 회귀 테스트는 이전에 실행했던 테스트를 재실행하는 방식으로 수행한다.

리빙 도큐멘테이션

예제를 활용한 명세의 프로세스와 산출물을 살펴볼 수 있는 두 가지 대중적인 모델이 있다. 하나는 '인수 테스트 중심 모델'이고 다른 하나는 '시스템 행위 명세 모델’이다. ‘인수 테스트 중심 모델’은 예제를 활용한 명세 프로세스에서 테스트 자동화 부분에 초점을 맞춘다. 이 모델의 주요 이점은 개발 목표가 분명해지고 기능 회귀가 예방된다는 것이다. ‘시스템 행위 명세 명세 모델’은 시스템의 동작하는 시나리오를 명세화하는 프로세스에 초점을 맞춘다. 이 모델은 협업을 통해 명세를 명확하게 함으로써 이해관계자와 개발팀이 동일하게 이해하는 데 중점을 둔다. 더불어 테스트 자동화를 통해 기능 회귀를 예방하는 것을 중요시한다.

실행된 테스트와 테스트의 목적을 함께 나열하면 회귀 테스트 실패를 조사하는 일이 쉬워진다. (테스트의 목적을 이해할 수 있기 때문에 문제를 더욱 쉽게 해결할 수 있는 것이다)

변화의 시작

품질 향상에 집중하라 프로세스 변화에 대해 저항할 것이 우려되는 경우, 품질 향상을 위한 공개적인 활동에는 크게 불평하지 않는다. 개발자와 테스터가 긴밀히 협업하지 않는 상태에서 인수품질에 대한 이견이 있을 경우 제품 출시와 관련된 활동을 가시화하는 것이 유용할 수 있다.

기능 테스트 자동화부터 시작하라 단지 업무를 떠넘기는 것 아닌가? 개발자가 테스트 자동화에 참여함으로써 테스터의 시간적 여유가 생긴다는 것에 대한 대표적인 반대 의견은 프로그래머가 일을 더하게 되어 기능 개발이 늦어진다는 것이다. 사실 업계의 일반적인 추세는 테스터보다 개발자가 더 많은 팀의 경우 테스터의 업무를 개발자에게 넘기는 것이 그리 나쁘지 않을뿐더러 프로세스의 병목을 제거할 수 있다는 것이다.

시스템에서 가장 위험 요소가 많은 부분부터 자동화를 시작한다. 레거시 시스템 전체에 자동화 테스트를 적용하려는 것은 헛된 노력에 불과하다. 실행 가능한 명세로 나아가기 위한 한 단계로서 기능적 테스트 자동화를 이용한다면 테스트 자동화의 가치를 보여주고 도구에 익숙할 정도만 자동화해도 충분하다. 그 후 변경을 위해 실행 가능한 명세를 구현하기 시작하면 점점 테스트 커버리지가 올라갈 것이다. 초기 기능 테스트 자동화를 최대한 활용하려면 문제가 일어났을 때 많은 비용이 발생할 수 있는 시스템의 위험 요소를 자동화하는 데 초점을 둔다. 그곳에서 발생하는 문제를 예방하는 것은 즉시 가치를 입증할 것이다. 기능 테스트 커버리지가 높다면 팀은 더 확신을 가질 수 있을 것이다. 위험이 덜한 부분을 자동화해서 얻는 효과는 주목받지 못한다.

도구에 집착하지 마라 예제를 활용한 명세는 프로그래머 중심이 아니며, 프로그래머만이 도구를 활용한다면 지속되기 어렵다. 이러한 접근법은 기술적이고 개발자 중심의 테스트를 관리하기 위해 프로그래머가 실행 가능한 명세를 위한 비기술적인 도구를 사용하는 것으로 끝나는 경우가 많다. 이것은 시간 낭비다. 도구에서 얻을 수 있는 이점을 분석하고 가장 쉽게 이점을 누릴 수 있는 방법을 모색해라.

목표에서 범위 도출하기

성공적인 팀은 프로젝트 범위(제품이나 서비스의 기능을 제공하기 위해 수행해야 하는 업무)를 정의하는 책임을 다른 사람에게 떠넘기는 대신 주도적으로 행동하고 적절한 범위를 결정하기 위해 비즈니스 사용자와 협업해서 목표를 달성한다. 이것이 목표에서 범위를 도출하는 핵심이다.

시스템의 기대 결과에서 시작해 범위를 도출하는 방식은 BDD 커뮤니티에서 나온 아이디어다. 그 아이디어는 공통의 문제를 제기할 수 있다는 점에서 최근 많은 주목을 받고 있다. '~로서 ~위해 ~가 필요하다. '

기술적인 기능 명세를 그대로 사용하는 대신 그 기능이 어디에 유용한지 상위 수준의 예를 요청해야 한다. 그러면 실제 문제를 알 수 있다. 그 기능이 유용한 예를 물어보는 것이 좀 더 나은 방법이라고 생각한다. 그것이 왜 필요하냐고 묻는 것은 다소 도전적으로 보여서 다른 사람을 방어적으로 만들 수 있고 특히 규모가 큰 조직일수록 더욱 그렇다. 어떤 기능이 어디에 유용한지를 묻는 것은 누군가의 권위에 도전하지 않고도 논의를 시작하는 데 도움이 된다.