//구글콘솔 광고 추가가

룰루루루루루룰루 블로그에 짧은 후기를 남기고 한동안 가을만 느끼며 살던 나에게 기적 같은 일이 일어났다.
찍었던 문제가 다 맞은 것인지 푼 문제가 다 맞은 것인지 합격을 했다.
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
반응형
6.1 테스팅 지원 도구
< 테스트 도구는 다양한 테스트 활동을 지원하고 촉진한다! >
관리 도구 소프트웨어 개발수명주기, 요구사항, 테스트, 결함, 형상 관리를 용이하게 해서 테스트 프로세스 효율성을 높인다.
정적 테스팅 도구 테스터의 리뷰와 정적 분석 수행을 지원한다.
테스트 설계 및 구현 도구 테스트 케이스, 테스트 데이터, 테스트 절차 생성을 용이하게 한다.
테스트 실행 및 커버리지 도구 자동 테스트 실행 및 커버리지 측정을 지원한다.
비기능 테스팅 도구 수동으로 실행하기 어렵거나 불가능한 비기능 테스트를 테스터가 수행할 수 있게 한다.
데브옵스 도구 데브옵스 배포 파이프라인, 작업 흐름 추적, 자동 빌드 프로세스, 지속적인 통합 및 배포 등을 지원한다.
협업 도구 원활한 커뮤니케이션을 지원한다.
확장성 및 배포 표준화 지원 도구 ex. 가상머신, 컨테이너화 도구.
테스팅에 도움이 되는 기타 도구 ex. 테스팅에 활용하면 스프레드시트도 테스트 도구가 된다.

 

6.2 테스트 자동화의 효과와 리스크

 

테스트 자동화가 가져올 수 있는 효과

  • 반복적 수작업을 줄여 시간 절약.
  • 일관성 및 재현성 향상으로 사람의 단순 실수 방지.
  • 더욱 객관적인 평가 및 사람이 도출하기 너무 복잡한 측정치의 제공.
  • 테스트 관리 및 테스트 보고에 필요한 테스팅 정보의 접근성 향상.
  • 결함 조기 식별, 빠른 피드백, 출시 시간 단축을 가능하게 하는 테스트 실행 시간 단축.
  • 테스터가 새로운, 그리고 더 심층적이며 효과적인 테스트를 설계할 시간 확보.

테스트 자동화 활용 시 잠재적 리스크

  • 도구의 효과에 대한 비현실적인 기대.
  • 도구 도입, 테스트 스크립트 유지 관리, 기존 수동 테스트 프로세스 변경에 필요한 시간, 비용, 노력에 대한 부정확한 추정.
  • 수동 테스팅이 더 적합한 곳에 테스트 도구 사용.
  • 도구에 지나치게 의존.
  • 폐업, 도구 지원 중단, 다른 공급업체로 도구 매각, 열악한 지원 등의 문제가 생길 수 있는 도구 공급업체에 대한 종속성.
  • 지원이 중단되거나 , 추가 개발을 통해 내부 컴포넌트를 빈번하게 업데이트해야 할 필요가 있을 수 있는 오픈 소스, 소프트웨어의 사용.
  • 자동화 도구가 개발 플랫폼과 호환되지 않을 수 있음.
  • 규제 요건이나 안전 표준을 준수하지 않는 부적합한 도구의 선택.

ISTQB 4.0 정리가 끝났다. 이제는 다시 처음부터 외우면서 문제를 풀어봐야겠다.

시험이 3주 남았으니까 잘 준비해 보면 지난번 시험보단 확실히 점수가 잘 나오지 않을까 싶은데.

정리를 하면서 느낀 점은 확실히 처음에 무조건적으로 외울 때보다 자세하게 이해를 할 수 있었던 것 같다.

역시 무작정 외우는 것보단 확실하지 않아도 이해를 어느 정도 했느냐가 더 중요한 것 같다.

문제로 푸는 소프트웨어 테스팅 책이 너무 기대가 된다. 드디어 나에게도 풀 수 있는 문제집이 있다니!! 다시 생각해도 잘 산 것 같다. 시간이 좀 많이, 아주 많이 많이 지났지만 그래도 풀 문제가 있다는 사실이 너무 좋다.

 

자 다시 해보자고!

 

728x90
반응형
들어가기 전 알아둬야 할 5.4 용어, 5.5 용어 설명
형상 관리 : 변경 사항을 체계적으로 추적, 통제한다는 것.

베이스 라인 : 기준, 기준치, 기준선. 각 형상항목들의 기술적 통제시점으로 개발 과정의 각 단계별 산출물을 검토, 평가, 조정, 처리 등의 모든 변화를 통제하는 시점의 기준.

지속적 통합 : 커밋되는 즉시 모든 변경 사항을 병합, 통합 및 테스트하는 자동화된 소프트웨어 개발 절차.
지속적 테스팅 : 소프트웨어 릴리스 후보와 관련된 비즈니스 리스크에 대한 피드백을 가능한 빨리 얻기 위해 조기에 테스트하고, 자주 테스트하고, 모든 곳에서 테스트하고, 자동화하는 프로세스포함하는 접근 방식.

결함 보고서 : == 인시던트 보고서. 결함의 발생, 유형, 상태에 대한 문서.

 

5.4 형상 관리
: 식별, 제어, 추적
테스팅에서 형상 관리는??
: 테스트 계획서, 테스트 전략서, 테스트 컨디션, 테스트 케이스, 테스트 스크립트, 테스트 결과, 테스트 로그, 테스트 보고서와 같은 작업 산출물을 형상 항목으로 식별, 제어, 추적하는 지침을 제공한다.

복잡한 형상 항목의 경우 형상 관리는 구성 항목, 항목 간 관계, 버전 등을 기록.
형상 항목이 테스팅용으로 승인되면 베이스라인이 되며, 공식적인 변경 제어 프로세스를 통해서만 수정할 수 있다.

