페이스북 문화 소개 그리고 QA

페이스북 문화 소개 및 성장

발표자: 이은창 Facebook 8년 → Sendbird [Head of Engineering]

https://www.youtube.com/watch?v=rFh21zGLqfw&feature=youtu.be&ab_channel=EO이오

영상 TL;DR 은 아래 접은글, 하지만 보시는걸 추천합니다

- 할 수 있는것 이상을 하기 위해서 설치고 깨져보자

- 성장을 계속 optimize 하는 방법은 해보지 않았던 경험에 자신을 밀어넣으면서 성장하는 것
- 부트캠프 8~10주 다양한 태스크를 진행하며 엔지니어는 팀 쇼핑을하고 매니저들은 엔지니어를 찾는 과정이 있었다.
- 어디가 막혔는지 파악하고 동료/Public Forum 에 공유하는것은 중요한 Skill Set이자 성장하는데 better path 다.
- Mave Fast & Break Things, Done is better than perfect, Fail fast & iterate tasks
- 시니어 엔지니어로서 성장 혹은 Manager로서의 성장 중 고민해보자 (어떤게 보람있는지)
- 정말 어려운 Technical Challenge 를 도전하는데 보람을 느끼는지
- Feedback, Struggling 하는 사람에 도움을 주는지 (하지만 매니저는 직설적으로 이야기하기보다 말하는 방법이 주니어 혹은 누군가에게 다르게 받아들여지는 부분이라는점을 중요하게 생각하자 Peception !== Intention)
- 매니저로서 해고를 하는건 정말 힘들다. 누군가 퍼포먼스를 잘 못내고 있다면 피드백을 충분히주자. 누구든 삽질한적은 있다. 기회를 주자. 성공적으로 남을 수 있는 환경을 제공해주자.
- 어떤 팀, 조직이건 회사가 거쳐가는 단계, 그리고 회사의 구성원들의 강점과 약점에 따라 조직과 팀에 필요한것이 다르다.

페이스북에서 일한 이야기가 흥미로워 어떤 회사인지 조직 문화를 찾아보다 QA에 관해 조사해보게 되었습니다.

 

Meta

• Facebook - SNS, 뉴스 피드, 페이지, 그룹, 마켓플레이스, 이벤트, 페이스북 라이브, 메신저
• Instagram - 사진, 영상 공유, 피드, 스토리, Explore, 인스타그램 TV, 쇼핑
• Whatsapp - 메신저, End-to-End Encryption, GroupsStatus
• 비지니스 - Business Suite, Ads Manager, Pages, Instagram Business Tools
• Tech - React, Redux, GraphQL, Pytorch, Flow, Jest, Buck, Hack, BuckleScript, Hermes, Litho

페이스북이라고 하면 너무 작은 SNS 같지만 실제로 꽤 많은 서비스를 담당하고 있습니다.

 

QA 문화

Facebook에는 테스터가 없으며 특히 고품질 소프트웨어를 생산할 필요가 없습니다. (2012)

Facebook에는 QA를 전담하거나 QA를 주요 업무로 수행하는 직원이 없었습니다. 테스트 코드 라인이나 테스트를 실행하는 데 걸리는 시간에 따라 측정하면 Facebook에 엄청난 양의 자동 테스트가 있지만 범위와 적용 범위 측면에서 Facebook의 자동 테스트 양이 제한적임을 언급했습니다.

"전반적으로 특히 고품질 소프트웨어를 생산할 필요가 없기 때문에" 테스터가 없는 것이 부분적으로 Facebook에 적합하다고 말하면서 대답하였습니다. 그는 Facebook에 많은 버그, 손상된 기능 및 UI 결함이 있다고 말합니다. "고품질" 소프트웨어에 대한 그의 정의는 이러한 것들이 거의 없는 코드이며 예를 들어 Apple, Amazon 및 Google과 같은 회사의 소프트웨어가 포함된다고 말합니다.

