문성준의 단단해지기

오늘은 정말 오랜만에 또 글을 쓰게 되었습니다.

경력직으로 이직했지만

신입사원의 마음으로 일을 하고 있습니다.

그래서 잠도 22시 ~ 23시면 골아떨어집니다.

그래서 티스토리에 포스팅해야 하는데~

라고 생각만 하고 침대에 몸을 맡기는 게 일상이 되어버렸네요.

어쨌든!

오늘의 주제는 

협업 도구

입니다.

QA 실무를 하면서 회사의 특성상 사용하는 도구가 다 다를 텐데요.

어떻게 활용하고 있는지 오늘은 간단하게 알아보도록 하겠습니다.

알기 쉽도록 Before & After로 말이죠.

주요 업무 소통 방식

인트라넷 + 내선전화 VS Slack입니다.

●인트라넷 + 내선전화 ●

인트라넷(intranet)은 단체의 직원만 접근이 가능한 사설망을 말합니다.

모든 업무는 인트라넷에서 이루어졌으며 인트라넷의 모든 기능을 통해 업무를 진행하였습니다.

인트라넷에서 각 부서 게시판으로 이동 후 글을 작성하고, 댓글을 달아서 업무를 진행했습니다.

업무에 관한 모든 정보가 인트라넷에 남아있는 장점이 있습니다.

그러나 대부분의 작성글은 비밀글이고, 퇴사자가 발생하게 되면 관련문서를 찾아가기 힘든 적이 한두 번이 아니었습니다.

그리고 내선전화로 이해를 돕고, 급한 용무도 처리하였습니다.

●Slack ●

Slack 은 인스턴트 메시징 프로그램입니다.

비공개 채팅 또는 채널, 워크스페이스 등을 만들어 음성 통화, 화상 통화, 미디어 및 파일 통신이 가능합니다.

그리고 또 여러 소프트웨어와도 통합하여 사용할 수 있고요.

그렇기 때문에 긴 설명이 필요 없습니다.

저는 슬렉을 통한 업무가 딱딱한 대화환경을 조성하지 않음으로

다양한 커뮤니케이션이 가능하다는 것을 몸소 깨달았습니다.

보고를 하는데 형식적인 문서와 언어 사용을 위해 시간이 걸리지도 않고

허들을 통해 논의하고, 브레인 스톰을 즐길 수 있습니다.

메신저

메신저가 無 VS Slack입니다.

●메신저 없음 ●

메신저가 없습니다.

모든 업무는 인트라넷으로 진행했으니깐요.

그래서 다른 직원과 사담을 나누는 것은 자리에서 잠깐 얘기하는 것뿐이었습니다.

간단한 업무 지시도 메신저가 없었으므로 빠르게 전달되지 않았습니다.

●Slack ●

Slack 은 조직적인 커뮤니케이션을 위해 개발되었지만 커뮤니티  플랫폼으로도 활용하고 있습니다.

이모지를 제작해서 쓸 수도 있고, 개성 넘치는 프로필도 꾸밀 수 있습니다.

DM을 통해 비공개적인 교류도 할 수 있습니다.

공통 관심사가 있는 사람들을 모아 채널을 만들어서 소통하기도 합니다.

기획서 & 디자인 가이드

PowerPoint 와 ZEPLIN VS Notion, Miro, Figma입니다. 입니다.

●PowerPoint 와 ZEPLIN ●

기획서는 PowerPoint로 버전별로 확인할 수 있었습니다.
PowerPoint 첫 페이지에 버전관리 항목을 작성하여 관리를 합니다.
단, PowerPoint는 한 번에 모든 기획을 볼 수 있지만 새로운 정책, 기획이나 수정사항이 반영되기까지 시간이 오래 걸립니다.
디자인 가이드는 ZEPLIN으로 화면별 디자인가이드를 확인할 수 있었습니다.

●Notion, Miro, Figma ●

User Story와 Acceptance Criteria(인수테스트 시나리오)를 Notion으로 확인할 수 있습니다.
그리고 전반적인 기획은 Miro로 확인이 가능하고요.
UX와 Flow에 따른 최종 디자인은 Figma에서 확인할 수 있습니다.
비교적 많은 도구를 통해 기획문서를 확인해야 하지만 직관적이며 도구 내에서 소통이 가능한 장점이 있고
빠르게 반영된다는 장점이 있습니다.

