테스트자동화의 원칙

테스트자동화의 원칙

 

1) 수동테스트는 없어지지 않는다
2. 수동으로 테스트하여 효과없는 테스트를 자동화해도 소용없다
3) 자동 테스트는 수집한 입력된 정보만 테스트 한다
4. 테스트 자동화의 효용은 비용절감만은 아니다
5. 자동 테스트 시스템은 지속적으로 개발 및 유지보수되어야 한다
6. 자동화 검토는 프로젝트 초반부터 되어야 한다
7. 자동 테스트에서 신종 버그가 발견되는 경우는 드물다
8. 테스트 결과 분석이라는 새로운 작업이 생겨나다

이들 원칙들은 어떤 프로젝트나 시스템 운영 현장에서의 테스트 자동화를 도입하기 전에 유의해야 할 사항(원칙)을 정리한 것 입니다.
앞으로 테스트 자동화를 도입 할 분들이나 도입하고 있는 분들 그리고 도입을 검토하고 계시는 분들이 참고하시면 좋을 것 같습니다.
1) 수동테스트는 없어지지 않는다
테스트 중에서는 원래 자동화 할 수 없는 테스트의 유형이 존재 합니다.(편의성 검사[Usability Test])
시스템에 대해 처음 실행되는 테스트는 테스트 케이스 자체의 성숙도의 관점에서 수동으로 실시하는 편이 테스트 실행 품질이 높은 경우가 많다.
자동화가 잘 진행되고 있는 기능 테스트의 나머지 몇 % 등 테스트를 자동화하는 비용과 이점이 맞지 않는 경우도 있다.
이런 사정으로 수동으로 실시되는 테스트가 없어지는 일은 없다.

2. 수동으로 테스트하여 효과없는 테스트를 자동화해도 소용없다
애초에 테스트 프로세스 특히 테스트 분석, 테스트 설계가 적절하게 이루어지지 않은 테스트는 우수한 테스터가 수동으로 테스트를 실시하였어도 테스트에 기대되는 동작의 보증이나 버그 검출과 같은 효과를 발휘하지 않는다.
하물며 이런 것들은 자동 테스트에 있어서 아무런 소용이 없다.

3) 자동 테스트는 수집한 입력된 정보만 테스트 한다
인간에 의한 수동 테스트는 테스트 케이스의 기술에 대해 놀랄 정도로 광범위한 요소를 암묵적으로 테스트하고 있다.
이에 대하여 조작, 합격 여부 판정을 엄밀하게 기술할 필요가 있는 자동 테스트에서는 자연스럽게 시야는 기술된 것처럼 한정된다.
사용자명과 패스워드를 입력해 로그인하는 등의 테스트가 자동화되고 있다면, 그 자동테스트는 가령 로그인 화면에 표시되는 로고가 경쟁타사의 것이라 해도 그것을 깨닫지 못한다.

4. 테스트 자동화의 효용은 비용절감만은 아니다
만약 테스트 자동화에 의해 어느 정도 비용을 절감할 수 있다면 충분히 성숙한 테스트 케이스가 이미 존재하고 있으며, 그 테스트는 향후 몇 번이나 실행될 예정이고 자동 테스트 개발을 원활하게 진행하기 위한 준비가 완료된 경우와 테스트 순서가 같고 테스트해야 하는 데이터가 방대하게 존재할 경우의 '테스트 실행' 비용이다.
테스트 자동화에는 반복형 개발에서의 세이프티 넷(safety net)으로서의 역할이나 버그 수정일수의 저감, 영향 범위 검토 프로세스의 대체와 같은 개발 액티비티에 대한 효용도 존재하기 때문에 앞에서 서술한 심하게 한정된 국면을 노리는 것보다 승산이 있을지도 모른다.

5. 자동 테스트 시스템은 지속적으로 개발 및 유지보수되어야 한다
테스트 자동화에 관련된 어려움을 10으로 할 때, 자동 테스트 시스템이 완성될 때까지가 3, 나머지 7은 운용에 관한 비용이다.테스트 대상의 변화에 대한 추종, 테스트 케이스, 테스트 유형 자체의 추가, 변경에 대한 적응 등, 지금 있는 것이 지속적으로 효과를 발휘하기 위한 활동은 물론 자동 테스트의 턴어라운드 타임 향상, 신뢰성 향상 등 시스템의 가치를 향상시켜 나가기 위한 활동 등, 해야 할 일은 다양하다.테스트 자동화 시스템의 제공은 프로젝트라기보다 서비스로서 인식해야 한다.

6. 자동화 검토는 프로젝트 초반부터 되어야 한다
자동화를 고려하지 않고 '완성된' 시스템에 대해 자동 테스트를 써 나가는 것은 흔한 테스트 자동화 엔지니어의 고행 중 하나이다.
자동 테스트 시스템이 시스템을 보다 잘 조작, 판정할 수 있도록, 나아가서는 세이프티 넷을 최적의 비용으로 구축하기 위해서는 시스템 측에서 처음부터 검토하고 설계에 포함시켜 둘 필요가 있다.
반복적으로 실행되는 테스트를 미리 알고 있다면 자동화를 전제로 테스트 계획을 책정하면 효과적이다.

7. 자동 테스트에서 신종 버그가 발견되는 경우는 드물다
운용 환경에서 자동 테스트는 기본적으로 고정 또는 한정된 테스트 케이스를 대상으로 하기 때문에 대부분의 종류의 버그는 이미 수정이 완료되어 정상 작동되는 테스트 케이스들이다.
자동 테스트를 실행하는 과정은 이미 사람들에 의해서 많이 수행되어 발견된 것들 일 것이다.
많은 운용 환경에서의 테스트 자동화의 의의는 당연히 정상 수행되어야 할 기능이 무심코 망가졌을 떄 신속하게 발견한느 것에 있다.
단, 순서가 같고 데이터의 종류가 방대한 테스트를 자동화하는 경우, 퍼징, 테스트 패턴을 유기적으로 생성할 수 있는 API 레이어의 테스트, 브라우저나 RDB 등의 버전 업의 영향을 받지 않았음을 확인하는 테스트 등, 몇 가지 예외도 있다.

8. 테스트 결과 분석이라는 새로운 작업이 생겨나다
매뉴얼 테스트에서 버그가 발견된 경우, 그 재현 순서는 명확하기 때문에 인간은 어느 정도의 최적화 후에 즉시 버그를 등록한다.
하지만 테스트 자동화는 실패가 발생 했을 경우 무슨 일이 일어났는지 다시 한 번 인간이 확인할 필요가 있다.
이것이 하루 몇건이라면 운영자는 쉽게 처리 할 수 있으나 수천 건의 테스트 케이스에 대해 수만 건의 실패가 검출되었다고 하자 그것을 종류별로 나누는 작업만으로도 어려움이 있다.
테스트 자동가 확대된 결과 테스트 결과 분석 비용이 늘어나지 않도록 하는 대책이 필요하다. 각 시스템 또는 업무별 담당자 R&R를 주고 자동으로 분류하고 알림을 주는 등