[무신사] 자동화의 신뢰성(정확도)을 높이기 위한 액션

정확한 로케이터 생성: Element를 찾기 위한 로케이터를 정확하게 생성하는 것이 중요합니다. ID, XPath, CSS Selector 등을 사용하여 각 요소를 식별하고, 유지 관리를 위해 일관된 네이밍 규칙을 적용하세요.

대기 시간 관리: Element가 로딩되기를 기다리는 대기 시간을 적절히 설정하세요. 너무 짧은 대기 시간은 오류를 발생시킬 수 있고, 너무 긴 대기 시간은 테스트 실행 속도를 늦출 수 있습니다.

테스트 데이터 관리: 테스트 데이터를 효율적으로 관리하세요. 테스트 시나리오에 필요한 데이터를 미리 생성하고, 테스트 종료 후 정리하는 프로세스를 구축하세요.

안정적인 환경 구성: 테스트 환경을 안정적으로 유지하세요. 필요한 앱 버전, 디바이스 설정, 네트워크 연결 등을 관리하고 업데이트하세요.

테스트 결과 분석: 자동화 테스트 결과를 철저히 분석하세요. 실패한 테스트 케이스를 확인하고, 원인을 파악하여 수정하세요.

테스트 스크립트 유지 보수: 앱의 변경 사항에 따라 테스트 스크립트를 지속적으로 업데이트하세요. 새로운 기능이나 화면 변경이 있을 때마다 관련 스크립트를 수정해야 합니다.

무신사 QA 팀은 자동화 테스트, 매뉴얼 테스트, 그리고 테스트 자동화를 모두 진행합니다.

자동화 테스트 수행 시간은 케이스 추가로 인해 늘어날 수 있으며, 이를 고려하여 테스트 전략을 세우는 것이 중요합니다.

무신사의 정기 배포 주기는 주 1회입니다.

자동화 스크립트 작성에는 파이썬과 Appium을 사용하고, 기본적인 코딩 지식만으로도 가능합니다.

ID 값이 누락된 경우에는 다른 데이터로 요소를 탐색하고 찾는 전략을 사용합니다.

개발팀과 협업하여 자동화 요소를 개발 시점에 고려하는 것이 중요합니다.

Accessibility ID는 테스트에 필요한 요소에만 생성 요청을 드리고 있습니다.

QA 팀은 개발팀과 디자인팀의 도움을 받아 테스트 자동화를 구축하고 있습니다.

* 웹뷰 요소 탐색 문제 해결

문제: Appium에서 웹뷰의 UI 요소를 찾지 못하는 경우가 발생.

해결 방법: 개발자에게 Webview Inspector 사용을 요청. Android에서는 Chrome Inspector 사용.

* 자동화 학습 시작하기

기본 공부: 자동화 코드 언어 및 툴 학습, 자동화 필요성 이해가 중요.

중점: 자동화의 필요성과 테스트 케이스/시나리오 구성에 대한 이해.

* Accessibility ID 관리

우선순위: 많은 UI 요소에 ID를 추가하기 어려울 경우, 주요 요소부터 ID를 생성.

계층 탐색: ID가 있는 요소를 기준으로 하위 요소를 탐색.

* ID 요청 기준

요청 기준: 테스트에서 사용되는 모든 요소에 ID를 요청.

요청 방법: ID 값을 직접 전달하고 컴포넌트별로 방식이 다름.

* 자동화 도구 선정

주요 고려사항: 테스트할 플랫폼의 커버리지 및 병렬 수행 가능성.

* QA 팀 업무 분담

조직 구조: 29CM QA 팀 내에서 자동화 업무 수행, 팀원 모두 자동화 진행.

* 업무 분담: 플랫폼별로 나누어 진행.

* 자동화 경험 및 학습

경험: 입사 전 매뉴얼 테스트만 진행 후, 자동화 필요성을 느끼고 시작.

학습 방식: 한 기능을 자동화하는 것부터 시작.

* ID가 없는 경우의 대처

우선순위 정리: 필요한 요소에 대해 ID 생성 우선순위를 정하고 개발자와 논의.

