ITQB CTAL Test Automation Engineer - 5. Test Automation Reporting and Metrics

Keyword
automation code defect density, coverage, traceability matrix, equivalent manual test effort, metrics, test logging, test reporting

5.1 Selection of TAS Metrics

TAS 지표의 선택

이번 절에서는 테스트 자동화 전략, TAS의 효과 및 효율성을 모니터링하기 위해 사용될 지표에 대해 알아본다. 이것은 프로젝트의 테스트 매니저가 SUT와 SUT의 기능 및 비기능 테스트를 모니터링하기 위해 사용하는 SUT 관련 지표와는 별개다. 테스트 자동화 지표는 테스트 자동화 매니저 및 테스트 자동화 엔지니어가 테스트 자동화 목표에 대한 진행상황을 추적하고 테스트 자동화 솔루션의 변경 사항이 미치는 영향을 모니터링할 수 있게 해준다.

TAS 지표는 외부 지표와 내부 지표로 나누어 볼 수 있다. 외부 지표는 TAS가 다른 활동 (특히 테스팅 활동) 에 미치는 영향을 측정하는데 사용된다. 내부 지표는 TAS가 목표를 달성하는데에 얼마나 효과적이고 효율적인지를 측정하는 데 사용된다.

측정된 TAS 지표는 일반적으로 아래를 포함한다.

• 외부 TAS 지표
  • 자동화 이점
  • 자동화된 테스트 작성을 하는데 들어간 리소스
  • 자동화된 테스트 이슈를 분석하는데 들어간 리소스
  • 자동화된 테스트를 유지보수 하는 리소스
  • 실패 대 결함 비율
  • 자동화 테스트 실행 시간
  • 자동화된 테스트케이스의 갯수
  • 성공 및 실패 결과 횟수
  • 오탐 및 미탐의 갯수
  • 코드 커버리지
• 내부 TAS 지표
  • 도구 스크립팅 지표
  • 자동화 코드 결함 밀도
  • TAS 구성 요소의 속도 및 효율성

각각 설명하면 아래와 같다.

Automation benefits, 자동화 이점

TAS의 이점을 측정하고 보고하는 것이 특히 중요하다. 이는 일정 기간 동안 관련된 사람 수로 계산하는 비용은 쉽게 보이지만, 외부 사람들이 이러한 비용을 볼 수는 있어도, TAS의 이점을 알지 못할 수 있기 때문이다.

어떠한 이점이라도 측정은 TAS의 목표에 따라 결정된다. 일반적으로 시간 또는 리소스의 전략, 테스트 수행 갯수의 증가(커버리지 폭이나 깊이 또는 실행 빈도) 또는 반복 가능성의 증가, 자원의 보다 더 나은 활용, 수작업 오류의 감소와 같은 이점을 포함한다. 가능한 측정 기준은 아래를 포함한다.

• 절약된 수동 테스트 시간
• 회귀 테스트 수행 시간의 단축
• 추가 테스트 실행 주기 수
• 추가 실행된 테스트케이스의 갯수 혹은 비율
• 전체 테스트 케이스 중 자동화된 테스트 케이스의 비율 (자동화된 테스트 케이스는 매뉴얼 테스트 케이스와 쉽게 비교할 수는 없음)
• 커버리지의 증가(요구사항, 기능, 구조적)
• TAS로 인해 더 빨리 발견된 결함 갯수 (결함 발견 시의 평균 이점을 알고 있는 경우, 이것은 예방된 비용의 합으로 계산될 수 있음)
• 매뉴얼 테스트로는 발견되지 않는, TAS로 확인된 결함 수 (신뢰성 결함 등)

테스트 자동화는 일반적으로 수동 테스트의 노력을 절약해준다. 이 노력이란, 다른 종류의 매뉴얼 테스트에 사용될 수 있다. 이러한 추가 테스트에서 발견된 결함도 TAS의 간접적 이익이라고 판단할 수 있다. TAS가 없었다면 이러한 테스트는 수행되지 않았을 것이고, 그에 따라 추가 결함도 발견되지 않았을 것이다.