형상 관리는 새 베이스라인을 만들 때 변경된 형상 항목에 대한 기록을 유지한다. 이전 베이스라인으로 되돌리면 이전 테스트 결과를 재현할 수 있게 된다.

 

테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다.

  • 테스트 항목을 포함한 모든 형상 항목에는 고유한 식별지가 부여, 버전 관리, 변경사항 추적, 다른 형상 항목과 가지는 연관성 식별 ==> 테스트 프로세스 전체에 추적성 유지.
  • 식별된 모든 문서와 소프트웨어 항목은 테스트 문서에서 명확히 참조됨.

▶ 지속적 통합, 지속적 전달, 지속적 배포, 그리고 관련된 테스팅은 일반적으로 자동화된 데브옵스 파이프라인으로 구현하며, 여기에 보통 자동화된 형상 관리가 포함돼 있다.

 

5.5 결함 관리
테스트의 주요 목적 중 하나가 결함 식별이므로 잘 확립된 결함 관리 프로세스가 필요하다.

이상 현상은 소프트웨어 개발수명주기 모든 단계에서 보고 될 수 있다.

결함 관리 프로세스에는 기본적으로 개별 이상 현상을 발견 부터 종료까지 처리하는 작업 흐름과 분류 규칙이 포함되어야 한다.
>> 이 작업 흐름은 보통, 보고된 이상 현상을 기록하고, 분석 및 분류하고, 수정하거나 유지하기로 하는 등의 적절한 대응책을 결정하고, 끝으로 결함 보고를 종료하는 활동으로 구성된다. 이 프로세스는 관련된 모든 이해관계자가 따라야 한다. 정적 테스팅에서 식별한 결함도 비슷한 방식으로 처리하는 것이 좋다.
< 결함 보고서의 목적 >
1. 결함을 처리 및 해결하는 책임을 진 사람에게 문제 해결을 위한 충분한 정보 제공.
2. 작업 결과물의 품질을 추적할 수 있는 수단 제공.
3. 개발 및 테스트 프로세스 개선을 위한 아이디어 제공.
< 동적 테스팅 중에 작성하는 결함보고서에 포함될 내용 >
1. 고유 식별자.
2. 보고하는 이상 현상을 요약하는 제목.
3. 이상 현상이 관찰된 날짜, 보고 주체 조직, 작성자(역할 포함)
4. 테스트 대상 및 테스트 환경 식별 정보.
5. 결함의 정황.
6. 이상 현상을 발견한 절차, 관련 테스트 로그, 데이터 베이스 덤프, 스크린 샷, 녹음파일 등 장애의 재현 및 해결에 필요한 정보.
7. 기대 결과와 실제 결과.
8. 결함이 이해관계자의 이익 또는 요구사항에 끼치는 영향의 심각도. 
9. 수정 우선순위.
10. 결함 상태.
11. 참조 사항.

 

 

728x90
반응형
들어가기 전 알아둬야 할 5.3 용어 설명
마일스톤 : 프로젝트 진행 과정에서 특정할 만한 건이나 표를 말함. 프로젝트 계획에서 진척 상황을 나타내는 강력한 이정표.

메트릭 : 측정에 쓰이는 측정 척도와 방법.

번다운 차트 : 잔여 작업량과 잔여 시간을 세부적으로 비교해 애자일 팀이 기한까지 어떻게 작업하고 있는지를 시각적으로 나타냄. == 시간에 따라 남아있는 작업의 양을 보여주는 시각적 표현. (팀이 업무를 완료하는 데 충분한 시간이 있는지 효율적으로 계산하기 위해 사용. 일반적으로 짧은 반복 작업을 할 때 사용 된다.)

 

5.3 테스트 모니터링, 테스트 제어, 테스트 완료
테스트 모니터링 : 테스팅에 대한 정보 수집과 관련이 있다. 이 정보는 테스트 진행 상황을 판단하고 테스트 완료 조건 또는 완료 조건과 관련된 테스트 업무가 충족됐는지 측정하는 데 사용.

테스트 제어 : 테스트 모니터링에서 얻은 정보로 가장 효과적이고 효율적인 테스팅을 위한 제어 지침/지도/필요 수정 조치 등을 제공.
제어지침 ex.
1. 식별된 리스크가 발현될 경우 테스트 우선순위 재지정.
2. 재작업 이후 테스트 항목이 시작 조건 및 완료 조건을 충족하는지 재평가.
3. 테스트 환경 인도 지연에 대응하기 위한 테스트 일정 조정.
4. 필요한 지점과 시기에 신규 자원 추가.

테스트 완료 : 끝난 테스트 활동에서 데이터를 수집하여 경험, 테스트웨어, 기타 관련 정보를 수집하는 단계.
테스트 완료 활동은 어떤 프로젝트 마일스톤에 도달했을 때 이루어짐. 테스트 레벨이나 애자일 반복 주기의 끝, 테스트 프로젝트를 완료(또는 취소)한 시점, 소프트웨어를 배포했거나 유지보수 릴리스를 끝냈을 때 등이 여기에 해당.

 

5.3.1 테스팅에 사용하는 메트릭
테스트 메트릭 : 계획한 일정 및 예산 대비 현재 진행 상황, 테스트 대상의 현재 품질, 테스트 목적이나 반복 주기 목표 대비 테스트 활동의 효과를 보여주기 위해 수집한다.

테스트 모니터링은 테스트 제어 및 테스트 완료 활동을 지원하는 다양한 메트릭을 수집한다.
< 많이 사용하는 테스트 메트릭 7가지 >
프로젝트 진행 상황 메트릭 ex. 작업 완료율, 자원 사용률, 테스트 노력 투입률
테스트 진행 상황 메트릭 ex. 테스트 케이스 구현 진행률, 테스트 환경 준비 진행률, 실행/미실행 및 합격/불합격 테스트 케이스 수, 테스트 실행 시간.
제품 품질 메트릭 ex. 가용성, 응답 시간, 평균 장애 시간.
결함 메트릭 ex. 발견/수정한 결함의 수와 우선순위, 결함 밀도, 결함 발견 비율.
리스크 메트릭 ex. 잔여 리스크 수준.
커버리지 메트릭 ex. 요구사항 커버리지, 코드 커버리지.
비용 메트릭 ex. 테스팅 비용, 조직의 품질 비용.

 

