책 발췌 – 구글의 테스트 엔지니어 채용 인터뷰

출처: 책 How Google Tests Software, James Whittaker, Jason Arbon, Jeff Carollo, 2012년, 130~133 페이지

 

구글의 테스트 엔지니어(TE) 면접이 어떤 식으로 이루어지고 어떤 인재상을 원하는지에 대해 기술한 것이다.

 

---

 

TE(Test Engineer) 채용을 위한 인터뷰

구글은 적절한 스킬 셋을 구비한 후보자를 찾으면 면접을 실시한다. 우리가 어떻게 TE를 인터뷰하는 지에 대해 사람들이 종종 물어보는 데, 실제로 구글 블로그나 공개 행사 토크에서 가장 많이 나오는 질문이기도 하다. 우리의 면접 질문 목록 전체를 내놓을 생각은 없지만, 우리 사고방식에 대한 이해를 돕기 위해 여기에 샘플을 공개한다(이게 공개되었기 때문에 더 이상 사용하지 않을 예정이다!).

 

먼저 우리가 테스트 적성을 조사한다. 우리 의도는 후보자가 그저 영리하고 창의적인 사람 이상인지, 테스트에 타고난 재능이 있는지 알아보는 것이다. 우리는 모든게 어떻게 만들어지는지, 어떤 변수와 구성 조합이 가능하고 테스트하기에 흥미로운지에 대한 타고난 호기심을 가진 이를 찾고 있다. 우리는 시스템이 어떻게 작동해야 하는지에 대한 확고한 감각과 그것을 명확하게 표현할 수 있는 능력을 찾고 있다. 우리는 또한 강인한 성격을 찾고 있다.

 

우리 아이디어는 다양한 입력 및 환경 조건이 필요한 테스팅 문제를 제공한 다음 후보자에게 가장 흥미로운 항목들을 열거하도록 요청하는 것이다. 단순한 수준에서 후보자에게 그림 3.26 같은 웹 페이지를 테스트하도록 요청한다(단일 텍스트 입력 상자와 레이블 count가 써진 버튼이 있으며, 버튼을 눌렀을 때 텍스트 스트링에 있는 문자 A의 수를 계산한다). 여기서 질문은 “당신이 테스트하려는 입력 스트링 목록을 작성하십시오” 이다.

 

그림 3.26 테스트 질문용 샘플 UI

 

일부 후보자는 곧장 뛰어들어 테스트 케이스를 나열하기 시작한다. 이게 종종 위험한 신호인 데, 그들이 문제에 대해 충분히 생각하지 않는 것을 보여주기 때문이다. 질보다 양에 초점을 맞추는 경향은 (대부분 경험을 통해 배운 바로는) 비효율적인 작업 방식이기 때문에 우리가 부정적인 것으로 해석을 한다. 후보자가 문제에 접근하는 방식을 살펴봄으로써, 그들이 솔루션에 미처 도달하기 전에, 우리가 후보자에 대해 많은 것을 알게 된다.

 

더 나은 경우는 후보자가 문제를 명확히 하기 위한 질문을 하는 것이다. 대문자 또는 소문자입니까? 영어만 인가요? 답이 계산된 후 텍스트가 지워집니까? 버튼을 반복적으로 누르면 어떻습니까? 등등

 

문제가 명확해지면 후보자가 테스트 케이스 나열을 시작한다. 미친 듯이 써 내려가는 그들의 열의에 특정 방법이 녹아 있는지 확인하는 것이 중요하다. 그들이 단지 소프트웨어를 망가트리려 애쓰는가 아니면 그것이 잘 작동하는지 확인하는 노력도 수반하는가? 자신이 하고 있는 일이 전자 또는 후자인지 그들이 인지하고 있는가? 최대한 빨리 큰 버그를 찾아내기 위해 빤하고 간단한 것부터 시작하는가? 자신의 테스트 계획/데이터를 명확하게 표현하는 방법을 생각해 낼 수 있는가? 화이트보드에 무작위 순서로 나열된 스트링이 사고의 명확성을 나타내지는 않으며, 그들의 테스트 계획(후보자가 계획을 세우는 수고라도 한 경우에)이 누더기가 될 가능성이 높다.

 

일반적인 목록이 아래와 같다.

