QA != 통합테스트

안녕하세요. 우아한형제들 품질개선팀에서 근무하고 있는 임선진입니다.
저희 팀에서는 우아한형제들 서비스와 제품에 대한 QA, QC, Testing 업무를 주로하고 있습니다.
이 글은 어찌보면 모두가 알고 있는 QA(Quality Assurance Assistant)에 대한 이야기 입니다.

왜 이런 글을 쓰게 되었나?

이 글을 팀장님도 아닌 제가 써도 되나… 많이 망설였습니다.
너무나 거국적인 주제인데다, 이미 충분히 잘 알고 있어서 이해해주시는 분도 있는데, 굳이 쓸 필요가 있을까 싶은 생각도 들었습니다.
또한 다른 곳에서 같은 QA업무를 수행하며 현재는 고통받고 계시지만, 개선의 의지를 가진 분들이 …
“배민도 별거 없네.” 라고 생각하고 희망을 접어버리지 않을까 걱정도 했습니다.
그리고 괜한 오해가 생길 수도 있단 생각을 했지요.

하지만 불과 몇일 전 까지도 잘못된 이해로 많은 일들을 겪으면서 꼭 이 주제에 대해 써야 될 것 같다고 생각했습니다.

QA를 통합테스트와 동일시 여기는 상황들

저는 몇몇 분들이 QA를 통합테스트로 이해하고, QA의 일을 이해하지 못하는 상황을 접합니다.
프로젝트를 진행하거나 유관부서 분들을 만나 얘기를 할 때, 제 입장에서는 황당한 일들을 많이 겪습니다.
몇 가지 예를 들어보겠습니다.

상황1. (한 달도 넘게 진행된 프로젝트 내용을 미리 공유받지 못한 상황에서) “다음주 오픈 예정인데 일주일만 QA해주세요.”

“일주일 기능 테스트만이라도 해주세요.” 라고 하면 조금 덜 당황할 수 있습니다.
QA는 프로젝트 시작과 끝 전반에 걸쳐 품질을 저해할 수 있는 요소를 찾아내고 알리고 해결을 돕는 활동들을 의미합니다.
QA라고 말하는 것도 이상할 뿐 더러, 기능 테스트만 하더라도 몇일은 테스트 대상과 범위를 분석하는데 거의 모든 시간을 소모하게 됩니다.

(상황1 +) 상황2. “QA했는데 왜 운영 이슈가 계속 나와요? (QA한 거 맞나요?)”

1번에서 말한 상황이 황당하긴 하지만, 단 몇일 이라도 기능 테스트를 해서 사용자에게 더 나은 가치를 제공할 수 있다면 어쩔 수 없이 테스트를 시작합니다.
이 경우 버튼을 누르자마자 기능 동작을 하지 않는 등 엉망진창인 상태에서 올 때가 가끔 있습니다.
이 때, 저희는 의사결정을 할 수 있는 분께 프로젝트 일정을 더 늘려야한다, 개발 완료가 되지 않았다고 알립니다.
하지만 프로젝트를 처음부터 참여하지 않은 탓일까요? 얼마 만큼의 일정이 더 필요하고 얼마 만큼 구현이 덜 되었는지 근거가 부족할 때가 많습니다.
다행히도 무사히 프로젝트가 잘 진행되어 왔다면 그나마 안도하지만, 짧은 기간 안에 파악한 내용으로는 정말 어떻게 동작하는게 맞는 방향인지 알기 어려울 때가 많습니다.
국지적으로 확인만 하는 체커(checker)에 지나지 않을 수 밖에 없습니다.
(물론 처음부터 프로젝트를 같이 진행했더라도 이슈는 많을 수도 있습니다. 하지만 훨씬 가능성이 낮아질 겁니다 !)

[이게 어떻게 만들어지는게 맞는 거야? 일단 의자가 앞뒤로 움직이면 맞는건가?]

상황3. QA담당자가 프로젝트 킥오프 회의와 회고 회의들에서 누락되는 상황.

앞서 말했지만, QA는 테스트만 하는 활동이 아닙니다.
프로젝트의 목적과 목표에 어긋나지 않으면서도 소프트웨어와 기술을 바탕으로 사용자에게 최고의 품질(가치)을 제공하기 위해 노력하는 활동입니다.
그런 활동들 중 테스트라는 것이 있고, 그 동안은 테스트를 하는 활동에 집중 됐을 뿐입니다.
킥오프 회의에서 프로젝트의 목적과 목표를 듣지 못했다면, 적절한 활동을 하지 못할 것입니다.
회고 회의에서 이번 프로젝트가 어땠는지에 대해 듣지 못한다면, 다음 어떤 활동을 할지 발전이 없을 것입니다.

이것 외에도 … 크고 작은 황당한 일들은 시도때도 없이 힘을 빼놓습니다.

