QA했는데 왜 버그가 있어요?

이 말은 초기에 QA업무를 하면서 듣던 말인데 

그 때는 이 말이 정말 스트레스였죠.

 

"나는 버그를 잡는 사람인데 내가 못찾은 버그가 나왔어. "

"이건 너무 특수한 케이스인데 이런걸 어떻게 놓치지 않을 수 있는거지?"

 

사실 저 때는 나에게 누군가 와서 저렇게 말했을 때 대답을 할 수 없었습니다.

마치 모든것이 나의 잘못인것만 같았거든요

QA란 직업에 대한 이해가 부족했죠.

 

하지만 지금은 어느정도 판단이 가능해졌습니다. 조금은 QA란 직업을 이해하고 있다고 할 수 있겠죠.

지금 저 위에 제목처럼 저에게 묻는다면 이렇게 대답할 것 같네요.

 

"QA팀에 주어진 인적, 시간적 리소스가 충분했는가?"

  - 오픈일은 고정인데 개발이 늦어지면서 QA시간이 줄지는 않았나요?

 

"QA가 모든 버그를 찾아낸다는 것은 당연히 불가능하다. 이것을 이해하고 있는가?"

  - 이건 아주 중요한 이야기 입니다.

    QA팀은 규모가 작을 경우 제품당 1명이 진행할 수도 있고, 많아도 평균적으로 30명을 넘지 않는 곳이 많을겁니다.

    물론 결함을 발견하기 위한 전문적인 업무는 하지만 제품을 이용하는 수백, 수천, 수만의 유저들의 다양한 행동

    패턴들을 모두 확인할 수는 없습니다.

    이런곳에서 발생하는 이슈들은 자연스럽게 나올 수 밖에 없는 이슈로 취급하는 것이 맞습니다.

 

"사전에 해당 QA에 대한 리스크를 공유하지 않았는가?"

  - 해당 테스트를 하기 위해서는 8h가 필요한데 현재 4h밖에 진행할 수 없으니
    미 발견 잔존 이슈들이 포함된 채 서비스 될 수 있습니다.

  - 반드시 수정되어야 할 이슈들이 있는데 시간이 없다고 수정하지 않고 나간다면
    서비스 오픈 이후 추가이슈가 발생할 수 있습니다.

  - BVT조차 진행할 수 없는 짧은 시간밖에 남지 않았다면 이건 아예 QA를 진행하지 못하고 나가는것입니다
    (리스크가 어떤것인지를 판단할 수 없다는 것 자체가 리스크)

 

물론 QA팀의 실수가 있을 수도 있습니다.

충분한 리소스가 있었음에도 불구하고 Test Plan을 충분히 고려하지 않아서 테스트가 누락되는 부분이 생긴가던지, 

팀 내 커뮤니케이션 미스로 테스트 진행을 잘못하는 등의 문제가 생길 수 있습니다. 

 

물론 회사는 업무에 대한 댓가를 받고 일을 하는 곳이기 때문에 실수는 없어야 하겠지만

사람인 이상 실수는 발생하겠죠.

그래도 이런 실수에 대한 회고만 잘 이루어지고 재발방지를 위해 노력한다면 저는 이런것들이 쌓여 QA팀을 더 단단하게 만들어줄 것이라고 보기 때문에 실수를 한다고 해서 누구를 질책하거나 추궁하는 문화는 좋지 않다고 봅니다. 

 

다행히도 예전에는 저런 분들이 많았지만 최근에 들어서는 많이 보지 못했습니다. 만약 서비스 중인 제품에서 문제가 발생한다면 모두가 생각하는 우선순위가 바뀐 것 같은 느낌입니다.

 

과거	현재
1. 오류 원인 찾기 (QA팀)	1. 오류 원인 찾기 (QA팀)
2. 오류 해결 방법 찾기 (SE팀&기획팀)	2. 오류 해결 방법 찾기 (SE팀&기획팀)
2-1 책임자 추궁 (꼭 바쁠때와서 뭐라고 하는 사람 있다...)	3. 빠른 수정 후 테스트 (SE팀&기획팀&QA팀)
3. 수정 후 테스트 (SE팀&기획팀&QA팀)	4. 업데이트 (SE팀)
4. 업데이트 (SE팀)

※위의 표는 제 경험의 이야기 입니다. 실제와는 상이할 수 있습니다.

 

이후에는 팀 내부적으로 원인 분석과 재발방지 대책을 체크하고 팀 내에 공유하는 건강한 문화가 진행이 됩니다. 

다만 매니저라면 해당 이슈가 왜 발생했는지 체크는 해야할 것 입니다.

하지만 이것이 추궁하듯이 진행되면 좋지 않다고 생각합니다.

감정은 배제하고 논리적으로 대화하고 위의 예시처럼 리스크가 있는 상황이라면 이것은 발생할 수 밖에 없었던 상황이 됩니다. 이럴경우 전체 팀에 공유를 해야겠죠. (우리가 말한 리스크가 표면으로 드러난 상황이니)

그게 아니라 팀원의 실수가 맞다면 팀원은 스스로 실수를 인정하고 재발방지를 위해 노력하면 됩니다. 

누구를 추궁해야 할 필요도, 질책을 할 필요도 없는 것이죠.

 

제가 생각하는 QA란 

 

"주어진 리소스를 가지고 가장 효율적으로 효과적인 방법을 사용하여 제품의 안정성과 완성도를 확보하는 일"

 

이라고 생각합니다.

 

QA는 모든 버그를 찾을 수 없고 완벽한 사람이 아니므로 QA를 마치더라도 이슈는 나올 수 있습니다. 

중요한건 이 이슈가 왜 나왔냐에 집중하기 보다,

이것을 해결하기 위한 가장 빠르고 안전한 방법이 무엇인지에 집중하고, 이것을 재발하지 않도록 노력하는 것입니다. 

 

회사내에 모든 사람들이 이러한 내용을 이해하고 동의한다면, 그 곳의 제품 안정성은 점점 더 좋아질거라고 생각합니다.