2023 2nd QA 코리아 컨퍼런스 Day2

6. 롯데ON Test journey : 테스트 맵 활용기 : 이문현 (롯데ON QA Engineer)

MSA란?

MicroService Architecture, 경량화되고 독립적인 여러 개의 서비스를 조합하여 구현하는 방식.

세부적인 복잡성 때문에 개별적인 파악은 쉽지만 전체적인 파악이 상대적으로 어려운 한계점을 가짐.

전체를 시각적으로 한눈에 파악할 수 있는 <테스트 맵>을 작성하기로 함.

테스트 맵이란?

서비스의 도구, 서비스 정책, 프로세스, 기능 등을 마인드 맵처럼 시각적으로 표현한다.

요구사항 확인과 테스트 설계 단계에서 사용 가능. 영향범위 파악, 테스트 매트릭스 설계, Ad-Hoc 테스트를 용이하게 함.

테스트 맵을 활용한 테스트 매트릭스 설계

1. 테스트 설계 시간 감소
2. 커버리지 확보
3. 데이터 검증 용이
4. 손 쉬운 유지보수
5. 설계 난이도 하락

7. 라미엘: 원격 모바일 테스팅을 위한 HBsmith의 노력 : 윤제상 (HBsmith CTO)

원격 모바일 테스팅이 요구되는 상황

1. 보안 문제로 인해 실제 디바이스에서 테스트가 필수적
2. 원하는 장비를 필요에 따라 사용하기 위해서는 구매가 필요
3. 다양한 장비에서 동시에 사용하기 위해서는 구매가 필요, 비용이 증가
4. 자산 관리 최소화

원격 모바일 테스팅 구축에서 발생한 문제

1. 365일 24시간 운영 필요 + 전력과 온도, 인터넷 등 안정적인 환경이 필요 + 화재 등 리스크에 대응이 필요 → IDC에 입고
2. 장비들이 좁은 공간에 배치되다보니 전자파로 인한 기기간 간섭이 발생 → 특수 하우징 케이스 제작 및 유선 연결로 제어 안정성 확보
3. iOS 플랫폼 제어를 위해 MacOS와 XCode 필수 + 실시간 스트리밍의 느린 반응 속도 → 자체 방식으로 개선중
4. iOS의 강제 업데이트 팝업과 권한 제어 팝업 → 정기적인 IDC 점검

8. API 테스트의 시작 : 유다훈 (MyRealTrip QA Engineer)

API란?

Application Programming Interface. 정의 및 프로토콜 집합을 사용하여 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘.

Request와 Response를 사용하여 서로 다른 두 APP이 통신하는 방법을 API라고 정의할 수 있다.

API 테스트란?

API가 요구사항 혹은 API 문서에 명시된 대로 동작하는지를 확인하는 작업.

UI 없이도 핵심 비즈니스 기능을 제공할 수 있는지를 확인하는 일종의 Graybox Test에 해당한다.

API 테스트를 해야하는 이유

1. 빠른 릴리즈 주기에 대응이 가능
   1. 핵심 기능에 대해 빠른 시간 내에 테스트가 가능
   2. 개발 초기에 테스트 진행 시 비즈니스 로직에 대한 이슈를 조기에 확인 가능(Shift-Left)
2. 이슈에 대한 수정 확인이 빠름
   1. 이미 작성된 스크립트에 대한 재실행이 가능하여 재확인 코스트가 저렴함.
3. 테스트 커버리지 확보
   1. UI 테스트보다 Edge 케이스 확인에 용이
4. 테스트 스크립트에 대한 유지보수 코스트가 낮음
   1. 응답값의 수정 빈도가 낮으며 수정 시 인지가 빠름
5. Learning Cost 낮음
   1. 지원하는 도구가 다양하여 API 테스트만을 위해 특정 언어를 습득할 필요가 없음

9. QA Process 개선으로 팀빌딩 시작하는 법 : 권덕중 (야놀자 클라우드 QA Leader)

