//구글콘솔 광고 추가가

룰루루루루루룰루 블로그에 짧은 후기를 남기고 한동안 가을만 느끼며 살던 나에게 기적 같은 일이 일어났다.
찍었던 문제가 다 맞은 것인지 푼 문제가 다 맞은 것인지 합격을 했다.
istqb 불합격 ㄴㄴ!! 유후!

사실 정말 시험이 어려웠어서 기대가 하나도 되지 않는 상황이었다. 집에 돌아오는 길 내내 복기하면서 왔을 정도로 다음 시험을 준비해야 되겠구나 싶었는데 이렇게 합격이 뜨다니! ㅎㅎㅎㅎㅎㅎ
최근 들어서 지금 이 순간이 제일 기분이 좋다.
목요일 밤 9시에 결과가 발표 난다는 것을 알고 있었지만 속상할 것 같아서 텐트 밖은 유럽을 보며 애써 잊었다.
그러다 자기 전에 내일 친구를 만나러 가기 전 결과를 보면 친구한테도 별로 좋지 않은 영향을 줄 것 같다는 생각을 하고 슬그머니 sten을 들어가 봤다.
지난번보다 많이 틀렸으려나 하고 들어간 화면에서 “합격” 문구를 본 순간. 난 내 눈을 의심했다. 뭔가 잘못된 것인가 하는 마음으로 로그아웃하고 다시 들어가 봤다. 새로고침도 하고 결과확인도 다시 클릭해 보고 다해봐도 합격이었다. “합격.” 모두가 자고 있는 이 시간에 난 쾌재를 불렀다. 에헤라디야 둥가둥가 룰룰루 합격이라는 두 글자에 이렇게 기쁠 수 있을까.



일단 istqb ctfl v4.0 시험 합격의 기쁨은 여기까지 하고 간단하게 나의 합격 방법을 적어둔다. 누군가에게 도움이 되길 바라며.

0. 시험 시간 진짜 촉박하다. 40문제를 1시간 안에 풀어야 된다 생각하지 말고 50분 안에 푼다 생각하자. 20문제를 풀고 있는데 25분이 지나가고 있으면 속도를 내야 한다. 시험 보는 날 시간이 여유롭다면 일찍 와서 공부하자. 그때가 제일 공부가 잘 된다. 시험장에는 일찍 들어갈 수 있다. 긴장되니까 화장실은 다녀오고 들어가자. 컴싸도 상관없지만 다한증이라도 있다면 볼펜을 추천한다. 안 번진다. 난 그냥 두 개 다 들고 갔다.
 

1. 나는 샘플문제를 각각 5번 정도 풀어봤다. 아이패드를 사용하는 나로서는 레이어를 나눌 수 있어서 풀고 채점하고 복기하고 다른 날 다시 풀고 채점하고 복기하고를 반복했다. (처음엔 A, B, C, D 순서대로 풀고 두 번째부터는 순서대로 하지 말고 계속 섞어가면서 풀었다.)
 

2. 나의 경우 시험 보러 가기 3일 전 인공눈물을 잘못 사용해서 눈병에 걸렸다. 눈알이 검은 눈동자 빼고 전부 부풀어 올라서 눈이 터지려고 하는 상황에 더 이상 눈을 뜨고 공부를 할 수 없어 다시 유튜브 “김기태 님의 sw강의”를 밤새 들었다. 근데 이게 공부했던 내용을 꽤 정리해 주는 계기가 되었다. 전부 외웠다고 생각해도 놓칠만한 게 분명 생긴다. 나는 강의를 시험 보러 가기 이틀 전 정도에 다시 들어보는 걸 추천한다. + 유튜브 “라메드랩스“ - 단어 풀이해 주는 강의도 꼭 들어보기. 강추. 강추.
 

3. 실라버스 한국어 해석이 그렇게 잘 되어 있지 않다. 영어 버전도 다운로드하여서 번역해서 같이 읽어보는 것을 추천한다. 나의 경우엔 테스트 피라미드 부분을 영어 번역본을 통해 다시 읽어봐서 이해가 됐다. 다른 부분들도 꽤 도움이 되니 화면을 이중으로 켜두고 같이 읽어보는 것을 추천한다. 나는 캡쳐해서 내 한국어 실라버스 옆에 붙여두고 공부할 때 같이 읽었다.
 

