문성준의 단단해지기

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주, 길게는 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 마무리하겠습니다.

다음에 만나요~

오늘은 QA 산출물 중에 하나인 프로젝트 중간 보고서에 대해 이야기해보려고 합니다.

프로젝트의 결과도 중요하지만

결과만큼이나 과정도 중요합니다.

늘 과정에서 배우고 결과로 증명하기 때문입니다.

프로젝트 중간 보고서는 말 그대로 프로젝트 중간에 보고서를 쓰지만

주간 보고서, 현황보고 등

프로젝트가 어떻게 진행되는지 공유가 필요한 시점에 작성합니다.

예를 들어보겠습니다.

11월 1일~ 11월 30일 1달간 진행되는 프로젝트가 있습니다.

언제 중간보고서를 작성해서 공유해줘야 할까요?

1. 매주 금요일 주간 보고서

11월 4일 / 11월 11일 / 11월 18일 / 11월 25일 

총 4번 작성되어집니다.

2. 프로젝트 중간 보고서

11월 18일 

프로젝트 중간에 1번 작성되어집니다.

4번 작성하느냐 1번 작성하느냐 차이지만 각자 회사의 환경 또는 프로세스에 따라 작성하는 것을 권장드립니다.

( 저는 주로 주간 보고서 형태로 작성합니다.)

중간 보고서 작성하기 #01 : 이 보고서를 꼭 봐주세요.

1. 수신, 참조자 파악하기 

저는 주로 [수신 : 실무 진행자], [참조 : 관리자, 내가 소속되어 있는 팀]으로 작성합니다. 

실무 진행자는 꼭 프로젝트의 현황을 알아야 하고, 숙지해야 합니다.

그래서 남은 일정 동안 프로젝트를 완성할 수 있을지에 대해 늘 생각해야 합니다.

만약, 본인이 맡은 업무 중 어떠한 요인으로 인해 수행하기 어렵다면 QA에게 공유가 되어야 합니다.

관리자 ( 각 팀 팀장), 내가 소속되어 있는 팀으로 참조를 포함시킨 이유는 각 팀의 팀장들 또한 현재 프로젝트 업무

상황을 확인하여 팀 운용에 참고를 할 것입니다. 또한 프로젝트에 참여하지 않더라도 중간보고를 받음으로써 프로

젝트 진행상황이 와전되는 것을 방지하기 위함입니다.

그리고, 팀원들에게 공유하는 이유는 제가 부재중이더라도 다른 인원이 대응할 수 있도록 공유를 해주고 있습니다.

중간 보고서 작성하기 #02 : QA팀은 이러한 환경에서 검증하고 있습니다.

1. QA가 어떤 환경에서 진행되고 있는지 공유합니다.

예를 들면 Test Device, Test App ver, OS ver 등 이 있겠죠?

2. QA 범위에 대해서 공유합니다.

신규 프로젝트일 경우 Front, Admin 둘 다 진행하겠지만 기존에 운영되고 있던 제품을 리뉴얼할 때는 일부 기능에 대해서는 검증 범위가 제외될 수 있으므로 범위에 대해 명확하게 적어줍니다.

3. 기획서 Histroy에 대해 공유합니다.

저는 주로 명세 기반 작성법으로 Testcase를 작성합니다. 

업무 프로세스상 [사업부 & 연구소 → 기획팀]으로 요구사항을 반영하여 기획서를 작성하기 때문에 기획서가 어떻게 변화했는지 중요합니다.

어떤 사람은 1.0ver 초기기획서를 보고 업무를 진행하고, 어떤사람은 1.5 ver의 최신 기획서를 보고 업무를 진행하는 불상사가 일어나는 것을 방지하기 위함입니다.
 

중간 보고서 작성하기 #03 : 본론입니다. 현재 상황을 숙지해주세요.

1. 한눈에 알아볼 수 있도록 진척률을 도식화하여 작성합니다.

기획서에 명시된 I.A ( Information Architecture )  기준으로 각 기능별 %에 대한 Progress bar를 작성합니다.

2. Test scope에 대한 CheckList를 작성합니다.

기능별 분류 값을 Depth 별로 구분을 합니다.

그리고 [확인] 칸에는 해당 기능(Depth)에 어떤 주요 기능이 확인되어야 하는지 기입합니다.

그리고 진행 여부에 [ 완료 / 진행 중 / 진행 예정 / X ] 항목을 만들어서 프로젝트 진행 현황을 공유합니다.

중간 보고서 작성하기 #04 : 결함 분석을 진행하겠습니다.

1. 진행된 Issue tracking or Bug tracking을 표와 차트를 이용하여 제공합니다.

현재 검출된 결함이 어느 정도이고, 수정률은 어느 정도인지 한눈에 파악할 수 있어야 합니다.

중간 보고를 통해 앞으로의 결함 도출 및 수정률을 예상하여 

예정된 일정을 앞 당길지, 아니면 연장할지 생각할 수 있습니다.

2. Critical 한 결함은 따로 기입을 진행합니다.

Critical 한 결함은 교과서라고 생각하시면 됩니다.