Effort to build automated tests, 자동화된 테스트 작성을 하는데 들어간 리소스

테스트 자동화의 주요 비용 중 하나는 테스트를 자동화하는데에 필요한 노력이다. 이는 종종 동일한 테스트를 매뉴얼로 수행하는 비용보다 더 많이 들며, 따라서 테스트 자동화의 사용 확대를 결정하는 데에 방해가 될 수 있다. 특정 자동 테스트를 구현하는 비용은, 테스트 그 자체에 크게 좌우되나, 사용하는 스크립팅 방법, 테스트 도구에 대한 친숙도, 환경, 테스트 자동화 엔지니어의 기술 수준 등 다른 요소도 영향을 미친다.

더 크거나 더 복잡한 테스트는 짧거나 간단한 테스트 보다 자동화 하는데에 더 오랜 시간이 걸리기 때문에, 테스트 구축 비용을 계산하는 방법 중 하나는 평균 구축 시간을 기준으로 하는 것이다. 이것은 같은 기능을 목표로 하는 테스트나 특정 테스트 레벨에서의 테스트 집합에 대한 평균 비용을 고려하여 더 세분화할 수도 있다. 다른 접근법으로는 구축 비용을 매뉴얼 테스트 수행 노력의 배수로 표현하는 것이다. (Equivalent Manual Test Effort, EMTE ) 예를 들어서 테스트 케이스를 자동화 하는데 매뉴얼 테스트 코스트의 2배가 필요할 수 있다.

Effort to analyze SUT failures, 자동화된 테스트 이슈를 분석하는데 들어간 리소스

자동화된 테스트 실행 중 발견된 SUT 실패를 분석하는 것은 매뉴얼 테스트보다 훨씬 더 복잡할 수 있다. 왜냐하면, 매뉴얼 테스트를 수행하는 테스트 담당자가 실패로 이어지는 어떠한 이슈들을 이미 알고 있는 경우가 많기 때문이다. 이것은 3.1.4의 설계 수준과 5.3, 5.4의 보고 수준에서 설명한대로 완화될 수 있다. 이 측정치는 실패한 테스트 케이스 당 평균으로 표현할 수 있거나 EMTE의 배수로 표현할 수 있다. 후자는 자동화된 테스트가 복잡성 및 실행 길이에 따라 크게 다른 경우에 특히 적합하게 표현할 수 있다.

SUT 및 TAS의 로깅은 실패를 효율적으로 분석하는데 중요한 역할을 한다. 로깅은 효율적으로 분석을 하는 데에 충분한 정보를 제공해야한다. 중요한 로깅 기능은 아래와 같다.

• SUT 로깅 및 TAS 로깅은 동기화되어야 한다.
• TAS는 예상 및 실제 동작을 기록해야한다.
• TAS는 수행할 작업을 기록해야한다.

반면 SUT는 매뉴얼 테스트 혹은 자동 테스트 결과와 관계 없이, 모둔 수행된 작업을 로깅해야한다. 내부 오류는 기록되어야하며 크래시 덤프나 스택 트레이스도 제공되어야한다.

Effort to maintain automated tests 자동화된 테스트케이스를 유지보수하는 코스트

자동화된 테스트를 SUT와 동기화 하는데 필요한 유지 보수 코스트는 매우 클 수 있으며, 궁극적으로는 TAS로 인해 얻는 이점을 초과할 수도 있다. 이것은 많은 자동화 시도의 실패 원인이 되었다. 유지보수 코스트를 모니터링하는 것은 유지보스 코스트가 증가하지 않도록 방지하거나 줄이기 위한 조치를 취할 필요성을 강조하는 데 중요하다.

유지보수 코스트의 측정은 새로운 SUT 버전 배포마다 유지보수가 필요한 모든 자동 테스트 케이스의 총 합으로 표현할 수 있다. 또한 업데이트된 자동 테스트케이스 당 평균으로 표현되거나 EMTE의 배수로 표현될 수 있다. 관련 지표는 유지 보수가 필요한 테스트케이스 수 또는 비율이다.