5.3.2 테스트 보고서의 목적, 내용, 대상
테스트 보고 : 테스팅 도중과 이후에 테스트 정보를 요약해 전달하는 활동.

테스트 진행 상황 보고서
: 테스팅의 지속적인 관리를 지원. 계획에서 벗어나거나 상황이 바뀌어 테스트 일정, 자원, 테스트 계획을 수정해야 할 경우 그것을 할 수 있는 충분한 정보를 제공해야 함.

테스트 완료 보고서
: 테스팅의 특정 단계(ex. 테스트 레벨, 테스트 주기, 반복 주기)를 요약하고, 후속 테스팅을 위한 정보를 제공할 수 있다.

>> 테스트 진행 상황 보고서는 테스트 모니터링, 제어 과정에서 작성을 하고 테스트 완료에서 가장 많이 활용함.

 

▶ 테스트 모니터링 및 제어 과정 중 테스트팀은 이해관계자에게 정보를 제공하기 위해 테스트 진행 상황 보고서를 작성한다. 일반적으로 테스트 진행 상황 보고서는 정기적으로 작성한다.

< 테스트 진행 상황 보고서에 들어가는 내용 >
- 테스트 기간
- 테스트 진행 상황, 주목할 만한 편차 포함.
- 테스팅 진행 방해 요소와 대응 방법.
- 테스트 메트릭.
- 테스팅 중 식별할 신규 및 변경된 리스크.
- 다음 주기에 예정된 테스팅.

 

▶ 테스트 완료 보고서는 프로젝트, 테스트 레벨, 테스트 유형이 끝나고, 이상적으로는 완료 조건도 충족된 상황에서 이루어지는 테스트 완료 활동 중 작성한다. 이 보고서는 테스트 진행 상황 보고서와 기타 데이터를 기반으로 작성한다.

< 테스트 완료 보고서에 들어가는 내용 >
- 테스트 요약.
- 원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가.
- 테스트 계획과의 편차.
- 테스팅 방해 요소와 대응 방법.
- 테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭.
- 완화되지 않은 리스크, 수정되지 않은 결함.
- 테스팅 관련 교훈.

 

5.3.3 테스팅 상황 전달
테스트 상황을 전달하는 가장 좋은 의사소통 방법 테스트 관리자의 관심, 조직의 테스트 전략, 규제 표준, 자체 조직 팀일 경우 팀 자체에 따라 달라진다.
< 좋은 의사 소통 방법 >
- 팀원 및 기타 이해관계자와의 대화.
- 대시보드(ex. "지속적 통합"/ "지속적 전달" 대시보드, 태스크 보드, 번다운 차트)
- 전자 통신 채널(ex. 이메일, 채팅)
- 온라인 문서.
- 공식 테스트 보고서.

 

 

728x90
반응형
들어가기 전 알아둬야 할 5.2 용어 설명
: 이해 ㄱㄱ
프로젝트 리스크 : 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 프로젝트의 성공에 영향을 미칠 때, 그러한 잠재적인 문제들을 프로젝트 리스크라고 부름. ex> 프로젝트의 완성을 연기시킬 수 있는 인력 부족.
제품 리스크(== 품질 리스크) : 잠재적인 문제가 발생해 이로 인한 직접적인 효과가 제품의 품질에 영향을 미칠 때, 그러한 잠재적인 문제들을 제품리스크라고 부름. ex. 제품을 사용하는 일반적인 상황아래서 시스템 크래시를 일으키는 잠재적 신뢰성 결함.

++ < 리스크 대응 4가지 방법 >
- 리스크 수용 : (== 리스크 흡수) 반복적이고 피해가 크지 않은 리스크의 경우, 이 리스크에 대해 아무것도 하지 않고 피해를 받아들인다고 결정할 수 있는데 이것이 리스크 수용이다.
- 리스크 완화 : 리스크 빈도와 강도를 낮추기 위한 대응을 하는 것을 의미.
- 리스크 전가 : 리스크를 다른 제 3자에게 넘기는 것을 의미.
- 리스크 회피 : 리스크를 감당하는 것을 피하는 것. 발생하면 너무 피해가 클 것으로 예상되는 리스크의 경우 회피 대응을 할 수 있다. ex. 계약 협상 시 계약서 조항에 예외 조항을 넣거나 몇몇 조문을 거부함.

 

5.2 리스크 관리
리스크 관리란?
: 조직이 목표를 달성할 가능성과 제품의 품질을 높이고 이해관계자의 신뢰와 믿음을 얻을 수 있게 한다.
주요 리스크 관리 활동 2가지
리스크 분석 리스크 식별과 리스크 평가로 구성.
리스크 제어 리스크 완화와 리스크 모니터링으로 구성.
리스크 기반 테스팅이란
: 리스크 분석과 리스크 제어를 기반으로, 테스트 활동을 선택하고 우선순위를 정해 관리하는 테스트 접근법.

 

5.2.1 리스크의 정의와 리스크의 속성
: 리스크 발생 가능성과 리스크 영향도는 독립적이다.
리스크 : 발생시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황을 말한다.

< 리스크의 특징 두 가지 요소 >
1. 리스크 발생 가능성 - 리스크 발생 확률(0보다 크고 1보다 작음).
2. 리스크 영향(피해) - 발생했을 때 생기게 될 피해.
>> 이 두가지 요소로 리스크 수준을 표현한다.

▶ 리스크 수준 = 리스크를 측정한 값.
리스크 수준이 높을수록 그에 대한 조치 또한 중요해진다.

 

