그림 출처: https://www.mindfulqa.com/analyst-vs-engineer/

들어가는 글

현재와 미래의 SQA의 역활에 대해서 제가 고민하던 것들을 정리해보려고 합니다.
아무래도 제 주관대로 정리를 할 것이라서 정답이 아닌 내용이 있을 수 있으니 제 글을 읽어주시는 분이 잘 판단하셔서 읽어 주세요.
(정보가 부족한 시대가 아니고 너무 많은 정보가 있지만 잘못된 정보가 많기 때문에 주관을 가지고 판단하셔야 합니다. 유명한 분의 글이라고 항상 정답은 아니더라고요.저는 유명한 사람도 아닙니다.)

이 글을 시작하게 된 이유는 여러 가지가 있습니다. 하지만, 가장 결정적인 것은 페이스북에 어떤 유명한 분이 올려주신 [QA 담당자 채용 공고]였습니다. 그 글의 일부만 가져오면 다음과 같습니다.

지원방법: 위 자격 요건에 본인이 얼마나 잘 맞는지, 주요 업무와 추가 업무를 얼마나 잘 해낼 수 있는지 상세히 글로 적어서 자기소개서 및 이력서와 함께 다음 주소로 메일 보내주세요.

사실 저는 평소에 구인광고를 틈날 때마다 관심을 가지고 읽어보는 습관을 가지고 있습니다. 이유는 SQA에게 현재 기업에서 요구하는 능력이 무엇인지 알고 싶어서입니다.

그런데 이 기업의 "지원방법"이 본인이 얼마나 잘 맞는지, 주요 업무와 추가 업무를 얼마나 잘해낼 수 있는지 상세히 글로 적어서 제출하라는 것이 저에게는 하나의 화두가 되더군요. 저는 이 글이 저에게는 이렇게 들렸습니다.

"해당 회사에서는 어떻게 Software QA 활동을 해야 할까요? 계획서를 제출하세요!"

"앗! 블로그에 글을 쓸 주제를 찾았어! 현재까지의 SQA의 역활과 앞으로 미래의 SQA역활에 대해서 정리해봐야지" 해서 이 글을 쓰기 시작 했습니다.

폭포수 모델에서의 SQA

