Quality Assurance (QA: 품질보증)

신입으로 들어온 지 3주차, 회사에 본사의 다른 팀(QA)에서 우리 한국 지사가 어떻게 일하는지, 자신들이 어떻게 일하는지 소개하기 위해 3일간 회사를 방문했다. 엔지니어가 다수를 차지하고 있고, 모든 팀이 소프트웨어를 개발하는 만큼, QA팀은 Software Engineer의 생각이 궁금한 것 같았다. (문서화 작업과 QA팀의 도입에 대한 생각을 본사에서 하고 있는 것 같기도 하다)

간단한 QA에 대한 이해와 또한 엔지니어 입장에서 사용하고 있는 QA프로세스와 중요성 그리고 나의 이해와 의견 한 수푼을 넣고자 한다.

QA?

우선 QA는 어떤 일을 하는 것일까?

품질보증을 뜻하는 Quality Assurance의 약어.
국내에 화공 플랜트계에서 최초로 1980년대 도입되었다. 1980년대 전에는 QC(품질관리)였으며 현대에는 QM으로 품질경영 역사가 발전되고 있다. QA의 본질적인 어원은 과거 영국의 로이드에서 어원이 파생됐으며 현재도 LRQA(로이드인증원)이라는 조직으로 활동하고 있다. 품질관리(QC)와는 다르며 QC는 시야가 작은 범위을 검증한다면 QA는 보다 넓은 범위를 검증한다. 즉 리스크를 예방한다는 것.
-나무위키-

"리스크를 예방한다", QA팀의 담당자 분도 강조한 점이다. 엔지니어로서 놓칠 수 있는 부분들, 즉 Consumer의 Shoes에서 관점을 볼 수 있는 것.

그는 예시를 이렇게 들었다

만약 당신이 차를 판다고 생각해보세요. 당신은 차를 설계하고 판매 전략을 세울 때, 도시 주행용 차, 즉 시티카를 설계했어요. 만약 구매자(Consumer)가 같은 의도로 사서 주행을 한다면 다행이지만, 그가 오토반을 달린다면? 당신은 100km/h의 속도로 주행하도록 최적화 했지만, 구매자가 160km/h로 달린다면?

중요한 것은 구매자의 마음이다. 구매자(Consumer)는 어떠한 의도든 갖을 수 있고, 시티카여도 고속 주행을 위해 광활한 도로로 나갈 수 도 있다. 우린 시티카를 설계했으니까 너네가 잘못했어! 라는 전략이 잘먹힐 수 있을까?

즉, 리스크 관리를 통해 구매자(Consumer)가 갖을 수 있는 불편함을 예방하고, 방지하는 작업이 QA의 역할이다.

ISSUES

QA는 항상 0 Issue를 목표로 한다. 하루가 끝날 때 0 Issue! (하지만, 현실은 절대 그런 일은 없다고 하셧다 하하)
고객서비스팀(Customer Service team)에는 항상 수 많은 유저 이슈들이 들어온다. 이러한 이슈들은 QA팀에게 인수인계되고, 해당 내용을 검증 후 엔지니어에게 들어온다. 해당 내용이 Critical하거나 고객의 서비스 측면에서 강대하게 영향을 미친다면, priority를 고려하여 해당 이슈에 대한 티켓이 생성 될 것이다.

Software Engineering 관점에서의 QA

우선 강의를 해주신 분의 소속은 Mobile 쪽의 어플리케이션 팀이다. 메신저 앱을 개발하고 있는 팀의 QA를 공유해주셨다. 그가 가장 궁금한 것은, Software Engineer 분들이 QA대해 어떻게 생각하고, 어떻게 실질적으로 도입하고 있는지었다. 그들은 우선 자신의 팀이 기존 존재하던 레거시에 QA를 도입하는데 있어, 어떻게 진행하였는지 (기존 레거시들이 안드로이드에 맞추어져 있어, ios은 개발을 할 때, 기존 코드들의 개선점을 보고 작업하여, 안드로이드는 높은 QA 코드들을 이루었지만, ios는 최신 코드인것에 반해 QA가 적다는 것을 설명했다. 즉 애초에 stable 한 코드를 바탕으로 짯다는 뜻 이었던 것 같다), 어떤 수치를 목표로 하고있는지 (Backend 100%, Mobile 80%... Frontend는...?) 설명하였다. 가장 중요하게 강조한 부분은 Documentation 이었다. QA팀이 엔지니어로부터 제대로 된 Documentation을 받지 못한다면? 혹은 작업물들에 대한 목업이나 프로토타입이 Figma나 다양한 툴을 이용하여 상세하게 설명되있지 않다면? 그들이 판단 할 수 있는 것은 없다.

Unit Testing & E2E Testing

개발자들이 가장 접할만한 테스팅은 Unit Test와 E2E Test이다.

