구글은 어떻게 소프트웨어를 테스트하는가를 다시 보면서 책 내용 정리이다.

이 책 안에서도 품질, 테스팅에 대해서는 일관된 의견을 보이지 않는 부분들이 있다. 이 책의 저자, 그리고 인터뷰 대상자들은 각기 그들만의 테스팅, 품질에 대한 시각을 가지고 있다. 우리에게도 각기 다른 품질과 테스팅에 대한 시각이 있음을 인정하고, 이를 통해 더욱 나은 가치를 주는 서비스, 좋은 품질을 포함하는 코드가 세상에 나오도록 노력해야할 것 같다.

아이콘이 붙은 글들은, 책을 읽어가면서 아이디어, 우리에게 적용할 수 있는 부분들을 노트해놓은 것이다.

1. 테스트 전반

  • 품질 활동은 예방활동이다. 찾고 수정하는 활동이 아니라, 발생 전에 예방하는 활동이다.

  • 점진적으로 코드를 추가하는 프로세스를 추구한다. 이는 되돌리기 쉽도록 하기 위함이다. 작은 릴리즈를 선호한다. 한번에 많은 기능을 릴리즈하려 하지 않는다.

  • 테스트의 구분은 다음과 같다.

    • 소형 테스트 - 모듈, 함수에 대한 테스트이다.

    • 중형 테스트 - 이웃 기능간의 상호작용에 대한 테스트이다.

    • 대형 테스트 - 사용자 기대대로 동작하는지에 대한 테스트이다.

  • google에서 일반적으로 사용하는 테스트의 비중은 소형테스트 70, 중형테스트 20, 대형테스트 10이다.

  • 테스트는 애플리케이션/서비스의 feature 중 하나다.

  • 개발자를 테스트에 참여시키는 것이 중요하다. 이를 위해 TEST 인증 badge를 주는 방법을 도입했다.

    • 테스트 문화를 만드는 것이 중요하다.

  • 테스트 플랜은 리스크 관리 중심의 테스트 플랜이어야 한다. 지속적으로 살아있는 플랜이어야한다.

  • 왜라는 질문을 해야한다.가장 힘든 문제를 실제로 해결해주고 존경심을 얻어야 한다. 이것이 영향력이다.

  • `테스팅 문제와 테스팅을 수행하는 것이 인정받는 문화`가 중요하다.

  • 테스트를 해야한다는 것을 안다. 하지만 작성에 어려움을 겪는다.. 이를 해결하기 위한 방법은?

    • 스스로 경쟁하게 하는 것이다.

      • 테스트를 측정하여 공유한다. 커버리지는 몇 이고, 몇 분안에 수행된다…​ 다른 팀이 자극을 받도록 한다.

    • 측정도 중요하지만 믿음은 `사람`에게 둔다.

    • 굴종하는 문화는 좋지 않다.

  • qa 테스팅 활동외에는 테스트에 대한 측정/가시화가 되고 있지 않다.

    • 현재는, 과제 진행시 테스트에 대한 정보는 QA 테스트의 리포팅 뿐이다. QA 테스팅은 발견 후 수정을 위한 것이다. 개발 과정 중(코드가 만들어 지는 중)의 소형 테스트(단위테스트)의 활동에 대해서 측정하여 본다면, 더욱 어떤 테스트에 더 집중해야할지를 파악하는 데에 도움이 될 것이다.

    • 앞으로는, 모든 단계, 다양한 엔지니어의 테스팅 액티비티를 측정하고 이런 활동이 조화를 이루도록 하는 것이 필요할 것 같다. 이런 테스트 활동을 보여줄 방안이 필요하다.

  • 현재의 테스트 인풋은 무엇일까? 대부분 기획서에 의존한다.

    • 기획/ 비즈니스 룰/ 정책 등을 별도 정의하는 것은 어떨까? 이를 지속적으로 라이브하게 관리되고 있지 않다.

    • 비즈니스 로직의 문서화는 어떻게 해야하는가?

