우리 회사에서의 QA와 테스팅은 어떤 모습이어야 하는지를 고민하면서, 도대체 다른 회사는 어떻게 테스팅을 하고 있을까에 대한 조사를 하면 도움일 될 것 같았다. 그래서 Google, Facebook, Atlassian의 사례를 찾아 간략하게 정리해본다.
1. Google
구글은 소프트웨어를 어떻게 테스팅하는가 책의 서문과 1장에 해당하는 내용 중 일부를 정리한 내용이다.
Google의 Tester
구글의 고참 디렉터이며, 테스팅 계엘의 최상급자인 Patric Copeland는 책의 서문에서 이렇게 말하고 있다.
구글은 전산학과 코딩 기술을 존중한다. 테스터가 그 클럽에 동참하려면 훌륭한 전산지식과 절묘한 코딩 기술을 갖추어야 한다.
우리나라에서 테스터로 업무를 시작한 사람들에게 패트릭이 말한 훌륭한 전산 지식과 절묘한 코딩지식을 갖추라는 조언은 숙응은 되지만, 쉽게 그 목적을 달성해내기는 쉽지 않다. 대부분의 테스팅의 업무란, 사용자에게 최상의 경험을 주기위해, 앞서 경험을 해주는 대리자의 입장이 많았기 때문인 것 같다. 경험을 미리 해주는 테스터에게는 엄청난 전산 지식도, 절묘한 코딩 스킬이 필요한 것은 아니기 때문이다.
패트릭이 주는 첫 번째 조언은 “테스터의 수를 많이 두지 말라“는 것이다. 래리 페이지(Larry Page)도 “부족함이 명석함을 만든다”고 하였다. 아웃소싱 리소스 투입을 통해서 대체 경험자의 투입의 수를 늘려, 배포 전에 이슈를 최대한 많이 잡아내려는 시도는 어쩌면 명석하지 않은 솔루션일지도 모르겠다.
구글에서 테스터의 일은 다른 엔지니어들이 하지 않는 더 좋은 테스트를 하는 사람이다. 테스터의 실제 업무는 생산성을 향상 시키는 일이고, 느슨한 개발로 인한 재작업이 늘어나는 것을 예방하는 활동이다. 구글에서는 개발자가 자신의 품질을 스스로 책임을 지기때문에 적은 수의 전문 테스터 만으로도 테스팅을 해낼 수 있다고 한다. 품질 활동의 초점은 결함을 찾는 것보다는 예방에 맞추어져 있다
지금은 구글에 있지 않지만, 이 책의 저자 중 한 명인 제임스 휘태커(James Whittaker)는 이렇게 언급하고 있다.
품질과 테스트가 동치는 아니다. 하지만 품질을 이루기 위해서는 개발과 테스팅을 믹서기에 함께 넣고 구분되지 않을 정도로 섞어야 한다.
QA부서나 테스팅부서가 따로 있는 것이 주는 가장 큰 맹점이자 악효과가 바로 이것이라고 생각된다. 개발자는 개발을, 테스터는 테스트를 하는 것으로 분리하는 순간에 많은 문제가 발생힌다. 간단한 테스트로 수정하고 고쳐질 수 있는 부분이, 여런 단계와 컴포넌트 및 시스템의 통합을 거쳐 테스터가 설정한 테스트 케이스를 실행하는 순간에 발생되고 이로 인한 재작업의 비용과 시간의 손실은 너무나도 크다.
개발자가 품질을 책임진다는 말, 개발과 테스트를 분리하지 말아야한다는 말은 QA와 테스팅을 업무로 삼고 있는 입장에서는 job security와도 연관되어있는 무서운 말일 수도 있다. 하지만 배포가 임박하여 수없이 쏟아지는 버그를 정신없이 리포팅하는 것이 테스팅을 잘 하고 있음을 보여주는 것은 절대 아닌 것 같다.
Software Engineer(SWE), Software Engineer in Test(SET), Test Engineer(TE)
구글은 SWE, SET, TE로 역할이 구분되어 있다. 간략히 살펴보면 다음과 같다.
- SWE는 개발자이다. fault-tolerant 설계, TDD, unit 테스트를 수행한다.
- SET는 Testability 및 범용 테스트 인프라에 중점을 두며, 테스트 기능을 개발하는 개발자이다. 각 기능의 품질에 초점을 두고 개발자의 테스트를 돕는다. 모든 단계에서 테스트를 가능케 하는 사람들로 100% 코딩을 하는 역할이며, 기능 코드 작성을 하는 훌륭한 테스터이다.
- TE는 반은 사용자 입장, 반은 개발자 입장에서 테스트한다. 엔지니어이며, 사용자인 개발자이다. 개발자가 존중하는 기술과 개발자가 알아야하는 사용자 측면의 관심영역을 조합한 직책이다. 제품전문가, 품질 조언자, 리스크 분석가이다.
조직 구조
조직 측면에서 보면 ‘생산성혁신팀’의 이름으로 독립되어 있지만, 전략적으로 테스터는 상품화팀에 배치(할당)된다. 한 제품에 대해 테스터는 약 18개월 정도 일하며, 원하면 아무 문제 없이 다른 팀으로 옮길 수 있다. 이렇게 독립 중앙 조직으로 할당되는 방식을 통해 좋은 아이디어와 모범 사례들이 퍼져나가게 한다.
테스트 유형
구글에서는 흔히 구분하는 코드 테스트, 통합 테스트, 시스템 테스트로 구분하는 대신 범위를 강조하는 방식으로 테스트 유형을 구분한다.
| 소형 테스트 |
중형 테스트 |
대형(초대형) 테스트 |
 |
 |
 |
