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

소프트웨어 테스트 수명 주기(Software Testing Life Cycle) 소프트웨어 품질 목표가 충족되었는지 확인하기 위해, 테스트 프로세스 중에 수행되는 일련의 특정 활동 (Validation + Verification) 6가지 주요 단계 요구사항 분석 테스트 계획 테스트 케이스 개발 테스트 환경 설정 테스트 실행 테스트 주기 종료 요구사항 분석 (= 요구사항 단계 테스트) 수행할 테스트 유형 식별 테스트 우선 순위 및 초점에 대한 세부 정보 수집 요구사항 추적성 매트릭스 (RTM) 준비 → 결과물: RTM 테스트가 수행되어야하는 테스트 환경 세부 정보 식별 자동화 타당성 분석 (필요한 경우) → 결과물: 자동화 타당성 보고서(Automation Feasibility Report) 테스트 계획 ..

1. 테스트 = 결함의 존재 (결함 없음 X) 테스트는 소프트웨어의 결함을 감지하는데 목적이 있으나, 제품을 아무리 철저히 테스트하더라도 결함이 없다고 100% 확신할 수 없다. 테스트는 발견되지 않은 오류의 수를 '줄이기' 위해서만 사용할 수 있다. 2. 완벽한 테스팅 불가 데이터 입력값, 시나리오, 조건들의 모든 조합들을 테스트할 수 있는 방법은 없다. 예를 들어, 어플 화면이 10개의 입력 필드와 각 3개의 옵션값을 포함하고 있다면, 가능한 모든 조합을 커버하기 위해서는 테스트 엔지니어들은 59,049 (310)개의 테스트 시나리오를 작성해야 한다. 수백만개의 시나리오를 작성하는데 몇 주를 소비하지 않으려면, 더 중요한 시나리오에 집중하는 것이 좋다. 3. 조기 테스팅 오류 비용은 SDLC 단계 전..

이어지는 시리즈 테스트 더블: 소개 테스트 더블: 입력값 테스트 더블: 출력값 더미 객체, 테스트 스텁, 페이크 객체 → 입력값 제공 모의 객체(Mock), 스파이 객체 → 입력값, 세밀한 모니터링 기능 제공 테스팅은 function 출력값을 확인하는 것보다 더 많은 것을 포함한다. 만약, function이 void값을 리턴한다면? 상호작용(interactions)을 테스트할 것! - 올바른 순서대로 메소드가 호출되었는지 - 메소드가 호출 되었는지/안 되었는지 - 메소드 호출에 적절한 파라미터들이 사용되었는지 모의 개체는 페이크 객체들의 상호작용을 관찰할 수 있게 해준다 // Mocking은 객체 간의 상호작용을 결정하는데 사용된다 // AirlineTravelService에 대해 호출되는 메소드를 보여..

이어지는 시리즈 테스트 더블: 소개 테스트 더블: 입력값 테스트 더블: 출력값 입력값으로 사용되는 3가지 1. 더미 객체 테스트 입력을 위해 파라미터로서 필요한 값. 어떤 값인지 중요치 않기때문에 무엇이든 대입한다. null값을 제외하지 않음. 2. 테스트 스텁 여러 값들이 결과값을 제공할 수 있도록 하는 매우 단순화된 특수 목적 객체. 예) 특정 입력값들이 있는 테스트 스텁에 메소드를 호출하면, 결과값을 제공할 수 있다. 3. 페이크 객체 사용함에 있어, 값비싼 것을 저렴한 것으로 대체함. 예) 서버에 실행되는 외부 데이터베이스 → 인메모리 데이터베이스(비용적으로 저렴한 쿼리) 페이크 객체: 테스트 대상인 것처럼 실행되는 새로운 클래스를 작성 더미 객체, 테스트 스텁: 프레임워크(예. Mockito)를..

