노년코딩

jira >> 오른쪽 위에 톱니바퀴 ui 클릭 >> 시스템 클릭 >> 프로젝트 역할 클릭 >> 프로젝트 역할 추가에 이름과 설명 써 주고 프로젝트 역할 추가 버튼 클릭하면 역할 추가 완료!

이렇게 추가해 준 역할은 프로젝트 설정에서 사용자를 클릭해 주고 사용자 추가에 사용자와 사용자에 맡는 역할을 선택해 주고 추가해 주면 역할 부여가 된다. 하지만 무료버전에서는 사용자 추가가 안 되는 것 같다. 관리 설정에서 해줘야 한다고 나온다. 이런 거 보면 무료버전에서는 거의 할 수 있는 게 없는 듯..?

Jira의 프로젝트 역할(Role)과 권한(Permission) 구조는 아주 중요한 것 같다.

Jira의 프로젝트 구성원에서 프로젝트에서 필요한 프로젝트 역할을 할당해 주고, 프로젝트 역할을 각 Permission에 할당을 해주고, 프로젝트에 Permission Scheme을 지정해 준다.

Jira의 구조 

Jira 이슈 유형

지라가 2023년에서 2024년으로 넘어오면서 Jira Software가 없어지고 Jira로 통합된 것 같다. 

1. 새로운 프로젝트 만들기를 클릭하고 원하는 프로젝트 템플릿을 클릭한다.

2. 탬플릿 사용하기 버튼 클릭 후 프로젝트 유형을 선택한다.

3. 프로젝트 유형 선택하고 프로젝트 세부사항 추가에 이름을 적으면 키는 알아서 만들어 준다. 직접 써도 상관 X. 프로젝트 만들기 버튼 클릭하면 프로젝트가 생성된다.

게임 QA이나 다른 QA의 채용 모집에서 빈번하게 보이는 Jira.

ISTQB 만큼 자주 보인다. 그래서 나도 한번 공부해 보려 한다.

모르는 상태보다는 어느 정도 알고 있는 상태여야 언제든 써먹을 수 있지 않을까란 생각으로! 

마침 내가 코딩 공부를 하기 위해 자주 이용했던 인프런이라는 사이트에서 내가 언제 구매해 뒀는지도 모를 Jira강의가 있었기 때문에 이걸 통해서 찬찬히 공부를 해볼 예정이다.

오늘도 처음 시작해 보려고 Jira를 깔다가 조직을 두 개를 만들어서 당황했지만 괜찮다. 수많은 프로그램들을 배울 때도 무수히 경험해 본 일이다.(마야, 섭스턴스, 누크, 유니티, 비주얼 스튜디오 등등) 이런 일이 한두 번인가. 

구글 검색으로 해결 방법을 찾아 따라 해 보았는데도 안되길래 시간이 필요한 것 같아 잠시 그대로 두었다. 내일쯤 다시 확인을 해봐야겠다. 

그럼 이제 시작해 보겠다. 

++

첫날부터 문제를 일으켰던 jira 조직제거 이슈

https://community.atlassian.com/t5/Jira-questions/%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%B0%8F-%EC%A1%B0%EC%A7%81-%EC%82%AD%EC%A0%9C-%EB%AC%B8%EC%9D%98/qaq-p/2440491

나중엔 이것도 추억이 되겠지.

8월 29일 오후 7시 30분 ISTQB 시험을 보고 나왔다. 

역시 시험은 봐봐야 안다. 이제 어떻게 공부를 해야 되는지 알 것 같다.

그래서 나 같은 비전공자들을 위한 간단한 후기이자 나의 경험을 일기로 남겨두기 위해 이렇게 글을 써본다.

나는 비전공자로써 QA에 대해 궁금증만 있었지 어떤 역할을 하고 무슨 공부를 해야 하는지 정확하게 알고 있지 않은 상태였다. 그럼에도 느낌 적인 느낌으로 나의 적성에 맞을 것 같다는 단순한 관심이 생겨 시험을 준비하고자 계획을 짜보았다. 그렇기 때문에 처음 ISTQB 실라버스의 4.0을 다운 받아 읽어봤을 때 도무지 이게 무슨 말들인가 라는 생각밖에 들지 않았었다. 그저 "72장의 페이지에는 글들이 쓰여있고, 그건 한글이었다." 정도였달까. 