4. 외워야 되는 건 그냥 암기가 답이다. 자기 전에 외우고 일어나서 암기했던 부분을 다시 적어보면서 공부를 시작했다. 외워서 맞출 수 있는 문제를 틀리기엔 시험이 너무 어렵다. 그렇게 틀리기엔 아까워서 두고두고 후회할 것이다. 외워서 맞출 수 있는 문제는 꼭 다 외워가자. (테스트 활동과 업무, 테스트 웨어는 무조건 다 외우는 게 낫다. 그 외에 테스트 레벨, 테스팅 사분면, 동적테스트와 정적테스트 차이, 테스팅 지원도구 등등)
 

5. 아이패드나 갤럭시탭이나 용지로 직접 공부하는 것이 아니라면 레이어를 적극 활용해 보자. 한번 정리해서 공부하고 난 뒤 다시 새로운 레이어에서 아무 필기가 안되어 있는 상태로 다시 공부를 하면 내가 놓치고 못 본 부분도 다시 볼 수 있다. 두 개 정도 레이어를 나눠서 공부했다면 두 개의 화면을 같이 켜두고 안 보고 넘긴 부분이 있는지 다시 체크해서 읽어보는 것을 추천한다. (나의 경우는 총 3개의 레이어를 사용했다. 1 레이어 - 번역본 + 용어 설명 + 키워드, 2 레이어 - 꼭 외워야 되는 내용, 3 레이어 - 샘플 문제에서 틀린 부분 정리해서 다시 키워드 정리)
시험은 정말 실라버스의 모든 내용에서 나오는 것 같다. 한 문장이라도 대충 보고 넘어간 그 부분에서 문제가 나온다. 나도 알고 싶지 않았다가 두 번째 시험 보고 나서 깨달았다.
 

6. 문배를 풀어보는 것을 추천한다. 문배의 문제도 문제지만 해설에서 도움을 꽤 받았다. (특히 4장 테스팅문제 푸는 부분) 실라버스를 어느 정도 공부를 했다면 문배를 풀어보자. 문배에서 내용이 너무 예전 것이라 헷갈릴 수 있지만 공부를 했다면 시험범위가 아닌 부분을 바로 캐치할 수 있다. 넘길 부분들은 넘기고 그 외의 부분들을 풀어보면서 해설과 실라버스 내용을 같이 읽어보는 것을 추천한다. 실라버스만 공부해서는 사실 쉽지 않은 것 같다.
 

7. 샘플 문제 안에서 틀린 문제들은 자신이 문제 안에서 나온 단어들을 제대로 이해하였는지 확인하는 것이 중요하다. 구글을 통해 이해가 안 된 단어들을 자세하게 알아보는 게 이해하는데 도움이 된다. + 답만 찾지 말고 답이 아닌 애들은 왜 틀렸는지, 뭘 설명하는지 적어두고 풀이할 때 맞게 썼는지 확인해 보면 1문제로 여러 공부를 할 수 있다. 이것도 강추.
 



사실 나는 정말 실라버스를 거의 다 외우고 갔다고 생각했는데 문제를 받고 머리가 새하얘졌다. 모두 시간도 적당히 봐서 넘길 문제는 넘기고 풀 수 있는 문제 먼저 푸는 것을 추천한다. 혹시나 시간을 들여서 이미 풀려고 했다면 아닌 답들이라도 확실하게 지워두고 넘어가자. 나중엔 시간이 촉박해서 다시 풀고 싶어도 못 푸는 상황이 올 수 있다. 그럴 땐 어쩔 수 없이 찍는다 하더라도 적어도 맞출 확률은 높여둬야 하니까!

모두 화이팅! 이제 취업의 문을 두드리러 가봐야지!

++ 그리고 지난번 시험이 끝나고 궁금했던 나가는 순서에 대한 의문점이 풀렸다. 감독관님께서 싸인을 해주시고 나가도 된다는 말을 해주신다. 시험이 완전히 끝나기 전에 끝마친다면 감독관님이 싸인을 해주시면서 이야기해 주신다. 나도 두 번째 시험에서는 나가도 된다는 허락을 받고 먼저 일어났다. 시험 시간이 완전히 끝나면 나가는 게 보류되는 것 같았다. 내가 나가려고 일어났을 때 다시 한번 다른 감독관님께서 오셔서 허락받았는지 확인하셨었다.

