회사의 가장 중요한 소프트웨어가 갑자기 작동하지 않는다고 상상해 보세요. 어떤 일이 일어날까요? 주문이 누락되고 마감일을 놓칠 수 있지만 고객은 확실히 불만을 제기할 것입니다.
이 악몽 같은 시나리오는 혼란을 일으키기 전에 문제를 포착하는 지속적이고 엄격한 테스트 프로세스를 구현하여 피할 수 있습니다. 하지만 조직에서 이러한 프로세스를 구현하는 것은 말처럼 쉽지 않습니다.
이 문서에서는 회사에서 테스트를 시작할 때 고려해야 할 모든 사항과 장기적으로 테스트를 통해 얻을 수 있는 이점을 보여줍니다.
제품팀을 위한 테스트 권장사항
이 문서의 첫 번째 부분에서는 워크플로에서 테스트를 구현하기 시작하는 프로세스를 다룹니다.
팀에 테스트 문화 구현
팀에 테스트를 성공적으로 도입하려면 모든 사람이 공통된 사고방식을 공유하고 품질을 부담이 아닌 투자로 간주해야 합니다. 이는 다른 문화적 변화와 마찬가지로 시간과 일관성이 필요한 프로세스입니다.
이러한 문화를 형성하는 데 도움이 될 수 있는 한 가지 방법은 결함, 결함의 영향, 결함의 원인, 결함을 수정하는 데 필요한 사항을 논의하기 위해 정기적으로 회의를 여는 것입니다. 이렇게 하면 이러한 결함을 사전에 방지하는 것이 좋은 이유를 인식하는 데 도움이 됩니다.
팀에서 이러한 노력을 감독하고 추진하는 전담 담당자를 두면 성공 가능성을 크게 높일 수 있습니다. 팀 또는 조직 전체의 가이드라인을 정의하고, 권장사항을 수집하고 공유하며, 모든 수준에서 이러한 노력을 옹호하는 담당자가 필요합니다.
또 다른 유용한 방법은 제품의 지원 역할을 교대로 맡는 것입니다. 고객으로부터 직접 필터링되지 않은 통찰력을 얻고 제품과 관련하여 고객이 매일 겪는 문제를 파악하는 것은 제품 관리자, 디자이너, 개발자에게 유용한 경험이 될 수 있습니다.
목표는 팀의 모든 구성원이 품질이 제품을 위해 빌드하는 다른 기능만큼 중요한 기능임을 이해하는 것입니다. 모든 사람이 이러한 사고방식을 채택하면 테스트도 기능이라는 것을 자연스럽게 이해하게 됩니다. 테스트는 제공되는 품질을 보장하기 때문입니다.
단계별 테스트 프로세스
제품 개발에 참여하는 여러 팀 간에 조정이 이루어지면 테스트의 존재와 사용을 더욱 공식화할 수 있습니다.
테스트를 '완료 정의'에 포함
테스트를 기능 요구사항으로 추가하면 기능이 적절하게 자동으로 테스트될 때까지 제공할 준비가 되지 않았음을 명시합니다.
정기적으로 테스트 실행
자동화된 테스트는 구현되면 개발 프로세스의 모든 단계에서 보호 장치가 될 수 있습니다. 사용자의 개입이 필요하지 않으며 개발 파이프라인의 모든 중요한 단계에서 실행할 수 있습니다. 예를 들면 다음과 같습니다.
- 모든 커밋에서.
- 모든 pull 요청에서.
- 모든 전체 출시 또는 환경 변경 후.
프로덕션 환경에서 서드 파티 서비스를 사용하는 경우 서드 파티 API가 예상대로 동작하는지 확인하기 위해 프로덕션에 대해 테스트를 실행하는 것이 좋습니다.
측정항목 정의 및 수집
테스트의 효과와 테스트 워크플로가 비즈니스에 미치는 영향을 측정하려면 측정항목 집합을 정의하는 것이 중요합니다. 다음은 사용할 수 있는 측정항목의 몇 가지 예입니다.
- 월별 출시 수: 월별 출시 수가 많을수록 더 애자일한 개발 프로세스를 나타낼 수 있습니다. 자동화된 테스트는 출시를 자신 있게 진행할 수 있도록 보장함으로써 여기서 중요한 역할을 합니다.
- 버그 신고: 버그 신고가 감소하는 추세는 테스트 (및 개발 프로세스)가 효과적이라는 긍정적인 신호 일 수 있습니다.
- 테스트 범위: 정확한 측정항목은 아니지만 범위는 중요한 사용 사례를 얼마나 심층적으로 테스트하는지 나타내는 좋은 지표가 될 수 있습니다.
이러한 측정항목은 측정항목을 왜곡할 수 있는 다른 요인의 영향도 받습니다. 예를 들어 연말연시에는 출시 수가 감소하고 버그 신고가 증가할 수 있습니다. 따라서 몇 가지에만 의존하지 말고 팀에서 사용할 수 있는 다른 데이터와 교차 매핑해야 합니다.
팀에서 이러한 단계를 성공적으로 구현하면 장기적으로 제품 상태에 확실히 도움이 될 것입니다. 하지만 아직 할 수 있는 일이 더 있습니다.
시스템 관리자를 위한 테스트 권장사항
제품팀은 자체적으로 작업할 수 없습니다. 시스템 관리자가 유지관리하는 하드웨어, 도구, 인프라에 의존합니다. 시스템 관리자는 일반적으로 제품 개발에 직접 기여하지 않지만 개발 워크플로에 긍정적인 영향을 미칠 수 있습니다. 예를 들어 회사에서 특정 사용자 그룹이 사용하는 브라우저 버전을 적극적으로 관리하는 것입니다.
이 도움말의 두 번째 부분에서는 Chrome의 출시 채널 과 엔터프라이즈 정책을 사용하여 이 기능이 어떻게 작동하는지 설명합니다.
Chrome 출시 채널
출시 채널은 공개 버전, 베타, 개발자, Canary의 4가지가 있습니다.
자세한 내용은 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%)을 계속 할당할 수 있습니다.
결론
테스트는 제품의 품질을 보장하는 소프트웨어 개발 회사의 중요한 부분이며, 시스템 관리자가 조직의 직원에게 고품질 소프트웨어에 대한 액세스 권한을 부여하고 비즈니스 프로세스를 중단하지 않도록 하는 중요한 단계이기도 합니다.
조직 내에서 테스트 워크플로를 구현할 때 성공하려면 모든 사람이 품질과 테스트가 기능이라는 공통된 사고방식을 공유하는 것이 중요합니다.
테스트 시작부터 끝까지의 안내는 최근의 테스트 학습 과정과 자동화 테스트 권장사항 도 web.dev에서 참고하세요.