2024 3rd QA 컨퍼런스

0. 오프닝 : 박인권 (Adriel QA Team Lead)

QA 코리아 컨퍼런스 1회차 750명, 2회차 1100명의 참석자를 기록. 3회차는 1100명 이상이 참석할 예정.

만족도 조사에서는 1회차 87%, 2회차 92%로 온라인 전용 행사인 것을 감안하면 주로 긍정적인 피드백.

 

QA 코리아 컨퍼런스는

1. 현업 전문가를 발굴하여 소프트웨어 품질에 대한 유익한 콘텐츠를 생산하고 전파하는 것을 목표로 하고 있음
2. 소프트웨어 품질 엔지니어링의 대외적인 인지도와 저변을 확대하는 데 주력하고 있음

3. 모두가 새로운 변화에 빠르게 적응할 수 있는 기회를 제공하려고 함

 

1. 여기어때 사용자 행동로그 검증으로 보는 데이터 QA 전략 : 이경형 (여기어때컴퍼니 QA Engineer)

사용자 행동 로그

• 사용자의 행동 패턴 분석을 목적으로 사용자의 행동(클릭, 뷰, 스크롤 등)을 속성 값 구조로 기록함
• 마케팅 성과 측정 도구로 활용, 추천 시스템의 AI 학습 데이터로 활용, 데이터 기반 의사결정의 근거, 디버깅
• 잘못된 데이터로 성과를 측정하거나 학습하거나 의사결정하지 않도록 데이터 QA가 필요.
  • 요구 분석과 데이터 설계 단계 : 데이터 개발 요청서 검토
    • 기획의 요구 사항이 모두 적절히 반영되었는가?
    • 개발 요청서의 표현은 명확한가?
  • 데이터 개발 태깅 단계 : TC 설계
    • 이벤트와 태그는 정상 동작하는가?
    • 각 이벤트 발생 시 로그는 1회 적재되는가?
    • 다른 환경의 같은 이벤트에 대해 동일하게 동작하는가?
    • 적재된 로그가 요청된 데이터를 모두 담고 있는가?
    • 로깅 자체가 APP 기능에 영향을 주고 있는가? (속도, 크래시 등)

검증 도구

• ELK Stack (Elasticsearch, Logstash, Kibana)
  • Elasticsearch - 저장, 적재
  • Logstash - 수집
  • Kibana - 시각화 → 검증 도구로 활용
• Postman Collection

2. 자동화의 신뢰성(정확도)을 높이기 위해 한 액션 : 정다정 (무신사 QA Engineer)

자동화 도입

• 무신사 29CM는 QA팀이 신설되는 시점부터 자동화 도입을 염두에 두었음
  • 주 2회, 핫픽스 포함 시 그 이상 진행되는 반복되는 앱 배포, 한정된 QA 인원으로 인한 리소스 확보 어려움
  • 필요한게 무엇일까?
    • 명확한 목적과 전략
    • 명확한 테스트 범위 정의
    • 적절한 테스트 툴
• 조건들을 만족하여 자동화 테스트가 업무에 도입됐을 때, 성공적인 도입으로 평가하려면?
  • 테스트 결과에 대한 일관된 정확도와 신뢰성 확보가 필요
  • 이를 위해 29CM QA팀은 자동화 테스트의 결과를 DB화 및 트래킹 중
    • Grafana
    • Post-GRES
  • APP 이슈로 인한 테스트 실패 비율은 제외하고 자동화 코드 이슈만 카운트

전략과 액션

