왜 테스트를 자동화하나요? 테스트 자동화를 통해 얻을 수 있는 이점이 무엇일까요?
종종 사람들이 자동화 테스트에 참여할 때, 그들의 주된 초점은 좋은 테스트 설계에서 자동화된 코드가 실제로 테스트를 실행할 수 있도록 하는 것입니다.
팀원들이 제한된 시간 내에 스토리를 전달해야하는 압력을 받고 있는 스프린트 동안, 새로운 기능을 테스트하기 위해 자동화된 테스트 스크립트를 작성하는 것 외에도 계획된 모든 시나리오를 테스트 할 시간이 충분하지 않습니다.
우리는 왜 테스트를 자동화하는지에 대한 중요한 이유를 망각하고 작업, 코딩, 검토, 실행에 대한 세부사항으로 수렁에 빠질 수 있습니다.
테스트를 자동화하는 이유는 무엇입니까?
이것은 테스트 자동화 역할을 위해 후보자를 인터뷰 할 때 묻는 질문 중 하나인데 놀랍게도 많은 후보자가 테스트를 자동화해야하는 주된 가장 중요한 이유를 놓치고 있는 것 같습니다. 후보자들로부터 얻은 답변 중 일부는 상당히 신뢰할 만하지만 내가 찾고 있는 답변은 아닙니다. 위의 질문에 대한 답변 중 일부는 다음과 같습니다.
테스트 범위 증가
이 답변은 매우 유효하지만 적용 범위를 어떻게 정의합니까? 100번의 테스트가 있는 경우 백분율 범위를 어떻게 측정 할 수 있습니까?
성숙한 테스트 자동화 방법을 사용하면 비교적 짧은 시간에 수백 개의 테스트를 실행할 수 있습니다.
이 때문에 더 많은 테스트 사례, 더 많은 테스트 시나리오를 만들고 주어진 기능에 대해 더 많은 입력 데이터로 테스트 할 수 있으며 시스템이 예상대로 작동하고 있다는 확신을 얻을 수 있습니다.
그러나 테스트 및 특히 테스트 자동화에서 더 많은 테스트가 실제로 품질이 향상되거나 버그를 발견 할 가능성이 더 높은 것은 아닙니다.
Martin Fowler의 게시물에서 Test Coverage를 논의하는 곳에서 그는 언급합니다.
만약 당신이 특정 수준의 적용 범위를 목표로 삼으면 사람들이 이를 달성하려고 시도합니다. 문제는 낮은 품질의 테스트로 높은 적용 범위 수치를 찾기가 너무 어렵다는 것입니다. 가장 터무니없는 수준에서는 AssertionFreeTesting이 있습니다. 그러나 그것 없이도 당신은 거의 잘못되지 않는 것들을 찾는 많은 테스트를 받게 되고, 여러분이 정말로 중요한 것들을 시험하는 것을 방해하게 됩니다.
시간 절약
자동화된 테스트가 실행되는 동안 흥미로운 탐색 테스트를 수행하는데 소중한 시간을 할애 할 수 있기 때문에 이 답변도 사실입니다. 그러나 개발된 새로운 기능의 경우 첫 번째 순간에 수동으로 기능을 테스트하는 것보다 자동화된 스크립트를 작성하는 것이 실제로 더 오래 걸릴 수 있습니다.
따라서 자동화된 테스트에서 시간을 절약하려면 자동화된 테스트를 스크립팅하고 코드를 검토하고 자동화된 테스트를 실행하는데 방해가 되지 않도록 초기에 더 많은 노력을 기울여야합니다.
더 많은 버그 찾기
이 답변은 수동/탐색 테스트보다 자동화에 의해 더 많은 버그가 발견되었음을 시사한 어떤 측정 기준도 본 적이 없기 때문에 이 대답은 가끔 나를 걱정스럽게 합니다. 자동화된 테스트는 일반적으로 새로운 코드가 구현된 후 시스템의 회귀 여부를 점검합니다.
기존 기능보다 새로운 기능에서 버그를 발견할 가능성이 항상 더 많습니다. 또한 자동화된 테스트에서 결함을 찾지 못하는 다른 이유들이 있습니다.
수동 테스터 교체
이것은 테스트를 자동화하는 이유와 관련하여 내가 들었던 최악의 답변 일 것입니다. 수동 테스터가하는 것과 자동 테스트가하는 것에는 분명한 차이가 있습니다. 자동화된 테스트는 테스트가 아니라 사실을 확인하는 것입니다.
테스트를 자동화하려면 유효 하거나 유효하지 않은 결과를 확인할 수 있도록 예상 결과를 알아야합니다. 이것이 우리에게 참 또는 거짓, 긍정적 또는 부정적, 합격 또는 불합격을 주는 것입니다.
반면에 테스트는 테스트를 동시에 설계하고 실행하는 조사 연습입니다. 관찰자인 인간만이 테스터를 알아볼 수 있는 곳에서는 다르게 행동 할 수 있습니다.
다른 사고방식과 시스템에 의문을 제기 할 수 있는 능력 때문에 항상 좋은 수동 테스터가 필요합니다.
품질 향상
자동화 된 테스트는 빠른 피드백을 제공하고 응용 프로그램의 상태에 대해 경고해 줄 수는 있지만, 그래서 시스템을 손상시킨 코드 변경을 되돌릴 수는 있지만 자동화된 테스트 자체로는 품질이 향상되지 않습니다. 테스트 자동화가 제대로 되어 있다고 해서 버그가 프로덕션으로 빠져 나가지 않는다고 보장 할 수는 없습니다.
개발 주기의 처음부터 끝까지 올바른 관행을 준수함으로써 품질을 향상시킬 수 있습니다. 품질은 사후 고려대상이 아닙니다. 처음부터 바로 적용하여야 합니다. 제품의 품질을 파악하기 위해 자동화된 테스트에 의존하는 것만으로는 충분하지 않습니다.
테스트를 자동화하는 주된 이유는 무엇입니까?
짧은 대답은 반복성입니다. 우리는 동일한 테스트를 반복해서 수행해야하므로 테스트를 자동화합니다. 테스트를 한 번만 실행하고 잊어버린 경우 테스트를 자동화 하시겠습니까? 당연히 그러면 안 됩니다. 테스트 자동화에 소요되는 시간과 노력으로 수동 테스트를 실행할 수 있습니다.
이제 정의에 따라 반복 실행 테스트, 즉 회귀 테스트를 자주 실행해야 한다는 것을 자동화해야 합니다.
다음에 테스트를 자동화하려는 경우 한 걸음 물러서서 이 테스트를 얼마나 자주 실행할지 생각해 보십시오. 정말로 테스트를 자동화하려는 노력의 가치가 있는건가?
Amir Ghahrai
Founder and Creator of DevQA.io
Sr Test Consultant | CEH | SDET
London, Greater London, United Kingdom
이해를 돕기 위해 도움이 될만한 좋은 글을 소개합니다.