유닛 테스트(Unit Test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자(developer) 뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터(tester)에 의해 수행되기도 한다.
-위키백과-

유닛 테스트는 Functional 하다. 즉, 같은 Input에 대해 항상 같은 Output을 반환해야 한다는 것이다. 그 이상, 그 이하도 없다. 심플하다. 개발자가 짠 코드가 의도된대로 작동하는지, 부수효과는 없는지, 모듈로 잘 쪼개져 가독성이 있고 유지보수가 용이한지 보는 것 이다.

E2E Test(End to End Test)는 애플리케이션이 잘 돌아가는지, 개발자가 사용자 관점에서 보는 것이다. 특정 DOM들이 잘 동작하는지, 의도대로 흘러가는지 테스트하는 과정이다.

E2E 테스트는 여러가지의 Functional한 부분들이 애플케이션 내에서 잘 동작하는 지 볼 수 있다. 즉, 어플리케이션이 잘 돌아 가고 있다는 것을 테스트 할 수있다는 것 이다.

Frontend & Testings

취업 준비를 하며, QA와 테스팅을 요구사항으로 기술 해놓은 곳을 몇몇 볼 수 있어, 공부하며 적용해 본 경험을 바탕으로 신입이지만? 개인적인 견해를 써본다.

 

우선 나는 Jest와 React Testing Library 등을 사용 해 보았다. 결론부터 말하자면, 혼자서 진행한 프로젝트에서 테스팅 툴을 도입하여 각 모듈을 체킹하고, e2e 테스트로 DOM이 올바르게 작동하는지 확인하는 작업은, 순수 extra cost 였다. 팀의 규모가 작을 수록, 프로젝트의 규모가 작을 수록, 테스팅에 대한 관점은 회의적일 수 밖에 없다는 것은 당연한 것 같다.

 

또한, Frontend의 UI를 테스팅하는 과정은 생각보다 쓸모없게 느껴진다. Extra cost가 정말 2배수가 되는 느낌이 들기도 한다. 애초에 Frontend Engineer는 실시간으로 Web Browswer에 페이지를 띄우며 테스트 과정을 거친다. 사실 디버깅을 잘하는 프론트엔드 개발자보다, 테스팅을 잘하는 프론트엔드 개발자가 많지 않을까? 할 정도로, 직접적인 테스트를 이룬다. 이러한 과정을 겪는 프론트엔드 개발자의 관점에선, 테스팅은 그저 코드 작성 노동이 아닐까?

 

클라이언트 사이드에서의 기술들이 나날이 발전하고, 하드웨어적인 사양들도 빠르게 발전하고 있으며 (모던 브라우저를 사용하지 않는 한국인들이 과연 얼마나 될까?)이에 따른 페이지의 동작 방식이 굉장히 복잡해지고 있다. 단순히 HTML을 띄우던 옛과는 다르게, 이제는 동작을 위한 Javascript와 수많은 서드파티들이 붙어있다. 이러한 과정속에서 E2E 테스팅을 할 때, 오히려 오류를 야기할 수 있다. Network의 고도화, module의 Authentication, 서버와 DB의 종속, 비동기적인 통신, 디바이스와의 동기화 등 수 많은 요소들이 들어간 페이지는 더 이상 혼자서 테스트하기 좋은 환경이 아니다. 어느정도의 규모있는 회사라면, 실 서버와 테스팅 서버를 독립적으로 갖고 있기 때문에, 테스트 서버에 모든 부분들이 올라가 테스트 과정을 거치는 것이 사실 가장 쉽고 빠른 것이 아닐까? 정말 UI 테스팅이 의미가 있을까?

 

이런 생각과 함께, Unit Test에 대해서는 호의적인 생각이 들었다. 프론트엔드의 추세는 함수형 프로그래밍이다. 컴포넌트와 모듈들은 모두 Funtional하게 동작하고자 하고, 추구한다. 이러한 모듈과 컴포넌트들을 잘 분리하여, Unit Test로 작성하는 것은 코드의 안정성을 보장해준다. 다수의 개발자가 같은 코드를 볼때 더욱 빛날 것이다.

 

회사의 슬랙 채널 중 자유롭게 생각을 공유하는 곳에서, 이와 같은 주제로 토의를 하는 것을 볼 수 있었다 (Frontend 개발자의 관점). 어느 7년차 개발자(외국)는 7년간 한번도 테스트코드를 작성하지 않다가, 현 회사를 들어와 작성해보았다고도 했고 이에 대해 긍정적인 반응을 보이기도 했다. 어느 한 개발자는 DOM 테스팅은 정말 부질없다, 시간 낭비다, 어차피 하는 것이다 라는 생각을 비추기도 하였다.

 

내 의견도 후자에 가깝긴하다. 아직까지 테스팅의 중요성을 느낀적이 없다. 하지만 하나는 확실하다. 팀의 크기와 프로젝트의 볼륨에 따라 테스팅의 도입은 아주 좋은 QA를 제공 할 수 있다는 것. 개발 년차가 올라가며, 다양한 프로젝트를 접하면서 이 프로세스가 정론이 될지, 트렌드가 될지, deprecate 되어 잊혀질지, 추 후 몇년이 지난 포스트를 돌아보며 다시 적어보고싶다.