노년코딩

테스팅의 독립성 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), 경험 중시

테스팅에 대해 알아보자.

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. 테스트 케이스의 수를 늘린다고 커버리지가 높을 수 있는 것은 아님!!!! ★

테스트 프로세스에서 3~4 문제 나온데. 중요, 중요!!

아주 중요한 파트!!

테스트 프로세스

* 테스트 모니터링과 제어 : 관리자 역할(감시자 역할)로 계획, 분석, 설계, 구현, 실행, 완료단계까지 다 들어가. 

* 테스트 스위트 / Test Suite : 테스트 케이스들을 하나로 묶은 것. 테스트 스크립트 세트.

* 테스트 하네스 / Test Harness : 자동화된 테스트 지원 도구, 다양한 환경에서 프로그램 단위를 작동시키고 그 작동과 출력을 모니터하기 위해 사용되는 소프트웨어와 테스트 데이터의 집합. >> 테스트하기 위한 환경이라 알아두면 돼.

*** 테스트 모니터링과 제어는 테스트 분석, 테스트 설계, 테스트 구현, 테스트 실행 까지 테스트 모니터링과 제어는 계속 되어야 해!!! 한 단계에서 필요한게 아니야. 테스트 계획단계에서 테스트 모니터링과 제어가 시작하는거 X.

테스트 프로세스의 기초 (빨간 글씨들은 다 외운다 생각해야돼!!)

▶ 테스트 프로세스

 - 테스팅 관련 활동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성요소를 엮어 주는 역할.

 >> 테스트 베이시스 : 계획단계 부터 필요. 설계시 반드시 요구 -> 문서화를 해야 한다.

 >> 테스트 조직 : 계획단계 부터 필요, 실행 단계에서 다수 인력 필요

 >> 테스트 전략

 >> 테스트 기법 : 분석 및 설계 단계에서 필요.

 >> 테스트 대상 : SW는 가장 이른 시기 준비, 늦어도 실행 단계에서는 필수.

 >> 테스트 기반 설비 및 환경 : 실행 단계 전에 구축.

- 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크) 제공.

테스트 계획과 제어(통제)

▶ 테스트 제어
- 계획 대비 실제 진행 상황을 비교하는 지속적인 활동
- 계획과의 차이 확인 >> 지속적인 모니터링
- 제어 작업
 >> 테스트 결과에 대한 측정과 분석
 >> 테스트 진척 사항, 완료조건의 모니터링과 문서화
 >> 테스트 계획과의 차이 교정
 >> 테스팅의 진행과 변경에 대한 의사 결정 활동
 >> 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영

▶ 테스트 계획과 제어
- 주요 활동
 >> 테스트 목적/ 목표 및 대상 연구
 >> 테스트 전략 개발
 >> 테스트 완료 조건의 결정(80~90%)
 >> 테스트를 추정
 >> 테스트 조직 구성
 >> 테스트 계획 활동
 >> 테스트 관리 및 제어
 >> 리포팅 

테스트 프로세스

▶ 1-1. 테스트 계획
- 테스트 계획은 테스팅의 미션과 목표를 정의하고 이를 만족시키기 위한 테스트 활동들을 수립하는 과정.
- 테스트 계획은 모니터링 및 통제 활동의 피드백에 따라 조치를 할 수 있도록 수립되어야 한다.

★ ★ ★ 계획 단계에서 해야하는 일 ★ ★ ★
 >> 1.테스트를 위한 자원 파악(인적 자원, 테스트 환경, PC사양 등).
 >> 2. 테스트 정책 및 테스트 전략 수립.
 >> 3. 테스트 분석 및 설계 업무 일정 관리.
 >> 4. 테스트의 적용, 실행, 평가에 대한 일정 관리.
 >> 5. 완료 조건 결정.

▶ 1-2. 테스트 제어
- 테스트 통제는 실제 진행 상황과 계획을 비교하고 보고 하는 활동.
- 여기에는 프로젝트의 미션과 목표를 위해 조치가 이루어질 수 있음.
- 이를 위해 프로젝트의 진행이 지속적으로 모니터링 되어야 할 것.

★ ★ ★ 제어 단계에서 해야 하는 일 ★ ★ ★
 >> 1. 결과 측정 및 분석.
 >> 2. 모니터링 및 문서화의 진행, 테스트 범위, 종결 기준.
 >> 3. 결과 반영(수정, 변경 등) 활동.
 >> 4. 의사 결정

 - 테스트 계획과 제어 단계는 테스트 분석과 설계, 테스트 구현과 실행, 종료 조건의 평가 레포팅의 모든 단계를 모니터링 해줘야돼. 

▶ 2. 테스트 분석과 설계
- 테스트 계획에서 제시된 목표를 테스트 케이스로 반영.

>> 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동.

★ ★ ★ 분석과 설계 단계에서 해야하는 일 ★ ★ ★
 >> 1. 테스트 베이시스 리뷰(가장 기초 문서, 요구사항 명세서, 설계 계획서, 디자인 등). *테스트 베이시스 : 요구사항 등 테스트 케이스의 토대. 
 >> 2. 테스트 대상 아이템 또는 명세, 구조 분석을 통해 테스트 상황을 식별하고 우선순위 선정.
 >> 3. 테스트 케이스 설계와 우선 순위 선정.
 >> 4. 비공식적인 기법으로 테스트 케이스 추가 도출 및 보완
 >> 5. 테스트 상황과 테스트 케이스에 필요한 테스트 데이터 식별.
 >> 6. 테스트 환경 구축에 대한 디자인과 요구되는 기반 시설 및 도구 식별. (완전한 구축이 아니라 어떠한 환경에서 할지 정하는 것)

▶ 3. 테스트 구현 및 실행  (테스트 프로시저, 테스트 스크립트 키워드 나오면 테스트 구현 및 실행!)
- 효과적/ 효율적 테스트를 위해 테스트 케이스를 조합하고, 테스트 프로시저(==모듈시스템이 있으면 정하는 순서)/ 테스트 스크립트를 작성.(자동화)

- 테스트 환경이 구축되어 있어야 한다.(환경 완성돼있어야 됨.)

★ ★ ★ 구현 및 실행 단계에서 해야하는 일 ★ ★ ★
 >> 1. 테스트 데이터 생성.
 >> 2. 효과적인 테스트를 위해 테스트 프로시저 생성.
 >> 3. *테스트 하네스 준비.
 >> 4. 테스트 환경이 제대로 설정되었는지 확인.
 >> 5. 계획된 절차에 따라 테스트 케이스를 직접 또는 툴을 사용하여 수행.
 >> 6. 테스트 실행 결과를 기록하고 테스트 수행 대상 및 소프트웨어 버전을 기록.

 >> 7. 예상 결과와 실제결과를 비교.

 >> 8. 불일치하는 결과가 나오는 원인을 기록.

 >> 9. 각각의 불일치에 대한 반복적인 활동.

