문성준의 단단해지기

일곱 번째 에피소드입니다.

오늘 제목은 솔직합니다.

모든 업무는 투명하게 기록되어야 합니다.

투명하게 기록한다.

오늘의 핵심 키워드는 "기록" 입니다.

오늘은 제가 실무를 진행하며 겪었던 일에 대해 

MSG좀 첨가하여 예를 들어보겠습니다.

왜 QA 한테는 공유를 안 해주시나요?

프로젝트 단위로 QA를 진행하다 보면 엄청 다양한 일이 일어납니다.

그리고 여러 책임감 없는 사람도 볼 수 있습니다.

며칠 전에는 QA Plan, Design 기간이 종료되고 검증일이 시작한 후에 일부 정책이 변경되었다는 것을 알 수 있었습
니다.

명세 기반 작성법으로 Testcase를 작성하고 수행하게 되면 설계기간 이후에 발생되는 정책 변경 사항은 치명적입니다.

회사 정책 같은 경우에는 굉장히 민감한 사항입니다.

관련 사업부서, 마케팅 부서, 영업 부서도 정책을 기반으로 한 매뉴얼대로 움직이고 각 회사 법무팀에서 법적으로 위반되는 사항이 있는지 까지 확인을 하기 때문입니다.

그런 중요사항이 검증 시작 이후 공유가 된다면, QA는 다시 Testcase를 손 볼 수밖에 없습니다.

명세 기반 Testcase를 작성할 때는 명세서에 있는 기능에 대해 모든 Testcase를 작성한 후에 작성한 case들이 정책에 위반되지는 않는지 CrossCheck 프로세스가 추가되기 때문입니다.

하지만 QA를 단순 Tester로 보는 구성원, 혹은 회사라면 이런 정책 변경사항을 공유를 잘해주지 않습니다.

정책 같은 부분이 Software에 적용된다는 사실을 간과하기 때문이죠.

그렇기 때문에 최종적으로 QA Plan, QA Design 전에 QA 엔지니어는 바뀐 정책이 있는지에 대해 항상 확인을 해야 합니다.

사실 QA가 확인한다고 해서 100% 대비할 수는 없지만  QA 엔지니어는 항상 최악의 경우를 대비해야 되기 때문에  명심하고 조심해야 합니다.

또 QA 한테는 공유를 안 해주셨네요? 

이런 적도 있습니다.

Dev ↔ 기획자 둘만의 소통으로 인해 QA에게 정보가 누락된 경우가 있습니다.

이는 주로 빠른 업무처리를 위해 BTS에 등록하지 않고, 그 자리에서 즉흥적으로 기획을 변경하거나 개발을 수정하는 경우가 많습니다.

그래서 나중에 검증기간에 관련해서 결함으로 등록하면 돌아오는 답변은

" 기획자와 유선으로(구두로) 수정된 사항입니다."

라고 답변이 옵니다.

이럴 경우 화가 머리끝까지 치밀어 오릅니다.

같은 프로젝트를 진행하는데 왕따를 당한 기분이 드니까 말이죠.

사실 이런 경우에는 힘이 빠지긴 하지만 저 같은 경우는 프로젝트 관련 게시글 혹은 Slack에 공지를 합니다.

1. 기획 변경 시, 꼭 QA를 포함한 모든 관련 부서에게 공유 부탁드립니다.

2, QA 기간 동안에는 보고되지 않은 결함 수정은 진행되지 않아야 합니다.

3. 프로젝트 진행 시, 프로젝트와 관련된 모든 사항들은 해당 게시글(Slack 등)에 기록되어야 합니다.

라고 공지를 합니다.

왜 강하게 공지를 하냐면, 결론적으로 QA는 일을 두 번씩 하게 되는 무의미한 업무를 진행하게 됩니다.

예를 들어 기획에 맞지 않는 기능이 있어 해당 issue를 BTS에 등록합니다.

Assign to dev 상태로 등록이 되겠죠?

그러면 Fix 상태로 와야 될 결함이 Not a bug 상태로 오게 됩니다. 왜냐면 이미 QA 가모르는 상태에서 기획이 변경되었기 때문이죠.

그러면 해당 issue는 벌써 여러 상태 값이 존재하게 되고 QA > 개발 > QA > 기획 > QA라는 불필요한 핑퐁이 생겨나게 됩니다.

QA > 개발 > QA에서 끝나게 될 일을 말이죠.

이건 싸우겠다는 건가요?