5.2.2 프로젝트 리스크와 제품 리스크
프로젝트 리스크 프로젝트 관리 및 제어와 관련.
프로젝트 리스크가 발생하면 프로젝트 일정, 예산, 범위에 영향을 끼쳐 프로젝트의 목표 달성 능력에 영향을 미칠 수 있다.
프로젝트 리스크 예시 :
- 조직 문제(ex. 작업 산출물 인도 지연, 부정확한 추정, 예산 축소)
- 인력 문제(ex. 기술 부족, 갈등, 의사소통 문제, 직원 부족)
- 기술적 문제(ex. 협의되지 않은 개발 범위의 점진적 추가, 도구 지원 부족)
- 공급업체 문제(ex. 제 3자 인도 실패, 지원 기업의 파산)
제품 리스크 제품 품질 특성과 관련.
제품 리스크의 예시 : 누락 또는 잘못된 기능, 부정확한 계산, 런타임 오류, 열악한 아키텍처, 비효율적인 알고리즘, 부적절한 응답 시간, 열악한 UX(사용자 결험, user experience), 보안 취약점 등.
제품 리스크가 발현됬을 때 오는 부정적인 결과 예시 :
- 사용자 불만족.
- 매출, 신뢰, 평판 손실.
- 제 3자의 피해.
- 높은 유지보수 비용, 고객지원 부서의 과부하.
- 형사 처벌.
- 극단적일 경우 신체적 손상, 부상 또는 사망.

 

5.2.3 제품 리스크 분석
< 테스팅 관점에서 제품 리스크 분석의 목표 >
: 제품 리스크를 인식해 잔존 제품 리스크 수준을 최소화하는 방향으로 테스트 노력을 집중할 수 있도록 하는 것.
- 제품 리스크 분석은 소프트웨어 개발수명주기 초기에 시작하는 것이 이상적.

제품 리스크 분석은 리스크 식별과 리스크 평가로 이루어진다.
리스크 식별 포괄적인 리스크 목록을 생성하는 것.
이해관계자는 브레인스토밍, 워크숍, 인터뷰, 원인-결과 다이어그램 등 다양한 기법과 도구를 사용해 리스크를 식별.
리스크 평가 식별한 리스크를 분류하고, 리스크 발생 가능성/영향/수준을 결정하고, 우선순위를 정해 조치 방법을 제안하는 작업을 포함.

 

▶ 리스크 평가는 정량적 또는 정성적 접근법을 사용하거나, 두 가지를 혼합해 사용할 수 있다.

  • 정량적 접근법 : 리스크 수준은 리스크 발생 가능성과 리스크 영향을 곱한 값으로 계산.
  • 정성적 접근법 : 리스크 행렬을 사용해 리스크 수준을 판단.

제품 리스크 분석은 테스팅의 강도와 범위에 영향을 미칠 수 있다.

   

< 분석 결과 활용 방향 >

  • 테스팅 수행 범위 결정.
  • 테스트 레벨 결정 및 수행할 테스트 유형 제안.
  • 사용할 테스트 기법과 달성할 커버러지 결정.
  • 업무별 필요 테스트 노력 추정.
  • 중요 결함을 가능한 빨리 식별하기 위한 테스트 우선순위지정.
  • 리스크를 줄이기 위해 테스팅 외 다른 활동을 할 수 있는지 판단.

>> 평가된 리스크 수준은 테스팅을 얼마나 엄격하게 해야 하는지 판단하는 데 도움이 된다.(철저성과 범위에 영향)

 

5.2.4 제품 리스크 제어
제품 리스크 제어는 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치를 말한다.

제품 리스크 제어는 리스크 완화와 리스크 모니터링으로 이루어진다.
리스크 완화 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동.
리스크 모니터링 목적 : 리스크 완화 조치가 효과적인지 확인하고, 리스크 평가 개선을 위해 추가로 필요한 정보를 확인하고, 새롭게 나타난 리스크를 식별.

 

제품 리스크 제어 측면에서 리스크를 분석하면 거기에 대응하기 위한 다양한 완화 방안을 수립할 수 있다.

ex. 테스팅을 통한 리스크 완화, 리스크 수용, 리스크 전가, 대안 계획 등.

 

테스팅으로 제품 리스크 완화를 위해 취할 수 있는 조치

  • 주어진 리스크 유형에 적절한 경험과 기술을 갖춘 테스터 선정.
  • 적절한 수준의 테스팅 독립성 적용.
  • 리뷰 및 정적 분석 수행.
  • 적절한 테스트 기법 및 커버리지 수준 적용.
  • 영향을 받는 품질 특성을 다루는 적절한 테스트 유형 적용.
  • 리그레션 테스팅을 포함한 동적 테스팅 수행.

 

 

728x90
반응형
들어가기 전 알아둬야 할 5.1 용어 설명
: 이해 중심! 부족하면 용어 설명 글 참고.
테스트 프로세스 : 테스트 계획, 테스트 모니터링 및 제어, 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행, 테스트 완료로 상호 연관되어 구성된 활동들의 집합.

제품 백로그 : 제품을 개발하기 위해 수행할 작업의 목록과 우선순위. 제품 소유자가 관리하며 고객의 언어로 기록된다.

스모크 테스트 : 소프트웨어가 기본적인 기능을 수행할 수 있는지, 즉 연기를 내지 않는지 확인하는 테스트를 의미.

메트릭 : 측정을 위해 사용되는 측정 척도 및 방법.

테스트 피라미드 : 레벨별 테스트 양의 관계를 나타내는 시각적 모델로, 테스트 양은 상단보다 하단에 더 많이 분표 돼 있음.
입도 : 세분화된 수준, 상세화 수준.

테스팅 사분면 : 특정 이해관계자 대상으로 하는 등의 여러기준에 따라 테스트 레벨과 테스트 유형을 그룹화한다.

 

5.1 테스트 계획
- 5.1.1 테스트 계획서의 목적과 내용
테스트 계획서란?
: 테스트 프로젝트의 목적, 자원, 프로세스를 설명한다.

