ITQB CTAL Test Automation Engineer - 6. Transitioning Manual Testing to an Automated Environment

Keyword
confirmation testing, regression testing

6.1 Criteria for Automation

자동화의 기준

전통적으로 조직은 수동 테스트 케이스를 개발해왔다. 자동화 테스트 환경으로 전환하기로 결정할 때는 현재의 매뉴얼 테스트 상태를 평가하고, 이 테스트 자산을 자동화 하는데 가장 효과적인 접근 방법을 결정해야한다. 기존 매뉴얼 테스트의 구조가 자동화에 적합하지 않을 수 있으며, 이 경우에는 자동화를 하기 위해 테스트를 완전히 재작성해야할 수도 있다. 대안으로, 기존 매뉴얼 테스트에서 관련 검포넌트 (입력값, 예상결과, 탐색 경로 등)을 추출하여 자동화에 재사용할 수도 있다. 자동화를 고려한 매뉴얼 테스트 전략은 구조가 자동화로의 전환을 용이하게 하는 테스트여야할 것이다.

모든 테스트를 자동화할 수 있거나, 자동화해야하는 것은 아니며, 때로는 테스트의 첫 번째 반복은 수동일 수도 있다. 따라서 전환을 고려할 두 가지 측면이 있다.

1. 기존 매뉴얼 테스트를 자동화로 초기 변환하는 것
2. 새로운 매뉴얼 테스트를 자동화로 후속 전환하는 것

또한 특정 테스트 타입은 자동화된 방식으로만 효과적으로 실행될 수 있다. 예를 들자면 신뢰성 테스트, 스트레스 테스트, 성능 테스트가 그 예이다.

테스트 자동화를 통해 유저 인터페이스 없이 앱과 시스템을 테스트할 수도 있다. 이 경우, 테스트는 소프트웨어의 인터페이스를 통해 통합 수준에서 수행할 수 있다. 이러한 유형의 테스트케이스도 매뉴얼로 실행은 할 수 있지만 (인터페이스를 트리거하는 수동 명령을 이용) 실용적이진 않을 수 있다. 예를 들어 자동화를 통해 메세지 큐 시스템에 메세지를 삽입할 수 있다. 이런 방법으로 매뉴얼 테스트가 아직 불가능 할 때, 테스트를 일찍 시작하고 결함을 더 빨리 식별해낼 수 있다.

테스트 자동화에 코스트를 투입하기 전에, 테스트의 자동화와 매뉴얼 테스트를 만드는 것의 적용 가능성과 타당성을 고려해야한다. 적합성을 판단하는 기준에는 다음이 포함될 수 있다.

• 사용 빈도
• 자동화의 복잡성
• 도구 지원의 호환성
• 테스트 프로세스의 성숙도
• 소프트웨어 제품 수명 주기 단계에 대한 자동화 적합성
• 자동화 환경의 지속 가능성
• SUT의 제어 가능성

Frequency of use

테스트가 실행되어야하는 빈도는 자동화 할지 말지의 타당성을 결정하는 하나의 고려사항 이다. 메이저 또는 마이너 릴리즈에서 일부로 더 자주 실행되는 테스트는 더욱 자주 사용될 것이기 때문에, 자동화의 더 좋은 후보가 된다. 일반적으로는 앱의 릴리즈 수가 많으면 많을 수록 테스트 자동화의 이점도 커진다. 기능 테스트가 자동화되면 회귀 테스트의 일부로 포함시켜 다음 릴리즈에 사용할 수도 있다. 회귀 테스트에서 사용되는 자동 테스트는 기존 코드 기반에 대한 높은 ROI(높은 투자 수익률)과 리스크 완화를 제공한다.

테스트 스크립트가 1년에 한 번 실행되고, SUT가 그 해 변경되면 자동화된 테스트를 작성하는 것이 실현 불가능하거나 효율적이지 않을 수도 있다. SUT에 맞게 테스트를 매년 조정하는데 걸리는 시간보다 매뉴얼로 테스트를 수행하는게 훨씬 싸게 먹힐 수도 있다.