++ 주요 작업(위의 해야하는 일과 같은데 같이 읽어보고 공부해. 아마 비슷할꺼. 키워드 위주로 봐봐.)

- 테스트 케이스 개발, 구현과 우선 순위 설정

- 자동화 테스트 스크립트 작성

- 테스트 하네스 준비

- 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성

- 테스팅 실행(겨로가 기록 -식별과 버전 관리)

- 기대 결과와 비교 -> 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고 -> 불일치 원인 파악(원인을 파악하는건 테스터가 하는 일, 원인을 찾아서 수정하고 제거하는 건 개발자가 하는 일.)

- 예상과 실제의 불일치로 테스트 케이스 결함, 테스트 정황 결함, 어플리케이션 결함이 있을 수 있다.

- 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복

 >> 수정이 되었는지 테스트 실행 -> 확인 테스팅(Confirmation Testing).

 >> 수정으로 새로운 버그가 발생하지 않았는지 전체를 테스트 실행 -> 회귀 테스팅(Regerssion Testing). 

- 결함의 유형

 >> 기획시 유입된 결함 : 요구사항의 표준 미준수, 테스트 불가능 등.

 >> 설계시 유입된 결함: 설계의 표준 미준수, 테스트 불가능 등.

 >> 코딩 시 유입된 결함: 코드의 표준 미준주 등. 

*테스트 하네스 :

- 테스트 드라이버 + 테스트 스텁.

- 드라이버 : 상향식 테스트, 하위 모듈에서 상위 모듈로의 테스트를 진행

- 스텁 : 하향식 테스트, 상위 모듈에서 하위 모듈로의 테스트를 진행.

▶ 4-1. 완료 조건의 평가와 리포팅
- 테스트 수행 결과를 목적과 비교하여 평가.

★ ★ ★ 완료 조건의 평가와 리포팅 단계에서 해야하는 일 ★ ★ ★
 >> 1. 테스트 계획에 정의된 완료 기준에 따라 테스트 로그 확인. (로그가 나온다? 무조건 완료 조건.)
 >> 2. 추가 테스트가 필요한지에 대한 평가를 하거나 완료 기준을 변경.
 >> 3. 이해 관계자들을 위한 테스트 요약 보고 작성.
 

- 리포팅 내용으로 뭐가 있냐. -> 리포팅에 표현되는 내용.

 >> 발견된 결함과 미해결 결함의 추이 및 우선순위. 

 >> 테스트 진척도. (테스트 어느 정도 진행됐는지.)

 >> 리스크 및 메트릭으로 실증된 조언.

*메트릭 : 메트릭이란 지연, 오류 비율에서 사용자 가입까지 시간에 따른 모든 환경 변화를 추적할 수 있는 숫자 값.

 >> 테스트 환경의 가용성.

 >> 테스트 커버리지, 결함 발견 효과성/ 효율성, 품질 평가 결과, 결함 상태별 결함수.

 >> 소프트웨어 사이즈 대비 결함 수 등.

▶ 4-2.  테스트 마감 조건과 리포팅

- 모든 테스트 활동에서 경험, 테스트 도구, 사실, 통계를 종합하기 위해 데이터를 수집하고 완료.

★ ★ ★ 테스트 마감 조건과 리포팅 단계에서 해야하는 일 ★ ★ ★
 >> 1. 계획된 산출물이 산출되었는지에 대한 확인, 개별 요소에 대한 보고완료, 또는 아직 수행 중인 활동의 변경에 기록에 대한 이슈제기.

 >> 2. 시스템 인수와 관련된 문서 확인.
 >> 3. 유지보수 조직에 테스트 도구 인계.
 >> 4. 사후 관리 및 테스트 성숙도 향상 수준 분석.

++ 

▶ 테스트 마감 활동

- 산출물 확인, 테스트 웨어(산출물) 보관(-> 다음 프로젝트를 위해)

- 테스트 프로세스 평가 심사.

- 주요활동

>> 테스트 결과 마감(예정된 산출물, 인시던트 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)

>> 테스트웨어, 테스트 환경, 테스트 기반 설비를 차후에 사용위해 마감, 보관.

>> 테스트 웨어를 유지보수 조직에 이관

>> 테스트 프로세스 심사 및 개선 사항

>> 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석

효과적 / 효율적의 차이(시험엔 안나와도 알아는 둬볼까.)

효율적이면서 효과적인 그 중간을 찾아야 된다.

테스팅과 디버깅의 차이

테스팅의 특성 ★

▶ 완벽한 테스팅은 불가능하다.
- 한 프로그램 내의 내부 조건이 무수히 많을 수 있다.
- 입력이 가질 수 있는 모든 값의 조합이 무수히 많다.
- 이벤트 발생 순서에 대한 조합도 무수히 많다.
▶ ★ ★ ★ 테스트는 결함이 없음을 보이려는 것이 아니다. ★ ★ ★
- 테스팅은 결함이 존재함을 밝히는 활동.
▶ 본인이 만든 프로그램의 결함을 발견하기는 쉽지 않다,
▶ 현실적인 테스팅의 목적.
- 주어진 리소스(시간, 인력 등)로 리스크가 높은 시스템 부분의 결함을 발견할 확률을 극대화 >> 리스크의 최소화.

테스팅의 일반적 원리 7가지