2. TE(Test Engineer), SET(Software Engineer in Test), TEM(Test Engineer Manager)

  • TE (여기서의 TE는 구글에서의 TE직무를 의미함.)는 `서비스 전체`의 약점을 찾는 직군이다.

    • TE로써 모호한 요구사항을 뛰어넘어야하며, 불분명한 문제들에 대한 이유를 밝히고 `논의`를 이끌어낸다.

    • 테스트 계획 - TC - 버그리포트 - 커버리지 리포트 - 사용자 만족도 조사 - 소프트웨어 품질 데이타 수집의 일을 한다.

    • Product domain expertise가 있어야한다. go-to person이다.

    • 제품 전문가가 되어야 문제가 보인다. 늘 질문해야한다. 이 일이 가치가 있는 것인가?

  • TEM(Test Engineer Manager)

    • 기술, 리더쉽, 조정자 역할로 모든 지원 팀에 단일 컨택포인트이다. TE / SET 모두에게 필요한 기술 셋을 알고 있어야한다.

    • TEM을 향한 조언 - 1) 제품을 알라 2) 네 사람들을 알라.

    • 개발과 품질에 대한 동등한 `파트너쉽`이 있어야한다.

    • 엔지니어의 목표는 영향력(impact)을 만드는 것이다

      • TEM은 성장에 대한 책임이 있고, 영향력을 갖도록 할 책임이 있다.배정한 후에는 TE/SET가 한 일이 영향력이 있도록 하는 역할을 해야한다.

    • 좋은 사례나 툴을 성공적으로 적용해야 한다.

    • 테스트 리더쉽으로 어려운 점.

      • 격려 vs. 명령 사이.

      • 스스로 자율적인 업무 진행, 실험정신을 갖고 업무 진행 vs. 팀 업무에 대한 일관성.

      • 정해진 리소스, 일정 안에서 어떻게 효율화된 테스트를 할 것인가에 대한 고민을 해야한다.

        • 리스크 분석 후 우선 순위를 매핑하는 것도 방법이다.

  • QA로써 논의거리를 던져 줄 수 있어야한다.

    • 모호한(없는) 기획서, 변경에 대한 공유 부재 등의 환경에서 어떻게 모호한 요구사항을 명확하게 이해할 것인가..

    • 테스트를 할 수 있도록 정보를 요구할 수 있어야 한다.

  • 기획/feature/spec은 moving target이다. 이를 어떻게 맞출 것인가?

  • 테스트.qa에 관련된 오픈 커뮤니티에 적극적으로 참여할 필요도 있다.

  • 장애나 이슈 발생시, 테스트 케이스가 있었나? 를 묻는 것은 당연한 것으로 여기자. 스트레스 받지 말자.

3. 테스트 자동화

  • 자동화 테스트는 정말 사람이 봐야하는 테스트에 집중할 수 있게, 그 활동이 믿을만 할 수 있게 도와주는 역할이다.

  • 테스트 자동화는 소프트웨어 개발이다.

    • 테스트 코드는 개발 속도를 가속화 시킬수 있어야하고, 개발을 방해하지 않는 선에서 실행해야한다.

    • 개발 프로세스와 통합해야한다. 개발과 분리해선 안된다.

  • 자동화 측면에 있어

    • 회귀 테스트(regression test)는

      1. 고위험군 capability에 대해서

      2. 중요버그 중 자동화 가능한 부분에 대한 것이 후보가 될 수 있다.

4. 서비스별 사례

Gmail (TEM 앵킷 메타(Ankit Mehta))

  • 테스트 비율은

    • 20% - 탐색적 테스트

    • 30% - 기능 테스트 (TE)

    • 50% - SET와 관련된 테스트 자동화 및 테스트 인프라 구축, 생산성 툴 만들기 작업을 한다.

  • 자동화 TIP

    • 개발언어와 동일한 언어로 만들라.

    • 테스트를 매끄럽게 작성할 테스트 인프라가 필요하다.

    • use case 20%가 80%의 사용성을 대표한다고 보는데, 대표성을 갖는지에 대한 질문하기.

    • 개발과의 협업이 필수적이다. 협업이 없는 것은 해결책이 아니라 수습책에 불과하다. 혁신적인 해결책을 고민하고 제시하라.

    • 테스트 자동화는 결국 탐색적테스트(수동테스트)를 잘하도록 돕는 것이다.

  • TE는

    • 전체 프로덕트를 자기 통제안에 둘 수 있어야한다.

    • 모든 테스트, 테스트 인프라가 실제적으로 효과적으로 사용될 수 있도록 해야한다.

  • 빠른 속도로 고품질을 갖도록 제품을 만드는 것은 최대의 도전이다.

Android(TEM 훙 당(Hung Dang))

  • pillar(기둥) 관점으로 테스트를 분류한다. 시스템, 프레임워크, 앱, 마켓 기둥으로 .. 그리고 테스터의 기술 역량을 해당 기둥에 매핑한다.

  • 자동화가 없다. 모든 사람(TE이건, SET이건)이 탐색적 테스트를 한다. 가치를 주고 있는지 끊임 없이 질문한다.

  • `전문사용자`가 되어야한다. `목적을 갖는 수동 테스트`에 대한 믿음이 있다.

  • 분석하고 분석하고 분석한다.

    • 변화에 중점을 두고 테스트 대상을 분석한다. 변경 내용이 무엇인지, 어떤 CL(Chnage list)들이 있는지, 추가/변경된 기능은 무엇인지, 누가 커밋을 하는지..

    • `수동 테스트의 핵심은 집중과 조율`이다. 이 두 가지가 있다면, 탐색적 테스트의 노력은 매우 가치가 있다.

  • 테스트케이스 문서화는 두 가지로 진행한다.

    1. 일반적인 유스 케이스.

    2. 특화 기능에 대한 테스트 가이드라인. (이는 테스트 케이스 형식이 아니다. 중요 기능을 테스트하는 방법과 가이드라인이다.)

  • "전 테스트 스크립트만 사용하며, 눈감고 업무를 수행하는 테스트 팀을 관리하고 싶지 않다"

  • `개발은 협력을 통해 일해야하는 파트너`이다.

