테스트를 자동화할 때에 명심해야할 8가지 항목에 대해 기재해봅니다.
본 글은 아래의 내용을 번역한 것임을 미리 말씀드립니다.
테스트 자동화의 8원칙
아래에서 언급드리는 내용들은 어떠한 현장에서든지 테스트를 자동화한다면 공통적으로 말할 수 있는, 테스트를 자동화하기 전에 유의해야할 사항들을 "원칙" 으로써 테스트 자동화 연구회의 멤버들이 토론한 끝에 도출한 내용입니다.
1. 수동 테스트는 줄어들지 않는다.
Usability(사용성) 등, 애시당초에 자동화할 수 없는 테스트 타입이 존재하기 마련입니다. 시스템에 대해 처음 실행하는 테스트는 테스트 자체의 성숙도의 관점에서 본다면, manual로 실시하는 것이 테스트 자체의 품질이 높은 경우가 많습니다. (익숙하지 않은 사람이 테스트하기에, 사용성의 좋고나쁨에 대해 민감하게 반응할 수 있기 때문)
또한 운좋게 자동화를 진행하여도, 테스트를 자동화하는 코스트에 비해 메리트가 없는 케이스도 있습니다. 이러한 것을 고려한다면, 테스트를 자동화한다고 한들 수동 테스트가 아예 필요하지 않은 것이 아닙니다.
2. 수동으로 실시하여 효과없던 테스트는 자동화해도 무의미하다.
테스트 프로세스, 특히 테스트 분석, 설계단계에서 해당 프로세스가 적절히 수행되지 않은 테스트는, 우수한 테스터가 수동으로 테스트를 실시했다 하더라도, 동작의 보증이나 버그의 확인 등의 효과는 기대하기 어렵습니다. (즉, 테스트 설계부터 잘못되어있을 확률이 높다.)
3. 자동 테스트는 작성한 내용만 테스트할 수 있다.
사람이 직접 수행하는 수동 테스트는, 테스트케이스에 기술된 내용보다 더 넓은 범위를 암묵적으로 테스트합니다. 이에 반해 조작이나 합격/불합격 판정을 엄밀히 기술해야할 필요가 있는 자동 테스트는, 어디까지나 기술되어져 있는 대로 실행할 뿐입니다. ID와 Password를 입력하여 로그인한다. 와 같은 테스트가 자동화되어있다한들, 이 자동테스트는 가령 로그인 화면에 표시되는 로고가 다른 회사의 로고라 할 지라도 검출해낼 수 없습니다.
4. 테스트 자동화의 이점은 코스트 삭감뿐만은 아니다.
만약 테스트 자동화로 인하여 어떠한 코스트를 삭감할 수 있었다고 한다면 그 코스트는, 자동화 하고자하는 테스트는 충분히 잘 짜여진 테스트 케이스가 이미 존재하고 있었을 것이며, 해당 테스트는 이후 몇번이고 실행될 예정이 있고, 자동 테스트의 개발을 원활하게 진행하기 위한 준비가 되어있는 경우와, 테스트의 순서도 같으며 테스트해야할 데이터가 충분히 존재하고 있는 경우의 테스트 실행 의 코스트일 것 입니다.
테스트의 자동화에는 Iteration한 개발에 있어서의 어떠한 안전장치로서의 역할이나 버그 수정 공수의 삭감, 영향범위 Review process의 대체 등과 같은 Development activity의 효과도 존재하기에, 이러한 효과를 노려서도 테스트 자동화를 시도해볼 수 있을 것 입니다.
5. 자동테스트 시스템의 개발은 계속적으로 이루어져야 한다.
테스트 자동화에 드는 비용을 10이라고 가정한다면, 자동 테스트 시스템을 구축하는데에는 3이 소모되고, 나머지 7은 그것을 운용하는데 소모될 것 입니다. 테스트 대상이 변함에 따라 그에 알맞는 유지보수비용 (테스트케이스, 테스트타입 검토, 테스트 대상의 변경에 따른 적절한 대응 들) 필요합니다. 때문에 매우 많은 부분에서 검토해야하고 손이 많이 갑니다. 테스트 자동화 시스템의 구축은, 프로젝트라기 보단 서비스에 가깝게 생각해야할지도 모릅니다.
6. 자동화 검토는 프로젝트 초기에서부터 해야한다.
자동화를 고려하지 않은 시스템에 대해, 자동 테스트를 작성해나가는 것은 흔하게 있는 자동화 엔지니어들의 고통 중 하나입니다. 자동화 테스트 시스템이 테스트 대상 시스템을 보다 더 조작하기 쉽고 판정하기 쉽게 하고자 한다면, 애시당초 테스트 대상 시스템을 초기단계에서부터 자동화 테스트에 대해 검토하고 설계를 했어야합니다. 또한 반복적으로 실행되는 테스트를 미리 알고 있었다면, 자동화를 전제로하여 테스트 설계시에 감안해야할 것 입니다.
7. 자동테스트로 새로운 버그를 찾아내는 것은 극히 소수이다.
이미 운용중인 자동테스트는 기본적으로 이미 실행되었던 테스트 케이스를 대상으로 하기 때문에, 대부분의 버그는 해당 테스트케이스를 처음 실행했을 과정, 혹은 자동 테스트를 구현하는 과정에서 테스터에 의해 검출되었을 것입니다. 운용중인 많은 자동 테스트들의 정의는, 한 번 동작했었던 기능이 동작하지 않는 것 을 빠르게 확인하기 위함에 있습니다. 단, 순서가 같으며 데이터의 종류가 많은 테스트를 자동화하는 경우는, Fuzzing (프로그램에 예상치 않은 무작위 데이터를 입력 ) 이나 사용하는 소프트웨어의 version up의 영향을 받지 않는지를 확인하는 등의 예외는 있습니다.
8. 테스트 결과 분석이라는 새로운 업무가 발생한다.
수동테스트가 버그를 찾아내는 경우, 대부분 해당 버그의 재현 순서를 확실히 알고 있기 때문에, 그 자리에서 관계자들에게 공유를 합니다. 단, 자동화 테스트가 실패하는 경우, (Fail발생)에는 무엇이 일어난 것인지 사람이 직접 확인해야할 필요가 있습니다. 이것이 하루 몇 개 수준이라면 괜찮을지도 모릅니다만, 자동화 테스트의 범위가 점점 더 커져, 수 만건의 테스트케이스에 대해, 수 천건의 Fail이 발생했다고 한다면 그것들을 종류별로 분류하는 작업만으로도 큰일일 것 입니다. 자동화 테스트가 커지면 커질수록, 테스트 결과 분석에 드는 비용도 같이 커져만 갑니다.
Ref