개발자는 추후 프로젝트 진행 시, Critical 결함이 왜 나왔는지에 대해 Feedback을 통해 재발을 막을 수 있습니다.

3. 기획 관련 이슈도 공유되어야 합니다.

이는 기획서 관리에도 도움이 될 뿐만 아니라 관련 정책을 재확인할 수 있는 기회입니다.

중간 보고서 작성하기 #05 : 특이사항입니다. 

1. 마지막으로 프로젝트 기간 도중 발생된 특이사항에 대해 모두 기록합니다.

저번에도 말씀드렸듯이 모든 업무는 투명하게 진행되어야 합니다.

숨기지 않아야 대처가 가능합니다. 

본인이 실수를 했다거나, 타인이 실수를 해서 지연되는 사항이 있더라고 하더라도 목표를 위해 다 기록되어야 합니다.

그것이 제가 말씀드렸던 " 늘 과정에서 배우고 결과로 증명한다 " 의 철칙입니다.



▼참고▼

2022.10.25 - [QA로 단단해지기/내가 업무 할 때 소통하는 이야기] - [내소기] Episode_#07 : 모든 업무는 투명하게 기록한다.

오늘은 QA 담당자로써 프로젝트 중간보고서는 어떻게 쓸까?

감이 안 오시는 분들에게 조금이나마 도움이 되고자

제가 작성하는 방법을 공유해봤습니다.

물론 각자 회사에서 사용하고 있는 보고서 양식이 있으시다면 사용하셔도 무방합니다.

저 같은 경우에는 QA 프로세스가 확립되어있지 않은 회사에서 

프로세스 구축을 진행하며 여러 양식으로 중간보고서를 작성해 보고 난 후

제일 깔끔하고, 전달력이 좋았던 방법이 위의 방법처럼 작성하는 것이었습니다.

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

다음에도 QA 산출물에 대해 작성해보도록 하겠습니다.

그럼 이만!

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

오늘은 처음으로 면접관이 돼서 면접에 참여한 이야기를 해볼까 합니다.

면접은 항상 긴장되고 떨립니다.

파트장으로 승진한지 1년도 되지 않은 어느 날이었습니다.

새롭게 인력을 충원해야 하고, 프로세스를 개편해야 하는 단계였죠.

매일매일이 바쁘고 어지러웠습니다.

그러던 어느 날 면접관의 부재로 제가 대신해서 1차 면접에 면접관 자격으로 참석하게 되었습니다.

물론, 지원자의 이력서만 잠깐 확인한 정도였습니다.

사실 제가 늘 했던 생각은

"내가 면접관이 되면 안 떨리겠지?"

라는 생각을 많이 했습니다.

그런데 웬걸 면접을 보는 지원자일 때와 별반 다를게 없이 긴장이 되었습니다.

첫 면접의 기억

그렇게 해서 면접관으로 첫 면접을 들어갔습니다.

지원자는 신입사원으로 지원을 하였습니다.

지금 생각해보면 지원자에게도 굉장히 죄송스럽습니다.

면접을 보기 위해 얼마나 많은 준비를 하고 긴장을 하는지 누구보다 더 잘 알기 때문입니다.

어찌 됐던 면접에 참석을 하였으니 최선을 다해야겠다고 생각했습니다.

제가 중점적으로 확인하고 싶었던 건 

QA 엔지니어로써 어떤 기술력을 가지고 있느냐 보다는

내가 속해있는 QA 팀이 나아가고자 하는 방향성과 부합한 인물인지 확인하는 것이었습니다.

신입사원으로 지원한 만큼 QA 이론보다는 업무를 빠르게 습득할 수 있고, 팀에 어울릴 수 있는 사람인지를 

확인해야 하기 때문에 커뮤니케이션 능력, 성격 위주로 질문을 구성해서 면접을 진행하였습니다.

현실의 벽에 부딪히다.

여러 번 면접관 업무를 진행하다 보니

현실의 벽에 부딪히는 경우가 많았습니다.

우리는 좋은 인력이 필요하지만, 내가 소속된 회사는 그렇게 좋지는 않았습니다.

어떻게 보면 "양두구육"(羊頭狗肉) 이였죠.

면접이 끝나갈 무렵 항상 지원자에게 회사에 대해 궁금한 점을 질문을 받습니다.

신입으로 지원한 지원자의 경우 

대부분 회사에 대한 기대감이 눈에 드러날 정도로 기대를 하는 모습을 많이 보았습니다.

저는 그러나 회사에 4년 가까이 몸담았기 때문에 사실 좋은 모습보다는 안 좋은 모습을 많이 알고 있습니다.

그렇기 때문에, 만약에 이 지원자를 채용한다고 했을 때, 지원자가 나중에 가지게 되는 실망감이 

저에게 돌아올 수도 있다고 생각을 하여 많은 고민에 잠을 설친 적이 하루 이틀이 아녔습니다.

현실의 벽을 부수다.

사실 위와 같은 고민은 쉽게 해결되었습니다.

나 자신이 "복지"가 되는 것이었는데요.

