자동화 테스트 커버리지를 높이는 방법

by | Jul 6, 2024

자동화 테스트 커버리지란 자동화 테스트를 통해 검증되는 소프트웨어 애플리케이션의 양이다. 보통 백분율의 형태의 숫자로 표시된다. 커버리지가 높다는 의미는, 애플리케이션의 더 많은 부분이 출시 전에 테스트 된고, 최종 사용자가 경험하는 결함의 수가 줄어들고, 소프트웨어 품질이 높아진다는 뜻이다.

자동화 커버리지를 높이는5 가지 실행 단계(Action step) 다음과 같다:

  1. 어느 테스트를 자동화할 것인지 식별한다
  2. 올바른 테스트 수행 도구를 선택한다
  3. 올바른 테스트 커버리지 기술을 선택한다
  4. 자동화 테스트 커버리지를 평가하기 위한 지표를 설정한다
  5. 테스트 유지 관리에 투자한다

1. 어느 테스트를 자동화할 것인지 식별한다

여러분의 팀은 자동화 테스트 수행 도구를 써서 테스트할 것들과 수작업으로 테스트할 것들을 결정할 수 있는 구체적인 가이드라인을 개발해야 한다. 자동화의 범위를 결정하기는 다른 말로 자동화 타당성 분석(Automation Feasibility Analysis)이라고도 부른다.

애자일 테스트 사분면을 사용하면, 여러분은 테스트들을 그 목적에 따라 분류할 수 있다. 개발을 안내하는 기술 중심 테스트는 대부분 자동화에 적합한 대상이다.

다음은 개별 테스트를 위해 고려해야 할 몇 가지 추가 기준들이다:

  • 테스트를 얼마나 자주 반복해야 하는가
  • 기능적 테스트인가 아니면 비기능적 테스트인가
  • 테스트의 규모와 범위
  • 전반적인 테스트 수행의 목표들 그리고 리소스 할당
  • 전반적인 프로젝트의 목표

