우리는 '어떤' QA를 해야할까?

QA란 Quality Assurance의 준말로, Software QA는 소프트웨어가 올바르게 구동하는지 테스팅 하고, 제품의 품질을 높이는 활동을 말합니다.

표준 프로세스는 존재하지만 어떤 일이든 프로세스 대로 진행되는 경우는 거의 없습니다. 기업에 따라 생각하는 프로세스와 목표하는 바가 다르기 때문이죠. 그렇다면 우리는 어떤 목표를 잡고, 무엇을 위해 QA를 해야할까요?

세상에는 수많은 기업들이 있듯이, 수 많은 프로세스가 존재합니다. 

추구하는 바도 모두 다르고, 규모 또한 다릅니다. 

여러 기업들의 QA 사례를 통해 더 배울점은 없는지, 우리에게 더욱 적합한 프로세스 또는 전략은 무엇인지 생각을 해볼 필요가 있습니다.

다른 기업들은 어떻게 QA를 하고 있는지 알아보겠습니다!

QA 프로세스 사례는 일부만 공개된 경우가 많고, 오래된 자료가 많아 참고만 해주세요

1. Google

< 특징 >

- 테스팅만을 수행하는 조직은 없음

- 엔지니어링 생산성(Engineering Productivity) 라고 부르는 집중 영역 안에 테스트가 존재

- 사전에 버그를 예방하는 것이 주된 목표

  다른 엔지니어들이 하지 않는 ‘더 좋은 테스트’를 하는 사람

< 엔지니어링 생산성 영역은 크게 세가지로 분류됨 >

- Product Team

  : 회사 전반에 걸쳐 다양하게 사용되고 있는 내부 오픈소스 툴을 만드는 팀

     코드 분석기/통합 개발 환경/테스트 케이스 관리 시스템, 

     자동화 테스팅 툴, 소스 제어 시스템, 코드 리뷰 스케쥴러/버그 데이터베이스 등

-> 업무 생산성을 더 높이는 활동

- Service Team

  : 지식과 서비스를 제공해주는 팀

     툴에 대한 사용법, 문서화 / 테스팅과 관련된 지식 / 릴리즈 관리법 / 교육 훈련 등

- Embedded engineers

  : 필요할 때 마다 제품의 팀에 투입됨. 기간과는 상관 없이 가장 필요하다고 생각되는 곳에 

   투입되며, 업무 전반적으로 폭넓게 이해하고 경력이 많은 사람들이 있음

구글은 주기적으로 팀을 바꿀 것을 권장합니다. 새로운 제품을 접함으로써 업무에 집중하고, 객관적인 자세를 유지할 수 있다고 생각합니다. 이는 테스터도 예외가 아니며, 실제로도 자주 변경된다고 합니다. 다만, 팀을 변경할지에 대한 여부는 개인이 결정합니다.

한 제품 내에는 아래와 같이 역할이 구분되어 있습니다.

  1. SWE (Software Engineer)

  2. SET (Software Engineer in Test)

  3. TE (Test Engineer)

SWE는 전통적인 의미의 개발자입니다. 

개발 단계에서 테스트 주도 개발, 유닛 테스트 등의 테스트 활동에도 참여를 합니다. 또한 그들이 작성하거나 혹은 변경한 모든 것의 품질에 대한 책임을 집니다.

SET는 SWE와 같이 개발을 하지만, in test 테스트에 관한 것들을 개발하는 사람입니다. 

SWE가 작성한 설계 문서를 리뷰, 코드의 품질 및 리스크를 심도있게 살펴보는 활동을 하며, 리팩토링, 유닛 테스팅 프레임 워크, 자동화 코드 작성등의 활동을 합니다.

TE는 개발자 입장보다는 사용자 입장에서 테스트를 진행합니다. 

해당 제품의 전문가여야 하며, 품질에 대한 조언을 하는 역할입니다.

이 중 SET와 TE는 제품의 팀원이면서 동시에 엔지니어링 생산성 조직에 포함되어 있습니다.

< 테스트 규모 >

구글은 소, 중, 대로 총 3단계의 테스트 규모를 가지고 있습니다.

소규모

- 규모가 작은 코드를 커버하며, SWE, SET에 의해 자동화 됩니다.

중규모

- 2개이상의 기능이 포함되며, 상호작용을 테스트 합니다. 

