문성준의 단단해지기

2019년 3월 7일에 작성한 제 게시글 중 가장 인기가 많은 게시글 중 하나인 

https://ddanx2.tistory.com/96

실무에서 쓰이는 ad-hoc testing, 그리고 random testing에 관련된 글이 있습니다.

이때는 QA 경력이 1년차일때, QA 보다는 Tester에 가까운 입장에서 쓴 글이었습니다.

그러나 지금은 하나의 part를 관리하는 part manager 로써 Ad-hoc testing에 관한 제 생각을 써보려고 합니다.

그때 제가 Ad-hoc testing에 대해 마지막으로 제 생각을 적었는데요 한번 보겠습니다.

이때 제가 쓴 글을 하나하나 분석해보겠습니다.

제 생각은 프로젝트의 테스트 케이스 수행을 마무리 한 단계에서 예상치 못한 결함을 도출할 때는 Ad hoc, Random testing 둘 다 진행해도 좋다고 생각됩니다.

이 때는 Ad-hoc testing의 매력을 느끼지 못한 상태에서 단순 사전적 의미로 분석하고 제 생각을 적었었는데요.

사실 이때는 Tester의 입장에서 작성해서 둘 다 진행해도 좋다고 썼습니다. 

두 가지 테스트 방법을 동일선상에서 생각했기 때문이죠.

그러나 적재적소에 맞는 Testing 방법이 있습니다. 본인이 판단하기에 Ad-hoc Testing이 필요한 경우에는 Ad-hoc testing을 진행하면 되고, Random Testing 이 필요한 경우에는 Random Testing을 진행하면 됩니다.

다만 제가 하고자 했던 말의 요점은 Ad-hoc Testing 안에 Random Testing 이 포함된다고 느꼈기 때문에 저런 워딩이 나왔다고 생각됩니다.

그러나 기간이 촉박한 프로젝트에서는 모든 Testcase를 수행한 이후 Ad hoc testing 만 진행하는 게 맞다고 생각됩니다.
기간이 촉박하고 일정을 미룰 수 없을 때, Random testing을 통해 임의의 값을 입력하여 결함을 찾아냈을 때
결함 보고까지의 범위를 측정하는 시간이 많이 소요된다고 생각합니다.

이 부분을 작성한 이유는 제가 업무를 할 때 1~2달 사이의 프로젝트 업무를 많이 진행하였습니다.

3일 정도의 기획서 리뷰 기간을 가진 후 5일 정도 Testcase를 작성했습니다.

명세 기반의 Testcase를 작성하다 보면 느끼는 점이 많은데요.

사실 명세서는 유저의 요구사항이나, 유관부서의 요구사항이 반영되어있다고 하더라도 

소프트웨어의 품질을 높이는 데에는 한계가 있습니다.

어떻게 보면 사용설명서 같은 느낌으로 정해진 Step과 정해진 Result 가 나오기 때문입니다.

그래서 정해지지 않은 Step으로 진행하였을 때 소프트웨어 특성상 예기치 못한 Result 가 나오기 때문에

Ad-hoc testing을 진행해야 한다고 생각했던 것 같습니다.

그리고 이 생각을 뒷받침하는 근거로 실제 제가 근무하는 환경에서 Ad-hoc testing으로 나온 critical 한 이슈가 많았기 때문에 더욱더 그렇게 생각한 것 같네요.

그리고 Random testing의 정의를 봐도 일정이 촉박하면 테스트 케이스를 설계하여 문서화할 시간도 없다고 생각됩니다.
그래서 Ad hoc testing 만 단독으로 진행할 때는 프로젝트의 규모가 작아야겠죠..?

이 부분의 생각은 3년이 지난 지금 많이 바뀌었습니다.

2019년에 간과했던 부분은 Ad-hoc Testing을 진행할 때, Tester 나 QA 엔지니어의 역량이라는 필수 요소를 배제했었던 점이 가장 크게 작용했는데요.

Ad-hoc testing을 매력적으로 보는 이유는 보이지 않는 "역량"에 따라 결과물이 달라지기 때문입니다.

Part manager가 된 지금 QA Team을 구성할 때 제일 먼저 보는 것이 구성원의 경력입니다.

예를 들면,  신입직원, 1년 차, 3년 차, 5년 차 총 4명의 테스터가 있다고 한다면, 저는 신입직원, 5년 차의 Ad-hoc testing 의 결과에 주목할 것입니다.