Complexity to automate

복잡한 시스템을 테스트해야하는 경우, 복잡한 단계를 반복하여 매뉴얼 테스트를 수행하는 어려운 작업을 피할 수 있으므로 자동화하는 이점이 클 수도 있다.

그러나 특정 테스트 스크립트는 자동화하기 어렵거나 구현대비 리소스가 효율적이지 않을 수 있다. 여기에는 SUT가 기존 사용 가능한 자동화 테스트 솔루션과 호환되지 않음, 자동화를 위해 상당한 양의 프로그램 코드를 생성하고 API 호출을 개발해야하는 요구사항, 테스트 실행의 일부로 해결해야하는 시스템의 다중성, 외부 인터페이스 및 독점 시스템과의 상호작용, 사용성 테스트의 일부 사항, 자동화 스크립트를 테스트하는데 필요한 시간 등의 이유가 있다.

Compatibility and tool support 도구 지원의 호환성

서비스를 만드는데 사용되는 개발 플랫폼은 매우 다양하다. 테스트 도구를 사용해야할 테스트 담당자가 어떤 도구가 존재하는지를 알고, 플랫폼이 어느 정도까지 지원되는지를 이해하는것이 중요하다. 조직은 벤더, 오픈소스, 사내 개발 도구 등 다양한 테스트 도구를 사용한다. 각 조직은 테스트 도구를 지원하기 위한 다양한 요구사항과 자원을 가지고 있다. 벤더는 일반적으로 유료 지원을 제공하며, 시장 선도 업체의 경우 테스트 도구 구현을 지원하는 전문가 생태계를 보유하고 있는 경우가 많다. 오픈 소수 도구는 사용자가 정보를 얻고 질문을 게시할 수 있는 온라인 포럼과 같은 지원을 제공할 수 있다. 사내 개발 테스트도구는 기존 직원이 지원을 제공한다.

테스트 도구 호환성 문제를 과소평가해서는 안된다. 테스트 도구와 SUT 간의 호환성 수준을 완전히 이해하지 않고 자동화 테스트 프로젝트를 시작하면 치명적인 결과를 초래할 수 있다. SUT에 대한 대부분의 테스트를 자동화할 수 있더라도 가장 중요한 테스트는 불가능할 수 있다.

Maturity of test process 테스트 프로세스의 성숙도

자동 테스트 프로세스를 효과적으로 구현하기 위해서는 해당 프로세스가 구조화되고, 규율이 있으며 반복 가능해야한다. 자동화는 기존 테스트 프로세스 전체에 개발 프로세스를 도입하는 것으로, 이는 자동화 코드 및 관련 컴포넌트를 관리하는 것이 요구된다.

Suitability of automation for the stage of the software product lifecycle 소프트웨어 제품 수명 주기 단계에 대한 자동화 적합성

SUT는 수년에서 수십 년에 이르는 제품 수명 주기를 가지고 있다. 시스템 개발이 시작되면 시스템은 결함을 해결하고 최종 사용자 요구를 충족하기 위해 개선된다. 시스템 개발 초기 단계에서는 자동화 테스트 솔루션을 구현하기에는 변경이 너무 빠를 수 있다. 화면 레이아웃과 조작이 최적화되고 향상됨에 따라, 동적으로 변경되는 환경에서 자동화를 생성하는 것은 지속적인 재작업이 필요하기 때문에 비효율적이고 비효과적일 수 있다. 이것은 움지이는 차에서 타이어를 교체하려는 것과 비슷하다. 그럴 때는 차가 멈출 때까지 기다리는 것이 좋다. 순차적인 개발 환경에서 대규모 시스템이 안정화되고 핵심 기능을 포함하게 되면, 이 시점에서 테스트 자동화를 수행 시작하는 것이 가장 좋다.

