인수 테스트

의사소통 또한 프로 개발자의 임무. 의사소통이 정확하고 도움이 되도록 신경써야 한다!

요구사항 관련 의사소통

흔한 의사소통의 쟁점 = 요구사항

기획 혹은 사업부에서는 자신들이 필요한 것을 설명하고, 그것을 프로그래머가 구현한다. 일반적으론 그렇다.

하지만 그 안을 들여다 보았을 때, 요구사항 관련 의사소통은 엄청나게 어렵고, 그 안에서의 오류가 가득 차 있다.

저자의 경혐

"어떤 기능에 대한 고객들의 예상은 컴퓨터로 구현하고 나서 보면 그 예상이 틀린 경우가 잦다"

어떻게 하면 프로답게 의사소통 하여 효율을 높일 수 있을까?

시기상조의 정밀도

초기에 너무 정확하게 하려 하지 말자. 양쪽이 원하는 정밀도는 현실적으로 불가능하다. 앞서 이야기한 대로 예상이 바뀌는 경우가 매우 잦기 때문.
불확실성의 원칙

요구사항이 실제 동작하는 모습을 보고 나면 더 나은 생각이 떠오르는데, 대게 눈앞의 시스템과는 다르다. 개발 과정을 지키보면 계속 새로운 시각으로 제품을 바라보게 되고.. 결국 초기 기획 요구사항과 최종 구현된 시스템은 차이가 크게 벌어진다.

정리하면. 초기 기획을 아무리 정밀도 있게 하더라도 실제 구현되는 과정에서 여러가지 노이즈가 있기에 최종 구현체는 언제나 불확실 하다는 이야기 이다. 따라서 시기상조의 정밀도의 정도를 잘 생각해야 한다.
불안한 추정 = 시기상조의 정밀도
때늦은 모호함

시기상조의 정밀도를 해결하려면 정밀도를 늦추면 되지만, 모호함이 생긴다. -> 요구사항의 모호함은 이해당사자들 간의 논쟁을 대변한다.

관련 예는 책의 "7장 153쪽" 을 참고하도록 하자. (모호함 때문에 고객의 요구사항이 잘못 구현되었다.)

샘, 폴라, 피터 = 프로그래머
칼 = 고객

샘 & 폴라 : 로그를 매일 자정에 서브 디렉토리에 백업을 하자.
폴라 to 피터 : 파일명은 log.backup 이고, 메일 자정에 백업해
칼 : 로그는 하나도 잃어버리면 안된다. 몇 개월 아니 몇년 후에도 로그파일을 바탕으로 복구할 수 있어야 한다
결론 : 매일 log.backup 이 갱신되고, 이전 로그들은 날라간다. 칼의 요구사항은 구현되지 않았다.

아래부터는 위의 문제들을 어떻게 해결하는지에 대한 이야기이다.

결국 인수 테스트는 필요하다.

요구사항이 언제 "완료"되는지를 정의하기 위해 이해당사자와 프로그래머들이 힘들 모아 작성하는 테스트

게임 업계에서는 아마도 기획자와 프로그래머, QA담당자 일 듯 싶다. 결국 전부 다..ㅋㅋ

"완료"에 대한 정의를 짚고 넘어가자

개발한 그 기능을 배포할 준비가 되었다

QA과정을 거칠 준비가 되었다.

코딩이 다 끝났다.

저자는 "완료"를 "완료" 와 "끝마침"으로 나눴다.

하지만 이게 중요한게 아니라. 프로 개발자에게 '완료'란 '다 되었다' 라는 뜻이고, 모든 테스트를 통과했다 라는 의미이고 QA전문가와 이해당사자들이 이를 인수했다 라는 뜻이다.

이것은 '우리'가 구현한 어떠한 것이 자동화 테스트를 통과 했다는 이야기 이다.

게임 업계에서 "프로그래머 입장에서의 완료"는 개발자가 코딩을 다 끝내고 유닛 테스트 혹은 더미 테스트가 통과한 상태이다.

다시 인수 테스트로 돌아가서,

인수 테스트를 모든 이해 당사자와 프로그래머가 작성을 하면 그 인수 테스트 케이스가 기능 구현 명세서가 될 것이다.

누가, 언제 인수테스트를 작성하는가?

기획자와 QA담당자가, 기능 구현 시작 몇 일 전에. 물론 개발자가 협조해야 한다.

인수테스트 작성이 완료되면 그 이후부터 구현 시작이다.