• “banana”: 3 (하나의 현실 단어)
• “A” 또는 “a”: 1 (긍정 출력 결과를 가지는 단순한 유효 케이스)
• “”: 0 (0을 출력 결과로 가지는 단순한 유효 케이스)
• null: 0 (단순한 에러 케이스)
• “AA” 또는 “aa”: 2 (count > 1 이고 모두 A로 구성된 케이스)
• “b”: 0 (부정 출력 결과를 가지는 단순하고 공백이 아닌 유효 케이스)
• "aba": 2 (off-by-one 루프 버그를 찾기 위해 시작과 끝에 타겟 문자를 배치)
• "bab": 1 (스트링 ​​중간에 타겟 문자 배치)
• space/tabs/etc.: N (N개의 A를 가진 스트링에 혼합되어 있는 공백 문자)
• long string without As: N, where N > 0     「 왜 결과가 0이 아니고 N인지 모르겠음. 오타인가? 」
• long string with As: N, 여기서 N은 A의 수와 동일
• 스트링에 X\nX 포함: N, 여기서 N은 A의 수와 동일 (포맷 문자)
• {java/C/HTML/JavaScript}: N, 여기서 N은 A의 수와 동일 (실행가능한 문자, 에러 또는 우연한 코드 인터프리테이션).

 

위에 제시된 테스트 중 여러 개를 놓쳤다면 좋지 않은 지표이다.

 

더 훌룡한 후보자는 입력 선택의 세부 사항을 뛰어 넘어 더 고급 테스팅 이슈에 대해 논의한다. 예를 들면 아래와 같은 것이다.

• 모양과 느낌, 색상 팔레트 및 대조(contrast)에 대한 질문을 한다. 다른 관련 애플리케이션과 일관성을 유지합니까? 시각 장애인 등도 이용할 수 있습니까?
• 텍스트 상자가 너무 작은 걸 걱정하고, 입력 가능한 긴 스트링을 수용할 수 있을 만큼 충분히 크게 만들도록 제안한다.
• 동일 서버에서 이 애플리케이션의 여러 인스턴스에 대해 궁금해한다. 사용자 간의 혼선(crosstalk) 가능성이 있습니까?
• “데이터가 기록됩니까?”라는 질문을 한다. 주소나 기타 개인 식별 정보가 포함될 수 있다.
• 단어 사전에서 뽑아내거나 또는 책에서 선택한 텍스트 같은 일부 현실 데이터로 자동화를 제안한다.
• “충분히 빠른가? 부하가 있을 때도 충분히 빠를 것인가?” 같은 질문을 한다.
• “검색에 잡히는가? 사용자가 어떻게 이 페이지를 찾아내는가?” 같은 질문을 한다.
• HTML과 JavaScript를 입력하는 것이 페이지 렌더링을 훼손하는가?
• 대문자로 계산하는지 소문자로 계산하는지 또는 둘 다 세어야 하는지 질문한다.
• 스트링의 복사 및 붙여넣기를 시도한다.

 

후보자가 내놓는 일부 개념은 훨씬 더 발전된 것으로, 기꺼이 제시된 문제 너머를 바라보는 숙련되고 유용한 테스팅 마인드를 나타낸다. 예를 들면 아래와 같은 것이다.

• 카운트가 URL 인코딩된 HTTP GET 리퀘스트를 통해 서버로 전달되는 경우 스트링이 네트워크를 거쳐가는 동안 일부 ​​잘릴 수 있으며, 따라서 지원되는 URL 길이를 보장할 수 없음을 지적한다.
• 애플리케이션을 매개변수화 하도록 제안한다. 왜 오직 A만 계산하는가?
• 다른 언어(예: angstrom 또는 umlaut)에 쓰인 다른 A를 세는 것을 고려한다.
• 이 애플리케이션의 국제화(internationalization) 가능성에 대해 고려한다.
• 한계를 찾고 그 사이의 스트링 길이가 작동하는지 확인하기 위해 스크립트를 작성하거나 또는 스트링 길이를 수동으로 샘플링하는 방법(예: 2의 거듭제곱)에 대해 생각한다.
• 그 뒤에 있는 구현과 코드를 고려한다. 스트링을 한 문자씩 확인하는 카운터와 얼마나 많은 A와 마주쳤는지 추적하는 카운터(누산기)가 있을 수 있다. 따라서 흥미로운 경계 값을 중심으로 A의 총 수와 A가 포함된 스트링 길이, 이 둘 모두에 변화를 주면 재미있는 일이 생길 수 있다고 생각한다.
• “HTTP POST 메쏘드와 패러미터가 해킹될 수 있는가? 보안 취약점이 있는 것은 아닐까?” 라는 질문을 한다.
• 스트링 속성(예: 길이, A의 수 등)에 대한 흥미로운 순열과 조합을 만들기 위해 스크립트로 테스트 입력 및 검증(validation)을 생성한다.

 