시간이 지나면서, 시스템은 제품 수명 주기의 끝에 도달하고 폐기되거나, 더 새로운 효율적인 기술을 사용하여 재설계된다. 수명 주기 끝에 가까운 시스템에 대해 자동화를 하는 것은 권장하진 않는다. 그러나 기존 기능을 보존하면서 다른 아키텍쳐를 사용하여 재설계되는 시스템의 경우, 데이터 요소를 정의하는 테스트 자동화 환경이 구 시스템과 신 시스템 모두에서 동일하게 유용할 것이다. 이 경우 테스트 데이터의 재사용이 가능하며 신규 아키텍처에 맞게 자동화 환경을 재코딩해야한다.

Sustainability of the environment 환경의 지속 가능성

자동화를 위한 테스트 환경은 시간이 흐름에 따라 SUT 변경에 대해 유연하게 적응할 수 있어야한다. 여기에는 자동화 문제를 신속하게 진단하고 수정하는 능력, 자동화 컴포넌트를 쉽게 유지보수할 수 있는 능력, 자동화 환경에 새로운 기능과 부가 지원을 추가하는 능력이 포함된다. 이러한 속성은 gTAA의 전반적인 설계 및 구현에 통합된 중요한 부분이다.

Controllability of the SUT (preconditions, setup and stability)

TAE는 효과적인 자동화 테스트 생성에 도움이 되는 SUT의 제어 및 가시성 특성을 식별해야한다. 그렇지 않으면 자동 테스트는 UI 상호 작용에만 의존하게 되어 유지 관리가 덜 용이한 자동화 테스트 솔루션을 초래한다. 테스트 가능성과 자동화 설계에 대한 자세한 내용은 섹션 2.3을 참고한다.

Technical planning in support of ROI analysis, ROI 분석 지원을 위한 기술 계획

테스트 자동화는 테스트 팀에 다양한 수준의 혜택을 제공할 수 있다. 그러나 효과적인 자동화 테스트 솔루션을 구현하려면 상당한 노력과 비용이 필요하다. 테스트를 자동화하는데에 소요되는 시간과 노력을 들이기 전에, 테스트 자동화를 구현하는데에 의도한 잠재적 전체 혜택과 결과를 평가하는 것이 수행되어야한다. 이를 결정한 후에는 그러한 계획을 효과적으로 수행하기 위해 필요한 활동이 정의되고 관련 비용을 포함하여 ROI를 계산하여야 한다.

---

자동화 환경으로의 전환을 적절히 준비하기 위해 다음 내용을 다루어야한다.

• 테스트 환경에서 자동화를 위한 도구의 가용성
• 테스트 데이터 및 테스트 케이스의 정확성
• 테스트 자동화의 범위
• 패러다임 변화에 대한 테스트팀의 교육
• 역할과 책임
• 개발자와 테스트 자동화 엔지니어간의 협력
• 병렬 리소스
• 테스트 자동화 리포팅

Availability of tools in the test environment for test automation

선택한 테스트 도구는 설치되고 테스트 환경에서 제대로 동작하는지 확인해야한다. 여기에는 서비스 팩 혹은 릴리즈 업데이트를 다운로드하고 SUT를 지원하는 데 필요한 적절한 설치 구성을 선택하여 자동화 개발 환경과 비교하여 테스트 환경에서 TAS가 올바르게 동작하는지를 확인하는 작업이 포함될 수 있다.

Correctness of test data and testcases

매뉴얼 테스트 데이터와 테스트 케이스의 정확성과 완전성은 자동화에서 예측 가능한 결과를 제공하기 위해 필수적이다. 자동화된 테스트는 입력, 탐색, 동기화 및 검증을 위한 명시적인 데이터가 필요하다.

Scope of the test automation effort