728x90
반응형
들어가기 전 알아둬야 할 4.1 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.
블랙박스 테스트 기법 : 개발자 입장이 아닌 사용자 입장에서 바라본 제품의 요구사항이 일치하는지 확인하는 테스트 기법. 명세 기반 기법.
화이트박스 테스트 기법 : 개발자 입장에서 바라본 로직에 대한 설계로 구현이 제대로 되었는지 확인하는 테스트 기법. 구조 기반 기법.
경험 기반 테스트 기법 : 탐색적 테스팅.
테스트 케이스 : 테스트 베이시스를 토대로 만들어짐. 블랙박스와 경험기반 테스트의 주요 차이점은 테스트 베이시스가 다른 거야. 블랙박스는 명세, 경험기반은 탐색.

 

4.1 테스트 기법 개요
:테스트 설계와 분석에 적용할 활동들을 공부해보자고!
테스트 기법이란?
- 테스터의 테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업을 지원.
- 적은 수이지만 충분한 테스트 케이스를 체계적인 방식으로 개발할 수 있도록 해줌.
- 테스터가 테스트 분석과 설계에서 테스트 컨디션을 정의하고, 커버리지 항목과 테스트 데이터를 식별하는데 도움을 줌.
< 실러버스에서 분류하는 테스트 기법 3가지 >
블랙박스 테스트 기법
(==명세 기반 기법)
내부 구조를 참조하지 않음(외부문서O). 테스트 대상의 명시된 동작에 대한 분석을 기반. 
>> 테스트 케이스는 소프트웨어 구현 방식에 의존하지 않는다. 구현이 바뀌더라도 필요한 동작이 동일하다면, 테스트 케이스는 여전히 유효함.
ex> 경계값 분석 기법, 동등 분할 기법, 결정 테이블 테스팅, 상태 전이 테스팅, 유즈 케이스 테스팅 기법
화이트박스 테스트 기법
(==구조 기반 기법)
테스트 대상이 내부 구조와 처리에 대한 분석을 기반.
>> 테스트 케이스는 소프트웨어, 설계 방식에 의존하기 때문에 테스트 대상의 설계나 구현이 끝난 후에 만들 수 있다.
ex> 구문테스팅, 결정테스팅, 제어 흐름 테스팅 기법
경험 기반 테스트 기법 테스터의 지식과 경험을 테스트 케이스의 설계 및 구현에 효과적으로 활용. 
이런 기법의 효과성은 테스터의 능력에 따라 크게 달라짐!
경험 기반 테스트 기법은 블랙박스와 화이트박스 테스트 기법으로는 식별하지 못할 수 있는 결함을 찾을 수 있게 해줌. >> 블랙박스 및 화이트박스 테스트 기법을 보완함.

 

 

 

728x90
반응형
용어 정리
: 용어부터 정리해 두고 봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/
인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

경계값 분석 : 경계값을 기반으로 테스트 케이스를 설계하는 블랙박스 테스트 기법.

분기 커버리지 : ==결정 커버리지. 결정된 결과값에 대한 커버리지. 

체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 및 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

커버리지 : 커버리지 항목이 식별되거나 테스트 스위트에 의해 수행된 정도를 백분율로 표시한 것.
커버리지 항목 : 테스트 실행의 완전성을 측정할 수있는 테스트 기법을 사용해 하나 이상의 테스트 컨디션에서 도출하는 속성 또는 속성들의 결합체.

결정 테이블 테스팅 : 테스트 케이스가 결정 테이블에 표시된 조건과 결과 행위 조합을 실행하도록 설계하는 블랙박스 설계 기법.

동등 분할 : 명세에 따라 모든 값이 동일하게 취급될 것으로 예상되는 컴포넌트 또는 시스템 내의 변수 값 도메인의 하위 집합.

오류 추정 : 과거 장애에 대한 테스터의 지식이나 장애 형태에 대한 일반적인 지식에 기초하여 테스트 케이스를 도출하는 테스트 기법.

탐색적 테스팅 : 테스터가 자신의 지식, 테스트 항목에 대한 탐색과 이전 테스트 결과를 기반으로 테스트를 동적으로 설계하고 실행하는 테스트 접근 방식.
상태 전이 테스팅 : 테스트 케이스가 상태 전이 모델의 개별 요소를 실행하도록 설계된 블랙박스 테스트 기법.

구문 커버리지 : 실행 가능한 구문에 대한 커버리지.

