구글은 테스트 어떻게하는가 3
구글은 어떻게 테스트하는가 - Part 3
At Google, quality is not equal to test. Yes I am sure that is true elsewhere too.
“Quality cannot be tested in” is so cliche it has to be true.
From automobiles to software if it isn’t built right in the first place then it is never going to be right.
Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-the-fact.
구글에서 "품질"이란 개념은 "테스트" 라는 개념과 일맥상통하지 않습니다. 물론 다른곳도 그렇다고 생각합니다. "품질은 테스트될수 없다" 라는 말은 너무나도 이제 흔한 말이니, 당연히 사실이겠지요.
자동차부터 소프트웨어까지, 처음부터 제대로 만들어지지 않았다면 절대로 끝까지 제대로 되지 않을 것입니다.
리콜을 해야 했던 어느 자동차 회사에 물어보십시오. 사후(事後)에 품질을 바로잡는 것의 비용은 엄청나다고 할것입니다.
However, this is neither as simple nor as accurate as it sounds.
While it is true that quality cannot be tested in, it is equally evident that
without testing it is impossible to develop anything of quality.
How does one decide if what you built is high quality without testing it?
하지만, 저 말은 저만큼 간단하지도 않거니와, 정확한 말도 아닙니다. 품질이 테스트될 수는 없다는 말도 옳지만, 테스팅을 하지 않는다면 만족스러운 품질의 어떤 산출물도 나오지 않는다는 말 역시 옳습니다.
무엇이 만족스러운 품질을 가지고 있는지 테스트 하지 않고 어떻게 알수 있습니까?
The simple solution to this conundrum is to stop treating development and test as separate disciplines.
Testing and development go hand in hand.
Code a little and test what you built. Then code some more and test some more.
Better yet, plan the tests while you code or even before.
Test isn’t a separate practice, it’s part and parcel of the development process itself.
Quality is not equal to test; it is achieved by putting development and testing
into a blender and mixing them until one is indistinguishable from the other.
이 제 꼬리를 잡는 문제를 간단하게 해결하는 방법은, 개발과 테스트를 두개의 다른 업무로 생각하지 않는 것입니다. 테스트와 개발은 함께 톱니바퀴처럼 함께 실행하세요.
코드를 조금 작성하고 방금 만든것을 테스트하세요. 그리고 코드를 조금 더 쓰고 테스트를 조금 더 쓰세요. 그보다 더 좋은 것을 말하자면, 코드를 쓰면서, 혹은 쓰기 전에 테스트를 계획하세요.
테스트는 하나의 분리된 업무가 아니라 개발이라고 하는 커다란 프로세스의 한 부분입니다. 품질은 테스트가 아닙니다; 개발과 테스팅을 믹서기에 넣어 둘이 서로 구분이 되지 않을때 까지 섞어야만 이룰수 있는 것입니다.
At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other.
Build a little and then test it. Build some more and test some more. The key here is who is doing the testing.
Since the number of actual dedicated testers at Google is so disproportionately low,
the only possible answer has to be the developer.
Who better to do all that testing than the people doing the actual coding?
Who better to find the bug than the person who wrote it?
Who is more incentivized to avoid writing the bug in the first place?
The reason Google can get by with so few dedicated testers is because developers own quality.
In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong.
Having too large a test team is a very strong sign that the code/test mix is out of balance.
Adding more testers is not going to solve anything.
이곳 구글에서는 바로 그것이 목표입니다: 개발과 테스팅을 하나 없이 나머지를 할수 없을 정도로 합치는 것. 조금 빌드하고, 조금 테스트하고. 더 빌드하고, 더 테스트 하고.
여기에서 키 요소는 누가 테스팅을 하느냐 입니다. 구글에서 테스팅 업무를 전담하는 테스터들의 비율은 엄청 낮기 때문에, 유일한 가능성은 개발자가 테스팅을 하는 것입니다.
자신이 쓴 코드의 테스트는 누가 제일 잘 쓸까요? 자신이 써낸 버그를 가장 잘 찾는것은 누구일까요? 아예 버그를 피하고 싶은 욕구가 가장 큰 것은 누구일까요?
구글에서 이렇게 적은 숫자의 테스터들로도 작동할수 있는 이유는 개발자들이 품질을 "소유"하고 있기 때문입니다.
오히려, 테스트에 유난히 신경 쓴다면 일반적으로 애초에 제대로 하지 않고 있기 때문이라고 생각합니다.
너무 많은 테스터들을 가지고 있는 팀은 코드/테스트의 비율이 깨져있다는 것의 강한 징조이며, 테스터들을 더 추가한다고 해결할 수 있는 문제가 아닙니다.
This means that quality is more an act of prevention than it is detection.
Quality is a development issue, not a testing issue.
To the extent that we are able to embed testing practice inside development, we have created a process that is hyper incremental where
mistakes can be rolled back if any one increment turns out to be too buggy.
We’ve not only prevented a lot of customer issues,
we have greatly reduced the number of testers necessary to ensure the absence of recall-class bugs.
At Google, testing is aimed at determining how well this prevention method is working.
TEs are constantly on the lookout for evidence that the SWE-SET combination of bug writers/preventers are screwed toward the latter and
TEs raise alarms when that process seems out of whack.
결국 이 모든것의 의미는 품질이란 "찾는" 행동보단 "예방하는" 행동이라는 것입니다. 품질은 개발의 이슈이지 테스팅의 이슈가 아닙니다.
우리가 테스팅을 개발 안에 융합한다면, 우리는 아주 증분적인 방식으로 개발을 할 수 있습니다. 그 말은, 한번 수정 후에 너무 버그가 많다면 언제든지
한번 전으로 롤백을 부담없이 할 수 있다는 것입니다. 우리는 이것으로 인해 여러가지의 고객 이슈들을 예방했을 뿐만 아니라, 리콜을 해야 할 수준의
버그들을 예방할 수 있는 테스터들의 숫자 역시 큰 폭으로 줄였습니다.
구글에서의 테스팅은 이 "예방"의 방식이 얼마나 잘 이루어 지고 있는가 를 측정하는 데에 있습니다.
TE들은 항상 SWE-SET의 버그를 쓰는 자/예방자가 올바른 길로 가고 있는지를 확인하고 있으며, 그들이 그러지 않을 경우에는 바로 경보를 울립니다.
Manifestations of this blending of development and testing are all over the place from code review notes asking ‘where are your tests?’
to posters in the bathrooms reminding developers about best testing practices, our infamous Testing On The Toilet guides.
Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved.
SWEs are testers, SETs are testers and TEs are testers.
이 개발과 테스트의 융합을 추구하기 위해 회사의 아주 많은 곳에서 홍보를 하고 있습니다. 코드 리뷰에서의 "테스트는 어디있습니까?" 라는 말 부터,
이미 유명한 개발자들에게 테스팅의 best practice를 알려주는 화장실의 포스터들까지 이 활동의 일부입니다. 테스팅은 개발의 피할수 없는 요소이며,
개발과 테스트의 "결혼"이 "품질"이라는 아이를 낳습니다. SWE는 테스터이며, SET는 테스터이고 TE도 테스터입니다.
If your organization is also doing this blending, please share your successes and challenges with the rest of us.
If not, then here is a change you can help your organization make: get developers fully vested in the quality equation.
You know the old saying that chickens are happy to contribute to a bacon and egg breakfast but the pig is fully committed?
Well, it's true...go oink at one of your developer and see if they oink back. If they start clucking, you have a problem.
만약 당신의 조직 역시 이런 융합을 하고 있다면, 당신의 성공사례를 우리와 함께 해주세요.
만약 그렇지 않다면, 당신의 조직이 필요로 할수 있는 변화가 여기 있습니다: 개발자들이 품질교육을 완벽하게 받도록 하세요.
베이컨과 계란프라이의 아침식사를 위해 닭들은 알 하나만 헌신하면 되는데, 돼지는 자신을 완전히 바치지요?
당신의 개발자들에게 "꿀꿀!" 하고 물어보세요. "꿀꿀!"이라는 대답이 돌아온다면, 그들은 자신을 완전히 헌신할 수 있는 개발자들입니다.
만약 그들이 "꼬끼오~"라고 한다면? 그때부터 문제가 생기는 것이겠죠.
읽어주셔서 감사합니다.
설현준 드림.