왜 신입직원의 testing 결과를 주목할 것이냐 의문을 가지실 수 있는데요.

Testing 경력이 얼마 없기 때문에 고정관념이 없고, 예외적인 시도에 대해 열려 있기 때문입니다.

그리고 5년차의 Testing을 주목하는 이유는 베테랑 테스터의 실력을 믿기도 하는 것이지요.

물론 경력이 테스팅 역량을 대변해 줄 수 있는 수단은 아니지만 위험성을 줄일 수 있기 때문에 업무 분배에 참고하고 있습니다.

그래서 제가 하고 싶은 말은

"역량"이 높은 사람은 일정이 촉박해도 Testcase 나 CheckList 설계가 가능하며 동시에 Testing 도 무사히 마칠 수 있습니다.

그래서 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 생각이 바뀌었습니다.

아래 관련 게시글을 보면서 더 이어나가겠습니다.

https://ddanx2.tistory.com/125

제가 Flow Chart 기반으로 Test Case를 작성하는 방법에 대해 공유한 적이 있습니다.

주로 기획문서가 없는 소프트웨어에 대해 Testing을 진행할 때 사용하는데요.

옛날에는 기획문서가 없는 소프트웨어에 대해 Ad-hoc Testing으로만 진행될 수 있다고 말했지만

이제는 역으로 기획문서가 없어도 소프트웨어를 보고 Flow Chart를 작성할 수 있고, 그 Flow Chart 를 기반으로 Test case , Scenario 등 여러 문서를 작성할 수 있는 실력을 갖추었습니다.

그래서 2019 년과는 다르게 Ad-hoc Testing 만 단독으로 진행할 필요가 없다고 말하고 싶습니다.

결국 지금 와서 생각해보면 2019년의 제 QA 역량과, 2022년의 제 QA 역량이 다르고 그만큼 성장했기 때문에 생각이 바뀌었다고 볼 수 있습니다.

이제 또 3년 뒤에 저는 해당 글을 다시 가지고 와서 2025년에 작성하는 Ad-hoc testing에 대한 나의 생각 이런 식으로 포스팅을 할 수도 있겠네요.

아무튼 밤에 두서없이 쓴 글이긴 하지만 읽어주셔서 감사합니다.

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

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

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

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

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

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

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

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

그건 더더욱 안되죠.

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

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

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

사전적 의미입니다.

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

관용구로는 

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

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

예를 들면,

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

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

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

예를 들면,

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

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

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

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

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

어려운 문제였는데요.

정답은 4번입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

간단한 예절 숙지해서 

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

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

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

진짜 대박입니다.

https://naver.me/5AmEM4Ta

오늘 중요한 미팅이 있어서

식사자리를 찾던 도중

인테리어가 깔끔해 보여 들어간 곳입니다.

인테리어 정말 깔끔하죠???

테이블을 한번 보겠습니다.

테이블에 앉으면

이렇게 주문을 할 수 있는 태블릿 PC가 있습니다.

저는 창가쪽에 앉았어요.

통닭부터 해서 안주까지 너무 종류가 많습니다.

뭘 먹을지 정말 고민됐는데요.

양념 반 치즈 반 통닭, 갈비 통닭(반마리) 시켰습니다.

반마리 단위로도 팔아서 정말 나이스 했습니다.

치킨집 갔을 때 보통 4명이서 2마리 먹잖아요,

그럼 3명이서 모이면? 2마리는 좀 과한 느낌이 있습니다.

그렇지만! 여기는 반마리도 팔아서 메뉴 고를 때 너무 좋았어요.

안내사항입니다.

화장실도 깔끔하고요

핸드폰도 유료로 충전할 수 있습니다.

그리고 젤 신기하고 좋았던 건

로 봇 서 빙

이렇게 로봇이 가져다줍니다.

너무 신기했어요.

음식이 테이블까지 옵니다.

음식을 받고 확인을 누르면 로봇이 다시 가요

그래서 그런지 몇 시 이후부터는 노 키즈존으로 운영하더라고요

몇 시부터인지는 확인을 못했는데

애들이 신기해서 막 건들면 위험하잖아요~~

맞는 운영정책인 것 같습니다.

살얼음 맥주.... 말이 필요 없는 천국의 음료

치즈 반 양념 반 통닭... 안에는 밥과 누룽지까지....

갈비양념통닭(반마리) 맛없는 메뉴가 하나도 없습니다.

가게도 엄청 넓고요.

가운데 단체석도 있습니다.

