CI/CD가 녹색으로 통과되더라도 앱이 깨진 채로 배포될 수 있습니다. 빌드가 통과되고 QA가 승인하고 릴리스가 나가고, 첫 번째 실제 사용자가 권한 프롬프트가 반환되지 않는 것,陈舊한 자바스크립트 번들, 또는 하나의 안드로이드 스킨에서만 나타나는 충돌을 만나게 됩니다. 대부분의 품질 보증 과정 지침은 이 부분을 생략하고, 모바일 팀은 일반적으로 어려운 방법으로 배운다는 것입니다.
실용적인 품질 보증 과정 품질 보증 과정은 완전한 루프이며, 단지 결함을 로깅하는 단순한 체크리스트가 아니다. 요구 사항과 테스트 설계로 시작하지만, 발견된 결과가 릴리즈 결정, 모니터링, 롤백, 다음 테스트 라운드에 반영될 때만 유용해진다. CapacitorJS 또는 Electron 앱을 배포하는 경우, 하나의 잘못된 웹 번들만으로도 모든 사용자가 동시에 영향을 받을 수 있으며, 네이티브 리뷰는 영구적인 수정을 늦추기 때문이다.
목차
- 현대 품질 보증 과정은 실제로 무엇을 포함하는가
- 목표, 범위, 테스트 가능한 수락 기준 정의
- 자동화된 테스트와 수동 테스트의 올바른 혼합을 선택하는 방법
- CI/CD pipeline에 QA를 통합하는 방법
- 스테이징, 캐니발, 및 phased 롤아웃을 위한 추측 없이
- 사용자가 문제를 보고하기 전에 문제를 잡아내는 관찰성 및 메트릭
- 사고 복구, 롤백 및 올바른 교훈을 얻기
현대 품질 보증 프로세스가 실제로 무엇을 포함하는지
현대 품질 보증 품질 보증 프로세스는 명확한 제어점이 있는 닫힌 루프이다. 실제 순서는 요구 사항 분석, 테스트 계획, 테스트 설계 및 케이스 개발, 환경 설정, 실행, 결함 추적, 재 테스트 및 회귀, 릴리스 검증 및 테스트 종료이다.. 가장 중요한 제어는 여전히 지루한 것들이다. 요구 사항에서 테스트까지의 추적 가능성 및 공식적인 버그 분류 및 검증 루프이유는, 수정 사항이 닫기 전에 검증되지 않으면 카운트되지 않기 때문입니다. 닫기 전에 검증되지 않은 수정 사항은 카운트되지 않습니다. TestSigma에서 설명한 QA 프로세스 가이드.
릴리스가 끝나면 루프가 멈추지 않습니다.
품질 보증이 릴리스 후보가 녹색이 될 때 끝나지 않는다는 것을 기억하세요. 그것은 프로덕션 검증, 지원 신호, 라이브 업데이트 복구, 그리고 다음 스프린트의 테스트 디자인을 통해 계속됩니다. 많은 팀이 버그를 티켓으로 대신하여, 요구 사항, 테스트, 또는 배포 경계를 변경해야 하는 증거로 인식하지 못하는 이유입니다.
품질 보증을 관리 시스템으로 생각하는 유용한 방법입니다. 품질 보증 프로세스 단계 품질 보증 프로세스 가이드는 많은 프로그램이 고객 피드백 루프와 다중 채널 평가를 놓치고, 그 격차가 앱 팀에도 중요하다는 점을 지적합니다. 지원이 릴리스 후 동일한 불만을 계속 보고한다면, 프로세스는 배웠지 않습니다. 단지 측정한 것입니다.
도구를 추가하기 전에 측정할 내용
도구를 구매하기 전에 팀이 빌드를 안전한지 결정하기 위해 사용할 신호에 대한 명확성을 얻으세요. 일반적으로 릴리스 게이트, 각 게이트의 소유자, 그리고 롤백 기준을 정의해야 합니다. 롤백 기준이 게이트를 통과하지 못한 경우에 적용됩니다.
실용적인 시작 세트는 간단합니다.
- 요구 사항 커버리지사용자에게 보이는 규칙이 최소한 하나의 테스트를 가지고 있는지 여부를 보여줍니다.
- 결함 심각도 및 소유권팀이 릴리즈를 막고誰가 해결하는지 알 수 있도록합니다.
- 회귀 범위fixes가 인접한 흐름에서 이전 문제를 다시 열지 않도록fixes가 인접한 흐름에서 이전 문제를 다시 열지 않도록합니다.
- 릴리즈 후 신호생산 피드백이 다음 테스트 사이클을 변경하는 대신 대시보드에 살아남지 않도록합니다.
인접한 운영 프로세스의 수동 재작업을 줄이기 위해 노력하는 팀에게, 도자 labor 비용 감소 가이드 구조화된 검토와 명확한 전달이 낭비된 노력을 줄일 수 있는 예시입니다. QA도 마찬가지로, 루프가 명확할 때 사람들은 추측하지 않습니다.
현재 프로세스가 실패한 것을만 알려주면, 다음 변경 사항을 알려주지 않는다면, 그것은 완전하지 않습니다. 테스트 루틴과 실제 품질 시스템의 차이입니다. 릴리즈 관리 관점이 그 마음가짐에 맞는 내부 가이드에 대해 릴리스 관리 프로세스 같은 폐쇄 루프 접근 방식과 잘 어울립니다.
목표, 범위, 테스트 가능한 수락 기준 정의
QA가 더 선명해지면 제품 언어가 테스트 가능한 언어로 변환될 때입니다. '체크아웃이 빠르도록 하세요'라는 요구 사항은 깨끗하게 검증할 수 없지만 '제공자가 성공을 반환하고 사용자가 앱을 닫기 전에 결제 확인 화면을 표시하세요'라는 요구 사항은 테스트할 수, 추적할 수, 개발자와 지원 팀 모두에게 유용합니다. 이 추적 가능성은 이전 섹션에서 설명한 폐쇄 루프 모델의 핵심 제어점 중 하나입니다.
수락 기준을 테스터가 실행할 수 있는 방식으로 작성하세요.
CapacitorJS 앱의 경우, 결제 흐름을 고려하세요. 앱이 세 번째 결제 시트를 사용하는 경우, 수락 기준은 시트가 성공, 실패, 타임아웃, 또는 취소될 때 발생하는 것을 포함해야 합니다. 흐름이 카메라 권한, 위치 권한, 또는 푸시 알림 동의에 의존하는 경우, 각 branch는 iOS와 Android에서 권한 프롬프트가 다르게 동작할 수 있기 때문에 각 branch에 대한 명확한 결과를 포함해야 합니다.
가볍고 가볍게 사용하는 템플릿이 잘 작동합니다:
- 주어 사용자는 인증되었습니다.
- 조건 사용자가 결제 버튼을 탭했습니다.
- 결과 앱은 결제 UI를 제공하고 성공 여부를 확인하거나 회복 가능한 오류 상태를 표시합니다.
- 그리고 이벤트는 릴리스 티켓으로 추적되므로 QA는 실패를 요구 사항으로 맵핑할 수 있습니다.
포인트는 모든 문장을 공식적으로 만들지 않아야 한다는 것이 아니라, 특정 기능이 성공했는지 여부를 인간이 판단할 수 있도록 하자는 것입니다. 그 후에 의도에 대해 논쟁하는 것을 피하기 위해서입니다. 그 것도 내부 체크리스트가 __CAPGO_KEEP_0__ 앱 업데이트를 검증하는 데 유용해지는데, 업데이트를 검증하는 과정에서 누락된 수락 기준이 드러날 수 있기 때문입니다. validating Capacitor app updates 정의된 릴리스는 모호한 릴리스보다 더 쉽게 방어할 수 있습니다. 고위험 표면은 더 광범위한 검사를 deserve합니다. 반면, 저위험 복사본 변경 또는 고립된 UI 조정은 작은 의존성 표면이 있는 경우 가벼운 검사를 수행할 수 있습니다. 실제로, 인증, 결제, 권한, 오프라인 동작 또는 네이티브 브리지를 조정하는 경우 더 깊은 검사를 수행해야 합니다.
실용적인 규칙:
기본적인 사용을 차단하는 방식으로 기능이 실패할 수 있다면, 명시적인 수락 기준과 최소한의 단위 검증 경로가 필요합니다.
단위 또는 통합 테스트로 잘 수행되지 않는 기능은 무시하지 마십시오. 다른 층이 필요합니다. 종종 수동 패스, 장치별 검사 또는 릴리스 단계 검증 단계가 필요합니다. 특히, Electron 앱은 OS 수준 대화, 파일 접근 또는 브라우저 고유한 특성에 의존하기 때문에 컴포넌트 테스트가 충실하게 모델링되지 않습니다. validating __CAPGO_KEEP_0__ app updates
Scope the release by risk, not by optimism
만약 범위가 정확하다면 QA가 마지막 순간의 논쟁으로 느껴지지 않는다. 팀은 증명해야 할 것이 무엇인지, 샘플링할 수 있는 것이 무엇인지, 그리고 자동화 경계가 끝나는 곳에서 인간의 눈으로 확인해야 할 것이 무엇인지 알게 된다.
적절한 자동화와 수동 테스트의 혼합을 선택하는 방법
자동화가 주목을 받는 이유는 확장성이 있기 때문이다. 그러나 모델링할 수 있는 것만 잡을 수 있다. 수동 테스트는 느리다고 여겨지지만, 시각적 드리프트, 장치별 문제, 또는 사용자가 앱을 사용할 때 발생하는 워크플로의 이상함을 잡는 유일한 방법이 될 수 있다. 균형 잡힌 품질 보증 프로세스 품질 보증 프로세스는 자동화와 수동 테스트의 균형이 필요하다. 그 균형은 위험에 따라야 하며, 이념에 따라서는 아니야.
각 층이 가장 잘할 수 있는 일
단위 및 통합 테스트는 논리가 결정론적일 때 가장 강하다. CapacitorJS 또는 Electron 스택에서 말하면, Jest는 비즈니스 로직, 상태 리듀서, 헬퍼, 컴포넌트 동작, 그리고 API 경계, 업데이트 파싱, 및 권한 처리 branch에 대한 통합 테스트를 위해 적합하다. Cypress는 웹层의 브라우저 주도 종단 간 테스트를 원할 때 잘 맞는다. Detox-style 흐름은 유지보수 비용을 감수할 수 있는 장치 수준의 모바일 상호 작용이 필요할 때 중요하다.
수동 테스트는 상황에 맞는 곳에서 자리를 차지합니다. 탐색적 세션은 이상한 네비게이션 경로, 다크 모드 불일치, 작은 장치에서 키보드 겹침, 또는 OS 버전 하나에서 너무 sớm로 닫히는 모달을 잡을 수 있습니다. 또한 접근성에 중요합니다. 스크린 리더 순서, 포커스 트랩, CONTRAST 문제는 일반적으로 정적 검사만 믿고 시도하지 않으면 발견하기 더 쉬운 경우가 많습니다.
만약 더 광범위한 자동화 카테고리와 트레이드 오프를 원한다면 Appjet.ai의 테스트 도구는 자동화된 테스트 개요 는 스택을 표준화하는 팀에게 유용한 비교 지점입니다. 자동화된 테스트와 수동 테스트
시나리오
| 최적의 선택 | 왜 | 공유 모듈 내의 순수 비즈니스 논리 |
|---|---|---|
| 자동화 | 시나리오 | 빠른 피드백, 안정적인 입력, 쉽게 반복 |
| 결제 제공자 callback 처리 | 자동화 및 수동 | 논리는 스크립트화 될 수 있지만 사용자 경험은 인간의 검증이 필요하다 |
| iOS 및 Android에서 권한提示 | 수동 우선 | OS 동작 및 장치 상태가 흐름을 변경할 수 있다 |
| 설정 화면의 시각적 회귀 테스트 | 수동 및 시각 도구 | 실제 통과 시 레이아웃 버그를 더 쉽게 발견할 수 있다 |
| 오프라인 동기화 및 재연결 동작 | 자동화 및 장치 테스트 | 시간, 재시도, 및 상태 복구가 반복 가능한 테스트 커버리지가 필요합니다. |
| 새 기능 플래그에 대한 베타 피드백 | 수동 | 컨텍스트: Capgo 솔루션 마케팅 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보이는 곳: 페이지 솔루션/프리뷰.아스트로. 메시지 키 `solutions_pr_compare_cleanup_tf` (Solutions Pr Compare Cleanup Tf). |
실제 세계의 동작이 테스트에서 놓친 부분을 드러내는 경우가 많습니다.
외부 베타 테스터의 도움을 받는 곳
외부 베타 테스터는 내부 팀이 너무 많은 공유 컨텍스트를 가지고 있을 때 유용합니다. 그들은 당신의 가정들을 재현하지 않습니다. 그게 목적입니다. 그들은 특히 온보딩, 첫 번째 실행 권한, 또는 익숙하지 않은 사용자 동작에 의존하는 흐름을 터치하는 릴리스 후보에 특히 효과적입니다.
오버 인덱싱의 함정은 어느 쪽에도 지나치게 집중하는 것입니다. 자동화 테스트 계획이 모두 자동화라면 인간의 민감성을 놓치게 됩니다. 수동 테스트 계획이 모두 수동이라면 비용이 많이 들고, 일관성이 없으며, 마감일이 촉박해지면 쉽게 생략할 수 있습니다. 올바른 답은 일반적으로 안정적인 자동화 기반에 의한 인간의 커버리지가 의도적으로 표면에 적용된 경우입니다.
CI/CD pipeline에 QA를 통합하는 방법 CI/CD는 품질을 강제해야 합니다. 단순히 아티팩트를 이동하는 것이 아닙니다. pipe line이 가장 잘 작동하는 경우 각 단계가 단일 작업을 수행할 때입니다. 혼합된 관심사로 인해 실패가 더 어려운 것을 이해하고, 더 느린 것을 고치는 것입니다. 좋은 품질 보증 프로세스는 나쁜 __CAPGO_KEEP_0__를 막는 곳에 체크를 두고, 동일한 아티팩트를 릴리스까지 이동하는 동안 보존합니다. places checks where they block bad code early, then preserves the same artifact as it moves toward release.
빠른 검사 항목을 먼저 넣으세요
모든 커밋마다, 빠르고 결정적인 검사 항목을 실행하세요. lint, 타입 검사, 단위 테스트 및 집중된 통합 테스트는 anyone이 네이티브 바이너리를 빌드하기 전에 실패해야 합니다. 그럼으로 noise가 낮아지고 다음 단계인 빌드가 컴퓨팅 비용을 가치 있게 만듭니다.
code 변경이 iOS 및 Android 바이너리를 생성할 때, gated 빌드는 signed 바이너리를 생성해야 합니다. Capacitor 앱의 웹层에서만 변경이 발생한 경우, 여전히 pipeline이 웹 번들을 빌드하고, 검증하고, 안전하게 패키징하여 스테이징 또는 프로덕션에 전달해야 합니다. artifact identity가 중요합니다. 테스트를 통과한 번들이 스테이징 또는 프로덕션에 도달하는 번들이 동일해야 합니다.
artifact를, 환경만을 전달하는 것보다
환경 전달만이 artifact 전달을 생략하는 곳입니다. 팀이 drift를 만들 수 있습니다. 내부 QA에서 스테이징으로, 스테이징에서 프로덕션으로 가능한 한 동일한 번들이 이동해야 합니다. 그렇지 않으면, 하나의 것을 테스트하고 다른 것을 배포합니다. Electron 앱에도 적용됩니다. 패키징 및 서명은 릴리스 게이트에 포함되어야 하며, 후기에 포함되어서는 안 됩니다.
실용적인 규칙: 커밋에서 서명된 artifact로, 배포된 버전으로 추적할 수 없는 빌드는, pipeline이 QA가 필요로 하는 증명 chain을 제공하지 못한다는 것을 의미합니다.
Capacitor 팀의 경우, live-update 도구는 검증과 롤아웃 간의 격차를 줄일 수 있습니다. 테스트된 웹 번들이 스테이징으로 이동할 수 있으며, 네이티브 셸이 변경되지 않은 경우, 네이티브 바이너리를 다시 빌드하지 않고도 iteration이 훨씬 빠릅니다. 통합 설정 이 가이드는 CI가 자동으로 올바른 채널에 검증된 패키지를 배포할 수 있도록 하기 때문에 여기에 관련이 있습니다.
간단히 말해 CI CD는 '빌드가 성공했는가?'라고 물어보지 말아야 합니다. '이 정확한 아티팩트가 올바른 환경에서 올바른 게이트 앞에 있는지, 올바른 체크를 통과했는가?'라고 물어보야 합니다.
late-stage 통합 검사 추가
외부 시스템이 참여하는 경우에만 나타나는 일부 실패가 있습니다. 인증 제공자, 결제 게이트웨이, 푸시 토큰, SMS 인증 흐름과 같은 경우에 특히 그렇습니다. 플랫폼 워크플로우에서 통합 테스트 커버리지에 대한 더 광범위한 참조점으로는 SMS Activate 통합 테스트 가이드 외부 의존성을 명시적으로 검증하는 것이 중요합니다. 단순히 기대하기만 하는 것은 아닙니다.
pipeline이 이렇게 구축되면 QA는 별도의 절차가 아닌 배달 자체가 됩니다.
Staging, Canary, Phased Rollout Without Guesswork
Staging, Canary, phased rollout은 서로 교환할 수 없습니다. 서로 다른 문제를 해결하고 팀이 하나를 다른 것처럼 사용할 때 문제가 발생합니다. 건강한 품질 보증 과정 그것들을 별개의 배포 전략으로, 별개의 폭파 반경으로, 별개의 결정 지점으로 다루어야 합니다.
릴리스 단계의 각 목적
스테이징 생산 이전의 마지막 풀 피들리 체크포인트입니다. 스테이징은 가능한 한 생산과 일치해야 하므로 팀은 빌드, 데이터 흐름 및 릴리스 패키징을 현실적인 조건 하에서 검증할 수 있습니다.
캐니 작은 실제 사용자 슬라이스에서 학습하는 데 사용됩니다. 캐니는 스테이징이 자주 놓치는 장치별 및 네트워크별 문제를 노출합니다. 왜냐하면 세상은 어떤 전제 환경보다 더 복잡하기 때문입니다.
스테이지드 롤아웃 첫 번째 신호가 건강하게 보이면 점진적으로 노출을 확대합니다. 이는 사용자 베이스 전체에 단일 릴리스 결정에 베팅하지 않고 폭파 반경을 확대하는 가장 안전한 방법입니다.
Capgo-style 채널이 롤아웃 전략과 어떻게 매핑되는지
실시간 업데이트 도구에 대한 채널 디자인은 중요합니다. 하나의 채널은 내부 QA를 위해 사용할 수 있고, 다른 채널은 베타 그룹을 대상으로 하며, 세 번째 채널은 첫 번째 생산波를 위해 사용할 수 있고, 네 번째 채널은 오로지緊急 롤백을 위해 존재할 수 있습니다. 이 분리 덕분에 엔지니어링 및 지원 팀은 새로운 스토어 제출을 기다리지 않고도 위험을 분리할 수 있습니다.
이것은 또한 목표 장치 할당이 도움이 되는 곳입니다. 특정 사용자 또는 장치에 대한 디버깅이 필요하다면, 채널을 단일 경우에만 설정할 수 있습니다. 이로써 나머지 기본 버전은 알려진 좋은 버전으로 유지됩니다. Capgo은 Capacitor 앱에 대한 목표된 품질 보증 흐름을 지원합니다. 이는 버그가 복제하기 어려울 때 특히 유용합니다. 또한 모든 사용자의 릴리즈 상태를 변경하지 않고 단일 장치를 관찰해야 할 때입니다.
품질 보증 기준이 명확해야 합니다.
빌드는 증거가 이를 허용할 때만 진행되어야 합니다. 일반적으로 이는 이전 단계가 정의된 검사에서 통과했으며, 새로운 충돌 패턴이 나타나지 않았으며, 동일한 불만이 지원 큐에 채워지지 않는다는 것을 의미합니다. 신호가 불분명하다면 빌드를 그대로 유지해야 합니다.
단순한 승진 규칙이 있습니다:
- 내부 QA에서 스테이징, 정확한 아티팩트가 스모크 체크와 중요 사용자 흐름을 통과한 후에만.
- 스테이징에서 캐니, 전체 신뢰도 환경이 예상 동작과 일치하는 경우에만.
- 캐니에서 phased 롤아웃, 초기 사용자가 안정적인 동작을 보여주고, 지원 팀이 릴리즈를 단순한 용어로 설명할 수 있을 때.
- phased 롤아웃에서 전체 프로덕션, 프로덕션 관찰성이 오랫동안 깨끗한 상태를 유지할 때까지.
그것이 제거하는 추측의 부분입니다. 홍보는 증거에 기반한 결정이 되고, 진행의 축하가 아니라 됩니다.
관찰성 및 지표가 사용자가 문제를 보고하기 전에 문제를 잡습니다.
릴리스가 출시된 후 QA는 사라지지 않습니다. 그것은 모양을 바꿉니다. 프로덕션 관찰성은 릴리스가 테스트가 말한 대로 행동했는지, 사용자가 실패를 만나는지, 실험 환경에서 본 적 없는 실패를 만나는지 알려주는 품질 보증 프로세스의 부분입니다. 모바일 및 크로스 플랫폼 앱의 경우, 그것은 장치별 신호, 업데이트 건강, 오류 패턴을 함께 살펴보는 것입니다. 품질 보증 프로세스의 부분 사용자 고통을 반영하는 신호를 관찰하십시오
가장 유용한 지표는 실제로 오류가 발생하는 것과 관련이 있는 지표입니다. 충돌 없는 세션, 자바스크립트 오류율, 네트워크 오류율, 업데이트 수락률, 업데이트 실패율은 각각 다른 부분의 이야기를 전달합니다. 앱이 그 신호 중 하나를 놓치면, 지원 팀이 엔지니어보다 문제를 먼저 듣게 됩니다.
__CAPGO_KEEP_0__ 또는 Electron 앱의 경우, 장치별 로그가 중요합니다. 동일한 릴리스가 OS 버전, 형태, 업데이트 상태에 따라 다르게 행동할 수 있기 때문입니다. 라이브 업데이트 플랫폼은 장치별로 수락 및 실패 데이터를 노출할 수 있습니다. 엔지니어는 롤백이 필요한지, 문제가 작은 부분에만 국한되어 있는지 확인할 수 있습니다.
For a Capacitor or Electron app, per-device logs matter because the same release can behave differently across OS versions, form factors, or update states. A live-update platform can expose adoption and failure data by device, which gives engineering a way to see whether a rollback is needed or whether the issue is isolated to a small slice.
품질 보증 프로세스
대시보드가 실패할 때는 nobody가 응답을 소유하지 않습니다. 각 지표는 소유주, 경고 조건, 표준 다음 단계가 필요합니다. 업데이트가 실패할 때 스파이크가 발생하면 somebody가 채널을 일시 중단, 패키지를 롤백, 새로운 핫픽스를 배포해야 합니다.
실용적인 설정은 다음과 같습니다:
- 크래시 및 오류 모니터링, 앱 불안정성을 빠르게 감지하기 위해.
- 업데이트 수용 추적, 사용자가 수정된 패키지를 받는지 여부를 확인하기 위해.
- 실패율 경고, 지원 백로그가 증가하기 전에 나쁜 패키지를 잡기 위해.
- 장치 수준 드릴다운, 팀이 광범위한 실패와 플랫폼 특이적인 노이즈를 분리할 수 있도록.
대시보드는 결정을 변경할 때만 유용합니다. 그렇지 않으면 그것은 더 많은 탭이 있는 스크린샷입니다.
피드 생산은 다음 릴리스에 신호를 되돌려줍니다.
최고의 QA 팀은 출시 후 데이터를 새로운 테스트로 변환합니다. 특정 장치 클래스가 업데이트를 적용하지 못한 경우, 해당 경로에 대한 유효성 검사 사례를 추가합니다. 네트워크 재시도가 하나의 플랫폼에서 나쁘게 작동한 경우, 다음 테스트 계획에 실패 모드를 포함합니다. 그게 관찰 가능성이 품질의 입력이 아닌 오페레이션 사이드바가 아닌 품질이 되는 방법입니다.
릴리스 도구가 QA에 포함되기 보다는 단순히 배포에만 포함되는 것이 됩니다. 팀이 장치가 업데이트되었는지, 실패했는지, 그리고 활성화된 버전이 무엇인지 볼 수 있게 되면, 사용자가 지원에 몰려들기 전에 반응할 수 있습니다. Capgo의 장치별 로그와 채널 가드레일은 출시 후에도 릴리스 프로세스가 설명할 수 있는 모델에 잘 맞습니다.
사고 복구, 롤백 및 올바른 교훈을 얻기
잘못된 릴리스가 출시된 순간이 품질 보증 프로세스가 진짜인지 증명하는 것입니다. 팀이 강력한 계획, 합리적인 테스트 커버리지, 그리고 깨끗한 pipeline를 가지고 있지만, 빠르게 복구할 수 없거나 교훈을 얻을 수 없다면, 모든 가치가 사라집니다. 그 때문에 사고 대응이 QA에 속해야 하며, 그 옆에 속해야 하는 것은 아닙니다.
처리 먼저, 설명 두 번째
릴리스가 잘못되면 첫 번째 작업은 범위 확인입니다. 장치의 subset이 특정화되었는지, 하나의 버전과 관련되었는지, 또는 전체 사용자에게 영향을 미치는지 확인합니다. 그게 명확해지면 팀은 롤백, 채널 일시정지, 또는 수술적 핫픽스를 선택할 수 있습니다.
실시간 업데이트 플랫폼에서 자바스크립트 또는 CSS 변경 사항은 앱 스토어 또는 플레이 리뷰를 기다리지 않고 몇 분 안에 롤백할 수 있습니다. 그 이유는 팀이 문제를 확산하는 속도에 따라 나쁜 경험과 제한된 사고 사이의 차이가 종종 결정되기 때문입니다. 사고 대응 가이드 사고 후 리뷰를 작성하여 행동을 바꾸세요
사고 후 보고서에는 단순히 원인만 기록하는 것이 아니라 관찰한 내용, 신호가 있었는지, 첫 번째 잘못된 가정, 문제를 일찍 발견할 수 있었던 조치를 기록해야 합니다. 만약 동일한 유형의 결함이 다시 발생할 수 있다면, 보고서에는 변경된 수락 기준, 새로운 테스트 케이스, 또는 CI 게이트가 포함되어야 합니다.
리뷰 출력으로 유용한 항목은 다음과 같습니다:
수정된 수락 기준
- 원래 요구 사항이 너무 추상적이었다면.새로운 회귀 테스트
- 실패가 기술적으로 예방할 수 있었다면.배포 경계
- 문제가 더 오래 스테이징에 머물러야 했다면., if the issue should have stayed in staging longer.
- A 지원 메모입니다.만약 고객 대면 팀이 다음 번에 더 나은 스크립트가 필요하다면.
실용적인 규칙: 포스트 모터멘트가 게이트, 테스트, 또는 롤아웃 규칙을 변경하지 않는다면, 그것은 그냥 문서일 가능성이 높습니다.
그런 학습 루프가 성숙한 QA와 릴리즈 극장의 차이를 만드는 것입니다. 릴리즈가 실패했고, 팀이 그것을 포함했고, 프로세스가 약한 곳에서 더 엄격해졌습니다.
Capgo은 팀이 그 루프를 짧게 하여 실시간 업데이트를 배포하고 채널을 목표로 하며, 릴리즈 소유자가 장치 수준에서 오류가 발생했을 때 시각화를 제공합니다. CapacitorJS 또는 Electron 앱을 위한 더 안전한 품질 보증 프로세스를 구축하려면 Capgo을 방문하고, 실시간 업데이트의 롤아웃, 롤백, 관찰 가능성을 동일한 운영 모델에 통합하는 방법을 살펴보세요. 품질 보증 프로세스의 안전성을 높이기 위해 CapacitorJS 또는 Electron 앱을 위한 더 안전한 품질 보증 프로세스를 구축하려면 __CAPGO_KEEP_0__을 방문하세요. Capgo 작성자