제 경험상 프로젝트 진행 중 언성이 높아지는 경우는 위와 같이 어떠한 내용이 공유가 되지 않을 때입니다.

" 왜 공유해주지 않으셨죠?"

"저희는 몰랐는데요?"

"저희한테 공유 안 해주셨으니 책임지지 않겠습니다." 등등

사소한 내용이라도 공유가 되지 않았을 경우 같이 협업하는 입장에서 이미 기분이 상하기 때문에 언성이 높아질 확률이 높다고 생각됩니다.

그래서 제가 하고 싶은 말은 모든 업무는 투명하게 기록되어야 합니다.

왜 "투명하게" 기록되어야 하냐면, 각자 A라는 주제에 대해 소통을 하더라도 어떤 사람은 A로 이해를 하고 또 어떤사람은 B로 이해를 할 수 있기 때문입니다.

그렇기 때문에 업무에 대해 기록을 할 때는 객관적으로 기록을 해야 되며, 주관적인 생각이 들어갈 때에는 반드시 "제 의견은", "00팀 의견은" 이런 식으로 꼭 명시를 해줘야 됩니다.

그래야 추후 오해가 생기지 않고, 누구나 수긍 가능한 결과를 도출해낼 수 있기 때문입니다.

오늘은 업무를 진행할 때, 

불필요한 커뮤니케이션 또는 오해를 방지하기 위해 QA 엔지니어는 어떻게 업무를 진행해야 하는가에 대해

제 경험과 함께 알아봤습니다.

물론 다들 각자의 방법이 있겠지만 저는 투명하게 기록하는 것

업무의 정석이라고 생각됩니다.

그럼 Episode 07 마무리하겠습니다.

다음에 또 만나요~

여섯 번째 에피소드입니다.

제목이 오늘 엄청 특이하죠?

가수 임재범의 "너를 위해"를 패러디했습니다.

제목 : 프로젝트를 위해

거친 개발자와~~ 불안한 기획자와~~ 그걸 지켜보는 QA~~

실무를 하다 보면 여러 사람이 있습니다.

개발자로서의 프라이드가 엄청 강하신 사람이 있고,

경력이 얼마 되지 않아 자신이 한 기획에 대해 자신감이 없는 사람도 있습니다.

모든지 완벽할 수 없습니다.

제가 생각하기에는 완벽한 프로젝트는 개발&기획&QA가 서로 마주 보고 손바닥을 쳤을 때

짝 소리가 나야 합니다.

삼위일체가 되어야 한다는 뜻이죠.

오늘은 프라이드가 강한 거친 개발자, 경력이 부족한 불안한 기획자, 그걸 지켜보는 QA에 대해서 이야기해보겠습니다.

오늘도 쉬운 예를 들어보겠습니다.

여기 기획서가 있습니다.

구매하기 BTN을 클릭하면

구매하기 Alert 이 출력되어야 합니다.

QA 도중 해당 페이지에서 구매하기 BTN 을 클릭했는데 

바로 결제 페이지로 이동되는군요.

결함을 등록합시다.

이게 왜 결함이야!!!

개발자가 엄청 화가 났습니다.

왜일까요?

QA에서 BTS에 등록한 결함을 보고 왜 결함이냐고 묻습니다.

●QA : 기획서에 명시된 대로 BTN 클릭 시 Alert 이 출력되어야 합니다.

●Dev : 어차피 유저는 구매할 생각으로 눌렀는데, 왜 Alert을 띄워줘야 하죠?
그리고 또 결제 페이지로 이동되면 정상 동작 아닌가요?
이 issue #001 은 수정하지 않겠습니다.

●Planner : 헉! ㅠㅠ 

●QA : 흠... 

냉정하게 분석하기

●QA : 기획자님 해당 기능에 대한 기획의도가 무엇일까요?

●Planner : 어... 그냥 다른 사이트도 구매하기 BTN을 클릭하였을 때, Alert 이 나와서 동일하게 기획하였습니다.

●QA : 흠... 그러면 해당 기능에 대해서 수정을 진행할 수 없습니다.
사실 구매하기 BTN을 클릭하였을 때, 결제 페이지로 이동되는 현상은 정상적입니다.

●Planner : 어떻게 하죠 ㅜㅜ

●QA : 잠시만요...

기획자가 경력이 부족하여 자세한 히스토리를 모르는 업무에 대해

기획서를 쓰다 보니 이런 사소한 기능에서도 

