구글은 테스트를 어떻게하는가 2

 김정민 센터장님이 Part 1을 공유해 주시고, Original 역자께서 이러저런 사유로 부담이 크다며 공유가 늦어졌습니다. 

몇일 전 Part5까지 나온 걸 보고 밀린 포스트를 부랴부랴 번역해서, Part 5까지 금주 중에 연재로 공유 드리겠습니다.

발번역을 양해해 주시면 감사하겠습니다. ^^

(Part 2까지는 오리지널 역자께서 수고해 주셨습니다.)

 

James Whittaker가 구글로 갔을 때 James Whittaker를 알고 계신 분은 의외다~라고 생각하시는 분이 계셨을 겁니다.

James Whittaker는 개발자와 테스터가 나누어졌던 시절(?) 테스터 진영에 계신 분였습니다. 

탐색적 테스팅(Exploratory testing)을 강조하시던 분이셨고, 소프트웨어를 Break하는데 주된 관심을 가지고 계셨던 분입니다. 

이런분이 Test director가셨는데, 개발자 테스트를 강조하는 구글의 문화에 어떤 변화가 있을까?~가 제 나름의 관심사였습니다.

이런 궁금증은 머지않아 풀리게 됩니다.

 

혹시 지난 포스트가 궁굼하신 분은 아래 참고 바랍니다.

 

구글은 어떻게 테스트하는가 - Part 1

http://devcafe.nhncorp.com/ShareWithPDC/board_3/296855

 

 

====================================

 

구글은 어떻게 테스트하는가 - Part 2

 

By James Whittaker (Test Director at Google.)

 

"당신이 만들고 당신이 부셔라" 라는 모토를 실현하기 위해서는, 일반 개발자 외에도 조직 내에 추가로 필요한 역할이 있습니다.

특히 개발자들이 테스트를 효율적이고 효과적으로 할 수 있도록 해주는 엔지니어가 반드시 있어야 합니다. 

구글에서는 다른 사람을 좀 더 생산적이게 하는 역할이 있습니다.

이 엔지니어들은 자신을 테스터로 인식하기도 하지만, 사실 중요 미션은 생산성입니다.

여기서 생산성이 의미하는 바는 개발자들이 좀 더 효율적이고 품질좋은 코드를 생산해 내도록 하는 것입니다.
이러한 역할들에 대해 좀 더 알아보겠습니다.
 
1. SWE 또는 Software Engineer 는 일반 개발자를 의미합니다.

SWE는 사용자에게 전달될 Funtional 코드를 작성합니다.

설계 문서를 만들고, 자료 구조나 아키텍처를 설계하며, 대부분의 시간을 코드를 작성하고 리뷰하면서 보냅니다.

TDD, 단위 테스트, 또 앞으로 다른 포스트에서 추가로 설명하겠지만, Small, Medium, Large 테스트를 포함하는 많은 테스트 코드를 작성합니다.

SWE는 작성하건 고치건 수정하던 간에 그들이 만진 모든 것에 대한 품질을 책임집니다.

2. SET 또는 Software Engineer in Test는 역시 개발자지만, 주로 Testability에 초점을 맞춥니다.

그들은 설계를 리뷰하고 코드의 품질이나 위험을 좀 더 자세히 들여다 봅니다.

그들의 주요 임무는 코드를 좀 더 테스트 가능하게 만드는 것입니다.

SET는 단위 테스팅 프레임웍을 작성하거나 자동화를 책임집니다.

SWE가 작성한 코드를 기준으로 보면 SET는 파트너이지만, 기능을 추가하거나 성능을 높이기보다는 품질이나 테스트 커버리지를 높이는데 좀 더 중점을 둡니다.

3. TE 또는 Test Engineer는 SET와는 정반대 방향으로 일을 합니다. 즉 테스트를 먼저 생각하고 개발을 나중에 생각하는 역할입니다.

구글의 TE들은 자동화 스크립트 형태의 코드를 작성하고, 사용자 시나리오 또는 실제 사용자 행위를 흉내 내는 코드를 작성합니다.
또한 TE는 특히 릴리즈를 앞둔 프로젝트의 마지막 단계에서 SWE나 STE의 테스트 작업물들을 조직화하고 테스트 결과를 해석하며 테스트 실행을 주도합니다.

TE는 제품 전문가이고 품질 조언가이며, 위험 분석가라고 할 수 있습니다.
 
품질입장에서 보면, SWE는 Feature와 Feature별 품질을 책임진다. 

Fault Tolerant 설계, Failure 복구, TDD, 단위 테스트를 책임지며, SET와 협업하에 Feature 를 실행시키는 테스트를 작성합니다.
SET는 테스팅 Feature를 제공하는 개발자입니다.

stub, mock, fake으로 의존성을 대체하여 신규 개발 코드를 고립시키는 프레임웍 등을 의미합니다.

다른 말로 하면, SET는 SWE가 기능을 테스트할 수 있게 도움을 주는 코드를 개발합니다.

대부분의 테스트는 SWE에 의해 이루어집니다.

