회사의 가장 중요한 소프트웨어가 갑자기 작동하지 않는다고 가정해 보겠습니다. 어떤 일이 일어날까요? 주문이 누락되고 기한을 놓칠 수 있지만 고객은 확실히 불만을 제기할 것입니다.
이러한 악몽 같은 시나리오는 혼란을 야기하기 전에 문제를 포착하는 지속적이고 엄격한 테스트 프로세스를 구현하여 피할 수 있습니다. 하지만 조직에서 이러한 프로세스를 구현하는 것은 말처럼 쉽지 않습니다.
이 도움말에서는 회사에서 테스트를 시작할 때 고려해야 할 모든 사항과 장기적으로 테스트를 통해 얻을 수 있는 이점을 설명합니다.
제품팀을 위한 테스트 권장사항
이 도움말의 첫 번째 부분에서는 워크플로에서 테스트를 구현하는 프로세스를 다룹니다.
팀에 테스트 문화 구현
팀에 테스트를 성공적으로 도입하려면 모든 사람이 공통된 사고방식을 공유하고 품질을 부담이 아닌 투자로 간주해야 합니다. 이는 다른 문화적 변화와 마찬가지로 시간과 일관성이 필요한 프로세스입니다.
이러한 문화를 형성하는 데 도움이 되는 한 가지 방법은 결함, 결함의 영향, 결함의 원인, 결함을 수정하는 데 필요한 사항을 논의하는 정기적인 회의입니다. 이렇게 하면 이러한 결함을 사전에 방지하는 것이 좋은 이유를 알 수 있습니다.
팀에 이러한 노력을 감독하고 추진하는 전담 직원이 있으면 성공 가능성이 크게 높아질 수 있습니다. 팀 또는 조직 전체 가이드라인을 정의하고, 권장사항을 수집하여 공유하며, 여러 수준에서 노력을 옹호하는 사람
제품의 지원 역할을 교체하는 것도 유용한 방법입니다. 고객으로부터 직접 필터링되지 않은 유용한 정보를 얻고 제품과 관련해 고객이 매일 겪는 문제를 파악하는 것은 제품 관리자, 디자이너, 개발자에게 유익한 경험이 될 수 있습니다.
목표는 팀의 모든 구성원이 품질이 제품을 위해 구축하는 다른 기능만큼 중요한 기능임을 이해하는 것입니다. 모두가 이러한 사고방식을 채택하면 테스트도 기능이라는 것을 자연스럽게 이해하게 됩니다. 테스트는 제공되는 품질을 보장하기 때문입니다.
단계별 테스트 프로세스
제품 개발에 참여하는 여러 팀 간에 의견이 일치하면 테스트의 존재와 사용을 더욱 공식화할 수 있습니다.
테스트를 '완료의 정의'에 포함
테스트를 기능 요구사항으로 추가하면 적절하고 자동으로 테스트될 때까지 기능이 출시 준비가 되지 않았음을 나타냅니다.
정기적으로 테스트 실행
구현되면 자동화된 테스트는 개발 프로세스의 모든 단계에서 보호 장치가 될 수 있습니다. 인적 개입이 필요하지 않으며 개발 파이프라인의 모든 중요한 단계에서 실행할 수 있습니다. 예를 들면 다음과 같습니다.
- 모든 커밋에서
- 모든 풀 요청에서
- 전체 출시 또는 환경 변경 후
프로덕션 환경에서 서드 파티 서비스를 사용하는 경우 서드 파티 API가 예상대로 작동하는지 확인하기 위해 프로덕션에 대해 테스트를 실행하는 것이 타당할 수도 있습니다.
측정항목 정의 및 수집
테스트의 효과와 테스트 워크플로가 비즈니스에 미치는 영향을 측정하려면 측정항목을 정의하는 것이 중요합니다. 사용할 수 있는 측정항목의 예는 다음과 같습니다.
- 월별 출시 수: 월별 출시 수가 많을수록 더 민첩한 개발 프로세스를 나타낼 수 있습니다. 자동 테스트는 출시를 자신 있게 진행할 수 있도록 지원하여 여기서 중요한 역할을 합니다.
- 버그 신고: 버그 신고가 감소하는 추세는 테스트 (및 개발 프로세스)가 효과적이라는 긍정적인 신호일 수 있습니다.
- 테스트 범위: 정확한 측정항목은 아니지만 범위는 중요한 사용 사례를 얼마나 깊이 테스트하는지 나타내는 좋은 지표가 될 수 있습니다.
이러한 측정항목은 다른 요인의 영향을 받아 왜곡될 수 있습니다. 예를 들어 연말연시에는 출시 횟수가 줄어들고 버그 신고가 늘어날 수 있습니다. 따라서 몇 개에만 의존하지 말고 팀에서 사용할 수 있는 다른 데이터와 교차 매핑해야 합니다.
팀과 함께 이러한 단계를 성공적으로 구현하면 장기적으로 제품 상태에 확실히 도움이 될 것입니다. 하지만 아직 할 수 있는 일이 더 있습니다.
시스템 관리자를 위한 테스트 권장사항
제품팀은 자체적으로 작업할 수 없습니다. 시스템 관리자가 유지관리하는 하드웨어, 도구, 인프라를 사용합니다. 시스템 관리자는 일반적으로 제품 개발에 직접 기여하지는 않지만 개발 워크플로에 긍정적인 영향을 줄 수 있습니다. 예를 들어 회사에서 특정 사용자 그룹이 사용하는 브라우저 버전을 적극적으로 관리합니다.
이 도움말의 두 번째 부분에서는 Chrome의 채널과 엔터프라이즈 정책을 사용하여 작동 방식을 설명합니다.
Chrome 출시 채널
기본적으로 Chrome은 모든 사용자가 최신 기능이 포함된 가장 안정적이고 안전한 버전의 Chrome(안정화 버전 채널에서 출시된 Chrome 버전)을 실행할 수 있도록 자동 업데이트됩니다.
웹 기반 제품을 개발하는 회사라면 제품팀이 웹 플랫폼의 변경사항에 제품을 적응시킬 시간을 주기 위해 안정화 채널보다 앞선 브라우저를 사용하고 싶을 수 있습니다.
이 사용 사례에서 Chrome은 다양한 사용자 그룹을 대상으로 총 4개의 출시 채널을 제공합니다.
Chrome의 경우 향후 브라우저 변경사항을 예측하고 최신 기능을 널리 제공되기 전에 테스트할 수 있는 다양한 출시 채널이 있습니다.
- 안정화 채널: 대부분의 사용자가 이 채널을 사용합니다. 안정화 버전 채널은 매달 발생하는 새로운 Chrome 출시가 있을 때 자동으로 업데이트됩니다.
- 베타 채널: 이 버전은 4~6주 후에 안정화되므로 곧 출시될 안정화 버전을 미리 보고 테스트하고 준비할 수 있습니다.
- 개발자 채널: 이 채널은 일주일에 한 번 새로운 버전의 Chrome을 제공하며, 결국 베타로 이동할 모든 최신 수정사항이 포함됩니다. 채널 이름에서 알 수 있듯이 개발 중이므로 예기치 않게 중단될 수 있지만 안정 버전보다 훨씬 전에 최신 기능이 포함되어 있습니다. 따라서 개발자 채널은 프로토타입 제작과 최첨단 개발에 유용한 도구입니다.
- Canary 채널: 가장 실험적인 채널로, 모든 최신 기능이 포함되어 있지만 테스트가 많이 이루어지지 않습니다. 매일 출시됩니다.
Chrome 채널에 대해 자세히 알아보려면 관련 Chrome 개념 에피소드를 확인하세요.
모범적인 조직에서 채널 사용
소프트웨어 개발에 있어 모든 조직에 적합한 접근 방식은 없으므로 제품팀의 구조는 조직마다 다릅니다. 예를 들어 제품 관리, UX 및 UI, 엔지니어링, 운영 및 지원이라는 역할을 가진 팀이 있다고 가정해 보겠습니다.
이러한 조직의 경우 다음과 같은 채널 분할을 고려할 수 있습니다.
- 제품 관리: PM은 대부분의 사용자와 동일한 버전을 사용하기 위해 일반적으로 안정화 채널을 사용할 수 있습니다. 아직 출시되지 않은 API가 필요한 기능을 작업하는 경우 베타 또는 개발자 채널을 사용할 수 있습니다.
- 엔지니어링 및 UX: 이러한 팀의 일부는 안정화되기 전에도 전환 보기와 같은 최신 기능에 액세스할 수 있도록 개발자 채널에 있을 수 있습니다.
- 운영: 다음에 사용자에게 영향을 미칠 수 있는 중단을 예측하기 위해 베타에 있을 수 있습니다.
- 지원: 대부분의 고객과 동일한 브라우저로 제품과 상호작용할 수 있도록 안정 채널을 유지할 수 있습니다.
엔터프라이즈 정책을 사용하여 채널 관리
가이드라인을 제공하고 사용할 채널에 관한 결정을 맡기는 대신 Chrome은 각 사용자가 사용하는 채널을 적극적으로 관리할 수 있는 엔터프라이즈 및 관리 도구도 제공합니다. 이렇게 하면 테스트 대상이 몇 명의 개별 사용자에서 결정적인 사용자 집합으로 즉시 늘어나므로 최대한 빨리 추적 가능한 방식으로 중단 문제를 식별하는 데 도움이 됩니다.
이 수준의 제어를 사용하려면 다음 구성을 사용하는 것이 좋습니다.
- 직원 (앱 사용자): 중단 위험을 최소화하기 위해 대부분의 직원은 Chrome 테스트팀에서 완전히 테스트한 안정 채널을 사용해야 합니다. 또한 소수의 사용자 (5~10%)가 베타 채널에 있을 수 있습니다. 이 채널에서는 안정화 버전의 미리보기를 4~6주 동안 제공하며, 관리자가 출시와 관련된 문제를 파악하여 모든 사용자에게 출시되기 전에 문제를 해결할 시간을 더 많이 가질 수 있습니다.
- IT 부서: 시스템 관리자를 비롯한 IT 부서 구성원은 베타 또는 개발자 채널을 통해 Chrome의 안정화 버전에 적용될 업데이트를 4~6주 또는 9~12주 전에 미리 볼 수 있습니다.
장기 출시 채널
제품 개발이 계획보다 느리게 진행될 수 있으며 Chrome의 월별 출시 주기가 너무 높을 수 있습니다. 이 사용 사례에서 Chrome은 기능 업데이트 빈도는 낮지만 보안 수정사항 업데이트가 계속 제공되는 확장 공개 버전 채널을 제공합니다. 이 채널은 8주마다 업데이트됩니다.
다음 다이어그램은 Chrome의 다양한 출시 채널을 통해 다양한 주요 버전이 진행되는 방식을 보여줍니다.
- 안정화 버전과 확장된 안정화 버전은 처음 4주 동안 동일한 버전을 제공하며, 그 후에는 두 버전이 달라집니다.
- 확장 베타 채널은 없습니다. 대신 표준 4주 베타 주기를 사용하여 안정화 버전과 확장 안정화 버전을 모두 안정화합니다. 8주 연장 안정화 버전을 선택한 기업은 환경에 영향을 미칠 수 있는 문제를 사전에 식별하기 위해 현재와 같이 베타 채널을 계속 실행해야 합니다.
확장 공개 버전 사용자를 위한 개발자 및 베타 채널의 지속적인 중요성
안정화 버전 채널이 2주 출시 주기로 가속화되고 조직에서 테스트 시간을 늘리기 위해 8주 확장 안정화 버전 주기를 채택하는 동안에도 개발자 및 베타 채널을 사용하는 것이 중요합니다. '연장 개발 또는 베타' 채널은 별도로 없습니다. 표준 개발 및 베타 채널은 안정화 버전과 연장 안정화 버전 출시를 모두 안정화하는 데 사용됩니다.
개발 채널과 베타 채널을 계속 실행하면 기업에서 환경에 영향을 미칠 수 있는 문제를 사전에 식별할 수 있습니다. 개발자 및 베타 채널에서는 곧 출시될 안정적인 버전을 4주 동안 미리 볼 수 있습니다. 확장 안정화 사용자의 경우 이 미리보기 창은 8주 기능 업데이트 전에 잠재적인 중단을 미리 발견하고 해결하는 데 필수적입니다.
개발자 및 베타 채널은 기본적으로 8주 연장된 안정적인 환경에 적용되는 변경사항에 대한 기본 조기 경보 시스템 역할을 하여 엔터프라이즈 앱의 호환성을 유지합니다. 시스템 관리자는 이점을 극대화하기 위해 개발자 및 베타 채널에 소규모의 결정론적 사용자 그룹 (예: 앱 사용자의 5~10%)을 계속 할당할 수 있습니다.
결론
테스트는 소프트웨어 개발 회사가 제품의 품질을 보장하는 데 중요한 부분이며, 시스템 관리자가 조직의 직원에게 고품질 소프트웨어에 대한 액세스 권한을 부여하고 비즈니스 프로세스를 중단하지 않도록 하는 데도 중요한 단계입니다.
조직 내에서 테스트 워크플로를 성공적으로 구현하려면 모든 사람이 품질이 기능이라는 공통된 사고방식을 공유하는 것이 중요합니다.
이 도움말에서는 조직에 테스트 권장사항을 통합하는 다양한 방법을 검토했습니다. 기존 테스트 도구에 대한 자세한 내용은 원활한 자동 테스트를 위한 Chrome 도구 도움말을 참고하세요.
테스트를 처음부터 끝까지 진행하는 실습 가이드는 최근 테스트 학습 과정과 web.dev의 테스트 자동화 권장사항을 참고하세요.