Description이 왜 이렇게 정의되어 있는지 모르고 있습니다. 

이전 대화에서 기획자가 "다른 사이트도..... 동일하게...."

라고 말한 것 기억하시죠?

자 그럼 다른 사이트를 확인해보면 QA가 해야할 일은 두가지가 있습니다.

히스토리 파악하기

1. 다른사이트를 기획한 사람에게 히스토리를 물어봅니다.

●QA : 혹시 00 사이트를 기획하실 때, 해당 Alert을 띄우는 이유에 대해 알고 계신가요?

●다른 기획자 : 흠... 잘 모르겠지만 CS 관련 부서에서 요청이 들어왔었어요.


2. 관련된 프로젝트 문서를 확인해보기 

CS 관련부서에서 요청이 들어왔기 때문에 CS 확인할 수 있는 게시판에서 특정 키워드로 검색을 하거나 

관련된 프로젝트 문서에 대해 열람 권한을 획득한 후 히스토리를 파악할 수 있습니다.

●QA : 그럼 해당 프로젝트를 진행할 때에 문서를 확인할 수 있도록 열람 권한을 주시겠습니까?

●다른 기획자 : 네 ~ 드렸습니다.

관련 프로젝트 문서를 확인하던 도중 

CS 관련부서의 요청을 확인할 수 있었습니다.

이유는 두 가지였습니다.

1. 강성 컴플레인 유저

2. 구매하시겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많았던 점.

자 그럼 이제 개발자를 설득할 시간이 되었습니다.

수정해주세요. 얼른!!

●QA : 개발자님

●Dev : 왜요! 

●QA : Issue #001 수정해주셔야겠습니다.

●Dev : 왜요!! QA 도 개발팀 소속이면서 기획자 편을 들어주는 거예요?!

●QA : 해당 기능은 과거 유저 CS로 인해 생긴 기능입니다.
바로 구매 페이지로 이동하여 강성 컴플레인을 건 유저가 있었습니다.
그리고 구매하겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많아 다른 사이트에도 모두 Alert 을 노출시켜주고 있습니다.
그래서 이번 00 사이트에서도 구매하기 BTN을 클릭하였을 때, Alert 이 출력되어야 합니다.

●Dev : 깨갱.. 알겠습니다. 수정되었습니다.

이렇게 해서 잘 마무리되었습니다.

물론 위의 예시는 쉽게 설명하기 위해 들은 예시입니다.

실무를 하다 보면 많은 사람들과 커뮤니케이션을 하지만

늘 잘되는 일은 없습니다.

실제로 저는 위와 같은 경험을 굉장히 많이 겪었습니다.

Minor 한 결함이고, 당연하다고 생각되는 기능이지만

의문을 가지고 자신이 한 개발이 항상 맞다!

이런 식의 대화도 많이 겪었습니다.

여기서 QA는 그 누구의 편도 아니며, 항상 품질만을 생각해야 되기 때문에

이런 상황에서는 "근거"가 명확해야 합니다.

저는 회사를 다닐 때, 항상 다른 사람과 친하게 지냅니다.

물론 사람들과 대화하는 걸 좋아해서 그렇죠.

이런 상황이 오면 또 다른 사람들에게 도움을 받기에도 엄청 좋습니다.

물론 저도 제 일이 아니더라도 도움을 받는 만큼 돌려줍니다.

그리고 항상 확인하는 것이 프로젝트를 진행할 때에 유사한 프로젝트는 어떻게 진행되었으며

특이사항이 있었는지에 늘 체크를 합니다.

그리고 이번 프로젝트에서 예외적인 상황이 나올 수 있는지 미리 체크리스트를 작성하여 대비를 하는 것이지요.

오늘은 거친 개발자, 불안한 기획자 사이에서 QA는 어떻게 행동해야

품질을 높일 수 있는지 알아보는 시간을 가졌습니다.

QA 는 항상 품질만 생각해야 합니다. 

커뮤니케이션은 양팔저울처럼 어느 하나 기울어진 곳 없이 

동등하게 대해야 합니다.

그럼 Episode 06 마무리하겠습니다.

다음에 또 만나요~

다섯 번째 에피소드입니다.

입사 후 수습기간이 끝나고 나면 

이제 저도 정식직원입니다.

그러면 나를 대표할 수 있는 종이 한 장 필요하겠죠?

오늘의 키워드는 명함 입니다.

사람을 주로 만나는 높은 자리의 임원 혹은 영업직이 아니면 