• 테스트를 좀 더 정확하게, 오류 없이 진행하기 위해
  • 테스트 대상 요소를 정확하게 탐색해야 함. → accessibility id 적재
    • Inspector가 XPATH를 활용해서 요소를 탐색할 경우, UI 변경에 취약하기 때문에 UI구조가 변경될 때마다 XPATH 수정이 강요됨.
    • accessibility id = 고유하다, 일반적으로 UI 레이아웃이나 디자인이 변경되어도 유지함.
  • 29CM는 native 와 webview가 공존하는 하이브리드 APP.
    • native 는 특별한 처리 없이 Appium에서 요소 접근이 가능
    • webview는 상호작용을 위해 추가적인 처리가 필요.
    • 따라서 native/webview가 공존하는 페이지에서는 분기 처리와 context 전환을 동시에 하도록 처리하면 효율적.
• 테스트 결과에 대한 신뢰성을 조금 더 확보하기 위해
  • API를 보조 수단으로 사용, 잘못된 테스트 결과값을 전달하지 않도록
    
    • "요소의 노출 여부"로 자동화 테스트 결과를 판단했을 때
      • 카테고리 항목과 연결된 브랜드의 매칭이 잘못되었음에도 "카테고리"와 "브랜드"가 노출되었기 때문에 "성공"으로 판단함.
    • 하드 코딩 시 예외 상황 발생
      • 품절된 상품을 구매할 수 없어 "실패"로 판단함.
      • 옵션이 없는 상품에서는 옵션을 선택할 수 없어 "실패"로 판단함.
      • 2개 이상의 옵션을 필수 선택해야하지만 1개 옵션만 선택하여 "실패"로 판단함.
      • 따라서 API 호출로 옵션의 존재 여부, 개수 등을 우선적으로 확인하여 데이터를 확보 후 테스트를 진행
  • 테스트 케이스별 독립성 확보
    • 장바구니 담기 - 상품 정보 변경 - 주문서 이동 - 결제 를 한다고 하면 앞선 과정에서 실패하면 이후 테스트가 모두 실패하여 실패율이 증가함
    • 한 페이지 단위로 실행 가능한 함수들을 각각 작성해서 활용하는 구조로 변경

3. 키워드기반 자동화 테스트 with 로봇프레임워크 : 육경민 (코인원 QA Engineer)

키워드 기반 자동화 테스트를 시작하게 된 계기

• 자동화 테스트가 APP의 잦은 변경에 어떻게 대응할 수 있을까?
• 테스트 스크립트 열심히 작성 → APP 변경 → 무용지물
• 서로에 대한 간섭 없이 깔끔하게 정리된 테스트 케이스로 협업할 수 있어야 한다.
  • 케이스 추적성 확보에 어려움
  • 코드마다 주석 달고 파일 이름 다는게 오래 걸리고 어려움

어떤 방식을 쓸까?

• Record & Play 방식
  • 화면을 녹화하고, 화면을 재생하면서 테스트 결과 여부를 판단
  • 고전적, 난이도가 쉬움
  • 재사용성이 부족하고 유지 보수가 어려움
  • 코드 형상이 바뀌면 처음부터 다시 녹화해야 함.
• Use-Reuse of Function 방식
  • 스크립트를 함수 단위로 묶어 케이스를 나누는 방식
  • 확장성 향상, 유지-관리 용이
  • 분석 및 흐름 식별이 오래걸림.
  • 함수 단위라 작성자 이외에는 파악이 어려움. (코딩 스타일이 다르기 때문)
• Data Drive Script 방식
  • 스크립트와 데이터가 분리되는 장점
  • 데이터 설정에 많은 시간이 소요됨
  • 테스트 소요 시간도 늘어남
• Action Keyword Script 방식
  • 키워드를 사용
  • 재사용 가능
  • 개발 지원 테스트 설계 가능

4. QA 엔지니어와 협업하여 생성형 AI 프로덕트의 완성도 높이기 : 안소현 (Adriel Product Designer)

프로덕트 디자인 측면에서 디자이너와 효율적으로 커뮤니케이션하는 방법