< 테스트 계획서의 목적 >
- 테스트 목적 달성을 위한 방법과 일정을 문서화한다.
- 수행한 테스트 활동이 정해진 기준을 충족하는 데 도움을 준다.
- 팀원과 기타 이해관계자의 의사소통 수단으로 사용된다.
- 테스팅이 수립한 테스트 정책 및 전략을 준수함을 보여준다.( or 테스팅이 그것을 준수하지 않는 이유를 설명.)

테스트 계획 활동은 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 함.
테스트 계획서를 준비하는 과정은 테스트 프로젝트의 목적을 달성하는 데 필요한 노력을 추론하는 유용한 방법이다.

< 테스트 계획서의 내용 >
내용 예시
테스트 정황. ex. 범위, 테스트 목적, 제약 사항, 테스트 베이시스.
테스트 프로젝트의 가정 및 제약 사항.  
이해관계자. ex. 역할, 책임, 테스팅 관련성, 채용 및 훈련 요구사항.
의사소통. ex. 의사소통 방법 및 빈도, 문서 양식.
리스크 목록. ex. 제품 리스크, 프로젝트 리스크.
테스트 접근법. ex. 테스트 레벨, 테스트 유형, 테스트 기법, 테스트 산출물, 시작 조건 및 완료 조건, 테스팅의 독립성, 수집할 메트릭, 테스트 데이터 요구사항, 테스트 환경 요구사항, 조직의 테스트 정책 및 테스트 전략과의 편차.
예산 및 일정.  

 

5.1.2 반복 주기와 릴리스 계획에 대한 테스터의 기여
반복적 소프트웨어 개발수명주기에서의 두가지 계획
릴리스 계획 제품 릴리스를 계획하는 단계.

>> 제품 백로그를 (재)정의하며, 큰 사용자 스토리를 작은 사용자 스토리들로 세분화하는 작업을 포함할 수 있다.
>> 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.
릴리스 계획에 참여하는 테스터는 
1. 테스트 가능한 사용자 스토리와 인수 조건이 작성되도록 함.
2. 프로젝트 및 품질 리스크 분석에 참여.
3. 사용자 스토리와 관련된 테스트 노력을 추정.
4. 테스트 접근법을 결정.
5. 릴리스를 위한 테스팅을 계획.
반복 주기 계획 개별 반복 주기를 계획하는 것.

>> 반복 주기 백로그와 관련이 있다.
반복 주기 계획에 참여하는 테스터는
1. 사용자 스토리의 구체적인 리스크 분석에 참여.
2. 사용자 스토리의 테스트 용이성을 판단.
3. 사용자 스토리를 업무(특히 테스팅 업무) 단위로 분류.
4. 각 테스팅 업무에 필요한 테스트 노력을 추정.
5. 테스트 대상의 기능 및 비기능적 측면을 식별하고 구체화.

 

5.1.3 시작 조건과 완료 조건

 

시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며 테스트 목적에 따라 달라진다.
시작 조건( == 준비의 정의) 어떤 활동을 수행하기 위한 전제 조건을 정의한다.
가장 많이 사용하는 시작 조건
1. 자원의 가용성.(ex. 인력, 도구, 환경, 테스트 데이터, 예산, 시간)
2. 테스트웨어 가용성.(ex. 테스트 베이시스, 테스트 가능한 요구사항, 사용자 스토리, 테스트 케이스)
3. 테스트 대상의 초기 품질 수준.(ex. 모든 스모크 테스트가 합격함)
완료 조건( == 완료의 정의) 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항을 정의한다.
널리 활용하는 완료 조건
1. 충분함에 대한 측정.(ex. 달성한 커버리지 수준, 해결되지 않은 결함 수, 결함 밀도, 실패한 테스트 케이스 수)
2. 종료 기준.(ex. 계획한 모든 테스트 실행, 정적 테스트 수행, 발견한 모든 결함 보고, 모든 리그레션 테스트 자동화 완료)
3. 시간 및 예산의 소진 : 이때 이해관계자들이 추가 테스트 없이 배포하는 리스크를 검토하고 수용했다면, 다른 완료 조건이 충족되지 않더라도 테스트를 종료할 수 있다.

 

5.1.4 추정 기법
테스트 노력 추정은 테스트 프로젝트의 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것이다.
추정에는 항상 오류가 있을 수 있다는 점을 이해관계자가 명확히 이해하도록 하는 것이 중요하다.

보통은 규모가 큰 작업보다 작은 작업에 대한 추정치가 정확.
따라서 큰 작업에 대해 추정할 때는 우선 여러개의 작은 작업으로 나눈 다음 추정.
< 4가지 추정 기법 > 
메트릭 기반 기법 비율 기반 추정 조직에서 수행한 이전 프로젝트 수치를 수집해 유사 프로젝트를 위한 "표준" 비율을 도출.
보통, 조직에서 직접 수행한 프로젝트에서 수집한 비율이 추정 과정에 사용하기 가장 좋은 자료로 이런 표준 비율을 가지고 새로운 프로젝트에 필요한 테스트 노력을 추정할 수 있다.
ex. 이전 프로젝트에서 개발 노력 대 테스트 노력의 비율이 3:2였고, 현재 프로젝트에서 개발 노력을 600MD로 예상한다면, 테스트 노력은 400MD로 추정할 수있음.
외삽법 현재 프로젝트에서 데이터 수집을 위해 가능한 빨리 측정을 수행.
관찰 결과가 충분히 쌓이면 이 데이터를 가지고 외삽법을 적용해 남은 작업에 필요한 노력의 근사치를 추정할 수 있다.
이 방법은 반복적 소프트웨어 개발수명주기에 매우 적합.
ex. 팀이 지난 세번의 반복 주기에 들인 평균 노력으로 다음 반복 주기의 테스트 노력을 추정할 수 있다.
반복적, 전문가 기반 기법 와이드밴드 델파이 반복적, 전문가 기반 기법으로 전문가의 경험을 기반으로 추정한다.
각 전문가는 독립적으로 노력을 추정. 결과를 수집해서 합의된 범위를 벗어난 편차가 있다면 전문가들이 각자의 추정치에 대해 논의한다. 그 다음 각 전문가에게 논의 결과를 바탕으로 다시 한번 새로운 추정치를 제시하도록 한다.
합의에 도달할 때까지 이과정을 반복한다.
ex. 플래닝 포커는 애자일 소프트웨어 개발에서 많이 사용하는 와이드밴드 델파이의 변형이다. 플래닝 포커는 보통 노력의 규모를 나타내는 숫자가 적힌 카드를 사용해 추정한다.
전문가 기반 기법 3점 추정 전문가가 세개의 추정치를 도출한다.
추정치는 가장 낙관적인 추정치(a), 확률적으로 가장 높은 추정치(m), 가장 비관적인 추정치(b)이며 최종 추정치(E)는 이들의 가중 산출 평균이 된다.
>> 계산식 : E = (a + 4*m + b)/6
     표준 편차(SD) 계산식 : SD = (b-a)/6 