1. 테스팅은 결함이 존재함을 밝히는 활동이다.
- 잠재적으로는 존재하는 결함 줄임.
>> But, 결함이 없다고는 증명할 수 없다.
2. 완벽한 테스팅은 불가능하다.
- 리스크가 높은 것부터 해결해 나가야 함.(중요도 순서)
>> 한 프로그램 내에 내부 조건이 너무 많음.
>> 입력이 가질 수 있는 모든 값의 조합이 무수히 많다.
>> 이벤트 발생시 발생 순서에 대해 조합도 무수히 많다.
>> 리스크에 따라 테스트 강도 높게 수행 -> 실제 완벽하게 수행하는 것은 불가능하다.
3. 개발 초기에 테스팅 시작한다.
>> 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근.
>> 요구사항 분석서와 설계서 등의 개발 산출물 분석후 테스트 케이스 도출. 
4. 결함은 집중되어 있다. 
- 특정 모듈에 집중되어 있음. (넓게 퍼져있지 않음.) >> 결함이 집중돼있는 곳을 잡아야 돼.
>> 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임.
>>결함의 집중은 운영상의 장애를 초래함. (운영상의 장애 ex : 복잡한 구조의 모듈, 다른 모듈과 다량의 상호작용을 하는 모듈, 개발 난이도가 높거나 최신 기술을 사용한 모듈, 크기가 큰 모듈, 경험이 미흡한 팀에서 개발한 모듈, 새롭게 개발한 모듈)
5. 살충제 패러독스.
- 면역력이 생기는 거 >> 테스트 케이스를 늘 똑같은 걸 사용하면 버그 찾기 쉽지 않음. >> 주기적으로 업데이트된 테스트 케이스 필요.
>> 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함을 찾기 어려워진다.
>> 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선해야 함. 
6. 테스팅은 정황에 의존적이다. >> 테스트는 정황과 도메인(대상 영역)에 따라 다르게 수행되어야 함.(똑같은 테스트 케이스를 쓰는 게 X)
>> 모든 테스트에 적용되어야 하는 것 : 테스트 프로젝트 기획, 표준적인 기법 적용, 독립적인 테스트 환경, 효율적/ 효과적 테스트 팀 조직, 정식 리포팅 등.
7. 오류 - 부재의 궤변.
- 개발된 소프트웨어를 사용자가 원하는 데로 만들지 않으면(요구사항 충족 ㄴㄴ, 요구 수준 만족 ㄴㄴ) 결함을 수정해도 필요(또는 의미)가 없음.

테스팅에 대한 오해

1. 테스트는 완벽하게 수행될 수 있다. >> X
2. 아무나 테스트를 수행할 수 있다. >> X 
3. 테스트는 그리 어려운 작업이 아니다. >> X
4. SW나 시스템이 잘 실행됨을 보여주는 것이다 >> X >> 결함이 있다는 것을 보여주는 것. 결함을 잡고 리스크를 낮춘다!! 실행이 잘되는 걸 보여주는 건 개발자의 역할!
5. 테스트는 개발 이후의 작업이다. >> X 개발 초기의 작업.
6. 개발 일정에 따라 테스트는 생략 될 수 있다. >> X
7. 시간, 인력이 부족해서 테스팅을 제대로 못한다. >> X 말도 안 되는 내용.

테스트 프로세스와 산출물

계획 / 통제(제어) - 조직 구성 테스트 베이시스(기초문서- 엑셀파일) 필요.
▼
분석 및 설계 - 테스트 기법 필요, 테스트 베이시스 필수, 테스트 설비 및 환경 구축.
▼
구현과 실행 - 테스트하는 거.
▼
완료 조건의 평가와 리포팅 - 테스트 커버리지 90퍼센트 했으니까 그만 끝내자. 마감 보고서 쓰기(리포팅).
▼
테스트 마감활동 - 결함 보고서 쓰기.

유튜버 "Ares"의 ISTQB 자격증 강의를 보면서 정리해 둔 내용.

이전에 봤던 유튜버 "김기테의 JAVA를 자바"의 SW 테스팅 강의를 다 듣고 들으니 이해가 쉽게 된다.

혹시나 ISTQB를 준비한다면 이 두 유튜브 강의를 둘다 들어보는 것을 추천함!

하드웨어 : 

- 입력장치, 중앙처리 장치, 기억장치, 출력장치

소프트웨어 :

- 시스템 소프트 웨어 : 컴퓨터를 사용하기 위해 가장 근본 적으로 필요한 소프트웨어 (ex. 윈도우, 리눅스, 맥)

- 응용 소프트 웨어 : 컴퓨터를 사용할 때 편리한 기능을 제공해주는 소프트웨어(ex. exe 파일)

소프트웨어 테스팅의 필요성 - 결함을 발견하는 것.
테스팅의 필요성 - 소프트웨어 시스템의 문제를 최소화하는 것.

테스팅의 정의

- 결함 발견과 격리(때로는 예방까지).

- 결함 발견(Defect Detenction) 메커니즘.

- 결함 예방 조화를 이루어야 함.

- 품질과 리스크에 대한 통찰력을 제공.

- 테스팅은 수명 주기와 프로세스를 갖는 프로젝트

- "테스트"는 실제 수행하는 하나하나의 실체

소프트웨어 테스팅의 정의

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

소프트웨어 테스팅 용어
오류 >> 결함 == 결점 == 버그 == 인시던트 == 이슈 >> 장애 >> 리스크로 이어질 수 있음.

*인시던트 : 테스팅 중 발생하여 조사가 요구되는 모든 이벤트 ( 6 파트에서 나옴 )

오류(에러) : 사람의 실수에 의한 에러, 원인은 사람.
결함 : == 결점(Defect), 버그(bug), 에러에 의해 발생하는 것, 에러가 실제로 코드에 구현(내재화) 된 것.
장애 : 결함을 가진 SW 실행하면 발생(눈에 보이게)하는 것, 눈에 보여지는 것.

★ 모든 결함이 장애로 가지는 않는다. ★ 
결함이 있어도 정상적으로 실행될 수 있다.

소프트웨어 결함의 원인

소프트웨어 결함 :
- 인간의 실수 : 사람의 실수는 소프트웨어 또는 시스템 코드에 결함을 야기시킬 수 있다.
- 주변환경에 의한 결함: 전자파, 자석, 공해, 자연현상 등과 같은 주변 환경의 영향으로 소프트웨어 또는 시스템이 사용하는 하드웨어에 영향을 주어 오류를 발생시킬 수 있다.(ex. 컴퓨터 속에 먼지나 벌레가 들어가서 전원이 제대로 안 켜지는 경우)

ISTQB 답)
 결함은 소프트웨어에서만 문제를 야기시킨다 >> X,
 결함은 소프트웨어와 하드웨어에서 모두 다 문제를 야기시킬 수 있다. >> O

소프트웨어의 개발, 유지보수, 운영과 테스팅

▶ 소프트웨어 개발 과정에서의 테스팅은?
- 개발 초기부터 정적 분석(코드 문을 보면서 테스팅하는 것 >>정적분석은 리뷰랑 연계됨)을 통해 시작한다.
- 개발 단계에 대응하는 테스트 레벨에 따라 테스팅을 실행한다.
- 테스트 조직의 독립성 문제.

▶ 운영 테스팅
- 기존 운영 시스템의 변경/ 단종/ 환경 변화 등으로 변경된 시스템에 대한 테스팅.

테스팅과 품질

▶ 소프트웨어 품질 특성
: 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성

▶ 테스팅
: 기능 테스팅, 비기능 테스팅