• Adriel은 스타트업이라 5~6명의 스쿼드 단위로 빠른 의사소통이 일반적.
• 디자이너도 디자인 팀원들보다 PM, 개발자, QA 엔지니어와 더 밀접하게 일함.
• 전체적인 워크플로우에서 각자의 직무에 대해 이해를 하고, 협업을 함께 해야 함.
• 프로젝트의 흐름과 기획 의도를 정확하게 이해하고 있으면 이미 기획 단계에서 이슈 캐치가 가능
• QA 엔지니어가 디자인 시스템에 대한 지식과 문서 이해도가 있다면 커뮤니케이션 비용이 상당이 줄어듦.

테스트 측면에서 디자이너와 협업하는 방법 (수많은 테스트와 자동화의 지옥에서 위기에 빠진 동료 디자이너를 구해주는 법)

• 공통적으로 디자인 이슈가 많이 발생하는 경우
  • 버튼 사이 여백과 간격이 충분한가
  • 버튼의 색깔과 크기, 위치가 적절한가
  • (모바일의 경우) 터치 영역이 고려가 되었는가
  • 버튼의 어조에 일관성이 있는가 ("사용할래요", "해볼래요" 하다가 갑자기 "삭제")
  • 텍스트 박스 배치가 적절한가
  • 정보 위계에 맞는 컴포넌트가 사용됐는가

프로덕트 디자이너들이 실무를 진행할 때 많이 참고하는 서비스 (실질적인 레퍼런스 수집)

• Mobbin
• WhatWasIT
• Product Hunt
• aiverse.design
• There is an AI For That
• 지금 써보러 갑니다

5. 게임에서 데이터를 기반으로 QA하는 방법 : 김준식 (넷마블 ntri QA 파트장)

게임회사의 기본적인 구조

• 개발 스튜디오 : 직접적인 개발 담당
• 퍼블리셔 : 개발된 게임을 운영, 유통, 마케팅 진행

소프트웨어와 게임 QA의 차이점

• 게임은 수많은 소프트웨어 중 한 종류일 뿐
• 그러나 게임이라는 도메인의 특징이 있다.
  • 통제할 수 없는 변수가 많은 편
  • 정해진 일정 안에 최대한 많은 커버리지를 달성해야 함

게임의 데이터 구조

• 일반적으로 게임의 데이터 형태는 RDBMS, 관계형 데이터베이스의 형태로 구성
• 하나의 값에 기본 키가 하나 있고, 각 키들이 서로 다른 테이블에서도 외래 키의 형태로 사용됨.

가챠란?

• 한국어 표현에서는 "뽑기"
• 1개의 가챠에서 획득 가능한 캐릭터가 100개. 신규 추가된 캐릭터는 3종. 각 신규 캐릭터의 등급은 희귀, 전설, 신화, 각 등급별 확률은 3%, 0.01%, 0.0045%로 가정한다면 신화 캐릭터 확률 검증을 어떻게 진행해야 할까?
  • 시뮬레이션 툴을 사용할 수도 있지만 그럴 경우 시간이 너무 많이 든다.
  • 데이터 테이블 단에서 검증을 하는 것이 훨씬 리소스를 절약할 수 있음

데이터로 QA할 수 있다면

• 게임의 구조를 더 이해할 수 있다
  • 원인 식별이 빨라진다
• 재화가 비정상적으로 획득된다면
  • 보상 데이터 확인 → 데이터 이슈
  • 데이터 정상 → 보상 지급 로직 이슈 혹은 테스터 실수
  • 획득한 재화가 저장이 안됨 → 클라이언트 로그에서 데이터 저장 요청이 있었는지 체크 → 클라이언트 이슈
  • 저장 요청이 있었지만 저장 실패 → 서버 이슈 혹은 네트워크 이슈

6. 쏘카 QA 프로세스로 AI챗봇 고객센터 시스템(AICC) 품질 높이기 : 문성준 (쏘카 QA Engineer)

쏘카의 QA 프로세스