대체 방법: ID가 없는 요소는 xpath나 css로 탐색하고, 이후 ID로 변경.

자동화 수행 신뢰성과 ID 생성: QA 팀이 직접 ID를 생성하는 것이 효율적이며, 프론트 엔드나 앱 개발자 대신 QA가 ID를 부여하는 경우에는 프로세스와 논의가 중요하다고 생각합니다.

응답시간과 API 테스트: 응답시간이 느려지는 경우에는 화면 로딩 시간과 API 테스트 결과를 비교하여 이슈를 확인하고 관련 팀에 보고하고 있습니다.

자동화 코드 유효기간: 코드마다 다르며, 빠르게 변화하는 화면과 변경이 거의 없는 화면에서도 다양한 코드 유지 기간이 있습니다.

자동화와 매뉴얼 테스트 비율: 테스트 종류에 따라 다르며, Feature QA와 Regression Test에서 자동화와 매뉴얼 테스트를 적절히 조합하는 것이 중요합니다.

Accessibility ID 추가와 효율성: 기획 및 개발 초기 단계에서 ID 생성 요청을 먼저 진행하는 것이 효율적입니다.

API 테스트 결과와 UI 테스트 비교: 자동화 코드 상에서 비교하고 결과를 전달하고 있습니다.

테스트 결과 보고서: 슬랙과 Testrail을 활용하여 결과를 확인하고 있습니다.

웹 페이지 자동화: 현재 진행 중이지는 않지만, 웹 자동화 시에는 Selenium을 사용할 계획입니다.

* 오류 발생 테스트 케이스

    오류 강제 발생: 기대 결과가 다를 경우 강제로 오류를 발생시켜 테스트 실패 처리.

* 데이터 초기화

    중간 실패 시 처리: 테스트 중 실패 시 API를 통해 데이터 초기화, 화면 초기화는 첫 화면으로 이동하거나 앱 재실행.

* 자동화 테스트 산출물 관리

    결과 관리: 결과를 슬랙으로 전송 및 Testrail에 기록, DB에 결과값 적재하여 통계 관리.

* 핫픽스 및 자동화 테스트

    모든 배포에서 실행: 자동화 테스트는 모든 배포 빌드에서 실행.

* 스크립트 유지보수

    유지보수 계획: 하루 또는 주 단위로 일정 시간을 스크립트 유지보수에 할당, 상황에 따라 유동적.

* Appium+Python 독학

    조언 필요: 독학을 고려하는 경우, 유용한 자료 및 실습 중심의 학습 권장.

* 유지보수 비용 전략

    운영환경 테스트: DEV, QA 환경을 피하고 운영환경에서만 테스트하여 유지보수 비용 절감.

* 추가 리소스 관련

    리소스 부담: 자동화 코드 작성에 따른 추가 리소스 부담 인지.

*  QA 업무 병행

    업무 병행: 자동화 유지보수와 매뉴얼 QA를 병행, 매뉴얼 QA에 더 많은 집중 시간 확보.

* ID 추가 요청

    ID 추가 프로세스: ID 추가는 개발팀에서 진행하며, 필요 시 QA팀에서 요청.

* 테스트 케이스 수집

    수집 방법: 회의를 통해 케이스를 정리하고, 데이터가 필요할 경우 데이터팀의 도움을 받음.

* Accessibility ID 도입

    ID 존재 여부: 처음부터 존재하는 요소와 필요에 의해 추가된 요소가 있음. 초기 논의에서 개발자들이 협조.

* 자동화 테스트 커버리지

    커버리지 범위: 29CM 앱의 전반적인 동작을 확인하며, 결제 이전까지의 제품 탐색 및 장바구니까지 포함.

* 타이밍 이슈 해결

    해결 방법: 강제 sleep 코드 또는 명시적 대기를 사용하여 정확도를 높임.

* GUI 기반 자동화 툴 도입 계획

    현재 계획: GUI 기반 자동화 테스트 툴 도입에 대한 논의는 없음.

