오랜만에 10번째 에피소드입니다.

오늘은 일하면서 들어본 이상한 단어와 웃픈 에피소드에 대해서 말해보려고 합니다.

#1 아삭하게 해주세요.

제가 아웃소싱에서 일할 때였습니다.

고객사에서 급한 일감이 들어왔는데요.

언제까지 해야 하는지 물어봤는데

돌아온 대답은 "아삭하게"였습니다.

아삭하게? 뭘 아삭하게 하라는 거지?

어느 지역 사투리지??

야무지게 하라는 건가???

평소 사투리를 쓰시던 분이셔서 

어느지역 사투리인지 검색을 하다가

ASAP이라는 단어를 검색하고 

깊은 탄식을 내뱉은 적이 있습니다.

As Soon As Possible

빨리빨리 / 가능한 (최대한) 빨리라는 뜻입니다.

본래 1900년대 중반에 미군에서 사용되던 단어이고,

미군에서 퍼져 보통 사람들 사이에도 적잖게 사용되는 단어라고 합니다.

에이에스에피라고 하거나 글자를 그대로 읽어서 에이쌥, 아삽이라고 읽기도 합니다.

사람마다 다르게 말한다고는 하지만

 다만 영어권 원어민이 “아삽”이라고 읽는 경우는 없다고 합니다.

즉, 고객사에서는 가능한 빨리 업무를 수행해 달라고 했었지만

저는 야무지게 하라는 뜻으로 이해했던 그런 해프닝이 있었습니다!

#2 tl;dr로 말씀드릴게요~.

오늘 있었던 일입니다.

앱 배포 때 minor 한 버그를 포함시켜야 할지 말지를 논의하고 있었습니다.

제가 답변 내용을 크게 보지 않고

변경점이라는 포인트에 집중하다 보니 

어떤 의미인지 다시 여쭤봤습니다.

저는 tl;dr이

채팅으로 대화를 했기 때문에

한/영 키를 잘못 누른 상태에서 입력하신 줄 알았습니다.

역시나 검색해 보니 

아래와 같이 나왔습니다.

TL;DR

TL;DR, 풀어서 "too long; didn't read"(너무 길어서 읽지 않았다)라는 뜻입니다.

응답이 되는 어떠한 텍스트가 그 길이 때문에 무시되고 있다는 것을 말하는 인터넷 속어입니다.

인터넷에서 글이 지나치게 길어 이를 비난하거나 글을 줄이는 것을 조언하기 위해 쓰는

'생략'과 흡사한 단어입니다.

즉, 두괄식으로 요점만 말해주겠다.라고 이해할 수 있겠습니다.

TL; DR로 한번 표현을 해보면

TL;DR : 이번 배포에 포함시키지 말죠! 
(뒤의 내용~~~ )

이런 식으로 응용해 볼 수 있겠네요.

오늘은 일하면서 처음 들어본 생소한 단어에 대해서 

재밌게 풀어보는 시간을 가졌는데요

일할 때 처음 듣는 단어라고 너무 거부감을 가지거나 놀라지 마시고

적극 활용한다면 지식도 얻고 업무처리도 빠르게 할 수 있습니다.

그럼 이만!

오늘 포스팅할 내용은

나는 어떤 강점이 있는 QA 엔지니어일까? 

태크블로그에 작성했던 글에 대한 회고입니다.

https://tech.socarcorp.kr/qa/2023/05/15/qa-skills-marktang.html

올해 1월에 새로운 회사로 이직한 이후로, TECH 블로그에 글을 업로드하는 것은

제 목표 중 하나이자 작은 소망이었습니다.

.면접 때 블로그 운영 경험을 어필한 후,

수습기간 동안 TECH 블로그에 글을 작성하는 과제를 제안 받았고,

이를 위해 3개월 동안 글을 작성했습니다.

당연히 하루 종일 글만 작성한 것은 아니었고,

온보딩을 받고 업무도 진행하다 보니 글을 작성하는 기간이 길어졌습니다.

호기롭게 TECH 블로그에 등록될 글감을 작성하려고 보니, 주제는 어떻게 선정해야할지가 막막했습니다.

첫번째 : 주제 정하기

QA엔지니어로써 TECH 블로그에 주제를 정하기 위해 5가지의 큰 기준을 잡아봤습니다.

