What the Agile

Copyright ⓒ All Right Reserved by Buzzvil
What the Agile!
Agile 조직의 QA
QA Team
QA Manager Amy Kim
2021.08.25

View Slide

1. Agile? Agile!
1 - 1 Agile Manifesto
1 - 2 What the agile!
2. User story
2 - 1 User Story
3. AdM
3 - 1 How about AdM?
3 - 2 AdM + User Story = ?
목차

View Slide

1. Agile? Agile!

View Slide

Agile Manifesto
Agile? Agile!
최우선 순위는 가치 있는
소프트웨어를 일찍 그리고
지속적으로 전달해서 고객을
만족시키는 것이다.
● 팀은 그리고 조직은
고객이라는 하나의 동일한
목표를 가진다.
개발 후반부일지라도, 요구사항
변경을 welcome한다.
● 무조건 변경을 수용하는게
아니라 변화를 활용해
고객들에 대한 경쟁력을
강화한다.
최고의 아키텍처, 요구사항은
스스로 움직이는 팀에서
탄생한다.
● 좋은 설계는 사람으로부터
나오는 것이지, 특정한
역할로부터 나오는 것이
아니다.

View Slide

Agile Manifesto
Agile? Agile!
비즈니스 팀과 개발팀은
프로젝트 전체에 걸쳐 함께
일하는 것이다.
● 커뮤니케이션의 퀄리티를
높여야 한다. 매일은
아니여도 빠른 피드백이
가능하면 좋다.
지속 가능한 개발을 장려한다.
● 개발자, 사용자 모두 일정한
속도를 계속 유지할 수
있어야 한다. 단기간 높은
성과보다 길게 꾸준한
성과가 좋다.
팀은 어떻게 하면 효과와 효율을
높일지 치열하게 고민하고,
적용하고, 개선한다.
● 이러한 과정은 정기적으로
반복해서 가져가야 한다.

View Slide

Agile Manifesto
애자일은 문화 그 자체이다.
스크럼, 칸반 같은 방법론을 취한다고 해서 저절로 애자일 조직이 되는
것이 아니다. 따라서 100% 완벽하게 프로세스에 따라야 하는 것은
아니다. 방법론은 얼마든지 기업과 팀의 사정에 맞게 바꿀 수 있다.
중요한 것은 이를 문화로서 받아들이는 조직 구성원이다.
팀 전체가 애자일의 가치와 원칙을 공유해야만 한다.
Agile? Agile!

View Slide

QA 엔지니어는,
● 어떤 관점으로 애자일을 바라봐야 할까?
● 애자일 조직에서 무엇을 놓치고 있을까?
이 두 질문에 대한 대답은, “사용자에게 전달되는 가치” 이다.
E2E 테스터는 사용자의 입장에서 테스트를 해야한다는 걸 알지만, 쉽지
않다.
그렇다면, 사용자 모드로 전환시킬 수 있는 기법을 사용해보자
그래서 애자일이 어쨌다고?
Agile? Agile!

View Slide

2. User Story

View Slide

User Story(사용자 스토리)는 무엇인가?
사용자 스토리는 고객에게 가치를 줄 수 있는 기능을 서술한 것이다.
사용자가 시스템을 사용하는 주 목적을 중심으로 작성한다. 사용자가 기능을
사용하여 목적을 완료할 수 있는 단위가 되어야 한다.
사용자 스토리는 구현에 대한 약속이라기 보다는 구현하기 전, 사용자와 팀
사이의 대화를 이끌어내는 도구에 가깝다.
User Story

View Slide

[사용자 유형]은 [행위/목표]를 수행하여 [기능이 필요한 이유]를 할
수 있다.
As a , I want so that functionality>.
User Story는 어떻게 생겼을까?
User Story

View Slide

[블랙핑크 팬들]은 [죠스바 포장지에 삽입된 이미지를 한눈에
알아보는 것]을 수행하여 [최애 멤버의 죠스바를 구입] 할 수 있다.
User Story는 어떻게 생겼을까? - 블랙핑크가 삽입된 죠스바 포장지 디자인하기
User Story

View Slide

