A practical
__CAPGO_KEEP_0__ 품질 보증 절차 품질 보증 절차는 완전한 루프이며, 누군가가 결함을 로깅할 때 체크리스트가 끝나는 것이 아니다. 요구 사항과 테스트 설계로 시작하지만, 발견된 결과가 릴리즈 결정, 모니터링, 롤백, 다음 테스트 라운드에 반영될 때만 유용해진다. CapacitorJS 또는 Electron 앱을 배포하는 경우, 그 루프는 더 중요하다. 하나의 잘못된 웹 번들만으로도 모든 사용자가 한 번에 영향을 받을 수 있지만, 네이티브 리뷰는 영구적인 수정을 늦추기 때문이다.
목차
- 현대 품질 보증 절차가 실제로 무엇을 포함하는가
- 목표, 범위, 테스트 가능한 수락 기준 정의
- 자동화된 테스트와 수동 테스트의 올바른 혼합 선택
- CI/CD pipeline에 QA를 통합하는 방법
- 스테이징, 캐니리, 및 phased 롤아웃을 guesswork 없이
- 사용자가 문제를 보고하기 전에 문제를 잡아내는 관찰성 및 메트릭
- __CAPGO_KEEP_1__
__CAPGO_KEEP_4__
__CAPGO_KEEP_5__ __CAPGO_KEEP_6__ __CAPGO_KEEP_7__ __CAPGO_KEEP_8____CAPGO_KEEP_9__ __CAPGO_KEEP_10__ __CAPGO_KEEP_11__ 결함 분류 및 확인 루프, 왜修정은 종결 전까지 검증이 이루어질 때까지 카운트되지 않는다는 것을 설명한 TestSigma에서 제공하는 QA 프로세스 가이드.
Release 단계에서 루프가 멈추지 않는다
품질 보증이 좋은 것은 릴리즈 후보가 녹색이 될 때 종료되지 않는다. 그것은 프로덕션 검증, 지원 신호, 라이브 업데이트 복구, 다음 스프린트의 테스트 설계를 통해 계속된다. 많은 팀들이 결함을 티켓으로 대신하여, 요구 사항, 테스트, 배포 경계 장치가 변경해야 하는 증거로 대체하는 것을 넘어서서, 그것을 놓치고 있다.
품질 보증을 관리 시스템으로 생각하는 것이 유용하다. 품질 보증 프로세스 단계 안내점은 많은 프로그램이 고객 피드백 루프와 다중 채널 평가를 놓치고 있으며, 그 격차는 앱 팀에도 중요하다는 것을 지적한다. 지원이 릴리즈 후 동일한 불만을 계속 보고한다면, 프로세스는 배운 것이 아니라, 단지 측정한 것 뿐이다.
도구를 추가하기 전에 무엇을 측정해야 하는지
도구를 구매하기 전에 팀이 빌드를 안전한지 결정하기 위해 사용할 신호에 대한 명확성을 얻는 것이 중요하다. 일반적으로 릴리즈 게이트, 각 게이트의 책임자, 롤백 기준을 정의하는 것이 필요하다.
실용적인 시작 세트는 간단하다
- 기능 커버리지사용자에게 보이는 규칙이 최소한 하나의 테스트를 가지고 있는지 여부를 보여줍니다.
- 결함 심각도와 소유권팀이 출시를 막고 누구가 해결할지 알 수 있도록 합니다.
- 회귀 범위fixes가 인접한 흐름에서 이전 문제를 다시 열지 않도록 합니다.
- 제작 후 신호제작 피드백이 다음 테스트 사이클을 바꾸도록 합니다.
인접한 운영 프로세스의 수동 재작업을 줄이기 위해 노력하는 팀에게, Dooza 노동 비용 감소 안내서 구조화된 검토와 명확한 전달이 낭비된 노력을 줄일 수 있는 예시입니다. QA도 마찬가지입니다. loop이 명확할 때, 사람들은 추측하지 않습니다.
현재 프로세스가 실패한 것을만 알려주지, 다음 변경 사항을 알려주지 않는다면, 그것은 완전하지 않습니다. 그것이 테스트 루틴과 실제 품질 시스템의 차이입니다. 출시 관리 관점이 그 마음가짐에 맞는 것을 찾고 있다면, 내부에 있는 이 안내서에 대해 릴리스 관리 프로세스 같은 폐쇄 루프 접근 방식과 잘 어울립니다.
목표, 범위, 테스트 가능한 수락 기준 정의
QA가 제품 언어가 테스트 가능한 언어로 변환되면 더 선명해집니다. '체크아웃이 빠르다'라는 요구 사항은 깨끗하게 검증할 수 없지만 '제공자가 성공을 반환하고 사용자가 앱을 닫기 전에 결제 확인 화면을 표시한다'는 것은 테스트할 수 있으며, 테스트할 수 있으며, 엔지니어링과 지원 모두에게 유용합니다. 그 트레이스 ability은 폐쇄 루프 모델의 핵심 제어점 중 하나입니다.
테스터가 실행할 수 있는 수락 기준을 작성하십시오.
CapacitorJS 앱의 경우, 결제 흐름을 고려하십시오. 앱이 세 번째 결제 시트를 사용한다면, 수락 기준은 시트가 성공, 실패, 타임아웃, 또는 사용자가 취소할 때 발생하는 것을 모두 포함해야 합니다. 흐름이 카메라 권한, 위치 권한, 또는 푸시 알림 동의에 의존한다면, 각 branch는 iOS와 Android에서 권한 프롬프트가 다르게 동작할 수 있기 때문에 각 branch에 대한 명확한 결과를 포함해야 합니다.
가볍고 가볍한 템플릿이 잘 작동합니다:
- Given 사용자는 인증되었습니다.
- When 결제 버튼을 탭합니다.
- Then 앱은 결제 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
__CAPGO_KEEP_0__
자동화와 수동 테스트의 올바른 조합을 선택하는 방법
자동화가 주목을 받는 이유는 확장성이 있지만, 모델링할 수 있는 범위만 잡을 수 있다. 반면 수동 테스트는 느리다고 여겨지지만, 시각적 드리프트, 장치별 문제, 또는 사용자가 앱을 사용할 때 발생하는 워크플로의 이상 현상만 수동 테스트로 해결할 수 있다. 품질 보증의 균형 품질 보증 프로세스는 자동화와 수동 테스트가 모두 필요하며, 이들 간의 비율은 위험에 따라 결정되어야 한다.
각层의 장점
단위 및 통합 테스트는 논리적 결정이 가능할 때 가장 강력하다. CapacitorJS 또는 Electron 스택에서, 그 의미는 Jest를 비즈니스 로직, 상태 리듀서, 헬퍼, 컴포넌트 동작에 사용하고, API 경계, 업데이트 파싱, 권한 처리 branch에 대한 통합 테스트를 수행하는 것이다. Cypress는 웹层의 브라우저 기반 종단 간 커버리지가 필요할 때 잘 맞는다. 반면 Detox-style 흐름은 장치 수준의 모바일 상호 작용이 필요하고 유지 보수 비용을 부담할 수 있는 경우에 중요하다.
문서 테스트는 맥락이 중요한 곳에서 자리를 차지합니다. 탐색적 세션은 이상한 네비게이션 경로, 다크 모드 불일치, 작은 장치에서 키보드 겹침, 또는 OS 버전 하나에서 너무 sớm로 닫히는 모달을 잡을 수 있습니다. 또한 접근성에 중요합니다. 스크린 리더 순서, 포커스 트랩, CONTRAST 문제는 일반적으로 정적 체크만 믿고 시도하지 않으면 더 쉽게 발견할 수 있습니다.
더 광범위한 자동화 카테고리와 트레이드 오프를 원한다면 Appjet.ai의 테스트 도구는 자동화 테스트의 대안 자동화 테스트 대안 시나리오
최적의 선택
| 왜 | 공유 모듈 내의 단순한 비즈니스 로직 | 자동화 |
|---|---|---|
| 자동화 테스트 대안 | 자동화 테스트 대안 | 빠른 feedback, 안정적인 입력, 쉽게 반복 |
| 결제 제공자 callback 처리 | 자동화된 플러스 수동 | 사용자 경험을 위한 인간의 검증이 필요한 논리가 스크립트 될 수 있지만 |
| iOS 및 Android에서 권한提示 | 수동으로 먼저 | OS 동작 및 장치 상태가 흐름을 변경할 수 있습니다. |
| 설정 화면의 시각적 회귀 | 수동 플러스 시각 도구 | 실제 통과 시 레이아웃 버그가 더 쉽게 발견됩니다. |
| 오프라인 동기화 및 재연결 동작 | 자동화된 플러스 장치 테스트 | 실행 시간, 재시도 및 상태 복구가 반복 가능한 테스트 커버리지가 필요합니다. |
| 새 기능 플래그에 대한 베타 피드백 | 수동 | 실제 세계의 동작은 테스트가 놓친 틈을 드러내는 경우가 많습니다. |
외부 베타 테스터가 도움을 주는 곳
외부 베타 테스터는 내부 팀이 너무 많은 공유된 컨텍스트를 가지고 있을 때 유용합니다. 그들은 여러분의 가정에 동의하지 않습니다. 그게 포인트입니다. 그들은 특히 온보딩, 첫 번째 실행 권한, 또는 익숙하지 않은 사용자 동작에 의존하는 흐름에 영향을 미치는 릴리스 후보에 특히 효과적입니다.
오버 인덱싱하는 함정은 두 가지 측면 중 하나에 집중하는 것입니다. 자동화만 의존하는 테스트 계획은 인간의 유연성을 놓치게 됩니다. 반대로, 수동만 의존하는 테스트 계획은 비용이 많이 들고 불일치하며, 일정 시간이 촉박해지면 쉽게 생략할 수 있습니다. 올바른 답은 일반적으로 안정적인 자동화 기반에 의도적으로 인간의 커버리지가 있는 표면에서 가장 쉽게 깨질 수 있는 곳에 집중하는 것입니다.
CI/CD pipeline에 QA를 통합하는 방법
CI/CD는 품질을 강제하는 것이 아니라, 단순히 아티팩트를 이동하는 것입니다. pipe line은 각 단계가 단일 작업을 수행할 때 가장 잘 작동합니다. 혼합된 관심사로 인해 실패가 더 어려운지라 더 느리게 고쳐질 수 있습니다. 좋은 품질 보증 프로세스는 나쁜 __CAPGO_KEEP_0__를 막는 곳에 체크를 두고, 나아가 릴리스까지 이동하는 동안 동일한 아티팩트를 보존합니다. CI/CD pipeline의 5단계 다이어그램, __CAPGO_KEEP_0__ 커밋부터 배포까지 품질 보증이 통합된 CI/CD pipeline CI/CD pipeline의 5단계 다이어그램, code 커밋부터 배포까지 품질 보증이 통합된 CI/CD pipeline
cheap한 검사들을 먼저 넣으세요
커밋마다 빠르고 결정적인 검사들을 실행하세요. lint, type checks, unit tests, 그리고 집중적인 통합 테스트는 native binaries를 만들기 전에 실패해야 합니다. 그럼으로 noise가 낮아지고 다음 단계인 빌드가 컴퓨팅 비용을 가치 있게 만듭니다.
그 다음, gated 빌드는 native code 변경에 따라 signed iOS와 Android binaries를 생성해야 합니다. 만약 변경이 웹层에만 있는 Capacitor 앱일 경우, 여전히 pipeline이 웹 번들을 빌드하고, 검증하고, 안전하게 배포할 수 있는 형태로 패키징해야 합니다. artifact identity가 중요합니다. 테스트를 통과한 번들이 스테이징 또는 프로덕션으로 이동하는 번들이어야 합니다.
artifact를, 환경만을 promot하는 것이 아닙니다
environment promotion without artifact promotion은 팀이 drift를 만들게 합니다. 내부 QA에서 스테이징으로, 스테이징에서 프로덕션으로 이동하는 동일한 번들이어야 합니다. 그렇지 않으면, 테스트한 것이 배포하는 것이 다릅니다. Electron 앱에도 마찬가지로, 패키징과 서명은 릴리즈 게이트에 포함되어야 하며, postscript가 아닙니다.
실용적인 규칙입니다. 만약 빌드가 커밋에서 signed artifact로, 그리고 배포된 버전으로 추적할 수 없다면, pipeline이 QA가 필요로 하는 증명 chain을 제공하지 못하고 있습니다.
Capacitor 팀에게는 live-update tooling이 검증과 롤아웃 간의 격차를 줄일 수 있습니다. 테스트된 웹 번들이 스테이징으로 이동할 수 있으며, native binaries를 다시 빌드할 필요가 없습니다. native shell이 변경되지 않았을 때 iteration이 훨씬 빠르다는 것을 의미합니다. 연속 통합 설정 CI는 자동으로 올바른 채널에 검증된 번들을 게시할 수 있어야 하므로 이 안내서가 관련이 있습니다.
간단한 버전은 CI CD가 "빌드가 성공했는가?"라고 물어보지 말아야 한다는 것입니다. "이 정확한 아티팩트가 올바른 환경에서 올바른 게이트 앞에 있는 올바른 체크를 통과했는가?"라고 물어야 합니다.
late-stage 통합 확인 추가
외부 시스템이 참여하는 경우 일부 실패는 나타나지 않습니다. 인증 제공자, 결제 게이트웨이, 푸시 토큰, SMS 인증 흐름과 같은 대상화된 종단 간 패스가 도움이 됩니다. 플랫폼 워크플로우에서 통합 테스트 커버리지에 대한 더 광범위한 참조점으로 필요하다면 SMS Activate 통합 테스트 안내서 외부 의존성에 대한 명시적인 검증이 아니라 희망에 의존해서는 안 됩니다.
pipeline이 이와 같은 방식으로 빌드되면 QA가 별도의 절차가 아닌 배달 자체가 됩니다.
Staging, Canary, and Phased Rollouts Without the Guesswork
Staging, Canary, and Phased Rollouts는 서로 교환할 수 없습니다. 서로 다른 문제를 해결하고 팀이 하나를 다른 것처럼 사용하면 문제가 발생합니다. 건강한 품질 보증 프로세스 그것들을 별도의 릴리즈 전략으로 다루어야 하며 별도의 폭파 반경과 별도의 결정 지점을 가집니다.
배포 단계의 목적
준비 은 프로덕션 이전의 마지막 완전한 신뢰성 점검입니다. 프로덕션과 가능한 한 유사하게 반영되어 빌드, 데이터 흐름 및 릴리스 패키징을 현실적인 조건 하에서 팀이 검증할 수 있도록 해야 합니다.
Canary 은 작은 실제 사용자 조각에서 학습하는 데 사용됩니다. 준비 단계는 종종 놓치는 장치 및 네트워크 관련 문제를 노출합니다. 왜냐하면 세상은 어떤 전제 환경보다 더 복잡하기 때문입니다.
격주 배포 은 첫 번째 신호가 건강해보인 후 점진적으로 노출을 확대합니다. 이는 사용자 베이스 전체에 대한 단일 릴리스 결정에 베팅하지 않고도 폭파 반경을 확대하는 가장 안전한 방법입니다.
Capgo-style 채널이 배포 전략과 어떻게 매핑되는지
라이브 업데이트 도구에 대한 채널 디자인은 중요합니다. 하나의 채널은 내부 QA를 위해 사용할 수 있고, 다른 채널은 베타 그룹을 대상으로 하며, 세 번째 채널은 첫 번째 프로덕션 웨이브를 대상으로 하며, 네 번째 채널은 오로지 긴급 롤백을 위해 존재할 수 있습니다. 이 분리 덕분에 엔지니어링 및 지원 팀은 새로운 스토어 제출을 기다리지 않고도 위험을 분리할 수 있습니다.
이것은 또한 목표 장치 할당이 도움이 되는 곳입니다. 특정 사용자 또는 장치가 디버깅이 필요할 때, 채널을 설정할 수 있습니다. 그 경우, 나머지 기본 버전은 알려진 좋은 버전으로 유지됩니다. Capgo은 Capacitor 앱에 대한 목표 질량 보증 흐름을 지원합니다. 이 흐름은 버그가 복제하기 어려울 때 유용합니다. 또한 모든 사용자의 릴리스 상태를 변경하지 않고 한 장치만 관찰할 때.
기본적인 승인 기준이 명확해야 합니다.
빌드는 증거가 그것을 진행할 수 있음을 말할 때만 진행되어야 합니다. 일반적으로 이것은 이전 단계가 정의된 검사에 통과했을 때, 새로운 충돌 패턴이 나타나지 않았을 때, 그리고 동일한 불만이 지원 큐에 채워지지 않았을 때입니다. 신호가 불분명할 때, 빌드를 그대로 유지해야 합니다.
단순한 승인 규칙이 있습니다.
- 내부 QA에서 스테이징으로만약 정확한 아티팩트가 스모크 체크를 통과하고 중요한 사용자 흐름을 통과했다면만.
- 스테이징에서 캐니로만약 전체 신뢰도 환경이 예상 동작과 일치한다면만.
- 캐니에서 phased 롤아웃으로만약 초기 사용자가 안정적인 동작을 보여주고 지원 팀이 릴리스를 단순한 용어로 설명할 수 있다면만.
- phased 롤아웃에서 전체 프로덕션으로만약 프로덕션 관찰성이 오랫동안 깨끗한 상태로 유지되면, 팀이 트렌드에 신뢰할 수 있다면만.
guesswork를 제거하는 부분입니다. 홍보가 증거에 기반한 결정이 되고, 진행의 축하가 아니라 됩니다.
사용자가 문제를 신고하기 전에 문제를 잡아내는 관찰성과 메트릭
릴리즈가 출시된 후 QA는 사라지지 않습니다. 형태만 바뀝니다. 프로덕션 관찰성은 품질 보증 프로세스의 부분입니다. 이것은 릴리즈가 테스트에서 말한 대로 작동했는지 알려주고, 사용자가 실패를 경험하는지 여부를 알려줍니다. 그리고 사용자 환경에서 보지 못한 실패를 경험하는지 여부를 알려줍니다. 모바일 및 크로스 플랫폼 앱의 경우, 이는 장치별 신호, 업데이트 상태, 오류 패턴을 함께 살펴보는 것입니다. 사용자 고통을 반영하는 신호를 살펴보세요.
실제로 깨지지 않는 세션, 자바스크립트 오류율, 네트워크 실패율, 업데이트 채택률, 업데이트 실패율 등이 실제로 깨지지 않는 세션과 같은 유용한 메트릭입니다. 앱이 이러한 신호 중 하나를 놓치면, 지원 팀이 문제를 먼저 알게 되고, 엔지니어링 팀은 문제를 알게 되지 않습니다.
Capgo 또는 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.
__CAPGO_KEEP_0__
대시보드가 실패할 때는 nobody가 응답을 소유하지 않습니다. 각 지표는 소유주, 경고 조건, 표준 다음 단계가 필요합니다. 업데이트 실패가 급증하면 채널이 일시 중단되거나 패키지가 롤백되거나 새로운 핫픽스가 게시되도록 결정해야 합니다.
실용적인 설정은 다음과 같습니다:
- 버그 및 오류 모니터링앱 불안정성을 빠르게 감지하기 위해 사용합니다.
- 업데이트 수용 추적사용자가 수정된 패키지를 받는지 여부를 확인하기 위해 사용합니다.
- 실패율 경고지원 백로그가 증가하기 전에 나쁜 패키지를 잡기 위해 사용합니다.
- 장치 수준 드릴다운팀이 광범위한 실패와 플랫폼 특이적인 노이즈를 분리할 수 있도록합니다.
대시보드는 결정을 변경할 때만 유용합니다. 그렇지 않으면 그것은 단순히 탭이 더 많은 스크린샷입니다.
피드 생산 신호를 다음 릴리스에 반영합니다.
최고의 QA 팀은 출시 후 데이터를 새로운 테스트로 변환합니다. 특정 장치 클래스가 업데이트를 적용하지 못한 경우, 그 경로에 대한 유효성 검사 케이스를 추가합니다. 네트워크 재시도가 하나의 플랫폼에서 나쁜 결과를 냈을 경우, 다음 테스트 계획에 그 실패 모드를 포함시킵니다. 그게 어떻게 관찰 가능성이 품질의 입력이 아닌 오페레이션의 사이드바가 아닌지 알게 됩니다.
릴리즈 툴링이 QA의 일부가 되면, 단순히 배포만 하는 것이 아닌 것입니다. 장치가 업데이트되었는지, 실패했는지, 어떤 버전이 실시간으로 실행되고 있는지 볼 수 있으면, 사용자가 지원센터로 몰려오기 전에 반응할 수 있습니다. Capgo의 장치별 로그와 채널 가드레일은 릴리즈 프로세스가 런칭 후에도 설명할 수 있는 모델에 잘 맞습니다.
사고 복구, 롤백, 올바른 교훈을 얻기
품질 보증 프로세스가 진짜인지 증명하는 것은 출시 후 나쁜 릴리즈의 순간입니다. 팀이 강력한 계획, 합리적인 테스트 커버리지, 깨끗한 PIPE라인을 가지고 있지만, 빠르게 복구할 수 없거나 실수를 배운다면, 그 모든 가치가 사라집니다. 그 때문에 사고 대응은 QA의 일부가 되어야 합니다.
처음에는 분류, 두 번째로 설명
릴리즈가 나쁜 경우, 첫 번째 작업은 범위 확인입니다. 장치의 subset이 특정한 것인지, 하나의 버전과 관련된 것인지, 전체 사용자에게 영향을 미치는 것인지 확인합니다. 그게 명확해지면, 팀은 롤백, 채널 일시정지, 또는 수술적 핫픽스를 선택할 수 있습니다.
live-update 플랫폼에서, 자바스크립트 또는 CSS 변경이 종종 앱 스토어 또는 플레이 리뷰를 기다리지 않고 몇 분 안에 롤백 될 수 있습니다. 그 중요성은 팀이 문제의 확산을 멈출 수 있는 속도와 종종 나쁜 경험과 제한된 사고 사이의 차이입니다. 사고 대응 가이드 사고 대응 가이드는 팀이 운영 계획서를 더 깨끗하게 작성하고 싶다면 올바른 동반자 참고서입니다.
사고 후 검토를 작성하여 행동을 바꾸세요.
사고 후 보고서에는 더 이상의 원인만 기록하는 것 이상이 필요합니다. 관찰된 사항, 사용 가능한 신호, 첫 번째 잘못된 가정, 문제를 일찍 발견할 수 있었던 것, 같은 유형의 결함이 다시 발생할 수 있다면 문서는 변경된 수락 기준, 새로운 테스트 케이스, 또는 CI 게이트를 생성해야 합니다.
리뷰 출력에는 다음이 포함됩니다.
- 수락 기준이 수정된 것, 원래 요구 사항이 너무 추상적이었다면.
- 새로운 회귀 테스트, 기술적으로 예방할 수 있었다면.
- 배포 경계 장치, 문제가 더 오래 스테이징에 머물러 있어야 했다면.
- A 지원 메모고객 대면 팀이 다음 번에 더 좋은 스크립트가 필요할 때.
실용적인 규칙: 사후 분석이 게이트, 테스트, 또는 롤아웃 규칙을 변경하지 않으면, 그건 그냥 문서일 가능성이 높습니다.
그런 학습 루프가 성숙한 QA와 릴리스 극장의 차이입니다. 릴리스가 실패했으며 팀이 그것을 제어했으며 프로세스가 정확한 위치에서 약점이 있었던 곳에서 더 엄격해졌습니다.
Capgo은 팀이 그 루프를 짧게 만들 수 있도록 실시간 업데이트, 채널을 대상으로, 릴리스 소유자가 장치 수준에서 오류가 발생했을 때 시각화할 수 있도록 해줍니다. 릴리스가 실패했으며 팀이 그것을 제어했으며 프로세스가 정확한 위치에서 약점이 있었던 곳에서 더 엄격해졌습니다. 만약 CapacitorJS 또는 Electron 앱을 위한 더 안전한 품질 보증 프로세스를 구축하고자 한다면, __CAPGO_KEEP_0__ Capgo 작성자