테스트 기법 : 테스트 조건을 정의하고, 테스트 케이스를 설계하고, 테스트 데이터를 지정하는 데 사용되는 절차.

블랙박스 테스트 기법 : 컴포넌트나 시스템의 명세에 대한 분석을 기반으로 하는 테스트 기법.

화이트박스 테스트 기법 : 컴포넌트 또는 시스템의 내부 구조에만 기반을 둔 테스트 기법.

경험 기반 테스트 기법 : 테스터의 경험, 지식, 직관에만 기반을 둔 테스트 기법.

4장의 내용은 엄청 많으면서 엄청 중요한 내용이다. 테스트 기법에 대해서도 알아야 되고 분석 문제도 풀 줄 알아야 된다.

샘플문제도 많이 풀어보고 발품팔아 구글링이랑 네이버 블로그 뒤적거려서 문제도 많이 찾아보고 풀어보는 게 좋다.

728x90
반응형
들어가기 전 알아둬야 할 3.1 용어, 3.2 용어 설명.
: 사전적으로 설명정리한 건 바로 앞에 적어둔 블로그 용어 설명ㄱㄱ
사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항.
백로그 :  프로젝트 관리, 소프트웨어 개발, 업무 관리 등 다양한 분야에서 사용되는 용어로, 완료되지 않은 작업 항목들의 리스트나 목록을 가리킴.

공식 리뷰
 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형.
리뷰어 : == 검토자. 작업 산출물의 이슈를 식별하는 리뷰 작업 참여자.

워크스루 : 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의 진행.(비형식적인 검토기법.)
인스펙션 : 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제 해결.(형식적 검토기법.)

퍼실리테이션 : 직역- 용이성,편리성. 집단의 공동의 목적을 쉽게 달성할 수 있도록 도구와 기법을 활용하여 절차를 설계하고 중립적인 태도로 진행 과정을 돕는 활동을 일컬음.

 

3.1 정적 테스팅의 기초
정적 테스팅테스트 대상 소프트웨어를 실행하지 않아도 된다.
테스팅의 목표 품질 개선, 결함 식별, 또한 가독성/완전성/정확성/테스트 용이성/일관성과 같은 특성을 평가하는 것이며 베리피케이션과 밸리데이션 모두에 적용할 수 있다. 
사용자 스토리가 완전하고 이해하기 쉬우며, 테스트 가능한 인수 조건을 가지고 있는지 확인하기 위해 리뷰 기법을 적용할 수 있다. 적절한 질문을 통해 테스터는 제안된 사용자 스토리를 탐색하고, 문제를 제기하며 개선하는 데 도움을 준다.
정적 분석테스트 케이스가 필요 없고, 도구를 사용하는 경우가 많기 때문에 상대적으로 적은 노력으로 동적 테스팅 전에 문제를 식별할 수 있다.
정적 분석주로 구체적인 코드 결함을 식별하는 데 사용하지만, 유지보수성과 보안을 평가하는 데도 사용된다.
맞춤법 검사기나 가독성 도구로 정적 분석 도구의 예라 할 수 있다.

 

3.1.1 정적 테스팅으로 검사 가능한 작업 산출물
  • 정적 테스트를 사용해 거의 모든 작업 산출물을 검토할 수 있다. ex> 요구사항 명세서, 소스 코드, 테스트 계획서, 테스트 케이스, 제품 백로그 항목, 테스트 차터, 프로젝트 문서, 계약서, 모델 등이 그 대상이 될 수 있다.
  • 읽고 이해할 수 있는 모든 작업 산출물은 리뷰 대상이 될 수 있다. But, 정적 분석의 경우, 작업 산출물을 검토할 수 있는 기준이 되는 어떤 구조가 필요하다. ex> 모델, 공식 문법이 정해진 코드나 텍스트.
  • 사람이 해석하기 어려운 것과 도구로 분석해서는 안 되는 작업 산출물(ex> 법적으로 문제가 되는 타사의 실행 코드)은 정적 테스트에 적합하지 않은 작업 산출물이다.