내가 성장해서 많은 것을 알려주고, 내가 분위기를 주도한다면 

회사까지는 아니겠지만 최대한 내가 속해있는 Team도 분위기가 변할 것이라고 생각하였습니다.

그렇기 때문에 나 스스로 성장을 해야겠다는 생각이 많이 들었고,

목표로 설정한 건 " 회사는 별로지만 팀원분들이 너무 좋다."

라는 소리가 나올 정도로 케어를 해줘야겠다는 생각도 들었습니다.

물론 늘 이직을 생각하고 있었지만, 왠지 모를 책임감이 생겨 인력을 충원할 때에는 이력서 사이트를 모두 OFF 시키기도 하였습니다.

아직도 많이 부족하지만 그래도 이때 다짐했던 목표를 지금까지는 잘 수행하고 있는 것 같습니다.

오늘은 처음 면접관의 자격으로 면접에 참석했을 때 기억을 되살려봤는데요.

면접관의 자격으로 한 20번 이상의 면접을 진행한 것 같습니다.

그런데도 아직 면접 일정이 잡히게 되면 

지원자일 때와 동일하게 잠을 설치고 소화도 잘 안되고 긴장이 되는건 마찬가지더라고요.

내가 지원자일때 면접관들은 피도 눈물도 없는 냉혈한인줄 알았지만

다 똑같은 사람입니다.

면접관들도 행여 실수를 하여 지원자의 마음에 상처를 주지 않을까

굉장히 고민을 많이 한다는 점.(물론 안 그런 사람도 있지만)

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

다음에 만나요~

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

오늘 제목은 솔직합니다.

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

투명하게 기록한다.

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

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

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

다음에 또 만나요~

두 번째 에피소드입니다.

오늘은 명세 기반 작성법으로 TestCase를 작성한 후에

TestCase를 보완하는 CheckList를 작성하는 이유와 방법에 대해 간단하게 포스팅해보겠습니다.

가기 전에 두 가지 Keypoint를 짚고 넘어가겠습니다.

입력 값에 대한 예상 출력 값을 정해놓고 그대로 결과를 나오는지 확인한다.

테스트 혹은 평가해야 할 항목을 정리하고 누락 없이 검증하는 것을 목적으로 한다.

얼핏 보면 같은 내용 아닌가요?

라고 생각할 수 있습니다만

포커스를 어디에 맞추느냐 생각해보면 달라질 수 있습니다.

첫 번째 키 포인트는 예상 출력 값에 포커스를 맞췄습니다.

즉, 기대 결과를 중심으로 작성한 TestCase입니다.

두 번째 키 포인트는 항목에 포커스를 맞췄습니다.

경험이나 TestCase를 보완할 테스트 항목에 대해 작성한 CheckList입니다.

각각 차이를 쉽게 볼 수 있도록 아래 표를 준비해 보았습니다.

공통된 목적을 가지고 있으나 미세하게 다른 차이가 있습니다.

물론 사람마다 다르겠지만 제가 업무를 할 때는 위의 표처럼 구분지어서 사용하고 있습니다.

간단하게 예를 들어보겠습니다.

여기 로그인 페이지에 대한 기획서가 있습니다.

Description 1번 로그인 항목에 대한 Test Case를 작성해 보겠습니다.

# 명세 기반의 TestCase 작성

명세서 기반으로 작성하였기 때문에 위의 TestCase 에는 Test Step 동작 후 로그인 처리 동작에만 포커스를 맞췄습니다.

물론 로그인이 동작하면 Pass 처리가 되겠지만

우리는 그동안의 업무 경험으로 인해 우리는 추가로 보완해야 할 항목이 무엇인지 알고 있습니다.

회원에 대해 분류를 해야 하는데요.

이는 어떠한 사이트를 가도 공통된 항목이 있을 것입니다.

대표적으로, 비밀번호가 만료된 계정 또는 일정 기간 동안 접속하지 않아 휴면 처리된 계정 등 

해당 사이트를 접속하는 여러 회원에 대해서 테스트가 누락될 수 있습니다.

그렇기 때문에 CheckList를 추가적으로 작성합니다.

# 업무 경험 기반으로 CheckList 추가 작성

이런 식으로 회원별 CheckList를 추가로 작성하는 겁니다.

그렇게 된다면 TestCase로 1차적으로 로그인 기능에 대해 확인을 하고,

2차적으로는 회원을 분류하여 회원 타입별로 로그인 기능이 정상 동작을 하는지 확인할 수 있습니다.

오늘은 "TC 다 썼는데 CheckList도 작성해야 돼요?"

라는 의문에 대한 답을 어떻게 내렸는지에 대해 다뤄봤는데요.

사람마다 생각하고 실무에 적용하는 것이 각자 다르겠지만

우리 QA 엔지니어의 목적은 하나입니다.

어떻게 품질을 상승시킬 수 있고, 효율적으로 문서들을 관리할 수 있는지에 대해 늘 고민해야 됩니다.

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

오늘은 제가 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에 활용하는지 간단하게 알아보았습니다.

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