로봇이 다 배달하는 것도 아니고 뜨겁거나 부상의 위험이 있는 메뉴는

직원이 직접 가져다주시기도 합니다.

음식 진짜 너무 맛있었고요

친구들이랑 아지트로 써야겠어요 ㅋㅋㅋㅋ

수내역 구도로 통닭 왕 추천입니다.

네 번째 에피소드입니다.

실무를 하다 보면 의견이 맞지 않거나, 돌발행동을 하는 사람들을 심심치 않게 볼 수 있습니다.

그때 대부분은 

" 점마 와 이라노?"

이렇게 생각할 겁니다.

하지만!! 우리 긍정적 사고방식을 가지고 있는 QA 엔지니어들은

" 아 그럴 수 도 있겠구나~"

긍정적인 사고방식, 열린 사고방식으로 여러 사람들의 의견을 취합할 수 있어야 합니다.

오늘의 키워드는 긍정, 오픈마인드 입니다.

여기 머리카락이 있습니다.

당연히 머리카락입니다.

그런데 누군가는 스파게티라고 주장을 하고 있습니다.

이해가 가지 않습니다만. QA 엔지니어라면 왜 스파게티라고 주장을 하는지 인터뷰를 진행해야 합니다.

선생님 왜 스파게티인가요?

"제가 봤을 땐, 스파게티가 확실합니다. 왜냐하면 이태리에 한 음식점에서 먹었던 스파게티와 모양이 똑같습니다."

선생님 그러면 저걸 드실 수 있으신가요?

"스파게티이니까 먹을 수 있겠죠."

후루 룹 

네, 그렇습니다.

결국 선생님은 실려가셨습니다.

여기서 우리는 간과했습니다. 우리는 익숙해진 사물에 대해서 충분한 가이드라인을 공지하지 않았습니다.

이런 비상식적인 상황은 비개발자가 포함된 회의에서 발생할 수 돼있고, 종종 CS로 인입되기도 합니다.

왜냐면 우리는 우리가 하는 일에 대해 익숙해져 있기 때문에 간과할 수 있습니다.

그래서 QA는 "그럴 수도 있겠다. 저걸 스파게티라고 생각하는 사람이 있을 수 있으니 사전에 스파게티가 아니라는 것을 알려주는 장치를 심어놔야겠다."

라고 생각을 해야 됩니다.

다시 시간을 돌려서 선생님이 실려 가기 전 상황으로 돌아가 보겠습니다.

선생님 혹시 저게 스파게티처럼 보이시나요?

" 저게요?? 저건 스파게티가 아니라 누가 봐도 머리카락입니다!"

다행입니다.

한 번에 머리카락임을 인지하였습니다.

QA 엔지니어는 항상 오픈 마인드를 가져야 합니다.

위와 같이 왜 저렇게 생각하였을까? WHY에 대한 답을 생각해 내야 합니다.

그렇게 하기 위해서는 긍정적인 사고방식을 가져야 합니다.

나와 다른 의견에 대해서 거부감을 보이기보다 왜 다른 의견을 가지고 있는지 생각해야 됩니다.

충분히 훈련할 수 있습니다.

사소한 것부터 말이죠.

극단적인 예를 들어보겠습니다.

옆자리 신입사원이 지각을 하였습니다.

당연히 ' 신입사원이 벌써부터 지각을 해?'라는 괘씸한 생각이 들겠지만

우리는 긍정적인 사고와 오픈 마인드를 가지고 있는 QA 엔지니어입니다.

" 오늘 조금 늦게 오셨네요. 이유가 있으실까요?"

그러면 신입사원이 이유를 말하겠죠.

"사실 전날 술을 마셔서 늦잠을 잤습니다."

속으론 열이 나겠지만,

"그러면 술을 마시기 전에 컨디션을 드시거나, 알람을 여러 개 맞춰놓으면 늦잠은 안자더라고요"

상황에 대해 공감해주며 대안을 제시해주는 방법으로 이끌어 나가는 것 

긍정적인 사고와 오픈마인드를 가지는 첫 발걸음입니다.

물론 계속되면 얄짤없이 바로 팀장님께 보고합니다. 흐흐흐

사실 긍정적인 사고를 갖는다는 건 내 속이 타들어갈 수도 있는 위험하기도 한 사고방식이기도 합니다.

긍정적인 사고방식이라고 해서 뭐든 다 OK가 아닌 품질을 높일 수 있는 선에서 OK가 되어야 합니다.

