ISTQB ) 소프트웨어 테스팅의 기초에 대해 알아보자.

테스팅에 대해 알아보자.

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