[CM]은 [Automation Rule]을 수행하여 [밤 12시에 Dash에서 소재
on/off를 직접 변경할 필요 없이, 자동으로 예약 세팅] 할 수 있다.
User Story는 어떻게 생겼을까? - Dash/Campaign Manager
User Story

View Slide

User Story의 짝꿍 - Acceptance Criteria
Acceptance Criteria (인수 조건)
사용자가 제품에 대하여 기대하거나 가정하는 조건을 인수 조건이라고 한다. 각
유저 스토리마다 고유한 인수 조건이 있고, end-user의 관점에서 기능의
behavior을 정의한다.
QA 엔지니어는 인수조건으로부터 테스트 항목을 도출할 수 있다. 보통 생각하는
요구사항이 인수 조건이라고 할 수 있다.
일반적으로 BDD(Behavior-driven development) 형식에 기반하여 작성한다.
● Given
● When
● Then
User Story

View Slide

✓ Independent: 독립적인 스토리인가? (변경되거나 제거될 때, 다른 기능에 영향이
없는지)
✓ Negoticable: 조정 가능한 스토리인가? (상위 수준으로 작성되어서 , 실제 구현에
있어서 유동적으로 조정할 수 있는지)
✓ Valuable: 사용자에게 가치를 제공하는가? (구현 가능한가 보다 중요한, 진짜
쓸만한가?)
✓ Estimatable: 측정 가능한 스토리인가? (유저 스토리에 들어가는 코스트는 어느
정도 이며, 그리고 개발과 테스트에 얼마나 시간이 걸리는지)
✓ Small: 충분히 작은 단위인가? (3~4명의 개발자가 반나절~2주 안에 구현하고
테스트까지 할 수 있는 정도)
✓ Testable: 테스트 가능한가? (테스트 가능한 인수조건이 세워졌는지 )
User Story를 위한 체크리스트 INVEST
User Story

View Slide

1. 유저 스토리는 필수가 아니다. 단지 가이드라인을 제공할 뿐.
2. 개발자는 유저를 대체할 수 없다. 따라서, 개발자 중심의 유저 스토리는
피해야 하며 기술에 대한 가정도 포함되어서는 안된다.
3. 너무 많은 디테일이 들어가선 안된다. 사용자의 요구사항과 가치 전달에
집중해야 한다.
4. 우선 순위는, 사용자의 요청과 피드백으로부터 결정된다.
5. 비어 있는 템플릿을 채우듯이 작성하는 것은 의미 없다.
User Story 작성 시, 유의할 점
User Story

View Slide

3. AdM

View Slide

Ad Management
QA Process of AdM
● 2주 스프린트
● Test Case Meeting
How about AdM?

View Slide

● Team-based QA
● 2주 스프린트 = 2주에 한번씩 돌아오는 QA 기간
2주 스프린트
How about AdM?

View Slide

“개발자는 프로덕트의 품질에 오너십을 가지고, 개발 전 Test Case(TC)를 직접 작성해보자.”
by. Ethan
1. QA 매니저의 참여를 스프린트의 앞단으로 끌어오자
2. 개발자는 직접 자신의 카드에 TC를 작성하자
스프린트 초기에 작성한 TC를 리뷰하는 Test Case 미팅을 갖는다.
Test Case Meeting
How about AdM?
장점?
● 기능 명세를 보다 명확하게 정의하고 개발 단계로 넘어갈 수 있다.
● 하나의 카드에 대해 개발자와 QA 매니저 뿐만 아니라, 모든 팀원들 사이의 공통된 이해를
끌어낼 수 있다.
● 팀내의 앞선 소통은 의사 결정을 앞당길 수 있다.

View Slide

“개발자는 절대 유저를 대신할 수 없다?”
개발자의 TC는, 유저도 QA 엔지니어도 작성할 수 없는 고유한 영역의 Test case
But, 유저스토리의 관점에서 보면 개발자의 TC는 개발 명세에 가깝고, 개발 명세에 치중된 기능 개발
및 테스트는 사용자에게 가치를 전달하기에는 부족할 가능성이 있다.
Test Case Meeting
How about AdM?

View Slide

[CM]은 [Bulk Creative]를 수행하여 [각 라인아이템을 일일이
클릭하여 소재를 업로드 할 필요 없이, 여러개의 라인아이템에
여러개의 소재를 한꺼번에 업로드]한다.
User Story 적용 예시
User Story + AdM = ?
Jira Card