즉, 여러 의견을 존중하고 취합하려면 긍정적으로 생각하는 것이 첫 발걸음이 된다고 말씀드리고 싶습니다.

오픈마인드 또한 모든 결함 가능성을 생각해야 하는 QA 엔지니어에겐 필수 능력치입니다.

오픈마인드는 긍정적인 사고방식을 습득하게 된다면 자연스럽게 얻어질 것입니다.

결국 한 단계 더 성장하려면 이렇게 받아들인 의견을 취합해서 설득하고 전달하는 것!

제일 중요하다고 생각됩니다.

위의 스파게티 선생님 예시처럼, 우리는 Web, App을 제작하고 사용자들에게 전달할 때 가이드라인을 제시하는 이유가 있습니다.

사용자들이 편히 사용하라고 가이드라인을 제시하지만, 스파게티 선생님처럼 의도하지 않은 방식으로 사용하는 유저들에게 사전에 장치를 심어놓는 것이죠. 

여러 의견에 대해서 수용할 수 있는 것

그 의견들을 종합해서 낸 결론으로 다른 상대를 설득해야 하는 것

오픈 마인드로 살아가는 것

제가 일하고 소통하는 방식입니다.

오늘은 나와 다른 의견에 대해 

QA 엔지니어는 어떤 역량을 가지고 의견을 대해야 하는지

간략한 예시와 함께 알아봤습니다.

업무를 진행하다 보면  나와 다른 의견에 대해 설득하는 것만큼 힘든 일이 없습니다.

그렇지만 왜 나와 다른 의견을 낸 사람이 그렇게 생각하는지에 대해 알아보기 위해서는

긍정적인 사고방식과 오픈마인드가 필요하다고 강조하고 싶습니다.

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

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

세 번째 에피소드입니다.

옛 속담 중에 사공이 많으면 배가 산으로 간다는 말이 있습니다.

여러 사람이 저마다 자기주장대로 배를 몰려고 하면 결국 배는 물로 못 가고 산으로 올라간다는 말로 

지시하고 간섭하는 사람이 많으면 일이 제대로 되기 어렵다는 뜻이에요.

그러나 저희는 QA 엔지니어입니다. 산에 올라간 배를 끌고 내려와야 해요.

그래서 직장인들이 항상 품속에 사직서를 들고 다닌다지만, QA 엔지니어는 차선책을 들고 다녀야 됩니다...

오늘의 키워드는 최선과 차선 입니다. 

지금 프로젝트가 산으로 가고있습니다.

거리를 두고 보니 왜 프로젝트가 산으로 가고 있는지 알겠네요.

정작 다른 사람들은 눈에 보이지도 않겠지만요.

아니, 눈에 보이지만 못 본 척하는 것 일수도 있지만요.

왜 내가 참여하는 프로젝트 구성원들은 협력이 아닌 난투를 좋아하는 것일까?

왜 일정 연기에 대한 긴급회의, 리뷰는 항상 누군가가 범인이 되길 바라고 탐정놀이를 할까?

그래서 프로젝트 QA Lead를 하다 보면 인민재판에 끌려가지 않을까... 하는 걱정이 앞설 때가 있어요...

걱정 마세요.

QA 엔지니어는 절대로 싸움에 휘말려서도, 주도해서도 안됩니다.

요구사항을 만족할 때까지 품질향상에 신경 써야 돼요.

선수는 전광판을 보지 않습니다. 하하하

그렇습니다.

카우보이가 되어서 산에 있는 배를 끌어내려서 목적지에 가야 합니다.

이미 예정된 일정보다 늦춰지거나 긴급 이슈가 발생했을 때 QA의 목표는 하나입니다.

요구사항을 만족할 때까지, 일정 수준 이상의 품질이 나올 때 까지 끌고 와야 합니다.

예정된 일정대로 계획대로 흘러간다면 최선책이겠지만

이제부터는 차선책을 생각해야 됩니다.

예를 들어 상황을 부여해보겠습니다.

퇴사율이 높은 회사에서 일을 하고 있는 QA 엔지니어가 있습니다.

요구사항 전달 > 기획 정의 > 개발 > 테스트 > OPEN의 프로세스로 프로젝트를 진행하고 있었습니다.

테스트 단계에서 예상치 못한 기획이슈가 발생했습니다.

테스트 기간을 늘려야 하는데 기획을 정의하는 기획자가 오늘이 마지막 날이라네요.