• 플래닝 미팅 - Kick off - QA PLAN - Testcase 설계 - Testcase 리뷰 / Test data 준비 - Test 수행 - Sign off - Monitoring - 회고

쏘카의 AICC

• AICC란
  • AI 챗봇 기반의 고객센터 시스템
• AS-IS
  • 잦은 상담사 Turnover
  • 불균일한 응대
  • 운영 비용
• TO-BE
  • AI 챗봇 기반
  • 빠르고 균일하게
  • 상담사 인입량 해소
• 모든 고객문의를 GPT로 해결? → 비용이 문제가 됨

쏘카의 AICC 엔진 구조

• FAQ인지 시나리오인지를 구분, FAQ라면 사전 문답으로 이동
• 사전 문답 중 고객의 발화와 비교하여 알맞은 3~4개의 답변을 추출 후 우선순위 1개를 GPT로 전달.
• GPT가 판별을 실패하면 유저에게 실시간 채팅 상담으로 연결 유도

쏘카의 AICC 엔진 QA PLAN

• 요구사항 분석
  
  • Front : 사용자 기반 FLOW
  • Admin : 운영자 기반 기능 검증, 데이터 정합성
  • 챗봇 : 성능 부하테스트
  • 상담 시스템 : 외부 시스템 연결
• 테스트 목표 구체화
  • 의도한 동작에 따른 TC 수행률 85% 달성

AI를 QA할 때

• AI 모델의 복잡한 알고리즘과 데이터 흐름을 이해하기 어려움
• 다양한 시나리오, 엣지 케이스를 커버하는 테스트케이스를 작성하기 어려움
• AI 모델의 예측이 항상 확실하지 않음
• 데이터팀, AI팀, 개발팀, 운영팀, 고객관리팀 간 서로 다른 언어로 협업하기 어려움

7. 결제 단말기 E2E 자동화 도입 및 운영 사례 : 이성수 (토스플레이스 QA Manager)

결제 단말기에서 가장 중요한 것은?

• 결제 안정성 : 결제 실패가 잦지 않도록
• 결제 신뢰성 : 잘못된 금액으로 결제되지 않도록

반복적인 리소스 사용

• 토스플레이스는 매주 배포
• 결제 테스트의 강도가 높다보니 개발자와 크로스체크로 테스트 진행
• 이것을 자동화하지 않는 것은 비효율적
• E2E 테스트 자동화 도입 결정

E2E란?

• 사용자 관점에서 애플리케이션의 흐름을 테스트하는 방법
• 사용자가 실제 환경에서 겪을 수 있는 시나리오를 모방하고 설계된 대로 동작하는지 검증
• Mocking 최소화
  • Mocking을 하면 커버리지는 늘어나나 실제 동작이 아니기 때문에 유효성이 감소함.
• 사전 작업으로 Driver를 각각 컨트롤할 수 있게 되어 사용자 동작과 동일하게 Action 가능

 

8. Intelligent Automation : 효율적인 Test를 위한 Test case priority : 황재성 (LG전자 Software Engineer)

리그레션 테스트

• OS 개발에서 리그레션 테스트를 가장 많이 한다.
• 리그레션 테스팅의 목적은 변경된 SW에 대해 축적되는 테스트케이스들을 반복 수행하여 품질이 유지되는지 확인하는 것
• 테스트를 반복하면서 결함이 언제 발견될지를 예상하기는 어렵다. → 결함 검토의 효율성을 저해한다.
• "우리는 어떻게 결함 발생을 예측하면서, 결함을 빨리 찾을 수 있는가?"

테스트케이스 우선순위

• (경험기반 방법) Heuristic Method
  • 시험 이력 기반으로 차수 별 가중치를 적용하여 우선순위 결정
  • APFD (Average Percentage of Fault Detection)
• 그외 여러가지 머신 러닝을 활용하여 테스트케이스의 우선순위를 결정하면 조기 결함 검출이 가능하다.