어느 정도의 테스팅이 적절한가?
▶ 테스팅의 제약 사항
- 테스팅을 많이 할수록 좋겠지만, 현실적으로는 제약이 있다.
- 대표적인 4가지 제약 사항 : 일정, 비용, 조직의 성숙도, 테스터의 역량.
▶ 적절한 테스팅의 정도는?
- 리스크 수준을 고려(리스크 큰 것부터 제거)
- 기술적인 내용, 비즈니스, 제품 리스크, 프로젝트 리스크, 시간, 비용 등을 고려.

소프트웨어 테스팅의 목적 1

소프트웨어 테스팅의 목적 2

▶ 주요 이유 
- 잔존 결함을 발견
- 개발 시스템/ SW 자신감 부여
- 결함을 미연에 방지
- 명세를 충족 확인 >>엑셀 파일 문서(테스트 베이시스 == 요구사항문서)
- 사용자 및 비즈니스의 요구 충족 확인 (사용자가 원한 거 충족 됐는지 확인)
- 비즈니스 리스크를 감소시키는 정보 제공 (발견된 결함 기반의 수치 데이터 제공)

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

소프트웨어 테스팅의 목적 3

테스팅의 목적은 테스트의 상황이나 관점에 따라 달라질 수 있다.
1. 개발 과정: 소프트웨어의 결함을 찾아내고 수정하기 위해서 가능한 많은 장애의 원인을 발생시킴.
2. 인수 과정: 사용자에게 예상된 대로 시스템이 동작하는지 확인하고, 요구사항에 맞는지 확신을 얻는 과정.
3. 품질 평가: 특정 시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달.
4. 유지 보수: 변경사항을 추가적으로 개발하는 중에 새로운 결함이 유입되었는지 확인하는 테스팅 과정 포함.
5. 운영 과정 : 신뢰성 또는 가용성과 같은 시스템의 특성을 평가.
테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함한다. 

6.1.5 테스트 실행 및 로깅 지원 도구

▶ 테스트 프레임워크

 - 테스트 수행을 위한 전체적인 프로세스

 - 테스트 자동화 설계 유형

   >> 데이터 주도 : 테이블이나 스프레드쉬트에 테스트 입력값과 예상 결과를 저장하여 스크립트를 작성하고 테스트하는 기법.

   >> 키워드 주도 : 테스트 데이터와 예상 결과 뿐만 아니라 테스트 대상 어플과 관련된 키워드를 포함한 데이터 파일을 사용하는 테스트 기법

 - 테스트 도구를 구축하는데 사용할 수 있는 재사용 및 확장 가능한 테스트 라이브러리

▶ 테스트 실행 도구

 - 저장된 입력 값들과 예상 결과를 이용해 테스트를 자동 혹은 반자동으로 실행(스크립트 언어 이용)

 - 캡쳐 & 재실행 도구 - 테스트 스르립트와 실행결과 저장

 - 테이블 기반 테스트 실행 도구

 - 도입 시 고려사항

   >> 대규모 테스트 자동화에 부적합 - 예상하지 못한 이벤트 취약

   >> 스크립트 언어에 대한 전문가 필요

   >> 테스트 결과의 비교를 위해 각각의 테스트에 대한 기대 결과 저장 필요

▶ 테스트 하네스 도구(개발자에게 더 적절한 지원) 

 - 테스트 대상 실행 환경을 시뮬레이션하여 격리된 상태에서 컴포넌트를 테스트하거나 적절한 스텁과 드라이버와 함께 테스트 할 수 있도록 지원하는 도구

 - 테스트 하네스 도구는 미들웨어 상의 테스트 실행 프레임워크를 제공하는 용도로 사용

▶ 단위 테스트 프레임워크 도구(개발자에게 더 적절한 지원)

 - 컴포넌트 테스트 레벨에 포커스를 맞춘 도구

 - 단위 테스트 레벨에 특화된 테스트 하네스로 코드를 개발하는 동안 컴포넌트 테스트를 병렬적으로 수행 하도록 지원

 - TDD(Test Driven Development) - 단위 테스트 유용

 - 단위 레벨의 테스트 케이스는 리그레션 테스트에서도 의미 있게 재사용

▶ 테스트 비교자

 - 파일, 데이터베이스 혹은 테스트 결과 사이의 차이를 비교하고 결정

 - 자동화 시스템에서 테스트 오라클(판단 근거)을 이용

 - 일반적으로 테스트 실행 도구에 포함

▶ 커버리지 측정 도구(개발자에게 더 적절한 지원)

 - 측정된 유형의 구조가 테스트 세트에 의해 얼마나 완벽하게 실행됐는지 확인

 - 코드 커버리지 도구는 측정하고자 하는 특정 유형의 코드 구조( 구문, 분기 또는 결정, 모듈 또는 함수 호출)가 몇 퍼센트 실행됐는지 측정

▶ 보안 테스트 도구

 - 컴퓨터나 바이러스나 서비스 거부 공격 검사

 - 시스템 특정 취약성을 찾기 위해 부하를 주는 도구

 - 운영체제를 시뮬레이션해 보안성을 테스트 하는 도구

6.1.6 성능과 모니터링 도구

▶ 동적 분석 도구(개발자에게 더 적절한 지원)

 - SW 실행 중에만 발생하는 시간 의존성과 메모리 누수와 같은 결함을 발견

 - 컴포넌트 / 통합 테스팅에서 사용되거나 미들웨어를 테스트할 때 사용

▶ 성능 / 부하 / 스트레스 테스팅 도구

 - 시스템이 시뮬레이션된 다양한 사용 조건 하에서 어떻게 동작하는가를 모니터링

 - 어플리케이션, 데이터베이스, 네트워크 서버와 같은 시스템 환경에 대해 부하를 시뮬레이션

 - 자동 반복 실행에 기초하고 있고 파라미터에 의해 조정

 - 성능 테스팅 전문가 필요(테스트 설꼐 및 실행 결과 해석)

▶ 모니터링 도구

 - 특정 시스템 리소스의 사용량을 지속적으로 분석하고 확인해서 보고

 - 예상되는 서비스 상의 문제점에 대해 경고

6.1.7 특정 어플리케이션 영역을 위한 도구

▶ 특정 유형의 어플리케이션만을 위해 전문화

 - 웹 기반 어플리케이션에 특화된 성능 테스팅 도구

 - 특정 개발 틀랫폼을 위한 정적 분석 도구

 - 보안 테스팅에 특화된 동적 분석 도구

 - 임베디드 시스템과 같은 특정 어플리케이션 분야를 위한 상용 도구 스위트