자동화된 테스트케이스의 유지보수 코스트를 확인할 수 있거나, 파악이 되는 경우에 이 정보는 특정 기능을 구현하거나 특정 결함을 수정할 지 여부를 판단하는 데에 중요한 역할을 할 수 있다. 소프트웨어 변경으로 인한 테스트케이스 유지보수에 필요한 코스트는 SUT의 변경과 함께 고려되어야 한다.

Ratio of failures to defects 실패 대 결함 비율

자동 테스트의 일반적인 문제로는 하나의 소프트웨어 결함으로 인해 많은 테스트가 실패할 수 있다는 점이다. 테스트의 목적은 소프트웨어의 결함을 찾아내는 것이지만, 여러 테스트가 동일한 이슈를 찾아내는 것은 낭비이다. 이것은 특히 자동 테스트의 경우, 각 실패한 테스트를 분석하는 데 필요한 리소스가 꽤나 클 수 있기 때문이다. 주어진 이슈에 대해 실패한 자동 테스트 케이스 수를 측정하면, 이러한 문제가 발생할 수 있는지를 나타낼 수 있다. 해결책으로는 자동 테스트의 설계와 실행을 선택하는 것에 있다.

Time to execute automated tests 자동 테스트 실행 시간

자동 테스트 실행 시간은 결정하기 쉬운 지표 중 하나이다. TAS 초기에는 중요하지 않을 수 있으나, 자동화된 테스트케이스의 갯수가 증가함에 따라 이 지표는 매우 중요해질 수 있다.

Number of automated testcase 자동화된 테스트케이스의 갯수

이 지표는 테스트 자동화 프로젝트의 진행 상황을 나타낼 수 있다. 그러나 자동화된 테스트 케이스 갯구 만으로는 많은 정보를 얻을 수 없다. 예를 들어 테스트 커버리지가 증가했는지 어떤지는 알 수 없다.

Number of pass and fail results 성공 및 실패 갯수

이것은 일반적인 지표로, 자동화된 테스트가 성공한 횟수와 예상 결과를 달성하지 못한 횟수를 추적한다. 실패는 SUT의 결함으로 인한 것인지, 환경 문제나 TAS 자체의 문제로 인한 것인지는 분석해야한다.

Number of false-fail and false-pass results 오탐 및 미탐 갯수

여러 이전 지표들에서 보았듯, 테스트 실패를 분석하는 것은 상당한 시간이 걸릴 수 있다. 이것은 문제가 SUT가 아 TAS 또는 테스트케이스에 있을 때 더욱 좌절하게 될 것이다. 잘못된 실패 false-fail 의 갯수는 낮아야하며, 이것은 TAS에 대한 신뢰도를 낮출 수 있다. 반대로 실패했지만 찾지 못하는 경우 false-pass 의 경우는 위험하다. 이 경우가 발생하게 되면 SUT에 결함이 있었지만 자동 테스트가 이것을 식별해내지 못해 PASS 결과로 통보하게 된다. 이 경우 잠재적인 이슈를 탐지해내지 못하게 된다. 이것은 확인이 제대로 이루어지지 않거나 잘못된 테스트 오라클을 사용했거나 혹은 테스트 케이스가 잘못된 기대결과를 가졌을 수도 있다.

오탐의 경우 테스트 코드의 결함 (자동 테스트코드 결함 밀도 참조) 으로 인해 발생할 수도 있으나, 불안정한 SUT로 인해 발생할 수도 있다. Test hook의 침입 수준도 오탐을 유발할 수 있다.

Code coverage

다양한 테스트케이스가 제공하는 SUT의 코드 커버리지를 아는 것은, 유용한 정보를 얻을 수 있다. 이것은 회귀 테스트 스위트의 코드 커버리지와 같은, 높은 수준에서 측정될 수 있다. 적절한 커버리지를 나타내는 절대적인 비율은 없으며, 가장 단순한 소프트웨어를 제외하고 100% 코드 커버리지는 달성할 수 없다. 그러나, 일반적으로 커버리지가 높을수록 소프트웨어 배포의 전반적인 리스크가 감소하므로 커버리지가 높으면 높을 수록 좋다고 여겨진다. 이 지표는 SUT의 활동을 나타낼 수도 있다. 예를 들어 코드 커버리지가 감소하면, 신규 기능이 SUT에 추가되었으나 해당 테스트 케이스가 자동화 테스트 스위트에 추가되지 않았음을 의미할 수 있다.