명함을 주로 쓰는 일은 없을 겁니다.

그래서 명함을 그냥 포스트잇처럼 주고받고 하는 사람이 있는데요.

그건 더더욱 안되죠.

오늘은 명함 예절에 대해 알아보도록 하겠습니다.

명함 "名銜" 이름 명, 재갈 함

성명, 주소, 직업, 신분 따위를 적은 네모난 종이 쪽. 흔히 처음 만난 사람에게 자신의 신상을 알리기 위하여 건네준다.

사전적 의미입니다.

자신의 신상 혹은 존재를 알리기 위해 사용하는데요

관용구로는 

명함도 못 들이다 라는 표현과 명함을 내밀다 라는 표현을 자주 쓰곤 합니다.

명함도 못 들이다 라는 표현은 주로 수준이나 정도 차이가 심하여 도저히 견줄 바가 못 될 경우 사용하죠.

예를 들면,

"Critical issue를 을 분석하기 위해 초급 테스터가 왔다가 명함도 못 들이고 갔다." 

라는 식으로 쓸 수 있겠네요.

명함을 내밀다 라는 표현은 존재를 드러내 보일 때 사용하곤 합니다.

예를 들면,

" QA 업계에 문성준이 처음으로 명함을 내밀다."

하하하 이런 식으로 존재를 드러내어 보일 때 사용합니다.

위의 두 가지 예를 든 것은 그만큼 명함의 중요성을 강조하기 위해서 예시를 들었습니다.

그만큼 중요한 물건을 남에게 전달할 때도 소중히 전달해야겠지요?? 

1. 탈것을 타고 전단지를 뿌리듯 전해준다.	2. 공중으로 뿌려 던진다.
3. 수리검 던지듯 던진다.	4. 두 손으로 건네며, 상대방이 명함을 바로 확인할 수 있게 상대 방향으로 돌려서 전달한다.

어려운 문제였는데요.

정답은 4번입니다.

명함을 줄 때는 두 손으로 건네며, 상대방이 명함을 바로 확인할 수 있게 상대 방향으로 돌려서 전달해야 합니다.

그리고 명함은 서열이 낮은 사람이 먼저 건네야 합니다. (단, 상대 서열이 낮다고 해서 앉아서 명함을 받는 행위는 예의가 아닙니다.)

그렇지만 예외는 있습니다.

만약 파견업무를 갔지만 나보다 서열이 낮은 사람이라도 방문한 사람이 먼저 건네는 것이 예절입니다.

또한, 한 손으로 전달하는 방법도 있습니다.

오른손으로 전달해야 하며, 상대 방향으로 돌려서 전달해야 합니다.

또한 왼손은 오른손을 받쳐서 전달해야 합니다.

명함을  같이 교환할 때 주로 한 손 전달법을 사용합니다.

오른손으로 주고, 왼손으로 받아야 합니다.

그리고 항상 명함을 줄 때는 손가락으로 이름을 가리는 일은 없어야 합니다.

오늘은 명함을 전달하는 방식에 대해 알아봤습니다.

QA 엔지니어라고 해도 명함이 있고 언젠가는 명함을 주거나 받는 일이 생길 수 있습니다.

어버버 하다가 예의범절 없는 놈이라고 낙인찍히지 말고

간단한 예절 숙지해서 

젠틀한 QA 엔지니어가 됐으면 좋겠습니다.

그럼 Episode 05 마무리하겠습니다.

다음 Episode로 돌아오겠습니다.

두 번째 에피소드입니다.

저는 왜요? 를 굉장히 좋아합니다.

왜요?

오늘의 키워드는 : 왜요? 그래서요?입니다.

항상 제가 업무를 배울 때는  YES맨입니다.

넵, 해보겠습니다, 네 알겠습니다.

왜냐? 하지도 못할 일을 주지는 않거든요.

근데 여기서 YES 맨으로만 끝난다면, 그냥 평생 YES 맨이 되는 거예요.

항상 WHY? 가 붙어야 합니다.

예를 들어보겠습니다.

직장상사가 "엑셀 시트에 본인 생년월일을 입력해주세요."라고 지시를 했습니다.

별로 어렵지 않은 일이니 "네" 하고 그냥 작성하고 끝날 수 있어요.

그런데 저 같은 경우는 " 네 알겠습니다. 그런데 시트에 생년월일을 적는 이유가 있나요?"라고 물어봅니다.