이어지는 시리즈 테스트 더블: 소개 테스트 더블: 입력값 테스트 더블: 출력값 테스트 더블 (= 영화 스턴트 대역) 시험 대상 시스템(SUT)을 지정하는 클래스 또는 시스템을 테스트하기 위해 필요한 컴포넌트들의 단순화된 버전 테스트 더블을 생성하는 이유? 컴포넌트들이 아직 완성되지 않음 컴포넌트들을 구성하는데 많은 비용이 들어감 컴포넌트들이 제 3자에 의해 소유되어있음 테스팅의 결과로 실제 컴포넌트들에 부작용이 생기는 것을 피하기 위함 항상 잘 실행되지는 않지만 어쩔 때는 괜찮은 테스트(Flakey Tests)들을 방지하는데 도움을 줌 시험 대상 시스템을 세밀한 관찰을 허용함(테스트 결과뿐만이 아닌 컴포넌트들의 상호작용) 테스트 더블은 생태계를 제공한다 더미 객체: 테스트 대상 시스템에서 파라미터로서 필..

유닛 테스팅: 개발자들에 의해 행해지며, 본질적으로 화이트박스 테스팅에 속함. 리스크 기반 접근법으로, 유닛이 궁극적으로 지지하는 상위 레벨 시스템 행동에 집중하기보다는 코드 자체를 공격한다. off-by-one 오류에서 루프의 경계 등을 테스트함. 배열과 그 경계들, 구조상의 또 다른 오류들에도 적용된다. 모듈의 유닛은 그 것의 핵심 기능이 정확한지 확인하기 위해 실행된다. 기능은 유닛 레벨에서 저의되며, 모듈이나 시스템 레벨과는 상관없다. 단위 내부의 결함 제거를 주목적으로 함 구조 기반 (화이트박스 테스트) 설계 기법을 주로 사용 가능한 많은 결함 발견하고자 함 테스트 케이스와 결함을 공식적으로 관리 X (주로, 개발자에게 맡김) 단위 테스트 프레임워크 또는 디버깅 도구의 지원으로 테스트 수행 자동..

REVIEW 소프트웨어 테스팅 과정 단계 유닛테스팅: 개발자가 주로 오류발생이 쉬운 구조와 하위수준 기능성 보증을 위해 본인이 작성한 코드를 테스트하는 것 디자인 검증(verification) 테스팅: 개발자에 의해 실행되는 통합 테스팅을 통해 모듈의 통합을 테스트하고, 테스팅팀 또는 개발자에 의해 완성되는 기능성 테스팅을 포함 시스템 검증(validation) 테스팅: 테스트 팀에 의해 행해지며, 시스템이 완성되거나 개발이 거의 끝나갈 때, 시스템의 상위수준의 행동과 비기능적 퍼포먼스를 테스트하는 것 고객 인수 테스팅: 최종 제품을 고객에게 인수 가능(acceptable)한지 고객과 테스팅 팀이 함께 수행하는 테스팅. 디자인 검증(verification)과 시스템 검증(validation) → 테스트 ..

유닛 테스팅 개발자가 작성한 코드를 테스트하는 것 오류발생이 쉬운 구성, 하위 수준(low-level) 기능성 보증에 사용 개발자가 프로젝트를 하면서 유닛 테스팅 계획 생성 디자인 검증(Verification) 테스팅 개발자가 모듈의 통합을 테스트하는 통합 테스팅 실행 기능성 테스팅은 개발자들 또는 테스팅 팀에 의해 실행 예. 모든 기능성 요구사항들과 외적 요구사항들을 충족시키면서, 예상대로 기능하고 보기 좋은 유닛들을 많이 만들어낼 수 있는가? 시스템 검증(Validation) 테스팅 테스트 팀에 의해 실행 시스템이 완성되거나 개발이 거의 끝나면, 시스템은 상위 수준(high-level) 행동과 비기능적 퍼포먼스를 테스트 디자인 검증 테스트와 시스템 검증 테스트 계획들은 검증 레벨의 "시스템을 올바르게..