BTS

REDMINE VS Jira 입니다.

●REDMINE●

인트라넷과 연동해서 쓸 수 있는 Redmine입니다.
Redmine 도 다양한 기능을 추가할 수 있습니다만 참고문서를 쉽게 찾을 수 없고 플러그인을 적용하는 데에 어려움이 있었습니다.
전 직장에서 Redmine은 전 직원이 들어올 수 없었습니다.
개발, QA, 기획자가 주로 협업하는 공간이었습니다.
그렇기 때문에 디자인, 사업부 정책논의가 필요할 경우에는 해당 이슈를 캡처해서 공유해줘야 하는 불편함이 있었습니다. (지금 와서 생각해 보면 왜 그랬는지는 모르겠음, 수정권한을 빼고 입장했으면 좋았을 텐데...)

●Jira●

처음에 우아한 형제들이나 다른 기업 면접을 봤을 때, 티켓관리는 어떻게 하느냐?
라는 질문을 들었을 때 의아했던 부분이 있었습니다.
Redmine을 사용하면서 티켓이라는 단어를 들어본 적이 없었거든요.
Jira를 사용하면 일감, 이슈들을 티켓으로 관리할 수 있습니다.
티켓으로 소요시간을 측정하거나, 우선순위 산정, 히스토리 남기기, 다른 티켓과의 연결이 용이합니다.
Jira는 활용방법이 무궁무진합니다.
JQL로 필터 기능을 사용하여 내가 원하는 정보만 확인할 수 도있고요.
아직 사용한 지 2개월밖에 지나지 않아 설정된 값만 확인이 가능하지만 자유자재로 쓰게 된다면 업무 효율이 향상될 것입니다.

팀 내부 문서 & Test Case 

Excel, Google Drive VS Confluence, TestLink입니다. 입니다.

●Excel, Google Drive●

팀 내부문서나 Testcase는 구글 스프레드시트 혹은 엑셀로 작성하여서 개인 폴더에 보관하거나 팀 드라이브에 공유를 했습니다.
계정을 연동하면 오프라인에서도 작업이 가능하고요.
수정이력도 확인할 수 있지만 문서의 양이 많아질 때를 대비하여 카테고리별로 정리가 확실해야 합니다.
딱히 엑셀과 구글 스프레드시트, 드라이브는 단점이 없다고 생각합니다.
상황에 맞게 적절한 선택을 하면 되니깐요.
그러나 텍스트에 최적화되어있다는 느낌을 많이 받습니다.
따라서 팀 내 가이드문서를 만들 때는 살짝 아쉬웠습니다. 그림과 같이 설명하기에는 가독성이 떨어졌거든요. 물론 제가 잘 활용하지 못했을 수도 있지만...

●Confluence, TestLink●

팀 내부 문서는 컨플루언스에 모두 저장하고 있습니다.
업무 공유부터 시작해서 회의록, 가이드문서까지 컨플루언스에 작성합니다.
작성했을 때, 관찰자에게 알림을 보내줄 수 돈 있고 관찰자에게 알리지 않고 게시할 수도 있습니다.
직접 코멘트를 추가할 수도 있고 댓글로 소통이 가능합니다.
테스트 링크는 저도 처음 봤습니다. 테스트 케이스를 관리하는 툴은 생각도 못했어요.
오픈소스 도구이고 쉽게 접근할 수 있는 도구인데요. 
Test Spec을 정하고 Test case를 작성하여 Test Suite를 형성합니다.
여러 Step actions을 Expected results에 매칭시킬 수 있고, 각자 사용 방법에 따라 Testcase 뿐만 아니라 Test 시나리오도 작성할 수 있습니다.
그렇게 작성된 Testcase를 plan을 세우고 build version을 구분하여 자유자재로 활용할 수 있습니다.
BTS와 연동도 가능하여 Testcase 수행할 때도 버튼클릭으로 상태를 바꿀 수 있습니다.
성공/ 실패 히스토리도 파악할 수 있고요.
좀 더 연구해 볼 만한 도구입니다.

이렇게 해서 오늘은 간단하게 

전 직장과 현 직장이 사용하는 협업 도구를 비교해 봤습니다.

갑자기 늘어난 협업 도구부터 숙지해야 했기 때문에

업무 피로감이 늘어났었어요.