자동화에서 초기 성공을 보여주고 진행에 영향을 미칠 수 있는 기술적 문제에 대한 피드백을 얻기위해, 제한된 범위로 시작하는 것이 향후 자동화 작업을 용이하게 한다. 파일럿 프로젝트는 전체 시스템 상호 운용성을 대표하는 시스템 기능의 한 영역을 대상으로 할 수 있다. 파일럿에서 얻은 교훈은 향후 시간 추정 및 일정 조정에 도움이 되며, 전문 기술 자원이 필요한 영역 파일럿 프로젝트는 초기 자동화 성공을 빠르게 보여주어 추가 관리 지원을 강화한다.

이를 돕기 위해 자동화할 테스트 케이스는 현명하게 선택해야한다. 자동화하는 데 많은 노력이 필요하지 않으면서 높은 부가가치를 제공하는 케이스를 선택해야한다. 자동 회귀 테스트 또는 스모크 테스트는 자주 실행되므로 상당한 가치를 추가할 수 있다. 또 다른 좋은 후보는 신뢰성 테스트이다. 이러한 테스트는 종종 여러 단계를 포함하여 반복적으로 실행되어 수동으로 감지하기 어려운 문제를 발견한다. 이러한 신뢰성 테스트는 구현하는 데는 적은 리소스가 필요하지만 매우 빠르게 부가가치를 보여줄 수 있다.

이러한 파일럿 프로젝트는 자동화를 주목받게 하고 (절약한 매뉴얼 테스트 코스트 또는 심각한 문제 식별 등) 추가 확장의 길을 열어줄 수 있다.

게다가, 우선 순위는 조직에 중요한 테스트에 부여해야 하며, 이는 초기에는 가장 큰 가치를 보여줄 것이다. 그러나 파일럿 프로젝트의 일환으로 기술적으로 가장 도전적인 테스트 자동화는 피하는 것이 중요하다. 그렇지 않으면 너무 많은 노력이 자동화 개발에 소비되나 보여줄 결과는 적을 것이다. 일반적으로는 애플리케이션의 많은 부분과 특성을 공유하는 테스트를 식별하면 자동화를 지속할 수 있는데 필요한 모멘텀을 제공할 수 있다.

Education of test team to paradigm shift

테스터들은 다양한 배경을 가지고 있다. 일부는 최종 사용자 커뮤니티에서 온 도메인 전문가 이거나 비즈니스 분석가로 참여한 경험이 있으며, 다른 일부는 시스템 아키텍처를 더 잘 이해할 수 있는 강력한 기술적 역량을 가지고 있다. 테스트가 효과적이기 위해서는 다양한 배경의 조합이 바람직하다. 테스트팀이 자동화 팀으로 전환됨에 따라 역할은 더욱 전문화가 될 것이다. 자동화가 성공하기 위해서는 테스트 팀의 구성 변화를 이해하는 것이 중요하며, 변화에 대한 교육을 일찍 시작하면 역할에 대한 불안감이나 실직에 대한 걱정을 줄일 수 있다. 적절히 다루면 자동화 팀으로의 전환은 테스트 팀의 모든 구성원을 흥분시키고 조직적/기술적 변화에 참여할 준비를 시킬 것이다.

Role and responsibilities

테스트 자동화는 모든 사람이 참여할 수 있는 활동이어야한다. 그러나 모든 사람이 동일한 역할을 가진다는 의미는 아니다. 자동화된 테스트 환경을 설계, 구현 및 유지 관리하는 것은 기술적 특성을 가지기 때문에, 강력한 프로그래밍 기술과 기술적 배경을 가진 개인에게 맡겨야한다. 자동화된 테스트 환경 개발의 결과로는 기술적 및 비기술적 개인 모두가 사용할 수 있는 환경이어야한다. 자동화된 테스트 환경의 가치를 최대화하려면 도메인 전문 지식과 테스트 기술이 필요한 개인이 필요하다. 이들은 적절한 테스트 스크립트를 개발하여 자동화 환경을 구동하고 목표로 하는 테스트 커버리지를 제공한다. 도메인 전문가는 보고서를 검토하고 애플리케이션 기능을 확인하고 기술 전문가는 자동화 환경이 올바르게 동작하고 효율적인지 확인한다. 이러한 기술 전문가는 테스트에 관심있는 개발자일 수도 있다. 유지 보수 가능한 소프트웨어를 설계하는 경험은 테스트 자동화에서 가장 중요하다. 개발자는 테스트 자동화 프레임워크 또는 테스트 라이브러리에 집중할 수 있다. 테스트 케이스의 구현은 테스터에게 맡겨야한다.