▶ 자동화도구범위와오픈소스참조

☞https://www.oss.kr/info_test/show/b3f50bf5-7d67-486f-bc70-d426d6f01dc4

☞http://www.pseg.or.kr/pseg/casetest

6.1.8 테스팅 도구 이외의 다른 도구

▶ 기타 도구

 - 테스터는 개발자가 사용하는 도구, 사무용으로 사용하는 도구도 활용할 수 있음

6.1.9 상용 도구와 오픈 소스 도구

▶ 오픈소스도구 

 - 무료로 사용할 수 있는 오픈소스 도구는 코드를 공개하는 경우와 사용만 무료로 하는 경우로 나누어 질 수 있음

6.2.1 테스팅 도구 도입의 잠재 이익과 위험

++ RPA(Robotic Process Automation)란? 
디지털 시스템 및 소프트웨어와 사람 사이의 상호 작용을 에뮬레이션하는 소프트웨어 로봇을 쉽게 빌드, 구현, 및 관리할 수 있도록 해주는 소프트웨어 기술

로보틱 프로세스 자동화(RPA)는 소프트웨어 로봇을 사용하여 인간이 수행하는 작업을 자동화하는 비즈니스 프로세스 자동화 기술의 한 형태이다.

▶ 자동화 도구의 장단점

 - 혜택(benefit)

   >> 테스트 노력 절감 및 실수 감소 : 반복되는 부분을 자동화 시켜, 리소스를 보다 리스크가 높은 부분의 테스팅에 집중하도록 함 / 리그레이션 테스팅 실행, 동일 테스트 데이터 재입력, 코딩 표준 준수 여부 점검

   >> 객관적인 평가 기준 및 테스트의 신뢰성 제공 : 정적 측정치, 커버리지

   >> 테스트와 테스팅에 대한 정보에 쉬운 접근성 제공 : 테스트 진척도, 결함율, 그리고 성능에 대한 통계와 그래프

   >> 월등한 일관성과 반복성 제공 : 비용 효율적 유지보수 가능 --> 고객의 요구에 빠르게 대응할 수 있는 장점

   >> 품질 향상 --> 고객 만족도 향상 

++ 패턴이 있거나 굉장히 단순한 반복이 있다면 자동화를 이용, 건 바이 건 또는 랜덤형식이다. 하면 사람이 하는게 나음.

  -리스크(risk)

   >> 고가이면서 유지비용( 가상사용자, 업그레이드, 기술 지원 등) 높음

   >> 초기 환경 및 테스트 설정에 많은 시간과 노력 소요

   >> 도구를 통해 중대하고 지속 가능한 성과를 얻기 위해 많은 시간이나 노력 소요

   >> 도구에 의해 생성된 테스트 자산인 테스트 스크립트 유지 보수가 어려움

   >> 오픈 소스와 같은 비영리 프로젝트의 갑작스러운 중단

   >> 새로운 플랫폼 지원과 같은 변화된 환경에 대한 지원 능력 부족

   >> 도구에 대한 비 현실적인 기대/ 도구에 대한 지나친 의존

6.2.2 도구 유형별 고려사항

▶ 유형별 고려사항

 - 테스트 실행 도구

   >> 테스트를 실행할 수 있도록 작성된 스크립트를 재생

   >> 이런 종류의 도구는 가치를 끌어내기 위해 상당한 노력과 전문성 필요

 - 성능 테스팅 도구

   >> 성능 테스팅을 설계하고 테스트 결과를 해석할 수 있는 전문가 필요

 - 정적 분석 도구

   >> 소스 코드에 코딩 표준을 강제하는데 사용

   >> 실제 적용시 매우 많은 경고 메시지 발생 >> 유지보수를 위한 조치 취함

 - 테스트 관리 도구

   >> 조직의 요구에 맞는 최적화된 형태의 정보를 생성하기 위해 다른 도구와 연계하여 사용할 필요가 있음

6.3.1 도구 선택 및 도입

▶ 도구 선택

 - 주요 고려 사항

   >> 조직의 성숙도, 강점과 약점을 평가한 후, 도구 지원으로 테스팅 프로세스를 개선할 수 있는 기회를 발견.

   >> 도구 도입을 위한 명확한 요구사항과 객관적인 도구 평가 기준을 가지고 도입 하고자 하는 도구를 평가.

   >> 도구가 요구되는 기능성을 만족하는 지, 도구가 본래 목표하는 바를 달성하는지를 등을 파일럿 프로젝트에 적용하여 입증.

   >> 교육 제공과 지원 능력 등을 고려하여 도구 제작 회사나 배포 회사를 평가한다.

   >> 도구 사용과 관련된 조직 내부 교육과 개별 지도에 대한 요구사항을 식별한다. 

6.3.2 파일럿 프로젝트 적용

▶ 파일럿 프로젝트

 - 목표

   >> 도구와 관련된 상세한 사항을 습득

   >> 현 프로세스나 업무에 도구를 어떻게 적용할 수 있는지 평가하고, 도구 적용을 위해 현 프로세스나 업무의 무엇을 변경해야 하는 지 결정.

   >> 도구의 사용, 관리, 저장, 유지보수하는 표준적인 방식을 결정.

   >> 합리적인 비용으로 목표하는 성과에 도달할 수 있는지 평가. (시간이 너무 들거나 도입할 때 비용이 너무 많이 들면 ㄴㄴ )

6.3.3 테스트 자동화

▶ 테스트 자동화

 - 테스트 자동화시 고려사항

   >> 적절한 자동화 대상 프로젝트 선정

   >> 자동화를 테스트 전략과 계획에 포함
   >> 자동화 도구 선정에 신중

   >> 도구에서 요구하는 것에 따라 제품과 테스트 스펙을 공식적으로 변경
   >> 자동화 테스트 지원 시설(도구) 개발 계획 고려

   >> 상세한 자동화 테스트 지침 필요

   >> 도구 전문가 참여

   >> 자동화 도구 관련 프로세스의 정의와 적용

6.3.4 도구의 배포

▶ 도입한 도구를 조직 내부에 배포

 - 성공 요인

   >> 조직의 나머지 부분에도 도구의 사용을 점진적으로 확대

   >> 도구의 사용법에 맞게 프로세스를 수정하고 개선

   >> 새로운 사용자를 위한 교육과 훈련(멘토링) 수행

   >> 사용 가이드라인을 정의

   >> 도구 사용을 통해 교훈을 얻는 방법을 마련

   >> 도구 사용 현황과 성과를 모니터링

6.3.4 도구 도입 절차