1. 관심 분야 파악:  자신이 관심 있는 기술, 도구, 프로그래밍 언어, 프레임워크 등을 파악합니다.

자신의 전문성을 강조할 수 있는 주제를 선택하여 독자들에게 정보를 공유하고 피드백을 받는 형태로 글감을 작성합니다.

2. 업계 동향과 트렌드: QA 시장에 최신 업계 동향과 트렌드를 파악합니다. 새로운 기술의 도입, 현재 시장의 트렌드, 미래에 대한 핵심기술을 선정하여 독자들과 토론하는 형태으로 글감을 작성합니다.

3. 문제 해결과 가이드: QA엔지니어 또는 Software엔지니어(Dev)가 자주 마주치는 문제를 해결하는 방법이나, 실용적인 가이드를 제공하는 주제를 선정하여 독자들에게 가이드를 전달하는 형태로 글감을 작성합니다.

4. 프로젝트 경험 공유: 자신이 진행한 프로젝트나 QA 경험을 공유하는 주제를 선정합니다. 프로젝트의 참여한 QA 엔지니어의 A to Z 를 공유하고, 어려웠던점이나 갈등이 있었던경우 어떻게 극복했는지 본인의 경험을 독자들에게 전달하여 공감대를 형성할 수 있드록 글감을 작성합니다.

5. 튜토리얼과 팁: QA 엔지니어가 사용하는 특정 기술이나 도구의 사용법을 소개하는 튜토리얼이나,  유용한 팁을 제공하는 주제를 선정합니다. 본인의 주관적인 생각도 좋지만 정보의 전달은 객관적으로 정확하게 전달되도록 글감을 작성합니다.

관심 분야, 문제 해결과 가이드, (프로젝트) 경험 공유

저는 이 3가지 기준을 잘 조합해서 글을 작성하기로 했습니다.

주제는 "QA 엔지니어로 어떻게 성장을 해야할까?" 로 말이죠!

두번째 : 대상 독자, 독자가 얻을 수 있는 내용 정하기

주제를 선정하였으므로 

이제 두번째는 내 글을 누가 읽어줬으면 좋겠고, 어떤 정보를 얻어가면 좋을지 고민해야 됩니다.

대상 독자에 맞게 어휘력, 단어 사용을 고려해야 합니다.

또한 누구나 아는 내용을 적는 양산형 정보글을 작성하는 건 개인 블로그에서 충분히 작성해왔으니.. 

독자가 얻을 수 있는 내용을 확실하게 정해야 합니다.

저는 위와 같이 대상 독자와 독자가 얻을 수 있는 내용을 정하였습니다.

세번째 : 글의 주요 내용은?

.주제와 대상 독자가 정해졌으니, 글의 주요 내용을 정해야 합니다. 

제 경험에서 발생한 문제를 먼저 공유해드리고, 이 문제는 독자들이 궁금해하고 관심있어하는 주제일 것입니다. 

또한, 문제 해결을 위해 어떻게 노력하고 있는지에 대해 글을 설계하으므로 

위의 인과관계가 물 흐르듯 자연스럽게 이어져야 읽기에도 편한 글이 될 것입니다.