소형 테스트는 코드가 제대로 잘동하는지 확인한다. SWE에 의해 대부분 테스트는 자동화 된다.깨끗한 코드, 잘 정의된 인터페이스가 필요하다. 에러간 독립성을 보장하면서 테스트가 가능하다.하지만 서브시스템을 mock으로 만들기가 어려우며, mock/fake가 실제와 다를 수 있다는 단점은 있다.
중형 테스트는 이웃하는 기능(2-3개 정도의 인터렉션이 발생하는)이 제대로 기능하는지를 확인한다. 대형 테스트에 비해 자주/쉽게 수행가능하지만, 외부의존성으로 비결정적일 수 있다. 주로 외부 시스템의 행동을 설명한다.
대형 테스트는 3개 이상의 기능의 인터렉션으로 구성되며, 사용자 시나리오를 중심으로 확인한다.궁극적으로 중요한 내용의 테스트이지만, 외부의존성으로 인해 비결정적일 가능성도 가장 높다. 테스트 실패의 원인을 찾기 어렵고 데이터 설정에도 시간이 소요되어 비 실용적일 수 있다.
이렇게 테스트 용어를 구분한 것은 별도의 개념을 만들기 위함은 아니다. 구글 테스터가 테스트하고자 하는 대상과 테스트 범위에 대해 공통의 용어를 사용하게 하기 위함이다. 자동/수동 테스트를 혼합하여 이 세가지 크기의 테스트에 적용하며, 자동화될 수 있고 사람의 지식과 직관을 필요로 하지 않는 문제라면 반드시 자동화한다.
코딩 프로세스
사레를 조사하면서, 어떻게 생각하면 당연할 수 있는 것에 놀랐다.
조사한 회사 모두 코드 리뷰를 하고 있으며, 코드 리뷰 시스템에는 기능에 대한 코드 뿐 아니라 해당 코드에 대한 테스트도 함께 포함된다는 것이다. 아래 간략히 그린 그림처럼 코드 리뷰시에 변경 코드와 해당 코드에 대한 테스트를 포함한다.
테스트 개선
Patric Copeland는 테스트 인증 프로그램이라는 방식을 사용하여 각 조직의 테스트 스킬과 성숙도를 높여갔다고 한다.
- 1단계 : 준비가 된 기본상태.
- 2단계 : 정책 세워지고 점진적 커버리지 개선이 이루어 짐.
- 3단계 : 새로 작성된 코드를 테스트 함.
- 4단계 : 레거시 코드의 리팩토링으로 테스트 수행력 올림.
- 5단계 : 전체 커버리지 올려나가고, 모든 결함에 대한 테스트를 작성하며, 정적/동 테스트 툴을 사용함.
나에게 던지는 질문들
이를 정리하면서 나에게 던지는 질문을 정리해본다.
- 코딩 능력을 어떻게 기를 수 있나? 지금이라도 코딩능력을 가져야하는 것일까?
- 현재 개발조직의 테스트는 어떠한가?
- 예방활동으로 하는 것이 있나?
- 현재의 업무 배정이 적절한 것인가? (현재는 독립된 조직으로 남아 테스팅을 해준다는 느낌이 여전히 강하다.)
- 대부분 우리가 하는 테스트는 구글의 테스트 유형으로 보면 대형테스트인데, 외부 의존성으로 인한 비결정적 문제를 어떻게 해결 할 수 있는걸까?
- 자동화는 옵션이 아니라 필수이다. 이를 위해 어떤 전략을 가져가야할까?
- 버그는 쉽게 등록되어야하고, 모두가 볼 수 있게 해야하는데.. 우리는 어떠한가?
- 유지관리 모드 테스트도 필요하다. 이는 검출의 목적이 아니라 품질 모니터링의 관점. 이 부분에 자동화를 엮으면 좋다. 이런 유형의 자동화가 각 서비스의 핵심 품질을 고려하여 수행되고있는가?
참조
2. Facebook
Facebook의 QA에 대한 내용은 quora에 facebook을 재직했던 엔지니어가 답변을 적은 것을 정리했다. 2-3년 전의 내용이며, 현재 Facebook의 QA상황과는 다를 수 있지만 충분히 참고할만 한 것 같다.
Facebook의 QA
별도로 독립된 QA Team은 없다. ‘Test engineering team’이 있었으나 이 팀은 Test infrastructure를 구축하고 유지보수 하는 업무이다. 앞서 살펴본 회사들과 마찬가지로 개발자들이 직접 테스트를 작성하고 실행 및 유지보수를 한다. 개인 또는 팀이 하는 테스트보다 도그푸딩(dog-fooding)을 한다. 출시 전에 일주일 정도는 임직원들이 미리 변경을 경험하고 버그를 올릴 수 있으며, 수동 테스트 보다 자동화 테스트를 한다. 또한 릴리즈 24시간 전에 beta facebook에 미리 반영하여, 이에 대한 버그도 리포트 받고 있으며, 페이스북 베타테스터 프로그램도 운영하고 있다.
실제로, Facebook 채용 사이트를 살펴봐도 Google과는 달리 Test 및 QA 엔지니어가 별도로 나와있지 않은 것을 보면, 현재도 QA나 테스팅 엔지니어로 구분된 역할은 Facebook에 없는 것 같다.
테스트 유형
Facebook의 테스트는 다음과 같은 유형으로 정리된다.
- PHP 코드 테스트
- 브라우져 기반 테스트
- UI기반 테스트 (Site behavior 테스트)
- Javascript 테스트
- 백본 테스트
PHP 코드 테스트는 PHPUnit 테스트 프레임워크를 사용하여 수행한다. 코드 베이스에 대해서 Unit 테스트는 상시 수행한다. 코드 커버리지 데이터는 수행해야할 테스트를 파악하기 위해 사용되며, 테스트결과는 코드리뷰 툴에 포함된다. 코드 리뷰 툴에는 변경 대상인 PHP 또는 Javascript뿐 아니라 이에 대한 테스트 결과도 포함되어 있다. 브라우져 기반 테스트는 Watir 프레임워크를 이용한다. 여기서는 개인정보 부분에 중점을 두고 테스트한다(예를 들어, ‘X가 어떤 항목 Y를 작성할 경우, Z에서 보여져야(혹은 안보여져야) 한다’ 와 같은 시나리오). 이와 같은 부분은 facebook에서 매우 중요한 부분(critical factor)이기에, PHP 코드 테스트에도 포함되어 있지만 중복으로 테스트를 수행한다.
UI기반 테스트는 UI 흐름에 의한 테스트로, Watir로 자동화되어있다. 조금 더 최신의 글을 보면 Site behavior 테스트도 소개되고 있는데 이는 Webdriver를 이용하여 자동화를 만들어 수행한다. 사용자가 사용하는 것과 같게 시나리오를 구성하고, 비동기적(asyncronous) 테스트를 만든다. Javascript 테스트는 jsspec을 이용하여 테스트한다. StackShare에 공유된 것을 보면 현재는 jsspec이 아닌 Jest를 사용하는 것 같다.
백본 테스트는 서비스에 따라 다양한 테스트 프레임워크를 사용한다. Boost 테스트 클래스, JUnit 및 자체 C++로 구현된 테스트 프레임워크를 사용한다. CI와 빌드시스템에 통합되어 있어 지속적으로 테스트가 수행된다.
이렇게 QA/Test Engineer를 두지 않고 서비스를 배포 운영할 수 있는 데에는 무책임하게 사이트에 변경을 반영하는 것을 매우 부끄럽게 여기는 문화가 중요한 역할을 한다고 한다. 나쁜 코드에 Clowntown 태그를 붙여두어 개발자들이 실수를 반복하지 않도록 하기도 한다 (참고).
또한 견고한 Lint 프로세스가 있다. anit-pattern, 알려진 성능 킬러, bad style 등을 걸러내며 PHP, JS, CSS 등 모든 변경이 Lint를 거친다. 성능 지표를 얻는 프레임워크를 통해 성능 이슈를 걸러내고 있다.
자동화
최근의 내용을 보면, GTAC2104 – Never Send a Human to do a Machine’s Job: How Facebook uses bots to manage tests에서 Facebook의 테스트 자동화에 대한 이야기를 들을 수 있다. 규모가 커지면서 발생한 문제들을 테스트 자동화로 극복한 것을 설명하며 10000여개 정도의 테스트가 수행된다고 한다. 또한 사람의 개입을 최소화하면서 테스트를 지속적으로 수행하면서 실패 테스트 비율을 줄여나가고 있음을 말하고 있다.
테스트 개선의 방향
테스트 프로세스의 튜닝은 엔지니어의 효율을 극대화하며, 테스트의 수행을 기다리는 시간을 최소화하는 방향으로 이뤄진다. Facebook에서는 테스트 속도를 어떻게 높일수 있을지, 중요한 부분에 대해 테스트하도록 테스트 대상을 어떻게 선정할지, 의사결정에 도움을 주기위해 테스트결과를 어떻게 통합할지를 고민하면서 계속적으로 테스팅 프로세스를 개선해 나간다.
나에게 던지는 질문
- 사내 베타 테스트를 위해, 전체 서비스가 통합된 베타 환경이 있어야하는 건 아닌가?
- 이제 코드리뷰가 필수 문화가 되어갈텐데, 우리도 변경 코드 뿐 아니라 테스트도 함께 포함되도록 해야하는 건 아닐까?
참조
3. Atlassian
Atlassian 블로그의 QA 시리즈 포스트를 요약하여 정리한다.
Atlassian의 QA
Atlassian의 테스팅 및 QA의 목표는 “높은 품질의 소프트웨어를 빠르게 배포하는 것”이다.
인력구성은 다음과 같다.
- 개발 및 Team Lead (78)
- 제품 관리자 (Product Manager) (10)
- UX(UI) 디자이너 (6)
- Tech writer(3)
- QA 엔지니어(6)
QA는 역할은 테스터가 아니며, 실제 수동테스트를 포함한 모든 테스트는 개발자가 수행한다. Atlassian의 대표 제품인 JIRA에 대한 QA 프로세스는 아래와 같다.
QA는 각 단계에서 피드백을 주는 데, Demo 단계에서는 실제 코드 레벨까지 보면서 미팅을 수행하기도 한다. Demo 이후 단계인 ‘개발자 테스트’는 옵션이다. 내가 속한 현실에서는 보통 앞 단계의 피드백은 주지 못한 채, 오픈 전 테스트는 필수로 하고 있는데 이런 방식은 조금 충격적이다. 테스팅을 하는 QA 엔지니어가 테스트 안해도 된다는 판단을 내려주는 것이다. 이는 단순한 판단이 아닌 전문가적인 판단이 필요한 영역이다. QA 엔지니어는 테스팅 의사 결정을 내리는데에 도움을 줄 수 있는 역량을 가지고 있어야 하는데, Atlassian에서는 아래와 같이 정리하고 있다.
- 코딩 지식
- 테스팅 스킬
- 제품 지식
- 유저 중심의 마인드 셋
- 버그 히스토리에 대한 지식
이렇게 하는 이유는 최대한 빠른 릴리즈를 지원하기 위해 버그로 인한 재작업을 줄일 수 있도록 지원하고자 함이다. QA 엔지니어는 시니어 기술 스킬을 갖고 있는 전문가로, 시니어 개발자에게 조언(advice)를 할 수 있는 수준이어야 한다. 때문에 Altlassian에는 주니어 QA 엔지니어가 없다.
구글과 마찬가지로 QA와 테스팅의 목표는 결함 찾기가 아니라 예방에 초점을 맞추며, 화이트박스 테스트와 테스트 의사결정에 중점을 둔다. 결함 분석을 할 때에도 기존의 버그 DB를 뒤지면서 분석한다.
조직의 측면을 보면, Atlassian은 제품에 따라 서브팀이 있을 뿐, 직무에 따른 서브팀은 없다. 모든 QA는 실제로 다른 팀에 소속되어 일을 한다. 이 부분도 구글과 같다. ‘나는 테스팅을 한다’라는 목표보다는, 실제 제품팀에 속하여 ‘나는 제품을 만든다’는 느낌으로 업무를 수행한다.
초기 QA를 세팅한 Andrew Prentice은 다음에 기초하여 QA가 만들어졌음을 Introducing Atlassian QA 포스트에서 설명한다.
- 테스팅 능력은 태생적으로 갖게 되는 것이 아니다. 마법도 아니다. 배울 수 있고 가르칠 수 있는 기술(skill)이다.
- 개발자가 테스팅의 주체(Master)이다. 팀의 효율과 능력을 높이는 것 뿐 아니라 높은 품질의 소프트웨어를 만드는 것도 개발자의 몫이다.
- 테스팅은 결함을 찾을 뿐 아니라, 품질 문제의 근본 원인(root cause)를 해결하는 데에 초점을 둔다.
- 개발자가 좋은 테스터(good tester)가 되도록 돕는다. Quality Assurance를 하지 않는다. 다만 Quality Assistance를 한다.
나에게 던지는 질문들
- 우리 조직의 목표는?
- 전문적인 테스팅에 대한 의사결정을 내릴 수 있어야 하는 데, 이렇게 하려면 필요한 건 무엇일까?
- 단지 버그 등록 – 수정 확인 – 재 테스트 후 이슈 종료에 급급한 상황은 아닌지 되물어 보게된다. 버그의 근본원인을 파악하려고 하는 노력이 필요한 것이 아닐까? (이것도 예방의 한 차원일 수 있겠다.)
- 궁극적으로는 개발/제품팀에 실제로 소속되어 일하는 것이 필요한 것 아닌가?
참조
4. 비교
| 구분 |
|
|
|
| QA 업무 분류 |
개발 |
개발 |
개발 |
| 별도 직무로 존재? |
SET – 범용 테스트 인프라에 중점을 두며, 테스트 기능을 개발하는 개발자임 |
별도 존재하지 않음 |
QA (주니어는 없고, 시니어만 있음) |
|
TE – 엔지니어이며, 사용자인 개발자이다. 개발자가 존중하는 기술과 개발자가 알아야하는 사용자 측면의 관심영역을 조합한 직책임 |
|
|
| 조직 |
생산성혁신팀(Engineering Productivity)으로 독립 |
별도 팀 없음 |
별도 팀 없음 |
|
제품팀에 속하여(배정)되어 일함. (18개월 정도) |
|
제품팀에 속하여 일함. |
| 목표 및 초점 |
(모든 엔지니어가 테스트는 하지만) 더 좋은 테스트하기 |
|
높은 품질의 s/w를 빠르게 배포하는 것 |
|
근본원인 파악 및 예방에 중점 |
(동일) |
(동일) |
|
테스팅이 혁신과 개발의 뒷덜미를 잡지않도록 함 |
엔지니어의 효율 극대화 및 테스트 수행 대기 최소화를 목표 |
테스팅 스킬을 가르쳐서 개발자가 Good Tester가 되도록 도움 |
|
|
|
단계별로 QA는 피드백을 주며 테스트 의사결정에 도움을 줌 |
| 테스트 유형 |
소형/중형/대형/초대형 테스트 |
PHP/Javascript 테스트 |
DEMO 진행 후 개발자테스트는 선택임 |
|
|
브라우져기반 핵심영역 테스트 |
|
|
|
UI / Site Behavior 테스트 |
|
|
|
백본 테스트 |
|
| 개발자의 테스트 정도 |
소형테스트의 주체 |
모든 테스트를 개발자가 실행 및 유지보수 |
모든 테스트를 개발자가 실행 및 유지보수 |
|
중형은 SET, (초)대형은 TE가 테스트 주체 |
개인/팀보다는 출시 전 도그푸딩 |
수동테스트도 개발자가 진행 |
| 코드 리뷰 |
리뷰 시스템에 변경 코드 및 테스트 결과도 포함 |
(동일) |
(동일) |
| 자동화 |
사람의 직관이 필요하지 않은 모든 부분 자동화 |
테스트 유형별로 자동화 수행 |
(별도 언급 없음) |
|
제품팀별로 알맞은 테스트 프레임워크를 이용하여 수행 |
PHPUnit, Jest, Watir, Webdriver 등 사용 |
(개발자테스트는 자동화로 수행되는 듯) |
|
|
10000개 정도의 테스트 수행됨. (GTAC2104에서 발표) |
|
| 프로세스 |
카나리아-개발-테스팅-(베타)-릴리즈 |
|
계획 – 개발 – 데모 – 개발자 테스팅 – 완료 |
| 사내 베타 |
단계 중 ‘테스팅’ 단계는 사내 임직원이 사용할 수 있는 수준으로 배포됨 |
릴리즈 일주일전에 pre-release 버전을 임직원 대상 배포 |
(별도 언급 없음 ) |
|
|
외부에 beta facebook 및 안드로이드 베타 프로그램 운영 |
| |
Oasis5pm's Blog 