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