* Appium 선택 이유

    선택 배경: 다양한 자동화 도구 중 Appium을 채택한 이유는 별도로 언급됨.

* 웹, 안드로이드, iOS 자동화 진행 여부

    진행 상황: 현재 웹 자동화는 진행하지 않지만, 곧 진행할 예정.

* 테스트 데이터 우선 순위

    우선 순위 선정: 크리티컬한 이슈 발생 시와 유저 사용 비율이 높은 케이스를 기준으로 선정.

* 자동화 테스트 케이스 수

    운용 개수: 약 86%의 커버리지를 확보하고 있음.

* 결제 테스트 가능성

    결제 테스트: 인증 절차가 필요 없는 경우에는 자동화 테스트가 가능, 테스트 환경이 잘 세팅되어 있어야 함.

*  테스트 결과 및 API 사용
- 테스트 결과: 슬랙 스레드를 통해 전달하며, API 테스트 시 Postman 사용.

*  ID 신뢰성 보장
- ID 누락 대처: 개발자들이 ID 누락을 방지해야 하지만, 예외 처리를 통해 대비.

*  플러터 개발 및 자동화
- 플러터 앱 자동화: Appium을 사용하여 요소를 찾을 수 있으며, 특정 요소에 ID를 부여하는 것이 가능.

*  요소 식별 팁
- 식별 방법: 테스트 케이스를 수행하여 필요 요소를 확인하고 ID 생성에 필요한 요소를 명확히 식별.

*  자동화 테스트 기준
- 검증 기준: 통합 테스트 또는 E2E 테스트를 통해 검증.

 *  자동화 커버리지
- 커버리지 수준: 약 86%의 자동화 테스트 커버리지를 확보.

*  Mocking 활용
- Mock Data 사용 여부: 테스트 실패율 감소가 예상되지만, 실제 값 검증을 위해 활용하지 않음.

*  기대 결과 설계
- 기대 결과 설정: 요소의 존재 여부와 값의 정상성을 기준으로 설정.

*  동화 테스트 시간 관리
- 수행 시간 기준: BVT 자동화 테스트 수행 시간을 20분으로 설정.

*  개발팀과 자동화
- 테스트 수행: 개발팀은 자동화 테스트를 직접 수행하지 않으며, 필요한 시점에 트리거를 설정.

*  로케이터 관리
- 로케이터 하드코딩: 현재 하드코딩 방식 사용, 변경 시 리소스 소모는 비슷하다고 생각.

*  ID 누락 예외 처리
- 예외 처리 방침: ID 누락에 대해 최대한 예외 처리를 진행하여 테스트 실패 시 리소스 소모를 줄임.

*  분기문 테스트 케이스
- 예외 처리: 화면 진입 후 요소를 찾을 때 주로 분기문을 사용하여 예외 처리.

*  Accessibility ID 관리
- DB 관리: 29CM QA팀에서는 Accessibility ID를 별도로 데이터베이스화하지 않음.

*  테스트 실패 집계
- 구분 방법: 직접 화면 확인 후 앱 이슈 여부를 판단하고, 앱 이슈가 아닐 경우 자동화를 통해 확인.

*  사이드 프로젝트 주제 추천
- 주제 선택: 공부를 위한 프로젝트는 주요 기능 위주, 결과를 위한 프로젝트는 PoC 형태로 주요 기능 자동화 추천.

*  자동화 vs. 매뉴얼 테스트
- 시간 관리: 매뉴얼 테스트 일정으로 인해 자동화 테스트 수행 시간이 부족, 업무 외 시간에 작업하는 경우도 있음.

*  Accessibility ID 정의 및 협업
- 협업 시기: ID 관련 논의는 화면 개발 이후 진행, 추적 매트릭스는 현재 작성하지 않고 있으나 필요성을 느끼고 있음.

*  유 ID가 없는 경우 대안
- 대안 방법: 고유하게 확인 가능한 데이터 이벤트 로그 사용은 좋은 방법으로 인정.

*  API 테스트 기준
- 기준: 화면의 노출 정보 정확성과 필요한 데이터가 테스트 가능한지를 확인할 때 API 활용.

