구글은 어떻게 소프트웨어를 테스트하는가[독후감-1]

올해 이사하며 비싼똥 전공책까지도 다 버려서 텅텅 빈 책장을 보며, 이젠 사회인으로서 책을 사겠어! 마인드로 사놨던 중고책, 서점갔다가 표지가 예뻐서, 코드 품질 으음 중요하지^-6묵혀두었던 책들을 틈틈이 읽고 있다.

책은 마음의 교양

독서 스터디도 하고, 어휘력 증강을 목적으로 교양 책도 읽었던 열정을 되살려 독후감까지 써본다. 내 글이 책 구매까지 이어지길 바라는 마음도 있었지만 중간 중간 적은 내용이기 때문에 뒤죽박죽 의식의 흐름을 잘 따라와주시길 바랍니다...

---

저자인 휘태커와 이본은 구글, 마소 공룡기업에서 일했던 활동을 기반으로 내용이 작성되어있으며, 책 자체는 13년도에 나와 조금은 오래됐지만 방법론은 옛것이라고 가릴게 없다고 생각되어 샀던 책이였다. 다른 후기를 보니 혁신적인~ 완벽한 이라고 하는데 오늘날에는 어떻게 하고 있을지 문화 체험해보고 싶었다.ㅎㅎ:)

영어도 실력도 무리데쓰

 

아직 반정도밖에 못 읽었지만 읽다보면 실무에서 느끼고 있는, 고민하고 있던 부분을 콕 집는 문장과 방법을 메모하다보니 1 포스팅 분량이 나왔고, 초반부에는 테스트 엔지니어의 개요, 역할, 작업하며 고찰, 인터뷰 내용이 담겨져있다.

---

품질 != 테스트

품질 관련 조직에서 하는, 할 수 있는 많은 일 중 하나가 테스팅이다. 깊이의 차이가 있을뿐 자신이 할 줄아는 일이 하나뿐인 사람이 어디있겠는가? 하지만 주변 지인들과 이야기하다보면 '너 뭐하는데? 테스트?' 정도의 질문을 자주 받아왔고, 그럴때 마다 '테스트만 하지않고 이것 저것해' 식으로 얼버무렸던 것 같다. 여기서 저자는 좋은 품질의 제품을 만들기 위해서 테스트가 당연히 수반되는 것이며, 종종 조직에서 테스트했다고 품질을 갖췄어! 라는 맹신을 하곤 하는데, 품질과 테스트를 동치라고 생각하기 때문이 아닐까 싶다.

 

그래서 구글에서는 개발과 테스트 따로 구분하지 않는다고 하며, 실제로 코드를 만든 사람보다 더 테스트를 잘할 수 있는 사람은 없기 때문이다. 그래서 개발->테스트 구분하지 않고 짧게 개발하여 빌드 후 테스트하는 것을 추구한다.

---

Role of engineer

업무 역할 단위로 나뉘었는데 다음과 같다.

• SWE(software engineer) : 전형적인 개발자. 지엽적이고 부분적인 내용을 최적화하려는 경향이 있다. SET는 제품 전체와 전체 기능에 대한 넓은 관점과 많은 생명주기 동안 SWE가 이탈 및 참여를 한다는 것을 이해해야 한다.
• SET(software engineer in test) : 범용적인 개발자. 코드가 좀 더 테스트 가능하게 리팩토링 하고 설계를 검토, 테스트 프레임워크를 작성하고 자동화한다. 개발 프로세스의 모든 단계에서 테스트를 가능케 하는 사람. 품질 모델이나 테스트 계획에 관한 내용이 아닌 코드 기반의 설계와 생성에 능동적인 참여자라고 할 수 있다.
• TE(test engineer) : 전체 품질 활동을 계획하며 결과를 해석하고 수행하고 end to end 자동화를 빌드한다. 기능 구현을 위한 개발자와 달리 특정 단위 테스트를 만들며, 사용자 입장도 고려한다. 유스케이스, 유저 시나리오, 탐색 테스팅 등과 같은 사용자 중심의 업무를 수행한다