자동화 또는 일부는 수동으로 진행합니다.  테스트가 난해할수록 수동으로 진행하는 비율이 증가합니다.

대규모

- 3개 이상의 기능 및 최대한 많은 사용자 시나리오를 반영합니다. 

기능이 제대로 동작하는 것 뿐만 아니라 ‘우리가 기대한 대로 동작하는 건가?’ 등의 난해한 질문에 대해 답하기 위한 테스트가 수행되기도 합니다. 출시가 되기 전, 자동화, 탐색적 테스팅, 개밥먹기등 가능한 모든 수단이 테스트를 완수하기 위해 동원됩니다.

< 내부 소스코드 채널 관리 >

구글의 소스코드 채널은 총 4단계로 구분됩니다.

- Canary Channel : 아직은 부적합한 코드가 업로드되는 채널

- Dev Channel : 개발자들이 하루 단위의 작업을 확인하기 위한 채널

- Test Channel : 내부적인 개밥먹기 및 테스트를 위한 채널

- Beta or Release Channel : 외부로 노출되는 최초의 빌드

2. Facebook

- 테스팅 만을 수행하는 조직은 없음

- Test engineering team이 존재하여, 테스트 기반을 구축하고 유지보수함

- 개발자들이 직접 테스트 코드를 작성함

- 많은 개밥먹기

< 대부분의 테스트를 자동화 >

PHP 코드 테스트 -> PHP Unit

브라우저 기반 테스트 -> Watir

UI 기반 테스트 -> Watir

Javascript 테스트 -> Jsspec / Jest

백몬 테스트 -> 서비스에 따라…

< Facebook 문화 >

  별도의 QA와 TE를 두지 않고 서비스를 배포하고 운영할 수 있는 데에는, 사이트의 변경점을 무책임하게 반영하는 것을 매우 부끄럽게 여기는 문화가 중요한 역할을 한다고 얘기합니다.

< 품질 관리의 규모화 >

  페이스북은 품질 관리를 규모화 하기 위해 총 3단계로 구분합니다.

1. 점진적인 릴리즈

- 주요한 릴리즈를 한꺼번에 하지 않으며, 점진적으로 천천히 릴리즈 합니다. 문제가 발생 했을 때 대응하기가 수월합니다.

2. One World를 통한 테스트

모바일과 웹을 사용하는 사용자들의 환경은 무궁무진 합니다. 이런 환경을 테스트할 수 있도록 시뮬레이터와 도구를 구축 했는데요. 사내 모바일 디바이스 실험실 / 시뮬레이터 및 에뮬레이터인 “One World” 등이 있습니다. 팀이 원하는 만큼 테스트를 진행할 수 있습니다.

3. 릴리즈 전 개밥먹기

회사의 규모가 큰 만큼, 전 세계적으로 수 많은 직원들이 있습니다. 이런 막대한 인력을 통해 사내 개밥먹기 테스트를 진행합니다. 다양한 환경 뿐만 아닌, 다양한 관점에서의 테스트가 진행될 수 있습니다. 실제로 사내에 아이폰 사용자가 너무 많아 개밥먹기를 위해 “Droidfooding”를 구현하기도 했습니다.

3. 스타일 쉐어 (Style Share)

지금까지 큰 기업들만 소개 해드렸는데요. 하지만 규모가 큰 기업들 보다는 규모가 작은 기업들이 훨씬 많기 마련입니다. 스타일 쉐어는 패션 정보를 공유하는 어플리케이션으로, 인스타그램과 비슷한 느낌입니다. 웹, 안드로이드, iOS 플랫폼을 대상으로 합니다.

  - 인력과 시간이 상대적으로 제한적인 소규모 팀으로 구성되어 있음

  - 명세기반 테스트는 최소화, 도구를 사용함

< 프로세스 >

알파 빌드 > 1차 QA / 알파 테스트 > 버그 수정 > 베타 빌드 > 최종 확인 > 릴리즈

- 업데이트 주기 : 4주당 1회

- 마지막 4주차에 QA 및 릴리즈 스프린트가 진행됨

- 담당 엔지니어의 단위 테스트 > 통합 테스트 순으로 진행

- 개밥먹기 적극 활용

< 최소한의 테스트 케이스만 확인 >