SET는 Feature가 Testable 하고 SWE가 테스트 케이스 작성에 적극적으로 참여할 수 있도록 기반을 제공합니다.
 
SET의 주요 관심사는 개발자입니다.

각 Feature의 품질이 목표이며, 개발자가 작성하는 코드를 쉽게 테스트할 수 있도록 하는데 목표를 둡니다.

이 개발자 초점의 테스트에는 큰 구멍이 하나 있습니다.

사용자 관점은 어떻게 할까요?
 
사용자 중심의 테스트는 구글 TE의 주요 업무입니다.

SWE와 SET가 모듈과 Feature 레벨의 테스팅이 충분히 수행되면, 다음 단계는 실행 코드와 데이터 집합이 함께 어우러져 사용자 니즈를 어떻게 만족하는지 확인하는 것입니다.

TE는 개발자의 작업을 재확인 합니다.

이 단계에서 뻔한 버그가 보인다면, 개발자 테스팅의 초기 단계에서 뭔가 불충분하거나 대충 수행하였다는 것을 의미합니다.

이런 버그들이 많지 않다면, TE는 다음 단계로 넘어갈 수 있습니다.

소프트웨어가 일반 사용자의 시나리오를 잘 수행하는지, 성능이 충분히 나오는지, 안전한지, 국제화가 잘 되었는지 등을 확인합니다.

TE는 많은 테스트를 수행하고 TE, 계약직 테스터, 외부 Crowd 테스터, Dog Fooding 수행자, 베타 유저, 얼리 어댑터가 수행하는 테스트를 코디네이션합니다.

상위 설계에 포함된 위험, 기능상의 복잡도, 실패 회피 방법 등을 모든 참가자와 공유합니다.

TE가 한번 참여하기 시작하면, 그 임무에는 끝이 없습니다.
 
이제 역할에 대해서는 좀 더 이해하게 되었을 것입니다.

다음에는 이런 업무 항목들을 어떻게 구성하는지 좀 더 자세히 알아볼 것입니다.

다음까지...여러분의 관심에 감사 드립니다.

 

============원문=============

 

How Google Tests Software - Part Two

Wednesday, February 09, 2011 6:36 PM

By James Whittaker

In order for the “you build it, you break it” motto to be real, there are roles beyond the traditional developer that are necessary. Specifically, engineering roles that enable developers to do testing efficiently and effectively have to exist. At Google we have created roles in which some engineers are responsible for making others more productive. These engineers often identify themselves as testers but their actual mission is one of productivity. They exist to make developers more productive and quality is a large part of that productivity. Here's a summary of those roles:

The SWE or Software Engineer is the traditional developer role. SWEs write functional code that ships to users. They create design documentation, design data structures and overall architecture and spend the vast majority of their time writing and reviewing code. SWEs write a lot of test code including test driven design, unit tests and, as we explain in future posts, participate in the construction of small, medium and large tests. SWEs own quality for everything they touch whether they wrote it, fixed it or modified it.

The SET or Software Engineer in Test is also a developer role except their focus is on testability. They review designs and look closely at code quality and risk. They refactor code to make it more testable. SETs write unit testing frameworks and automation. They are a partner in the SWE code base but are more concerned with increasing quality and test coverage than adding new features or increasing performance.

The TE or Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Many Google TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics a user. They also organize the testing work of SWEs and SETs, interpret test results and drive test execution, particular in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers and analyzers of risk.

From a quality standpoint, SWEs own features and the quality of those features in isolation. They are responsible for fault tolerant designs, failure recovery, TDD, unit tests and in working with the SET to write tests that exercise the code for their feature.

SETs are developers that provide testing features. A framework that can isolate newly developed code by simulating its dependencies with stubs, mocks and fakes and submit queues for managing code check-ins. In other words, SETs write code that allows SWEs to test their features. Much of the actual testing is performed by the SWEs, SETs are there to ensure that features are testable and that the SWEs are actively involved in writing test cases.

Clearly SETs primary focus is on the developer. Individual feature quality is the target and enabling developers to easily test the code they write is the primary focus of the SET. This development focus leaves one large hole which I am sure is already evident to the reader: what about the user?

User focused testing is the job of the Google TE. Assuming that the SWEs and SETs performed module and feature level testing adequately, the next task is to understand how well this collection of executable code and data works together to satisfy the needs of the user. TEs act as a double-check on the diligence of the developers. Any obvious bugs are an indication that early cycle developer testing was inadequate or sloppy. When such bugs are rare, TEs can turn to their primary task of ensuring that the software runs common user scenarios, is performant and secure, is internationalized and so forth. TEs perform a lot of testing and test coordination tasks among TEs, contract testers, crowd sourced testers, dog fooders, beta users, early adopters. They communicate among all parties the risks inherent in the basic design, feature complexity and failure avoidance methods. Once TEs get engaged, there is no end to their mission.

Ok, now that the roles are better understood, I'll dig into more details on how we choreograph the work items among them. Until next time...thanks for your interest.

 

http://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html