Cooperation between developers and test automation engineers

성공적인 테스트 자동화는 소프트웨어 개발팀과 테스터의 참여가 필요하다. 개발자와 테스터는 테스트 자동화를 위해 훨씬 더 긴밀하게 협력해야하며, 개발자는 개발 방법과 도구에 대한 기술 정보를 제공하고 지원 인력을 제공해야한다. 테스트 자동화 엔지니어는 시스템 설계와 개발자 코드의 테스트 가능성에 대해 우려를 제기할 수 있어야 한다. 이는 특히 표준이 준수되지 않거나 개발자가 특이하고 자체 제작된 또는 매우 새로운 라이브러리/객체를 사용하는 경우에 해당된다. 예를 들어 개발자가 선택한 서드 파티 GUI 컨트롤이 선택한 자동화 도구와 호환되지 않을 수 있다. 마지막으로 조직의 프로젝트 관리 팀은 성공적인 자동화 노력을 위해 필요한 역할과 책임의 유형을 명확히 이해해야한다.

Parallel effort

전환 활동의 일환으로, 많은 조직들은 기존 매뉴얼 테스트 스크립트를 자동화하는 과정을 시작하기 위해 병행 팀을 구성한다. 새로운 자동화된 스크립트는 테스트 리소스에 포함되어 매뉴얼 스크립트를 대체한다. 그러나 그렇게 하기 전에 자동화된 스크립트가 대체할 매뉴얼 스크립트와 동일한 내용을 수행하는지 비교하고 검증하는 것이 권장된다.

많은 경우에 자동화로 전환하기 전에 매뉴얼 스크립트에 대한 평가가 수행된다. 이러한 평가의 결과로 기존 매뉴얼 테스트 스크립트를 자동화 하에 더 효율적이고 효과적인 접근 방식으로 재구조화할 필요가 있을 수 있다.

Automation reporting

TAS는 다양한 보고서를 자동으로 생성할 수 있다. 여기에는 개별 스크립트 또는 스크립트 내 단계의 통과/실패 상태, 전체 테스트 실행 통계, TAS의 전체 성능 등이 포함된다. TAS의 올바른 동작에 대한 가시성을 확보하는 것도 중요하여 보고된 애플리케이션 특정 결과가 정확하고 완전하다고 평가될 수 있다. 자세한 내용은 7장 TAS 검증을 참조하라.

6.2 Identify Steps Needed to Implement Automation within Regression Testing

회귀 테스트 내 자동화 구현 단계 식별

회귀 테스트는 자동화 하기에 좋은 기회를 제공한다. 오늘의 기능 테스트가 내일의 회귀 테스트가 되면서 회귀 테스트 케이스 수는 점점 증가하게 된다. 회귀 테스트가 매뉴얼 테스트 팀의 시간과 자원을 초과하기 전에 자동화를 준비해야한다. 다음과 같은 내용들을 고려해야한다.

• 테스트는 얼마나 자주 실행되어야 하는가?
• 각 테스트의 실행 시간은 얼마나 되는가?
• 테스트 간의 기능 중복이 있는가?
• 테스트가 데이터를 공유하는가?
• 테스트가 서로 의존적인가?
• 테스트 실행 전에 필요한 사전 조건은 무엇인가?
• 테스트가 SUT의 몇퍼센트를 커버하는가?
• 테스트가 현재 실패 없이 실행되는가?
• 회귀 테스트가 너무 오래 걸릴 경우 어떻게 해야 하는가?