*  자동화 테스트 구축 범위
- 도입 방식: 기존 테스트 항목을 기반으로 기능 단위로 단계적으로 테스트 케이스를 만들어 도입.

*  자동화 코드 작성 및 TC 작성
- 기준 설정: 반드시 확인해야 하는 요소들을 기준으로 삼아 효율성을 높이고 있음. 회사 프로세스에 따라 차이가 있음.

*  ID 누락 시 테스트 결과
- 예외 처리: 테스트 목적에 따라 ID 누락 시에도 정상적으로 요소를 찾으면 Pass 처리. ID 값 존재 여부가 주요 항목인 경우, 결과에 반영.

*  검증 코드 작성 방식
- 현재 방식: `try-except`와 `if`문 사용. 필요 시 `assert`문도 활용할 계획.

*   자동화 대상 케이스 선정
- 선정 기준: 배포 전 반드시 테스트해야 하는 항목 중심으로 선정. 매뉴얼 테스트 케이스 수에 대한 자동화 커버리지 산출도 진행.

*  코드 리뷰
- 진행 방식: 팀 내에서 코드 리뷰 진행. 복잡한 기능에 대해서는 함께 논의하여 코드 작성.

*  신규 기능 프로세스
- 프로세스: 매뉴얼 QA와 자동화 테스트의 프로세스가 다름.
  - 매뉴얼: 기획 리뷰 → TC 설계 → TC 작성 → 테스트 → Sign-Off
  - 자동화: 스크립트 논의 → ID 요청 → 스크립트 작성 → 자동화 케이스 포함 여부 판단.

*  랜덤 ID 처리
- 대처 방법: 랜덤으로 변경되는 ID의 경우, 요소의 위치를 기준으로 XPath 작성하여 테스트 진행.

*  모바일 자동화 테스트 환경
- 해결 방안: 리얼 단말 환경 및 속도 이슈 해결 방안에 대한 언급이 있었으나 구체적인 내용은 답변에서 언급됨.

*  매뉴얼 테스트와 자동화 테스트의 공존
- 가능성: 일주일 배포 주기 내에서 매뉴얼 테스트와 자동화 테스트를 함께 수행할 수 있음.

*  테스트 환경
- 운영환경: 29CM QA팀은 운영환경에서 자동화 테스트를 진행함.

*  인프라 구축
- 구성: Appium + Python을 사용하여 POM 구조로 자동화 프레임워크 구성. Jenkins로 CI/CD 파이프라인 설정, Git으로 관리.

*  테스트 커버리지
- 커버리지: 약 86%의 커버리지를 확보하며, 페이지 진입 및 로드 상태를 확인.

*  사전 조건 및 실패 처리
- 사전 조건: 사전 조건 실패 최소화를 위해 딥링크와 API 사용. 실패 시 문제를 개발팀에 전달.

*  언어 선정 및 학습
- 언어 공부: Appium 독학 가능하며, 자사 QA 입사에 필요한 수준에 대한 조언 제공.

*  테스트케이스 관리 툴
- 사용 툴: 29CM QA팀에서는 Testrail을 사용.

*  iOS 자동화 속도
- 속도 문제: iOS 자동화 속도가 느린 점을 감안하고 진행하며, 개선 노력 지속. 관련 경험은 미디움 글로 공유.

*  자동화 셋팅 기간
- 기간: 자동화 구성 및 CI/CD 세팅에는 큰 시간 소요 없으나, 스크립트 작성에는 시간이 걸림. 유관부서의 도움도 받음.

*  테스트 단말의 noReset
- noReset 사용: True 값을 유지하여 기존 정보를 삭제하지 않고 테스트를 진행함. 데이터 삭제가 필요할 경우에만 False로 설정.

*  로그인 및 회원가입 자동화
- 현재 상황: 인증 문제로 인해 회원가입은 자동화 범주에 포함되지 않음.
- 보안 키패드 자동화: 보안키패드 UI가 동일한 경우, OpenCV를 활용하여 원하는 숫자 키패드를 눌러 자동화 진행.