3.1.2 정적 테스팅의 가치
  1. 소프트웨어 개발수명주기 초기 단계에서 결함을 식별하기 때문에 조기 테스팅 원리를 지킬수 있게 한다.
  2. 동적 테스팅으로 식별할 수 없는 결함(ex> 도달 불가능한 코드)을 찾을 수도 있다.
  3. 작업 산출물의 품질을 평가하고 신뢰를 쌓을 방법을 제공한다.
  4. 문서화된 요구사항을 확인함으로써 이해관계자는 요구사항이 실제로 자기가 필요한 것을 묘사하고 있는지 확인할 수 있다.
  5. 소프트웨어 개발수명주기 초기에 수행할 수 있으므로 관련된 이해관계자 간 공통된 이해를 형성할 수 있다. 관련된 이해관계자 간의 의사소통도 개선된다. 때문에 정적 테스팅에 다양한 이해관계자가 참여하는 것이 권장됨.
  6. 리뷰를 구축하는 비용은 클수 있지만, 프로젝트 후반에 결함을 수정하는 시간과 노력이 줄어들어 리뷰를 수행하지 않을 때보다 전체 프로젝트 비용이 훨씬 낮아지는 경우가 많다.
  7. 동적 테스팅 보다 효율적으로 코드 결함을 식별할 수 있으며, 대부분의 경우 결과적으로 코드 결함이 줄고, 전반적인 개발 노력도 감소한다.

 

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.
  • 주어진 목표를 달성할 수 있으면서 작업 산출물 유형, 리뷰 참여자, 프로젝트 요구사항 및 정황에 맞는 리뷰 유형 선택.
  • 리뷰어가 개별 리뷰 또는 리뷰 회의에서 집중력을 잃지 않도록 작은 단위로 리뷰 진행.
  • 이해관계자와 저자에게 리뷰 피드백 제공 >> 제품 및 활동을 개선할 수 있도록 함.
  • 참가자가 리뷰를 준비할 수 있는 충분한 시간 제공.
  • 리뷰 프로세스를 관리층이 지원.
  • 학습 및 프로세스 개선 촉진을 위해 리뷰가 조직 문화의 일부가 되도록 한다.
  • 모든 참가자가 자신의 역할을 어떻게 충족해야 하는지 알수 있도록 적절한 교육 제공.
  • 회의에 퍼실리테이션을 적용.

여기서는 정적 테스팅과 동적테스팅의 차이를 알아야 되며, 리뷰 역할과 책임, 리뷰 유형, 리뷰 성공 요소는 꼭 알아둬야 한다. 샘플 문제에서도 이 부분들의 문제는 하나씩 꼭 등장함!

728x90
반응형
용어 정리
: 용어부터 정리해 두고 먼저 읽어봐야 이해가 쉬움.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/
이상 사항 : ==이상 현상. 요구사항 명세서, 설계 문서, 사용자 문서, 표준 또는 누군가의 인식이나 경험 등에 기반한 기댓값에서 벗어난 상태를 말한다. 이상 현상은 리뷰, 테스팅, 분석, 비교, 혹은 소프트웨어 제품이나 해당 문서의 사용 도중에 발견할 수 있지만, 이에 국한되지는 않음.

동적 테스팅 : 테스팅 항목의 실행과 관련된 테스트.

공식 리뷰 : 공식 산출물로 정의된 프로세스를 따르는 리뷰 유형.
비공식 리뷰 : 정의된 프로세스를 따르지 않고 문서화된 공식 결과가 없는 리뷰 유형.

인스펙션 : 작업 산출물의 이슈를 식별하기 위한 공식리뷰 유형. 리뷰 프로세스와 소프트웨어 개발 프로세스를 개선하는 데 필요한 정보를 제공.

리뷰 : 결함을 발견하거나 개선 사항을 제공하기 위해 한 명 이상의 개인이 작업 산출물 또는 프로세스를 평가하는 정적 테스팅 유형.

정적 분석 : 형식이나 구조, 내용, 문서를 기반으로, 컴포넌트나 시스템을 실행하지 않으면서 평가하는 프로세스.

정적 테스팅 : 테스트 항목의 실행을 수반하지 않는 테스팅.

기술 리뷰 : 작업 산출물의 품질을 검사하고 명세 및 표준과의 불일치를 식별하는 기술 전문가의 공식 리뷰.

위크 쓰루 : == 워크스루. 작성자가 작업 산출물에 대한 리뷰를 주도하고, 참가자들은 발생 가능 이슈에 대한 질문과 의견을 제시하는 리뷰 유형.