• QA가 기술적인 내용을 쓸게 있나요?
  • 우리는 기술적 지식을 바탕으로 활동합니다. appium, selenium, sitespeed.io(+yslow), postman-newman 등등 시도와 삽질과 적용의 반복을 합니다. 또한 끊임없이 공부합니다.
• (오픈해도 되는지 물어보며) QA팀은 맨날 그냥 불안해 하잖아요.
  • 과정이 클리어하고 잘 만들었으면 안 불안해 합니다. 뭔가를 물어봐도 답변이 불명확하고, 크고 작은 이슈가 오픈이 다가옴에도 어째서인지 줄어들지 않는 때가 있습니다.
• (품질개선팀-> ???? -> QA팀이라 소개하면) 아~ 테스트 팀!
  • ㅠㅠㅠ;;
• (테스트 대상이 아닌 것들에 대한 질문을 할 경우) 왜 QA가 그런 것 까지 챙겨요?
  • 테스터가 아니니까요. 프로젝트 함께 진행하는 구성원 중 아무도 신경을 못쓰고 있다면 누구라도 챙기는 게 맞다고 생각합니다.

[잠깐만 숨 한 번 고르고요]

왜 이런 상황을 겪게 되는걸까?

이런 일들을 이해는 합니다.

소프트웨어의 역사만큼이나 소프트웨어 품질의 역사는 길지 않다.

소프트웨어의 품질은 처음 제조업에서 말하는 품질관리에서 시작되어, 제조업의 품질관리를 소프트웨어에서 동일하게 적용하면 안 된다는 것을 알게 된지 얼마 되지 않았습니다.
아직도 이렇게 하는 게 맞는지 저렇게 하는게 맞는지, 고민하고 방향을 찾아가는 과정에 있다고 생각합니다.
심지어 업무를 진행하고 있는 사람들 조차도 본인의 일이 QA인지 테스트인지 인지하지 못하는 분들도 더러 있을 것입니다.

QA 업무를 하는 사람과 일해본 사람은 드물다.

지금의 조직에서도 프로그래머와 기획자의 수에 비해 QA로 일을 하는 분들은 정말 소수 입니다.
그리고 그 소수의 인원은 한정된 다른 부서의 분들과 함께 일을 합니다.
어느 정도 큰 조직이 아니면 별도의 QA조직을 두고 운영하기 힘들어서, 경력이 꽤 있더라도 함께 일해 본적이 없다고 합니다. (혹은 테스터 분들 하고만 일을 해봤다고 합니다.)

QA의 일은 계속해서 변화합니다.

소프트웨어의 플랫폼과 언어가 변화하듯 비지니스 구조가 변하듯, 우리는 더 많은 파라미터를 가지고 움직여야 합니다.
어떤 제품을 맡게 되느냐에 따라 계속해서 플랫폼과 로직에 대한 학습이 필요하고, 무언가를 시도하고 적용하는데 더 많은 노력이 듭니다.
또한, 현재는 주로 테스트를 직접 수행함으로써 고객에게 가치를 제공하지만 다른 형태가 될 수도 있습니다.
다른 조직에서는 또 다른 방법으로 QA 활동을 하는 분들도 있고, QA가 하는 활동을 명확히 정의하기 어렵기 때문에 잘 모를 수도 있다고 생각합니다.

우리는 앞으로도 더 많은 일을 해야하고 …

다시 한 번 더 말씀드리지만, QA는 통합테스트와 대치할 수 없는 단어입니다.
QA는 통합테스트만 하는 일을 의미하지 않습니다.

[출처 : https://www.slideshare.net/interfaceULG-innovationManagement/130528jodogneprofessionalsoftwaredevelopment-140113090851phpapp01]

품질(Quality) 관점에서 테스트는 극히 일부 밖으로 보이는 영역일 뿐, 우리는 더 많은 일들을 해야합니다.
사용자에게 어떻게 하면 극대의 가치를 전달할 수 있도록 잘 만들어질 수 있나 사용자의 입장에서, 기술 관점에서 모두 신경써야 합니다.

사실 저도 어떻게 하면 잘하는 것인지, 어떻게 하면 좋은 방법인지 잘 모르겠습니다.
하지만 계속해서 더 나은 방향을 생각해내고 최선을 다해 행동하는 것을 멈추면 안 되겠지요.

[현실과 부딪혀가며…]

계속해서 황당한 상황이 반복되고 앞으로 나갈 수 없는 많은 이유중 하나는 단어의 정의부터 잘못 인식하고 있기 때문이라는 생각이 들었고, 이렇게 기술블로그에 글을 쓰게 되었습니다.

여러분들이 생각하는 QA는 어떤 것이었나요?

덧붙임 …

덧1. 심심하면 나무위키 페이지. 보러가기

덧2. 품질개선팀의 채용은 열려있습니다. 우리 함께 일하며 성장해요. 입사지원서