기업마다 다르겠지만, 규모가 클 수록 개발 조직 내에서도 세분화되어 다음과 같은 형태를 띄고 있는 것 같다. 반대로 말하면 혼자서 다 해야됨

---

설계 문서

설계 문서는 프로젝트 목적, 배경, 멤버, 제안된 내용 등을 담고 있으며 프로젝트와 함께 발전한다. 피어 혹은 다른 테크 리더를 통해 리뷰를 받을 때 SET는 광범위한 패턴과 컴포넌트 상호작용 설계 등 영향력을 증가시켜야 한다.

 

설계 문서 리뷰 GUIDE

1. 완전성: 문서에서 불완전한 부분이나 특별한 지식을 요구하는 부분, 새로운 멤버가 알아야 할 부분을 식별한다.
2. 정확성: 문법, 철자, 마침표에 대한 실수를 찾는다. 엉성함은 문서의 신뢰도를 낮춘다.
3. 일관성: 문서와 다이어그램이 일치해야 한다. 상충되는 내용이 없어야 한다.
4. 인터페이스와 프로토콜: 사용할 프로토콜에 대해 명확하게 식별되야 한다. 프로토콜 버퍼를 정의하게 할 수 있는가
5. 테스팅: 기술된 시스템을 어떻게 테스트 하는가? 새로운 장비 또는 기술이 필요하다면 내용을 추가한다.
   문서 리뷰는 추구하고자 하는 특정 목표가 있어야 한다.

---

 

테스트 규칙

테스트는 다른 테스트와 독립적이여야 하고 어떤 순서로든, 배타적으로 병렬 수행할 수 있어야 한다. 병렬 실행으로 인해 어느 한쪽의 테스트가 실패되어서는 안된다.
지속적으로 반복되는 어떠한 side effect가 없어야 한다. 테스트 중에 환경, 설정 정보가 변경되며 위배될 수 있다.

---

테스트 인증 프로그램

개발자에게 테스트의 중요성을 고착화하고 테스팅에 참여시키는 것은 어려운 일이다. 구글에서는 콘테스트처럼 레벨 단계 별에 따라 발전해나갈 수 있게 하였다고 한다. 구글링 해봤으나 지금도 하고 있는지는 모르겠다...구글 인맥 없음;;

적용 당시 초기 장애물로 무력증(내 할일도 바빠!), 제로 베이스, 나쁜 테스트, 시간이 오래걸린다는 걱정, 테스트를 다른 사람 혹은 팀의 문제로 생각하는 것이 있었고 이를 해결하고자 인증이 중요한 이유, 어떤 종류의 도움을 받을 수 있는 지 설정하는 방법들이 나와있다. 코드 리뷰 문화가 있는 조직에 들어가게 된다면 한번 기획해보고 싶은 보상 프로그램이였다.

---

테스트 계획

가장 처음으로 생성되는 테스트 산출물이지만, 가장 먼저 방치된다. like 빨래걸이가 되버린 런닝머신. 계획을 유지하는 방법은 손이 많이 가고 이해관계자와 정기적으로 논의되어 현 상태를 반영할 수 있어야 가치가 있는 것이기 때문이다.

테스트 계획서 요령:
서술형은 피하고 단순한 문장을 사용한다. 
뻥튀기 하지 말자. 대학 과제가 아니다.
흐름을 만들어라. 각 섹션은 이전 섹션과 흐름을 이어가며 독자가 읽는 것을 잠시 멈추고 제품 기능을 그릴 수 있어야 한다.
최종 결과물은 테스트 케이스여야 한다. 단순히 필요성에 대해 설명하는 것에 그치지 않고 직접적으로 케이스를 이끌어내야 한다

---

마치며

책 후반부는 TE에 대한 내용이 많은데, 원래도 궁금한거 생기면 찾아보면서 책을 읽다보니 조금 많이 오래걸릴 것 같은 느낌적인 느낌이지만 핑계대지 않고 금방 포스팅 할 수 있길!