[QA] 테스트 자동화

지금 현재 인턴을 하고 있는 회사에서 TA 업무를 담당했었다.

테스트 자동화를 어떤식으로 활용하는지 기록하고 싶어서 해당 카테고리를 생성했다.

QA 조직에는 되게 다양한 역할이 있다. 유스케이스 작성, 유스케이스를 스크립트로 옮겨서 작성 등등…
나는 키워드 함수 제작을 담당 했는데, 이게 무엇이고 왜 필요한지 어떻게 하는건지 등등을 정리해보려고 한다.
TA 카테고리에는 이 포스팅 이후 groovy언어와 키워드 함수 작성법, 카탈론 스튜디오 사용법의 글을 쓸 예정이다.

---

QA / TA

QA와 TA란?

QA가 더 넓은 개념이고 그 안에 TA가 있는 것인데,

 

QA: 개발 과정 중 품질 보증에 초점을 맞춤 (개발단계의 품질 보증)

  1차 QA (API test) : 백엔드에서 발행 / 프론트에서 검수

  2차 QA (Process test) : 프론트에서 발행 / 기획에서 검수

  3차 QA (UI/UX test) : 기획에서 발행 / 디자인에서 검수

 

TA: 자동화된 테스트와 지속적인 품질 모니터링에 집중 (운영단계의 품질 보증)

  1) 유즈케이스 작성

  2) 테스트케이스로 변환

  3) e2e 테스트

 

✅ TA는 QA(1차, 2차, 3차)가 다 끝난 뒤에 진행

 

✅ 3차 QA까지 끝나면 해당 모듈에 대한 유즈케이스가 TA부서에 전달되며,
      TA부서는 테스트케이스를 작성하여 TA를 진행함

 

✅ TA가 완료되면 최종 개발이 완료되며, 주간회의에서 리뷰

---

TA 목표

E2E(end to end) Test를 automation 하고 결함을 탐지하기 위함.

 

e2e 테스트의 목표: 고객 신뢰

• 통합 오류 발견: 개별 컴포넌트는 정상 작동하지만, 시스템 전체에서 발생하는 오류를 조기에 발견 (DMZ 영역 해결)
• 사용자 경험 저하 예방: 실제 사용자 시나리오를 테스트하여 사용성 문제가 발생하는 상황을 사전 차단
• 회귀 버그 예방: 신규 기능추가로 인한 풍선효과 및 부작용을 최소화 (되던 게 안되는 상황)
• 성능 문제 모니터링: 테스팅 시간 추적을 통한 성능 저하 상황을 모니터링
• 비즈니스 로직 오류 사전 조치: TA 및 매뉴얼 작업을 통해 기획설계 내용 추가 검토
• 보안 취약점 사전 발견: TA 작업을 통해 보안 이슈 발생 시 즉각적 공유

e2e 테스트의 범위

e2e는 각팀의 automation unit test 와 별개로 다음의 영역을 test 함.

• 핵심 기능: 사용자의 주요 흐름(user flow)과 비즈니스에 중요한 기능
• 고위험 영역: 오류가 발생했을 때 큰 영향을 미칠 수 있는 부분
• 복잡한 통합 지점: 여러 시스템이나 서비스가 연동되는 부분
• 자주 사용되는 기능: 사용 빈도가 높은 기능
• 회귀 테스트: 과거에 문제가 발생했던 부분들을 확인

결함탐지

ta의 목적은 결함을 탐지하는데 있으며, 이는 버그(bug),실패(failure),오류(error),플래키(flaky)로 나뉜다.

• 버그: 명확한 어플리케이션의 결함이나 오류
• 실패: 테스트가 기대한 결과를 얻지 못한 상황 (현재까지 버그가 아니나 문제가 있는 상황)
• 오류: 테스트 실행과정 상에 발생한 문제 상황 (버그나 실패가 아닌 TA상 문제에 가까운 상황)
• 플래키: 재현불가능한 불안정한 문제 상황 (조치가 어려우나 리스크 관리해야 하는 대상)

 

코어 기능 TA 항목

• 결성
  • 조합 생성
  • 회계원장 등록
  • 조합원 명부 등록
  • 출자 배분 등록
  • 출자 운용지시서 등록 (전자결재)
  • 등등
• 투자 심의
  • 투자 정보 입력
  • 투심 표결
  • 계약품의 (전자결재)
  • 투자 운용지시 (전자결재)
  • 투자 완료
• 투자 변동 관리
  • 거래원장관리
  • 전표입력
• 영업보고
  • 포트폴리오
  • 영업보고 요청
  • 영업보고 검수
  • 심사역 의견 작성
  • 영업보고서 생성
• 회수
  • 회수위원회 표결
  • 출고 운용지시 (전자결재)
  • 회수관리
  • 회수 운용지시(전자결재)
  • 전표 입력

---

Katalon Studio