각 내용들에 대해 상세히 설명하면 아래와 같다.

Frequency of test execution

회귀 테스트의 일부로 자주 실행되는 테스트는 자동화의 좋은 후보이다. 이러한 테스트는 이미 개발되었고 기존 SUT 기능을 실행하며 자동화를 통해 실행 시간을 크게 줄일 수 있다.

Test execution time

각 테스트 또는 전체 테스트 스위트의 실행 시간은 회귀 테스트 내에서 자동화 구현 가치를 평가하는 중요한 요소이다. 시간 소모적인 테스트부터 자동화를 시작하는 것이 하나의 방법이기도 하다. 이렇게 하면 테스트 실행이 더 빠르고 효율적으로 이루어지며, 추가적인 자동 회귀 테스트 실행 주기를 추가할 수 있다. 이로 인해 SUT 품질에 대한 추가적이고 빈번한 피드백을 제공하고 배포 리스크를 줄일 수 있다.

Functional overlap

기존 회귀 테스트를 자동화 할 때, 테스트 케이스 간 기능 중복을 식별하고 가능한 경우 자동 테스트에서는 중복을 줄이는 것이 좋다. 이는 자동화된 테스트 실행 시간의 효율성을 높이는 데 도움이 된다. 종종 자동화를 사용하여 개발된 테스트는 재사용 가능한 컴포넌트 및 공유 데이터 저장소에 의존하기 때문에 새로운 구조를 가지게 된다. 기존 매뉴얼 테스트를 여러 작은 자동 테스트로 분해하거나, 여러 매뉴얼 테스트를 하나의 큰 자동 테스트로 통합하는 것이 적절한 해결책일 수 있다. 수동 테스트를 개별적/그룹으로 평가하여 효과적인 변환 전략을 개발해야한다.

Data sharing

테스트는 종종 데이터를 공유한다. 이것은 테스트가 다른 SUT 기능을 실행하기 위해 동일한 데이터 레코드를 사용할 때 발생할 수 있다. 예를 들어, 테스트 케이스 A는 직원의 사용 가능한 휴가 시간을 확인하고, 테스트 케이스 B는 직원이 직업 개발 목표의 일환으로 수강한 과정을 확인할 수 있다. 각 테스트 케이스는 동일한 직원을 사용하나 다른 파라미터를 확인한다. 매뉴얼 테스트 환경에서는 직원 데이터를 사용하는 각 매뉴얼 케이스마다 직원 데이터가 여러번 중복될 수 있다. 그러나 자동화된 테스트에서는 데이터가 중복되거나 오류가 도입되지 않도록 단일 소스에서 데이터를 저장하고 접근해야한다.

Test interdependency, 테스트 상호 의존성

복잡한 회귀 테스트 시나리오를 실행할 때, 하나의 테스트가 다른 테스트에 의존할 수 있다. 예를 들어 테스트 단계의 결과로 새로운 주문 아이디가 생성될 수 있다. 이 다음 후속 테스트에서는 새로운 주문이 시스템에 올바르게 표시되는지, 주문 변경이 가능한지, 주문 삭제가 성공적인지 확인하려 할 수 있다. 이 경우 첫 번째 테스트에서 동적으로 생성된 주문 아이디 값을 확인하고, 이후 테스트에서 재사용해야한다. TAS 설계에 따라 이러한 문제를 해결할 수 있다.

Test preconditions

테스트 실행 전에 초기 조건을 설정해야 하는 경우가 종종 있다. 이러한 조건에는 올바른 데이터베이스나 테스트 데이터 세트를 선택하거나 초기 값이나 매개변수를 설정하는 것이 포함될 수 있다. 이러한 초기화 단계를 자동화하면, 테스트 실행 전에 이러한 단계를 놓치지않도록 하여 더욱 신뢰할 수 있는 솔루션을 제공할 수 있다. 회귀 테스트를 자동화시킬 때 이러한 사전 조건도 자동화 프로세스의 일부로 포함되어야한다.