시기적으로 내가 실라버스를 알게 된 날은 버전 4.0이 이미 나온 시점이었다. 6월의 시험을 마지막으로 이후 시험부터는 선택의 여지가 없이 무조건 4.0으로 공부를 해야 된다는 부분은 어떤 버전의 실라버스 공부를 선택해야 하는지 시작부터 고민이 되었었다. 두 가지 버전을 다 다운을 받고 읽어봤더니 다시 한번 깨달았다. 이건 버전의 문제보단 역시나 뭐라는지 전혀 모르겠다는 것을. 그냥 읽어서 공부하기에는 이해도 전혀 되지 않았던 상황이기에 유튜브 김기태 님의 강의였던 sw테스팅 강의를 전부 들어봤다.

1.

시험 보기까지 어느 정도 시간이 여유 있다면 나는 이 강의들을 들어보는 것을 추천한다. 나의 경우는 강의 속도가 좀 느리게 느껴져서 재생 속도를 올려 들어봤더니 훨씬 집중력이 올라갔었다. 재생 속도를 1.25나 1.5 정도로 듣는 것을 추천한다.

하지만 시간이 촉박할 때는 강의를 들을 때가 아니다. 무조건 실라버스를 우선적으로 외워라. 물론 실라버스를 외운다 해도 문제를 다 풀지는 못한다. 당장 샘플 문제만 풀어봐도 내가 무슨 말을 했는지 알 수 있을 것이다. 실라버스에 쓰여있는 내용만 문제로 나오지 않는다. 샘플 문제의 문제들과 해설을 같이 읽으며 공부해야 한다. 해설에는 문제마다 어디 부분에서 문제가 도출되었는지 알려주는 학습 목표가 기재되어 있다. 이걸 같이 보면서 공부를 해야 된다. 샘플 문제는 A, B, C, D 문제들로 구성되어 있으며 A가 가장 쉬운 난이도이고, 순차적으로 어려워져 D 샘플 문제가 제일 어렵게 느껴졌다.

처음에는 A 샘플 문제를 풀어보면서 내가 이해한 게 맞는지를 확인해 보고 B, C, D 샘플 문제로 가서 더 외워야 될 암기 내용들을 정리를 하면서 공부를 하면 될 것 같다. 문제를 풀고 오답풀이를 한 다음 실라버스 이론을 다시 공부하고 다시 풀어보는 방식으로 공부를 해보니까 나중엔 머릿속에 답이 외워져서 의미가 없어지더라. 그래서 추천하는 방법은 A 문제 풀고 오답풀이 후, B 문제 풀고 오답 풀이한 다음 실라버스 이론 공부하고 C 문제 풀고 오답풀이 하고 A문제로 돌아가서 다시 풀어보는 형식으로 세 개 정도의 샘플문제를 풀고 처음으로 돌아와서 다시 풀어보는 방법을 추천한다.

2.

그리고 계산 문제! 4단원에서 나오는 계산 문제는 답이 명확하기에 다 맞는 게 가장 중요하다고 어느 블로그를 통해 알게 되었다. 실제로 샘플 문제를 풀어봤을 때도 두 가지가 답이 되는 문항에서도 더 답과 가까운 답을 선택해야 되는 문제들이 있다. 그런 걸 생각해 보면 계산 문제는 정말 다 맞는 게 자격증을 딸 수 있는 확률을 높이는 지름길이다. 

하지만 비전공자들에겐 계산 문제가 쉬울 리 없다. 실라버스에서만 설명하는 내용으로는 어떻게 풀어야 하는 건지 이해도 안 될 수 있다. 나의 경우는 우선 김기태 님 유튜브에서 문제 푸는 설명을 해둔 강의들을 보면서(ex> 결정 테이블 테스팅 영상) 이해를 하고 네이버 카페 "SW TestER들의 모임. 소프트웨어 테스트/팅 QA,ISTQB,CSTS,검증"에서 찾아서 문제를 풀어봤다. 그 외에는 네이버나 티스토리나 구글에서 문제들을 찾아서 발품 팔듯 문제를 찾아 헤맸다. 이렇게 찾아서 풀 때도 약간 이해 안 가는 문제들이 생겨서 막막했었는데 시험 보러 가서는 문제들이 더 어렵게 나오기 때문에 계산 문제들은 많이 풀어보는 게 맞는 것 같다. 샘플 문제에서는 어딘가 눈치껏 풀면 정답을 찾을 수 있다 하면 자격증 시험 문제에서는 정확하게 모르면 시간만 엄청 잡아먹고 결국은 찍어야 되는 상황이 온다.

