dev + qa = hq sw dev + qa = hq sw

요구사항 수집 및 분석 단계 가장 신경써야하는 QA 활동 단계 (조기 식별 및 해결 = 비용, 리스크 ↓) 고객 또는 비즈니스 요구사항에서 품질 목표를 도출 고객 및 비즈니스 요구사항 → 품질, 테스트 요구사항 (테스트 관점에서 재정의) 기능성 & 비기능성 요구사항 분류 테스트 요구사항 정의서 작성 (= 모든 품질 활동의 주축) 설계 단계 테스트 아키텍처, 리스크 분석, 품질 목표 설정 테스트 계획서 작성 구현 단계 정적 분석 (표준 및 형상관리 검증) 테스트를 위해 이슈 분석 및 관리 단위 테스트 & 통합 테스트에서 발견되는 버그 → 이슈 이슈 해결에 따라 테스트 아키텍처 및 설계 보완 (+ 리스크 확인) 테스트 단계 시스템 테스트 & 인수 테스트 수행 고객에게 제품 전달 또는 공식 배포까지 품질 상태..

Fork Clone Git 저장소(Github나 Bitbucket 등)를 통해 가능 Git을 통해 가능 (git clone) 내 계정으로 repo를 복제 로컬 머신으로 repo를 복제 원본 repo, fork repo 원본 repo, local repo fork repo에서 변경사항(commit) 생성 내가 추가/수정한 사항을 원본 repo에 포함하고 싶은 경우, fork repo에서 pull request를 통해 원본 repo로 변경사항 보내기 원본 repo에서 merge 할 지 결정 및 merge (merge 커밋 자동 생성) merge된 경우, fork repo에서 sync (원본 repo = fork repo) 원본 repo로 변경사항 바로 push 가능 (권한이 있을 경우) 권한이 없을 경우, ..

Jira는 자동화 테스트 프레임워크와 직접적 통합 X Option 1 처리 CI 서버를 통해서만 테스트 프레임워크와 통합할 수 있음 Jira에는 테스트 관련 기능 없음 (Jira 플러그인으로 해결 가능) Option 2 Jira에 승인 테스트, 통합 테스트, 기능 테스트 셋업 가능 Jira의 특정 기능 (테스트 케이스 관리에 유용) 버그 및 요구 사항을 Jira 이슈에 연결 수동 테스트에 적합 커스텀 이슈 유형 (테스트 케이스 및 스토리) 버전에 대한 여러 영향 / 수정 자동 및 수동 이슈 할당 워크플로가 QA, 개발자 및 테스터의 작업 제어 수동 테스트를 위한 하위 작업 소스 코드 저장소와 통합 보고 이슈 커멘트 및 첨부 파일 커스텀 가능 imports from 다른 시스템 기존 및 알려진 도구 사용 ..

테스트 베이시스 테스트 분석 및 설계의 기초로 사용되는 지식 체계 테스트 분석, 설계 단계의 논리적인 케이스로 테스트 케이스 설계를 위한 기준이 되는 문서 (ex. 요구사항 명세서, 관련 기준 또는 표준) 요구사항을 내포하고 있는 모든 문서 테스트 컨디션 테스트 베이시스로 식별된 구성 요소 또는 시스템의 테스트 가능한 측면 테스트 케이스에 대한 트랜잭션, 기능 또는 구조적 요소와 같은 기능을 포함할 수 있는 특정 제약 조건 집합 특정 테스트 목적 달성과 관련있는 테스트 베이시스의 한 측면 하나 이상의 테스트 케이스에 의해 검증될 수 있는 컴포넌트나 시스템의 항목 또는 이벤트 (ex. fuction, transaction, quality attribute, 또는 structural element 등) 테스..

용도에 따라 적절한 툴 또는 프레임워크를 사용해야한다 예를 들어, 유닛 테스트와 기능 테스트는 본질적으로 다르다 유닛 테스트는 코드 내의 function과 method에 직접적으로 접근할 수 있으며, 기능 테스트는 여러 버전의 제품을 접할 수 있다 → 다양한 테스트 툴/프레임워크/솔루션이 필요 같은 Repository에 저장하는 경우 코드와 유닛테스트는 항상 같은 Repo에 저장되어야 한다 유닛 테스트는 소스코드에 의존 같은 언어로 작성되어야 한다 코드 변경이 있을 시, 유닛 테스트도 업데이트! 같은 언어로 작성 & 모든 소스코드가 한 개의 Repo에 저장되어있다면, 기능 테스트도 코드와 같은 Repo에 저장하는 것을 추천 (함께 버전 관리 가능) 다른 Repository에 저장하는 경우 소스코드와 다른..

Local 환경 컴퓨터에 개발 및 테스트 환경 또는 서버를 셋업한 환경 개발자마다 설치된 서버 환경 모든 개발자가 같은 개발 환경을 사용 다른 개발자들과 충돌 위험 X 환경 구성에 대한 완전한 제어 (개발 및 디버깅에 필요할 수 있는) 로그 파일에 대한 액세스 권한 zip파일 or VM 기반 이미지 배포 or Docker 컨테이너 사용 Development (dev) 환경 서버 개발 환경 코드 업데이트, 모든 커밋/브랜치로 이루어져있는 환경 개별 개발자들이 만든 코드를 합쳐서 서버 환경에서 테스트해볼 수 있는 환경 사용자가 사용하는 환경과 다르게 구성 실제 데이터를 건들이지 않게 코드 작성 (로컬/더미 데이터베이스 연결) 개발자들은 새로운 기능이 어떻게 작동하는지 확인하고, 개선사항을 시도 많은 예비 테..

지속적 통합 (Continuous Integration) 소프트웨어의 모든 변경 사항과 정기적으로 변경된 모든 구성요소를 통합 (최소 하루 한 번) 형상 관리, 편집, 소프트웨어 빌드, 배포 및 테스트를 하나의 자동화된 반복적인 프로세스로 통합 지속적 전달/배포의 일부분 요구사항 새로운 기능, 개선, 버그 수정마다 자동화 테스트 작성 메인 repo를 모니터하고 테스트를 자동으로 실행할 CI 서버/도구 필요 개발자는 가능한 자주 코드 변경에 대한 병합(merge) 필요 장점 지속적 통합, 구축, 테스트 → 결함 빨리 발견 테스트 자동화로 인해 리그레션이 조기에 발견 → production으로 전달되는 버그 ↓ 통합(integration) 이슈 조기 해결 → 쉬운 릴리스 빌드 빌드가 손상되자마자 알려주므로,..

일반적으로 사용할 수 있는 시나리오 예제 풀 리퀘스트(PR)가 생성되면, 테스트 실행 풀 리퀘스트가 develop 브랜치로 병합되면, QA 서버로 배포 풀 리퀘스트가 master 브랜치로 병합되면, production 서버로 배포 예) bitbucket-pipeline.yml (자바스크립트) image: node:15.8.0 pipelines: default: - step: script: - npm run test branches: master: - step: deployment: production script: - npm run test - ./deploy.sh production develop: - step: deployment: staging script: - npm run test - ./dep..