ex. 추정치(MH)가 a=6, m=9, b=18인 경우, E = (6 + 4*9 +18) / 6 =10,
SD = (18 - 6) / 6 = 2 이므로 최종 추정치는 10±2(즉 8과 12 사이의 맨아워)가 됨.

 

5.1.5 테스트 케이스 우선순위지정
테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다. 테스트 일정은 테스트 실행 순서를 정의한다.
< 많이 사용하는 테스트 케이스 우선순위지정법 3가지 >
리스크 기반 우선순위지정 리스크 분석 결과에 따라 테스트 실행 순서를 결정.
가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행.
커버리지 기반 우선순위지정 테스트 실행 순서를 커버리지에 따라 결정.
가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행.
"추가 커버리지 우선순위지정"이라는 다른 변형에서는, 가장 높은 커버리지를 달성하는 테스트 케이스가 먼저 실행된다. 이후에 실행하는 각각의 테스트 케이스는 가장 높은 추가 커버리지를 달성하는 것이다.
요구사항 기반 우선순위지정 테스트 실행 순서를 해당 테스트 케이스의 기반이 되는 요구사항의 우선순위에 따라 결정.
요구사항의 우선순위는 이해관계자가 정의.
가장 중요한 요구사항 관련 테스트 케이스를 먼저 실행.
>> 위에서 언급한 3가지 중 하나, 또는 여러 전략을 사용해 우선순위를 지정해서 테스트 케이스 실행 순서를 도출하는 것이 이상적이다. But, 테스트 케이스 또는 테스트 대상 기능이 종속성을 가진 경우 그렇게 하기 힘들 수 있다.

테스트 실행 순서에는 자원의 가용성도 고려해야 한다.
ex. 필요한 테스트 도구, 테스트 환경, 인력이 가용한 시기가 따로 있을 수 있다.

 

5.1.6 테스트 피라미드

< 테스트 피라미드 >
- 테스트에 따라 입도가 다를 수 있다는 것을 보여주는 모델.
- 테스트 피라미들 모델 : 테스트 자동화 수준에 따라 지원하는 목표가 다를 수 있다는 것을 보여줌으로써 팀의 테스트 자동화와 테스트 노력 할당을 도와준다.
- 피라미드 각 층은 하나의 테스트 그룹을 나타냄. 층이 올라갈 수록 테스트 입도가 낮고, 테스트 격리가 어려워지며, 테스트 실행 시간도 길어진다.

아래층 아래층에 있는 테스트는 규모가 작고, 독립적이며, 빠르고, 대상이 되는 기능이 작기 때문에 적절한 커버리지를 달성하기 위해 많은 테스트가 필요한 경우가 많다.
높은 층 복잡하고 상위 수준의 엔드-투-엔드 테스트를 대변한다. 이런 상위 수준 테스트는 보통 하위층의 테스트보다 속도가 느리며, 큰 규모의 기능을 확인하기 때문에 적은 수로 적절한 커버리지를 달성할 수 있다.
층의 수와 각 층의 명칭은 다를 수 있다.
ex. 최초의 테스트 피라미드 모델은 "단위 테스트", "서비스 테스트", "UI 테스트"라는 세 개의 층을 정의했다. 단위(컴포넌트) 테스트, 통합(컴포넌트 통합) 테스트, 엔드-투-엔드 테스트로 정의하는 모델도 많이 알려져 있다. 

 

5.1.7 테스팅 사분면

1 사분면 (기술, 팀) 컴포넌트 및 컴포넌트 통합 테스트를 포함.
이런 테스트는 자동화해야 하며, 지속적인 통합 프로세스에 포함돼야 함.
2 사분면 (비즈니스, 팀) 기능 테스트, 예제, 사용자 스토리 테스트, 사용자 경험 프로토타입, API 테스팅, 시뮬레이션 등 포함.
이런 테스트는 인수 조건을 확인하며, 수동으로 실행하거나 자동화할 수 있다. 
3 사분면 (비즈니스, 제품 평가) 탐색적 테스팅, 사용성 테스팅, 사용자 인수 테스팅을 포함.
이런 테스트는 사용자를 중심으로 이루어지며, 수동으로 실행하는 경우가 많다.
4 사분면 (기술, 제품 평가) 스모크 테스트, 비기능 테스트(사용성 테스트 제외)를 포함.
이런 테스트는 자동화되는 경우가 많다.

 


테스팅 사분면은 반드시 나올 테니 꼭 외워야 함.

나의 경우 1기팀자컴, 2비팀자수기능사용자스토리, 3비제수탐색인수, 4기제자스모크비기능으로 외웠다.

기술 측면인지 비즈니스 측면인지, 팀지원인지 제품 평가인지, 자동화인지 수동인지, 예시로 무슨 테스팅이 들어가는지 찾을 수 있어야 한다. 그냥 간단하게 저 4분면을 그릴 수 있게 외우면 만사가 해결된다. 외울게 많은 5장이다. 잘 알아두자.

 

 