3.

40문제를 60분 안에 풀어야 하기 때문에 시간을 잘 분배해야 된다. 나의 경우에는, 샘플문제들을 40분 정도에 다 풀고 20분 정도가 남았던 반면에 시험장에서는 오히려 20분 정도가 모자랐다. 헷갈리는 문제가 있다면 아닌 답은 확실하게 그어 문제에 체크를 해두고 바로 넘어가는 방법을 추천한다. 아닌 답들은 이후에 다시 찾아오면 까먹기 때문에 찍으려고 해도 확실히 제거된 답들은 아웃시키고 남은 답들 중 선택하는 편이 오답률을 줄일 수 있다. 아 그리고 오히려 뒤에 남은 문제가 더 쉬울 수 있다. 시험시간이 촉박해져서 더 쉬운 문제를 놓치게 된다면 집 가는 길에 눈에서 뭔가 흐를지도 모른다.

그리고 답안지에는 이름, 영문 이름, 또 이것저것을 써야 하기 때문에 답안지 교체를 웬만하면 안 하는 것이 낫다. 시험지에 답을 체크를 해두고 한 번에 옮겨 적는 게 제일 시간 절약하는 방법이다.

4.

내가 선택한 7시 반 타임의 시험장은 대화빌딩 지하 1층이었다. 가는 길에는 스타벅스도 있고 파스쿠찌도 있다. 미리 와서 공부를 할 경우 저 두 개의 카페를 선택하는 것도 방법이긴 하지만 대화빌딩 지하 1층에도 카페가 하나 있다. 샐러드를 중심으로 판매하는 카페로 자릿수가 많지는 않다. 그래도 그곳에 있는 거의 모두가 시험을 준비하고 있어서 자리만 잡으면 아주 조용하게 공부할 수 있다. 그리고 5시 전에 가면 창문을 통해 5시 시험자들의 모습도 볼 수 있다. 만약 집중이 안 되는 상태라면 차라리 이 모습을 보고 빠르게 떨리는 마음을 장착하고 더 집중하는 게 나을지도 모른다.

5.

경기도에 산다면 istqb 말고 kstqb를 준비를 해보는 것도 나쁘지 않다. 왜냐면 경기도 잡아봐 홈페이지에서 국가 자격증, 민간 자격증, 어학 자격증을 딸 때 응시료를 지원해 주기 때문이다. istqb는 국제 자격증이라 지원을 안 해주지만 kstqb는 민간 자격증이라 지원을 해주는 것 같았다. 최대 30만 원까지 응시료를 지원해 주기 때문에 이 돈으로 여유롭게 여러 번 봐봐도 될 것 같은 느낌이 들었다. 물론 한 번에 합격하는 것이 제일 좋겠지만 뭐가 돼었든 알아두면 손해 볼 정보는 아니지 않은가.

6.

시험 공부기간은 적어도 한 달 정도의 기준으로 잡는 게 심적으로 편하다. 나의 경우는 시험 보기 아주 예전에 유튜브 강의를 다 들어두고 본격적으로 시험 준비를 한 게 2주 전부터였는데, 사실 2주 중 1주일은 코로나에 걸려있어서 제대로 공부한 시간은 일주일이었다. 일주일 동안 준비를 하는 건 비전공자는 절대 불가능하다는 것을 알았다. "그냥 다 외우면 되지 뭐."라고 생각했던 마음은 진짜 샘플문제 풀어보면 산산조각 난다. 응용도 응용이지만 실라버스에 나와있지 않는 내용에 대해 문제로 만들어져 있다. 아니면 그냥 블라 블라 어쩌고 저쩌고 하는 곳에 적혀있던 사이에 껴있는 단어 한 개를 두고 예시를 주고 이 단어가 그거라는 것을 알아야 된다. 솔직히 이건 쫌...? 그렇기에 일주일 정도로 공부해서 시험 보겠다는 생각을 하는 사람이 있다면 QA가 직업인 사람, 전공자, 원래 이쪽 분야에 관심과 지식이 있었다 하는 사람들만 가능하다. 적어도 2주, 3주는 있어야 심적으로 편하다.  