그런데 이러한 협업 도구들을 사용하면서 

왜 피곤하게 이런 걸 쓰냐?

라는 생각보다는

뭔가 조금 더 익숙해지고, 잘 활용하게 된다면

업무 효율을 높이거나 커뮤니케이션을 할 때 시간을 단축시킬 수 있겠구나

라는 생각이 들었습니다.

즉, 비효율적인 건 아니라는 겁니다.

그러나 무분별하게 잘 나가는 회사들이 쓴다더라

해서 무조건적으로 도구만 많이 쓴다면 그건 닭 잡는데 소 잡는 칼을 쓰는 것과 다름없는 행동이겠지만요.

일단은 이 정도로만 소개하고

시간이 된다면 각 도구에 대해 자세한 설명과 활용방법에 대해 포스팅하고 싶습니다.

언제가 될지는 모르겠지만 그때가 빨리 오면 좋겠네요!!

그럼 이만!

아홉 번째 에피소드입니다.

오늘은 이런저런 넋두리를 하려고 합니다.

프로젝트가 끝나고 나면 복잡한 감정이 생깁니다.

짧게는 2주, 길게는 2달 이상의 프로젝트를 주기적으로 하다 보면

리뷰 → 설계 →  QA → 결과보고 → 리뷰 → 설계 →  QA → 결과보고

무한 루프에 빠지게 됩니다.

 프로젝트가 끝났다는 안도감

몰려오는 피곤함

프로젝트 중 받은 스트레스

다음 프로젝트에 대한 고민

엄청 심경이 복잡해집니다.

이럴 땐 아무것도 하기 싫어지는데요.

잘못하다간 번아웃 증후군으로 이어질 수도 있을 것 같습니다.

https://namu.wiki/w/%EB%B2%88%EC%95%84%EC%9B%83%20%EC%A6%9D%ED%9B%84%EA%B5%B0

결국에는 이런 복잡한 감정들을 어떻게 정리하느냐

정리하고 나아가느냐 아니면 무기력 해지느냐의 싸움인데요.

사실 앞으로 나아가야 할 걸 알면서도 몸은 쉽게 따라주지 않습니다.

그럴 때 저는 주위를 한번 정리합니다.

주위를 정리한다는 것은 Feedback 활동을 진행하는 겁니다.

프로젝트가 마무리된 후

설계된 Testcase의 부족한 점은 없었는지

Test를 진행할 때 도움이 된 테스트에 대한 경험을 팀원들과 공유한다거나

다른 부서와 의사소통할 때 더 완곡한 표현을 쓰면 어땠을까

하는 나만의 피드백을 진행하여

무기력함에 빠지는 일이 없도록 해야 합니다.

그렇게 되면 복잡한 감정도 하나씩 정리가 되고요.

앞으로 나아가는데 큰 무리가 없게 됩니다.

오늘은 프로젝트가 끝난 후 몰려오는 감정에 대해

넋두리를 해봤는데요.

결국엔 앞으로 나아가는 QA 엔지니어가 되기 위해서는

주변을 정리하고(Feedback) 다시 달릴 준비를 해야 합니다.

프로젝트는 기간이 종료되었다고 해서 끝이 아니라

어떻게 보면 다시 출발점으로 돌아온 거나 마찬가지입니다.

다들 멘털 관리 철저히 하시고

나만의 방법으로 성장할 수 있도록 노력합시다.

그럼 Episode09 마무리하겠습니다.

다음에 만나요~

오늘은 제가 PC Web Test를 진행할 때

사용하는 방법 중 하나인 개발자 도구(F12) 이용하는 법에 대해 간단하게 설명드리겠습니다.

1. 개발자 도구 켜기

개발자 도구를 켜는 단축키는 웹 브라우저에서 F12를 누르면 됩니다.

그러면 사진과 같이 개발자 도구가 나오죠?

톱니바퀴 도구를 눌러봅시다.

여기서 한국어로 변경 가능합니다.!!

2. Network 탭 사용하기

일단 Network 탭 사용하기에 앞서 간단하게 Network 탭을 사용하면 좋은 점에 대해 알아보겠습니다.

일단 Naver에서 개발자 도구(F12)에 Network 탭에 대한 구성을 확인해볼까요?

Waterfall 마우스 커서를 올리면 자세한 지표를 보여줍니다.

사실 제가 여기서 활용하는 정보는 Status Codes입니다.