2. 올바른 테스트 수행 도구를 선택한다

    프로젝트 요구 사항을 먼저 고려한 다음에, 자동화 프레임워크를 결정해야 한다. Selenium, Cypress, Playwright가 가장 잘 알려져 있다. 하지만 여러분의 애플리케이션에 따라, 이것들이 적합하지 않을 수도 있다. 여러분이 직접 여러분에게 필요한 것에 대해 생각해보고 조사해야 한다. 즉, 언어 지원, 플랫폼간 호환성, 사용 편의성 측면을 고려하고 나서 프레임워크를 확정해야 한다.

    똑같은 주의가 테스트 관리 도구를 선택할 때도 필요하다. 요구 사항 커버리지의 경우, 여러분은 요구 사항과 테스트 케이스 간의 연결을 명확하게 시각화 할 수 있는 도구가 필요하다. 예를 들어, TestRail과 같은 도구를 사용하면, Jira 안에 있는 이슈들을 TestRail 안에 있는 특정 테스트 케이스들과 테스트 결과들에 연결할 수 있다. 그렇게 하면, QA 팀과 개발 팀 모두 서로의 작업에 대한 가시성을 확보한다고 보장할 수 있다.

    TestRail & Jira TestRail 아카데미 강좌를 확인해 보자. 효율적인 테스트 수행 절차, 커버리지 추적, Jira와 TestRail을 활용해 개발과 QA 사이의 광범위한 추적 능력을 구축하는 방법에 대해서 배울 수 있다.

    3. 올바른 테스트 커버리지 기술을 선택한다

    커버리지 기술들은 테스트의 특정 영역들 안에 있는 격차들을 파악하는데 도움이 된다.

    일부 QA 팀에서는, 기술(technique)과 지표(metric)를 같은 의미로 보고 같이 사용하기도 한다.

    기술(technique)은 여러분이 커버리지를 측정할 때 사용하는 방식이다. 지표는 실제 측정 그 자체다.

    아래 차트에는, 5가지 일반적인 커버리지 기술들과 그것들이 사용되는 이유다.

    기술(technique)정의사용되는 이유
    제품 커버리지테스트가 제품의 전반적인 기능을 얼마나 잘 평가하는지 측정 한다테스트가 모든 중요한 기능을 커버하는지 확인한다; 복잡하거나, 리스크가 크거나, 제대로 테스트되지 않은 영역을 식별하는 데 도움이 된다.
    요구 사항 커버리지 사용자 스토리들, 기능 요구사항들, 비기능 요구사항들을 해당 테스트 케이스들과 짝을 짓는다. 스토리들과 모든 프로젝트 요구 사항들이 검증되었는지 확인한다.
    리스크 커버리지리스크가 높은 영역을 테스트 활동이 얼마나 잘 커버하고 있는지 살펴본다. 취약한 영역(예: 사용자 인증)을 목표로 하는 테스트를 생성하는데 도움이 된다.
    호환성 커버리지다양한 플랫폼, 브라우저, OS, 기타 다른 기술을 포함하고 있는 테스트들에서 그 수준을 검사한다.여러 가지 환경과 설정들에 걸쳐서, 사용자 경험이 일관성 있게 유지되도록 보장하는데 도움이 된다.
    경계 값 커버리지경계 혹은 극단적인 케이스를 다루는 테스트들에서 그 수준을 살펴본다.입력 범위의 한계로 인한 버그 또는 기타 이슈를 식별하는데 도움을 준다.

    4. 자동화 테스트 커버리지를 평가하기 위한 지표를 설정한다

    테스트 커버리지 지표는 커버리지가 얼마나 완전한지 평가한다. 여러분의 테스트 수행 절차를 평가할 때 고려해야 할 몇 가지 지표는 다음과 같다:

    • 테스트 불안정성 (Test flakiness): 불안정한 테스트가 많다는 것은 코드 또는 테스트 스크립트에 근본적인 문제가 있음을 나타낸다. 불안정한 테스트들을 일관성있게 진단하려면, 여러분은 그런 테스트들을 격리시키고, 이슈를 재현해 봐야 한다.
    • 결함 밀도 (Defect density): 높은 결함 밀도는 여러분의 테스트 수행 데이터 중에서 오류가 발생하기 쉬운 영역을 짚어준다. 이는 커버리지가 부족한 영역을 짚어주기도 한다. 그런 영역들은 자동화가 도움이 될 수도 있다. 또한, 이 영역에 들어 있는 코드가 특히 복잡하다는 의미일 수도 있다.
    • 테스트 실행 시간 (Test execution time): 소프트웨어가 복잡해 질수록 테스트 실행 시간이 증가하는 것은 당연하다. 그런데, 뚜렷한 이유 없이 갑자기 시간이 늘어나는 것에는 주의해야 한다. 이는 테스트 구성에 이슈가 있다는 의미일 수도 있다. 테스트의 전체 실행 시간을 줄이고 싶을 때는, 테스트 병행 수행을 검토해 보는 것도 좋다.
    • CI/CD 파이프라인 안정성 비율 (stability rate): CI/CD 불안정성은 신뢰할 수 없는 테스트 결과로 이어질 수 있다는 점을 여러분이 팀이 인지하고 있는지 확인하자. 불안정성의 근본적인 원인으로는 불안정한(flaky) 테스트들에서부터 외부 API의 문제까지 다양하다.

    5. 테스트 유지 관리에 투자한다

      테스트 유지관리는 전형적으로 스프린트에서 늘 진행되는 절차다. 별도의 특정 단계가 아니다. 이것은 회귀 테스트 수행(regression testing)과 연계되어 작동한다. 그래서 소프트웨어에서 최근에 변경된 사항들을 다룬다.

      테스트 유지 관리에 속하는 몇 가지 활동은 다음과 같다:

      • 테스트들을 추가해서 새 기능이나 요구 사항을 커버하기
      • 테스트들을 업데이트해서 프로젝트의 변경 사항이나 새 테스트 데이터를 반영하기
      • 망가지거나 쓸모 없는 테스트를 제거해서, 불안정한(flaky) 테스트들을 교정하기
      • 과거 테스트 주기에 나타난 결함들을 분석하기

      좋은 테스트 커버리지란 무엇인가?

      좋은 테스트 커버리지에 대한 정의는 상황에 따라 미묘하게 달라질 수 있다.

      일반적으로, 좋은 커버리지란 대개 다음의 특징들을 가지고 있다:

      • 균형 잡힌 다양한 테스트 케이스: 테스트 케이스들의 조합을 정확히 하는 것은 여러분의 테스트 수행 목표들에 따라 달라진다. 하지만, 표준 동작과 예외 상황을 모두 테스트하는 것은 좋은 관행이다. 유닛 테스트 수행의 경우에는 예상하지 못한 값을 사용(예: 숫자 입력시 0 사용)하는 것일 수 있다. 호환성 테스트 수행의 경우에는 다양한 브라우저들에 걸쳐서 테스트를 수행하는 것일 수 있다.
      • 코드 및 기능 커버리지: 좋은 테스트 커버리지는 코드베이스 테스트 수행뿐만 아니라 애플리케이션의 기능에 대한 테스트 수행도 포함된다.
      • 측정할 수 있음(Measurable): 테스트 커버리지는 측정하여 수치화 하는 것이 가능해야 한다. 이는 테스트 전략의 전반적인 상태뿐만 아니라, 요구 사항 커버리지 및 리스크 커버리지 같은 특정 지표를 측정하는 데 있어서도 중요하다.
      • 적용할 수 있음(Adaptable): 자동화된 테스트는 소프트웨어의 현재 상태를 다룰 수 있어야 한다. 개발자가 새로운 기능을 추가하거나 테스터가 새로운 버그를 발견한다고 가정해보자. 그때 테스트가 변경될 수 있어서, 해당 추가 요구 사항을 다룰 수 있어야 한다.
      • 유지 관리가 쉬움: 테스트 커버리지는 유지 관리하기 쉬워야 한다. 품질 자동화 프레임워크와 테스트 관리 소프트웨어를 선택하면 커버리지를 관리하는 시간을 줄일 수 있다.

      테스트 관리 도구로 자동화 테스트 커버리지를 높이는 방법

      테스트 관리 도구는 자동화 테스트 커버리지를 높일 수 있다. 구조화된 프레임워크와 잘 정비된 절차를 제공해 자동화 테스트 케이스를 관리하면 된다. 다음은 TestRail이 자동화 테스트 커버리지를 높이는데 구체적으로 어떤 도움이 되는지를 정리한 내용이다:

      • 중앙 집중식 테스트 리포지토리
        • 중앙 집중식 리포지토리는 수작업 테스트 및 자동화 테스트 케이스를 둘 다 구성을 단순화한다.
        • 자동화 엔지니어들은 자동화 테스트 스크립트를 업로드할 수 있다. 그리고 그것들을 해당 테스트 케이스들과 연결할 수 있다. 그래서 어느 테스트 케이스가 자동화되었는지, 여전히 자동화가 필요한 테스트 케이스가 무엇인지 빠르게 파악할 수 있는 기능과 가시성을 보장한다.

      그림: 하나의 협업 플랫폼에서 자동 및 수작업 테스트 케이스를 계층적 폴더로 구성, 관리, 추적할 수 있다.

      • 테스트 커버리지와 요구 사항 추적
        • 테스트 케이스를 요구 사항 또는 사용자 스토리에 연결하는 기능을 사용하면, 모든 요구 사항 각각을 하나 또는 그 이상의 테스트 케이스에 의해 커버될 수 있다는 점을 보장할 수 있다. 수작업이든 자동화된 테스트든 모두 해당된다.
        • 이 연결을 설정하게 되면, 팀은 자동화에 의해 커버되는 요구 사항들을 추적할 수 있다. 그리고 테스트 커버리지 안에 뼈져 있는 것들을 식별하여 누락된 시나리오들을 자동화 하도록 알려줄 수 있다.
      • 자동화 도구와 통합
        • 다양한 자동화 테스트 도구와의 원활한 통합된다. 예를 들면 Selenium, JUnit, TestNG, 기타 등등과 통합된다. 그렇게 하면, 자동화 엔지니어가 테스트를 TestRail 안에서 직접 시작 시킬 수 있다. 이렇게 통합하면, 절차가 간소화되고, 자동화된 테스트 케이스를 효율적으로 관리할 수 있다.

      그림: 여러분이 Selenium, 유닛 테스트 수행 프레임 워크, 또는 지속적인 통합(CI, continuous integration) 시스템 (예: Jenkins) 등을 사용하든 그렇지 않든, TestRail은 거의 모든 도구와 통합될 수 있다.

      • 버전 컨트롤 통합
        • 버전 관리 시스템과 통합하면, 자동화 스크립트의 변경 사항을 추적할 수 있게 된다. 이를 통해 팀 구성원들 간의 협업이 용이해지며, 자동화된 테스트의 최신 버전을 사용하도록 보장할 수 있다.
      • 테스트 실행 및 일정 관리
        • 자동화된 테스트 실행을 계획하고 일정을 예약함으로써, 특정 시차를 두고 또는 필요할 때마다 광범위한 테스트 커버리지를 확보할 수 있다. 이는 개발 작업 흐름을 방해하지 않는다.
      • 광범위한 리포팅 및 분석
        • 강력한 리포팅 기능을 사용하면, 테스트 커버리지, 통과/실패 상태, 시간 경과에 따른 추세 등에 대한 통찰력을 제공할 수 있다. 이렇게 데이터 기반 접근 방식을 적용하면, 정보에 근거한 결정을 내리는 데 도움이 된다.

      그림: 데이터-기반 의사 결정을 신속히 내릴 수 있다. 테스트 분석 및 리포트를 통해 품질 운영에 대한 전체 그림을 보면서 판달할 수 있다.

      • 협업 및 커뮤니케이션
        • TestRail은 테스트 실행 절차에 대한 실시간 가시성을 제공한다. 그로 인해 프로젝트 이해관계자가 테스트 수행 활동을 모니터링하고, 정보에 근거한 결정을 내릴 수 있도록 한다. 테스터들, 개발자들, 이해관계자가 테스트 결과를 공유하고, 피드백을 제공하며, 효과적으로 커뮤니케이션 할 수 있도록 함으로써 협업을 촉진한다. 궁극적으로는 모두가 자동화 목표에 부합하도록 돕는다. 이를 통해 보다 포괄적인 테스트 커버리지를 확보할 수 있다.

      테스트 커버리지에 있어서는, 언제나 향상시킬 여지가 있다.

      TestRail 아카데미의 강좌 Test Automation & TestRail을 보기 바란다. 여러분의 자동화 프레임워크를 어떻게 TestRail과 통합하는지 배울 수 있다.

      TestRail의 기능을 활용하면, 팀은 자동화 노력을 효율적으로 관리할 수 있다. 또한 커버리지의 격차를 파악하고, 애플리케이션에 대한 보다 높은 수준의 테스트 커버리지를 보장할 수 있다. TestRail 30일 무료 평가판을 지금 바로 시작해 보자.

      자동화 테스트 커버리지 FAQ

      포괄적인 테스트 커버리지가 중요한 이유는 무엇인가?

      좋은 자동화 테스트 커버리지가 투자 대비 높은 이익을 가져다 주는 영역을 살펴보자.

      • 추적성: 자동화 도구를 사용하면 추적성이 향상된다. 의료 분야와 같이 엄격한 규제가 있는 산업 부문에서, 추적성은 여러분의 회사가 규정을 준수하고 있음을 문서화할 수 있는 방법을 제공한다.
      • 확장성: 모듈식 접근 방식을 테스트 수행에서 채택하면, 테스트 커버리지가 유연해진다. 또한 쉽게 확장될 수 있다.
      • 조기 이슈 감지: 테스트 커버리지를 구성해서 애플리케이션의 중요한 영역들을 다루도록 하라. 그러면 이슈를 생산 초기에 파악하는데 도움이 된다.
      • 효율성: 최적화는 중복 테스트를 제거하고, 커버리지 격차를 파악하는 것을 의미한다. 그러면 향후 테스트 시나리오에 리소스를 할당하기에 가장 좋은 환경을 가지게 된다.
      • 리스크 완화: 테스트 커버리지가 철저하다면, 여러분이 보안의 취약점 그리고 기타 사용자 경험에 부정적인 영향을 줄 수 있는 결함들을 놓칠 확률이 더 낮아진다.
      • 팀 신뢰: 요구 사항과 테스트 케이스 사이의 관계를 시각화 하자 (TestRail과 같은 도구를 사용하면 된다). 그러면 테스트에 대한 신뢰가 높아질 것이다.

      테스트 커버리지 vs 코드 커버리지: 차이점은 무엇일까?

      전체 테스트 커버리지와 비교하여, 코드 커버리지는 더 세분화된 지표다. 코드 커버리지는 주로 유닛 테스트에 중점을 두고 있으며, 정량화 하기가 더 쉽다.

      코드 커버리지를 계산하려면, 테스트 스위트가 커버하는 줄 수를 코드베이스 안에 있는 실행 가능한 총 줄 수로 나누면 된다. 여기에 100을 곱하면 커버리지의 백분율을 구할 수 있다.

      코드 커버리지 = (테스트가 커버하는 코드의 줄 수/코드의 총 줄 수) x 100

      이를 더 세분화 하려면, 테스트에 의해 커버되고 있는 분기(branch), 문장(statement), 경로(path)의 수를 살펴보고, 코드베이스의 총 수와 비교하면 된다.

      반면에, 테스트 커버리지는 그 지표가 더 광범위한데 정량화 하기는 더 어렵다. 소프트웨어의 복잡한 특성 때문이다.

      고려해 볼 수 있는 방식 중 하나를 들자면, 여러분의 프로젝트에 정의된 모든 요구 사항들의 목록을 준비한다. 이것을 기준으로 각 요구 사항에 대해 통과한 테스트의 수와 비교한다.

      테스트가 통과한다면 그때마다 해당 요구 사항이 충족되었다는 의미다. 커버된 요구 사항의 숫자를 집계하고, 아래 공식을 사용하여 테스트 커버리지를 계산한다:

      테스트 커버리지 = (충족된 요구 사항의 수/요구 사항의 총 수) x 100

      테스트 커버리지와 코드 커버리지는 용어로는 종종 같은 의미로 사용되는 경우가 있다. 이 둘은 서로 다르면서도 서로 연관된 두 가지 지표다. 그런데, 둘 다 여러분의 자동화 테스트의 성공 여부를 판단할 때 유용하다.

      아래의 차트에는 이 두 용어의 유사점과 차이점이 세분화되어 있다.

      테스트 수행 차원테스트 커버리지코드 커버리지
      정의테스트 수행이 프로젝트 요구 사항 및 기능을 확인하는 정도테스트 수행이 프로젝트 요구 사항 및 기능을 확인하는 정도
      기능 또는 비-기능 테스트 수행기능 테스트 수행과 비-기능 테스트 수행 모두와 관련 있음주로 기능 테스트 수행과 관련이 있다. 하지만, 비-기능 테스트(예: 성능 테스트) 수행에도 유용함
      테스트 유형통합 테스트, 수락 테스트, 회귀 테스트유닛 테스트, 시스템 테스트, 통합 테스트
      관련 도구TestRail(테스트 관리용), Jira(이슈 추적용), Selenium(테스트 자동화용) Coverage.py(파이썬용), JaCoCo(자바용), Istanbul(자바 스크립트용)
      화이트 또는 블랙 박스 테스트 수행블랙 또는 화이트 박스 테스트 수행화이트박스 테스트 수행
      측정 가능성정량화 하기 어려움: 테스트 커버리지는 광범위한 용어이기 때문이다. 여기에는 많은 요소들(요구 사항, 기능, 사용 시나리오)이 들어 있다 공식을 사용하여 쉽게 정량화 할 수 있음

      (원문: Taryn McMillan | December 4th, 2023 | How to Improve Automation Test Coverage)

      다른 기고들

      어느 문서 관리 회사가 테스트 수행을 능률화하고 효율성을 향상시킨 방법: TestRail과 Reflect를 활용

      문서 관리 업계에서 선도적인 회사의 사례다. 이 회사는 클라우드 기반 문서 관리 플랫폼을 통해 디지털 콘텐츠 액세스 및 구성을 능률화하는 데 상당한 진전을 이루었다. 이 회사의 소프트웨어 제품군을 사용하면, 기업은 운영, 양식, 절차, 컨텐츠를 디지털화하고 효율적으로 관리할 수 있다. 25년 이상의 서비스 역사를 자랑하는 이 회사의 솔루션은 주요 주 정부 기관 및 지방 정부 기관 분야에서 광범위하게 활용되고 있다. 이렇게 수많은 기관의 디지털 전환을 밑받침하고 있다. 당면...

      소프트웨어 개발사 ELEKS는 어떻게 가시성과 생산성을 높였을까: Jira와 TestRail을 통합한 사례 연구

      게스트의 글입니다. (작성자: Ostap Elyashevskyy) QA 절차를 처음부터 구축하거나 기존 QA 절차를 개선하는 경우, 올바른 테스트 관리 도구 선택은 매우 중요하다. 그것은 여러분이 버그를 찾고, 테스트 케이스를 관리하는 것을 도와준다. 또한 궁극적으로는, 소프트웨어 개발 절차를 잘 다듬을 수 있도록 돕는다. 이 글에서 나는 ELEKS의 우리 팀에게 효과적인 테스트 관리 솔루션을 찾은 경험을 공유하고자 한다. 그리고 그 과정에서 평가한 다른 몇 가지 대안들...

      애자일 테스트 수행에서의 수락 기준들 (Acceptance Criteria in Agile Testing)

      애자일이라는 직조물(tapestry)에서, 수락 기준은 황금색 실과 같다. 이것은 사용자 스토리를 최종 형태로 연결한다. 이 기준은 테스터가 테스트 수행 전략을 수립하는데 도움이 된다. 그리고 기능 및 품질 보증을 검증하는 데에도 중요한 임계 값 역할을 한다. 수락 기준은 제공된 제품이 고객의 기대에 부합할 것이라고 약속한다. 고객에게 필요한 사항을 정확히 정의하여, 발생 가능한 오해를 줄이고, 더욱 명료하게 한다. 이렇게 고객의 기대치에 맞춰 조율하는 것은 고객 만족으로...