1. 도구 도입 계획 및 전략 수립
- 도구 도입 목적 정의 및 내부 요구사항 식별
- 비용 편익 비율 추정 >> 구체적인 비즈니스 사례 기반
- 상용 도구 도입 시 직접 개발하는 부분 존재(상용 도구 한계)
2. 후보 도구 선정 및 평가
- 자료 검토 및 후보 도구 선정
- 목적 달성 여부 검증
- 요구사항과 객관적인 기준으로 평가
- 교육 및 지원 능력 등 고려해 평가
3. 파일럿 프로젝트 
- 도구 적용 평가 및 프로세스 변경 대상 및 범위 결정
- 도구 사용, 관리, 저장, 유지 보수 등 표준 방식 결정(라이브러리 개발, 테스트 스위트 모듈화 등)
- 합리적인 비용으로 목적하는 성과에 도달할 수 있는지 점검
4. 도구 배포 및 확산
- 조직에 점진적으로 확대
- 도구 / 사용법에 맞게 프로세스 적용/ 개선
- 사용자 교육 및 지도 / 멘토링
- 사용 가이드 라인 정의
- 도구 사용과 성과 모니터링
- 도구 적용에 필요한 적절한 지원(인력, 기술 등)

6.4 도구 도입과 성과

▶ 도구 도입

 - 기대 효과 및 성과

   >> 사람의 실수로 인한 에러 최소화

   >> 수동으로 하기 어렵거나 불가능한 작업이 도구 지원을 통해 가능해짐

   >> 신뢰성 있는 정량적 테스팅 리포팅 >> 실시간 현황 파악 가능

   >> 테스트 시간의 단축으로 제품 릴리즈 시간 단축 가능

   >> 더욱 빈번하게 자주 테스트함으로써 신뢰성을 높일 수 있음

   >> 테스트 스킬이 높지 않아도 도구를 활용한 테스트 실행 가능

   >> 테스트 커버리지 높일 수 있음

   >> 실행 자동화 도구의 경우 리그레션 테스팅의 효과 가능

   >> 도구에 내장된 기능을 사용함으로써 객관적이고 효과적인 도구 사용

이제 드디어 6장만 남겨두고 있다. 이런 저런 일들이 있었지만 다 정리해서 공부하고 새롭게 시작할 공부로 넘어가 보자.

6.1.1 테스트 도구의 분류

▶ 테스트 도구 자동화

 - 테스팅 자동화 --> 모든 테스팅 활동에 대해 고려

   >> 반복적인 작업 자동화 또는 테스트 계획, 테스트 설계, 테스트 리포팅과 모니터링과 같은 메뉴얼 테스트 지원 --> 테스트 효율성 향상.

   >> 수작업으로 진행 시 상당한 자원을 필요로 하는 업무 자동화 (e.g. 정적 테스팅)

   >> 사람이 수행할 수 없는 업무 자동화 (e.g. 클라이언트 - 서버 어플리케이션의 대단위 성능 테스팅)

   >> 테스팅 신뢰성 향상(e.g. 대량 데이터 비교 자동화, 시뮬레이션)

 - 테스팅 활동에 따른 도구 분류

6.1.2 테스트 관리 지원 도구

▶ 테스트 관리 도구

 - 실행된 테스트와 테스팅 활동 관리를 지원

 - 추적성 제공 : 소스 문서(요구사항명세 등)와 테스트 케이스, 테스트 결과, 인시던터(결함) 간의 추적성 제공.

 - 리포트 생성 : 테스트 결과 기록, 테스트 진행 상황에 대한 리포트 생성

 - 정량적 분석 지원 : 테스트 관련 지표(실행한 테스트, 합격한 테스트 등)와 발견된 결함 또는 인시던트와 같이 테스트 대상에 관련된 정량적인 분석(측정)을 지원

 - 조직의 요구에 맞는 양식으로 유용한 정보를 생산하기 위해 스프레드시트, 테스트 실행 도구, 결함 추적 도구, 요구사항 관리 도구와 같은 다른 도구들과 연동 필요

▶ 인시던트 관리 도구

 - 보고된 인시던트 리포트 간에 우선순위 결정

 - 결함 수명 주기 관리

   >> 결함이 발견(탄생)되고, 분배되고, (재)수정되고, (재)확인되고, 종료되는 결함 수명 주기 관리

   >> 결함 수정 불필요, 수정 완료 및 테스트 준비, 수정을 다음 릴리즈로 연기 등의 결함 상태 변경

 - 결함을 기록하고 결함 관리 상황에 대한 리포트 생성(누적 s커브 등)

 - 담당자에게 수정 및 확인 테스트 등의 임무 할당

▶  요구 사항 관리 도구 

 - 요구사항 명세서 저장

 - 요구사항에 대한 특성(우선순위 포함) 저장

 - 요구사항에 대한 고유 식별자 부여

 - 요구사항에 대한 개별 테스트의 추적성 제공

 - 누락된 요구사항 또는 일관성이 없는 요구사항을 식별

** 참고: 요구사항 커버리지가 100% 커버했다고 하더라도 요구사항이 최소한 1개의 테스트 케이스로 테스트되었다는 정도만 의미함

▶ 형상 관리 도구

 - 형상관리 지원 도구는 테스트를 위한 도구는 아니지만 테스트 업무에 활용 가능함

 - 테스트웨어의 버전 관리와 저장을 위해 활용

 - 하나이상의 운영체제, 컴파일러, 브라우저 등의 하드웨어/ 소프트웨어 환경 구성에 필요

6.1.3 정적 테스팅 지원 도구

▶  정적 테스팅 지원 도구

 - 개발 프로세스 초기에 많은 결함을 발견 -> 비용 대비 효과성 올라감

 - 리뷰 프로세스 지원 도구

   >> 리뷰 프로세스에 관한 정보를 저장, 리뷰 코멘트를 저장

   >> 의사소통, 결합 및 노력을 기록/ 보고

   >> 리뷰 규칙이나 체크리스트를 참조할 수 있도록 지원

   >> 문서와 소스 코드 사이의 추적성 확보를 가능하게 함

   >> 온라인 리뷰 지원

 - 정적 분석 도구(개발자에게 더 적절한 지원)

   >> 개발자, 테스터, 품질보증 담당자가 동적 테스팅을 하기 전에 결함을 발견할 수 있도록 지원

   >> 코딩 표준을 지킬 것을 강제

   >> 구조와 의존관계를 분석(링크된 웹페이지의 구조와 의존 관계 분석 등)

   >> 코드 이해 지원

   >> 최근에는 의미 분석, 룰 체크 등으로 구분

 - 모델링 도구 (개발자에게 더 적절한 지원)

   >> 소프트웨어 모델 유효성 검증 지원

   >> 소프트웨어 모델을 기반으로 테스트 케이스 생성 지원

 - 정적 분석 툴이나 모델링 툴에서 가장 큰 이점은 개발 프로세스 초기에 더 많은 결함을 발견하게 하는 비용 효과성을 들 수 있음.