Tool scripting metrics

자동화 스크립트 개발을 모니터링하는데 이용할 수 있는 많은 지표가 있다. 대부분은 SUT 소스 코드 지표와 유사하다. 코드 라인(Line of Code, LOC) 과 순환 복잡도는 지나치게 크거나 복잡한 스크립트를 강조하여 재설계가 필요할 수 있음을 의미할 수 있다.

주석과 실행 가능한 코드의 비율은 스크립트의 문서화 및 주석의 범위를 나타낼 수 있다. 스크립트 표준에 대한 비준수 항목의 갯수는, 해당 표준이 얼마나 잘 준수되고 있는지를 측정할 수 있게해준다.

Automation code defect density 자동화 코드 결함 밀도

자동화 코드는 SUT의 코드와 다를 것 없이, 결함을 포함할 수 있는 소프트웨어다. 자동화 코드가 SUT코드보다 덜 중요하게 취급되어서는 안된다. 좋은 코딩 실습과 표준이 적용되어야 하며, 결과는 코드 결함 밀도와 같은 지표로 모니터링 되어야 한다. 이 지표는 구성관리 시스템의 지원으로 더 쉽게 수집할 수 있다.

Speed and efficiency of TAS components TAS 컴포넌트의 속도와 효율

동일한 환경과 동일한 테스트 단계를 수행하는 데 걸리는 시간의 차이는 SUT에 문제가 있음을 나타낼 수 있다. SUT가 동일한 기능을 동일한 시간 내에 수행하지 않는다면 확인이 필요하다. 이것은 시스템에 허용되지 않는 변동성이 있을 수 있음을 나타내며, 부하가 증가되면 더 악화될 수 있다. TAS는 SUT의 성능을 저해하지 않을 만큼 충분히 잘 동작해야한다. 만약 SUT의 성능이 중요한 요구사항인 경우에, TAS는 해당 요구사항을 고려하여 설계되어야한다.

Trend metrics

위와 같이 많은 지표에서 특정 시간의 측정값보다 시간 경과에 따른 변화 방식(추세)가 더 가치가 있을 수 있다. 예를 들어 유지보수가 필요한 자동 테스트케이스 당 평균 유지보수 코스트가, 이전 2번의 릴리즈의 SUT보다 증가했다는 것을 알게되면, 증가 원인을 파악하고 이러한 흐름을 역전시키기 위한 조치를 취해야할 수 있다.

측정 비용은 가능한 낮아야하며, 이것은 종종 수집 및 리포트의 자동화를 통해 달성할 수 있다.

---

5.2 Implementation of Measurement

테스트 자동화 전략의 핵심은 자동화된 테스트웨어이며, 자동화된 테스트웨어는 사용 정보를 기록하도록 기능을 적용할 수 있다. 추상화가 구조화된 테스트웨어와 결합된 경우, 기본 테스트웨어에 적용된 모든 개선 사항은 상위 수준의 모든 자동화 테스트 스크립트에 적용될 수 있다. 예를 들어 테스트 실행의 시작 및 종료 시간을 기록하도록 기본 테스트웨어를 개선하면, 모든 테스트에 적용될 수 있다.

Feature of automation that support measurement and report generation

많은 테스트 도구의 스크립트들은 개별 테스트, 테스트 셋 및 전체 테스트 스위트에 대해 실행 전, 중, 후에 정보를 기록하고 로그로 남길 수 있는 기능을 통해 측정 및 리포트를 지원한다.

각 테스트 실행 흐름에 관한 리포트는 이전 테스트 실행 결과를 고려하여 트렌드 (예를 들면 테스트 성공률의 변화) 를 강조할 수 있는 분석기능을 갖추어야한다.