e2e테스트와 QA, TA를 위한 테스트 자동화 툴

Katalon AI-augmented Test Automation Platform

 

• 웹, API, 모바일 테스트가 가능
• IDE를 사용하여 오픈소스 자동화 프레임워크인 Selenium, Appium을 기반으로 구축
• 스크립트 엔진으로 Groovy를 사용
• 키워드를 조합하여 “테스트 케이스”를 작성
• 테스트 케이스들을 묶어서 “테스트 스위트”를 구성
• 테스트 스위트들의 묶음이 “테스트 스위트 컬렉션”
• Github/Slack/Jira 와 연동이 가능

Selenium API jar 사용 가능

• Katalon에 내장 된 대부분의 Keyword는 Selenium을 기반으로 함
• Html Selector로 XPath(Html의 특정 요소나 속성에 접근하기 위한 경로)를 지원
• XPath는 구글 크롬 개발자도구에서 Element 선택 후 Copy XPath 옵션을 지원하고, Elements 탭에서 XPath 기반으로 특정 Element를 찾을 수 있음
• XPath 관련 크롬익스텐션들도 존재

 

Selenium이 아닌 Katalon Studio를 사용하는 이유

보통은 QA를 위한 테스트 자동화 툴로 Selenium을 많이 쓰는 편인데,

우리 조직은 Katalon studio를 이용한다.

 

그 이유는 QA조직에 개발자만 있는게 아니라 비개발자인 기획자들도 있기 때문이다.
 
카탈론은 프로그래밍언어를 사용해서 스크립트를 작성하지 않고도

드래그앤드롭으로 키워드들을 조합해 테스트 케이스를 구성하는 것이 가능하다.

 

쉽게 설명하자면 스크래치처럼 블록코딩을 하는 느낌이다.
 
그래서 개발자가 아니더라도 유스케이스의 내용을 코드로 작성하는 것이 아닌

키워드 함수들의 조합만으로도 사용 가능하다.
 
키워드 함수는 일종의 인터페이스 역할인데,

어쨌든 키워드 함수 내부에 오브젝트를 잡기 위한 로직들은 groovy로 작성을 해야한다.
내가 이 역할의 담당을 맡아서 테스트 자동화를 진행했다.

---

TestOps

github 활용

모듈을 각자 맡아서 스크립트를 작성
특정 모듈에 사용할 키워드 함수 제작 요청이 들어오면 키워드를 만드는 동안 다른 테스트 케이스를 작성

slack 활용

매일 아침 6시마다 자동으로 dev, staging 두 개의 서버에 대한 테스트 스위트들을 돌린다.
개발 변경사항이나 DB오류로 인한 버그를 잡아내기 위함이다.
slack에 ta 채널이 있는데 카탈론과 연동이 되어있어서 실패, 성공 여부가 공유된다.

여기서 staging 환경의 테스트가 실패했을 경우 원인을 분석해서 트러블 슈팅 채널에 올리고 해결한다

---

커스텀 키워드 필요성

"키워드"를 사용하는 이유

키워드의 목적은 유스케이스 내에 유저 액션을 테스트 실행 시 사람이 직접하지 않고, 자동으로 이뤄지도록 하기 위함이다.
 
위에서 언급했듯 블록코딩의 블록을 배치하는 역할은 개발자가 아니더라도 가능한 정도의 일인데,
그 블록을 제작하는 일은 코드를 짜야만 한다.

• 유저 액션을 순차적으로 등록하는 방식으로 각각의 테스트 케이스를 작성하게 된다.
• 이때 유저 액션은 “키워드”를 사용해서 실행하게 된다. (ex. Click, Drag, Delay, …)
  • 키워드는 테스트 케이스 파일을 생성하고 좌측 상단 Add 버튼을 눌러 추가할 수 있다.

"커스텀 키워드"를 사용하는 이유

• 하지만 카탈론에서 제공하는 기본적인 키워드만으로 모든 오브젝트(ex. 버튼, 그리드의 셀, 테이블 스크롤, …)를 잡기 힘들다.
• 그래서 다른 페이지더라도 같은 컴포넌트를 사용하는 오브젝트를 잡을 수 있게 일반화한 “커스텀 키워드”를 직접 제작하여 사용한다.
• 커스텀 키워드는 고유한 식별자인 “data-test”와 화면상의 “text”들을 조합해서 사용한다.
  • data-test란 페이지마다 있는 오브젝트들의 unique한 식별자 값이다.
  • data-test 값을 이용하는 이유는 같은 오브젝트라도 페이지마자 오브젝트의 위치(깊이)가 다르기 때문이다. (ex. 페이지에 바로 보이거나, 모달창 안에 있거나, …)
  • 그래서 같은 오브젝트에 적용되는 커스텀 키워드를 사용할 때 data-test를 입력하여 해당 오브젝트를 잡을 수 있도록 한다.

