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

이상적인 지속적 통합은, 코드가 빌드되면 모든 자동화 테스트가 수행되어 '소프트웨어가 잘 작동하는지'와 '코드 변경에 의해 문제가 생기지 않았는지'를 확인한다 위 조건에 부합하기 어렵게 만드는 지속적 통합의 2가지 목적이 있다 1. CI 프로세스는 빠른 피드백을 얻기 위해 자주 수행되어야 한다 2. 매 빌드마다 전체 코드를 검증해야한다 자동화 테스트 설계, 구현, 유지에 있어서 깊은 주의가 필요하며, 하루에 여러번 실행되는 CI 프로세스에 모든 자동화 테스트를 수행하기에는 너무 오래 걸릴 수가 있다 이러한 문제점에 대한 여러 해결책들을 알아보도록 하자 1. 리스크 기반 테스트(RBT) 접근법을 적용하여, '기본 & 중요 테스트'를 우선 순위로 지정하고 항상 수행 리스크 기반 테스트는 제품의 특성(feat..

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

소프트웨어 테스트 유형 중 하나인, API 테스트 API를 직접 테스트 통합테스트(Integration testing)의 일부로서, API가 기능성, 안정성, 성능 및 보안에 대한 기대를 충족시키는지에 대해 확인 API 테스트는 메세지 계층에서 행해짐 (API에는 GUI 존재 X) 애플리케이션 로직을 매우 빠르고 효과적이게 검증할 수 있음 API 테스트는 자동화 테스트와 CI/CD 프로세스에서 중요하게 여겨진다. 짧은 릴리즈 주기과 빈번한 변경, 특히 테스트 출력(output)을 손상시키지 않고, 프레젠테이션 계층에 대처 UI 자동화 테스트에 비해 유지/관리 노력이 덜 필요하므로, 애자일 및 데브옵스에서 선호 웹/모바일 애플리케이션에서는, API = 웹 서비스 API 테스트 = 웹 서비스에 수행되는 자동..

Testing Quadrants 브라이언 머릭이 정의한 4분면으로 이루어진 테스트 유형/레벨 분류 모델 테스트 목적의 2가지 측면에 연관 팀 서포트 vs. 제품 비판 기술 측면 vs. 비즈니스 측면 테스팅 사분면은 각 테스팅 레벨을 애자일 방법론에서 사용하는 테스팅 유형으로 잘 분류하고 있으며, 모든 중요한 테스트 유형 및 레벨이 개발 수명 주기에 포함되어 있는지 확인하는데 도움이 된다. 또한, 이 모델은 개발자, 테스터, 업무 대표자 등 모든 이해관계자에게 테스트의 유형을 구별하고 설명하는 방식이 된다. 1 사분면 단위 레벨, 기술적 측면이며, 개발자를 지원한다. 여기에는 단위 테스트가 포함된다. 1 사분면의 테스트는 자동화되어야 하고, 지속적인 통합 절차에 포함되어야 한다. 통합된 개발 환경에서 적절..

테스트 설계 기법 테스트 케이스를 도출, 설계하는데 사용하는 절차 테스트 컨디션, 테스트 케이스, 테스트 데이터를 식별 테스트 케이스를 도출하고 테스트 대상이 어느 수준까지 테스팅되었는지 확인 (보장성 확보) 기법 선택 요인 테스트 대상 시스템의 종류 컴포넌트/시스템의 복잡도 규제 기준 고객/계약 요구사항 유즈케이스 모델 리스크 수준/유형 사용 가능 문서 테스터 지식 및 역량 사용 가능 문구 시간, 예산 소프트웨어 개발 수명주기 예상되는 결함 유형

테스트 프로세스를 구성하는 주요 활동 테스트 계획 - 테스트 모니터링 및 제어 - 테스트 분석- 테스트 설계 - 테스트 구현 - 테스트 실행 - 테스트 완료 테스트 계획 테스팅의 목적 & 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동 적합한 테스트 기법 및 작업 명시 테스트 일정 수립 작업산출물 = 하나 이상의 테스트 계획 (+ 테스트 베이시스에 대한 정보 포함) 테스트 모니터링 및 제어 테스트 계획에 정의된 테스트 메트릭을 기반하여 모니터링 → 실제 & 계획을 지속적으로 비교 시간이 지나면서 업데이트 될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행 + 테스트 종료 조건 평가 (명시된 커버리지 조건 대비 테스트 결과 & 로그 확인 - 품질 수..

사전적 정의는 이러하다 점진적 개발 모델 (Incremental Development Model) 프로젝트 범위는 일반적으로 프로젝트 수명주기 초기에 결정되고, 시간 및 비용 견적은 제품에 대한 프로젝트팀의 이해도가 높아지면서 정기적으로 수정되는 개발 수명주기 모델. 제품은 일련의 반복되는 주기들을 거쳐 개발되며, 각 주기는 제품 기능에 무언가를 성공적으로 추가하는 증분을 전달함. 반복적 개발 모델 (Iterative Development Model) 한 프로젝트를 다수의 이터레이션(iteration)으로 세분화하는 개발 수명주기 모델. 하나의 주기는 하나의 완전한 개발 과정이며, 매 주기 결과로 실행 가능한 제품이 내부 혹은 외부로 릴리스된다. 이런 릴리스는 개발 중인 최종 제품의 하위 서브 셋이며, ..

Gitflow 워크플로 프로젝트 릴리즈를 중심으로 설계된 엄격한 branch 모델 대규모 프로젝트를 관리하기위한 강력한 프레임워크 제공 예정된 릴리즈 주기가 있는 프로젝트에 이상적 전반적 흐름을 살펴보자면, 1. master 브랜치 → develop 브랜치 생성 1개의 master 브랜치대신, 프로젝트 히스토리를 기록하기 위해 2개의 브랜치 사용 master: 공식적인 릴리즈 히스토리 저장 develop: features에 대해 통합(integration) 브랜치 역할 개발자가 로컬에서 빈 develop 브랜치를 생성하고, 서버로 푸시 git branch develop git push -u origin develop → -u: 최초에 한 번만 저장소명과 브랜치명을 입력함 (이후 생략) 2. develop..

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