시험장에는 7시부터 들어갈 수 있었다. 들어가기 전에 컴퓨터용 사인펜이나 유성 볼펜을 제대로 챙겨갔는지 확인을 하고 시험장 문 앞에 가면 안내해 주시는 분이 이름을 확인하고 자리를 안내를 해주신다. ISTQB 답게 자리가 a, b, c, d, e, f, g 열로 되어 있는데 "a열의 끝에서 몇 번째, 앞에서 몇 번째 자리로 가세요." 해주시면 그대로 가서 앉으면 된다. 만약 잘 모르겠다면 다시 한번 물어보면 되는데 그럴 때는 자리로 직접 데려다주시는 것 같다. 문제지를 다 나눠 주고 이름을 쓰고 다 준비가 되면 "시작하겠습니다." 하면서 그때부터 1시간의 타이머가 화면에 뜬다. 중간중간 답안지가 문제가 있을 때는 손을 들어 변경하면 되고 문제를 다 풀었다면 손들어서 시험지와 답안지를 제출하고 일어나서 나가면 된다. 이건 시험 시간이 꽤 남았을 때만 가능하고 시험 시간이 10분 전일 때는 앉아서 끝날 때까지 기다려야 한다. 시간에 쫓겼던 나는 당연히 1, 2분 정도를 남겨둘 때까지 시간을 사용했고 내가 끝나는 것을 보자마자 옆에 지나가시던 감독관님께서 시험지와 답안지를 가져가셨다. 실제로 중간에 가시는 분들이 계셨는데 잠깐이었지만 대단해 보였었다. 다 끝나면 감독관님들이 한 명 한 명 자리로 가서 시험지와 답안지를 가져가신다. 전부 수거가 되어도 바로 나갈 수 없다. 무언가의 규칙이 있는 것 같았는데 각 줄마다 앞에서 허락을 해주셔야 나갈 수 있다. 시험지와 답안지를 다 가져갔을 때가 그 타이밍 아닌 것은 내 눈으로 확인했다. 마치 학교나 교회 수련회에서 그룹마다 밥 먹으러 가는 걸 허락 맡는 것처럼 기다렸다 나오면 모든 게 다 끝난다.

시험 끝나고 나오니까 8시 50분쯤 되었었는데 밤 공기가 좋았다. 청담역까지 걸어가면서 빌딩들을 많이 봤다.

"저 어딘가 내가 일할 곳이 한 군데는 있겠지."라는 생각으로 걸음을 옮겼다.

19만 8000원이 큰돈으로 느껴지는 지금 나에게 응시료는 무거웠지만 그래도 도전해보길 잘 했다는 생각이였다. 시작해보지 않았을 때는 "내가 과연 저걸 해볼수 있을 까." 싶지만 막상 발로 밟아보니 "나 충분히 할 수 있겠구나." 생각할 수 있었다. 다음엔 더 잘 해보자 내 자신아.

테스팅의 독립성 4가지

>> 문제로 나오면 나열하는 문제로 나올 텐데 "독립성이 높은 것부터 나열하세요"라 하면 4,3,2,1 반대로면 1,2,3,4 생각하면 돼. 

테스트의 제약

▶ 관리자나 테스터가 테스팅에 대하여 단편적인 지식만 가지고 있음. 
▶ 부족한 인력과 자원으로 인해 테스팅에 대한 투자여력이 없음.
▶ 테스팅을 투자가 아닌 불필요한 비용으로 간주함.
▶ 의사결정권자나 프로젝트 관리자가 테스팅에 대한 인식이 부족함.

>> 전부 이러면 안 돼.

소프트웨어 테스팅에 대한 오해 >> 틀린 답으로 정확하게 파악하고 있어야 돼.

▶ 시간, 인력이 부족해서 테스팅을 제대로 못한다.
▶ 테스트는 완벽하게 수행될 수 있다.
▶ 테스트는 그리 어려운 작업이 아니다.
▶ 아무나 테스트를 수행할 수 있다.
▶ 프로그램이나 시스템이 잘 수행될 수 있음을 보여주는 것이다. >> 이건 개발자가 하는 거!!
▶ 테스트는 개발 이후의 작업이다. >> 초기 or 동시!!!
▶ 개발 일정에 따라 테스트는 생략될 수 있다. >> 생략 절대 ㄴㄴ

>> 계속 얘기하지만 여기도 전부 이러면 안 돼.