자동화된 테스트는 일반적으로 테스트 실행과 테스트 검증의 자동화 둘 다 필요하며 후자의 경우, 테스트 결과의 특정 요소를 사전에 정의한 기대 결과와 비교하여 달성할 수 있다. 이 비교는 일반적으로는 테스트 도구에 의해 수행되는 것이 제일 좋다. 이 비교의 결과로 보고되는 내용에 대해서는 고려되어야한다. 테스트의 상태 (통과 혹은 실패)가 정확하게 결정되는 것이 중요하다. 실패의 경우에는 실패 원인에 대해 스크린샷등과 같은 더 많은 정보들이 필요하다.

테스트의 실제 결과와 예상 결과에서 예상되는 차이를 구별하는 것이 항상 사소한 것은 아니지만 도구 지원은 예상치 못한 차이를 강조하면서 예상되는 차이(예: 날짜 및 시간)를 무시하는 비교를 정의하는 데 큰 도움이 될 수 있습니다.

Integration with other third party tools (Spreadsheets, XMl, documents, databases, report tools, etc.)

자동화된 테스트케이스 실행의 정보가 다른 도구에서 사용될 때, 이 정보를 서드파티 도구에 적절한 형식으로 제공하는 것이 가능하다. 이것은 종종 기존 테스트 도구 기능을 통해 이루어지거나, 다른 프로그램과 일치하는 형식으로 출력되는 맞춤형 보고서를 생성하는 것으로 달성할 수 있다.

Visualization of results (dashboards, charts, graphs)

테스트 결과는 차트로 시각화되어야한다. 테스트 실행의 문제를 나타내기 위해 색상을 사용하는 것을 고려해야한다. 예를 들어 테스트 실행/자동화의 진행 상황을 표시하기 위해 신호등 색상을 사용할 수 있다. 관리자는 테스트 결과를 한 눈에 보기 위해 시각적 요약에 특히 관심이 있으며, 더 많은 정보가 필요할 때 세부 사항을 탐색할 수 있다.

---

5.3 Logging of the TAS and the SUT

로깅은 TAS에서 매우 중요하며, 테스트 자동화 자체와 SUT에 대한 로깅을 포함한다. 테스트 로그는 잠재적 문제를 분석하는데에 자주 사용되는 소스다. 다음 섹션에서는 TAS 또는 SUT로 분류된 테스트 로깅의 예를 설명한다.

TAS 로깅 (TAF 또는 테스트 케이스 자체가 정보를 로깅하는지 여부는 중요하진 않으며 상황에 따 다름) 은 아래를 포함해야한다.

• 현재 실행중인 테스트케이스, 시작 및 종료 시간
• 테스트 케이스의 실행 상태.
  • 실패는 로그파일에서 쉽게 식별할 수 있으나 프레임워크 자체도 이 정보를 가지고 대시보드를 통해 보고할 수 있어야한다. 테스트케이스의 실행 상태는 PASS/FAIL 또는 TAS의 오류일 수 있다. TAS 오류는 문제가 SUT에게 있지 않은 상황에서 사용된다.
• 주요 단계의 타이밍 정보를 포함한 고 수준의 테스트 로그 세부사항
• 타사 도구의 도움으로 테스트케이스가 식별한 SUT의 동적 정보 (메모리 누수 등)
  • 이러한 동적 측정의 실제 결과와 실패는 이슈가 감지되었을 때 실행중이었던 테스트 케이스와 함께 기록되어야한다.
• 신뢰성 / 스트레스 테스트의 경우 실행되는 횟수를 기록해야하며, 테스트 케이스가 몇 번 실행되었는지 쉽게 확인할 수 있도록 해야한다.
• 테스트 케이스에 무작위 요소가 포함되어있는 경우 (랜덤 파라미터, 랜덤 스텝 등)에는 무작위 번호, 선택을 기록해야한다.
• 테스트 케이스가 수행하는 모든 액션은 로그 파일을 확인하고 정확히 동일한 단계와 동일한 타이밍으로 테스트를 다시 실행할 수 있도록 기록되어야한다.
  • 이것은 식별된 실패의 재현 가능성을 확인하고 추가 정보를 수집하는 데 유용하다.
  • 테스트 케이스의 작업 정보는 고객이 시결한 문제를 재현할 때 사용할 수 있도록 SUT 자체에 기록될 수 있다.