그러면 직장상사가 " 팀 내 문화활동으로 팀 내 생일자가 있으면 점심 회식을 한다."라고 대답을 해주겠죠?

그러면 사소한 예를 들었지만 여기서 WHY?라고 물어본 경우 알 수 있는 사실이 있습니다.

첫 번째, 팀 내 문화활동이 있다는 걸 알 수 있습니다. 그러면 또 어떤 문화활동이 있는지 물어봄과 동시에 상사와 여러 대화를 이어나갈 수 있습니다.

두 번째, 팀원들의 생년월일을 알 수 있습니다. 만약에 다른 팀원들이 선물을 줬는데 저는 안 챙겨준다면 조금 섭섭하겠죠?

이건 WHY?라는 물음에 여러 가지 사실을 알 수 있는 상황에 대해 지어낸 예시입니다.

실무에서는 어떻게 진행되는지 알아보겠습니다.

첫 번째 회사와 다르게 두 번째 회사에서는 Testcase를 작성할 때

one step one result의 방식을 내부 role로 정해서 사용하고 있었습니다.

그래서 저는 경력직으로 입사를 하였기 때문에 제 스타일대로 작성을 하려고 했으나 상사에게 한번 더 물어봤습니다.

" 여기 회사의 Testcase 리뷰를 해보니 TC가 세분화되어있더라고요. 왜 그렇게 작성하였나요?"라고 물어보았습니다. 

그러자 상사는 " BTS(Redmine)을 사용합니다. 그래서 1건의 Testcase에 1건의 issue를 입력하면 결함 관리가 수월하기 때문에 그렇게 작성하고 있습니다."
라고 대답하였습니다.

업무환경이 첫 번째 회사에서는 BTS를 JIRA를 사용했지만, 두 번째 회사에서는 폐쇄적인 느낌의 Redmine을 사용하였습니다.

왜냐하면 사내 인트라넷과 연동되는 기능이 있기 때문에 Redmine을 사용하고 있었던 것인데요.

업무의 99%가 인트라넷으로 이루어지는 시스템이었던 거죠.

그렇기 때문에 Testcase 진행 현황, 결함 관리를 위해 one step, one result를 사용하고 있다고 이해를 하게 되었습니다.

만약 제가 why? 를 하지 않았다면, 그냥 남들 하는 방식을 따라 하거나 불만을 표시했겠지만 TC를 작성하는 방식에 대한 한 번의 질문으로 회사의 업무체계가 어떻게 되어있는지 확인할 수 있었습니다.

WHY는 협업을 하고 있는 타 부서원과도 효과적인 대화를 이끌어낼 수 있습니다.

저 같은 경우는 책이나 구글링으로 지식을 습득합니다.

그러나 제일 효과적인 방법은 현직자한테 대화로 듣는 방법이었습니다.

요즘은 유튜브에서 다양한 동영상으로 지식을 습득할 수 있는데요. 

바로 앞에서 듣는 것만큼 귀에 쏙쏙 박히는 건 없겠죠??

그래서 저는 개발자, 기획자, 디자이너 등등 유관부서와 친분을 쌓는 행위도 QA 업무에서 굉장히 중요하다고 생각합니다.

이들이 가지고 있는 정보는 정말 방대합니다. 또한 제가 숙제처럼 지식을 습득하는 게 아니라 자연스럽게 습득이 되기 때문에 더 기억에도 오래 남습니다.

기획이 왜 이렇게 되느냐, 개발을 왜 이렇게 했던 거냐 하면서 회사 Histroy도 알 수 있습니다.

이런 정보들이 곧 QA 엔지니어에게는 노력으로 얻을 수 없는 영역 "센스"에 한발 짝 다가가는 행위라고 봅니다.

개발 리뷰, 기획 리뷰 또는 프로젝트 회의 때 이런 History 나 T.M.I가 회의시간을 단축시켜줄 수도 있고, 나아가 프로젝트의 방향성까지 정할 수 있게 된답니다.

주저리주저리 말이 길어졌는데, 강조하고 싶은 건 순수한 궁금증의 why입니다.

공격적인 why가 되면 흠...

모두가 당신을 피하게 될 거예요 ㅎㅎㅎ

오늘은 제가 QA실무를 하면서 다른 사람들에게 좋은 인상을 남겨줬던

순수한 궁금증의 WHY 커뮤니케이션에 대해 글을 작성해봤습니다.

그럼 Episode 02 마무리하도록 하겠습니다.

내일 봐요~~