QA best practices
1.0.0
이것은 Futurice가 사용하고 사용하는 것을 권장하는 QA 관행의 요약입니다. 그것은 자세한 설명이 아니며 때로는 모든 작업에 완전히 사용될 수는 없지만 가장 중요한 QA 프로세스와 사용해야 할 모범 사례 목록으로 완전히 사용될 수는 없습니다.
명확성의 목적을 위해이 문서는 오류 또는 입사 프로세스를 설명하지 않습니다 (즉, 새로운 버그는 생산에서 발견됩니다).
Futurice 팀의 모든 사람은 이름이 지정된 QA 관리자 또는 QA 전문가가 있더라도 QA 책임이 있습니다. 미래의 QA는 세 가지를 의미합니다.
높은 수준의 QA 작업 및 관행은 두 가지 프로세스로 나눌 수 있습니다.
또한 다른 QA 조치가 있습니다.
Futurice는 해당되는 경우 TDD 및 ATDD (수락 테스트 중심 개발) 방법을 사용합니다.
방법은 구현이 아키텍처를 따르고 사용되는 모듈을 고려하도록 강요합니다. 구현은 자동화 된 테스트를 먼저 작성한 다음 테스트를 통과하기 위해 기능을 구현하여 시작합니다.
Futurice는 해당되는 경우 쌍 프로그래밍 방법을 사용합니다. 이것은 개발중인 프로젝트 및 소프트웨어에 대한 지식과 경험을 공유하는 매우 편리한 방법입니다.
코드를 검토하면 다른 팀 구성원이 특정 기능에 대한 정보를 얻을 수 있으며 책임있는 사람에게 피드백을 제공 할 수 있으며 팀 구성원 간의 지식 공유를 보장합니다.
수동 테스트는 주로 탐색 테스트 방법론을 사용하여 수행되며 발견 오류는 즉시 수정되거나 우선 순위를 정하고 작업/스토리/오류 관리 도구에 기록됩니다. 기능적 인 것이 "준비된"후에 앱이나 서비스를 탐색하는 것은 바로 시작할 수 있습니다.
탐색 테스트는 전체 시스템이 테스트로 덮여있는 최종 테스트에서 끝까지 매우 강력한 도구입니다. 메소드 테스터는 테스트 사례에서 정의 할 수있는 것을 넘어서고, 사용자와 같은 사고를 적용하고 다양한 오류 시나리오로 시스템을 깨뜨 리려고 시도하며 테스트로 "완료"되지 않습니다.
기능적 요구 사항 및 테스트 주변에는 일반적으로 현지화, 유용성, 성능 및 부하 테스트를 적용하여 테스트 할 수있는 비 기능적 요구 사항이 있습니다. 요구와 도구는 프로젝트에 따라 다릅니다. 유용성 테스트를 위해 Futurice에는 사용용 모바일 유용성 랩이 있습니다. 성능 테스트의 경우 Futurice는 Browsermob과 같은 웹 기반 서비스를 사용하여 이름을 지정했습니다. 로드 테스트의 경우 LoadUi 및 J Meter는 적극적으로 사용 중이며 트래픽이 높은 서비스 기능을 검증하고 가능한 서비스 병목 현상을 찾기 위해 사용됩니다.
발견 된 문제는 우선 순위, 환경 (소프트웨어 및 장치 정보), 재현, 예상 결과, 시간 및 날짜 및 스크린 샷과 같은 정보가있는 특정 도구 또는 보드에 기록됩니다. Jira, Trello, PivotalTracker, 요청 추적기와 같은 도구는 오류 추적에도 적극적으로 사용됩니다.
Agile의 원칙 중 하나는 마스터 코드 브랜치가 항상 잠재적으로 선적 할 수 있어야한다는 것입니다. 그것은 항상 생산 품질이어야한다는 것을 의미합니다. 이것은 다음 수단으로 달성됩니다.
각 사용자 스토리 (또는 기능)는 자체 기능 지점에서 개별적으로 개발됩니다. 이것의 목적은 마스터 브랜치에 대한 각 업데이트가 동시에 1) 가능한 한 작고 2) 잠재적으로 전환 가능하고 완전한 이야기를 보장하는 것입니다.
기능 분기를 마스터 브랜치로 병합하기 전에 Dod (DoD)의 정의라는 조치, 요구 사항 및 관행 목록을 전달해야합니다. 이는 고객 PO 및 개발 팀과 함께 정의되며 프로젝트가 변경 해야하는 경우 프로젝트 중에 수정할 수 있습니다.
제안 된 DoD의 품목을 따르는 항목은 대담하게되었습니다
배포 프로세스는 새로운 릴리스 (또는 마스터 브랜치의 버전)가 생산에 배포되는 프로세스입니다. 이 과정에는 세 가지 관련 환경이 있습니다.
CI (Continuous Integration) 서버는 자동화 된 테스트 및 환경에 코드를 배포하는 데 사용됩니다. 이러한 환경이 업데이트 될 때 자동 테스트는 항상 실행됩니다.
마스터 브랜치가 업데이트 될 때마다 테스트 환경은 CI에 의해 자동으로 업데이트됩니다. 즉, 자동화 된 테스트 케이스는 마스터 브랜치가 업데이트 될 때 자동으로 실행됩니다.
테스트 환경은 Futurice의 주요 테스트 서버입니다. 여기서 테스트 된 릴리스는 QA 또는 생산으로 밀려날 준비가되어있을 것으로 예상됩니다 (이는 프로젝트에 사용 된 용어 및 통합에 따라 다름).
테스트 업데이트시 수동 회귀 테스트 케이스를 실행할 필요는 없습니다. 탐색 테스트에 소요되는 시간은 종종 더 유익합니다. 그러나 스프린트 당 적어도 한 번은 이러한 테스트를 실행하는 것이 좋습니다.
QA 환경은 승인 테스트, 데모 또는 타사 테스트 또는 감사 (보안, 현지화, 부하, 유용성 등)를위한 환경으로 사용해야합니다. 이것은 Futurice의 기본 테스트 서버가 아닙니다 (테스트 IS). QA에 대한 업데이트는 항상 고객과 Futurice의 PMS간에 합의됩니다.
두 가지 테스트 환경 (테스트 및 QA)이있는 주된 이유는 보안 및 통합 요구 사항을 준수하기 때문입니다. 테스트를 통해 Futurice는 민첩한 원칙을 사용하여 서비스를 개발할 수 있습니다. QA는 고객이 현재 QA 프로세스를 실행할 수있는 시간과 제어를 허용합니다.
릴리스가 테스트 환경에서 테스트를 통과하지 않으면 QA를 업데이트해서는 안됩니다.
Prod 환경은 라이브 사이트 (생산)의 환경입니다.
모범 사례는 업데이트를 Prod로 푸시하기 전에 최소한 QA로 자동 테스트를 배포하고 실행하는 것입니다. 그러나 Prod에서는 모든 배포 후 주요 기능을 점검해야합니다.
PO는 QA에서 테스트하지 않고 (버전이 테스트에서 전달되는 경우) PO는 ProD로 업데이트를 푸시 할 권리가 있습니다. 이것은 업데이트가 매우 작거나 간단한 경우에 관련이 있습니다.
궁극적으로 Agile Development에서 서비스가 지속적으로 개발 될 때 목표는 많은 소규모 업데이트를 Prod로 만드는 것입니다. 즉, 배포 프로세스가 방탄보다 적고 빠른 것이 더 중요합니다. 버그가없는 서비스를받는 것보다 빠르게 수정할 수있는 것이 더 중요합니다 (DoD 및 자동 테스트를 통해 품질도 높아야합니다). Futurice는이 접근법을 즉시 시작하지 않는 것이 좋습니다. 그러나 이것은 두 조직이 가고 싶어하는 방향이어야합니다.
각 모바일 플랫폼에는 특정 SDK, 도구 세트 및 Futurice의 모범 사례가 있습니다.
Android https://github.com/futurice/android-best-practices 용
iOS 용 https://github.com/futurice/ios-good-practices
Windows의 경우 https://github.com/futurice/windows-app-development-best-practices
모바일 플랫폼은 SDK 내에서 에뮬레이터를 제공합니다.
구현 단계에서 개발자는 시뮬레이션 / 에뮬레이션 장치를 사용하여 변경 사항을 검증 할 수 있지만 터치 스크린 및 통합 메모리에서 모바일 프로세서로의 전체 시스템이 고려되는 실제 장치 테스트를 이길 수는 없습니다.
모바일 브라우저는 Browserstack과 같은 클라우드 기반 서비스로 테스트 할 수도 있습니다.
Futurice는 기본 전화에서 고급 태블릿에 이르기까지 장치 라이브러리에 다양한 장치와 운영 체제 버전을 보유하고 있습니다.
무거운 데이터 트래픽 응용 프로그램 테스트 및 성능 검증 미래는 ELISA Test Lab을 사용하고 있습니다 (ELISA는 핀란드 모바일 서비스 제공 업체입니다). 실험실 환경 내에서는 효과적인 현장 테스트 세션이 아닌 비싸지 않고 제어 / 분리 된 환경에서 다양한 하중과 속도를 테스트 할 수 있습니다.
일반적으로 모바일 앱은 모바일 네트워크를 통해 백엔드 서비스에 연결됩니다. 테스트를 최대한 활용하려면 테스터는 다른 끝에서 종료 테스트 시나리오를 준비하고 실행하기 위해 모바일 애플리케이션이 연결된 백엔드를 완전히 제어해야합니다.
모바일 장치에서는 테스트 빌드 설치를 수행 할 수 있습니다. 로컬로 로컬로 개발 된 개발 SDK 도구는 TestFlight 또는 HockeyApp와 같은 빌드 배포 도구를 통해 무선으로 제어되는 SDK 도구입니다. 릴리스 프레임 워크는 일반적으로 충돌 로그 수집 및 버전 데이터를 지원합니다. 신청서를 매장에 공개하기 전에 피드백을 수집하기 위해 Dev, Alpha 및 Beta 릴리스를 제공 할 수도 있습니다. Google Play 스토어에는 그룹 구성원에게만 특정 앱을 사용할 수있는 알파 및 베타 테스트 그룹을 설정하는 옵션이 있습니다.
최신 모바일 애플리케이션에서 분석 및 데이터 수집은 테스트가 필요한 중요한 기능을 나타냅니다. Futurice는 이것을 기능 테스트의 중요한 부분으로 간주합니다.
모바일 앱 업데이트 프로세스가 웹 앱과 다르기 때문에 분석 설정은 첫 번째 시도에서 바로 가져와야합니다. 업데이트 프로세스는 응용 프로그램 저장 절차를 통해 수행되지만 업데이트가 수행되는지 여부는 사용자 설정 및 활동에 달려 있습니다. 따라서 첫 번째 버전이 일부 중요한 분석 기능을 놓치고 일부 사용자가 응용 프로그램을 업데이트하지 않으면 해당 데이터를 놓치게됩니다. 솔루션은 사용자가 사용 가능한 최신 버전으로 업데이트 될 때까지 앱을 사용할 수 없게되지만 너무 늦을 수 있습니다.