3장은 공부시간이 80분으로  6장 테스트 지원도구(20분) 외에 가장 짧은 시간이 필요하다. 읽어보면서 이해하고 넘어가야 80분의 시간 안에 끝낼 수 있다. 아무 생각 없이 읽기만 반복한다면 뫼비우스의 띠처럼 글씨, 글씨, 글씨로 시간이 줄줄이 흘러가 버려지는 시간이 늘어날 수 있다. 도저히 집중이 안된다 싶다면 문제를 풀어보면서 해설을 읽으며 공부해도 좋은 구역이다.

728x90
반응형
들어가기 전 알아둬야 할 2.2 용어, 2.3 용어 설명
: 사전적으로 설명 정리한 건 용어 설명 글 ㄱㄱ, 여기는 이해 쉽게 봐보자.
테스트 레벨 : 테스트 프로세스 중의 특정 예시 단계. 
테스트 유형 :
 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

컴포넌트
 : 개별적으로 테스트할 수 있는 시스템의 최소 구성단위.
엔드 투 엔드 테스팅 : 생산 환경과 유사한 환경에서 비즈니스 프로세스를 처음부터 끝까지 테스트하는 테스팅 유형.
테스트 명세 : 특정 테스트 항목에 대한 테스트 설계, 테스트 케이스, 테스트 스크립트를 모두 담고 있는 문서.

< 기능 테스트 & 비기능 테스트의 기능과 비기능 해석 >
기능 : 무엇을 해야 하는지.
비기능 : 얼마나 잘 돌아가는지.

확인 테스팅 : 원래 결함이 성공적으로 수정됐는지 확인.
리그레션 테스팅 : 변경으로 인해 부정적인 영향 있는지 확인. 확인 테스팅 이후에 리그레션 테스팅하는 거임.

운용 환경 : 움직이는 환경으로 이해 ㄱㄱ.

 

2.2 테스트 레벨과 테스트 유형
- 테스트 레벨 함께 구성하고 관리하는 테스트 활동 집합이다.
: 각 테스트 레벨은 특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스이다.
단계에 따라 소프트웨어는 개별 컴포넌트부터 완성된 시스템에 이를 수 있으며, 경우에 따라서는 시스템의 시스템일 수 있다.
- 테스트 레벨 소프트웨어 개발수명주기 내의 다른 활동과 연관성을 가진다.
: 순차적 소프트웨어 개발수명주기 모델은 한 레벨의 완료 조건이 다음 레벨의 시작 조건에 포함되도록 테스트 레벨을 정의하는 경우가 많다.

- 테스트 유형 특정 품질 특성 관련 테스트 활동의 집합으로, 이런 테스트 활동은 대부분 모든 테스트 레벨에서 수행할 수 있다.

 

2.2.1 실러버스에서 다루는 테스트 레벨 5가지
  • 컴포넌트 테스팅(== 단위 테스팅) : 컴포넌트를 개별적으로 테스트하는 데 중점. 테스트 하네스 또는 단위 테스트 프레임워크와 같은 구체적인 지원 수단이 필요한 경우가 많음. 일반적으로 개발자가 자신의 개발 환경에서 수행함.
  • 컴포넌트 통합 테스팅(== 단위 통합 테스팅) : 컴포넌트 간의 인터페이스와 상호 작용을 테스트하는 데 중점. 상향식, 하향식, 빅뱅 등 통합 전략 접근법에 따라 크게 달라진다.
  • 시스템 테스팅 : 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점. 엔드 투 엔드 동작에 대한 기능 테스팅과 품질 특성에 대한 비기능 테스팅을 포함하는 경우가 많음. 독립 테스트팀이 수행할 수 있으며, 시스템의 명세와 관련이 있음.
  • 시스템 통합 테스팅 : 다른 시스템 또는 외부 서비스와 테스트 대상 시스템의 인터페이스를 테스트하는 데 중점. 가급적 운영 환경과 유사한 적절한 테스트 환경을 사용함.
  • 인수 테스팅 : 밸리데이션과 배포할 준비, 즉 시스템이 사용자의 비즈니스에 필요한 사항을 충족하는지를 확인하는 데 중점. 실제 사용자가 수행하는 것이 이상적. 주요 유형으로 사용자 인수 테스팅, 운영 인수 테스팅, 계약 및 규제 인수 테스팅, 알파 테스팅, 베타 테스팅이 있음.