6.1.4 테스트 설계 지원 도구

▶ 테스트 설계 도구

 - 코드, 디자인 모델, 사용자 인터페이스, 요구사항으로부터 테스트 입력값과 실제 테스트 케이스를 생성

 - 일부 도구는 테스트 오라클을 사용해 예상 결괏값을 생성

 - 상태나 객체 모델로부터 생성된 테스트 케이스는 모델 구현을 검증하는데 매우 유용

▶ 테스트 데이터 준비 도구

 - 데이터 베이스, 파일, 데이터 전송을 적적히 조작해 테스트 데이터 마련

   >> 실 데이터의 익명성을 보장하여 데이터를 보호하면서 실제와 거의 동일한 데이터로 테스트 수행함.

   >> 다량의 데이터가 필요한 경우나 특정 생성 규칙에 맞는 데이터가 필요한 경우에도 유용하게 활용됨.

5.3.1 테스트 경과 모니터링

▶테스트 모니터링 목적

 - 테스트 활동에 대한 피드백과 가시성을 제공하여 테스트 계획, 또는 조직 차원의 테스트 정책이나 전략을 준수하는지 관찰.

- 테스트 케이스 작성률 : 계획 대비 완료된 테스트 케이스의 비율
- 테스트 환경 구축률 : 완료된 테스트 환경 구축 작업 비율
- 테스트 케이스 실행 관련 메트릭 : 실행된 테스트 케이스의 비율
- 통과되거나 실패된 테스트 케이스 수 : 결함 밀도, 발견된 결함과 수정된 결함, 장애율, 재 테스트 결과
- 요구사항, 리스트, 코드의 테스트 커버리지
- 제품에 대한 테스터의 주관적 자신감
- 테스트 마일스톤
- 테스팅 비용 관련 메트릭 : 비용 들여 추가 진행에 대한 이득 비

5.3.2 테스트 리포팅

▶ 테스트 리포팅

 - 테스팅 동안의 노력 및 활동에 대한 정보 및 제품의 결함 정보를 요약하여, 이해관계자의 의사결정을 지원할 목적으로 보고서를 작성하고 보고하는 활동

 - 진행 보고서 : 주요 시점에 현재 상황을 보고

   >> 주간, 월간 보고서(제품 품질, 테스트 생산성, 리스크, 프로세스 품질 등)

 - 종료 보고서 : 특정 테스트 유형 및 레벨이 종료되는 시점 보고 

   >> 테스팅 기간 동안 처리했던 주요 업무

   >> 향후 업무에 대한 의사결정을 위해 의미 있게 분석된 정보와 메트릭

 - 테스트 계획 단계에서 미리 계획하고 설계 --> 완성도 올라감.

▶ 결함 관련 메트릭 (메트릭 : 수치로 표현할 수 있는 측정)

 - 평균 결함 건수

 - 심각도별 결함 건수

 - 결함유형별 분포 비율

 - 결함 조치율

 - 발견 단계별 분포 비율

▶ 결함 발생 이유

 - 표준 미준수, 테스트 부족, 마무리 부족, 팀 간 의사소통 부족, 코딩 실수 등.

▶ 결함 유형

 - 시스템 오작동

 - 시스템이 멈추거나 다운됨

 - 예상치 못한 시스템의 동작이나 반응

 - 시스템이 가지고 있어야 할 기능, 성능 특성의 누락이나 불완전한 경우

 - 문서화 결함

 - 사용용이성 저하

 - 선능 저하

 - 데이터 훼손 및 데이터 무결성 깨짐

 - 데이터 손실 

- 수집된 메트릭의 활용
>> 해당 테스트 레벨에 대한 테스트 목적의 적절성 평가
>> 사용된 테스트 접근법의 적절성 평가
>> 목적 대비 테스팅의 효과성 평가

▶테스트 진행 보고서

 - 테스트 진행 중 합의사항과 근시일 내에 진행할 테스트 활동에 대한 내용을 포함.

   >> 소프트웨어 품질, 테스트 생산성, 소프트웨어 제품 리스크, 테스트 프로세서 품질, 테스트 문제점 등.

▶ 테스트 종료 보고서

 - 레벨별 종료 보고서와 프로젝트 종료 보고서로 나뉨

 - 테스트 계획 대비 차이

 - 오픈되어 있는 제품 리스크와 예상되는 영향

 - 해결되지 않은 결함과 그로 인해 예상되는 영향

 - 시스템 파트의 현 상태와 커버된 리스크

 - 테스트 프로세서 품질

 - 테스트 프로젝트 수행 경험

 - 다음번 테스트에 대한 조언

▶ 테스트 보고서 활용

 - 어플리케이션 출시 여부

 - 결함의 심각도 및 유형 파악

 - 요구사항에 대한 테스트 커버리지 확인

 - 어플리케이션 품질 결정

 - 다음 단계의 테스트를 위한 테스트 주요 요소 파악

▶좋은 리포팅 요건

5.3.3. 테스트 제어

▶ 테스트 제어

 - 테스트 진행 보고서나 수집된 메트릭을 근거로 테스트가 계획대로 수행되도록 가이드 하거나 정정하는 활동

 - 테스트 제어 활동의 예

   >> 테스트 모니터링으로부터 얻은 정보를 기반으로 의사 결정

   >> 프로젝트 리스크가 실제 발생 하였을 때 테스트의 우선순위를 조정

   >> 테스트 환경의 가용성 이슈가 있을 경우 테스트 일정 변경

   >> 테스트 시작 조건 조정

   >> 수정사항 빌드에 반영하기 전에, 해당 수정사항을 개발자가 재 테스트하도록 요구

5.3.4 테스트 완료

▶ 테스트 완료

 - 특정 레벨 또는 유형의 테스팅에서 테스트 계획서에서 계획했던 모든 항목들이 완료되면 시작하는 활동

 - 목적 : 테스트 자산 및 환경을 보존, 테스트 활동에서의 교훈을 찾아내어 이해관계자와 공유

 - 테스트 완료 보고서에는 테스트 계획대비 실적, 결함 상태, 리스크 등과 함께 테스트 자산의 보존 상황 및 교훈을 기록하고 이를 이해 관계자에게 보고함.