• 테스트 실행 중에 스크린 샷 및 기타 시각적 캡쳐를 저장하여 실패 분석 중에 사용할 수 있어야 한다.
• 테스트 케이스가 실패할 때마다 TAS는 문제를 분석하는 데 필요한 모든 정보가 이용 가능하도록 저장하고 테스트가 계속되는 경우 관련 정보를 포함해야한다.
  • 관련 크래시 덤프와 스택 트레이스 로그도 저장해야한다. 덮어쓸 수 있는 모든 로그 파일은 나중에 분석할 수 있도록 복사되어야한다.
• 색상을 사용하여 다른 유형의 기록 정보를 구분할 수 있어야 한다.

SUT 로깅은 아래를 포함해야한다.

• SUT가 문제를 식별할 때, 문제를 분석하는 데 필요한 모든 정보를 기록해야한다.
  • 날짜, 시간 스탬프, 문제의 소스 위치, 오류 메세지 등
• SUT는 모든 사용자 상호작용을 기록할 수 있다. 이렇게 하면 고객이 식별한 문제를 제대로 분석할 수 있으며 개발은 문제를 재현하려고 시도해볼 수 있따.
• 시스템 시작 시, 구성 정보는 파일로 로깅되어야하며 여기에는 소프트웨어/펌웨어 버전, SUT의 구성, 운영 체제의 구성 등이 포함된다.

모든 다양한 로깅 정보는 쉽게 검색할 수 있어야한다. TAS가 로그 파일에서 식별한 문제는 SUT의 로그 파일에서도 쉽게 식별될 수 있어야 하며, 그 반대의 경우도 마찬가지이다. 다양한 로그를 타임스탬프와 동기화하면 오류가 보고될 때 발생한 일을 상호 연관시키는데 도움이 된다.

---

5.4 Test Automation Reporting

테스트 로고는 테스트 케이스/테스트 스위트의 실행 단계, 작업 및 응답에 대한 세부 정보를 제공해야한다. 그러나 로그만으로는 전체 실행 결과에 대한 좋은 개요를 제공할 수는 없다. 이를 위해 보고 기능이 필요하다. 각 테스트 스위트를 실행 후, 간결한 보고서를 작성하고 배포할 수 있어야한다. 재사용 가능한 보고서 생성 구성 요소를 사용할 수 있어야 한다.

Content of the reports

테스트 실행 보고서에는 실행 결과, 테스트된 시스템 및 테스트가 실행된 환경에 대한 개요가 포함되어야하고, 이해관계자들에게 적합한 형태여야한다.

어떤 테스트가 실패했는지, 실패한 이유를 아는 것이 필요하다. 문제 해결을 쉽게 하기 위해, 테스트의 실행 이력과 누가 책임자인지를 아는 것이 중요하다. (테스트를 생성하거나 마지막으로 업데이트한 사람) 책임자는 실패 원인을 조사하고, 관련 이슈를 리포트하고, 문제를 추적하고 수정이 잘 되었는지 다시 확인한다.

리포트는 TAF의 컴포넌트의 실패를 진단하는데에도 사용된다 (7장 참조)

Publishing the reports

리포트는 실행 결과에 관심있는 모든 사람에게 배포되어야한다. 웹사이트에 업로드하거나, 메일로 보내거나, 테스트 관리 도구와 같은 다른 도구에 업로드할 수도 있다. 실용적인 측면에서, 구독 기능을 제공하고 이메일로 보고서를 받을 수 있는 경우, 실행 결과에 관심 있는 사람들이 보고서를 확인하고 분석할 가능성이 높다.

문제 있는 SUT 부분을 식별하는 또 다른 옵션으로는, 보고서의 이력을 유지하여 빈번한 회귀가 발생하는 테스트 케이스 또는 테스트 스위트에 대한 통계를 수집하는 것이다.

---

ref

• ISTQB AL TAE Syllabus