728x90
반응형
용어 정리
: 실러 버스 용어 정리. 들어가기 전에 한번 읽어보자.
▼ 혹시나 더 찾아보고 싶은 단어가 있다면 여기로 가서 찾아보기 ▼
++ https://glossary.istqb.org/ko_KR/
결함 관리 : 결함을 인식 및 기록, 분류, 조사, 해결, 처리하는 프로세스.

결함 보고서 : 결함의 발생, 유형, 상태에 대한 문서.

시작 조건 : 정의된 과업을 공식적으로 시작하기 위한 조건의 집합.

완료 조건 : 정의된 과업을 공식적으로 완료하기 위한 조건들의 집합.

제품 리스크 : 제품의 품질에 영향을 미치는 리스크.
프로젝트 리스크 : 프로젝트 성광에 영향을 미치는 리스크.

리스크 : 미래에 부정적인 결과를 초래할 수 있는 요소.

리스크 분석 : 리스크 식별 및 리스크 평가에 대한 전반적인 프로세스.

리스크 평가 : 식별된 리스크를 조사해서 리스크 수준을 결정하는 과정.

리스크 식별 : 리스크를 식별, 인식, 설명하는 프로세스.

리스크 수준 : 영향 및 가능석에 의해 정의된 리스크의 질적, 양적 측정치.

리스크 관리 : 리스크를 처리하는 프로세스.

리스크 기반 테스팅 : 연관된 리스크 유형과 리스크 수준을 기반으로 테스트 활동 및 리소스의 이용, 관리, 선택, 우선순위 등을 다루는 테스팅.

테스트 접근법 : 특정 프로젝트에 대한 테스트 전략을 구현한 것.

테스트 완료 보고서 : 종료 기준 대비 해당 테스트 항목의 평가를 제공하는 종료 마일스톤 때 생성되는 테스트 보고서 유형.

테스트 제어 : 테스트 프로젝트가 계획을 벗어났을 때 예정대로 진행되도록 시정 조치를 개발하고 적용하는 활동.

테스트 모니터링 : 테스트 활동의 상태를 확인하고 계획 또는 예상과의 차이를 식별하고 이해관계자에게 상태를 보고하는 활동. 

테스트 계획서 : 테스팅 활동 조정에 사용되며, 달성할 테스트 목표와 그것을 달성하기 위한 방법과 일정을 설명하는 문서.

테스트 계획 : 테스트 계획서의 수립 또는 수정 활동.

테스트 완료 보고서 : 종료 기준 대비 해당 테스트 항목의 평가를 제공하는 종료 마일스톤 때 생성되는 테스트 보고서 유형.

테스트 피라미드 : 레벨별 테스트 양의 관계를 나타내는 시각적 모델로, 테스트 양은 상단보다 하단에 더 많이 분표 돼 있음.

애자일 테스팅 사분면 : 4분면으로 구성된 테스트 유형/ 레벨 분류 모델로, 테스트 목표의 두 가지 차원(팀 지원 대 제품 비평, 기술 대면 대 비즈니스 대면) 

형상 관리 : 형상 항목의 기능적/ 물리적 특성을 식별/ 문서화하고, 해당 특성을 제어하며, 변경 처리 및 구현 상황을 기록/ 보고하고, 명시된 요구사항을 준수하는지 검증하기 위해 기술적, 행적적 지시와 감독을 적용하는 원칙.

 

 

728x90
반응형
들어가기 전 알아둬야 할 4.4 용어 설명, 4.5 용어 설명
: 이해에 중점. 부족하면 용어설명 글 참고.
체크리스트 기반 리뷰 : 질문 목록이나 확인해야 하는 특성을 기반으로 수행하는 리뷰 기법.
체크리스트 기반 테스팅 : 경험, 점검, 기억에 의한 목록 또는 제품 검증 기준 맟 규칙을 상위 수준으로 나열한 목록을 숙련된 테스터가 사용하는 경험 기반 테스트 기법.

사용자 스토리 : 일상 또는 비즈니스 언어로 사용자가 필요로 하는 기능, 그것의 이유, 비기능 조건, 인구 조건 등을 포착하는 한 문장으로 구성된 사용자 또는 비즈니스 요구사항.

인수 조건 : 사용자, 고객, 기타 권한을 지닌 사람이 제품을 인수하기 위해 컴포넌트나 시스템이 만족시켜야 하는 기준.
시나리오 기반 리뷰 : 특정 시나리오를 처리할 수 있는 능력을 판단하기 위해 작업 산출물을 평가하는 리뷰 기법.
인수 테스트 주도 개발 : 팀과 고객이 고객 고유의 도메인 언어를 사용하여 컴포넌트 또는 시스템을 테스트하기 위한 베이시스를 형성하는 고객 요구사항을 이해하는 개발에 대한 협업적 접근 방식.

 

4.4 경험 기반 테스트 기법 
: 널리 사용하는 경험 기반 테스트 기법 3가지
  • 오류 추정
  • 탐색적 테스팅
  • 체크리스트 기반 테스팅
4.4.1 오류 추정
< 오류 추정 >
: 테스터의 지식을 기본으로 오류, 결함, 발생을 예측하는 데 사용하는 기법.

>> 테스터의 지식
- 애플리케이션의 과거 동작.
- 개발자가 범하기 쉬운 오류 유형과 이런 오류로 인해 발생하는 결함 유형.
- 다른 유사 애플리케이션에서 발생한 장애 유형.

일반적으로 오류, 결함, 장애는 입력, 출력, 논리, 계산, 인터페이스, 데이터와 관련이 있을 수 있다.

결함 공격 - 오류 추정을 구현하는 체계적인 접근법.
: 테스터가 발생 가능한 오류, 결함, 장애 목록을 만들거나 획득해서 오류와 관련된 결함을 식별 및 노출하거나, 장애를 유발하는 테스트를 설계하도록 한다.
ex. 목록 : 올바른 입력 허용 X, 잘못된 입력 허용 O. 출력형식 올바르지 않음. / 테스터가 이 목록으로 테스팅하는 경우 결함 공격 테스트 기법 사용.

 