5.4 형상 관리

▶ 형상 관리의 목적

 - 프로젝트나 제품의 전체 수명 주기에 걸쳐 시스템이나 소프트웨어(컴포넌트, 데이터, 문서)의 상태를 그대로 보존, 보호하고 유지하기 위함

>> 테스트웨어 식별, 버전 관리, 변경 추적, 상호 연관성, 개발 아이템(테스트 대상)과의 연계 관리 등을 통해 테스트 프로세스 전반에 걸친 추적성 확보.
>> 테스트 문서에서 참조하고 있는 모든 관련 문서 또는 소프트웨어 아이템을 모호하지 않게 관리.

 - 테스터는 형상 관리를 통해 테스트된 품목, 테스트 문서, 케이스와 테스트 하네스(테스트환경셋팅) 등을 혼선 없이 관리하고 효율적 재사용.

 - 형상 관리 절차는 테스트 계획 단계에서 결정하고 문서화

5.5 리스크와 테스팅

▶ 리스크

 - 이벤트, 위험 요소, 위협 혹은 상황의 발생 가능성과 발생했을 경우의 바람직하지 못한 결과 즉, 잠재적 문제

5.5.1 프로젝트 리스크

5.5.2 제품 리스크

▶제품 리스크

 - 소프트웨어나 시스템에서 의도하지 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장애 영역.

   >> 개발 팀에서 전달받은 장애 가능성이 높은 소프트웨어

   >> SW 및 HW가 개인이나 회사에 손실을 끼칠 가능성

   >> 취약한 소프트웨어 특성(기능성, 신뢰성, 사용성, 성능)

   >> 의도된 기능을 수행하지 못하는 SW

 - 제품 품질에 대한 리스크

 - 리스크 vs. 테스트

   >> 리스크 : 테스트를 시작하는 시점을 결정하고 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용.

   >> 테스트 : 의도하지 않은 결과를 야기시키는 리스크를 줄이거나, 의도하지 않은 결과로 야기되는 영향과 손실을 줄이기 위해 사용.  

리스크 관리 : 리스크 식별 --> 리스크 분석 --> 리스크 계획 --> 리스크 추적
 - 리스크 식별 : 무엇이 리스크이고 어디에 리스크가 있는지 확인
 - 리스크 분석 : 중요하고, 복잡하고, 잠재적으로 결함이 많은 부분을 분석(리스크 우선 순위 결정.)
                         *리스크 = 장애 발생 빈도 x 장애로 인한 영향
 - 리스크 계획 : 리스크 정보를 근거로 대처 방안 수립 (리스크 줄이는 "테스트" 생성)
 - 리스크 추적 : 리스크 및 리스크에 대한 대응을 모니터링

▶  리스크 식별

   >> 기능적/ 기술적 아이템 모두 도출

   >> 요구사항에 따른 상위 레벨 테스트 관련 항목

   >> 아키텍처에 따른 하위 레벨 테스트 관련 항목

   >> 브레인스토밍을 통해 도출 가능

   >> 한 번에 분석해야 할 리스크 아이템 수를 적당히 제어할 필요 있음.

▶ 리스크 분석

▶ 경험적 리스크 요소

- 프로젝트 상황에 맞게 변형시킬 수 있으며, 가중치 적용 가능

▶리스크 계획 활동

 - 리스크 분석 결과를 근거로 대처 방안 수립

 - 리스크를 줄이는 테스트를 생성

 - 리스크 메트릭스 작성

   >> 리스크 분석 단계에서 합의/ 결정된 리스크 아이템별로 리스크 요소의 점수 이용하여 작성

   >> 장애 발생 가능성 리스크 요소 총점과 장애로 인한 영향 리스크 요소 총점을 구분하여 좌표에 표시

 - 테스트 레벨 별로 차별화된 리스크 기반 테스팅 전략 준비 

▶리스크 추적

 - 리스크 상황을 모니터링 해 잔존 리스크를 줄여나가는 활동

 - 리스크를 효과적으로 추적하기 위해 다양한 지표 개발 필요

5.6 인시던트 관리 ( == 결함관리)

▶ 인시던트 관리 목적

 -  테스트에서 발견한 이슈에 대해 추가적으로 수행해야 할 일에 대해 보고하고 이를 추적하기 위함

 -  인시던트 보고서 : 실제 결과와 기대 결과 사이의 불일치를 작성

 - 기 발생된 결함에 대한 재 테스트인 경우 인시던트 보고서 상태 변경

 - 인시던트 혹은 결함은 프로그램 개발, 리뷰, 테스팅 혹은 소프트웨어 제품 사용 중에 발견되거나 발생.

▶ 인시던트 혹은 결함 보고서

 목적 :
   >> 개발자와 다른 프로젝트 이해관계자가 문제점을 식별하고, 격리하고, 필요하면 정정하도록 피드백 제공.
   >> 테스트 대상 시스템의 품질과 테스팅 진척도를 추적하는 수단을 테스트 리더에게 제공.
   >> 테스트 프로세스 개선에 대한 아이디어 제공.

 - 인시던트 및 결함은 발견 및 분류에서 수정 및 확인까지 추적

 - 인시던트와 결함을 처리할 수 있는 적절한 조치에 대한 정의

 - 모든 인시던트 완료까지 관리하기 위해 조직은 인시던트 관리 프로세스 및 분류 규칙을 설정 --> 결함 생명 주기

5.7 테스트 프로세스 평가

▶  테스트 프로세스

 - 조직을 셋업하고 운영하는 관점에서의 조직 테스트 프로세스

   >> 테스트 정책과 테스트 전략을 수립하고 적용하며 개선하는 프로세스

 - 프로젝트 전체 또는 특정 레벨 및 유형의 테스트를 위한 테스트 매니지먼트 프로세스

   >> 총괄적으로 수행할 테스팅을 레벨 또는 유형 별로 수행되도록 관리, 통제.

 - 테스트 수행 관점에서 동적 테스팅과 정적 테스팅을 구분하여 각각의 프로세스 

▶ 테스트 프로세스 개선 활동(점진적, 효과적, 지속적)

 - 기대효과 

   >> 정렬되고 조직화되며 반복적

   >> 전문적이고 공학적인 활동으로 인식

   >> 개발 활동과는 독립적으로 수행

   >> 결함 발견 활동에서 결함 예방 활동으로 변화

   >> 정량적으로 측정되고, 관련 데이터가 축적되며, 테스트 프로세스의 문제점을 파악

   >> 지속적으로 개선되고 향상

   >> 테스트 비용을 절감시키고 조직 구성원의 만족감을 고취시킴