---

커스텀 키워드 사용법

• 테스트 케이스 작성시 좌측 상단 Add 버튼을 눌러 추가하고 해당 키워드에 필요한 식별자와 인자들을 입력해준다.

 

---

커스텀 키워드 작성법

주로 입력, 클릭, 드래그, 검증 등을 수행하는 키워드를 만든다.

1. 필요한 오브젝트의 xpath 잡기
2. 오브젝트에 어떤 유저액션을 해야하는지 파악 후 라이브러리를 사용해서 수행
3. 작성한 커스텀 키워드가 의도대로 작동되는지 테스트 케이스를 만들어 확인해보기

Introduction to custom keywords in Katalon Studio | Katalon Docs

 

 

오브젝트의 xpath 잡는 법

1) 카탈론의 recorder 이용

 
간단한 오브젝트의 경우 recorder로 잡으면 xpath, attributes등을 확인할 수 있다.
하지만 상황에 따라 xpath가 정확하지 않을 수 있으므로 잡은 xpath가 오브젝트를 정확히 잡을 수 있는지 확인을 하고 싶다면 selected locator에 xpath 편집 후 verify and highlight를 누르면 된다.
 
 
2) 개발자도구(f12)의 Elements탭에서 html을 보며 커서를 올리면 어떤 오브젝트가 어떤 xpath인지 확인할 수 있다.

 
좌측 상단에 화살표 모양을 누르고 오브젝트를 누르면 한 번에 확인 가능하다. 다른 오브젝트에 가려져있는 경우는 Elements 부분에서 조정하면서 확인하면 된다.
단순히 xpath를 잡는 것 이상으로 <어떠한 셀에 연관된 셀을 검증을 해야하거나> <어떤 셀을 확인하고 그 셀과 연관된 다른 셀을 클릭한다> 등의 특정 오브젝트를 이용해 다른 오브젝트를 잡아야하는 경우가 많기 때문에

단순히 이 두 가지 방식으로 xpath를 확인하는 것 외에 라이브러리들을 사용하거나 xpath에 조건을 추가하는 등의 방식으로 오브젝트를 탐색하는 것이 중요하다.
 
 
3) 기본적으로 data-test 식별자를 사용할 수 있는 xpath로 잡아야 한다. 

data-test란? 오브젝트를 통일성 있게 식별하기 위한 attribute로 사용

>> 다른 페이지에서 같은 컴포넌트를 사용하는 경우, 동일한 키워드 함수를 사용할 수 있도록 고유한 아이디를 부여하는 것이다. 화면번호 + 컴포넌트 이름 의 형태로 짓는다.

 
하지만 data-test만으로는 오브젝트를 특정하기에 부족한 경우가 많기 때문에, 키워드 함수 내부에서 data-test로 잡은 오브젝트를 기준으로 여러 번 더 깊게 들어가서 오브젝트를 잡는 방식으로 세부적인 오브젝트를 잡아야 한다. (tag나 role, aria-colindex등의 attributes 이용) 특정할 수 있는 속성으로 선택하는 것이 좋다.

 

유저액션 관련 라이브러리 함수

• DriverFactory, WebDriver, WebElement 등을 통해 findElement, click, sendKeys, switchTo, contains, … 등을 활용할 수 있다.
• KeywordUtil을 이용해 log, success, failed 관련한 문구를 작성해야한다.
•  

---

커스텀 키워드 주요 업무

새롭게 커스텀 키워드 작성

• 테스트 케이스 작성자의 요구사항에 맞게 data-test를 사용해서 키워드를 사용할 수 있도록 새롭게 커스텀 키워드를 작성
• 커스텀 키워드의 유저액션 단위는 로직이 복잡해지더라도 커스텀 키워드 사용자가 편하게 사용하는 것을 우선적으로 생각하여 분할하거나 합치기
  • 버튼 클릭과 입력을 한 번에 하는 것, 혹은 두개의 키워드로 분리하는 것 등등 플로우를 생각했을 때 한 번에 일어나는 것 분리되는 것 중 뭐가 더 편한지 상황마다 다르기 때문에 고려해서 작성.

기존 커스텀 키워드 로직 수정

• 기존에 작성된 커스텀 키워드가 새로운 상황에서 원하는 대로 실행이 안될 때, 로직을 수정하거나 특정 케이스에 대한 새로운 커스텀 키워드를 작성
  • 기존에 작성된 커스텀 키워드의 로직을 수정해야하는 경우, 기존에 작성된 테스트 케이스들까지 커버가 되는지 확인이 필요
  • 기존 커스텀 키워드의 로직 수정을 통해 최대한 일반화를 해서 특수한 상황까지 커버가 되도록 만드는 것을 목표로 함
  • 하지만 특수한 상황이 추가 입력값이 필요한 경우라면 새롭게 커스텀 키워드를 만드는 것이 좋음