블랙박스 테스트 기법 : 개발자 입장이 아닌 사용자 입장에서 바라본 제품의 요구사항이 일치하는지 확인하는 테스트 기법. 명세 기반 기법. 화이트박스 테스트 기법 : 개발자 입장에서 바라본 로직에 대한 설계로 구현이 제대로 되었는지 확인하는 테스트 기법. 구조 기반 기법. 경험 기반 테스트 기법 : 탐색적 테스팅. 테스트 케이스 : 테스트 베이시스를 토대로 만들어짐. 블랙박스와 경험기반 테스트의 주요 차이점은 테스트 베이시스가 다른 거야. 블랙박스는 명세, 경험기반은 탐색.
4.1 테스트 기법 개요 :테스트 설계와 분석에 적용할 활동들을 공부해보자고!
테스트 기법이란? - 테스터의 테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업을 지원. - 적은 수이지만 충분한 테스트 케이스를 체계적인 방식으로 개발할 수 있도록 해줌. - 테스터가 테스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는데 도움을 줌.
< 실러버스에서 분류하는 테스트 기법 3가지 >
블랙박스 테스트 기법 (==명세 기반 기법)
내부 구조를 참조하지 않음(외부문서O). 테스트 대상의 명시된 동작에 대한 분석을 기반. >> 테스트 케이스는 소프트웨어 구현 방식에 의존하지 않는다. 구현이 바뀌더라도 필요한 동작이 동일하다면, 테스트 케이스는 여전히 유효함. ex> 경계값 분석 기법, 동등 분할 기법, 결정 테이블 테스팅, 상태 전이 테스팅, 유즈 케이스 테스팅 기법
화이트박스 테스트 기법 (==구조 기반 기법)
테스트 대상이 내부 구조와 처리에 대한 분석을 기반. >> 테스트 케이스는 소프트웨어, 설계 방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 만들 수 있다. ex> 구문테스팅, 결정테스팅, 제어 흐름 테스팅 기법
경험 기반 테스트 기법
테스터의 지식과 경험을 테스트 케이스의 설계 및 구현에 효과적으로 활용. 이런 기법의 효과성은 테스터의 능력에 따라 크게 달라짐! 경험 기반 테스트 기법은 블랙박스와 화이트박스 테스트 기법으로는 식별하지 못할 수 있는 결함을 찾을 수 있게 해줌. >> 블랙박스 및 화이트박스 테스트 기법을 보완함.
인수 조건 :사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준. 인수 테스트 주도 개발 :팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.
경계값 분석 :경계값을 기반으로 테스트 케이스를 설계하는 블랙박스 테스트 기법.
분기 커버리지 :==결정 커버리지. 결정된 결과값에 대한 커버리지.
체크리스트 기반 테스팅 :경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.
커버리지 :커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분율로 표시한 것. 커버리지 항목 :테스트 실행의 완전성을 측정할 수있는 테스트 기법을 사용해 하나 이상의 테스트 컨디션에서 도출하는 속성 또는 속성들의 결합체.
결정 테이블 테스팅 :테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계 기법.
동등 분할 :명세에 따라 모든 값이 동일하게 취급될 것으로 예상되는 컴포넌트 또는 시스템 내의 변수 값 도메인의 하위 집합.
오류 추정 :과거 장애에 대한 테스터의 지식이나 장애 형태에 대한 일반적인 지식에 기초하여 테스트 케이스를 도출하는 테스트 기법.
탐색적 테스팅 :테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식. 상태 전이 테스팅 :테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법.
구문 커버리지 :실행 가능한 구문에 대한 커버리지.
테스트 기법 :테스트 조건을 정의하고, 테스트 케이스를 설계하고, 테스트 데이터를 지정하는 데 사용되는 절차.
블랙박스 테스트 기법 :컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.
화이트박스 테스트 기법 :컴포넌트 또는 시스템의 내부 구조에만 기반을 둔 테스트 기법.
경험 기반 테스트 기법 :테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.
4장의 내용은 엄청 많으면서 엄청 중요한 내용이다. 테스트 기법에 대해서도 알아야 되고 분석 문제도 풀 줄 알아야 된다.
샘플문제도 많이 풀어보고 발품팔아 구글링이랑 네이버 블로그 뒤적거려서 문제도 많이 찾아보고 풀어보는 게 좋다.
들어가기 전 알아둬야 할 3.1 용어, 3.2 용어 설명. : 사전적으로 설명정리한 건 바로 앞에 적어둔 블로그 용어 설명ㄱㄱ
사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항. 백로그 : 프로젝트 관리, 소프트웨어 개발, 업무 관리 등 다양한 분야에서 사용되는 용어로, 완료되지 않은 작업 항목들의 리스트나 목록을 가리킴.
공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형. 리뷰어 : == 검토자. 작업 산출물의 이슈를 식별하는 리뷰 작업 참여자.
워크스루 : 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의 진행.(비형식적인 검토기법.) 인스펙션 : 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제 해결.(형식적 검토기법.)
퍼실리테이션 : 직역- 용이성,편리성. 집단의 공동의 목적을 쉽게 달성할 수 있도록 도구와 기법을 활용하여 절차를 설계하고 중립적인 태도로 진행 과정을 돕는 활동을 일컬음.
3.1 정적 테스팅의 기초
정적 테스팅은 테스트 대상 소프트웨어를 실행하지 않아도 된다. 테스팅의 목표는 품질 개선, 결함 식별, 또한 가독성/완전성/정확성/테스트 용이성/일관성과 같은 특성을 평가하는 것이며 베리피케이션과 밸리데이션 모두에 적용할 수 있다. 사용자 스토리가 완전하고 이해하기 쉬우며, 테스트 가능한 인수 조건을 가지고 있는지 확인하기 위해 리뷰 기법을 적용할 수 있다. 적절한 질문을 통해 테스터는 제안된 사용자 스토리를 탐색하고, 문제를 제기하며 개선하는 데 도움을 준다. 정적 분석은 테스트 케이스가 필요 없고, 도구를 사용하는 경우가 많기 때문에 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다. 정적 분석은 주로 구체적인 코드 결함을 식별하는 데 사용하지만, 유지보수성과 보안을 평가하는 데도 사용된다. 맞춤법 검사기나 가독성 도구로 정적 분석 도구의 예라 할 수 있다.
3.1.1 정적 테스팅으로 검사 가능한 작업 산출물
정적 테스트를 사용해 거의 모든 작업 산출물을 검토할 수 있다. ex> 요구사항 명세서, 소스 코드, 테스트 계획서, 테스트 케이스, 제품 백로그 항목, 테스트 차터, 프로젝트 문서, 계약서, 모델 등이 그 대상이 될 수 있다.
읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. But, 정적 분석의 경우, 작업 산출물을 검토할 수 있는 기준이 되는 어떤 구조가 필요하다. ex> 모델, 공식 문법이 정해진 코드나 텍스트.
사람이 해석하기 어려운 것과 도구로 분석해서는 안 되는 작업 산출물(ex> 법적으로 문제가 되는 타사의 실행 코드)은 정적 테스트에 적합하지 않은 작업 산출물이다.
3.1.2 정적 테스팅의 가치
소프트웨어 개발수명주기 초기 단계에서 결함을 식별하기 때문에 조기 테스팅 원리를 지킬수 있게 한다.
동적 테스팅으로 식별할 수 없는 결함(ex> 도달 불가능한 코드)을 찾을 수도 있다.
작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다.
문서화된 요구사항을 확인함으로써 이해관계자는 요구사항이 실제로 자기가 필요한 것을 묘사하고 있는지 확인할 수 있다.
소프트웨어 개발수명주기 초기에 수행할 수 있으므로 관련된 이해관계자 간 공통된 이해를 형성할 수 있다. 관련된 이해관계자 간의 의사소통도 개선된다. 때문에 정적 테스팅에 다양한 이해관계자가 참여하는 것이 권장됨.
리뷰를 구축하는 비용은 클수 있지만, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 리뷰를 수행하지 않을 때보다 전체 프로젝트 비용이 훨씬 낮아지는 경우가 많다.
동적 테스팅 보다 효율적으로 코드 결함을 식별할 수 있으며, 대부분의 경우 결과적으로 코드 결함이 줄고, 전반적인 개발 노력도 감소한다.
3.1.3 정적 테스팅과 동적 테스팅의 차이 : 정적 테스팅과 동적 테스팅은 서로를 보완한다.
< 정적 테스팅과 동적 테스팅의 차이 > - 모두 결함을 식별한다는 것은 같지만, 정적 테스팅이나 동적 테스팅 중 한 가지로만 식별할 수 있는 결함 유형도 있다.
정적 테스팅
동적 테스팅
- 결함을 직접 식별한다.
- 장애를 일으킨 후 연관된 결함을 후속 분석을 통해 찾아낸다.
- 거의 실행되지 않거나 동적 테스팅으로 도달하기 어려운 코드 경로에 있는 결함을 더 쉽게 발견할 수 있다.
- 비 - 실행 작업 산출물에도 적용할수 있다.
- 실행 가능한 작업 산출물에만 적용할 수있다.
- 코드 실행에 의존하지 않는 품질 특성(ex>유지보수성)을 측정할 수있다.
- 코드 실행에 의존적인 품질 특셩(ex> 성능 효율성)을 측정할 수 있다.
< 정적테스팅을 통해 더 쉽게, 적은 비용으로 식별할 수 있는 대표적인 결함 >
- 요구사항 결함(ex> 불일치, 모호성, 모순, 누락, 부정확성, 중복) - 설계 결함(ex> 비효율적인 데이터 베이스 구조, 모듈화 불량) - 특정 유형의 코딩 결함(ex> 정의되지 않은 값을 가진 변수, 선언되지 않은 변수, 도달할 수 없거나 중복된 코드, 과도한 코드 복잡성) - 표준위반(ex> 코딩 표준 명명 규칙을 준수하지 않는 경우) - 잘못된 인터페이스 명세(ex> 매개변수의 개수, 유형, 순서 불일치) - 특정 유형의 보안 취약성(ex> 버퍼 오버플로우) - 테스트 베이시스 커버리지의 차이 또는 부정확성(ex> 인수 조건 하나에 대한 테스트 누락)
3.2 피드백과 리뷰 프로세스 - 3.2.1 이해관계자 피드백을 조기에 받을 때의 이점
1. 잠재적인 품질 문제를 조기에 파악할 수 있음. 2. 요구사항에 대한 오해를 방지하고 요구사항 변경을 조기에 이해하고 구현할 수 있음. 이를 통해 개발팀은 구현 중인 제품에 대한 이해도를 높일 수 있다. And 이해 관계자에게 가장 중요하고, 식별한 리스크에 가장 긍정적인 영향을 미치는 기능에 집중할 수 있음.
3.2.2 리뷰 프로세스 활동
계획 :계획 단계에서목적, 리뷰 대상 작업 산출물, 평가할 품질 특성, 집중할 영역, 완료 조건, 표준과 같은 추가 정보, 공수, 리뷰 일정 등으로 구성되는리뷰의 범위를 정의해야 함.
리뷰 착수 : 리뷰 착수의 목표는 관련된 모든 사람과 사항이 리뷰를 시작할 준비가 되었는지 확인하는 것.여기엔모든 참여자가 리뷰 중인 작업 산출물에 접근할 수 있는지, 자신의 역할과 책임을 이해하고 있는지, 리뷰를 수행하는 데 필요한 것들을 받았는지 확인하는 과정이 포함됨.
개별 리뷰 :모든 검토자(리뷰어)는 하나 이상의 리뷰 기법(ex> 체크리스트 기반 리뷰, 시나리오 기반 리뷰)을 적용해리뷰 중인 작업 산출물의 품질을 평가하고, 이상 사항, 권장 사항, 의문 사항을 식별하기 위해개별 기뷰를 수행함.검토자(리뷰어)는 식별한 모든 이상 사항, 권장 사항, 의문 사항을 기록.
논의 및 분석 :리뷰 중에 확인한 이상 사항이 반드시 결함은 아니므로 모든 이상 사항에 대해 분석하고 논의할 필요가 있음.각 이상 사항의 상태, 담당자, 필요 조치를 판단해야 함.일반적으로 리뷰 회의에서 이루어지며, 회의에 참가자들은 리뷰한 작업 산출물의 품질 수준과 필요한 후속 조치도 결정. 조치를 완료하기 위해 후속 리뷰가 필요할 수 있음.
수정 및 보고:모든 결함에 대한 결함 보고서를 작성해 후속 조치가 추적 가능하도록 함. 완료 조건을 충족하면 작업 결과물을 승인할 수 있으며 리뷰 결과를 보고 한다.
3.2.3 리뷰에서의 역할과 책임
리뷰에는 다양한 이해관계자가 참여하며, 한명이 여러 역할을 동시에 맡을 수도 있다.
주요 역할
책임
관리자
리뷰할 내용을 결정, 리뷰에 필요한 사람과 시간 등 자원을 제공.
저자
리뷰 대상 작업 산출물을 작성하고 수정.
중재자(==퍼실리테이터)
중재, 시간 관리, 모든 사람이 자유롭게 발언할 수 있는 안전한 리뷰 환경 조성 등 리뷰 회의의 효과적인 운영을 담당.
서기(==기록자)
리뷰어로부터 이상 사항을 수집하고, 결정 사항이나 리뷰 회의 중에 발견한 새로운 이상 사항 등 리뷰 정보를 기록.
리뷰어(==검토자)
리뷰를 수행한다. 리뷰어는 프로젝트에 참여하는 사람 또는 주제 전문가, 기타 이해관계자가 될 수 있음.
리뷰 리더
리뷰에 참여할 사람을 결정하고, 리뷰 시간과 장소를 협의하는 등 리뷰에 대한 전반적인 책임을 짐.
3.2.4 리뷰 유형
비공식 리뷰부터 공식 리뷰까지 다양한 리뷰 유형이 있다. 필요한 리뷰 목적을 달성하려면 적절한 리뷰 유형을 선택하는 것이 중요!
< 많이 사용하는 4가지 리뷰 유형 >
리뷰 유형
특징
KeyWord
비공식 리뷰
정의된 프로세스를 따르지 않으며, 공식적인 결과 문서도 요구하지 않음. 주요 목적 : 이상 사항을 식별하는 것.
문서작성X
워크쓰루
저자가 리더가 되는 워크쓰루를 통해 품질 평가 및 작업 산출물에 대한 신뢰 구축, 리뷰어 교육, 합의 도출, 새로운 아이디어 창출, 저자가 개선할 수 있도록 동기 부여 및 지원, 이상 사항 발견 등 여러가지 목적을 달성할 수있음. 리뷰어는 워크쓰루 전에 개별 리뷰를 수행할 수도 있지만, 반드시 해야하는 것은 아님.
저자가 리더, 리뷰어 훈련
기술 리뷰
기술적인 자격을 갖춘 리뷰어가 수행하고 중재자가 리더가 됨. 주요 목적 : 기술 문제에 대한 합의를 도출하고 결정을 내리며, 이상 사항 식별, 품질 평가 및 작업 산출물에 대한 신뢰 구축, 새로운 아이디어 창출, 저자가 개선할 수 있도록 동기를 부여하고 지원하는 것.
중재자가 리더, 저자의 개선의지 향상
인스펙션
가장 공식적인 리뷰 유형. 보편적으로 프로세스를 철저히 따라야 함. 주요 목적 : 이상 사항을 최대한 많이 찾는 것. 기타 목적 : 품질 평가, 작업 산출물에 대한 신뢰 구축, 저자가 개선할 수있도록 동기 부여 및 지원. 메트릭을 수집해 리뷰 프로세스를 포함한 전체 소프트웨어 개발수명주기를 개선하는 데 사용. +잠재적 결함 식별. 저자가 리뷰 리더나 서기가 될수 없음
저자가 리뷰리더나 서기가 될 수 없음, 프로세스 개선에 사용
3.2.5 리뷰의 성공 요소
명확한 목표와 측정 가능한 완료 조건을 정의. 참가자의 평가나 목적이 되어서는 절대 X.
주어진 목표를 달성할 수 있으면서 작업 산출물 유형, 리뷰 참여자, 프로젝트 요구사항 및 정황에 맞는 리뷰 유형 선택.
리뷰어가 개별 리뷰 또는 리뷰 회의에서 집중력을 잃지 않도록 작은 단위로 리뷰 진행.
이해관계자와 저자에게 리뷰 피드백 제공 >> 제품 및 활동을 개선할 수 있도록 함.
참가자가 리뷰를 준비할 수 있는 충분한 시간 제공.
리뷰 프로세스를 관리층이 지원.
학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.
모든 참가자가 자신의 역할을 어떻게 충족해야 하는지 알수 있도록 적절한 교육 제공.
회의에 퍼실리테이션을 적용.
여기서는 정적 테스팅과 동적테스팅의 차이를 알아야 되며, 리뷰 역할과 책임, 리뷰 유형, 리뷰 성공 요소는 꼭 알아둬야 한다. 샘플 문제에서도 이 부분들의 문제는 하나씩 꼭 등장함!
이상 사항: ==이상 현상. 요구사항 명세서, 설계 문서, 사용자 문서, 표준 또는 누군가의 인식이나 경험 등에 기반한 기댓값에서 벗어난 상태를 말한다. 이상 현상은 리뷰, 테스팅, 분석, 비교, 혹은 소프트웨어 제품이나 해당 문서의 사용 도중에 발견할 수 있지만, 이에 국한되지는 않음.
동적 테스팅: 테스팅 항목의 실행과 관련된 테스트.
공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형. 비공식 리뷰: 정의된 프로세스를 따르지 않고 문서화된 공식 결과가 없는 리뷰 유형.
인스펙션: 작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로세스를 개선하는 데 필요한 정보를 제공.
리뷰: 결함을 발견하거나 개선 사항을 제공하기 위해 한 명 이상의 개인이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅 유형.
정적 분석: 형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스.
정적 테스팅: 테스트 항목의 실행을 수반하지 않는 테스팅.
기술 리뷰: 작업 산출물의 품질을 검사하고 명세 및 표준과의 불일치를 식별하는 기술 전문가의 공식 리뷰.
위크 쓰루: == 워크스루. 작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형.
3장은 공부시간이 80분으로 6장 테스트 지원도구(20분) 외에 가장 짧은 시간이 필요하다. 읽어보면서 이해하고 넘어가야 80분의 시간 안에 끝낼 수 있다. 아무 생각 없이 읽기만 반복한다면 뫼비우스의 띠처럼 글씨, 글씨, 글씨로 시간이 줄줄이 흘러가 버려지는 시간이 늘어날 수 있다. 도저히 집중이 안된다 싶다면 문제를 풀어보면서 해설을 읽으며 공부해도 좋은 구역이다.
들어가기 전 알아둬야 할2.2 용어, 2.3 용어 설명 : 사전적으로 설명 정리한 건 용어 설명 글 ㄱㄱ, 여기는 이해 쉽게 봐보자.
테스트 레벨 :테스트 프로세스 중의 특정 예시 단계. 테스트 유형 : 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합. 컴포넌트: 개별적으로 테스트할 수 있는 시스템의 최소 구성단위. 엔드 투 엔드 테스팅: 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형. 테스트 명세: 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서.
< 기능 테스트 & 비기능 테스트의 기능과 비기능 해석 > 기능: 무엇을 해야 하는지. 비기능: 얼마나 잘 돌아가는지.
확인 테스팅: 원래 결함이 성공적으로 수정됐는지 확인. 리그레션 테스팅 :변경으로 인해 부정적인 영향 있는지 확인. 확인 테스팅 이후에 리그레션 테스팅하는 거임.
운용 환경: 움직이는 환경으로 이해 ㄱㄱ.
2.2 테스트 레벨과 테스트 유형
-테스트 레벨은함께 구성하고 관리하는 테스트 활동 집합이다. : 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다. 단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수 있다. -테스트 레벨은소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다. : 순차적 소프트웨어 개발수명주기 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.
-테스트 유형은특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.
2.2.1 실러버스에서 다루는 테스트 레벨 5가지
컴포넌트 테스팅(== 단위 테스팅) :컴포넌트를 개별적으로 테스트하는 데 중점. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많음. 일반적으로 개발자가 자신의 개발 환경에서 수행함.
컴포넌트 통합 테스팅(== 단위 통합 테스팅) :컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점.상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
시스템 테스팅:전체 시스템 또는 제품의 전반적인 동작과 기능에 중점.엔드 투 엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많음. 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있음.
시스템 통합 테스팅:다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점.가급적 운영 환경과 유사한 적절한 테스트 환경을 사용함.
인수 테스팅:밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점.실제 사용자가 수행하는 것이 이상적. 주요 유형으로 사용자 인수 테스팅, 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅이 있음.
▶ 테스트 레벨은 테스트 활동의 중복을 피하기 위해다양한 속성 "테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할"들을 고려해 구분한다.
2.2.2 실러버스에서 다루는 테스트 유형 4가지
기능 테스팅: 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가. 기능은 테스트 대상이 "무엇을" 해야 하는지를 의미.주요 목적 - 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것.
비기능 테스팅: 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가. "시스템이 얼마나 잘 동작하는지" 테스트하는 것.주요 목적 - 비기능 소프트웨어 품질 특성을 확인하는 것.
ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류함. - 수행 효율성. - 호환성. - 유용성. - 신뢰도. - 보안. - 유지 가능성. - 이동성.
수명 주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다. 기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다.비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.
블랙박스 테스팅: 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출.주요 목적 - 명세와 비교해 시스템의 동작을 확인하는 것.
화이트박스 테스팅: 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출.주요 목적 - 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것.
2.2.3 확인 테스팅 및 리그레션 테스팅
일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다.이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.
확인 테스팅
원래 결함이 성공적으로 수정됐는지 확인. ex > 결함으로 인해 이전에 실패했던 모든 테스트 케이스를 실행한다. 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가한다. but, 결함을 수정하는 데 시간이나 비용이 부족한 경우, 결함으로 생긴 장애를 재현하기 위한 절차를 거쳐 장애가 발생하지 않는지 확인하는 것만으로 확인테스팅이 끝날 수도 있다.
리그레션 테스팅
변경으로 인해 부정적인 영향이 없었는지 확인하는 것. 이미 확인 테스팅이 끝난 수정 사항도 여기서 말하는 변경에 포함된다. 테스트 대상 자체에만 국한되지 않고, 환경과도 관련이 있을 수 있음. 리그레션 테스팅의 범위를 최적화하기 위해 영향도 분석을 먼저 수행하는 것이 좋다. 영향도 분석은 소프트웨어의 어느 부분이 영향을 받을 수 있는지 보여줌. 리그레션 테스트 스위트는 반복적으로 실행되며, 리그레션 테스트는 자동화하기 매우 적합한 대상이 됨. 이런 테스트의 자동화는 프로젝트 초기에 시작해야 함. 데브옵스와 같이 지속적 통합을 사용하는 경우, 자동 리그레션 테스트를 포함하는 것이 좋은 프렉티스이다.
▶ 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.
2.3 유지보수 테스팅
유지보수에는 여러 범주가 있다.문제를 수정하기 위한 유지보수,환경 변화에 적응,성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다. 운용환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.
▶ 유지보수 테스팅의 범위는 일반적으로 "변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기"에 따라 달라진다.
< 유지보수와 유지보수 테스팅의 계기 >
계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항.
운영 환경의 업그레이드나 마이그레이션 하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션 할 때, 데이터 변환 테스트가 필요할 수 있다.
애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다. 보관기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다.
들어가기 전 알아둬야 하는 2.1 용어 설명 : 사전적으로는 용어설명 글 참고 ㄱㄱ, 여긴 간단하게 봐보자.
리그레션 테스팅 : 수정으로 기존에 있던 프로그램에 새로운 결함이 생겼는지 테스팅. 프랙티스 : 관리 활동. 시프트 레프트 전략 == 조기 테스팅원리. 인수 테스트 주도 개발 >> 대표적인 테스트 우선 개발 접근법. 명세 : 자세한 내용. 테스트 하네스 : 자동화된 테스트 지원도구. 회고 : 프로젝트 종료 후 회의.
테스트 주도 개발 : 테스트 케이스가 개발되고 많은 경우 자동화된 다음 해당 테스트 케이스에 합격하도록 소프트웨어를 점진적으로 개발하는 소프트웨어 개발 기법. >> 테스트가 주도하는 개발 방법론을 의미. 인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식. >> 인수테스트가 주도하는 개발 방법론을 의미. 행위 주도 개발 : 팀이 테스트의 베이시스를 형성하는 고객을 위한 컴포넌트 또는 시스템의 기대 동작을 제공하는 데 집중하는 개발에 대한 협업적 접근 방식. >> 시스템 동작의 행위를 기반. 행위에 대한 명세를 작성하는 것이라 생각하면 이해가 쉬움.
비기능 테스트 : 기능이 아닌 거. 테스트 결과가 기능 테스트처럼 Yes/No로 판단하기 힘듦. ex> 로그인 기능 테스트. 버튼 클릭시 로그인은 되는데 지연이 10초 이상 되었다가 로그인이 될 때.(기능은 정상 작동하지만 뭔가 문제가 있지.)
2.1 소프트웨어 개발수명주기에서의 테스팅
소프트웨어 개발수명주기(SDLC) 모델은 상위 수준에서 소프트웨어 개발 프로세스를 추상화해서 표현한 것이다. 소프트웨어 개발수명주기(SDLC) 모델의 예 : 순차적 개발 모델(ex> 폭포수 모델, V - 모델), 반복적 개발 모델(ex> 나선형 모델, 프로토 타이핑), 점진적 개발 모델(ex> 통합 프로세스)등이 있다.
2.1.1 소프트웨어 개발수명주기(SDLC)가 테스팅에 미치는 영향
테스트 활동 범위 및 시기(ex> 테스트 레벨 및 테스트 유형)
테스트 문서 상세화 수준
테스트 기법 및 테스트 접근법 선택
테스트 자동화 범위
테스터의 역할과 책임
순차적 모델
반복적 점진적 개발 모델
테스터는 초기 단계에서 요구사항 리뷰, 테스트 분석과 설계에 참여함. 실행 가능한 코드는 보통 개발 후반에 생성되므로, 동적 테스팅은 소프트웨어 개발수명주기 초기에 수행하기 어려운 경우가 많다.
반복 주기마다 동작하는 프로토 타입이나 제품 증분이 만들어진다고 가정한다.(일부) 이는 반복 주기마다 모든 테스트 레벨에서 정적 테스팅과 동적 테스팅을 수행할 수 있음을 의미함. 증분을 자주 전달하려면 빠른 피드백과 광범위한 리그레션 테스팅이 필요함.
애자일 소프트웨어 개발에서는 프로젝트의 어느 시점에도 변화가 생길 수 있다고 가정한다. 애자일 프로젝트는 리그레션 테스팅을 수월하게 하는 가벼운 작업 산출물과 테스트 자동화를 선호하게 된다. 수동 테스팅도 사전 테스트 분석과 설계가 필요하지 않은, 경험 기반 테스트 기법으로 진행하는 경향이 있다.
2.1.2 소프트웨어 개발수명주기(SDLC)와 우수한 테스팅 프랙티스 : 선택한 소프트웨어 개발수명주기 모델에 상관없이 다음과 같은 우수한 테스팅 프랙티스가 있다.
모든 소프트웨어 개발 활동에 상응하는 테스트 활동을 두어모든 개발 활동이 품질 제어의 대상이 되게 한다.
테스트 레벨마다 구체적이면서 독립적인 테스트 목적을 설정해, 중복은 피하고, 적절하면서 포괄적인 테스팅이 가능하게 한다.
특정 테스트 레벨을 위한 테스트 분석과 설계를 소프트웨어 개발수명주기의 상응하는 각 개발 단계에서 시작해 (테스팅 원리 중) 조기 테스팅 원칙을 준수할 수 있게 한다.
테스터가 문서 초안이 가용한 즉시 작업 산출물 리뷰에 참여하도록 해서, 시프트-레프트 전략 지원을 위한 조기테스팅과 결함 발견이 가능하도록 한다.
2.1.3 소프트웨어 개발 주도를 위한 테스팅
테스트 주도 개발, 인수 테스트 주도 개발, 행위 주도 개발은 서로 유사한 개발 접근법으로 개발 방향 결정을 위한 수단으로 테스트를 정의한다. 이런 접근법은 코드 작성 전에 테스트를 정의하므로 조기 테스팅 원리를 구현하고 시프트-레프트 접근법을 따르게 한다.반복적 개발 모델을 지원함.
테스트 주도 개발 (TDD)
인수 테스트 주도 개발(ATDD)
행위 주도 개발(BDD)
- 테스트 케이스를 통해 코딩 주도. - 테스트를 먼저 작성하고, 이를 충족하도록 코드를 작성한 다음, 테스트와 코드를 리팩토링.
- 시스템 설계 프로세스 중 인수 조건에서 테스트 도출. - 테스트는 해당 테스트를 만족해야 할 애플리케이션 영역을 개발하기 전에 작성.
- 애플리케이션의 기대 동작을 이해관계자가 이해하기 쉽도록, 간단한 자연어로 작성해 테스트 케이스로 표현 >> 일반적으로 Given/ When/Then 형태(시나리오 형태)를 사용. - 이후 테스트 케이스는 자동으로 실행 가능한 테스트로 변환.
위의 모든 접근법에서 테스트는 향후 적용/ 리팩토링 시 코드 품질 보장을 위해 자동화 테스트로 유지 가능하다.
2.1.4 데브옵스(DevOps)와 테스팅
- 테브옵스는 개발(테스팅 포함)과 운영이 협력해 공통된 목표를 달성하도록 시너지 창출을 목표로 하는 조직 차원의 접근법이다. - 데브옵스는 개발(테스팅 포함)과 운영이 가진 생각의 차이를 줄임과 동시에 각자 하는 일의 가치를 서로 동등하게 보도록 조직문화의 변화가 필요하다. - 데브옵스는 팀의 자율성, 빠른 피드백, 통합 도구 체인, 지속적 통합과 지속적 배포와 같은 기술 실천법을 장려한다. - 팀은 데브옵스 배포 파이프라인을 통해 높은 품질의 코드를 더 빠르게 빌드/ 테스트/ 릴리스할 수 있다.
테스팅 관점에서 데브옵스의 장단점.
장점
1. 코드 품질, 그리고 변경사항이 기존 코드에 악영향을 미치는지 여부에 대한 빠른 피드백을 제공. 2. 지속적 통합은 개발자가 컴포넌트 테스트 및 정적분석과 함께 높은 품질의 코드를 제출하도록 장려함으로써 시프트 레프트 테스팅 접근법을 장려. 3. 안정적인 테스트 환경 구축을 촉진하는 지속적 통합/지속적 배포와 같은 자동화 프로세스를 장려. 4. 비기능 품질 특성(ex>성능, 신뢰성)의 가시성을 높여줌. 5. 배포 파이프라인을 통한 자동화로 반복적인 수동 테스팅의 필요성을 줄여준다. 6. 자동 리그레션 테스트의 규모와 범위가 늘어나 리그레션 발생 리스크가 최소화된다.
단점
1. 데브옵스 배포 파이프라인을 정의하고 설정해야 함. 2. 지속적 통합/ 지속적 배포 도구를 도입하고 유지보수해야 함. 3. 테스트 자동화를 위한 추가 자원이 필요하며, 그것을 설정 및 유지보수하기 어려울수 있음.
>> 데브옵스는 높은 수준의 테스팅 자동화를 동반하지만, 수동 테스팅 또한 필요(특히 사용자 관점에서)!!
2.1.5 시프트 레프트 접근법
조기 테스팅 원리는 테스트를 소프트웨어 개발수명주기 초기에 수행하도록 하는 접근법이기 때문에 시프트 레프트라고도 지칭하기도 한다. 시프트 레프트는 테스트를 더 일찍 수행해야 한다는 것을 의미하지만, 그렇다고 소프트웨어 개발수명주기 후반의 테스트를 무시해도 된다는 의미는 아니다.
< 테스팅에서 시프트 레프트를 달성하는 좋은 일부 프랙티스>
테스팅 관점에서 명세를 리뷰. - 모호성, 불완정성, 불일치 등 잠재적인 결함을 발견하는 경우가 많다.
코드를 작성하기 전에 테스트 케이스를 작성하고, 코드 구현 중 코드를 테스트 하네스에서 실행한다.
빠른 피드백을 제공하고, 코드 저장소에 소스 코드를 저장할 때 자동 컴포넌트 테스트를 함께 제출하도록 하는 지속적인 통합, 가능하다면 지속적인 배포까지 적용한다.
동적 테스팅 전 또는 자동화된 프로세스의 일부로 소스 코드의 정적분석을 완료한다.
가능한 한 컴포넌트 테스트에서부터 비기능 테스팅을 수행한다. 비기능 테스트는 완성 시스템과 실제 환경을 대변하는 테스트 환경이 가용한 소프트웨어 개발수명주기 후반에 수행하는 경향이 있으므로, 이는 일종의 시프트 레프트가 된다.
>>시프트 레프트 접근법은 프로세스 초기에 훈련, 공수, 비용이 추가로 들지만, 프로세스 후반의 공수와 비용의 절감을 기대할 수 있다. 이해관계자들의 개념을 이해하고 받아들이는 것이 중요하다.
2.1.6 회고 및 프로세스 개선 : 회고 = 프로젝트 종료 후 회의 또는 프로젝트 회고라고 함.
회고는 프로젝트나 반복 주기가 끝날 때, 릴리스 마일스톤에서, 또는 필요시 진행할 수 있다. 회고의 시기와 구성은 사용 중인 소프트웨어 개발수명주기 모델에 따라 달라진다. 결과는 기록해야 하며이를 테스트 완료 보고서에 포함하는 경우가 많다. 회고는 지속적인 개선을 성공적으로 구현하기 위해 반드시 필요하며, 권장된 모든 개선 사항에 대한 후속 조치가 이루어지는 것이 중요.
>> 회고와 최종사용자는 관련이 없어.
< 테스팅 관점에서 일반적인 이점 >
테스트 효과성/ 효율성 향상(ex> 프로세스 개선 권고 사항 구현을 통해)
테스트웨어 품질 향상(ex> 테스트 프로세스를 함께 검토함으로써)
팀의 결속 및 학습 향상(ex> 문제를 제기하고, 개선점을 제안할 기회를 제공함으로써)
테스트 베이시스 품질 개선(ex> 요구사항의 범위나 품질에서 부족한 점을 발견하고, 수정함으로써)
개발(개발자로부터 피드백)과 테스팅 간의 협업 개선(ex> 정기적으로 협업 과정을 검토하고 최적화함으로써)
들어가기 전 알아둬야 하는 1.5 용어 설명 : 사전적으로는 용어설명 글 참고 ㄱㄱ. 여기서는 간단하게 이해 쉽게 설명
도메인 : 유효한 입력값/ 출력값의 선택을 가능하게 하는 집합.
1.5. 테스팅의 필수 기술 및 모범 사례
- 우수한 테스터는 팀플레이, 즉 협업에 능한 사람이어야 하며, 다양한 수준의 독립성으로 테스팅을 수행할 수 있어야 한다.
1.5.1 테스팅에 보편적으로 필요한 기술
테스팅 지식(테스팅 효과를 높이기 위해 - ex> 테스트 기법 활용)
철저함, 신중함, 호기심, 세부사항에 대한 주의력, 체계적인 접근(결함, 특히 찾기 어려운 결함 식별을 위해)
우수한 의사소통 기술, 경청하는 자세, 팀플레이(모든 이해관계자와 효과적으로 상호작용하고, 다른 사람에게 정보를 전달하고, 상대의 이해를 구하고, 결함을 보고하고, 논의하기 위해)
분석적 사고, 비판적 사고, 창의성(테스팅 효과를 높이기 위해)
기술 지식(테스팅 효과를 높이기 위해 - ex> 적절한 테스트 도구 사용)
도메인 지식(최종 사용자/ 비즈니스 대표자를 이해하고 그들과의 소통을 위해)
테스터에게는 의사소통 기술이 매우 중요. 결함과 장애 관련 정보를 건설적인 방법으로 전달할 수 있어야 함.
1.5.2 전체 팀 접근법 : 누구나 모든 작업 수행 O, 모든 팀원이 품질에 대해 책임. 의사소통 & 협업 Up!
- 전체 팀 접근법에서는 필요 지식과 기술을 갖춘 팀원이라면 누구나 모든 작업을 수행할 수 있고, 모든 팀원이 품질에 대해 책임진다. 같은 공간을 사용하는 것은 의사소통과 상호작용을 용이하게 하므로 팀원들은 작업 공간을 공유한다. - 전체 팀 접근법은 팀의 활력을 높이고, 팀 내 의사소통과 협업을 강화하며, 프로젝트의 성공을 위해 팀이 가진 다양한 기술을 활용해 시너지를 창출한다.
테스터는 필요한 수준의 품질 달성을 위해 다른 팀원과 긴밀히 협력하게 된다. 여기에는 비즈니스 담당자와 협력해 적절한 인수 테스트를 작성하고,개발자와 협력해테스트 전략을 협의하고, 테스트 자동화 접근법을 결정하는 것도 포함된다. 따라서 테스터는 테스팅 지식을 다른 팀원과 공유하게 되며, 제품 개발에 영향을 주게 된다.
- 정황에 따라 전체 팀 접근법이 적절하지 않을 수 있다. ex> 안전이 치명적인 경우에는 높은 수준의 테스트 독립성이 필요할 수 있다.
1.5.3 테스팅의 독립성
- 일정 수준의 독립성은 저자와 테스터의 인지 편향 차이로 테스터가 결함을 더 효과적으로 식별할 수 있도록 한다. 그러나 독립성이 친숙함을 대체하는 것은 아니다. ex> 개발자는 자신이 작성한 코드에서 많은 결함을 효율적으로 찾아낼 수 있다.
< 작업 산출물 독립성 단계 >
1단계 - 독립성 없음 : 저자가 직접 테스트. 2단계 - 일정 수준의 독립성 : 저자의 같은 팀 동료가 테스트. 3단계 - 높은 독립성 : 저자의 팀 외부에 있지만 조직 내에 있는 테스터가 테스트. 4단계 - 매우 높은 독립성 : 조직 외부의 테스터가 테스트.
< 독립적인 테스팅의 주요 이점 > - 배경, 기술적 관점, 편향이 다르기 때문에 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다. - 독립적인 테스터는 시스템 명세를 작성하고 구현하는 과정에서 이해관계자의 가정을 검증하고, 그것에 대한 이의를 제기하거나 반증할 수 있다.
< 독립적인 테스팅의 단점 > - 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며, 개발팀과 적대적인 관계로 이어질 수 있다. - 개발자가 품질에 대한 책임감을 잃을 수도 있다. - 독립적인 테스터가 병목으로 인식되거나, 출시 지연의 원인으로 비난받을 수도 있다.
▲ 여기는 생각보다 문제가 잘 나오는 구역 같다. ▲
테스터에게 요구되는 기술을 물어보거나, 전체 팀 접근법의 장단점 문제, 테스팅의 독립성 단계 선택이나 장단점을 찾아내는 문제들로 샘플문제에서 자주 봤다. 외울 필요는 없지만 이해만 하면 문제를 맞히기 쉬운 부분이다.