인력이 한정되어 있다 보니 명세기반 테스트는 최소화 합니다. 또한 다양한 시각으로 테스트를 할 수 있도록 해당 기능을 개발한 엔지니어가 아닌, 다른 파트의 엔지니어가 테스트를 진행합니다. 오류를 발견하거나, 서비스 개선 아이디어를 찾는데 효과적인 전략입니다. 1차 QA가 끝난 후에는 전체적인 개밥먹기가 진행됩니다.

< 점진적 출시 >

안드로이드 어플리케이션에는 ‘제품의 단계적 출시’라는 기능이 있습니다. 업데이트를 한번에 모든 사용자에게 하는 것이 아닌, 일부에게만 업데이트를 한 후 문제가 없으면 더 많은 사용자에게 배포를 하는 것을 의미합니다. 페이스북의 점진적 릴리즈와 비슷한 맥락이며, 오류가 생겼을 때 빠르게 대처가 가능하다는 특징이 있습니다.

정리를 해보자면..

개밥먹기, 우리도 해볼까?

세 기업의 특징은 모두 개밥먹기를 하고 있다는 것이었습니다. 물론 새로운 것을 시도해볼 때는 ‘이게 좋대~ 우리도 해보자~’ 하는 마음이 아닌, ‘이런 효과가 있다는데… 우리에게도 적용해볼 수 있을까?’ 라는 생각으로 접근하는 것이 중요합니다.

개밥먹기란, 우리가 만든 제품을 우리가 테스트 해보는 것을 말합니다. 만든 사람 본인이 기획대로 만들어졌다고 하여 직접 사용해보지 않는다면 그 프로그램의 품질은 말로 하지 않아도 알것입니다. 만든 사람 본인 뿐만 아니라, 해당 제품을 만드는데 기여한 모든 사람들에게 폭넓게 적용될 수 있습니다.

개밥먹기는 신입 사원에게 제품을 이해시키는데 탁월하며, 사내 직원을 통해 진행이 되기 때문에 전사적으로 제품을 이해하고 관심을 갖게 하는데 좋습니다. 또한 제품 관계자만 테스트를 진행하다 보면 매너리즘에 빠질 수 있기에 다양한 시각으로 보는 관점에도 영향을 끼칩니다.

자동화는 필수, 어떤 식으로 전략을 가져가야 할까?

세상이 자동화에 대해서 떠들지만, 사실 모든 것이 자동화 될 수는 없습니다. 오히려 자동화를 하는데 더 많은 리소스가 들어갈 수도 있습니다. 그렇기에 어떤 것을, 어떤 수준까지 자동화 할 것인지에 대한 전략이 필요합니다. 플랫폼이나 제품 성향등에 따라 전략은 다양하게 세워질 수 있습니다. 우리 제품에서 자동화 할 수 있는 부분은 얼마나 있을지, 초기 개발단계 또는 마지막 테스트 단계등 어느 부분에서 자동화를 해야 더 효율적일지를 생각해볼 필요가 있습니다.

더 많은 생각들

다른 기업들의 프로세스를 살펴보며, 우리가 취해야할 전략은 무엇인지와 우리 제품의 특징에 대해서 한번 더 생각해 볼 수도 있습니다.

대부분의 기업은 규모가 크지 않습니다. 작은 규모의 테스트를 전략적으로 고려해볼 수 있을지에 대해 되돌아 볼 수도 있습니다.

다른 기업들의 사례를 보며, 좋았던 것들을 기업에 적용 하는 것도 방법이 될 수 있습니다. 코드 리뷰를 한다던지, 계속 설명드리는 개밥먹기를 적용 한다던지 말이지요.

궁극적으로, 어떤 것을 중점으로 둘 것이냐에 대해서 생각해 봐야 합니다. 크게 놓고 본다면 무조건 완전한 품질이 우선인지, 빠른 배포가 우선인지 말이지요. 구글의 목표도 ‘완전한 품질’이 목표가 아닌, ‘사전에 버그를 예방하는 것’이 목표입니다. 하지만 사용자의 안전과 밀접하게 관련된 제품이라면 ‘완전한 품질’이 목표가 될 수도 있겠죠?

‘우리의 목표는 무엇인가? 어떤 QA를 해야하나?’

위와 같은 질문에 우리의 제품을 되돌아보고, 다시 한 번 생각해보게 되는 계기가 되었길 바랍니다. 감사합니다.

참고자료

- https://oasis5pm.wordpress.com

- https://www.google.com

- https://www.theteams.kr