* 알기 쉬운 소프트웨어 공학 배우 유튜브 찾아서 한번 봐봐.

테스트의 심리학 (>> 도덕적 태도에 대해 말하고 있는 거야. 문제에서 긍정적인 게 답이겠지.)

▶ 개발자와 테스팅 엔지니어 분리 >> 각자의 활동에 집중.

▶ 테스팅 독립성(-> 단계가 오를 수록 독립성이 높아짐)

 1. 테스트 대상 소프트웨어의 개발자가 설계한 테스트(독립성 정말 떨어짐)

 2. 개발팀 내의 다른 인원이 설계한 테스트

 3. 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용성 또는 성능 테스트 전문가 등)가 설계한 테스트

 4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적 조직에 의한 인증, 아웃소싱)

- 명확한 테스팅의 목표 설정은 테스팅을 성공적으로 수행하는데 있어 중요

▶ 테스팅 진행하는 동안 결함을 식별하는 과정

- 작성자에 대한 비판으로 오해될 소지 존재 (야 너 뭐 이따위로 테스트했어! >> 이러면 안 돼)

 >> 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험 필요.

- 오류나 결함, 장애가 긍정적인 방법으로 의사소통 된다면, 테스트와 개발자 간에 발생할 수 있는 감정 악화를 피할 수 있다. (명세화시킨 문서로 이야기하고, 전문적 비판을 하면 만족도 높아지겠지.)

- 테스터, 테스트 리더 사이 >> 좋은 대인관계 필요..

- 결함 정보

 >> 결함 발견 -> 시간과 비용 절감 및 리스크 요소 줄임

▶ 테스터의 역할

- 다툼보다는 협력으로 시작 -> 공통적인 목표를 모든 사람에게 전달

- 소프트웨어를 개발한 사람에게 비평을 배제하고 중립적이고 사실에 근거한 제품의 결함만 전달하려고 노력한다.

- 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다.

- 상호 간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다.

▶ 최근 소프트웨어는!

- 전통적인 컴퓨팅 영역 탈피 >> 가전, 무선단말기, 산업기기, 휴대폰, 자동차(ESU) 분야, AI분야

- SW개발 프로세스 품질의 중요성과 함께 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 테스팅의 중요성 부각

 >> 전체 개발비의 40~60% 이상의 테스팅 비용(개발 < 테스팅 비용)(유지보수비용이 많이 든다.)

 >> 하지만 기존 개발자들은 테스팅에 소극적 -> 하위레벨 테스트 부족. (컴포넌트, 통합테스트)

- 품질에 대한 인식 높아져 기대 수준 높아짐 -> 리스크 관리 필요.

 >> 체계적인 테스팅을 위해서는 테스트의 우선순위 중요.

소프트웨어 테스팅을 제약하는 요소

▶ 테스트에 대한 문제점

- 테스터가 테스팅에 대해 너무 단편적으로 알고 있는 것은 체계적인 테스팅을 제약하는 요인.

 >> 개념과 연관성 이해

 >> 리스크 기반 테스팅 접근법, 테스트 기법, 테스트 커버리지

 >> 이론을 실무에 적용하는 노력 필요 (이론과 실무를 골고루 알고 있어야 된다!)

- 의사결정권자와 매니저의 테스팅에 대한 인식 부족 (테스팅은 언제나 해야 돼!)

 >> 임시방편

 >> 테스트 자동화 도구의 중장기적 계획 or 테스트 프로세스 정립 필요

- 테스팅을 투자가 아닌 불 필요한 비용으로 인식

 >> 테스팅은 개발보다 더 확실한 ROI(Return On Investment - 투자자본수익률) 활동

(얼마나 효율적으로 투자가 이루어진 건지??)

테스팅 분야의 매력

▶ 테스팅 분야의 전문가

- 체계적인 지식 체계를 갖는 전문 분야

 >> 기존적인 컨셉과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함관리, 지원도구, 정적 테스트 기법, 비기능성 테스팅 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등의 분야 포함.

- 테스팅 분야는 넓고 다양함.

 >> 자동화 도구에 대한 전문적 기술

 >> 보안성 테스트, 신뢰성 테스팅 분야 전문가

 >> 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별 최적화하여 적용

- 테스팅 필요성 급증

- 테스팅 분야에서 연령 제한(X), 경험 중시