• 회사의 모든 사람이 항상 소프트웨어를 사용하고 코드베이스의 시험판 버전에서 발견한 버그를 보고하는 도구가 있습니다.
• 집계된 오류 로그는 로깅 코드 또는 언어 기능(예: 존재하지 않는 메서드 호출)으로 식별되는 문제가 프로덕션에서 대규모로 발생하는 경우 표시됩니다.
• 집계된 사용자 보고서 및 워크플로우 성공 그래프(예: 지난 주에 전송된 메시지 수와 지난 주 이 시간에 전송된 메시지 수)는 사용자 기반의 상당 부분에서 기능이 완전히 중단된 시기를 보여줍니다.
• Facebook 플랫폼의 주요 클라이언트는 그들의 비즈니스가 Facebook에 의존하기 때문에 사실상 Facebook에 대한 QA를 수행해야 하므로 플랫폼 문제를 보고합니다(beta.facebook.com을 통해 화요일 릴리스 24시간 전에 새 코드에 액세스할 수 있음 ) .
• 품질에 대한 관심을 줄임으로써 Facebook은 회사를 재능 있는 엔지니어를 유치하고 유지할 수 있는 재미있는 일터로 만드는 것과 같은 다른 일에 집중할 수 있었습니다. 품질에 더 신경을 쓴다면 페이스북은 아마도 재미가 덜할 것입니다.
• Facebook의 제품은 웹사이트이므로 신속하게 문제를 해결할 수 있습니다. 새 코드의 신속한 배포와 버그가 있는 변경 사항의 신속한 롤백을 허용하는 프로세스가 있습니다. 이렇게 하면 버그 복구 비용이 줄어듭니다.
• Facebook의 제품에는 많은 추진력과 잠금 기능이 있습니다. 사용자나 기업이 Facebook을 떠나는 장벽은 매우 높습니다. 이로 인해 Facebook은 결함이 있는 소프트웨어를 출시할 때 더 넓은 오류 마진을 갖게 됩니다. Google이 하루 동안 중단된 경우 Bing으로 이동하고 돌아오지 않을 수 있습니다. 당신의 아이폰이 항상 당신을 화나게 한다면 당신은 아마도 1~2년 후에 결정에 직면했을 때 안드로이드를 살 것입니다. 아마존에서 주문할 수 없는 경우 다른 곳에서 주문할 수 있습니다. Facebook이 고장 나면 다시 작동할 때까지 계속 돌아옵니다.
• 기업의 경우에는 더욱 그렇다. Facebook 플랫폼은 작년에 더 좋아졌지만 아주 오랫동안 개발하는 것은 꽤 끔찍했습니다. 그러나 옵션이 없습니다. 분명히 Zynga 수익의 94%는 Facebook에서 나옵니다 . 플랫폼 개발자는 실제로 Facebook에 책임을 물을 수단이 없습니다.

개발 중심 접근법

Facebook은 개발자가 자신의 코드를 테스트하고 서로의 코드도 테스트하도록 하여 개발자를 통과하는 버그의 수를 줄이려고 합니다. 개발자가 작업에 더 주의를 기울이겠지만 이 방법은 코드를 검토하는 신선하고 편견 없는 눈의 이점이 부족합니다.

 

도그푸딩 기술

Facebook의 테스트 전략 중 또 다른 하나는 모든 직원이 애플리케이션을 사용하도록 하여 dogfood하는 것입니다. 또한 발견한 버그를 보고하는 데 필요한 도구도 제공됩니다. 따라서 이 시나리오에서는 거의 모든 직원이 테스터이지만 차이점은 테스트만으로는 주요 작업이 아니라는 것입니다. 마찬가지로 QA에 더 집중하는 직원은 거의 없지만 그것만으로는 그들의 목적이 아닙니다.

 

Canary 릴리스 (A/B 테스트 활용 혹은 K8S)

Facebook은 변경 사항을 전체 기반에 직접 배포하지 않습니다. 대신 처음에는 직원에게 Canary 릴리스를 제공합니다. 보고된 문제가 없으면 전 세계적으로 출시되기 전에 소규모 실제 사용자 그룹에게 출시됩니다. Facebook의 다양한 클라이언트도 플랫폼에 대한 서비스 의존도가 높기 때문에 QA 활동을 수행합니다. 클라이언트는 출시 24시간 전에 beta.facebook.com을 방문하여 베타 버전에 액세스할 수 있습니다.

 

버그 바운티 프로그램

Facebook의 테스트 전략의 일환으로 2011년부터 버그 바운티 프로그램을 운영하고 있습니다. 이는 기존 테스트를 통과할 수 있는 주요 문제를 발견하는 방법으로 사용됩니다. 상금은 발견된 문제의 심각도 및 영향 수준에 따라 계산됩니다. 버그 바운티 프로그램 10주년을 맞아 Facebook은 우승자에게 198만 달러 이상의 상금을 수여했다고 발표했습니다. 전직 Facebook 직원에 따르면 전직 직원이 발견한 문제를 보고할 수 있는 특권 채널도 몇 개 있습니다. 직원은 또한 매달 약 13,000개의 버그를 보고한다고 주장했습니다.

 

사용자 데이터

더 큰 사용자 기반으로 인해 Facebook은 새로 배포된 변경 사항의 성능을 모니터링하기 위해 마음대로 사용할 수 있는 많은 양의 데이터를 보유하고 있습니다. Facebook은 성공을 분석하기 위해 사용자 보고서와 워크플로 성공률을 집계했습니다. 또한 이전 주 대비 이번 주 이 시간 동안 전송된 메시지 수와 같은 데이터를 사용하여 기존 사용자를 확인합니다.

 

또 다른 기업

Uber

