인수 테스트는 무엇일까?
시기 상조의 정밀도
불확실성의 원칙
- 서류와 실제 시스템의 동작은 다르다.
- 사업부는 요구했던 내용이 실제 시스템에서 돌아가는 모습과 다르다는 것을 깨닫는다.
- 요구사항이 정밀해질수록 최종 구현된 시스템과 초기 요구사항의 차이는 벌어진다.
불안한 추정
- 개발자 또한 정밀도 함정에 빠진다.
- 완벽한 정보로 추정을 한다해도 추정에는 큰 편차가 생긴다.
- 요구사항은 반드시 바뀌기 때문에 초기 정밀도는 고려할 가치가 없다.
- 프로 개발자는 정밀도가 낮은 요구사항을 바탕으로 추정해야 할 때가 많다.
- 곧 말그대로 "추정"일 뿐이다.
- 이를 보강하기 위해 오차 범위를 추가해 불확실성을 이해하게 만든다.
때 늦은 모호함
- 이런 시기상조의 정밀도를 해결하려면 가능한 정밀도를 늦추면 된다.
- 그렇기에 개발 직전까지도 요구사항에 살을 붙이지 않는다. (뭔가 이상하지만 말하지 않음)
- 그런데 이렇게 되면 때늦은 모호함으로 이어진다.
- 이해 당사자들은 필연적으로 의견이 어긋나는 경우가 많다.
- 이를 해결하기 보다는 매끄러운 말솜씨로 우회하는 것을 선호하게 된다. (더 쉬우니까)
- 요구 사항에서 모든 모호함을 제거하는 것은 프로 개발자의 책임이다.
- 이를 처리하는 방법은 단 하나다.
인수 테스트
요구사항이 언제 완료되는지를 정의하기 위해 이해당사자들과 프로그래머들이 힘을 모아 작성하는 테스트
완료에 대한 정의
- "완료"라는 말은 굉장히 모호하다.
- QA배포 준비가 되었다는 것인가?
- 완벽히 확신하여 해당 기능이 배포될 준비가 되었다는 뜻인가?
- 만들고 한번 확인했으나 테스트는 제대로 하지 않은 상태인가?
- 프로 개발자에게 완료에 대한 정의는 단 하나 뿐이다. 즉, 다 됐다라는 뜻이다.
- 모든 코드를 작성했고, 모든 테스트를 통과했음을 말한다. QA전문가와 이해 당사자들이 이를 인수했다는 뜻이다.
- 어떻게하면 이 정도로 높은 완료 수준을 지키면서 다음 Iteration으로 빠르게 넘어갈 수 있을까?
- 위 기준을 만족하는 자동화 테스트를 만들고 통과하면 된다.
의사소통
- 인수 테스트의 목적은 소통, 명확성 및 정밀성이다.
- 개발자, 이해당사자, 테스터 모두 동의함으로써 시스템 행동을 위한 계획을 이해한다.
자동화
- 인수테스트는 언제나 자동화해야 한다.
- 소프트웨어 생명 주기에 수작업 테스트 과정이 있지만, 인수 테스트는 수작업이 되어서는 안된다. 비용때문이다.
추가작업
- 인수테스트를 만드는 작업을 보고는 "이렇게 할일이 많아?"라고 말할 수 있다.
- 하지만 이를 만들지 않았을 때 생기는 수작업 리스트와 비교하면 많은 작업이 아님을 알 수 있다.
- 이는 곧 spec을 명확히 하는 작업일 뿐이다.
- 이렇게 해야만 "완료"라는 의미를 제대로 이해할 수 있다.
누가, 언제 인수 테스트를 작성하는가?
- 이상적이라면 이해 당사자와 QA는 이런 테스트의 작성을 도와야 한다.
- 하지만 현실은 이해 당사자가 이러한 세부 내역 수준을 들여다 볼 시간도 없다. 실제로도 안하고.
- 그래서 그들은 그 책임을 사업 분석, QA, 개발자들에게 위임한다.
- 테스트는 사업 가치를 가진 기능을 설명하기 때문에, 테스트이 행복한 경로를 작성한다.
- QA는 좋지 않은 경로, 경계, 예외, 구석 사례를 작성한다.
개발자의 역할
- 기능 구현은 그 기능의 인수 테스트가 준비되면 시작한다.
- 개발자는 그 테스트를 통과시키는 것이 의무이다.
테스트 협상과 수동적 공격성
- 테스트를 만든 사람도 인간이기에 실수를 한다.
- 이를 보완하도록 협상을 하는 것은 프로개발자의 일이다.
- 가장 나쁜 것은 "테스트가 이렇게 되어 있길래 그냥 했어"이다.
- 이를 수동적 공격이라 한다.
- 명심해야 하는 건 팀이 최상의 소프트웨어를 만드는데 도움을 주는 것이 중요하다는 것이다.
인수 테스트와 단위 테스트
- 인수 테스트는 단위 테스트가 아니다.
- 단위테스트는 프로그래머가 프로그래머를 위해 만드는 것이다.
- 인수 테스트는 사업부를 위해 사업부가 작성한다.
- 사업적 관점에서 시스템의 운영 방법을 구체적으로 표시한 공식 문서이다.
GUI및 다른 문제점
- GUI는 제대로 명세하기 어렵다.
- 미학이라는 것이 주관적이기 때문이다.
- 팁은 GUI 역시 API인 것 처럼 만드는 것이다.
- GUI 역시 하나의 버튼은 하나의 기능을 해야한다는 점에서
지속적 통합
- 모든 단위 테스트와 인수 테스트를 하루에 몇번이라도 실행할 수 있도록 확실히 하라.
- 커밋할 때마다 CI는 빌드를 시작하고 모든 테스트를 실행해야 한다.
- 그리고 그 결과를 모든 인원에게 이메일로 보내야 한다.
출시를 멈춰라
- 언제나 CI가 동작하도록 유지해야 한다.
- CI는 실패하면 안된다.
- 다 멈추고 이것부터 해야 한다.
- 나중에 고치는 것은 시스템의 위험도를 증가시킨다.
결론
- 세부사항에 대한 의사소통은 어렵다.
- 프로그래머와 이해당사자는 더 어렵다.
Reference
Goal, Plan, Execute.