QA 프로세스?

QA팀의 Quality 개선 활동이 SDLC (Software Development Life Cycle) 전반에서 어떻게 이루어지는지에 대한 Standard 제시

QA팀의 Pain Point는 무엇일까

1. QA팀의 역할을 관계 부서가 제대로 인식하지 못함
2. QA = TEST 로 인식
3. QA Engineer 에 대한 낮은 신뢰도
4. 사양 변경에 대한 추적이 어려움
5. 너무 많은 Testcase
6. 오래 걸리는 Test 시간
7. 막바지에 확인되는 Critical Issue
8. 승인 기준이 모호하고 상이함
9. 스케줄 관리가 어려움

QA Process 배포 시 명심할 것들

1. 각자의 목적에 맞게 빠르게 요약과 지침을 찾을 수 있도록 제공할 것
2. 최대한 시스템과 통합하여 공수를 줄이고 사용자의 실수 또한 줄일 것

업무 생산성을 개선하라

1. 외부에서는 QA팀이 적은 비용을 사용하여 높은 품질을 유지하여 적기에 배포하기를 원함
2. QA팀은 Test 기간을 단축하면서도 높은 품질을 유지하는 것을 노력해야 함.
3. 개발 완료 전 설계 및 분석, 준비를 완료하고 계획 조정이 필요함.

QA팀의 성숙도와 개인의 성장을 준비하라

1. 지금 우리 회사, 우리 조직은 어떤 상황인가?
2. 우리 QA팀은 어떤 일을 하고 있는가?
3. 지금 내가 해야할 일은 무엇인가?
4. 나는 무엇을 할 수 있는가?

10. 웹 서비스, 기능을 넘어 성능 품질까지 책임지기 : 유동균 (해치랩스 Front End Engineer)

서비스 성능에 대해 QA가 할 수 있는 것이 없다고 생각할 수도 있지만 멀고도 가까운 관계.

기능이 정상 작동하더라도 속도가 너무 느린 제품을 품질이 좋은 제품이라고 말하지는 않는다.

웹 성능?

1. 웹 사이트가 얼마나 빠르게 동작하는가
2. 객관적인 측정치이면서, Loading Time과 Running Time을 어떻게 인식하는지에 대한 주관적인 User eXperience.
3. 좋은 웹 성능은 매출로 직결됨.
4. 기능이 다양해지고 고도화되면서 복잡해지고 무거워짐. 성능이 저하되면, 사용자가 떠나고 매출이 감소한다.
5. 웹 성능 최적화는 더 나은 사용자 경험을 제공하며 전환율이 증가, 이탈율이 감소하여 더 많은 수익을 창출할 수 있게 됨.

웹 성능 측정법

• Web Vitals : 사용자 경험에 대한 품질 지표

1. First Paint
2. First Contentful Paint
3. Largest Contentful Paint : 페이지가 로드될 때 뷰포트 내에 있는 가장 큰 요소가 렌더링되는 시점
4. Cumulative Layout Shift : 예기치 않은 레이아웃 이동에 대한 누적 점수
5. First Input Delay : 사용자의 최초 상호작용에서 화면이 반응하는 시간

등등.

이 중에서 LCP, FID, CLS 가 핵심 지표인 코어 웹 바이탈.

11. 테스트 아키텍트가 하는 일 : 오의한 (HP inc. Test Architect)

• Technical Leadership을 바탕으로 Problem Solving, System Thinking, Engineering Norm이 기둥이 되어 팀에 Influence를 펼친다.
• Continuous Learning : 매일같이 새롭게 등장하는 기술 동향, 아티클들을 지속적으로 학습. 폭넓지만 얕게 아는 것이 중요하다.
• Long-term Planning : 기업의 로드맵에 대해 이해하고 한발 물러서서 넓은 시야로 팀을 이끌어야 한다.
• Practices, Strategy, Processes, Tools…. : 정의 혹은 포인트를 찾아 개선해야 한다.
• Communication : 수많은 형태의 소통으로 업무의 60% 이상을 차지함.