Uber는 빠르게 확장해야 하는 대규모 스타트업입니다. 병목 현상을 일으키는 경향이 있는 별도의 QA 팀이나 수동 테스터에 의존할 수 없습니다. 품질 보증 프로세스가 없다는 의미는 아닙니다. 그것은 단지 다른 것입니다.

Uber는 Google이나 Amazon을 바라보는 것과 유사한 엔지니어 문화를 만들고 있습니다. 개발자는 코드를 테스트하고 고품질 소프트웨어를 제공해야 합니다. 그들은 많은 단위 및 통합 테스트를 작성하고 버그를 방지하기 위해 다양한 시나리오를 다룹니다.

 

Yahoo

야후의 수석 아키텍트인 아모츠 마이몬(Amotz Maimon)과 과학 및 기술 담당 수석 부사장인 제이 로시터(Jay Rossiter)에 따르면 적어도 야후의 경험은 그랬다. 2013년 개발 프로세스의 작은 변화와 2014년 중반부터 2015년 1분기까지 더 큰 추진력을 얻은 후 Yahoo의 소프트웨어 엔지니어링은 큰 변화를 겪었습니다. 이러한 노력은 Yahoo가 Warp Drive라고 부르는 프로그램의 일부였습니다. 코드의 일괄 릴리스에서 지속적인 전달 시스템으로의 전환입니다. Yahoo의 소프트웨어 엔지니어는 더 이상 교차 확인을 위해 완성된 코드를 다른 팀에 전달할 수 없습니다. 대신 코드는 있는 그대로 실행됩니다. 문제가 있으면 시스템이 실패하고 종료되어 야후 고객에게 직접적인 영향을 미칩니다.

Rossiter는 "이렇게 함으로써 엔지니어가 문제에 대해 생각하는 방식에 패러다임 변화가 일어났습니다."라고 말했습니다.

그는 또한 엔지니어가 이전에 인간 팀이 처리했던 종류의 검사를 자동화하는 도구를 개발하도록 강요했다고 말했습니다. 엔지니어는 코드를 한 번 확인하는 힘든 과정을 거칠 수 있지만 그런 다음 해당 과정을 자동화하는 도구를 구축하기 시작합니다.

 

Microsoft

SDET 역할은 공식적으로 9년 전에 Microsoft에서 사라졌습니다. 모든 QA 역할/작업에 대해 동일합니다.

클라우드의 등장과 회사가 Agile 개발 방법론으로 전환하도록 방향을 바꾸면서 회사는 DevOps로의 전환과 함께 역할을 합리화해야 했습니다. IT Infra, 개발자, QA 등 모든 역할이 재정렬되어야 했습니다. 무슨 일이에요. 이제 사람들이 혼자 작업하고 독립적인 작업을 수행하는 대신 코드를 작성하는 Dev 팀도 자체 코드를 테스트하고 프로덕션 시스템에 푸시합니다.

이는 부풀림을 어느 정도 제거하지만 조직이 운영을 합리화하고 P&L 균형을 유지하며 사람들이 새로운 업무 방식에 적응할 수 있는 올바른 기술을 보유하고 있는지 확인할 수 있는 기회를 제공합니다.

Would Microsoft really cut its QA department?

Would Microsoft really cut its QA department?

 

Amazon

2014년 10월에 저는 매우 힘든 인터뷰 과정을 거쳐 Amazon에서 소프트웨어 품질 보증 엔지니어로 채용되었습니다. 여러 페이지를 통한 반복적인 UI 클릭과 함께 풍부한 UI 상호 작용을 포함하는 일부 웹 애플리케이션에서 웹 서비스 수준에서 모든 비즈니스 로직 테스트를 다루어 테스트를 흥미롭게 만들었습니다. 기능 설계가 완료되면 테스트 전략 및 계획을 시작합니다. 나는 주기가 끝날 때 소프트웨어 릴리스를 단순히 통제하는 양질의 경찰이나 문지기 역할을 하지 않습니다. 저는 개발자와 협력하고 변경/구현을 이해하며 이에 따라 테스트 전략을 수립합니다. 이렇게 하면 회귀에 불필요하게 소요되는 시간을 줄일 수 있습니다. 나는 테스트 자동화 피라미드를 신뢰하고 부서지기 쉽고 유지 관리할 수 없는 UI 대신 서비스 계층을 자동화하는 데 집중합니다.

 

Google

Google에는 품질 보증(QA) 부서가 있습니다. 검색 알고리즘과 같은 제품의 기능과 유용성을 테스트하여 회사의 표준과 사용자 기대치를 충족하는지 확인하여 품질 보증을 처리합니다. 또한 자동화된 테스트 도구를 사용하고 사용자 조사를 수행하여 제품에 대한 피드백을 수집할 수도 있습니다.

 

Why Facebook doesn't have or need testers

https://blog.testproject.io/2022/06/21/tips-to-work-if-you-are-the-only-qa-of-the-team/