SUT coverage

테스트가 실행될 때마다 SUT의 기능 일부가 실행된다. 전체 SUT 품질을 평가하기 위해 테스트는 가장 넓고 깊은 커버리지를 가지도록 설계되어야한다. 코드 커버리지 도구를 사용하여 자동화된 테스트의 실행을 모니터링하고 테스트의 효과성을 정량화하는데 도움이 될 수 있다. 자동화된 회귀 테스트를 통해 시간이 지남에 따라 추가적인 테스트가 추가 커버리지를 제공할 것으로 기대할 수 있다. 이를 측정하면 테스트 자체의 가치를 정량화하는 효과적인 수단을 제공한다.

Executable tests

매뉴얼 회귀 테스트를 자동화하기 전에, 매뉴얼 테스트가 올바르게 동작하는지 확인하는 것이 중요하다. 이를 통해 자동화된 회귀 테스트로 성공적으로 변환할 수 있는 올바른 출발점을 제공할 수 있다. 매뉴얼 테스트가 제대로 실행되지 않으면 (잘못 작성되었거나, 잘못된 데이터를 사용하거나, 현재 SUT 스펙으로 갱신되지 않았거나, SUT 결함으로 인해) 실패 원인을 이해하거나 해결하기 전에 이를 자동화해버리면 비생산적인 비기능 자동 테스트가 생성될 수 있다.

Large regression test sets

SUT의 회귀 테스트 세트는 매우 커질 수 있다. 너무 커져서 테스트 세트를 하루나 주말동안 완전히 실행할 수 없는 경우가 발생할 수 있다. 이 경우 여러 SUT가 사용 가능한 경우, 테스트 케이스의 동시실행이 가능할 수 있다. (PC 프로그램의 경우 문제가 되지 않으나, SUT가 항공기나 우주 로켓인 경우는 다르다) SUT가 부족하거나 비싸서 동시 실행이 비현실적인 경우도 있을 수 있다. 이 경우 회귀 테스트의 일부만 실행하는 것이 하나의 방법일 수도 있다. 시간이 지남에 따라 전체 세트를 결국 실행하게 될 수도 있다. 회귀 테스트 스위트의 어느 붑누을 실행할 지 선택할 때도 리스크 분석을 기반으로 할 수 있다. (SUT의 어느부분이 최근에 변경되었는지 등)

6.3 Factors to Consider when Implementing Automation within New Feature Testing

새로운 기능 테스트에서 자동화 구현 시 고려해야할 요소들

새로운 기능을 위한 테스트 케이스를 자동화하는 것은 구현이 아직 완료되지 않았거나 시작되지 않았기 때문에 일반적으로는 더 쉽다. 테스트 엔지니어는 새로운 기능이 효과적이고 효율적으로 테스트될 수 있도록 개발자와 아키텍트에게 필요한 사항을 설명할 수 있어야 한다.

SUT에 새로운 기능이 도입되면, 테스터는 이러한 새로운 기능과 관련 요구사항에 맞춘 새로운 테스트를 개발해야한다. TAE는 도메인 전문가인 테스트 디자이너의 피드백을 받아, 현재 TAS가 새로운 기능의 요구를 충족할 수 있는지 판단해야한다. 이 분석에서는 기존 접근 방식, 서드파티 개발 도구, 테스트 도구 등이 포함된다.

TAS에 대한 변경 사항은 기존 자동화된 테스트웨어 구성 요소에 대한 영향을 평가하여 변경 또는 추가 사항이 완전히 문서화되고 기존 TAS 기능의 동작이나 성능에 영향을 미치지 않도록 해야한다.

예를 들어, 새로운 기능이 다른 클래스의 객체로 구현된 경우, 테스트웨어 구성 요소를 업데이트하거나 추가해야할 수도 있다. 또한 기존 테스트 도구와의 호환성을 평가하고 필요한 경우 대체 솔루션을 찾아야한다. 키워드 기반 접근 방식을 사용하는 경우, 새로운 기능을 수용하기 위해 추가 키워드를 개발하거나 기존 키워들르 수정/확장해야할 수도 있다.