Engagement Model

1. Roster & Job Description : 팀이 성장할 수록 대내외적으로 팀의 역할을 알려주는 것이 중요
2. RACI (Responsible, Accountable, Consulted, Informed) & Deliverables : 각 단계와 과정마다 개인이 맡은 역할이 어떤 것인지 테이블로 정리하여 관리함.
3. Swimlane : 업무흐름도를 정의하여 Workflow를 효율화해야 함.
4. 당신의 모범이 팀의 문화를 만든다.
5. 고객 중심 전략은 팀원의 다양성이 필수다.
6. 멍청해보이는 질문이 팀을 더 똑똑하게 만든다.
7. 커뮤니케이션이 팀을 앞으로 나아가게 한다.

Quality Roadmap

1. Business Priorities : 기업의 비즈니스 우선순위를 파악하고 있어야 팀이 성장할 수 있다.
2. NUDD Assessment (New, Unique, Difficult, Different) : 다양한 관점으로 타겟을 바라보면 새로운 아이디어를 얻을 수 있다.
3. Testing Problem : 지금 가진 역량과 수준에서 해낼 수 없는 것들에 대해 발굴하여 반영해야 한다.
4. Goal & Metrics : 단계 별 목표를 정하고 각 성과를 측정해야 한다.
5. 노출된 리스크는 관리될 뿐 완벽하게 사라지지 않는다.
6. 숫자가 중요하지만 정성적 평가와 서사는 더 중요하다.
7. 제품과 서비스의 생명 주기를 고려하여 리소스를 분배해야 한다.
8. 항상 블랙박스는 존재한다.

Coexistence: New vs Legacy

Service A 가 General Availability 에서 End Of Life를 지나 End Of Support Life에 닿는 동안

새로운 Service B 가 GA 에서 EOL로 가는 사이 A(Legacy)와 B(New)가 Co-existed 하는 시점에 리소스를 어떻게 분배할 것인가?

1. New 의 GA 시점에는 동시기의 Legacy 와 동등한 수준의 기능을 가지고 있어야 한다. (Feature Parity)
2. Legacy 의 사용자들이 완전히 New 로 넘어오기 전까지 지속적인 관심을 가져야 한다.

Layered Test Architecture

1. Test Polygon : 각 기업과 제품, 서비스의 특성에 따라 중점적인 요소가 다를 수 있다.
2. Test Gap & Duplicate : 각 계층마다 다른 팀에서 맡아 소통을 통해 차이와 중복된 사항들을 줄여나갈 필요가 있다.
3. Coverage Map :가시성 확보를 통해 부족한 점을 파악하고 더 나은 테스트 아키텍처를 구현할 수 있다.
4. 다이어그램은 강력하다.
5. 중복은 낭비이지만, 가끔은 동일한 시나리오에서도 각각 Unique한 Value를 갖는 경우도 있다.
6. 제약사항은 팀에 창의성을 부여한다.
7. 테스트의 목적이 중요한 것이지, 자동화는 도구에 지나지 않는다.

Closed Loop Process

1. Escalation : 시장 이슈 및 고객 불만
2. Escape : 테스트에서 놓친 것
3. Get Well Program : 전체적인 관점을 가지고 취약점을 개선하기 위한 투자
4. 이슈 발생 시 이슈 원인을 파고들어 파악하지 않고 롤백하는 습관은 좋지 않다.
5. Escape가 발생하여 TC를 보완하는 것은 바람직한 행동이지만, 장기적으로 봤을 때 유지보수 비용이 지속적으로 들어간다고 볼 수 있다. 근시안적 개선은 더 큰 문제를 야기한다.
6. 고객이 경험한 이슈로부터 고객의 인사이트를 얻을 수 있다.
7. 소 잃고 외양간 고치는 경우를 전략으로 사용할 수도 있다.