[내소기]Episode_#07 : 모든 업무는 투명하게 기록한다.

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

 

오늘 제목은 솔직합니다.

 

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

 

투명하게 기록한다.

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

 

 

 

---

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

 

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

 

다음에 또 만나요~