▶ 테스트 레벨은 테스트 활동의 중복을 피하기 위해 다양한 속성 "테스트 대상, 테스트 목적, 테스트 베이시스, 결함과 장애, 접근법과 역할"들을 고려해 구분한다.

 

2.2.2 실러버스에서 다루는 테스트 유형 4가지
  • 기능 테스팅 : 컴포넌트 또는 시스템이 수행해야 하는 기능을 평가. 기능은 테스트 대상이 "무엇을" 해야 하는지를 의미. 주요 목적 - 기능 성숙도(완전성), 기능 정확성, 기능 타당성(적합성)을 확인하는 것.
  • 비기능 테스팅 : 컴포넌트 또는 시스템의 기능 특성 이외의 속성을 평가. "시스템이 얼마나 잘 동작하는지" 테스트하는 것. 주요 목적 - 비기능 소프트웨어 품질 특성을 확인하는 것.
ISO/IEC 25010 표준은 비기능 소프트웨어 품질 특성을 다음과 같이 분류함.
- 수행 효율성.
- 호환성.
- 유용성.
- 신뢰도.
- 보안.
- 유지 가능성.
- 이동성.

수명 주기 초기에 비기능 테스팅을 시작하는 것이 바람직할 때가 있다.
기능 테스트에서 비기능 테스트를 도출하는 경우도 많다. 이때 기능 테스트에서 기능이 수행되는 동안 비기능 제약 조건의 충족 여부를 확인하게 된다. 비기능 결함을 늦게 발견하면 프로젝트의 성공에 심각한 위협이 될 수 있다.
  • 블랙박스 테스팅 : 명세를 기반으로 하며, 테스트 대상 외부에 있는 문서에서 테스트를 도출. 주요 목적 - 명세와 비교해 시스템의 동작을 확인하는 것.
  • 화이트박스 테스팅 : 구조 기반이며, 시스템의 구현 또는 내부 구조에서 테스트를 도출. 주요 목적 - 테스트를 통해 내부 구조를 인수에 필요한 수준까지 충분히 커버하는 것.

 

2.2.3 확인 테스팅 및 리그레션 테스팅
일반적으로 컴포넌트나 시스템을 변경하는 이유는 새로운 기능을 추가해 개선하거나 결함을 제거해 수정하기 위함이다. 이때는 테스팅에 확인 테스팅과 리그레션 테스팅을 추가할 필요가 있다.
확인 테스팅 원래 결함이 성공적으로 수정됐는지 확인.   
ex > 결함으로 인해 이전에 실패했던 모든 테스트 케이스를 실행한다. 결함을 수정하기 위해 변경한 사항을 확인하는 새로운 테스트를 추가한다.
but, 결함을 수정하는 데 시간이나 비용이 부족한 경우, 결함으로 생긴 장애를 재현하기 위한 절차를 거쳐 장애가 발생하지 않는지 확인하는 것만으로 확인테스팅이 끝날 수도 있다.
리그레션 테스팅 변경으로 인해 부정적인 영향이 없었는지 확인하는 것. 이미 확인 테스팅이 끝난 수정 사항도 여기서 말하는 변경에 포함된다. 테스트 대상 자체에만 국한되지 않고, 환경과도 관련이 있을 수 있음.
리그레션 테스팅의 범위를 최적화하기 위해 영향도 분석을 먼저 수행하는 것이 좋다. 영향도 분석은 소프트웨어의 어느 부분이 영향을 받을 수 있는지 보여줌.
리그레션 테스트 스위트는 반복적으로 실행되며, 리그레션 테스트는 자동화하기 매우 적합한 대상이 됨.
이런 테스트의 자동화는 프로젝트 초기에 시작해야 함. 데브옵스와 같이 지속적 통합을 사용하는 경우, 자동 리그레션 테스트를 포함하는 것이 좋은 프렉티스이다.

▶ 어떤 테스트 레벨이라도 해당 레벨에서 결함을 수정하거나 변경을 적용한 경우, 테스트 대상에 대한 확인 테스팅과 리그레션 테스팅이 필요하다.

 

2.3 유지보수 테스팅
유지보수에는 여러 범주가 있다. 문제를 수정하기 위한 유지보수, 환경 변화에 적응, 성능 또는 유지보수성을 개선하기 위한 것도 있기 때문에 유지보수는 계획된 릴리스/배포 또는 계획되지 않은 릴리스/배포 모두와 연관돼 있다.
운용환경에서 시스템의 변경사항을 테스트하는 것에는 변경 구현의 성공을 검증하는 것과, 변경되지 않은 시스템 영역(보통은 시스템 대부분)에서 발생할 수 있는 리그레션을 확인하는 작업이 모두 포함된다.