오늘 저녁은 냉면이다. 나는 얼음 팩을 끌어 안고 있다. 덥다. 이토록 더울 수 있다는 게 그저 신기할 따름의 체감 온도 33도이다. 집에는 에어컨이 설치되어 있지만 우리집은 에어컨을 그렇게 좋아하지 않는다. 나이가 들면서 달라진 점이 있다면 더위를 잘 느끼고, 땀이 잘 난다는 것. 물론 다른 사람들 기준이 아닌 지극히 나의 기준에서 그렇다. 어렸을 때는 이렇게까지 더위를 느끼지 않았던 것 같은데, 이렇게 까지 땀도 나지 않았던 것 같은데 무엇이 문제가 되었으면 지금의 상황이 되었을까 고민을 해본다. 나는 추위를 잘탄다. 추위를 잘 타면 더위는 넘어가야 이상적인게 아닌가 싶다가도 무엇이 그 기준을 정하느냐를 생각해봤을 때에 그렇게 집착할 것이 아닐 것 같다는 생각을 하게 된다. 어렸을 때는 더위를 잘 느끼지 못했다. 그때는 더위와 추위가 공평했다. 한쪽이 강하면 한쪽은 작아졌으니까. 그런데 지금은 왜 두가지의 느낌을 어느 하나 부족하지 않게 공평하게 대하고 있는 걸까. 그렇게 공평하고 싶다면 차라리 둘다 느끼지 못하는 쪽은 택할 수 없었던 것일까 한탄을 하게 된다. 

테스팅에 대해 알아보자.

1. 결함 발견과 격리(때로는 예방까지)
2. 결함 발견 메커니즘을 가지고 있다.
3. 제품의 자신감 제공
4. 결함 예방과 조화를 이루어야 함
5. 품질과 리스크에 대한 통찰 제공(결함을 많이 잡으면 리스크 낮아짐)
6. 테스팅은 수명주기와 프로세스를 갖는 프로젝트
7. "테스트"는 실제 수행하는 하나하나의 실체이다.

▶ 테스트를 하는 목적
프로그램의 동작(기능)과 성능, 안정성이 사용자의 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 방법.

테스팅의 목적

▶ 주요 이유
- 잔존 결함 발견
>> 잔존 결함이 있는 채로 출시했다가 후에 발견하면 유지보수 비용이 많이 들어! 그전에 찾아내야 됨.
- 개발 시스템 / sw자신감 부여 >> 품질 수준에 대한 자신감 획득과 정보 제공
- 결함을 미연에 방지
- 명세를 충족 확인
>> 소비자의 요구사항에 만족하는지를 확인한다!
- 사용자 및 비즈니스의 요구 충족 확인
- 비즈니스 리스크를 감소시키는 정보 제공(발견된 결함 기반의 수치 데이터 제공)
>> 리스크는 큰 것부터(시간이 많지 않아. 출시시키고 나중에 잡을 수 있는 작은 것들보단 큰 것부터!)

▶ 기타 이유
- 개발 프로세스 점검, 이슈 제거 
- 논리적 설계의 구현 검증
- 시스템 / sw가 적절히 동작함을 확인

▶ 테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질 수 있다.

무슨 말인가 하면, 
개발과정 : 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시킴. >> 많은 결함을 발견하기 위해!
인수과정 : 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정. >> 말 그대로 사야 되니까 제대로 동작하는지 확인을 해야지!
품질 평가 : 특정시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달. >> 개발 시간은 항상 정해져 있으니까. 
유지 보수 : 변경사항을 추가적으로 개발하는 중에 새로운 결함이 유입되었는지 확인하는 테스팅 과정 포함.
운영 : 신뢰성 또는 가용성과 같은 시스템의 특성을 평가.

1.1.1 SW 시스템 관점에서 테스팅의 필요성

▶ SW 관점에서 테스팅(SW테스팅이 왜 필요할까?)

- 비즈니스 애플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분 사용 >> 비중은 계속 증가.

- 금전적인 손실, 시간낭비, 비즈니스의 이미지 손상(== 제품 잘못됐다고 하면 사용자는 그 제품을 더 이상 쓰지 않음), 그리고 부상이나 사망에 이르기까지 다양한 심각성

- 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요.

▶ 소프트웨어 결함 - 세 가지 구분해야 돼! 오류, 결함, 장애!

- 오류(error) : 인간의 행위, 실수 (== 사람이 실수하는 것)

