Acceptance Testing

인수 테스트는 무엇일까?

시기 상조의 정밀도

불확실성의 원칙

• 서류와 실제 시스템의 동작은 다르다.
• 사업부는 요구했던 내용이 실제 시스템에서 돌아가는 모습과 다르다는 것을 깨닫는다.
• 요구사항이 정밀해질수록 최종 구현된 시스템과 초기 요구사항의 차이는 벌어진다.

불안한 추정

• 개발자 또한 정밀도 함정에 빠진다.
• 완벽한 정보로 추정을 한다해도 추정에는 큰 편차가 생긴다.
• 요구사항은 반드시 바뀌기 때문에 초기 정밀도는 고려할 가치가 없다.
• 프로 개발자는 정밀도가 낮은 요구사항을 바탕으로 추정해야 할 때가 많다.
• 곧 말그대로 “추정”일 뿐이다.
• 이를 보강하기 위해 오차 범위를 추가해 불확실성을 이해하게 만든다.

때 늦은 모호함

• 이런 시기상조의 정밀도를 해결하려면 가능한 정밀도를 늦추면 된다.
• 그렇기에 개발 직전까지도 요구사항에 살을 붙이지 않는다. (뭔가 이상하지만 말하지 않음)
• 그런데 이렇게 되면 때늦은 모호함으로 이어진다.
• 이해 당사자들은 필연적으로 의견이 어긋나는 경우가 많다.
• 이를 해결하기 보다는 매끄러운 말솜씨로 우회하는 것을 선호하게 된다. (더 쉬우니까)
• 요구 사항에서 모든 모호함을 제거하는 것은 프로 개발자의 책임이다.
• 이를 처리하는 방법은 단 하나다.

인수 테스트

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

완료에 대한 정의

• ”완료”라는 말은 굉장히 모호하다.
  • QA배포 준비가 되었다는 것인가?
  • 완벽히 확신하여 해당 기능이 배포될 준비가 되었다는 뜻인가?
  • 만들고 한번 확인했으나 테스트는 제대로 하지 않은 상태인가?
• 프로 개발자에게 완료에 대한 정의는 단 하나 뿐이다. 즉, 다 됐다라는 뜻이다.
• 모든 코드를 작성했고, 모든 테스트를 통과했음을 말한다. QA전문가와 이해 당사자들이 이를 인수했다는 뜻이다.
• 어떻게하면 이 정도로 높은 완료 수준을 지키면서 다음 Iteration으로 빠르게 넘어갈 수 있을까?
• 위 기준을 만족하는 자동화 테스트를 만들고 통과하면 된다.

의사소통

• 인수 테스트의 목적은 소통, 명확성 및 정밀성이다.
• 개발자, 이해당사자, 테스터 모두 동의함으로써 시스템 행동을 위한 계획을 이해한다.

자동화

• 인수테스트는 언제나 자동화해야 한다.
• 소프트웨어 생명 주기에 수작업 테스트 과정이 있지만, 인수 테스트는 수작업이 되어서는 안된다. 비용때문이다.

추가작업

• 인수테스트를 만드는 작업을 보고는 “이렇게 할일이 많아?”라고 말할 수 있다.
• 하지만 이를 만들지 않았을 때 생기는 수작업 리스트와 비교하면 많은 작업이 아님을 알 수 있다.
• 이는 곧 spec을 명확히 하는 작업일 뿐이다.
• 이렇게 해야만 “완료”라는 의미를 제대로 이해할 수 있다.

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

• 이상적이라면 이해 당사자와 QA는 이런 테스트의 작성을 도와야 한다.
• 하지만 현실은 이해 당사자가 이러한 세부 내역 수준을 들여다 볼 시간도 없다. 실제로도 안하고.
• 그래서 그들은 그 책임을 사업 분석, QA, 개발자들에게 위임한다.
• 테스트는 사업 가치를 가진 기능을 설명하기 때문에, 테스트이 행복한 경로를 작성한다.
• QA는 좋지 않은 경로, 경계, 예외, 구석 사례를 작성한다.

개발자의 역할

• 기능 구현은 그 기능의 인수 테스트가 준비되면 시작한다.
• 개발자는 그 테스트를 통과시키는 것이 의무이다.

테스트 협상과 수동적 공격성

• 테스트를 만든 사람도 인간이기에 실수를 한다.
• 이를 보완하도록 협상을 하는 것은 프로개발자의 일이다.
• 가장 나쁜 것은 “테스트가 이렇게 되어 있길래 그냥 했어”이다.
• 이를 수동적 공격이라 한다.
• 명심해야 하는 건 팀이 최상의 소프트웨어를 만드는데 도움을 주는 것이 중요하다는 것이다.

인수 테스트와 단위 테스트

• 인수 테스트는 단위 테스트가 아니다.
• 단위테스트는 프로그래머가 프로그래머를 위해 만드는 것이다.
• 인수 테스트는 사업부를 위해 사업부가 작성한다.
• 사업적 관점에서 시스템의 운영 방법을 구체적으로 표시한 공식 문서이다.

GUI및 다른 문제점

• GUI는 제대로 명세하기 어렵다.
• 미학이라는 것이 주관적이기 때문이다.
• 팁은 GUI 역시 API인 것 처럼 만드는 것이다.
  • GUI 역시 하나의 버튼은 하나의 기능을 해야한다는 점에서

지속적 통합

• 모든 단위 테스트와 인수 테스트를 하루에 몇번이라도 실행할 수 있도록 확실히 하라.
• 커밋할 때마다 CI는 빌드를 시작하고 모든 테스트를 실행해야 한다.
• 그리고 그 결과를 모든 인원에게 이메일로 보내야 한다.

출시를 멈춰라

• 언제나 CI가 동작하도록 유지해야 한다.
• CI는 실패하면 안된다.
• 다 멈추고 이것부터 해야 한다.
• 나중에 고치는 것은 시스템의 위험도를 증가시킨다.

결론

• 세부사항에 대한 의사소통은 어렵다.
• 프로그래머와 이해당사자는 더 어렵다.

Reference

• The Clean Coder