4.4.2 탐색적 테스팅
: 테스터가 가지고 있는 경험, 지식, 그리고 호기심, 창의성들이 높으면 테스팅이 효과적!
< 탐색적 테스팅 >
- 테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 하게 된다.
- 테스트 대상에 대해 더 배우고, 집중하고 있는 테스트는 더 깊이 탐색하고, 테스트되지 않은 영역에 대한 테스트를 만들기 위해 사용.
- 테스트를 체계적으로 수행하기 위해 세션 기반 테스팅을 사용하기도 함.

▶ 탐색적 테스팅은
- 명세가 부족하거나 부적합할 경우, 테스트에 시간적 압박이 심할 때 유용!
- 다른 공식 테스트 기법을 보완하기에도 유용!
- 테스터가 풍부한 경험과 도메인 지식을 가지고 있고 높은 수준의 분석 기술, 호기심, 창의성 등 필요 기술을 갖춘 경우 더욱 효과적일 수 있다.

 

4.4.3 체크리스트 기반 테스팅
: 자동화 항목은 포함하면 x
< 체크리스트 기반 테스팅 >
- 테스터는 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행한다.
- 자동으로 점검할 수 있는 항목, 시작/ 종료 조건으로 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안된다.
- 체크리스트 항목을 질문 형식으로 표현하는 경우가 많음. 각 항목은 개별적이면서 직접적으로 확인할 수 있어야 한다. 이런 항목은 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션일 수 있다.
- 시간이 지남에 따라 개발자가 같은 오류를 범하지 않게 됨으로 일부 체크리스트 항목은 점차 효과가 떨어질 수 있음. 결함 분석을 기반으로 정기적으로 업데이트 해야 함!!
- 구체적인 테스트 케이스가 없는 경우에 체크리스트 기반 테스팅은 일관성을 제공할 수 있다.
- 체크리스트가 상위 수준으로 작성된 경우 실제 테스트는 조금씩 달라질 수 있으며, 결국 커버리지는 높아지지만 재현 가능성은 떨어질 수 있다.

 

4.5 협업 기반 테스트 접근법
: 협업과 커뮤니케이션을 통한 결함 예방에 초점.

4.5.1 협업 기반 사용자 스토리 작성
  • 사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타낸다.
사용자 스토리의 3가지 중요 요소(== '3C')
카드(Card) 사용자 스토리를 설명하는 매체(ex. 인덱스 카드, 전자 게시판 항목)
대화(Conversation) 소프트웨어 사용 방법에 대한 설명(문서 또는 구두로)
확인(Confirmation) 인수 조건
사용자 스토리의 가장 일반적인 형식:
"[역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기 원한다." 이며 이후 인수 조건이 뒤따르는 형식이다.
  • 협업 기반 사용자 스토리 작성은 브레인스토밍, 마인드 매핑과 같은 기법을 사용. 협업을 통해 팀원들은 비즈니스, 개발, 테스팅의 세 가지 관점을 고려해 만들어서 전달할 것에 대한 공유된 비전을 얻을 수 있다.
  • 좋은 사용자 스토리는 독립적이고 협상가능하고, 가치 있고, 추정 가능하고, 테스트 가능해야 한다.
4.5.2 인수 조건
사용자 스토리의 인수 조건은 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건.
이런 관점에서 인수 조건을 테스트해야 하는 테스트 컨디션으로 볼 수 있다.

인수 조건은 보통 3C중 대화를 통해 결정된다.
인수 조건은 다음을 위해 사용된다.
1. 사용자 스토리 범위 정의.
2. 이해관계자 간 합의 도출.
3. 긍정과 부정 시나리오 설명.
4. 사용자 스토리 인수 테스팅의 베이시스 제공.
5. 정확한 계획 및 추정.
인수 조건 작성법 두가지
시나리오 기반 행위 주도 개발에서 사용하는 Given/ When/ Then.
규칙 기반 베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑.
- 대부분의 인수조건은 이 두 가지 형식 중 하나로 문서화할 수 있다.

 

4.5.3 인수 테스트 주도 개발(ATTD)
: 테스트 우선 접근법.
테스트 케이스는 사용자 스토리 구현 전에 만들어진다. 고객, 개발자, 테스터 등 서로 다른 관점을 가진 팀원들이 테스트 케이스를 만든다.

첫 번째 단계 : 명세 워크숍으로 팀원들은 여기서 사용자 스토리와 인수조건을 분석하고 토론해서 작성. 이 과정에서 사용자 스토리의 불완전성, 모호성, 결함을 해결하게 된다.
두 번째 단계 : 테스트 케이스를 만드는 것. 이 작업은 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있다. 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어가 어떻게 작동하는지에 대한 예제로 볼 수 있다. 이는 팀이 사용자 스토리를 올바르게 구현하는데 도움을 준다.

일반적으로 첫 번째 테스트 케이스는 예외나 오류 조건 없이 올바른 동작을 확인하고 모든 것이 예상대로 진행될 경우 실행되는 일련의 활동으로 구성된 긍정/유효 테스트 케이스이다.
유효 테스트 케이스를 끝내고 나면 팀은 비유효/부정 테스트를 수행해야 한다.
마지막으로 팀은 비기능 품질 특성도 다뤄야 한다. 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 하며, 일반적으로 테스트 케이스는 필요한 전제 조건, 입력값, 사후 조건을 포함하며 자연어 문장으로 구성한다.
테스트 케이스는 사용자 스토리의 모든 특성을 다뤄야 하며 스토리를 벗어나면 안 된다. 또한 두 개 이상의 테스트 케이스가 사용자 스토리의 같은 특성을 설명해서는 안된다.
테스트 자동화 프레임 워크가 지원하는 형식으로 작성하면 개발자는 사용자 스토리에서 설명하는 기능을 구현할 때 필요한 코드를 작성해 테스트 케이스를 자동화할 수 있다. 그러면 인수 테스트가 실행 가능한 요구사항이 된다.

 

728x90
반응형

+ Recent posts