후보자가 테스트 케이스로 사용하는 스트링 길이에 대한 문제를 파헤치다 보면 그들이 업무를 얼마나 잘 수행할 수 있는지에 대해 많은 것을 알 수 있다. 후보자가 자주 대답하는 "긴 스트링" 이라는 표현을 그들이 기술적으로 더 구체화할 수 없다면 이는 나쁜 징조이다. 좀 더 기술적인 후보자는 이 스트링에 대한 사양을 묻고 그 한계 주변으로 경계 값 테스트를 제공할 것이다. 예를 들어 한계가 1,000 글자이면 999, 1,000, 1,001을 시도한다. 최고의 후보자는 2^32와 그 사이에 있는 많은 흥미로운 값(예: 2와 10의 거듭제곱)을 시도할 것이다. 후보자가 그냥 무작위 숫자가 아니라 어떤 값이 중요한 지를 이해하고 있음을 보여주는 것이 중요하다(그들이 기저 알고리즘, 언어, 런타임, 하드웨어에 대해 어느 정도 이해하고 있을 필요가 있는 데, 여기가 결함이 가장 자주 발생하는 곳이기 때문이다). 그들이 또한 가능한 구현 세부 사항을 기반으로 한 스트링 길이를 시도하고, 카운터와 포인터 및 off-by-one 가능성에 대해 생각할 것이다. 가장 훌룡한 후보자들은 시스템이 상태를 가질 수 있으며, 테스트가 앞서 입력된 값을 고려해야 한다는 것을 깨닫는다. 따라서 동일한 스트링을 여러 번 시도하거나 1,000자 길이 스트링 다음에 길이가 0인 스트링을 시도하는 것이 중요한 케이스가 된다.

 

우리가 후보자 인터뷰에서 찾는 또 다른 주요 특징은 TE가 애매모호함(ambiguity)을 잘 처리하고 어리석은 아이디어는 되밀어내는 능력이 있는지 여부다. 후보자가 문제를 명확히 하기 위한 질문을 할 때 우리가 종종 명세(specifications)를 바꾸거나 또는 말이 안되는 동작을 명세로 지정한다. 그들이 이런 애매모호함을 어떻게 다루는가는 그들이 업무를 얼마나 잘 할 것인지에 대해 많은 것을 드러낼 수 있다. 구글에서는 명세가 종종 움직이는 타겟이며 릴리스 주기의 속도에 따라 그 해석 및 변경이 열려있다. 스트링 최대 길이가 5자인 것이 이상하고 사용자 불만 가능성이 높다고 지적하는 것은 후보자가 사용자를 염두에 두고 있음을 보여주는 훌륭한 지표이다. 맹목적으로 이것을 받아들이고 계속 나아가는 후보자들은 업무에서도 똑같이 할 것이고 어리석은 행동도 곧이곧대로 받아들일 것이다. 명세를 밀어 내치거나 의문을 던지는 후보자는 직무에서 종종 놀라운 일을 해낸다(이를 외교적 수완으로 할 수 있는 경우에).

 

TE 인터뷰의 마지막 부분은 우리가 "Googliness"라고 부르는 것을 탐색하는 과정이다. 우리는 들은 대로만 하는 것이 아니라 여러 옵션을 조사하고 직무 설명서의 지시 밖에 있는 일을 하는 호기심 많고 열정적인 엔지니어를 원한다. 책임진 직무를 완수해야 하지만, 삶과 일이 주변 세계에 최대의 영향을 미치는 것이어야 한다. 우리는 주변 세계와 그리고 더 큰 컴퓨터 과학 커뮤니티와 연결되어 있는 사람을 원한다. 오픈 소스 프로젝트에 버그를 신고하는 사람들이 그러한 예이고, 재사용을 위해 자신의 작업을 일반화/표준화하는 사람들이 또 다른 예이다. 우리는 함께 일하기가 즐겁고, 다른 사람들과 잘 어울리며, 여기 우리 문화에 가치를 더할 수 있는 사람을 고용하기 원한다. 우리는 계속해서 배우고 성장하고자 하는 엔지니어를 원한다. 우리는 또한 우리가 배울만한 것을 가진 사람(즉, 우리의 집단 인재 풀에 추가될 새로운 아이디어와 경험을 보유한 사람)을 원한다! 악을 행하지 말라(do no evil)'는 기업 모토처럼 악을 보면 비판의 목소리를 낼 수 있는 사람을 원한다!

 

큰 기술 회사에서 면접을 보는 것은 사람을 위축되게 한다. 우리도 같은 경험을 했기 때문에 이를 잘 알고 있다! 많은 사람들이 한 번에 통과하지 못하고 제대로 하기 위한 연습 라운드가 필요하기도 하다. 우리가 가혹하게 대하려는 게 아니라 회사에 기여할 수 있고 Google TE가 되었을 때 자신의 역할에서 성장할 수 있는 사람이 확실한지를 찾기 위해 애쓰는 것이다. 이것이 회사와 후보자 모두에게 좋은 일이어야 한다. 구글은, 숫자 상 큰 기업이지만 작은 회사 느낌을 유지하고자 하는 대부분 회사와 마찬가지로, 지나치다 싶을 정도로 신중한 경향이 있다. 우리는 구글이 앞으로도 계속 오랫동안 일하고 싶은 곳이 되기를 바라며, 적합한 사람을 고용하는 것은 이를 보장하는 가장 좋은 방법이다!