검색,지도 (Test Director 쉘튼 마(Shelton Mar))

  • 구글 초기 변화해야했던 3가지

    1. 테스트를 위로 올려서, 전체 팀(개발 + 테스트)이 산출물에 대한 책임을 가지게 하는 것.

    2. `테스트 엔지니어링을 프로젝트 팀의 일부로 포함`하는 것.

      • 도전 과제, 기술을 이해할 수 있는 강한 엔지니어가 필요.

    3. `테스트에 전산학과 엔지니어링을 적용`하는 것.

  • Google Search

    • 구글 검색 테스트는 1) 검색품질 자체를 검증하는 것과 2) 검색 처리 인프라와 시스템을 검증하는 것으로 분리했다.

    • 무엇이 시스템에 있어 제일 중요한가를 질문하며 이를 먼저 제대로, 완벽히 검증해 나갔다.

    • 수동 테스트는 CI빌드가 있는 부분에는 사용하기가 어렵다.

      • 가능한 자동화했다. 기계가 90%, 사람이 10%정도이다. 지능적인 검증이 필요하다.

제임스 휘태커(James Whittaker) 인터뷰

  • 먼저 배우고 - 먹히는 방법을 찾고(경험하여 증명해보이기)- 혁신을 일으킬 방법을 세우기 의 순으로 업무를 진행했다.

  • google testing을 발전시키는데의 키워드는 기술, 희소성(개발자를 도울 수 있는 테스팅 자원의 희소성), 자동화, `반복적인 통합`이었다.

  • 테스팅 프로세스는 모든 엔지니어의 업무 흐름에 품질을 포함시키는 것이다.

  • 초기 구글 프로세스의 결함은

    1. "품질은 개발자의 업무이다."라는 것은 사실이나, 여기서 파생되는 `"테스터는 개발자의 보조"라는 부분이 결함`이다.

      • "테스트는 테스터가 한다" 라는 것은 오해며 오류이다. 이렇게 말하는 순간 더 이상 신경쓰지 않는 영역이고 서비스를 받는 영역이라는 생각을 갖게 한다.

    2. `테스터가 제품과 연결된 것으로 보기보다 직무 자체로 구분하는 결함`이다.

      • 건강한 조직은 "전 테스터에요"라고 말하는 것이 아니라, "나는 크롬을 만들어요"라고 말할 수 있어야 한다.

      • 테스트를 위해 일하는 것이 아니라, 제품을 위해 일해야한다.

    3. 테스터가 때로 `테스트 산출물을 더 중요히 여기는 오류`이다.

      • 테스팅의 가치는 그 `활동 자체`에 있다. 산출물에 있지 않다.

      • 모든 테스팅 산출물은 소스코드이다. 즉 제품에 영향을 미칠 때에 테스팅의 존재 가치가 있다.

  • 테스트를 거쳤음에도 여전히 살이있는 문제들을 잡기위해, 제한된 사용자에게 얼마나 자주 제품을 릴리즈 하고 있는가가 중요하다.

    • 도그푸딩, 클라우드 소싱 테스터, 얼리 어댑터 등 제한된 사용자 그룹에 자주 제품을 릴리즈하고 피드백을 받는 것이 중요하다. 이들은 항상 더 좋은 버그를 찾는다.

  • 중요한 기능이나 feature에 대해서는 단순 테스트케이스의 항목으로만 커버되지 않는 것 같다.

    • 주요 부분(고 위험의 capability를 갖는 부분 등..)에 대해서는 테스트 가이드가 정리되면 좋겠다.

  • Test Analytics for Naver.. (link, oss)

    • 컵셉은 좋다.. 다시 사용해볼까? GWT기반으로 유지보수는 쉽진 않다.. 내부 만들고 있는 곳에서 먼저 사용을 해보는 시도를..?

  • 개발자들이 개발에 어떤 툴, 언어, IDE.. 를 사용하는가? 인프라는 어떻게 되어있는가? 를 알고 개발의 언어와 컨텍스트를 점차 이해해나갈 수 있어야한다.

  • 클라우드 테스팅을 실험해 보는 것을 어떨까?

  • 생산성과 사기를 높이는 방법은 무엇일까?

    • 질문해볼 것 (우리에게) 1) 무엇이 흥분하게 하고, 2) 무엇이 회의감을 들게 하는가?

  • 다양한 테스트 영역을 보기위해..

    • 역량을 기르는 것도 중요하나, 역량이 있는 사람을 투입/추가/채용 하는 것도 중요하다.

    • 현재 우리가 구글에 정의한 SET,TE의 역할을 다 할 수는 없다. 기술 셋을 가진 사람이 있어야 한다.