QA 엔지니어는 눈앞이 깜깜해졌습니다.

이미 예정된 OPEN 일자는 다가오고 있습니다.

주변에서는 프로젝트를 엎어야 한다. 다시 뜯어고쳐야 한다. 누가 책임을 질 것이냐.. 등등 

사공이 많아질 거 같은 기분이 드는데요?

여기서 우리는 어떻게 해야 될까요??

놀랍게도 이 상황은 제가 겪은 실화입니다.

그래서 제가 진행한 방법으로 설명해드리겠습니다.

저는 일단 프로젝트에 참여하는 모든 이해당사자들에게 현재 상황에 대해 공유를 했습니다.

제가 상황 공유를 할 때는 항상 두괄식 표현을 씁니다.

즉 말하고자 하는 핵심 내용을 첫 문장으로 써야 합니다.

상황이 어떻고 누가 나갔으며, 개발이 덜됬고 일정이 부족하다? 

위에서 볼 때는 변명으로 느껴질 수 있기 때문입니다.

그리고 제가 두괄식 표현을 쓰는 이유는 항상 근거가 있기 때문입니다.

저는 차선책을 가지고 있었습니다.

문제가 발생한 기획이슈 부분에 대해 위험성을 먼저 인지하고 있었습니다.

왜냐하면 처음 시도하는 기법이었고, 기존 인력이 아닌 새로운 인력들로 구성된 팀이었기 때문입니다.

그렇기 때문에 저는 타 업체가 만든 유사한 프로그램은 어떻게 동작하는지에 대해 모든 분석을 미리 완료했었습니다.

그렇기 때문에 두괄식 표현으로 결론을 먼저 전달한 다음 그 이후로 설득을 진행했습니다. 물론 100% 근거 있는 자신감으로요.

설득하기 위해서 저는 요구사항에 포커스를 맞췄습니다. 

그다음 현재 우리가 가용할 수 있는 모든 시간과 인력을 동원해서 요구사항을 만족하는 데에 목표를 두고

QA 엔지니어인 제가 이슈가 발생한 부분에 대한 기획을 일부 수정하였습니다.

해당 이슈사항에 대한 해결책과 품질 가이드라인을 이해당사자들에게 전달하였습니다.

그 결과 초기 기획과는 다르지만 결국엔 요구사항을 만족하는 결과물이 나왔습니다.

어떻게 보면 임기응변이거나 운이 좋았다고 할 수 있겠지만 

퇴사율이 높은 회사에서 일을 하고 있는 QA 엔지니어는 항상 차선책을 품고 다녀야 합니다.

그래서 초기 일정에 대한 계획 수립할 때에도 참여하는 인력 외의 유사한 작업을 진행한 인력, history 등 프로젝트에 도움이 되는 정보를 모두 파악하고 있어야 합니다. 

이렇게 글로 쓰면 어렵다고 생각하실 수 있는데

쉽게 말하면 차선책은 소화기 같은 겁니다.

화재가 발생하지 않으면 최선이겠지만, 화재가 났을 경우를 대비해 항상 소화기를 구비하고 있죠?

실무도 똑같습니다.

최악의 상황이 발생하지 않으면 좋겠지만, 최악의 상황을 대비한 해결책은 항상 존재합니다.

문서를 백업해 둔다던지, 작성하던 글을 중간저장한다던지 이런 것들이 차선책입니다.

위험을 인지하는 것 으로부터 여러분들의 차선책은 이미 준비되어있습니다.

당황하지 않는 것, 보이지 않는 긴장을 하고 있어야 하는 것 

제가 일하고 소통하는 방식입니다.

오늘은 예상치 못한 상황에 대해

QA 엔지니어는 어떻게 대처를 해야 하는가에 대해 

간략한 상황설명과 함께 알아봤습니다.

불안, 긴장, 초조 , 압박이 몸을 지배하면 안돼요 ㅠㅠ 

항상 차선책을 생각하는 습관을 가지는 게 좋습니다.

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

다음 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 마무리하도록 하겠습니다.

내일 봐요~~

오늘은 제가 처음 QA 조직에 들어가게 되었을 때 기억을 더듬어 작성해보았습니다.

물론 MSG 조금은 치도록 하겠습니다.

오늘의 키워드는 : 먼저! 그리고 열정!입니다.

첫 번째 회사에 입사하고 낙동강 오리알 마냥 혼자 방치되어있던 적이 많았습니다.