▶ 유지보수 테스팅의 범위는 일반적으로 "변경의 리스크 수준, 기존 시스템의 크기, 변경사항의 크기"에 따라 달라진다.

 

< 유지보수와 유지보수 테스팅의 계기 >

  • 계획된 개선사항, 수정을 위한 변경, 핫픽스와 같은 수정사항.
  • 운영 환경의 업그레이드나 마이그레이션 하는 경우, 변경된 소프트웨어뿐만 아니라 새로운 환경 관련 테스트가 필요할 수 있으며, 다른 애플리케이션의 데이터를 유지보수 중인 시스템으로 마이그레이션 할 때, 데이터 변환 테스트가 필요할 수 있다.
  • 애플리케이션의 수명이 다하는 등의 단종. 시스템을 단종할 때 데이터 보존 기간이 길면 데이터 보관 테스팅이 필요할 수 있다. 보관기간 중 데이터가 필요한 경우를 대비해, 보관 이후 복원 및 복구 절차 테스팅이 필요할 수 있다. 

 

 

 

728x90
반응형
들어가기 전 알아둬야 하는 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> 정기적으로 협업 과정을 검토하고 최적화함으로써) 

 


전체적으로 외우지 말고 계속 읽어보는 게 공부가 되는 구역. 


728x90
반응형
용어 정리
: 용어부터 알아둬야 문제 이해가 쉬움.
혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 
++ https://glossary.istqb.org/ko_KR/
테스트 대상: 테스트할 작업 산출물. 

테스트 유형: 컴포넌트나 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합.

테스트 레벨: 테스트 프로세스 중의 특정 예시 단계.

인수 테스팅: 시스템을 승인할지 여부를 결정하는 데 초점을 둔 테스트 레벨.

컴포넌트 테스팅: 개별 하드웨어 또는 소프트웨어 컴포넌트에 초점을 둔 테스트 레벨.

통합 테스팅: 컴포넌트 또는 시스템 간의 상호작용에 중점을 둔 테스트 레벨.

시스템 통합 테스팅: 시스템 간의 상호작용에 초점을 둔 테스트 레벨.

시스템 테스팅:  전체로 봤을 때 시스템이 명시된 요구사항을 충족하는지 확인하는 데 초점을 둔 테스트 레벨.

블랙박스 테스팅: 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식의 테스팅.

화이트 박스 테스팅: 컴포넌트나 시스템의 내부 구조 분석에 기반한 테스팅.

컴포넌트 통합 테스팅: 통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함을 노출시키기 위한 테스팅.

기능 테스팅: 컴포넌트 또는 시스템이 기능 요구사항을 충족하는지 평가하기 위해 수행되는 테스트.

비기능 테스팅: 컴포넌트 또는 시스템이 비기능적 요구사항을 충족하는지 평가하기 위해 수행되는 테스트.

유지보수 테스팅: 운영 중인 시스템에 대한 변화, 또는 운영 중인 시스템에 미치는 환경 변화의 영향에 대한 테스팅.

확인 테스팅: 결함을 수정한 후 해당 결함으로 인해 발생한 장애가 다시 나타나지 않는지 확인하기 위해 수행하는 변경 관련 테스트 유형. 

리그레션 테스팅: 소프트웨어의 변경되지 않은 영역에 결함이 도입 또는 발현되었는지 여부를 감지하기 위한 변경 관련 테스트 유형.

시프트- 레프트: 소프트웨어 개발 라이프 사이클(SDLC)에서 가능한 빨리 보안을 도입하는 것을 의미.

 


시프트레프트는 위에 말한 사이트에서 찾을 수 없어서 구글로 검색해 봤는데 생각보다 이해해 두고 넘어가는 게 중요할 것 같아서 참고할 만한 블로그를 찾았다. 한번 읽어 보고 넘어가는 걸 추천.

https://katalon.com/resources-center/blog/shift-right-testing

 

What is Shift Right Testing? Shift Left vs. Shift Right

Learn about the concept of shift right testing, its benefits, and the major differences between shift-left vs. shift-right testing.

katalon.com

 

 

 

 

 

728x90
반응형

+ Recent posts