"Zero Defects"라는 용어는 프로세스에서 버그와 문제의 수를 줄이고 최소화하여 처음부터 올바르게 작업을 수행하는 것을 목표로 하는 QA/QC 개념입니다. 주요 아이디어는 실수가 발생한 후에 수정하는 것이 아니라 실수가 발생하지 않도록 방지하는 것입니다. 이 개념은 Philip Crosby가 1979년에 쓴 저서 “Quality is Free”에서 처음 소개되었습니다.
무결점의 핵심은 완벽함을 달성하는 것이 아니라, 그 표준을 일관되게 충족할 수 있는 메커니즘을 구현하는 표준을 설정하는 것입니다. 무결점은 정의된 단계가 있는 특정 프로세스가 아니라 팀/회사 전체에 수용되어야 하는 사고방식 또는 개발/기술 문화입니다. 여기에는 지속적인 개선 프로세스, 높은 품질 문제 비용 인식, 앱 및 개발 프로세스의 버그 식별 및 수정을 위한 적극적 작업이 포함됩니다.
무결함 달성이라는 개념은 실제 프로젝트 사례에서 현실보다는 이상에 더 가깝습니다. 대신, 비즈니스/사용자/시스템에 영향을 미치는 결함, 특히 앱 기능을 손상시킬 만큼 중요한 결함을 최소화하는 쪽으로 초점이 이동합니다. 이 접근 방식은 비용이 많이 드는 오류를 완화하기 위해 프로젝트 초기부터 품질 우선 순위를 지정하는 것이 중요하다는 점을 강조합니다.
고품질 표준을 달성하는 방법은 무엇입니까?
- QA 전문가가 회귀 테스트를 실행합니다.
회귀 테스트가 중요합니까?
- 예.
충분한가?
- 좋은 출발점이지만 더 높은 소프트웨어 품질과 더 효과적인 프로세스를 위해 더 많은 일을 할 수 있습니다.
각각의 새로운 빌드/커밋/스테이징 배포와 함께 자동으로 트리거되는 자동 테스트/스크립트는 변경 사항/수정 사항이 테스트되고 검증되도록 합니다. 이러한 통합은 지속적인 개선과 빠른 결과 문화를 가져옵니다. 팀은 SDLC 초기에 문제/버그를 감지하고 해결할 수 있습니다. 민첩한 방법론 프로세스를 도입하여 더 빠른 속도로 고품질 소프트웨어를 제공하는 데 도움이 됩니다.
다양하고 현실적인 테스트 데이터 세트의 가용성을 보장하면 테스트 범위와 앱 기능 검증이 향상됩니다. 테스트를 위해 데이터 생성 도구(사용자 정의 또는 자체 작성) 또는 난독화된 프로덕션(실제 사용자) 데이터를 사용하면 효과적인 테스트 시나리오 생성을 향상시킬 수 있습니다. 데이터 마스킹/난독화를 사용하면 테스트 중에 민감한 정보를 보호하고 데이터 보호 및 보안 정책을 준수할 수 있습니다.
회귀 테스트를 탐색적 테스트와 결합하거나 대체하면 테스트 범위가 향상되고 특이한 회귀 결함을 발견할 수 있습니다. QA 엔지니어는 도메인 지식과 직관을 사용하여 앱을 탐색하여 회귀(자동 테스트) 테스트에서 누락되었을 수 있는 "숨겨진" 문제/버그를 찾을 수 있습니다. 이 민첩한 결합 접근 방식은 팀이 표준 회귀 테스트에서 쉽게 놓칠 수 있는 복잡하고 까다로운 문제와 특수 사례를 찾는 데 도움이 됩니다.
성능 및 보안 테스트와 기능 회귀 테스트를 결합하는 것은 앱 성능 및 보안 문제를 놓치지 않는 데 중요합니다. 이는 앱 성능 및 보안 테스트의 표준이지만 중요한 변경이 이루어지고 앱 성능이 영향을 받을 수 있거나 시스템에 새로운 취약점이 도입될 수 있는 경우 회귀 테스트로 수행됩니다.
크로스 브라우저(크로스 플랫폼/디바이스) 테스트를 사용하면 QA 엔지니어는 다양한 브라우저, 버전, OS, 디바이스(하드웨어) 및 화면 해상도에서 앱 기능과 레이아웃을 검증할 수 있습니다. 이러한 유형의 테스트는 시간이 많이 걸릴 수 있으므로 합리적인 범위를 이해하고 필요한 테스트만 수행하는 것이 중요합니다. 그러나 BrowserStack과 같은 플랫폼이나 자체 디바이스 팜 + 자동화를 사용하면 더 빠를 수 있습니다. 그러나 예를 들어 API 회귀 또는 기능 회귀 테스트보다 더 많은 리소스가 필요하므로 주의를 기울여 변경 사항과 입증된 위험에 따라 범위를 최적화하세요.
잠재적인 회귀 위험을 식별하고 기능 구현/코드 변경의 초기 단계에서 회귀 테스트 활동을 계획합니다. 이러한 초기 참여를 통해 개발팀과 QA팀 간의 협업이 설정되어 재작업, 버그 수정, 테스트 반복 횟수, 추가 회귀 테스트가 최소화되고 출시 기간이 단축됩니다.
그 밖에 유용할 만한 것이 있나요?
- 물론! 모범 사례를 사용하더라도 접근 방식과 제품 품질을 개선하는 데 사용할 수 있는 다른 것이나 새로운 것이 항상 있습니다. 모든 접근 방식에는 특정 프로젝트, 팀 및 상황에 대한 적응과 조정이 필요했습니다.
이는 분산 시스템 분야에서 나온 것입니다. 이는 약점과 실패를 밝혀내기 위해 시스템에 통제된 혼돈을 의도적으로 도입하는 것을 포함합니다. 전통적으로 탄력성 테스트에 사용되었지만 카오스 엔지니어링을 회귀 테스트에 적용할 수 있습니다.
회귀 테스트에서 카오스 엔지니어링은 소프트웨어를 프로덕션 환경과 유사한 예측할 수 없는 다양한 조건/데이터 세트에 적용합니다. 네트워크 연결, 종속성 또는 인프라와 같은 일부 구성 요소를 의도적으로 방해/변경함으로써 테스터/개발자는 앱이 예기치 않은 입력에 어떻게 반응하는지 확인할 수 있습니다.
Chaos Engineering을 회귀 테스트 프로세스에 통합하면 최종 사용자 또는 이후 단계의 테스트 프로세스에 영향을 미치기 전에 잠재적인 회귀 위험/버그를 식별하고 수정할 수 있는 추가 방법이 제공됩니다.
돌연변이 테스트는 잠재적인 버그를 시뮬레이션하기 위해 소스 코드를 약간 변경하는 기술입니다. 체크리스트/테스트 사례가 이러한 변경 사항/버그를 얼마나 잘 감지하는지 평가함으로써 QA 엔지니어는 회귀 테스트의 효율성을 평가할 수 있습니다. 이 접근 방식은 테스트 스위트의 효율성에 대한 정보를 제공하고 추가 변경이 필요한 사례/영역을 보여줍니다.
회귀 결함의 근본 원인을 식별하기 위해 기계 학습 알고리즘을 사용하는 도구는 회귀 테스트 전략에 매우 유용할 수 있습니다. 이러한 도구는 코드 변경 사항, 테스트 결과 및 시스템 로그를 분석하여 회귀 원인을 제안할 수 있습니다. 이 접근 방식은 버그 예방 및 해결 속도를 높이고 조사에 소요되는 시간을 줄여 전반적인 생산성과 출시 기간을 향상시킵니다. AI 기반 도구/알고리즘은 코드 변경 사항과 테스트 결과(통계)를 분석하여 실행에 가장 관련성이 높은 테스트를 식별할 수도 있습니다.
위험을 이해하고 회귀 버그에 관한 통계를 알아야 한다는 점을 항상 기억하세요. 제품 팀에서는 모든 팀 구성원(개발자, QA, PM, PdM/PO/FO, DevOps 등)이 협력하여 잠재적인 위험을 효과적으로 평가하고 회귀 영역을 최소한으로 좁힐 수 있습니다. 빠른 배송을 위해 일정 수준의 위험을 감수하는 것도 중요합니다. 거의 사용되지 않거나 중요하지 않은 기능의 회귀 버그는 나중에 허용되고 수정될 수 있습니다.
단지 "이상적인 품질"이나 Zero Defects 개념을 위해 과잉 테스트를 피하십시오.