CI 빌드가 통과되어도 앱이 깨질 수 있습니다. 빌드가 통과하고 QA 팀이 승인하면 릴리스가 나가고 첫 번째 실제 사용자가 권한 요청이 반환되지 않는 것을,陈舊한 자바스크립트 번들, 또는 한 개의 안드로이드 스킨에서만 나타나는 충돌을 만날 수 있습니다. 대부분의 품질 보증 과정 지침은 이러한 부분을 생략하고, 모바일 팀은 일반적으로 이러한 부분을 어려움을 겪으며 배운다는 것을 알게 됩니다.
실용적인 품질 보증 과정 은 폐쇄 루프가 아니라, 결함을 로그한 후에 끝나는 체크리스트가 아닙니다. 요구 사항과 테스트 디자인으로 시작하지만, 발견된 결과가 릴리스 결정, 모니터링, 롤백, 다음 테스트 라운드에 반영될 때만 유용해집니다. CapacitorJS 또는 Electron 앱을 배포하는 경우, 하나의 잘못된 웹 번들이 모든 사용자를 동시에 영향을 줄 수 있으면서, 영구적인 수정이 지연되는 네이티브 리뷰를 고려할 때, 이 루프는 더 중요합니다.
목차
- 현대 품질 보증 과정은 실제로 무엇을 포함하는가
- 도구를 추가하기 전에 측정해야 할 것
- 자동화된 테스트와 수동 테스트의 올바른 혼합 선택
- CI/CD PIPELINE에 QA를 통합하는 방법
- 스테이징, 카나리, 및 phased 롤아웃을 추측하지 않고
- 사용자들이 문제를 신고하기 전에 문제를 잡아내는 관찰성 및 지표
- 사고 복구, 롤백 및 올바른 교훈을 얻는 것
현대적인 품질 보증 프로세스가 실제로 무엇을 포함하는지
현대적인 품질 보증 프로세스 은 명확한 제어점이 있는 닫힌 루프이다. 실제적인 순서는 요구 사항 분석, 테스트 계획, 테스트 설계 및 케이스 개발, 환경 설정, 실행, 결함 추적, 재 테스트 및 회귀, 릴리스 검증 및 테스트 종료. 가장 중요한 제어 요소는 여전히 지루한 것들입니다. 요구 사항에서 테스트까지의 추적 가능성 및 공식적인 결함 분류 및 검증 루프, 왜냐하면 수정 사항은 검증이 끝난 후에야만 종료될 수 있기 때문입니다. TestSigma에서 제공하는 QA 프로세스 가이드에서 설명한 바와 같이. Continuous Quality Assurance Loop를 구성하는 네 가지 반복적인 단계: Plan, Test, Release, Learn의 다이어그램입니다..
Good QA는 Release Candidate가 녹색이 될 때 끝나지 않습니다. 그것은 생산 검증, 지원 신호, Live-Update 복구, 그리고 다음 스프린트의 테스트 설계를 통해 계속됩니다. 많은 팀들이 여기서 실수를 하게 되는데, 왜냐하면 그들은 결함을 티켓으로 대신하여, 요구 사항, 테스트, 또는 배포 경계를 변경해야 하는 증거로 간주하지 않기 때문입니다.
QA에 대한 유용한 방법은 관리 시스템으로 생각하는 것입니다. 점수 카드가 아닌.
품질 보증 프로세스 단계 안내 문구는 많은 프로그램이 고객 피드백 루프와 다중 채널 평가를 놓치고, 그 격차는 앱 팀에도 중요하다는 점을 지적합니다. 지원이 출시 후 동일한 불만을 계속 보고한다면, 프로세스는 배웠지 않습니다. 단지 측정한 것입니다. 품질 보증 프로세스 단계
도구를 추가하기 전에 무엇을 측정해야 하나?
도구를 더 구매하기 전에, 팀이 빌드를 안전한지 결정하기 위해 사용할 신호에 대한 명확성을 얻으려면 먼저 릴리스 게이트, 각 게이트의 소유자, 그리고 어떤 것이 통과해도 롤백 기준을 정의해야 합니다.
실용적인 시작 세트는 간단합니다:
- 요구 사항 커버리지사용자에게 보이는 모든 규칙이 적어도 하나의 테스트가 있는지 여부를 보여줍니다.
- 결함 심각도 및 소유권팀이 릴리스를 막는 것을 알고 있고, 누구가 해결해야 하는지 알 수 있습니다.
- 회귀 범위수정 사항이 인접한 흐름에서 이전 문제를 다시 열지 않도록 고쳐지지 않는다.
- 릴리스 후 신호생산 피드백이 다음 테스트 사이클을 변경하는 대신 대시보드에 살아남지 않도록 합니다.
인접한 운영 프로세스에서 수동 재작업을 줄이기 위해 노력하는 팀에게는 Dooza 노동 비용 절감 가이드 구조화된 검토와 명확한 전달을 통해 낭비된 노력을 줄일 수 있는 유용한 예입니다. QA도 마찬가지로, 명확한 루프를 통해 사람들은 추측하지 않습니다.
만약 현재 프로세스는 실패한 것만 알려주고 다음 변경 사항을 알려주지 않는다면, 그것은 불완전합니다. 그것이 테스트 루틴과 실제 품질 시스템의 차이점입니다. 릴리스 관리 관점이 그 마음가짐에 맞는 것을 찾고 싶다면, 내부 가이드인 릴리스 관리 프로세스 목표, 범위, 테스트 가능한 수락 기준 정의
목표 정의, 범위 설정 및 테스트 가능한 수락 기준 정의
수락 기준을 테스터가 실행할 수 있는 방식으로 작성하십시오
테스터가 그들을 실행할 수 있도록 수락 기준을 작성하십시오.
가볍고 가벼운 템플릿이 잘 작동합니다:
주어
- Given 사용자는 인증되었습니다.
- 그들은 결제 버튼을 탭할 때
- 그런 다음 앱은 결제 UI를 표시하고 성공을 확인하거나 회복 가능한 오류 상태를 표시합니다.
- 그리고 이벤트는 릴리스 티켓으로 추적되므로 QA는 실패를 요구 사항으로 맵핑할 수 있습니다.
그것의 목적은 모든 문장을 공식적으로 만들지 않기 위해서입니다. 그 목적은 인간이 특성이 통과했는지 여부를 알 수 있는지 여부를 확인하는 것입니다. 그 후에 의도에 대해 논쟁하는 것을 피하기 위해서입니다. 내부 체크리스트는 Capacitor 앱 업데이트를 검증하는 데 유용해지는데, 업데이트를 검증하는 것은 종종 누락된 수락 기준을 드러내는 경우가 많기 때문입니다. 릴리스 범위를 위험도에 따라 설정하세요.
위험에 따라 릴리스 범위를 정의하십시오.
업데이트 검증은 종종 누락된 수락 기준을 드러내는 경우가 많습니다.
실무 규칙: 기본적인 사용이 차단되는 기능이 실패할 수 있다면, 명시적인 승인 기준과 최소한의 단위 검증 경로가 필요합니다.
단위 또는 통합 테스트로 잘 수행되지 않는 기능은 무시하지 마세요. 대신 다른层, 종종 수동 검증, 장치별 검증 또는 릴리스 단계 검증 단계가 필요합니다. 특히 Electron 앱은 OS 수준 대화, 파일 접근 또는 브라우저 특이성에 의존하여 컴포넌트 테스트가 충실하게 모델링되지 않습니다.
범위가 올바르게 설정되면 QA가 마지막 순간의 논쟁으로 느껴지지 않습니다. 팀은 무엇을 증명해야 하는지, 무엇을 샘플링해야 하는지, 무엇이 인간의 눈으로 확인해야 하는지 알 수 있습니다. 자동화 경계는 그곳에서 끝납니다.
자동화 테스트와 수동 테스트의 적절한 혼합 선택
품질 보증 프로세스 자동화와 수동 테스트가 모두 필요하고, 위험에 따라 분할해야 합니다. 각 layer가 가장 잘하는 것
자동화와 수동 테스트의 올바른 혼합
단위 및 통합 테스트는 논리가 결정적일 때 가장 강력합니다. CapacitorJS 또는 Electron 스택에서, 그 의미는 Jest를 비즈니스 논리, 상태 리듀서, 도우미, 컴포넌트 동작, 그리고 API 경계, 업데이트 파싱, 및 권한 처리 branch에 대한 통합 테스트로 사용하는 것입니다. Cypress는 웹层의 끝-to-end 커버리지를 원할 때 잘 맞습니다. 반면 Detox-style 흐름은 유지 보수 비용을 부담할 수 있는 장치 수준의 모바일 상호 작용이 필요할 때 중요합니다.
수동 테스트는 컨텍스트가 중요할 때 자리합니다. 탐색적 세션은 이상한 네비게이션 경로, 어둡게 모드 불일치, 작은 장치에서 키보드 겹침, 또는 OS 버전 하나에서 모달이 너무 일찍 닫히는 경우를 발견합니다. 또한 접근성에 중요합니다. 스크린 리더 순서, 포커스 트랩, CONTRAST 문제는 일반적으로 정적 체크만 믿고는 발견하기 어려운 경우가 많습니다.
만약 더 광범위한 자동화 카테고리 및 트레이드 오프를 원한다면 Appjet.ai의 테스트 도구는 카테고리별로 나누어져 있습니다. 자동화된 테스트와 수동 테스트의 경계는 어디에 위치하는지 정의하는 데 도움이 됩니다. 자동화 테스트와 수동 테스트의 비교 Scenario
최적의 선택
| 왜 | 최적화 | Scenario |
|---|---|---|
| Best Fit | 자동화 | 빠른 feedback, 안정적인 입력, 쉽게 반복 |
| 결제 제공자 callback 처리 | 자동화 플러스 수동 | 논리 처리는 스크립트화 할 수 있지만 사용자 경험은 인간의 검증이 필요합니다 |
| iOS 및 Android에서 권한提示 | 수동 우선 | OS 동작 및 장치 상태가 흐름을 변경할 수 있습니다 |
| 설정 화면의 시각적 회귀 | 수동 플러스 시각 도구 | 실제 통과 시 레이아웃 버그가 더 쉽게 발견됩니다 |
| 오프라인 동기화 및 재연결 동작 | 자동화 및 장치 테스트 | 시간, 재시도 및 상태 복구가 반복 가능해야 하는 범위 |
| 새 기능 플래그에 대한 베타 피드백 | 수동 | 실제 세계의 동작이 테스트에서 놓친 부분을 드러내는 경우가 많다 |
외부 베타 테스터의 도움
내부 팀이 너무 많은 공유 컨텍스트를 가지고 있는 경우 외부 베타 테스터가 유용합니다. 그들은 당신의 가정들을 재현하지 않습니다. 그게 목적입니다. 그들은 특히 온보딩, 첫 번째 실행 권한, 또는 익숙하지 않은 사용자 동작에 의존하는 흐름에 영향을 미치는 릴리스 후보에 특히 효과적입니다.
두 가지 측면에 과도하게 집중하는 함정은 테스트 계획이 모두 자동화가 되거나 모두 수동화가 된 경우입니다. 자동화만 의존하는 테스트 계획은 인간의 민감성을 놓치게 되고, 수동화만 의존하는 테스트 계획은 비용이 많이 들고 불일치가 발생하며, 마감일이 가까워질 때는 쉽게 무시할 수 있습니다. 올바른 해결책은 일반적으로 안정적인 자동화 기반에 의도적으로 인간의 커버리지가 있는 가장 유사하게 깨질 수 있는 표면에 집중하는 것입니다.
CI/CD pipeline에 QA를 통합
CI/CD는 품질을 강제해야 합니다. 단지 아티팩트를 이동하는 것이 아닙니다. pipe line이 가장 잘 작동하는 것은 각 단계가 단일 작업을 수행할 때입니다. 혼합된 관심사로 인해 실패가 더 어려워지고 더 느리게 수정됩니다. 좋은 품질 보증 프로세스는 잘못된 __CAPGO_KEEP_0__를 막기 위해 체크를 수행한 후, 동일한 아티팩트를 릴리스까지 이동하는 동안 보존합니다. 품질 보증 프로세스 질병 검사를 하는 곳에서 문제가 있는 것을 막기 위해 code을 일찍 차단하고, 출시까지 이동하는 동안 동일한 artifact를 보존합니다.
저렴한 체크를 먼저 수행하세요.
커밋마다 빠르고 결정적인 체크를 수행하세요. lint, 타입 체크, 단위 테스트 및 집중된 통합 테스트는 native 바이너리 빌드를 위해 시간을 들이지 전에 실패해야 합니다. 그럼 다음 단계인 빌드가 컴퓨팅 비용을 가치 있게 만듭니다.
code 변경이 iOS 및 Android 바이너리를 생성할 수 있는 게이트드 빌드가 다음으로 와야 합니다. Capacitor 앱의 웹层에서만 변경이 있는 경우에도 pipeline이 웹 번들을 빌드하고 검증하고 안전하게 패키징하여 스테이징 또는 프로덕션으로 승격할 수 있도록 해야 합니다. artifact identity가 중요합니다. 테스트를 통과한 번들이 스테이징 또는 프로덕션으로 승격되는 번들이어야 합니다.
환경 보다는 artifact를推진하세요
실용적인 규칙:
배포된 버전으로부터 signed artifact로, 그리고 커밋으로 추적할 수 없는 빌드가 있다면, pipeline이 QA가 필요로 하는 증명 체인에 결여가 있는 것입니다. __CAPGO_KEEP_0__ : commit, __CAPGO_KEEP_1__ : app
Capacitor 팀에게는 Live Update 도구가 검증과 배포 간의 격차를 줄일 수 있습니다. 테스트된 웹 번들이 스테이징 환경으로 이동할 수 있으며, native 바이너리 재빌드 없이 native shell이 변경되지 않았을 때 iteration 속도가 훨씬 빠릅니다. 연속적 통합 설정 이 가이드는 CI가 자동으로 올바른 채널에 유효한 번들을 게시할 수 있도록 하기 때문에 여기서 관련이 있습니다.
간단히 말하면 CI CD는 "빌드가 성공했는가?"라고 물어보지 말아야 합니다. "이 정확한 아티팩트가 올바른 환경에서 올바른 게이트 앞에 있는 사용자에게 올바른 검증을 통과했는가?"라고 물어보야 합니다.
late-stage 통합 검사 추가
외부 시스템이 참여하는 경우 일부 실패는 나타나지 않습니다. 특히 인증 제공자, 결제 게이트웨이, 푸시 토큰, SMS 인증 흐름과 같은 경우 end-to-end 패스가 도움이 됩니다. 플랫폼 워크플로우에서 통합 테스트 커버리지에 대한 더 광범위한 참고 자료가 필요하다면 SMS Activate 통합 테스트 가이드 외부 의존성을 명시적으로 검증하는 대신에 희망에 의존하지 말라는 것을 기억하는 데 도움이 됩니다.
pipeline이 이와 같이 구축되면 QA는 별도의 절차가 아닌 배달 자체가 됩니다.
스테이징, 캐니, 및 phased 롤아웃의 추측 없이
스테이징, 캐니, 및 phased 롤아웃은 상호 교환할 수 없습니다. 그들은 서로 다른 문제를 해결하고, 팀이 하나를 다른 세 가지로 사용할 때 문제가 발생합니다. 건강한 품질 보증 프로세스 이러한 전략들을 별도의 릴리스 전략으로 다루고 별도의 폭파 반경과 별도의 의사 결정 지점을 가지고 있습니다.
릴리스 단계의 각 목적
스테이징 생산 이전의 마지막 완전한 신뢰도 점검입니다. 스테이징은 가능한 한 생산과 유사해야 하며, 팀은 빌드, 데이터 흐름, 및 릴리스 패키징을 현실적인 조건 하에서 검증할 수 있습니다.
캐니리 작은 실제 사용자 조각에서 배운다. 캐니리는 스테이징이 놓치고 있는 장치 및 네트워크 관련 문제를 노출한다. 왜냐하면 세상은 어떤 전제 환경보다 더 복잡하기 때문이다.
스테이지드 롤아웃 신호가 건강하게 보이는 첫 번째 신호가 나면 점진적으로 노출을 확대한다. 이는 사용자 전체를 단일 릴리스 결정에 베팅하지 않고 폭파 반경을 확대하는 가장 안전한 방법이다.
Capgo-style 채널이 롤아웃 전략과 어떻게 매핑되는지
라이브 업데이트 도구에 대한 채널 디자인은 중요합니다. 하나의 채널은 내부 QA를 위해 사용할 수 있고, 다른 채널은 베타 그룹을 위해 사용할 수 있으며, 세 번째 채널은 첫 번째 생산 wave를 위해 사용할 수 있으며, 네 번째 채널은 오로지緊急 롤백을 위해 사용할 수 있습니다. 이러한 분리 덕분에 엔지니어링 및 지원 팀은 새로운 스토어 제출을 기다리지 않고 위험을 분리할 수 있습니다.
이것은 또한 목표 장치 할당이 도움이 되는 곳입니다. 특정 사용자 또는 장치가 디버깅이 필요할 때, 채널을 설정할 수 있습니다. 그 경우, 나머지 기본 버전은 알려진 좋은 버전으로 유지됩니다. Capgo은 Capacitor 앱에 대한 목표 질적 보증 흐름을 지원합니다. 이는 버그가 복제하기 어려울 때, 한 장치만 관찰하고 다른 모든人的 릴리스 상태를 변경하지 않도록 유용합니다.
품질 보증 기준이 명확해야 합니다.
빌드는 증거가 그것이 진행될 수 있는지 말할 때만 진행되어야 합니다. 일반적으로 이는 이전 단계가 정의된 검사에서 통과했으며, 새로운 충돌 패턴이 나타나지 않았으며, 지원 큐가 동일한 불만으로 채워지지 않았습니다. 신호가 불분명한 경우, 빌드를 그대로 유지해야 합니다.
단순한 승진 규칙이 있습니다:
- 내부 QA에서 스테이징정확한 아티팩트가 스모크 체크와 중요 사용자 흐름을 통과한 후에만.
- 스테이징에서 캐니전체 신뢰도 환경이 예상 동작과 일치하는 경우에만.
- 캐니에서 phased 롤아웃초기 사용자가 안정적인 동작을 보여주고, 지원 팀이 릴리스를 단순한 용어로 설명할 수 있는 경우에만.
- phased 롤아웃에서 전체 생산생산 관찰성이 오랫동안 깨끗한 경우에만.
그것이 제거하는 추측의 부분입니다. 홍보는 증거에 기반한 결정이 되고, 진행의 축하가 아니라 됩니다.
사용자가 문제를 신고하기 전에 문제를 잡아내는 관찰성 및 지표
릴리스가 출시되면 QA는 사라지지 않는다. 그것은 모양을 바꾸고 있다. 운영 중인 시스템의 관찰 가능성은 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.
관찰성 및 지표
대시보드가 실패할 때는 nobody가 응답을 소유하지 않습니다. 각 지표는 소유주, 경고 조건 및 표준 다음 단계가 필요합니다. 업데이트 실패가 급증하면 somebody가 채널을 일시 중단, 패키지를 롤백하거나 새로운 핫픽스를 배포해야 합니다.
실용적인 설정은 다음과 같습니다:
- 크래시 및 오류 모니터링앱 불안정성을 빠르게 감지하기 위해.
- 업데이트 수용 추적사용자가 수정된 패키지를 받는지 여부를 확인하기 위해.
- 실패율 경고지원 백로그가 증가하기 전에 나쁜 패키지를 잡기 위해.
- 장치별 드릴다운팀이 광범위한 실패와 플랫폼별 노이즈를 분리할 수 있도록.
대시보드는 결정을 변경할 때만 유용합니다. 그렇지 않으면 그것은 더 많은 탭이 있는 스크린샷입니다.
피드 생산은 다음 릴리스에 신호를 되돌려줍니다.
최고의 QA 팀은 배포 후 데이터를 새로운 테스트로 변환합니다. 특정 장치 클래스가 업데이트를 적용하지 못한 경우, 해당 경로에 대한 유효성 검사 케이스를 추가합니다. 네트워크 재시도가 하나의 플랫폼에서 나쁘게 행동한 경우, 다음 테스트 계획에 실패 모드를 포함시킵니다. 그게 관찰 가능성이 품질의 입력이 아닌 오페레이션 사이드바가 아닌 품질이 되는 방법입니다.
Capgo의 장치별 로그와 채널 가드레일은 출시 후 릴리스 프로세스가 설명 가능해야 하는 팀에 적합합니다.
사고 복구, 롤백, 올바른 교훈을 얻기
품질 보증 프로세스가 실제인지 증명하는 것은 나쁜 릴리스가 발생한 순간입니다. 팀이 강력한 계획, 합리적인 테스트 커버리지, 깨끗한 PIPELINE을 가지고 있으면, 빠르게 복구할 수 없거나 실수를 배운다면 모든 가치가 사라집니다. 그 때문에 사고 대응이 QA에 속해야 하며, 그 옆에 있어야 하는 것은 아닙니다.
사고를 분류하고 설명하기
릴리스가 나쁘면 첫 번째 작업은 범위 확인입니다. 장치의 subset이 특정화되었는지, 하나의 버전과 관련되었는지, 전체 사용자에게 영향을 미치는지 확인합니다. 그게 명확해지면 팀은 롤백, 채널 일시 중단, 또는 수술적 핫픽스를 선택할 수 있습니다.
라이브 업데이트 플랫폼에서 자바스크립트 또는 CSS 변경은 앱 스토어 또는 플레이 리뷰를 기다리지 않고 몇 분 안에 롤백할 수 있습니다. 이는 팀이 확산을 멈출 수 있는 속도와 경험의 차이로 종종 결정됩니다. 사고 대응 가이드 사고 대응 가이드는 팀이 운영 절차를 더 깨끗하게 관리하기 원한다면 해당 단계의 운영 매뉴얼을 제공하는 올바른 동반 참고 자료입니다.
사고 후 분석을 작성하여 행동을 바꾸세요
사고 후 분석 문서는 단순한 원인 분석만으로는 충분하지 않습니다. 관찰한 내용, 사용 가능한 신호, 첫 번째 잘못된 가정, 이슈를 이전에 잡을 수 있었던 신호를 기록해야 합니다. 동일한 유형의 결함이 다시 발생할 수 있다면 문서는 변경된 수락 기준, 새로운 테스트 케이스, 또는 CI 게이트를 생성해야 합니다.
사용 가능한 분석 결과에는 다음과 같은 항목이 포함됩니다:
- 수정된 수락 기준원래 요구 사항이 너무 추상적이었다면.
- 새로운 회귀 테스트실패가 기술적으로 예방할 수 있었다면.
- 배포 경계 장치이슈가 스테이징에서 더 오래 머물러야 했다면.
- A 지원 메모입니다.만약 고객 대면 팀이 다음 번에 더 나은 스크립트가 필요하다면.
실용적인 규칙: 포스트 모템이 게이트, 테스트, 또는 롤아웃 규칙을 변경하지 않는다면, 그것은 그냥 문서일 가능성이 높습니다.
그런 학습 루프가 성숙한 QA와 릴리즈 극장의 차이입니다. 릴리즈가 실패했고, 팀이 그것을 포함했고, 프로세스가 약한 곳에서 더 엄격해졌습니다.
Capgo은 팀이 그 루프를 짧게 만들 수 있도록 라이브 업데이트, 채널을 대상으로, 릴리즈 소유자가 장치 수준에서 오류가 발생했을 때 시야를 제공합니다. CapacitorJS 또는 Electron 앱을 위한 더 안전한 품질 보증 프로세스를 구축하려면 Capgo을 방문하세요. 품질 보증 프로세스 CapacitorJS 또는 Electron 앱의 경우 방문 Capgo 작성자