Web QA를 할 때, 제가 우선순위를 높게 보는 것은 Web page를 잘 불러오느냐부터 확인을 하는 것이지요.

그럴 때 가끔 아래와 같이 페이지를 불러올 수 없을 때가 있는데요.

Status Codes로 어떤 점이 문제인지 확인할 수 있습니다.

자세한 Status codes 정보는 아래 링크에서 확인할 수 있습니다.

▼▼▼▼▼▼▼

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

3.throttling 설정

Fast 3G, Slow 3G, Offline.. 등의 느린 네트워크 환경을 설정할 수 있습니다.

아무것도 설정하지 않은 상태의 Naver를 불러오는 속도입니다.

Finish :7.56s / DOM : 867ms / Load : 1.05s

여기서 Slow 3G 환경으로 변경하면 어떻게 될까요?

눈에 띄게 차이가 나는 것을 확인하실 수 있을 것입니다.

Finish :48.37s / DOM  : 4.30s / Load : 12.71s

DOM이나 Load 같은 경우에는 단위가 바뀔 정도이고 7초에서 49초가량 7배나 느려진 속도를 확인하실 수 있습니다.

throttling 설정 같은 경우는 QA에서 어떻게 활용하냐면

정상 동작하는 Web 사이트에서 가끔 콘텐츠가 제대로 노출되지 않는다고 CS 유입될 때가 있습니다.

재현도 어렵고요.

그럴 때 제일 먼저 하는 방법이 throttling 설정을 통해 유저가 혹시 느린 네트워크 환경에서 

Web 사이트를 이용하지는 않았는지 확인합니다.

대부분 유저가 일시적으로 느린 네트워크 환경을 사용하여 발생되는 사건일 때가 많았습니다.

원래 주말에 포스팅했어야 했는데 주말에 큰 사건이 있었죠,

물론 티스토리도 예외는 아니었죠.

그래서 뒤늦게 작성한 감이 있지만 오늘은 개발자 도구(F12)의 Network 탭을 사용하여 

어떻게 Web QA에 활용하는지 간단하게 알아보았습니다.

그럼 다음 에피소드도 기대해주세요.

실무를 할 때, 요구사항 명세서 (기획서) 기반으로 Testcase를 설계하는 경우가 많습니다.

그래서 업무를하면서 과장하면 100개 이상의 기획서를 확인했다고 해도 과언이 아닐 정도인데요.

같은 기획서를 봐도 QA 엔지니어의 역량에 따라 다른 Testcase가 설계되는 경우가 많습니다.

물론, Testcase가 다르더라도 소프트웨어의 품질 향상이 목적이기 때문에 큰 문제는 없습니다만

효율적으로 업무를 하기 위해서는 우리는 빠르게 접근할 수 있어야 합니다.

그래서 제가 Testcase를 설계할 때 사용하는 방법 중 하나는

FlowChart를 작성하고 그 FlowChart 기반으로 Test case, Scenario 를 작성하는 것입니다.

Flow Chart 를 작성하는 방법은 아래와 같습니다.

위의 세 가지만 구분된다면 Flow Chart를 쉽게 작성 할 수 있습니다.

예를 한번 들어보겠습니다.

세가지 STEP으로 진행해보겠습니다.

Flow Chart를 도식화 하기 위해서는 소프트웨어의 간단한 설명(또는 기획서)에서 

요구사항이 무엇인지, 핵심이 무엇인지 빠르게 파악을 해서 요약을 해야 합니다.

그리고 여기서 Flow Chart의 세 가지를 도출해낼 수 있어야 합니다.

#Step 1#

▶Condition : 유저, 교육용 App

▶States : 메인 화면, 내비게이션 드로어 화면, 학습 유형 선택 화면, 자음/모음 선택 화면, 학습 화면

▶Actions : 유저가 각 화면에서 상호작용 할 수 있는 항목들을 기록( 선택, 클릭, 스와이프, 스크롤 등등..)

##Step 2##

요구사항 도식화

###Step 3###

Flow Chart 기반의 Test case, Scenario 작성

위에서 작성한 Flow Chart 기반으로 아래와 같은 case가 도출됩니다.

예시를 들기 위해서 만든 요구사항과 Flow Chart 이므로 굉장히 간단하고 쉽습니다.

이를 응용하는 것은