물론 신규 입사자에 대한 프로세스가 시스템화 되어있는 대기업 같은 경우는 그럴 일 없겠지만요.

아무튼 첫 번째 회사에 입사했을 땐, 다들 설날 전에 업무를 마무리해야 한다고 바빴습니다.

아침에 가서 인사하고 9시부터 18시까지 앉아만 있었습니다.

그래서 저는 팀장님께 바쁜 일이 끝나면 저도 업무에 빠르게 적응하기 위해 업무 매뉴얼이 있냐고 물어봤는데

없다고 가만히 앉아있으라고 하더라고요. (이때, 바로 퇴사하지 않은 게 후회가 됩니다.)

아무튼 첫 번째 회사에서 제가 진행한 커뮤니케이션 방법은 "먼저 말 걸기, 열정 보여주기"였습니다.

먼저 말 걸기, 열정 보여주기 같은 경우는 PASS로 갈 확률이 높지요.

그러나 말도 안 되는 중소기업들은 항상 우리 주변에 있으니 조심하자고요. ㅋㅋㅋ 

사실 회사에서 요구하는 것은 1인분 + α입니다.

누구에게나 일을 가르치면 100 명중 99명은 전공이 아니더라도 따라 할 수 있을 겁니다.

그런데 여기서 중요한 건 가르쳐준 일만 하느냐, 자기 것을 만들어서 응용을 할 수 있느냐 문제입니다.

응용을 잘하는 대다수의 사람들은 먼저 말 걸기, 열정 보여주기의 커뮤니케이션을 적극 활용하고 있었습니다.

두 번째 회사의 경우에는 경력직으로 입사하였지만 3개월이라는 수습기간이 있었는데요.

저는 두 번째 회사에서도 항상 먼저 말 걸기, 열정 보여주기 커뮤니케이션을 적극 활용하였습니다.

사실 새로운 환경에 적응한다는 것이 얼마나 두려운 일인지 잘 알고 있습니다.

그러나 입장을 바꿔 생각해보면 입사자 말고 원래 있던 조직원들은 제가 새로운 환경이라고 느껴질 겁니다.

서로 새로운 환경을 맞이하게 되는 것이니 조직원들에게 무언갈 바라는 행위는 이기적인 모습이라고 느껴졌기

때문에 저는 어딜 가나 먼저 다가가기, 열정 보여주기 커뮤니케이션을 진행하였습니다.

아마 회사에 처음 들어가면 오전 티타임 아니면 점심 이후 데일리 미팅 시간에 팀원들 간 인사를 나누기 위해 한번 모이게 될 텐데요.

위의 gif처럼 잡아먹으려고 하지 않으니 다들 너무 걱정은 안 하셨으면 좋겠네요.

다 같이 모였을 때, 당찬 포부를 말하는 것도 좋겠지만 평범한 모습을 보여주는 게 저는 좋다고 생각합니다.

어차피 같은 회사 사람들은 가족 이외에 제일 많이 보게 될 테니 처음부터 색안경을 씌워주는 행위는 NO라고 생각되거든요~

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

모든 직장인들 화이팅 입니다.

내가 업무 할 때 소통하는 이야기

야심차게 준비하였습니다. 내 소 기 !!!

내가 업무 할 때 소통하는 방법들을 정리해놓은 이야기를 펼쳐보려고 합니다.

Episode 별로 상황에 따라 소통했던 방법들을 재미로 보는 시간을 가지려고 합니다.

왜 이 코너를 준비했냐면,

QA 업무는 꼼꼼함? 높은 집중력? 다 좋습니다.

그러나 저는 개인적으로 높게 평가하는 능력이 하나 있습니다.

제가 면접관 업무를 볼 때나, 신규 인력 교육할 때 파악이 되는 능력 중 하나입니다.

바로 커뮤니케이션 능력인데요.

거의 5년 가까이 QA 업무를 하면서 느낀 점은 효과적인 커뮤니케이션은 

내 부족한 능력치를 채워줄 수 있다고 느꼈습니다.

그래서 실무에서는 제가 어떻게 커뮤니케이션을 하며 

임기응변을 진행했는지 공유해보려고 합니다.

일단은 경험의 기록의 목적으로 쓰려고 했으나

재미적인 요소도 있어야 할 것 같고요 또 교육적인 목적도 있어야 할 것 같습니다.

그리고 QA 업무를 지망하는 취준생들에게도 많은 도움이 되었으면 좋겠네요.

 다음 에피소드로 만나요~~