(그림 출처: https://www.javatpoint.com/jira-waterfall-model)

폭포수 모델에서는 Software QA는 Quality Gateway Keeper의 역활로 생각하는 경우가 많습니다.

Quality Gateway Keeper로 이야기 하는 이유는 개발 완료가 된 소프트웨어가 배포(릴리즈)되기 전에 테스트를 수행하여서 소프트웨어가 고객에게 전달이 가능한 완성도인지를 확인하는 역활을 수행하기 때문입니다. 이런 환경에서는 소프트웨어가 릴리즈 되었을 때 이슈가 발생하면 가장 많이 책임을 묻게 되는 담당자가 QA가 됩니다.

폭포수 모델에서 Testing 단계에서만 Sofware QA의 역활이 있지는 않습니다.이를 가장 잘 정리한 것이 아래 그림인 V 모델(V-model)입니다.

Software QA가 폭포수 모델에서 하는 역활을 정리한 것입니다.

제 경험과 지식을 기반으로 정리하면 다음과 같은 활동들을 합니다.

• 개발 초기에 테스트 목표를 정의 및 개발 전체 관련자(Product Owner, 기획자, 고객, 개발자등)과 협의합니다.
• 테스트 목표가 수립된 것을 기반으로 테스트 환경을 준비/구축합니다.
• 합의된 테스트 목표를 기반으로 테스트 시나리오(사용자 시나리오 기반)를 작성합니다. 저는 이것은 Acceptance Test에 해당하는 레벨에서 작성이 되어야 한다고 생각합니다.
• System test를 준비하고 수행합니다. 이는 실제 사용자가 아니고 테스트를 담당하는 전문 인력이 담당합니다. QA+Tester의 조합이 수행하는 경우라고 생각하면 될 것 같습니다.
• Integration Test와 Unit Test는 개발자가 수행하는 경우가 대부분입니다. 저는 관련된 산출물을 리뷰하고 피드백을 하면서 전체 개발프로세스를 준수하도록 하는 PMO의 역활을 일부 수행했었습니다.
• 준비된 테스트 환경에서 테스트 케이스를 수행하고 그 결과를 피드백합니다.
• 발견된 이슈가 수정이 정상적으로 되었는지 확인합니다.
• 이슈 수정이 Side-effect가 되어서 다른 이슈가 발생이 되지 않는 것을 확인합니다.

Agile 그리고 Scrum 상의 QA

Agile Process (그림 출처: https://www.javatpoint.com/jira-agile)

Scrum/Sprint Process (그림 출처: https://www.javatpoint.com/jira-scrum)

제가 주로 경험한 Agile 개발 방법은 Scrum입니다. 도구로는 Jira의 KANBAN 보드를 활용했었습니다.(화이트보드에 포스트잇을 붙이는 KANBAN을 한 적도 있습니다.) Agile에 대해서 제가 설명하는 것은 주제에서 벗어나기 때문에 다른 분의 좋은 글이나 도서들을 읽어주십시오.
저는 Agile을 아신다는 가정하에서 QA의 역활에 대해서 적어보겠습니다.

Scrum에서는 매 Sprint에 고객에게 전달이 가능한 릴리즈를 만드는 것을 목표로 합니다. MVP(Minimum Viable Poduct)를 만들어 나가는 것이죠. 폭포수 모델에서는 개발이 완료되고 테스트를 수행하고 릴리즈를 했었습니다.그렇다면 Scrum에서는 QA는 언제 어떤 활동을 해야 할까요? 제가 일했던 내용과 추구했던 일의 방식에 대해서 적어보겠습니다.(다시 말씀드리지만 이것이 정답은 아닙니다.)

Scrum에서 3가지 중요한 요소가 있습니다. Prduct Backlog, Sprint Backlog, Burndown chart입니다.

Artificts of Scrum(그림 출처: https://www.javatpoint.com/jira-scrum)

1. QA는 고객에 전달되는 기준을 정하는 사람입니다.

Product Owner가 있다면 Product Backlog에 항목을 추가하고 어떤 항목을 Sprint Backlog에 먼저 할당 할지를 정해 주실 것입니다. 물론 개발자, 기획자 등과 협의를 먼저 한 다음입니다. QA는 해당 항목들의 릴리즈 기준을 먼저 제시하셔야 합니다. 일반적으로 기획자와 개발자 분들은 각자의 입장에서 자신의 언어로 업무 협의를 합니다. 각자의 언어로 이야기를 하다 보면 명확히 달성해야 하는 목표가 없이 기획되고 개발이 완료되고 고객에게 전달하게 됩니다. 이러면 고객은 자신이 원하지 않았던 제품이라고 불만족하게 되는 경우가 많아집니다.

• User Story를 작성할 때에부터 고객에게 전달되는 기준을 고민하고 기획자와 개발자 사이에서 협의를 이끌어 내야 합니다.
• Epic, Task, Sub-Task를 작성할 때에 개발자 분들이 놓치시는 예외케이스를 찾아서 개발 이전에 해당 사항들이 설계에 반영이 되도록 협업해야 합니다.
• 고객이 요구하는 요구사항 뿐만 아니라 비기능적 요구사항을 먼저 제안을 하도록 노력해야 합니다. 예를 들면 시스템의 성능에 대해서 먼저 대략적인 수치라도 협의를 이끌어 내고 시스템 설계가 시작되기 전에 반영이 되도록 해야 합니다. 동시 사용자수, 시스템의 확장 가능성등에 대한 고민을 같이 하도록 먼저 제안을 하면 좋습니다.
• 개발자가 티켓에 대한 개발을 완료하면 개발 내용에 대한 검증을 수행하고 고객에게 전달할 빌드에 해당 티켓이 포함이 되어도 되는지를 판단합니다.
• Sprint는 Shippable Product를 만드는 것을 목표로 합니다. 회사마다 다른 Git Work Flow를 가지고 가겠지만 Release branch에 Merge하는 것은 QA의 검증 Task가 종료되거나 최소한 동료 개발자의 Review등이 이뤄진 Feature들만 Merge를 합니다.

2. 고객의 소프트웨어 품질을 위한 고민을 하고 방법을 찾는 사람입니다.

사업, 기획자 분들이 이런 문제에 대해서 가장 먼저 고민하시는 분들입니다. 하지만 기술적인 접근이 아니고 고객의 입장에서 접근하시는 분들입니다.
개발 조직에서도 개발 품질을 높이고 싶어하시고 다양한 도구를 도입하시거나 익스트림 프로그래밍 등의 다양한 개발 방법을 도입하십니다. 하지만 각자의 위치에서 접근을 하시기 때문에 노력하시는 것에 비해서 얻어지는 성과가 적은 경우가 많습니다.

소프트웨어의 고객이 누구냐에 따라서 매우 다른 접근이 필요합니다. 예를 들어서 항공, 국방, 자동차 등 안전과 직결되어 있어서 실패는 비용 뿐만 아니라 생명이 달린 것이라면 매우 타이트한 품질을 위한 기준(ASPICE, DO-178C 등)을 준수한 개발을 해야만 합니다. 품질이 절대 명제인 소프트웨어가 아니고 경쟁자가 많은 소프트웨어를 만드신다면 적절한 시간에 고객에게 전달하는 것(Time to market)이 중요하기 때문에 소프트웨어의 개발을 너무 충실하게만 할 수 없는 것이 현실입니다.

일반적인 경우에는 QA는 고객, 사업, 기획자와 개발조직간의 사이에서 현실에서 해야만 할 사항과 할수 있는 것, 하면 좋은 것을 구분해 내야 합니다. 이를 구분하고 관련된 모든 사람에게 해당 내용을 전달하고 자신이 할수 있는 최선을 다합니다. 고객을 위해서! 내가 같이 만드는 소프트웨어를 위해서! 어떤 일이던지 혼자서 모든 일을 할 수는 없습니다. 같이 일하는 사람이 같이 성장해야지 좋은 결과를 얻을 가능성이 높아집니다.

좋은 소프트웨어 품질을 가지기 위해서 하는 활동들을 일부 적어 보면 다음과 같습니다. 상황에 맞게 반드시 해야 할 활동을 찾고 그 활동을 자신이 개발하는 소프트웨어에 맞게 적용해 나가는 활동은 QA가 혼자만 할수 있는 일들이 아닙니다. 개발자, 기획자, 디자이너 등 모든 소프트웨어 개발을 위해서 함께 하는 분들이 같이 해주셔야 합니다. 또 제가 미처 적지 못한 좋은 방법들도 많을 것입니다.

• 코드리뷰 프로세스
• 정적분석 도구 도입
• 테스트 자동화 도구 도입
• 부하 테스트(성능 테스트, 신뢰성 테스트, 스트레스 테스트)

QA는 소프트웨어의 품질을 책임지는 사람입니다. QA가 모든 일을 다해서 책임을 져야 한다는 말이 아닙니다. 개발자와 같이! 기획자와 같이! 디자이너와 같이! 사업과 같이! 다 같이 성장하고 다같이 고민해야 한다고 생각합니다. 이를 같이 하고 싶은 강력한 목표 의식을 가지고 있는 사람이 QA입니다.

해야만 할 것, 해야 할 것, 하면 좋은 것, 하지 않을 것을 구분하는 방법으로 대표적인 리스크 기반 테스팅이 있습니다. QA가 할 일뿐만 아니라 소프트웨어를 같이 만드는 모든 사람이 각자 해야 할 일을 이런 기준에서 같이 정하고 주어진 환경에서 최선을 다해야 하지 않을까요?

클라우드 환경에서의 QA

클라우드 환경으로 많은 서비스들이 이동하게 되어가는 현실에서 저는 QA는 Devops의 역활도 일부는 같이 해야 한다고 생각합니다.

On-Premise환경 + Monolithic Architecture에서는 QA는 Gateway Keeper의 역활을 담당하는 것도 나쁜 선택이 아니라고 개인적으로 생각합니다.

하지만 현재에 많은 서비스가 Cloud + Microservices Architecture으로 이동하는 과정에서는 QA는 Devops의 역량을 같이 가져야만 실제 서비스가 고객에게 전달/오픈 되어서 운영되는 과정에서 발생할 다양한 문제들에 대한 고민을 사전에 해보고 테스트를 할수 있을 것입니다.

SRE(Site Reliability Engineering)의 역활을 이야기 하는 것이 아니냐는 질문을 하실 분이 분명히 있으실 것입니다. 저는 중복을 제거하는 것이 아니고 고객에게 최선의 제품/서비스를 제공하기 위한 역량을 이야기하는 것입니다. "내 영역인데 침범하지 말아라!" 혹은 "중복으로 왜 그런 일을 해야만 하느냐? 낭비할 필요가 있어?"라는 다양한 이야기가 나올 수 있는 것도 압니다. 그렇지만 품질만 생각한다면 각자 독립적으로 일을 할 수 있어야 하고 서로의 영역에 대해서 어느정도 알고 있어야 서로 협업을 원활하게 할 수 있지 않을까요?

또한 Cloud + MSA 환경에서 테스트 환경을 구축하고 다양한 테스트(기능 테스트, 성능 테스트 등)을 진행하려면 Devops의 역량을 QA도 갖춰야 한다고 생각합니다.

마무리하는 글

술자리에서 이런 저런 이야기를 하시다가 저에게 "Software QA를 어떻게 하는 것이 좋은 소프트웨어를 만들수 있을까?"라는 질문을 하시는 분이 꽤 있었습니다. 제 대답은 항상 "케바케(Case by Case)"였습니다. 그러면 상대방은 항상 에이 너무 불성실한 답이라고 저를 타박하셨었죠. 사실 어떻게 이야기를 풀어서 해야 할지 모르겠는 질문이였기 때문입니다.

그것을 그나마 쉽게 설명드릴 수 있는 좋은 글을 몇 일 전에 지인 분의 페이스북에서 봤고 글을 작성하신 분의 허락을 구하고 여기에 가져왔습니다.

시작은 사람이고 끝도 사람입니다.

다양한 사람이 구성하고 있는 회사입니다. 어떤 도구, 어떤 방법론이 은탄환과 같이 한 방에 모든 문제를 해결할 수는 없다고 생각합니다. 구성원들이 같이 노력하고 도전하고 부족한 점은 서로 도와가며 서로의 장점을 배워야지 좋은 소프트웨어를 만들 수 있지 않을까요?

QA(Quality Assurance)는 품질을 보증합니다. 하지만 혼자가 아니고 같이 보증합니다. 누가 이미 거쳐간 길이라면 기존의 경험과 기록을 기반해서 길을 걸어가면 되겠지요. 하지만 아무도 걸어가보지 않은 길이라면 그 길을 걸어가는 방법에 대해서 고민해본 사람의 이야기를 듣고 같이 걸어가는 것이 좋지 않을까요? QA는 제품의 품질을 위한 고민을 하고 자신의 지식과 경험을 같이 나눕니다.

QA는 판사(Quality Gateway Keeper)가 아닙니다. QA는 개발자와 기획자를 괴롭히는 사람이 아닙니다. 자신이 같이 만들어나가는 소프트웨어가 고객에게 전달되었을 때에 고객이 만족하기를 바라는 사람입니다. 각자의 위치에서 최선을 다하고 계신 분들에게 짐을 더 얹어 드리는 사람이 아닙니다. 같이 손을 잡고 걸어가는 동료입니다.

최근에 Quality Coach라는 용어도 쓰이고 있습니다. Quality를 위한 다양한 활동을 하도록 도와드리는 사람! QA가 열심히 한다고 해서 좋은 소프트웨어를 못 만들테니 구성원들이 조금 더 Quality를 다시 생각하고 관련된 변화를 이끌어 낼수 있도록 하는 역활을 표현하는 단어라고 생각합니다. 그런데 저는 Coach라는 단어보다는 같이 이야기하고 나누는 동료를 표현하는 단어가 있었으면 하는데... 그건 제 욕심일까요?