프로젝트에 참여하는 이해당사자(기획자, 디자이너, 개발자 등등) 에게 프로젝트를 쉽게 설명할 수 있을뿐더러

접근하는 데에 오랜 시간이 걸리지 않습니다.

Testcase 리뷰 기간에 사용하는 것이 적절할 수 있겠네요.

마지막으로

저는 실무를 진행할 때, 유스 케이스 다이어그램을 사용하여 프로세스를 따로 정의하지 않습니다.

제가 하고 있는 업무 환경에서는 불필요한 동작이기 때문이죠.

그러나 Testcase 설계를 진행할 때에는 꼭 노트와 펜으로 도식화나 Flow Chart를 그린 후 Testcase 설계를 진행합니다.

Flow Chart를 그리다 보면 기획서의 오류에 대해 알 수 있고,

전반적인 테스트 흐름도 머릿속에서 시뮬레이션할 수 있기 때문입니다.

따라서 이번 글에서 하고 싶은 말은 제가 쓴 글은 단순 참고 대상입니다. 

본인이 QA를 진행할 때, 설계 때부터 테스트가 어떻게 진행되는지에 대한 시뮬레이션을 2~3번 머릿속으로 진행해 봐야

미리 예정해두었던 일정에 차질이 없이 진행될 것입니다.

그럼 모든 QA 엔지니어 분들 파이팅입니다.

오늘은 탐색적 테스팅에 관해 알아보도록 하겠습니다.

탐색적 테스팅의 개념 :

경험 기반의 테스팅 기법 중 하나로 테스터의 경험, 직관, 기술능력을 바탕으로 테스팅 하는 기법

탐색적 테스팅은 테스터가 의도하던, 의도하지 않던 테스트 진행 시 발생되는 기법중에 하나라고 생각됩니다.

탐색적 테스트는 테스터의 역량에 따라 결과가 달라질 수도 있습니다.

저는 주로 명세기반으로 TC를 작업하고, 그 TC 를 가지고 테스트를 하게되면 전반적인 기능에 대한 검증은 가능하지만

예외적인 상황에 놓칠 수 있는 결함이 발생하게 됩니다. (소프트웨어의 특성상 더더욱 확인이 필요한 작업)

예를 들면 , 음원 재생에 관한 탐색적 테스팅 기법을 적용해보도록 하겠습니다.

EX)

APP : MP3 플레이어 

준비물 : 기획서, 기획서 기반으로 작성된 Testcase, 테스트용 단말기, 

명세기반으로 작성된 TC

일 때, 명세기반으로만 확인을 하게되면

단순히 재생버튼을 눌렀을 때의 동작만 확인하게됩니다.

재생버튼을 눌렀을 때 외부환경에 따라 재생기능이 어떻게 동작되는지 확인하고 싶습니다. (테스트 차터)

그러나 우리의 경험 멜론, 지니뮤직, 애플 뮤직 등 여러 음원 스트리밍 APP을 사용해본 경험에 의거하여 해당부분에 대해 추가적인 테스트를 할 수 있습니다. 이러한 계획들은 테스트 노트에 간단하게 기록합니다. (테스트 노트)

그러면 추가적으로 탐색적 테스팅을 간단하게 진행해보도록 하겠습니다.

 제 경험으로는 대표적으로 MP3가 재생될 때 전화가 오거나 혹은 백그라운드에 MP3플레이어를 실행 시켜놓은 후 다른 APP 을 사용하였을 때 어떻게 결과가 나올지 궁금합니다.

1. MP3가 재생될 때 전화수신 event 추가

2. Pre-condition에 재생중인 MP3 제외 유저들이 많이 사용하는 APP 실행 추가

(Time box 를 설정하여 검증 진행)

위의 테스트를 진행하게 되었을 때, 극단적으로 외부 앱과의 충돌로 인한 APP 종료 상황이 발생되었다고 가정한다면

이 결함에 대해 팀원들과 이슈를 논의할 수 있습니다. (요약 보고 Debriefing)

요약 보고 활동을 통해 공유된 결함으로 앞으로의 프로젝트에 있어 시행착오를 줄이고, 효과적인 기획, 개발, 검증 모두 

피드백이 가능합니다.

*** 탐색적 테스팅에 관해 임의로 예를 들어 작성해 보았지만 부족한 부분이 많습니다.

피드백 환영입니다.***