View Slide

Acceptance Criteria 적용 예시
● 이미지 업로드 (image/native)
● 이미지 타입 별 필드 나타남 (name on report, icon, description)
● 아이콘 업로드 (한번의 업로드로 모든 아이콘에 적용)
● 잘못된 사이즈 이미지 업로드 시 에러핸들링
● URL 등 필수값 미 입력 시 에러핸들링
● 독립된 페이지에서 페어링 (같은 라인아이템에 속한 소재끼리만 가능)

View Slide

Given 노출형 애드그룹에서 Bulk
Duplicate으로 라인아이템을 생성
완료
When “Add Creative” 버튼을
클릭하여 이미지 선택
Then 이미지 업로드
Given Image 타입 소재 업로드
When 이미지 업로드 완료
Then “Landing URL”, “Title”, “CTA”,
“Category” 필드 나타남
Given Native 타입 소재 업로드
When 이미지 업로드 완료
Then 추가적으로 “Name on report”,
“Icon”, “Description” 필드 나타남
Given 잘못된 사이즈 이미지
When “Add Creative” 버튼을
클릭하여 이미지 선택
Then 업로드 되지 않으며, 잘못된
사이즈라는 얼럿 메시지 출력
Given Native 타입 소재 업로드
When 헤더의 “Icon” 라벨 옆, 업로드
버튼 클릭 및 이미지 선택
Then 모든 icon 필드에 한꺼번에
업로드

View Slide

Given Landing URL 등 필수값
미입력
When “Save Creatives” 버튼 클릭
Then 필수값 입력 누락 얼럿 메시지
출력 및 저장 되지 않음
Given Bulk Creative 페이지에서
올바른 값을 입력
When “Save Creatives” 버튼 클릭
Then Bulk Pairing 페이지 접근
Given Bulk Pairing 페이지 접근
When “Pair” 버튼 클릭 후 올바른 쌍
(Native를 클릭했을 시 Image, vice
versa) 선택
Then 페어링 적용
Given Bulk Paring 페이지에서
페어링 완료
When “Save Pairing” 버튼을 클릭
Then 최종적으로 소재 저장에
성공하며, Ad group의 Ads 탭으로
이동

View Slide

무엇이 좋았나?
개선 사항

View Slide

개선 사항
소재를 추가하기 위해 “Add
Creative” 버튼을 누를 때,
라인아이템이 많으면, 어떤
라인아이템의 하위 소재가 될지
구분이 어려울 것이다.

View Slide

개선 사항
Pairing 페이지에서, 라인아이템 하나에 속한 소재가 많을 때, 소재의 이름이 보이지 않으면, 페어링
해야하는 이미지를 구별하기 어려울 것이다.

View Slide

Users’ Feedback
● 슬랙 채널
● 화면 녹화 공유
● AdM-CM 위클리 미팅
● 설문조사
● 버그 리포트

View Slide

앞으로의 과제
추후 Bulk Managing과 관련해서 논의해볼 만한 과제들
1. 텍스트를 한꺼번에 대체/변경할 수 있는 text editor
2. 텍스트, 이미지 등 필드 입력값을 한꺼번에 적용하는 기능 (현재는 아이콘에만 적용)
3. 소재 copy, paste 기능
4. Bulk Managing 내부에서의 search 기능 (2번과 결합하면 더 의미 있는 ux가 될 듯)
5. Bulk Creative Edit (현재 Bulk Creative는 Bulk duplicate에서 이어지지 않으면 접근 불가)
미팅노트

View Slide

앞으로의 과제
중요할 수도 있지만 말하지 않은 것들
● 유저 스토리 사이의 우선순위 선정: User story가 평면적인 백로그에
쌓이면서 생기는 문제점을 보완하기 위해 만들어진 User Story Mapping
이라는 기법도 있다.
● Estimation을 위한 도구들 (planning poker, story point): 유저 스토리에서
핵심은 아니지만 유용할 수 있는 도구.

View Slide

Thank you!
QA Team
QA Manager Amy Kim
2021.08.25

View Slide

What the Agile

What the Agile

Buzzvil

More Decks by Buzzvil

Other Decks in Programming

Featured

Transcript