새로운 기능이 존재하는 환경을 지원하기 위해, 추가 테스트 도구를 평가해야할 수도 있다. 예를 들어 기존 테스트 도구가 HTML만 지원하는 경우 새로운 테스트 도구가 필요할 수 있다.

새로운 테스트 요구사항은 기존 자동화 테스트와 테스트웨어 구성 요소에 영향을 미칠 수 있다. 따라서 변경을 수행하기 전에 기존 자동화 테스트를 새로운 SUT에 대해 실행하여 기존 자동화 테스트의 올바른 동작인하고 기록해야한다. 여기에는 다른 테스트와의 상호 의존성 매핑도 포함되어야한다. 새로운 기술 변화는 현재 테스트웨어 구성요소 (테스트 도구, 함수 라이브러리, API 등)와 기존 TAS와의 호환성을 평가할 필요가 있다.

기존 요구사항이 변경되면 이러한 요구사항을 검증하는 테스트 케이스를 업데이트하는 작업은 프로젝트 일정의 일부가 되어야한다. 요구사항과 테스트 케이스 간의 추적성은 어떤 테스트 케이스를 업데이트해야하는지 나타낼 것이다. 이러한 업데이트는 전체 계획의 일부가 되어야한다.

마지막으로, 기존 TAS가 현재 SUT의 요구사항을 계속 충족할 수 있는지 여부를 결정해야한다. 구현 기술이 여전히 유효한지, 새로운 아키텍처가 필요한지, 그리고 현재 기능을 확장함으로써 이를 달성할 수 있는지 확인해야한다.

새로운 기능이 도입될 때, 테스트 엔지니어가 새로 정의된 기능이 테스트 가능하도록 보장할 수 있는 기회가 있다. 설계 단계에서 스크립트나 테스트 자동화 도구를 사용하여 새 기능을 검증할 수 있는 테스트 인터페이스를 제공하는 계획을 세워야한다. 이 부분은 섹션 2.3을 참고해라.

6.4 Factors to Consider when Implementing Automation of Confirmation Testing

확인 테스트 자동화 구현 시 고려해야할 요소들

확인 테스트는 보고된 결함을 해결하기 위한 코드 수정을 수행한 후에 수행된다. 테스터는 일반적으로 결함이 더 이상 존재하지 않음을 확인하기 위해 결함을 재현하는데 필요한 단계를 따른다.

결함은 이후 릴리즈에서 다시 나타나는 경향을 보인다. (구성관리의 문제일 수도 있다.) 따라서 확인 테스트는 자동화의 주요 후보 중 하나이다. 자동화한다면 확인 테스트의 실행 시간을 줄일 수 있다. 확인 테스트는 기존에 자동화된 회귀 테스트 셋에 추가되어 이것을 보완할 수 있다.

자동화된 확인 테스트는 일반적으로 기능의 좁은 범위를 갖는다. 결함이 보고되고 이를 재현하는 데 필요한 단계를 이해하면, 언제든지 구현할 수 있다. 자동화된 확인 테스트는 자동화된 회귀 테스트 스위트에 통합되거나, 실용적인 경우에는 기존 자동화된 테스트에 포함할 수 있다. 어느 접근법을 사용하던 결함 확인 테스트를 자동화하는 가치는 여전히 유효하다.

자동화된 확인 테스트를 추적하면 결함 해결에 소요된 시간과 사이클 수를 추가로 보고할 수 있다.

확인 테스트 외에도 회귀 테스트가 필요하다. 이는 결함 수정의 부작용으로 새로운 결함이 나타나지는 않는지 확인하기 위해서이다. 적절한 회귀 테스트 범위를 결정하기 위해 영향 분석이 필요할 수도 있다.

---

ref

ISTQB AL TAE Syllabus