>> 코드 작성, 소프트웨어나 시스템 또는 문서 작성 시 결함을 만드는 오류.

- 결함(defect) - 요구된 기능의 부정확한 처리를 말하며 이것으로 인해 고장 또는 장애를 발생시키는 원인이 됨(장애가 발생할 수 있는 원인)

>> 시간적인 압박, 복잡한 코드, 기반환경의 복잡성, 기술이나 시스템의 변경, 수많은 시스템 상호 간의 연동.

>> 결함은 장애의 원인(환경, 기술이나 시스템의 변경, 요구된 기능의 부정확한 처리)

>> But, 모든 결함이 장애를 발생시키는 것은 아니다.★★

- 장애(failure) : 코드에 존재하는 결함의 실행 또는 환경적 조건에 의해 부정확하게 처리되는 것을 의미함.

>> 결함 + 환경적인(방사, 전자기장, 물리적 오염 등) 조건.

소프트웨어의 결함을 발생시키는 2가지 원인

1. 인간의 소스코드 실수 - 인간의 실수 또는 시스템 코드에 결함을 야기시켰을 때.
2. 주변환경에 의한 결함 - 전자파, 자석, 공해, 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어 영향을 주 오류 

소프트웨어 결함의 원인 문제가 나오면 대부분 결함이 정답이래!! 기억하고 가래!!

1.1.2 테스팅이란 무엇인가??

▶ 테스팅

- 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는 지 확인하기 위해 결함을 발견하는 메커니즘

 >> 정상 동작 여부 확인.

 >> 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인. == 벨리데이션

 >> 개발 프로젝트의 리스크 정보를 정량적 수치로 의사결정권자에게 전달.

- 초기 개발 산출물 -> 리뷰.(초기엔 코드가 없어서 리뷰를 해. 리뷰는 정적분석이라고도 하는데 코드없이 테스팅하는것을 말함. / 동적 분석이라는 것도 있는데 얜 코드를 실질적으로 돌려보는걸 말해) 

- 테스트 케이스 작성 과정(결함 예방 활동)

- 다양한 테스팅 활동. (단통시인)

1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할

▶ 테스팅

- 개발 초기의 요구사항 분석 단계부터 리뷰와 정적분석을 통해 정적으로 시작

>> 각각의 개발 단계에 대응하는 테스트 레벨별(단위, 통합, 시스템, 인수) 테스팅

- 컴포넌트, 통합 테스팅은 개발 조직 중심으로 수행

- 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직 중심

- 테스트 레벨에 따른 테스트

>> 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화하는 게 목적.

- 유지보수 활동으로 변경 및 단종되거나 환경이 변경

>> 변경된 환경에 대해 운영 테스팅(리그레이션 테스팅)

>> 변경으로 인한 결함과 장애를 예방

- 계약상 요구조건 및 산업에 특화된 표준 만족

1.1.4 테스팅과 품질

▶ 품질 특성 및 향상

- ISO /IEC 9126 소프트웨어 제품 품질

>> 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 높아야 돼!!

(외울 때! 기사신효이성 - 기사가 신효를 지키려고 이성을 붙잡는다. )

- 품질 향상 

>> 테스팅 결함을 찾아내고, 발견된 결함을 수정한다.

- 품질 보증

>> 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보

>> 발견되니 결함의 근본 원인 이해를 통해 프로세스 개선

>> 결함의 재발 방지

- 개발 표준이나 교육 훈련 그리고 결함 분석

1.1.5 테스팅, 얼마나 해야 충분한가?

▶ 적절한 테스팅 정도

- 리스크 수준을 고려

- 프로젝트 제약 사항

>> 기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간, 비용

- 테스팅은 테스트된 sw나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해 관계자들이 릴리즈 결정을 내릴 수 있도록 충분한 정보를 제공

- 적절한 릴리즈를 결정해야 한다.(다른 회사보다 먼저 출시해야 하며 안전한지 정보를 제공할 수 있을 만큼 테스팅이 진행되어야 한다.)

커버리지

1. 커버리지를 높이면 결함이 줄어들어 품질이 높아짐.
2. 리스크를 반영해 커버리지를 높이면 테스트의 완성도가 높아짐.
3. 커버리지는 어떤 커버리지인지 명시해 주지 않으면 의미가 없음.
4. 테스트 케이스의 수를 늘린다고 커버리지가 높을 수 있는 것은 아님!!!! ★