머릿말 : redgate의 Test Engineering Skill Map (https://www.red-gate.com/blog/test-engineering-skills-map)을 참고하여 QA엔지니어는 어떤 Skill 을 향상시켜야 하는지 방향성을 제공해 줍니다.
(쏘카 QA팀도 해당내용을 참고하여 본인이 어떤 Skill이 부족한지 확인하고 장기적인 Skill up 목표를 세워 달려나갑니다.)
내가 QA엔지니어로써 어떤 부분이 부족한지 확인하고, 구체적인 목표를 달성할 수 있습니다.
QA Skill영역은 단순히 노력이냐, 재능이냐 두 가지의 불분명한 관점이 아닌 Specialist, Product/Domain, Leadership, Project를 기준으로 여러 가지 사례를 확인하며 보다 구체적인 관점으로 QA Skill을 완성시킬 수 있습니다.

서론 :   전 직장에서 면접관 업무를 진행했던 경험으로 여러 면접자들이 Skill을 어필하지 못했던 사례에 대해 알아봅니다. 그리고 본인이 느꼈던 착오에 대해 간단하게 설명합니다. 

 본론 : 주요 Skill 과 각 항목에는 어떤 능력들이 필요한지 알 수 있습니다. 쏘카에서 본인이 QA엔지니어로 성장하기 위해 어떤 목표를 설정하고 진행하는지 확인할 수 있습니다.

 결론 : 본론을 바탕으로 QA엔지니어가 어떻게 자신을 단련시키고, 어필하는지에 대해 제 생각을 정리하여 글을 마무리합니다.

위의 3가지 단계로 글을 작성하였습니다.

여기서 끝!

이라고 생각하였으나

막상 글을 작성하고 보니 일기장인지, 어떤 내용을 전달하려고 하는지 감이 오지 않았습니다.

뭐가 잘못된 것일까?

1. 정보 공유를 위한 목적이아닌 위에서 언급했던 수습과제를 끝내기 위해 작성한 글 같다.

2. 글의 목적이 명확하지 않다. (QA SKILL 에 관한 내용인지 REDGATE에 대한 설명인지...)

3. 과도한 접속사 사용으로 글을 읽기에 불편하고, 문장이 길다.

4. 한글 영문 혼용규칙을 설정하지 않아 어디서는 엔지니어, 어디서는 Engineer ...

5. 본문과 내 경험과 맞지 않다..

등 여러 피드백을 받고 다시 작성을 했습니다...

글을 작성하는데만 초점을 둔 결과였습니다.

결국 다시 피드백을 보고 하나씩 수정을 하였고,

이 과정에서는 많은 분들의 도움이 있었습니다.

우여곡절 끝에 SOCAR  Tech Blog 에 제가 작성한 글이 올라가게 되었습니다!

링크드인에서도 확인가능 합니다.

https://www.linkedin.com/posts/socarkr_scitcu-qzcstkrzorxgqyy-qa-activity-7066276503264645120-wNdw?utm_source=share&utm_medium=member_android 

QA엔지니어로써 막연한 목표만 가지고 계신 분들에게는 도움이 되었으면 합니다.

1년에 1개이상의 글감을 TECH 블로그에 등록 할 수있도록

QA분야에 많은 관심을 가지고 업무에 임하는것이 이번년도 작은 목표입니다.!

이번 글을 작성하면서 

저를 제일 많이 도와주신 분께 책 선물도 받았습니다.

"우리글 바로 쓰기"

우리가 모르고 사용하고 있는 외래어 표현에 대해 우리말로 어떻게 표현할 수 있는지 

우리말 표현에 대한 이야기와 방법에 대해 알 수 있습니다.

앞으로 제 블로그도 외래어 표현을 자제하고 

아름다운 우리말로 작성될 수 있도록 노력할 것입니다.

그리고

"조직의 습관을 바꾸는 일"

책도 선물받았는데요.

(아직 한글자도 못봤어요 ㅠㅠ)

이건 다음에 리뷰할 수 있도록 살펴봐야 겠습니다. 허허

그럼 오늘은 여기까지 ㅡ ★

오늘 포스팅할 내용은

state-of-quality-report-2022

을 주관적으로 분석한 글입니다.

관련 자료는 아래 링크에서 다운로드하여보실 수 있습니다.

제 글을 읽으시기전에 한 번 본인의 생각은 어떤지 

정하고 보시는 걸 추천드려요.

팀 내에서만 공유했지만 혼자보기 아까워서 개인 블로그에 올립니다~!

https://katalon.com/state-quality-2022

요약

Katalon 에서 소프트웨어 품질에 대한 설문 조사와 분석을 바탕으로 작성된 리포트입니다.

QA 업계에서 일어나는 변화, 테스트 자동화와 인공지능 기술의 활용 등에 대한 정보를 제공하는 문서입니다.

머리말

요즘 빠르게 변화하는 세상에서, 조직들은 소프트웨어 품질(QA) 관행에서의 개선을 위해 내부와 외부 모두를 살펴야 합니다. 소프트웨어 품질을 빠른 속도로 제공하는 데에 대한 강점과 약점을 결정하기 위해 자신들의 관행에서 생성된 정보와 데이터를 수집하고 분석해야 합니다. 동시에, 그들은 각자의 산업에서 현재 상황과 트렌드를 찾아내야 합니다.

이 보고서는 3,000명 이상의 응답자를 대상으로 한 조사 결과를 바탕으로, 현재 소프트웨어 품질의 상태를 스냅숏으로 담아내며, QA 기술, 관행, 도구에 대한 통찰력과 트렌드를 예측합니다. 우리의 연구는 소프트웨어 엔지니어, QA 엔지니어, 분석가 및 관리자를 대상으로 조사되었으므로, 이러한 소프트웨어 품질을 보장하는 데 직접 관여하는 사람들의 의견과 목소리를 반영합니다.

본문

결론(이라 쓰고 3줄 요약이라고 적기)

자동화 테스트는 생각보다 많은 팀이 사용하지 않는다.

그럼에도 필요한 기술이다.

왜냐면 자동화를 도입한 팀들은 시간과 비용을 절약했기 때문이다.

상업적인 목적으로 만들어진 자료이기 때문에 100% 맹신할 필요는 없습니다.

그냥 이런 흐름이 있구나~라고 가볍게 보는 걸 추천드려요!

58 page 중에 3분의 1 정도는 Katalon이 어떤 회사인지... 알 수 있습니다.

참고 링크

https://xmlangel.kr/posts/2023-04-10-Katalon-2022-Report : 다른 분들은 어떻게 분석했나 보고 싶었는데 해당 블로그가 많은 도움을 주었습니다.

위 글은 Katalon에서 만든 자료를 제 개인적인 생각을 넣어서 분석한 글이기 때문에 모든 저작권 및 권한은 Katalon에 있습니다.

안녕하세요!!

오늘은 처음 써보는 유머글입니다.

인터넷에서 재밌는 걸 봤는데

이걸 QA 엔지니어 관점에서 봤을 때

단위테스트만 진행하고 통합테스트를 진행하지 않은 결과물

관련한 짤(gif)을 보도록 하겠습니다.

옷 다 젖는 수도꼭지

잠금장치만 확실한 문

이중 보안

보는 사람만 재미있는 워터 슬라이드

좋지 못한 곳에 설치된 물비누 디스펜서

위의 짤(gif)만 봐도

왜 통합테스트가 이뤄져야 하는지 이해가 되시죠??

그냥 웃고 넘길 수 있는 짤(gif) 지만

QA엔지니어 관점에서 다시 보니 웃음과 교훈도 얻을 수 있었습니다.

그럼 이만!

출처 : https://m.cafe.daum.net/dotax/Elgq/3359298?svc=topRank

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

경력직으로 이직했지만

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

그래서 잠도 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 수행할 때도 버튼클릭으로 상태를 바꿀 수 있습니다.
성공/ 실패 히스토리도 파악할 수 있고요.
좀 더 연구해 볼 만한 도구입니다.

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

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

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

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

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

왜 피곤하게 이런 걸 쓰냐?

라는 생각보다는

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

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

라는 생각이 들었습니다.

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

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

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

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

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

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

그럼 이만!

오늘은 일회용 이메일 주소를 만들어주는 사이트에 대해서 공유하려고 합니다. 

일회용 이메일 주소가 왜 테스트와 연관이 있지?

라고 궁금해하시는 분들이 있는데요.

일단 사용법 부터 소개해드리도록 하겠습니다.

욥메일

https://yopmail.com/

입니다.

일단 위의 링크에 접속해 보겠습니다.

위의 링크 따라 욥메일 페이지에 들어가면 위와 같이 나옵니다.

저는 구글의 번역기능을 썼어요.

왼쪽 상단에 보면 원하는 이메일 이름을 입력하세요.

라는 칸이 보입니다.

여기서 자기가 원하는 대로 이메일을 생성할 수 있습니다.

예를 들면 회사에서 어떤 네이밍 규칙으로 QA 팀에서 사용하는 메일을 만든다. 

라고 가정 합시다.

그러면 오늘이 2월 6일이고 여러 개를 만들어야 하니 아래와 같이 

qa_0206_001

qa_0206_002

qa_0206_003

.

.

.

.

.

이렇게 이메일주소를 만들 텐데요.

원하는 이메일 이름을 적어주고 화살표 버튼을 클릭하면

qa_0206_001@yopmail.com이라는 이메일이 생성되었습니다.

그러면 생성된 이메일로 메일을 하나 보내보겠습니다.

네이버에서 이렇게 보내보겠습니다.

왜 안 왔지? 

새로고침을 눌러볼게요.

메일이 온 걸 볼 수 있습니다.

어때요 참 쉽죠?

클릭 한 번으로 이메일을 받아볼 수 있는 일회용 이메일을 생성했습니다.

사용법을 보고 나니 이제 어떤 상황에 쓰일지 감이 오시나요?

예를 들면, dev 서버 또는 qa 서버에서 회원가입 페이지를 테스트할 때,

내 개인이메일 주소가 아닌 일회용 이메일 주소를 등록해서 

인증번호를 받거나, 알림 메일 또는 프로모션 메일을 받아볼 수 있습니다.

또한 위와 같은 방법을 반복해서 여러 개의 일회용 이메일 주소를 받아

여러 계정에 대한 테스트도 진행할 수 있기 때문입니다.

물론 더 많은 활용방법이 있겠지만 그건 나중에 생각해 보려고요.

그럼 이만!

2022.12.07 - [QA로 단단해지기] - [이직:移職] Episode_#02 : 2022년을 마무리하며 회상에 잠기다.

이직 두번째 에피소드에 이어 세 번째 에피소드

이직을 위한 준비에대해 포스팅하려고 합니다.

이직을 준비하는 누군가에게는 도움이 되었으면 합니다.

#01. 포트폴리오와 경력기술서 그리고 이력서

직장에 다니고 있는 90%이상의 직장인, 아니 누구나 새로운 도전을 하기 위해 준비를 하고 있을 것입니다.

물론 저도 업무를 하면서 포트폴리오, 경력기술서는 계속 업데이트하였습니다.

기회는 준비하는 자에게 오기 때문입니다.

나만의 경력기술서, 포트폴리오는 굉장히 중요합니다.

내가 몇 년 동안 어떻게 업무를 했는지, 내 장점은 무엇인지를 몇 장의 문서로  어필을 할 수 있기 때문입니다.

일단 포트폴리오의 목차부터 바꿨습니다.

기존의 포트폴리오는 경력 사항을 나열해놓은 것이라면

이번에 바꾼 포트폴리오는 내가 어떤 업무를 수행할 수 있는지를 중점으로 작성하였습니다.

크게 3단계로 나눴습니다.

저는 아웃소싱 회사에 처음 입사하여 자회사 QA Lead, Part Manager까지 올라간 경험이 있었기 때문입니다.

각각의 위치에서 어떻게 업무를 했는지, 어떤 장점이 있는지 중점만 요약해서 작성하였습니다.

너무 길어지면 제 포트폴리오를 읽는 사람에게 내가 뭐가 장점인지를 확실하게 어필할 수 없지 않을까 라는 생각으로 줄였습니다.

경력 기술서는

제가 그동안 업무 하면서 진행한 프로젝트에 대해 작성을 했습니다.

경력 요약, 경력 사항, 프로젝트 

세 가지 메뉴로 나눠서 작성하였습니다.

경력 요약은 말 그대로 경력을 요약한 것이고요, 내가 어떤 BTS를 사용할 수 있는지, 또는 어떤 언어를 쓸 수 있는지에 대한 것도 적었습니다.

경력 사항은 Web, App을 나눠서 작성하였고 

각각 세부사항은 프로젝트 항목에 Max 5줄이 넘어가지 않도록 작성하였습니다.

위를 바탕으로 지원서를 제출하였습니다.

제출을 하면 아래와 같이 사전 설문 메일이 오게 됩니다.

#02. 채용 사전 설문

제출한 서류와 설문 결과를 기반으로

면접을 진행할지 결정하게 됩니다.

사전 설문의 내용은 직무 테스트 참여 동의서에 동의하였으므로

자세한 설명은 생략하고 넘어가겠습니다.

여러 기업의 직무 테스트를 보신 분들은 아시겠지만 회사가 직무 테스트에서 어떤 걸 요구하는지 먼저 파악하는 것이 중요합니다.

물론 인터넷 검색을 통해 많은 정보를 작성해서 제출하는 것도 방법이겠지만

만약 설문에 통과해서 면접을 볼 때, 내 지식이 아닌 것들로 답변을 하였을 경우

횡설수설하지 않을까요?

그래서 제 능력선에서 솔직하게 작성하였습니다.

#03. 1차 면접 준비

1차 면접을 준비합니다.

지금 와서 생각해보면 제가 'H' 교육그룹에서 Part Manager로 면접관 업무도 진행하였습니다.

이력서도 100장 넘게 검토를 해본 경험이 있고, 제가 면접관으로 들어가서 인재를 채용했던 경험도 있습니다.

면접관 준비과정에서 지원자들에게 어떤 질문을 할까?라는 생각을 많이 했었고 

지원자들에게 신선한 답변도 많이 받았던 점이 이번 쏘카 1차 면접에서 굉장히 많은 도움이 되었습니다.

내용들을 정리하다 보니

대략 20page 분량의 예상 질문, 답변 내용을 정리하였습니다.

QA 업무는 무엇인가?라는 가장 기본적이면서 핵심적인 질문부터 

이전 회사에서 어떻게 업무를 진행했으며, 왜 이직을 생각하는지 등등

최대한 저를 어필할 수 있는 방향으로 준비를 했습니다.

그리고 실수를 하지 않기 위해 여러 번 소리 내서 연습도 하였습니다.

익숙해져야 머릿속에 남기 때문이죠.

한 가지 약점이 있다면, 코로나로 인한 비대면 면접은 늘 떨립니다.

면접을 볼 때 면접 분위기에 맞는 멘트도 생각을 해서 면접을 주도해나가야 하지만

비대면 면접 같은 경우에는 화면 송출 딜레이가 어느 정도 있기 때문에 면접관들의 표정이나 분위기를 읽기가 어렵기 때문입니다.

그래서 즉흥적인 대처에는 항상 신중해야 됩니다.

#04. 2차 면접 준비

1차 면접은 많이 떨렸습니다.

그래서 면접을 보고 난 후 피드백을 개인적으로 했는데, 준비한 답변을 제대로 말하지 못하고 횡설수설했던 점이 여럿 있었습니다.

그래도 면접관 분들께서 지원자들을 위한 마음이 스크린을 통해서 느껴질 정도로 존중받고 있다는 느낌으로 면접을 진행했습니다.

그 결과 2차 면접을 진행하게 되었습니다.

사실 2차 면접은 처음이었습니다.

그전에 다녔던 회사는 1차 면접만 보는 프로세스였고, 2차 면접이 있던 회사에 지원했을 때는 1차 면접에서 항상 탈락했었습니다.

지금 와서 생각해보면 당장 회사를 바꾸고 싶기 때문에 도피성 이직을 선택해서 내가 그 회사에 다니고 싶다.라는 점이 어필되지 않아 탈락을 한 것 같습니다.

즉, 목적 없는 이직이었기 때문이죠.

그러나 이번에는 제가 왜 쏘카에 가고 싶은지에 대해 명확한 근거가 있었습니다.

이 부분이 1차 면접에 많은 도움이 되었습니다.

2차 면접 준비 항목도 준비하였습니다.

역시 20page 정도 준비하였습니다.

1차 면접은 직무 관련 면접이라면 2차 면접은 컬처 핏 면접이라고 안내를 받았습니다.

컬처 핏이라고 하면 인성면접이라서 쉽다?라는 생각을 하시는 분들이 계시겠지만

이 세상에 쉬운 면접은 없습니다.

경력직의 컬처 핏은 어떤 걸 요구하는지에 대해 분석을 하였습니다.

여러분들이 면접관이라면 다른 회사에서 오래 근무한 사람이 과연 우리 회사에 잘 맞는 사람인지, 바로 일할 수 있는 사람인지, 적응할 수 있는 사람인지 확인이 필요하다고 생각을 하시겠죠?

그래서 업무 Skill이 아닌 어떻게 의사소통을 진행했는지에 대해 중점적으로 준비를 하였습니다.

그리고 회사에 대한 지식도 필요하다고 생각을 하였고,

모빌리티 산업, 카쉐어링 산업이 우리나라에서 어떻게 진행되고 있는지에 대한 간단한 지식도 숙지를 하였습니다.

그리고 쏘카의 기술 블로그나 , 기업 블로그의 게시글을 보고 쏘카는 어떻게 일하고 어떤 조직문화를 가지고 있는지도 숙지하였습니다.

그래서 2차 면접 준비는 내가 쏘카에서 일을 하는 사람이라고 생각을 하고 어떻게 대처할 것인지 머릿속으로 시뮬레이션을 여러 번 진행하였습니다.

그리고 인터넷에 보니 제가 질문을 하는 시간도 리버스 면접도 있다고 하여 궁금한 것들을 따로 준비하였습니다.

#05. 합격

2차는 대면 면접을 선택해서 진행하였습니다.

이렇게 긴장을 해본 적이 없을 정도로 왜 이렇게 긴장했는지 모르겠습니다.

1시간 정도 면접을 보고 난 후 건물 밖으로 나오니 머릿속이 하얗게 누가 지우개로 지운 것처럼

아무런 생각이 나지 않았습니다.

ㅋㅋㅋ 그래도 집에 와서 피자 먹으면서 피드백을 하니까 생각이 다시 나더라고요.

대면 면접이기 때문에 어떻게 왔는지 이런 대화를 하면서 긴장을 풀어주시려고 하셨고

편한 분위기에서 면접이 진행되었습니다.

뭔가 제가 생각했던 2차 면접 분위기가 아니어서 놀랐습니다.

제가 생각했던 2차 면접 분위기는 높은 직책의 사람이 들어와서 굉장히 딱딱한 분위기에서 진행될 줄 알았거든요.

면접을 보고 나오니 뭔가 더 쏘카에 다니고 싶다는 마음뿐이었습니다.

여러 이유가 있겠지만, 다들 다른 세계에 사는 사람처럼 뭔가 다들 평화로운 그런 느낌(?!?!) 이 많이 들었습니다.

진짜 뭔가 다른 세계인가?라는 생각이 지워지지가 않았어요.

아무튼 결국 세 번째 도전을 위해 2주간 잠도 제대로 못자고 준비를 했던것 같습니다.

겉으로는 여유를 찾으려고 했지만 역시 쉽지 않았네요.

다사다난했던 2022년이 이렇게 마무리됩니다.

세번째 도전은 제가 한 단계 더 성장할 수 있는 좋은 기회라고 생각됩니다.

제 티스토리에도 좋은 Skill들을 더 많이 작성할 수 있을 거라고 생각이 됩니다.

물론 늘 그래 왔던 것처럼 문성준의 도전은 계속됩니다.

初心

초심을 잃지 않는 것

이번 에피소드 마무리하도록 하겠습니다.

몇 년이 지나서 다시 쓸지 모르겠지만

이번 이직 Episode는 끝!

입니다.

오늘은 그동안 글을 올리지 않았던 이유 2번째

이직을 준비한 과정에 대해 글을 써보려고 합니다.

# 첫 번째 도전

돌이켜보면 2018년 2월 졸업하자마자 QA가 되기 위해

국내에서 인지도가 있다는 아웃소싱 회사에서

8개월간 Tester로 업무를 시작했었습니다.

그러나 처음 마주한 현실은 제가 생각했던 게 아녔습니다.

업무보다는 사회생활에 적응하는 법에 대해 먼저 알게 된 회사였습니다.

많은 일이 있었지만, 중요한 것은 긍정적인 마인드로

그 회사의 "장점"만 최대한 기억해야 한다는 것을 항상 느끼고 있습니다.

아무튼 그 힘든 백골 수색대에서도 2년을 잘 버티고 나왔지만

8개월 업무를 진행하고 결단을 내렸습니다.

#두 번째 도전

'W' 테스팅 회사를 다니면서 

여러 회사에 중고 신입으로 지원하였습니다.

하지만, 저는 아직 어렸기 때문에 회사의 네임벨류를 더 중요하게 생각했던 것 같아요.

그래서 면접 볼 때의 태도는 건방지고, 오만했던 것 같습니다. 나 자신을 너무 과장하려 하고 솔직하지 못했던 것이 

면접에서 많은 탈락을 했던 이유인 것 같습니다.

게임회사 QA에 지원했지만 별다른 성과를 올리지 못하고

마지막으로 'H' 교육그룹에 지원을 했습니다.

솔직함, 간절함을 어필했던 것 같습니다.

결과는 합격이었고 Tester에서 자회사 QA로 8개월 만에 이직을 하였습니다.

좋은 사람들을 많이 만날 수 있었습니다.

4년이라는 시간 동안 지적도 많이 받고, 칭찬도 많이 받았습니다.

인정받기까지 3년이라는 시간이 걸린 것 같습니다.

30살의 어린 나이로 Part Manager라는 직책도 경험해봤습니다.

하지만 인간의 욕심은 끝이 없다고 시간이 갈수록 새로운 업무에 대한 호기심과 열망이 하루가 다르게 늘어났습니다.

새로운 업무에 대한 호기심이 하루아침에 생기는 것은 아니지만 

뭔가 회사를 오래 다닐수록 회사 시스템이 눈에 보이게 됩니다.

어떻게 하면 " 일 잘했다"라는 소리를 듣고 , '어느 정도 수준까지만 일해도 인정받을 수 있다.'라는 게 다 눈에 보였습니다.

그렇게 되니 사람의 한계가 없음에도 불구하고, 이 정도면 되겠지?라고 스스로 맥시멈을 정해서 일을 하는 제 자신을 보고 회의감이 들었어요.

이렇게 나태 해진 건 회사 시스템이라고도 생각을 해본 적이 있습니다.(직책이 없었을 때의 업무와 직책이 생겼을 때의 업무가 차이가 있음에도 보상이 똑같았다..?)

하지만, 결국은 제가 이 시스템에 익숙해져서 나태해진 것이겠지만요.

그래도 저는 두 번째 회사에서 정말 많은 값진 경험과 좋은 사람들을 많이 만났습니다.

퇴사자가 정말 많은 회사지만 아이러니하게도 같이 일하는 직원들은 정말 좋은분들이고, 배울 점이 많은 분들이었습니다.

좋은 에너지와 업무 Skill을 대화를 통해서 많이 배웠습니다.

프로젝트 단위로 일을 하다 보니, 매번 같은 사람과 일을 하는 게 아니었기 때문입니다.

각자 살아온 환경, 일하는 방식이 모두 다르기 때문에 카멜레온처럼 업무 스타일을 많이 바꿔가면서 장점과 단점에 대해 체크하고 이를 바탕으로 업무 프로세스에 반영해본다던지, 위험성을 확인해본다던지 

집에 와서도 업무를 어떻게 해볼까 라는 생각을 많이 해봤습니다.

물론 시련도 많았습니다.

제일 기억에 남는 건 위에 말했듯이 퇴사자가 정말 많습니다.

QA팀도 예외는 아니었죠. 

인원이 절반 정도 나가서 팀을 다시 개편해야 하는 시기가 왔습니다.

그 시기에 제가 Part Manager 직책을 수행하게 되었습니다.

회사 스타일과 QA팀에 적응할 수 있는 인원을 채용해서 업무를 알려주고 회사에 적응할 수 있도록 도와주는 일을 해야 했습니다.

그리고 팀이 유지되려면 탄탄한 팀 내부 매뉴얼도 있어야 했습니다.

1년 동안 QA팀의 재건을 위해서 참고자료도 없는 Skill이나 프로세스를 고민하면서 구축하고

새로운 테스트 방법도 도입하고, 신규 직원들에게 더 많은 정보를 알려주기 위해 문서작업과 개인적으로 공부를 많이 했었습니다.

그래도 부족했지만요.

아무튼 이런 과정 속에서 생각도 많이 바뀌고 업무 스타일도 많이 바뀐 것 같습니다.

뭔가 예전에는 싸워서 쟁취해야 일을 잘한다?라는 생각이 있었지만 대화로 풀어나가면 더 좋은 결과물을 낼 수 있다는 점을 느꼈고, 여유를 잃지 말아야 한다는 점도 느꼈습니다.

이런 부족한 점이 많은 파트장이었지만 

믿고 의지해준 팀장님과 팀원분들께는 정말 감사한 한 해가 되었습니다.

세 번째 도전

만남이 있으면 헤어짐도 있는 법입니다.

물론, 더 같이 오래오래 일하고 싶은 마음도 있지만

현실적으로는 어렵죠.

그래서 아름다운 이별을 준비하기 위해 세번째 도전을 하려고 합니다.

다음 에피소드에서는 세번째 도전을 하기위해 어떤 준비를 했는지

포스팅을 하도록 하겠습니다.

그럼 이만 ㅡ★